(重点)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承载。
- 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规模之前，该问题都不可避免存在。