经典案例_通过uu口和X2信令跟踪分析处理RRC重建问题

经典案例_通过uu口和X2信令跟踪分析处理RRC重建问题
经典案例_通过uu口和X2信令跟踪分析处理RRC重建问题

通过uu口和X2信令跟踪处理RRC重建

问题

目录

通过uu口和X2口信令跟踪处理RRC重建问题 (3)

一、概述 (3)

1.1切换失败类重建 (3)

1.2重配置失败类重建 (4)

1.3其他类重建 (4)

二、优化流程 (5)

三、分析方法 (6)

3.1重建测量相关指标 (6)

3.2UU信令分析方法 (7)

3.3X2信令分析方法 (9)

四、优化案例 (10)

4.1越区覆盖导致的重建处理 (10)

4.2PCI混淆导致的重建处理 (12)

五、经验总结 (14)

通过uu口和X2口信令跟踪处理RRC重建问题

【摘要】RRC连接重建过程:无线资源控制(Radio Resource Control, RRC)连接重建过程是用户发起的RRC资源恢复过程,该过程对维持无线链路的可靠性,保证服务的连续性有着重要作用。很多因素都会导致RRC重建,有无线信号的因素、网络的因素、终端兼容性的因素甚至是终端本身BUG的因素,定位起来一直比较困难。本文主要针对RRC重建比例指标进行分析,从引起重建原因分类,到结合uu口和X2口信令跟踪进行细致分析,为后续优化提供一定参考。

【关键字】RRC连接重建比例、UU、X2信令跟踪

【业务类别】基础维护、参数优化

一、概述

RRC重建立比例公式定义如下:

RRC连接重建比例= RRC连接重建请求次数/RRC连接建立成功次数*100;

从计算公式来看,如果要降低RRC重建比例,最好的办法就是降低RRC连接重建请求次数,重建流程如下图所示。

RRC重建请求消息带的重建原因值有以下三个:handover failure(切换失败类)、reconfiguration failure(重配置失败类)、other failure(其他类)。

1.1切换失败类重建

UE在切换流程中,在收到了切换的重配置消息之后,会启动T304,但如果在T304超时之前UE无法完成在目标小区的随机接入,则会发起原因值为“handover failure”的重建。

1.2重配置失败类重建

UE在安全模式激活的状态下,如果收到了重配置消息后对于重配置消息内的信元无法匹配/兼容,则发起原因值为“reconfiguration failure”的重建。

1.3其他类重建

除切换失败和重配失败触发的重建,重建原因都是other。other重建常见原因为RLF(Radio Link Failure, RLF),如果UE检测到当前检测到RLF,则会发起原因值为“other”的重建,通常RLF导致的RRC重建,协议中又分为如下几种场景:

场景1:当终端底层上报了N310次连续的失步指示,终端启动T310,在T310超时前未能收到N311次连续的同步指示,则在T310超时后,终端发起RRC重建过程。

场景2:当随机接入过程出现问题。

场景3:当RLC层达到最大重传次数。

二、优化流程

目前现网重建原因主要为切换失败类以及Other类。

切换失败类导致重建主要原因为:弱覆盖切换失败触发重建;邻区漏配、错配切换失败触发重建;切换过早、过晚切换失败触发重建。

Other类导致重建主要原因为:上行信号质量差,导致eNB未解析到包,UE不断重传导致重传到最大;下行信号质量差,导致UE未收到eNB的确认包,然后不断重传到最大。

三、分析方法

3.1重建测量相关指标

3.2UU信令分析方法

终端在发起RRC重建时,根据不同场景填写不同原因值(和前面的重建场景有对应关系):如果是收到重配置消息并且无法按网络侧消息进行重配,则原因值为“reconfigurationFailure”,如果是由于切换失败导致RRC重建,如果终端收到了切换命令,但是在目标小区还没有收到RAR,则RRC重建的原因值为“handoverFailure”,其它场景RRC 重建的原因值统一为“otherFailure”。

UE发起重建请求时会携带重建源小区PCI,CRNTI,和重建原因值(包括三类:重配置失败,切换失败,Other失败)

R9终端保存了重建前的RLF相关信息,重建完成时,基站根据重配完成消息中的rlf-InfoAvailable指示,请求UE上报RLF Report。UE上报的RLF Report信息中包含重建前的服务小区、邻区相关信息。

重建失败UU信令如下所示:

3.3X2信令分析方法

UE在非源小区重建,如果收到重建请求的小区配置了源小区为邻区,且和源小区所在站点存在X2链路,会通过X2向原来的服务小区发送HUAWEI_PRIVATE_MSG消息请求UE上下文,HUAWEI_PRIVATE_MSG消息中含有源小区的PCI、重建前的CRNTI,收到重建的目的小区CellId,其中CellId前20bit为eNodeBId,20~28bit为CellId。具体如下图所示:

正常请求到UE上下文的信令如下,源小区通过HANDOVER_REQUEST把UE上下文发送给重建的目的小区。

如果重建目的小区请求不到源小区的UE上下文,此时重建目的小区也会向源小区回复一条HUAWEI_PRIVATE_MSG消息,HUAWEI_PRIVATE_MSG消息携带的reestWithoutUecntRsp 标识为failure。

综合来说,在本小区发起重建时,会向对端小区请求UE上下文,如果对端小区响应失败,则通过分析响应HUAWEI_PRIVATE_MSG消息的小区,并结合邻区配置信息,可快速识

别邻区漏配问题。响应失败原因通常为对端小区未配置本小区为邻区,即在源小区根据CRNTI找不到UE上下文。

统计本小区发送出去的HUAWEI_PRIVATE_MSG响应,结合本小区的邻区配置,可定位是否把对端配置为邻区。

四、优化案例

4.1越区覆盖导致的重建处理

4.1.1问题描述

FY-太和-老陈寨-HFTA-436792-53,eNodeB=436792 CellId=53小区接收到重建请求,PCI 为299,重建原因为handoverfailure。

4.1.2问题分析以及处理结果

查看外部小区配置,只有一个邻区的PCI=299,eNodeBId=436755 CellId=52。

通过X2信令确认,PCI 299小区属于436755站点。eNodeB=436792 CellId=53小区向eNodeBId=436755 CellId=52请求切换过程中失败,初步怀疑eNodeB=436792 CellId=53小区未把eNodeBId=436755 CellId=52小区配置为邻区。

查看eNodeBId=436755的外部小区配置,eNodeB=436792 CellId=53 PCI=189的外部小区

有1个。查看eNodeBId=436755 CellId=52的邻区,没有一个PCI=189,eNodeB=436792的邻区,同理查询eNodeB=436792 CellId=53小区的邻区配置信息,未发现eNodeBId=436755 PCI=299的邻区,确认为邻区漏配。

检查436755与436792之间的站间距,距离4.7KM,且越区覆盖严重。如下图,通过优化邻区关系和小区覆盖控制处理后,436792_53小区重建请求次数明显下降。

4.2PCI混淆导致的重建处理

4.2.1问题描述

FY-市区-金牛药械十四中-HFUA-436456-51,eNodeB=436456 CellId=51小区接收到重建请求,PCI为216,重建原因为handoverfailure。

4.2.2问题分析以及处理结果

查看外部小区配置,只有一个外部邻区的PCI=216,该邻区的NodeBId= 436177 CellId=53。

通过X2信令确认,PCI为216的小区属于436177站点。eNodeB=436456 CellId=51小区向eNodeBId=436177 CellId=53请求UE上下文失败,初步怀疑eNodeBId=436177 CellId=53小区未把eNodeB=436456 CellId=51小区配置为邻区。

查看eNodeBId=436177的外部小区配置,PCI等于88的外部小区有2个:436347_51和436456_51。查看436177_53的邻区配置,436347_51和436456_51为该小区邻区。

根据PCI距离核查结果可知,两个站点的站间距为2895m。

检查436177信令中UE上报的MR,MR携带PCI为88,向436347_51小区发起了切换,X2未收到目的侧切换完成后发送的UE上下文释放消息,切换失败,原因为PCI混淆,切换到了错误的小区。

通过合理调整436347站点的PCI值,436792_53小区重建请求次数明显下降,具体如下。

五、经验总结

在LTE网络中针对RRC重建比例进行优化时,需要重点注意以下三个方面:一方面是覆盖,一定要控制好覆盖,避免越区现象的发生;另一方面是邻区,避免邻区漏配或错配;最后需要注意的是PCI的使用,尽量避免模三干扰和PCI复用距离不足导致混淆以及冲突的发生。做好以上三个方面并结合着uu口信令跟踪和X2信令跟踪分析,对避免RRC重建立的发生和处理具有很重要的影响。

相关主题
相关文档
最新文档