目录
1 概述
2 RRC重建定义与触发条件
2.1 RRC重建的定义
2.2 RRC重建的原因
2.2.1 终端发起重建的原因
2.2.2 reconfigurationfailure
2.2.3 handoverfailure
2.2.4 radiolink failure ( OtherFailure )
3 RRC连接重建流程
4 RRC连接重建问题定位及处理
4.1 故障告警
4.2 邻区漏配
4.3 干扰检查
4.4 覆盖问题
4.5 参数核查
4.6 相关问题信息反馈到研发
5 RRC连接重建TOP小区及相关案例
5.1 RRC连接重建问题TOP小区
5.2 案例呈现
案例 1- 重叠覆盖导致 RRC 连接重建比率高
案例 2- 切换参数设置不合理导致 RRC 连接频繁重建立
案例 3- 越区覆盖导致 RRC 连接重建失败
1 概述
RRC 重建目的是恢复RRC信令连接,减少掉线。 但是RRC在源小区重建过多会影响小区吞吐量和用户感知。 本文介绍了RRC重建定义,触发条件和RRC在源小区重建过多,RRC重建成功率低、、问题小区的处理
当处于RRC连接状态时,如果出现切换失败、无线链路失败、完整性保护失败、RRC重配置失败、情况,将会触发RRC连接重建过程。 该过程旨在重建RRC连接,包括SRB1操作的恢复,以及安全的重新激活。 处于RRC_CONNECTED状态的UE,安全已被激活,可以发起该过程继续RRC连接。 仅当相关小区是具有UE上下文的小区时,连接重建才会成功。 假如E-UTRAN认可重建,SRB1的操作会恢复,而其它RB将继续保持挂起。 如果AS安全没有被激活,UE不会发起该过程,而直接转到RRC_IDLE状态
RRC 连接重建比率 =RRC 重建请求次数/(小区接收UE的RRC Connection Request消息次数(包括重发)+RRC重建请求次数)*100%
RRC 重建成功率= 小区RRC重建成功次数/小区RRC重建请求次数
RRC 测量统计项如下:
RRC 重建测量统计项 |
RRC 重建成功次数 |
RRC 重建请求次数 |
|
非源侧小区RRC重建成功次数 |
|
非源小区RRC重建请求次数 |
|
切换失败触发RRC重建成功的次数 |
|
切换失败触发RRC重建请求的次数 |
|
重配置失败触发RRC重建成功的次数 |
|
重配置失败触发RRC重建请求的次数 |
RRC 重建失败测量统计项 |
RRC 重建拒绝次数 |
UE 无应答而导致RRC重建失败次数 |
|
切换失败触发RRC重建拒绝的次数 |
|
小区内因为无上下文导致的RRC重建拒绝的次数 |
|
预处理失败的无UE上下文导致RRC重建失败次数 |
|
重配置失败触发RRC重建拒绝的次数 |
|
资源分配失败而导致RRC重建失败次数 |
在36.331协议中,发起重建的条件描述如下:
The UE shall only initiate the procedure when AS security has beenactivated. The UE initiates the procedure when one of the following conditionsis met:
upon detecting radio link failure, in accordance with 5.3.11; or
upon handover failure, in accordance with 5.3.5.6; or
upon mobility from E-UTRA failure, in accordance with 5.4.3.5; or
upon integrity check failure indication from lower layers; or
upon an RRC connection reconfiguration failure, in accordance with5.3.5.5;
概括的说,UE发起重建的原因有3种:reconfiguration failure、handover failure、radio link failure、
协议原文如下:
if the UE is unable tocomply with (part of) the configuration included in theRRCConnectionReconfiguration message:
continue using theconfiguration used prior to the reception of RRCConnectionReconfigurationmessage;
if security has not beenactivated:
perform the actions uponleaving RRC_CONNECTED as specified in 5.3.12, with release cause other;
else:
initiate the connectionre-establishment procedure as specified in 5.3.7, upon which the connectionreconfiguration procedure ends;
既UE在安全模式激活的状态下,如果收到了重配置消息后对于重配置消息内的信元无法匹配/兼容,则发起原因值为“reconfiguration failure”的重建
if T304 expires (handover failure):
NOTE: Following T304 expiry any dedicated preamble, if provided within therach-ConfigDedicated, is not available for use by the UE anymore.
既UE在切换流程中,在收到了切换的重配置消息之后,会启动T304,但如果在T304超时之前UE无法完成在目标小区的随机接入,则会发起原因值为“handover failure”的重建
如果UE检测到当前检测到“radio link failure”,则会发起原因值为“other”的重建,通常引起RLF存在如下三种机制:
上行RLC重传达到最大次数
“indication from RLCthat the maximum number of retransmissions has been reached”,包括SRB和DRB,与eNB侧下行的SRB与DRB机制相同,当UE RLC发送了一个PDU之后,需要、、到eNB侧反馈对应的状态PDU才能完成一次RLC的正常调度。 对于没有收到eNB状态PDU的原因有两个,一个原因为eNB侧上行根本就没有收到任何RLC PDU,也就不会响应状态PDU,另一个原因为eNB响应的状态PDU,由于下行误码的原因,没有到达UE侧
Preamble 达到最大发送次数
在切换过程中,切换完成命令丢失后导致的PUCCH没激活,或者,在业务保持过程中由于Ta超时导致的PUCCH没激活,此时如果UE有SR发送,因为下行链路问题,UE无法收到ENB的MAC层确认,SR重传达到最大次数(physicalconfigDedicatedschedulingRequestConfig dsr-TransMax,华为基线配置为64次)后触发MAC_RA_IND(基于竞争的随机接入),在随机接入因为Preamble发送达到最大次数(preambleTransMax,华为基线为10次)后上报RLF指示给L3后发起重建请求。 时延谱首径搜索失败(UE检测到下行RLF)
UE DSP 每200ms对时延谱滤波值进行判断,如果满足某门限,则上报L3失步、同时,启动T310定时器,在T310超时前,若收到N311次in-sync指示(2.1基线值为5次,N311=n5),则认为UE恢复同步状态(100ms + 10*(N311 -1 ) =140ms,既在启动T310后,终端在100ms时测量上报判断满足们先后记录N311+1,然后每10ms测量上报一次),否则,T310超时后(2.1基线值为200ms,对应MML参数配置为T310=MS200_T310)UE会触发重建流程(包括搜索小区、L3在同步状态连续收到N310个L1上报的out-of-sync指示(2.1版本基线值为6次,N310=n6),则认为失步(触发需要时长预计为:200ms + 10 * (N310-1) =250ms,既200ms测量上报判断满足们先后记录N310+1,然后每10ms测量上报一次)、同步、重建),同时启动T311定时器(2.1基线值为10s,对应MML参数配置为T311=MS10000_T311),若超时仍未重建成功,则进入IDLE态
成功的重建流程
失败的重建流程
UE 发送RRC Connection Reestablishment Request消息。 根据不同的场景,消息中携带的重建原因与小区信息不同
· 重配置失败触发的重建原因为“reconfigurationFailure”,其中的C-RNTI和physCellId为本小区信息
· 切换失败触发的重建原因为“handoverFailure”,其中的C-RNTI和physCellId为源小区的信息
· 无线链路失败触发的重建原因为“otherFailure”,其中的C-RNTI和physCellId为本小区信息
eNodeB 进行安全参数认证,如果UE的安全参数认证信息与eNodeB的一致,则UE认证通过。 UE身份认证后,eNodeB将原资源释放,重新进行准入和资源分配
eNodeB 在CCCH信道上向UE发送RRC Connection Reestablishment消息,消息中携带新分配资源的信息。 UE收到RRC Connection Reestablishment消息,根据消息指示重新配置无线资源,激活加密和完整性保护
UE 发送RRC Connection Reestablishment Complete消息给eNodeB
RRC 重建问题定位流程图:
告警可通过在U2000侧进行观察,对于每个告警,都有相关的处理建议,可通过U2000的在线帮助进行阅读。 如下图所示:
也可通过MML命令查询告警: LST ALMAF(查询当前告警), LST ALMLOG(查询告警日志)
若出现以下告警,需要排除告警后,再进行后继优化分析:
网元级别 |
告警、、级 |
告警号 |
告警名称 |
ENODEB |
重要 |
26538 |
射频单元时钟异常告警 |
重要 |
29243 |
小区服务能力下降告警 |
|
重要 |
26529 |
射频单元驻波告警 |
|
重要 |
26540 |
射频单元交流掉电告警 |
|
重要 |
26235 |
射频单元维护链路异常告警 |
|
重要 |
26322 |
BBU IR 光模块收发异常告警 |
|
重要 |
29248 |
射频单元业务不可用告警 |
|
重要 |
26260 |
系统时钟不可用告警 |
|
重要 |
26508 |
射频单元IR接口异常告警 |
|
重要 |
26506 |
射频单元光接口性能恶化告警 |
|
重要 |
29205 |
X2 接口配置更新失败告警 |
|
重要 |
26324 |
BBU IR 接口异常告警 |
|
重要 |
29207 |
基站控制面传输中断告警 |
|
重要 |
26503 |
射频单元光模块收发异常告警 |
|
重要 |
26242 |
配置文件损坏告警 |
|
重要 |
26222 |
传输光接口异常告警 |
|
重要 |
26245 |
配置数据不一致告警 |
终端重建到其它站点,如果要重建成功,对重建前后两个站有如下要求
两个站点之间存在X2链路并且是Huawei基站
重建前后的两个小区存在双向的邻区关系
邻区漏配会造成目标小区无UE上下文,UE在目标小区发起RRC连接重建,重建必然被拒绝,导致RRC重建失败
邻小区漏配需要结合工参、电子地图、信息进行优化,添加必要的邻区。 对错配的邻区需进行外部小区核查,需提取外部小区数据与现网小区数据进行对比核查
通常干扰分为上行干扰及下行干扰,系统内干扰及外来干扰。 干扰容易导致无线链路失败RLF,当上行RLC达到最大次数后将触发本小区RRC连接重建立,原因为other failure
外部干扰一般指当前网络制式之外的干扰源引起的干扰。 外部干扰源由于非法或不当使用引起对TD-LTE频段的干扰。 集中体现为同频干扰。 常见的外部干扰包括:军区的通信系统、银行ATM机内警用信号干扰装置、学校及社会考点的信号屏蔽装置、,可通过扫频进行排查
LTE 网内干扰,由于LTE采取的同频组网,因此必然会存在同频干扰,PCI规划不合理还容易导致MOD3干扰
通常,对于下行,当服务小区的RSRP高于-90dBm,但是SINR低于-6dbm,基本上可以认为是下行干扰的问题(当邻小区错/漏配或切换不及时的时候,也可能出现服务小区RSRP信号很好,但SINR很差的情况)、、下行的干扰通常是指导频污染,指覆盖地区存在3个以上的小区满足切换条件,由于信号的波动常常出现频繁小区重选者乒乓切换,可能会导致RRC重建
上行干扰可通过查询PRB干扰噪声统计,系统上行每个PRB上检测到的干扰噪声的平均值 (毫瓦分贝)>-110,判断为有上行干扰,具体如图:
通常在没有干扰的情况下,上下行是平衡的,而当下行存在干扰时,会体现在下行受限,上行不受限、、而存在上行干扰时,则是上行受限但下行不受限