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 在执行时序上的本质差异：

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重建

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 为例）：

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 版本的完整定义：

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
    ]]
}

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 参数：

执行条件（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 流程：

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 全周期中的状态与事件迁移：

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 配置。下表汇总核心能力位及其约束：

一致性约束（consistency requirement）是该表的重点：CHO 能力不能"挑频段"实现，必须在指定的频段组内统一取值，否则网络无法正确决策。这与 Rel-16 之前的能力上报粒度相比更为严格，反映了 CHO 涉及跨频段、跨双工方式的复杂性。

六、与传统切换、DAPS 切换的对比

为更清晰定位 CHO，下表对比三种移动性增强机制：

注意：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 常见故障点与排错思路

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 — §9.2.3.2/§9.2.3.4 CHO 流程定义、优先级规则、候选与执行条件原则
2. ShareTechnote — CHO(Conditional Handover) — ConditionalReconfiguration IE 完整 ASN.1 结构、UE 能力位详解、四阶段信令流程
3. WirelessBrew — Conditional Handover (CHO) in 5G NR Release 16 — CHO 原则、Legacy HO 优先级 fallback 流程、逐步信令解析
4. 3GPP TS 38.331 — NR RRC Protocol Specification — ConditionalReconfiguration、CondEvent、attemptCondReconfig、§5.3.7.3 失败复用机制
5. Ericsson Blog — The key to mobility robustness in 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 等场景全覆盖。