# Xn切换：旁路核心网的捷径
> 第3轮原理科普 · 移动性管理专题
你正在边走边打视频电话，手机从A基站的覆盖区溜达到了B基站的覆盖区。如果切换做得不够好，画面会卡顿一两秒甚至直接掉线；如果做得好，你根本感觉不到基站换了人。今天我们要拆解的，就是5G里那条"最快、最常用"的切换路径——**Xn切换**，以及它凭什么能做到"无感"。
## 一、从一个生活类比说起：搬家与改地址
想象你长期在A快递站收包裹。某天你搬到B快递站附近去了，会发生什么？
- **最笨的办法**：包裹照旧发到A站，A站再骑电动车给你送到B站附近。这样每件货都多绕一段路，A站也很累。
- **最聪明的办法**：你一搬完，立刻通知总部（核心网），"以后所有新货直接发到B站"。而A站那边**已经到货但还没派送的旧包裹**，用一条A→B的内部专线先转运过去，等你到了B站一起收。
这就是5G Xn切换的全部精髓，没有任何更复杂的东西。剩下要解决的工程问题只有三个：
1. **A站和B站怎么商量好这件事？**（切换准备）
2. **A站的存货怎么不丢地转运？**（数据转发）
3. **总部什么时候、由谁去通知改地址？**（路径切换 Path Switch）
把这三个问题想透，Xn切换的原理就吃透了90%。
## 二、为什么要有"两条"切换路径？
5G的基站间切换有两条路：**Xn切换**和**N2切换**（也叫NG切换）。很多人背得出定义，却说不清为什么非要搞两条。答案藏在"接口"这个最朴素的事实里。
两个基站之间能不能直接说话，取决于它们之间有没有拉一条叫 **Xn** 的专线。这条线是gNB与gNB之间的"对讲机"，专门用来传基站间的控制信令和转发数据。**不是任意两个基站之间都有Xn**——跨厂商、跨规划区域、或还没来得及配置邻区关系时，Xn链路可能根本不存在。
| 比较维度 | Xn切换 | N2切换（NG切换） |
|---|---|---|
| 协调主体 | 源/目标gNB直接协商 | AMF（核心网）居中协调 |
| 核心网是否参与准备阶段 | 否，全程不参与 | 是，AMF全程在场 |
| 信令时延 | 低（两跳直达） | 较高（绕核心网） |
| 数据转发 | gNB间直接转发（Xn） | 经UPF间接转发 |
| 适用场景 | 有Xn接口、同厂商同区域 | 无Xn接口、跨厂商、跨AMF区 |
| 规则中是否被"优先"选择 | 是，能走Xn就走Xn | 作为后备方案 |
网络设备有一条不成文的优先级原则：**能用Xn，就不用N2**。原因很简单——少一跳、少一个需要协调的网元，时延就更低，出故障的概率也更小。N2切换更像是"兜底方案"，专门处理那些Xn够不着的情况。
## 三、Xn切换的三阶段全景
一次完整的Xn切换在规范里被清晰地切成三段：**准备（Preparation）、执行（Execution）、完成（Completion）**。这种切分不是凑数，而是为了让"风险最高、对时延最敏感的动作"集中在中段，前后两端则尽量从容。
```mermaid
flowchart LR
subgraph 准备阶段[准备阶段 Preparation]
A1[UE 上报测量报告] --> A2[源gNB 决策切换]
A2 --> A3[源→目标 HO Request
Xn接口]
A3 --> A4[目标gNB 准入控制]
A4 --> A5[目标→源 HO Request Ack
携带HO命令]
end
subgraph 执行阶段[执行阶段 Execution]
B1[源gNB 下发HO命令给UE] --> B2[数据转发+SN状态传递]
B2 --> B3[UE 在目标小区随机接入]
end
subgraph 完成阶段[完成阶段 Completion]
C1[UE 发送完成消息] --> C2[目标gNB 发起Path Switch]
C2 --> C3[UPF 切换N3下行隧道]
C3 --> C4[源gNB 释放UE上下文]
end
准备阶段 --> 执行阶段 --> 完成阶段
```
为什么要这么切？因为**准备阶段**所有动作都发生在网络内部（gNB之间），UE完全不知情，可以慢慢来；**执行阶段**是UE真正"断开旧基站、接入新基站"的窗口，此时UE有一段时间收不到下行数据，这就是所谓的**切换中断时间（Interruption Time）**，必须尽量短；**完成阶段**是收尾，把核心网的隧道指向改过来、把旧资源清掉。
```mermaid
sequenceDiagram
participant UE
participant Src as 源gNB
participant Tgt as 目标gNB
participant AMF
participant UPF
Note over UE,Src: === 准备阶段 ===
UE->>Src: 测量报告 Measurement Report
Src->>Tgt: Xn: Handover Request（含UE上下文）
Note over Tgt: 准入控制 / 资源分配
Tgt->>Src: Xn: Handover Request Acknowledge（含HO Command）
Note over UE,Tgt: === 执行阶段 ===
Src->>UE: RRC Reconfiguration（切换命令）
Src->>Tgt: Xn: 数据转发（DL PDCP SDU）
Src->>Tgt: Xn: SN Status Transfer
Note over UE: 断开源小区，接入目标小区
UE->>Tgt: 随机接入 RACH + RRC Reconfig Complete
Note over UE,UPF: === 完成阶段 ===
Tgt->>AMF: N2: Path Switch Request
AMF->>UPF: 切换N3下行GTP隧道端点
UPF->>Src: End Marker（旧隧道终止）
Src->>Tgt: 转发End Marker
AMF->>Tgt: N2: Path Switch Request Acknowledge
Tgt->>Src: Xn: UE Context Release
```
这张时序图建议你存下来反复看——后面每一节，都是在拆解这张图里某一条箭头的"为什么"。
## 四、准备阶段：两个基站怎么"私底下"商量好
切换的扳机来自UE上报的**测量报告**。当邻区信号强过服务小区达到一定阈值（比如经典的A3事件：邻区比服务小区高一个偏移量），源gNB心里就有了"该换基站了"的念头。
但源gNB不能自作主张把UE一脚踢过去，它得先问目标gNB："我这边有个用户要过来，QoS要求这么高、安全参数是这些、无线承载有几个，你接得住吗？"——这就是 **Handover Request**，走Xn接口，**核心网AMF完全不知情**。
目标gNB收到后做一件关键的事：**准入控制（Admission Control）**。它要算算自己还有没有足够的PRB（物理资源块）、有没有空闲的DRB承载、空口调度拥不拥挤。如果接得住，就分配资源，并把"UE该怎么接入我"的所有参数（目标小区C-RNTI、随机接入前导、安全算法、新配置）打包进 **Handover Request Acknowledge** 里的RRC容器，回给源gNB。
> **设计巧思**：注意目标gNB给UE的接入命令，是**装在ACK里、由源gNB转发给UE**的。为什么不让目标gNB直接发给UE？因为此刻UE还和源gNB连着、还不知道目标在哪。让源gNB"代转"这条命令，是唯一不需要UE提前跳槽就能完成的办法。这就是工程上的妥协——用一次转发，换来UE全程不脱网。
到这里，准备阶段结束。此时UE**尚未移动**，但它未来的"新家"已经被目标gNB布置好了，连钥匙（接入参数）都准备好了。
## 五、执行阶段：数据转发——切换不丢包的灵魂
现在进入风险最高的阶段。源gNB把切换命令（RRC Reconfiguration）发给UE，UE开始转向目标小区。**就在UE断开源、接入目标的这个窗口里，下行数据还在源源不断从核心网涌向源gNB**。如果什么都不做，这些包就会在源gNB堆积、最终丢弃——这就是传统切换丢包的根源。
数据转发（Data Forwarding）就是为解决这件事而生的。源gNB把**还没成功发给UE的下行PDCP SDU**，通过Xn接口直接送到目标gNB缓存起来。等UE一接入目标，这些"接力赛下一棒"的数据立刻就能下发，UE几乎感觉不到中断。
```mermaid
flowchart TB
subgraph 源gNB
S1[从核心网收到的下行包]
S2[已发给UE并确认的包]
S3[未确认/未发送的包]
end
S1 --> S2
S1 --> S3
S3 -->|Xn 数据转发| T1[目标gNB 缓存]
T1 --> T2[按序下发给UE]
UPF[UPF 新数据] -.N3新隧道.-> T1
```
但光把包转过去还不够，有个棘手的"顺序问题"。试想：源gNB转发的旧包序号是 5、6、7，而UE接入目标后，核心网新发来的包序号已经是 10、11、12了（因为路径切换前源gNB可能还在收）。如果不加管理，UE收到的包顺序会乱掉。这就引出了下一个机制。
## 六、SN Status Transfer：无损切换的"账本"
为了让UE收到的下行包**严格按序**、上行包也不丢，源gNB在切换瞬间要把自己的"PDCP账本"抄一份给目标gNB，这就是 **SN Status Transfer**。
它传递的核心信息是两类序号状态：
- **DL：** 源gNB下一个该发的下行PDCP序号（`Next PDCP TX SN`），以及哪些包还没收到UE的确认（需要目标重传）。
- **UL：** 源gNB期望收到的下一个上行序号（`Next PDCP RX SN`），以及哪些上行包还没收齐（避免目标重复交付）。
有了这本账，目标gNB就知道：转发来的旧包从几号开始发、新包该从几号接续、上行重传窗口在哪。这就保证了 **PDCP层的按序交付（in-sequence delivery）**，是5G声称"无损切换"的数学根基。
PDCP序号的生成有一个简洁的公式，把"短序号"和"长超帧号"拼起来避免回绕：
$$
\text{COUNT} = \text{HFN} \times 2^{\text{SN\_Length}} + \text{PDCP\_SN}
$$
其中HFN（Hyper Frame Number）是超帧号，SN是实际的PDCP序号。SN Status Transfer传递的本质，就是把这个COUNT值的"游标"位置同步给目标gNB，让加密、完整性保护、按序交付都能无缝衔接——**因为安全也依赖COUNT做计数器，序号一错，整个加密链就断了**。
## 七、完成阶段：Path Switch——告诉核心网"改地址"
UE在目标小区随机接入成功、回完RRC Reconfiguration Complete之后，它在无线侧已经"安家"了。但此时还有一个尾巴没收：**核心网的下行N3隧道，还指向源gNB**。新数据还在往老地址送。
目标gNB主动发起 **Path Switch Request**，走N2接口通知AMF："UE现在归我了，请把N3下行GTP隧道端点改到我这里。"AMF协调SMF/UPF执行隧道切换。切换完成后，UPF的下行数据直奔目标gNB，不再经过源gNB。
这里有两条原则值得记住：
1. **Path Switch由目标gNB发起**，不是源gNB。因为切换成功的"知情者"只有目标gNB。
2. **只改N3这一侧的隧道端点**，UPF往上（N9/N6到数据网络）那一侧完全不动。对互联网来说，UE的IP地址、PDU Session一点没变，业务完全无感。
> **设计巧思**：为什么不让核心网"全程盯着"切换？因为核心网一旦深度介入，每多一个网元协调，就多一份时延和故障面。Xn切换把"无线侧自己能解决的事"全部留在gNB之间搞定，只在最后**不得不动隧道时**才惊动核心网一次。这就是"旁路核心网"四个字的全部含义——**让该快的快、该省的省**。
## 八、End Marker：转发结束的一声哨
Path Switch切换隧道后，会出现一个微妙的时间差：UPF已经开始往目标gNB发新数据了，但**源gNB手里还攥着切换前最后那一批包**，正通过Xn往目标转发。目标gNB怎么知道"转发结束了、可以开始按新隧道的数据排序了"？
答案是一个特殊的标记帧——**End Marker**。UPF在切换完N3隧道后，会往**旧隧道**（通往源gNB）发一个或多个GTP-U End Marker包。源gNB收到后照常把它转发给目标gNB。目标gNB一看到End Marker，就知道：**"这条转发链到此为止，后面来的都是新隧道的数据了。"** 于是它把之前缓存的、转发的、按序排好的数据一次性交付，然后无缝接上新数据。
```
UPF ──旧N3隧道──> 源gNB ──Xn转发──> 目标gNB ──┐
│ 按序交付给UE
UPF ──新N3隧道──────────────────────> 目标gNB ─┘
↑End Marker标记旧隧道结束的边界
```
End Marker的妙处在于：它用"一个数据帧"优雅地解决了**两条数据流交汇点的同步问题**，而不是靠额外的信令去协商。这种"用数据本身携带控制语义"的设计，在网络协议里反复出现（比如TCP的FIN），是工程美学的体现。
## 九、切换中断时间的极限在哪里
对工程师来说，最关心的指标是**切换中断时间（Handover Interruption Time）**——UE多久收不到下行数据。传统Xn切换的中断主要花在：
$$
T_{interrupt} \approx T_{RRC\_proc} + T_{search} + T_{RA} + T_{sched}
$$
分别是处理切换命令、搜索目标小区、随机接入、首次调度的时间。典型值在十毫秒量级，对语音和视频基本无感，但对URLLC（超可靠低时延）业务仍嫌偏大。这也是后续演进的动力。
## 十、进阶：当Xn切换还不够快——CHO与DAPS
移动性管理在R16/R17做了两次重要升级，都是为了"压低中断时间、提高切换成功率"。
**条件切换（CHO, Conditional Handover）** 针对的是高铁、覆盖边缘等"信号掉得太快"的场景。传统切换里，源gNB要等目标准备好、再把命令发给UE，这条链路如果中途信号骤降，命令都可能收不到，切换直接失败。CHO的做法是：**源gNB提前把"如果满足某条件，就接入目标小区"的命令连同多个候选目标一起配给UE**。UE收到后先不动，等到真正满足触发条件时，自己执行切换。它把"等待确认"变成了"满足即执行"，极大降低了命令丢失风险。代价是源gNB要把多份配置提前准备好，信令开销略增。
**DAPS切换（Dual Active Protocol Stack）** 则更激进：UE在切换的瞬间**同时维持与源和目标两条链路**，下行在两条腿上接收，直到确认目标稳定才断开源。这几乎把中断时间压到零（理论上接近无缝），但要求UE有两套收发能力，功耗和复杂度都高，多用于对可靠性极致要求的场景。
| 特性 | 传统Xn切换 | 条件切换CHO | DAPS切换 |
|---|---|---|---|
| 中断时间 | 毫秒级 | 毫秒级（成功率高） | 接近零 |
| 命令丢失风险 | 较高（边缘场景） | 低 | 低 |
| UE复杂度 | 低 | 中 | 高（双栈） |
| 适用场景 | 常规覆盖 | 高速/边缘/高铁 | 超可靠/URLLC |
## 十一、调试实战：工程师在哪里会用到这些
理论落到现网，这几个点最常被拿来排查：
1. **看切换走的是Xn还是N2**：在信令跟踪里找 `Handover Request`/`Path Switch Request`（Xn）还是经过AMF转发的 `Relocation` 系列（N2）。如果一个本该走Xn的场景走了N2，多半是Xn接口没建起来、或邻区关系缺失（ANRF没配好），要查gNB之间的Xn链路状态。
2. **切换掉话，看数据转发**：如果UE切过去就卡顿，重点看源gNB有没有正确发起数据转发、SN Status有没有传递。抓Xn接口的GTP-U，确认转发包是否到达目标。**常见陷阱**：以为"切过去就有数据"，其实转发没做，UE等到新隧道建好才收到包，造成明显中断。
3. **Path Switch超时**：目标gNB发了Path Switch Request迟迟收不到响应，往往卡在SMF/UPF侧的会话管理。这时候问题不在无线侧，而在核心网。
4. **End Marker没收到导致乱序**：少数情况下，UPF的End Marker丢失或被丢弃，会导致目标gNB一直等转发数据、不敢交付新数据，表现为短暂卡顿后突然恢复。这是较隐蔽的坑。
## 十二、几个常被混淆的概念
- **Xn切换 ≠ 全程不碰核心网**。准备和执行阶段确实旁路了AMF，但完成阶段必须通过N2做Path Switch，否则下行隧道永远指错。
- **数据转发 ≠ 永久转发**。它只在"路径切换前后"的过渡期存在，End Marker一到就结束。
- **Path Switch ≠ 改PDU Session**。只动N3这一跳，UE的IP和数据网络侧全不变。
- **SN Status Transfer ≠ 只传序号**。它隐含传递了**安全上下文的游标**，是加密链不断的关键。
## 常见问题
**Q1：为什么网络"优先"选Xn切换而不是N2？**
A：因为Xn切换在准备和执行阶段完全不经过核心网，信令只走gNB之间的Xn接口，少一跳、少一个协调网元，时延更低、出故障面更小。N2切换要AMF居中协调，时延和信令开销都更大，是Xn不可用时的兜底。
**Q2：UE怎么知道该往哪个基站切？**
A：靠测量报告。UE持续测量服务小区和邻区的信号质量（RSRP/RSRQ），当邻区满足A3/A5等事件触发条件时上报，源gNB据此决策。目标gNB的选择由源gNB根据测量结果和邻区关系决定，不是UE自己挑。
**Q3：数据转发是必须的吗？不转会怎样？**
A：不强制，但不用就会丢包。如果不做数据转发，源gNB在切换瞬间丢弃所有未发送的下行包，等新隧道建好才能继续。对TCP业务会触发重传，对实时语音/视频就是可感知的卡顿甚至花屏。所以现网几乎都开。
**Q4：End Marker如果丢了怎么办？**
A：理论上目标gNB会一直等。实际实现里有**保护定时器**：超过一定时间没收到End Marker，目标gNB会主动结束转发流程、开始交付新数据。代价是这批转发的尾部数据可能与新数据存在轻微乱序，交给上层（如TCP）重排。这是工程上"宁可轻微乱序，也不能永久卡死"的取舍。
**Q5：CHO和DAPS会让Xn切换被淘汰吗？**
A：不会。CHO/DAPS都是Xn切换的**增强**，依然跑在Xn/N2接口上，只是改了"何时下发命令、是否维持双链"。传统Xn切换仍是绝大多数场景的主力，CHO/DAPS只在高铁、URLLC等特殊场景启用。
## 参考来源
1. [Introduction of Xn and NG (N2) based handover — free5GC](https://free5gc.org/blog/20251105/20251105/) — 开源5G核心网项目对Xn与N2切换路径的对比说明，含call flow。
2. [5G SA Inter gNB Handover - Xn Handover — Techplayon](https://www.techplayon.com/5g-sa-inter-gnb-hanodver-xn-handover/) — 完整的Xn切换信令流程与call flow图解。
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 NR Handover Procedure — Xn and N2 Handover — ranbits.com](https://ranbits.com/module12/12-1-handover.html) — 两条切换路径的选择逻辑与流程对比。
5. [End Marker in 5G Data Network — IETF](https://www.ietf.org/archive/id/draft-zzhang-dmm-5gdn-end-marker-00.html) — End Marker帧在转发结束判定中的作用机制。
6. [Conditional Handover in 5G: Principles, Future Use Cases and FR2 Performance — arXiv](https://arxiv.org/abs/2204.01283v1) — 条件切换CHO的原理、用例与高频段性能分析。
---
> 本文由「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 等场景全覆盖。
