news 2026/10/12 21:17:02

5G下行数据流程怎么画?一张图讲清UPF到UE的传输链路

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
5G下行数据流程怎么画?一张图讲清UPF到UE的传输链路

简介:一份面向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 泳道
T2UPF 封装 GTP-U,准备转发UPF 泳道上画“装集装箱”
T3gNB 收包,SDAP/PDCP 完成 Flow 到 DRB 映射、加密加头gNB 泳道上画封包盒
T4MAC 调度器参考 CQI 选定 MCS/RB 资源gNB 泳道上画调度器输出
T5同一 slot 内,PDCCH 发送 DCI、PDSCH 发送数据gNB 和 UE 泳道之间的粗箭头
T6UE 解调 PDSCH,CRC 校验,MAC 层反馈 ACK/NACKUE 泳道画回到 gNB 的细箭头
T7若 NACK,gNB 在对应 HARQ 进程上重传,UE 做软合并gNB 与 UE 之间的折线箭头,标注 RV 版本
T8UE 协议栈解包,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 的同事,让他看这张图复述一遍。如果复述不出这条链,说明信息层级还是太多,回去砍。我画到第三版才总结出一个教训:图之所以难看,不是因为信息不够,而是因为分类不清。现在无论给谁讲,我只带两张图,一张主干、一张时间轴,细节都收在讲稿里,听众要哪一层再展开哪一层。

希望你也能把这张图画到“讲一遍就被人记住”的程度,到时候你会回来感谢当年那个愿意把图撕掉重画的自己。希望帮到你。

本文还有配套的精品资源,点击获取

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/12 21:13:44

多层网络关键节点智能识别:从建模到GNN的落地实践

简介:这份文档面向人工智能、大模型与复杂网络分析方向的学习者与研究者,系统梳理多层网络建模与关键节点智能识别技术,帮助读者理解如何从多层网络结构中提取关键信息并应用于社交网络、生物网络、供应链等场景。资源包共1个docx文件&#x…

作者头像 李华
网站建设 2026/10/12 21:13:03

中缀转后缀的本质:运算符优先级与结合性深度解析

1. 这道题不是考“写代码”,而是考你有没有真正理解表达式求值的本质“7-20 表达式转换(25分)”——看到这个标题,很多刚接触数据结构或编译原理的同学第一反应是:“哦,中缀转后缀,用栈嘛&#…

作者头像 李华
网站建设 2026/10/12 21:11:40

中医舌苔项目Python源码解析:Flask与OpenCV特征提取实战

简介:这是一份基于深度学习的舌象分析Web应用完整源码包,面向计算机、电子信息、数学等专业学生及开发者,适用于课程设计、期末大作业或毕业设计参考。项目采用YOLOv5目标检测与Segment Anything模型分割舌象,再通过ResNet50对舌色…

作者头像 李华
网站建设 2026/10/12 21:08:59

企业级AI Agent落地实战:从OpenClaw看智能体如何成为企业基础设施

1. 从“OpenClaw”刷屏说起:一个标题背后的行业信号前几天技术圈里不少人在转一个标题,大意是“OpenClaw干翻了软件业,全球首款企业版Claw来了”。我第一眼看到的时候,反应和大多数人一样:又是一个蹭热度的营销标题。但…

作者头像 李华