5G协议栈全景：从比特到应用的数据封装之旅

你有没有想过，手机里的一条微信消息，是怎么变成电磁波飞出去的？

当你在微信里点下"发送"，一段文字从你手机的CPU出发，经过七八层协议的"包装车间"，最终变成空气中以光速传播的电磁波信号。到了对方手机，又被一层层"拆包"还原成文字。这个过程就像俄罗斯套娃——每一层都把上一层的数据当作自己的"内容"，再套上自己的"外壳"。

这就是协议栈（Protocol Stack）干的事情。理解协议栈，是理解整个移动通信系统的"地基"。今天我们就从上到下，把5G NR协议栈的每一层拆开来看，讲清楚三个核心问题：每一层干什么？为什么这样设计？数据在各层之间怎么封装和解封装？

一、先建立全局观：5G协议栈长什么样？

5G NR协议栈分为两个"面"：

• 用户面（User Plane）：传输用户数据（你看视频、刷网页的数据走这里）
• 控制面（Control Plane）：传输信令（网络告诉你"你可以接入"、"请切换到另一个基站"等控制信息走这里）

两者的底层（PHY/MAC/RLC/PDCP）是共享的，区别在于用户面顶部多了一个SDAP层，而控制面顶部是RRC和NAS。

graph TB
    subgraph 用户面["用户面 (User Plane)"]
        APP_U["应用数据<br/>(IP数据包)"]
        SDAP["SDAP<br/>QoS流映射"]
        PDCP_U["PDCP<br/>加密/头压缩"]
        RLC_U["RLC<br/>分段/重传"]
        MAC_U["MAC<br/>调度/复用"]
        PHY_U["PHY<br/>调制/编码/OFDM"]
    end

    subgraph 控制面["控制面 (Control Plane)"]
        NAS["NAS<br/>注册/会话管理<br/>(UE↔AMF)"]
        RRC["RRC<br/>无线资源控制<br/>(UE↔gNB)"]
        PDCP_C["PDCP<br/>加密/完整性保护"]
        RLC_C["RLC<br/>分段/重传"]
        MAC_C["MAC<br/>调度/复用"]
        PHY_C["PHY<br/>调制/编码/OFDM"]
    end

    APP_U --> SDAP --> PDCP_U --> RLC_U --> MAC_U --> PHY_U
    NAS --> RRC --> PDCP_C --> RLC_C --> MAC_C --> PHY_C

    style SDAP fill:#4CAF50,color:#fff
    style NAS fill:#FF9800,color:#fff
    style RRC fill:#FF9800,color:#fff
    style PDCP_U fill:#2196F3,color:#fff
    style PDCP_C fill:#2196F3,color:#fff
    style PHY_U fill:#9C27B0,color:#fff
    style PHY_C fill:#9C27B0,color:#fff

与OSI七层模型的对应关系

很多工程师最早接触的是OSI七层模型，但5G协议栈并不是简单地"套用"OSI。两者的对应关系如下：

设计哲学差异：OSI是"教学模型"，告诉你网络通信"应该"分几层；5G协议栈是"工程实现"，每一层的存在都对应着无线信道中的某个具体问题需要解决。比如RLC层的存在，就是因为无线信道会丢包、会乱序，需要专门的机制来处理。

二、逐层深入：每一层到底在干什么？

2.1 SDAP层——5G独有的"快递分拣员"

SDAP（Service Data Adaptation Protocol，业务数据适配协议）是5G NR新增的层，4G LTE里没有。

为什么需要SDAP？

4G时代的QoS是"承载级"的（Bearer-based）——一个EPS Bearer对应一套QoS参数。但5G要支持网络切片、海量业务，需要更细粒度的QoS控制，所以5G改成了"流级"（Flow-based），一个PDU会话内可以有多个QoS Flow，每个Flow有不同的QoS要求。

SDAP的工作就是：把核心网下发的QoS Flow映射到对应的无线承载（DRB）上。

类比理解：SDAP就像快递分拣中心的员工。核心网送来一批包裹（IP数据包），每个包裹上贴着"加急"、"普通"、"大件"标签（QFI），SDAP根据标签把包裹放到不同的运输车上（DRB），确保加急的走高速通道。

SDAP头部非常精简：只有1～2个字节。其中最重要的字段是QFI（QoS Flow Identifier，6比特），最多支持64个QoS Flow。

映射规则

一个QoS Flow只能映射到一个DRB，但一个DRB可以承载多个QoS Flow（比如多个"普通"级别的Flow可以复用同一个DRB）。这种设计在灵活性和效率之间取得了平衡。

2.2 PDCP层——数据的"保险箱"和"压缩机"

PDCP（Packet Data Convergence Protocol，分组数据汇聚协议）是协议栈中最"全能"的一层，身兼数职：

头压缩的威力

一个标准的VoIP包（RTP over UDP over IP）的头部开销是：

$$\text{头部总开销} = \text{IP头}(20\text{B}) + \text{UDP头}(8\text{B}) + \text{RTP头}(12\text{B}) = 40\text{B}$$

而语音编码器每20ms产生的有效载荷可能只有 $32\sim80$ 字节。头部开销占总带宽的 33%～55%！通过ROHC压缩，40字节头部可以压缩到 1～4字节，节省大量空口资源。

PDCP序列号（SN）

PDCP使用12比特或18比特的序列号：

$$N_{\text{PDCP_SN}} = 12 \text{ bit} \Rightarrow \text{范围: } 0 \sim 4095$$ $$N_{\text{PDCP_SN}} = 18 \text{ bit} \Rightarrow \text{范围: } 0 \sim 262143$$

18比特SN主要用于高吞吐量场景（如eMBB），避免序列号快速回绕。

2.3 RLC层——数据的"裁缝"和"质检员"

RLC（Radio Link Control，无线链路控制）负责数据的分段、重组和重传。它有三种工作模式：

graph LR
    subgraph RLC三种模式
        TM["透明模式 (TM)<br/>─────────<br/>无头部、无重传<br/>用于：BCCH/PCCH/CCCH<br/>类比：明信片，不封套"]
        UM["无确认模式 (UM)<br/>─────────<br/>有分段、无ARQ重传<br/>用于：VoNR/视频流<br/>类比：发传单，不管对方收没收到"]
        AM["确认模式 (AM)<br/>─────────<br/>有分段、有ARQ重传<br/>用于：TCP/IP数据<br/>类比：挂号信，必须签收"]
    end

    TM ---|可靠性递增| UM ---|可靠性递增| AM

    style TM fill:#8BC34A,color:#fff
    style UM fill:#FF9800,color:#fff
    style AM fill:#F44336,color:#fff

为什么需要三种模式？

不同的业务对可靠性和时延的要求不同：

• TM（透明模式）：系统广播消息（SIB）、寻呼消息——这些信息量大、时效性强，丢了就丢了，不需要重传（下一周期会再广播）。如果加了头部反而浪费资源。
• UM（无确认模式）：语音包——50ms一个包，如果丢了重传过来已经过时了。不如直接用下一个包替代。但需要按序交付，否则语音会断续。
• AM（确认模式）：网页浏览、文件下载——必须保证每个字节都正确到达，用ARQ（自动重传请求）机制确保可靠性。

分段机制

上层传下来的PDCP PDU可能很大（比如1500字节的IP包），但MAC层分配的传输块（TB）可能只有几百字节。RLC的"裁缝"功能就是把大衣"裁"成合适大小的片段：

$$\text{RLC PDU} = \text{RLC头}(2\sim6\text{B}) + \text{RLC SDU片段}$$

分段时，RLC头中的关键字段： - SI（Segmentation Info）：2比特，标识这是完整SDU还是片段 - SO（Segment Offset）：16比特，标识该片段在原始SDU中的偏移量 - SN（Sequence Number）：12或18比特，用于排序和重传

2.4 MAC层——资源的"交通警察"

MAC（Medium Access Control，媒体接入控制）是协议栈中最繁忙的层之一，它负责调度、复用和错误重传。

MAC层的核心职责

HARQ：物理层的快速纠错

HARQ（Hybrid ARQ）是MAC层最重要的机制之一。与RLC层的ARQ不同，HARQ工作在物理层，速度更快：

$$\text{HARQ重传时延} \approx 4\text{ms（5G NR）}$$ $$\text{RLC ARQ重传时延} \approx 10\sim50\text{ms}$$

HARQ采用软合并（Soft Combining）技术：第一次传输失败后，接收端不丢弃错误数据，而是将其与重传数据合并，提高解码成功率。这就像拼图——第一次拿到半张图，第二次拿到另外半张，拼在一起就完整了。

MAC PDU的结构

MAC PDU不是简单的"头部+数据"，而是由多个MAC子头部（Subheader）和对应的MAC SDU或MAC CE交替排列：

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ MAC子头1 │ MAC SDU1 │ MAC子头2 │ MAC CE  │ MAC子头3 │  ...
│ (LCID,L) │ (RLC PDU)│ (LCID,L) │(控制元素)│ (LCID,L) │
└──────────┴──────────┴──────────┴──────────┴──────────┘

其中LCID（Logical Channel ID，6比特）标识了该MAC SDU来自哪个逻辑信道，这是解复用的关键。

2.5 PHY层——把数据变成电磁波

PHY（Physical Layer，物理层）是协议栈的最底层，也是最"硬核"的一层。它把MAC层交来的比特流变成可以在天线口发射的OFDM符号。

PHY层的处理流水线

flowchart TD
    TB["传输块 TB<br/>(来自MAC)"]
    CRC["添加CRC校验"]
    SEG["码块分段<br/>+ 每段加CRC"]
    CC["信道编码<br/>LDPC(数据)<br/>Polar(控制)"]
    RM["速率匹配<br/>适配实际资源"]
    SC["码块级联"]
    MOD["调制映射<br/>QPSK/16QAM<br/>64QAM/256QAM"]
    LM["层映射<br/>(MIMO)"]
    PR["预编码<br/>(波束赋形)"]
    RE["资源映射<br/>(映射到RE)"]
    OFDM["OFDM信号生成<br/>IFFT+CP"]
    TX["天线发射<br/>(射频信号)"]

    TB --> CRC --> SEG --> CC --> RM --> SC --> MOD --> LM --> PR --> RE --> OFDM --> TX

    style TB fill:#4CAF50,color:#fff
    style CC fill:#FF9800,color:#fff
    style MOD fill:#2196F3,color:#fff
    style OFDM fill:#9C27B0,color:#fff
    style TX fill:#F44336,color:#fff

为什么用LDPC和Polar码？

5G NR做了一个重要决定： - 数据信道：用LDPC码（取代4G的Turbo码） - 控制信道：用Polar码（全新技术）

为什么这样分工？ 数据信道通常传输大的数据块（几百到几千字节），LDPC码在高速率下解码效率更高，且天然支持并行处理，适合5G的高吞吐量需求。控制信道传输的是小的控制信息（几十比特），Polar码在短码和低码率下理论性能最优。

CRC校验的必要性

PHY层在传输块（TB）和每个码块（CB）上都会添加CRC：

$$\text{TB CRC} = 24\text{ bit（用于判断整个TB是否正确）}$$ $$\text{CB CRC} = 24\text{ bit（用于判断每个码块是否正确）}$$

如果TB CRC校验失败，PHY层通过HARQ请求重传；如果只是某个CB CRC失败，LDPC解码器可以利用这个信息辅助后续解码。这是一种多层校验策略。

2.6 RRC层——无线网络的"总指挥"

RRC（Radio Resource Control，无线资源控制）是控制面的核心协议，管理UE（手机）和gNB（基站）之间的所有无线资源。

RRC的状态管理

5G NR引入了一个新状态——RRC_INACTIVE，这是相比4G的重要改进：

为什么需要INACTIVE状态？ 在4G时代，UE要么IDLE（省电但恢复慢，需要重新建立整个承载），要么CONNECTED（快但费电）。5G面向海量物联网和频繁小包业务，需要一种"快醒快睡"的中间状态——INACTIVE状态下，UE和核心网的上下文都保留着，恢复连接只需1～2个信令交互，而不是IDLE态的5～8个。

RRC管理的核心流程

RRC管理着手机生命周期中最关键的流程：

• RRC连接建立：手机从IDLE进入CONNECTED的"敲门"过程
• RRC重配置：基站告诉手机"你的无线承载参数变了"（比如增加一个新的承载）
• 切换：手机从A基站移到B基站的控制权转移
• 系统信息广播：基站广播小区的"名片"（频点、带宽、接入参数等）
• 寻呼：网络找手机（有来电或下行数据到达时）

2.7 NAS层——跨越基站的"直通车"

NAS（Non-Access Stratum，非接入层）是UE和核心网（AMF/SMF）之间的信令协议，消息不终止于gNB，基站只是"中转站"。

类比理解：NAS就像你去银行办业务时，直接和总行客服通话。支行的工作人员（gNB）帮你把电话接通，但他不会偷听你们的对话内容（NAS消息在PDCP层加密后，gNB无法解读NAS内容）。

NAS协议分为两个子层：

NAS层还负责NAS级安全（加密和完整性保护），这和PDCP层的安全是独立的——形成"双层加密"：NAS消息经过NAS加密后，又被PDCP加密一次才上空口。为什么？因为NAS消息经过gNB中转，如果gNB不可信（比如漫游场景），NAS级加密可以防止gNB窃取核心网信令。

三、数据封装全景：一个IP包的协议栈之旅

现在我们把所有层串起来，看一个完整的IP数据包从手机出发到空口的全过程：

flowchart TB
    subgraph 封装过程["发送端封装过程（自上而下）"]
        IP["📦 IP数据包<br/>(1500字节，含应用数据)"]
        SDAP_H["SDAP封装<br/>+ SDAP头(1~2B，含QFI)<br/>= SDAP PDU"]
        PDCP_H["PDCP封装<br/>+ PDCP头(2~3B，含SN)<br/>+ ROHC压缩IP头<br/>+ AES加密<br/>= PDCP PDU"]
        RLC_H["RLC封装<br/>+ RLC头(2~6B，含SN/SI/SO)<br/>+ 按MAC调度大小分段<br/>= RLC PDU(s)"]
        MAC_H["MAC封装<br/>+ MAC子头(含LCID/L)<br/>+ 多个RLC PDU复用<br/>+ MAC CE(控制信令)<br/>= MAC PDU (Transport Block)"]
        PHY_H["PHY处理<br/>+ CRC24 → 信道编码(LDPC)<br/>→ 速率匹配 → 调制(QAM)<br/>→ 层映射 → 预编码<br/>→ OFDM(IFFT+CP)<br/>= 射频信号"]
    end

    IP --> SDAP_H --> PDCP_H --> RLC_H --> MAC_H --> PHY_H

    subgraph 解封装过程["接收端解封装过程（自下而上）"]
        RX["射频接收 → OFDM解调 → 解码 → CRC校验"]
        RX_MAC["MAC: 解子头 → 解复用 → 提取RLC PDU"]
        RX_RLC["RLC: 去头 → 重组分段 → 恢复PDCP PDU"]
        RX_PDCP["PDCP: 解密 → 解头压缩 → 去重排序"]
        RX_SDAP["SDAP: 去头 → 恢复原始IP包"]
        RX_IP["✅ IP数据包送达应用层"]

        RX --> RX_MAC --> RX_RLC --> RX_PDCP --> RX_SDAP --> RX_IP
    end

    PHY_H -.->|"空口传输<br/>(电磁波)"| RX

    style IP fill:#4CAF50,color:#fff
    style SDAP_H fill:#4CAF50,color:#fff
    style PDCP_H fill:#2196F3,color:#fff
    style RLC_H fill:#FF9800,color:#fff
    style MAC_H fill:#9C27B0,color:#fff
    style PHY_H fill:#F44336,color:#fff
    style RX fill:#F44336,color:#fff
    style RX_IP fill:#4CAF50,color:#fff

各层头部开销汇总

以一个1500字节的下行IP数据包为例，各层添加的开销：

关键发现：协议栈L2各层的头部开销总共不超过 15字节，相对于1500字节的数据包不到1%。真正的"开销大户"是PHY层的信道编码——码率越低（覆盖越差），编码开销越大。所以在覆盖受限场景下，头压缩（ROHC）的价值更加突出。

四、协议栈在CU/DU架构中的分布

5G NR引入了CU/DU分离架构（Centralized Unit / Distributed Unit），把协议栈的不同层放在不同的物理位置：

graph TB
    subgraph 5GC["5G核心网"]
        AMF["AMF<br/>移动性管理"]
        UPF["UPF<br/>用户面转发"]
    end

    subgraph CU["集中式单元 CU"]
        RRC_L["RRC"]
        SDAP_L["SDAP"]
        PDCP_L["PDCP"]
    end

    subgraph DU["分布式单元 DU"]
        RLC_L["RLC"]
        MAC_L["MAC"]
        PHY_H_L["PHY-高层<br/>(编码/调制)"]
    end

    subgraph RU["射频单元 RU"]
        PHY_L_L["PHY-低层<br/>(OFDM/射频)"]
        ANT["📡 天线"]
    end

    UPF <-->|"GTP隧道"| SDAP_L
    AMF <-->|"NGAP/NAS"| RRC_L
    RRC_L <--> SDAP_L <--> PDCP_L
    PDCP_L <-->|"F1接口"| RLC_L <--> MAC_L <--> PHY_H_L
    PHY_H_L <-->|"eCPRI"| PHY_L_L <--> ANT

    style CU fill:#E3F2FD
    style DU fill:#FFF3E0
    style RU fill:#F3E5F5
    style 5GC fill:#E8F5E9

为什么要把协议栈"切开"？

工程直觉：越往上层集中，越能实现小区间协作（比如干扰协调、联合调度），但回传/前传带宽需求越大。越往下层分布，前传带宽越小，但协作增益越低。运营商需要根据光纤资源和网络目标来选择。

五、4G LTE vs 5G NR协议栈对比

设计趋势：从4G到5G，协议栈的演进方向是"更灵活"——灵活的参数集（numerology）、灵活的QoS映射、灵活的带宽管理。这反映了5G需要同时服务eMBB、URLLC、mMTC三大场景的诉求，不能用"一刀切"的设计。

六、现网调试：工程师哪里会用到这些知识？

6.1 抓包分析

当你在现网抓取空口信令时，协议栈知识是必选项：

• MAC层抓包：分析LCID值，判断哪些逻辑信道被调度、BSR是否正常上报
• RLC层抓包：查看SN号是否连续，判断是否有丢包或乱序（乱序可能是HARQ重排序导致）
• PDCP层抓包：如果数据全是乱码——说明加密正常；如果能看到明文——说明PDCP加密未启用（调试环境有时如此）
• RRC层抓包：分析系统信息（SIB）、切换命令（RRC Reconfiguration）、拒绝原因值

6.2 常见调试陷阱

6.3 用协议栈知识定位问题的思路

遇到空口数据异常时，从下往上逐层排查：

1. PHY层：看RSRP/SINR是否正常 → 不正常是覆盖/干扰问题
2. MAC层：看调度是否正常（MCS、PRB分配） → 不正常是调度问题
3. RLC层：看是否有大量重传 → 有重传是底层丢包导致
4. PDCP层：看加密是否匹配、SN是否连续 → 不连续可能是切换异常
5. SDAP层：看QFI映射是否正确 → 错误映射导致QoS不符

七、关键公式速查

传输块大小计算

$$TBS = N_{\text{PRB}} \times N_{\text{symb}}^{\text{slot}} \times N_{\text{RE}}^{\text{PRB}} \times Q_m \times R \times v$$

其中： - $N_{\text{PRB}}$：分配的PRB数 - $N_{\text{symb}}^{\text{slot}}$：每个slot的OFDM符号数 - $N_{\text{RE}}^{\text{PRB}}$：每个PRB中的可用RE数（12×可用符号 - 开销） - $Q_m$：调制阶数（QPSK=2, 16QAM=4, 64QAM=6, 256QAM=8） - $R$：目标码率 - $v$：层数（MIMO）

协议栈各层速率关系

$$R_{\text{app}} = R_{\text{PHY}} \times \eta_{\text{coding}} \times \eta_{\text{OH}} \times \eta_{\text{ARQ}}$$

其中： - $R_{\text{PHY}}$：物理层原始比特率 - $\eta_{\text{coding}}$：编码效率（码率） - $\eta_{\text{OH}}$：协议栈开销率（各层头部 / 总包长） - $\eta_{\text{ARQ}}$：重传效率（1 - 重传率）

常见问题

Q: SDAP层在什么情况下不存在？ A: SDAP层仅存在于5G NR的用户面。如果UE使用的是4G LTE接入（EN-DC场景中的MCG），则没有SDAP层。此外，在SRB（信令无线承载）上也没有SDAP，SDAP只用于DRB（数据无线承载）。

Q: PDCP层既做加密又做头压缩，顺序是怎样的？ A: 发送端先做头压缩（ROHC），再做加密。接收端反过来：先解密，再解头压缩。这个顺序很重要——因为加密后的数据无法被压缩（看起来是随机数据），所以必须先压缩再加密。

Q: HARQ和RLC ARQ有什么区别？为什么不保留一个就够了？ A: HARQ工作在MAC/PHY层，重传时延约4ms，速度快但重传次数有限（通常最多4次）。RLC ARQ工作在RLC层，重传时延约10～50ms，速度慢但可以无限重传直到成功。两者是互补关系：HARQ处理大多数单次错误（快修），RLC ARQ处理HARQ搞不定的顽固错误（慢修但彻底）。如果只用HARQ，遇到持续差信道会导致数据永久丢失；如果只用RLC ARQ，每次重传时延太长，影响用户体验。

Q: 为什么5G协议栈不像TCP/IP那样只有四五层，而要分这么多子层？ A: 无线信道和有线信道有本质区别——无线信道会随时间、频率、空间变化，存在衰落、干扰、多径效应。每一层都是为了解决一个特定的无线问题：PHY解决"比特如何在恶劣环境中可靠传输"，MAC解决"有限的无线资源如何高效共享"，RLC解决"数据如何按序可靠交付"，PDCP解决"如何在不可靠的无线链路上保证安全和效率"。如果把RLC和MAC合并，调度器在处理复用的同时还要处理分段和重传，复杂度会爆炸。

Q: 控制面和用户面为什么要分开设计？ A: 两者的设计目标完全不同。用户面追求吞吐量和效率（大数据量、头压缩、QoS映射）；控制面追求可靠性和安全性（完整性保护、双层加密、信令优先调度）。如果混在一起，信令消息可能被大块数据"堵"住，导致切换延迟、呼叫建立超时等严重问题。

参考来源

1. ShareTechnote - 5G NR Radio Protocol Stack Architecture — 5G协议栈架构详细图解，含用户面和控制面对比
2. RF Wireless World - 5G Protocol Stack — 5G L1/L2/L3各层功能概述与参数说明
3. TelecomTrainer - 5G NR Data Flow Explained — 从IP包到MAC PDU的完整数据流封装过程图解
4. MathWorks - 5G Toolbox and NR Protocol Layers — MATLAB官方5G工具箱文档，含PHY层处理流程
5. 5G NR MAC RLC PDCP SDAP详解 - CSDN博客 — 中文Layer 2各协议层功能详解

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。