(重点)VOLTE掉话分析
精品案例_VoLTE异常掉话分析
VoLTE异常掉话分析目录一、问题描述 (3)二、分析过程 (4)三、解决措施 (6)四、经验总结 (6)VoLTE异常掉话分析【摘要】VoLTE语音掉话是指在UE在与eNB间成功建立eRAB（QCI1）之后，由于异常原因导致的eRAB（QCI1）释放，原因通常包括RRC重配置（包括语音挂机触发）失败；终端RRC重建失败；UE LOST检测打开后终端重同步失败等。
本文通过对池州RCU路测中的掉话事件进行分析，发现DRB异常释放导致掉话。
【关键字】VoLTE掉话、DRB释放【业务类别】参数优化一、问题描述2019年7月18日，池州RCU 1200设备在市区和谐路与平湖路交口约100M处发生一次掉话，掉话位置如下图所示。
图1.掉话区域位置图二、分析过程VoLTE语音掉话问题的定位和普通数据业务掉话问题的定位步骤类似，主要有以下几个原因：1、覆盖类：越区覆盖、重叠覆盖、弱覆盖等导致掉话。
2、切换导致的掉话：过早切换、过晚切换及乒乓切换等导致掉话。
3、干扰引起的掉话：通常干扰分为上行干扰及下行干扰，系统内干扰及外来干扰。
不论哪种类型的干扰都会导致掉话。
4、流程交互失败：VoLTE相比普通业务需要建立QCI1的专有承载，当切换和QCI1专有承载修改/建立/删除冲突时，可能导致QCI1对应的NAS流程失败，导致掉话。
5、异常分析：传输问题（S1、X2口复位、闪断等）、eNB故障（单板复位、射频通道故障等）、UE故障等（UE死机、发热等）。
通过网管查询周边GC-市区-平天湖假日酒店-ZFTA-447481、GC-市区-贵池消防大队-ZFTA-447489、GC-市区-池州科苑-ZFTA-447903等基站均工作正常无告警。
分析掉话处RSRP及SINR值，如图2所示，可以看出此处占用GC-市区-平天湖假日酒店-ZFTA-447481-54信号，RSRP值约-75.19dBM,SINR约19.2dB，信号质量良好。
VOLTE端到端掉话分析指导
VOLTE端到端掉话分析指导端到端掉话是指通话过程中，双方用户在语音通话过程中突然失去声音或嘈杂的背景声音，导致通话无法继续进行。
在进行VOLTE（Voiceover Long Term Evolution）时，如果出现端到端掉话问题，需要进行分析和解决。
1.确定掉话现象2.收集掉话问题的证据在用户报告掉话问题后，需要收集相关的证据以进行分析。
可以收集以下内容：-掉话的具体时间和地点-掉话前后的通话质量和信号强度-接入网关或基站的状态信息-网络负载和流量数据3.检查网络和设备接下来，需要检查网络和设备的问题。
可以执行以下操作：-检查网络连接是否正常，例如查看是否有网络故障或网络拥塞的现象。
-检查设备是否有软件更新或升级，确保设备处于最新的运行状态。
-检查设备的电池是否充足，如果电池电量不足可能会影响通话质量。
4.分析通话质量报告VOLTE通话质量报告会记录通话过程中的相关数据，如接收信号强度指示（RSSI）、信噪比（SNR）、块错误率（BLER）等。
分析这些报告可以帮助找到问题的原因。
如果在特定时间段内出现了信号强度下降、信号干扰或其他异常现象，可能会对通话质量产生影响。
5.进行网络路径分析网络路径分析可以帮助确定通话过程中数据传输的路径，并找出可能的问题。
可以通过以下方式进行网络路径分析：- 使用ping命令测试网络连通性，了解数据包在网络中的传输情况。
-分析数据包进出的路由情况，检查是否存在延迟或丢包的现象。
-检查语音流量是否经过负载均衡设备，负载均衡设备的故障可能会导致掉话问题。
6.调查核心网和IMS网络- 网络设备或服务器故障，如SBC（Session Border Controller）或BGCF（Breakout Gateway Control Function）的故障。
-网络节点配置错误，如路由配置错误或信道配置错误。
总结：。
VOLTE掉话分析
VOLTE掉话分析VOLTE（Voice Over LTE）是一种在4G LTE网络上实现高质量语音通话的技术。
它比传统的2G和3G网络更高效和先进，但在实际应用过程中，仍有可能出现掉话的情况。
下面将分析VOLTE掉话的可能原因和解决方法。
首先，VOLTE掉话的原因可能和网络覆盖有关。
4GLTE网络有时在一些较为偏远的地区信号覆盖可能不稳定，或者室内覆盖不足，这都可能导致VOLTE掉话。
解决这一问题的方法可以是增加基站的覆盖范围或增加室内信号增强器等设备。
其次，VOLTE掉话的原因还可能和设备功率管理有关。
在信号弱的地方，手机可能会增大功率以保持通信连接，这可能会导致电量消耗过快，进而导致掉话。
此外，设备的软件或硬件故障也可能导致VOLTE掉话。
解决这一问题的方法可以是优化设备的功率管理算法，确保设备正常运行，并及时修复软硬件故障。
再次，VOLTE掉话的原因还可能和网络负载有关。
在高峰时段或网络拥堵的情况下，网络负载增加可能导致语音通话的质量下降，包括掉话。
解决这一问题的方法可以是提升网络的容量，增加带宽等。
此外，VOLTE掉话还可能和网络的QoS（Quality of Service）设置有关。
QoS的设置可以对不同类型的数据流分配不同的优先级，如果语音通话的优先级设置不当，可能导致VOLTE掉话。
解决这一问题的方法可以是合理设置QoS，确保语音通话的优先级高于其他数据流。
最后，VOLTE掉话的原因还可能和网络的连接稳定性有关。
网络的连接不稳定可能导致通话中断，从而出现掉话情况。
解决这一问题的方法可以是优化网络的传输协议，提高连接的稳定性。
总的来说，VOLTE掉话的原因可能涉及网络覆盖、设备功率管理、网络负载、QoS设置和连接稳定性等多个方面。
要解决这一问题，需要优化网络、设备和软件配置，并加强对网络质量的监控和维护。
只有在确保网络稳定和通信质量高的情况下，才能实现高质量的VOLTE通话体验。
Volte故障分析手册
Volte故障分析手册1. 前言随着通信技术的不断发展，Voice over LTE (VoLTE)已成为现代通信中普遍采用的标准。
然而，由于复杂的网络结构和通信设备的多样性，VoLTE服务在一些情况下可能会遇到故障。
本文将介绍一些常见的VoLTE故障及其分析方法，以帮助读者更好地解决和排查故障。
2. 故障一：通话质量差2.1 故障描述在VoLTE通话过程中，用户可能会遇到通话质量差的问题，如杂音、断续和声音不清晰等。
2.2 分析方法a) 检查网络信号强度：VoLTE通话对网络信号强度要求较高，低信号强度可能导致通话质量差。
使用信号测试工具检查信号强度并与基准值进行比较。
b) 检查网络负载：高网络负载可能会降低VoLTE通话质量。
使用网络分析工具检查网络负载情况，确保网络资源足够用于VoLTE通话。
c) 检查设备兼容性：某些设备可能不兼容VoLTE技术，导致通话质量下降。
确保设备支持VoLTE功能并进行升级或更换。
d) 检查网络配置：网络配置错误可能导致VoLTE通话质量差。
检查各个网络节点的配置是否正确，并进行必要的修改。
3. 故障二：呼叫无法接通3.1 故障描述用户在进行VoLTE呼叫时，可能会遇到呼叫无法接通的问题。
无法接通的呼叫可能包括呼叫失败、长时间等待或无法连接对方等。
3.2 分析方法a) 检查设备设置：确保用户设备的呼叫设置正确，如是否开启飞行模式、是否设置了呼叫转移等。
b) 检查呼叫号码：检查呼叫的号码是否正确，可能是输入错误导致无法接通呼叫。
c) 检查网络状态：当网络状态不稳定或网络连接中断时，呼叫可能无法接通。
使用网络分析工具检查网络状态，并进行必要的修复。
d) 检查网络中断：网络中断可能是导致呼叫无法接通的原因之一。
检查网络设备和线路是否正常工作，确保网络连接畅通。
e) 检查呼叫服务器状态：呼叫服务器故障可能导致呼叫无法接通。
检查呼叫服务器的状态，并与运营商联系以修复问题。
VOLTE掉话分析
TOP筛选条件◆当日掉话次数大于3次为TOP小区◆一周内出现3次TOP小区为高掉话TOP小区TOP分析方法手段掉话问题掉话原因分析➢按照掉话分子，按原因值提取相关计数器进行分析；➢检查站点是否存在邻区漏配或者配置不合理，导致无法及时切换出而吊死，引发掉线；➢小区存在异频邻区时，需要核查异频切换类相关A2、A3配置门限是否合理；➢检查小区是否存在超远覆盖，导致覆盖孤岛，无法及时切换到周边基站，可通过后台信令跟踪，观察测量报告，补齐漏配的邻区，随后及时对覆盖进行控制；➢对于弱覆盖引起的掉线，若终端处于覆盖边缘，周围无可用LTE小区，可以合理添加异系统邻区，合理配置重定门限，及时重定向到异系统，减少掉线。
➢关注小区无线环境，分析是否NI过高；➢关注影响业务的故障类告警；掉话Context归类如下：●ENB由于S1链路故障发起释放分为三类◆Context释放，Gtpu ErrInd触发释放：主要是核心网参数问题，部分原因是TAC边界不和导致，可以优化TAC边界◆Context释放，Path故障触发释放：传输故障导致，需核查传输◆Context释放，光口故障触发释放：光口、S1链路故障等原因，推维护处理●Context释放，ENB切换失败引发释放：检查切换参数、功率参数、定时器设置；●Context释放，由于小区关断或复位引发释放：检查掉线对应时间段内基站小区故障类告警●Context释放，ENB由于其他原因引发释放：容量等其他问题；●Context释放，ENB重建立失败导致释放：检查小区NI是否过高，RS功率设置是否偏小，检查现场无线环境，开启X2口进行优化（重建立如果在目标基站没有上下文，重建肯定失败）；●ENB空口失败引发释放次数分四类◆ERAB释放，空口定时器超时：检查CPU负荷，同时在线用户数是否偏高，如是可增加SR信道配置容量进行优化，排除MR开启时间段内计时器增多，提故障交研发处理；◆ERAB释放，空口质量差触发RLF：检查无线环境是否存在弱覆盖、模三干扰、越区覆盖、底噪偏高、基站存在故障；◆ERAB释放和RLC达到最大重传次数：检查RLC参数设置，排除MR开启时间段内计时器增多，提故障交研发处理；◆ERAB释放，PDCP完整性保护失败：检查加密完保参数设置，排除MR开启时间段内计时器增多，提故障交研发处理；Context整理情况如下：切换问题：切换分为切换准备阶段和切换执行阶段切换准备阶段多由外部邻区参数配置错误（邻区配置正确）或者切换准备目标基站故障引起。
VOLTE掉话率及接入时延分析0513
QZ VOLTE掉话率及接入时延短板分析一、VOLTE掉话率分析1、VOLTE掉话率概述通过提取GN平台掉话率专题分析统计了近7天全省VOLTE掉话率,情况如下:VOLTE掉话率=VOLTE掉话总次数/VOLTE应答总次数。
从指标情况看,衢州掉话率为0.29%排名第十,与省平均掉话率差距0.14%,与省内最优地市掉话率差距0.24%，相比其他地市VOLTE应答总次数基数较小，且掉话总次数偏高。
VOLTE 应答总次数基数大的地市掉话率整体较低。
2、VOLTE掉话分析1）GN平台提取VOLTE掉话原因分布如下：1、1 TX2 RELOCOverall E xpiry；分析部分小区为无线环境差导致在ESRVCC过程中X2定时器超时，导致上下文释放携带此错误代码，现通过提升B2门限与增加功率来解决此类问题，还有部分疑难小区已跟取calltrace待问题复现后分析。
2、16 Normal Call Clearing；表示呼叫正在被清除，这是因为呼叫所涉及的用户之一已经请求清除呼叫，这种情况流程正常，被叫侧上发某SIP消息携带该信息，一般为被叫挂机，怀疑为GN平台统计问题。
3、21 Radio Connection with UE lost，一般为无线问题，已进行最低接入电平修改，B2门限抬升，功率调整，以及频繁切换地带修改CIO，减少切换，部分小区已解决，对于疑难小区已跟取calltrace待问题复现后分析。
若解决掉话主要问题 1 TX2 RELOCOverall E xpiry占比29.17% 、21 Radio Connection with UE lost占比20.83%，掉话率可提升50%。
2）GN平台近一天大于2次小区掉话分析通过对近1天掉话次数大于2次的小区进行具体分析，发现问题占比最多的为MME回复SGW UPDATE BEARER RESPONSE(Cause:94)占比约52%，若解决此问题，掉话率可提升50%，可达全省前5名，详情如下：掉话原因占比次数MME回复SGW UPDATE BEARER RESPONSE(Cause:94)，52.38% 22 Request rejected（52.38%）Normal call clearing（14.29%）23.81% 10基站在BYE之前异常发出的上下文释放中携带casue（1）9.52% 4tx2relocoverall-expiry（9.52%）基站发送UE CONTEXT RELEASE REQUEST（21）casue：9.52% 4 radio-connection-with-ue-lost给MME(（9.52%）)unspecified4 （4.76%） 4.76% 23、VOLTE掉话后续优化建议通过分析，VOLTE掉话主要原因为，MME回复SGW UPDATE BEARER（cause94），其次为radio-connection-with-ue-lost(21)、tx2relocoverall-expiry切换超时。
VOLTE掉话分析处理方法
一、VOLTE掉话优化方法（包括测试、统计）1.1、Volte掉话定义：Volte掉话率=掉话次数/成功建立呼叫次数*100%统计方法•掉话：空口RRC连接释放（终端Radio Link Failure或者网络侧RRC Release）；主被叫bye消息异常或者通话结束收到bye和ACK消息，但是未正常释放承载。
•成功建立呼叫：包括RRC连接建立和SIP会话建立。
a)RRC连接建立：RRC IDLE状态的终端通过“随机接入-RRC连接建立-DRB建立”立空口过程完成与无线网的连接并开始上、下行数据传送，视作成功完成连接建立；b)成功建立呼叫：从主叫终端发起SIP INVITE消息到接收到网络侧下发的SIP 200 OK消息；1.2、Volte掉话率优化思路：Volte掉话分析大致来源于投诉、DT、统计（炎强或者网管）三方面；目前掉话原因主要集中在两方面：一方面是无线；另一方面是EPC或者IMS的问题。
针对掉话优化，具体优化流程涉及方面如下：1.2.1 路测掉话分析思路Volte目前在我省处于试商用阶段，现阶段测试是我们发现Volte问题的主要手段。
通过全国各地对Volte掉话分析处理的经验，如上六方面是影响Volte测试掉话率的主要因素，具体分析方法如下：1、服务小区故障导致掉话：此类问题的表象不一，总的来说，在确认系统的功率、切换、业务相关参数无误、并排除了无线环境（信号）的影响之后，掉话问题依旧存在，这时可以将问题考虑为系统设备（可能是硬件或软件）异常。
1. 网管告警查询，如果存在告警及时处理。
2. 切换流程异常（在切换区、无法正常完成切换、而导致掉话）3. 在业务进行到相对固定的一段时间内、发生掉话（并且可复现）4. 在特定某（几）个扇区、eNodeB下，发生可复现的掉话5. 跨MME、或者跨TA等，在特殊区域进行业务时，发生可复现的掉话2、弱覆盖导致掉话：现象由于弱覆盖导致的掉话，通常有以下表现：1. 掉话前服务小区的RSRP持续变差（低于弱覆盖标准1，如：小于-110dBm）、同时服务小区的SINR也一起持续变差（小于-0dB，甚至更低）；2. 掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。
经典案例-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语音掉话问题分析【产品族】LTE TDD【关键字】SEQ、VoLTE掉话率、重定向开关、eSRVCC开关【问题描述】S省N市C运营商LTE全网VoLTE语音掉话率指标陡增1倍，无线网管变化不大，需要分析具体原因：【处理过程】1、SEQ提取掉话原因分布28 Inter-RAT redirection原因掉话次数剧增，其他原因导致的掉话次数变化不明显行标签11月02 11月03 掉话次数VoLTE语音始呼掉话次数VoLTE语音终呼掉话次数VoLTE语音始呼掉话次数VoLTE语音终呼掉话次数修改前修改后28 Inter-RAT redirection 30 18 228 217 48 445 10RESOURCE_ALLOCATION_FAILU143 111 191 134 254 325RE0 BEARER_RELEASED 80 75 118 108 155 226210 13 17 23 23 40 INSUFFICIENT_BEARER_RESOURCES26 Failure in the Radio Interface14 13 24 16 27 40 Procedure9000 Timeout 1 1 12 20 2 3221 Radio Connection With UE22 23 13 15 45 28 Lost7 EPS services not allowed 4 4 5 13 8 1816 Normal Call Clearing 10 0 14 1 10 15其他23 21 30 9 44 39总计337 279 654 557 616 12112、剧增掉话场景分析：28 Inter-Rat redirection提取掉话原因剧增场景28 Inter-Rat redirection 的掉话话单并进行分析：呼叫应答后35秒，MME收到eNodeB上报的UE CONTEXT RELEASEREQUEST(Cause:28)，携带原因值为interrat-redirection (28)，说明用户在通话过程中发起重定向，可能是由于4G无线问题，导致用户向2G网络发起重定向，6秒后承载被释放，呼叫掉话，建议对现网参数配置进行核查。
(重点)VOLTE掉话分析
VoLTE经验总结1 广州VOLTE网络质量现状经过近三个月的优化工作，广州ATU网格内，掉话率逐步改善，从11.5%（四月）下降至3.27%（七月）；接通率从93.1%提升至6月份的96.6%，七月份下降至89.46%。
?七月份测试期间核心网的IOT测试也在进行；较多invite 500、SIP unknown、MT CSFB等异常问题导致的连续多次未接通。
广东公司计划在本周对广州IMS 进行华为IMS替换爱立信IMS的操作，故七月份测试遇到的异常IMS相关问题分析进度暂缓。
2 广州VoLTE测试问题优化进展2.1 异频重定向掉话问题验证（问题解决）背景：中兴eNodeB在P01版本下，因邻区缺失导致异频重定向掉话，该问题需升级P02版本解决。
网格44、45测试过程中未发生异频重定向掉话，信令上分析测试过程中出现过多次连续上报异频A3的测报，未切换也未发生重定向，P02版本禁止QCI 1 业务异频重定向功能生效。
2.2 异系统重定向掉话问题验证（问题解决）背景：中兴eNodeB在P01版本下，VoLTE发生重定向掉话，该问题需升级P02版本解决。
网格44、45基础覆盖较差，以往拉网测试均会发生多次系统重定向掉话，7月24日，网格44、45完成P02版本升级，升级后重定向掉话问题解决，拉网测试掉话率改善明显。
P02版本禁止QCI 1业务重定向功能打开，终端上报A2（盲重定向门限）或B2事件（2G 邻区信息错误）等前期会导致重定向的情况下，网络均未下发重定向，VoLTE业务保持通话结束后自动挂机，未产生掉话事件2.3 TM3/8转换掉话问题验证（问题解决）背景：中兴eNodeB在P01版本下，VoLTE业务过程中发生TM3到TM8模式转换，因为基站提前转换导致终端掉话，该问题需升级P02版本解决。
8月3日，网格45所有升级站点打开TM3/8自适应，验证VoLTE业务在TM3与TM8进行转换时是否掉话，测试结果如下：网格45遍历拉网测试中出现26次TM3向TM8的模式转换，转换正常未发生异常。
室分VoLTE掉话问题处理总结
室分VoLTE掉话问题处理总结一、问题描述近日接到县局反馈在XX电信大楼通话过程中容易掉话，出现次数较多。
二、分析处理过程根据县局提供室分信息，查询了基站的告警情况，该小区为1t2r配置，底噪情况如下，实际底噪-85左右，（诺基亚基站小区正常底噪在-105左右；该小区ANT2实际未接馈线）：根据县局提供的手机号码及掉话时间，在智慧优化平台查看通话记录，发现其掉话原因为BEARER_RELEASED。
端到端语音质量对比情况，主被叫语音质量均优良，没有丢包问题和时延问题：分析被叫端语音质量，可以看出在最后的5秒内达到的达到包数相比减少了非常多：在“信令回溯”页面，可以看出eNobeB发送了UE Context Release Complete 消息给MME，具体原因未知：继续查询XDR话单，找到对应的使用记录，可以看出UE Context Release 的原因是Radio Connection With UE Lost:根据上述分析，在空口侧应该是UE失步了导致基站释放了它的上下文信息。
按照通话时间在基站侧进行了calltrace，从信令来看，掉线原因是Radio Connection With UE Lost，具体原因为上行BLER达到了100%，然后基站认为手机out of syn并释放了其手机上下文信息，导致掉话问题出现。
若干秒后三、处理方案根据上面的分析，是手机失步了然后基站释放上下文导致掉话问题出现。
查询小区参数，其N310，N311，T310均已达到最极限值，没有修改的空间了，而该小区的底噪问题由于涉及到较多的环节，暂时无法处理。
分析该小区周边站点情况，同站址内有L800小区在用，故暂时采用语数分析方案，临时解决掉话问题。
XX大楼室分小区_1修改了如下参数：数修改如下：因L800小区带宽较小，在承载了较多的语音业务后需控制其覆盖范围，我们将其rsboost调整为-3，电子倾角下压了3度。
关于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统计距离明显大于最小站间距，则该小区极可能存在过覆盖。
对于过覆盖问题需进行增大下倾角、降低功率、站点整改等。
➢无线网络拥塞原因。
对于无线网络拥塞原因导致语音掉话，则需对拥塞原因进行排查及扩容等优化处理。
1.1.1.2.2.基于路测定位优化流程➢基于测试数据在ATU平台进行异常事件统计。
精品案例_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为主叫测试端口信令，不应该会有被叫时间出现，且存在大量未接通。
VoLTE掉线率优化处理分析
VoLTE掉线率优化处理思路【摘要】VoLTE即Voice over LTE，它是一种IP数据传输技术，使得用户在LTE网络下不仅仅能够享受高速率的数据业务，同时还能获得高质量的音视频通话。
VoLTE是基于IMS的语音业务，而IMS由于支持多种接入和丰富的多媒体业务，成为全IP时代的核心网标准架构, 本文主要介绍VoLTE掉话率优化方法，为后续VoLTE接入成功率的优化提升提供参考【关键字】VoLTE掉话率【故障现象】VoLTE掉话排查思路1、无线侧原因排查：终端异常进入空闲模式或者无线链路失败、RRC重建失败，需要查看当时的SINR和RSRP，确认是否由于越区覆盖、邻区漏配、PCI模3干扰、弱覆盖、基站故障等无线问题导致，VoLTE掉话应重点关注以下几个环节：是否发生无线链路失败终端在无线质量极差时会发生无线链路失败（Radio Link Failure,RLF）事件，RLF事件可从路测软件中查到。
出现无线链路失败后建议检查以下几点。
1) 邻区漏配导致无法切换导致掉话。
邻区漏配现象：掉话前下行覆盖变差， UE多次上报测量报告（MR），已经满足切换门限后网络侧不下发包含mobilitycontrol的RRC重配消息，最后掉话。
2) 覆盖弱导致无线链路失败（Radio Link Failure）3) 干扰强造成了SINR低，导致无线链路失败（Radio Link Failure）。
建议检查掉话点的SINR、RSRP以及相邻站点的PCI，确认是否存在越区覆盖、重叠覆盖、PCI模3干扰等。
无线链路失败后是否RRC重建成功RLF之后若终端搜索到合适的小区，可发起RRC重建流程。
重建成功话音则得到接续，不算掉话。
设备功能问题导致掉线说明：若无线环境较好未发生无线链路失败而终端突然掉线，建议检查基站或终端是否存在功能问题导致掉话。
例如：TM3/8转换导致掉话。
2、EPC原因排查：如果通话发生专用承载丢失、去激活承载消息未收到、核心网下发Detach Request，跟踪MME、S/PGW、PCRF信令查找问题原因。
VOLTE案例分析(PDCP SN SIZE 配置不一致导致异常掉话问题。)
PDCP SN SIZE配置不一致导致异常
1.问题现象:
小区1：PDCP SN SIZE配置为7；小区2：PDCP SN SIZE配置为12。
当手机在小区1和小区2互切时，主被叫同时发起bye，引起掉话。
2.问题分析:
现场选取两个贝尔站点，把PDCP SN SIZE修改不一致后复测（来凤街，PDCP SN SIZE=7；
第二机床厂，PDCP SN SIZE=12），手机首先在来凤街注册并拨号，此时它的RRC
RECONFIGRATION带下来的PDCP SN SIZE=7。
当手机向第二机床厂移动时，发起handover request，此时IE中携带PDCP SN SIZE为
7.（截图如下）
此时目标基站回复Ack消息，并进行了切换。
但是原小区在给手机发的rrcConnectionReconfiguration消息中，未带有PDCP重配消息。
从而导致PDCP解码失败，形成单通or双不通。
（截图如下）
3.问题处理：
通过研发分析，是由于PDCP-config没有下发导致；根据研发提供的patch，验证结果如下：
现场选取两个贝尔站点，把PDCP SN SIZE修改一致后复测，主叫发生了60次切换，被叫发生65次切换，未发生掉话。
从手机侧log看，当PDCP SN SIZE配置一致时，在RRC重配置消息中携带pdcp-config消息。
（截图如下）
4．问题解决：
建议厂家之间协商好PDCP SN SIZE，临时解决问题。
贝尔将在LR14.3彻底解决PDCP SN SIZE 配置不一致导致异常掉话问题。
VOLTE掉话参数设置对VOLTE掉话率影响分析
VOLTE掉话参数设置对VOLTE掉话率影响分析中国联通陕西省分公司陕西西安710000【摘要】VoLTE（Voice over LTE）是一项利用4G网络传输数据和语音的技术，无需依赖2G/3G网络，提供高清、低延迟的语音通信。
然而，室内深度覆盖不足是LTE网络的问题。
在处理Top小区时，我们采用参数配置和综合分析方法，通过异常指标、告警、干扰、覆盖等因素进行问题定位和解决，以改善VoLTE服务质量。
这有助于实现更清晰、高质量的语音通信，提升用户体验，前提是LTE网络需有完善的覆盖。
【关键字】VOLTE掉话参数、VOLTE掉话率【业务类别】优化思路原因分析排查：1、基站告警导致VOLTE掉话率高2、覆盖异常导致VOLTE掉话率高3、邻区关系不完善导致VOLTE掉话率高4、切换参数设置异常导致VOLTE掉话率高5、定时器设置不合理导致VOLTE掉话率高处理步骤：1、核减VOLTE掉线区域基站是否存在告警2、分析VOLTE掉话区域MR数据3、通过Mapinfo邻区分析工具分析邻区漏配情况4、核实系统间切换参数5、统计现网掉话各counter占比情况一、问题描述我们在日常监控指标时发现，西安_徐家湾_文德路与学府环路十字_DMBFLX 基站下XA_26ED3_0_LM_徐家湾_文德路与学府环路十字小区VOLTE掉话率高。
提取该小区一周的指标进行核查，VOLTE掉话主要原因为“无线层问题导致的激活的语音业务E-RAB异常释放次数”。
日期小区名称QCI为1的业务E-RAB异常释放次数eNodeB发起的S1 RESET导致的QCI为1的E-RAB异常释放次数切换出QCI为1的E-RAB异常释放次数传输层问题导致的激活的语音业务E-RAB异常释放次数切换流程失败导致的激活的语音业务E-RAB异常释放次数无线层问题导致的激活的语音业务E-RAB异常释放次数2 021-09-04XA_26ED3_0_LM_徐家湾_文德路与学府环路十字300003二、分析过程1、问题分析通过移动网和传输网管查看该基站故障告警信息，发现并无故障告警；查看该基站基站XA_26ED3_0_LM_徐家湾_文德路与学府环路十字，小区级连续一周指标，该小区状态正常，无干扰，指标正常。
VOLTE掉话分析
TOP筛选条件◆当日掉话次数大于3次为TOP小区◆一周内出现3次TOP小区为高掉话TOP小区TOP分析方法手段掉话问题掉话原因分析➢按照掉话分子，按原因值提取相关计数器进行分析；➢检查站点是否存在邻区漏配或者配置不合理，导致无法及时切换出而吊死，引发掉线；➢小区存在异频邻区时，需要核查异频切换类相关A2、A3配置门限是否合理；➢检查小区是否存在超远覆盖，导致覆盖孤岛，无法及时切换到周边基站，可通过后台信令跟踪，观察测量报告，补齐漏配的邻区，随后及时对覆盖进行控制；➢对于弱覆盖引起的掉线，若终端处于覆盖边缘，周围无可用LTE小区，可以合理添加异系统邻区，合理配置重定门限，及时重定向到异系统，减少掉线。
➢关注小区无线环境，分析是否NI过高；➢关注影响业务的故障类告警；掉话Context归类如下：●ENB由于S1链路故障发起释放分为三类◆Context释放，Gtpu ErrInd触发释放：主要是核心网参数问题，部分原因是TAC边界不和导致，可以优化TAC边界◆Context释放，Path故障触发释放：传输故障导致，需核查传输◆Context释放，光口故障触发释放：光口、S1链路故障等原因，推维护处理●Context释放，ENB切换失败引发释放：检查切换参数、功率参数、定时器设置；●Context释放，由于小区关断或复位引发释放：检查掉线对应时间段内基站小区故障类告警●Context释放，ENB由于其他原因引发释放：容量等其他问题；●Context释放，ENB重建立失败导致释放：检查小区NI是否过高，RS功率设置是否偏小，检查现场无线环境，开启X2口进行优化（重建立如果在目标基站没有上下文，重建肯定失败）；●ENB空口失败引发释放次数分四类◆ERAB释放，空口定时器超时：检查CPU负荷，同时在线用户数是否偏高，如是可增加SR信道配置容量进行优化，排除MR开启时间段内计时器增多，提故障交研发处理；◆ERAB释放，空口质量差触发RLF：检查无线环境是否存在弱覆盖、模三干扰、越区覆盖、底噪偏高、基站存在故障；◆ERAB释放和RLC达到最大重传次数：检查RLC参数设置，排除MR开启时间段内计时器增多，提故障交研发处理；◆ERAB释放，PDCP完整性保护失败：检查加密完保参数设置，排除MR开启时间段内计时器增多，提故障交研发处理；Context整理情况如下：切换问题：切换分为切换准备阶段和切换执行阶段切换准备阶段多由外部邻区参数配置错误（邻区配置正确）或者切换准备目标基站故障引起。
高负荷场景VoLTE语音掉话分析案例
高负荷场景VoLTE语音掉话分析案例一、【问题描述】分析淮南市区网格RCU V oLTE测试数据，测试中出现掉话事件，掉话原因：“RRC重配消息中包含释放DRB承载信息或未重建起呼DRB”。
针对此现象，我们展开分析处理。
二、【问题分析与排查】2.1 UE log分析终端占用HN-市区-洞山局-NFTA-440705-50无线环境良好（RSRP=-80.62dBm，SINR=15.2dB），通话过程中，在19:21:03.574收到基站侧下发的携带释放QCI=1专载的重配置消息，之后终端上发BYE请求挂机，主叫掉话。
被叫在19:21:03.534同样收到携带释放QCI=1专载的重配置消息，被叫终端也上发BYE请求挂机，造成被叫掉话。
2.2 Emil Trace分析Emil 信令消息显示，在19:21:04基站侧下发重配置消息，消息中包含释放QCI=1专载的信息，如下图所示：在E-RAB Release Indication消息中显示，释放专载的原因值为：radio-resources-not-available，即无线资源不可用，如下图所示：2.3 原因排查2.3.1 设备告警&干扰排查经核查，问题区域附近站点无设备告警，无异常干扰现象。
2.3.2 参数核查① V oLTE相关参数（包含切换参数）核查；②QCI1 DRX ROHC核查；③Inactivity timer参数核查；④ iniMcsUl和iniPrbsUl参数核查；⑤CFI核查。
参数影响排查后：只有CFI、iniMcsUl 和iniPrbsUl这3个参数与网络物理资源相关。
2.4 指标统计分析HN-市区-洞山局-NFTA-440705-50小区V oLTE掉话问题点，对这些小区对应时间段的重要指标进行统计，对比测试异常时段与其他非测试同时段网管KPI 发现，测试时段该小区CCE_BLOCKING_RATE异常，指标如下：可以得出结论：本次异常掉话很可能与问题小区CCE_BLOCKING_RATE 指标相关联，而从参数核查情况来看，与PDCCH拥塞相关参数只有CFI设置。
VOLTE端到端掉话分析指导
VOLTE端到端掉话分析指导VOLTE掉话率分析进展掉话率整体情况：关联MR、干扰、TOP等整体分析情况通过SEQ信令平台端到端指标分析全省8月4日掉话率，掉话原因归属中无线原因占比最高，达到96.61%。
总掉话次数6973次，始呼掉话3679次，终呼掉话3294次，一共涉及小区5682个小区，掉话用户5712个，不存在明显TOP小区与TOP用户；在对掉话小区MR对比中发现，MR覆盖率大于98%掉话小区数325个，MR覆盖率小于98%掉话小区数5537个，MR覆盖率最差为6.71%，对掉话小区干扰分析发现，高于-110小区429个，低于-110小区5253个。
“10RESOURCE_ALLOCATION_FAILURE”原因值占比28.84%,占比最高。
本周发现掉话类型案例第一类：MME释放UE上下文导致掉话问题描述：SBC向SCSCF发送BYE消息，携带原因为承载释放，统计为一次掉话。
问题分析：最后一次切换17S后，MME向基站下发UE上下文释放命令，携带原因值为正常释放。
分析PS话单发现，最后一次S1切换后无其他PS话单，掉话后发起TAU流程。
结合语音质量话单分析发现，此次通话上行单通6112ms，语音分片记录发现23:29:30.484开始S1-U口已经无语音包。
S1-U口GM口从MR及干扰分析来看，本次通话占用CCCC_天琴湾小区_HLH_F22_1小区，当日MR覆盖率为92.58%，平均干扰为-115，通话时间占用站点无影响业务告警。
问题定位:结合以上分析来看，此次通话占用站点无干扰，MR覆盖率相对较差，用户上行单通时间较长，初步判定为无线原因导致。
第二类：切换中MME释放UE上下文超时导致掉话问题描述：SBC向SAEGW发送“Insufficient Bearer Resource”承载资源不足，统计掉话。
问题分析：回溯SIP信令发现，19:14:14.443干沟子基站向MME发起切换，PS话单显示切换成功。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
VoLTE经验总结1 广州VOLTE网络质量现状经过近三个月的优化工作，广州ATU网格内，掉话率逐步改善，从11.5%（四月）下降至3.27%（七月）；接通率从93.1%提升至6月份的96.6%，七月份下降至89.46%。
七月份测试期间核心网的IOT测试也在进行；较多invite 500、SIP unknown、MT CSFB等异常问题导致的连续多次未接通。
广东公司计划在本周对广州IMS 进行华为IMS替换爱立信IMS的操作，故七月份测试遇到的异常IMS相关问题分析进度暂缓。
2 广州VoLTE测试问题优化进展2.1 异频重定向掉话问题验证（问题解决）背景：中兴eNodeB在P01版本下，因邻区缺失导致异频重定向掉话，该问题需升级P02版本解决。
网格44、45测试过程中未发生异频重定向掉话，信令上分析测试过程中出现过多次连续上报异频A3的测报，未切换也未发生重定向，P02版本禁止QCI 1 业务异频重定向功能生效。
2.2 异系统重定向掉话问题验证（问题解决）背景：中兴eNodeB在P01版本下，VoLTE发生重定向掉话，该问题需升级P02版本解决。
网格44、45基础覆盖较差，以往拉网测试均会发生多次系统重定向掉话，7月24日，网格44、45完成P02版本升级，升级后重定向掉话问题解决，拉网测试掉话率改善明显。
P02版本禁止QCI 1业务重定向功能打开，终端上报A2（盲重定向门限）或B2事件（2G 邻区信息错误）等前期会导致重定向的情况下，网络均未下发重定向，VoLTE业务保持通话结束后自动挂机，未产生掉话事件2.3 TM3/8转换掉话问题验证（问题解决）背景：中兴eNodeB在P01版本下，VoLTE业务过程中发生TM3到TM8模式转换，因为基站提前转换导致终端掉话，该问题需升级P02版本解决。
8月3日，网格45所有升级站点打开TM3/8自适应，验证VoLTE业务在TM3与TM8进行转换时是否掉话，测试结果如下：网格45遍历拉网测试中出现26次TM3向TM8的模式转换，转换正常未发生异常。
2.4 X2开启告警验证（问题解决）背景：广州前期因中兴网管告警问题未打开X2接口，导致跨站重建立不可用，需升级P02版本对X2告警量进行抑制。
8月5日，网格44、45所有升级站点打开X2接口功能，指定开启X2自配置站点213个，8月6日统计站点X2偶联条数共计4604条。
告警问题：网格44、45开启X2后，8月6日网管出现60多条X2断链告警，告警主要原因：a、传输不通，部分微站无法与宏站正常建链；b、个别小区被蔽塞不能正常建链；升级后EMS网管上只出X2断链告警，并且所有基站仅出1条（多条X2断链），无SCTP断链告警，网管上可明确区分X2与S1告警，告警量大幅下降。
2.5 X2开启跨站重建立功能验证P02版本支持无邻区的跨站重建立，在X2链路建立后，对于无邻区跨站重建立带来一定的增益，提高跨站重建立的效率；X2开启,网格44统计VoLTE拉网发生重建立请求共14次,跨站重建成功6次；从性能指标统计来看，RRC重建成功率从50%左右提升至80%左右。
原理：目标小区通过终端上报的PCI查找该站点保存的有X2关系的邻站所有小区信息，向所有相同PCI小区索取上下文。
3 广州VOLTE优化经验3.1 日常优化工作日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
3.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
3.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显3.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
3.5 系统间邻区优化广州LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
通过经纬将4G弱信号(RSRP<-110dbm)与2G强信号（RXLOV>-95dbm）在50米范围内拟合，根据拟合度对2G邻区进行补漏工作5月份第一轮拟合数据，剔除现网已配置的邻区关系，补漏483对；6月份第二轮拟合数据，剔除现网已配置的邻区关系，补漏邻区关系487对。
eSRVCC切换提升明显，且由于2G邻区不准确导致的异系统重定向大大减少。
3.6 重定向掉话中兴区域掉话最严重属于重定向掉话，在中兴基站算法中，以下三种可能发生重定向，重定向释放RRC后，专载同时被拆除，VoLTE业务产生掉话。
3.7 上行PUSCH功控参数优化背景：4月集团在中兴区域拉网测试发现上行PUSCH发射功率偏高，对现网参数检查发现，中兴区域上行期望功率值设置过高。
优化措施：进行功控相关参数优化，现网配置：p0NominalPUSCH =-75 ；puschPCAdjType=0优化值：p0NominalPUSCH =-87 ；puschPCAdjType=2●同等路损情况下，参数修改后，ue发射功率大约下降2~3dB。
●目前终端平均上行发射功率仍高于10db，仍需中兴完善现有功控方式。
修改后，PUSCH TxPower（10dbm以上）占比由40%下降到30%左右。
3.8 RTP丢包率优化背景：4月份测试中，中兴区域RTP丢包率偏高，个别网格甚至达到2%以上。
原因分析：在无线质量较好的情况下基本无丢包；无线质量较差的情况下上行丢包现象较为严重，PDCP重传时间超时，数据包将被丢弃；外场测试表明QCI 1 PDCP Discardtimer 配置与RTP丢包率及Jitter有密切关系，QCI 1 PDCP Discardtimer 配置越大，RTP丢包率越低，但Jitter也随之变大。
●MOS值与RTP丢包及Jitter关系都较大，目前广州正在601P02版本下进行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的对比验证。
●进一步联合中兴公司定位RTP丢包率偏高的问题，并推动产品功能算法改进。
3.9 MME专载保存功能（可选）功能描述：在基站发起UE-lost原因值的上下文释放请求时，MME保持专载2s 不释放，等待空口重建。
验证情况：已在GZMME1602下成功验证了该功能。
当时无线环境较差，UE 发起RRC重建失败，通过MME专载QCI1保持功能使得在新发起的业务过程中，RRC重配中建立包括专载QCI1的3条DRB，不会发生掉话。
（本次测试中专载保持时长约1.358s）功能总结：1）当无线环境较差时，UE发生RRC重建，若RRC重建成功，手机将不会掉话。
2）MME侧也可以在RRC重建失败后，通过MME专载QCI1保持功能使得在新发起的业务过程中，专载QCI1继续保持，也可使得手机不掉话。
3）此功能为爱立信MME非必选功能，建议打开。
但是该功能不在集采目录，暂时无法采购。
3.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 code DIAMETER_OUT_OF_SPACE)。
[优化措施]：当前解决办法：（1）缩短DRA时延配置。
（2）修改SAPC到DRA链路为主-备模式，保证CCA和RAR走同一路径和到达PGW的先后顺序。
[优化结果]：近期调整后的网格测试，暂时没有发现BYE200消息前后发生的切换没释放QCI 1专载的情况。
3.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消息。
[优化措施]：属测试软件统计问题，建议软件加以剔除该问题。
4 存在问题和建议设备功能问题：●切换冲突问题：基站无法解码SIP消息，UE专载建立完成的NAS消息上报时间无法确认，基站侧难以彻底解决，需要核心网做相应的功能优化，●呼叫过程eSRVCC：IMS不支持呼叫过程中发生eSRVCC，在4g网络覆盖达到2g规模之前，该问题都不可避免存在。