最新LTEtopn处理.docx
《最新LTEtopn处理.docx》由会员分享，可在线阅读，更多相关《最新LTEtopn处理.docx（10页珍藏版）》请在冰点文库上搜索。
最新LTEtopn处理
LTE-topn处理
（1） TOPN处理方法汇总：
1、日常KPI指标监控
TOPN小区KPI分为几大类：
接入类，移动类，保持类，.如下列图所示：
KPICategory
KPIElement
接入类
RRC建立成功率
E-RAB建立成功率
RRC连接建立最大用户数
移动类
系统内同频切换出成功率
系统内异频切换出成功率
重定向到TDS/GSM比例
保持类
E-RAB掉话率
干扰类
RSSI/单RB干扰噪声
2、下面对各类TOP小区处理思路及方法说明
2.1RRC建立失败TOP10及原因分析：
A 指标名如下：
RRC连接建立成功率
RRCEstablishmentSuccessRate
筛选出RRC连接建立成功率的TOP小区明细。
B 具体KPI分析：
通过excel画曲线图分析如下counter值与rate本身的关联性，通过excel曲线图分析成功率底下的主要原因是如下哪个主要因素引起？
mt-Access类型RRC连接失败次数，定时器超时、
mt-Access类型RRC连接失败次数，eNB接纳失败、
mt-Access类型RRC连接失败次数，其他原因
mo-Signalling类型RRC连接失败次数，定时器超时、
mo-Signalling类型RRC连接失败次数，eNB接纳失败、
mo-Signalling类型RRC连接失败次数，其他原因、
mo-Data类型RRC连接失败次数，定时器超时、
mo-Data类型RRC连接失败次数，eNB接纳失败、
mo-Data类型RRC连接失败次数，其他原因
曲线分析结果：
1 如果主要为“定时器超时〞。
定时器超时，根本上是由于弱覆盖引起的。
对于RRC连接失败，定时器超时〔次〕这一项可通过后台调整如下参数解决：
射关系设置不标准，NCS/PRACHCONFIGINDEX配置等随机接入参数。
2.2E-RAB建立失败TOP及原因分析
A 指标名如下：
E-RAB建立成功率
E-RABSetupSuccessRate
筛选出RAB连接建立成功率的TOP小区明细
B 具体KPI分析：
通过excel画曲线图分析如下counter值与rate本身的关联性，通过excel曲线图分析成功率底下的主要原因是如下哪个主要因素引起？
初始的E-RAB建立失败次数，eNB接纳失败、
初始的E-RAB建立失败次数，空口失败、
初始的E-RAB建立失败次数，平安激活失败、
初始的E-RAB建立失败次数，消息参数错误、
初始的E-RAB建立失败次数，RRC重建立原因、
初始的E-RAB建立失败次数，其他原因、
增加的E-RAB建立失败次数，eNB接纳失败、
增加的E-RAB建立失败次数，空口失败、
增加的E-RAB建立失败次数，切换引起+增加的E-RAB建立失败次数，消息参数错误、
增加的E-RAB建立失败次数，RRC重建立原因、
增加的E-RAB建立失败次数，其他原因
曲线分析结果：
1 如果主要为“eNB接纳失败〞,
信令跟踪进行分析。
查看小区配置的相关接纳参数是否正常，比方小区ActiveE-RAB数门限是否设置过小。
2 如果主要为“空口失败〞。
空口失败（个）最直接的理解就是用户自己造成的原因，如拔插终端，终端异常吊死，或者进入恶劣的无线环境导致建立失败〔对于是不是弱覆盖导致可以先查看目标小区的RRC连接是否正常.〕
3 如果主要为“其他原因〞，
对于初始的E-RAB建立失败次数，其他原因（个）这项那么需要对信令进行跟踪分析，以及查看相关的参数是不是配置错误（对于ERAB建立失败其它原因首先可以对参数先进行排查，如：
PCI的PRACH映射关系设置不标准，TAC配置是否合理，频点对应的带宽是否正确以及相应的带宽分配的RB数目是否正确等等。
下面列举信令跟踪分析失败几个案例：
. 对于ERAB建立成功率低的两个案例：
第一种为信令里面曝出现INTIALCONTESTSETUPFAILURE〔初始上下文设置失败〕这一条，原因侧为transport=0:
TS1AP_transport_resource_unavailable,字面上的意思就是传输资源不可用.出现这种情况的时候自己首先可以做一个PING包测试，方法：
首先查看目标小区的所在的核心网IP地址是多少，然后拿目标基站ENBID来对核心网做PING包测试，查看该目标小区的时延和丢包率是否异常，如果异常那么肯定是传输方面出现了问题.如果查看传输方面正常，那就建议将基站进行整表同步，也就是所谓的重启，对单板或者RRU进行复位就可以了。
第二种为信令里面出现了INTIALCONTESTSTEUPFailure，失败的原因为TS1AP_failure-in-the-radio-interface-procedure （无限资源借口不可用）这个有可能是现场督导将鸳鸯线接反导致，或者是干扰导致，也可以通过整表同步进行尝试.
还有一种情况是可能是有干扰源存在导致的ERAB建立失败，这时候就需要你对失败的目标小区进行频谱扫描查看是否存在干扰〔单RB情况下频谱扫描值一般稳定在-118左右〕。
2.3ERAB异常释放TOP10及原因分析：
A 指标名如下：
E-RAB掉话率
E-RABDropRate
筛选出RAB连接建立成功率的TOP小区明细
B 具体KPI分析：
通过excel画曲线图分析如下counter值与rate本身的关联性，通过excel曲线图分析成功率底下的主要原因是如下哪个主要因素引起？
：
E-RAB释放次数，由于ENB过载控制导致的释放、
E-RAB释放次数，由于ENB其他异常原因、
E-RAB释放次数，由于ENB的无线链路失败、
E-RAB释放次数，由于ENB重建立失败、
E-RAB释放次数，由于ENB小区闭塞，复位、
E-RAB释放次数，MME由于ErrorInd或者跨站重建立导致的释放、
E-RAB释放次数，ENB由于S1链路故障发起释放
曲线分析结果：
1 如果主要为“由于ENB的无线链路失败〞
请进一步细化counter值，再导一下KPI数据，counter值如下：
C373210392
E-RAB释放次数，空口定时器超时
NumberofE-RABReleaseduetoUuInterfaceTimeout
C373210393
E-RAB释放次数，空口质量差触发RLF
NumberofE-RABReleaseduetoRLFtriggeredbyPoorUuQuality
C373210394
E-RAB释放次数，RLC到达最大重传次数
NumberofE-RABReleaseduetoMaximumofRLCRetransmission
C373210395
E-RAB释放次数，PDCP完整性保护失败
NumberofE-RABReleaseduetoPDCPIntegrityprotectionFailure
〔对于counterC373210393，后期版本中没有该counter，如果KPI效劳器上找不到该counter值属于正常现象，不导该counter值即可〕
导出该counter值后，再话excel曲线分析：
Ø 如果主要为“空口定时器超时〞，一般无线环境导致或天馈问题。
Ø 如果主要为“RLC到达最大重传次数〞，一般无线环境导致或天馈问题。
Ø 如果主要为“PDCP完整性保护失败〞，请联系用户面排查。
2 如果主要为“由于ENB其他异常原因〞：
需要抓取信令进一步分析。
3 如果主要为“MME由于ErrorInd或者跨站重建立导致的释放〞：
首先排查覆盖问题，假设覆盖没问题，需要抓取信令进一步分析，方法如下：
请通过实时kpi监控如上占据“主要因素〞的counter值和重点小区〔小区数最好为只监控一个，因为信令跟踪多个小区信令可能会丧失对于问题分析不利〕，同时开启信令跟踪〔和内部信令，详情方法见该文档前文描述〕，一旦发现“主要因素〞的counter值出现，反应该实时KPI和对应时段的信令跟踪给控制面同事。
4 如果主要为“ENB由于S1链路故障发起释放〞：
请进一步细化counter值，再导一下KPI数据，counter值如下：
C373210396
E-RAB释放次数，GtpuErrInd触发释放
NumberofE-RABReleaseduetoGTPUErrorIndication
C373210397
E-RAB释放次数，Path故障触发释放
NumberofE-RABReleaseduetoPathFault
C373210398
E-RAB释放次数，光口故障触发释放
NumberofE-RABReleaseduetoOpticalPortFault
Ø 如果主要为“GtpuErrInd触发释放〞，那么须核心网排查为撒发送GTPU 层错误指示给基站。
Ø 如果主要为“Path故障触发释放〞，一般传输配置问题导致，需联系传输排查。
Ø 如果主要为“光口故障触发释放〞，请排查ENB上的BPL板上的光模块是否物理损坏？
可以尝试换正常的光模块，假设还不正常，请确认平台和RRU同事排查。
2.4切换失败TOP10及原因分析：
通过KPI报表导出切换成功率比拟低小区，然后导出切换失败的具体COUNTER，由于涉及到切换失败的COUNTER比拟多，在此文就不列举。
下面对切换准备及切换执行阶段各种失败原因及处理思路进行分析。
切换准备阶段：
对于源侧而言eNB收到切换测量报告到等待目标侧切换请求确认消息〔S1切换收到HANDOVERCOMMAND；X2切换收到HANDOVERREQUESTACK〕
对于目标侧而言，收到源侧的HANDOVERREQUST到发送HANDOVERREQUESTACK。
〔1〕切换准备失败，源侧、目标侧发生重建立
一般情况是由于基站切换参数设置不合理导致UE切换过早或过晚。
需要优化切换参数。
可以通过导出切换时效劳小区、目标小区RSRP及RSRQ等报表，确认切换时候无线情况。
具体例如如下：
目标小区RSRP在范围[-100,-96]的上报次数
目标小区RSRP在范围[-95,-91]的上报次数
目标小区RSRP在范围[-90,-86]的上报次数
目标小区RSRP在范围[-85,-81]的上报次数
目标小区RSRP在范围[-80,-76]的上报次数
29
31
39
14
1
28
53
48
27
13
〔2〕切换准备失败，目标侧准备失败
需要导处“小区对〞的切换KPI，找出这个目标小区，然后再导出目标侧切换KPI，查看切换准备失败原因。
一般情况是由于源侧邻区中目标侧数据配置与实际不一致导致。
〔3〕切换准备失败，资源分配失败
一般是由于资源相关参数配置异常导致，重点检查资源配置参数。
包括无线资源及传输资源参数。
〔4〕切换准备失败，其他原因
需要抓取信令进行分析。
〔5〕切换准备失败，等待切换响应定时器超时
S1切出，源侧等待MMEhandovercommand超时，同样需要通过“小区对〞KPI，找到目标小区，假设目标侧已经发送了S1handoverrequestACK，那么需要MME侧来排查为什么handovercommand没有发送给源侧。
〔可先检查一下目标侧邻接小区邻接关系配置、目标侧小区S1链路配置〕。
〔6〕切换准备失败，源侧取消
目标侧的counter，这个也需要先通过“小区对〞KPI，来找出对应的源侧小区，进而定位源侧切换取消的原因。
切换执行阶段：
源侧下发切换命令〔重配消息〕到收到MME释放命令〔S1切换〕或目标站释放消息〔X2切换〕；目标侧收到重配完成到给MME发送切换完成指示〔S1切换〕或给源侧发送释放消息〔X2切换〕
〔1〕切换执行失败，源侧发生重建立
看切换时源和目标侧RSRP是否合理〔同切换准备失败分析1，可以通过性能报表导出切换时RSRP情况〕，确认切换参数是否配置合理。
如果这种失败集中发生在切换至某一个或多个小区，可能目标侧小区PRACH参数设置异常或存在冲突，导致无法与目标侧建立同步。
〔2〕切换执行失败，等待UECONTEXTRELEASE消息超时
源侧未收到MME的释放命令〔S1切换〕或目标站的释放消息〔X2切换〕，需要通过“小区对〞KPI找到目标侧，查看是否已经发送切换完成标识（S1）或释放消息（X2），假设已发送那么需要排查传输问题。
〔3〕切换执行失败，其他原因
一般情况下，是由于发生跨站重建立导致，需要抓取信令确认。
外场多数情况下，是由于目标侧存在同频同PCI小区导致。
〔4〕切换执行失败，PATHSWITCH 失败
此情况很少发生，假设发生需要MME协助定位。
升级会员 