简介针对5G网络中VONR通话异常问题这份docx案例文档完整记录了从用户投诉、SEQ话单分析到多楼层现场测试的优化闭环适合从事5G网络优化、VoNR业务保障的工程师参考。资源包仅含1个docx文件大小约11.76MB内容围绕某市政府办公区域的通话卡顿案例结合多个楼层、东西电梯、连廊及客房等场景采集的RSRP、SINR、下载速率等实测数据对比4G/5G室分与宏站占用情况和切换关系定位弱覆盖、互操作参数等根因并给出了干扰规避和切换策略调整等优化建议。整体按问题描述、原因分析、测试验证、解决措施模块组织数据详实、结论可落地便于读者快速复用VONR异常排查思路。已有153人学习下载对于希望提升5G语音业务优化能力的网优人员具有较好的实操参考价值。1. 从VoNR的“通但弱”说起今年在做5G语音专项优化时盯着一批VoNRVoice over New Radio新空口承载语音的通话异常case最典型的一句话投诉是“5G信号满格电话能打出去但对面声音断断续续像在水里说话一样。”这类问题在VoNR商用初期非常普遍看似“能通”但实际体验远低于用户对5G的预期。VoNR的优势在于协议栈精简、时延低、语音质量高但因为承载在5G NR上任何一个无线侧参数失配、互操作策略异常或核心网QoS配置偏差都会直接体现为杂音、断续、掉话甚至无法注册。这篇博文不铺垫概念直接以一个完整的VoNR通话异常优化案例为主线从现象、排查思路、信令分析、根因定位到最终优化落地把过程中用到的工具、参数、判断逻辑逐一拆出来。适合刚接触VoNR的网优工程师也适合做核心网语音策略校验的同行做横向参考。2. 案例还原与基础背景梳理2.1 现场情况与投诉描述用户反馈的位置在某商圈室内使用5G SA终端手机显示5G驻留RSRP约 -82dBmSINR在18dB左右无线信号看起来并不差。但用户通话过程中频繁出现对方声音断续偶尔有金属音质感单次通话时长超过3分钟后问题尤为明显。实测终端型号为主流国产5G手机系统版本已更新到最新排除了终端固件bug的可能。现场用测试终端复测问题可稳定复现排除偶发干扰或用户误操作因素。2.2 基线数据与知识准备接手案例前先梳理一下VoNR通话的完整链路方便后续定位。VoNR呼叫的核心路径是终端UE通过NR空口接入发起IMS注册SIP信令经5GC网元到达IMS域完成媒体协商后语音数据以AMR-NB/AMR-WB编码格式通过QoS Flow承载在NR数据无线承载DRB上传输。这其中任何一个环节的QoS参数设置不合理、测量配置错误或切换策略冲突都可能导致上行或下行语音包延迟、抖动或丢失最终体现为“通话异常”。我习惯在采集数据前先把几个关键参数想明白再有的放矢地去抓数据避免盲人摸象。3. 信令追踪与数据采集实操3.1 CDT日志的开启与抓取VoNR语音质量类问题最重要的第一步是抓取带QoS流量统计的CDTCall Detailed Tracing日志。操作路径一般是在核心网侧对用户号码开启信令跟踪同时在无线侧对该终端所在小区开启空口日志采集设置采样周期建议不超过200ms需要保留Uu接口RRC、NGAP、E1AP消息并勾选PDCP丢包和RLC重传统计。这一步有个容易忽略的点必须同时抓取上行调度信息。如果只抓下行遇到上行丢包定位会非常被动。我这次同步开了NR小区级的调度跟踪对接下来的根因判断起了决定性作用。3.2 SIP信令与QoS Flow映射的核对拿到CDT后先梳理SIP呼叫流程。从INVITE请求的SDP消息体里可以看到终端协商的编码格式这里确认协商结果是AMR-WB 23.85kbps单声道这符合5G VoNR的典型配置。随后核对核心网下发的QoS规则。VoNR语音业务通常承载在QCI 15QI 1上核心网通过PDU Session Modification流程为语音流分配专用QoS Flow其中5QI 1的关键参数包括资源类型GBR保证比特率优先级25G中数值越小优先级越高包时延预算PDB100ms误包率PER10^-2这些参数如果被修改比如PDB放宽到150ms或者错误率配置到10^-3会直接影响调度器对语音包的优先级判断从而在空口拥塞时造成丢包。核对后发现参数符合规范排除核心网QoS策略配置问题。3.3 空口质量与调度数据的交叉验证空口侧数据是最关键的证据。根据采集的NR调度日志我重点看了三项指标PUSCH的MCS调制编码方式分布上行PDCP SDU丢弃个数RLC层重传率结果一目了然用户上行PUSCH的MCS从初始的20左右随时间逐步降低最终稳定在8~10之间同时上行PDCP SDU丢弃数呈台阶式上涨RLC重传率平均达到8%以上。这个现象说明终端的上行信道质量在持续恶化而用户所在位置的RSRP和SINR采样点波动并不大说明问题不是简单的弱覆盖或外部干扰更像上行发射受限或功控参数异常。4. 异常原因挖掘与根因定位4.1 上行功控参数的排查在确认覆盖无异常后重点转向功控参数核查。VoNR语音是上行受限业务尤其是室内场景手机的发射功率和上行功控直接影响语音包的传输成功率。我核对了小区的P0-PUSCH-AlphaSet配置VoNR专用配置的P0值为 -106dBmAlpha为1.0这个配置本身是常规值。问题在于VoNR与数据业务的功控参数是否共用了同一套配置。现场核查发现该小区把VoNR的PUSCH功控参数和eMBB数据业务完全共用没有做业务级差异化功控。这会导致一个典型场景当多个用户同时做大数据量业务时小区对上行资源的干扰抬升VoNR语音用户无法通过功控快速提升发射功率导致上行语音包大量重传。这个发现和前面MCS逐步下调、上行PDCP丢包上升的现象完全吻合。4.2 边缘用户切换与承载类型回退验证另一个并行排查的方向是VoNR与EPS Fallback的切换策略。因为问题用户处于室内虽然RSRP不低但考虑到室内衰减和邻区关系我核查了该小区配置的A2事件门限触发VoNR到VoLTE重定向/切换的测量门限。该门限若设置过高在信号轻微波动时会过早触发回退导致通话中断和切换失败若设置过低终端会死守NR不放在信道条件已经无法满足语音QoS时才切换。结合CDT里的信令时间线通话第2分钟出现了两次RRC重配置但并未真正执行重定向随后上行丢包激增。这属于典型的“该切没切硬顶到底”场景。4.3 根因锁定与验证综合两路线索根因分两层第一层VoNR使用与数据业务完全相同的功控参数上行功控对抗干扰能力不足第二层A2门限配置偏低在信道劣化初期没有及时触发语音承载迁移。两个因素叠加导致用户在弱干扰上升场景中语音质差持续累积最终表现成断续和杂音。经过与核心网同事确认该小区确实是首批开VoNR时从存量NSA小区改造而来参数继承自原数据业务配置未做VoNR差异化。5. 优化调整方案与复测结果5.1 参数调整明细在明确根因后我分两步做调整每步单独验证避免参数混用无法评估效果。第一步调整VoNR专用上行功控参数。在小区配置中增加业务级功控策略VoNR业务使用独立的P0值从 -106dBm 调整到 -100dBmAlpha保持1.0同时开启格式相关的功率偏置保证语音上行覆盖增强但不产生过度干扰。第二步优化VoNR到VoLTE的切换门限。A2门限从 -115dBm 调整为 -108dBm同时将A2触发时延从640ms调整为320ms确保信道质量下降时可以更快触发测量、更快完成切换决策。需要说明的是A2门限不能盲目上调。门限过高会导致大量VoNR用户过早回落VoLTE损失VoNR的语音质量优势。我结合现网RSRP的分布统计把 -108dBm 作为临界点既保证正常用户90%以上的时间稳定驻留VoNR又给边缘用户留出安全切换的余量。5.2 调整后复测指标参数下发后同一位置、同一时段、同一终端的复测结果对比非常明显上行PDCP SDU丢包率从调整前的2.8%降至0.3%RLC重传率从8.2%降至1.5%MOS值POLQA评估从平均2.9提升至4.2通话10分钟内未再出现断续、金属音现象现场随机抽测周边5个点位VoNR持续时间占比均在96%以上更重要的是A2门限调整后全网的VoNR语音时长占比没有出现异常下降说明门限调整的副作用被控制在了合理范围内。5.3 批量推广前的小区筛选逻辑优化策略验证有效后我没有马上全网铺开而是先做了一轮小区级筛选。筛选逻辑是凡是VoNR占比高且平均MOS低于3.5的小区优先核查功控参数是否与数据业务共用凡是上行丢包率超过1%的小区核查A2门限和时延配置。这一步做完又发现了两个类似配置问题的小区同一批参数调整后问题同步消除。所以这条优化经验不是个案而是具有相当代表性的通用排查路径。6. 常见问题速查表与避坑指引6.1 高频异常分类表根据这个案例和同类项目的横向经验我把VoNR通话异常梳理成一张速查表遇到问题可以直接对照排查方向。异常现象优先排查项常用工具/手段关键判据注册失败/无法拨打核心网切片配置、5QI映射、IMS APN配置CDT、SIP信令SIP 403/480响应码呼叫接通但单通上下行调度是否均衡、RTP媒体方向媒体面抓包反向RTP包为0通话断续/杂音上行功控、空口丢包、邻区干扰NR调度日志PDCP丢包率1%特定区域掉话切换参数、邻区漏配、外部干扰MR、切换统计A2触发率异常VoIPotel回落失败EPS Fallback配置、互操作策略信令流程追踪重定向无响应6.2 实战中的几个关键提醒第一核查功控参数时不要只看P0值一定要连带确认Alpha、闭环功控开关和TPC累积状态是否一致这三个要素共同决定上行发射功率的实际行为。第二VoNR语音质量优化MR数据只能用来筛小区不能用来定根因。MR的采样周期太长无法捕捉几百毫秒级的语音丢包抖动必须依赖CDT级别的调度数据。第三调整A2门限要同时关注掉话率和VoNR时长占比两个指标只看掉话率容易把门限压得过低导致VoNR形同虚设。第四终端版本差异对VoNR异常复现影响很大同一问题换个终端可能完全复现不出来。现场排查时至少选用两款不同芯片的终端做交叉验证避免被终端特性带偏方向。7. 最后分享一点个人判断VoNR异常优化本质上是无线和核心网之间的“翻译”工作。很多时候问题不在某一个网元而在参数配置策略和业务特性不匹配。像这次案例无线侧信号看着挺好语音却一塌糊涂就是因为功控参数没有跟上VoNR的业务诉求。我个人在操作中养成的习惯是每处理一个VoNR case都会把“信号覆盖-功控策略-切换门限-核心网QoS”这四个维度同步过一遍而不是看到丢包就急着加功率或改编码。这也是希望看到这篇内容的朋友能带走的经验——先有全局视角再去动参数。如果你手头正好有VoNR通话异常的case不妨先按这个思路拉一遍日志大概率能少走不少弯路。本文还有配套的精品资源点击获取