经典案例_通过uu口和X2信令跟踪分析处理RRC重建问题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
通过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的外部小区