TOP小区管理方案计划RRC重建成功率低优化案例解析Word文件下载.docx
《TOP小区管理方案计划RRC重建成功率低优化案例解析Word文件下载.docx》由会员分享，可在线阅读，更多相关《TOP小区管理方案计划RRC重建成功率低优化案例解析Word文件下载.docx（15页珍藏版）》请在冰点文库上搜索。
5>
uponanRRCconnectionreconfigurationfailure
（2）reconfigurationfailure定义：
UE在安全模式激活的状态下，如果收到了重配置消息后对于重配置消息内的信元无法匹配/兼容，则发起原因值为“reconfigurationfailure”的重建。
（3）handoverfailure定义
UE在切换流程中，在收到了切换的重配置消息之后，会启动T304，但如果在T304超时之前UE无法完成在目标小区的随机接入，则会发起原因值为“handoverfailure”的重建。
（4）协议3GPP36.331定义重建失败
（5）重建原因（radiolinkfailure）
重建常见原因为RLF,如果UE检测到当前检测到“radiolinkfailure”，则会发起原因值为“other”
问题分析流程图
1、首先检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。
2、通过COUNTER分析重建流程图如下：
关键字：
RRC重建，掉话，CELLTRACE，信令
1.问题描述
进行FDD-LTE网络每日TOP小区处理的过程中，XZL2NTD铜山区_茅村周宅子WBBU1-2的RRC重建成功率为31.31%，该数据严重低于正常RRC重建成功率的平均值，且已持续了一段时间。
通过对XZL2NTD铜山区_茅村周宅子WBBU1-2的重建次数统计，对小区问题进行了分析。
作为后台日常KPI优化的一个重要指标，RRC重建对全网掉线率等指标起着至关重要的作用。
通过提取相关COUNTER统计出RRC重建的相关原因值，如下图所示：
如上图所示，RRC重建失败原因值多为OTHERFAILURE,此时，使用CELLTRACE对目标小区进行TRACE并进行分析；
2.问题分析
2.1TRACE分析过程
RRCConnectionReestablishmentReestablishmentRequest消息如下：
Request：
<
UL-CCCH-Message>
<
message>
c1>
rrcConnectionReestablishmentRequest>
criticalExtensions>
rrcConnectionReestablishmentRequest-r8>
ue-Identity>
c-RNTI>
0000011011010110
/c-RNTI>
physCellId>
328<
/physCellId>
shortMAC-I>
0101110011010111
/shortMAC-I>
/ue-Identity>
reestablishmentCausenumber="
2"
>
otherFailure/>
/reestablishmentCause>
spare>
00
/spare>
/rrcConnectionReestablishmentRequest-r8>
/criticalExtensions>
/rrcConnectionReestablishmentRequest>
/c1>
/message>
/UL-CCCH-Message>
附件是完整信令：
由以上信令可知，该信息包含的C-RNTI为1750和且对端PCI为328，原因值显示为OTHERFAILURE;
同时找出了很多重建立失败的原因值都为OTHERFAILURE，且对端为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信息去RecordingSession面找到TRSR=855的该信令消息，如下图所示：
该信令信息见此附件：
2.2信令分析
其中，RRCConnectionReestablishmentReestablishmentRequest如下：
rrcConnectionRequest>
rrcConnectionRequest-r8>
s-TMSI>
mmec>
00000001
/mmec>
m-TMSI>
11011000000011111100110000011010
/m-TMSI>
/s-TMSI>
establishmentCausenumber="
4"
mo-Data/>
/establishmentCause>
0
/rrcConnectionRequest-r8>
/rrcConnectionRequest>
RRCConnectionRequest信令见附件：
其中，在该条信令的L3Message显示如下：
可见，在该小区上产生了一系列测量报告；
Diagram图显示如下：
其中L3Messagedetails信息显示如下：
UL-DCCH-Message>
measurementReport>
measurementReport-r8>
measResults>
measId>
2<
/measId>
measResultPCell>
rsrpResult>
!
[CDATA[-119.0<
=rsrpResult<
-118.0dBm]]>
/rsrpResult>
rsrqResult>
[CDATA[-18.0<
=rsrqResult<
-17.5dB]]>
/rsrqResult>
/measResultPCell>
measResultNeighCells>
measResultListEUTRA>
element>
254<
measResult>
[CDATA[-102.0<
-101.0dBm]]>
[CDATA[-9.0<
-8.5dB]]>
/measResult>
/element>
/measResultListEUTRA>
/measResultNeighCells>
/measResults>
/measurementReport-r8>
/measurementReport>
/UL-DCCH-Message>
同时，在Measurement图中显示信息如下:
由上图可知，在茅村周宅子_2发生重建的该时间点，邻区中存在RSRP由于PCI=328的小区，且时间轴显示的时间也达到了切换的时间条件；
TA图显示如下：
上图可知，在茅村周宅子_2发生重建的该时间点，用户距离基站位置约1km左右，距离较近，不存在异常弱覆盖等情况。
通过以上信令可知，虽然主服务小区（PCI=328）的RSRP值还处于正常水平，但此时邻区（茅村周宅子_2）的RSRP已高于服务小区约8dBm，服务小区RSRQ已降低到-15左右，信号质量较差。
信令上显示，终端一直上报MR测量，但基站未下发切换命令，终端未执行同频切换，因此判断终端发起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重建作为KPI指标的一部分，RRC重建成功率低会引起掉话，影响用户感知，如果优化合理，可以挽救部分掉话，降低网络掉线率；
如果RRC连接重建失败，UE将进入RRC_IDLE状态，发生掉线，影响用户感知的同时，对网络其他指标也会造成一些不必要的影响。
通常在处理后台KPI的TOP小区的时候，首先要检查一下基站是否存在告警、是否存在干扰、是否为突发状况、是否为成片区域，是否为弱覆盖等较易排查的问题，然后提取相关counter进而进一步发现问题并排查，相关流程图及处理思路见下文中的原理补充。
升级会员 