爱立信LTE运维速查手册_无线

LTE运维速查手册1 Moshell/AMOS重要的常用命令
2 无线与核心网交叉问题界定常用方法与技巧2.1 无线侧
需要督导和施工队上站处理的告警：
需要后台控站人员处理的告警：
2.2.3 无线侧检查核心网相关的参数设置是否一致且正确
2.2.4 无线侧分析基站KPI/pm counter, 结合分析结果开相应的L3层trace进行抓包
2.2.5 对比3GPP标准信令流程，定位问题节点由相关工程师分析解决
3 实例分析
3.1 小区附着成功率低
3.1.1 UE附着标准信令流程
3.1.2 问题定位及解决方案
•通过pm counter/KPI 定位问题
随机接入成功率 = pmRaSuccCbra/ pmRaAttCbra
RRC建立成功率= pmRrcConnEstabSucc / (pmRrcConnEstabAtt - pmRrcConnEstabAttReatt) S1建立成功率= pmS1SigConnEstabSucc / pmS1SigConnEstabAtt
E-RAB建立成功率 = pmErabEstabSuccInit / pmErabEstabAttInit
小区附着成功率 = 随机接入成功率× RRC建立成功率× S1建立成功率× E-RAB建立成功率
其中，S1建立和E-RAB建立设计到RAN&Core的信息交互。

在这个实例中，随机接入成功率是影响小区附着率低的主要因素。

EUtranCellFDD=2 pmRaAttCbra 377 558 310 366 359
102477 94694 75550 70990 79056 70787 66067 73615 394
EUtranCellFDD=2
pmRaSuccCbra 374 369 309 355 356 437 374 373 385 358 357 354 319189
•向爱立信要求抓基站L3和baseband trace, 和3GPP标准信令流程对比进行分析3.1.3 结论
RAN侧基于竞争机制的随机接入成功率低，导致小区附着率低。

3.2 S1 中断，SCTP连接建立失败，MME disabled
3.2.1 S1
3.2.2 问题定位及解决方案
•查看基站异常的信息和Log
➢te log read
➢向爱立信要求开启基站侧S1建立相关trace以及核心网侧相关log进行问题定位分析
➢将抓包信息与标准信令对比（如下），基站收到S1 setup response消息配置不一致导致SCTP建立失败
value S1SetupResponse : {
protocolIEs {
{
id 61,
criticality ignore,
value MMEname : "SamsungMme"
},
{
id 105,
criticality reject,
value ServedGUMMEIs : {
{
servedPLMNs {
'54F060'H,
'54F080'H,
'540008'H
},
servedGroupIDs {
'0001'H
},
servedMMECs {
'01'H
}
}
}
},
{
id 87,
criticality ignore,
value RelativeMMECapacity : 1
}
}
}
}
[2011-12-06 14:10:17.096] /LmCentralConfigPT(ABNORMAL)
/vobs/erbs/node/lm/centralLmU/model/LmCentralLmU_mp750_EXE/src/UehNwIfRoIns tanceC.cpp:431 CHECK:!<0x9fd>! Configuration data in received Setup procedure message not OK, association will be closed
➢与核心网同事沟通，基站侧没有开shared-RAN feature的时候，核心网侧应该关闭multi-PLMN feature; 此时基站只能接收一个PLMN的配置
3.2.3 结论
无线侧与核心网配置不一致导致该问题的出现。

3.3 寻呼成功率低
3.3.1 寻呼流程
UE eNB MME
3.3.2 问题定位及解决方案
对于涉及基站，核心网和UE的性能问题，推荐首先查看pm counter/KPI.
•查看基站端跟Paging有关的pm counter，通过如下counter我们可以大致了解paging消息丢失的位置。

pmPagS1Discarded：pmPagS1Received超过了s1接口能接受Paging的最大数目，表示基站丢弃的S1口的Paging消息
pmPagS1Received：基站收到来自核心网Paging消息的数目
pmPagDiscarded：由于某种原因（如阻塞）小区丢弃从基站路由过来的Paging消息的数目
pmPagReceived：基站路由到某个小区的Paging消息的数目
➢如果pmPagS1Discarded过大，说明大量Paging从核心网下发导致基站丢失消息
➢如果pmPagDiscarded过大，查该小区阻塞情况
➢如果上述pm counter都正常，确认UE是否受到Paging消息
o如果UE没收到，检查UE的无线环境
o如果UE收到但并没有完成Paging的功能（如接听来电或者下行数据/短信等），向爱立信要求抓L3 trace,与实例3.1标准信令流程对比查看
哪一步出问题导致业务请求未完成。

追踪到出问题的某一条信令然后定
位问题节点（RAN或者Core）
如下图是处于RRC_IDLE状态下LTE手机接到GSM手机电话的CSFB信
令流程图
3.4 L/W异系统切换失败
3.4.1 L/W IRAT切换标准信令流程
3.4.2 问题定位及解决方案
•无线侧(L/W)和核心网同时对切换失败进行trace抓包分析，无线侧分析如下➢eNB成功发送Handover Required给MME
➢MME没有回复Handover Command给eNB
➢eNB端5s计时器超时，触发Handover Cancel
➢问题定位：核心网MME为什么不发送Handover Command给eNB •RNC侧和核心网trace分析，对比3GPP标准信令流程找到root cause ➢核心网侧Trace分析
o MME收到eNB发送的Handover Required
o MME发送Relocation Request给SGSN，且SGSN收到该消息
o没有看到SGSN传送Relocation Request给RNC
o证实RNC没有收到SGSN发送的Relocation Request
3.4.3 结论
核心网SGSN处于某种原因不传送Relocation Request给目标RNC；核心网工程师修改核心网参数配置，L/W异系统切换成功
3.5 UE附着失败
3.5.1 问题定位
•问题
➢eNB 13670_L 所有UE附着失败，但是小区正常开启
•分析
➢无线侧(LTE)，核心网和UE端同时进行抓log，从eNB和UE log可以看到，在UE attach的过程中：
o eNB发送InitialUEMessage给MME
o MME直接通知eNB释放UE
➢核心网侧
o MME收到eNB发送的InitialUEMessage
o MME没有发送S11 Create Session Request给SGW
•问题定位：核心网MME为什么不发送S11 Create Session Request给SGW
•无线侧与核心网内部会议，得知客户使用了DNS,MME在发送session creation request给SGW之前需要与DNS沟通获得SGW的IP地址
3.5.2 正常流程
3.5.3 解决方案
•这个站是新开站，TAC设置成15039，它是用来对应SGW IP地址的一个参数；如果客户没有添加该TAC与SGW的对应关系,MME将找不到对应的SGW
•结论：与客户沟通后，发信信息不透明；客户新增的TAC 15039忘记添加进DNS，并没有和正确的SGW IP地址进行映射
4 无线和核心网交叉问题解决措施
•无线侧基站和核心网侧节点软件版本是否支持
•无线侧检查核心网相关的参数设置是否一致且正确
•基站pm counter/KPI检查，初步定位问题
•无线侧L3层trace和核心网相关节点trace抓包记录
•对比3GPP标准信令流程，找到异常或者错误信令，定位问题节点由相关工程师分析解决。