LTE topn处理

(1) TOPN 处理方法汇总：1、日常 KPI 指标监控TOPN 小区 KPI 分为几大类：接入类，移动类，保持类，.如下图所示：KPI Category KPI ElementRRC 建立成功率E-RAB 建立成功率接入类RRC 连接建立最大用户数系统内同频切换出成功率系统内异频切换出成功率移动类重定向到 TDS/GSM 比例保持类 E-RAB 掉话率干扰类 RSSI/单 RB 干扰噪声2、下面对各类 TOP 小区处理思路及方法说明2.1 RRC 建立失败 TOP10 及原因分析：A 指标名如下：RRC 连接建立成功率 RRC Establishment Success Rate筛选出 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/PRACH CONFIG INDEX 配置等随机接入参数。2.2 E-RAB 建立失败 TOP 及原因分析A 指标名如下：E-RAB 建立成功率 E-RAB Setup Success Rate筛选出 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 接纳失败”,信令跟踪进行分析。查看小区配置的相关接纳参数是否正常，比如小区 Active E-RAB 数门限是否设置过小。2 如果主要为 “空口失败”。空口失败(个) 最直接的理解就是用户自己造成的原因，如拔插终端，终端异常吊死，或者进入恶劣的无线环境导致建立失败（对于是不是弱覆盖导致可以先查看目标小区的RRC 连接是否正常.）3 如果主要为 “其他原因”，对于初始的 E-RAB 建立失败次数，其他原因(个) 这项则需要对信令进行跟踪分析，以及查看相关的参数是不是配置错误(对于 ERAB 建立失败其它原因首先可以对参数先进行排查，如：PCI 的 PRACH 映射关系设置不规范， TAC 配置是否合理，频点对应的带宽是否正确以及相应的带宽分配的 RB 数目是否正确等等。下面列举信令跟踪分析失败几个案例：. 对于 ERAB 建立成功率低的两个案例：第一种为信令里面曝出现 INTIAL CONTEST SETUP FAILURE（初始上下文设置失败）这一条，原因侧为 transport=0:TS1AP_transport_resource_unavailable,字面上的意思就是传输资源不可用.出现这种情况的时候自己首先可以做一个 PING 包测试，方法：首先查看目标小区的所在的核心网 IP 地址是多少，然后拿目标基站 ENBID 来对核心网做 PING 包测试，查看该目标小区的时延和丢包率是否异常，如果异常则肯定是传输方面出现了问题.如果查看传输方面正常，那就建议将基站进行整表同步，也就是所谓的重启，对单板或者 RRU进行复位就可以了。第二种为信令里面出现了 INTIAL CONTEST STEUP Failure，失败的原因为TS1AP_failure-in-the-radio-interface-procedure (无限资源借口不可用 )这个有可能是现场督导将鸳鸯线接反导致，或者是干扰导致，也可以通过整表同步进行尝试.还有一种情况是可能是有干扰源存在导致的 ERAB 建立失败，这时候就需要你对失败的目标小区进行频谱扫描查看是否存在干扰（单 RB 情况下频谱扫描值一般稳定在 -118 左右）。2.3 ERAB 异常释放 TOP10 及原因分析：A 指标名如下：E-RAB 掉话率 E-RAB Drop Rate筛选出 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 值如下：C373210392E-RAB 释放次数，空口定时器超时Number of E-RAB Release due to Uu Interface TimeoutC373210393E-RAB 释放次数，空口质量差触发 RLFNumber of E-RAB Release due to RLF triggered by Poor Uu QualityC373210394E-RAB 释放次数，RLC 达到最大重传次数Number of E-RAB Release due to Maximum of RLC RetransmissionC373210395E-RAB 释放次数，PDCP 完整性保护失败Number of E-RAB Release due to PDCP Integrity protection Failure（对于 counter C373210393，后期版本中没有该 counter，如果 KPI 服务器上找不到该counter 值属于正常现象，不导该 counter 值即可）导出该 counter 值后，再话 excel 曲线分析： 如果主要为“空口定时器超时 ”，一般无线环境导致或天馈问题。 如果主要为“RLC 达到最大重传次数 ”，一般无线环境导致或天馈问题。 如果主要为“PDCP 完整性保护失败 ”，请联系用户面排查。2 如果主要为 “由于 ENB 其他异常原因”：需要抓取信令进一步分析。3 如果主要为 “MME 由于 ErrorInd 或者跨站重建立导致的释放”：首先排查覆盖问题，若覆盖没问题，需要抓取信令进一步分析，方法如下：请通过实时 kpi 监控如上占据“主要因素”的 counter 值和重点小区（小区数最好为只监控一个，因为信令跟踪多个小区信令可能会丢失对于问题分析不利），同时开启信令跟踪（和内部信令，详情方法见该文档前文描述），一旦发现“主要因素”的 counter 值出现，反馈该实时 KPI 和对应时段的信令跟踪给控制面同事。4 如果主要为 “ENB 由于 S1 链路故障发起释放”：请进一步细化 counter 值，再导一下 KPI 数据，counter 值如下：C373210396E-RAB 释放次数，Gtpu ErrInd触发释放Number of E-RAB Release due to GTPU Error IndicationC373210397E-RAB 释放次数，Path 故障触发释放Number of E-RAB Release due to Path FaultC373210398E-RAB 释放次数，光口故障触发释放Number of E-RAB Release due to Optical Port Fault 如果主要为“Gtpu ErrInd 触发释放”，则须核心网排查为撒发送 GTPU 层错误指示给基站。 如果主要为“Path 故障触发释放 ”， 一般传输配置问题导致，需联系传输排查。 如果主要为“光口故障触发释放 ”，请排查 ENB 上的 BPL 板上的光模块是否物理损坏？可以尝试换正常的光模块，若还不正常，请确认平台和 RRU 同事排查。2.4 切换失败 TOP10 及原因分析：通过 KPI 报表导出切换成功率比较低小区，然后导出切换失败的具体 COUNTER，由于涉及到切换失败的 COUNTER 比较多，在此文就不列举。下面对切换准备及切换执行阶段各种失败原因及处理思路进行分析。切换准备阶段：对于源侧而言 eNB 收到切换测量报告到等待目标侧切换请求确认消息（S1切换收到 HANDOVER COMMAND；X2 切换收到 HANDOVER REQUEST ACK）对于目标侧而言，收到源侧的 HANDOVER REQUST 到发送 HANDOVER REQUEST ACK。（1）切换准备失败，源侧、目标侧发生重建立一般情况是由于基站切换参数设置不合理导致 UE 切换过早或过晚。需要优化切换参数。 可以通过导出切换时服务小区、目标小区 RSRP 及 RSRQ 等报表，确认切换时候无线情况。具体示例如下：目标小区RSRP 在范围[-100,-96]的上报次数目标小区 RSRP在范围[-95,-91]的上报次数目标小区 RSRP在范围[-90,-86]的上报次数目标小区 RSRP在范围[-85,-81]的上报次数目标小区 RSRP在范围[-80,-76]的上报次数29 31 39 14 128 53 48 27 13（2）切换准备失败，目标侧准备失败需要导处“小区对”的切换 KPI，找出这个目标小区，然后再导出目标侧