企业官网建设流程全解析

简介：这是一份聚焦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业务确实在掉。这种情况如果按照传统思路“先优化覆盖、再调切换”，大概率会白忙活好几天。接下来必须把视角从空口往上提，做一次端到端的排查。

2. 端到端排查思路：把语音链路拆成四段

2.1 端到端链路的完整构成

VoNR呼叫一条完整的信令和媒体链路，拆开看大概是这样的：

用户手机发起呼叫后，语音控制面消息从gNB通过AMF进入5G核心网，再路由到IMS域处理；语音媒体面则走gNB到UPF，UPF把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承载比较直接，QCI=1的承载建立完成后基本就不变了；但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策略模板中，5QI=1语音承载的保证比特率GFBR和最大比特率MFBR虽然显示已配置，但实际下发的GFBR值比我预期的低不少，而且语音专用DNN的会话聚合最大比特率Session-AMBR也被策略模板限制得比较死，上下行加起来只有几百kbps。更麻烦的是，同一份策略同时适配给数据业务和语音业务，没有做语音DNN的差异化保障。

这意味着什么？简单说，语音流量在核心网侧被“限速”了。当用户同时在5G网络上有数据业务跑着，或者无线侧因为调度资源紧张导致语音包的优先级没有真正拉起时，RTP包在用户面转发时会排队、重传甚至丢弃。RTP丢包率一高，IMS侧质量监控就会触发BYE，于是表现为VoNR高掉话。

3.3 参数确认与修改细节

为了确认这个推断，我抓取了问题小区下某次掉话前后的用户面速率曲线，发现RTP流的实际速率确实在某一时刻被“削顶”了——语音码率加IP报文头本来需要约50kbps左右，但因为AMBR受限，UPF在转发时对RTP流做了限速，导致语音包被丢弃。我随后调取了PCF策略模板和SMF会话管理配置，重点核对三处：

第一处是5QI=1承载的GFBR/MFBR设置。语音编码采用AMR-WB的情况下，实际音频码率一般不超过24kbps，但加上RTP/UDP/IP报文头之后，如果不启用ROHC头压缩，每20ms一个语音包会产生额外的40到60字节开销，实测速率轻松超过50kbps。GFBR如果按照64kbps甚至48kbps配置，遇到空口调度紧张或者同时有大数据业务并发，很容易保障不了。

第二处是语音DNN的Session-AMBR。这个值代表了用户在这个DNN上所有承载的总速率上限，如果设置得太小，即使5QI=1承载的GFBR够也没有用，其他数据流量会把总速率顶到上限，语音包照样被限制。

第三处是IMS侧的媒体质量监控门限。P-CSCF和MRF（媒体资源功能）侧会对RTCP XR上报和SIP事件包做实时统计，一旦丢包率或者抖动超过门限且持续一定时间，就触发呼叫释放。实际处理时不能只看门限数值，还要看统计窗口长度，窗口太短容易被瞬时抖动误触发。

基于这些分析，我修改了三类参数，名称不同厂家略有差异，但核心逻辑一致：适当上调5QI=1语音承载的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时代，“端到端”三个字不是口号，而是每次排障都必须践行的思路。无线工程师不能只盯着空口，核心网工程师也不能只盯信令，大家得会用同一种语言描述同一段“通话为什么断了”。

最后再分享一个小技巧：如果你也是无线和核心网联合排查，把两侧的告警窗口和指标统计粒度统一到同一时区、同一分钟级别，前期准备工作做得越细，后面定位的速度就越快。这个习惯帮我省了不知道多少沟通成本，值得长期坚持。

本文还有配套的精品资源，点击获取