# 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$$ 其中各参数含义如下表所示： | 参数 | 含义 | 来源 | |------|------|------| | Mn | 邻区测量结果（RSRP/RSRQ/SINR） | UE实测 | | Mp | 服务小区测量结果 | UE实测 | | Ofn | 邻区频率特定偏置 | measObject配置 | | Ocn | 邻区小区特定偏置 | measObject配置 | | Ofp | 服务频率特定偏置 | measObject配置 | | Ocp | 服务小区特定偏置 | measObject配置 | | Hys | 滞后参数 | reportConfig配置 | | Off | A3事件偏置 | reportConfig配置 | ### 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： ```mermaid 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）的完整信令时序图： ```mermaid 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执行接纳控制
分配无线资源
准备RRC配置 T_gNB->>S_gNB: XnAP: HANDOVER REQUEST ACKNOWLEDGE Note left of T_gNB: 携带Target-to-Source Transparent Container
（含RRC Reconfiguration）
携带Data Forwarding地址 Note over UE,S_gNB: Phase 2: Handover Execution S_gNB->>UE: RRC Reconfiguration (Handover Command) Note right of UE: 含目标小区PCI=114
随机接入参数
新安全配置 S_gNB->>T_gNB: XnAP: SN STATUS TRANSFER Note right of T_gNB: 上行PDCP SN接收状态
下行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列表
T_gNB N3隧道信息 AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request SMF->>UPF: N4 Session Modification Request Note right of UPF: 更新N3 DL隧道端点
从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如下表： | IE名称 | 方向 | 说明 | |--------|------|------| | UE-XnAP-ID | S→T | 源gNB分配的逻辑连接标识 | | Target Cell ID | S→T | 目标小区全局标识（NR CGI） | | UE Context Information | S→T | 安全能力、安全密钥、RRC上下文 | | Source to Target Transparent Container | S→T | 源gNB的RRC测量结果和配置信息 | | PDU Session Resource Admit List | S→T | 需要接纳的PDU Session列表及其QoS Flow信息 | | DRB List | S→T | 需要建立的DRB及其QoS参数（5QI、ARP） | | UE Security Capabilities | S→T | NR和E-UTRA安全算法支持能力 | | Security Key | S→T | $K_{gNB}$ 或 $K_{NG-RAN}^{*}$ 密钥 | | UE History Information | S→T | UE最近驻留的小区列表 | | Allowed NSSAI | S→T | 允许的网络切片选择辅助信息 | **安全上下文传输**是关键设计点：源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： | IE名称 | 说明 | |--------|------| | UE-XnAP-ID (Target) | 目标gNB分配的UE标识 | | Target to Source Transparent Container | 封装了RRCReconfiguration消息（Handover Command） | | PDU Session Resource Admitted List | 成功接纳的PDU Session及其N3隧道信息 | | PDU Session Resource Failed List | 接纳失败的PDU Session及原因 | | Data Forwarding Address | 用于数据转发的GTP-U TEID和IP地址 | **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。常见失败原因： | Cause值 | 含义 | 典型场景 | |---------|------|---------| | radio-resources-not-available | 无线资源不足 | 目标小区高负荷 | | invalid-candidate-cell | 候选小区无效 | 目标PCI错误 | | unknown-targetID | 未知目标标识 | Xn邻居配置错误 | | ho-failure-in-target-5GC-nr-node | 目标侧5GC失败 | 切片资源不可用 | 源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）。 ```mermaid 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** 的定义，该消息传输以下状态信息： | IE | 方向 | 说明 | |----|------|------| | UL PDCP SN Receiver Status | S→T | 上行期望接收的下一个PDCP SN和HFN | | DL PDCP SN Transmitter Status | S→T | 下行已发送的PDCP SN+1和HFN | | DRBs Subject to Status Transfer List | S→T | 需要传递状态的DRB列表 | 对于配置了按序递交（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。数据转发有两种时机： | 转发模式 | 触发时机 | 特点 | |---------|---------|------| | **Early Forwarding** | 发送Handover Command后立即开始 | 时延最低，Xn切换专用 | | **Late Forwarding** | 收到SN STATUS TRANSFER后开始 | 状态已知后转发，更精确 | 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）。 ```mermaid 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后
知道旧路径数据已全部收到
可停止转发 UPF->>T_gNB: 下行数据 (新N3隧道) Note right of T_gNB: 先处理转发数据
再处理新路径数据
保证按序递交 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侧的协议状态转换： ```mermaid 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切换：关键对比 | 维度 | Xn切换 | N2切换 | |------|--------|--------| | **协议定义** | TS 23.502 §4.9.1.2 | TS 23.502 §4.9.1.3 | | **RAN协议** | XnAP（TS 38.423） | NGAP（TS 38.413） | | **准备阶段路径** | 源gNB ↔ 目标gNB（直连） | 源gNB → AMF → 目标gNB（中转） | | **核心网参与时机** | 仅Path Switch阶段 | 准备和执行全程参与 | | **典型准备时延** | 10-30ms | 30-100ms | | **数据转发路径** | 直接（Xn-U，gNB间） | 直接或间接（经UPF中转） | | **SN状态传递** | XnAP直接传递 | 经AMF中转（Uplink/Downlink RAN Status Transfer） | | **AMF重定位** | 不支持（需回退N2） | 支持（Inter-AMF Handover） | | **前提条件** | 源/目标gNB间存在Xn接口 | 无特殊要求 | | **适用场景** | 同AMF下邻区gNB | 无Xn接口/Inter-AMF/Inter-RAT | | **信令消息数** | ~8条 | ~15条 | --- ## 十、实战连接：抓包识别与故障排查 ### 10.1 抓包识别Xn切换流程 | 接口 | 协议 | 关键过滤表达式 | 识别要点 | |------|------|--------------|---------| | NR-Uu | RRC | `rrc.reconfiguration` | spCellConfig中包含reconfigurationWithSync即为Handover Command | | NR-Uu | RRC | `rrc.reconfigurationComplete` | UE确认切换完成 | | Xn-C | XnAP | `xnap.handoverRequest` | 切换准备开始标志 | | Xn-C | XnAP | `xnap.snStatusTransfer` | PDCP状态传递 | | N2 | NGAP | `ngap.pathSwitchRequest` | Path Switch触发标志 | | Xn-C | XnAP | `xnap.ueContextRelease` | 资源释放完成标志 | ### 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](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — 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](https://www.3gpp.org/DynaReport/38423.htm) — Xn Application Protocol (XnAP): Handover Preparation, SN Status Transfer, UE Context Release 3. [3GPP TS 38.331 V18.x](https://www.3gpp.org/DynaReport/38331.htm) — NR RRC Protocol: Measurement Report, RRC Reconfiguration, Event A3 4. [free5GC Blog: Introduction of Xn and NG(N2) based handover](https://free5gc.org/blog/20251105/20251105/) — Xn与N2切换完整对比分析 5. [3GLTEInfo: 5G NR Xn Handover Procedure](https://www.3glteinfo.com/call-flows/5g/xn-handover/) — Xn切换信令流教程与排错指南 6. [Nu Radio Concepts: 5G Connected Mode Mobility (Xn Handover)](https://nuradiocncpts.wordpress.com/2024/10/03/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 等场景全覆盖。