当你坐高铁刷视频、打电话，手机在几秒内换了三四个基站，画面却没卡、通话没断。这背后不是魔法，而是一套精密的"数据搬家"机制——数据转发（Data Forwarding） 与 序列号状态转移（SN Status Transfer）。今天我们拆解它，看看切换瞬间那几毫秒的"空窗期"里，网络到底做了什么，才让你的数据一个不丢。
想象你在搬家。老房子（源基站）和新房子（目标基站）之间，有一批快递（你的数据包）正在路上。如果搬家这一刻，你直接锁门走人，那正在路上的快递怎么办？两种可能：要么丢在老房子门口，要么送错了地方。
通信里的切换，本质上就是一次"搬家"，而"路上的快递"就是那些已经从核心网发到源基站、但还没来得及发给你（下行） 或者你已经发出去、但源基站还没收到确认（上行） 的数据包。
切换发生时，UE（终端）会从源基站断开、接入目标基站。这段断开的时间里：
如果什么都不做，每一次切换都会丢一批包。打 VoIP 电话时，丢包表现为几声"咔咔"的爆音；看视频时会卡顿一下；玩实时游戏会掉帧。这对 1Hz 频繁切换的高铁场景，是灾难性的。
所以网络设计了一套机制，专门解决这个"搬家丢快递"的问题。它的核心思想其实很朴素：在 UE 还没到新房子之前，就把老房子里的快递转寄过去，并且附上一张清单，告诉新房子的主人"这些我已经签收了，那些还没收到"。
这张"转寄"的动作叫数据转发，这张"清单"叫SN 状态转移。两者配合，才能实现真正的无损切换。
数据转发不是把所有数据都转发，那样太浪费带宽。源基站只会转发"还有价值"的数据：
| 方向 | 转发的内容 | 不转发的内容 |
|---|---|---|
| 下行（DL） | 已从核心网收到、但还没发给 UE 的 PDCP SDU；已发给 UE 但未收到确认的 PDCP SDU | 已经被 UE 确认接收的包 |
| 上行（UL） | 源基站已成功收到、但还没传给核心网的上行 PDCP SDU | 已交给核心网的包 |
关键点：转发的单位是 PDCP SDU（业务数据单元），而不是 RLC 层的 PDU。这是因为 PDCP 是切换中"承上启下"的连续性承载点——RLC 层在切换后会在目标基站重新建立（reset），而 PDCP 层可以选择"继续"，这样才能保证上层应用看到的序号是连续的。
"转寄快递"有两条路可走，源基站会根据实际情况选择：
flowchart LR
A[源 gNB<br/>Source gNB]
T[目标 gNB<br/>Target gNB]
U[核心网 UPF]
UE[终端 UE]
subgraph 直接转发 [直接转发 Direct Forwarding]
A -->|Xn 接口<br/>低延迟| 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）时，只能通过核心网中转。
很多人以为是核心网决定的，其实不是。转发方式由源基站在切换准备阶段自行决策。源基站在发出切换请求（Handover Request）时，会评估： - 我和目标基站之间有没有 Xn 接口？ - 这个 Xn 接口是否可用、负载如何？ - 这是不是一次跨制式切换？
据此选择直接或间接，并把"数据转发隧道信息"（forwarding TNL address，即转发用的传输层地址）告诉目标基站，建立起专用的转发隧道。
实战提示：网络优化时，如果发现切换后丢包率高、时延大，第一步就要查数据转发是否生效、走的是哪条路径。一个常见问题是 Xn 接口虽然存在但配置异常，导致本应直接转发却退化为间接转发，增加了几十毫秒的额外时延。这类问题在 Xn 信令跟踪里能看到转发隧道的建立情况。
数据转发了，但光有数据还不够。想象目标基站收到了源基站转来的一堆包，它怎么知道：
这些信息必须由源基站"交底"给目标基站，否则目标基站两眼一抹黑。这张"交底清单"就是 SN Status Transfer（序列号状态转移）。
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 的当前值交给目标基站，意味着加密"密钥流"也能无缝衔接——这是为什么切换后你的加密数据还能被正确解密的根本原因。
这是 SN 状态转移最微妙的地方，也是工程师最容易搞错的地方：
它不是在切换准备时就交，而是在 UE 已经成功接入目标基站之后才交。
为什么这么晚？因为源基站必须确认 UE 真的"搬家成功"了。如果太早交，万一 UE 切换失败、又回到源基站，那源基站手里已经没有完整的 SN 状态了，会乱套。所以流程是：
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: 决定直接/间接转发<br/>建立数据转发隧道
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，目标基站才"心里有数"，开始按正确序号有序投递。
到这里，聪明的读者可能有个疑问：如果保证零丢包这么容易，为什么还要区分"无损切换"和"无损容忍切换"？
答案在于承载的 RLC 模式不同。数据无线承载（DRB）的 RLC 层有两种工作模式，决定了切换的"服务质量承诺"：
| RLC 模式 | 工作机制 | 切换类型 | 应用场景 |
|---|---|---|---|
| AM（确认模式） | 通过 ARQ 重传保证可靠交付，有状态 | 无损切换（Lossless） | 银行转账、文件下载、TCP 业务 |
| UM（非确认模式） | 不重传，强调低延迟 | 无损容忍切换（Loss-tolerant） | VoIP 语音、视频流、实时游戏 |
对于 AM 承载，切换承诺一个包都不丢。机制是：
代价是：重排序会引入一点额外时延，但对 TCP 类业务来说，丢一个包要触发 TCP 重传，代价大得多，所以这点时延值得。
对于 UM 承载（语音、视频），网络不追求零丢包，而追求低延迟。
这个设计哲学很深刻：通信系统不是盲目追求"零丢包"，而是在"丢包率"和"时延"之间，针对不同业务做不同的权衡。 语音宁可丢一点也不能慢，文件传输宁可慢一点也不能丢。数据转发和 SN 状态转移机制为两种模式都提供了"开关"，由承载的 QoS 配置决定用哪种姿态。
理解了上面两块，我们就能看清切换防丢包的完整图景。它其实是三个机制的协同：
flowchart TB
subgraph A [机制一：数据转发 Data Forwarding]
A1[把源基站未交付的数据<br/>搬到目标基站]
end
subgraph B [机制二：SN状态转移 SN Status Transfer]
B1[把序列号/COUNT 状态<br/>同步给目标基站]
end
subgraph C [机制三：路径切换 Path Switch]
C1[让核心网把数据流<br/>改道发往目标基站]
end
A -.保证有数据可发.-> Goal
B -.保证序号不乱.-> Goal
C -.保证后续路由正确.-> Goal
Goal[🎯 切换无缝、无丢失、无中断]
| 机制 | 解决的问题 | 如果缺失会怎样 |
|---|---|---|
| 数据转发 | UE 到新基站时"有数据可发" | 切换瞬间出现数据真空期，丢包 |
| SN 状态转移 | 目标基站知道序号从哪续、哪些冗余 | 序号重复或空洞，乱序、重传、解密失败 |
| 路径切换 | 核心网把数据流改道到目标基站 | 核心网继续往源基站发，数据越积越多 |
三者缺一不可。一个完整的下行数据流时序是这样的：
第 5 步路径切换（Path Switch Request） 是收尾动作，它让核心网的数据流"改道"。在它完成之前，核心网的数据是经过源基站"绕一圈"转发到目标基站的；完成后则是直达。这个"绕一圈"到"直达"的切换点，就是数据路径收敛的时刻。
前面提到 COUNT 用于加密。这里展开讲一个容易被忽略、但极其关键的点：SN 状态转移不只是为了排序，更是为了安全连续性。
5G 的空口数据加密和完整性保护，用的是基于 COUNT 的流密码。每次加密一个 PDCP 包，密钥流由"密钥 + COUNT 值"推导而来。一个铁律是：同一个密钥下，同一个 COUNT 值绝不能被重复使用，否则就会暴露密钥流，带来严重的安全漏洞（重用密钥流攻击）。
这就引出一个矛盾：切换后，目标基站要用同一个密钥继续加密。如果目标基站不知道源基站把 COUNT 用到哪了，从 0 重新开始，就会和源基站用过的 COUNT 撞车——安全崩溃。
所以 SN Status Transfer 把 COUNT 的精确当前值传给目标基站，目标基站从这里继续往后用，既保证了序号连续，又保证了密钥流不重复。一张"清单"，同时解决了排序和安全两个问题——这是系统设计的高明之处。
现网最常见的一类 KPI 异常是：切换成功率正常，但切换时丢包率突增。 这时候就要从数据转发和 SN 状态转移角度排查：
在 1 秒内多次切换的高铁场景，数据转发的隧道频繁建立和拆除，会占用大量 Xn 带宽和基站内存。工程师需要评估转发缓冲大小、转发时长（定时器）配置，避免转发数据积压或过早丢弃。
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，转发的数据被目标基站清理丢弃即可。系统通过这个时序设计，保证了切换失败的可恢复性。
本文由「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 等场景全覆盖。