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 IRA T切换标准信令流程
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标准信令流程，找到异常或者错误信令，定位问题节点由相关工程师分析解决