当你用手机发送一条微信消息,这串文字经历了怎样的旅程?它被切割、封装、调制、发射、传播、接收、解调、解封、重组——最终出现在对方的屏幕上。这条看不见的数据之路上,每一层协议栈都在默默工作。理解协议栈,就是理解通信系统的"神经系统"。
想象你要寄一份合同给远方的朋友。你不会直接把纸扔到路上,而是经历这样的过程:
每一层只关心自己的任务,并为上一层提供服务。这就是分层架构的核心思想——各司其职、互不干扰。
通信协议栈的设计哲学也是如此。在移动通信领域,我们主要关注两种协议栈模型:
| 对比维度 | OSI 七层模型 | TCP/IP 四层模型 | 5G 无线协议栈 |
|---|---|---|---|
| 层数 | 7层 | 4层 | 3层(PHY/MAC/RLC/PDCP/SDAP/RRC/NAS) |
| 设计哲学 | 理论完备 | 实用导向 | 面向无线信道优化 |
| 主要用途 | 教学参考 | 互联网通信 | 移动通信系统 |
| 数据单元 | SDU/PDU | 报文/段/包 | TB/PDU/SDU |
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
物理层是协议栈的"地基"。它回答一个根本问题:如何把一串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{电磁波} $$
物理层要完成的具体工作远比"发信号"复杂得多:
| 任务 | 具体功能 | 为什么需要 |
|---|---|---|
| 信道编码 | 给数据加冗余(LDPC/Polar码) | 无线信道有噪声,冗余用于纠错 |
| 调制 | 将比特映射为复数符号(QPSK/16QAM/64QAM/256QAM) | 提高频谱效率,每个符号携带更多比特 |
| 层映射 | 将符号分配到多个MIMO层 | 利用多天线提升吞吐量 |
| 预编码 | 对多天线信号做加权 | 让信号在特定方向增强(波束赋形) |
| 资源映射 | 将符号放入时频网格 | 规范化管理有限的无线资源 |
| OFDM生成 | IFFT变换+加CP | 抗多径衰落,简化均衡 |
工程师实战提示:在调试无线链路问题时,如果发现BLER(误块率)偏高,首先要区分是调制阶数过高(SNR不够支持当前MCS)还是信道编码速率过低(冗余不够)。这直接影响你是该降MCS还是调整信道编码参数。
物理层用资源网格(Resource Grid)来管理时频资源,这是理解5G物理层最关键的概念之一:
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层就是"交通指挥"。它决定: - 谁能在什么时候用多少资源发送数据 - 如何处理多个终端竞争同一资源的问题
MAC层提供三种逻辑信道到传输信道的映射:
| 逻辑信道 | 方向 | 功能 | 映射到传输信道 |
|---|---|---|---|
| BCCH(广播控制信道) | 下行 | 系统信息广播 | BCH / DL-SCH |
| PCCH(寻呼控制信道) | 下行 | 寻呼消息 | PCH |
| CCCH(公共控制信道) | 双向 | 随机接入信令 | UL/DL-SCH |
| DCCH(专用控制信道) | 双向 | RRC/NAS信令 | UL/DL-SCH |
| DTCH(专用业务信道) | 双向 | 用户数据 | UL/DL-SCH |
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),充分利用无线资源。
MAC层管理的一个重要流程是随机接入(Random Access)。这是终端从"没人认识"到"被网络认可"的第一步:
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(Radio Link Control)层有三种传输模式,对应三种截然不同的"性格":
| 模式 | 全称 | 特点 | 适用场景 | 开销 |
|---|---|---|---|---|
| TM | 透明模式 | 原样透传,不加任何头部 | 系统信息、寻呼 | 无 |
| UM | 非确认模式 | 分段/重组,不重传 | VoNR语音、视频 | 低 |
| AM | 确认模式 | 分段/重组+ARQ重传 | TCP业务、信令 | 高 |
为什么需要三种模式? 核心逻辑是时延和可靠性的权衡: - 语音通话(VoNR)对时延极度敏感,一个包丢了就丢了,重传来的包已经没用了(人的耳朵不会等),所以用UM模式 - 文件下载对可靠性要求高,丢包要重传,所以用AM模式 - 系统信息是广播的,不需要反馈,所以用最简单的TM模式
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(Packet Data Convergence Protocol)是用户面协议栈中"智商最高"的一层,承担三个关键使命:
| 使命 | 功能 | 为什么在PDCP做 |
|---|---|---|
| 安全处理 | 加密(用户面/控制面)和完整性保护(控制面) | 高层做安全,防止低层协议漏洞导致数据泄露 |
| 头压缩 | ROHC(健壮头压缩) | IP/TCP/UDP/RTP头部开销大(40-60字节),压缩后仅1-4字节 |
| 重排序与重复检测 | 基于COUNT值的排序 | 切换时可能乱序接收 |
一个典型的VoIP数据包:
IP头(20B) + UDP头(8B) + RTP头(12B) + 语音载荷(20-160B)
头部占比:$\frac{40}{60} = 67\%$(以最小载荷20字节计)
这意味着,如果不对头部压缩,三分之二的无线资源都被浪费在头部上!ROHC压缩后,头部可压缩到1-4字节:
$$ \text{压缩效率} = \frac{40 - 2}{40} = 95\% $$
这就是为什么语音通话可以这么高效——头压缩功不可没。
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(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 → 逻辑信道
| 功能 | 描述 | 实现方式 |
|---|---|---|
| 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(Radio Resource Control)是控制面的核心,负责: - 系统信息广播(SIB) - 连接管理(建立/重配/释放) - 移动性管理(切换/重定向) - 测量配置与报告 - 专用信令的加密/完整性保护
RRC状态机是理解终端行为的关键:
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倍。这对频繁收发小包的物联网设备尤为重要。
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数据包从应用到天线的完整封装过程:
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算法如此重要——合并小包可以显著提高无线链路的效率。
协议栈在用户面和控制面的结构有所不同:
| 对比项 | 用户面 | 控制面 |
|---|---|---|
| 应用层 | 应用数据(视频/网页/语音) | NAS信令 |
| SDAP层 | ✅ 有(QoS映射) | ❌ 无 |
| PDCP层 | ✅ 加密 | ✅ 加密+完整性保护 |
| RLC层 | AM/UM模式 | AM模式 |
| MAC层 | 调度/复用 | 调度/复用+RA |
| PHY层 | 数据信道(PDSCH/PUSCH) | 控制信道(PDCCH/PUCCH) |
| 时延要求 | 因业务而异 | 通常要求低时延 |
| 可靠性要求 | 因业务而异 | 极高(信令不能丢) |
控制面信令全部使用AM模式,因为信令丢失会导致状态不一致——比如切换命令丢了,UE和gNB对"该切到哪个小区"的理解就不一样,后果严重。
| 现象 | 可能的协议层 | 排查思路 |
|---|---|---|
| SINR好但吞吐量低 | MAC层调度 | 检查调度器配置、PRB利用率 |
| 吞吐量波动大 | RLC层重传 | 查RLC重传率、BLER统计 |
| 连接建立后数据异常 | PDCP层 | 检查COUNT同步、安全配置 |
| 切换后短暂断网 | PDCP/RLC | 查看PDCP状态报告是否交互 |
| 无法驻留小区 | PHY/MAC | 检查SSB测量、PRACH配置 |
| QoS不符合预期 | SDAP层 | 检查QFI映射、QoS参数配置 |
用Wireshark分析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只是"多了几个旋钮"。
回顾整个协议栈,你会发现几个贯穿始终的设计原则:
每层只关心自己的事。物理层不关心传的是视频还是信令,RLC不关心数据的加密方式。这使得每一层可以独立优化——物理层可以用新的调制技术,不影响MAC层的调度逻辑。
每一层为上一层提供"服务",隐藏下层的复杂性。PDCP层给上层提供"可靠的安全通道",不用管RLC是用AM还是UM。
信令和数据走不同的"管道",可以独立优化。控制面追求极致可靠,用户面追求极致效率。这种分离在5G核心网中进一步延伸为CUPS(控制面与用户面分离)架构。
协议栈提供多种模式(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层的参数通常采用默认配置即可,很少需要调整。
本文由「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 等场景全覆盖。
