TOP小区处理RRC重建成功率低优化案例Word格式.docx
- 文档编号:18142946
- 上传时间:2022-12-13
- 格式:DOCX
- 页数:13
- 大小:512.46KB
TOP小区处理RRC重建成功率低优化案例Word格式.docx
《TOP小区处理RRC重建成功率低优化案例Word格式.docx》由会员分享,可在线阅读,更多相关《TOP小区处理RRC重建成功率低优化案例Word格式.docx(13页珍藏版)》请在冰豆网上搜索。
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>
10110
/c-RNTI>
physCellId>
328<
/physCellId>
shortMAC-I>
10111
/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>
1111111010
/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进而进一步发现问题并排查,相关流程图及处理思路见下文中的原理补充。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TOP 小区 处理 RRC 重建 成功率 优化 案例
![提示](https://static.bdocx.com/images/bang_tan.gif)