语音质量提升专题_RRC重建

语音质量提升专题_RRC重建

一、概述

VoLTE呼叫中RRC重建和数据业务触发机制以及对RRC层影响完全相同，在LTE常规优化和投诉处理中因为影响较小而经常被忽视。但RTCP协议对底层链路失败引起的re-cover机制支持不好，所以RRC重建过程很容易被用户感知到；另外RRC重建更有可能造成VoLTE掉话和接入失败。所以VoLTE优化和商用保障过程中，需要仔细梳理现网存在RRC重建的原因，并有针对性的采取优化措施。

对于数据业务使用来说，短时间的业务中断很难被用户觉察到。因此在业务进行过程中发生的RRC异常释放和切换失败，只要后续RRC重建成功，甚至即使重建不成功，网络侧或者UE侧很快又发起连接建立并成功建立连接，对用户体验基本不会带来影响更不太会引起投诉，RRC异常释放后如果重建成功甚至不会影响KPI指标。

但对于实时的会话业务来说，RRC重建明显影响用户感知并引起投诉：

➢RRC重建前后短时的业务中断会被用户立即感受到，表现为听不清、通话吞字、一段时间听不到声音、视频停滞等，

➢LTE中的无线链路失败（RLF）并不会直接导致VoLTE话音呼叫的掉话，但是在有些情况下还是会在RLF之后出现VoLTE掉话。比如重建时如果不能建立UM承载

则会掉话，或者重建后应用层不能恢复RTP包也会造成RTP timeout。

➢VoLTE呼叫建立阶段发生RRC重建，可能引起和PRACK的冲突，IMS CORE定时器超时，IMS向主叫终端发480 TEMPORARILY UNAVAILABLE错误码RRC重建对语音质量影响：

以下公式为无线链路失败引起RRC重建场景下，RTP包恢复时间T的计算公式：

t是RLC完成一个RTP包的传输间隔，取值为100ms。N为RRC重建尝试次数。

对于多数运营商来说，底层RTP包恢复时间都在3~5秒之内，但实际上用户感受到的语音中断期（audio muting）要远远大于这个时间。主要原因就是RTP/RTCP协议最初是基于IETF开发的，并未充分考虑在链路质量不稳定的无线网络承载，对于底层链路失败引起的re-cover机制支持不好。下图显示在RRC层已经恢复后，RTP层乃至应用层数据并不会马上恢复。

VoLTE测试中也经常能够发现，RRC重建前后MOS的两个采样点都非常低，而前一个采样点主要是受到重建前空口RTP丢包的影响，重建后的低MOS采样点则可能是上层协议不能正常生成RTP包引起的。

二、RRC重建原因分析

当处于RRC连接状态时，如果出现切换失败、无线链路失败、完整性保护失败、RRC 重配置失败等情况，将会触发RRC连接重建过程。

RRC重建原因主要包括基础网络问题，规划配置类问题；基础网络问题包括弱覆盖、越区覆盖、邻区漏配和干扰引起的质量问题；规划配置类问题，包括PCI冲突以及相邻基站RLC SNSIZE不一致造成的切换失败；以及重载场景SRI和GAP冲突造成的重建。

RRC重建过程旨在重建RRC连接，包括SRB1操作的恢复，以及安全的重新激活。处于RRC_CONNECTED状态的UE，安全已被激活，可发起该过程继续RRC连接。仅当相关小区是具有UE上下文的小区时，连接重建才会成功。假使E-UTRAN认可重建，SRB1的操作会恢复，而其它RB将继续保持挂起。如果AS安全没有被激活，UE不会发起该过程，而直接转到RRC_IDLE状态。总体信令流程图如下：

三、RRC重建被拒原因（描述RRC重建成功和被拒理论原因）

失步、完整性校验失败、达到最大重传次数等都会导致无线资源的重建。重建要成功，首先要确定重选的小区是否存有已经挂起的无线承载资源信息。

如果是切换失败导致的重建，且重建场景发生在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重建处理思路（处理流程图）

针对RRC重建失败，首先需要检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。

整个切换过程异常情况我们分为几个阶段：测量报告发送后是否收到切换命令，收到重配命令后是否成功在目标测发送MSG1成功发送MSG1之后是否正常收到MSG2在某一环节出现问题我们可查询相应处理流程进行排查。

由于终端未收到切换命令，可能有两种情况：

1、基站未收到测量报告（可通过后台信令跟踪检查）：

检查覆盖点是否合理，主要是检查测量报告点的RSRP,SINR等覆盖情况，确认终端是否在小区边缘，或存在上行功率受限情况（根据下行终端估计的路损判断）。如果是该情况，按照现场情况调整覆盖，及切换参数，解决异常情况；

2、基站收到了测量报告：

2.1基站未向终端发送切换命令情况：

（1）确认目标小区是否为漏配邻区

（2）需要检查是否目标小区未向源小区发送切换响应，或者发送HANDOVER PREPARATION FAILUE信令，在这种情况下源小区也不会向终端发送切换命令。

2.2基站向终端发送切换命令情况：

主要检查测量报告上报点的覆盖情况，是否为弱场，或强干扰区域，优先建议通过工程参数解决覆盖问题，若覆盖不易调整则通过调整切换参数优化，具体分析流程图如下：

五、RRC重建处理实例（处理前后对比图，发生重建原因详细分析）

5.1、蒙自市金色碧海南门-LZHQ与蒙自市南湖花园商业区-LZHQ附近路段RRC重建失败导致掉话10:38: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主要占用越区至该路段的蒙自市江川农家乐-LZHQB-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，减慢切换；蒙自市南湖花园商业区-LZHQB-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小区信号，RSRP在-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:5

6.587（模三干扰）

【问题描述】：

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-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切换比例；红河选取以下站点为试点进行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重建失败次数减少，具体如下：

<以上所有信息均为中兴通讯股份有限公司所有，不得外传>

All Rights reserved, No Spreading abroad without Permission of ZTE

第11页

七、无线参数核查

邻区关系不合理、PCI 冲突等无线参数是导致RRC 重建失败的主要因素，邻区及PCI 合理性核查对减少全网RRC 重建比例，提高VOLTE 语音通话质量具有重要意义；

针对邻区关系合理性，通过健康卫士进行核查，主要核查超远邻区、近距漏配、单向邻区以及邻区同频同PCI ，超远邻区及近距漏配定义如下：

超远邻区：城区邻区距离大于3km 、农村邻区距离大于5km ；

近距漏配：城区邻区距离小于300m 、农村邻区距离小于500m ；

邻区核查

不合理邻区 超远邻区 单向邻区 漏配邻区 邻区条数 2508 54 736 411

为减少PCI 冲突对全网PCI 进行核查，PCI 复用距离为3km ，即3km 内不允许出现同频同PCI （考虑后续开启FD 站点较多，建议F 频段站点扩容D 频段站点，D 频段站点复用F 频段站点PCI ）；对同站同MOD3进行核查，在PCI 规划时确保第一小区模0、第一小区模1、第一小区模2；在网格拉网测试中出现的模三干扰进行PCI 优化，避免出现因模三干扰导致RRC 重建；

PCI 核查类型 同站同模三 近距同频同PCI 二阶邻区同PCI

异常数量 13 59 91

邻区核查优化.xlsx

PCI网内参数核查优

化红河.xlsx

<以上所有信息均为中兴通讯股份有限公司所有，不得外传>

All Rights reserved, No Spreading abroad without Permission of ZTE

第12页 八、专题优化总结

自百日大会战以来红河蒙自网格VOLTE 拉网测试多次出现因RRC 重建失败导致掉话问题，致使蒙自网格掉话率居高不下，经过对RRC 重建的专题优化分析处理，目前红河蒙自VOLTE 整体掉话率较低，具体如下：

VoLTE 呼叫中RRC 重建和数据业务触发机制以及对RRC 层影响完全相同，在LTE 常规优化和投诉处理中因为影响较小而经常被忽视。但如前文分析的，RTCP 协议对底层链路失败引起的re-cover 机制支持不好，所以RRC 重建过程很容易被用户感知到；另外RRC 重建更有可能造成VoLTE 掉话和接入失败。所以VoLTE 优化和商用保障过程中，需要仔细梳理现网存在RRC 重建的原因，并有针对性的采取优化措施。

VOLTE百日会战测试

指标和问题库汇总.xls