第3轮原理科普 · 移动性管理专题
你正在边走边打视频电话，手机从A基站的覆盖区溜达到了B基站的覆盖区。如果切换做得不够好，画面会卡顿一两秒甚至直接掉线；如果做得好，你根本感觉不到基站换了人。今天我们要拆解的，就是5G里那条"最快、最常用"的切换路径——Xn切换，以及它凭什么能做到"无感"。
想象你长期在A快递站收包裹。某天你搬到B快递站附近去了，会发生什么？
这就是5G Xn切换的全部精髓，没有任何更复杂的东西。剩下要解决的工程问题只有三个：
把这三个问题想透，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切换在规范里被清晰地切成三段：准备（Preparation）、执行（Execution）、完成（Completion）。这种切分不是凑数，而是为了让"风险最高、对时延最敏感的动作"集中在中段，前后两端则尽量从容。
flowchart LR
subgraph 准备阶段[准备阶段 Preparation]
A1[UE 上报测量报告] --> A2[源gNB 决策切换]
A2 --> A3[源→目标 HO Request<br/>Xn接口]
A3 --> A4[目标gNB 准入控制]
A4 --> A5[目标→源 HO Request Ack<br/>携带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），必须尽量短；完成阶段是收尾，把核心网的隧道指向改过来、把旧资源清掉。
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几乎感觉不到中断。
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收到的包顺序会乱掉。这就引出了下一个机制。
为了让UE收到的下行包严格按序、上行包也不丢，源gNB在切换瞬间要把自己的"PDCP账本"抄一份给目标gNB，这就是 SN Status Transfer。
它传递的核心信息是两类序号状态：
Next PDCP TX SN），以及哪些包还没收到UE的确认（需要目标重传）。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做计数器，序号一错，整个加密链就断了。
UE在目标小区随机接入成功、回完RRC Reconfiguration Complete之后，它在无线侧已经"安家"了。但此时还有一个尾巴没收：核心网的下行N3隧道，还指向源gNB。新数据还在往老地址送。
目标gNB主动发起 Path Switch Request，走N2接口通知AMF："UE现在归我了，请把N3下行GTP隧道端点改到我这里。"AMF协调SMF/UPF执行隧道切换。切换完成后，UPF的下行数据直奔目标gNB，不再经过源gNB。
这里有两条原则值得记住：
设计巧思：为什么不让核心网"全程盯着"切换？因为核心网一旦深度介入，每多一个网元协调，就多一份时延和故障面。Xn切换把"无线侧自己能解决的事"全部留在gNB之间搞定，只在最后不得不动隧道时才惊动核心网一次。这就是"旁路核心网"四个字的全部含义——让该快的快、该省的省。
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（超可靠低时延）业务仍嫌偏大。这也是后续演进的动力。
移动性管理在R16/R17做了两次重要升级，都是为了"压低中断时间、提高切换成功率"。
条件切换（CHO, Conditional Handover） 针对的是高铁、覆盖边缘等"信号掉得太快"的场景。传统切换里，源gNB要等目标准备好、再把命令发给UE，这条链路如果中途信号骤降，命令都可能收不到，切换直接失败。CHO的做法是：源gNB提前把"如果满足某条件，就接入目标小区"的命令连同多个候选目标一起配给UE。UE收到后先不动，等到真正满足触发条件时，自己执行切换。它把"等待确认"变成了"满足即执行"，极大降低了命令丢失风险。代价是源gNB要把多份配置提前准备好，信令开销略增。
DAPS切换（Dual Active Protocol Stack） 则更激进：UE在切换的瞬间同时维持与源和目标两条链路，下行在两条腿上接收，直到确认目标稳定才断开源。这几乎把中断时间压到零（理论上接近无缝），但要求UE有两套收发能力，功耗和复杂度都高，多用于对可靠性极致要求的场景。
| 特性 | 传统Xn切换 | 条件切换CHO | DAPS切换 |
|---|---|---|---|
| 中断时间 | 毫秒级 | 毫秒级（成功率高） | 接近零 |
| 命令丢失风险 | 较高（边缘场景） | 低 | 低 |
| UE复杂度 | 低 | 中 | 高（双栈） |
| 适用场景 | 常规覆盖 | 高速/边缘/高铁 | 超可靠/URLLC |
理论落到现网，这几个点最常被拿来排查：
看切换走的是Xn还是N2：在信令跟踪里找 Handover Request/Path Switch Request（Xn）还是经过AMF转发的 Relocation 系列（N2）。如果一个本该走Xn的场景走了N2，多半是Xn接口没建起来、或邻区关系缺失（ANRF没配好），要查gNB之间的Xn链路状态。
切换掉话，看数据转发：如果UE切过去就卡顿，重点看源gNB有没有正确发起数据转发、SN Status有没有传递。抓Xn接口的GTP-U，确认转发包是否到达目标。常见陷阱：以为"切过去就有数据"，其实转发没做，UE等到新隧道建好才收到包，造成明显中断。
Path Switch超时：目标gNB发了Path Switch Request迟迟收不到响应，往往卡在SMF/UPF侧的会话管理。这时候问题不在无线侧，而在核心网。
End Marker没收到导致乱序：少数情况下，UPF的End Marker丢失或被丢弃，会导致目标gNB一直等转发数据、不敢交付新数据，表现为短暂卡顿后突然恢复。这是较隐蔽的坑。
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等特殊场景启用。
本文由「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 等场景全覆盖。