<!-- title: 通信协议栈全景：从比特到应用的数据之旅 -->

# 通信协议栈全景：从比特到应用的数据之旅

> 当你用手机发送一条微信消息，这串文字经历了怎样的旅程？它被切割、封装、调制、发射、传播、接收、解调、解封、重组——最终出现在对方的屏幕上。这条看不见的数据之路上，每一层协议栈都在默默工作。理解协议栈，就是理解通信系统的"神经系统"。

---

## 一、从一个比喻开始：快递系统的七层模型

想象你要寄一份合同给远方的朋友。你不会直接把纸扔到路上，而是经历这样的过程：

1. **写好合同**（应用层）—— 确定要传递的内容
2. **装进信封，写上地址**（表示层）—— 格式化、加密
3. **交给快递公司**（会话层）—— 建立传输通道
4. **快递员确认收件**（传输层）—— 确保可靠送达
5. **快递站点分拣**（网络层）—— 选择路由
6. **装车运输**（数据链路层）—— 分段运输
7. **卡车在公路上行驶**（物理层）—— 实际的物理传输

每一层只关心自己的任务，并为上一层提供服务。这就是**分层架构**的核心思想——各司其职、互不干扰。

通信协议栈的设计哲学也是如此。在移动通信领域，我们主要关注两种协议栈模型：

| 对比维度 | OSI 七层模型 | TCP/IP 四层模型 | 5G 无线协议栈 |
|---------|------------|--------------|-------------|
| 层数 | 7层 | 4层 | 3层（PHY/MAC/RLC/PDCP/SDAP/RRC/NAS） |
| 设计哲学 | 理论完备 | 实用导向 | 面向无线信道优化 |
| 主要用途 | 教学参考 | 互联网通信 | 移动通信系统 |
| 数据单元 | SDU/PDU | 报文/段/包 | TB/PDU/SDU |

```mermaid
graph TB
    subgraph "5G 无线协议栈（控制面）"
        NAS["NAS层<br/>非接入层信令"]
        RRC["RRC层<br/>无线资源控制"]
        PDCP["PDCP层<br/>分组数据汇聚"]
        RLC["RLC层<br/>无线链路控制"]
        MAC["MAC层<br/>介质访问控制"]
        PHY["PHY层<br/>物理层"]
    end

    NAS --> RRC --> PDCP --> RLC --> MAC --> PHY

    subgraph "对等关系"
        UE_PHY["UE 物理层"] <--> gNB_PHY["gNB 物理层"]
    end

    style NAS fill:#e74c3c,color:#fff
    style RRC fill:#e67e22,color:#fff
    style PDCP fill:#f1c40f,color:#333
    style RLC fill:#2ecc71,color:#fff
    style MAC fill:#3498db,color:#fff
    style PHY fill:#9b59b6,color:#fff
```

## 二、物理层（PHY）：比特的物理化身

### 2.1 物理层是什么？为什么最复杂？

物理层是协议栈的"地基"。它回答一个根本问题：**如何把一串0和1变成能在空气中传播的电磁波？**

这看起来简单，实际上牵涉到整套信号处理链。让我们追踪一个比特从诞生到"飞出去"的全过程：

$$
\text{比特流} \xrightarrow{\text{信道编码}} \text{码字} \xrightarrow{\text{调制}} \text{符号} \xrightarrow{\text{层映射}} \text{层} \xrightarrow{\text{预编码}} \text{天线端口} \xrightarrow{\text{RE映射}} \text{资源网格} \xrightarrow{\text{OFDM}} \text{时域信号} \xrightarrow{\text{DAC+RF}} \text{电磁波}
$$

### 2.2 物理层的核心任务清单

物理层要完成的具体工作远比"发信号"复杂得多：

| 任务 | 具体功能 | 为什么需要 |
|------|---------|----------|
| 信道编码 | 给数据加冗余（LDPC/Polar码） | 无线信道有噪声，冗余用于纠错 |
| 调制 | 将比特映射为复数符号（QPSK/16QAM/64QAM/256QAM） | 提高频谱效率，每个符号携带更多比特 |
| 层映射 | 将符号分配到多个MIMO层 | 利用多天线提升吞吐量 |
| 预编码 | 对多天线信号做加权 | 让信号在特定方向增强（波束赋形） |
| 资源映射 | 将符号放入时频网格 | 规范化管理有限的无线资源 |
| OFDM生成 | IFFT变换+加CP | 抗多径衰落，简化均衡 |

**工程师实战提示**：在调试无线链路问题时，如果发现BLER（误块率）偏高，首先要区分是**调制阶数过高**（SNR不够支持当前MCS）还是**信道编码速率过低**（冗余不够）。这直接影响你是该降MCS还是调整信道编码参数。

### 2.3 资源网格：物理层的"棋盘"

物理层用**资源网格（Resource Grid）**来管理时频资源，这是理解5G物理层最关键的概念之一：

```mermaid
graph LR
    subgraph "时频资源网格"
        direction TB
        R1["RE"] --- R2["RE"] --- R3["RE"] --- R4["RE"]
        R5["RE"] --- R6["RE"] --- R7["RE"] --- R8["RE"]
        R9["RE"] --- R10["RE"] --- R11["RE"] --- R12["RE"]
    end

    subgraph "资源层级关系"
        RE_m["1个RE<br/>= 1子载波 × 1 OFDM符号<br/>承载1个调制符号"]
        RB_m["1个RB<br/>= 12子载波 × 7符号<br/>最小调度单位"]
        PRB_m["1个PRB<br/>= BWP内的RB<br/>实际可调度资源"]
    end

    RE_m --> RB_m --> PRB_m
```

资源网格的关键参数：

$$
N_{\text{RB}} = \frac{BW}{\Delta f \times 12}
$$

其中 $BW$ 是带宽，$\Delta f$ 是子载波间隔（SCS）。例如，100MHz带宽、30kHz SCS下：

$$
N_{\text{RB}} = \frac{100 \times 10^6}{30 \times 10^3 \times 12} \approx 273 \text{个RB}
$$

**为什么SCS这么重要？** 5G引入了灵活的参数集（Numerology），SCS可以是15kHz、30kHz、60kHz、120kHz甚至240kHz。SCS越大，OFDM符号越短，时延越低——这就是URLLC场景用大SCS的原因。但代价是CP（循环前缀）也变短了，抗多径能力下降，所以覆盖场景要用小SCS。这是一个经典的**时延 vs. 覆盖**的权衡。

## 三、MAC层：交通指挥官

### 3.1 MAC层的核心角色

如果物理层是"公路"，MAC层就是"交通指挥"。它决定：
- **谁**能在**什么时候**用**多少资源**发送数据
- 如何处理多个终端竞争同一资源的问题

MAC层提供三种逻辑信道到传输信道的映射：

| 逻辑信道 | 方向 | 功能 | 映射到传输信道 |
|---------|------|------|--------------|
| BCCH（广播控制信道） | 下行 | 系统信息广播 | BCH / DL-SCH |
| PCCH（寻呼控制信道） | 下行 | 寻呼消息 | PCH |
| CCCH（公共控制信道） | 双向 | 随机接入信令 | UL/DL-SCH |
| DCCH（专用控制信道） | 双向 | RRC/NAS信令 | UL/DL-SCH |
| DTCH（专用业务信道） | 双向 | 用户数据 | UL/DL-SCH |

### 3.2 MAC PDU的精巧结构

MAC层的数据包（PDU）设计非常精巧。它不是简单的"头部+载荷"，而是采用了**子头+MAC SDU**的串联结构：

```
┌──────────┬──────────┬──────────┬─────────┐
│ MAC子头1 │ MAC SDU1 │ MAC子头2 │ MAC SDU2│ ... │填充│
└──────────┴──────────┴──────────┴─────────┘
每个子头包含：
┌────┬────┬─────┬──────┬────────┐
│ LCID│ F  │ L   │ (可选)│  ...   │
│ 6bit│1bit│8/16bit│      │        │
└────┴────┴─────┴──────┴────────┘
LCID: 逻辑信道标识（0-32为DTCH/DCCH，33+为特殊用途）
F: 长度字段标志（0=8bit, 1=16bit）
L: 对应SDU的长度
```

**为什么这样设计？** 这种设计让MAC层可以在一个传输块（TB）中复用多个逻辑信道的数据。比如一个TB里同时装RRC信令（DCCH）和用户数据（DTCH），充分利用无线资源。

### 3.3 随机接入：从"无人认识"到"建立连接"

MAC层管理的一个重要流程是**随机接入（Random Access）**。这是终端从"没人认识"到"被网络认可"的第一步：

```mermaid
sequenceDiagram
    participant UE as 终端(UE)
    participant gNB as 基站(gNB)
    
    Note over UE: 1. 选择前导码
    UE->>gNB: Msg1: PRACH前导码<br/>(随机选择preamble index)
    Note over gNB: 2. 检测前导码<br/>计算TA(Timing Advance)
    gNB->>UE: Msg2: RAR(Random Access Response)<br/>包含: RA-RNTI, TA, UL Grant, TC-RNTI
    Note over UE: 3. 用分配的资源发送
    UE->>gNB: Msg3: RRC连接请求/调度请求<br/>包含: C-RNTI(如有)或UE标识
    Note over gNB: 4. 竞争解决
    gNB->>UE: Msg4: 竞争解决消息<br/>包含: Msg3的拷贝+C-RNTI
    
    Note over UE,gNB: 连接建立完成
```

**工程师调试陷阱**：如果UE反复发起随机接入但Msg2不回来，**不要立刻怀疑是UE的问题**。大概率是：
1. PRACH功率设置太低（gNB没听到Msg1）
2. PRACH配置索引不对（UE在错误的时频位置发送）
3. 小区负载过高（gNB来不及处理RAR）

如果Msg3发了但Msg4竞争解决失败，那才是**碰撞**问题——多个UE选了同一个前导码。

## 四、RLC层：可靠传输的守护者

### 4.1 三种模式，三种性格

RLC（Radio Link Control）层有三种传输模式，对应三种截然不同的"性格"：

| 模式 | 全称 | 特点 | 适用场景 | 开销 |
|------|------|------|---------|------|
| TM | 透明模式 | 原样透传，不加任何头部 | 系统信息、寻呼 | 无 |
| UM | 非确认模式 | 分段/重组，不重传 | VoNR语音、视频 | 低 |
| AM | 确认模式 | 分段/重组+ARQ重传 | TCP业务、信令 | 高 |

**为什么需要三种模式？** 核心逻辑是**时延和可靠性的权衡**：
- 语音通话（VoNR）对时延极度敏感，一个包丢了就丢了，重传来的包已经没用了（人的耳朵不会等），所以用UM模式
- 文件下载对可靠性要求高，丢包要重传，所以用AM模式
- 系统信息是广播的，不需要反馈，所以用最简单的TM模式

### 4.2 AM模式下的ARQ机制

AM模式的核心是**ARQ（自动重传请求）**机制。RLC AM使用基于状态报告（Status Report）的ARQ：

$$
\text{ARQ重传条件：发送方收到 NACK 或 STATUS PDU 中指示的 SN 范围}
$$

RLC AM维护一个滑动窗口，窗口大小由配置参数决定：

$$
\text{发送窗口}: [VT(A), VT(A) + AM\_WINDOW\_SIZE)
$$
$$
\text{接收窗口}: [VR(R), VR(R) + AM\_WINDOW\_SIZE)
$$

其中：
- $VT(A)$：发送方确认的最低SN
- $VR(R)$：接收方期望接收的最低SN
- $AM\_WINDOW\_SIZE$：通常为 $2^{SN\_LENGTH - 1}$

**工程实战**：RLC层的重传次数统计是判断**无线链路质量**的重要指标。如果某个UE的RLC重传率持续高于5%，说明物理层已经"力不从心"，应该考虑：
- 切换到信号更好的小区
- 降低MCS（调制编码方案）
- 检查是否存在外部干扰

## 五、PDCP层：安全与效率的平衡术

### 5.1 PDCP层的三大使命

PDCP（Packet Data Convergence Protocol）是用户面协议栈中"智商最高"的一层，承担三个关键使命：

| 使命 | 功能 | 为什么在PDCP做 |
|------|------|--------------|
| 安全处理 | 加密（用户面/控制面）和完整性保护（控制面） | 高层做安全，防止低层协议漏洞导致数据泄露 |
| 头压缩 | ROHC（健壮头压缩） | IP/TCP/UDP/RTP头部开销大（40-60字节），压缩后仅1-4字节 |
| 重排序与重复检测 | 基于COUNT值的排序 | 切换时可能乱序接收 |

### 5.2 头压缩：为什么这么重要？

一个典型的VoIP数据包：

```
IP头(20B) + UDP头(8B) + RTP头(12B) + 语音载荷(20-160B)
```

头部占比：$\frac{40}{60} = 67\%$（以最小载荷20字节计）

这意味着，如果不对头部压缩，**三分之二的无线资源都被浪费在头部上**！ROHC压缩后，头部可压缩到1-4字节：

$$
\text{压缩效率} = \frac{40 - 2}{40} = 95\%
$$

**这就是为什么语音通话可以这么高效——头压缩功不可没。**

### 5.3 COUNT值：安全的基石

PDCP层的安全依赖于COUNT值，这是一个32位的计数器，由两部分组成：

$$
\text{COUNT} = \text{HFN}(\text{超帧号，25-32bit}) + \text{PDCP SN}(\text{序列号，5-18bit})
$$

| 参数 | 长度 | 含义 |
|------|------|------|
| HFN | 25~32 bit | 高位计数器，SN翻转时+1 |
| PDCP SN | 5/7/12/15/18 bit | 低位序列号，每个PDU+1 |
| COUNT | 32 bit | 完整计数器，用于加密算法输入 |

**为什么不能只用SN？** 因为SN长度有限（最短只有5bit，即32就翻转），如果只用SN做加密输入，攻击者可以通过收集相同SN的包来分析密钥流。HFN的引入使得COUNT值在极长时间内不重复（32bit = 43亿个PDU），极大提升了安全性。

**工程师注意**：如果现网中某个UE出现**PDCP COUNT值失同步**（比如UE侧和gNB侧COUNT不一致），会导致该UE所有加密数据无法解密——现象就是"连接在但数据全乱"。这种情况常见于**切换失败后回退**或**DRB重建**场景，需要关注PDCP状态报告是否正确交互。

## 六、SDAP层：5G新增的"流量调度员"

### 6.1 为什么4G没有SDAP？

SDAP（Service Data Application Protocol）是5G新引入的层，它的出现和5G的网络切片紧密相关。

在4G时代，所有业务通过EPS承载（Bearer）映射到逻辑信道，承载数量有限（通常8-11个），灵活性不足。5G引入了**QoS Flow**概念，可以支持大量细粒度的QoS流，这就需要一个专门的层来管理**QoS Flow到DRB的映射**。

```
4G: 应用数据 → 承载(EPS Bearer) → 逻辑信道
5G: 应用数据 → QoS Flow → SDAP映射 → DRB → 逻辑信道
```

### 6.2 SDAP的两个关键功能

| 功能 | 描述 | 实现方式 |
|------|------|---------|
| QoS Flow到DRB映射 | 决定每个QoS Flow走哪个DRB | SDAP头部中的QFI字段 |
| 反射式QoS | UE通过观察下行包自动学习上行映射 | SDAP头部中的RDI字段 |

反射式QoS（Reflective QoS）是5G的一个巧妙设计：gNB在下行数据包的SDAP头部标记RDI=1，UE观察到后，就知道"这个QoS Flow对应的DRB是什么"，然后在上行方向也用同样的映射——**不需要显式信令配置**。这大大减少了信令开销。

## 七、控制面协议栈：RRC与NAS

### 7.1 RRC层：无线世界的"大管家"

RRC（Radio Resource Control）是控制面的核心，负责：
- 系统信息广播（SIB）
- 连接管理（建立/重配/释放）
- 移动性管理（切换/重定向）
- 测量配置与报告
- 专用信令的加密/完整性保护

RRC状态机是理解终端行为的关键：

```text
stateDiagram-v2
    [*] --> RRC_IDLE: 开机驻留
    RRC_IDLE --> RRC_INACTIVE: 5G新增状态<br/>核心网保持连接
    RRC_IDLE --> RRC_CONNECTED: RRC建立<br/>（发起业务/被叫）
    RRC_INACTIVE --> RRC_CONNECTED: RRC恢复<br/>（RNA内返回）
    RRC_INACTIVE --> RRC_IDLE: RNA超时<br/>（移出RNA区域）
    RRC_CONNECTED --> RRC_INACTIVE: RRC释放<br/>（挂起配置）
    RRC_CONNECTED --> RRC_IDLE: RRC释放<br/>（正常释放）
    
    note left of RRC_IDLE: UE位置: TA级别<br/>CN连接: 无<br/>功耗: 最低
    note left of RRC_INACTIVE: UE位置: RNA级别<br/>CN连接: 保持<br/>功耗: 中等
    note right of RRC_CONNECTED: UE位置: 小区级别<br/>CN连接: 有<br/>功耗: 最高
```

**RRC_INACTIVE状态是5G的杀手锏之一。** 4G只有IDLE和CONNECTED两个状态，终端从IDLE回到CONNECTED需要完整的RRC建立过程（约100ms）。5G引入INACTIVE后，核心网的NAS连接保持不释放，UE只需要做RRC恢复（约10-20ms），时延降低了5-10倍。这对频繁收发小包的物联网设备尤为重要。

### 7.2 NAS层：终端与核心网的直接对话

NAS（Non-Access Stranning）信令是UE和AMF之间的"直线电话"，gNB只是"传话人"。关键NAS流程包括：

| NAS流程 | 功能 | 典型消息 |
|---------|------|---------|
| 注册管理 | 注册/去注册 | Registration Request/Accept |
| 连接管理 | 建立/释放NAS信令连接 | Service Request |
| 会话管理 | PDU会话建立/修改/释放 | PDU Session Establishment |
| 安全流程 | 认证/安全模式 | Authentication/SMS |

**为什么需要NAS？** 因为有些信息（比如用户身份、鉴权密钥）不应该暴露给无线接入网（gNB）。NAS信令在UE和核心网之间端到端加密，gNB只能看到外层的RRC封装，看不到NAS内容。这是5G安全架构的一个重要原则——**接入网不被完全信任**。

## 八、数据封装的完整图景：一个包的完整旅程

让我们追踪一个TCP数据包从应用到天线的完整封装过程：

```mermaid
graph TB
    subgraph "封装过程（发送方向）"
        A["应用数据<br/>（HTTP请求）"] -->|TCP头| B["TCP段<br/>+ TCP头部(20B)"]
        B -->|IP头| C["IP包<br/>+ IP头部(20B)"]
        C -->|SDAP头| D["SDAP PDU<br/>+ QFI(1B)"]
        D -->|PDCP头| E["PDCP PDU<br/>+ PDCP SN + 加密"]
        E -->|RLC头| F["RLC PDU<br/>+ RLC SN + 分段"]
        F -->|MAC头| G["MAC PDU(TB)<br/>+ MAC子头 + 复用"]
        G -->|信道编码<br/>调制<br/>OFDM| H["物理信号<br/>电磁波发射"]
    end

    subgraph "每层增加的开销"
        OH1["+20B TCP头"]
        OH2["+20B IP头"]
        OH3["+1B SDAP"]
        OH4["+2-3B PDCP"]
        OH5["+2-3B RLC"]
        OH6["+3-6B MAC"]
        OH7["+物理层开销<br/>（编码+CP+参考信号）"]
    end
```

**开销到底有多大？** 让我们算一笔账：

假设发送一个100字节的TCP ACK包（仅ACK，无载荷）：

| 层 | 头部大小 | 累计大小 |
|----|---------|---------|
| 原始数据 | 0B（纯ACK） | 0B |
| TCP头 | +20B | 20B |
| IP头 | +20B | 40B |
| SDAP头 | +1B | 41B |
| PDCP头 | +2B | 43B |
| RLC头 | +2B | 45B |
| MAC头 | +3B | 48B |
| MAC CRC | +3B | 51B |
| 物理层开销 | ~30-50% | ~70-80B |

最终一个"空"的TCP ACK在空中实际占用约70-80字节——**效率只有0%**（没有有效载荷），但这就是协议栈的"税"。

**优化启示**：这就是为什么TCP的延迟ACK（Delayed ACK）和Nagle算法如此重要——合并小包可以显著提高无线链路的效率。

## 九、用户面 vs. 控制面：两条不同的高速公路

协议栈在用户面和控制面的结构有所不同：

| 对比项 | 用户面 | 控制面 |
|--------|-------|--------|
| 应用层 | 应用数据（视频/网页/语音） | NAS信令 |
| SDAP层 | ✅ 有（QoS映射） | ❌ 无 |
| PDCP层 | ✅ 加密 | ✅ 加密+完整性保护 |
| RLC层 | AM/UM模式 | AM模式 |
| MAC层 | 调度/复用 | 调度/复用+RA |
| PHY层 | 数据信道(PDSCH/PUSCH) | 控制信道(PDCCH/PUCCH) |
| 时延要求 | 因业务而异 | 通常要求低时延 |
| 可靠性要求 | 因业务而异 | 极高（信令不能丢） |

**控制面信令全部使用AM模式**，因为信令丢失会导致状态不一致——比如切换命令丢了，UE和gNB对"该切到哪个小区"的理解就不一样，后果严重。

## 十、协议栈在现网中的体现：工程师调试指南

### 10.1 各层异常的典型现象

| 现象 | 可能的协议层 | 排查思路 |
|------|------------|---------|
| SINR好但吞吐量低 | MAC层调度 | 检查调度器配置、PRB利用率 |
| 吞吐量波动大 | RLC层重传 | 查RLC重传率、BLER统计 |
| 连接建立后数据异常 | PDCP层 | 检查COUNT同步、安全配置 |
| 切换后短暂断网 | PDCP/RLC | 查看PDCP状态报告是否交互 |
| 无法驻留小区 | PHY/MAC | 检查SSB测量、PRACH配置 |
| QoS不符合预期 | SDAP层 | 检查QFI映射、QoS参数配置 |

### 10.2 抓包分析的正确姿势

用Wireshark分析5G协议栈时，注意这些关键信息：

1. **PHY层**：通常不可直接抓取（需要专用设备），但可以通过日志查看MCS、PRB分配、BLER等统计
2. **MAC层**：关注BSR（Buffer Status Report）、PHR（Power Headroom Report）、CE（Control Element）
3. **RLC层**：关注SN序列、重传统计、状态报告
4. **PDCP层**：关注SN、COUNT值、丢弃计时器
5. **RRC层**：关注消息类型、承载配置、测量报告

## 十一、4G到5G协议栈的关键演进

| 演进点 | 4G LTE | 5G NR | 设计动机 |
|--------|--------|-------|---------|
| 新增SDAP层 | 无 | 有 | 支持灵活的QoS Flow映射 |
| PDCP SN长度 | 5/7/12 bit | 5/7/12/15/18 bit | 支持更大带宽和更多数据 |
| RLC AM SN | 10 bit | 12/16 bit | 减少SN翻转导致的窗口停顿 |
| MAC CE类型 | 较少 | 新增多个（如BFR、SCell等） | 支持更复杂的MAC层功能 |
| RRC状态 | IDLE/CONNECTED | +INACTIVE | 减少信令、降低时延 |
| 灵活参数集 | 单一SCS | 多种SCS | 适应不同场景需求 |

**最大变化**：5G协议栈不是推翻4G重来，而是在4G基础上做了"增量升级"。核心的分层架构（PHY→MAC→RLC→PDCP）完全保留，各层的核心机制（调度、ARQ、安全）一脉相承。理解了4G协议栈，5G只是"多了几个旋钮"。

## 十二、协议栈设计的深层哲学

回顾整个协议栈，你会发现几个贯穿始终的设计原则：

### 12.1 分层解耦

每层只关心自己的事。物理层不关心传的是视频还是信令，RLC不关心数据的加密方式。这使得每一层可以独立优化——物理层可以用新的调制技术，不影响MAC层的调度逻辑。

### 12.2 逐层抽象

每一层为上一层提供"服务"，隐藏下层的复杂性。PDCP层给上层提供"可靠的安全通道"，不用管RLC是用AM还是UM。

### 12.3 控制面与用户面分离

信令和数据走不同的"管道"，可以独立优化。控制面追求极致可靠，用户面追求极致效率。这种分离在5G核心网中进一步延伸为**CUPS（控制面与用户面分离）**架构。

### 12.4 适配而非统一

协议栈提供多种模式（TM/UM/AM）、多种SCS、多种MCS——没有一种"最优"配置，只有"最适合"的配置。这种灵活性使得5G能同时服务eMBB、URLLC和mMTC三种截然不同的场景。

---

## 常见问题

**Q: 为什么5G要在PDCP层做加密而不是在更低的MAC或RLC层？**
A: 两个原因。第一，MAC和RLC在切换时可能会改变（比如切换到新小区，MAC和RLC重建），如果在低层加密，切换会导致密钥上下文丢失。PDCP在切换时可以保持安全上下文，实现无损切换。第二，低层协议可能被篡改（比如伪基站攻击），加密放在高层可以保护数据不被中间环节窃听。

**Q: RLC层的ARQ和HARQ有什么区别？为什么需要两层重传？**
A: HARQ在物理层/MAC层运行，特点是快速（约4ms反馈）但只是简单重传+软合并。RLC ARQ在RLC层运行，特点是可靠（基于状态报告，确保不丢包）但时延较大（10-100ms级别）。两层配合的逻辑是：HARQ先快速纠正大部分错误，剩下HARQ搞不定的（比如严重衰落）交给RLC ARQ慢慢重传。这样兼顾了效率和可靠性。

**Q: 5G协议栈和Wi-Fi协议栈有什么本质区别？**
A: 最大区别在于**资源调度机制**。5G是集中调度——基站决定每个终端在什么时间用什么资源，通过DCI（下行控制信息）通知终端。Wi-Fi是竞争接入——大家抢信道，先到先得（CSMA/CA）。这导致5G的MAC层比Wi-Fi复杂得多（需要DCI、BSR、调度请求等机制），但也保证了确定性的时延和更高的频谱效率。

**Q: 协议栈各层的处理时延大概是多少？**
A: 以5G NR为例（假设30kHz SCS）：物理层处理约1-2个OFDM符号（~35μs），MAC层调度约1个slot（0.5ms），RLC层通常1-2ms，PDCP层<1ms，SDAP层可忽略。从应用层数据到空中发射，总处理时延约2-5ms（不含传播时延和核心网时延）。但要注意这只是单方向，端到端还要加上对端处理、核心网转发等。

**Q: 实际工程中，哪一层的参数调优对用户体验影响最大？**
A: 通常是**MAC层的调度参数**影响最大。因为调度器直接决定了用户获得多少PRB资源、使用什么MCS。一个调度器配置不当的小区，即使用户信号很好，也可能只分到很少的资源。其次是**物理层的功控参数**和**RLC层的重传参数**。PDCP和SDAP层的参数通常采用默认配置即可，很少需要调整。

---

## 参考来源

1. [3GPP TS 38.300 - NR and NG-RAN Overall Description](https://www.3gpp.org/DynaReport/38300.htm) — 5G无线协议栈总体架构的权威规范
2. [ShareTechnote - 5G Protocol Stack](https://www.sharetechnote.com/html/5G/5G_ProtocolStack.html) — 韩国工程师博客，包含丰富的协议栈图解和实例
4. [5G Americas - 5G NR Overview](https://www.5gamericas.org/resource/5g-nr-overview/) — 行业白皮书，包含协议栈设计动机分析
5. 《5G移动通信系统及关键技术》— 人民邮电出版社，协议栈各层详细原理的中文教材参考

---
> 本文由「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)