语音质量提升专题_RRC重建

1、 内部公开 Internal Use Only语音质量提升专题_RRC重建一、概述VoLTE呼叫中RRC重建和数据业务触发机制以及对RRC层影响完全相同，在LTE常规优化和投诉处理中因为影响较小而经常被忽视。但RTCP协议对底层链路失败引起的re-cover机制支持不好，所以RRC重建过程很容易被用户感知到；另外RRC重建更有可能造成VoLTE掉话和接入失败。所以VoLTE优化和商用保障过程中，需要仔细梳理现网存在RRC重建的原因，并有针对性的采取优化措施。对于数据业务使用来说，短时间的业务中断很难被用户觉察到。因此在业务进行过程中发生的RRC异常释放和切换失败，只要后续RRC重建成功，甚至即

2、使重建不成功，网络侧或者UE侧很快又发起连接建立并成功建立连接，对用户体验基本不会带来影响更不太会引起投诉，RRC异常释放后如果重建成功甚至不会影响KPI指标。但对于实时的会话业务来说，RRC重建明显影响用户感知并引起投诉：Ø RRC重建前后短时的业务中断会被用户立即感受到，表现为听不清、通话吞字、一段时间听不到声音、视频停滞等，Ø LTE中的无线链路失败（RLF）并不会直接导致VoLTE话音呼叫的掉话，但是在有些情况下还是会在RLF之后出现VoLTE掉话。比如重建时如果不能建立UM承载则会掉话，或者重建后应用层不能恢复RTP包也会造成RTP timeout。Ø

3、VoLTE呼叫建立阶段发生RRC重建，可能引起和PRACK的冲突，IMS CORE定时器超时，IMS向主叫终端发480 TEMPORARILY UNAVAILABLE错误码RRC重建对语音质量影响：以下公式为无线链路失败引起RRC重建场景下，RTP包恢复时间T的计算公式：t是RLC完成一个RTP包的传输间隔，取值为100ms。N为RRC重建尝试次数。对于多数运营商来说，底层RTP包恢复时间都在35秒之内，但实际上用户感受到的语音中断期（audio muting）要远远大于这个时间。主要原因就是RTP/RTCP协议最初是基于IETF开发的，并未充分考虑在链路质量不稳定的无线网络承载，对于底层链路

4、失败引起的re-cover机制支持不好。下图显示在RRC层已经恢复后，RTP层乃至应用层数据并不会马上恢复。 VoLTE测试中也经常能够发现，RRC重建前后MOS的两个采样点都非常低，而前一个采样点主要是受到重建前空口RTP丢包的影响，重建后的低MOS采样点则可能是上层协议不能正常生成RTP包引起的。二、RRC重建原因分析当处于RRC连接状态时，如果出现切换失败、无线链路失败、完整性保护失败、RRC重配置失败等情况，将会触发RRC连接重建过程。RRC重建原因主要包括基础网络问题，规划配置类问题；基础网络问题包括弱覆盖、越区覆盖、邻区漏配和干扰引起的质量问题；规划配置类问题，包括PCI冲突以及相

5、邻基站RLC SNSIZE不一致造成的切换失败；以及重载场景SRI和GAP冲突造成的重建。RRC重建过程旨在重建RRC连接，包括SRB1操作的恢复，以及安全的重新激活。处于RRC_CONNECTED状态的UE，安全已被激活，可发起该过程继续RRC连接。仅当相关小区是具有UE上下文的小区时，连接重建才会成功。假使E-UTRAN认可重建，SRB1的操作会恢复，而其它RB将继续保持挂起。如果AS安全没有被激活，UE不会发起该过程，而直接转到RRC_IDLE状态。总体信令流程图如下：三、RRC重建被拒原因（描述RRC重建成功和被拒理论原因）失步、完整性校验失败、达到最大重传次数等都会导致无线资源的重建

6、。重建要成功，首先要确定重选的小区是否存有已经挂起的无线承载资源信息。如果是切换失败导致的重建，且重建场景发生在target cell，则重建是否会被eNB接受需要看target cell中是否有该UE的上下文（即如果是inter-ENB切换，是否有X2口用来传递UE的上下文），如果target cell没有该UE context，重建会被eNB拒绝，然后UE需要再发起TAU Request流程。RRC重建被拒主要有等待RRC连接重建立完成定时器超时、eNB接纳失败、UE上下文找不到、再次重建立、其他原因等，short MAC-I较验失败也会被拒绝；四、RRC重建处理思路（处理流程图）针对RR

7、C重建失败，首先需要检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。整个切换过程异常情况我们分为几个阶段：测量报告发送后是否收到切换命令，收到重配命令后是否成功在目标测发送MSG1成功发送MSG1之后是否正常收到MSG2在某一环节出现问题我们可查询相应处理流程进行排查。由于终端未收到切换命令，可能有两种情况：1、基站未收到测量报告（可通过后台信令跟踪检查）：检查覆盖点是否合理，主要是检查测量报告点的RSRP,SINR等覆盖情况，确认终端是否在小区边缘，或存在上行功率受限情况（根据下行终端估计的路损判断）。如果是该情况，按照现场情况调整覆盖，及切换参数，解决异常情况；2、基站收到

8、了测量报告：2.1基站未向终端发送切换命令情况：（1）确认目标小区是否为漏配邻区（2）需要检查是否目标小区未向源小区发送切换响应，或者发送HANDOVER PREPARATION FAILUE信令，在这种情况下源小区也不会向终端发送切换命令。2.2基站向终端发送切换命令情况：主要检查测量报告上报点的覆盖情况，是否为弱场，或强干扰区域，优先建议通过工程参数解决覆盖问题，若覆盖不易调整则通过调整切换参数优化，具体分析流程图如下：五、RRC重建处理实例（处理前后对比图，发生重建原因详细分析）5.1、蒙自市金色碧海南门-LZHQ与蒙自市南湖花园商业区-LZHQ附近路段RRC重建失败导致掉话10:38:

9、09.865（越区覆盖）【问题描述】：UE在蒙自市金色碧海南门-LZHQ与蒙自市南湖花园商业区-LZHQ附近路段掉话（经度：103.357574 /纬度：23.388983）示意图如下所示：【问题分析】：主叫UE在10:35:56.931发起invite；被叫UE在10:35:57.529响应invite，后主被叫承载建立，通话建立；但主叫在10：38:09.485RRC重建失败，而后在主叫10：38:09.725随机接入蒙自市十里铺-LZHQVB-YZ-003-PCI-233小区成功，但在此小区QCI1承载未建立，导致掉话；在此过程中主被叫UE主要占用越区至该路段的蒙自市江川农家乐-LZHQ

10、B-XX-001-PCI-35小区信号，RSRP在-104dBm左右，SINR在-4.1dB左右；【优化方案】：1、建议将蒙自市南湖花园商业区-LZHQB-ZD-002小区下倾角由3度调整为0度，方位角由140度调整为120度；将蒙自市十里铺-LZHQVB-YZ-003小区方位角由260调整为220度，下倾角由6度调整为4度；2、蒙自市金色碧海二期-LZHQB-ZB-002小区下倾角由8度调整为10度，将其功率由12.2调整为9.2；3、蒙自市南湖花园商业区-LZHQB-ZD-002与蒙自市江川农家乐-LZHQB-XX-001小区间CIO由0调整为-5，减慢切换；蒙自市南湖花园商业区-LZHQ

11、B-ZD-002、蒙自市江川农家乐-LZHQB-XX-001小区与蒙自市十里铺-LZHQVB-YZ-003小区间CIO由0调整为3，加快切换；【优化效果】：【遗留问题】：5.2、蒙自市紫金花园-LZHQ附近RRC重建失败导致掉话10:35:42.090（邻区漏配）【问题描述】：UE在红河大道蒙自市紫金花园-LZHQ附近掉话（经度：103.369209 /纬度：23.363779）示意图如下所示：【问题分析】：主叫UE在10:33:30.036发起ACK；被叫UE在10:33:30.112响应ACK，通话建立，后被叫在问题路段占用蒙自市君达酒店-LZHQB-XU-001PCI162小区信号，RS

12、RP在-90dBm左右，SINR在4.4dB左右，终端一直上报测量报告，但是一直未收到切换命令，与邻区蒙自市紫金花园-LZHQB-ZD-001PCI211小区不切换，导致掉线，至使RRC重建失败产生掉话。【优化方案】：1、核查蒙自市君达酒店-LZHQB-XU-001PC162与蒙自市紫金花园-LZHQB-ZD-001PCI211邻区关系及参数设置。2、下压蒙自市君达酒店-LZHQB-XU-001PCI162小区机械下倾角至10度左右，控制其覆盖。【优化效果】：【遗留问题】：5.3、蒙自市州政府路灯-LZHQ与蒙自市州政府-LZHQ站点之间路段RRC重建失败导致掉话10:57:56.587（模三

13、干扰）【问题描述】：UE在蒙自市州政府路灯-LZHQ与蒙自市州政府-LZHQ站点之间路段掉话（经度：103.3730284 /纬度：23.3636158）示意图如下所示：【问题分析】：主叫UE在10:57:14.402发起ACK；被叫UE在10:57:14.606响应ACK，通话建立，后主叫在问题路段占用蒙自市君达酒店-LZHQB-XU-001PCI162小区信号，RSRP在-95dBm左右，SINR在-16dB左右，在此路段与蒙自市州政府路灯-LZHQB-ZD-001PCI384模三干扰严重，导致RRC重建失败，产生掉话。【优化方案】：1、重新规划蒙自市州政府路灯-LZHQ站点小区PCI（2

14、-385改为2-386）。2、下压蒙自市君达酒店-LZHQB-XU-001PCI162机械下倾角至10度左右，或功率降3dB左右控制其覆盖。【优化效果】：【遗留问题】：六、X2（现网X2开启比例分析，X2未开启原因分析，X2开启比例提升）目前红河主要通过SON开启X2自优化进行全网X2链路添加，提取X2自优化监控日志发现红河所有站点X2自优化均已开启；但统计全网X2切换比例发现，红河存在462个小区X2切换比例低于50%，657个小区X2切换比例在50%至70%，2099个小区X2切换比例在70%至90%，具体如下：针对X2切换比例较低小区，红河通过优化X2链路，提高全网X2切换比例；红河选取

15、以下站点为试点进行X2链路优化：子网名称网元网元名称X2自优化开启情况X2链路优化时间红河(26)37517石屏县龙朋甸中-LZHN开启5月26日红河(26)577129石屏县哨冲-LZHZ开启5月25日红河(27)570376个旧市大修厂-LZHX开启5月26日红河(27)570377个旧市灯泡厂-LZHX开启5月26日红河(27)570717个旧市疾控中心-LZHX开启5月26日X2链路优化后对比前后指标发现：X2切换次数较优化前大幅提升，RRC重建失败次数减少，具体如下：七、无线参数核查邻区关系不合理、PCI冲突等无线参数是导致RRC重建失败的主要因素，邻区及PCI合理性核查对减少全网R

16、RC重建比例，提高VOLTE语音通话质量具有重要意义；针对邻区关系合理性，通过健康卫士进行核查，主要核查超远邻区、近距漏配、单向邻区以及邻区同频同PCI，超远邻区及近距漏配定义如下：超远邻区：城区邻区距离大于3km、农村邻区距离大于5km；近距漏配：城区邻区距离小于300m、农村邻区距离小于500m；邻区核查不合理邻区超远邻区单向邻区漏配邻区邻区条数250854736411为减少PCI冲突对全网PCI进行核查，PCI复用距离为3km，即3km内不允许出现同频同PCI（考虑后续开启FD站点较多，建议F频段站点扩容D频段站点，D频段站点复用F频段站点PCI）；对同站同MOD3进行核查，在PCI规划时确保第一小区模0、第一小区模1、第一小区模2；在网格拉网测试中出现的模三干扰进行PCI优化，避免出现因模三干扰导致RRC重建；PCI核查类型同站同模三近距同频同PCI二阶邻区同PCI异常数量135991八、专题优化总结自百日大会战以来红河蒙自网格VOLTE拉网测试多次出现因RRC重建失败导致掉话问题，致使蒙自网格掉话率居高不下，经过对RRC重建的专题优化分析处理，目前红河蒙自VOLTE整体掉话率较低，具体如下：VoLTE呼叫中RRC重建和数据业务触发机制以及对RRC层影响完全相同