# 5G条件切换CHO机制全链拆解 ## 一、为什么需要条件切换：从"网络决定何时切"到"UE决定何时切" 传统切换（Legacy Handover）的执行时序是**串行紧耦合**的：UE上报 `MeasurementReport`（如 A3 事件）→ 源 gNB 决策 → 目标 gNB 准备 → 源 gNB 下发 `RRCReconfiguration`（含 HO Command）→ UE 立即同步到目标小区。整条信令链路中，**HO 命令的下发时刻与执行时刻被强绑定**。问题在于：在高铁、高速公路、小区边缘信号剧烈波动等场景下，源 gNB 决策并下发 HO 命令后到 UE 真正向目标发起随机接入这段时间内（通常几十毫秒），源链路可能已经恶化到无法可靠接收，或者在 RACH 接入目标过程中链路条件已发生变化，最终导致切换失败（HO Failure）并触发 RRC 重建，中断时延显著增加。 3GPP 在 Release 16 引入了**条件切换（Conditional Handover，CHO）**，其核心思想用一句话概括： > **传统切换由网络决定"何时执行"；条件切换由 UE 决定"何时执行"。** TS 38.300 对 CHO 的权威定义是：**"a handover procedure that is executed by the UE only when execution condition(s) are met."**——网络预先为 UE 配置一个或多个候选小区（candidate cell）及其各自的切换命令和执行条件，UE 收到后继续驻留源小区、持续评估条件，**一旦某候选小区满足其执行条件，UE 自主执行切换并应用预先存储的该候选配置，无需等待网络再下发任何命令**。这一机制将"切换命令下发"与"切换执行"在时间上彻底解耦，把 HO Command 提前准备好并存储在 UE 侧，从而在最关键的时刻（源链路最差的瞬间）不再依赖源链路传递任何关键命令。 下面给出传统切换与 CHO 在执行时序上的本质差异： ```mermaid sequenceDiagram autonumber participant UE participant SRC as 源 gNB participant TGT as 目标 gNB Note over UE,TGT: 传统切换(Legacy HO):决策→下发→执行 紧耦合 UE->>SRC: MeasurementReport(A3事件) Note over SRC: 此刻源链路可能已开始恶化 SRC->>TGT: HandoverRequest (Xn) TGT->>SRC: HandoverRequestAcknowledge SRC->>UE: RRCReconfiguration(含HO Command) Note over UE: 立即执行,无缓冲 UE->>TGT: RACH(专用Preamble) Note over UE,TGT: ⚠️ 若源链路在步骤5-6间断→HO失败→RRC重建 ``` ```mermaid sequenceDiagram autonumber participant UE participant SRC as 源 gNB participant T1 as 候选gNB-1 participant T2 as 候选gNB-2 Note over UE,T2: 条件切换(CHO):准备→存储→条件触发 执行解耦 SRC->>T1: HandoverRequest(CHO准备) SRC->>T2: HandoverRequest(CHO准备) T1->>SRC: HandoverRequestAcknowledge(候选配置1) T2->>SRC: HandoverRequestAcknowledge(候选配置2) SRC->>UE: RRCReconfiguration(condReconfigToAddModList) UE->>SRC: RRCReconfigurationComplete(仅确认收到CHO配置) Note over UE: 持续评估条件,继续驻留源小区 loop 条件评估 UE->>UE: 评估CondEvent(A3/A5) for 每个候选 end Note over UE: 源链路恶化,但候选2条件满足 UE->>T2: RACH(专用Preamble,无需新命令) UE->>T2: RRCReconfigurationComplete(HO完成) T2->>SRC: HANDOVER SUCCESS Note over UE: 释放其余存储的CHO配置 ``` 第二张图清楚展示了 CHO 的三大解耦点：**命令下发与执行解耦**（命令提前存储）、**多目标并行准备**（最多 8 个候选小区）、**执行时机由 UE 掌控**（条件满足即触发）。这正是 CHO 相对传统切换的根本性架构差异。 ## 二、CHO 全链信令流程：准备—执行—完成三阶段 依据 TS 38.300 §9.2.3.4 与 §9.2.3.2，Intra-NR RAN 的 CHO 全流程分为三个阶段：**准备阶段（Preparation）**、**执行阶段（Execution）**、**完成阶段（Completion）**。值得注意的是，对于站间 CHO（inter-gNB CHO），准备与执行阶段均**不经 5GC（AMF/UPF）参与**，准备消息在 gNB 间经 Xn 接口直接交互；只有完成阶段的目标路径切换会触及 5GC。 下面是完整的三阶段信令时序图（以两个候选 gNB 为例）： ```text sequenceDiagram autonumber participant UE participant SRC as 源gNB participant C1 as 候选gNB-1 participant C2 as 候选gNB-2 participant AMF Note over UE,AMF: ═══ 阶段一:CHO准备(Preparation) ═══ SRC->>UE: MeasConfig(测量配置) UE->>SRC: MeasurementReport Note over SRC: 决策发起CHO,选定候选小区 SRC->>C1: HANDOVER REQUEST(Xn,含CHO指示) SRC->>C2: HANDOVER REQUEST(Xn,含CHO指示) Note over C1,C2: 准入控制(切片感知);为每个候选预留资源+生成RR配置 C1->>SRC: HANDOVER REQUEST ACKNOWLEDGE(候选配置1:reconfigurationWithSync) C2->>SRC: HANDOVER REQUEST ACKNOWLEDGE(候选配置2:reconfigurationWithSync) SRC->>UE: RRCReconfiguration(condReconfigToAddModList + 执行条件) UE->>SRC: RRCReconfigurationComplete(确认收到CHO配置) opt Early Data Forwarding SRC->>C1: EARLY STATUS TRANSFER end Note over UE,AMF: ═══ 阶段二:CHO执行(Execution,UE自主) ═══ Note over UE: 维持源连接,持续评估各候选执行条件 Note over UE: 某时刻候选2满足CondEvent → 停止评估 → 应用候选2存储配置 UE->>C2: MSG1(RACH,专用Preamble) C2->>UE: MSG2(RAR,TA+UL Grant) UE->>C2: RRCReconfigurationComplete(HO Complete) Note over UE,AMF: ═══ 阶段三:CHO完成(Completion) ═══ C2->>SRC: HANDOVER SUCCESS(UE已成功接入) SRC->>C2: SN STATUS TRANSFER(PDCP状态) SRC->>C1: HANDOVER CANCEL(取消其余候选) C2->>AMF: PATH SWITCH REQUEST(NGAP) AMF->>C2: PATH SWITCH REQUEST ACKNOWLEDGE C2->>SRC: UE CONTEXT RELEASE(Xn,释放源资源) ``` ### 关键步骤逐条解析 **步骤 1-2（测量配置与上报）**：源 gNB 通过 `MeasConfig` 配置测量对象与上报规则，UE 上报 `MeasurementReport`。这里与传统切换一致，区别在于 gNB 的决策结果不是"立刻切"，而是"准备 CHO 候选"。 **步骤 3-4（Xn 侧 CHO 准备）**：源 gNB 为每个候选小区单独发送 `HANDOVER REQUEST`，其中携带 CHO 指示。候选 gNB 执行准入控制（Admission Control），**若携带切片信息则执行切片感知准入**；若候选小区不支持 UE 当前所用切片，对应的 PDU Session 将被拒绝。准入通过后，候选 gNB 生成针对该候选小区的 `reconfigurationWithSync`（含目标小区 PCI、TA、专用 RACH 资源等）作为 HO Command，回 `HANDOVER REQUEST ACKNOWLEDGE`。 **步骤 6-7（RRC 侧 CHO 配置下发与确认）**：源 gNB 将所有候选配置与执行条件打包进 `RRCReconfiguration` 的 `condReconfigToAddModList` 下发。**UE 回复的 `RRCReconfigurationComplete` 只表示"我已收到并存储 CHO 配置"，并不表示执行了切换**——这是 CHO 与传统切换最容易混淆的点，也是抓包定位时的关键识别特征。 **步骤 8（早期数据转发，可选）**：若启用 early data forwarding，源 gNB 在 UE 还未执行 CHO 前就向候选 gNB 转发下行数据，以便无论 UE 最终选择哪个候选都能快速获取数据，降低中断。 **步骤 9-10（条件评估与自主执行）**：UE 在收到 CHO 配置后**继续维持与源 gNB 的连接**，持续评估各候选小区的执行条件。一旦某候选满足条件，UE 立即停止评估、与源小区分离、应用该候选的存储配置，向该候选发起专用 RACH 并完成 `RRCReconfigurationComplete`。**执行阶段网络完全不参与命令下发**，这也是 CHO 鲁棒性的来源。 **步骤 11-13（成功通知与状态转发）**：目标 gNB 通过 `HANDOVER SUCCESS`（Rel-16 新增的 XnAP 消息）通知源 gNB"UE 已成功接入"，源 gNB 随即回送 `SN STATUS TRANSFER` 以保证 PDCP 层无缝衔接，并向其他未选中的候选发送 `HANDOVER CANCEL` 释放它们预留的资源。 **步骤 14-16（路径切换与源释放）**：目标 gNB 向 AMF 发 `PATH SWITCH REQUEST`，AMF 协调 UPF 切换 N3 隧道至目标 gNB，回 `PATH SWITCH REQUEST ACKNOWLEDGE`，最后目标 gNB 向源 gNB 发 `UE CONTEXT RELEASE` 释放源侧全部资源。 > **设计要点**：注意 CHO 准备阶段在 Xn 间并行准备了多个候选，但执行时只有一个候选胜出。这要求网络侧做好"准备成本 vs 切换可靠性"的权衡——候选越多鲁棒性越高，但每个候选都需预留资源，资源开销线性增长。规范将候选数量上限定为 8（见 `condHandover-r16` 能力），实际部署通常配置 2-4 个候选。 ## 三、RRC 信令结构：ConditionalReconfiguration IE 全解 CHO 的全部控制信息都承载在 RRC 层的 `ConditionalReconfiguration` 信息元素中（TS 38.331）。理解其 ASN.1 结构是抓包解析和参数调优的基础。以下是 Rel-18 版本的完整定义： ```asn1 ConditionalReconfiguration-r16 ::= SEQUENCE { attemptCondReconfig-r16 ENUMERATED {true} OPTIONAL, -- Need N condReconfigToRemoveList-r16 CondReconfigToRemoveList-r16 OPTIONAL, -- Need N condReconfigToAddModList-r16 CondReconfigToAddModList-r16 OPTIONAL, -- Need N ..., [[ scpac-ReferenceConfiguration-r18 SetupRelease {ReferenceConfiguration-r18} OPTIONAL, -- Need M servingSecurityCellSetId-r18 SecurityCellSetId-r18 OPTIONAL, -- Need M sk-CounterConfiguration-r18 SK-CounterConfiguration-r18 OPTIONAL -- Need M ]] } ``` ```mermaid graph TB A[RRCReconfiguration] --> B[condReconfigToAddModList-r16] B --> C1[ConditionalReconfig 条目1] B --> C2[ConditionalReconfig 条目2] B --> C3[...最多8个候选] C1 --> D1[condReconfigId] C1 --> D2[condExecutionCond 执行条件] C1 --> D3[rrcReconfig: 包含reconfigurationWithSync] D2 --> E1[CondEvent A3: 候选比SpCell偏置好] D2 --> E2[CondEvent A5: SpCell低于门限 且 候选高于门限] D3 --> F1[目标小区PCI/TA] D3 --> F2[专用RACH资源] D3 --> F3[安全配置/密钥派生参数] A --> G[attemptCondReconfig: 失败后是否尝试CHO] A --> H[condReconfigToRemoveList: 移除候选] ``` 下面用表格逐一说明关键 IE 参数： | IE 参数 | 作用说明 | 典型取值/备注 | |---------|---------|--------------| | `condReconfigToAddModList` | **核心容器**，承载一个或多个候选 SpCell 的完整配置（CHO/CPA/CPC） | 列表，每条对应一个候选小区 | | `condReconfigId` | 候选配置的唯一标识，用于增删改 | 整数，全网内唯一 | | `condExecutionCond` | **执行条件**，含 1-2 个触发事件 | CondEvent A3 / A5（Rel-16）；A4/D1/T1（NTN，Rel-17） | | `rrcReconfig` | OCTET STRING，**内含完整的 RRCReconfiguration（含 reconfigurationWithSync）** | 即目标 gNB 生成的 HO Command，UE 存储待执行 | | `attemptCondReconfig` | 失败恢复指示：RLF/重建后若选中小区是候选，是否直接复用 CHO 配置 | 参见 TS 38.331 §5.3.7.3，缩短恢复时延 | | `condReconfigToRemoveList` | 指示 UE 删除哪些已存储的候选配置 | 维护候选一致性 | | `scpac-ReferenceConfiguration` | （Rel-18）CPAC 场景下多候选共享的参考配置 | 减少信令冗余 | | `servingSecurityCellSetId` / `sk-CounterConfiguration` | （Rel-18）安全小区集与 S-KgNB 密钥派生计数器 | 仅 MN 生成时提供，SN 不提供 | ### 执行条件（CondEvent）的设计 执行条件是 CHO 区别于传统切换的灵魂。Rel-16 主要支持两种测量事件作为条件： - **CondEvent A3**：候选小区质量**比 SpCell（服务小区）偏置好**（candidate becomes offset better than PCell），即相对比较，是最常用的条件，对应"候选比当前服务小区更好就切"。 - **CondEvent A5**：SpCell 质量低于某门限**且**候选小区质量高于某门限，双门限条件，适合"服务小区已差 + 候选已好"的双重确认场景。 每个候选的执行条件最多由**两个触发事件**组成（需 UE 支持 `condHandoverTwoTriggerEvents-r16` 能力，且该能力对支持 CHO 的 UE 是**强制必备**），支持 RSRP+RSRQ 或 RSRP+SINR 等两种触发量组合，增强鲁棒性。但规范同时规定：**单个候选的 CHO 执行条件评估最多支持一种参考信号类型（SSB 或 CSI-RS）**，避免 UE 评估复杂度过高。 Rel-17 针对 NTN（非地面网络）场景扩展了三种新条件：`CondEvent A4`（候选绝对门限，适配卫星大范围覆盖）、`CondEvent D1`（基于位置/距离）、`CondEvent T1`（基于时间）。这是因为卫星运动轨迹可预测，用位置或时间触发比信号测量更稳定。 ## 四、CHO 优先级与失败处理：状态机视角 ### 4.1 Legacy HO 优先于 CHO（关键规则） TS 38.300 §9.2.3.2 规定了一条**容易被忽视但极其重要**的优先级规则： > **在 CHO 执行条件被满足之前，如果 UE 收到了一个不含 CHO 配置的普通 HO 命令（Legacy HO Command），UE 必须立即执行该 Legacy HO，并放弃之前所有 CHO 配置的评估——Legacy HO 配置优先于 CHO 配置。** 这条规则的设计意图是：源 gNB 仍保留最终控制权。如果网络在 CHO 准备后基于更新的信息（如负载、新的测量）决定走传统切换，UE 必须服从。下图展示该 fallback 流程： ```mermaid sequenceDiagram autonumber participant UE participant SRC as 源gNB participant TGT as Legacy目标 Note over UE: 已配置CHO,正在评估条件 SRC->>UE: RRCReconfiguration(普通HO Command,无CHO) Note over UE: ⚠️条件尚未满足 → 立即放弃CHO评估 UE->>SRC: RRCReconfigurationComplete(对Legacy HO) UE->>TGT: 执行Legacy HO(RACH→Complete) Note over UE: 释放所有存储的CHO候选配置 ``` ### 4.2 CHO 失败与重建复用 CHO 并非万能，执行阶段仍可能失败（如向目标发起 RACH 失败、目标链路也恶化）。此时 TS 38.331 §5.3.7.3 定义了**CHO 配置在重建中的复用机制**：若 UE 支持 `condHandoverFailure-r16` 能力且 `attemptCondReconfig` 被置位，则 UE 在 RLF/重建后若选中的小区恰好是某个已配置的 CHO 候选，可直接复用存储的候选配置快速恢复，而不必走完整的连接重建流程，显著缩短恢复时延。 ### 4.3 CHO 状态转换图 下图归纳了 UE 在 CHO 全周期中的状态与事件迁移： ```mermaid stateDiagram-v2 [*] --> Connected: 正常连接 Connected --> CHO_Configured: 收到condReconfigToAddMod CHO_Configured --> CHO_Configured: 评估条件未满足/继续驻留源 CHO_Configured --> CHO_Executing: 条件满足→应用候选配置→RACH CHO_Configured --> LegacyHO: 收到普通HO命令(优先) CHO_Executing --> HO_Complete: RRCReconfigComplete到目标 CHO_Executing --> RLF: 执行失败(链路问题) RLF --> CHO_Configured: 重建选中候选且attemptCondReconfig置位→复用 RLF --> Reestablish: 选中非候选→标准重建 HO_Complete --> Connected: 路径切换完成,释放其余候选 CHO_Configured --> Connected: 源gNB取消CHO(condReconfigToRemove) Connected --> [*] ``` ## 五、UE 能力协商：CHO 启用的前提 CHO 不是默认开启的，需要 UE 在 `UECapabilityInformation` 中明确上报支持，gNB 才能下发 CHO 配置。下表汇总核心能力位及其约束： | UE 能力位 | 含义 | 关键约束 | |----------|------|---------| | `condHandover-r16` | **总开关**，支持 CHO 含执行条件、候选配置，**最多 8 个候选** | 需在 FDD-FR1/TDD-FR1/TDD-FR2 等各频段组内**一致设置** | | `condHandoverTwoTriggerEvents-r16` | 支持单条件两触发事件 | **对支持 CHO 的 UE 强制必备** | | `condHandoverFailure-r16` | 支持重建时复用 CHO 配置 | 提升失败恢复鲁棒性 | | `condHandoverFDD-TDD-r16` | 支持 FDD↔TDD 间 CHO | 需两端均支持 condHandover + handoverFDD-TDD | | `condHandoverFR1-FR2-r16` | 支持 FR1↔FR2 间 CHO | 需配合 inter-frequency HO 能力 | | `condHandoverWithSCG-NRDC/ENDC/NEDC-r17` | 双连接场景下 CHO | 需配合对应 DC 频段组合 | | `eventA4Based/locationBased/timeBasedCondHandover-r17` | NTN 场景的 A4/位置/时间触发 | 需同时上报 NTN 能力 | **一致性约束**（consistency requirement）是该表的重点：CHO 能力不能"挑频段"实现，必须在指定的频段组内统一取值，否则网络无法正确决策。这与 Rel-16 之前的能力上报粒度相比更为严格，反映了 CHO 涉及跨频段、跨双工方式的复杂性。 ## 六、与传统切换、DAPS 切换的对比 为更清晰定位 CHO，下表对比三种移动性增强机制： | 对比维度 | Legacy HO（传统） | CHO（条件切换，Rel-16） | DAPS HO（双激活协议栈，Rel-16） | |---------|------------------|------------------------|-------------------------------| | 执行决策者 | **网络（源 gNB）** | **UE（条件满足时自主）** | 网络，但 UE 短暂保持双连接 | | HO Command 下发时机 | 切换瞬间下发 | **提前下发并存储**，执行时不依赖网络 | 切换瞬间下发 | | 候选目标数 | 单一目标 | **多候选（≤8）** | 单一目标 | | 源小区在执行期 | 立即断开 | 条件触发后断开 | **保持连接**直到完成 | | 数据中断 | 较大（断源→接目标） | 较小（条件即时触发） | **接近零**（双栈并行收发） | | 核心目标 | 通用移动性 | **提升切换成功率/鲁棒性** | **零中断/无缝** | | 资源开销 | 最低 | 较高（多候选预留） | 高（双份空口资源） | | 支持场景 | 全场景 | 高速/小区边缘/不稳定链路 | URLLC/低时延业务 | | 可组合性 | — | 可与 DAPS 叠加（Rel-17） | 可与 CHO 叠加 | | NG-C 切换支持（Rel-16） | 支持 | **不支持**（仅 Xn 侧准备） | 支持 | > 注意：`reconfigurationWithSync` 的 CHO 候选配置**不能**同时包含 DAPS 配置（TS 38.300 Note 2），二者在同一候选内互斥，但不同候选或不同阶段可分别采用。Rel-17 起 CHO 与 DAPS 可组合使用以兼得鲁棒性与零中断。 ## 七、抓包识别与故障排查（实战连接） ### 7.1 如何在 pcap 中识别 CHO 流程 使用 Wireshark/TShark 解析 5G 信令时，CHO 的识别要点如下： 1. **XnAP 侧**：寻找 `HANDOVER REQUEST` 消息中的 CHO 相关指示；关键标志是源 gNB 向**多个不同目标 gNB-ID** 几乎同时发送 `HANDOVER REQUEST`（多候选并行准备），以及执行后目标回送的 **`HANDOVER SUCCESS`**（XnAP Procedure Code = 0x2C 范畴，Rel-16 新增，这是 CHO 区别于普通 Xn 切换的"吸烟枪"）。 2. **RRC 侧**：在 `RRCReconfiguration` 中出现 **`condReconfigToAddModList-r16`** 字段即确认为 CHO 配置下发。紧跟一条 `RRCReconfigurationComplete` **回给源 gNB**（注意是源，不是目标），证明 UE 仅确认接收配置而非执行。 3. **执行确认**：一段时间后，`RRCReconfigurationComplete` 出现在**目标候选小区**对应的链路上，配合同一 UE 的专用 RACH 过程，即为 CHO 执行完成点。 ### 7.2 常见故障点与排错思路 | 故障现象 | 可能原因 | 排错思路 | |---------|---------|---------| | CHO 配置下发后 UE 一直不执行 | 执行条件偏置过大（A3 offset 太高） | 检查 `CondEvent` 偏置参数，调小 A3 hysteresis/offset | | 频繁乒乓切换 | 条件偏置过小或 time-to-trigger 过短 | 增大触发滞后与触发时延，避免抖动误触发 | | UE 执行 CHO 后立即 RLF | 目标候选实际信号不稳定 | 核查候选小区覆盖，考虑减少不可靠候选 | | 准备阶段候选 gNB 拒绝 | 切片不支持或资源不足 | 检查切片感知准入日志，确认候选 gNB 切片支持 | | 重建后无法复用 CHO | UE 未上报 `condHandoverFailure-r16` 或 `attemptCondReconfig` 未置位 | 核查 UE 能力与配置一致性 | | 误把 CHO 当 Legacy HO | 未识别 `condReconfigToAddModList` | 重点检查 RRC 字段，注意收 Complete 的对象是源还是目标 | ## 常见问题 **Q1: CHO 与传统 Xn 切换在信令上的本质区别是什么？** A: 传统 Xn 切换中，HO Command 在切换瞬间由源 gNB 下发，UE 立即执行，执行与下发紧耦合，且单目标。CHO 中，HO Command（`reconfigurationWithSync`）被**提前打包进 `condReconfigToAddModList` 下发并存储在 UE**，UE 仅回 Complete 确认接收；真正执行时 UE 自主判断条件、应用存储配置、发专用 RACH，网络不再下发任何命令，且支持多候选并行准备。抓包上 CHO 有两个明显的 Complete（一个给源确认配置、一个给目标确认执行）和 `HANDOVER SUCCESS` 消息。 **Q2: 为什么 Legacy HO 命令会优先于已配置的 CHO？** A: 这是 TS 38.300 §9.2.3.2 明确规定的优先级规则。设计意图是让源 gNB 保留最终决策权：若网络在 CHO 准备后基于更新信息（负载均衡、新测量、紧急策略）决定走传统切换，UE 必须服从。这避免了 CHO 与网络实时策略冲突，保证网络对移动性的总体可控性。 **Q3: CHO 能否用于 NG-C（N2）切换？Rel-16 有何限制？** A: Rel-16 中 CHO **不支持 NG-C based handover**，准备阶段消息仅在 gNB 间经 Xn 直接交互，不经 AMF。只有完成阶段的 `PATH SWITCH REQUEST`（路径切换）会触及 5GC。后续 Rel-17/18 逐步扩展了 CHO 的适用范围（如双连接、CPAC），但核心的 UE 自主执行机制保持不变。 **Q4: 如果多个候选小区同时满足执行条件，UE 如何选择？** A: TS 38.300 明确规定：**若多个候选同时满足条件，由 UE 实现决定（up to UE implementation）选择哪一个**，规范不做强制规定。实际中 UE 厂商通常基于信号质量、历史成功概率等策略选择，不同厂商可能有细微差异，这是协议留给实现优化的空间。 **Q5: CHO 在 NTN（卫星）场景有何特殊增强？** A: Rel-17 针对 NTN 引入了 `CondEvent A4`（候选绝对门限）、`CondEvent D1`（基于位置/距离）、`CondEvent T1`（基于时间）三种新触发条件，对应 UE 能力 `eventA4Based/locationBased/timeBasedCondHandover-r17`。这是因为卫星运动轨迹可预测、传播时延大、信号相对稳定，用位置或时间触发比传统测量触发更可靠，是 5G 卫星接入的关键移动性增强。 ## 参考来源 1. [ETSI TS 138 300 V18.4.0 — NR and NG-RAN Overall Description](https://www.etsi.org/deliver/etsi_ts/138300_138399/138300/18.04.00_60/ts_138300v180400p.pdf) — §9.2.3.2/§9.2.3.4 CHO 流程定义、优先级规则、候选与执行条件原则 2. [ShareTechnote — CHO(Conditional Handover)](https://sharetechnote.com/html/5G/5G_CHO.html) — ConditionalReconfiguration IE 完整 ASN.1 结构、UE 能力位详解、四阶段信令流程 3. [WirelessBrew — Conditional Handover (CHO) in 5G NR Release 16](https://wirelessbrew.com/5g-nr/conditional-handover-in-5g-nr-release16/) — CHO 原则、Legacy HO 优先级 fallback 流程、逐步信令解析 4. [3GPP TS 38.331 — NR RRC Protocol Specification](https://www.3gpp.org/dynareport/38331.htm) — ConditionalReconfiguration、CondEvent、attemptCondReconfig、§5.3.7.3 失败复用机制 5. [Ericsson Blog — The key to mobility robustness in 5G networks](https://www.ericsson.com/en/blog/2020/5/the-key-to-mobility-robustness-5g-networks) — Rel-16 移动性鲁棒性增强（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 等场景全覆盖。