尧图网页设计 
简介这是一份面向5G网络优化工程师与核心网维护人员的实战案例资料以某市VoNR端到端掉话率异常升高为背景完整展示从大数据平台指标下钻、厂家区县对比、SEQ信令追踪到问题根因确认与优化验证的排查闭环。资源为PDF文档共1个文件约1.81MB便于阅读与打印目前已有499人学习下载。案例重点剖析了注册超时类掉话的产生机制包括诺基亚MME在TAU与X2切换冲突时直接返回失败、华为MSC位置更新流程概率性时延过长以及4G TDD语数分层功率触发二次切换等关键问题。同时记录了关闭语数分层功能后VoNR掉话率从0.24%下降至0.08%、E-RAB掉线率从0.05%改善至0.02%的实际效果并对EPSFB回落成功率、VoLTE质差等指标做了对比评估。通过信令字段、A4事件门限和功率参数的逐项核查读者可快速建立跨厂家设备环境下5G语音优化的排查思路是理解VoNR切换到VoLTE流程冲突与优化策略的实用参考对一线网优工程师和技术管理者的日常排障与方案决策均有参考价值。1. 案例开局VoNR高掉话问题现象与网络背景分析1.1 投诉现象与指标确认先说说背景。这个案例发生在某市区5G连续覆盖区域核心问题是VoNRVoice over New Radio5G新通话端到端掉话率持续偏高全网统计掉话率一度超过5%而同期VoLTE掉话率只有0.3%左右。用户感知层面的投诉主要集中在通话中断、听不清、需要重拨这几个典型症状投诉量占当月语音类投诉的六成以上。拿到问题后第一步不是急着翻参数而是先确认问题是真的还是指标统计口径出了问题。我当时的操作分三步走先要一周的KPI明细按天、按小区粒度拉出掉话率、ERAB异常释放次数、VoNR话务量其次抽查投诉用户的通话详单确认掉话发生的时间和所在小区最后做了一次路测和CQT拨打测试实测复现掉话现象。三步走完掉话率高这个结论基本坐实而且发现一个规律——掉话集中在每天早晚高峰时段地点集中在两个连续覆盖的宏站交界区域。这里有个容易踩的坑VoNR掉话率指标在很多厂家的计数器里口径不统一。有的厂家把QoS Flow释放也算语音掉话有的只算ERAB异常释放有的把切换失败导致的释放单独归类。如果你不看原始计数器定义直接拿网管指标对比很容易被误导。所以拿到高掉话指标的第一件事永远是先确认指标口径再往下排查。1.2 告警与参数维度初排确认问题真实存在后我开始从告警和参数两个基础维度做初步筛查。告警方面把涉及区域的所有gNodeB5G基站、UPF用户面功能、SBC会话边界控制器、IMS核心网设备全部拉一遍历史告警重点看有没有硬件故障、传输闪断、License超限这类会导致语音承载异常的问题。筛查结果比较干净除了一个基站有一块基带板曾经上报过热告警但已自动恢复外没有发现持续性的硬件故障。参数维度重点核查了VoNR相关的关键配置包括QoS Flow的5QI标识、ARP优先级、切换参数、DRX非连续接收周期、SRS配置等。这里要特别说明一个关键点5G VoNR的QoS映射和4G VoLTE有本质区别。VoLTE走QCI 1承载一路语音一个专用承载结构相对简单而VoNR是QoS Flow模型语音业务映射到5QI 1的QoS Flow上和默认承载、其他数据Flow之间的优先级关系、反射QoS映射、SDAP层的映射关系都会影响语音质量。我在核查中发现一个可疑点部分小区的RRC重建比例明显偏高这说明空口侧可能存在系统性异常。这个阶段排查下来初步判断问题大概率出在移动性管理环节也就是切换相关的配置或流程上但还缺少直接证据需要深入到信令层面进一步定位。2. 端到端逐段定位与根因锁定2.1 空口侧弱覆盖、干扰与切换分析空口侧排查是整个端到端分析里最耗时但也最关键的一环。VoNR语音业务对空口质量的要求比数据业务苛刻得多数据业务可以靠HARQ重传兜底语音业务是实时业务重传次数有限一旦空口质量恶化直接表现就是RTP丢包率上升、抖动增大严重时触发掉话。我先拿了问题区域的MR测量报告数据统计RSRP参考信号接收功率分布和SINR分布。从MR数据看问题区域的RSRP均值在-98dBm左右SINR均值在8dB左右整体不算特别差但边缘区域的采样点占比明显偏高RSRP低于-110dBm的采样点超过了10%。这个数据说明覆盖不算重度弱覆盖但处于“亚健康”状态语音业务在这种环境下很容易出问题。干扰方面我拉取了问题区域的上行干扰底噪数据发现一个基站的某几个小区在特定时段存在明显的上行干扰抬升底噪从-120dBm抬升到-105dBm左右。排查后发现是该站周边存在一个未加屏蔽的直放站设备产生带外杂散干扰。这里要提醒各位干扰排查一定不要只看网管平均指标要按PRB粒度去分析干扰底噪的分布特征。如果是全频段干扰抬升大概率是外部干扰源如果只是特定PRB抬升要考虑帧结构配置或邻区干扰。切换分析是空口侧的重中之重。我提取了问题区域的切换统计包括切换请求次数、切换成功率、切换失败原因。数据显示同站切换和站间切换成功率都正常但是分布在两个宏站交界区域的切换次数特别高一天下来单个小区切换请求次数超过两万次。这本身就是个隐患——切换越频繁失败的绝对次数就越多掉话的概率自然就上去了。2.2 核心网侧PDU会话与QoS Flow状态核查空口侧排查结束后我把重点转向核心网。VoNR通话不仅仅涉及空口和基站还涉及完整的5GC5G核心网信令链路。一个典型的VoNR呼叫流程是UE发起PDU会话建立请求→AMF接入和移动性管理功能处理注册和会话管理→SMF会话管理功能选择UPF并建立用户面通道→IMS域完成SIP信令交互和媒体面协商→语音数据流经gNodeB→UPF→IMS网络传输。核心网侧排查我关注三个层面第一是PDU会话建立成功率第二是QoS Flow的建立和修改流程第三是N2接口gNodeB与AMF之间和N3接口gNodeB与UPF之间的信令交互是否正常。从信令跟踪数据看PDU会话建立成功率基本在99.5%以上没有异常。但我在分析QoS Flow修改流程时发现了一个值得注意的细节部分VoNR呼叫在建立语音QoS Flow时经历了多次QoS Flow修改过程正常情况下语音Flow应该在通话开始时一次性建立成功并保持稳定但这些异常呼叫在通话过程中反复触发QoS Flow修改每次修改都伴随短暂的媒体面中断。RTP丢包率在通话过程中的波动情况和QoS Flow修改的节奏高度相关。这让我怀疑问题不只是空口核心网在QoS Flow管理策略上可能有配置偏差。进一步核查SBI接口服务化接口上的Nsmf_PDUSession_UpdateSMContext消息发现SMF在部分场景下会触发QoS Flow的重建或修改这直接导致了通话质量的短暂劣化。2.3 IMS域与SIP信令深度关联分析IMS域排查是整个端到端分析中信息量最大的环节。VoNR的呼叫控制层完全依赖IMS终端发起呼叫后SIP信令会经过P-CSCF代理呼叫会话控制功能、S-CSCF服务呼叫会话控制功能等网元完成呼叫路由和会话控制。掉话问题的IMS侧分析核心是看SIP消息中的BYE消息或Session Timer超时记录。我把问题区域所有掉话话单中的SIP信令拉出来逐一分析重点看两条线索一是掉话前最后一条SIP消息是什么二是媒体面RTP流的收发方向和丢包统计。分析结果很有意思相当一部分掉话案例中SIP层面没有收到BYE消息也没有正常的会话释放流程。也就是说这条语音通话是在承载层静默中断的两边终端都不知道对方已经不可达直到RTP超时后各自触发本地释放。这种“沉默中断”现象说明问题出在承载层面也就是QoS Flow或用户面传输链路而不是IMS业务逻辑本身。我把SIP信令和基站侧的用户面数据做时间对齐发现了一个规律性现象每次掉话前大约2-3秒N3接口上该用户的GTP-UGPRS隧道协议用户面隧道会出现短暂的数据中断或巨大时延抖动紧接着RTP丢包率飙升然后通话掉线。到这里根因范围已经从“泛泛的端到端问题”缩小到了“N3接口用户面传输链路”嫌疑集中在传输网络或UPF转发链路上。2.4 根因锁定传输链路丢包与转发异常复现为了进一步确认N3接口的传输状况我组织了一次针对性的联通测试。方法很简单粗暴在问题区域的基站侧挂一台测试终端发起VoNR呼叫并保持通话同时在基站侧和UPF侧分别做端口镜像抓包然后对比分析GTP-U隧道两端的报文收发序列号和时间戳。测试结果印证了之前的判断基站侧发出的GTP-U报文和UPF侧收到的GTP-U报文之间存在不连续的序列号跳跃说明传输链路有丢包。更关键的是我在UPF侧抓到的报文里发现了重传和乱序现象而且乱序的规律不是随机出现的而是呈周期性爆发大概每隔几十秒出现一次。这个周期性特征让我把怀疑对象指向了传输设备的队列调度策略。我们顺着链路逐跳排查传输设备最终定位到一台汇聚交换机上——该交换机上配置了针对特定业务流的QoS策略但策略的队列带宽设置不合理语音流的优先级队列被分配了极小的带宽当承载语音流的物理链路出现瞬时拥塞时语音报文就会被大量丢弃。到这里根因链完整闭合承载VoNR语音流的物理链路存在周期性瞬时拥塞汇聚交换机QoS队列调度不合理导致语音GTP-U报文被过度丢弃N3接口丢包触发RTP质量劣化最终表现为VoNR端到端高掉话。3. 端到端优化方案设计与落地实施3.1 传输侧QoS策略调整根因明确后方案设计就变得有的放矢了。最直接、见效最快的措施是调整汇聚交换机的QoS策略。语音业务在5G网络里对应5QI 1VoNR语音、5QI 2VoNR语音实时视频端到端承载时需要在传输设备上识别这些优先级并进行差异化调度。调整思路是这样的在汇聚交换机上为VoNR语音流量单独划分一个高优先级队列配置严格优先级调度确保语音报文在任何拥塞场景下都能优先转发。同时对语音流量做流量监管超出预期带宽的语音流量不丢弃而是重新标记为低优先级避免恶意或异常流量挤占语音队列。配置完成后我安排了一次压力测试在语音链路叠加人为背景流量观察通话质量变化。测试结果表明语音MOS分平均意见分衡量语音质量的指标在背景流量达到链路带宽90%时仍能保持在4.0以上而调整前同等条件下MOS分会跌到2.5以下甚至掉话。另外针对周期性的瞬时拥塞我把传输链路的缓存策略也做了优化。具体做法是增大语音所属队列的缓存深度配合WRED加权随机早期检测算法用轻微的队列时延换取更低的丢包率。语音业务对时延敏感但对瞬时突发有容忍度这个权衡在实测中效果不错。3.2 无线侧参数优化与切换策略调整传输侧解决的是“管道”问题无线侧还要解决“源头”问题。前面提到问题区域的切换过于频繁这是导致切换失败绝对次数偏高的直接原因。我在无线侧做了三个方面的参数优化。第一是切换门限调整。原配置中A3事件的幅度偏置设置过小导致终端在信号质量还可以的情况下就频繁触发切换。我把A3事件的幅度偏置从2dB调整为3.5dB同时调整了切换迟滞参数让终端在信号变化较小时不轻易触发切换减少不必要的切换次数。参数调整后问题区域日切换请求次数从两万多次下降到了一万三千次左右降幅约35%。第二是MLB移动负载均衡参数校准。检查发现部分小区开了MLB后为了均衡负载把一个边缘用户成批地往邻区赶这些用户到了邻区往往信号质量不理想反而埋下掉话隐患。我把MLB的负载差阈值从20%提高到35%让负载均衡策略更保守一些只有当小区间负载差异明显时才触发迁移。第三是上行干扰处理。针对之前发现的直放站干扰源协调相关单位关闭了问题设备上行干扰底噪从-105dBm恢复到了-118dBm左右干扰消除后上行语音质量有了明显改善。这里要补充一个经验VoNR语音对上行干扰尤其敏感因为语音业务的上行发射功率有限干扰抬升会直接影响eNodeB侧的语音信号解调质量。干扰排查应该作为VoNR优化的一项常态化工作来做。3.3 端到端监控体系建设方案落地后我同步搭建了一套面向VoNR业务的端到端监控体系目的不是解决眼前的掉话而是下次出现类似问题时能快速定位。监控体系的思路是把无线侧、传输侧、核心网侧和IMS侧的关键指标统一到一个看板上。无线侧关注掉话率、RRC重建比例、切换成功率、MR覆盖分布传输侧关注N3接口丢包率、时延、抖动和队列丢弃计数核心网侧关注PDU会话建立成功率、QoS Flow建立成功率、N2/N3接口信令时延IMS侧关注SIP信令成功率、BYE消息分布、RTP丢包率。这套监控体系最大的价值在于跨域关联。以前无线侧说无线没问题、传输侧说传输没问题、核心网说核心网没问题最后问题悬在空中没人负责。现在有了统一的端到端指标关联分析方法任何一个环节出现异常都能通过指标相关性快速缩小排查范围。比如N3接口的丢包率和RTP丢包率如果强相关基本可以判断问题出在传输链路如果RTP丢包率升高而N3接口丢包率没有变化就需要把注意力放到无线空口或IMS媒体面。4. 常见问题速查与排查工具清单4.1 VoNR掉话根因速查表端到端排查最大的难点不是某一个环节有多复杂而是端到端涉及的网络层级太多。为了便于日常排查快速参照我把VoNR掉话常见原因整理成了一张速查表。注意实际排查时先确认指标口径再按“空口→传输→核心网→IMS”的顺序逐段排查避免东一榔头西一棒子。问题环节常见原因关键特征排查手段空口覆盖弱覆盖/盲区MR中RSRP-110dBm占比高RS-SINR差MR数据、路测、覆盖规划空口干扰外部干扰/邻区干扰上行底噪抬升特定PRB干扰干扰底噪扫描、频谱分析移动性切换参数不合理、频繁切换切换失败率高、切换次数异常切换统计、A3事件参数核查传输链路QoS队列配置不合理、物理链路拥塞N3接口丢包率周期性升高端口镜像抓包、GTP-U序列号分析用户面UPF转发异常、GTP-U隧道老化单用户丢包率与N3丢包率非同步变化UPF日志、GTP-U隧道状态核查IMS域SBC媒体转发异常、SIP超时配置SIP层无正常释放媒体面先中断SIP信令跟踪、媒体流分析终端侧VoNR开关异常、终端协议栈缺陷特定终端型号集中掉话终端日志、型号维度统计这张表看起来简单但每一条背后都有真实的排查案例支撑。比如“特定终端型号集中掉话”这种情况在端到端排查里非常容易被忽略建议所有VoNR掉话分析第一步就按终端型号、芯片平台做交叉维度统计能省掉大量排查时间。4.2 排查工具和信令分析方法端到端排查离不开工具支撑。基站侧用厂家网管系统采集MR、切换、干扰等无线侧数据传输侧用端口镜像配合Wireshark分析GTP-U协议重点看序列号连续性和时间戳核心网侧通过AMF/SMF网元的信令跟踪功能抓取N1/N2/N4接口消息IMS侧通过P-CSCF/S-CSCF的SIP日志分析呼叫流程。信令分析里有一个实用的经验把不同接口的消息用时间对齐后放在同一个时间轴上分析比单独看某个接口的消息要有用得多。比如你把基站侧的N2接口信令、N3接口的GTP-U数据、IMS侧的SIP消息和终端侧的日志放在同一个时间轴上对比掉话发生前几秒每个环节发生了什么一目了然。我在本案例中就是用这个方法一次性看到了“传输丢包→RTP质量劣化→承载中断→SIP超时释放”的完整因果链条。Wireshark分析GTP-U时过滤语法可以参考这个示例# 过滤特定用户的GTP-U流量假设TEID为0x12345678 gtpu.teid 0x12345678 # 过滤包含丢包重传特征的GTP-U报文 gtpu tcp.analysis.retransmission # 按GTP-U隧道ID统计流量 gtpu frame.time_relative 120 frame.time_relative 180另外推荐大家养成记录排查日志的习惯。每次掉话问题处理完把现象、根因、处理措施、验证结果整理成结构化文档时间长了就形成了自己的知识库。很多看似新的问题翻翻以前的案例记录往往能直接找到思路。5. 一些操作心得和后续工作建议这套端到端排查方法跑通之后我再处理VoNR类问题就有了更清晰的路径依赖。但我还是想补充一个在项目中得到的教训很多人遇到掉话第一反应就去调无线参数这在多数情况下没错但如果根子在上层网络无线参数怎么调都是隔靴搔痒。本案例就是一个典型例子——无线侧指标看起来确实“有点问题”但真正的决定性因素在传输侧。端到端分析这个方向本身不是口号而是确实要有方法、有工具、有跨域联动机制去支撑。关于VoNR优化还想再多说一句。5G语音业务虽然已经商用多年但VoNR的体验优化和VoLTE时代比复杂度是有增无减的。核心原因在于5G网络的云化架构让信令路径更长、涉及网元更多、虚拟化环境带来的不确定性也更多。这意味着优化人员不能只懂无线还得懂传输、懂核心网、懂IMS。这既是挑战也是这个岗位的护城河。后续如果条件允许我建议在现有监控体系基础上引入用户感知层面的自动关联分析把QoE体验质量指标和网络KPI实时关联起来一旦出现用户感知劣化就能自动回溯对应的网络事件进一步缩短故障定位时间。这个方向目前已经有现成的平台能力可以对接剩余的更多是数据模型和业务规则沉淀的工作。本文还有配套的精品资源点击获取 VoNR端到端掉话排查实战：从QoS队列到传输链路的根因定位
简介这是一份面向5G网络优化工程师与核心网维护人员的实战案例资料以某市VoNR端到端掉话率异常升高为背景完整展示从大数据平台指标下钻、厂家区县对比、SEQ信令追踪到问题根因确认与优化验证的排查闭环。资源为PDF文档共1个文件约1.81MB便于阅读与打印目前已有499人学习下载。案例重点剖析了注册超时类掉话的产生机制包括诺基亚MME在TAU与X2切换冲突时直接返回失败、华为MSC位置更新流程概率性时延过长以及4G TDD语数分层功率触发二次切换等关键问题。同时记录了关闭语数分层功能后VoNR掉话率从0.24%下降至0.08%、E-RAB掉线率从0.05%改善至0.02%的实际效果并对EPSFB回落成功率、VoLTE质差等指标做了对比评估。通过信令字段、A4事件门限和功率参数的逐项核查读者可快速建立跨厂家设备环境下5G语音优化的排查思路是理解VoNR切换到VoLTE流程冲突与优化策略的实用参考对一线网优工程师和技术管理者的日常排障与方案决策均有参考价值。1. 案例开局VoNR高掉话问题现象与网络背景分析1.1 投诉现象与指标确认先说说背景。这个案例发生在某市区5G连续覆盖区域核心问题是VoNRVoice over New Radio5G新通话端到端掉话率持续偏高全网统计掉话率一度超过5%而同期VoLTE掉话率只有0.3%左右。用户感知层面的投诉主要集中在通话中断、听不清、需要重拨这几个典型症状投诉量占当月语音类投诉的六成以上。拿到问题后第一步不是急着翻参数而是先确认问题是真的还是指标统计口径出了问题。我当时的操作分三步走先要一周的KPI明细按天、按小区粒度拉出掉话率、ERAB异常释放次数、VoNR话务量其次抽查投诉用户的通话详单确认掉话发生的时间和所在小区最后做了一次路测和CQT拨打测试实测复现掉话现象。三步走完掉话率高这个结论基本坐实而且发现一个规律——掉话集中在每天早晚高峰时段地点集中在两个连续覆盖的宏站交界区域。这里有个容易踩的坑VoNR掉话率指标在很多厂家的计数器里口径不统一。有的厂家把QoS Flow释放也算语音掉话有的只算ERAB异常释放有的把切换失败导致的释放单独归类。如果你不看原始计数器定义直接拿网管指标对比很容易被误导。所以拿到高掉话指标的第一件事永远是先确认指标口径再往下排查。1.2 告警与参数维度初排确认问题真实存在后我开始从告警和参数两个基础维度做初步筛查。告警方面把涉及区域的所有gNodeB5G基站、UPF用户面功能、SBC会话边界控制器、IMS核心网设备全部拉一遍历史告警重点看有没有硬件故障、传输闪断、License超限这类会导致语音承载异常的问题。筛查结果比较干净除了一个基站有一块基带板曾经上报过热告警但已自动恢复外没有发现持续性的硬件故障。参数维度重点核查了VoNR相关的关键配置包括QoS Flow的5QI标识、ARP优先级、切换参数、DRX非连续接收周期、SRS配置等。这里要特别说明一个关键点5G VoNR的QoS映射和4G VoLTE有本质区别。VoLTE走QCI 1承载一路语音一个专用承载结构相对简单而VoNR是QoS Flow模型语音业务映射到5QI 1的QoS Flow上和默认承载、其他数据Flow之间的优先级关系、反射QoS映射、SDAP层的映射关系都会影响语音质量。我在核查中发现一个可疑点部分小区的RRC重建比例明显偏高这说明空口侧可能存在系统性异常。这个阶段排查下来初步判断问题大概率出在移动性管理环节也就是切换相关的配置或流程上但还缺少直接证据需要深入到信令层面进一步定位。2. 端到端逐段定位与根因锁定2.1 空口侧弱覆盖、干扰与切换分析空口侧排查是整个端到端分析里最耗时但也最关键的一环。VoNR语音业务对空口质量的要求比数据业务苛刻得多数据业务可以靠HARQ重传兜底语音业务是实时业务重传次数有限一旦空口质量恶化直接表现就是RTP丢包率上升、抖动增大严重时触发掉话。我先拿了问题区域的MR测量报告数据统计RSRP参考信号接收功率分布和SINR分布。从MR数据看问题区域的RSRP均值在-98dBm左右SINR均值在8dB左右整体不算特别差但边缘区域的采样点占比明显偏高RSRP低于-110dBm的采样点超过了10%。这个数据说明覆盖不算重度弱覆盖但处于“亚健康”状态语音业务在这种环境下很容易出问题。干扰方面我拉取了问题区域的上行干扰底噪数据发现一个基站的某几个小区在特定时段存在明显的上行干扰抬升底噪从-120dBm抬升到-105dBm左右。排查后发现是该站周边存在一个未加屏蔽的直放站设备产生带外杂散干扰。这里要提醒各位干扰排查一定不要只看网管平均指标要按PRB粒度去分析干扰底噪的分布特征。如果是全频段干扰抬升大概率是外部干扰源如果只是特定PRB抬升要考虑帧结构配置或邻区干扰。切换分析是空口侧的重中之重。我提取了问题区域的切换统计包括切换请求次数、切换成功率、切换失败原因。数据显示同站切换和站间切换成功率都正常但是分布在两个宏站交界区域的切换次数特别高一天下来单个小区切换请求次数超过两万次。这本身就是个隐患——切换越频繁失败的绝对次数就越多掉话的概率自然就上去了。2.2 核心网侧PDU会话与QoS Flow状态核查空口侧排查结束后我把重点转向核心网。VoNR通话不仅仅涉及空口和基站还涉及完整的5GC5G核心网信令链路。一个典型的VoNR呼叫流程是UE发起PDU会话建立请求→AMF接入和移动性管理功能处理注册和会话管理→SMF会话管理功能选择UPF并建立用户面通道→IMS域完成SIP信令交互和媒体面协商→语音数据流经gNodeB→UPF→IMS网络传输。核心网侧排查我关注三个层面第一是PDU会话建立成功率第二是QoS Flow的建立和修改流程第三是N2接口gNodeB与AMF之间和N3接口gNodeB与UPF之间的信令交互是否正常。从信令跟踪数据看PDU会话建立成功率基本在99.5%以上没有异常。但我在分析QoS Flow修改流程时发现了一个值得注意的细节部分VoNR呼叫在建立语音QoS Flow时经历了多次QoS Flow修改过程正常情况下语音Flow应该在通话开始时一次性建立成功并保持稳定但这些异常呼叫在通话过程中反复触发QoS Flow修改每次修改都伴随短暂的媒体面中断。RTP丢包率在通话过程中的波动情况和QoS Flow修改的节奏高度相关。这让我怀疑问题不只是空口核心网在QoS Flow管理策略上可能有配置偏差。进一步核查SBI接口服务化接口上的Nsmf_PDUSession_UpdateSMContext消息发现SMF在部分场景下会触发QoS Flow的重建或修改这直接导致了通话质量的短暂劣化。2.3 IMS域与SIP信令深度关联分析IMS域排查是整个端到端分析中信息量最大的环节。VoNR的呼叫控制层完全依赖IMS终端发起呼叫后SIP信令会经过P-CSCF代理呼叫会话控制功能、S-CSCF服务呼叫会话控制功能等网元完成呼叫路由和会话控制。掉话问题的IMS侧分析核心是看SIP消息中的BYE消息或Session Timer超时记录。我把问题区域所有掉话话单中的SIP信令拉出来逐一分析重点看两条线索一是掉话前最后一条SIP消息是什么二是媒体面RTP流的收发方向和丢包统计。分析结果很有意思相当一部分掉话案例中SIP层面没有收到BYE消息也没有正常的会话释放流程。也就是说这条语音通话是在承载层静默中断的两边终端都不知道对方已经不可达直到RTP超时后各自触发本地释放。这种“沉默中断”现象说明问题出在承载层面也就是QoS Flow或用户面传输链路而不是IMS业务逻辑本身。我把SIP信令和基站侧的用户面数据做时间对齐发现了一个规律性现象每次掉话前大约2-3秒N3接口上该用户的GTP-UGPRS隧道协议用户面隧道会出现短暂的数据中断或巨大时延抖动紧接着RTP丢包率飙升然后通话掉线。到这里根因范围已经从“泛泛的端到端问题”缩小到了“N3接口用户面传输链路”嫌疑集中在传输网络或UPF转发链路上。2.4 根因锁定传输链路丢包与转发异常复现为了进一步确认N3接口的传输状况我组织了一次针对性的联通测试。方法很简单粗暴在问题区域的基站侧挂一台测试终端发起VoNR呼叫并保持通话同时在基站侧和UPF侧分别做端口镜像抓包然后对比分析GTP-U隧道两端的报文收发序列号和时间戳。测试结果印证了之前的判断基站侧发出的GTP-U报文和UPF侧收到的GTP-U报文之间存在不连续的序列号跳跃说明传输链路有丢包。更关键的是我在UPF侧抓到的报文里发现了重传和乱序现象而且乱序的规律不是随机出现的而是呈周期性爆发大概每隔几十秒出现一次。这个周期性特征让我把怀疑对象指向了传输设备的队列调度策略。我们顺着链路逐跳排查传输设备最终定位到一台汇聚交换机上——该交换机上配置了针对特定业务流的QoS策略但策略的队列带宽设置不合理语音流的优先级队列被分配了极小的带宽当承载语音流的物理链路出现瞬时拥塞时语音报文就会被大量丢弃。到这里根因链完整闭合承载VoNR语音流的物理链路存在周期性瞬时拥塞汇聚交换机QoS队列调度不合理导致语音GTP-U报文被过度丢弃N3接口丢包触发RTP质量劣化最终表现为VoNR端到端高掉话。3. 端到端优化方案设计与落地实施3.1 传输侧QoS策略调整根因明确后方案设计就变得有的放矢了。最直接、见效最快的措施是调整汇聚交换机的QoS策略。语音业务在5G网络里对应5QI 1VoNR语音、5QI 2VoNR语音实时视频端到端承载时需要在传输设备上识别这些优先级并进行差异化调度。调整思路是这样的在汇聚交换机上为VoNR语音流量单独划分一个高优先级队列配置严格优先级调度确保语音报文在任何拥塞场景下都能优先转发。同时对语音流量做流量监管超出预期带宽的语音流量不丢弃而是重新标记为低优先级避免恶意或异常流量挤占语音队列。配置完成后我安排了一次压力测试在语音链路叠加人为背景流量观察通话质量变化。测试结果表明语音MOS分平均意见分衡量语音质量的指标在背景流量达到链路带宽90%时仍能保持在4.0以上而调整前同等条件下MOS分会跌到2.5以下甚至掉话。另外针对周期性的瞬时拥塞我把传输链路的缓存策略也做了优化。具体做法是增大语音所属队列的缓存深度配合WRED加权随机早期检测算法用轻微的队列时延换取更低的丢包率。语音业务对时延敏感但对瞬时突发有容忍度这个权衡在实测中效果不错。3.2 无线侧参数优化与切换策略调整传输侧解决的是“管道”问题无线侧还要解决“源头”问题。前面提到问题区域的切换过于频繁这是导致切换失败绝对次数偏高的直接原因。我在无线侧做了三个方面的参数优化。第一是切换门限调整。原配置中A3事件的幅度偏置设置过小导致终端在信号质量还可以的情况下就频繁触发切换。我把A3事件的幅度偏置从2dB调整为3.5dB同时调整了切换迟滞参数让终端在信号变化较小时不轻易触发切换减少不必要的切换次数。参数调整后问题区域日切换请求次数从两万多次下降到了一万三千次左右降幅约35%。第二是MLB移动负载均衡参数校准。检查发现部分小区开了MLB后为了均衡负载把一个边缘用户成批地往邻区赶这些用户到了邻区往往信号质量不理想反而埋下掉话隐患。我把MLB的负载差阈值从20%提高到35%让负载均衡策略更保守一些只有当小区间负载差异明显时才触发迁移。第三是上行干扰处理。针对之前发现的直放站干扰源协调相关单位关闭了问题设备上行干扰底噪从-105dBm恢复到了-118dBm左右干扰消除后上行语音质量有了明显改善。这里要补充一个经验VoNR语音对上行干扰尤其敏感因为语音业务的上行发射功率有限干扰抬升会直接影响eNodeB侧的语音信号解调质量。干扰排查应该作为VoNR优化的一项常态化工作来做。3.3 端到端监控体系建设方案落地后我同步搭建了一套面向VoNR业务的端到端监控体系目的不是解决眼前的掉话而是下次出现类似问题时能快速定位。监控体系的思路是把无线侧、传输侧、核心网侧和IMS侧的关键指标统一到一个看板上。无线侧关注掉话率、RRC重建比例、切换成功率、MR覆盖分布传输侧关注N3接口丢包率、时延、抖动和队列丢弃计数核心网侧关注PDU会话建立成功率、QoS Flow建立成功率、N2/N3接口信令时延IMS侧关注SIP信令成功率、BYE消息分布、RTP丢包率。这套监控体系最大的价值在于跨域关联。以前无线侧说无线没问题、传输侧说传输没问题、核心网说核心网没问题最后问题悬在空中没人负责。现在有了统一的端到端指标关联分析方法任何一个环节出现异常都能通过指标相关性快速缩小排查范围。比如N3接口的丢包率和RTP丢包率如果强相关基本可以判断问题出在传输链路如果RTP丢包率升高而N3接口丢包率没有变化就需要把注意力放到无线空口或IMS媒体面。4. 常见问题速查与排查工具清单4.1 VoNR掉话根因速查表端到端排查最大的难点不是某一个环节有多复杂而是端到端涉及的网络层级太多。为了便于日常排查快速参照我把VoNR掉话常见原因整理成了一张速查表。注意实际排查时先确认指标口径再按“空口→传输→核心网→IMS”的顺序逐段排查避免东一榔头西一棒子。问题环节常见原因关键特征排查手段空口覆盖弱覆盖/盲区MR中RSRP-110dBm占比高RS-SINR差MR数据、路测、覆盖规划空口干扰外部干扰/邻区干扰上行底噪抬升特定PRB干扰干扰底噪扫描、频谱分析移动性切换参数不合理、频繁切换切换失败率高、切换次数异常切换统计、A3事件参数核查传输链路QoS队列配置不合理、物理链路拥塞N3接口丢包率周期性升高端口镜像抓包、GTP-U序列号分析用户面UPF转发异常、GTP-U隧道老化单用户丢包率与N3丢包率非同步变化UPF日志、GTP-U隧道状态核查IMS域SBC媒体转发异常、SIP超时配置SIP层无正常释放媒体面先中断SIP信令跟踪、媒体流分析终端侧VoNR开关异常、终端协议栈缺陷特定终端型号集中掉话终端日志、型号维度统计这张表看起来简单但每一条背后都有真实的排查案例支撑。比如“特定终端型号集中掉话”这种情况在端到端排查里非常容易被忽略建议所有VoNR掉话分析第一步就按终端型号、芯片平台做交叉维度统计能省掉大量排查时间。4.2 排查工具和信令分析方法端到端排查离不开工具支撑。基站侧用厂家网管系统采集MR、切换、干扰等无线侧数据传输侧用端口镜像配合Wireshark分析GTP-U协议重点看序列号连续性和时间戳核心网侧通过AMF/SMF网元的信令跟踪功能抓取N1/N2/N4接口消息IMS侧通过P-CSCF/S-CSCF的SIP日志分析呼叫流程。信令分析里有一个实用的经验把不同接口的消息用时间对齐后放在同一个时间轴上分析比单独看某个接口的消息要有用得多。比如你把基站侧的N2接口信令、N3接口的GTP-U数据、IMS侧的SIP消息和终端侧的日志放在同一个时间轴上对比掉话发生前几秒每个环节发生了什么一目了然。我在本案例中就是用这个方法一次性看到了“传输丢包→RTP质量劣化→承载中断→SIP超时释放”的完整因果链条。Wireshark分析GTP-U时过滤语法可以参考这个示例# 过滤特定用户的GTP-U流量假设TEID为0x12345678 gtpu.teid 0x12345678 # 过滤包含丢包重传特征的GTP-U报文 gtpu tcp.analysis.retransmission # 按GTP-U隧道ID统计流量 gtpu frame.time_relative 120 frame.time_relative 180另外推荐大家养成记录排查日志的习惯。每次掉话问题处理完把现象、根因、处理措施、验证结果整理成结构化文档时间长了就形成了自己的知识库。很多看似新的问题翻翻以前的案例记录往往能直接找到思路。5. 一些操作心得和后续工作建议这套端到端排查方法跑通之后我再处理VoNR类问题就有了更清晰的路径依赖。但我还是想补充一个在项目中得到的教训很多人遇到掉话第一反应就去调无线参数这在多数情况下没错但如果根子在上层网络无线参数怎么调都是隔靴搔痒。本案例就是一个典型例子——无线侧指标看起来确实“有点问题”但真正的决定性因素在传输侧。端到端分析这个方向本身不是口号而是确实要有方法、有工具、有跨域联动机制去支撑。关于VoNR优化还想再多说一句。5G语音业务虽然已经商用多年但VoNR的体验优化和VoLTE时代比复杂度是有增无减的。核心原因在于5G网络的云化架构让信令路径更长、涉及网元更多、虚拟化环境带来的不确定性也更多。这意味着优化人员不能只懂无线还得懂传输、懂核心网、懂IMS。这既是挑战也是这个岗位的护城河。后续如果条件允许我建议在现有监控体系基础上引入用户感知层面的自动关联分析把QoE体验质量指标和网络KPI实时关联起来一旦出现用户感知劣化就能自动回溯对应的网络事件进一步缩短故障定位时间。这个方向目前已经有现成的平台能力可以对接剩余的更多是数据模型和业务规则沉淀的工作。本文还有配套的精品资源点击获取