简介一份聚焦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-UTEID 为什么管不到 QoS Flow2.1 TCP 与 IP 头部20 字节里装的是排序、确认与路由的契约下行数据从应用服务器出发第一个动手的是 TCP 层。用户在浏览器里发 HTTP GET默认端口 80TCP 头部用源端口和目的端口把流量关联到具体应用。Sequence Number 为接收端提供重排序和丢包检测的依据Acknowledgment Number 是对端确认收到的凭证Data Offset 声明头部长度Window Size 告诉对端“我还能收多少字节”Checksum 覆盖头部和负载做误码检测Urgent Pointer 则允许个别数据被标记为紧急。这 20 字节把流量控制、可靠性、优先级三类诉求压进一个固定格式几十年没大改说明这套契约的抽象层次选得准。TCP 字段作用Source / Destination Port标识上层应用HTTP 默认 80Sequence Number重排序、丢包检测Acknowledgement Number确认对端收到的数据Data Offset声明头部长度Window Size接收窗口流量控制Checksum头部与负载误码检测Urgent Pointer高优先级数据标记TCP 头之后是 IPv4 头。Version 固定为 4HDR 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、源端口、目的端口等字段和 SDFService Data Flow模板逐一比对。SDF 模板是 PDU Session 建立时 SMF 下发给 UPF 的相当于一张“包往哪儿走”的对照表。例如一段视频流可能匹配 {源 IPX、目的 IPY、源端口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 ContainerTEID 只认会话QFI 靠扩展头携带映射完成之后数据要套上 GTP-U 隧道进入核心网数据面。GTP-U 承载在 UDP/IP 之上UDP 目的端口 2152 是它的注册端口。这里有个容易误读的设计NG-U 接口上每条 PDU Session 只建一条 GTP-U 隧道所以 GTP-U 头里的 Tunnel Endpoint IdentifierTEID只能标识“哪条会话”标识不到“哪个 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 位指示后面是否携带 PPIPaging Policy Indicator当 UE 处于 RRC Inactive 时UPF 可以通过 PPI 影响 gNB 发起寻呼的优先级RQIReflective QoS Indicator告诉 gNB 这条 QoS Flow 是否要让 UE 反向学习映射关系。一句话GTP-U 基础头回答“包属于哪个隧道”PDU Session Container 回答“包在隧道里属于哪个流、要不要特殊处理”。PDU Session Container 字段含义PDU Type 0下行数据包PPP是否携带 PPIPPI寻呼策略指示影响 RRC Inactive 下的寻呼优先级RQI是否需要 Reflective QoSQFIQoS Flow Identifier标识具体业务流还要注意内外两层 IP 头GTP-U 隧道在传输网上还要加一层 UDP/IP于是同一个包有 inner IPTCP/IP 封装和 outer IPGTP-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 留在 CUF1 接口还要重打一遍隧道3.1 高层拆分架构DU 管实时调度CU 管安全与映射独立组网基站采用 CU-DU 高层拆分DU 承载 RLC、MAC 和物理层CU 承载 SDAP 和 PDCP。这个分工不是随手划的。MAC 层调度器要跟 HARQ 重传、信道质量反馈紧密配合时延敏感得放在离天线近的 DUPDCP 管加密密钥、SDAP 管 QoS 映射实时性要求低但集中管理要求高放在 CU 更合理。拆分之后 CU 与 DU 之间用 F1 接口相连设计上只要 IP 可达就能承载并不强制 CU 和 DU 在同一机房——这也是运营商能做“控制面集中、用户面分散”部署的基础。但拆分带来一个新问题PDCP PDU 怎么从 CU 搬到 DU答案还是 GTP-U。F1 上的 GTP-U 隧道按 Data Radio BearerDRB建立不再按 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 ContainerCU 完成 SDAP/PDCP 处理后PDCP PDU 要过 F1 交到 DU。这时 GTP-U 的扩展头从 PDU Session Container 换成 NR RAN Container内容由 New Radio User Plane ProtocolTS 38.425规定。这个容器携带的是 RAN 内部协作所需的头信息比如 DU 做调度决策时要用的状态信息。两个容器各管一段NG-U 上的容器面向核心网与基站之间的业务区分F1 上的容器面向 CU 与 DU 之间的处理协作。对比项NG-U 接口F1 接口隧道粒度每条 PDU Session 一条每条 DRB 一条扩展头类型PDU Session ContainerNR RAN Container主要用途核心网与基站间业务区分CU 与 DU 间处理协作关键信息QFI、PPI、RQINR 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 的寻呼策略配置抓包确认容器里 PPP1 且 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 包外面套 IPIP 外面再套 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画完再决定在哪里抓包。绝大多数翻车点其实都藏在这三个标识的某一次映射失误里。希望帮到你。本文还有配套的精品资源点击获取