简介:一份面向5G NR通信学习者的下行数据传输流程图解PDF,以图形化方式拆解独立基站中CU-DU分离架构下的用户平面协议栈(SDAP/PDCP、RLC/MAC/PHY)。内容围绕“应用层HTTP请求→TCP/IP头部封装→物理层无线传输”的完整链路,逐层解读TCP的源/目的端口、序列号、确认号、数据偏移、窗口大小、校验和,以及IP的源/目的地址、版本、头部长度、总长度、DSCP、ECN、协议号等关键字段,并通过分步流程图对比每一层的封装变化,将抽象的协议分层与数据流形象化,帮助读者突破下行数据如何封装、寻址与传输的理解难点。资源为单个PDF文件,压缩包仅874KB,共1个文件,轻量易读;已有270人学习/下载,适合5G网络工程师、通信专业学生及协议初学者作为快速入门与复习资料。
1. 一张图讲清 5G 下行数据流程,怎么画才不算白画
我见过不少讲“5G 下行数据传输流程”的图:UE、gNB、UPF 三个方块一摆,几条箭头连起来,旁边标上 N3、Uu、F1,就算交差。可真拿到例会或客户面前讲,听众要么问“这个包到了基站之后到底被做了什么”,要么问“这条线是实线那条是虚线,区别在哪”。问题不在信息不全,而在把信令流程和用户面数据流混在一张图上画了。
5G 下行数据传输流程要想让看图的人一次就记住,主线应该是一条用户面故事线:一个 IP 包从核心网的 UPF 出来,通过隧道进到基站,在无线协议栈里被拆、被编、被调度,最后由天线发到手机屏幕上。图形化描述的价值也在这里——不是画一张完整拓扑,而是画一张能被复述的“流水线地图”。这篇文章适合要给客户或领导讲清楚 5G 数据怎么走的网优工程师,也适合刚摸 5G 网络架构、想从整体上理解空口流程的研发和测试。
2. 先把数据面大图画对:从 UPF 到手机,哪段画线、哪段画框
2.1 用“快递分拨”当主线:UE、gNB、UPF 三个角色先分清
画任何一张“5G 下行数据传输流程”图,我习惯先从三个角色入手:UPF、gNB、UE。对应到快递场景里,UPF 是发货分拨中心,gNB 是本地配送站,UE 是收件人。视频服务器出来的 IP 包先到 UPF,UPF 把包塞进 GTP-U 隧道,交给 gNB;gNB 拆开隧道,把包按无线承载的规则重新封装,经空口发给 UE;UE 再做一次解封装,把 IP 包交回应用层。
这一步的关键是先把“谁负责什么”定死,后面画线才有依据。比如 UPF 只负责隧道转发,它不关心空口质量;gNB 负责调度和重传,它不关心视频服务器里存了什么内容;UE 负责把无线承载还原成 IP 包。三类角色画成三个方框,按“服务器 → UPF → gNB → UE”从左到右排开,方框大小一致,不要忽大忽小,否则看图的人下意识会觉得某个节点更重要。
确定角色后,再区分两条通路。信令面(RRC、NGAP 这类)画成细虚线,放在图的上方,单独成层,不参与“数据搬运”;用户面数据画成粗实线,放在图的中下部,是整张图的主干。常见做法是先画用户面,再叠控制面,最后标参数。如果一上来就画信令流程,数据流反而会被埋掉。
2.2 接口别画成“一条直线”:N3、F1、Uu 的图形约定
数据面大图里最容易误导人的,是接口的画法。很多图把 UPF 到 gNB 之间的 N3 画成一根直线,因为传输网被省略了,看上去像是物理光纤直连。但 N3 是逻辑隧道,承载在 IP 传输网上,图里必须体现“隧道”这个语义。
我一般会这样画:在 N3 线上画一个“集装箱”图标,里面标注三行小字——GTP-U、UDP/2152、TEID。含义是:UPF 把用户 IP 包作为 GTP-U 的 payload 装进去,外层套 UDP 头,再套 IP 头,经由承载网送到 gNB。TEID 是隧道端点标识,gNB 靠它区分这个包属于哪个 PDU 会话。图下加一句注释:“此处为 IP 传输网,画的是逻辑隧道,不是物理直连。”这样既保住网络语义,又不至于把传输网细节带进来。
如果图需要体现 CU/DU 分离,F1 接口也要画出来,但按 5G 架构,F1-U 同样跑在 GTP-U 隧道上,图形语言和 N3 保持一致,只是把“集装箱”标注换成“F1-U”。Uu 接口则完全不同,它没有隧道概念,画成一根从 gNB 天线指向 UE 的粗实线,线上标注“无线承载”。
[视频服务器] --IP--> [UPF] --GTP-U(N3)--> [gNB] --- 天线 ---> [UE] 集装箱里装:GTP-U + UDP/2152 + TEID这张主干图只要十秒钟就能讲完:服务器把 IP 包交给 UPF,UPF 装进集装箱走 N3,gNB 把集装箱拆开,把包搬到空口上,UE 收货。先有这张主干,再往下拆协议栈才有落脚点。注意 N3 这侧不要画成“直达”,它经过的是承载网;如果讲稿里需要提传输网,可以在 UPF 与 gNB 之间的空白处画一个浅色椭圆,标注“承载网”,不要给它加方框,它只是背景。
2.3 分层图形约定:一张图只画两层,超过就拆
5G 下行数据流程涉及的层很多,场景上有 QoS Flow、DRB,转发上有 GTP-U、TEID,空口上有逻辑信道、传输块,物理上又有 RB、PDSCH。全画到一张图里,信息密度立刻爆炸。行业里比较可靠的做法是给每种对象定一套图形元素,并且限定“一张图最多画两层”。
我用的约定如下:
| 层级 | 画的对象 | 图形元素 | 一句话说明 |
|---|---|---|---|
| 场景层 | QoS Flow(QFI)、DRB | 泳道/通道 | 标识业务是谁、归属哪个承载 |
| 隧道层 | GTP-U、TEID、IP | 集装箱/隧道线 | 标识转发路径和会话归属 |
| 接入层 | 逻辑信道(LCID)、传输块(TB) | 管线/闸门 | 标识复用与调度结果 |
| 物理层 | RB、PDSCH、MCS | 时频格 | 标识实际占用的无线资源 |
画图顺序也按这个表走:先画场景层和隧道层,这是数据面的主干;需要细化空口时,再把接入层和物理层单独拉出来画一张。控制面永远是“辅助层”,用灰虚线放在图顶,不要让它混进主干。这样做的原因很简单:一张图让读者在五秒内找到主干,才有继续看细节的意愿。
3. 空口协议栈画成“流水线”:SDAP/PDCP/RLC/MAC/PHY 的图形表达
3.1 一套图形语言:队列、封包盒、确认箭头分别画哪一层
端到端大图画完后,下一步是拆开 gNB 和 UE 之间的“空口黑匣子”——无线协议栈。下行方向从 SDAP 到 PHY,五层各干一件事。图形化描述的目标是让人一眼看出“这个包在每一层发生了什么变化”。
我常用的图形语言是四种元素:
- 队列:画成横向堆叠的小方块,代表 RLC 或 MAC 的缓冲区,等待调度的数据排在这里。
- 封包盒:画成一个小方框套在数据块外,代表协议层加头。PDCP 加头、加密、头压缩都在这类图形里表达。
- 确认箭头:画成从 UE 指回 gNB 的带回钩箭头,代表 RLC AM 的状态报告或 MAC 的 HARQ 反馈。
- 漏斗/闸门:画成窄口形状,代表 MAC 的逻辑信道优先级调度,把多个逻辑信道的数据复用到同一个传输块。
把五层纵向排列,每层旁边放一个图标:SDAP 画一个分拣闸口(把 QoS Flow 归到 DRB),PDCP 画一个封包盒(加头、加密、压缩),RLC 画一把剪刀(分段/级联),MAC 画一个闸门(复用和调度),PHY 画一组信号格(调制映射)。图标 + 一句话注释,比画几十个协议头结构实用得多。
画流水线时要注意“数据守恒”:PDCP 一个包进来,RLC 把它切成两段,两段总字节数必须等于切之前。有人画到分段时把包画小一号,现场就被懂行的人挑出来,追问“剩下的字节去哪了”。字节可以变化,但总量不能无中生有,这是图形化描述里最容易忽略的细节。
3.2 RLC 模式不能一张图画到底:TM/UM/AM 的线型怎么定
RLC 有三种传输模式,图形化时最怕用同一种线型画到底。TM(透传模式)不加工数据,用于 SRB0、广播这类场景,画成一条直通管道,不加任何箭头和分段标记;UM(非确认模式)不做重传,用于 VoNR 语音这类容忍少量丢失但对时延敏感的业务,画成一条单向传送带;AM(确认模式)带重传和状态报告,用于普通数据业务,画成一条带回环的传送带,回环里标注“状态报告”。
线型的约定可以这样定:TM 用细虚线,UM 用单箭头实线,AM 用双箭头实线。图例放在协议栈图的右下角,不要单独开一页解释。这样画的好处是,整张图即使不读文字,只看线型就能判断“这个承载丢包以后有没有人管”。
涉及多承载时,每根 DRB 线按自己的模式画,不要统一复制。默认数据业务画 AM,VoNR 画 UM,寻呼和广播画 TM。RLC 模式不是可选项,它由 QoS 参数里的传输模式决定,画错等于把业务可靠性画错了。
3.3 QoS Flow 与 DRB:别画成 1:1
5G 里最容易画错的,是把 QoS Flow 和 DRB 一一对应。LTE 时代一个 EPS 承载就是一条独立通道,但 5G 的 Qos Flow 只是数据包上的一个标记,多个 Flow 可以映射到同一个 DRB,由 SDAP 层做归属。
图形化表达上,我会在 SDAP 这一层画一个分拣闸口,左边进来多根 Flow 泳道,每根线上标 QFI(QoS Flow Identifier);闸口右侧输出到一根或两根 DRB 通道。常见场景是:一个视频业务 Flow(QFI=1)和一个 IMS 语音 Flow(QFI=2)同在一个 PDU 会话里,经过 SDAP 映射后,两者进入同一个 DRB,或者按运营商配置分成两个 DRB。图上用“多进一出”或“多进两出”来画,就能避免 1:1 的误导。
如果整张图的重点是空口调度而不是 QoS 架构,DRB 画一根就够了,然后在它旁边注一句“内嵌多个 QoS Flow”,不要为了表达完整画出四五根线,反而把调度主线冲淡。记住:5G 的差异化服务能力下放到 Flow 级别,而不是承载级别。
3.4 参数标在哪:MCS、CQI、TB size 的图形位置
流水线图不能只有盒子,还要有让内行看得懂的参数。CQI 是 UE 上报的信道质量指示,画在 UE 侧 PHY 层往 gNB 方向的反馈箭头上,标注形式是“CQI=12/15”,不需要解释数值含义;MCS 是 gNB 根据 CQI 决策出来的调制编码方案,画在 MAC 调度器的输出位置;TB size 由 MCS、调度 RB 数和层数共同决定,标注在 PDSCH 资源格上,用依赖箭头把三者连起来。
参数标注遵循一条原则:标“决策点”和“反馈点”,不标中间推导过程。CQI 是反馈,MCS 是决策,TBS 是结果,三者之间的换算查表即可,图里不需要展开公式。有人把 CQI 和 MCS 的 5G 索引表整个贴到图边,只会让读者失去焦点。一页图上参数超过五个,就按我的习惯拆分:主干图只标接口和承载,流水线图只标 CQI/MCS/TBS,调度时序图再标 HARQ 进程和 RV 版本。
还有一个容易被忽略的细节:PDCP 层的头压缩。ROHC 在图上画成两个重叠的小云块,旁边注释“IP 头压缩,可选”。如果不画,行家会问为什么视频业务少了几十个字节的开销没体现;画了,新手可能会误以为每个包都压缩,所以我习惯在压缩云块上加一个“按 QoS 策略启用”的括号注释,让两种情况都站得住。
4. 一次下行数据包的旅程:把时间轴和协议栈叠成一张图
4.1 画图前先把前提摆好:RRC 连接已建立、DRB 已就绪
讲解下行数据流程时,很多人直接从“UPF 收到包”开始,但真正能收到包的前提是 UE 处于 RRC_CONNECTED 状态,PDU 会话和 DRB 已经建立。如果 UE 在 RRC_INACTIVE,网络侧还得先触发状态恢复,拉起来的信令流程会冲淡数据面主线。
我的建议是在时间轴图的最左侧画一个淡灰色竖条,标注“前提:RRC_CONNECTED,DRB 已建立”,把连接建立过程排除在叙事线之外。这样既严谨,又不抢戏。如果听众问“DRB 哪来的”,可以在讲稿里单独补一句“由 RRC 重配置建立,细节不在这张图展开”。这在 SA 组网下尤其重要——SA 没有 LTE 承载兜底,一切业务都在连接态数据调度之上,先把前提画稳,后续的时序才立得住。
4.2 从“视频请求”到“屏幕出画面”:把九个时刻拆开
一张好的时序图,用横轴代表时间、纵轴从上到下排 UPF、gNB、UE 三个泳道。每个动作只落在对应泳道的某个时间点上,不跨线。以下行视频切片请求为例,我把它拆成九个时刻:
| 时刻 | 动作 | 图上怎么画 |
|---|---|---|
| T1 | 视频服务器向 UPF 发送 IP 数据包 | 小方块从左侧进入 UPF 泳道 |
| T2 | UPF 封装 GTP-U,准备转发 | UPF 泳道上画“装集装箱” |
| T3 | gNB 收包,SDAP/PDCP 完成 Flow 到 DRB 映射、加密加头 | gNB 泳道上画封包盒 |
| T4 | MAC 调度器参考 CQI 选定 MCS/RB 资源 | gNB 泳道上画调度器输出 |
| T5 | 同一 slot 内,PDCCH 发送 DCI、PDSCH 发送数据 | gNB 和 UE 泳道之间的粗箭头 |
| T6 | UE 解调 PDSCH,CRC 校验,MAC 层反馈 ACK/NACK | UE 泳道画回到 gNB 的细箭头 |
| T7 | 若 NACK,gNB 在对应 HARQ 进程上重传,UE 做软合并 | gNB 与 UE 之间的折线箭头,标注 RV 版本 |
| T8 | UE 协议栈解包,PDCP 重排、解密,IP 包上抛应用 | UE 泳道向右伸出的方块 |
| T9 | 应用层渲染,屏幕出画面 | 图的最右侧画一个手机屏幕示意 |
图上每个动作都横向对齐到时间刻度,不要重叠,也不要留大段空白。九步里 T5 是核心:DCI 和数据不是“先后两天”的关系,而是同一个传输时间间隔内的两个部分——PDCCH 在符号上略早,PDSCH 随后,但调度决策发生在更早时刻。画图时把“决策时刻”和“传输时刻”分开标,能避免现场被 DCI 顺序问住。
4.3 HARQ 重传的图像语言:增量冗余与软合并
HARQ 是 5G 下行流程里最难用静态图表达的概念,因为它既发生在 MAC 层,又跨了两次传输。可以这样比喻:第一次发来的是整张图的四分之一碎片,接收端拼不出来,第二次发来的是同一张图的另一个角度碎片,接收端把两次碎片叠在一起,拼出的内容比任何单独一次都完整——这就是软合并增益。
画法上:初始传输用粗实线箭头,从 gNB 指向 UE,TB 块标“RV0”;NACK 反馈用灰色细箭头从 UE 回到 gNB,不标数据只标“NACK”;重传用虚线箭头,传输块画成半透明、与初始块有 50% 重叠的图形,表示软合并。在 HARQ 箭头旁边标“进程 P3”“RV2”,能直接展示重传版本号。NDI(新数据指示符)在 DCI 里,如果 DCI 中 NDI 翻转,说明是全新数据;NDI 没变,说明是重传。图里在 DCI 旁写一行“NDI 翻转”,就能说明为什么 UE 知道自己收到的是新包而不是旧包。
特别注意:HARQ 只发生在 gNB 和 UE 之间,N3 隧道、UPF 都不参与 HARQ 反馈。有人为体现“完整”,画出 UPF 到 UE 的大回环标 HARQ,这等于把 MAC 层重传画成了传输层重传,方向就错了。UE 反馈 ACK/NACK 走的是 PUCCH,不是原路返回,这也要在图上用“反馈信道”和“下行信道”两条路径分开画。
4.4 参数背后的“玄学”提醒:CQI、MCS、HARQ 进程别画成理想值
时序图一旦带参数,就会暴露讲稿之外的细节问题。CQI 不是每个 slot 都上报,它有周期上报和事件触发上报之分,如果图上 T4 到 T5 之间画成“每次调度前都有新 CQI”,会被懂调度的人挑战“配置的 CQI 周期是多少”。我的做法是把 CQI 反馈箭头标成“周期上报,周期 n”,不做具体数值约定。
HARQ 进程数在 5G 下行是 16 个,图上不能画一个进程走到底。调度器按进程号分配新传和重传,至少图里要出现“P0、P3、P7”这类编号,让看图的人知道这是多进程并行。MCS 回退也是常见细节:重传之后 gNB 往往把 MCS 降档,以增加鲁棒性,图里可以在重传箭头上标注“MCS 下调一档”,这也解释了为什么实际吞吐量不会随重传次数线性增加。
MAC 调度器本身是不在标准里规定的黑匣子,任何厂商实现的细节都不同。图形化描述时,T4 的调度器画成一个“决策方框”,输入 CQI 和队列状态,输出 MCS/RB,不要标注具体的调度算法或权重,因为那部分信息无法从 5G 标准里推出来。知道边界在哪,图才不会因为过度承诺被问倒。
5. 避坑:画 5G 下行数据流程图最容易翻车的 5 个点
5.1 控制面和用户面画成一根线
现象:一张图里 RRC 建立、NGAP 信令和数据包共用同一批箭头,讲的人绕圈子,听的人分不清哪些流程是“修路”,哪些是“跑车”。
原因:5G 流程天然同时存在 NAS 信令与用户面数据,画图时没有做分层设计。控制面负责建立连接和配置承载,用户面负责搬运业务数据,两者生命周期不同,画在一起必然冲突。
解决:先画用户面主干,用粗实线;控制面整体上移,用灰色细虚线构成独立层,图例里写清楚“虚线仅表示控制面,不参与数据搬运”。如果必须在一张图里体现 RRC 重配置触发 DRB 建立,把它画成“一辆工程车在修车道”,修车道的故事线和跑车的运输线分开讲,不交替。
5.2 N3 接口被画成物理直连
现象:UPF 和 gNB 之间一条直线,没有传输网、没有隧道语义,看起来像是光纤把两个网元直连了。
原因:把 N3 简化过头,GTP-U 隧道被当成普通链路处理。N3 本质是承载在 IP 传输网上的逻辑隧道,数据包在外层还有 UDP 和 IP 头。
解决:在 N3 线上画“集装箱”图标,标注 GTP-U、UDP/2152、TEID,并加注释“逻辑隧道,非物理直连”。这条线在抓包时看到的是带 GTP-U 头的报文,如果图里不体现封装,读者拿真实报文去对比时会觉得图是错的。
5.3 HARQ 重传画成端到端往返
现象:从 UPF 到 UE 之间画一条大回环,标注“HARQ”,看起来像核心网参与了重传。
原因:把 L2 重传和传输层重传混为一谈。HARQ 是 MAC 层机制,参与实体只有 gNB 和 UE。
解决:HARQ 箭头只画在 gNB 和 UE 两个泳道之间,并标“MAC 层”。反馈路径走 PUCCH,和下行 PDSCH 路径分开画,不要画成原路返回。UPF 到 gNB 之间的丢包由更高层(比如 TCP)负责,这在图里单独标注“N3 重传不由 HARQ 承担”。
5.4 所有 DRB 都用 AM 画法
现象:协议栈图中每个承载都画成带回环的双箭头,语音业务和数据业务看不出区别。
原因:沿用 LTE 时代“默认承载一定 AM”的经验,忽略了 5G 里不同 QoS Flow 可以选不同 RLC 模式。
解决:按业务类型选线型——语音类画 UM(单箭头传送带),普通数据画 AM(带回环的传送带),广播寻呼类画 TM(直通宽带)。画完以后自查一遍,看到双箭头就追问一句“这个承载允许 RLC 重传吗”,不允许就改线型。
5.5 QoS Flow 和 DRB 画成 1:1
现象:一个 PDU 会话对应三个 Flow,图上画了三根线,全部拉通到 UE,像是三条物理管道各跑各的。
原因:在 5G 图里套用了 EPS 承载一一对应的思想。5G 的 QoS Flow 是 SDAP 层的一个标识,多个 Flow 可以复用到一个 DRB。
解决:在 SDAP 层画一个分拣闸口,左边 Flow 泳道(按 QFI 区分),右边 DRB 通道,用“多进一出”表达映射关系。整图重点是调度时,DRB 只画一根,注明“内嵌多 QFI”,避免主线被细枝末节冲掉。
6. 进阶:把静态图变成能讲 10 分钟的动态叙事
到了这个阶段,图和讲法已经一体。我会在主干图、协议栈图、时序图之外,再做两件小事:一套固定的颜色约定和一条三级讲稿主线。
颜色约定上,用户面主干用深蓝色,控制面信令用灰色虚线,重传数据用橙色半透明块,ACK/NACK 用绿色细箭头。这四种颜色固定下来以后,换图不换色,听众建立条件反射,看到橙色就知道是重传,看到灰虚线就知道不参与数据搬运。动画顺序也有讲究:先让“管道路由图”出现,讲十秒钟完整体验;再叠“协议栈流水线”,讲每一层做了什么;最后在时间轴上放“数据包旅程”,用 PPT 的擦除动画让数据块从 UPF 一路移动到手机屏幕。三步走完,一个完全没接触过 5G 的听众也能说出五个关键词:UPF 封装、gNB 调度、空口发送、HARQ 反馈、UE 解包。
验证图是否合格的唯一方法,是找一位没做过 5G 的同事,让他看这张图复述一遍。如果复述不出这条链,说明信息层级还是太多,回去砍。我画到第三版才总结出一个教训:图之所以难看,不是因为信息不够,而是因为分类不清。现在无论给谁讲,我只带两张图,一张主干、一张时间轴,细节都收在讲稿里,听众要哪一层再展开哪一层。
希望你也能把这张图画到“讲一遍就被人记住”的程度,到时候你会回来感谢当年那个愿意把图撕掉重画的自己。希望帮到你。
本文还有配套的精品资源,点击获取