5G NR下行数据传输全流程解析：从HTTP到PDSCH的七层封装与CU-DU映射

发布时间：2026/10/24 18:01:49
5G NR下行数据传输全流程解析：从HTTP到PDSCH的七层封装与CU-DU映射

简介：本资源是一份面向5G通信初学者与网络协议学习者的图形化教学材料，聚焦5G NR下行数据传输全流程解析，帮助理解用户面协议栈各层协同机制及实际数据封装过程。内容以清晰图示（含图212–214）串联应用层HTTP GET请求、TCP/UDP/IP头部封装细节、CU-DU分离架构下的PDCP/SDAP/RLC/MAC/PHY分层处理，以及GTP-U隧道、空口传输等关键环节，形象展现从网页下载到无线空口发送的端到端路径。资源为单个PDF文件，大小874KB，结构紧凑、图文并茂，适合作为协议栈学习的可视化补充材料或课堂辅助讲义。目前已有270人学习下载，读者可直接获取完整协议栈分层说明、标准头部字段详解（如TCP序列号/窗口大小、IPv4 DSCP/ECN字段）、典型端口号（HTTP 80）及gNodeB CU-DU功能划分等核心知识点，快速建立5G用户面数据流的系统性认知。

1. 5G NR下行数据传输：为什么一个HTTP请求要穿7层“外套”，却只在空口发1次物理帧？

你点开一个网页，浏览器发出一个HTTP GET请求——这看似简单的一次交互，在5G NR网络里，实际触发的是一场横跨核心网、传输网、接入网、终端的精密接力。它不是“IP包直飞UE”，而是被层层封装、映射、加解密、调度，最终压缩进一个物理层的PDSCH时隙中。更反直觉的是：同一个TCP段，在gNodeB侧可能被拆成多个PDCP PDU，再拼成多个RLC AM PDU，再打散成数十个MAC PDU，最后在物理层被调制为一串OFDM符号流——但整个过程对上层应用完全透明，且端到端时延控制在毫秒级。这背后不是堆砌协议，而是5G NR用“分层解耦+语义映射+隧道抽象”三重机制，把IP世界的无连接、尽力而为，硬生生改造成无线世界的确定性、可保障、可切片的管道。搞懂这个流程，你才能真正看懂QoS Flow和DRB的映射关系为何是5G承载管理的核心命门，也才能理解为什么Wireshark抓到的“一个TCP包”，在空口信令里根本找不到对应实体——它早已被SDAP/PDCP/RLC/MAC四层协议揉碎、重组、加密、编号、重传、调度，最终以比特流形态抵达UE天线。这不是玄学，是3GPP TS 38.300、38.321、38.415等十几份规范共同编织的确定性工程。

2. 协议栈分层解耦：CU-DU架构如何用“逻辑切片”打破传统基站的硬件绑定？

5G NR的下行数据路径，首先是一场“空间上的分工革命”。图212明确展示：用户面协议栈不再由单体基站（monolithic gNodeB）全权处理，而是按功能粒度劈开——CU（Centralised Unit）负责高层协议（SDAP、PDCP），DU（Distributed Unit）专注低层（RLC、MAC、PHY）。这种split不是为了炫技，而是为了解决两个根本矛盾：时延刚性约束 vs. 处理资源弹性调度，以及核心网策略集中管控 vs. 空口实时响应。

2.1 CU-DU split的协议边界：为什么SDAP必须在CU，而RLC必须在DU？

关键在于“决策延迟容忍度”。

  • SDAP层负责QoS Flow到DRB的映射（即把UPF送来的GTP-U包，绑定到某条无线承载上）。这个映射规则由SMF下发，属于会话级策略，变化频率低（秒级），且需与核心网强同步。放在CU，便于集中管理、批量更新、跨DU复用。
  • RLC层则承担ARQ重传、分段/重组、状态报告等实时性极强的任务。一次HARQ失败后，RLC需在毫秒内决定是否重传、重传多大尺寸、是否等待新数据填充——这些决策必须紧贴物理层反馈（如PHICH/NACK、CSI测量），延迟超过1ms就可能导致重传窗口错失。因此RLC必须下沉至DU，与MAC/PHY共址，共享同一块FPGA或ASIC的时钟域。

提示：CU-DU split位置并非固定。3GPP定义了Option 2（PDCP/SDAP在CU，RLC/MAC/PHY在DU）是当前主流，但Option 7（RLC也在CU）仅用于超低频段（如700MHz）广覆盖场景，此时空口时延大，允许将RLC上移以节省DU硬件成本。

2.2 GTP-U隧道：为什么需要两套独立隧道（NG-U和F1）？

从UPF到gNodeB的路径，本质是“核心网域”到“接入网域”的跨越。这两个域的安全边界、管理主体、QoS保障机制完全不同，因此必须用隧道隔离：

隧道类型终端点承载内容关键字段设计动机
NG-U隧道UPF ↔ CUPDU Session级数据TEID（标识PDU Session）、PDU Session Container（含QFI、PDU Type）将核心网的会话语义（PDU Session）透传给接入网，使CU能识别业务类型（如视频vs.信令）
F1-U隧道CU ↔ DUDRB级数据TEID（标识DRB）、NR RAN Container（含DRB ID、SN状态）将CU的调度指令（该走哪条DRB、用什么RLC模式）精准下达给DU，实现空口资源的细粒度分配

注意：TEID在NG-U和F1-U中完全独立，互不复用。UPF给CU的TEID只在NG-U接口有效；CU给DU的TEID只在F1-U接口有效。这是避免跨域混淆的关键设计——就像快递公司（UPF）用运单号（NG-U TEID）把货发到区域分拣中心（CU），分拣中心再用内部工单号（F1-U TEID）派单给末端网点（DU），两个号码体系绝不混用。

2.3 SDAP层：QoS Flow到DRB的“翻译官”，为何能绕过传统QCI僵化模型？

4G LTE用QCI（QoS Class Identifier）硬编码9种优先级，无法支撑5G URLLC/eMBB/mMTC三类业务并存。5G NR引入QoS Flow概念，每个Flow由5元组（源IP、目的IP、源端口、目的端口、协议）+ QFI（QoS Flow Identifier）唯一标识。SDAP层的核心职责，就是把UPF送来的GTP-U包头里的QFI，映射到一条已建立的DRB上。

这个映射不是静态查表，而是动态协商：

  • 初始接入时，UE通过NAS消息向AMF上报其支持的QoS规则；
  • SMF根据签约数据、应用需求生成SDF（Service Data Flow）模板，并下发给UPF；
  • UPF用SDF模板匹配IP包，打上QFI标签；
  • CU的SDAP层收到GTP-U包后，查询本地DRB配置表（由RRC重配消息建立），将QFI→DRB ID绑定。

关键细节：SDAP header是否添加，由RRC参数sdap-HeaderDL控制。若设为present，则每个PDCP PDU都带SDAP头（含QFI），供UE做Reflective QoS；若设为notPresent，则仅靠CU侧隐式映射，UE无法反向推导上行QoS Flow。

3. 封装与映射：从TCP/IP包到PDSCH物理帧，数据如何被“揉碎又捏合”？

当HTTP响应的TCP段抵达UPF，它才真正进入5G NR的“变形记”起点。这一过程不是简单加头，而是逐层注入语义、剥离无关信息、适配无线特性。我们以一个典型场景为例：服务器返回1500字节TCP payload（含HTTP头部+HTML内容），分析其在各层的“变身”。

3.1 IP层到GTP-U：双IP头的“套娃”逻辑与DSCP继承

UPF收到IP包后，先执行SDF匹配，确定其归属PDU Session X、QoS Flow Y（QFI=9）。随后封装GTP-U头：

[Outer IP Header] // 用于传输网路由，DSCP=EF（ Expedited Forwarding, 值46） [UDP Header] // Source Port=2152, Dest Port=2152 [GTP-U Header] // Version=1, Message Type=255 (GPDU), TEID=0x1A2B3C4D [PDU Session Container] // QFI=9, PDU Type=0 (DL) [Inner IP Header] // 原始IP头，DSCP保留原值（如AF41） [TCP Header] [HTTP Payload]

这里出现内外双IP头：外层IP头（Outer IP）由UPF生成，用于骨干网路由，其DSCP由UPF策略设定（如eMBB业务设为EF）；内层IP头（Inner IP）是原始包，DSCP值被完整保留，供UE侧QoS处理。这种分层标记，使核心网能控制传输网QoS，而终端仍能感知业务原始优先级。

3.2 CU侧PDCP处理：加密、完整性保护与序列号压缩

CU的PDCP层接收GTP-U解封装后的IP包（即Inner IP+TCP+Payload），执行三项关键操作：

  1. 完整性保护：用KgNBint密钥计算MAC-I（Message Authentication Code - Integrity），附加在PDCP header后；
  2. 加密：用KgNBenc密钥对IP包payload（不含PDCP header）进行流加密；
  3. 头压缩：对TCP/IP头执行ROHC（Robust Header Compression），但5G NR默认禁用ROHC for data（仅语音启用），因TCP选项字段（如SACK、Timestamp）在无线丢包下易导致解压失败。

PDCP header结构（简版）：

| D/C | R | R | R | R | R | R | R | // Data/Control flag | SN (12 bits) | // PDCP Sequence Number, modulo 4096 | MAC-I (16 bits, if integrity enabled) |

注意：SN是12位，意味着每4096个PDCP PDU后SN回绕。这要求RLC层必须严格按序递交，否则SN错乱将导致解密失败——这也是PDCP重排序必须在RLC之上完成的根本原因。

3.3 DU侧RLC/MAC处理：从字节流到物理资源的“颗粒度转换”

DU收到PDCP PDU后，进入RLC AM（Acknowledged Mode）处理：

  • 若PDCP PDU > RLC AM PDU最大尺寸（由maxRLCDataSize参数配置，通常1000~2000字节），则RLC将其分段（Segmentation），每段加RLC header；
  • 每个RLC PDU再经MAC层添加MAC header（含LCID、Length字段），并可能插入MAC CE（Control Element）如BSR（Buffer Status Report）；
  • 最终MAC PDU被送入物理层，按TTI（1ms子帧）和PRB（Physical Resource Block）网格进行映射。

关键转换点：RLC PDU是字节单位，MAC PDU是TB（Transport Block）单位，而物理层调度以PRB为最小资源单元。例如，一个1500字节RLC PDU，经MAC头添加（约4字节）后，成为1504字节MAC PDU；物理层根据CQI（Channel Quality Indicator）选择MCS（Modulation and Coding Scheme），计算出该TB需占用多少PRB。若选QPSK+1/3码率，1个PRB（12子载波×7符号=84RE）可传84×2×1/3≈56bit≈7字节，则1504字节需约215个PRB——这正是调度器（Scheduling Entity）在毫秒级内完成的数学运算。

4. 避坑：5G NR下行传输的5个典型翻车现场与根因定位

实际部署与调试中，下行数据不通、时延突增、吞吐量骤降等问题，往往源于对协议栈某一层的误解或配置错位。以下是某实验室在搭建CU-DU分离测试床时踩过的5个真实坑，附带现象、根因与验证方法：

4.1 现象：UE能附着成功，但所有HTTP请求均超时，Wireshark在UPF侧可见正常TCP SYN，但CU侧PDCP日志无任何PDU收发记录

原因：NG-U隧道未建立。UPF与CU之间的GTP-U隧道依赖NG Setup Request/Response流程，若CU未向AMF注册或AMF未向UPF下发UPF信息，隧道TEID无法协商。此时UPF虽收到IP包，但因无有效TEID，直接丢弃。
解决：检查CU的ngSetupRequest信令是否成功；在UPF侧执行show gtpu tunnel确认TEID表为空；抓取CU与AMF间的NGAP信令，确认UPF Configuration Update是否送达。

4.2 现象：UE能下载小文件（<1KB），但大文件（>10MB）下载到80%时卡死，TCP重传次数激增

原因：RLC层AM模式下的接收窗口（RX Window）溢出。RLC AM要求按序递交PDCP PDU，若某PDCP PDU因空口误码丢失，后续PDU在RLC接收缓存中堆积，超过rlcRxWindowSize（默认1000字节），新PDU被丢弃，导致TCP窗口停滞。
解决：增大CU侧RLC配置参数rlcRxWindowSize（如设为2000）；或临时切换为UM（Unacknowledged Mode）验证（仅测试用）；用tcpdump在UE侧确认是否收到乱序包。

4.3 现象：下行吞吐量仅为理论值的30%，调度器显示PRB利用率不足50%，但UE上报CQI很高

原因：MAC层HARQ进程数配置不足。5G NR支持最多16个并行HARQ进程，若CU配置numHarqProcesses=4，则同一TTI最多处理4个TB。当UE高速移动导致CQI快速变化时，旧HARQ进程未及时释放，新TB无法调度，造成资源浪费。
解决：在CU配置中将numHarqProcesses设为12或16；用get harq-status命令观察各进程busy/idle状态分布。

4.4 现象：同一PDU Session内，视频流（QFI=8）和信令（QFI=1）的时延差异巨大，视频卡顿严重

原因：QoS Flow到DRB的映射错误。检查CU的SDAP配置，发现QFI=8被映射到DRB2（RLC UM模式），而QFI=1映射到DRB1（RLC AM模式）。UM模式无重传，但视频包丢失即卡顿；AM模式有重传，保障信令可靠。正确做法是：URLLC类QFI（如1）用AM+低延迟DRB，eMBB类（如8）用UM+高吞吐DRB。
解决：修改RRC重配消息中的drb-ToAddModList，为不同QFI指定不同rlc-Config；用show sdap-mapping验证映射表。

4.5 现象：UE在RRC Inactive态收到下行数据，但未触发寻呼，数据丢失

原因：UPF未在GTP-U头中设置Paging Policy Indicator（PPI）。图216中PPP字段为0，表示PPI不存在，gNodeB无法得知该下行包需触发寻呼。RRC Inactive态下，UE不监听PDCP，必须由gNodeB发寻呼唤醒。
解决：在UPF的SDF模板中，为该业务流启用pagingPolicyIndicator；检查GTP-U包解析，确认PDU Session Container中PPP=1且PPI字段存在（值通常为1，表示高优先级寻呼）。

5. 安全与可靠性：PDCP加密与完整性保护的密钥演进机制

PDCP层的加密（ciphering）与完整性保护（integrity protection）是5G NR用户面安全的基石。但很多人忽略一个关键事实：这些密钥并非一成不变，而是随RRC连接状态、切换事件、密钥更新周期动态演进的。理解其生命周期，是排查“偶发解密失败”“间歇性连接中断”的核心。

5.1 密钥层级与派生树：从KgNB到Kupenc的完整链条

5G NR采用分层密钥架构，所有密钥均源自根密钥KgNB（gNodeB Key），由AMF通过SecurityModeCommand下发。KgNB本身由Kseaf（SEAF Key）派生，而Kseaf又来自Kausf（Authentication Server Function Key）。整个派生链如下：

KgNB ├── KgNBint → 用于PDCP完整性保护（SRBs & DRBs） └── KgNBenc → 用于PDCP加密（仅DRBs，SRBs不加密） └── Kupenc → 用于UP层加密（如TLS，非PDCP范畴）

注意：SRB（Signaling Radio Bearer）只做完整性保护，不做加密；DRB（Data Radio Bearer）则两者皆做。这是为平衡信令可靠性（防篡改）与数据机密性（防窃听）的设计取舍。

5.2 密钥更新触发条件：何时会“突然换锁”？

密钥更新（Key Refresh）不是定时轮转，而是由以下事件显式触发：

  • RRC重配（Reconfiguration）：当CU下发securityConfig包含keyChangeIndicator=true时，UE立即派生新KgNB；
  • 切换（Handover）：目标gNodeB在RRCReconfiguration中携带新KgNB，UE切换完成后启用；
  • 密钥老化（Key Lifetime）：3GPP建议KgNB有效期≤24小时，但实际由运营商策略控制，可通过keyUpdateTimer参数配置。

关键细节：密钥更新期间，UE会同时维护新旧两套密钥。PDCP层用SN（Sequence Number）判断该包属于哪个密钥周期——SN小于keyChangeSN用旧密钥，大于等于则用新密钥。这保证了切换/重配过程中的零丢包。

5.3 加密算法选择：NEA0/NEA1/NEA2/NEA3的实战取舍

PDCP加密算法（NEA: Network Encryption Algorithm）有四种：

  • NEA0：空加密（no encryption），仅完整性保护。仅限测试环境，生产网禁用；
  • NEA1：Snow 3G，轻量级流密码，适合低端UE；
  • NEA2：AES-CTR，高性能，主流选择；
  • NEA3：ZUC，中国国密算法，国内运营商强制要求。

选择依据不仅是性能，更是生态兼容性：若UE仅支持NEA1，而CU配置NEA2，则SecurityModeCommand会失败，RRC连接无法建立。因此，CU必须在securityCapability中声明支持的算法列表，并与UE能力协商。

6. 设计取舍的底层思考：为什么5G NR坚持“隧道+映射”而非“IP直通”？

写到这里，你或许会问：既然最终都是传IP包，为何不简化架构，让UPF直接把IP包发给DU，由DU完成全部协议栈？答案藏在三个不可妥协的工程约束里：可扩展性、可维护性、可保障性。

6.1 可扩展性：CU-DU分离如何支撑百万级小区管理？

假设一个大型运营商有10万个gNodeB，每个gNodeB平均管理10个DU（覆盖不同频段/场景）。若采用单体基站，每个基站需独立运行全套协议栈，UPF需维护100万条GTP-U隧道（10万×10）。而CU-DU架构下，CU可池化部署（如1个CU管理100个DU），UPF只需与CU建立1000条NG-U隧道（10万÷100）。隧道数量降低3个数量级，UPF的TEID表、会话管理、QoS策略下发压力断崖式下降。这就是“逻辑集中、物理分布”的规模效益。

6.2 可维护性：协议栈分层如何降低故障定位复杂度？

当用户投诉“视频卡顿”，传统单体基站需在1个设备上排查PDCP/RLC/MAC/PHY全栈日志，线索交织难分离。CU-DU分离后，问题可快速归因：

  • 若CU侧PDCP日志显示PDU正常发出，但DU侧RLC无接收记录 → 问题在F1-U接口（传输网丢包/MTU不匹配）；
  • 若DU侧RLC有PDU但MAC无调度 → 问题在调度器或CQI上报异常；
  • 若MAC有调度但UE无解调 → 问题在PHY层（干扰/同步失败）。

每一层都有清晰的输入/输出契约（如PDCP交付给RLC的是字节流，RLC交付给MAC的是TB），故障域被天然切割。

6.3 可保障性：QoS Flow与DRB的两级映射如何兑现SLA？

4G的QCI是扁平化模型，一个QCI对应一套固定参数（ARP、GBR、MBR）。5G NR的QoS Flow+DRB两级映射，则实现了策略与执行的解耦：

  • QoS Flow由核心网（SMF）定义，承载业务语义（如“4K视频流”）；
  • DRB由接入网（CU）定义，承载无线能力（如“20MHz带宽+4x4 MIMO”）。

当网络拥塞时，SMF可动态调整QoS Flow的5QI（5G QoS Identifier），降低其优先级；CU则根据新5QI，将该Flow重新映射到另一条DRB（如从eMBB DRB切到mMTC DRB），无需重建RRC连接。这种“策略热更新”能力，是5G切片商业化的技术底座。

从那以后我每次分析5G下行问题，都强制走一遍“UPF→CU→DU→UE”的隧道路径，逐层比对TEID、QFI、DRB ID、SN的连续性，而不是盯着Wireshark里一个TCP包猜来猜去。因为真正的答案，永远藏在协议栈的缝隙里，而不是应用层的表象中。希望帮到你。

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