先讲一个很多新手工程师都经历过的场景：用户投诉“刷视频卡”，你在核心网N3口挂上Wireshark抓包，看到的是一段干干净净的IP明文，源地址、目的地址、端口号一目了然，应用层对话清清楚楚。可是当同事把探针挪到基站空口侧，屏幕上出现的却是完全认不出的比特流——同样的数据，为什么到了空口就“面目全非”了？
答案就藏在5G空口的用户面协议栈里。一个IP包从手机发出、到达基站天线的这短短几毫秒里，要经历五层“深加工”：贴服务标签、加密编号、大件拆小、调度拼车、编码调制。每一层只解决一类问题，每一层都给数据包加上自己的“包装”。理解这个逐层封装的过程，你就掌握了5G空口数据面的一半精髓——另一半是反过来走一遍的接收解封装。
本文就跟着一个1400字节的IP包，从上到下走完这趟空中之旅。重点不是罗列每层的功能清单，而是回答那个更有价值的问题：每层为什么这样设计？
在展开之前，先聊聊分层哲学。试想如果所有功能——加密、重传、调度、调制——都揉在一个“超级协议”里，会是什么局面？
分层的本质，是把“变化的原因”和“实现的位置”对齐：调度策略经常变，就单独一层；加密算法要统一管控，就单独一层。层与层之间只通过明确定义的接口交互（层间传递的数据单元叫SDU，加上本层头部后叫PDU），于是每一层都可以独立演进、独立测试、独立排障。
5G空口用户面从上到下五层，各自的核心使命一句话概括：
| 层 | 核心使命 | 招牌功能 | 所在承载 | 一句话类比 |
|---|---|---|---|---|
| SDAP | 告诉无线网“这个包多重要” | QoS流↔DRB映射、反射映射 | 仅用户面 | 快递面单上的“加急”贴纸 |
| PDCP | 安全与业务连续性 | 加密、完整性保护、ROHC压缩、序列号重排序 | 用户面+控制面 | 银行保险箱+挂号信流水号 |
| RLC | 把大小不一的包适配给下层 | 三种模式（TM/UM/AM）、分段、ARQ重传 | 用户面+控制面 | 大件拆包的打包师傅 |
| MAC | 决定谁、何时、用什么资源发 | 动态调度、逻辑信道复用、HARQ | 用户面+控制面 | 机场塔台调度员 |
| PHY | 把比特变成电磁波 | CRC、信道编码、加扰、调制、OFDM、波束 | 最底层 | 装车加固+贴防伪条码 |
（注：控制面在此之上还有RRC和NAS层，它们管理以上所有层的配置，本文聚焦用户面数据路径。）
flowchart TB
subgraph UE["手机(UE)"]
APP["应用产生的IP包(约1400字节)"] --> S1["SDAP<br/>贴QoS标签"]
S1 --> P1["PDCP<br/>编号+压缩+加密"]
P1 --> R1["RLC<br/>按模式加工/分段"]
R1 --> M1["MAC<br/>调度+复用+HARQ"]
M1 --> F1["PHY<br/>编码+调制+OFDM"]
end
F1 -- "空口(无线电波)" --> F2
subgraph gNB["基站(gNB)"]
F2["PHY"] --> M2["MAC"] --> R2["RLC"] --> P2["PDCP"] --> S2["SDAP"]
end
S2 -- "GTP-U隧道(N3接口,已是明文IP)" --> UPF["核心网UPF"]
RRC["RRC(控制面)<br/>远程配置以上每一层"] -.->|配置参数| P1
看这张图要注意三点：
下面，正式跟着IP包出发。
IP包的第一个疑问是：我到底有多重要？
这个问题在4G时代不存在。LTE里，一条EPS承载（Bearer）从核心网一路通到手机，QoS直接绑在承载上。但5G面临新问题：网络切片时代，核心网的QoS流（QoS Flow）数量远多于无线侧的承载（DRB），而且运营商希望核心网的QoS体系和无线网的承载体系解耦——核心网管核心网的优先级分类，无线网管无线网的资源分配，两者之间需要一层“翻译”。
SDAP就是为这个翻译工作新设的层，也是5G相对4G在用户面协议栈上最显眼的结构性变化。它做的事情：根据核心网下发的映射规则，把每条QoS流装进合适的DRB，并在包头上标记QFI（QoS Flow Identifier）。
flowchart LR
subgraph Core["5G核心网侧"]
Q1["QoS Flow 1<br/>5QI=1 语音会话(GBR)"]
Q2["QoS Flow 2<br/>5QI=9 普通上网(Non-GBR)"]
Q3["QoS Flow 3<br/>5QI=7 视频直播"]
end
Q1 -->|"独占"| D1["DRB 1<br/>(配置了SDAP头)"]
Q2 -->|"两条流合走一条承载"| D2["DRB 2"]
Q3 --> D2
D1 --> L2["PDCP → RLC → MAC → PHY"]
D2 --> L2
一个容易忽略的设计细节：SDAP头只有1个字节（其中主要是QFI），而且不是每条DRB都有——只有RRC明确配置的DRB才带SDAP头。能用最小代价说清楚的事，就不增加固定开销，这是协议栈设计的一贯美学。
SDAP还有个巧思叫反射映射（Reflective Mapping）：正常流程是核心网通过NAS信令告诉手机“这类业务走哪条DRB”，但每条流都发信令太啰嗦。反射模式下，手机直接“偷看”下行包的QFI标记和所在DRB，自己学习出“上行同类包也这么发”的规则——看一遍就会，不用老师反复教。这个设计对短视频这类高频新建流的业务能明显减少信令开销。
过了SDAP，包进入PDCP——整个二层里功能最密集的一层。它一次性解决四个问题：压缩、编号、安全、连续性。
IP包的头部并不小。一个典型的语音RTP包，IPv4头20字节+UDP头8字节+RTP头12字节=40字节头部，而语音载荷往往只有32字节左右。算一下开销：
$$\eta_{压缩前} = \frac{40}{40+32} \approx 56\%$$
也就是说，超过一半的无线资源在传输“关于数据的数据”。而IP/UDP/RTP头部中有大量字段在整个通话期间几乎不变（源地址不变、端口不变、时间戳按固定增量走），完全没必要每个包都完整重发。ROHC（鲁棒头压缩）利用这个规律，把40字节头部压缩到1~3字节：
$$\eta_{压缩后} = \frac{2}{2+32} \approx 6\%$$
开销从56%降到6%。据Wikipedia的PDCP词条记载，PDCP支持的头部压缩可基于IP头压缩（RFC 2507）或ROHC（RFC 3095）。对VoLTE/VoNR这种海量小包业务，这直接决定了同样频谱资源下能塞进多少路通话。
PDCP给每个包分配一个序列号SN（5G支持12位或18位），但真正干活的是个更大的概念——COUNT：
$$\text{COUNT} = \text{HFN} \times 2^{L_{SN}} + \text{SN}$$
其中HFN（超帧号）是维护在发送和接收两侧PDCP实体内存里的“高位计数”，SN是包头里的“低位计数”。设计成两段拼接的道理很微妙：包头里的SN必须尽量短（省开销），但加密需要的输入流计数必须足够长（防重放、防密钥流重复）。短的SN在链路上飞，长的COUNT在心里记——一个负责省空气，一个负责保安全。
加密时就用COUNT作为输入之一生成密钥流，与数据异或。这带来一个关键性质：只要两侧COUNT对齐，加密流就连续。这正是下一小节“切换不丢数据”的数学基础。
一个经典问题：WiFi把加密放在MAC层，为什么蜂窝网络放在二层中间的PDCP？
核心原因是PDCP是切换过程中唯一“连续”的锚点。看位置就明白：加密如果在物理层或MAC层，手机每切换一次小区（PHY/MAC全部重建），密钥流就得重新同步，中间极易出错；而PDCP在切换时执行“状态前转”——把已编号未确认的包从老基站转到新基站，COUNT无缝延续，加密流水线不断流。同时，PDCP位于双连接（主辅基站同时服务）的分叉点之上，两层拆分也不需要二次加密。
还有一个值得讲的细节：控制面强制完整性保护，用户面长期只加密不保完整。完整性保护（防止包被篡改）要为每个包计算和校验MAC-I，CPU代价高。信令被篡改后果严重（想想有人改你的切换指令），必须保；普通数据包篡改了顶多应用层自己出错，历史上为省算力只加密。5G针对工业互联网等高安全场景新增了可选的用户面完整性保护，但默认不开启——算力换安全，依然是一笔工程账。
PDCP收发两侧都维护基于COUNT的重排序窗口和乱序重组缓存。为什么有了下层重传还要这层“终审”？下文讲RLC时你就明白了。
RLC的任务朴素：把上层交付的大小不一的PDCP PDU，加工成MAC能调度的大小。但它的精髓在于三种模式——同一套协议，提供三档“快递服务”：
| 模式 | 全称 | 有无重传 | 典型业务 | 快递类比 |
|---|---|---|---|---|
| TM | 透明模式 | 无，不加头 | 广播信令（如系统消息） | 明信片：不包装不追踪 |
| UM | 非确认模式 | 无 | VoIP语音、视稀流媒体 | 普通快递：丢了不补发 |
| AM | 确认模式 | 有（ARQ） | 网页、文件、大部分数据 | 签收快递：丢了必补 |
为什么语音宁可丢包也不用重传？算一笔时延账：语音对话的单向时延预算通常只有几十毫秒，一次ARQ重传（接收端发现丢包→发状态报告→发送端重发）往返轻松超过20ms。重传成功的包到达时，通话已经翻篇了——迟到的正确等于错误。所以语音走UM：丢了就丢了，接收端用丢包隐藏（PLC）技术合成一段“糊弄”过去，人耳几乎听不出。而文件传输对时延不敏感、对完整性极敏感，AM模式丢一个补一个，天经地义。
据Wikipedia的RLC词条，RLC的三种模式、ARQ（仅AM）、分段与重组、重排序、重复检测都是标准任务清单。但5G对RLC动了一次著名的手术，也是本系列最值得记住的架构演进之一：
4G时代，RLC承诺“按序递交”——重组好的包严格按顺序交给PDCP。5G把这个承诺收回了。
sequenceDiagram
participant P as PDCP(发送侧)
participant R as RLC-AM(发送侧)
participant A as 空口
participant R2 as RLC-AM(接收侧)
participant P2 as PDCP(接收侧)
P->>R: 交付包 #100~#105
R->>A: 发送 #100 #101
A--xR2: #102 在无线信道丢失
R->>A: #103 #104 #105 先行到达
R2->>R2: 检测到缺口：缺#102
R2->>R: STATUS报告：请求重传#102
R->>A: 重传 #102
R2->>P2: 收齐后递交(NR允许乱序上交)
P2->>P2: 按COUNT重排序<br/>补齐#102后按序向上交付
为什么要收回？想象切换场景：RLC实体在新小区重建，4G时代RLC层缓存里那些“收到但还没轮到递交”的包全部作废，上层立刻面对一串乱序包——对TCP是灾难（大量重复ACK、误判拥塞）。5G的解法是：RLC只管快（收到就上交，绝不扣留），按序的承诺由PDCP统一兑现——因为PDCP的COUNT跨切换连续，它的重排序窗口在任何动荡中都是稳定锚点。同一时间只让一层负责按序，责任清晰，切换更快，TCP更稳。
伴随这次手术，5G的RLC还砍掉了“级联”功能（4G可把多个小包串联成一个RLC PDU），打包合并的活全部交给MAC。预处理越少，单包处理时延越短——5G URLsLLC场景毫秒级时延目标，就是这样从每一层的细节里抠出来的。
如果说上面几层是“处理车间”，MAC就是整个基站的调度指挥中心。它每时隙（5G最短可到0.125毫秒级）都在回答三个问题：
1. 谁来发？——动态调度 物理下行共享信道上的无线资源是全体用户共享的，调度器综合各用户的缓存积压、信道质量、QoS优先级，每时隙决定“给谁分几块RB”。逻辑信道的优先级机制保证：信令永远排在普通数据前面，GBR业务优先于Non-GBR——SDAP在包上贴的标签，最终在这里兑现成资源。
2. 怎么拼车？——复用 RLC交下来的多个逻辑信道数据，MAC把它们拼进同一个传输块：信令的小包、语音的小包、上网的大包，共用一次调度机会。旁边还有个贴心设计：手机缓存积压了就发BSR（缓存状态报告）报告“我有多少货”，功率紧张就发PHR（功率余量报告）——调度器据此“看菜下饭”。
3. 发错了怎么办？——HARQ MAC层的HARQ是空口纠错的第一道快速反应（本系列此前专文讲过其软合并原理，此处不赘述）。这里只强调层次关系：HARQ管“快速补救”，RLC ARQ管“彻底补救”——HARQ重传若仍失败，AM模式的状态报告会在更长的周期里兜底重传。两道纠错各司其职，前者争毫秒，后者保可靠。
最后来到物理层。前面四层交下来的比特，在这里走完发射前的标准流水线：
flowchart TD
TB["MAC传输块"] --> CRC["加CRC校验"] --> SEG["码块分割"] --> COD["信道编码<br/>(数据走LDPC/控制走Polar)"] --> RM["速率匹配"] --> SCR["加扰"] --> MOD["调制<br/>QPSK~256QAM"] --> LAY["层映射+预编码<br/>(MIMO/波束赋形)"] --> REM["RE资源映射<br/>(OFDM)"] --> ANT["天线发射"]
这条流水线的每一段，本系列前几期都单独拆解过——LDPC/Polar码为什么能逼近香农极限、QAM星座图怎么“一格塞更多比特”、波束赋形怎么让能量指哪打哪、HARQ怎么做软合并。本文只补一个“栈视角”的观察：
物理层是唯一知道“电磁波世界物理规律”的层。调制阶数随信道质量动态切换、编码码率随BLER目标自适应、波束随手机移动实时跟踪——上层完全无感。这正是分层的回报：无论空口物理技术怎么换代（4G→5G→未来），上面的协议栈结构基本稳定。技术在底层革命，架构在中层稳定，业务在顶层生长。
以一个1400字节的上行IP包为例（各层头部取典型值）：SDAP约1字节+PDCP约3字节+RLC约2字节+MAC约3字节，合计不足10字节：
$$\frac{9}{1400+9} \approx 0.6\%$$
大包场景下分层开销几乎可忽略。但反过来看一个60字节的语音小包：同样是约9字节包装，开销冲到约13%——幸好有ROHC把40字节IP头压到几字节，否则小包业务早就被“包装税”拖垮。这解释了为什么协议对大包慷慨、对小包抠门：空口每字节都要花钱。
1. 分层定位法——吞吐率低时自底向上查
flowchart TD
Q["用户吞吐率低"] --> A{"PHY层: BLER是否持续偏高?"}
A -->|是| A1["查覆盖/干扰/波束对不准"]
A -->|否| B{"MAC层: HARQ重传率是否高?"}
B -->|是| B1["查信道质量波动/调度配比"]
B -->|否| C{"RLC层: AM重传率/状态报告是否频繁?"}
C -->|是| C1["查持续性弱覆盖或终端问题"]
C -->|否| D{"PDCP层: 丢弃计数是否增长?"}
D -->|是| D1["查空口拥塞或QoS不匹配"]
D -->|否| E["问题不在无线侧, 查核心网/传输/服务器"]
现网gNB的性能计数器基本就是按这个层次组织的（物理层BLER、MAC HARQ重传率、RLC重传率、PDCP丢弃率），一层层收敛，比“重启试试”专业得多。
2. 抓包位置决定你看到哪一层 N3口Wireshark看到的是PDCP解封后的明文IP——所以“核心网抓包一切正常但用户就是卡”完全可能：问题在基站以下的无线段。想看空口行为，需要基站侧日志/空口探针。
3. 常见误解清单 - 误解一：切换瞬间数据不丢是物理层的功劳。其实是PDCP的状态前转+COUNT连续性+重排序在兜底，PHY和MAC在切换中是彻底重建的。 - 误解二：语音丢包该去找RLC重传。语音走UM模式，RLC根本不重传；该查的是覆盖质量，以及接收端PLC是否在正常工作。 - 误解三：RLC UM模式“什么都不做”。它仍然做分段、重排序和重复检测，只是不重传——“不保证送达”不等于“不闻不问”。 - 调试陷阱：ROHC上下文失步。压缩依赖收发两侧维护相同的上下文，一旦失步（如长期丢包后），解压失败表现为“话音质量骤降但BLER正常”，此时要查PDCP层压缩反馈，别在物理层死磕。
Q1: PDCP和RLC都有重排序，到底听谁的？ A: 听PDCP的。5G里RLC允许乱序向上递交，PDCP按自己的COUNT做最终裁决。原因在切换：RLC实体跨小区会重建、缓存作废，而PDCP的COUNT跨切换连续——只有它有资格当“终审法官”。
Q2: 一条DRB能装多条QoS流吗？反过来呢？ A: 可以，而且这是常态——多条低优先级流常复用同一条DRB以省资源。但反过来不行：任一时刻，一条QoS流只能属于一条DRB，否则SDAP的映射规则就乱了。
Q3: 为什么加密放在PDCP，而不是像WiFi那样放在底层？ A: 为了跨切换的密钥流连续性。PDCP的COUNT跨小区切换、跨RLC重建都保持连续，加密流水线不断流；若在PHY/MAC加密，每次换小区换波束都要重新同步密钥，出错窗口大。安全锚点必须放在最“稳”的那一层。
Q4: NR用户面加密连包头里的SN也加密吗？抓包为什么完全看不到？ A: 5G对DRB的加密覆盖数据部分，空口探针在PDCP以下只能看到密文。工程师想在N3口分析应用行为是可以的（那里已是明文IP），但想核对空口的QoS标记，只能依赖gNB日志或空口协议分析仪。
Q5: 语音走UM不怕丢包，那视频通话也走UM吗？ A: 是的，实时视频同样走UM——它和语音一样“宁丢勿迟”。但非实时的视频下载/点播走AM（本质是文件传输）。同一种业务，实时属性决定模式选择，与内容类型无关。
本文由「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 等场景全覆盖。