VoLTE掉话问题处理思路与优化方法VoLTE掉话问题处理思路与优化方法目录VoLTE掉话问题处理思路与优化方法 (1)1概述 (3)2VoLTE掉话率问题定界排查 (3)2.1VoLTE掉话问题定界思路 (4)2.2VoLTE掉线率TOPN小区定位排查思路 (5)3VoLTE掉线信令流程以及相关指标 (6)4VOLTE掉话无线问题优化方法 (7)4.1由于ENB的无线链路失败 (7)4.2由于ENB重建立失败 (9)4.3由于小区关断或复位 (11)4.4ENB由于S1链路故障发起释放 (11)4.5由于UE切换失败 (14)4.6由于UE不在线导致释放 (14)4.7由于ENB小区拥塞导致的释放 (14)4.8由于ENB过载控制导致的释放 (14)5VOLTE掉话处理案例 (15)5.1邻区漏配导致的掉话问题处理案例 (15)5.2弱覆盖导致的掉话问题处理案例 (18)5.3切换失败导致的掉话问题处理案例 (19)6总结 (20)1 概述目前萍乡电信VoLTE商用在即，VoLTE作为LTE网络实现语音通话的最终方案，用户对VoLTE高清语音的需求将越来越大，但目前由于电信Volte没有实现弱覆盖情况下的异系统切换，所以在弱覆盖区域存在较大的掉话风险。

伴随着网络规模的进一步扩大以及网络结构的日渐复杂，处理VoLTE的掉线问题即将成为日常网络维护中一项重要的工作。

本文通过研究VoLTE掉话问题定位及处理方法，主要从无线链路失败、切换失败、拥塞等方面展开分析，并总结VoLTE掉话问题处理优化经验。

2 VoLTE掉话率问题定界排查VoLTE掉话率指在移动通信的过程中，终端在VoLTE的通信意外中断的几率。

在信令监测平台上，VoLTE掉话指标取自于Rx接口和Mw接口，公式如下：VoLTE语音掉话率=VoLTE语音掉话次数/(（VoLTE语音始呼应答次数+VoLTE语音终呼应答次数）)VoLTE语音掉话次数指SBC（不区分主叫域和被叫域）收到PCRF发送媒体类型为语音的ASR（下图消息1）的次数，且ASR中Abort Cause为“PS to CS Handover”不含在内。

如下图所示：信令监测指标判断应答次数在Mw口统计，掉话次数在RX口统计，有ASR/ASA 消息（会话中断消息）且ASR消息中携带的abort cause值不为3（3 表示ESRVCC切换）。

信令监测掉话率有可能同一个呼叫PCRF发多次ASR，比如多方通话场景或者用户呼叫保持后再拨打另一路通话，这时会议发起方掉话就会算多次掉话。

从目前大量测试分析发现当前判断标准并不能涵盖所有掉话场景，有部分场景的掉话并不会触发ASR/ASA消息。

各信测厂家对不同网元厂家Rx接口的关联情况实现有差别，需明确信测厂家支持AAR消息中sip和tel这两种格式的关联。

2.1 VoLTE掉话问题定界思路针对不同应用场景下的应用的算法，可从核心网、无线网两方面共同发起定界分析：对端到端信令平台的各接口如Mw、Rx、Gx、S11接口数据，利用时间维度和终端信息对失败原因进行准确关联，获取掉话场景下各接口承载释放消息中的失败原因码，形成主要问题的判决条件。

通过对大量信令案例的分析对比，总结出各类型问题的典型信令特征，以SIP信令中BYE消息的reason头域深度解析为着手点，对用户、无线、EPC、IMS等问题进行原因定界。

选用接近UE侧的S1-MME接口作为分析VOLTE掉话的入口。

使用IMSI为串联关键字，串联出一个用户在S1接口上的四种消息流程：EPS_BEARER_CONTEXT_ACTIVATIONEPS_BEARER_CONTEXT_DEACTIVATIONUE_CONTEXT_RELEASE_REQUESTUE_CONTEXT_RELEASE_COMMAND数据的关联聚合按照IMSI和时间点进行排序，并按照VOLTE无线掉话特征流程：专载建立成功后，在没有专载去激活流程的情况下，eNodeB直接发起UE上下文释放请求，符合VOLTE无线掉话信令模式。

UE CONTEXT RELEASE REQUEST选取消息中带的radionetworklayercause来进行判别，除了2，20，23，24，28，其它都定界为无线掉话。

2.2 VoLTE掉线率TOPN小区定位排查思路先分析是哪类原因引起的掉话，再根据触发异常的网元分析掉话的原因。

对于VoLTE 通话过程中网络侧发起RRC Release，涉及到传输、eNodeB、核心网。

VoLTE掉线流程如下：1、提取细分异常释放原因的计数器，查看由那类计数器引起的失败次数最多，针对性处理。

2、核查邻区关系：删除过远邻区，添加漏配邻区3、核查邻区参数配置是否正确4、上行干扰排查处理：对于上行干扰站点及时进行处理5、同频同PCI、同频同PRACH复用距离核查6、上行功控参数核查：对于上行功控方式（开环、闭环），P0等相关参数核查配置是否合理7、站点告警核查：对于影响指标的告警及时进行处理8、对于因弱覆盖导致掉线，若终端处于覆盖边缘，周围无可用的LTE小区，可以调整系统间重定向/切换策略，使用终端重定向/切换到3G/2G，减少掉线次数。

3 VoLTE掉线信令流程以及相关指标UE释放相关信令流程如下：KPI统计相关失败Counter如下：4 VOLTE掉话无线问题优化方法4.1 由于ENB的无线链路失败无线链路失败由以下四种情况造成：（1）eNodeB的RLC层检测到空口重传超过最大重传次数；（2）eNodeB的PDCP层检测到完整性保护失败。

通常和加密/完保算法相关，需要重点核查基站配置的加密/完保算法；（3）监测到空口消息超时。

空口定时器超时是指等待RRC重建立完成/重配完成定时器超时。

重配的作用主要是是修改RRC连接（如建立/修改/释放无线承载）、执行切换、建立/修改/释放测量、增加/修改/释放辅载波，当重配消息中部分或是全部小区和UE理解不一致时，会造成重配不响应；（4）SR达到最大重传次数或者上下行HarqFail过高。

造成空口失败的主要原因有：告警、上行干扰、弱覆盖、超远覆盖、参数问题、其它原因。

详细排查流程如下：（1）站点告警：关联无线链路失败时段相关告警，若指标较差时段和告警时段相匹配，需要进行告警处理，无线链路失败涉及告警如下：（2）异常参数配置：核查无线链路失败相关参数，如和推荐参数不一致，修改为推荐参数。

（3） 上行NI>=-105dBm:干扰问题排查。

（4） RSRP<=-110dBm:弱覆盖问题排查。

（5） TA>6（城区）或TA>36（农村）：超远覆盖问题排查。

4.2 由于ENB 重建立失败当eNodeB 接收到从UE 来的RRCConnectionReestablishmentRequest 消息后，经过接纳等流程，处理失败，给UE 发RRCConnectionReestablishmentReject 消息，触发UE 释放。

造成重建失败的原因包括：（1）检测无线链路失败； （2）切换失败导致； （3）eUTRA 移动性失败； （4）完整性校验失败； （5）RRC 重配置失败。

路测中发现的RRC 重建原因归类。

其中超过64%的属于基础网络问题，包括弱覆盖和邻区干扰引起的质量问题；约27%属于规划配置类问题，包括PCI 冲突以及相邻基站RLC SNSIZE 不一致造成的切换失败；约9%属于其它原因。

另外目前跨站重建立成功需要X2进行上下文信息交互，如果不配置X2的话跨站重建立则不能够成功。

建议处理重建立失败导致的掉线问题时首先确保网络中X2配置占比达到95%以上，以降低跨站重建立失败概率，减少由于重建立失败导致的掉线。

造成重建立失败的主要原因有超远覆盖、邻区漏配、X2漏配、参数配置异常、其它原Others:下行链路质量原因23%Others ：上行链路质量原因32%Others ：PCI 冲突4%Reconfigurefailure ：SN 参数不一致，重配置失败23%HandoverFailure ：RF 原因9%Others:其它原因9%RRC 重建原因归类因。

详细排查流程如下：（1）参数配置异常：需要核查重建失败相关参数配置（2）邻区漏配核查：邻区漏配会导致切换不及时，服务小区信号指标差导致重建立。

详细核查流程如下：（3）X2漏配：X2配置需要和邻区配置保持一致。

（4）TA>6（城区）或TA>36（农村）：超远覆盖问题排查。

4.3 由于小区关断或复位当eNodeB接收到从OMC来的人为触发的小区闭塞命令，或者由于eNodeB异常告警触发小区Reset，导致发起E-RAB释放。

该问题需要重点核查小区告警，相关告警如下：4.4 ENB由于S1链路故障发起释放S1链路故障包含如下情况：（1）当eNodeB检测到S1的光口故障。

当eNodeB检测到光口相关故障触发UE释放。

通过和光口告警相关，重点核查相关告警（参见5.3.1）。

（2）GTPU层检测到Path（eNodeB和SGW业务通路）故障。

当eNodeB检测到GTP-U Path（eNodeB和SGW的业务通道）故障触发UE释放。

当UE接入网络后，为保证eNodeB和SGW的业务通道处于激活状态，eNodeB会周期性的向SGW发送Echo Request消息，如果收到SGW的Echo Response，说明GTP-U隧道处于激活状态，如果未收到Echo Response消息，说明GTP-U隧道异常，eNodeB会发起释放请求。

SGW的地址可以在Initial context setup request消息中进行查询。

该问题是由于eNodeB和SGW通道出现异常，原因主要是由于传输或是核心网问题导致GTP-U隧道通信异常。

可以通过EMS->诊断测试->IP通道测试进行问题排查。

（3）GTPU层接收到对端的Error Ind消息。

S1链路释放导致的释放通常和光口告警、传输或是核心网相关。

当eNodeB收到从MME来的S1 Rest消息或者Error Index消息，该问题主要和核心网相关，需要核心网协助排查。

S1链路故障导致异常释放主要和传输、参数配置、告警、核心网、其它。

详细排查流程如下：（1）传输问题排查：eNodeB->SGW ping包丢包率>3%时需要核查eNodeB<->SGW 之间的IP通道质量问题。

（2）告警排查：关联S1链路故障相关告警，若指标较差时段和告警时段相匹配，需要进行告警处理，S1链路故障涉及告警如下。

（3）参数配置问题：重点核查和S1链路故障相关参数配置。

（4）核心网问题排查：当eNodeB收到从MME来的S1 Rest消息或者Error Index 消息时，需要核心网协助进行排查。