简介：一份聚焦5G NR下行数据传输流程的图形化讲解资料，适合5G网络工程师、通信专业师生以及备考5GNR认证的读者快速建立整体认知。内容以清晰的协议栈图与流程图，展示了独立组网下CU-DU分离架构的用户平面协议栈构成，并从浏览器发起HTTP GET请求出发，完整梳理下行数据依次经过应用层、TCP层、IP层、MAC与物理层直至空口传输的封装链路，同时对TCP头部与IPv4头部的关键字段（端口、序列号、确认号、数据偏移、窗口大小、校验和、源地址与目的地址等）给出逐项图解说明，使抽象协议字段与真实报文一一对应，有助于理解协议栈分层协作与路由器转发依据。资源为单个PDF文件，大小约874KB，结构紧凑、即开即用，可用于课堂演示、课后自习或5G知识笔记整理。目前已有270人学习，适合希望通过图文对照快速掌握5G下行数据流程的读者。
1. 一包网页数据的前半生：5G NR 下行在到达空口前为什么要换三套“外衣”
很多人以为 5G NR 的下行数据传输是从基站天线开始的，其实在空中接口之前，数据包已经穿过了 TCP、IP、GTP-U、UDP、SDAP、PDCP 至少六层封装，依次经过核心网 UPF、NG 接口、CU、F1 接口、DU，最后才轮到 RLC、MAC 和物理层。整条链路里真正“无线”的部分，只有最后几十米。这趟旅程的本质是不断“换外衣”：每到一个新网元，就剥掉一层旧头部，再套上新头部，而每一层头部的字段设计都对应一个明确的职责——排序、确认、路由、隧道标识、QoS 映射。搞懂这条封装链，才能解释为什么有人信号满格却卡顿、为什么 QoS Flow 配了却走默认承载、为什么寻呼会慢半拍。下面按“现象→机制→排查”的顺序，把这条链路拆开讲透。
2. 核心网侧封装：从 TCP/IP 到 GTP-U，TEID 为什么管不到 QoS Flow
2.1 TCP 与 IP 头部：20 字节里装的是排序、确认与路由的契约
下行数据从应用服务器出发，第一个动手的是 TCP 层。用户在浏览器里发 HTTP GET，默认端口 80，TCP 头部用源端口和目的端口把流量关联到具体应用。Sequence Number 为接收端提供重排序和丢包检测的依据；Acknowledgment Number 是对端确认收到的凭证；Data Offset 声明头部长度，Window Size 告诉对端“我还能收多少字节”；Checksum 覆盖头部和负载做误码检测；Urgent Pointer 则允许个别数据被标记为紧急。这 20 字节把流量控制、可靠性、优先级三类诉求压进一个固定格式，几十年没大改，说明这套契约的抽象层次选得准。
| TCP 字段 | 作用 |
|---|---|
| Source / Destination Port | 标识上层应用，HTTP 默认 80 |
| Sequence Number | 重排序、丢包检测 |
| Acknowledgement Number | 确认对端收到的数据 |
| Data Offset | 声明头部长度 |
| Window Size | 接收窗口，流量控制 |
| Checksum | 头部与负载误码检测 |
| Urgent Pointer | 高优先级数据标记 |
TCP 头之后是 IPv4 头。Version 固定为 4，HDR Length 与 Total Length 分别描述头部和整包大小，源/目的 IP 地址供路由器逐跳转发。容易忽略的是 DSCP 和 ECN 两个字段：DSCP 允许网络在 IP 层给报文分类打标，ECN 用于路由器在拥塞时显式通知对端。这两个字段到了 5G 里会“二次上岗”——UPF 会重新利用外层 IP 头的 DSCP，让传输网按业务优先级做队列调度，这一点在排查下行速率时是重点。
注意：TCP/IP 头是端到端契约，只在 UE 和应用服务器之间有完整含义。UPF、gNB 这些中间网元不改它们，只读取字段做映射决策。
2.2 UPF 的 SDF 模板匹配：五元组如何变成 PDU Session + QoS Flow
数据包穿过 IP 网络到达 UPF，这是进入 5G 核心网的入口。UPF 做的第一件事不是转发，而是“认身份”：它做包检测，把源 IP、目的 IP、源端口、目的端口等字段和 SDF（Service Data Flow）模板逐一比对。SDF 模板是 PDU Session 建立时 SMF 下发给 UPF 的，相当于一张“包往哪儿走”的对照表。例如一段视频流可能匹配 {源 IP=X、目的 IP=Y、源端口=J、目的端口=K}，UPF 据此把它归入某条 PDU Session 的某个 QoS Flow。
这一步很关键：TCP/IP 头在这里不再只是传输信息，而是变成了“业务分类”的输入。UPF 的映射结果决定了这个包在 5G 系统内走哪条 QoS 管道——超高可靠低时延，还是普通尽力而为。我一般这么理解：UPF 是把互联网的无差别数据，翻译成 5G 有差别服务的“翻译官”。翻译错了，后面所有层的映射都会跟着错，这也是为什么下行问题排查总要先确认 UPF 的 SDF 匹配是否命中。另外，核心网可能串联多个 UPF，第一个 UPF 识别完会话后，还可能用 GTP-U 隧道把包再转给下游 UPF，再交给 gNB——隧道嵌套的层次因此不总是两层。
2.3 GTP-U 与 PDU Session Container：TEID 只认会话，QFI 靠扩展头携带
映射完成之后，数据要套上 GTP-U 隧道进入核心网数据面。GTP-U 承载在 UDP/IP 之上，UDP 目的端口 2152 是它的注册端口。这里有个容易误读的设计：NG-U 接口上每条 PDU Session 只建一条 GTP-U 隧道，所以 GTP-U 头里的 Tunnel Endpoint Identifier（TEID）只能标识“哪条会话”，标识不到“哪个 QoS Flow”。QoS Flow 的信息放在紧随基础头的扩展头 PDU Session Container 里，其格式由 3GPP TS 38.415 规定，而 GTP-U 基础头本身由 TS 29.281 定义。协议层这么划，是为了让 GTP-U 隧道本体保持通用，5G 特有信息全部外置到扩展头，隧道格式才能同时服务 4G 和 5G 两代系统。
PDU Session Container 里值得记住三个字段：PDU Type 取 0 表示这是下行包；PPP 位指示后面是否携带 PPI（Paging Policy Indicator），当 UE 处于 RRC Inactive 时，UPF 可以通过 PPI 影响 gNB 发起寻呼的优先级；RQI（Reflective QoS Indicator）告诉 gNB 这条 QoS Flow 是否要让 UE 反向学习映射关系。一句话：GTP-U 基础头回答“包属于哪个隧道”，PDU Session Container 回答“包在隧道里属于哪个流、要不要特殊处理”。
| PDU Session Container 字段 | 含义 |
|---|---|
| PDU Type = 0 | 下行数据包 |
| PPP | 是否携带 PPI |
| PPI | 寻呼策略指示，影响 RRC Inactive 下的寻呼优先级 |
| RQI | 是否需要 Reflective QoS |
| QFI | QoS Flow Identifier，标识具体业务流 |
还要注意内外两层 IP 头：GTP-U 隧道在传输网上还要加一层 UDP/IP，于是同一个包有 inner IP（TCP/IP 封装）和 outer IP（GTP-U 隧道封装）两套地址。UPF 可以用 outer IP 头的 DSCP 给包打上传输网优先级的标记，到隧道对端（gNB 或链式 UPF）再一并剥掉。验证这套封装最直接的手段是抓包：
# 抓取 N3 接口 GTP-U 下行数据，只看 GTP-U 使用的 UDP 2152 端口 tcpdump -i eth0 -nn 'udp port 2152' -w n3_downlink.cap # 解析 GTP-U 的 TEID 与 PDU Session Container 中的字段 # message_type == 255 对应 G-PDU 数据面消息，过滤掉 GTP-C 控制面信令 tshark -r n3_downlink.cap -Y 'gtp && gtp.message_type == 255' \ -T fields -e gtp.teid -e gtp.pdu_type -e gtp.qfi -e gtp.ppi这里gtp.teid输出会话级隧道标识，gtp.qfi来自 PDU Session Container 里的 QoS Flow Identifier。如果gtp.qfi抓出来是空，先别急着怀疑抓包工具，回到 UPF 侧确认 PDU Session Container 是否真的被填充——很多下行“丢流”问题，本质就是这一层没填对。
3. CU-DU 拆分：为什么 SDAP/PDCP 留在 CU，F1 接口还要重打一遍隧道
3.1 高层拆分架构：DU 管实时调度，CU 管安全与映射
独立组网基站采用 CU-DU 高层拆分：DU 承载 RLC、MAC 和物理层，CU 承载 SDAP 和 PDCP。这个分工不是随手划的。MAC 层调度器要跟 HARQ 重传、信道质量反馈紧密配合，时延敏感得放在离天线近的 DU；PDCP 管加密密钥、SDAP 管 QoS 映射，实时性要求低但集中管理要求高，放在 CU 更合理。拆分之后 CU 与 DU 之间用 F1 接口相连，设计上只要 IP 可达就能承载，并不强制 CU 和 DU 在同一机房——这也是运营商能做“控制面集中、用户面分散”部署的基础。
但拆分带来一个新问题：PDCP PDU 怎么从 CU 搬到 DU？答案还是 GTP-U。F1 上的 GTP-U 隧道按 Data Radio Bearer（DRB）建立，不再按 PDU Session。意思是同一条 PDU Session 下的多个 QoS Flow，被 SDAP 映射到不同 DRB 后，会分别走 F1 上不同的 GTP-U 隧道。隧道粒度从“会话级”细化到“承载级”，这个变化不是巧合，而是因为 DU 的调度、ARQ、缓存都是按 DRB 组织的，流量天然该按 DRB 走。
3.2 SDAP 的映射逻辑与 Reflective QoS：下行头如何教 UE 发上行
数据包到达 CU 后，SDAP 层根据 GTP-U 头里携带的 PDU Session 和 QoS Flow 信息，把包映射到具体的 DRB。SDAP 有两种工作模式：不加 SDAP 头直接透传，或者带一个 SDAP 头并在头里写明包属于哪个 QFI。带头模式是 Reflective QoS 的基础：UE 收到下行包后，读 SDAP 头里的 QFI，结合当前 DRB，反推出“上行时这个 QoS Flow 应该走这条 DRB”，于是省掉一次专门的下行 RRC 重配置信令。
这个机制是“用下行数据顺便教 UE 上行映射”的典型设计，把信令开销摊进数据流。代价同样明显：如果某条 QoS Flow 一直没有下行数据，UE 永远学不到映射，必须有显式配置兜底。所以 SDAP 头是可选、Reflective QoS 是按需打开的——UPF 在 PDU Session Container 里置 RQI，就是在告诉 gNB“这条流需要触发 UE 的反射学习”。实际部署里见过不少把 RQI 全部关掉的省事配置，结果 UE 只能靠 RRC 重配才知道映射，回传信令反而多了。
3.3 PDCP 的安全面：先算 MAC-I 再加密，顺序为什么不能反
PDCP 层负责两件安全事：完整性保护和加密。完整性保护计算一个认证码（MAC-I）追加到包头，接收端拿它验证包是否被篡改或伪造；加密作用于包负载，让没有密钥的第三方读不懂内容。协议明确要求：先计算 MAC-I，再对负载加密。这个顺序是硬性规定，不是实现偏好。
为什么不能先加密再算认证码？因为完整性校验的输入必须是“明文语义”。先加密再算 MAC-I，接收端得先解密才能校验，等于把完整性建立在解密成功之上；一旦密文被破坏，解密失败，你分不清是传输损坏还是恶意篡改。而先算 MAC-I 再加密，接收端先解密、后验 MAC-I，错误类型就分得清：MAC-I 对不上，直接判定数据被动过。另外，PDCP 头里有序列号，负责接收端重排序，这也是 PDCP 必须放在 RLC 之上的原因——RLC 只保证按序递交或丢弃，跨重传恢复顺序要靠 PDCP 自己的序列号。还有一个细节：PDCP 的头压缩通常只用在语音这类载荷特征明显的业务上，普通数据包一般不压，因为压缩省下的字节在高速率业务里往往抵不上解压带来的复杂度。
3.4 F1 接口的 DRB 级隧道与 NR RAN Container
CU 完成 SDAP/PDCP 处理后，PDCP PDU 要过 F1 交到 DU。这时 GTP-U 的扩展头从 PDU Session Container 换成 NR RAN Container，内容由 New Radio User Plane Protocol（TS 38.425）规定。这个容器携带的是 RAN 内部协作所需的头信息，比如 DU 做调度决策时要用的状态信息。两个容器各管一段：NG-U 上的容器面向核心网与基站之间的业务区分，F1 上的容器面向 CU 与 DU 之间的处理协作。
| 对比项 | NG-U 接口 | F1 接口 |
|---|---|---|
| 隧道粒度 | 每条 PDU Session 一条 | 每条 DRB 一条 |
| 扩展头类型 | PDU Session Container | NR RAN Container |
| 主要用途 | 核心网与基站间业务区分 | CU 与 DU 间处理协作 |
| 关键信息 | QFI、PPI、RQI | NR User Plane 状态信息 |
我一般这么理解双层容器的设计：外层容器解决“这个包属于哪个业务”，内层容器解决“包到了 DU 该怎么处理”。如果把两段合并成一个头，核心网就不得不感知 RAN 内部的调度细节，CU-DU 拆分的灵活性也就没了。验证 F1 侧封装可以用同样的抓包思路，但解析字段换成扩展头类型：
# 抓 F1 接口数据面，按 GTP-U 端口过滤 tcpdump -i any -nn 'udp port 2152' -w f1_downlink.cap # 查看 GTP-U 扩展头类型，确认是 NR RAN Container 而非 PDU Session Container tshark -r f1_downlink.cap -Y 'gtp' -T fields -e gtp.teid -e gtp.extension_header_typegtp.extension_header_type在 N3 和 F1 上应该给出不同的取值，正好用来快速判断抓包位置抓没抓对。若解析结果不符合预期，优先怀疑两端扩展头定义不一致，这属于多厂商集成的经典雷区。
4. 5G NR 下行链路排查：吞吐上不去、走错承载、寻呼失控的几个典型翻车点
下行的坑大多不在空口，而在封装链的某一次映射失误上。以下四条是实际排查里最常见的翻车场景，每条按“现象→原因→解决”展开，可以直接对照你的抓包结果。
4.1 空口很好但吞吐上不去：先查外层 DSCP 和 TEID，别急着怪调度
现象：UE 信号满格，CQI/SINR 都正常，下行速率却只有预期的一半，空口没有重传，调度器指标也正常。
原因：问题根本不在无线侧。最常见是 UPF 在外层 IP 头上打的 DSCP 不符合传输网约定，包在回传网上被降级；另一种是 GTP-U 的 TEID 与会话建立时不一致，部分包被对端直接丢弃，表现出的症状和“无线差”一模一样，很容易让人误判。
解决：先抓 N3 接口，确认外层 DSCP 和 TEID 是否与会话建立信令一致，再逐跳沿 F1 对比。用第 2 章的 tshark 命令分别抓 N3 和 F1，把 TEID、QFI、DRB 三列列出来，哪一跳对不上就在哪一跳修。这个场景最能反映一条经验：下行速率问题里，相当大比例是“有线侧背了无线侧的锅”，核心网对无线工程师来说曾经是个黑匣子，现在抓包就能解开。
4.2 业务走了默认承载：SDAP 映射没生效时看什么
现象：用户开通了高优先级 QoS Flow，但业务流量依然占用 default DRB，体验没有任何改善。
原因：SDAP 层的 QoS Flow→DRB 映射没有配置或没有生效；或者走 Reflective QoS 时，UE 还没从下行包学到映射就急着发上行，包被塞回默认承载。这类问题一度被当成玄学，其实链路是可追踪的。
解决：在 CU 侧核对 SDAP 配置里该 QFI 是否映射到目标 DRB；抓下行包看 SDAP 头里的 QFI 是否填充、RQI 是否置位；如果 UE 一直没学到映射，不要干等下行触发，直接用 RRC 重配置显式下发映射最稳。
4.3 RRC Inactive 下寻呼优先级错乱：PPI 没透传的典型症状
现象：UE 进入 RRC Inactive 后，下行包到达触发寻呼，但语音等高优先级业务的寻呼被普通流量挤在后面，接通变慢。
原因：UPF 没在 PDU Session Container 里填 PPI，或者 PPP 位没置位，gNB 拿不到寻呼策略指示，只能按统一优先级处理。
解决：在核心网侧核对 PDU Session 的寻呼策略配置，抓包确认容器里 PPP=1 且 PPI 字段有值；如果 UPF 版本不支持填 PPI，只能升级或通过 SMF 下发的策略强制携带。这个坑相当隐蔽，它不丢包、不降速，只是“慢半拍”，不抓包很难察觉。
4.4 F1 上 DU 收不到 PDCP PDU：扩展头解析失败的兼容性坑
现象：CU 侧显示 PDCP PDU 已经发出，DU 侧却收不到完整数据，或者出现大量乱序、丢弃。
原因：F1 上用的是 NR RAN Container 而不是 PDU Session Container，两段扩展头格式不同。CU 与 DU 来自不同实现时，对扩展头长度或 Next Extension Header Type 的解析不一致，DU 找不到容器边界，整个包被丢弃。
解决：抓 F1 包检查扩展头类型与长度字段，确认两端实现的 TS 38.425 版本一致。多厂商环境里，这个验证必须放在集成测试阶段做字段级比对，否则到现网就是整条 DRB 上的数据时断时续，定位成本极高。
5. 设计取舍：双层隧道与两段容器的“冗余封装”，到底换来了什么
把整条链路摊开看，最反直觉的是“封装套封装”：TCP 包外面套 IP，IP 外面再套 GTP-U/UDP/IP，到了 F1 又来一遍。单看一个包的开销，这套设计确实“浪费”——GTP-U 头 20 字节起步，加上 UDP/IP 和扩展头，每包纯头部开销轻松超过 40 字节。但放到系统层面，这个冗余是明码标价的取舍。
第一层取舍是隧道粒度。NG-U 按 PDU Session 建隧道，因为核心网关心的是“这条会话的服务合同”：移动性、计费、策略都挂在会话上，TEID 跟着会话走，切换时只换隧道端点、不换业务归属。F1 按 DRB 建隧道，因为 DU 关心的是“这条承载的调度参数”：每个 DRB 有独立的 RLC 配置、ARQ 参数和优先级，隧道跟着承载走，DU 收到包就对应到调度实体，省掉一次会话到承载的查表。实时性要求最苛刻的一环，反而最不该多做间接查找。
第二层取舍是容器分离。把 QFI、PPI、RQI 放进 PDU Session Container 而不是 GTP-U 基础头，是为了不动隧道本体就能演进：GTP-U 头要同时服务 4G/5G 两代系统，5G 特有信息全部塞进扩展头，于是 TS 29.281 管隧道、TS 38.415/38.425 管容器。协议边界划得越清楚，实现越能独立演进。第三层取舍在安全顺序。先算 MAC-I 再加密，表面多一次计算，实际省掉了“解密失败时分不清损坏还是篡改”的排查地狱，接收端先解密后验 MAC-I，与发送端严格镜像。
这套交换的代价是每包几十字节开销，换来的是每层职责单一、各段独立演进、错误类型可判定——对一张要跑十年以上的网络来说，这笔账是划算的。如果把这条封装链的每一步头部演进画成示意图，你会更直观地看到开销花在了哪里、值在哪里。从那以后，我每次排查下行链路问题，都强制自己先沿这条封装链走一遍，标出每一跳的三个标识：TEID、QFI、DRB，画完再决定在哪里抓包。绝大多数翻车点，其实都藏在这三个标识的某一次映射失误里。希望帮到你。
本文还有配套的精品资源，点击获取
