TOP小区处理-RRC重建成功率低优化案例

1、RRC重建成功率低优化案例 摘要RRC重建流程图RRC重建成功流程图：RRC重建失败流程图：（1）协议3GPP36.331定义触发重建原因包括如下几类1>upondetecting radio link failure, 2>uponhandover failure, 3>uponmobility from E-UTRA failure, 4>uponintegrity check failure indication from lower layers; 5>uponan RRC connection reconfiguration failure（2）reco

2、nfiguration failure定义：UE在安全模式激活的状态下，如果收到了重配置消息后对于重配置消息内的信元无法匹配/兼容，则发起原因值为“reconfiguration failure”的重建。（3）handover failure定义UE在切换流程中，在收到了切换的重配置消息之后，会启动T304，但如果在T304超时之前UE无法完成在目标小区的随机接入，则会发起原因值为“handover failure”的重建。（4）协议3GPP36.331定义重建失败（5）重建原因（radio link failure）重建常见原因为RLF, 如果UE检测到当前检测到“radio link fa

3、ilure”，则会发起原因值为“other”问题分析流程图1、首先检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。2、通过COUNTER分析重建流程图如下：关键字：RRC重建，掉话，CELL TRACE，信令1. 问题描述进行FDD-LTE网络每日TOP小区处理的过程中，XZL2NTD铜山区_茅村周宅子WBBU1-2的RRC重建成功率为31.31%，该数据严重低于正常RRC重建成功率的平均值，且已持续了一段时间。通过对XZL2NTD铜山区_茅村周宅子WBBU1-2的重建次数统计，对小区问题进行了分析。作为后台日常KPI优化的一个重要指标，RRC重建对全网掉线率等指标起着至关重要

4、的作用。通过提取相关COUNTER统计出RRC重建的相关原因值，如下图所示：如上图所示，RRC重建失败原因值多为OTHER FAILURE, 此时，使用CELL TRACE对目标小区进行TRACE并进行分析； 2. 问题分析2.1 TRACE分析过程RRCConnectionReestablishmentReestablishmentRequest消息如下：Request：<UL-CCCH-Message> <message> <c1> <rrcConnectionReestablishmentRequest> <criticalExten

5、sions> <rrcConnectionReestablishmentRequest-r8> <ue-Identity> <c-RNTI> 0000011011010110 </c-RNTI> <physCellId>328</physCellId> <shortMAC-I> 0101110011010111 </shortMAC-I> </ue-Identity> <reestablishmentCause number="2"><othe

6、rFailure/></reestablishmentCause> <spare> 00 </spare> </rrcConnectionReestablishmentRequest-r8> </criticalExtensions> </rrcConnectionReestablishmentRequest> </c1> </message></UL-CCCH-Message>附件是完整信令：由以上信令可知，该信息包含的C-RNTI为1750和且对端PCI为328，原因值显示为O

7、THER FAILURE;同时找出了很多重建立失败的原因值都为OTHER FAILURE，且对端为PCI=328的站点发生的次数较多，此时，可TRACE周边站点在TRACE中PCI重复出现次数较多的小区。MAPINFO图层显示如下：由图可见，PCI=328的该小区距离茅村周宅子_2距离较近，此时，定制PCI=328的小区TRACE,对端PCI为328的小区跟踪信息分析如下；根据上面茅村周宅子_2小区的信令中获得的C-RNTI=1750，对应着找到PCI=328的小区INTERFACE面的L3Message信息中该时间段的C-RNTI=1750的显示如下：根据上图中所对应的TRSR=855信息去

8、Recording Session面找到TRSR=855的该信令消息，如下图所示：该信令信息见此附件：2.2信令分析其中，RRCConnectionReestablishmentReestablishmentRequest如下：<UL-CCCH-Message> <message> <c1> <rrcConnectionRequest> <criticalExtensions> <rrcConnectionRequest-r8> <ue-Identity> <s-TMSI> <mmec>

9、 00000001 </mmec> <m-TMSI> 11011000000011111100110000011010 </m-TMSI> </s-TMSI> </ue-Identity> <establishmentCause number="4"><mo-Data/></establishmentCause> <spare> 0 </spare> </rrcConnectionRequest-r8> </criticalExtensi

10、ons> </rrcConnectionRequest> </c1> </message></UL-CCCH-Message>RRCConnectionRequest信令见附件：其中，在该条信令的L3Message显示如下：可见，在该小区上产生了一系列测量报告；Diagram图显示如下：其中L3Message details信息显示如下：<UL-DCCH-Message> <message> <c1> <measurementReport> <criticalExtensions>

11、 <c1> <measurementReport-r8> <measResults> <measId>2</measId> <measResultPCell> <rsrpResult><!CDATA -119.0 <= rsrpResult < -118.0 dBm ></rsrpResult> <rsrqResult><!CDATA -18.0 <= rsrqResult < -17.5 dB ></rsrqResult> &

12、lt;/measResultPCell> <measResultNeighCells> <measResultListEUTRA> <element> <physCellId>254</physCellId> <measResult> <rsrpResult><!CDATA -102.0 <= rsrpResult < -101.0 dBm ></rsrpResult> <rsrqResult><!CDATA -9.0 <= rsrqResult

13、 < -8.5 dB ></rsrqResult> </measResult> </element> </measResultListEUTRA> </measResultNeighCells> </measResults> </measurementReport-r8> </c1> </criticalExtensions> </measurementReport> </c1> </message></UL-DCCH-Message

14、>同时，在Measurement图中显示信息如下:由上图可知，在茅村周宅子_2发生重建的该时间点，邻区中存在RSRP由于PCI=328的小区，且时间轴显示的时间也达到了切换的时间条件；TA图显示如下：上图可知，在茅村周宅子_2发生重建的该时间点，用户距离基站位置约1km左右，距离较近，不存在异常弱覆盖等情况。通过以上信令可知，虽然主服务小区（PCI=328）的RSRP值还处于正常水平，但此时邻区（茅村周宅子_2）的RSRP已高于服务小区约8dBm，服务小区RSRQ已降低到-15左右，信号质量较差。信令上显示，终端一直上报MR测量，但基站未下发切换命令，终端未执行同频切换，因此判断终端发起

15、RRC重建原因为：测量邻区RSRP高于服务小区，终端上报MR但未执行切换导致服务小区质量下降，发起原因值为”OTHERFAILURE”的RRC重建。3. 问题解决1.2.3.3.1 解决方案按照数据显示，邻区茅村周宅子_2小区的RSRP优于主服务小区（PCI=328）的RSRP，且上报时间已超出了正常切换的时间，该用户从PCI=328的小区释放后理论上应该是正常切换至茅村周宅子_2，而非通过RRC重建到茅村周宅子_2小区；由上可知，该情况属于邻区漏配导致的RRC重建失败。核查茅村周宅子与周边站点的邻区关系，发现该邻区关系不存在，属于邻区漏配的现象，此时，优化该站点与周边站点的邻区关系。邻区配置后，未出现RRC重建失败事件。3.2 优化结果处理后，指标统计如下：优化前后指标对比图：RRC连接重建成功率优化前后对比图：指标已恢复，问题已解决。4. 方法总结RRC重建