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的商用对网络覆盖、网络结构提出了更高的要求。
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未接通分析案例摘要：市区2.1G覆盖不连片导致的邻区干扰对VOLTE呼叫建立成功率和掉话影响较大关键字： VOLTE未接通 2.1G【故障现象】：汤王大道玉兰苑向北，16:36:45.596主叫起呼随后信令正常交互至prack200，在16:37:05.391发cancel取消通话，此时统计为主叫未接通。
主叫占用BZ-市区-建安中学-HFTA-439095-50（RSRP=-63,SINR=17.3）。
【原因分析】：volte呼叫信令说明如下：1．1到6，UE起呼，UE高层协议层需要发送INVITE到IMS，触发RRC连接、安全模式等过程，并通过RRC重配置消息建立SRB2信令无线承载、恢复QCI 5承载，配置测量控制，IMS收到主叫的INITE消息，开始寻呼，并发送INVITE 100（TRYING）给主叫UE，用于响应INVITE 消息，INVITE消息中包含呼叫类型、主被叫的号码、主叫方支持的媒体类型和编码等；2．7到15，核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户，被叫UE收到寻呼后，触发RRC连接、安全模式等过程，被叫通过RRC重配置消息建立SRB2信令无线承载，CN侧通过QCI=5的RB向被叫发送INVITE消息，UE收到后发送INVITE 100消息进行响应，同时被叫发送INVITE 183消息给CN表示会话正在处理，启动Precondition(资源预留)过程，并通知主叫自己所支持的媒体类型和编码，并建立起QCI=1的承载；3. 16到17，IMS收到被叫的INVITE 83 后，对主叫启动Precondition(资源预留)过程，通过EPC通知主叫SM层建立起QCI=1的承载后，向UE发送INVITE 183消息；4．18到25，主叫向被叫发送PRACK消息，PRACK过程是一个预确认过程，主要为了防止会话超时及拥塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，发送UPDATE消息，进行媒体格式协商过程，被叫通过UPDATE 200返回协商结果；5. 26到31是振铃接听过程，被叫发送INVITE 180给主叫，振铃，摘机后发送INVITE 200给主叫，主叫返回ACK进行确认，通话完全建立，进入通话过程；6. 32到37为挂机过程，通话结束后，主叫发送BYE请求结束本次会话，IMS服务器给被叫发送BYE,请求结束本次会话，被叫挂机，回BYE 200消息，核心网IMS服务器给主叫发BYE 200，标明会话结束，主被叫分别去激活EPS专用承载消息，删除QCI=1的数据无线承载。
Volte-4-VoLTE语音质量优化案例(14个)-图文
Volte-4-VoLTE语音质量优化案例（14个）-图文以下是为大家整理的Volte-4-VoLTe语音质量优化案例（14个）-图文的相关范文，本文关键词为Volte-4-VoLTe,语音,质量,优化,案例,14个,，您可以从右上方搜索框检索更多相关文章，如果您觉得有用，请继续关注我们并推荐给您的好友，您可以在教育文库中查看更多范文。
VoLTe语音质量优化1案例1：VoLTe窄带与宽带语音质量对比【问题现象】在3gppLTe中，VoLTe业务编码有AmR-nb窄带和AmR-wb宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTe 标清语音（或VoLTe12.2kbps）和VoLTe高清语音（或VoLTe23.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个点。
AmRnb的语音带宽范围：300－3400hz，8Khz采样。
AmRwb的语音带宽范围：50－7000hz，16Khz 采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AmRwb与AmRnb不同之处在于AmRwb按16khz采样，分别按频率带50~6400hz和6400~7000hz进行编码。
VoLTE外场测试分析案例
案例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 PreconditionFailure失败消息。
主叫收到网络侧下发的580，接续被中止，导致了会话未接通。
3、从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层nomal_release，导致专载QCI 1被释放。
4、专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。
【测试验证】案例2：Server Internal Error 500导致的未接通【问题描述】在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。
VOLTE寻呼拥塞分析优化案例
VOLTE寻呼拥塞分析优化案例一、案例背景VOLTE（Voice over LTE）是指通过LTE网络进行语音通信的技术，它提供了高质量的语音通话和丰富的通话功能。
然而，在实际网络运营中，由于网络拥塞等原因，VOLTE寻呼过程中可能浮现延迟或者失败的情况，影响用户的通话体验。
因此，我们需要进行VOLTE寻呼拥塞分析优化，以提高寻呼成功率和通话质量。
二、问题分析1. 寻呼拥塞原因分析：我们需要对VOLTE寻呼拥塞问题进行深入分析，找出导致寻呼失败或者延迟的具体原因。
可能的原因包括网络拥塞、信号覆盖不足、信道干扰等。
2. 寻呼成功率分析：对于寻呼成功的情况，我们需要分析成功率，并根据不同地区、时间段等因素进行对照分析，找出成功率较低的地区或者时间段，并进一步分析原因。
3. 通话质量分析：除了寻呼成功率外，我们还需要分析VOLTE通话质量，包括音质、时延、丢包率等指标。
通过对通话质量的分析，我们可以找出影响通话质量的因素，并进行优化。
三、数据采集与分析1. 数据采集：我们需要采集VOLTE寻呼过程中的相关数据，包括寻呼请求次数、寻呼成功次数、寻呼失败次数、寻呼延迟时间、通话质量指标等。
这些数据可以通过网络监测设备、基站设备、用户设备等进行采集。
2. 数据分析：采集到的数据需要进行详细的分析，包括寻呼成功率的计算、寻呼延迟时间的统计、通话质量指标的计算等。
通过对数据的分析，我们可以找出问题所在，并制定相应的优化方案。
四、优化方案1. 网络优化：针对网络拥塞问题，我们可以通过增加基站、优化网络参数、调整信道分配等手段来提高网络容量和覆盖范围，从而减少寻呼拥塞情况的发生。
2. 信号优化：对于信号覆盖不足的问题，我们可以通过增加基站或者调整天线方向来改善信号覆盖情况，提高寻呼成功率。
3. 干扰处理：针对信道干扰问题，我们可以通过频谱分析、干扰源定位等手段来找出干扰源，并采取相应的干扰消除措施，提高寻呼成功率和通话质量。
VOLTE接通率(500错误)优化分析案例
VOLTE接通率（500错误）优化分析案例一、问题现象某地市VOLTE接通率（信令）指标一直处于全省倒数，未达到99.5%考核值。
通过借助中兴信令平台分析发现，失败原因值主要为主要集中在500（占比39.11%）、504（占比34.47%）错误。
二、问题分析从失败反馈原因值500进行深入分析发现，500错误场景主要为VOLTE-CS与VOLTE-固话。
而两者问题以后者为主，如下表。
故从VOLTE-固话入手分析，而且失败固话号码基本全部为移动铁通固话。
通过中兴信令平台信令来看，携带原因值解码为R eason:Q.850;cause=4;text=”Send special information tone “,SIP;cause=500.根据此信息联系本地铁通关口局管理人员。
得知，目前IMS固定电话和VOLTE用户拨打铁通固定电话由移动关口局完成话务转接，因前期固话业务在话务转接中，对主叫号码属性有要求，故移动关口局上，对IMS号码拨打铁通号码做有主叫号码属性变换：后在拨打测试中发现，当VOLTE用户拨打铁通固定号码时，因关口局对主叫号码进行变换为“用户号码”，此时，关口局会将主叫号码进行删除前四位的处理（关口局指定用户号码本质是删除前四位0915区号），此时主叫号码只剩下后7位，继续接续到铁通后，由于主叫号码改变，铁通关口局无法识别主叫号码，便会将此呼叫过程拒绝，在拒绝的返回原因中未指定具体原因值，此拒绝信令通过关口局透传至主叫侧，由于整个拒绝信令中都未指定拒绝原因值，VOLTE核心网变将此类失败统一归纳为：“失败值500：server fault ”。
发现此问题后，9月27日17点通过在关口局对指定主叫号码格式的参数进行修改，对主叫号码格式不再进行指定：再次进行业务测试，主叫号码位长正常，铁通关口局正常完成接续过程，VOLTE接通正常。
三、问题总结验证抽取9月27日前三天VOLTE接通失败数据与9月27日17点后数据进行对比，发现500错误中VOLTE-固话基本全部消失。
VoLTE外场测试分析案例
案例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 Failure失败消息。
主叫收到网络侧下发的580，接续被中止，导致了会话未接通。
3、从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层nomal_release，导致专载QCI 1被释放。
4、专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。
【测试验证】案例2：Server Internal Error 500导致的未接通【问题描述】在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。
5.VoLTE案例分析
测试软件问题：呼叫过程中主叫再次起呼与被叫振铃不接听
1. 呼叫过程中再次起呼案例
现象：上次呼叫满3分钟后，主叫终端未上发挂断， 间隔30秒后，主叫按照呼叫规则又上发了起呼。 软件：惠杰朗CDS 分析：满3分钟，终端不挂断；怀疑软件触发的挂断 AT指令未能正常发到主叫终端，导致30秒后主叫在 通话中再次起呼，被计为掉话。
注：确实发现了满3分钟挂断，但RTP包单通的情况，将认为网络问题不予剔除。
几类人工剔除异常介绍
统计规则问题：VOLTE起呼失败触发CSFB且未接通
现象：1次VOLTE呼叫后，发生sip 500错误，2秒触发CSFB再起呼，但该次CSFB起呼也未接通。 规则：集团统计认为，该现象实际是1次用户按键行为触发了2次信令起呼，对客户感知来讲是1次失败，而 非两次失败，当前认定前1次VOLTE失败计入未接通统计，而CSFB不计失败 分析：实际该次触发的CSFB确实未接通，但是遵循集团VOLTE统计规则，暂时不列入未接通统计。
几类人工剔除异常介绍
测试终端问题：主叫CSFB回落位置更新不起呼与丢信令
1. 主叫CSFB回落位置更新不起呼
2. 丢信令
现象：主叫CSFB上发ESR，触发盲重定向回落GSM 并进行了回落位置更新，位置更新请求不带起呼标识， 且位置更新后不做起呼 。 终端：HTC M8 分析：主叫CSFB起呼时，ESR消息实际已触发了终 端后续行为在回落GSM后必然进行CM起呼，在信令 侧首先看到CM起呼后，再做RR信道请求。
主叫CSFB呼叫回落后位置更新不带起呼标识
主叫侧发起ESR后回落位置更新均应带follow 端偶尔为0
on=1，但VOLTE终
SIM卡欠费或误开机
欠费导致的业务无法进行，或非测试区域的误开机
VOLTE案例
3
大话务场景下频繁发生未接通
广东公司9月份案例
问题描述：大话务场景下，出现较多的未接通事件。通过分析Log发现，主叫向网络 侧发了invite请求，但没有收到网络侧下发的100 trying消息，之后终端直接上报 CANCEL，导致未接通。 问题分析： 1、主叫起呼后发起RRC连接请求，但是RRC连接失败，层3信令显示RRC被拒。之后一 直发RRC连接请求，RRC连接依然被拒。最后RRC连接释放掉了，释放原因other。 2、由于话务量高，RRC接入成功率只有51.577%，判断是基站侧的问题影响RRC接入。
问题解决：通过指令“MOD CELLUEMEASCONTROLCFG”，将小区异频异系统测量对象最大值将修 改为12后，基站除下发LTE异频和TDS异系统测量频点外，还可下发2G频点，成功实现eSRVCC。
6
典型案例介绍（3）
TAU与QCI1建立冲突导致未接通
北京公司10月份案例
问题现象：主叫发生X2切换，收到携带QCI1建立消息的RRC重配置消息后，没有立即回激活QCI1 的上行直传消息给MME，而是先发送了TAU消息，导致在eNB和MME侧QCI1承载建立状态不 同， MME认为QCI1没有建立成功，导致未接通。 问题分析： 1、主叫X2切换成功后，收到QCI1建立消息，并且 答复了RRC重建完成。终端首先发送TAU Request的 上行直传消息，显示有3个EPS承载，随后再发送 包含QCI1承载建立完成的上行直传消息。 2、eNB收到RRC连接重配置完成消息，并且发送 ERAB Response消息给MME，终端和eNB都认为 QCI1承载已经建立。 3、MME没有收到终端发的激活QCI1承载接收的上 行直传消息，认为QCI1没有建立成功，回复的TAU Accept中只包含2个EPS承载。 4、 TAU成功后，MME收到UE发送的QCI1激活消 息，在create bearer response里回复成功。由于 eNB已经存在QCI1承载，答复失败，原因： Multiple-E-RAB-ID-instances，产生未接通。 问题解决：需要在规范中明确，UE发送QCI1建立的RRC重配置消息后，先发送激活QCI1的上行直传 消息给MME，再发送TAU request 。
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案例分析报告
漏配邻区的各种情况邻区漏配导致主叫掉话（漏配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不存在邻区关系。
随后主叫发生掉话事件。
案例-VOLTE未接通分析案例
VOLTE未接通分析案例摘要：市区2.1G覆盖不连片导致的邻区干扰对VOLTE呼叫建立成功率和掉话影响较大关键字： VOLTE未接通 2.1G【故障现象】：汤王大道玉兰苑向北， 16:36:45.596主叫起呼随后信令正常交互至prack200，在16:37:05.391发cancel取消通话，此时统计为主叫未接通。
主叫占用BZ-市区-建安中学-HFTA-439095-50（RSRP=-63,SINR=17.3）。
【原因分析】：volte呼叫信令说明如下：1．1到6，UE起呼，UE高层协议层需要发送INVITE到IMS，触发RRC连接、安全模式等过程，并通过RRC重配置消息建立SRB2信令无线承载、恢复QCI 5承载，配置测量控制，IMS收到主叫的INITE消息，开始寻呼，并发送INVITE 100（TRYING）给主叫UE，用于响应INVITE 消息，INVITE消息中包含呼叫类型、主被叫的号码、主叫方支持的媒体类型和编码等；2．7到15，核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户，被叫UE收到寻呼后，触发RRC连接、安全模式等过程，被叫通过RRC重配置消息建立SRB2信令无线承载，CN侧通过QCI=5的RB向被叫发送INVITE消息，UE收到后发送INVITE 100消息进行响应，同时被叫发送INVITE 183消息给CN表示会话正在处理，启动Precondition(资源预留)过程，并通知主叫自己所支持的媒体类型和编码，并建立起QCI=1的承载；3. 16到17，IMS收到被叫的INVITE 83 后，对主叫启动Precondition(资源预留)过程，通过EPC通知主叫SM层建立起QCI=1的承载后，向UE发送INVITE 183消息；4．18到25，主叫向被叫发送PRACK消息，PRACK过程是一个预确认过程，主要为了防止会话超时及拥塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，发送UPDATE消息，进行媒体格式协商过程，被叫通过UPDATE 200返回协商结果；5. 26到31是振铃接听过程，被叫发送INVITE 180给主叫，振铃，摘机后发送INVITE 200给主叫，主叫返回ACK进行确认，通话完全建立，进入通话过程；6. 32到37为挂机过程，通话结束后，主叫发送BYE请求结束本次会话，IMS服务器给被叫发送BYE,请求结束本次会话，被叫挂机，回BYE 200消息，核心网IMS服务器给主叫发BYE 200，标明会话结束，主被叫分别去激活EPS专用承载消息，删除QCI=1的数据无线承载。
- 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。