TOP小区处理RRC重建成功率低优化案例.docx
《TOP小区处理RRC重建成功率低优化案例.docx》由会员分享,可在线阅读,更多相关《TOP小区处理RRC重建成功率低优化案例.docx(13页珍藏版)》请在冰豆网上搜索。
TOP小区处理RRC重建成功率低优化案例
RRC重建成功率低优化案例
摘要
RRC重建流程图
RRC重建成功流程图:
RRC重建失败流程图:
(1)协议3GPP36.331定义触发重建原因包括如下几类
1>upondetectingradiolinkfailure,
2>uponhandoverfailure,
3>uponmobilityfromE-UTRAfailure,
4>uponintegritycheckfailureindicationfromlowerlayers;
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:
10110
328
10111
00
附件是完整信令:
由以上信令可知,该信息包含的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如下:
00000001
1111111010
0
RRCConnectionRequest信令见附件:
其中,在该条信令的L3Message显示如下:
可见,在该小区上产生了一系列测量报告;
Diagram图显示如下:
其中L3Messagedetails信息显示如下:
2
[CDATA[-119.0<=rsrpResult<-118.0dBm]]>
[CDATA[-18.0<=rsrqResult<-17.5dB]]>
254
[CDATA[-102.0<=rsrpResult<-101.0dBm]]>
[CDATA[-9.0<=rsrqResult<-8.5dB]]>
同时,在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进而进一步发现问题并排查,相关流程图及处理思路见下文中的原理补充。