# 数据转发：切换不丢包的秘密
> 当你坐高铁刷视频、打电话，手机在几秒内换了三四个基站，画面却没卡、通话没断。这背后不是魔法，而是一套精密的"数据搬家"机制——**数据转发（Data Forwarding）** 与 **序列号状态转移（SN Status Transfer）**。今天我们拆解它，看看切换瞬间那几毫秒的"空窗期"里，网络到底做了什么，才让你的数据一个不丢。
## 一、先建立一个直觉：切换为什么"天然"会丢包？
想象你在搬家。老房子（源基站）和新房子（目标基站）之间，有一批快递（你的数据包）正在路上。如果搬家这一刻，你直接锁门走人，那正在路上的快递怎么办？两种可能：要么丢在老房子门口，要么送错了地方。
通信里的切换，本质上就是一次"搬家"，而"路上的快递"就是那些**已经从核心网发到源基站、但还没来得及发给你（下行）** 或者**你已经发出去、但源基站还没收到确认（上行）** 的数据包。
切换发生时，UE（终端）会从源基站断开、接入目标基站。这段断开的时间里：
- 核心网如果还往源基站发数据，这些数据会"堵"在源基站，UE 已经走了，永远收不到；
- 源基站发出去但 UE 没确认的下行包，UE 也不会再向源基站要了；
- UE 上行发出的包，源基站没来得及确认的，UE 也不知道要不要重传。
如果什么都不做，**每一次切换都会丢一批包**。打 VoIP 电话时，丢包表现为几声"咔咔"的爆音；看视频时会卡顿一下；玩实时游戏会掉帧。这对 1Hz 频繁切换的高铁场景，是灾难性的。
所以网络设计了一套机制，专门解决这个"搬家丢快递"的问题。它的核心思想其实很朴素：**在 UE 还没到新房子之前，就把老房子里的快递转寄过去，并且附上一张清单，告诉新房子的主人"这些我已经签收了，那些还没收到"。**
这张"转寄"的动作叫**数据转发**，这张"清单"叫**SN 状态转移**。两者配合，才能实现真正的无损切换。
## 二、数据转发：把快递转寄到新地址
### 2.1 转发什么？
数据转发不是把所有数据都转发，那样太浪费带宽。源基站只会转发**"还有价值"的数据**：
| 方向 | 转发的内容 | 不转发的内容 |
|------|-----------|-------------|
| **下行（DL）** | 已从核心网收到、但还没发给 UE 的 PDCP SDU；已发给 UE 但未收到确认的 PDCP SDU | 已经被 UE 确认接收的包 |
| **上行（UL）** | 源基站已成功收到、但还没传给核心网的上行 PDCP SDU | 已交给核心网的包 |
关键点：转发的单位是 **PDCP SDU**（业务数据单元），而不是 RLC 层的 PDU。这是因为 PDCP 是切换中"承上启下"的连续性承载点——RLC 层在切换后会在目标基站**重新建立**（reset），而 PDCP 层可以选择"继续"，这样才能保证上层应用看到的序号是连续的。
### 2.2 两条转发路径：直接 vs 间接
"转寄快递"有两条路可走，源基站会根据实际情况选择：
```mermaid
flowchart LR
A[源 gNB
Source gNB]
T[目标 gNB
Target gNB]
U[核心网 UPF]
UE[终端 UE]
subgraph 直接转发 [直接转发 Direct Forwarding]
A -->|Xn 接口
低延迟| T
end
subgraph 间接转发 [间接转发 Indirect Forwarding]
A2[源 gNB] -->|N3 隧道| U2[UPF 中转]
U2 -->|N9/N3 隧道| T2[目标 gNB]
end
T --> UE
T2 --> UE
```
**直接转发（Direct Forwarding）**：源基站通过 **Xn 接口**直接把数据交给目标基站。路径短、延迟低、不经过核心网。条件是两个基站之间有可用的 Xn 接口。这是最理想的路径，5G 同制式 gNB 间切换通常走这条。
**间接转发（Indirect Forwarding）**：源基站把数据先发给 **UPF（核心网用户面）**，再由 UPF 转给目标基站。路径长、延迟略高，但它"万能"——当两个基站之间没有 Xn 接口（比如跨厂商、跨区域未互联），或者**跨制式切换**（比如 5G NR 切到 4G LTE）时，只能通过核心网中转。
### 2.3 谁来决定走哪条路？
很多人以为是核心网决定的，其实不是。**转发方式由源基站在切换准备阶段自行决策**。源基站在发出切换请求（Handover Request）时，会评估：
- 我和目标基站之间有没有 Xn 接口？
- 这个 Xn 接口是否可用、负载如何？
- 这是不是一次跨制式切换？
据此选择直接或间接，并把"数据转发隧道信息"（forwarding TNL address，即转发用的传输层地址）告诉目标基站，建立起专用的转发隧道。
> **实战提示**：网络优化时，如果发现切换后丢包率高、时延大，第一步就要查**数据转发是否生效、走的是哪条路径**。一个常见问题是 Xn 接口虽然存在但配置异常，导致本应直接转发却退化为间接转发，增加了几十毫秒的额外时延。这类问题在 Xn 信令跟踪里能看到转发隧道的建立情况。
## 三、SN 状态转移：那张"已签收/未签收"清单
数据转发了，但光有数据还不够。想象目标基站收到了源基站转来的一堆包，它怎么知道：
- 哪些序号的包是 UE **已经收过**的（这些是冗余的，不该重发，否则乱序）？
- 哪些序号的包 UE **还没收到**（这些要优先发给 UE）？
- 下一个**新包**该用什么序号编号，才不会和 UE 已收到的包撞号？
- 加密用的 COUNT 值现在到哪了？
这些信息必须由源基站"交底"给目标基站，否则目标基站两眼一抹黑。这张"交底清单"就是 **SN Status Transfer（序列号状态转移）**。
### 3.1 清单里写了什么？
SN Status Transfer 是**针对每个 DRB（数据无线承载）** 分别传递的，核心内容如下表：
| 字段 | 含义 | 解决什么问题 |
|------|------|-------------|
| **DL COUNT value** | 下一个待发的下行 PDCP COUNT 值 | 目标基站知道该从哪个序号继续编号新包 |
| **HFN（超帧号）** | 序号回绕的高位计数 | 避免序号回绕时 COUNT 混淆，保证加密连续 |
| **UL Reception Status** | 上行已接收状态 | 告诉目标基站 UE 的哪些上行包源基站已收到 |
| **Missing SN bitmap** | 缺失上行序号位图 | 精确指出 UE 哪些上行包丢了，需要重传 |
这里要解释一个核心概念：**COUNT 值**。PDCP 的序号（SN）长度有限（比如 12 bit 或 18 bit），用完会回绕。光靠 SN 无法唯一标识一个包，所以引入 HFN（超帧号）作为高位，组合成 32 bit 的 COUNT：
$$\text{COUNT} = \text{HFN} \times 2^{\text{SN\_length}} + \text{PDCP\_SN}$$
COUNT 既用于排序，也用于**加密和完整性保护**的计数器输入。SN 状态转移把 COUNT 的当前值交给目标基站，意味着加密"密钥流"也能无缝衔接——这是为什么切换后你的加密数据还能被正确解密的根本原因。
### 3.2 这张清单何时递出？
这是 SN 状态转移最微妙的地方，也是工程师最容易搞错的地方：
**它不是在切换准备时就交，而是在 UE 已经成功接入目标基站之后才交。**
为什么这么晚？因为源基站必须确认 UE 真的"搬家成功"了。如果太早交，万一 UE 切换失败、又回到源基站，那源基站手里已经没有完整的 SN 状态了，会乱套。所以流程是：
```mermaid
sequenceDiagram
participant UE
participant S as 源 gNB
participant T as 目标 gNB
Note over S,T: ① 切换准备阶段
S->>T: Handover Request（切换请求）
T-->>S: Handover Request ACK（含转发隧道地址）
Note over S: 决定直接/间接转发
建立数据转发隧道
S->>UE: RRC Reconfiguration（切换命令）
Note over UE: ② 切换执行阶段：断开源，接入目标
Note over S,T: 此时数据转发已开始（DL 数据流向 T）
UE->>T: 随机接入 + RRC Reconfiguration Complete
Note over S,T: ③ 切换完成阶段
Note over T: UE 已成功接入！
T->>S: 此时源基站触发
S->>T: SN Status Transfer（关键：此刻才递清单）
Note over T: 收到清单后，开始有序下发/接收数据
T->>UE: 有序下发转发数据 + 新数据
```
注意上图的细节：**数据转发（搬数据）在切换准备完成后就开始了，但 SN 状态转移（交清单）要等 UE 接入目标基站后才发**。两者有时序差。这段时序差里，目标基站可以先把转来的数据"攒着"，但不能急着发——因为还不知道哪些是冗余的。直到收到 SN Status Transfer，目标基站才"心里有数"，开始按正确序号有序投递。
## 四、无损切换 vs 无损容忍：不是所有数据都一视同仁
到这里，聪明的读者可能有个疑问：**如果保证零丢包这么容易，为什么还要区分"无损切换"和"无损容忍切换"？**
答案在于**承载的 RLC 模式不同**。数据无线承载（DRB）的 RLC 层有两种工作模式，决定了切换的"服务质量承诺"：
| RLC 模式 | 工作机制 | 切换类型 | 应用场景 |
|---------|---------|---------|---------|
| **AM（确认模式）** | 通过 ARQ 重传保证可靠交付，有状态 | **无损切换（Lossless）** | 银行转账、文件下载、TCP 业务 |
| **UM（非确认模式）** | 不重传，强调低延迟 | **无损容忍切换（Loss-tolerant）** | VoIP 语音、视频流、实时游戏 |
### 4.1 无损切换（RLC AM）
对于 AM 承载，切换承诺**一个包都不丢**。机制是：
- 下行：源基站把"已发但未确认"的包也转发过去，目标基站根据 SN Status Transfer 知道哪些没被确认，会重新发给 UE；
- 上行：UE 会重传那些源基站没确认的包给目标基站；
- 目标基站做**按序投递（in-order delivery）**，收到乱序的包会先放进重排序缓冲，等齐了再往上交。
代价是：重排序会引入一点额外时延，但对 TCP 类业务来说，丢一个包要触发 TCP 重传，代价大得多，所以这点时延值得。
### 4.2 无损容忍切换（RLC UM）
对于 UM 承载（语音、视频），网络**不追求零丢包**，而追求**低延迟**。
- 不做按序投递（或重排序窗口很小），来一个发一个；
- 转发的数据量也更少——可能只转发最新的一小部分；
- 允许个别包丢失，因为语音业务丢几个包，编解码器能用补偿算法掩盖，但**绝不能让数据堆积产生几百毫秒时延**，那样对话就"串线"了。
这个设计哲学很深刻：**通信系统不是盲目追求"零丢包"，而是在"丢包率"和"时延"之间，针对不同业务做不同的权衡。** 语音宁可丢一点也不能慢，文件传输宁可慢一点也不能丢。数据转发和 SN 状态转移机制为两种模式都提供了"开关"，由承载的 QoS 配置决定用哪种姿态。
## 五、三剑客协同：数据转发 + SN转移 + 路径切换
理解了上面两块，我们就能看清切换防丢包的完整图景。它其实是三个机制的协同：
```mermaid
flowchart TB
subgraph A [机制一：数据转发 Data Forwarding]
A1[把源基站未交付的数据
搬到目标基站]
end
subgraph B [机制二：SN状态转移 SN Status Transfer]
B1[把序列号/COUNT 状态
同步给目标基站]
end
subgraph C [机制三：路径切换 Path Switch]
C1[让核心网把数据流
改道发往目标基站]
end
A -.保证有数据可发.-> Goal
B -.保证序号不乱.-> Goal
C -.保证后续路由正确.-> Goal
Goal[🎯 切换无缝、无丢失、无中断]
```
| 机制 | 解决的问题 | 如果缺失会怎样 |
|------|-----------|---------------|
| **数据转发** | UE 到新基站时"有数据可发" | 切换瞬间出现数据真空期，丢包 |
| **SN 状态转移** | 目标基站知道序号从哪续、哪些冗余 | 序号重复或空洞，乱序、重传、解密失败 |
| **路径切换** | 核心网把数据流改道到目标基站 | 核心网继续往源基站发，数据越积越多 |
三者缺一不可。一个完整的下行数据流时序是这样的：
1. **切换前**：核心网 → UPF → 源基站 → UE（正常下行）；
2. **切换准备**：建立源→目标的转发隧道；
3. **切换执行**：核心网的数据仍往源基站发，源基站同时往目标基站**转发**这部分数据；
4. **UE 接入目标**：源基站发 **SN Status Transfer**；
5. **路径切换**：目标基站通知核心网"数据改道发给我"，此后 UPF 直接 → 目标基站 → UE；
6. **转发收尾**：转发隧道里的存量数据发完后，拆除转发隧道，恢复正常的单条数据路径。
第 5 步**路径切换（Path Switch Request）** 是收尾动作，它让核心网的数据流"改道"。在它完成之前，核心网的数据是经过源基站"绕一圈"转发到目标基站的；完成后则是直达。这个"绕一圈"到"直达"的切换点，就是数据路径收敛的时刻。
## 六、COUNT、安全与连续性：那张清单的深层含义
前面提到 COUNT 用于加密。这里展开讲一个容易被忽略、但极其关键的点：**SN 状态转移不只是为了排序，更是为了安全连续性。**
5G 的空口数据加密和完整性保护，用的是基于 COUNT 的流密码。每次加密一个 PDCP 包，密钥流由"密钥 + COUNT 值"推导而来。一个铁律是：**同一个密钥下，同一个 COUNT 值绝不能被重复使用**，否则就会暴露密钥流，带来严重的安全漏洞（重用密钥流攻击）。
这就引出一个矛盾：切换后，目标基站要用同一个密钥继续加密。如果目标基站不知道源基站把 COUNT 用到哪了，从 0 重新开始，就会和源基站用过的 COUNT 撞车——安全崩溃。
所以 **SN Status Transfer 把 COUNT 的精确当前值传给目标基站**，目标基站从这里**继续往后用**，既保证了序号连续，又保证了密钥流不重复。一张"清单"，同时解决了排序和安全两个问题——这是系统设计的高明之处。
## 七、实战连接：工程师在哪里用到这些知识？
### 7.1 切换丢包问题排查
现网最常见的一类 KPI 异常是：**切换成功率正常，但切换时丢包率突增。** 这时候就要从数据转发和 SN 状态转移角度排查：
1. **看 Xn 接口配置**：如果 Xn 接口未建立或异常，会退化为间接转发（甚至 NG 切换不转发），时延增大。通过 Xn 链路状态检查确认。
2. **看转发隧道是否建立**：在 XnAP 信令里查找是否有 Data Forwarding 的 TNL Address 交互。没有则说明转发未生效。
3. **看 SN Status Transfer 是否及时**：跟踪该消息的发送时机和时延。如果它迟迟不发（比如源基站没及时收到 UE 接入目标的指示），目标基站会"持包不发"，表现为切换后短暂卡顿。
4. **看承载模式**：语音走 UM，本就有少量丢包设计，不要误判为故障；TCP 业务走 AM，丢包则需深究。
### 7.2 高铁/密集场景优化
在 1 秒内多次切换的高铁场景，数据转发的隧道频繁建立和拆除，会占用大量 Xn 带宽和基站内存。工程师需要评估转发缓冲大小、转发时长（定时器）配置，避免转发数据积压或过早丢弃。
### 7.3 跨制式切换的特殊性
5G↔4G 互操作时，由于没有直接的 Xn/S1-like 接口走直接转发，必须走间接转发（经 UPF/SGW）。工程师要意识到这种场景下时延更高，且 PDCP 版本不同（NR PDCP vs LTE PDCP），状态转移的处理也更复杂，是故障高发区。
## 八、一个常见误解：把"数据转发"等同于"无损"
最后澄清一个典型误区：**有数据转发 ≠ 无损切换。**
很多新人以为"只要配了数据转发，切换就不会丢包"。这是片面的。无损切换需要**数据转发 + SN 状态转移 + AM 承载的按序投递**三者同时成立。如果是 UM 承载，即便有数据转发，也允许少量丢包；如果 SN 状态转移缺失或延迟，即便转发了数据，也可能因序号混乱导致乱序丢弃。**机制是组合拳，不是单兵作战。**
另一个相关误区：以为 SN 状态转移和数据转发是同一回事。其实它们职责分明——**一个搬"数据"（货物），一个交"账本"（序号状态）**。货物可以先搬，账本后交；但账本交齐之前，货物不能乱发。理解了这层关系，才算真正读懂了切换的防丢包设计。
## 九、常见问题
**Q1：数据转发和 SN 状态转移，谁先谁后？**
A：**数据转发在前，SN 状态转移在后**。数据转发隧道在切换准备阶段就建好了，开始搬数据；但 SN 状态转移要等 UE 成功接入目标基站后，源基站才发出。原因是源基站必须确认 UE 真的搬家成功，才能把状态"交底"，否则若 UE 回退，源基站仍需持有完整状态。两者之间有时间差，目标基站会先攒着转来的数据，等收到清单再有序下发。
**Q2：直接转发和间接转发，什么时候各用哪个？**
A：优先用**直接转发**（源→目标 via Xn），它时延低、不经核心网，适用于有 Xn 接口的同制式 gNB 间切换。当两个基站间无 Xn 接口，或**跨制式切换**（如 5G→4G）时，必须用**间接转发**（源→UPF→目标）。转发方式由源基站在切换准备阶段自行决策。
**Q3：为什么语音业务切换时还会偶尔"咔"一下，不是说有无损切换吗？**
A：因为语音承载用的是 **RLC UM（非确认模式）**，走的是"无损容忍"切换，本来就不承诺零丢包。语音业务的设计哲学是**宁可丢几个包也不能让时延变大**——丢包靠语音编解码器补偿，但一旦数据积压产生几百毫秒时延，对话就会"串线"。所以偶尔一两声爆音是机制本身的取舍，不一定是故障。
**Q4：SN 状态转移和加密安全有什么关系？**
A：关系极大。5G 空口加密用的是基于 COUNT 值的流密码，**同一密钥下同一 COUNT 绝不能复用**，否则泄露密钥流。切换后目标基站沿用同一密钥，必须从源基站接续 COUNT 的精确当前值往后用，才能既保证序号连续、又保证密钥流不重复。所以 SN 状态转移同时解决了"排序连续"和"加密安全"两个问题。
**Q5：如果切换失败、UE 回退到源基站，转发的数据怎么办？**
A：这正是 SN 状态转移要"晚发"的原因——只要它还没发，源基站就还持有完整的 SN 状态和未确认数据。若 UE 回退，源基站可以继续用原有状态服务 UE，转发的数据被目标基站清理丢弃即可。系统通过这个时序设计，保证了切换失败的可恢复性。
## 参考来源
1. [5G SN Status Transfer | XnAP Message — 3glteinfo](https://www.3glteinfo.com/messages/5g/xnap/sn-status-transfer/) — 详细解释 XnAP SN Status Transfer 消息内容与 source-to-target PDCP 状态交接
2. [5G SA Inter gNB Handover - Xn Handover — Techplayon](https://www.techplayon.com/5g-sa-inter-gnb-hanodver-xn-handover/) — 完整的 Xn 切换信令流程，含 SN Status Transfer 的触发步骤
3. [5G Inter-gNB Handover - (Xn-based HO) and Data Forwarding — TelecomHall](https://www.telecomhall.net/t/5g-inter-gnb-handover-xn-based-ho-and-data-forwarding/28962) — 数据转发机制、直接/间接转发路径与隧道建立详解
4. [5G Handover — Devopedia](https://devopedia.org/5g-handover) — 5G 切换整体机制科普，含准备/执行/完成三阶段说明
5. [5G NR PDCP Reordering Explained — LinkedIn](https://www.linkedin.com/pulse/5g-nr-pdcp-reordering-explained-andrew-kolomatski-ukgoc) — PDCP 重排序与按序投递机制，理解无损切换的数据连续性基础
---
> 本文由「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 等场景全覆盖。
