LTE topn处理.docx

LTE topn处理.docx

《LTE topn处理.docx》由会员分享，可在线阅读，更多相关《LTE topn处理.docx（9页珍藏版）》请在冰点文库上搜索。

LTEtopn处理

（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连接失败，定时器超时（次）这一项可通过后台调整如下参数解决：

1）减小控制面user-inactivity定时器以及增大等待RRC建立完成的定时器来提升RRC连接成功率.

2）调整UE最大发射功率（取值建议23dBm,设置偏低会导致随机接入失败概率增加）。

3）调整PRACH前缀最大发送次数增大随机接入成功率，PRACH前缀最大发送次数这项参数不能设置过高，过高会增加对邻区的干扰，取值建议：

8次或10次.

4）调整最小接入电平门限。

2 如果主要为“eNB接纳失败”。

eNB接纳失败可理解为基站拥塞导致，结合后台统计该小区实时在线用户数目是否已经达到系统上限。

对于此类问题最好的解决方法就是调整拥塞小区的接纳用户数门限值.

3 如果主要为“其他原因”。

对于初始的RRC建立失败次数，其他原因（个）这项则需要对信令进行跟踪分析，以及查看相关的参数是不是配置错误（如：

PCI的PRACH映射关系设置不规范，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协助定位。