企业官网建设流程全解析

简介：这份文档面向5G网络优化工程师及VoNR运维人员，聚焦VoNR上行单通这一典型语音感知问题，提供从信令提取到根因定位的完整分析思路。资源包内含1个docx文件，约226KB，以案例文档形式呈现，便于随身查阅与团队内部分享。案例围绕某VIP用户在天宁营销中心通话单通展开，通过提取CS、PS及用户面信令，锁定15:19:40至15:19:46的丢包时段，结合NR小区占用、PAGING流程与切换信令，判断主叫侧道路覆盖质差，并进一步定位到室外信号外泄导致的邻区漏配。文档给出增加建设银行延陵路支行与常州大酒店裙楼滴灌站邻区关系的解决措施及复测验证结果，并总结端到端排查、异常信令对比、特殊地理环境关注等注意事项。目前已有144人学习，适合需要积累VoNR单通定位经验、完善邻区优化思路的读者参考。

1. VONR上行单通：一个让KPI和信令同时“说谎”的现场

VoNR（5G新通话）商用后，最让人头疼的不是接不通，而是上行单通——主叫能听见对方，对方听不见主叫；或者通话建立后上行RTP包在核心网侧被大量丢弃，而空口KPI却显示“正常”。这类问题最阴的地方在于：无线侧RSRP、SINR都漂亮，核心网侧NGAP、PFCP信令也走完了，但用户感知就是“我说话你听不见”。如果你正在做VoNR路测、核心网IMS排障或终端协议栈分析，这篇笔记就是把我踩过的坑按“定位路径”重新捋一遍。它不解决所有单通，但能让你在拿到一个“上行单通”投诉时，知道先看哪条信令、再抓哪个计数器、最后怎么用最小代价复现。

2. 先分清“上行单通”到底断在哪一段：从UE到IMS的四个观测点

2.1 上行单通的三种典型断点与对应信令特征

VoNR通话的数据面路径是：UE → gNB → UPF → IMS（P-CSCF/SBC）。上行单通意味着主叫发出的RTP包没有完整到达被叫侧。常见断点有三类：

第一类，空口上行调度异常。UE的BSR上报了，但gNB没有给足上行授权，或者给了授权但MCS选得过低导致丢包。信令上表现为：QoS Flow建立成功，但gNB侧DRB.UplinkPacketLossRate偏高，而DRB.AverageMCS异常低。

第二类，UPF侧N3/N6转发丢包。N3口GTP-U隧道建立正常，但UPF的QoS Flow映射错误，把VoNR的QFI=1映射到了非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侧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权限 DURATION=30 UE_IP="10.60.12.34" # 从SMF侧获取的UE IP GNB_N3_IP="192.168.10.1" UPF_N3_IP="192.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.port==2152,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之前就有问题。

参数说明：DURATION=30建议至少30秒，覆盖一次完整的上行RTP周期；UE_IP必须从SMF的PFCP会话报告中拿，不能猜；-c 5000限制包数防止磁盘打满；gtp.teid用于确认QFI映射是否一致。

3. 空口侧排查：为什么RSRP很好但上行RTP就是发不出去

3.1 上行调度与BSR上报的“时间差陷阱”

VoNR的RTP包是周期性的，每20ms一个包。UE的BSR（Buffer 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的QFI=1对应5QI=1（GBR承载），但很多现网把QFI=1映射到了逻辑信道组LCG=0，而LCG=0同时承载SRB和其它非GBR业务。当小区用户数多时，LCG=0的令牌桶被SRB占满，VoNR的上行RTP被排队延迟。

排查方法：在gNB侧查看LCG.UplinkBufferStatus，如果LCG=0的待发字节数持续>1000而LCG=1为空，说明映射错了。正确做法是把QFI=1映射到独立LCG（通常LCG=1或2），并配置独立的PBR（Prioritised Bit Rate）。

# 检查LCG映射与PBR配置（通用示意） show lcg config # 期望输出： # LCG 0: SRB, PBR=0 # LCG 1: QFI=1, PBR=200kbps # LCG 2: QFI=5/6/7/8/9, PBR=0

如果输出里QFI=1出现在LCG=0，直接改映射。这个改动通常需要重启DRB，建议在维护窗口做。

3.3 上行功率控制与PUCCH资源不足的连锁反应

上行单通还有一个隐蔽原因：PUCCH资源不足导致SR（Scheduling 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后，会根据PDR（Packet Detection Rule）和QER（QoS Enforcement Rule）建立QoS Flow。如果PDR里的QFI匹配条件写错，比如把QFI=1写成了QFI=0，上行RTP包会被匹配到默认承载，然后被限速或丢弃。

排查步骤：在UPF侧执行show pfcp session，找到对应UE的会话，检查PDR的precedence和QFI字段。正常应该有一条PDR的QFI=1且precedence最高。如果QFI=1的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，说明QFI=1优先，正常

如果发现QFI=1的PDR precedence值比默认PDR大（数值越大优先级越低），改小即可。这个改动通常热生效，不需要重启会话。

4.2 N6口防火墙与RTP端口段拦截

UPF的N6口到IMS的SBC之间通常有防火墙。VoNR的RTP端口是动态协商的，SDP里m=audio行的端口号每次通话可能不同。如果防火墙只放行了固定端口段（比如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 IP，m=行端口等于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-timeout，SBC误判媒体流结束，关闭上行端口。解决：把SBC的media-timeout从5秒改到20秒以上。

5.4 现象：概率性上行单通，重启UE后恢复

原因：UE协议栈的SDAP层QFI映射表在切换后未更新。VoNR通话中发生Xn切换时，目标gNB的QFI映射可能与源gNB不同，UE没有重新读取SDAP配置。解决：检查切换信令里的SDAP-Config是否包含QFI=1的映射，如果没有，需要在切换命令里强制携带。

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, # V=2, P=0, X=0, CC=0 0x00, 0x01, # M=0, PT=1 (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(src=SBC_IP, dst=UE_IP)/UDP(sport=RTP_PORT, dport=RTP_PORT)/Raw(rtp_packet)) print(f"Sent 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协商的实际端口；PT=1表示AMR，如果现网用EVS改成PT=96。

6.2 验证结果判读与下一步动作

如果UE侧抓到包，但真实通话仍上行单通，说明问题在UE协议栈的RTP处理，不在路径。如果UE侧抓不到包，但UPF的N6口抓到了，说明UPF到gNB之间有问题，查N3口GTP-U隧道。如果UPF的N6口都抓不到，说明SBC到UPF之间有问题，查N6口防火墙。

6.3 我自己的习惯：先反向验证，再正向排查

以前我排上行单通，总是从UE侧开始抓，抓完空口抓N3，抓完N3抓N6，一圈下来半天过去了。后来改成先做反向验证：从SBC发一个RTP包，5分钟就能定位到是哪一段断了。这个习惯帮我省了至少70%的排障时间。反向验证的另一个好处是：它不依赖真实通话，可以在业务空闲时做，不影响用户。

希望帮到你。

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