LTE掉话问题分析及RRC连接重建触发原因

宿迁电信RRC重建比例问题分析
概述：
按重建原因分类：
分析全网RRC重建次数其中由于切换失败导致的重建次数占总次数的%;其他原因触
发的RRC重建次数占总次数的%;切换失败多为PCI冲突、邻区错误、邻区缺失等原因,其他原因触发的重建原因多为弱覆盖、干扰等无线环境等原因;
分区域统计,泗洪RRC重建比例明显高于全网平均值,泗洪站点数为395个占全网总数的%,对RRC重建立尝试次数的贡献达到了%;从结果可以看出泗洪RRC重建立尝试次数明显较多,拉低全网RRC重建比例;
分析泗洪RRC重建立原因,泗洪切换失败触发的RRC重建比例达到%;明显高于其他区域;
UE去激活定时器修改
为改善RRC重建比例指标,3月8日选取现网150个站点,修改UE去激活定时器等参数;通过调整定时器可以将短暂是活动的UE去激活,增加RRC建立和重建立总次数,从而起到降低RRC重建比例的目的;目前五市中徐州已完成修改,修改后RRC重建比例提升40%左右;
150个站点区域分布情况：
通过修改前后RRC连接重建比例指标对比可以看出,参数优化完成后指标改善明显;
全网RRC重建比例
分区域RRC指标变化情况
RRC重建比例
RRC重建立尝试总次数
RRC建立和重建立总次数
参数调整后各个区域RRC重建比例均有降低,RRC重建尝试总次数没在参数修改前后没有明显变化,RRC建立和重建立总次数增加明显;
切换失败核查
目前全网只有泗洪区域RRC重建比例不达标,且切换失败导致的RRC重建立次数最多影响最为严重,分析泗洪区域TOP站点分布情况：
1、泗洪车门、重岗区域。

LTE的掉话原因分析及处理思路LTE“掉话”是指UE异常退出RRC_CONNECTED状态导致的连接中断。

统计节点为“RrcConnctionReconfigurationComplete”消息正确达到网络侧开始，之后进行的各类业务，未正常释放的均计为“掉话”。

正常释放流程如下：一、外场常见掉话原因分析目前LTE常见掉话原因包括弱覆盖、越区覆盖、切换失败、邻区漏配、系统设备异常、干扰、拥塞等。

掉话原因1：弱覆盖现象:由于弱覆盖导致的掉话，通常有以下表现：1.掉话前服务小区的RSRP持续变差（低于弱覆盖标准，如小于-105dBm），同时服务小区的SINR也一起持续变差（小于0dB，甚至小于-3dB）。

2.掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。

解决方案:要解决此类掉话，需要改善覆盖。

具体手段有：1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。

2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区，并加强它的覆盖。

如常用的天馈调整、站点建设等。

具体案例：对呼和浩特市大昭寺前街DT过程中占用到大昭寺华隆小区-FL_3小区，覆盖较差存在掉线风险。

通过调整PA：3→0，RS参考功率：13.4dB→15.2dB，覆盖改善，掉线风险大大降低。

掉话原因2：越区覆盖现象:在支持切换的移动通信网络中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况，导致“孤岛覆盖”无法与周边站点进行正常切换掉话，通常有以下表现：1.越区覆盖导致的“导频污染”。

在覆盖区内，没有稳定的强信号作为主服务小区。

服务小区信号的频繁变化，是导致掉话的一个主要原因。

2.越区覆盖对主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等）。

在某些区域，主服务小区收到越区信号的干扰，最终导致掉话。

解决方案：1.越区覆盖的一般优化原则是：在区域中已有合理的稳定信号覆盖的情况下，尽可能的控制越区覆盖的信号。

RRC多目标重建功能对VOLTE掉话率的影响分析目录第一章问题描述 (1)第二章问题分析 (1)1、Radio link failure流程 (1)2、VOLTE呼叫流程 (2)3、VOLTE掉话原因分析 (4)4、RRC多目标重建原理介绍 (5)第三章解决方案和效果 (7)1、RRC多目标重建验证方案 (7)2、效果验证 (9)第四章经验总结 (11)第一章问题描述针对集团要求的双提升测试，我们对临沂农村区域进行了测试，本次选取费县农村区域进行测试，发现农村区域存在多次RLF(Radio link failure)及VOLTE掉话，同时通过遍历测试发现了农村区域存在大量的弱覆盖区域，对于后期VOLTE语音要求的质量及移动性带来了挑战。

通过对测试数据的分析，发现现场存在较多RLF及RRC reestablishment reject等带来的异常事件及VOLTE掉话，针对RRC重建，本次试验尝试打开爱立信multi-targetre-establishment功能改善重建成功率，从而改善因此带来的VOLTE掉话。

第二章问题分析下文分别介绍无线链路失败（RLF）、RRC connection re-establishment、VOLTE Uu口信令流程等，进一步分析VOLTE掉话的原因，为本次试验做好理论解释。

1、Radio link failure流程LTE规定UE在RRC连接态下建立的内容如下：•SRB，如SRB1、SRB2；•缺省及专用无线承载，如DRB等•Security context•当RLF发生时，RRC协议规定执行如下操作•停止除T320以外的所有定时器•重置所有RB的无线资源•释放MAC、RLC、PDCP、PHY层配置，从而禁用SRB1并释放SRB2和DRB•Security context 仍然被激活同时RLF发生后UE会尝试恢复SRB1、SRB2、DRB和网络侧配置。

RLF一般会在如下条件下触发：RLC重传达到最大次数；T310超时，即指示物理层失步；MAC层指示的随机接入问题。

LTE的掉话原因分析及处理思路LTE“掉话”是指UE异常退出RRC_CONNECTED状态导致的连接中断。

统计节点为“RrcConnctionReconfigurationComplete”消息正确达到网络侧开始，之后进行的各类业务，未正常释放的均计为“掉话”。

正常释放流程如下：一、外场常见掉话原因分析目前LTE常见掉话原因包括弱覆盖、越区覆盖、切换失败、邻区漏配、系统设备异常、干扰、拥塞等。

掉话原因1：弱覆盖现象:由于弱覆盖导致的掉话，通常有以下表现：1.掉话前服务小区的RSRP持续变差（低于弱覆盖标准，如小于-105dBm），同时服务小区的SINR也一起持续变差（小于0dB，甚至小于-3dB）。

2.掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。

解决方案:要解决此类掉话，需要改善覆盖。

具体手段有：1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。

2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区，并加强它的覆盖。

如常用的天馈调整、站点建设等。

具体案例：对呼和浩特市大昭寺前街DT过程中占用到大昭寺华隆小区-FL_3小区，覆盖较差存在掉线风险。

通过调整PA：3→0，RS参考功率：13.4dB→15.2dB，覆盖改善，掉线风险大大降低。

掉话原因2：越区覆盖现象:在支持切换的移动通信网络中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况，导致“孤岛覆盖”无法与周边站点进行正常切换掉话，通常有以下表现：1.越区覆盖导致的“导频污染”。

在覆盖区内，没有稳定的强信号作为主服务小区。

服务小区信号的频繁变化，是导致掉话的一个主要原因。

2.越区覆盖对主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等）。

在某些区域，主服务小区收到越区信号的干扰，最终导致掉话。

解决方案：1.越区覆盖的一般优化原则是：在区域中已有合理的稳定信号覆盖的情况下，尽可能的控制越区覆盖的信号。

LTERRC重建流程详解和优化经验总结LTE RRC连接重建过程详解及优化应⽤当处于RRC连接状态时，如果出现切换失败、⽆线链路失败、完整性保护失败、RRC 重配置失败等情况，将会触发RRC连接重建过程。

该过程旨在重建RRC连接，包括SRB1操作的恢复，以及安全的重新激活。

处于RRC_CONNECTED状态的UE，安全已被激活，可发起该过程继续RRC连接。

仅当相关⼩区是具有UE上下⽂的⼩区时，连接重建才会成功。

假使E-UTRAN认可重建，SRB1的操作会恢复，⽽其它RB将继续保持挂起。

如果AS安全没有被激活，UE不会发起该过程，⽽直接转到RRC_IDLE状态。

总体信令流程图如下：注意：E-UTRAN在如下情况使⽤此过程：- 重配SRB1，且仅为其恢复数据传输；- 重新激活AS安全不改变算法。

⼀、RRC重建流程详解1.RRC重建初始化流程当出现以下任⼀情况是，触发RRC 重建初始化：1）检测到⽆线链路失败；2）切换失败；3）E-UTRA侧移动性失败；4）底层制式完整性校验失败；5）RRC连接重配失败。

在RRC重建初始化阶段，UE会执⾏如下操作：●停⽌定时器 T310，如果正在运⾏；●开始定时器T311；●挂起除SRB0之外的所有RB；●复位MAC；●应⽤缺省的物理信道配置；●应⽤缺省的半持久调度配置；●应⽤缺省的MAC主配置；●释放reportProximityConfig并情况所有邻近状态报告相关的定时器；●进⾏⼩区选择；当选择⼀个合适的 E-UTRA⼩区后，意味着RRC重建初始化完成，此时，UE将执⾏如下操作：●停⽌定时器T311；●开始定时器 T301；●采⽤SystemInformationBlockType2中包含的timeAlignmentTimerCommon。

●初始化RRCConnectionReestablishmentRequest消息的发送；注：该过程同样适⽤于如果UE返回源⼩区的情况注：在定时器T311运⾏过程中，UE选择了⼀个不同RAT的⼩区时，UE 将离开RRC_CONNECTED状态，同时‘RRC连接失败’。

LTE切换失败问答题分析案例分析X2IPPATH配置问题导致切换不成功关键字：X2IPPATH 切换【现象描述】切换测试时，从站点B1的标⼝信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进⼊该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所⽰。

【原因分析】对于切换流程失败⽽⾔，如果是切换准备阶段的失败，其原因通常为以下⼏种：（1）传输资源不够⽤；（2）没有配置IPPATH；（3）IPPATH中的邻居节点配置错误。

由于切换测试阶段的⽹络业务负载很⼩，接⼊⽤户数少，通过X2⼝传输的数据不多，⼀般来说不会出现传输资源不够⽤的情况。

所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2⼝和IPPATH问题排查处理，⼀步步解决问题。

【处理过程】每次切换到⽬标⼩区完成后，UE会读取⽬标⼩区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到⽬标⼩区的CGI，通过CGI中的基站ID确认⽬标基站B2的ID。

从该次切换的切换命令（RRC_CONN_RECFG）可以找到⽬标⼩区CELL2的PCI，在⽬标基站B2中⽤MML命令查询确实存在⼩区CELL2，所以接下来可以针对⽬标基站B2以及源基站B1来检查IPPATH的配置了。

先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接⼝ID与IPPATH的邻接点ID是否⼀致。

在webLMT上的命令如下：LST SCTPLNK；检查SCTPLNK是否建⽴并查看⽬标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。

DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接⼝的标识X2InterfaceId。

LST IPPATH; 根据X2接⼝标识X2InterfaceId，查看X2⼝两端的IP配置是否正确。