简介这份文档面向5G网络优化工程师及VoNR运维人员聚焦VoNR上行单通这一典型语音感知问题提供从信令提取到根因定位的完整分析思路。资源包内含1个docx文件约226KB以案例文档形式呈现便于随身查阅与团队内部分享。案例围绕某VIP用户在天宁营销中心通话单通展开通过提取CS、PS及用户面信令锁定15:19:40至15:19:46的丢包时段结合NR小区占用、PAGING流程与切换信令判断主叫侧道路覆盖质差并进一步定位到室外信号外泄导致的邻区漏配。文档给出增加建设银行延陵路支行与常州大酒店裙楼滴灌站邻区关系的解决措施及复测验证结果并总结端到端排查、异常信令对比、特殊地理环境关注等注意事项。目前已有144人学习适合需要积累VoNR单通定位经验、完善邻区优化思路的读者参考。1. VONR上行单通一个让KPI和信令同时“说谎”的现场VoNR5G新通话商用后最让人头疼的不是接不通而是上行单通——主叫能听见对方对方听不见主叫或者通话建立后上行RTP包在核心网侧被大量丢弃而空口KPI却显示“正常”。这类问题最阴的地方在于无线侧RSRP、SINR都漂亮核心网侧NGAP、PFCP信令也走完了但用户感知就是“我说话你听不见”。如果你正在做VoNR路测、核心网IMS排障或终端协议栈分析这篇笔记就是把我踩过的坑按“定位路径”重新捋一遍。它不解决所有单通但能让你在拿到一个“上行单通”投诉时知道先看哪条信令、再抓哪个计数器、最后怎么用最小代价复现。2. 先分清“上行单通”到底断在哪一段从UE到IMS的四个观测点2.1 上行单通的三种典型断点与对应信令特征VoNR通话的数据面路径是UE → gNB → UPF → IMSP-CSCF/SBC。上行单通意味着主叫发出的RTP包没有完整到达被叫侧。常见断点有三类第一类空口上行调度异常。UE的BSR上报了但gNB没有给足上行授权或者给了授权但MCS选得过低导致丢包。信令上表现为QoS Flow建立成功但gNB侧DRB.UplinkPacketLossRate偏高而DRB.AverageMCS异常低。第二类UPF侧N3/N6转发丢包。N3口GTP-U隧道建立正常但UPF的QoS Flow映射错误把VoNR的QFI1映射到了非GBR承载或者N6口防火墙把RTP端口段拦了。信令上PFCP会话建立成功但UPF的QoSFlow.UplinkPacketDrop计数持续增长。第三类IMS侧SBC媒体面未正确锚定。P-CSCF收到SDP后SBC没有正确更新远端媒体地址导致上行RTP发到了错误端口。信令上SIP 200 OK里的SDP连接地址与UPF实际分配的UE IP不一致。提示先别急着抓包。拿一个上行单通投诉第一件事是确认“单通是持续的还是概率的”。持续单通大概率是配置/映射错误概率单通优先查空口调度和UPF丢包。2.2 用最小信令集锁定断点一张表说清看什么观测点关键信令/计数器正常表现上行单通异常表现UE侧QFI1的SDAP/PDCP上行SDU丢弃计数接近0持续增长说明UE侧上行发送即失败gNB侧DRB.UplinkPacketLossRate / AverageMCS丢包1%MCS随SINR合理丢包5%或MCS被钉在低阶UPF侧PFCP Session Report / QoSFlow.UplinkPacketDrop无异常dropdrop计数与通话时长正相关IMS侧SIP 200 OK SDP中的c行与m行c行地址与UPF分配的UE IP一致c行指向错误地址或端口为0这张表的价值在于你不需要同时抓四个点。先看UE侧PDCP上行丢弃计数如果为0直接跳到UPF侧看QoSFlow drop如果UE侧就有丢弃问题在空口或UE协议栈。2.3 一个可复现的抓包与计数器采集流程下面这段bash脚本是我在现网排障时常用的“最小采集集”跑在gNB的OAM容器里同时抓取空口侧计数器和N3口包统计。注意不同设备商命令不同这里用通用Linux工具典型路径示意。#!/bin/bash # vonr_uplink_probe.sh # 用途在gNB OAM侧采集VoNR上行单通相关计数器与N3口包统计 # 前提已登录gNB OAM且具备tcpdump权限 DURATION30 UE_IP10.60.12.34 # 从SMF侧获取的UE IP GNB_N3_IP192.168.10.1 UPF_N3_IP192.168.10.2 # 1. 采集gNB侧DRB上行统计路径按设备商调整 echo DRB Uplink Stats cat /proc/drb_stats/drb1_uplink 2/dev/null || \ show drb statistics drb-id 1 | tee /tmp/drb1_uplink.txt # 2. 抓取N3口GTP-U上行包过滤UE IP对应的内层RTP echo N3 Uplink GTP-U Capture timeout $DURATION tcpdump -i n3 -w /tmp/n3_uplink.pcap \ src $GNB_N3_IP and dst $UPF_N3_IP and udp port 2152 \ -c 5000 # 3. 统计内层RTP包数量与序列号跳变 echo Inner RTP Analysis tshark -r /tmp/n3_uplink.pcap -d udp.port2152,gtp \ -Y gtp ip.src$UE_IP \ -T fields -e gtp.teid -e rtp.seq -e rtp.ssrc 2/dev/null | \ awk {print $2} | sort -n | uniq -c | head -20 echo Done. Check /tmp/n3_uplink.pcap and /tmp/drb1_uplink.txt逻辑说明第一步拿gNB侧DRB上行统计确认空口是否已经丢包第二步抓N3口GTP-U包用UE IP过滤内层RTP第三步用tshark解析GTP内层RTP序列号如果序列号出现大段跳变或重复说明UPF之前就有问题。参数说明DURATION30建议至少30秒覆盖一次完整的上行RTP周期UE_IP必须从SMF的PFCP会话报告中拿不能猜-c 5000限制包数防止磁盘打满gtp.teid用于确认QFI映射是否一致。3. 空口侧排查为什么RSRP很好但上行RTP就是发不出去3.1 上行调度与BSR上报的“时间差陷阱”VoNR的RTP包是周期性的每20ms一个包。UE的BSRBuffer Status Report上报的是“当前缓冲区有多少待发数据”但gNB收到BSR后分配上行授权需要时间。如果UE的PDCP层在BSR上报后、授权到达前又收到了新的RTP包而gNB只按旧BSR分配了刚好够一个包的授权就会导致第二个包被延迟或丢弃。现象DRB.UplinkPacketLossRate在通话开始后3-5秒内突然升高之后回落。原因RTP流刚建立时PDCP缓冲区瞬间堆积BSR上报滞后。解决检查gNB的ulSchdBsrPeriod和ulGrantSize配置VoNR场景建议BSR周期≤10ms授权大小留20%余量。3.2 逻辑信道优先级与QFI映射的坑VoNR的QFI1对应5QI1GBR承载但很多现网把QFI1映射到了逻辑信道组LCG0而LCG0同时承载SRB和其它非GBR业务。当小区用户数多时LCG0的令牌桶被SRB占满VoNR的上行RTP被排队延迟。排查方法在gNB侧查看LCG.UplinkBufferStatus如果LCG0的待发字节数持续1000而LCG1为空说明映射错了。正确做法是把QFI1映射到独立LCG通常LCG1或2并配置独立的PBRPrioritised Bit Rate。# 检查LCG映射与PBR配置通用示意 show lcg config # 期望输出 # LCG 0: SRB, PBR0 # LCG 1: QFI1, PBR200kbps # LCG 2: QFI5/6/7/8/9, PBR0如果输出里QFI1出现在LCG0直接改映射。这个改动通常需要重启DRB建议在维护窗口做。3.3 上行功率控制与PUCCH资源不足的连锁反应上行单通还有一个隐蔽原因PUCCH资源不足导致SRScheduling Request发不出去。UE有上行数据要发但SR被PUCCH资源冲突挤掉gNB根本不知道UE有数据。现象是UE侧PDCP上行丢弃计数增长但gNB侧看不到任何调度记录。检查方法看gNB的PUCCH.ResourceUtilization如果80%且SR.FailureCount增长说明PUCCH资源不够。解决给VoNR用户预留专用SR资源或者调整PUCCH格式从format1到format0以减少资源占用。注意PUCCH资源调整会影响整个小区不要只为一个用户改。先确认是普遍问题还是个别UE问题。4. 核心网与IMS侧排查UPF丢包和SDP不一致怎么抓4.1 UPF侧QoS Flow映射错误的定位方法UPF收到PFCP Session Establishment Request后会根据PDRPacket Detection Rule和QERQoS Enforcement Rule建立QoS Flow。如果PDR里的QFI匹配条件写错比如把QFI1写成了QFI0上行RTP包会被匹配到默认承载然后被限速或丢弃。排查步骤在UPF侧执行show pfcp session找到对应UE的会话检查PDR的precedence和QFI字段。正常应该有一条PDR的QFI1且precedence最高。如果QFI1的PDR precedence低于默认PDR上行包会先匹配默认PDR。# UPF侧PFCP会话检查通用示意 show pfcp session ue-ip 10.60.12.34 # 关注输出中的 # PDR ID: 1, Precedence: 100, QFI: 1, FAR: 1 # PDR ID: 2, Precedence: 200, QFI: 0, FAR: 2 # 如果PDR ID:1的Precedence大于PDR ID:2说明QFI1优先正常如果发现QFI1的PDR precedence值比默认PDR大数值越大优先级越低改小即可。这个改动通常热生效不需要重启会话。4.2 N6口防火墙与RTP端口段拦截UPF的N6口到IMS的SBC之间通常有防火墙。VoNR的RTP端口是动态协商的SDP里maudio行的端口号每次通话可能不同。如果防火墙只放行了固定端口段比如50000-50100而SBC协商到了50101上行RTP就被拦。现象UPF侧QoSFlow.UplinkPacketDrop增长但gNB侧无丢包。抓N6口包能看到上行RTP发出去了但SBC侧没收到。解决要么让SBC限制RTP端口范围要么在防火墙上放行整个动态端口段通常16384-32767。4.3 SIP SDP中c行与UPF分配的UE IP不一致这是IMS侧最隐蔽的坑。P-CSCF在转发SIP 200 OK时SDP里的c行应该填UPF分配给UE的IP。但如果SBC配置了“媒体锚定”但没更新c行被叫侧会把上行RTP发到SBC的IP而不是UE的IP导致上行单通。排查方法在SBC侧抓SIP包对比c行地址与SMF侧PFCP会话里UE的IP。如果不一致检查SBC的media-anchoring配置和SDP-rewrite策略。# SBC侧SIP包抓取与SDP解析通用示意 tcpdump -i any -w /tmp/sip.pcap port 5060 tshark -r /tmp/sip.pcap -Y sip.Status-Code 200 \ -T fields -e sip.c -e sip.m 2/dev/null # 期望c行地址等于UE IPm行端口等于SBC协商的RTP端口如果c行是SBC自己的IP说明SDP rewrite没生效。改SBC配置里的anchoring-mode为update-sdp。5. 避坑与常见问题上行单通排查的5条血泪经验5.1 现象UE侧PDCP上行丢弃计数为0但被叫就是听不见原因PDCP计数为0只代表UE把包交给了空口不代表gNB收到了。如果空口上行HARQ重传次数耗尽PDCP层可能已经丢弃但计数没更新。解决同时看gNB侧DRB.UplinkPacketLossRate和HARQ.UplinkRetxCount如果重传次数3说明空口质量有问题查上行干扰或PUCCH功率。5.2 现象UPF侧QoSFlow drop计数增长但gNB侧无丢包原因N3口GTP-U隧道MTU不匹配。VoNR的RTP包加上GTP头后可能超过N3口MTU通常1500导致分片或丢弃。解决检查N3口MTU建议设为1600以上或者开启GTP-U分片。5.3 现象通话建立后前5秒正常之后上行单通原因IMS侧SBC的媒体超时定时器太短。VoNR的RTP流在静默期SID帧间隔可能超过SBC的media-timeoutSBC误判媒体流结束关闭上行端口。解决把SBC的media-timeout从5秒改到20秒以上。5.4 现象概率性上行单通重启UE后恢复原因UE协议栈的SDAP层QFI映射表在切换后未更新。VoNR通话中发生Xn切换时目标gNB的QFI映射可能与源gNB不同UE没有重新读取SDAP配置。解决检查切换信令里的SDAP-Config是否包含QFI1的映射如果没有需要在切换命令里强制携带。5.5 现象抓包看到上行RTP序列号正常但被叫侧MOS分低原因上行RTP的jitter过大。VoNR的RTP包在UPF侧被整形如果UPF的QER里UL-AMBR设得过低RTP包被延迟发送jitter超过50ms。解决检查UPF的QER配置VoNR的UL-AMBR建议≥200kbps且开启QoSFlow.UplinkJitter监控。6. 用“反向验证法”快速确认上行单通是否修复6.1 反向验证法的核心思路正向排查是从UE往IMS追反向验证是从IMS往UE推。具体做法在SBC侧构造一个上行RTP包源地址填UE IP目的地址填SBC看这个包能不能穿过UPF和gNB到达UE。如果能到达说明上行路径通如果不能说明路径上有拦截。这个方法的好处是不需要真实通话只需要一个RTP构造工具。我常用scapy构造最小RTP包从SBC侧发出去同时在UE侧抓包。# reverse_rtp_check.py # 用途从SBC侧构造上行RTP包验证到UE的路径是否通 from scapy.all import * import random UE_IP 10.60.12.34 SBC_IP 10.10.10.5 RTP_PORT 32000 # 构造最小RTP包12字节头 20字节payload rtp_header bytes([ 0x80, 0x00, # V2, P0, X0, CC0 0x00, 0x01, # M0, PT1 (AMR) 0x00, 0x01, # sequence number 0x00, 0x00, 0x00, 0x01, # timestamp 0x00, 0x00, 0x00, 0x01, # SSRC ]) payload b\x00 * 20 rtp_packet rtp_header payload # 发送UDP包 send(IP(srcSBC_IP, dstUE_IP)/UDP(sportRTP_PORT, dportRTP_PORT)/Raw(rtp_packet)) print(fSent RTP from {SBC_IP} to {UE_IP}:{RTP_PORT})逻辑说明这个脚本从SBC侧发一个源地址为SBC、目的地址为UE的RTP包。如果UE侧能抓到说明上行路径SBC→UPF→gNB→UE是通的。如果抓不到在UPF的N6口和N3口分别抓定位拦截点。参数说明UE_IP和SBC_IP必须从现网获取RTP_PORT用SDP协商的实际端口PT1表示AMR如果现网用EVS改成PT96。6.2 验证结果判读与下一步动作如果UE侧抓到包但真实通话仍上行单通说明问题在UE协议栈的RTP处理不在路径。如果UE侧抓不到包但UPF的N6口抓到了说明UPF到gNB之间有问题查N3口GTP-U隧道。如果UPF的N6口都抓不到说明SBC到UPF之间有问题查N6口防火墙。抓包点抓到包没抓到包下一步SBC侧正常发送失败检查SBC路由UPF N6口路径通防火墙拦截放行RTP端口UPF N3口GTP隧道通GTP隧道断查PFCP会话gNB侧空口通空口调度问题查BSR/LCGUE侧全路径通UE协议栈问题查SDAP/PDCP6.3 我自己的习惯先反向验证再正向排查以前我排上行单通总是从UE侧开始抓抓完空口抓N3抓完N3抓N6一圈下来半天过去了。后来改成先做反向验证从SBC发一个RTP包5分钟就能定位到是哪一段断了。这个习惯帮我省了至少70%的排障时间。反向验证的另一个好处是它不依赖真实通话可以在业务空闲时做不影响用户。希望帮到你。本文还有配套的精品资源点击获取
