<!-- title: 5G协议栈全景：从物理层到应用层 -->

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

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

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

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

---

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

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

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

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

```mermaid
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层级 | OSI名称 | 5G协议栈对应 | 说明 |
|---------|---------|-------------|------|
| Layer 7 | 应用层 | 不在无线协议栈内 | 由手机APP和云端服务器处理 |
| Layer 6 | 表示层 | NAS安全 / PDCP加密 | 数据加密和格式转换 |
| Layer 5 | 会话层 | NAS会话管理 | PDU会话的建立和维护 |
| Layer 4 | 传输层 | SDAP（部分） | QoS流到无线承载的映射 |
| Layer 3 | 网络层 | RRC + NAS | 无线资源控制和移动性管理 |
| Layer 2 | 数据链路层 | PDCP + RLC + MAC | 头压缩、分段、复用、HARQ |
| Layer 1 | 物理层 | PHY | OFDM调制、信道编码、MIMO |

> **设计哲学差异**：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关键功能 | 说明 |
|-------------|------|
| QoS Flow → DRB映射 | 根据QFI将数据包分配到对应承载 |
| QFI标记 | 在上行/下行数据包中标记QoS Flow ID |
| 反射式QoS（Reflective QoS） | UE通过观察下行映射关系，自动推导上行映射 |

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，分组数据汇聚协议）是协议栈中最"全能"的一层，身兼数职：

| 功能 | 说明 | 为什么需要 |
|------|------|-----------|
| **加密/解密** | 对用户面和控制面数据进行AES/Snow3G加密 | 防止空口窃听 |
| **完整性保护** | 控制面必选，用户面可选 | 防止数据被篡改 |
| **头压缩** | 使用ROHC算法压缩IP/TCP/UDP/RTP头 | 无线带宽宝贵，40字节IP头可以压到1～3字节 |
| **重排序和去重** | 接收端按序交付，丢弃重复包 | 切换时可能收到重复数据 |
| **PDCP复制** | 同一数据通过两个RLC实体发送 | 提高可靠性（用于URLLC场景） |

#### 头压缩的威力

一个标准的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，无线链路控制）负责数据的分段、重组和重传。它有三种工作模式：

```mermaid
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层的核心职责

| 功能 | 说明 |
|------|------|
| **调度** | 决定哪些UE在什么时间、用哪些资源块传数据 |
| **复用/解复用** | 把多个逻辑信道的数据复用到一个传输块中 |
| **HARQ** | 混合自动重传请求，物理层的"快速纠错" |
| **逻辑信道优先级** | 按优先级分配资源（信令优先于数据） |
| **BSR上报** | 告诉网络"我还有多少数据要发" |
| **随机接入** | UE从空闲态接入网络的"敲门"过程 |
| **BWP切换** | 带宽部分切换，省电和灵活带宽管理 |

#### 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层的处理流水线

```mermaid
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码 | Polar码 | Turbo码（4G用） |
|---------|--------|---------|---------------|
| 适用场景 | 数据信道（大块数据） | 控制信道（小块数据） | 数据信道 |
| 解码复杂度 | 较低，支持并行 | 中等 | 较高 |
| 高码率性能 | 优秀（接近香农极限） | 一般 | 良好 |
| 低码率性能 | 良好 | 优秀（首次可达香农极限） | 良好 |
| 灵活度 | 支持很长码块 | 固定码长 | 码长受限 |

**为什么这样分工？** 数据信道通常传输大的数据块（几百到几千字节），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的重要改进：

| 状态 | 描述 | 特点 |
|------|------|------|
| **RRC_IDLE** | UE未建立RRC连接 | 省电，但寻呼时延长 |
| **RRC_INACTIVE** | RRC连接"挂起" | 核心网侧仍保留上下文，恢复速度快 |
| **RRC_CONNECTED** | UE活跃通信 | 可以收发数据，但最费电 |

**为什么需要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-MM**（移动性管理） | 注册、去注册、服务请求、寻呼 | AMF |
| **NAS-SM**（会话管理） | PDU会话建立/修改/释放 | SMF |

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

---

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

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

```mermaid
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数据包为例，各层添加的开销：

| 协议层 | 头部大小 | 关键字段 | 开销占比 |
|--------|---------|---------|---------|
| SDAP | 1～2 B | QFI, DCI | ≈ 0.1% |
| PDCP | 2～3 B | SN (12/18 bit), PDU Type | ≈ 0.2% |
| RLC | 2～6 B | SN, SI, SO, FI | ≈ 0.3% |
| MAC | 2～4 B/子头 | LCID, L, F | ≈ 0.3% |
| PHY | CRC 24bit + 编码开销 | 取决于码率 | 5%～50% |

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

---

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

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

```mermaid
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
```

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

| 架构选项 | 分割点 | 优点 | 缺点 |
|---------|--------|------|------|
| **Option 2** | PDCP/RLC之间 | CU集中调度，协作多点（CoMP）容易实现 | F1接口需要高带宽 |
| **Option 6** | MAC/PHY之间 | MAC集中调度，PHY分布式处理 | 前传带宽需求大 |
| **Option 7-2** | PHY内部（高/低层） | 平衡前传带宽和协作增益 | 接口标准化复杂 |

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

---

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

| 对比维度 | 4G LTE | 5G NR |
|---------|--------|-------|
| **用户面最上层** | 直接IP → PDCP | IP → **SDAP** → PDCP |
| **QoS机制** | 承载级（EPS Bearer） | **流级**（QoS Flow + DRB） |
| **RRC状态** | IDLE / CONNECTED | IDLE / **INACTIVE** / CONNECTED |
| **数据信道编码** | Turbo码 | **LDPC码** |
| **控制信道编码** | 卷积码（TBCC） | **Polar码** |
| **波形** | DL: OFDM, UL: SC-FDMA | DL/UL: **CP-OFDM** + DFT-s-OFDM |
| **PDCP SN长度** | 7/12 bit | **12/18 bit** |
| **头压缩** | ROHC | ROHC（增强） |
| **MAC层新增** | - | **BWP切换**、多TRP调度 |
| **最大带宽** | 20 MHz/载波 | **400 MHz**（mmWave） |
| **子载波间隔** | 固定15 kHz | **15/30/60/120/240 kHz**（灵活numerology） |

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

---

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

### 6.1 抓包分析

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

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

### 6.2 常见调试陷阱

| 陷阱 | 现象 | 原因分析 |
|------|------|---------|
| **HARQ vs RLC ARQ混淆** | 看到重传就认为是RLC ARQ | HARQ重传在MAC/PHY层，RLC ARQ在RLC AM实体。日志中看的位置不同 |
| **PDCP SN回绕** | PDCP SN突然从4095跳到0 | 12比特SN自然回绕，不是异常。但如果回绕时没做重排序，会导致丢包 |
| **RLC分段误解** | 看到多个RLC PDU的SN相同 | 这是分段（同一个SDU被分成多个PDU），不是重复。检查SO字段区分 |
| **SDAP缺失** | 抓包看不到SDAP头 | 某些配置下SDAP头可以省略（映射规则明确时），不是协议栈没工作 |
| **CU/DU接口问题** | F1接口告警但空口正常 | F1接口问题只影响CU/DU之间，不影响DU内部的MAC/PHY层本地操作 |

### 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](https://www.sharetechnote.com/html/5G/5G_RadioProtocolStackArchitecture.html) — 5G协议栈架构详细图解，含用户面和控制面对比
2. [RF Wireless World - 5G Protocol Stack](https://www.rfwireless-world.com/terminology/5g-protocol-stack) — 5G L1/L2/L3各层功能概述与参数说明
3. [TelecomTrainer - 5G NR Data Flow Explained](https://www.telecomtrainer.com/5g-nr-data-flow-explained-from-ip-packets-to-mac-pdus/) — 从IP包到MAC PDU的完整数据流封装过程图解
4. [MathWorks - 5G Toolbox and NR Protocol Layers](https://www.mathworks.com/help/5g/gs/5g-toolbox-and-the-5g-nr-physical-layer.html) — MATLAB官方5G工具箱文档，含PHY层处理流程
5. [5G NR MAC RLC PDCP SDAP详解 - CSDN博客](https://blog.csdn.net/bingfeilongxin/article/details/90245274) — 中文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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)