简介：这份PDF以图形化方式梳理5G NR下行数据传输的完整流程，定位为5G NR协议栈入门与复习资料，适合通信专业学生、5G基站/核心网工程师及对用户面协议栈感兴趣的人员。资源仅含1个PDF文件，压缩包大小874KB，当前已有270人学习。文档通过多幅示意图展示独立组网下集中单元（CU）与分布式单元（DU）分离架构的用户面协议栈分工：CU侧重SDAP和PDCP，DU包含RLC、MAC及物理层；并以浏览器HTTP GET请求为入口，逐步说明数据从TCP/IP封装、经链路层到物理层空口传输的完整链路。TCP头部的源/目的端口、序列号、确认号、窗口、校验和，以及IP头部的源/目的地址、头部长度、DSCP/ECN、协议号等关键字段均有清晰标注，便于对照协议栈理解各层的封装与作用。相比纯文字，这种图形化表达能帮助读者快速建立端到端下行传输的整体概念，既适合初学入门，也可作为课程讲义或自学笔记的辅助材料。
1. 5G NR下行数据流：不是背协议，而是看这条封装链
一张网页加载失败，很多工程师第一反应是先查空口，但我更愿意把5G NR下行数据的完整链路先过一遍。这份关于下行数据传输流程的图形化描述，改编自运营商内部培训材料，用图212到图220把从浏览器HTTP GET到空口的每一步封装画了出来。它不堆公式，而是把最难记的头部字段和协议栈关系变成一条能顺着指过去的线。适合刚接触5G的开发者用来建立全局视图，适合面试前快速把用户平面说清楚，也适合要给新人讲“下行到底怎么走”的老手当底稿。
2. 从HTTP到IP：先把用户面协议栈和CU/DU分工吃透
2.1 协议栈图怎么读：DU管三层，CU管两层
图212画的是独立组网（Standalone）基站下的用户面协议栈，核心是CU/DU高层拆分架构。DU承载RLC、MAC和物理层，CU承载SDAP和PDCP层。你第一眼会觉得这不过是一张分层图，但真正关键的是“为什么这么拆”。
RLC、MAC、物理层必须靠近空口。MAC调度器要根据信道质量决定每个传输块塞多少数据，物理层要处理HARQ重传和调制编码，这些动作时延敏感，放在离天线近的DU才跑得动。PDCP和SDAP则更适合集中放在CU：PDCP负责加密、完整性保护、切换时的数据转发，集中管理更安全；SDAP负责把QoS Flow映射到数据无线承载（DRB），是用户面的“流量管家”。
这张图里gNB被画成两个框，但逻辑上它仍然是一个网元。外部接口看不到CU/DU的划分，内部靠F1接口连起来。很多新手把CU/DU理解成两个独立基站，其实它只是把gNB的处理栈按实时性拆开部署。F1接口传的是PDCP PDU，不是原始的IP包，这一点后面讲容器类型时会再次踩到。
另外注意图212右侧，应用服务器上也画了TCP/IP、PDCP和SDAP层，但服务器侧没有RLC/MAC/PHY。原因很简单：服务器不接触空口，它只需要把自己的数据灌进TCP/IP，剩下的交给5G网元处理。读这张图时，脑子里要区分“端到端协议”和“只跑在空口侧的协议”：IP/TCP是端到端，PDCP/RLC/MAC/PHY只在UE和gNB之间有效。
2.2 TCP/IP头字段：真正的“应用层入口”长什么样
浏览器下载网页，实际是发了一个HTTP GET命令。HTTP消息本身没有“安全边界”，它要交给TCP处理。图213的TCP头标准大小20字节，里面几个字段值得逐个记住：
- 源端口/目的端口：识别上层应用，HTTP默认端口80。
- 序列号/确认号：序列号让接收端判断顺序和丢包，确认号是接收端告诉发送端“我已经收到哪些字节”。
- 数据偏移：4位，表示TCP头长度，因为TCP头允许带选项字段，不能写死20字节。
- 窗口大小：发送端愿意接收的字节数，流量控制的基础。
- 校验和：对TCP头和负载做差错检测。
- 紧急指针：用于带外数据，比如中断信号。
TCP把HTTP流切成段，每一段都带独立的序列号，接收端才能把乱序到达的段拼回原文件。这里有个容易被忽略的细节：TCP层加的是“段”，不是“包”，到IP层才变成“包”。
图214的IP头（IPv4）标准也是20字节。版本字段值为4表示IPv4；头长（HDR Length）指出IP头长度；总长度指出整个IP包的大小。DSSCP（Differentiated Services Code Point）用于区分服务优先级，ECN（Explicit Congestion Notification）用来标记拥塞。协议字段为6表示承载内容类型是TCP，源/目的IP地址则是路由器查表转发的地图。
请注意DSCP字段。它不是5G引入的新概念，IP网络本来就有，但5G RAN侧经常把DSCP映射成5QI优先级，再映射到空口上的调度权重。图214只画字段不画映射关系，但实际部署时，UPF会在外层IP头上重写DSCP，让传输网按优先级转发，这块在后面GTP-U隧道部分还会出现。
提示：图213和图214都标了20字节，但TCP和IP头都可以带可选字段变成变长。抓包时看到“Header Length”不是20也不要惊讶，数据偏移和头长字段就是干这个用的。
2.3 传输网这一段：为什么先理解内层IP这么重要
加了IP头之后，这个包从应用服务器进入IP网络，一路路由到UPF。IP网络靠下层承载，图里没画以太网头，是因为L2对路由决策没有直接影响。但你要知道，此时包头上只有“内层IP”——源IP是服务器地址，目的IP是UE地址（或PDN地址）。这个内层IP会一直保留到隧道终点，后续GTP-U翻转时还要包上一层新的IP头。
理解“内层IP”是看懂后面所有隧道的前提。下行数据在UPF看来，就是一个普通TCP/IP包；UPF要做的是把它翻译成5G内部的会话和流，再交给传输网送到gNB。如果一开始就把内层IP和外层IP搞混，图218里的两个IP头就会让你晕头转向。
3. UPF映射与GTP-U隧道：PDU Session和QoS Flow是怎么上路的
3.1 SDF模板：UPF凭什么把IP包认成某个会话
UPF是用户面进入5G核心网的入口，它的第一件事不是转发，而是“认包”。UPF用包检测提取IP头里的关键字段，再和SMF在PDU Session建立时下发的一组SDF模板比对。SDF模板就是一组服务数据流规则，通常由五元组构成：源IP、目的IP、源端口、目的端口、协议号。原文给的例子是{源IP=X，目的IP=Y，源端口=J，目的端口=K}，命中后就能确定这个IP包属于哪个PDU Session、哪个QoS Flow。
这里要分清两个粒度。PDU Session是UE和数据网络之间的一条逻辑连接，相当于一个会话管道；QoS Flow是管道里按QoS需求切分的数据流，同一个会话可以有多条不同优先级的QoS Flow。UPF把IP包映射到具体QoS Flow，gNB侧后续才能决定把它放到哪条DRB上调度。
如果核心网部署了多个UPF，数据可能链式经过多个UPF才到gNB。这种情况下，第一个UPF需要把数据通过GTP-U隧道转给下一个UPF，隧道终点右移。原文图示里虚线画的“GTP-U Tunnel per PDU Session”指的就是这段链路上的隧道关系。
| SDF模板匹配维度 | 说明 |
|---|---|
| 源IP地址 | 应用中谁在发 |
| 目的IP地址 | 数据给到谁 |
| 源端口 | 源端应用标识 |
| 目的端口 | 目的端应用标识 |
| 协议号 | TCP/UDP等 |
3.2 GTP-U头：TEID只管会话，QoS Flow要靠PDU Session Container
GTP-U隧道是整个用户面的骨架。原文明确：每个PDU Session建一条GTP-U隧道，TEID标识PDU Session，但TEID不标识QoS Flow。这是最容易被误解的一点。很多人以为隧道粒度一定等于流的粒度，实际不是这样。GTP-U头里的PDU Session Container才是携带QoS Flow标识的地方。
图215的GTP-U头包含扩展头，扩展头里放PDU Session Container。这个容器由3GPP TS 29.281定义结构，内容由TS 38.415定义。图216把它的字段拆开：
- PDU Type=0表示下行数据包，而不是上行。
- Paging Policy Presence（PPP）表示后面是否带Paging Policy Indicator（PPI）。
- PPI：UPF提供PPI给gNB，当UE处于RRC Inactive时，如果这个下行包到达，gNB要发寻呼，PPI影响寻呼优先级。
- Reflective QoS Indicator（RQI）：表示这个QoS Flow是否要采用反射QoS。
你可能要问：为什么TEID不直接带上QFI？因为TEID在GTP-U隧道建好后就被固定了，一条隧道上的所有包TEID都一样，效率更高。QoS Flow是动态变化的，SDAP层还要根据DRB配置做二次映射，所以放在扩展头里灵活匹配。抓包时看到同一个TEID下有很多不同QFI的包，这不奇怪。
GNB侧怎么处理这个包呢？gNB CU先读GTP-U头，拿出PDU Session和QoS Flow信息，再做SDAP层映射。也就是说，CU收到的数据包已经被拆解成“会话+流”两个维度，后续处理就可以精细到流级。
3.3 内层IP和外层IP：一张图里最容易看懵的两个头
GTP-U隧道跑在UDP/IP之上，传输网只认识外层IP和UDP端口。端口号固定用2152，UDP头只有8字节，简单直接。这一步会产生一个非常反直觉的结果：数据包里有两个IP头。内层IP是应用服务器和UE之间的原始寻址，外层IP是UPF到gNB（或UPF到UPF）的传输寻址。
图218把两个IP头都画了出来，目的就是想让你看清“套娃”。外层IP的源地址是UPF的传输地址，目的地址是gNB的传输地址；内层IP的源地址是应用服务器地址，目的地址是UE地址。UPF可以利用外层IP头里的DSCP字段做差异化转发：高优先级的QoS Flow在外层打上高DSCP，传输网路由器看到后优先转发。
两个IP头的区别要在抓包时特别注意：过滤器显示的第一个IP头一定是外层，往里剥才看到内层。初学者经常把内层目的IP当成去往gNB的路由地址，结果Trace里看着永远“路由不通”。
| 内层IP | 外层IP |
|---|---|
| 源：应用服务器地址 | 源：UPF传输地址 |
| 目的：UE地址/PDN地址 | 目的：gNB传输地址 |
| 作用：端到端寻址 | 作用：隧道内传输寻址 |
| 在gNB CU处不被修改 | 在隧道终点被剥离 |
4. CU侧SDAP与PDCP：把IP包变成无线可传的PDCP PDU
4.1 SDAP映射：QoS Flow到DRB，为什么一个会话可以挂多条DRB
gNB CU收到GTP-U包后，SDAP层就要上场了。SDAP的全称是Service Data Adaptation Protocol，它的职责是把上一个环节识别到的QoS Flow映射到具体的Data Radio Bearer（DRB）。图219画得很清楚：同一个PDU Session里的QoS Flow A、B、C映射到DRB 1，D、E、F映射到DRB 2；另一个PDU Session的数据又映射到自己的DRB组。
为什么一个会话能挂多条DRB？因为不同QoS Flow的时延、可靠性、优先级的诉求不一样。视频通话和网页下载可能同在一个PDU Session，但它们对无线承载的要求完全不同。DRB是空口侧承载的边界，每个DRB关联一套独立的RLC配置、MAC逻辑信道配置和调度优先级。SDAP的作用就是把IP包分类归栈。
SDAP有两种工作模式。第一种是不加SDAP头，直接透传，这样做少几个字节的开销；第二种是加SDAP头，在头里写入QoS Flow ID（QFI），主要用于反射QoS场景。反射QoS的含义是：UE收到下行包，看到SDAP头里的QFI和它所在的DRB，就能推断出上行包应该往哪条DRB上发，省去RRC单独配置的步骤。RQI（Reflective QoS Indicator）就是开关这个机制的。
这里有个实用细节：SDAP映射时，IP包本身已经带了内层IP头、TCP头等，SDAP头是加在最外层的。如果你抓包看到PDCP PDU里包裹的数据开头不是IP头而是SDAP头，不要惊讶，剔除SDAP头之后再解析IP层才正常。
4.2 PDCP安全与序列号：加密、完整性保护、头压缩各管哪一段
PDCP做的三件事，顺序很关键。
第一件是完整性保护。PDCP算出一个认证码，叫做MAC-I字段，追加在PDCP头之后，接收端用同样的密钥和算法重新计算并比对，以确认这个PDCP PDU不是别人伪造的。注意，MAC-I是“认证标签”，不是密文。
第二件是加密（Ciphering）。加密作用在PDCP负载上，是在完整性保护计算完成之后才做的。也就是说，先算认证码，再对payload加密。接收端的处理顺序正好反过来：先验证完整性，再解密。如果顺序错，解密出来的数据校验一定不过。
第三件是加PDCP序列号。序列号字段让接收端可以对乱序到达的PDCP SDU做重排，也可以检测丢包。PDCP序列号长度有12比特或18比特两种配置，具体看RRC怎么配，代码级联查表时要分清。
头压缩是另一个话题。PDCP可以选择性做ROHC，压缩掉冗余的IP/UDP/RTP头，语音包往往受益明显，因为语音净荷小，头占比高；对TCP大包来说，头压缩收益有限，还可能引入额外复杂度。图219里没有细化压缩流程，但在实际系统中，是否启用ROHC是由QoS Flow配置决定的，不是PDCP自己拍板。
PDCP做完这些，PDCP PDU从CU送到DU，接口是F1。这里有一个和NG-U隧道的关键差异：NG-U上是GTP-U per PDU Session，而F1上是GTP-U per DRB。因为数据已经从流粒度映射到了承载粒度，CU自然按DRB开隧道。F1 GTP-U头里不再用PDU Session Container，而是换成NR RAN Container，这个容器封装了TS 38.425里定义的NR用户面协议信息。换句话说，下行路径上你会看到两种不同的GTP-U扩展头，别混用。
到了DU之后，RLC负责分段和重传，MAC负责逻辑信道复用和HARQ，物理层做编码调制后从空口发射出去。图里没有展开RLC/MAC/PHY的具体字段，但链路走到这里，用户平面的封装就已经从“套IP头”变成了“无线承载”，后面就是空口资源调度的事了。
5. 常见问题与避坑：五个让你画错流程图的点
5.1 现象：把GTP-U隧道误以为按QoS Flow建立
很多人第一次看图212-215，会直接把“GTP-U Tunnel per PDU Session”理解为“每条QoS Flow一条隧道”。实际NG-U接口上一条PDU Session只建一条GTP-U隧道，TEID对应PDU Session，QoS Flow靠PDU Session Container里的QFI区分。
原因：GTP-U是承载层隧道，隧道数量越少越好，而QoS Flow是动态变化的业务流，设计上就不该和隧道一一绑定。
解决：抓包时先看TEID字段，再对比同一个TEID下的QFI变化。如果同一个TEID下出现多个QFI，说明系统行为正确，不要当成异常。
5.2 现象：F1接口上还在用PDU Session Container
CU和DU之间走F1接口，这里的GTP-U头扩展容器类型是NR RAN Container，不是NG-U上用的PDU Session Container。如果在F1抓包里找QFI，是找不到的。
原因：F1接口数据已经映射到DRB，隧道粒度是DRB，承载信息由NR RAN Container携带；QoS Flow到DRB的映射发生在CU的SDAP层，F1之后不再需要QFI。
解决：区分两段容器的使用位置。NG-U找TS 38.415定义的PDU Session Container，F1找TS 38.425定义的NR RAN Container。
5.3 现象：把PDCP的MAC-I字段当成普通头字段
在做PDCP头解析时，有人会把MAC-I当作固定头长度，剥离后直接解密payload，结果解密数据校验失败。
原因：MAC-I是完整性保护产生的认证码，它的存在让PDCP头长度随算法和密钥变化，不能简单当作固定偏移。接收端必须先验证MAC-I，再处理密文。
解决：排查PDCP问题序列时，按“先完整性、后解密”的顺序操作。在抓包工具里需要根据PDCP头里的长度字段动态计算MAC-I位置，不要硬编码偏移。
5.4 现象：把UDP端口2152当成5G新协议
一看到GTP-U就用“5G专用协议”去查资料，其实GTP-U从3G/4G时代就在用，UDP 2152端口也不是5G定义的。
原因：5G只是沿用了GTP-U隧道框架，新增了PDU Session Container和NR RAN Container这些扩展头结构。
解决：遇到GTP-U头解析问题，先查3GPP TS 29.281，那是基础规范；再查TS 38.415和TS 38.425去认扩展头内容。
5.5 现象：分不清RQI和PPI各自影响谁
PDU Session Container里既有PPI又有RQI，有人直接混为一谈，画流程时把寻呼优先级画到UE侧。
原因：PPI是UPF给gNB寻呼用的，影响RRC Inactive状态下UE被寻呼的优先级；RQI是给UE的反射QoS指示，影响UE上行数据映射到哪条DRB。
解决：按“谁消费这个字段”来记。PPI的消费方是gNB，RQI的消费方是UE。这样画图时不会放错位置。
6. 把图212到220串成一条线：我常用的验证技巧
6.1 用“封装前后对照表”自检
这套图形化资源最好的用法不是单张图看，而是把图213、214、215、216、218、219、220按数据流方向排成一条线，做一张封装前后对照表。从HTTP数据开始，每经过一层就记录新增的头字段名，同时标出哪个字段是端到端保留、哪个字段只在一个网段有效。
对照表示例：
| 阶段 | 新增头 | 关键字段 | 作用范围 |
|---|---|---|---|
| 应用 | HTTP请求 | URL/方法 | 端到端 |
| TCP | TCP头 | 端口/序号/窗口 | 端到端 |
| IP | IP头 | 源/目的IP、协议号 | 端到端 |
| UPF | GTP-U头+PDU Session Container | TEID、QFI、RQI | 核心网到gNB |
| CU-SDAP | SDAP头（可选） | QFI | gNB内部映射 |
| CU-PDCP | PDCP头 | 序列号、MAC-I | UE到gNB |
| F1 | GTP-U头+NR RAN Container | TEID、DRB标识 | CU到DU |
做完这步，对“哪个头在哪里被剥掉、哪里被加上”就有了肌肉记忆。
6.2 从抓包结果倒推图里每个字段
有环境的话，可以起一个小型5G模拟环境，让UE发起一次网页下载，在UPF和gNB之间抓包。过滤条件用UDP端口2152，抓到GTP-U包后，按图215逐字节比对：先是8字节GTP-U头，接着是扩展头长度，再找到PDU Session Container，读出PDU Type、RQI、QFI。整个过程和纸上读图完全一致，但你能看到动态的TEID值和ANDING的QFI变化。
没有模拟环境也没关系，在gNB内部日志或开源核心网的包记录里一样能找到GTP-U头样例。关键点是：亲手做一次“报文到图字段”的映射，比反复看十遍图都管用。
6.3 给新手的一条阅读顺序
如果你刚接触这份资源，建议按“上行逆推”的方式读一遍：从图218的GTP-U隧道倒回图213的TCP/IP，再正向从应用层走到F1。逆推会让你记住每个头是“为了解决上一层的什么问题”才加进来的，正向走一遍则确认没漏掉网元。从那以后我每次讲5G下行数据流程，都强制自己先画一遍这条封装链再翻PPT，画完再对照图212到220查漏，错过的细节基本都能找回来。希望帮到你。
本文还有配套的精品资源，点击获取
