简介5G NR下行数据传输完整流程的图解资料以图形化方式呈现从应用层到物理层的端到端数据传递过程面向5G网络工程师、通信专业学生或初识5G NR协议的读者。内容以独立基站为场景基于CU-DU高层切分架构展示用户平面协议栈梳理SDAP、PDCP、RLC、MAC与物理层各功能实体的分工并结合用户浏览网页的实际案例逐一拆解TCP层与IP层头部字段的作用帮助理解数据包从HTTP GET请求产生到最终经无线链路发送的每一环。资源为单个PDF文件压缩包约874KB内容精炼但覆盖完整流程图与关键头部字段说明。目前已有270人浏览学习说明该图解对初学者理解协议栈分层与数据面流程具有参考价值。拿到手可直接对照图表梳理下行链路适合配合教材或课程进行可视化复盘也可作为面试或考试前快速回顾5G NR下行数据流程的资料。1. 5G下行数据传输流程的图形化描述为什么值得亲手画一遍5G下行数据传输流程这个概念看协议文档很容易跟人讲清楚却很难数据从核心网出来到基站再到终端中间经历了GTP-U封装、SDAP映射、PDCP加密、RLC分段、MAC调度、HARQ重传……每一步都是「包一层、转一层」。很多人对着文字能背一被问「这个包在基站里到底长什么样」就卡壳。图形化描述解决的就是这个问题把这条链路上每一跳的封装变化、映射关系、调度过程画成一张人能一眼看懂的图。它不追求协议层面的绝对完整而是追求「拿着这张图能跟同事把一次下行数据的完整旅程讲明白能对着它定位问题」。这张图适合三类人刚接触5G协议栈的开发者需要把数据面流程讲给上下游听做外场测试和问题分析的人拿图当排查底图还有给非通信背景同事做技术普及的人。下面我按「先理清链路 → 再定图元 → 再画关键段 → 最后拿来排查」的顺序把整套做法拆给你。2. 先定坐标系5G下行链路到底要画哪些节点和协议画图前最重要的事不是打开绘图工具而是先把「坐标系」定下来。这里的坐标系是指这条下行数据链路从起点到终点经过哪些网络元素每一段使用哪些协议每一段的数据在图上应该是什么形态。如果这一步不先理清画出来的图多半会变成「节点加箭头」的拓扑图看起来完整实际上没讲清楚数据是怎么被封装、映射、调度和还原的。2.1 先认角色终端、基站、UPF以及它们之间的承载关系一次典型的5G下行数据传输主干路径是应用服务器 → UPF核心网用户面功能 → gNB基站 → UE终端 → 终端应用。这条路径上有四个关键角色画图之前必须明确每个角色在用户面承担什么职责。这里有两个常见误区。第一不要把核心网画成一朵云云会把UPF的位置模糊掉用户面数据必须经过UPF这一跳画清楚UPF才能解释N3接口和GTP-U隧道。第二不要把gNB画成一个黑盒gNB内部是一个完整的协议栈处理链把gNB画成一根天线会丢掉SDAP、PDCP、RLC、MAC、PHY这一串环节而这恰恰是下行流程里最容易被追问的部分。我把常用的角色清单整理如下画图时可以直接照这个表给每个节点加一行小字标注链路角色用户面职责图上画法建议应用服务器产生原始IP数据包经N6接口发给UPF左侧服务器图标旁注「原始IP包」UPF终结N6接口建立GTP-U隧道将数据转发给gNB圆角矩形旁注「GTP-U封装/转发」gNB解析GTP-U完成SDAP、PDCP、RLC、MAC、PHY处理后从空口发出圆角矩形内部绘制五层协议栈简图UE空口接收按逆序逐层还原IP包并交给应用圆角矩形内部绘制与gNB镜像的协议栈简图角色认全后还要顺手决定控制面要不要上图画。我的建议是数据面为主控制面只做阴影标注。SMF负责PDU会话和QoS规则管理AMF负责信令这些网元可以在图的角落用一个小方框标一句「隧道参数和QoS规则由控制面协商数据面按规则执行」即可。如果你想展开注册、鉴权、PDU会话建立流程那是另一张图不要塞进同一张数据流图。2.2 画「数据包的旅程」别画协议栈大全图形化的核心是「一次数据包的旅程」任何时候看图的人都能说得出当前这个数据包在哪个节点、被加了什么头、变成了什么形态。如果你把图展开成所有接口和所有协议的堆叠图会迅速变成一张没人看得懂的蜘蛛网。我习惯在动笔前先用文字把旅程过一遍这段文字就是整张图的「剧情主线」应用服务器发出的原始IP包到UPF后被封装成GTP-U包经N3隧道送到gNBgNB侧SDAP识别GTP-U扩展头中的QFI确定这个数据属于哪个QoS Flow再按映射规则把它映射到对应的DRB随后PDCP做加密加头RLC按DRB配置做分段MAC把多个逻辑信道的数据复用成一个传输块并分配给某个HARQ进程PHY完成调制后从空口发出UE一端按PHY到SDAP的逆序逐层解封装最终把原始IP包还原给应用。这段话建议直接写在画布最上方画到任何一步都要回来对照避免画着画着开始堆细节。还有一个实用的读图顺序建议横向从左到右看链路节点纵向在每个节点内部从下到上或从上到下看协议栈。比如gNB内部是从上到下走「加头路径」UE内部是从下到上走「去头路径」。两个方向一旦确定全图统一读者就不会迷路。2.3 图例规范一张图必须能「不靠解释」读懂图形化描述最容易翻车的地方是图例不统一有人用实线箭头表示数据流又用实线箭头表示信令有人用方框表示节点又用方框表示协议头。结果是图画完了只有作者自己能看懂。我常用的图元规范如下可以直接抄走节点圆角矩形内部写节点名称和核心功能协议头与该层缩写同名的小色块叠加在数据包上表示「加了一层头」数据流粗实线箭头沿箭头方向标注当前数据形态例如「GTP-U包」「PDCP PDU」控制或调度流细虚线箭头用于DCI调度、HARQ反馈等隧道双线或管道形状内部标注隧道参数映射关系细点线连接「源」和「目标」标注映射条件例如「QFI2 → DRB3」。提示同一张图上出现的线型不要超过三种。数据流、控制流、映射关系这三类足够覆盖绝大多数场景类型再多就会乱。坐标系理清、图例定好下面可以正式动笔画图了。整条链路我习惯分成两段来处理核心网到基站是一段基站到终端是另一段。两段的画法逻辑完全不同分开讲。3. 从核心网到基站N3隧道、GTP-U封装和三个必标参数下行数据从UPF出来后进入gNB之前走的是N3接口。N3在图形上不能简单画成一条线因为它实际承载的是GTP-U隧道UPF把原始IP包封装进GTP-U协议再放到UDP/IP之上通过N3发送给gNB。gNB收到后靠隧道参数识别出这是哪个PDU会话、哪个QoS Flow的数据。这一段是整个下行流程的第一站也是画错率比较高的位置。3.1 为什么 N3 要画成「隧道」而不是「链路」链路和隧道在图形上的表达完全不一样。链路画一条线读者会理解为「数据从一头送到另一头」隧道要画成一条管道或双线并标注「隧道起点、终点和携带的会话信息」读者才能明白这条通道上可能同时跑着多个PDU Session、多个QoS Flow它们复用同一条物理链路靠隧道参数区分彼此。画法上我会把N3接口画成一条粗管道管道上方标注「N3 / GTP-U」管道内部放一个GTP-U包的叠层示意最里层是原始IP包往外依次是GTP-U头、UDP头、IP头。这样看图的人一眼就知道这一段的空中传输不是裸IP而是「包了三层的GTP-U包」。如果只画一根线标「N3」读者完全看不到数据形态的变化而这恰恰是下行流程最核心的信息。3.2 三层封装叠层把「UPF 加头、gNB 拆头」画出来具体画法我习惯分四步走用绘图工具的矩形叠层就能实现第一步画UPF和gNB两个圆角矩形节点中间留出足够宽的画布区域放隧道图标。 第二步在UPF出口处画三个小矩形叠层最下层是「原始IP包」中间是「GTP-U头TEID、QFI」上层是「UDP/IP头源地址为UPF目的地址为gNB」。 第三步沿隧道方向画粗实线箭头到gNB入口处画同样的三块叠层但标注改为「剥离UDP/IP头 → 剥离GTP-U头 → 还原出原始IP包」。 第四步在gNB旁加一个注释框写明两个关键字段的含义TEID由gNB分配用于识别PDU会话QFI标识QoS Flow后续SDAP层要基于它做映射。为什么一定要强调「UPF加头、gNB拆头」因为这是我见过最多人画错的地方。很多图在UPF到gNB之间只画一个箭头标一个「N3」没有体现任何数据形态变化。而数据形态的变化才是下行流程最值得图形化的内容。形象不是说画得像而是说每一步的输入输出都能在图上直接看出来。3.3 三个必标参数TEID、QFI、PDU Session ID画完隧道后建议在图上固定标出三个参数。它们是排查下行问题时最常要和日志对着看的字段参数作用图上建议位置TEID标识隧道端点区分PDU会话由接收端分配发送端填入隧道图标内或GTP-U头叠层上QFI标识QoS FlowSDAP据此映射到DRBGTP-U扩展头旁用点线连到SDAP层PDU Session ID关联PDU会话一个会话下可以挂多个QoS Flow隧道起点和终点旁各标一次实际操作中这三个参数都能在抓包日志里直接看到。图上一旦标出它们排查问题时就可以拿图逐段比对N3段丢包率高先查是哪个TEID的流在丢QoS达不到预期先看QFI到DRB的映射是否按预期执行。画图不是画完就结束这张图要能陪你进排查现场。注意GTP-U头里的QFI不是固定出现在每一个包里它一般通过GTP-U扩展头按配置携带。图上要标注「按需携带」避免有人误解为每个GTP-U包都必然带QFI字段。4. 基站协议栈与空口的4个避坑点从SDAP到PHY的加头路径gNB收到GTP-U包后接下来的一连串处理都在基站内部完成最后从空口发出去。这一段是整个下行流程的主战场也最容易画翻车。原因很简单这段涉及五个协议层每一层都在改数据形态MAC层还牵涉调度和HARQ重传状态多、箭头也多。下面的内容我按「先摆正五层路径再逐个讲四个避坑点」的顺序来写每条避坑点都按现象、原因、解决的顺序展开。4.1 基站内部协议栈的「加头路径」五层处理怎么摆我在图上习惯把gNB画成一个大圆角矩形内部纵向排五个协议层从上到下依次是SDAP、PDCP、RLC、MAC、PHY。下行方向从上往下走每经过一层数据就加一个头或做一次变换所以我叫它「加头路径」。各层的输入、处理和输出形态整理成一张表可以直接对照着画协议层输入处理动作输出形态SDAP从GTP-U还原出的IP包及QFI识别QoS Flow按映射规则映射到DRB可选加SDAP头SDAP PDUPDCPSDAP PDU加密、加PDCP头维护COUNT值PDCP PDURLCPDCP PDU按DRB配置分段或拼接AM模式下做重传管理RLC PDU带分段信息MAC多个逻辑信道的RLC PDU复用一个传输块分配HARQ进程组装MAC头传输块TBPHY传输块编码、调制、资源映射和波束赋形空口信号画图时每一层的输出都要画成一个「数据加新头」的小叠层并在旁边标出这一层新加的东西是什么。例如PDCP的输出可以画成「IP数据 SDAP头 PDCP头」三块叠层到了RLC层再画成「PDCP PDU被切成段每段加RLC头」。这样读者能顺着叠层直观地看到数据一步步变「厚」这是整张图最需要耐心画的部分。4.2 避坑点一QoS Flow 画成与 DRB 一一对应现象图上每个QoS Flow门前挂一个DRB看起来整齐划一一对一的直线关系。原因SDAP的映射规则被忽略了。实际上SDAP会按核心网下发的映射规则把多个QoS Flow的数据映射到同一个DRB当QoS Flow经历重配置时它还可能从一个DRB切到另一个DRB。DRB的建立还绑定PDCP和RLC配置并不是按QoS等级简单一一对应。解决把「QoS Flow到DRB的映射」画成一张独立小表放在SDAP层右侧用点线箭头指出当前时刻的映射关系并留一行备注「映射关系可由RRC重配置随时调整」。排查时这条非常关键我曾经在分析某项目的下行速率不达标问题时按照一一对应的思路查配置查了很久后来把图上的映射关系改成「一对多」才意识到某个高优先级QoS Flow被SDAP映射到了低优先级DRB导致它和普通流量抢资源。4.3 避坑点二MAC 调度省略了复用与 HARQ 进程现象图里多个逻辑信道各自拉一根线到PHYPHY直接发出去MAC层完全空了。原因MAC层的复用和HARQ进程被当成「细节」省略了。但空口上真正发送的每一个TB都是MAC把多个逻辑信道的数据复用成一个传输块并分配一个HARQ进程来管理重传的。省略这一步图的空口部分会和实际抓包完全对不上。解决在MAC层内部画一个「复用」小方块输入侧画多个逻辑信道的箭头输出侧只画一个TB箭头TB旁边标注它所属的HARQ进程号以及初传或重传状态。这样读者能看到「多个逻辑信道合成一个传输块」的汇聚关系也能理解为什么空口一次只能调度一个TB。4.4 避坑点三HARQ 只画 ACK/NACK没画进程和重传现象空口上画一个箭头标着「HARQ ACK」就认为反馈画完了。原因HARQ是停止等待加多进程机制下行配置有多个HARQ进程并行工作。如果不画进程号就无法表达「同一个进程在初传失败后调度重传NDI反转表示新数据」这一套机制。而这类细节恰恰是空口日志里最常见的问题定位点比如重传占比异常就要靠HARQ进程号去追踪。解决在传输块箭头上标注「HARQ进程n初传」或「HARQ进程n重传」在终端侧画一个返回箭头标注「PUCCH反馈ACK/NACK」再用一条虚线把NACK导致重传的逻辑引回MAC调度模块。画完这一步空口的收发闭环才算真正成立。4.5 避坑点四空口画成「一条波」而忽略了时频资源和 DCI现象UE和gNB之间画一条弯弯的「电波」看起来形象实际上信息量为零。原因空口传输不是「把数据丢过去」而是基站先通过PDCCH下发DCI告诉终端「在哪个时频位置、用哪种调制方式接收」。终端依据DCI里的资源分配信息去解PDSCH。如果图形上不体现DCI空口就是一个黑匣子看的人不知道数据到底是怎么被收下来的。解决如果空间允许把空口从「一条波」改成「资源栅格」小图横轴是时间纵轴是频率栅格里用色块标出当前TB占用的资源和调制方式。如果觉得栅格太复杂至少要画两条方向不同的箭头一条下行数据走PDSCH一条下行调度走PDCCH并标注DCI旁边加一行调制方式说明。注意越接近物理层的部分越不能偷懒。上层图画错了看的人能靠常识纠正MAC和PHY的图画错了会直接给排查埋坑。5. 终端侧解封装与 QoS Flow 映射图形上怎么标注最直观基站侧画完数据到UE后还要走一条逆序路径。很多图在这里断掉画到空口就结束读者看到的数据是「发过去了」但终端接收后怎么还原完全没有交代。实际上下行流程的完整闭环必须画到「终端应用收到原始IP包」为止少这一段图的价值就少了一半。5.1 镜像画法gNB 加头、UE 去头一目了然最直观的做法是镜像gNB侧从上往下做「加头」UE侧从下往上做「去头」。UE内部的协议栈层序和gNB完全对称——PHY收信号、MAC解复用、RLC重组、PDCP解密、SDAP映射还原IP包。画图时把两个协议栈放在左右两侧中间隔一道空口两边的叠层用同一套颜色方向相反。具体到UE内部我的画法是纵向从下往上排PHY、MAC、RLC、PDCP、SDAP五层。每一层接收到的叠层先去掉本层对应的头再向上交。PHY解调出TB交给MACMAC去掉MAC头、把多个逻辑信道的数据分流给RLCRLC把分段重组回完整的PDCP PDU去掉RLC头后给PDCPPDCP校验并解密去掉PDCP头后给SDAPSDAP根据映射规则还原出IP包交给终端协议栈。镜像画法最直接的好处是看图的人一眼就能找到对称点。比如被问到「PDCP头在哪儿加上、在哪儿去掉」手指一左一右两秒钟讲完。这也是「形象」的核心价值——看图的人不是在读文档而是在找镜像、找对应。5.2 区分数据流与控制调度DCI、HARQ 反馈和用户数据别混线空口这一段同时存在三类信息PDSCH上承载用户数据PDCCH上承载DCI调度命令PUCCH上承载HARQ反馈和信道质量信息。如果全部画成同一种实线箭头图会变得极其难读。我用的还是第2章定的图例规范数据流用粗实线DCI调度用细虚线HARQ反馈用反向短虚线。把三类流分开后可以往深画一步把DCI和PDSCH画成「一对」。从gNB的MAC调度模块出发DCI先到UE告诉终端怎么收随后PDSCH带数据到达UE根据DCI里的频域资源、调制方式、HARQ进程号去解PDSCH。这个过程画完后空口从「一根波」变成「一套可讲解的收发协议」这是图形化描述从入门到实用的分水岭。5.3 从 QoS Flow 到应用把 DSCP、QFI、DRB 映射补在图的边上很多图在SDAP层把数据还原成IP包就停笔了。但做QoS排查的人往往会追问一句这个IP包在接入网侧对应哪个QoS Flow在空口走的是哪个DRB这个对应关系在数据包里没有直接字段需要用QFI和映射配置来解释图中最好专门留一块区域画映射关系。我习惯在图的右下角放一张小映射表列出三个层级之间的对应外层IP头里的DSCP映射到QoS Flow的QFISDAP再把QFI映射到DRBDRB再对应到RLC信道和逻辑信道。画这条完整链的好处是出问题时可以直接顺着链路找是第几级映射出了问题是DSCP标记错了还是QFI映射表配错了还是DRB的调度优先级不够。提示DSCP与QFI的映射依赖核心网的QoS策略不同运营商、不同切片可能完全不同。图形上只画「当前项目配置下的对应关系」不要画成普适规则。到这里整张图的闭环已经建立。下面是最后一步也是把图从「讲解工具」变成「排查工具」的关键一步。6. 把图画完以后用速查图反向排查下行问题的三个习惯图画完不是终点它的价值在于成为一张速查底图。我现在每处理一个5G下行问题都会先把图调出来按「N3隧道 → SDAP映射 → 空口调度 → UE解封装」逐段过检查点让排查有顺序N3隧道段检查抓包里GTP-U头的TEID是否和配置一致QFI携带是否符合预期。基站段检查QoS Flow到DRB的映射是否被RRC重配置调整过PDCP的COUNT值是否连续乱序率高不高。空口段检查DCI里的HARQ进程号和NDI确认当前是初传还是重传重传占比是否异常。UE段检查RLC是否频繁出现分段重组丢段PDCP是否有解密失败告警。第二个习惯是「纸面仿真」。拿一个实际抓到的IP包沿着画好的图从头走到尾在UPF入口是什么样出隧道是什么样SDAP映射后走哪个DRBMAC复用进哪个TB空口用的什么调制方式UE每一层去掉了哪个头。走完一遍所有标注不一致的地方立刻暴露。我每次画完新图都会做一次这样的仿真比反复读协议文档有效得多。第三个习惯是复盘补图。之前处理过一个下行时延突增的案例当时是个跨平台系统现场按拓扑排查了很久事后复盘才意识到问题就出在QoS Flow的映射表被重配而我们的排查图里根本没画映射关系。那次之后我就养成了一个习惯每处理完一个下行问题就在图上补一条备注写明现象、原因、检查点。时间长了这张图就变成了个人知识库比翻协议文档更顺手。这个习惯希望帮到你。本文还有配套的精品资源点击获取