VOLTE案例分析
(4G学习)中兴VoLTE优化案例5篇经验分享
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在该路段仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。
【解决方案】关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。
【问题总结】根据拉网统计，目前该类掉话占总掉话次数的82%以上，对测试指标影响非常严重。
异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切换到邻区，基站会给UE下发系统内重定向。
优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大优化力度。
后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，禁止专用承载的业务发生异频重定向。
案例2：异系统重定向掉话案例【问题描述】VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。
而CCO对于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，属于端到端问题，需要集团规范协议流程。
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终呼未接通分析案例分析
终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。
终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。
被叫上发的183里不携带SDP信息，正常的是会携带Session Description Protocol 信息的，导致SBC不发起承载建立。
主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。
1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMedia Attribute (a): curr:qos local sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local sendrecv| | Media Attribute (a): curr:qos remote none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote none| | Media Attribute (a): des:qos mandatory local sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv | | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 但在终端返回的183和update 200ok消息中，终端没有完成承载预留Media Attribute (a): curr:qos local none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local none| | Media Attribute (a): curr:qos remote sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote sendrecv| | Media Attribute (a): des:qos mandatory local sendrecv| | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv| | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。
VoLTE语音质量优化案例(14个)
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPP LTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE 12.2kbps）和VoLTE 高清语音（或VoLTE 23.85kbps）。
【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。
●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。
AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。
可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMR NB的语音带宽范围：300－3400Hz，8KHz采样。
AMR WB的语音带宽范围：50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMR WB与AMR NB不同之处在于AMR WB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz 进行编码。
用来降低复杂度，AMR WB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms 的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs 速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。
VoLTE评估测试典型案例分析
VoLTE评估测试典型案例分析【案例分类】VoLTE【案例摘要】结合VoLTE网络城区测试评估工作，对测试中的异常事件进行分析，总结VoLTE优化分析经验。
1、切换与承载建立流程冲突问题导致掉话问题描述：UE在行驶至此路段占用二中分校-432486_51小区在被叫上发sip183之后，在激活EPS承载之前，终端上报一条MR，满足A3，触发同频切换，在目标小区成功接入后很快发生掉话。
问题分析：起呼时MME进行激活EPS承载流程过程中，恰好发生切换时，由于EPS承载建立未完成，MME在切换准备阶段，对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载，导致VOLTE专载源小区完成的情况下，在目标小区下发的rrc ConnectionReconfiguration消息中的radioResourceConfig Dedicated中释放了DRB-Identity = 6，切换完成后呼叫中断。
结论建议：切换与EPS激活流程碰撞，为无线网与核心网配合问题。
在进行激活EPS专载过程中，发生切换时，均会造成上述问题，需要和核心网确认目前是否有解决方案。
2、弱覆盖导致掉话问题描述：终端RSRP持续低于-120dbm左右，SINR在-7左右,主被叫UE均发生切换失败，单通，最终掉话。
问题分析：主被叫问题一直为弱覆盖，终端RSRP持续低于-120dbm左右，SINR在-7左右，切换失败后的TAU无法成功建立RRC 连接，此时段RTP包不能正常发送，上下行丢包严重（丢包率60%以上），出现单通，10s后RTP Inactivity定时器超时，会话终端，产生掉话。
结论建议：附近已有建设任务站点，开通后可解决弱覆盖问题。
3、弱覆盖导致未接通问题描述：本通话过程中，主叫占用HF-市区-太阳湾9号楼-HFTA-430739-51无线环境良好（RSRP=-92,SINR=9）,被叫占用HF-市区-金色池塘-HFTA-905606-54无线环境较差（RSRP=-100,SINR=-7）,呼叫发起6s左右释放，造成未接通。
VOLTE接通率优化思路及案例
VOLTE接通率优化思路及案例随着移动通信技术的快速发展，人们对通话质量的要求也越来越高。
VOLTE（Voice over LTE）作为一种高质量的语音通信技术，具有更高的音质、更快的连接速度和更低的延迟，逐渐取代了传统的2G和3G语音通信方式。
然而，由于各种原因，VOLTE接通率可能会受到一些干扰，影响通话质量。
因此，提高VOLTE接通率成为了运营商和设备厂商共同面临的一个重要问题。
下面将介绍一些优化VOLTE接通率的思路和案例：1.信号覆盖优化：VOLTE需要在LTE网络下进行语音通信，因此优化LTE网络的覆盖范围和信号强度可以提高VOLTE接通率。
对于信号覆盖不好的区域，可以增设更多的LTE基站或放置室内LTE小站，以消除信号死角和盲区。
案例：城市的一些居民小区信号覆盖很差，导致VOLTE接通率低。
该地区的运营商决定在小区内增设室内LTE小站，通过强化信号覆盖，提高VOLTE接通率。
经过实施后，VOLTE接通率显著提高，用户体验得到了极大改善。
2. QoS优化：VOLTE语音通话对QoS（Quality of Service）要求较高，需要保证较低的延迟和较高的网络带宽。
因此，通过对网络中的资源进行调度和优化，可以提高VOLTE接通率。
例如，对于VOLTE通话流量进行优先级调度，确保其能够优先获得网络资源。
案例：国家的一个运营商发现，其LTE网络中VOLTE语音通话的延迟较高，导致VOLTE接通率较低。
通过对网络的QoS策略进行优化，提高了VOLTE语音通话的优先级，将相关资源分配给VOLTE通话，从而提高了接通率。
案例：运营商发现其IMS网络存在一些性能问题，导致VOLTE接通率较低。
运营商对IMS网络进行优化，增加了IMS服务器的数量，改进了通信协议，优化了网络参数等。
通过这些改进措施，VOLTE接通率得到了明显提高。
4.终端设备优化：VOLTE通话不仅依赖于网络的性能，还与终端设备的质量和性能密切相关。
经典案例-VoLTE与数据网络分层切换策略研究案例
VOLTE与数据网络分层切换策略研究案例1•问题现象1.1 VOLTE语音面临问题VOLTE语音业务和数据业务的QoS和用户感知存在差异，VOLTE对于时延、抖动更敏感，对于切换、掉话更敏感。
4G无线网络在RSRP达到-12OdBm时，就能够为用户提供较好的数据业务体验, 但是基本的高淸语音业务通话就要求信号电平至少要达到-115dBm,数据业务和语音业务对覆盖电平的要求差距将近5dB° VOLTE的商用对网络覆盖、网络结构提出了更高的要求。
现有4G网络在室外道路基本能够实现髙淸语音的连续覆盖，但是在室外盲点和室内弱覆盖场景，高淸语音还很难保障。
¾dB√-115dBm÷,-12OdBrTv1.2 VOLTE语音质量要求就业务体验中较为敏感的语音质量而言，业界普遍认为MoS达到3. 5分才能体现“高淸”业务优势，以应对体验竞争。
根据路测数据统汁,业务感知对RF条件的要求为:满足MOS大于3. 5分时,RSRP要求大于-IlOdBnbSiNR要求大于-2dB.详细的数据拟合曲线如下图:2•问题分析在实际电信多频组网中,800M网络RSRP性能远优于1.8G,2.1G; 室外盲点和室内弱覆盖场景均靠800M网络深度覆盖,在VOLTE商用后, 800M网络优良是保障VOLTE语音性能的关键。
2.1现阶段问题南充现网VOLTE初期下发多频组网策略后，VoLTE路测中，800M占比较少，以南充嘉陵为例，800M 占比大约20%,平均RSRP-76. 86dBm; VOLTE用户未能完全承载在800M网络上：室外1. 8G∕2. IG混合业务未能有效分层，针对数据和语音的性能增益参数无法同时实施，不能达到双向均升。
2.2现网多频组网策略分析现网VOLTE与数据业务均使用基于覆盖特性切换，语音与数据未能完全分层，现网策略如下：3•问题处理3. 1 方案思路VoLTE的商用对网络覆盖、网络结构提出了更高的要求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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拉网信号强度、经纬度、服务小区等信息导出。
通过经纬将4G弱信号(RSRP<-110dbm)与2G强信号（RXLOV>-95dbm）在50米范围内拟合，根据拟合度对2G邻区进行补漏工作。
剔除现网已配置的邻区关系，补漏邻区关系对后，eSRVCC切换提升明显，且由于2G邻区不准确导致的异系统重定向大大减少。
1.6 重定向掉话XX区域掉话最严重属于重定向掉话，在XX基站算法中，以下三种可能发生重定向，重定向释放RRC 后，专载同时被拆除，VoLTE业务产生掉话。
1.7 上行PUSCH功控参数优化背景：xx区域拉网测试发现上行PUSCH发射功率偏高，对现网参数检查发现，xx区域上行期望功率值设置过高。
优化措施：进行功控相关参数优化，现网配置：p0NominalPUSCH =-75 ；puschPCAdjType=0优化值：p0NominalPUSCH =-87 ；puschPCAdjType=2●同等路损情况下，参数修改后，ue发射功率大约下降2~3dB。
●目前终端平均上行发射功率仍高于10db，仍需完善现有功控方式。
修改后，PUSCH TxPower（10dbm以上）占比由40%下降到30%左右。
1.8 RTP丢包率优化背景：测试发现，XX区域RTP丢包率偏高，个别网格甚至达到2%以上。
原因分析：在无线质量较好的情况下基本无丢包；无线质量较差的情况下上行丢包现象较为严重，PDCP 重传时间超时，数据包将被丢弃；外场测试表明QCI 1 PDCP Discardtimer 配置与RTP丢包率及Jitter有密切关系，QCI 1 PDCP Discardtimer 配置越大，RTP丢包率越低，但Jitter也随之变大。
●MOS值与RTP丢包及Jitter关系都较大，目前正在进行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的对比验证。
1.9 MME专载保存功能（可选）功能描述：在基站发起UE-lost原因值的上下文释放请求时，MME保持专载2s不释放，等待空口重建。
验证情况：已在某MME下成功验证了该功能。
当时无线环境较差，UE发起RRC重建失败，通过MME专载QCI1保持功能使得在新发起的业务过程中，RRC重配中建立包括专载QCI1的3条DRB，不会发生掉话。
（本次测试中专载保持时长约1.358s）功能总结：1）当无线环境较差时，UE发生RRC重建，若RRC重建成功，手机将不会掉话。
2）MME侧也可以在RRC重建失败后，通过MME专载QCI1保持功能使得在新发起的业务过程中，专载QCI1继续保持，也可使得手机不掉话。
3）此功能为爱立信MME非必选功能，建议打开。
但是该功能不在集采目录，暂时无法采购。
1.10 专载释放与切换冲突，通话结束未收到专载释放掉话[问题描述]：在拉网测试过程中，通话挂机后，主叫上报BYE消息，IMS回BYE200消息前后，同时手机发生切换，未收到EPS专载释放请求，1s后软件统计掉话。
[问题分析]：经分析MME log，发现MME未收到PGW下发的delete bearer request消息。
当X2切换触发SGW-initiated bearer modification procedure（完整信令是CCR-CCA），如果此时SIP挂机触发PCRF 也发RAR给PGW，由于Gx链路时延等原因，使得RAR先于CCA到达PGW，根据协议规定，PGW会继续SGW-initiated bearer modification procedure而reject RAR (result codeDIAMETER_OUT_OF_SPACE)。
[优化措施]：当前解决办法：（1）缩短DRA时延配置。
（2）修改SAPC到DRA链路为主-备模式，保证CCA和RAR走同一路径和到达PGW的先后顺序。
[优化结果]：近期调整后的网格测试，暂时没有发现BYE200消息前后发生的切换没释放QCI 1专载的情况。
1.11 通话结束MME收到del bearer req，专载释放与切换冲突，基站未下发NAS[问题描述]：通话挂机后，主叫上报BYE消息，IMS回BYE200消息前后，同时手机发生切换，EPS专载没有释放，1s后软件统计掉话。
[问题分析]：主叫挂机后，MME收到del bearer req，下发Deactivate EPS bearer context Request给源eNB携带NAS释放专载，但同时源eNB触发X2切换，向MME响应ERAB release response （X2-Handover-Triggered），NAS消息未下发到手机。
根据协议36.413 中8.6.2.4有描述当eNB在触发X2切换时，eNB将不传递NAS消息。
[优化措施]：属测试软件统计问题，建议软件加以剔除该问题。
2 案例分析2.1 典型案例案例1：LTE弱覆盖，eSRVCC切换不及时掉话10:57:29.710基站下发异频异系统测量报告，包含2G频点及B2门限（LTE:-110，GERAN:-95）10:57:38.479，主叫达到B2门限10:57:42.109，主叫RSRP已恶化至-117dBm，SINR至-3，但终端仍没有上报B2事件10:58:05.587，RTP包不能正常收发，10s后RTP inactivity定时器触发，会话中断，出现掉话：解决建议：①规范LTE频点配置，清理多余异频频点，缩短终端测量周期；②终端芯片提高测量能力，尽快实现CDRX休眠期测量功能。
案例2：VoLTE单通现象VoLTE单通现象分为两类：一是VoLTE打VoLTE单通，二是VoLTE拨打GSM单通。
经分析，第一类主要是终端问题，第二类主要是网络问题。
注：红圈为RTP包抓包位置案例3：eNodeB参数配置不合理，导致eSRVCC失败问题现象：终端发生eSRVCC时，在LTE向GSM切换过程中产生掉话。
问题分析：终端可以正常收到测控消息，并上报测量报告，且掉话发生在向GSM切换过程中，是GSM或者和基站侧参数设置问题。
问题解决：基站BsCAccess-ID项中的管理状态为Locked，设置有误。
将该状态修改为Unlock后，对该站点进行重启后发现eSRVCC功能正常。
2.2 空口信令判断案例案例1：RRC重建失败，无线网问题现象：切换失败导致RRC释放，重建RRC未成功，重新进行RRC申请，QCI=1的承载未建立成功，导致掉话分析：呼叫重建失败后，新小区重新申请RRC，未能建立VOLTE专载，导致掉话。
该流程均由ENODEB 控制执行。
而切换失败的原因往往是无线环境问题、参数配置不合理、邻区漏配、非竞争随机接入异常等，均为无线网问题。
结论：切换失败与RRC重申请流程均与EUTRAN相关，因此认定为无线网问题。
案例2：基站异常导致双端无下行信令及RTP包断传，无线网问题现象：主被叫VOLTE接通后，在同一小区同时发生缺失下行信令20秒，此后数秒发生终端上发bye request挂断。
分析：丢信令之前，主被叫双端处于同一小区，且RTP包双向传输正常。
丢信令期间，终端测量信息完整，但在2秒后发生RTP包只有终端向网络单向传输，未再有任何网络下发的RTP包，高度怀疑基站临时故障导致。
结论：软件显示丢信令，但通过进一步分析确认应为基站故障导致。
无线网问题。
案例3：VOLTE接通下发生IMS注册掉话，IMS网络问题现象：VOLTE接通后，被叫发生IMS注册且成功，此时主叫收到网络下发的bye request内含注册超时字样分析：按照3GPP协议，终端应在3000秒上发注册，本次华为SBC于3600秒才收到注册请求，此时IMS认为注册超时，对主叫下发了sip bye消息释放了。
但通过进一步确认，终端实际于600秒前已上发了注册消息（UDP），但此时恰好在G网下，未收到回复：注：同样类型的掉话也有600秒前处于LTE网（TCP），而未收到OK或未鉴权回复的情况结论：前10分钟的注册失败，导致了后续的IMS通话中释放，虽然终端前一次的失败处理机制可能存在问题，但仍然体现出IMS对通话中发生注册时直接释放会话的措施欠妥。
2.3 网元流程判断案例案例1：被叫收到寻呼但未收到INVITE请求，核心网问题现象：主叫上发了invite，被叫收到了寻呼且建立RRC成功，此时应收到下行的invite，但始终未收到。
分析：被叫响应寻呼并进行了RRC申请，表明MME已收到由SGW触发的数据业务请求，即sip invite消息应由IMS网元的SBC下发给了PGW、SGW。