简介这是一份5G网络优化案例聚焦VONR通话异常问题适用于移动通信网络优化工程师、5G语音质量分析人员及通信专业学生。案例以办公区域电梯内通话卡断的真实投诉为起点完整记录了从SEQ话单分析、信令拆线原因定位、无线侧KPI指标提取、MRO弱覆盖分析到逐楼层现场测试对比的全过程清晰呈现了VONR通话质量问题的排查思路与闭环优化方法。资源为单个docx文档约11.76MB内容包含详细的数据表格和测试结论层次分明便于按图索骥。读者可从中掌握切换频繁、室分覆盖不足、宏站与室分信号强度接近等常见诱因的判断技巧学会利用话单和KPI指标快速锁定问题区域并参考其优化策略处理同类5G语音问题。目前已有155人学习下载适合需要提升现场优化实战能力的工程师学习借鉴。1. VONR通话异常优化案例在解决什么从投诉单到根因判定的一条验证链深夜被语音质量投诉叫醒是VoNR优化工程师最熟悉的场景。VONR通话异常优化案例这类文档通常被放进网优知识库时看起来平淡真到现场就能发现它的价值不在结论而在一条完整的验证链从用户投诉里的“听不清”“接通就断”出发一路推到无线覆盖、参数策略、核心网信令乃至终端版本最后落到可执行的调整动作。VoNR5G新通话刚规模商用那阵某个高端网格连续出现同一类投诉后台指标全绿问题却集中在某个地铁口——平均值把真问题盖住了。本文不虚构某份报告只按一线做VoNR异常优化的通用做法讲清楚如何读这类案例、复现排查思路并落地参数。适合网优、核心网和投诉处理工程师以及刚开始接手5G语音优化的人。2. 先把VoNR链路拆开关键节点、业务信令与三类异常落点2.1 VoNR与VoLTE的差异业务相同承载路径完全不同VoNR和VoLTE都走IMSIP多媒体子系统SIP信令从INVITE到BYE几乎一致差别在于无线承载。VoLTE是4G网络下的QCI1专载VoNR则是在5G NR上的5QI1语音和5QI2会话类视频承载。很多优化工程师习惯了4G那一套QCI1优化手段转到VoNR后第一反应是“改切换门限”但VoNR的语音承载建立还涉及QoS Flow到DRB数据无线承载的映射、IMS信令的传输路径以及是否存在N26接口的互操作选择。用一条用户主叫流程来说明节点更直观终端在NR驻留发起呼叫后先完成RRC建立再通知核心网建立PDU会话IMS信令走默认QoS Flow随后核心网为语音专载发起QoS Flow新建或修改无线侧完成DRB承载建立两端的SIP消息才真正开始协商。整个过程里任何一个节点失败都会表现为“呼叫异常”但用户侧现象往往高度相似这就决定了只看一端永远定位不准。2.2 5QI1承载为什么是排查的第一分界点5QI1属于GBR保证比特率承载无线侧需要为它预留调度资源并且它的调度优先级、时延预算和丢包率配置与默认承载完全不同。案例文档里如果提到“VoNR呼叫失败集中在建立阶段”第一件事不是看切换而是确认QoS Flow到底有没有建立成功。实际排查中常见情况是终端上报了PDU会话修改请求核心网也下发了QoS Flow建立命令但无线侧因资源不足、功率受限或配置冲突而拒绝最终表现为用户拨号后长时间无振铃或直接失败。还有一个容易误判的点EPS Fallback。5G覆盖不满足VoNR要求时系统会让呼叫回落到4G再建立语音这个动作发生在承载建立之前用户感觉是“呼叫建立慢”但后台VoNR接通率可能依然正常因为回落本身算业务成功。优化时如果把回落后的失败也算进VoNR指标就会把问题张冠李戴。所以拿到一个VoNR通话异常案例先要明确统计口径是从终端发起VoNR请求开始算还是从5QI1承载建立成功开始算。2.3 三类异常落点接入、承载与呼叫控制把大量案例归类后会发现VoNR通话异常无外乎三类异常类别典型现象关键信令节点第一步排查方向接入类拨号后无响应、呼叫建立明显变慢RRCSetupRequest / RRCSetup / RRCSetupComplete覆盖质量、随机接入、小区拥塞承载类能听到回铃音但接通后无声或立即断开PDUSessionModification、QoS Flow建立失败、DRB配置失败5QI参数配置、核心网与无线侧承载参数一致性呼叫控制类振铃正常但通话中掉线、单通、杂音SIP INVITE重传、183/180缺失、BYE原因值IMS链路、RTP媒体路径、编解码协商接入类最容易理解覆盖差导致RRC连接建立不了这种情况路测一遍就能复现。承载类最隐蔽因为它需要同时看核心网和无线侧两边的信令很多时候两边各自的错误计数都是零只有关联起来才能发现是QoS参数不匹配。呼叫控制类则往往不是无线问题典型如SIP INVITE发送后一直重传最终超时无响应问题在核心网或传输链路调无线参数完全无效。3. 完整排查路线从指标异动、信令取证到根因互斥3.1 指标口径先对齐接通率、掉话率、MOS与丢包的正确取法任何优化动作之前先把指标口径说清楚否则后面所有对比都是无效的。无线侧一般取RRC建立成功率、5QI1承载建立成功率、QoS Flow建立成功率业务侧取端到端接通率和掉话率质量侧取上行/下行RTP丢包率、抖动和MOS。常见问题是把不同系统的统计区间混在一起报表上看起来只差零点几个百分点实际根本不能比。处理单个案例时我更倾向于把时间粒度切到15分钟按小区、按栅格各出一张分位数统计。平均值全绿不代表问题不存在用户投诉往往落在5%分位或某个特定时段例如早晚高峰、地铁隧道区间。把指标按小时画出来如果劣化时段和投诉时段对齐这个案例才真正有的放矢。3.2 分阶段信令定位无线信令与SIP信令配合使用现场排查时信令是唯一的裁决者。无线侧和核心网侧都做了信令跟踪但两者配合使用时要掌握节奏。我的习惯是先看无线信令确认接入和承载是否建立再看SIP消息确认呼叫控制在哪个阶段失败最后把两条线索在时间轴上对齐。无线侧的排查顺序是RRCSetupComplete是否上报、PDUSessionModification是否成功、DRB配置是否完成。如果RRCSetupComplete未上报问题大概率在随机接入或覆盖现场路测补测RSRP和SINR即可确认如果承载修改失败则要抓取失败原因值常见有无线资源不足、QoS参数非法、定时器超时。SIP信令则按消息顺序观察INVITE发出后应收到100 Trying随后是183 Session Progress或180 Ringing最后是200 OK完成媒体协商。如果INVITE重传多次仍无响应排查核心网侧对INVITE的处理及传输时延如果183之后媒体通道建立失败再看RTP是否双向可达。单通问题常出现在这一环——信令会话建立了但一方RTP收不到多数是NAT、防火墙或媒体转发路径配置问题。3.3 根因假设互斥覆盖、参数、终端、核心网的四选一信令定位到具体阶段后进入根因推断环节。不要试图一次改三个参数来解决问题正确做法是列出互斥假设逐条用证据排除覆盖假设通过MR测量报告和路测数据判断弱场区域是否与实际投诉位置吻合。如果RSRP低于VoNR业务门限但VoLTE正常覆盖假设成立。参数假设检查近期是否有参数变更记录特别是切换门限、异频测量配置、语音承载优先级。参数问题往往有明确的时间点后台网管能查到修改记录。终端假设分析失败用户终端型号和版本是否集中。同一版本集中出现同样异常优先怀疑终端实现。核心网假设若无线侧指标正常且信令无失败记录问题多半在IMS侧此时需要核心网侧信令跟踪配合。A同学处理过一个典型案例某车站候车区用户反映VoNR通话经常断线无线侧指标全部正常最后通过终端日志发现终端在该区域频繁在NR和LTE之间切换而互操作参数中的触发时延配置过短导致切换尚未完成就发生了无线链路失败。这就是参数假设与覆盖假设同时存在时靠信令时间轴才分清了主次。4. 参数与动作怎么落地覆盖、干扰、互操作的调整边界4.1 覆盖与邻区调整先看测量报告再动偏置和切换参数案例文档里结论写“建议优化覆盖”往往太过笼统。真正落地的第一步是找出覆盖问题的具体形态是主覆盖小区RSRP整体偏低还是存在邻区漏配导致切换带断裂或者波束覆盖存在空洞。三者对应的动作完全不同。邻区漏配的典型证据是A3测量报告里出现了好的目标小区但切换请求未发起或切换准备失败。此时补邻区关系最直接同时可适度调整CIO小区个体偏移让切换提前发生。CIO的调整幅度要克制一般按0.5到1dB步进尝试配合切换迟滞和触发时延。触发时延TTT方面太短容易产生不必要的切换和乒乓太长则可能导致切换命令还没下发服务小区信号已经恶化到无线链路失败。实战中常见合理区间在数百毫秒到1秒量级但必须结合具体场景验证不存在通吃所有场景的万能值。4.2 干扰底噪清洗上行干扰不是靠调功率硬压的VoNR语音对时延和丢包都敏感上行干扰导致的PUSCH BLER升高会直接反映为对方听到断续或杂音。排查干扰时先看小区底噪是否抬升、抬升的时域和频域特征。如果底噪在某个频段持续偏高优先带扫频仪查外部干扰源而不是先调PUCCH期望接收功率。当干扰源确认无法立即清除时才考虑参数侧缓解提高PUCCH/PUSCH的期望接收功率或聚合级别并把语音业务的调度优先级提升保证5QI1承载的MCS不会被干扰环境拉得过低。这些调整能改善稳定性但代价是容量下降所以需要观察调整后的小区PRB利用率和用户体验速率避免把一个语音问题变成容量瓶颈。4.3 互操作参数VoNR与VoLTE之间的门限、迟滞和惩罚值VoNR覆盖不足区域系统的目标不是让用户“死在NR上”而是平滑地让语音业务转由LTE承载。这涉及两个场景呼叫建立阶段的EPS Fallback以及通话保持阶段的VoNR到VoLTE切换。互操作参数调整有四个基本维度参数维度作用调整方向要点验证指标服务小区RSRP触发门限触发从NR测量LTE的起点调高则更早启动测量但过低会在弱场仍坚持VoNREPS Fallback次数、VoNR呼叫失败率目标小区质量门限选择可用的LTE目标调低能更容易找到目标但可能选中差小区切换成功率、重定向后接通率迟滞防止门限附近乒乓门限越紧迟滞应越大乒乓切换次数触发时延确认信号持续劣化过短易误判过长会拖到RLF无线链路失败率最常见的翻车是把服务小区RSRP门限压得很低让更多呼叫尝试留在VoNR里。指标表上看VoNR占比漂亮了实际用户在弱场反复建立5QI1承载失败呼叫建立时延和失败率反而变差。正确的做法是先确认VoNR业务的最低工作电平再留出至少3到5dB的余量作为门限迟滞和惩罚值用来吸收波动落地后按小时对比呼叫失败率和EPS Fallback次数。5. VoNR优化案例里反复出现的五个坑现象、原因与解决办法5.1 后台指标全绿投诉却集中爆发现象某小区话统显示接通率、掉话率均达标但客服那边收到多起“无法接通”投诉位置集中在一个商圈地下车库入口。 原因平均值把所有时段和所有栅格揉在一起劣化区域的比例被淹没。地下车库入口信号本就边缘加上早晚高峰拥塞瞬时失败被平均数盖住。 解决把统计粒度切到15分钟按栅格或按小时重出指标锁定具体时段和位置。对VoNR业务还要单独统计5QI1承载建立成功率不能只看总体接通率。这个案例提醒我任何“指标正常但投诉不断”的局面都先怀疑统计口径而不是怀疑投诉真实性。5.2 切换失败被错判成弱覆盖现象路测显示RSRP在-100dBm以上但用户通话在特定路段频繁掉线后台掉话率中无线链路失败占比高。 原因看到掉话就先猜覆盖忽视了信令里切换准备失败的记录。实测覆盖不差真正原因是邻区漏配目标小区信号好但不在邻区表里UE上报了A3测量报告却找不到可切换目标。 解决从测量报告里找被漏配小区的物理小区ID补全邻区关系再观察A3事件后的切换执行成功率。案例里如果只按“覆盖优化”去抬天线或加站问题会原样保留。这类坑最好记的一句话是掉话点附近未必是弱场更可能是切换带设计不合理。5.3 门限压太低VoNR占比上去了失败率也上去了现象为了提升VoNR语音时长占比把VoNR到VoLTE的互操作门限从-110dBm压到-118dBm调整后VoNR指标确实上升但用户投诉呼叫失败和听不见的概率同步上升。 原因门限压到了业务承载能稳定工作的电平之下弱场终端还赖在NR上尝试建承载5QI1建立成功率明显下降呼叫建立时延变长。 解决回退门限到链路预算允许的范围并重新核对VoNR业务的最低工作电平。门限的调整必须配合成功率指标做A/B对比不能只看目标指标的单一变化。这类互相打架的目标在案例复盘时要明确优先级。5.4 语音断续但RTP丢包率不高现象用户听到对方说话像“卡顿”网管统计RTP丢包率不足1%看起来媒体质量正常。 原因丢包率只统计了RTP层的丢包而语音质量下降同样可能来自大时延抖动、抖动缓冲丢弃、调度不及时或上行PUSCH BLER高。某些情况下是头压缩RoHC上下文同步失败导致的整包解不出RTP计数里查不到。 解决把RTP统计、抖动、上行BLER和MCS一起看。如果RTP丢包低但抖动超阈值核查传输时延和核心网媒体路径上行BLER偏高则回到干扰排查RoHC问题要通过终端日志确认收到但解不出的包是否存在。5.5 同一型号终端集中出问题网络怎么调都没用现象某项目组收到一批投诉用户都使用同一款新上市终端VoNR呼出时偶发无振铃网络侧所有指标正常信令跟踪也看不到失败原因。 原因终端版本实现问题表现为UE给网络的SIP消息中缺少某个必带头域或编解码协商过程中异常终止。网络侧作为被叫路径的组成部分本身没有配置错误。 解决用信令跟踪对比不同终端在同一位置的呼叫流程确认问题是否与终端型号强相关。把失效消息片段、时间戳和终端能力上报整理成文档反馈给终端厂商处理而不是在网络侧反复调参。6. 让单篇案例变成可复用能力记录模板、信令切片与参数基线案例看一遍只觉得“有道理”真正要让它在下一次派上用场得把它变成一套操作资产。我处理完一个VoNR异常后一般会补三样东西案例模板、信令切片和参数基线。模板字段固定为现象、时间地点、影响终端型号、指标证据、信令关键帧、根因分类、优化动作、效果验证、回退预案。这张模板的价值在于逼自己把“感觉修好了”写成“用什么证据证明修好了”。信令切片不需要把所有跟踪文件都存下来只保留关键消息的截图或文本片段RRCSetupComplete、PDUSessionModification响应、SIP的INVITE与失败原因值再加上时间戳和脱敏后的用户标识。下次遇到类似现象时先拿新切的信令跟旧案例比对能把排查时间省下一大半。参数基线则更讲究每次改动前记录原值、新值、修改人、修改原因和生效时间一周后回填效果。很多所谓“疑难杂症”最后都发现是某个历史参数被反复修改却没有记录。我自己带人复盘时最常说的一句话是VoNR优化里的每个“玄学”背后都有一条没被找齐的证据链。把这些案例串起来检查你会发现方法论就那么多难的是每次都把证据链走完。希望帮到你。本文还有配套的精品资源点击获取
