在5G SA网络中，UE从一个gNB移动到另一个gNB时，最常见、也是时延最短的站间切换方式就是基于Xn接口的切换（Xn-based Handover）。它对应3GPP TS 23.502 Section 4.9.1.2。与需要AMF全程参与的N2（NGAP）切换不同，Xn切换在准备阶段完全不经过核心网，源gNB直接通过Xn-C接口向目标gNB申请资源，核心网只在切换成功后做一次"路径切换"（Path Switch）。这种设计把切换的关键路径压到最短，是5G实现毫秒级移动性的基石。
本文以TS 23.502 4.9.1.2为主线，结合TS 38.423（XnAP）、TS 38.413（NGAP）、TS 38.300（NG-RAN整体描述）和TS 38.331（RRC），逐条消息、逐个关键IE拆解Xn切换的完整信令流，并解释每个机制背后的设计意图。
Xn切换不是想用就能用，它有一组严格的前置条件（TS 23.502 4.9.1.2、TS 38.300 9.2.3.2）。理解这些前提，才能理解"为什么UE有时走Xn、有时被迫走N2"。
| 前置条件 | 说明 | 不满足时的后果 |
|---|---|---|
| Xn接口已建立 | 源、目标gNB之间Xn-C（SCTP）和Xn-U（GTP-U）链路均UP | 必须走N2/NGAP切换 |
| 同一AMF服务区 | 源、目标gNB连到同一个AMF | 走N2切换（涉及AMF重选） |
| PDU会话的UPF不变 | 目标gNB可达原UPF，无需插入I-UPF或重选PSA | 走N2切换或UPF重选流程 |
| 移动限制允许 | UE的RFSP/订阅不禁止目标小区 | 切换被拒，UE驻留原小区 |
| 切换类型匹配 | 可为intra-frequency或inter-frequency HO | 不影响是否走Xn |
一个常被忽视的细节：Xn切换本身允许源、目标gNB连接到不同的UPF——只要这些UPF对当前UE而言是可达的、无需重选锚点。真正禁止Xn切换的是"AMF变更"和"UPF重选（PSA change）"。这也是为什么TAC跨区时UE切换后可能触发一次移动性注册更新——TAC变化不影响Xn切换本身，但需要在切换完成后补登记。
下图给出一次成功的Xn切换从测量到资源释放的全过程（对应TS 23.502 4.9.1.2 Figure 4.9.1.2.2-1的核心步骤）。
sequenceDiagram
autonumber
participant UE
participant Src as 源gNB
participant Tgt as 目标gNB
participant AMF
participant UPF
Note over UE,Src: 步骤0: UE在源小区RRC_CONNECTED收发数据
UE->>Src: RRC MeasurementReport（含邻区PCI/RSRP）
Note over Src: 切换判决:选目标gNB，确认Xn可用、同AMF
Src->>Tgt: XnAP Handover Request（UE上下文+RRC容器+PDU会话列表）
Note over Tgt: 准入控制、分配资源、生成HO Command
Tgt-->>Src: XnAP Handover Request Acknowledge（HO Command容器+准入QoS流+转发地址）
Src->>UE: RRCReconfiguration（含reconfigurationWithSync：目标PCI、新C-RNTI、安全算法、专用RACH）
Src->>Tgt: XnAP SN Status Transfer（UL/DL PDCP SN与HFN）
Note over Src,UPF: 源gNB缓存UPF下行数据，经Xn-U转发到目标gNB
UE->>Tgt: RACH（专用preamble）+ RRCReconfigurationComplete
Note over UE,Tgt: UE上行数据开始发往目标gNB
Tgt->>AMF: NGAP Path Switch Request（待切换PDU会话列表+新N3上行TEID）
AMF->>UPF: Nsmf_PDUSession_UpdateSMContext（切换下行N3到目标）
UPF-->>Src: End Marker（旧下行路径终结）
Src-->>Tgt: End Marker（转发，标识转发数据流结束）
UPF-->>Tgt: 下行数据（新N3路径）
AMF-->>Tgt: NGAP Path Switch Request Acknowledge（已切换会话+UPF新下行TEID）
Tgt->>Src: XnAP UE Context Release
Note over Src: 源gNB释放UE上下文与无线/传输资源
整条流程可以划分为三个清晰阶段：① 准备阶段（步骤1–3，纯Xn交互，不碰核心网）；② 执行阶段（步骤4–7，UE实际跳转、SN状态与数据转移）；③ 完成阶段（步骤8–10，核心网路径切换与源侧清理）。三阶段的解耦是Xn切换时延优势的根源——准备阶段省掉了N2切换里"AMF→目标gNB"这段往返。
UE周期性或事件触发上报测量结果。Xn切换最常见的触发事件是A3事件（邻区质量优于服务小区偏移量）。MeasurementReport中关键的量是：
measResults.measId：标识哪个测量对象/配置measResultServingMOList：服务小区RSRP/RSRQ/SINRmeasResultNeighCells：邻区physCellId（PCI）与测量量源gNB用PCI经自身维护的邻区关系表（NRT）解析出目标gNB的Global gNB ID和Xn传输层地址，这是发起Xn切换的物理依据。若NRT里没有对应Xn链路，源gNB只能回退到N2切换。
这是源gNB向目标gNB"请求准入"的核心消息，也是Xn切换里IE最丰富的消息。其逻辑结构如下图：
flowchart LR
HReq["XnAP Handover Request"] --> A1["Message ID (5)"]
HReq --> A2["UE XnAP ID pair"]
HReq --> A3["Target Cell ID"]
HReq --> Ctx["UE Context Info"]
Ctx --> C1["UE Security Capabilities<br/>(NR/E-UTRA算法位图)"]
Ctx --> C2["Security Key<br/>(NH/KeNB派生)"]
Ctx --> C3["UE-AMBR"]
Ctx --> C4["UE History Information<br/>(最近访问小区列表)"]
Ctx --> C5["UE Radio Capability"]
HReq --> RRC["RRC Container<br/>(HandoverPreparationInformation)"]
HReq --> PS["PDU Session Resources<br/>To Be Setup List"]
PS --> P1["PDU Session ID + S-NSSAI"]
PS --> P2["PDU Session Type"]
PS --> P3["UL NG-U TNL Info<br/>(原上行N3隧道)"]
PS --> P4["QoS Flow List<br/>(QFI + 5QI + GBF/MBF)"]
PS --> P5["Data Forwarding<br/>Info Request"]
几个IE的设计意图值得展开：
UE Security Capabilities（TS 33.501）：位图形式告知目标gNB UE支持哪些加密/完整性算法（如NEA0–NEA3、NIA0–NIA3）。目标gNB据此选择算法并派生新的KgNB，保证切换后空口密钥前向更新，防止源gNB窃听切换后流量。
UE History Information（TS 36.413/38.423 SON机制）：包含UE最近访问的小区列表（含每小区停留时间、PCI、全局ID）。这是5G移动性优化（MRO）和最小化路测（MDT）的数据来源——目标gNB据此识别"乒乓切换""过早切换"等异常。
PDU Session Resources To Be Setup List：逐PDU会话列出QoS流。每个QoS流携带QoS Flow Level QoS Parameters（5QI、ARP、GBR/MBR）。目标gNB做准入控制（Admission Control）时，就是基于这些参数判断空口资源是否够分配。注意这里携带的是源gNB侧的上行NG-U TNL信息（即原N3隧道地址），供目标gNB理解旧路径。
RRC Container（HandoverPreparationInformation）：源gNB把UE当前的完整AS配置（测量配置、DRB/SRB配置、安全配置、UE无线能力）打包成透明容器发给目标gNB。目标gNB据此重建一份尽可能连续的配置，最大限度减少空口重配量——这就是"无缝切换"在协议层的体现。
源gNB发送此消息时启动定时器TXnRELOCprep（Xn切换准备定时器），超时未收到Acknowledge即判准备备失败。
目标gNB准入成功后回此消息，核心是两个东西：
reconfigurationWithSync配置，包含目标小区PCI、新分配的C-RNTI、所选安全算法、专用RACH资源（rach-ConfigDedicated）。这个容器对源gNB透明，源gNB直接塞进发给UE的RRCReconfiguration里。PDU Session Resources Admitted List（成功准入的QoS流及目标侧新上行NG-U TNL地址）和Failed to Setup List（拒绝的会话/流）。如果目标gNB全部拒绝，则回Handover Preparation Failure，源gNB需重新选目标或回退N2切换。
源gNB向UE下发切换命令。reconfigurationWithSync是UE接入目标小区的全部信息：目标PCI、新C-RNTI、spCellConfigCommon（目标系统消息关键参数）、rach-ConfigDedicated（专用前导码，避免竞争）。UE收到后即"指令式"执行，不再回到源小区协商——这是5G切换"硬切换+无竞争接入"的设计。
发送此消息时源gNB启动TXnRELOCoverall（整体切换定时器）。
这是Xn切换保证数据无损、按序的关键消息，下一节专门拆解。
UE成功接入目标gNB（RRCReconfigurationComplete）后，目标gNB向AMF发此消息，触发核心网把下行N3隧道从源gNB改到目标gNB。关键IE：
Path Switch Request TransferIE，内含目标gNB侧新的上行N3 TEID（UPF要往这里发下行数据）。AMF收到后调SMF，SMF指示UPF切换下行路径。UPF在新路径首发数据前，先在旧下行路径发End Marker。
AMF回确认，携带：
至此N3双向路径全部切到目标gNB，核心网对UE的"服务锚点"完成迁移（UPF不变，只是N3端点变了）。
目标gNB收到Path Switch Acknowledge后，向源gNB发此消息，源gNB才正式释放该UE的上下文和无线/传输资源。源gNB在收到此消息前，必须保留UE上下文，以便在切换失败时回滚或继续转发数据。
flowchart TD
subgraph 无损转发机制
S1["源gNB停止向UE下发行<br/>(对full bearer)"] --> S2["源gNB发 SN Status Transfer"]
S2 --> S3["Target获取: 下一个期望UL PDCP SN<br/>+ 下一个待发DL PDCP SN + HFN"]
S3 --> S4["源gNB经Xn-U转发缓存DL数据"]
S4 --> S5["Target重排序: 转发数据 + UPF新数据"]
S5 --> S6["UE上行按序重传缺失PDCP SDU"]
end
SN Status Transfer消息（TS 38.423）针对每个需要按序交付（in-order delivery）的DRB（通常是RLC AM模式的full bearer）携带两组计数器：
设计意图有三层：
关键陷阱：若承载被配置为DAPS（Dual Active Protocol Stack）切换（Rel-16引入），UE在切换期间同时维持与源、目标的连接，SN Status Transfer与数据转发的时序会更复杂——源gNB会持续向UE发送下行数据直到收到UE的UL DAPS HO完成指示。
Xn切换支持两种下行数据转发路径：
| 转发类型 | 路径 | 适用场景 |
|---|---|---|
| Direct Forwarding | 源gNB →（Xn-U）→ 目标gNB | 源、目标gNB间有Xn-U，最常用 |
| Indirect Forwarding | 源gNB →（N9）→ UPF →（N9）→ 目标gNB | Xn-U不可用或跨PLMN，需SMF协调并启动定时器释放 |
间接转发由SMF在Path Switch阶段为源gNB分配转发隧道，并启动一个定时器（TS 23.502 4.9.1.2.2 step 16），定时器到点后SMF释放间接转发隧道。直接转发则无需核心网介入，靠源、目标gNB自行通过Xn-U收发，转发数据流以End Marker作为终结标志：UPF切路径后向源gNB发End Marker，源gNB转发给目标gNB，目标gNB收到后即知"转发数据已全部送达，后续都是UPF直发的新数据"，可停止等待、按序flush缓冲区。
flowchart TD
Start["源gNB收到测量报告<br/>判决切换"] --> Q1{源-目标间<br/>Xn可用?}
Q1 -- 否 --> N2["回退 N2/NGAP 切换<br/>(AMF全程参与)"]
Q1 -- 是 --> Q2{同一AMF<br/>服务区?}
Q2 -- 否 --> N2
Q2 -- 是 --> Q3{PDU会话UPF<br/>无需重选?}
Q3 -- 否 --> N2
Q3 -- 是 --> Xn["执行 Xn 切换<br/>(准备阶段不过核心网)"]
| 维度 | Xn切换（4.9.1.2） | N2/NGAP切换（4.9.1.3） |
|---|---|---|
| 准备阶段信令路径 | 源gNB ↔ 目标gNB（Xn-C） | 源gNB → AMF → 目标gNB（N2） |
| 核心网参与时机 | 仅Path Switch阶段 | 准备、执行、完成全程 |
| 典型时延 | 低（准备阶段省N2往返） | 较高 |
| AMF可否变更 | 否（intra-AMF） | 可（inter-AMF） |
| UPF可否重选 | 否 | 可 |
| 何时被迫使用 | — | 无Xn链路、跨AMF、需UPF重选 |
Xn切换是性能优先的默认选择，N2切换是兼容性兜底。现网中，运营商通过ANR（自动邻区关系）功能尽量建立Xn链路，让绝大多数站间切换走Xn路径。
在Wireshark中开启XnAP和NGAP解析，一次Xn切换的关键识别特征：
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| Handover Preparation Failure | 目标gNB准入拒绝（资源不足）、安全算法不匹配、QoS流无法满足 | 查目标gNB日志的拒绝原因值（Cause IE） |
| 准备成功但UE切换后掉话 | SN Status Transfer丢失导致UL/DL PDCP SN错乱；专用RACH资源冲突 | 比对源、目标gNB的PDCP计数器；查RACH日志 |
| 切换后下行数据中断 | Path Switch Request被拒、UPF未及时切路径、End Marker未到 | 查NGAP Path Switch Acknowledge是否成功；抓N3看End Marker |
| 切换后UE发起注册更新 | 跨TAC（正常）或AMF区（异常，应走N2） | 查UE当前TAI与切换前TAI |
| 乒乓切换 | A3迟滞/触发时间设置过激进、邻区关系错误 | 结合UE History Information分析MRO |
| ## 常见问题 |
Q1: Xn切换和N2切换怎么从抓包上一眼区分？ A: 看准备阶段是否有NGAP消息。Xn切换准备阶段只有XnAP（Handover Request/Acknowledge），核心网第一条相关消息是执行后的Path Switch Request；N2切换准备阶段会有NGAP的Relocation Request/Command经AMF转发。另外Xn切换里目标gNB不向AMF发Handover Notify。
Q2: SN Status Transfer如果丢失会怎样？ A: 对RLC AM承载，会导致目标gNB的PDCP SN起点错误，可能引发重复计数或计数跳变，UE侧PDCP去重/重排异常，表现为切换后下行卡顿或丢包，严重时掉话。协议要求源gNB在停止该承载下行发送后立即发送，Xn-C基于SCTP保证可靠传输，正常不应丢失。
Q3: 为什么TAC变了还能走Xn切换？ A: TAC（跟踪区码）变化不影响Xn切换本身——Xn切换只要求同AMF、UPF不变。TAC变化的影响是UE切换完成后，发现不在原注册区，会主动发起一次移动性注册更新（Mobility Registration Update）向核心网报新位置。这是切换后的独立流程，不阻塞切换。
Q4: 跨UPF但同AMF的情况能走Xn吗？ A: 不能。Xn切换要求UE所有PDU会话的UPF（PSA）不变。一旦需要重选PSA（如UE移出原UPF服务区），必须走涉及SMF/UPF重选的N2切换或SSC模式3的会话重锚流程。Xn切换路径上核心网只做"N3端点迁移"，不做PSA重选。
Q5: 条件切换（CHO）和Xn切换是什么关系？ A: CHO（Conditional Handover，Rel-16）是Xn切换的一种增强形态。它复用Xn接口做目标准备，区别在于UE收到切换命令后不立即执行，而是预设一个或多个候选目标及其触发条件（如某候选小区RSRP超过门限），UE自行判断条件满足时再执行切换。CHO降低了切换失败率（尤其高速场景），但其准备阶段的XnAP信令（如多个候选小区的Handover Request）与普通Xn切换同源。
本文由「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 等场景全覆盖。