拓冰网站定制 
简介5G NR下行数据传输流程涉及应用层、TCP/IP与用户面协议栈的多层协同入门者往往难以快速理清各层间的封装与分工。这份图形化资料以终端浏览网页并下载数据为场景沿HTTP GET、TCP封装、IP封装、链路层MAC直至物理层无线传输的顺序展开并以独立组网下的CU-DU架构示意SDAP/PDCP位于集中单元、RLC/MAC/PHY位于分布式单元同时用图示点出F1接口和NG-U接口上的GTP-U隧道承载关系适合5G NR协议学习者、通信工程学生及需要查漏补缺的工程师直观建立整体流程感。压缩包内为1个PDF文件约874KB体量精简目前已有270人参与学习。借助图示和逐层拆解读者能看懂TCP源/目的端口、序列号、确认号、窗口大小、校验和等头部字段的实际用途也能理解IP地址如何用于路由转发还能看到数据面从应用服务器经GTP-U隧道到终端的完整走向以及PDCP以上协议层如何逐级添加头部并最终经空口发送。对想系统掌握5G用户面数据传输和链路细节的人来说这是一份很好的图解式入门参考也适合课堂辅助或考前快速回顾。1. 5G 下行数据传输流程一张图胜过背十层协议栈做 5G 协议栈的人大概都有过这种体验刚拿到一本讲用户面流程的书翻到协议栈层叠图SDAP、PDCP、RLC、MAC、PHY 排成一列旁边再挂一个 UPF、gNB、UE图很标准但看完还是说不清一个网页请求到底是怎么从应用服务器到达手机里的。真正的 5G 下行数据传输流程并不只是“每层加个头发出去”中间还有 NG-U、F1 两条接口隧道以及 QoS Flow 到 DRB 的映射问题。这份《5G NR in BULLETS》第 248~250 页的资源用 Figure 212 到 Figure 220 共九张图把一次网页下载从 HTTP GET 开始经过 TCP/IP 封装、UPF 的 SDF 匹配、GTP-U 隧道、CU 里的 SDAP/PDCP 处理、F1 接口传输一直到 DU 的 RLC/MAC/PHY 送向空口的整条链路画了出来。它好就好在把“协议栈”换成了“每一跳加什么头”的图形化描述直观很多。适合读这份资源的人一类是刚接触 5G 用户面被 QoS Flow、DRB、TEID 这几个缩写绕晕的新人另一类是做核心网或基站集成测试需要快速定位下行速率问题出在 N3 还是 F1 的老手。接下来我会按这条数据路径拆着讲遇到容易出错的地方会直接给出排错思路。2. 从 HTTP GET 到 NG-U 封装UPF 如何用五元组和 GTP-U 把数据送进基站2.1 用户面协议栈与 CU/DU 架构先对齐Figure 212 画的是一条独立 5G 基站的用户面协议栈而且明确假设基站采用了 Centralised UnitCU和 Distributed UnitDU分离架构。在这个架构里DU 承载 RLC、MAC 和物理层CU 承载 SDAP 和 PDCP。这对读图非常关键你后面看到的 NG-U 隧道到 CU 就结束了而 F1 隧道只存在于 CU 和 DU 之间。如果不先把这个架构认定下来很容易把 PDCP 算到 DU 侧导致抓包时找错设备。协议层所在网元主要职责SDAPgNB Centralised Unit (CU)将 QoS Flow 映射到 Data Radio Bearer (DRB)PDCPgNB Centralised Unit (CU)完整性保护、加密、序号管理、可选头压缩RLCgNB Distributed Unit (DU)分段、重传AM 模式、顺序传递MACgNB Distributed Unit (DU)调度、逻辑信道复用、HARQPHYgNB Distributed Unit (DU)编码、调制、无线传输这个 split 是 3GPP 里的高层分离架构常见于需要把集中控制和实时调度分开的组网。我一般读这类图时会先看协议层画在哪个网元里再看接口名字因为 NG-U 和 F1 的 GTP-U 隧道粒度完全不同这个后面会细说。记住一个结论SDAP 和 PDCP 在 CURLC、MAC、PHY 在 DU。理解了这一点后面所有的容器和隧道切换都顺理成章。2.2 HTTP GET 到 TCP/IP浏览器这端的头部信息资源假设用户正在用浏览器访问网页并且刚向服务器发出了 HTTP GET 命令。应用层产生 HTTP 载荷后交给 TCP 封装。Figure 213 画的是 TCP 头标准大小 20 字节可以通过可选字段扩大。这里面的源端口和目的端口用来识别上层应用HTTP 默认走 80。Sequence Number 是为了让接收端能重新排序并检测丢包Acknowledgment Number 负责确认Data Offset 表示 TCP 头有多大Window Size 告诉对端自己还能收多少字节Checksum 用来检测头和载荷的误码Urgent Pointer 则是给紧急数据用的。这些字段平时做网页访问似乎用不上但真正测速出问题时TCP Window 和 Sequence 是判断传输层瓶颈的第一站。Figure 214 紧接着画了 IPv4 头同样是 20 字节标准大小。IP 头里的版本字段是 4HDR Length 表示头长Total Length 是整个包的长度。DSCP 字段用来给包打优先级ECN 用于拥塞指示Protocol 字段标识上层协议TCP 对应的是协议号 6。源 IP 和目的 IP 则由路由器决定转发方向。这里有一个容易被忽略的细节DSCP 在 IP 头里而且可以出现两次。在内层 IP 头和外层 IP 头里各有一份。核心网设备和传输网设备通常只看外层 IP 头的 DSCP所以你想让 QoS 优先级在传输网络生效必须保证外层头被正确打标。后面第 5 章的踩坑记录会专门提这个。2.3 UPF 的 SDF 匹配与 NG-U 隧道TEID 和 QFI 各管什么数据包带着 TCP/IP 头穿过 IP 网络到达 5G 核心网的用户面功能 UPF。UPF 的第一件事是通过报文解析提取五元组比如源 IP X、目的 IP Y、源端口 J、目的端口 K然后把这组字段和 SMF 在 PDU 会话建立时下发的 SDF 模板比较从而决定这个包属于哪个 PDU 会话、哪个 QoS Flow。这一步是整个下行流程里最容易让人理解错的地方QoS Flow 不是用 GTP-U 的 TEID 来标识的。UPF 匹配到 QoS Flow 后会在 NG-U 接口上建立一个 GTP-U 隧道把数据发给 gNB。这里要记住一句话NG-U 的隧道是 per PDU Session 的所以 GTP-U 头里的 Tunnel Endpoint IdentifierTEID只能标识 PDU 会话不能区分 QoS Flow。为了把 QoS Flow 信息带过去GTP-U 扩展头里加了一个“PDU Session Container”里面才有 QoS Flow IdentifierQFI。GTP-U 的格式由 3GPP TS 29.281 定义PDU Session Container 的内容在 TS 38.415 里定义。PDU Session Container 里值得关注的字段有三个PDU Type 为 0 表示这是一个下行用户面包而不是上行包PPP 位控制是否携带 Paging Policy IndicatorPPI当 UE 处于 RRC Inactive 时PPI 可以影响基站触发寻呼的优先级RQI 表示这个 QoS Flow 是否需要启用 Reflective QoS。如果想验证自己的接口抓包是否能识别到 QFI我一般会在 UPF 的 N3 口上做一个镜像抓包然后用下面的命令把 GTP-U 流量单独拎出来# 在 N3 口镜像点抓包过滤 UDP 2152 端口 tcpdump -i eth0 -s 0 -w n3.pcap udp port 2152 # 读取 pcap 并输出关键 IP 和端口信息 tshark -r n3.pcap -Y udp.port 2152 -T fields -e frame.number -e ip.src -e ip.dst -e udp.dstport第一条命令里的-i eth0指定抓包网卡-s 0表示抓完整帧-w n3.pcap写文件udp port 2152是抓包过滤器GTP-U 注册端口就是 2152。第二条命令用-Y做显示过滤-T fields只输出指定字段便于快速确认包是否已经到达 N3 口。看到 UDP 目的端口 2152 之后再在 Wireshark 里展开 GTP-U 的扩展头就能看到 PDU Session Container 以及里面的 QFI。我特别建议把图 215 和 216 一起看因为一个画的是 GTP-U 头整体结构一个画的是 PDU Session Container 内部字段。实际工作中很多同事一听到 GTP-U 就只找 TEID结果永远解释不了同一个 TEID 里为什么有不同 QoS 的包。答案很简单TEID 只负责把包送到正确的 PDU 会话QFI 才负责告诉 gNB 这个包的服务质量等级。3. CU 侧处理心法QoS Flow 映射到 DRB 时 SDAP 和 PDCP 各干什么3.1 SDAP 映射逻辑无头模式和带 SDAP 头模式gNodeB 的 CU 从 NG-U 隧道收到数据包后会先用 GTP-U 头里的 TEID 和 PDU Session Container 识别出 PDU 会话以及 QoS Flow。接下来这个包就交给 SDAP 层。SDAP 的核心职责是把 QoS Flow 映射到某一条 Data Radio BearerDRB上。原因很简单在核心网侧服务质量粒度是 QoS Flow而在空口侧真正承载数据的是 DRB。一条 DRB 可以同时承载多个 QoS Flow例如同一会话里的语音包和普通上网流量可能因为优先级不同被映射到不同 DRB。资源里画得最形象的就是 SDAP 这一层上方是来自不同隧道、不同 PDU 会话的 QoS Flow下方则是 DRB1、DRB2、DRB3。SDAP 层在这里扮演的是“分拣员”角色它决定哪个 QoS Flow 进哪条 DRB。值得注意的是SDAP 可以有两种工作方式。第一种是不加 SDAP 头直接把包交给 PDCP第二种是增加一个 SDAP 头在头里携带 QoS Flow 标识这样终端收到下行包后就能自己推导出“哪个 QoS Flow 对应哪条 DRB”再用这个映射去发送上行数据。这就是 Reflective QoS 机制。很多刚接触的人以为不加 SDAP 头就是 SDAP 没参与转发其实不是。SDAP 是否加头由 RRC 配置决定与映射动作本身无关。无头模式更省字节适合不需要反射 QoS 的场景带头模式则方便终端学习映射。SDAP 本身的规范在 3GPP TS 37.324 里原文第 5.1 节也提了。如果你想确认某个 DRB 上是否加了 SDAP 头直接在 RRC 重配消息里看 SDAP-Config 的 sdap-HeaderDL 字段比对着空口数据猜要快得多。3.2 PDCP 在 CU 做的三件事完整性保护、加密和排序SDAP 把包映射到 DRB 之后交给同样位于 CU 的 PDCP 层。PDCP 在这里要干三件事完整性保护、加密和序号管理。完整性保护是先对包算一个认证码也就是 MAC-I然后附加到 PDCP 头里接收端拿这个认证码校验包是不是被人篡改过。这里有个容易混淆的点完整性保护不是所有 DRB 都默认开启通常只对某些需要高安全性的控制面或语音业务开启具体要看 RRC 消息里的安全配置。但资源在解释协议栈时把它画成 PDCP 的标准动作理解顺序上没问题。加密是对每个 PDCP 包的负载部分做加扰接收端只有拿着对应密钥才能解开。注意加密是在完整性保护计算完认证码之后才做的因为如果先加密再算完整性接收端就没法在没有密钥的情况下先验认证码流程会复杂很多。PDCP 头里还会加上一个 PDCP 序列号接收端用这个序列号把收到的包按顺序重排。某些应用场景下 PDCP 还会做头压缩典型的是语音包普通数据包一般不做。这三件事做完之后生成的就是 PDCP PDU。到这里数据还留在 CU 侧接下来要把它转给 DU。这个转交动作走的是 F1 接口而且用的是另一组 GTP-U 隧道。很多排障的人在这里会突然觉得“刚才还是 PDU 会话现在怎么变成 DRB 了”其实就是 PDCP 层完成封装后数据面已经以 DRB 为粒度在传递了。CU 侧没有空口调度也没有 HARQ它只负责把核心网传来的 QoS Flow 翻译成 DU 能认的 DRB 数据。3.3 从 NG-U 到 F1 的容器切换为什么隧道粒度变了NG-U 接口上GTP-U 隧道是 per PDU Session 的扩展头用 PDU Session Container。F1 接口上就不一样了。CU 把 PDCP PDU 发给 DU 时QoS Flow 到 DRB 的映射已经完成所以 F1 的 GTP-U 隧道是 per DRB 的。也就是说每一条 DRB 在 CU 和 DU 之间都有一条独立的 GTP-U 隧道GTP-U 扩展头也换成 NR RAN Container而不是 PDU Session Container。这个变化是 CU/DU split 架构下不可避免的因为 DU 侧只关心 DRB不关心 QoS Flow 与核心网的对应关系。接口隧道粒度GTP-U 扩展头扩展头内容定义NG-UUPF 到 gNB CUper PDU SessionPDU Session Container3GPP TS 38.415F1-UgNB CU 到 DUper DRBNR RAN Container3GPP TS 38.425这个表格是我自己读图时总结的。NR RAN Container 承载的内容来自 TS 38.425 的 New Radio User Plane Protocol简单理解就是 PDCP PDU 以及配套的用户面传输控制信息。正因为 NG-U 和 F1 的扩展头内容完全不同抓包时不能拿同一个模板去套两个接口。第 5 章会专门讲这个坑。讲到这里CU 侧的处理路径已经清楚了GTP-U 包到达 CU - 根据 TEID 和 PDU Session Container 识别 PDU 会话和 QoS Flow - SDAP 映射到 DRB - PDCP 做安全保护和排序 - 通过 F1 接口按 DRB 隧道转发给 DU。中间没有多余的封装也没有让 RLC 提前介入层次非常清晰。接下来看 DU 侧怎么接球。4. F1 与 DU 侧接力NR RAN Container 和按 DRB 建隧道的关键区别4.1 F1-U 的 GTP-U隧道按 DRB 建而不是按 PDU 会话建F1 接口位于 gNB 的 CU 和 DU 之间这道接口在资源里画得非常明确。CU 侧承载 SDAP/PDCPDU 侧承载 RLC/MAC/PHY中间隔着的就是 F1。F1 上的 GTP-U 隧道是 per DRB 的这意味着如果终端当前建立了三条 DRBCU 和 DU 之间就会有三条独立的 GTP-U 隧道每条隧道用各自的 TEID 区分。TEID 在这里标识的是一条 DRB而不是一个 PDU 会话。为什么 F1 要用 DRB 作为隧道粒度因为 DU 侧的处理和核心网没有直接关系。DU 只知道空口上要传哪些 DRB每个 DRB 对应一套 RLC/MAC 配置它不需要也不应该知道这个 DRB 里的数据来自哪个 QoS Flow。所以 CU 在向 DU 转发前已经把 QoS Flow 映射到 DRB并且把 GTP-U 扩展头从 NG-U 的 PDU Session Container 换成了 F1 的 NR RAN Container。NR RAN Container 的内容由 TS 38.425 的 New Radio User Plane Protocol 产生。它承载的是 PDCP PDU 本身以及该协议需要传递的相关用户面信息。和 NG-U 上 PDU Session Container 的区别在于前者关注 QoS Flow后者关注 DRB。如果你在 F1 抓包里看到一个 NR RAN Container并且能正确解析那么这个包对应的是哪条 DRB 就已经确定了接下来的恢复、重传和丢弃判断都围绕这条 DRB 展开。4.2 DU 侧接力RLC、MAC、PHY 把数据送向空口DU 从 F1-U 隧道里取出 PDCP PDU 后进入 RLC、MAC 和物理层。RLC 层的第一个动作是分段一个 PDCP PDU 可能因为空口资源块大小限制被切成多个 RLC PDU同时在确认模式下 RLC 还要负责重传。MAC 层做的是逻辑信道复用和调度它决定这一个小 TTI 里哪个 DRB 优先占用资源PHY 层则完成编码、调制并映射到物理资源块上最终通过天线发出去。这里有个容易被忽视的点RLC 到底工作在透明模式、非确认模式还是确认模式直接决定重传行为。像网页下载这类数据业务通常走确认模式速率波动时你会看到 RLC 重传和 TCP 重传同时出现。MAC 层的调度器则是另一套逻辑它根据 CQI、QoS 参数和逻辑信道优先级来决定给每个 DRB 分配多少资源。PHY 层再把这些调度结果变成实际的资源块和 MCS。可以说空口能力全部集中在 DUCU 只做映射和安全管理。这一段的日常排障意义在于当你看到下行速率上不去但 CU 侧 PDCP 缓存又正常时问题多半不在核心网侧而在 DU 侧的调度或者空口质量。很多团队在“核心网背锅”和“基站背锅”之间来回踢其实只要确认 NG-U 和 F1 上的包都已经正常到达 DU接着看 CQI、MCS、误块率和 HARQ 重传率就能判断是不是空口问题。DU 侧没有复杂的容器转换只有实时的传输处理。4.3 实操在 N3 和 F1 抓包对比两种扩展头要验证前面说的容器切换最简单的办法是分别在 N3 口和 F1 口各抓一份包然后用 Wireshark 打开对比。N3 口对应的是 UPF 和 gNB CU 之间的 NG-U 接口典型端口是 UDP 2152F1 口对应的是 CU 和 DU 之间的接口同样跑 GTP-U端口也是 UDP 2152。所以不能靠端口区分要靠接口位置和扩展头类型区分。# 在 N3 口抓包保存为 n3.pcap tcpdump -i eth0 -s 0 -w n3.pcap udp port 2152 # 在 F1 口抓包保存为 f1.pcap tcpdump -i eth1 -s 0 -w f1.pcap udp port 2152 # 用 tshark 分别列出 GTP-U 包的关键信息 tshark -r n3.pcap -Y gtp-u -T fields -e frame.number -e ip.src -e ip.dst -e udp.srcport tshark -r f1.pcap -Y gtp-u -T fields -e frame.number -e ip.src -e ip.dst -e udp.srcport-r n3.pcap指定读文件-Y gtp-u显示过滤器里只保留 GTP-U 报文-e udp.srcport输出源端口方便确认有没有走 2152。在 Wireshark 里展开 GTP-U 层N3 口那份包应该在扩展头里看到 PDU Session Container里面带 QFIF1 口那份包应该看到 NR RAN Container里面没有 PDU Session 概念。如果你能一次抓到这两种不同的容器就说明对 CU/DU split 下用户面的理解已经落地了。我这里还要提醒一句F1 接口在真实组网里可能是光纤直连也可能经过传输设备所以抓包点要选在靠近 CU 或 DU 的物理口最好是做了端口镜像的交换机口。如果在传输设备中间抓可能会看到 IP 隧道外面还套了 VLAN 或 MPLS这不是本资源讨论的范畴但会干扰你对 GTP-U 扩展头的判断。5. 避坑手册GTP-U 封装与 QoS 映射的四个常见翻车点这部分我挑了几个自己实际踩过或者看同事踩过的坑按“现象→原因→解决”写出来。每条都能在 N3 口或 F1 口的抓包里复现你可以直接对号入座。5.1 现象抓到同一个 TEID就把所有包当成同一个 QoS Flow现象在 N3 口抓包看到一个 GTP-U TEID 后面跟着一堆 UDP 包于是断言“这些都是同一个 QoS Flow”但速率监控却显示不同分组的时延差别很大定位不到原因。原因NG-U 的 GTP-U 隧道是 per PDU Session 建立的TEID 只标识 PDU 会话不标识 QoS Flow。真正区分 QoS Flow 的是 PDU Session Container 里的 QFI。一个 PDU 会话可以包含多个 QoS Flow它们在同一个 TEID 下是正常的。解决不要只看 GTP-U 头的基本字段展开扩展头看 PDU Session Container。确认 Wireshark 已经按 TS 38.415 解析了 PDU Session Container然后记录 QFI。排障时应该以“TEID QFI”作为最小粒度而不是单独用 TEID。如果你还要进一步定位业务类型再把内层 IP 的五元组一起加进去看这样才能把 5G 核心网的 QoS 标签和实际流量对应起来。5.2 现象SDAP 包没有 SDAP 头以为映射动作没发生现象在 CU 内部抓包发现 SDAP 层没有加头包直接就是 PDCP 头于是怀疑 gNB 配置有问题QoS Flow 到 DRB 的映射根本没做。原因SDAP 有两种模式无头模式是合法的。SDAP 不加头不代表它没有参与映射只是没有用“反射 QoS”需要的信息。映射动作在 SDAP 实体内部完成头只是可选信息。解决查 RRC 消息里 SDAP-Config 中的 sdap-HeaderDL 配置。如果配置是 absent说明采用无头模式如果配置要求携带 QFI你才会在 SDAP 头里看到 QoS Flow ID。排障时不要把“没有 SDAP 头”当成“SDAP 失效”。反过来也一样某些优化工具只统计“有 SDAP 头的包”就漏掉了一半流量统计结果偏低。5.3 现象在 N3 口抓不到 PDU Session Container就开始怀疑抓包位置现象在 N3 口镜像抓包过滤 UDP 2152 后能看到 GTP-U 头但 Wireshark 里没有出现 PDU Session Container 的解析结果于是怀疑接口不对或者包被加密了。原因很多抓包工具默认不认识 3GPP 的 GTP-U 扩展头不能自动识别 Next Extension Header Type 是 PDU Session Container。包本身没有问题是解析器没跟上或者抓包文件被软件以简化方式展示了 GTP-U 结构。解决先用udp.port 2152确认这是 GTP-U 包然后在 Wireshark 里对 GTP-U 协议做 Decode As 指定再手动展开扩展头字段。也可以直接看十六进制原始数据定位扩展头长度字段和 QFI 所在字节但那样效率低。真正专业的做法是确认 Wireshark 版本支持 TS 38.415 的 PDU Session Container 解析不支持就换一个版本或使用厂商抓包工具。5.4 现象QFI 打标正确传输网还是丢包最后发现外层 DSCP 是 0现象UPF 已经按 QoS Flow 把优先级分好N3 口抓包也能看到 QFI但业务体验仍然差传输网出现丢包或排队。查了一圈发现真正决定传输优先级的 DSCP 字段在外层 IP 头上而外层 DSCP 是 0。原因QFI 是 5G 核心网侧的 QoS 标识它决定 UPF 如何映射到外层 IP 头的 DSCP。如果 UPF 的 DSCP 映射没有配置或者传输网约定使用的 DSCP 值和 UPF 默认值不一致传输设备不会根据 QFI 转发只会看外层 IP DSCP。解决在 N3 抓包时同时看内层 IP 头和外层 IP 头的 DSCP 字段。外层 IP 头是 UPF 加的优先级由 UPF 配置决定。对照核心网 QoS 参数和传输网规划检查 DSCP 映射关系确保 DSCP 值符合传输网的队列策略。这个问题最容易在外场测试时出现因为核心网和传输网经常由不同厂商维护两边对优先级的理解往往各说各话。5.5 现象RQI 置位了但终端上行还是没有按预期走映射现象下行包 PDU Session Container 里的 RQI 位已经置 1SDAP 头也带了 QFI但终端发送的上行包 QoS Flow 还是乱的。原因Reflective QoS 不是只看一个 RQI 位就能生效的。UE 需要根据下行 SDAP 头学习 QFI 到 DRB 的映射如果 SDAP 头没有携带 QFI或者上行数据满足不了激活时间要求反射映射就会失效。另外有些数据不接受反射 QoS仍需 SMF 通过显式 QoS 规则配置上行映射。解决确认 UPF 在下行包同时设置了 RQI 和 SDAP 映射所需的信息再检查终端是否支持 Reflective QoS。如果不支持就不要依赖这个机制回到显式映射直接在核心网给该 QoS Flow 下发上行 SDF 模板。从经验看外场终端能力参差不齐反射 QoS 在实验室很美好到外场就成了玄学最好在商用前把头端主动升为显式配置。把这些坑串起来看排障时如果把“看见的包”直接等同于“它代表的意思”很容易被协议分层误导。GTP-U 隧道、QoS Flow、DRB 是三个不同粒度的概念抓包前先想清楚自己站在哪个接口再决定看哪个字段能省下大量甩锅时间。你甚至可以自己做一张“接口-字段”对照表贴在最常用的抓包工具旁边。6. 进阶技巧把统计图变成排障清单先看 QFI 再看 DRB 最后看调度用一句话概括这份资源的用法不要把它当协议教程背把它当一张“数据面地图”来查。我自己的习惯是把 Figure 212 到 220 打印出来遇到下行速率或用户面问题按“每一跳”把关键字段过一遍。在 N3 口只看 QFI 和 TEID确认核心网已经给包打了正确的 QoS 标签到 F1 口只看 DRB 和 TEID确认 CU 已经把 QoS Flow 映射到正确的 DRB最后在 DU 侧看调度统计确认空口资源分配是否正常。可以把这三步写成一个自查清单。第一步核心网侧打开 N3 pcap确认 UDP 2152 端口、GTP-U TEID、PDU Session Container 里的 QFI同时检查内层和外层 IP 头的 DSCP。第二步基站侧打开 F1 pcap确认每条 DRB 是否都有独立 GTP-U 隧道NR RAN Container 是否正常解出PDCP PDU 是否连续。第三步空口侧到 DU 拉调度统计看 MCS、CQI、HARQ 重传率确认空口衰减有没有进来搅局。凡是问题在第一步就能看出来多半是核心网或传输网配置第一步正常第二步正常问题大概率在 DU 的空口调度。下面给一个把两步抓包对比变成快速验证的命令片段# 第一步查看 N3 口 pcap 中的 UDP/GTP-U 包输出 DSCP 和 IP 地址 tshark -r n3.pcap -Y udp.port 2152 -T fields -e ip.dscp -e ip.src -e ip.dst # 第二步查看 F1 口 pcap 中的 GTP-U 包确认 DRB 隧道存在 tshark -r f1.pcap -Y gtp-u -T fields -e ip.src -e ip.dst -e udp.srcport -e udp.dstport第一行里ip.dscp看的是 IP 头 DSCP在 pcap 里如果同时存在内层和外层 IP 头Wireshark 会分别显示两个 DSCP 都要看一眼。第二行不直接输出 DRB 信息因为 F1 的 DRB 靠 TEID 区分你可以把-e gtp.teid加进来进一步确认隧道端点。实际使用中字段名可能随 Wireshark 版本略有差别但思路不变核心网侧盯 QoSF1 侧盯 DRBDU 侧盯调度。从那以后我每次处理下行速率问题都强制自己走一遍这个顺序先看 N3 口 QFI 和 DSCP再看 F1 口 DRB 隧道最后看 DU 空口调度。按这个顺序做过三轮以后发现很多问题根本不在你认为的那一层比如 UPF 打标错了、SDAP 映射冲突、甚至 F1 传输抖动最后都会以“空口速率差”的形式暴露出来。希望你拿到这份图形化流程后也能把九张图沉淀成自己的排查地图希望帮到你。本文还有配套的精品资源点击获取 5G下行数据传输全流程解析：从GTP-U隧道到QoS Flow映射的避坑指南
简介5G NR下行数据传输流程涉及应用层、TCP/IP与用户面协议栈的多层协同入门者往往难以快速理清各层间的封装与分工。这份图形化资料以终端浏览网页并下载数据为场景沿HTTP GET、TCP封装、IP封装、链路层MAC直至物理层无线传输的顺序展开并以独立组网下的CU-DU架构示意SDAP/PDCP位于集中单元、RLC/MAC/PHY位于分布式单元同时用图示点出F1接口和NG-U接口上的GTP-U隧道承载关系适合5G NR协议学习者、通信工程学生及需要查漏补缺的工程师直观建立整体流程感。压缩包内为1个PDF文件约874KB体量精简目前已有270人参与学习。借助图示和逐层拆解读者能看懂TCP源/目的端口、序列号、确认号、窗口大小、校验和等头部字段的实际用途也能理解IP地址如何用于路由转发还能看到数据面从应用服务器经GTP-U隧道到终端的完整走向以及PDCP以上协议层如何逐级添加头部并最终经空口发送。对想系统掌握5G用户面数据传输和链路细节的人来说这是一份很好的图解式入门参考也适合课堂辅助或考前快速回顾。1. 5G 下行数据传输流程一张图胜过背十层协议栈做 5G 协议栈的人大概都有过这种体验刚拿到一本讲用户面流程的书翻到协议栈层叠图SDAP、PDCP、RLC、MAC、PHY 排成一列旁边再挂一个 UPF、gNB、UE图很标准但看完还是说不清一个网页请求到底是怎么从应用服务器到达手机里的。真正的 5G 下行数据传输流程并不只是“每层加个头发出去”中间还有 NG-U、F1 两条接口隧道以及 QoS Flow 到 DRB 的映射问题。这份《5G NR in BULLETS》第 248~250 页的资源用 Figure 212 到 Figure 220 共九张图把一次网页下载从 HTTP GET 开始经过 TCP/IP 封装、UPF 的 SDF 匹配、GTP-U 隧道、CU 里的 SDAP/PDCP 处理、F1 接口传输一直到 DU 的 RLC/MAC/PHY 送向空口的整条链路画了出来。它好就好在把“协议栈”换成了“每一跳加什么头”的图形化描述直观很多。适合读这份资源的人一类是刚接触 5G 用户面被 QoS Flow、DRB、TEID 这几个缩写绕晕的新人另一类是做核心网或基站集成测试需要快速定位下行速率问题出在 N3 还是 F1 的老手。接下来我会按这条数据路径拆着讲遇到容易出错的地方会直接给出排错思路。2. 从 HTTP GET 到 NG-U 封装UPF 如何用五元组和 GTP-U 把数据送进基站2.1 用户面协议栈与 CU/DU 架构先对齐Figure 212 画的是一条独立 5G 基站的用户面协议栈而且明确假设基站采用了 Centralised UnitCU和 Distributed UnitDU分离架构。在这个架构里DU 承载 RLC、MAC 和物理层CU 承载 SDAP 和 PDCP。这对读图非常关键你后面看到的 NG-U 隧道到 CU 就结束了而 F1 隧道只存在于 CU 和 DU 之间。如果不先把这个架构认定下来很容易把 PDCP 算到 DU 侧导致抓包时找错设备。协议层所在网元主要职责SDAPgNB Centralised Unit (CU)将 QoS Flow 映射到 Data Radio Bearer (DRB)PDCPgNB Centralised Unit (CU)完整性保护、加密、序号管理、可选头压缩RLCgNB Distributed Unit (DU)分段、重传AM 模式、顺序传递MACgNB Distributed Unit (DU)调度、逻辑信道复用、HARQPHYgNB Distributed Unit (DU)编码、调制、无线传输这个 split 是 3GPP 里的高层分离架构常见于需要把集中控制和实时调度分开的组网。我一般读这类图时会先看协议层画在哪个网元里再看接口名字因为 NG-U 和 F1 的 GTP-U 隧道粒度完全不同这个后面会细说。记住一个结论SDAP 和 PDCP 在 CURLC、MAC、PHY 在 DU。理解了这一点后面所有的容器和隧道切换都顺理成章。2.2 HTTP GET 到 TCP/IP浏览器这端的头部信息资源假设用户正在用浏览器访问网页并且刚向服务器发出了 HTTP GET 命令。应用层产生 HTTP 载荷后交给 TCP 封装。Figure 213 画的是 TCP 头标准大小 20 字节可以通过可选字段扩大。这里面的源端口和目的端口用来识别上层应用HTTP 默认走 80。Sequence Number 是为了让接收端能重新排序并检测丢包Acknowledgment Number 负责确认Data Offset 表示 TCP 头有多大Window Size 告诉对端自己还能收多少字节Checksum 用来检测头和载荷的误码Urgent Pointer 则是给紧急数据用的。这些字段平时做网页访问似乎用不上但真正测速出问题时TCP Window 和 Sequence 是判断传输层瓶颈的第一站。Figure 214 紧接着画了 IPv4 头同样是 20 字节标准大小。IP 头里的版本字段是 4HDR Length 表示头长Total Length 是整个包的长度。DSCP 字段用来给包打优先级ECN 用于拥塞指示Protocol 字段标识上层协议TCP 对应的是协议号 6。源 IP 和目的 IP 则由路由器决定转发方向。这里有一个容易被忽略的细节DSCP 在 IP 头里而且可以出现两次。在内层 IP 头和外层 IP 头里各有一份。核心网设备和传输网设备通常只看外层 IP 头的 DSCP所以你想让 QoS 优先级在传输网络生效必须保证外层头被正确打标。后面第 5 章的踩坑记录会专门提这个。2.3 UPF 的 SDF 匹配与 NG-U 隧道TEID 和 QFI 各管什么数据包带着 TCP/IP 头穿过 IP 网络到达 5G 核心网的用户面功能 UPF。UPF 的第一件事是通过报文解析提取五元组比如源 IP X、目的 IP Y、源端口 J、目的端口 K然后把这组字段和 SMF 在 PDU 会话建立时下发的 SDF 模板比较从而决定这个包属于哪个 PDU 会话、哪个 QoS Flow。这一步是整个下行流程里最容易让人理解错的地方QoS Flow 不是用 GTP-U 的 TEID 来标识的。UPF 匹配到 QoS Flow 后会在 NG-U 接口上建立一个 GTP-U 隧道把数据发给 gNB。这里要记住一句话NG-U 的隧道是 per PDU Session 的所以 GTP-U 头里的 Tunnel Endpoint IdentifierTEID只能标识 PDU 会话不能区分 QoS Flow。为了把 QoS Flow 信息带过去GTP-U 扩展头里加了一个“PDU Session Container”里面才有 QoS Flow IdentifierQFI。GTP-U 的格式由 3GPP TS 29.281 定义PDU Session Container 的内容在 TS 38.415 里定义。PDU Session Container 里值得关注的字段有三个PDU Type 为 0 表示这是一个下行用户面包而不是上行包PPP 位控制是否携带 Paging Policy IndicatorPPI当 UE 处于 RRC Inactive 时PPI 可以影响基站触发寻呼的优先级RQI 表示这个 QoS Flow 是否需要启用 Reflective QoS。如果想验证自己的接口抓包是否能识别到 QFI我一般会在 UPF 的 N3 口上做一个镜像抓包然后用下面的命令把 GTP-U 流量单独拎出来# 在 N3 口镜像点抓包过滤 UDP 2152 端口 tcpdump -i eth0 -s 0 -w n3.pcap udp port 2152 # 读取 pcap 并输出关键 IP 和端口信息 tshark -r n3.pcap -Y udp.port 2152 -T fields -e frame.number -e ip.src -e ip.dst -e udp.dstport第一条命令里的-i eth0指定抓包网卡-s 0表示抓完整帧-w n3.pcap写文件udp port 2152是抓包过滤器GTP-U 注册端口就是 2152。第二条命令用-Y做显示过滤-T fields只输出指定字段便于快速确认包是否已经到达 N3 口。看到 UDP 目的端口 2152 之后再在 Wireshark 里展开 GTP-U 的扩展头就能看到 PDU Session Container 以及里面的 QFI。我特别建议把图 215 和 216 一起看因为一个画的是 GTP-U 头整体结构一个画的是 PDU Session Container 内部字段。实际工作中很多同事一听到 GTP-U 就只找 TEID结果永远解释不了同一个 TEID 里为什么有不同 QoS 的包。答案很简单TEID 只负责把包送到正确的 PDU 会话QFI 才负责告诉 gNB 这个包的服务质量等级。3. CU 侧处理心法QoS Flow 映射到 DRB 时 SDAP 和 PDCP 各干什么3.1 SDAP 映射逻辑无头模式和带 SDAP 头模式gNodeB 的 CU 从 NG-U 隧道收到数据包后会先用 GTP-U 头里的 TEID 和 PDU Session Container 识别出 PDU 会话以及 QoS Flow。接下来这个包就交给 SDAP 层。SDAP 的核心职责是把 QoS Flow 映射到某一条 Data Radio BearerDRB上。原因很简单在核心网侧服务质量粒度是 QoS Flow而在空口侧真正承载数据的是 DRB。一条 DRB 可以同时承载多个 QoS Flow例如同一会话里的语音包和普通上网流量可能因为优先级不同被映射到不同 DRB。资源里画得最形象的就是 SDAP 这一层上方是来自不同隧道、不同 PDU 会话的 QoS Flow下方则是 DRB1、DRB2、DRB3。SDAP 层在这里扮演的是“分拣员”角色它决定哪个 QoS Flow 进哪条 DRB。值得注意的是SDAP 可以有两种工作方式。第一种是不加 SDAP 头直接把包交给 PDCP第二种是增加一个 SDAP 头在头里携带 QoS Flow 标识这样终端收到下行包后就能自己推导出“哪个 QoS Flow 对应哪条 DRB”再用这个映射去发送上行数据。这就是 Reflective QoS 机制。很多刚接触的人以为不加 SDAP 头就是 SDAP 没参与转发其实不是。SDAP 是否加头由 RRC 配置决定与映射动作本身无关。无头模式更省字节适合不需要反射 QoS 的场景带头模式则方便终端学习映射。SDAP 本身的规范在 3GPP TS 37.324 里原文第 5.1 节也提了。如果你想确认某个 DRB 上是否加了 SDAP 头直接在 RRC 重配消息里看 SDAP-Config 的 sdap-HeaderDL 字段比对着空口数据猜要快得多。3.2 PDCP 在 CU 做的三件事完整性保护、加密和排序SDAP 把包映射到 DRB 之后交给同样位于 CU 的 PDCP 层。PDCP 在这里要干三件事完整性保护、加密和序号管理。完整性保护是先对包算一个认证码也就是 MAC-I然后附加到 PDCP 头里接收端拿这个认证码校验包是不是被人篡改过。这里有个容易混淆的点完整性保护不是所有 DRB 都默认开启通常只对某些需要高安全性的控制面或语音业务开启具体要看 RRC 消息里的安全配置。但资源在解释协议栈时把它画成 PDCP 的标准动作理解顺序上没问题。加密是对每个 PDCP 包的负载部分做加扰接收端只有拿着对应密钥才能解开。注意加密是在完整性保护计算完认证码之后才做的因为如果先加密再算完整性接收端就没法在没有密钥的情况下先验认证码流程会复杂很多。PDCP 头里还会加上一个 PDCP 序列号接收端用这个序列号把收到的包按顺序重排。某些应用场景下 PDCP 还会做头压缩典型的是语音包普通数据包一般不做。这三件事做完之后生成的就是 PDCP PDU。到这里数据还留在 CU 侧接下来要把它转给 DU。这个转交动作走的是 F1 接口而且用的是另一组 GTP-U 隧道。很多排障的人在这里会突然觉得“刚才还是 PDU 会话现在怎么变成 DRB 了”其实就是 PDCP 层完成封装后数据面已经以 DRB 为粒度在传递了。CU 侧没有空口调度也没有 HARQ它只负责把核心网传来的 QoS Flow 翻译成 DU 能认的 DRB 数据。3.3 从 NG-U 到 F1 的容器切换为什么隧道粒度变了NG-U 接口上GTP-U 隧道是 per PDU Session 的扩展头用 PDU Session Container。F1 接口上就不一样了。CU 把 PDCP PDU 发给 DU 时QoS Flow 到 DRB 的映射已经完成所以 F1 的 GTP-U 隧道是 per DRB 的。也就是说每一条 DRB 在 CU 和 DU 之间都有一条独立的 GTP-U 隧道GTP-U 扩展头也换成 NR RAN Container而不是 PDU Session Container。这个变化是 CU/DU split 架构下不可避免的因为 DU 侧只关心 DRB不关心 QoS Flow 与核心网的对应关系。接口隧道粒度GTP-U 扩展头扩展头内容定义NG-UUPF 到 gNB CUper PDU SessionPDU Session Container3GPP TS 38.415F1-UgNB CU 到 DUper DRBNR RAN Container3GPP TS 38.425这个表格是我自己读图时总结的。NR RAN Container 承载的内容来自 TS 38.425 的 New Radio User Plane Protocol简单理解就是 PDCP PDU 以及配套的用户面传输控制信息。正因为 NG-U 和 F1 的扩展头内容完全不同抓包时不能拿同一个模板去套两个接口。第 5 章会专门讲这个坑。讲到这里CU 侧的处理路径已经清楚了GTP-U 包到达 CU - 根据 TEID 和 PDU Session Container 识别 PDU 会话和 QoS Flow - SDAP 映射到 DRB - PDCP 做安全保护和排序 - 通过 F1 接口按 DRB 隧道转发给 DU。中间没有多余的封装也没有让 RLC 提前介入层次非常清晰。接下来看 DU 侧怎么接球。4. F1 与 DU 侧接力NR RAN Container 和按 DRB 建隧道的关键区别4.1 F1-U 的 GTP-U隧道按 DRB 建而不是按 PDU 会话建F1 接口位于 gNB 的 CU 和 DU 之间这道接口在资源里画得非常明确。CU 侧承载 SDAP/PDCPDU 侧承载 RLC/MAC/PHY中间隔着的就是 F1。F1 上的 GTP-U 隧道是 per DRB 的这意味着如果终端当前建立了三条 DRBCU 和 DU 之间就会有三条独立的 GTP-U 隧道每条隧道用各自的 TEID 区分。TEID 在这里标识的是一条 DRB而不是一个 PDU 会话。为什么 F1 要用 DRB 作为隧道粒度因为 DU 侧的处理和核心网没有直接关系。DU 只知道空口上要传哪些 DRB每个 DRB 对应一套 RLC/MAC 配置它不需要也不应该知道这个 DRB 里的数据来自哪个 QoS Flow。所以 CU 在向 DU 转发前已经把 QoS Flow 映射到 DRB并且把 GTP-U 扩展头从 NG-U 的 PDU Session Container 换成了 F1 的 NR RAN Container。NR RAN Container 的内容由 TS 38.425 的 New Radio User Plane Protocol 产生。它承载的是 PDCP PDU 本身以及该协议需要传递的相关用户面信息。和 NG-U 上 PDU Session Container 的区别在于前者关注 QoS Flow后者关注 DRB。如果你在 F1 抓包里看到一个 NR RAN Container并且能正确解析那么这个包对应的是哪条 DRB 就已经确定了接下来的恢复、重传和丢弃判断都围绕这条 DRB 展开。4.2 DU 侧接力RLC、MAC、PHY 把数据送向空口DU 从 F1-U 隧道里取出 PDCP PDU 后进入 RLC、MAC 和物理层。RLC 层的第一个动作是分段一个 PDCP PDU 可能因为空口资源块大小限制被切成多个 RLC PDU同时在确认模式下 RLC 还要负责重传。MAC 层做的是逻辑信道复用和调度它决定这一个小 TTI 里哪个 DRB 优先占用资源PHY 层则完成编码、调制并映射到物理资源块上最终通过天线发出去。这里有个容易被忽视的点RLC 到底工作在透明模式、非确认模式还是确认模式直接决定重传行为。像网页下载这类数据业务通常走确认模式速率波动时你会看到 RLC 重传和 TCP 重传同时出现。MAC 层的调度器则是另一套逻辑它根据 CQI、QoS 参数和逻辑信道优先级来决定给每个 DRB 分配多少资源。PHY 层再把这些调度结果变成实际的资源块和 MCS。可以说空口能力全部集中在 DUCU 只做映射和安全管理。这一段的日常排障意义在于当你看到下行速率上不去但 CU 侧 PDCP 缓存又正常时问题多半不在核心网侧而在 DU 侧的调度或者空口质量。很多团队在“核心网背锅”和“基站背锅”之间来回踢其实只要确认 NG-U 和 F1 上的包都已经正常到达 DU接着看 CQI、MCS、误块率和 HARQ 重传率就能判断是不是空口问题。DU 侧没有复杂的容器转换只有实时的传输处理。4.3 实操在 N3 和 F1 抓包对比两种扩展头要验证前面说的容器切换最简单的办法是分别在 N3 口和 F1 口各抓一份包然后用 Wireshark 打开对比。N3 口对应的是 UPF 和 gNB CU 之间的 NG-U 接口典型端口是 UDP 2152F1 口对应的是 CU 和 DU 之间的接口同样跑 GTP-U端口也是 UDP 2152。所以不能靠端口区分要靠接口位置和扩展头类型区分。# 在 N3 口抓包保存为 n3.pcap tcpdump -i eth0 -s 0 -w n3.pcap udp port 2152 # 在 F1 口抓包保存为 f1.pcap tcpdump -i eth1 -s 0 -w f1.pcap udp port 2152 # 用 tshark 分别列出 GTP-U 包的关键信息 tshark -r n3.pcap -Y gtp-u -T fields -e frame.number -e ip.src -e ip.dst -e udp.srcport tshark -r f1.pcap -Y gtp-u -T fields -e frame.number -e ip.src -e ip.dst -e udp.srcport-r n3.pcap指定读文件-Y gtp-u显示过滤器里只保留 GTP-U 报文-e udp.srcport输出源端口方便确认有没有走 2152。在 Wireshark 里展开 GTP-U 层N3 口那份包应该在扩展头里看到 PDU Session Container里面带 QFIF1 口那份包应该看到 NR RAN Container里面没有 PDU Session 概念。如果你能一次抓到这两种不同的容器就说明对 CU/DU split 下用户面的理解已经落地了。我这里还要提醒一句F1 接口在真实组网里可能是光纤直连也可能经过传输设备所以抓包点要选在靠近 CU 或 DU 的物理口最好是做了端口镜像的交换机口。如果在传输设备中间抓可能会看到 IP 隧道外面还套了 VLAN 或 MPLS这不是本资源讨论的范畴但会干扰你对 GTP-U 扩展头的判断。5. 避坑手册GTP-U 封装与 QoS 映射的四个常见翻车点这部分我挑了几个自己实际踩过或者看同事踩过的坑按“现象→原因→解决”写出来。每条都能在 N3 口或 F1 口的抓包里复现你可以直接对号入座。5.1 现象抓到同一个 TEID就把所有包当成同一个 QoS Flow现象在 N3 口抓包看到一个 GTP-U TEID 后面跟着一堆 UDP 包于是断言“这些都是同一个 QoS Flow”但速率监控却显示不同分组的时延差别很大定位不到原因。原因NG-U 的 GTP-U 隧道是 per PDU Session 建立的TEID 只标识 PDU 会话不标识 QoS Flow。真正区分 QoS Flow 的是 PDU Session Container 里的 QFI。一个 PDU 会话可以包含多个 QoS Flow它们在同一个 TEID 下是正常的。解决不要只看 GTP-U 头的基本字段展开扩展头看 PDU Session Container。确认 Wireshark 已经按 TS 38.415 解析了 PDU Session Container然后记录 QFI。排障时应该以“TEID QFI”作为最小粒度而不是单独用 TEID。如果你还要进一步定位业务类型再把内层 IP 的五元组一起加进去看这样才能把 5G 核心网的 QoS 标签和实际流量对应起来。5.2 现象SDAP 包没有 SDAP 头以为映射动作没发生现象在 CU 内部抓包发现 SDAP 层没有加头包直接就是 PDCP 头于是怀疑 gNB 配置有问题QoS Flow 到 DRB 的映射根本没做。原因SDAP 有两种模式无头模式是合法的。SDAP 不加头不代表它没有参与映射只是没有用“反射 QoS”需要的信息。映射动作在 SDAP 实体内部完成头只是可选信息。解决查 RRC 消息里 SDAP-Config 中的 sdap-HeaderDL 配置。如果配置是 absent说明采用无头模式如果配置要求携带 QFI你才会在 SDAP 头里看到 QoS Flow ID。排障时不要把“没有 SDAP 头”当成“SDAP 失效”。反过来也一样某些优化工具只统计“有 SDAP 头的包”就漏掉了一半流量统计结果偏低。5.3 现象在 N3 口抓不到 PDU Session Container就开始怀疑抓包位置现象在 N3 口镜像抓包过滤 UDP 2152 后能看到 GTP-U 头但 Wireshark 里没有出现 PDU Session Container 的解析结果于是怀疑接口不对或者包被加密了。原因很多抓包工具默认不认识 3GPP 的 GTP-U 扩展头不能自动识别 Next Extension Header Type 是 PDU Session Container。包本身没有问题是解析器没跟上或者抓包文件被软件以简化方式展示了 GTP-U 结构。解决先用udp.port 2152确认这是 GTP-U 包然后在 Wireshark 里对 GTP-U 协议做 Decode As 指定再手动展开扩展头字段。也可以直接看十六进制原始数据定位扩展头长度字段和 QFI 所在字节但那样效率低。真正专业的做法是确认 Wireshark 版本支持 TS 38.415 的 PDU Session Container 解析不支持就换一个版本或使用厂商抓包工具。5.4 现象QFI 打标正确传输网还是丢包最后发现外层 DSCP 是 0现象UPF 已经按 QoS Flow 把优先级分好N3 口抓包也能看到 QFI但业务体验仍然差传输网出现丢包或排队。查了一圈发现真正决定传输优先级的 DSCP 字段在外层 IP 头上而外层 DSCP 是 0。原因QFI 是 5G 核心网侧的 QoS 标识它决定 UPF 如何映射到外层 IP 头的 DSCP。如果 UPF 的 DSCP 映射没有配置或者传输网约定使用的 DSCP 值和 UPF 默认值不一致传输设备不会根据 QFI 转发只会看外层 IP DSCP。解决在 N3 抓包时同时看内层 IP 头和外层 IP 头的 DSCP 字段。外层 IP 头是 UPF 加的优先级由 UPF 配置决定。对照核心网 QoS 参数和传输网规划检查 DSCP 映射关系确保 DSCP 值符合传输网的队列策略。这个问题最容易在外场测试时出现因为核心网和传输网经常由不同厂商维护两边对优先级的理解往往各说各话。5.5 现象RQI 置位了但终端上行还是没有按预期走映射现象下行包 PDU Session Container 里的 RQI 位已经置 1SDAP 头也带了 QFI但终端发送的上行包 QoS Flow 还是乱的。原因Reflective QoS 不是只看一个 RQI 位就能生效的。UE 需要根据下行 SDAP 头学习 QFI 到 DRB 的映射如果 SDAP 头没有携带 QFI或者上行数据满足不了激活时间要求反射映射就会失效。另外有些数据不接受反射 QoS仍需 SMF 通过显式 QoS 规则配置上行映射。解决确认 UPF 在下行包同时设置了 RQI 和 SDAP 映射所需的信息再检查终端是否支持 Reflective QoS。如果不支持就不要依赖这个机制回到显式映射直接在核心网给该 QoS Flow 下发上行 SDF 模板。从经验看外场终端能力参差不齐反射 QoS 在实验室很美好到外场就成了玄学最好在商用前把头端主动升为显式配置。把这些坑串起来看排障时如果把“看见的包”直接等同于“它代表的意思”很容易被协议分层误导。GTP-U 隧道、QoS Flow、DRB 是三个不同粒度的概念抓包前先想清楚自己站在哪个接口再决定看哪个字段能省下大量甩锅时间。你甚至可以自己做一张“接口-字段”对照表贴在最常用的抓包工具旁边。6. 进阶技巧把统计图变成排障清单先看 QFI 再看 DRB 最后看调度用一句话概括这份资源的用法不要把它当协议教程背把它当一张“数据面地图”来查。我自己的习惯是把 Figure 212 到 220 打印出来遇到下行速率或用户面问题按“每一跳”把关键字段过一遍。在 N3 口只看 QFI 和 TEID确认核心网已经给包打了正确的 QoS 标签到 F1 口只看 DRB 和 TEID确认 CU 已经把 QoS Flow 映射到正确的 DRB最后在 DU 侧看调度统计确认空口资源分配是否正常。可以把这三步写成一个自查清单。第一步核心网侧打开 N3 pcap确认 UDP 2152 端口、GTP-U TEID、PDU Session Container 里的 QFI同时检查内层和外层 IP 头的 DSCP。第二步基站侧打开 F1 pcap确认每条 DRB 是否都有独立 GTP-U 隧道NR RAN Container 是否正常解出PDCP PDU 是否连续。第三步空口侧到 DU 拉调度统计看 MCS、CQI、HARQ 重传率确认空口衰减有没有进来搅局。凡是问题在第一步就能看出来多半是核心网或传输网配置第一步正常第二步正常问题大概率在 DU 的空口调度。下面给一个把两步抓包对比变成快速验证的命令片段# 第一步查看 N3 口 pcap 中的 UDP/GTP-U 包输出 DSCP 和 IP 地址 tshark -r n3.pcap -Y udp.port 2152 -T fields -e ip.dscp -e ip.src -e ip.dst # 第二步查看 F1 口 pcap 中的 GTP-U 包确认 DRB 隧道存在 tshark -r f1.pcap -Y gtp-u -T fields -e ip.src -e ip.dst -e udp.srcport -e udp.dstport第一行里ip.dscp看的是 IP 头 DSCP在 pcap 里如果同时存在内层和外层 IP 头Wireshark 会分别显示两个 DSCP 都要看一眼。第二行不直接输出 DRB 信息因为 F1 的 DRB 靠 TEID 区分你可以把-e gtp.teid加进来进一步确认隧道端点。实际使用中字段名可能随 Wireshark 版本略有差别但思路不变核心网侧盯 QoSF1 侧盯 DRBDU 侧盯调度。从那以后我每次处理下行速率问题都强制自己走一遍这个顺序先看 N3 口 QFI 和 DSCP再看 F1 口 DRB 隧道最后看 DU 空口调度。按这个顺序做过三轮以后发现很多问题根本不在你认为的那一层比如 UPF 打标错了、SDAP 映射冲突、甚至 F1 传输抖动最后都会以“空口速率差”的形式暴露出来。希望你拿到这份图形化流程后也能把九张图沉淀成自己的排查地图希望帮到你。本文还有配套的精品资源点击获取