TD-LTE VOLTE掉话分析案例

异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。

此处属于测试软件问题，应该予以剔除。

（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。

2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。

中国移动L T E V O L T E案例分析汇总Standardization of sany group #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#广东移动4GTD-LTE详细案例分析案例1：580 Precondition Failure导致的未接通。

【问题描述】在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。

Log文件名：MO UE:MT UE:时间：10：16：【问题分析】1、呼叫过程中，被叫发送Ringing 180后，收到网络下发的专载去激活命令，QCI 1被释放，被叫随后上报580 Precondition Failure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。

2、从信令中可以看到，被叫回复Ringing 180且主叫也已经收到Ringing 180，被叫随后收到网络侧下发的RRC重配，携带有QCI 1被释放的信息，被叫去激活专有承载。

由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition Failure失败消息。

主叫收到网络侧下发的580，接续被中止，导致了会话未接通。

3、从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层nomal_release，导致专载QCI 1被释放。

4、专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE 580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。

【解决措施】需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。

volte测试主叫异常导致的掉话
1.问题描述
在测试过程中，有时间会出现测试一次循环测试结束，信令已经完成，但是由于终端连接问题导致主叫还在继续发送IMS_SIP_BYE-Request，而被叫并没有收到请求，并未做出回应，最终导致Outgoing Dropped Call的错误统计。

2．分析处理过程
图1中在17:44:14时主叫发起IMS_SIP_BYE->Request，被叫也在17:44:14时响应并IMS_SIP_BYE->OK，此时通话应该结束。

但是在图2中主叫事件中出现Outgoing Dropped Call，且主叫信令中在17:44:16时又发起了IMS_SIP_BYE->Request通话结束请求，并连续下发几次请求，最终导致Outgoing Dropped Call。

图1.语音通话结束
图2主叫出现Outgoing Dropped Call现象
图3主叫继续发起IMS_SIP_BYE->Request
检查各项参数并未发现异常，经排查发现是由于UE终端连接异常，从而导致被叫已经挂断而主叫还在继续发送IMS_SIP_BYE->Request请求，出现这种情况检查UE连接状态，必要时需重新连接设备。

3.效果
需要在路测过程中需要实时监控设备连接状况，发现连接异常需及时处理。

4.经验推广情况
在路测过程中需尽量避免设备丢失，如果遇到设备丢失应该进行及时处理；同时进行数据分析时也要详细了解事件的发生的根本原因。

杭州电信VOLTE掉话问题端到端快速定界案例朱臻2019年04月目录1 VOLTE端到端分析困境 (3)1.1掉话定义 (3)2 VoLTE掉话问题定界 (4)2.1定界思路 (4)2.2定界方法 (6)2.2.1 接口选择 (6)2.2.2 接口代码解析 (7)2.2.3 基于代码的问题定界 (9)3 案例分析 (9)3.1 主叫用户不活动定时器超时导致的掉话 (9)3.2 主叫无线资源不可用导致的掉话 (11)VOLTE掉话问题端到端快速定界案例朱臻【摘要】通过以上分析可以发现本次掉话是由于主叫无线资源不可用所致，定位为无线原因。

分析无线侧问题发现UE所占用的小区负荷过高，对该小区进行负荷均衡后问题得到解决。

【关键字】VoLTE、参数优化【业务类别】VoLTE、参数优化1 VOLTE端到端分析困境相比LTE数据业务，VOLTE业务网络架构引入IMS域，VOLTE业务流程涉及终端、接入网、核心网、IMS域等，其中IMS域提供LTE、CDMA、WLAN、固网、他网等多种接入形式，并提供语音、视频、彩铃等多种IP多媒体业务。

因VOLTE业务流程涉及多专业、多网元、多流程，如何快速VOLTE端到端定界定位成为VOLTE端到端分析优化面临的困境。

1.1掉话定义VoLTE掉话率指在移动通信的过程中，终端在VoLTE的通信意外中断的几率。

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

如下图所示：信令监测指标判断应答次数在Mw口统计，掉话次数在RX口统计，有ASR/ASA 消息（会话中断消息）。

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

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”不含在内。

5G部分终端导致TDD小区VOLTE上行高丢包分析案例5G部分终端导致TDD小区VOLTE上行高丢包分析案例关键词：案例分类问题分类：网络性能手段分类：参数调整、软件功能、终端适配关于问题和手段分类项如有其他建议，可补充优化背景6月份开启锚点优先的部分小区，在个别时段下出现上行高丢包，上行高丢包比例达到80%以上，小区性能严重恶化。

问题现象从KPI看6月11日，小区上行VOLTE丢包比较高。

QCI1丢包明显（数量达百万数量级）原因分析在排除了基站告警、干扰等问题后，通过SEQ进行了终端聚类分析，发现高丢包主要集中在中兴5G终端：从话统看，高丢包率都出现在乱序包（L.Traffic.UL.PktDisorderLoss.Loss.QCI.1）异常大的周期：说明终端PDCP层的上行包存在乱序行为。

指标L.Traffic.UL.PktLoss.Loss的统计方式如下：根据SN号是否连续判断是否丢包。

终端上行SN不连续并翻转时，会导致统计大量的丢包。

从复测的结果看，celldt上也可以看到终端切换后重复上了2个SN号为0的包，从而导致基站侧丢包统计超大：重复的SN会导致基站与终端SN维护不对齐，最终解密失败，最终单通。

解决方案通过与华为研发确认，华为给出了解决方案：对应小区的QCI1的参数CELLQCIPARA.NsaDcDefaultBearerMode修改为MCG_BEARER_EUTRA_PDCP后，终端上行发包SN顺序发送，问题不再出现。

效果评估修改后，上行高丢包问题得以解决：时间RRC建立成功率E-RAB建立成功率无线接通率无线掉线率VOLTE无线接通率VOLTE掉线率上行丢包率下行丢包率2019-06-1000:00:0099.88%99.98%99.86%0.016%99.86%0.013%0.143%0.063%2019-06-1100:00:0099.89%99.98%99.87%0.018%99.87%0.015%0.155%0.067%2019-06-1200:00:0099.88%99.98%99.86%0.017%99.87%0.012%0.142%0.063%2019-06-1300:00:0099.89%99.98%99.87%0.016%99.88%0.015%0.021%0.060%基于案例提炼的方法、流程及评估标准建议中兴5G终端（天机10）在对应小区的参数CELLQCIPARA.NsaDcDefaultBearerMode为MCGBearer时，上行存在SN翻转乱序报文，CELLQCIPARA.NsaDcDefaultBearerMode配置为MCG_BEARER_EUTRA_PDCP可规避UE问题，终端发送重复SN报文问题待与终端厂家联合定位。

关于VOLTE掉话率定位分析及优化案例关于VOLTE掉话率定位分析及优化1.1.1.1.优化思路定界流程：1.1.1.2.定位及优化1.1.1.2.1.基于话统定位优化流程对小区的QCI1的ERAB异常释放原因进行统计分析。

对于传输层问题占比大，则需传输侧进行排查分析；切换流程失败原因则重点分析无线质量、邻区关系、参数配置；●排查源小区及目标小区覆盖、干扰等无线质量情况，避免切换时与目标小区同步失败。

●核查邻区关系及参数，并结合地理图层确保已完善周报邻区，保证邻区关系及参数合理性；●参数一致性：核查确保外部邻区基站标识、小区标识、频点、PCI与邻区小区实际参数一致性、避免测量上报错误小区导致切换失败。

●核查切换参数配置：现网同异频切换基本都是基于A3事件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off。

同频切换参数，主要核查优化同频切换参数组ID的同频切换幅度迟滞、同频切换偏置、同频切换时间迟滞：异频切换参数，主要核查优化异频A3偏置、基于A3的异频A1 RSRP触发门限、基于A3的异频A2 RSRP触发门限。

异系统的切换参数，主要合理设置 A2 测量门限，避免由于测量过晚导致终端来不及测量目标小区信号无法切换掉话；无线层问题原因则重点排查弱覆盖、过覆盖、PCI模3干扰、外部干扰、参数配置等；●借助MR数据等措施判断弱覆盖及优化；●核查小区干扰情况并进行处理优化；●通过CQI上报指标统计各调制方式占比，可反映下行信道质量情况，正常情况是64QAM远大于QPSK占比，反之则说明无线质量存在异常。

如下为正常小区下各调制方式占比情况：●通过性能平台TA数据统计评估是否存在过覆盖问题，当TA统计距离明显大于最小站间距，则该小区极可能存在过覆盖。

对于过覆盖问题需进行增大下倾角、降低功率、站点整改等。

无线网络拥塞原因。

对于无线网络拥塞原因导致语音掉话，则需对拥塞原因进行排查及扩容等优化处理。

经典案例-VoLTE掉话研究和实践总结Volte掉话研究和实践总结1概述随着Volte的不断放号，Volte用户不断增加，如何保持Volte用户在语音通话过程中不掉话将至关重要。

本文将介绍Volte语音掉话优化方法以及台州Volte掉话优化成果。

下图所示为挂机流程：Volte掉话定义如下：掉话率：（主叫掉话次数+被叫掉话次数）/(主叫呼叫建立成功次数+被叫呼叫建立成功次数)路测软件掉话定义：呼叫成功后，通话阶段收到RRCCONECTION RELEASE消息，挂机阶段QCI1承载没有释放，BYE REQUEST没有收到200 OK。

2影响Volte掉话的因素Volte掉话问题涉及到UE，EnodeB，EPS，IMS端到端网元，需要各个网元联合分析和定位具体原因。

影响Volte掉话的因素如下图所示：3Volte掉话定位思路首先确定是哪类原因引起的掉话，再根据触发异常的网元分析掉话原因。

Volte通话过程中网络侧下发RRC Release或者SIP信令异常等掉话问题，一般是由空口质量，切换失败，重建，流程冲突等原因造成，涉及端到端网元，因此定位根因需要端到端信令，下图是Volte 定位思路。

如上图所示，分析Volte掉话时，告警核查和参数核查是无条件执行的。

掉话是在通话阶段收到了RRC Release1、查看基站侧虚用户跟踪，若是基站触发的，查看S1口释放原因。

2、根据原因值结合基站日志进行分析。

3、若是MME触发的，则查看释放原因，联合MME分析。

QCI1承载没有删除1、查看QCI1承载删除是否有切换，TAU流程，若存在查看基站虚用户跟踪，EPC跟踪，分析流程交叉处理顺序是否合理。

2、若流程交叉无问题或是无流程冲突，则查看基站虚用户跟踪是否收到QCI1承载删除。

3、若基站收到QCI1承载删除，则分析基站为何没有下发给终端。

4、若基站没有收到QCI1承载删除，则查看MME/PGW/SGW是否收到PCRF指示删除QCI1承载。

Volte掉话案例在对已经升级为14.3版本的网格10进行拉网测试时发现，仍出现主叫与被叫先后上发BYE，去激活专用承载后收到BYE487导致掉话问题，具体情况如下：被叫，主被叫先后发起Bye消息，去激活专用承载后，网络侧下发Bye 487导致掉话（截图如下）：（A）核心网消息跟踪上看，被叫在15:35:51.470先上发BYE，核心侧未等到主叫回BYE200，就在15:35:51.556又收到主叫上发的BYE消息。

导致核心侧发BYE487：Glare BYE condition encountered，原因：在下发一个bye请求(来自被叫)，但还没有收到应答，收到一个上行的bye请求（来自主叫）。

（B）之前已经出现BYE487掉话的问题，是因为与华为站点的PDCP-SN-SIZE设置不同导致的掉话，但是网格10进行升版之后已经全部修改一致。

为了对问题更好的定位，次日我们对网格10又进行了一次拉网测试，并留意观察在掉话之前是否有声音以最终确定问题现象与PDCP-SN-SIZE导致的问题是否一致！结果发现在BYE487问题导致掉话前10s是没有声音的。

所以依然是单通和不通导致的掉话。

在对拉网数据进行分析时发现，在黄浦路二试扩L-1小区下进行起呼时在下发重配消息中的PDCP-SN-SIZE还是12bit。

（C）所以我们再一次进行了参数的核查，发现14.3版本的站点的应该和LR13.3一样指向DedicatedConf/0 PdcpConf/1，因为DedicatedConf/0 PdcpConf/2中定义的PDCPPDUSNSIZE=12,所以指向到了DedicatedConf/0 PdcpConf/2，就出错了。

截图如下：（D）最终核查结果又一百多个站点的指向错误，在修改指向后进行了复测，BYE487掉话没有出现。