简介这是一份聚焦5G网络优化中VoNR端到端高掉话问题的实战排查案例适合网络优化工程师、5G核心网与无线运维人员以及通信专业学习者。案例以AA市VoNR掉话率异常升高为切入点通过大数据平台指标下钻、厂家与区县对比、信令流程追踪等方法逐步定位到诺基亚MME处理TAU与X2切换冲突、华为MSC位置更新概率性延迟、4G TDD小区语数分层功率引发二次切换等根因并给出关闭语数分层功能后的实测改善数据案例还涉及4G与5G互操作、语音业务连续性保障等场景分析过程注重从指标异常到信令根因的逐步收敛。全文以单一PDF文档呈现文件大小1.81MB内容紧凑、逻辑清晰完整覆盖问题现象、分析过程、定位结论、处理措施与效果评估。读者可从中掌握VoNR掉话类型分类、信令话单关联分析、多厂家设备协同排错、参数调整与效果验证等关键技能形成一套可复用的端到端掉话问题排查框架。目前已有499人学习值得5G网络优化从业者参考。 做5G网络优化这几年VoNR相关的语音质量问题一直是最考验功底的活。今天把最近一次VoNR端到端高掉话排查案例完整复盘一遍案例里的站点位置和设备参数都做了脱敏处理但定位思路、数据分析和处理过程是完整的。掉话率这个指标4G时代基本看覆盖、看切换就能解决八成问题但到了5G VoNR阶段语音业务从空口一路承载到IMS涉及UE终端、gNB基站、承载网、AMF/SMF/UPF核心网、P-CSCF/S-CSCF等IMS网元光盯无线侧远远不够。这篇分享适合正在做5G无线优化、核心网排障和端到端语音质量保障的同事参考看完能帮你少走不少弯路。1. 案例背景VoNR掉话率从0.2%飙到1.5%1.1 先弄明白VoNR掉话意味着什么VoNR全称Voice over New Radio是5G SA独立组网架构下的原生语音解决方案。它和VoLTE最大的区别在于VoNR的语音和视频业务直接由5G空口承载不需要回落到4G语音数据封装成IP报文经由gNB、UPF进入IMS域完成会话控制。好处显而易见呼叫建立时延更低、音质更好、视频通话体验也更流畅而且语音和数据可以同时跑在5G网络上不会出现“打电话就断网”的情况。但VoNR也有让人头疼的地方——它把传统语音网络的质量问题从单一无线域扩散到了“无线传输核心网IMS”全链路。任何一个节点配置不当表面现象都可能是一个简单的“掉话率高”。掉话率的定义是在语音业务建立成功后通话过程中因为非用户主动挂断原因导致的连接中断占所有成功建立呼叫次数的比例。网络侧通常要求VoNR掉话率控制在0.5%以下一旦超过这个线用户就会明显感知到“说着说着就断了”投诉量也会跟着涨。1.2 问题现象和数据画像这次的问题区域集中在两个商圈加三个居民小区我接到任务时后台KPI统计显示区域VoNR掉话率已经连续一周走高从正常状态的0.2%左右攀升到1.5%以上峰值时段甚至到了2.8%。更难受的是投诉用户反馈比较零散不是集中在某一个基站但仔细看投诉地址又都分布在同一批小区覆盖范围内。我先把掉话率按照小时粒度、站点粒度、终端型号三个维度做了拆解发现三个规律第一掉话高峰集中在每天晚高峰19点到22点之间第二涉及站点大约有7个分布范围比较散第三同一站点下不同终端型号的掉话率差异非常大某头部品牌旗舰机型的掉话率明显高于平均水平。我当时的直觉是这可能不是简单的覆盖问题因为如果覆盖差掉话应该全天都有而且不会挑终端品牌。第一轮指标对比简单列出来是这样的指标维度正常状态异常状态差异特征VoNR掉话率0.2%以下1.5%~2.8%晚高峰明显抬升无线掉话率0.1%以下0.3%以下无明显劣化RRC重建率0.5%以下0.6%左右略微升高切换成功率99.8%以上99.5%以上基本正常5G驻网时长稳定稳定无频繁回落现象从这个表能看出来无线侧的指标并没有崩但VoNR业务确实在掉。这种情况如果按照传统思路“先优化覆盖、再调切换”大概率会白忙活好几天。接下来必须把视角从空口往上提做一次端到端的排查。2. 端到端排查思路把语音链路拆成四段2.1 端到端链路的完整构成VoNR呼叫一条完整的信令和媒体链路拆开看大概是这样的用户手机发起呼叫后语音控制面消息从gNB通过AMF进入5G核心网再路由到IMS域处理语音媒体面则走gNB到UPFUPF把RTP音频流转发给IMS侧的策略和计费网元最终完成主叫和被叫之间的媒体协商。通俗点说手机是“嘴巴”基站和核心网是“传输管道”IMS是“总机室”任何一个环节疲劳或堵车通话都会出问题。我把这条链路拆成四段来排查无线接入段UE到gNB重点看下行/上行覆盖、干扰、切换、RRC重建、QoS Flow的建立成功率、空口时延和丢包。承载传输段gNB到UPF重点看传输时延、抖动、丢包率特别是语音这种对时延敏感的业务传输抖动大了直接表现为“吞字”和“断续”。核心网控制面段AMF、SMF、PCF等网元重点看注册、鉴权、会话建立、策略下发是否正确QoS Flow参数是否按预期生效。IMS语音域P-CSCF、S-CSCF、TAS等IMS网元重点看SIP信令交互、媒体协商结果、编解码协商以及网络侧主动释放的触发条件。这里要提一个VoNR和4G语音不太一样的细节4G VoLTE的QoS承载比较直接QCI1的承载建立完成后基本就不变了但VoNR里引入了QoS Flow和DRB的映射关系QoS Flow是在核心网侧定义的DRB是空口侧的无线承载两层之间是需要一一绑定的。如果SMF下发的QoS Flow参数和gNB实际分配的DRB资源不匹配语音包在空口侧就可能被错误调度轻则MOS下降重则直接掉话。我在排查时专门把QoS Flow和DRB的映射关系拉出来做了比对确保没有错配。2.2 数据采集和三步分层法端到端排查最怕无头苍蝇一样乱抓数据。我的习惯是三步走第一步先做“横向指标对比”。把所有相关站点、小区、网元按小时粒度的掉话率、RRC重建率、切换成功率、QoS Flow建立成功率拉出来和正常站点做对比缩小问题范围。第二步做“纵向信令下钻”。锁定问题站点后选几个典型掉话小区现场路测和核心网信令跟踪同步进行。路测软件抓空口日志信令跟踪平台抓SIP和HTTP/2信令两边用统一的时间源对齐找出掉话的准确时间点和触发释放的信令消息。第三步做“用户面质量回溯”。控制面信令只能告诉我们“通话被释放了”但没法告诉我们“为什么被释放”。这时候要看语音媒体面的实时传输质量包括RTP包的抖动、时延、丢包率、RTCP XR反馈。很多掉话其实是媒体面先劣化到极限然后在某个时间点触发了IMS侧的主动释放。排查中需要准备的数据采集工具和材料包括后台性能指标平台、路测软件及测试终端、核心网信令跟踪平台、用户面抓包工具能抓UDP/RTP流就可以。关键一点是核心网信令必须能关联到具体用户的IMSI和语音呼叫否则路测打了两小时电话信令侧对不上号效率会非常低。3. 根因定位核心网策略惹的祸3.1 无线侧排查排除了覆盖和切换嫌疑先把无线侧的原因排除掉。我带着测试终端在问题区域跑了三轮回测分别在早上平峰、下午闲时、晚高峰时段做长时间VoNR通话保持测试同时采集空口日志和核心网信令。无线指标的结果是RSRP全程在-90dBm左右SINR大部分时间都在20dB以上可以说覆盖和干扰都非常健康。测试过程中preamble检测、RRC建立、QoS Flow建立全部正常没有出现RRC重建也没有发生异系统切换。后台切换成功率统计也是99.6%以上说明候选邻区关系配置和切换参数并没有明显问题。有意思的地方在于即使现场信号很好晚高峰时段打电话仍然会出现某几通电话在通话持续40到60秒后突然中断。这时候我基本排除了纯无线覆盖原因如果是因为覆盖差或者干扰导致的无线链路失败掉话前应该能观察到上行失步、下行失步或者连续N个NACK的消息但日志里都没有。掉话更像是一个“定时器”到点触发的而不是链路“突然死亡”。3.2 信令分析BYE消息暴露了释放方接下来的重点是核心网和IMS侧。从信令跟踪平台抓到的SIP消息看掉话的通话流程高度一致呼叫建立成功双方正常进入通话态持续40到60秒后P-CSCF网元向S-CSCF发出了BYE请求SIP响应里携带的原因值指向“媒体资源异常/承载质量不满足要求”。这个BYE消息非常关键。正常用户挂机BYE的发起方是UE网络侧释放要看是哪一个网元发起的。在这个案例里P-CSCF主动发出BYE说明问题出在IMS语音域的媒体质量监控机制上而不是用户侧或无线侧。再结合RTCP XR反馈数据看掉话前两三秒媒体面的RTP丢包率快速飙升到5%以上音频MOS评分从4.0左右直接跌到2.5以下。IMS侧的策略逻辑是如果媒体面质量低于门限持续一段时间就会判定这次呼叫“无法保障用户体验”主动释放会话。这说明掉话的本质是媒体面质量差而不是语音控制面故障。那问题就变成了为什么无线信号好、RTP丢包率还会飙升顺着这个思路继续查我翻看了SMF和PCF下发的QoS策略参数。在VoNR策略模板中5QI1语音承载的保证比特率GFBR和最大比特率MFBR虽然显示已配置但实际下发的GFBR值比我预期的低不少而且语音专用DNN的会话聚合最大比特率Session-AMBR也被策略模板限制得比较死上下行加起来只有几百kbps。更麻烦的是同一份策略同时适配给数据业务和语音业务没有做语音DNN的差异化保障。这意味着什么简单说语音流量在核心网侧被“限速”了。当用户同时在5G网络上有数据业务跑着或者无线侧因为调度资源紧张导致语音包的优先级没有真正拉起时RTP包在用户面转发时会排队、重传甚至丢弃。RTP丢包率一高IMS侧质量监控就会触发BYE于是表现为VoNR高掉话。3.3 参数确认与修改细节为了确认这个推断我抓取了问题小区下某次掉话前后的用户面速率曲线发现RTP流的实际速率确实在某一时刻被“削顶”了——语音码率加IP报文头本来需要约50kbps左右但因为AMBR受限UPF在转发时对RTP流做了限速导致语音包被丢弃。我随后调取了PCF策略模板和SMF会话管理配置重点核对三处第一处是5QI1承载的GFBR/MFBR设置。语音编码采用AMR-WB的情况下实际音频码率一般不超过24kbps但加上RTP/UDP/IP报文头之后如果不启用ROHC头压缩每20ms一个语音包会产生额外的40到60字节开销实测速率轻松超过50kbps。GFBR如果按照64kbps甚至48kbps配置遇到空口调度紧张或者同时有大数据业务并发很容易保障不了。第二处是语音DNN的Session-AMBR。这个值代表了用户在这个DNN上所有承载的总速率上限如果设置得太小即使5QI1承载的GFBR够也没有用其他数据流量会把总速率顶到上限语音包照样被限制。第三处是IMS侧的媒体质量监控门限。P-CSCF和MRF媒体资源功能侧会对RTCP XR上报和SIP事件包做实时统计一旦丢包率或者抖动超过门限且持续一定时间就触发呼叫释放。实际处理时不能只看门限数值还要看统计窗口长度窗口太短容易被瞬时抖动误触发。基于这些分析我修改了三类参数名称不同厂家略有差异但核心逻辑一致适当上调5QI1语音承载的GFBR/MFBR给足语音DNN的带宽余量打开语音DNN与数据DNN的差异化策略保证语音流量在UPF转发队列里始终有高优先级IMS侧媒体质量监控的时间窗口从2秒延长到5秒避免瞬时网络波动导致IMS直接释放呼叫。4. 优化实施与效果验证4.1 参数调整落地参数修改不是改完就结束要分层验证。我先把修改后的策略模板下发到一个问题最严重的小区做灰度验证这个小区掉话率之前最高到过4.8%。灰度验证期间我安排在早、中、晚三个时段各做一轮长时间VoNR保持测试每轮连续拨打60通电话每通保持2分钟以上。测试结束后统计掉话情况并同步拉取核心网SIP信令做二次确认。结果比较明显灰度小区的掉话率从4.8%降到了0.3%以内60通测试电话只出现了一次掉话而那一次掉话恰好发生在终端切换的瞬间怀疑和切换带覆盖有关和核心网策略已经无关。RTP丢包率也从之前的2%到5%恢复到0.5%以下MOS均值回到了3.8以上。4.2 全网KPI复测灰度验证通过之后把策略模板向全网同配置站点推广。在推广后的连续一周观察期内区域VoNR掉话率稳定在0.15%到0.2%之间晚高峰峰值也不再超过0.5%。用户投诉量同步减少原先集中投诉的几个小区再没有新增语音质量投诉。这里有一个经验要分享网络优化中对参数做修改一定要留好“退出机制”。这次我修改的PCF策略模板和SMF会话参数都保留了原始配置文件方便随时回退。因为策略模板一旦涉及多个站点和网元影响面会比预想的大出问题时逐条回退比重新排查快得多。5. 常见问题与排查技巧实录5.1 排查中容易踩的四个坑第一个坑是“无线指标没问题就怀疑终端”。在这个案例里不同终端掉话率差异大是因为不同终端对ROHC头压缩的支持度不一样支持ROHC的终端RTP报文头被压缩实际空口占用小不容易触发限速不支持ROHC的终端语音包大更容易撞到AMBR上限。如果只看终端差异就判定为终端问题方向就偏了。第二个坑是“只盯SIP控制面信令”。SIP信令只能告诉你谁释放了呼叫但真正的原因往往在媒体面。开始排查的时候如果能看到媒体面的RTP丢包和抖动同步劣化就能少走很多弯路。所以建议在做端到端排障时控制面信令和用户面质量必须同时抓、同时看。第三个坑是“信令时间戳对不齐”。无线侧日志、核心网信令、路测软件这三者的时间源如果不一致掉话现象和信令消息就会出现几十秒甚至几分钟的时间差导致错误的因果判断。实际操作时我会先用一次短呼叫确认三边时间对齐再开始长时间测试。第四个坑是“忽略了策略模板的全局影响”。这次根因产生的直接原因是策略模板没有区分语音DNN和数据DNN所有业务共用一套QoS参数导致语音的优先级没有真正保障。排查时如果只查单一网元的参数很容易漏掉策略层面的配置问题。我处理过不止一次VoNR掉话最后根因都落在核心网策略模板上建议大家遇到无线指标正常但VoNR掉话率异常时第一时间查PCF策略模板和SMF会话参数。5.2 几条可复用的实操经验做VoNR端到端优化我有几个固定的动作每次都能快速缩小排查范围。第一先把“掉话时间点分布”列出来。如果掉话集中在通话建立后某一段固定时间比如30秒、60秒那大概率是定时器或者策略触发而不是随机无线链路失败如果掉话时间非常随机才优先查覆盖和干扰。第二看掉话前5秒的用户面质量数据。RTP丢包率、时延均值、抖动均值这三个指标基本能把问题定位在空口还是核心网。空口问题通常伴随高误块率和上行失步核心网限速问题则表现为RTP流在实际速率上出现明显的“削顶”现象。第三遇到多网元协同的问题要善用核心网信令跟踪平台的关键字过滤功能。以IMSI或MSISDN为关联键把SIP、HTTP/2信令和用户面日志串在一起能快速还原一次呼叫从建立到释放的完整过程。说实话这次案例真正卡住我的地方不算多但反思下来最大的启发是在VoNR时代“端到端”三个字不是口号而是每次排障都必须践行的思路。无线工程师不能只盯着空口核心网工程师也不能只盯信令大家得会用同一种语言描述同一段“通话为什么断了”。最后再分享一个小技巧如果你也是无线和核心网联合排查把两侧的告警窗口和指标统计粒度统一到同一时区、同一分钟级别前期准备工作做得越细后面定位的速度就越快。这个习惯帮我省了不知道多少沟通成本值得长期坚持。本文还有配套的精品资源点击获取