5G Xn切换信令流全链拆解：从测量报告到路径切换的完整协议机制

一、引言：为什么Xn切换是5G最优先的移动性方案

在5G网络中，当UE处于RRC_CONNECTED状态从源gNB移动到目标gNB时，切换是保证业务连续性的核心机制。3GPP定义了两种主要的gNB间切换路径：Xn切换（经Xn接口直接协调）和N2切换（经核心网AMF中转）。

Xn切换的核心优势在于：切换准备和执行阶段完全在RAN内部完成，核心网仅在切换完成后的Path Switch阶段才参与。这种设计将切换时延从N2切换的30-100ms压缩至10-30ms级别，同时大幅减轻了AMF/SMF的信令负荷。

本文将深入拆解 TS 23.502 Section 4.9.1.2（Xn-based inter NG-RAN handover without UPF re-allocation）定义的完整Xn切换信令流程，覆盖从测量触发、XnAP Handover Preparation、RRC Reconfiguration执行、SN Status Transfer、直到Path Switch和资源释放的每一步协议细节。

二、Xn切换触发机制：测量事件与判决逻辑

2.1 测量事件配置

源gNB通过RRC Reconfiguration消息为UE配置测量报告规则。Xn切换最常见的触发事件是Event A3（邻区偏置后优于服务小区）。

根据 TS 38.331 Section 5.5.4 的定义，Event A3的触发条件为：

$$Mn + Ofn + Ocn - Hys > Mp + Ofp + Ocp + Off$$

其中各参数含义如下表所示：

2.2 Time-to-Trigger（TTT）防抖机制

触发条件满足后，UE并不会立即发送测量报告，而是等待TTT（Time-to-Trigger）时长持续满足条件后才上报。这一机制有效抑制了"乒乓切换"：

• 短TTT（如160ms、320ms）：高速移动场景，快速响应但误触发风险高
• 长TTT（如640ms、1280ms）：低速/静止场景，决策稳定但可能延迟必要切换

实际网络中，A3事件的典型TTT配置为320ms-640ms，配合Hysteresis=2（即1dB）使用。

2.3 测量报告IE结构

UE发送的Measurement Report（TS 38.331 Section 6.3.2）关键IE：

graph TD
    A[MeasurementReport] --> B[measResults]
    B --> C[measId: 关联测量对象和报告配置]
    B --> D[measResultServingMOList]
    B --> E[measResultNeighCells]
    D --> D1[physCellId: 服务小区PCI]
    D --> D2[measResult: RSRP/RSRQ/SINR]
    E --> E1[measResultListNR]
    E1 --> E2[physCellId: 邻区PCI]
    E1 --> E3[measResult: 邻区RSRP/RSRQ/SINR]

一个典型的A3事件Measurement Report实例如下： - 服务小区PCI 268：RSRP=-116dBm, RSRQ=-21dB, SINR=-9dB - 邻区PCI 114：RSRP=-107dBm, RSRQ=-14dB, SINR=-0.5dB

邻区RSRP比服务小区高9dB，超过A3偏置（典型6即3dB），触发切换判决。

三、Xn切换完整信令时序图

以下是基于 TS 23.502 Section 4.9.1.2.2（Xn-based handover without UPF re-allocation）的完整信令时序图：

sequenceDiagram
    participant UE
    participant S_gNB as Source gNB
    participant T_gNB as Target gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE,S_gNB: Phase 0: 测量与判决
    UE->>S_gNB: Measurement Report (Event A3)
    S_gNB->>S_gNB: 切换判决：选择Xn切换路径

    Note over S_gNB,T_gNB: Phase 1: Handover Preparation (XnAP)
    S_gNB->>T_gNB: XnAP: HANDOVER REQUEST
    Note right of T_gNB: 目标gNB执行接纳控制<br/>分配无线资源<br/>准备RRC配置
    T_gNB->>S_gNB: XnAP: HANDOVER REQUEST ACKNOWLEDGE
    Note left of T_gNB: 携带Target-to-Source Transparent Container<br/>（含RRC Reconfiguration）<br/>携带Data Forwarding地址

    Note over UE,S_gNB: Phase 2: Handover Execution
    S_gNB->>UE: RRC Reconfiguration (Handover Command)
    Note right of UE: 含目标小区PCI=114<br/>随机接入参数<br/>新安全配置

    S_gNB->>T_gNB: XnAP: SN STATUS TRANSFER
    Note right of T_gNB: 上行PDCP SN接收状态<br/>下行PDCP SN发送状态

    opt Data Forwarding
        S_gNB->>T_gNB: 转发下行缓存数据 (Xn-U/GTP-U)
    end

    UE->>T_gNB: Random Access (CFRA/CBRA)
    UE->>T_gNB: RRC Reconfiguration Complete

    Note over T_gNB,UPF: Phase 3: Path Switch
    T_gNB->>AMF: N2: PATH SWITCH REQUEST
    Note right of AMF: 携带PDU Session列表<br/>T_gNB N3隧道信息
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request
    SMF->>UPF: N4 Session Modification Request
    Note right of UPF: 更新N3 DL隧道端点<br/>从S_gNB切换到T_gNB
    UPF->>SMF: N4 Session Modification Response
    UPF->>S_gNB: End Marker Packets (旧N3隧道)
    UPF->>T_gNB: 下行数据 (新N3隧道)
    SMF->>AMF: Nsmf_PDUSession_UpdateSMContext Response
    AMF->>T_gNB: N2: PATH SWITCH REQUEST ACKNOWLEDGE

    Note over S_gNB,T_gNB: Phase 4: 资源释放
    T_gNB->>S_gNB: XnAP: UE CONTEXT RELEASE
    S_gNB->>S_gNB: 释放UE上下文和无线资源

四、Phase 1 逐步拆解：Handover Preparation

4.1 XnAP HANDOVER REQUEST（TS 38.423 Section 9.2.1）

源gNB向目标gNB发送HANDOVER REQUEST，这是Xn切换的第一条信令。该消息由TS 38.423 Section 9.2.1定义，关键IE如下表：

安全上下文传输是关键设计点：源gNB向目标gNB传递的是$K_{gNB}$密钥（TS 33.501 Section 6.9），目标gNB基于此密钥使用KDF推导出新的$K_{gNB}^{*}$和各DRB的加密/完整性保护密钥。这保证了前向安全性——即使旧密钥泄露，也无法推导新密钥。

4.2 目标gNB接纳控制

目标gNB收到HANDOVER REQUEST后执行接纳控制（Admission Control）：

1. 检查目标小区是否有足够的PRB资源
2. 评估各PDU Session的QoS Flow能否满足5QI对应的QoS指标
3. 检查SRS（Scheduling Request）资源可用性
4. 分配C-RNTI、RA前导码等随机接入资源

4.3 XnAP HANDOVER REQUEST ACKNOWLEDGE

接纳成功后，目标gNB返回HANDOVER REQUEST ACKNOWLEDGE（TS 38.423 Section 9.2.2），关键IE：

Target to Source Transparent Container内封装的RRC Reconfiguration包含了UE接入目标小区所需的全部配置：目标PCI、SSB频点、RA参数、新安全配置等。

4.4 Handover Preparation Failure（接纳失败场景）

若目标gNB无法接纳，返回HANDOVER PREPARATION FAILURE（TS 38.423 Section 9.2.3），携带Cause IE。常见失败原因：

源gNB收到失败后可尝试：选择其他目标小区、回退到N2切换、或维持当前连接。

五、Phase 2 逐步拆解：Handover Execution

5.1 RRC Reconfiguration（Handover Command）

源gNB将Target to Source Transparent Container中的RRC配置封装在RRC Reconfiguration消息中发送给UE（TS 38.331 Section 5.3.5.4）。

graph TD
    A[RRCReconfiguration] --> B[spCellConfig]
    B --> C[reconfigurationWithSync]
    C --> D[spCellConfigCommon]
    C --> E[reconfigurationWithSync专用IE]
    D --> D1[physCellId: 目标PCI]
    D --> D2[downlinkConfigCommon]
    D --> D3[uplinkConfigCommon]
    D2 --> D2a[absoluteFrequencySSB]
    D2 --> D2b[absoluteFrequencyPointA]
    E --> E1[rach-ConfigDedicated]
    E --> E2[newUE-Identity: C-RNTI]
    E1 --> E1a[cfra: 非竞争随机接入配置]
    E1 --> E1b[ra-PreambleIndex]
    A --> F[radioBearerConfig]
    F --> F1[DRB安全配置更新]
    A --> G[securityConfig]
    G --> G1[keyAlgPreference]
    G --> G2[securityAlgorithmConfig]

关键参数解读： - physCellId: 114 — 目标小区物理小区标识 - absoluteFrequencySSB: 126510 — 目标小区SSB频点（NR-ARFCN） - rach-ConfigDedicated — 分配专用RA前导码（CFRA），实现无竞争随机接入 - newUE-Identity — 目标小区分配的C-RNTI

5.2 SN Status Transfer（TS 38.423 Section 9.1.2.5）

源gNB在发送Handover Command后，立即向目标gNB发送SN STATUS TRANSFER消息。这是保证PDCP层按序传送的关键步骤。

根据 TS 38.423 Section 9.1.2.5 的定义，该消息传输以下状态信息：

对于配置了按序递交（in-order delivery）的DRB（如AM模式的SRB），目标gNB利用这些状态信息： - 上行：知道UE下一个期望确认的PDCP SN，避免重复接收 - 下行：知道从哪个SN开始继续发送，避免丢包或重复

设计意图：5G NR将PDCP实体重定位到目标gNB（不同于LTE的重建），因此需要精确传递发送/接收状态以实现无缝衔接，满足URLLC等低丢包率业务需求。

5.3 数据转发（Data Forwarding）

源gNB在切换执行期间将缓存的下行数据通过Xn-U接口（GTP-U隧道）转发到目标gNB。数据转发有两种时机：

Xn切换天然支持直接转发（Direct Forwarding），即数据直接经Xn-U接口在gNB间传递，无需经过UPF中转（N2切换可能需要间接转发经UPF中转）。这是Xn切换低时延的关键因素之一。

5.4 UE同步到目标gNB

UE收到Handover Command后： 1. 断开与源gNB的连接（不发送任何断开指示） 2. 使用分配的专用RA前导码向目标gNB发起随机接入（CFRA） 3. 目标gNB回复RAR，UE获得Timing Advance 4. UE发送RRC Reconfiguration Complete，确认切换完成

切换中断时间（Handover Interruption Time）主要来自这一阶段，典型值为10-20ms，包含RA过程和RRC完成消息传输。

六、Phase 3 逐步拆解：Path Switch

6.1 PATH SWITCH REQUEST（N2接口）

UE成功接入目标gNB后，目标gNB向AMF发送PATH SWITCH REQUEST（NGAP消息，TS 38.413 Section 8.7.1），触发核心网将下行数据路径从源gNB切换到目标gNB。

该消息携带： - PDU Session Resource Admitted List：待切换的PDU Session列表 - Target NG-RAN N3 Tunnel Info：目标gNB的N3 DL GTP-U TEID和IP地址 - UE Location Information：UE当前的位置信息 - Established QoS Flows：各PDU Session中活跃/非活跃的QoS Flow状态

6.2 SMF/UPF路径更新

AMF收到Path Switch Request后，为每个PDU Session调用 Nsmf_PDUSession_UpdateSMContext 服务（TS 23.502 Step 2），向SMF请求更新用户面路径。

SMF通过N4 Session Modification指示UPF： 1. 将N3 DL隧道端点从源gNB更新为目标gNB 2. 若源和目标gNB在不同IP域，UPF可能需要分配新的CN Tunnel Info

6.3 End Marker机制

路径切换完成后，UPF在旧N3隧道上发送一个或多个End Marker包（GTP-U End Marker，TS 29.281 Section 5.1）。

sequenceDiagram
    participant UPF
    participant S_gNB as Source gNB
    participant T_gNB as Target gNB
    participant UE

    Note over UPF: 路径切换完成
    UPF->>S_gNB: End Marker Packets (旧N3隧道)
    Note right of S_gNB: 收到End Marker后<br/>知道旧路径数据已全部收到<br/>可停止转发
    UPF->>T_gNB: 下行数据 (新N3隧道)
    Note right of T_gNB: 先处理转发数据<br/>再处理新路径数据<br/>保证按序递交
    T_gNB->>UE: 有序下行数据

End Marker的设计意图：目标gNB可能同时从两个路径收到数据——经Xn-U转发的旧数据和经N3新隧道的新数据。End Marker标记了旧路径数据的结尾，目标gNB据此确定何时停止等待转发数据，开始发送新路径数据，避免PDCP层重排序死锁。

6.4 PATH SWITCH REQUEST ACKNOWLEDGE

AMF汇总所有SMF的响应后，向目标gNB发送PATH SWITCH REQUEST ACKNOWLEDGE，携带： - 更新的CN Tunnel Info（如果UPF分配了新地址） - 各PDU Session的切换结果

若所有PDU Session都切换失败，AMF返回PATH SWITCH REQUEST FAILURE，目标gNB可能发起RRC连接重建。

七、Phase 4：资源释放

Path Switch成功后，目标gNB向源gNB发送XnAP: UE CONTEXT RELEASE（TS 38.423 Section 9.1.2.7），源gNB收到后释放： - UE上下文 - 无线承载资源 - C-RNTI - 与该UE关联的Xn-U数据转发隧道 - S1/X2-U残留隧道（如有）

八、Xn切换状态转换图

整个Xn切换过程涉及UE的RRC状态和gNB侧的协议状态转换：

stateDiagram-v2
    [*] --> RRC_CONNECTED_Serving: UE已建立连接

    RRC_CONNECTED_Serving --> Measurement_Triggered: A3条件满足+TTT超时
    Measurement_Triggered --> HO_Preparation: gNB判决Xn切换

    state HO_Preparation {
        [*] --> Xn_HO_REQ_Sent: 发送HANDOVER REQUEST
        Xn_HO_REQ_Sent --> Xn_HO_ACK_Received: 收到HANDOVER REQUEST ACK
        Xn_HO_REQ_Sent --> HO_Prep_Failed: 收到HANDOVER PREPARATION FAILURE
        HO_Prep_Failed --> RRC_CONNECTED_Serving: 回退
    }

    HO_Preparation --> HO_Execution: RRC Reconfiguration发送
    state HO_Execution {
        [*] --> SN_Status_Transfer: PDCP状态传递
        SN_Status_Transfer --> Data_Forwarding: 数据转发
        Data_Forwarding --> RA_to_Target: UE随机接入目标gNB
        RA_to_Target --> RRC_Reconfig_Complete: UE确认切换完成
    }

    HO_Execution --> Path_Switch: 目标gNB发起N2 Path Switch
    state Path_Switch {
        [*] --> N2_Path_Switch_Req: 发送PATH SWITCH REQUEST
        N2_Path_Switch_Req --> N4_Modification: SMF更新UPF
        N4_Modification --> N2_Path_Switch_Ack: 路径切换确认
    }

    Path_Switch --> Resource_Release: Xn UE CONTEXT RELEASE
    Resource_Release --> RRC_CONNECTED_Target: 切换完成
    RRC_CONNECTED_Target --> [*]

九、Xn切换 vs N2切换：关键对比

十、实战连接：抓包识别与故障排查

10.1 抓包识别Xn切换流程

10.2 常见故障场景与排查思路

场景1：Handover Preparation Failure - 检查Xn接口连通性：Xn Setup是否成功，邻居关系是否正确 - 检查目标小区负荷：PRB利用率、DRB接纳数 - 检查XnAP HANDOVER REQUEST中的Cause值定位根因

场景2：UE随机接入目标gNB失败 - 检查Handover Command中RA参数是否正确：专用前导码、SSB频点 - 检查目标gNB RA响应：是否正确回复RAR - 检查物理层：目标小区信号质量是否足够（RSRP > -120dBm为典型门限）

场景3：Path Switch失败 - 检查N2接口：AMF是否可达 - 检查SMF响应：PDU Session是否有效，UPF资源是否可用 - 检查NGAP PATH SWITCH REQUEST中N3 Tunnel Info是否正确

场景4：数据转发丢包 - 检查Xn-U隧道：GTP-U TEID是否匹配 - 检查End Marker是否正常收发 - 检查PDCP重排序定时器（t-Reordering）配置是否合理

十一、条件切换（CHO）增强——Rel-16对Xn切换的扩展

TS 38.300 Section 9.2.3.4 引入了Conditional Handover（CHO），这是对传统Xn切换的重要增强：

传统Xn切换的问题：UE在收到Handover Command后到实际接入目标gNB之间存在时间窗口，如果在此期间发生无线链路恶化（尤其是高速移动场景），UE可能无法完成切换导致RLF。

CHO的解决方案： 1. 源gNB可向多个候选目标gNB发起Handover Preparation 2. UE收到多个候选小区的Handover Command和切换执行条件（CHO Condition） 3. UE持续评估CHO Condition，当任意候选小区满足条件时才执行切换 4. 大幅缩短了"切换命令到切换执行"之间的时间窗口

CHO Condition通常基于RSRP/RSINR阈值，UE在满足条件后立即执行切换，无需再上报测量报告等待网络决策。

常见问题

Q1: Xn切换和N2切换，网络如何选择？ A: 源gNB在切换判决时首先检查与目标gNB之间是否存在Xn接口。若存在，优先选择Xn切换（更低时延、更少核心网信令）。仅在以下场景回退N2切换：无Xn接口、需要AMF重定位、Inter-RAT切换、或目标gNB在Handover Preparation中拒绝且源gNB配置了N2回退策略。

Q2: SN Status Transfer中PDCP SN和HFN分别是什么？ A: PDCP SN（Sequence Number）是PDCP PDU的序号，长度可配置为12bit或18bit（TS 38.323）。HFN（Hyper Frame Number）是超帧号，用于扩展SN空间防止回卷——当SN从最大值回绕到0时HFN递增。两者组合形成完整的PDCP COUNT值，用于加密和完整性保护的输入参数。

Q3: 数据转发和End Marker的关系是什么？为什么要两个机制？ A: 数据转发解决"切换期间源gNB缓存数据如何送达UE"的问题（避免丢包），而End Marker解决"目标gNB如何知道转发数据已经全部收到"的问题（避免重排序死锁）。没有End Marker，目标gNB无法区分"还有数据在路上"和"转发已结束"，只能依赖超时，增加时延。

Q4: Xn切换中安全密钥如何更新？ A: 源gNB将当前$K_{gNB}$传递给目标gNB，目标gNB使用KDF（Key Derivation Function，TS 33.501 Annex A）基于$K_{gNB}$和目标PCI推导出新的$K_{gNB}^{}$。这实现了前向安全*：即使攻击者获取了源gNB的密钥，也无法推导出目标gNB的密钥，因为PCI是推导输入之一。

Q5: Xn接口如何自动建立？ A: 通过ANR（Automatic Neighbor Relation，TS 38.300 Section 9.2.3.6）机制：UE在测量报告中上报邻区PCI，源gNB查询本地邻区表，若无该PCI的Xn接口信息，则通过OAM或Configuration Update获取目标gNB的传输层地址（TNL Address），然后发起Xn Setup过程（TS 38.423 Section 8.2）建立Xn-C连接。Xn-U隧道在需要时（如数据转发）动态建立。

参考来源

1. 3GPP TS 23.502 V18.10.0 — Section 4.9.1.2: Handover procedures via Xn, Section 4.9.1.2.2: Xn handover without UPF re-allocation
2. 3GPP TS 38.423 V18.x — Xn Application Protocol (XnAP): Handover Preparation, SN Status Transfer, UE Context Release
3. 3GPP TS 38.331 V18.x — NR RRC Protocol: Measurement Report, RRC Reconfiguration, Event A3
4. free5GC Blog: Introduction of Xn and NG(N2) based handover — Xn与N2切换完整对比分析
5. 3GLTEInfo: 5G NR Xn Handover Procedure — Xn切换信令流教程与排错指南
6. Nu Radio Concepts: 5G Connected Mode Mobility (Xn Handover) — 含真实RRC log的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 等场景全覆盖。