TD-LTE VOLTE掉话分析案例

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，属于端到端问题，需要集团规范协议流程。

中国移动LTEVOLTE案例分析汇总

中国移动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测试主叫异常掉话案例

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掉话问题端到端快速定界案例【推广案例】

杭州电信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掉话问题处理思路与优化方法目录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上行高丢包分析案例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掉话率定位分析及优化案例关于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统计距离明显大于最小站间距，则该小区极可能存在过覆盖。

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

无线网络拥塞原因。

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

5.VoLTE案例分析

落的小区根本无需做位置更新。
注：该问题正在与终端厂家沟通中….
几类人工剔除异常介绍
平台规则问题：3分钟双bye收OK回复案例
现象：呼叫满3分钟后，终端上发SIP bye后3秒又上发sip bye消息，并收到OK回复。规则：已有网络问题发现，存在双bye后掉话的情况，因此平台算法对全部双bye问题标记为掉话。分析：虽然出现了双bye挂断，（1）满足呼叫规则3分钟挂断且收到OK回复，（2）期间RTP包交互正常确认应为正常挂断，sip bye消息重发。
2. 被叫振铃不接听案例现象：被叫update交互完成后，上发振铃，未上发 OK,主叫收到振铃，18秒后上发了cancel取消。软件：惠杰朗CDS 分析：被叫上发振铃后，按照软件设置应在1秒后立即接听，怀疑软件触发的接听AT指令未其作用。
注：平台对掉话判断规则，在出现sip invite OK后，监测后续的sip bye消息，若出现sip bye且收到OK则判断为正常，若无发生下1次起呼，则以下次起呼时间作为上次掉话的时间点。。
现象/原因分类振铃不接听
呼叫过程中主叫再次起呼或被叫异常发起寻呼终端主动挂机
LOG信令记录丢失 SIM卡故障
说明被叫振铃但不接听接通状态下起呼或寻呼起呼或接通后的立即挂断由于软件问题导致的LOG未记录非人为因素导致的SIM卡松动
问题判定
问题子类判定
测试软件问题测试设备问题
丢信令
如GSM下的信令丢失，TD、LTE信令不连续则需要仔细辨认，确认非基站闪断造成
注：VOLTE未接通触发CSFB接通，仍然统计VOLTE未接通；特别说明由于是统计规则后续可能会按照集团要求变更。
HTC M8版本升级引入silent redial功能

经典案例-VoLTE掉话研究和实践总结

经典案例-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掉话案例(参数指向错误)

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掉话没有出现。

精品案例_电信Volte用户异常掉话故障排查案例

精品案例_电信Volte用户异常掉话故障排查案例Volte用户异常掉话故障排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)宣城电信Volte用户异常掉话故障排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB 异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。

【关键字】VoLTE 掉话专用承载【业务类别】VoLTE、掉话一、问题描述3月23日对宣城电信市区的主要路段进行了VOLTE业务拉网测试。

统计分析指标时，按照省公司下发的VOLTE业务能力测试规范统计指标时，发现1处掉话测试UE在其他基站可以正常进行VoLTE呼叫，基本可以排除测试UE的问题。

并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。

由于之前一直未查出原因，现场还进行数据重新制作，也未能解决。

二、分析过程按逻辑时间在MS1信令中查找该问题点，是一条RRC连接释放消息，如下图：向上查找，在22:53:13:452时刻发现DEACTIVATE EPS REQ （EPS承载去激活请求）消息，并得到了网络的响应（DEACTIVATE EPS ACC）。

继续向上查找，发现在22:53:13:392时刻MS1收到了BYE 500 Service Internal消息，如下图：查看消息体（下图），该消息为网络下发给UE的（Network to UE）,告警正文中显示无法收到对端（MS2）的响应（No Response From Peer）。

VoLTE通话跨厂家切换时释放QCI1导致掉话e66x

VoLTE通话跨厂家切换时释放QCI1导致掉话案例背景中国移动TD-LTE语音解决方案以VoLTE为主，同时兼顾CSFB，双待机作为一种终端形态将长期存在。

其中VoLTE由IMS网络实现呼叫控制，通过PCC架构提供端到端的QoS保障。

在移动到没有TD-LTE覆盖时，采用切换至GSM的方案实现语音业务连续性，切换方案主要采用3GPP R10的eSRVCC功能。

2015年广东移动开始部署VoLTE功能，VoLTE网络的复杂度对VoLTE的优化提出了极大的技术要求。

VoLTE语音通话的掉话直接影响用户感知，拉网测试过程中遇到VoLTE通话跨厂家切换时释放QCI1导致掉话。

问题案例描述广州VoLTE测试过程中，在爱立信-中兴边界，出现了较多的掉话现象，经过分析，掉话时都呈现如下一种现象：主叫在中兴小区向爱立信小区发起切换请求时，中兴基站下发的RRC Connection Reconfiguration消息中，包含QCI1释放的内容，之后该切换虽然成功，但手机上报BYE request，且网格不响应BYE消息，最终掉话。

分析与对策VoLTE通话过程中，当中兴小区向爱立信小区进行切换时，RRC Connection Reconfiguration消息中，包含QCI1释放的内容：VoLTE通话跨厂家切换时释放QCI1导致掉话图1反之爱立信小区向中兴小区切换时，RRC Connection Reconfiguration消息中不会释放QCI1：VoLTE通话跨厂家切换时释放QCI1导致掉话图2查看测试起呼QCI1建立时的RRC Connection Reconfiguration消息，并对比中兴、爱立信小区相应参数的设置，发现pdcp-SN-Size、sn-FieldLength设置不一致：中兴pdcp-SN-Size = len12bits、sn-FieldLength = size10，爱立信pdcp-SN-Size = len7bits、sn-FieldLength = size5。

LTE网络杂散干扰导致的VOLTE高掉话优化案例

LTE网络杂散干扰导致的VOLTE高掉话优化案例一、问题现象长治D2_LU潞城安乐ZLF_H-2小区无线接通率和掉话率指标持续恶化，且恶化趋势明显。

指标统计截图如下：二、问题分析通过TOP小区的分析流程进行问题排查发现，D2_LU潞城安乐ZLF_H-2小区上行干扰严重，且主要表现为前高后低的波形走势，判断为杂散干扰。

对于现网高干扰小区影响KPI指标时，由于扫频排查干扰源耗时较长，较难及时处理，可以通过修改上下行PRB偏置参数临时解决部分低接入、高掉话TOP小区。

参数使用场景：（1）、只有部分频段有强干扰（高干扰频段最好小于一半RB），频谱如图2.（2）、小区业务量不是很高（业务量较高的话，无论如何都会分配到高干扰频段PRB）（3）、一个站点3个小区只有1个或2个小区存在高干扰、指标差（3个小区上行干扰都高的小区无法解决）备注：该方案只是辅助性方案，需注意的是排查干扰依旧是解决问题主要手段。

三、问题处理基本原理：优先为终端配置干扰较小频段的资源（RB)修改方法：CellType=0/1/2，优先分配的RB如下图所示：注意：其中需PRB随机化偏置上下行都要同步修改。

PRB随机化偏置修改位置如下：将D2_LU潞城安乐ZLF_H-2的上下行PRB随机化偏置由0修改为2后低接入和高掉话问题基本解决，修改前后对比如下图所示：四、问题总结通常干扰分为上行干扰和下行干扰，系统内干扰和系统外干扰，不论哪种类型的干扰都会导致掉话：上行干扰可以从话统指标进行分析。

TDD系统上行干扰包括普通时隙和特殊时隙的干扰两方面，两种干扰呈现的特征也是不一样的。

对于杂散干扰只干扰前部分PRB的情况下，由于扫频排查干扰源耗时较长，较难及时处理，可以通过修改上下行PRB偏置参数临时解决部分低接入、高掉话TOP小区，该方案只是辅助性方案，需注意的是排查干扰依旧是解决问题主要手段。

案例-VoLTE测试常见掉话未接通案例

VoLTE测试常见掉话未接通案例1.背景VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。

首先，高清语音和视频编解码的引入显著提高了通信质量，其次，VoLTE的呼叫接续时长大幅缩短，但VoLTE测试过程中仍发现部分掉话、未接通的现象，严重影响用户的感知。

本文梳理了VoLTE测试过程中常见的掉话、未接通的处理案例，为日后VoLTE试商用后此类问题的处理打下坚实的基础。

2.VoLTE语音通话流程简要如下：1.主叫发起INVITE消息，触发RRC建立过程（假设为空闲态）；INVITE消息包括主被叫电话号码，主叫支持的媒体类型、编码；2.主叫建立SRB2承载、QCI=9的DRB、QCI=5的sip信令承载；3.核心网反馈INVITE 100，表面正在处理应答；4.主叫RRC重配置建立QCI=1的专用承载；并激活；5.主叫收到被叫INVITE 183消息；并反馈PRACK启动资源预留；6.被叫收到PRACK后，反馈PRACK 200，启动资源预留；7.主叫收到PRACK 200，发送UPDATE，表明资源预留成功；8.同样被叫收到UPDATE，反馈UPDATE 200，表明资源预留成功；9.被叫发送INVITE 180 RINGING，振铃；10.被叫反馈INVITE 200，表明摘机11.主叫收到INVITE 200后，反馈ACK给IMS服务器，应答初始INVITE请求；并有IMS发给被叫；12.通话中；13.被叫挂机，发送BYE；IMS转发给主叫；14.主叫挂机，反馈BYE 200，IMS转发给被叫，表明结束会话；15.RRC重配置去激活QCI=1专载；图1.1 释放专载图1.2 简化信令流程图3.DT测试中常见的掉话、未接通问题2.1.切换失败导致常见有较多MR上报但不切，可能邻区漏配，之后触发RRC Re-Establishment，重建立不成功时掉话。

2-VOLTE挂机信令不完整测试软件统计为掉话案例

告警信息
无告警
原因分析
（一）、分析流程图：
网格1
volte测试过程中小区切换导致
主叫掉话
可能导致该问题的原因：
1、测试终端问题；
2、无线网问题；
3、核心网问题
测试终端问题
是否是该原因导致
无线网问题
是否是该原因导致
N
核心网问题
是否是该原因导致
提出解决方案
问题是否解决
经验总结并输出报告
结束
2、主叫在15:30:37.737收到IMS下发的bye200消息后，MME应该下发Deactivate EPS bearer context
Request给源小区携带NAS释放专载，但同时源小区触发X2切换，向MME响应ERAB release response （X2-Handover-Triggered），NAS消息未下发到手机，而根据协议36.413 中8.6.2.4有描述当LTE小区在触发X2切换时，将不传递NAS消息，导致挂机流程超时而被CDS软件统计为掉话。

VOLTE案例分析

1 优化经验总结1.1 日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。

1.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。

呼叫建立过程中专载建立与切换几乎同时发生，MME 未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。

原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。

优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。

1.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。

原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。

经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。

优化措施：QCI5 PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481invite486invite580，呼叫失败。

优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。

1.5 系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。

精品案例_VoLTE掉话率异常分析案例

VoLTE掉话率异常分析案例目录一、问题描述 (3)二、分析过程 (4)三、解决措施 (6)四、经验总结 (7)VoLTE掉话率异常分析案例【摘要】日常进行VoLTE相关指标分析时，发现8-13号VoLTE掉话率激增异常，查看具体指标详情，主要由于一台设备某时段连续发生8起掉话，导致VoLTE掉话率指标恶化。

分析LOG发现高掉话时段主要由于主叫被一陌生号码连续呼叫导致，排除此号码后掉话率恢复正常。

【关键字】VoLTE,掉话【业务类别】化方法、参数优化、其他一、问题描述进行每周VoLTE指标分析时，发现VoLTE掉话率同比上周激增，掉话率为0.24%，接近不达标。

具体查看指标分析，发现主要由于0320设备导致掉话激增，同时该设备还存在一时段多次掉话的异常情况，需进行重点分析优化处理。

图表 1：VoLTE掉话率指标图表2：与上周VoLTE掉话率对比二、分析过程2.1、站点故障排查图表3：:异常小区清单1图表4：:异常小区清单2图表5：:告警查询由上图可知，掉话集中片区，站点无故障告警，性能指标无异常小区，判断非站点问题导致。

2.2、信号质量排查由于主要是VoLTE掉话率指标异常，首先查看是否信号质差导致。

排查是否信号质差导致。

图表6：：RSRP覆盖图表7：：SINR覆盖由上两图可知，大量掉话范围内的RSRP和SINR整体正常，判断掉话问题非信号原因导致。

2.3、终端问题排查前面排查可知，此次大量掉话问题非信号质量和基站故障导致，且只有某一时段故障，且故障时间内掉话非连续，排除核心网故障导致。

判断可能由于终端问题导致大量掉话问题。

大量掉话过程中存在正常的通话，表明卡使用正常，非手机卡的问题。

故障时段过后VoLTE掉话率恢复正常，且无异常情况。

表明测试终端正常。

2.4、掉话信令分析仔细进行信令分析，发现此段LOG还存在大量Incoming Blocked Call，但是问题LOG为主叫测试端口信令，不应该会有被叫时间出现，且存在大量未接通。

LTE异常掉话案例

异常掉话案例
1问题描述
在某地TD-LTE网络网格优化中，发现380到38切换覆盖路段连续异常掉话。

而且现场RSRP大于90dbm情况下掉话，路测截图如下：
2问题原因分析
排查思路
1. 查看后台告警信息，该小区没有历史告警和当前告警；
2. 定点验证各个站点速率是否正常；
3. 解决该路段导频污染问题；
4. 最后结合现场测试问题进行处理。

3问题解决方案
1. 通过检查该路段两个站点告警情况，发现1955、1954两个站点无告警，
而且定点速率可以达到为40Mbit/s，可以判断开通站点业务正常。

2. 通过分析发现该路段为PCI (380)——PCI (38) ——PCI (380)进行连续
覆盖频繁切换，速率不稳定，不能行成主服务小区单独覆盖。

后续对380增
加RS功率，减小38RS功率不能形成380主服务；对38增加RS功率，减
小380RS功率不能形成38主服务；
3. 关闭PCI (38) 小区，没有掉话，可以判断为38为主干扰源，如下图：
4. 分析发现为模3干扰，对1955站点二三小区PCI (38) 、PCI (37)进行
对换，修改完成PCI，进行验证，该路段覆盖和业务正常。

4总结及注意事项
1. 对路测分析时，要分析清楚各个小区的切换关系；
2. 对存在模3干扰的小区可以调整PCI，但是一定要注意修改后对其它站
点影响。

移动LTEVOLTE案例分析汇总

移动L T E V O L T E案例分析汇总Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】广东移动4GTD-LTE详细案例分析案例1：580PreconditionFailure导致的未接通。

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

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

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

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

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

3、从MME下发到NodeB的E-RABRELEASECOMMAND，原因上看是Nas层nomal_release，导致专载QCI1被释放。

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

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

【测试验证】案例2：ServerInternalError500导致的未接通【问题描述】在集团测试LOG中，存在ServerInternalError导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的ServerInternalError500消息，随后呼叫中止，出现未接通事件。