VoLTE外场测试分析案例
v1.0 可编辑可修改 1 案例1：580 Precondition Failure导致的未接通。
【问题描述】 在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。
【问题分析】 1、 呼叫过程中，被叫发送Ringing 180后，收到网络下发的专载去激活命令，QCI 1被释放，被叫随后上报580 Precondition Failure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。 2、 从信令中可以看到，被叫回复Ringing 180且主叫也已经收到Ringing 180，被叫随后收到网络侧下发的RRC重配，携带有QCI 1被释放的信息，被叫去激活专有承载。由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition v1.0 可编辑可修改 2 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。 v1.0 可编辑可修改 3 【测试验证】
案例2：Server Internal Error 500导致的未接通
【问题描述】 在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。
【问题分析】 1、 主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE 200，随后被叫发送Ringing 180，主叫同时收到UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE 200，再收到Ringing 180。 v1.0 可编辑可修改 4 2、 然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放，去激活，导致会话未接通。
【问题定位】 主叫收到网络侧下发的INVITE 500，然后网络侧又下发RRC重配，释放掉QCI 1，然后去激活，会话流程终止，导致未接通 v1.0 可编辑可修改 5 【解决措施】
需要核心网确认，为什么会下发INVITE 500，什么情况下会导致网络侧下发INVITE 500，随后的专载释放是否由INVITE 500导致的
【测试验证】 案例3：软件对失败事件的误判导致统计错误
【问题描述】 在集团测试LOG中，存在软件的误判而错误统计的失败事件。如在某个特定时间点上，信令显示主被叫正常通话，软件却统计出掉话或未接通事件。
【问题分析】 1、 主叫从09:42:41主叫开始呼叫到09:45:47挂机成功，在通话过程中信令流程正常，中间出现一次RRC重建被拒，导致RRC释放，事件表现为掉话，软件统计为掉话。 v1.0 可编辑可修改
6 2、 在09：44：主叫收到网络侧下发的RRC重建被拒，主叫随后发起RRC建立请求，在09：44：15：004，然后因为TAU，在09：44：15：128 RRC Connection Release了，软件统计为掉话。随后主叫又发起RRC连接，且在09：44：重建完成，从RRC重建被拒到RRC连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。
3、 到最后结束通话正常挂机都没有出现失败事件 v1.0 可编辑可修改
7 【问题定位】
主叫接通后，在没有收到通话结束的情况下，中间出现RRC Connection Release，软件判断为掉线，此次是在会话建立后出现，软件统计为掉话
【解决措施 】 需要鼎利修改判断事件失败的机制 【测试验证】 案例4：软件对失败事件的重复统计 【问题描述】 软件对于失败事件存在重复统计的问题，在集团测试问题统计表中，多次出现同一次失败事件，软件却作了多次统计，导致失败事件的增多。
【问题分析】 1、 主叫在10：04：发出INVITE会话请求，被叫在10：04：收到网络侧下发的BYE Request，软件统计为掉话。 v1.0 可编辑可修改
8 查看BYE Request中的CALL-ID，发现是上次会话的BYE Request
2、 被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100，又在10：04：收到网络侧下发的INVITE Request同时发送Trying 100，并在同时发送INVITE 486，软件统计为未接通。
3、 主叫在收到网络侧下发的UPDATE 200后，在10：04：上报Cancel，主叫的整个会话流程到这里被终止，事件上表现为未接通。且承载都存在 v1.0 可编辑可修改
9 【问题定位】 通话期间，被叫收到网络下发的BYE Request会被软件统计为掉话。被叫连续两次收到网络下发的INVITE Request，回复INVITE 486 Busy Here，由于第一次INVITE Request未释放，故第二次INVITE Request网络侧才会下发INVITE 486，流程停止，软件统计为未接通。此时主叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。
【解决措施】 需要鼎利确认对失败事件的统计机制。 【测试验证】 案例5：LTE到2G eSRVCC切换失败导致的掉话
【问题描述】 呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置v1.0 可编辑可修改 10 命令，但在2G侧切入失败，导致掉话。 【问题分析】 1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入2G网络，2G网络下发TMSI Reallocation Command，被叫回复TMSI Reallocation Complete，此后流程中断，eSRVCC切换失败。
3、 信令上看，4G流程正常走完且建立会话，被叫切换到2G，但是网络下发TMSI Reallocation Command导致流程终止，eSRVCC切换失败，会话流程结束，怀疑是2G问题。 v1.0 可编辑可修改
11 【问题定位】 4G流程正常且已正常建立会话，由于2G网络侧下发TMSI Reallocation Command导致eSRVCC切换失败，会话流程结束，导致掉话，怀疑是2G的问题。
【解决措施】 【测试验证】 案例6： TAU过程中RRC Connection Release导致的未接通
【问题描述】 在越秀区网格10的测试LOG中，出现如下的未接通事件： 主叫起呼发出Invite消息后，在收到网络效应Trying 100之前，先收到了网络下发的RRC v1.0 可编辑可修改 12 Connection Release消息，RRC连接释放后，接续被终止，出现了Blocked Call事件。
【问题分析】 1、通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：
2、在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。然而Invite上发后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫释放，从而导致了Blocked Call事件的发生： v1.0 可编辑可修改
13 3、进一步分析信令可以发现，主叫在该测试路段内连续在3个TAC（9437、10315、10014）间进行TAU更新，其中从11:42:53至11:43:04就发生了4次，可能在存在TAC规划不合理的问题。
【问题定位】 TAC规划不合理。 【解决措施】 规划TAC v1.0 可编辑可修改
14 案例7：Alerting中eSRVCC失败导致未接通
【问题描述】 主叫起呼后，流程正常，达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180，主叫未摘机，由于切换失败导致未接通。
【问题分析】 1、 主叫在11：25：起呼，到11：25：收到网络侧转发的Ringing 180，整个信令流程正常。
2、 在主叫几乎收到网络侧转发的Ringing 180的同时，主叫达到eSRVCC切换门限，网络侧在11：25：下发eSRVCC切换命令，在切换过程中主叫处于振铃中，并未摘话，而切换失败，导致了未接通。
VoLTE业务资料VoLTE问题案例集
文档版本
V1.0
发布日期
2015-01-28
华为技术
修订记录
Date
日期
Revision Version
修订版本
CR ID
CR号
Section Number
修改章节
Change Description
修改描述
Author
作者
2015-01-22
V1.0
初稿完成
曾佳00130333
为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个华为站点PTH112下面验证总共得到以下3种失败场景如下：
Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；
图9：Case1网络下发鉴权挑战401终端未收到
Case2: Sony终端基于UDP的Register消息异常；
通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。
P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：
如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.
3.eNodeB版本和配置以及话统分析
检查eNodeB版本：BTS3900 V100R009C00SPC160；
检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；
检查小区信号质量：正常；
检查数传业务成功率：正常；
检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，VoLTE均失败；
VOLTE路测分析报告-2015-07-20-2
VOLTE路测分析报告_20150720 1 概述1.1 测试区域1.2 测试方式2部MATE7互拨语音拉网测试，拨打时长180S，拨打间隔30S。
2 VOLTE测试结果2.1 总体指标概览2.2 关键指标分析1）RSRP&SINR2) MOS评分3 重点问题分析3.1 VOLTE呼叫建立失败问题本轮网格9拉网测试中，主叫VOLTE呼叫建立失败2次，被叫VOLTE呼叫建立失败1次，问题点分布如下所示。
3.1.1 EPC不发QCI建立导致未接通问题分析：车辆沿下贝岭大道由西向东行驶时，主叫UE终端在12:59:53.955占用东莞下岭贝商业街F-HLW-3起呼，RSRP=-84.50dBm，SINR=14dB，无线环境良好，但主叫在层3消息qci1已建立，最后转CSFB，导致接入失败。
在SIP消息上，主叫发INVITE 消息1s后，网络侧向主叫下发invite消息，3s后网络侧向主叫发送503service unavailable，主叫呼叫建立失败。
解决方案：1、需要EPC定位不下发QCI1建立请求的原因2、待复测时跟踪epc信令复测验证：3.1.2 EPC不发QCI建立导致未接通问题分析：车辆沿横东一路由东往西行驶时，主叫UE终端占用东莞富康新街D-HLH-102小区13：58:27:549起呼，起呼时RSRP=-100.38dBm，SINR=14dB，呼叫过程中主叫未收到QCI1的建立请求，2s后网络侧向主叫下发BYE：408 request timeout，网络侧没有响应，从SIP消息上看，主叫发送invite消息后网络侧没有向主叫发送update建立QCI1，最终主叫显示VoLTE的呼叫建立失败。
解决方案：1、epc未给主叫下发qci1建立请求，需要epc核查原因复测验证：3.1.3 被叫QCI=1承载未建立导致未接通问题分析：车辆沿长岭二街由由南向北行驶时，被叫UE占用东莞华诚实业D-HLH-2（PCI=394）小区，RSRP=-86.88dBm，SINR=-10dB，邻区里东莞霞边D-HLH-2（PCI=40）小区RSRP=-86.63dBm，该路段存在MOD3干扰。
VoLTE呼叫建立时延长案例分析
VOLTE呼叫建立时延长案例分析问题描述呼叫建立时延为VOLTE用户感知竞争力之一，经用户反馈使用VOLTE手机的呼叫建立时延有时较长，针对反馈的问题点进行实际测试，现个别呼叫建立时延在4s以上，影响用户感知，降低了用户满意度。
原因定位无线侧问题描述：正常呼叫建立时延在3s以内，针对用户反馈的问题，我们对网格进行VoLTE拉网测试，呼叫建立时延均在3.1s以上，最高时达3.5S：无线侧信令分析对多轮测试数据进行信令分段统计，筛选出INVITE REQUEST→180 RINGING信令段时间差大于5s的通话。
对超长时延通话的各个信令段占用时长进行统计，发现影响通话时长的主要信令段集中在100 trying->183段。
对超长时延的通话进行信令分析，均为主叫发送INVITE Request 到被叫收到INVITE Request时间长，在此段信令中进行深入分析，为被叫收到Paging 消息耗时长。
针对此情况在端到端信令分析平台上进行回溯分析，发现对被叫寻呼时，一次寻呼未成功，6s后再次寻呼，导致时延额外增加6秒，影响整体呼叫建立时延。
参数调整测试为减小呼叫建立时延，对一次寻呼成功率进行优化提升，因此在eNodeB侧进行最优参数组合优化，“开”寻呼信道干扰随机化开关、“降”寻呼码率、“增”寻呼下发次数，达到提升空口寻呼成功概率。
对测试网格主服务小区进行参数的修改优化，并对金湖网格进行复测，复测后网格的拉网测试呼叫建立时延由最高的3.5s降低到1.99s，大大降低了呼叫建立时延，提高了VOLTE用户感知。
问题原因：主叫发送INVITE Request到被叫收到INVITE Request时间较长，为被叫收到Paging消息耗时长，深入分析问题根因，为一次寻呼未成功，从而二次寻呼导致呼叫建立时延长，其次100 trying->183 这段信令的时延较长导致整体呼叫建立时延较长。
影响范围：全网解决方案通过eNodeB侧最优参数组合优化，“开”寻呼信道干扰随机化开关、“降”寻呼码率、“增”寻呼下发次数，达到提升空口寻呼成功概率，从而解决语音呼叫建立时延长问题。
VoLTE优化经验及案例
终端IMS注册问题
终端要完成在IMS的正常注册，前提必须要在LTE MME上 附着成功，即终端当前是在LTE网络上的。
终端未能在IMS注册成功时，终端屏幕上方的IMS图标通常 会显示为红色或出现一个叹号，此时无法做VoLTE语音业 务。
从无线角度可以从QCI=5承载建立不否不SIP注册流程上去 大致定位问题出现在哪部分，然后在联合相关网元迚行具 体排查。
率偏置。 5. 修改RS功率：确保满足预期的小区覆盖半径。
呼叫建立问题—eRAB承载问题
要实现VoLTE语音业务和视频业务需要建立以下承载组合： • 语音业务载组合：SRB1+SRB2+2xAM DRB+1xUM DRB，其中，UM DRB
的QCI=1，2个AM DRB的QCI分别为QCI=5和QCI=8/9。 • 音频业务承载组合：SRB1+SRB2+2xAM DRB+2xUM DRB，其中，2个UM
IMS呼叫建立时延
我司目标值 >99% <0.5% >99% >98% <2.6%
<200ms
<1% >3.8 <5% <5% <1% <1%
<3s
<2s
备注
被叫处于IDLE态下，主叫拨打被叫 被叫处于连接态，主叫拨打被叫
对亍接通率、掉话率、eSRVCC切换成功率等挃标，网优侧需要做好基础优化， 如覆盖、邻区（系统内/间、邻区参数、邻区完善等）、合理参数设置等这几 个方面的网优工作。
图一
图二
呼叫建立问题—eRAB承载问题
从基站侧看，源小区在切换时收到了ERAB Release Command消息，但由亍已经开始切换， 因此回的响应消息中显示为失败，原因是切换触发，见下图三：
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，属于端到端问题，需要集团规范协议流程。
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常见问题及优化策略
五、常见问题分析二 异系统重定向(1/2)
➢问题现象
终端在弱场区域，基站下发盲重定向的RRC Release消息，消息中包含重定向的2G 频点列表。
➢优化方法 1）可以通过调整天线方向角和下倾角、增加天线挂高、更换更高增益天线、 增强RS功率等方法来优化覆盖 2）对于相邻基站覆盖区不交叠部分内用户较多或者不交叠部分较大时，应新 建基站，或增加周边基站的覆盖范围，使两基站覆盖交叠深度加大 3）对于凹地、山坡背面等引起的弱覆盖区可用新增基站或RRU，以延伸覆盖 范围；对于电梯井、隧道、地下车库或地下室、高大建筑物内部的信号盲区可 以利用RRU、室内分布系统、泄漏电缆、定向天线等方案来解决
五、常见问题分析三 RSRP/SINR差（1/2）
➢问题现象 终端在弱场区域，RSRP/SINR过差，导致业务中断，原因多为RTP inactivity 导致RRC Release。 ➢分析方法 查看RRC Release之前的终端测量，确定终端是否处在RSRP/SINR过差区域。
五、常见问题分析三 RSRP/SINR差（2/2）
五、常见问题分析二 异系统重定向(2/2)
➢ 优化方法 1. LTE弱覆盖：优化LTE覆盖 2. 假性弱覆盖：优化切换、重选参数 3. 终端测量B2不及时：一是高通正在验证新的芯片，新芯片支持DRX休
眠期对异频异系统进行测量，缩短测量周期；二是通过删减无用的异 频频点，减少终端测量的频点数以达到缩短测量周期的目的 4. 2G邻区配置错误：做好eSRVCC的邻区精细化规划和周期一致性核查 5. 基站功能改进： 601P02版本可针对语音业务关闭重定向功能
广州中兴VoLTE优化案例
案例1：异频重定向掉话案例【问题描述】主叫占用广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）小区通话时，信号强度为-101dbm左右，出现一次RRC Connection Release，导致承载拆除，引起一次主叫掉话。
【问题分析】分析测试数据，发现UE占用服务小区广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）在通话的过程中信号越来越差，之后上报测量报告A2事件，eNODEB 收到报告后发起异频重定向判决，下发RRC Connection Release，由异频重定向后，eNodeB 向MME发送ue context release request，mme释放专用承载。
当UE被重定向后在新的小区发起RRC连接，网络只建立了默认承载，UE发送BYE消息，导致掉话。
从地理环境上看，服务小区与UE重定向目标小区相距较远，不需配邻区关系，UE在该路段仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。
【解决方案】关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。
【问题总结】根据拉网统计，目前该类掉话占总掉话次数的80%以上，对测试指标影响非常严重。
异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切换到邻区，基站会给UE下发系统内重定向。
优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大优化力度。
后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，禁止专用承载的业务发生异频重定向。
案例2：异系统重定向掉话案例【问题描述】VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。
而CCO对于VoLTE语音来说，必然导致掉话。
【问题分析】具体如下图所示。
1. 对于PSHO、CCO、重定向，优先级为PSHO>CCO>重定向。
经典案例-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案例分析报告
邻区漏配导致主叫掉话（漏配F-D）时间：2016-04-07主叫：被叫：【数据来源】**__移动_VOLTE主叫_网格1_鼎立ATU和HTCM8_0【问题现象】主叫11:10:56在,处发生掉话【问题分析】测试车辆在松福大道由北向南行驶，主叫11:07:36占用**沙井信维D-HLH-2发起呼叫，11:07:40通话建立。
主叫11:10:55发生掉话事件。
查看主被叫信令，从11:10:00开始，主叫占用**沙井展群F-HLH-2一直在上报切往**和山路D-HLH-2的A4事件，此时服务小区信号为RSRP=-106dBm，SINR=-16dB；无线环境恶劣导致RRC重建被拒，经后台查询**沙井展群F-HLH-2与**和山路D-HLH-2没有邻区关系。
主叫11:10:24占用**和山路D-HLH-2发生LTE Service Failure，随后主叫上报BYE，随后发生掉话。
【问题结论】邻区漏配导致主叫掉话【优化建议】1、添加**沙井展群F-HLH-2与**和山路D-HLH-2与的邻区关系邻区漏配导致主叫掉话（漏配F-F）测试时间：2016-04-09主叫号码：被叫号码：【数据来源】**__移动_VOLTE主叫_网格43_CDS和【问题现象】主叫20:27:58在,处发生掉话。
【问题分析】测试车辆在盐葵公路由东向西行驶，主叫20:25:57占用**盐葵梅沙D-HLH-1发起呼叫，RSRP=-93dBm，SINR=15dB，20:25:02通话开始建立。
测试车辆在盐葵公路行驶过程中，主叫20:27:49占用**下角湾F-HLH-1（RSRP=-118dBm，SINR=-12dB）期间连续弱覆盖，终端一直上报A3测量报告，目标小区为**大梅沙F-HLH-2，随后RRC重建被拒，经后台核查圳下角湾F-HLH-1与**大梅沙FHLH-2不存在邻区关系。
随后主叫发生掉话事件。
【问题结论】邻区漏配导致主叫掉话【优化建议】添加**下角湾F-HLH-1与**大梅沙F-HLH-2的邻区关系推动**云水间D-HLH **梅沙天琴半岛（微小M）建设邻区漏配导致主叫掉话(漏配D2-D2，已添加D1-D1)【问题现象】主叫在2016-04-10 18:09:40于发生主叫掉话【问题分析】测试车辆在航海路由东往西行驶过程中，主叫在18:09:40时分出现掉话事件，主叫在18:09:04时分开始起呼,在18:09:09时分通话建立，在18:09:10通话过程中主叫占用**兴海四D-HLH-103（RSRP=-112dBm,SINR=）多次上报A3事件切往**妈湾五D-HLH-102，由于漏配邻区，导致服务小区未切换到最优小区。