<!-- title: 5G条件切换CHO信令机制全链拆解 -->
<!-- domain: ran -->

# 5G条件切换（CHO）信令机制全链拆解

## 一、为什么需要CHO：传统切换的"信令赛跑"困境

在5G NR Release 15的基线切换（Legacy Handover）流程中，切换的"决定时刻"和"执行时刻"是被**网络严格串行绑定**的：源gNB收到UE的`MeasurementReport`后，先做切换决策，再向目标gNB发起资源准备（HO Request），等目标侧ACK回来，才把一条携带`reconfigurationWithSync`的`RRCReconfiguration`（即HO Command）下发给UE。UE收到命令后必须**立即**中断源链路、同步到目标小区并完成随机接入。

这套机制在FR1（Sub-6GHz）、中低速场景下表现良好，但在两类场景下会暴露出致命弱点，这也是3GPP在 **Release 16** 中引入条件切换（Conditional Handover, CHO）的直接动因：

1. **高速移动场景（高铁、高速公路）**：从"测量上报"到"HO Command下发"之间存在几十到上百毫秒的信令往返时延。在此期间UE仍在高速远离源小区、靠近目标小区，等命令真正到达时，源链路可能已经恶化到无法可靠接收命令本身，导致**HO Command丢失**或**RLF（Radio Link Failure）发生在切换执行之前**。
2. **FR2（毫米波）波束脆弱性场景**：高频段遮挡导致的信号衰落极其陡峭（一步之遥RSRP可跌落20dB以上），切换信令窗口稍纵即逝，传统"先准备、后同步"的串行流程来不及响应。

CHO的核心设计思想，是把切换的**准备阶段（Preparation）**与**执行阶段（Execution）**在时间上**彻底解耦**：源gNB提前为UE准备好一个或多个候选目标小区（candidate cell）的完整切换配置，连同"何时切换"的**执行条件（Execution Condition）**一起下发给UE，然后由**UE自主判断**何时触发切换执行。网络把"何时切"的决策权下放给最清楚链路实时状态的UE，从根本上消除了"信令赛跑"。

## 二、CHO的三个阶段：解耦的代价与收益

CHO流程在 **TS 38.300 Section 9.2.3.2** 与 **TS 38.331 Section 5.3.5.5** 中定义，完整生命周期分为三个阶段：**准备（Preparation）→ 配置下发与条件评估（Configuration & Evaluation）→ 执行与完成（Execution & Completion）**。

### 2.1 完整信令时序图

```mermaid
sequenceDiagram
    participant UE
    participant SgNB as 源gNB(Source)
    participant TgNB1 as 候选gNB-1(Target)
    participant TgNB2 as 候选gNB-2(Target)
    participant AMF

    Note over UE,TgNB2: 阶段一：CHO准备
    UE->>SgNB: MeasurementReport (Event A3触发)
    SgNB->>SgNB: 决策发起CHO，选定候选小区集
    SgNB->>TgNB1: XnAP/NGAP: HANDOVER REQUEST
    SgNB->>TgNB2: XnAP/NGAP: HANDOVER REQUEST
    TgNB1->>SgNB: HANDOVER REQUEST ACKNOWLEDGE<br/>(含candidate-1的HO Command)
    TgNB2->>SgNB: HANDOVER REQUEST ACKNOWLEDGE<br/>(含candidate-2的HO Command)
    SgNB->>SgNB: 组装condReconfigToAddModList<br/>+ condExecutionCond

    Note over UE,SgNB: 阶段二：配置下发与条件评估
    SgNB->>UE: RRCReconfiguration<br/>(condReconfigToAddModList: 2个候选+执行条件)
    UE->>UE: 存储至VarConditionalReconfig(不立即执行)
    UE->>SgNB: RRCReconfigurationComplete
    Note over UE: 持续评估A3执行条件(TTT计时)

    Note over UE,TgNB1: 阶段三：执行与完成(条件满足)
    UE->>UE: candidate-1满足条件且持续TTT
    UE->>UE: 选中candidate-1，丢弃candidate-2配置
    UE->>TgNB1: 应用reconfigurationWithSync<br/>发起RACH(msg1-msg4)
    UE->>TgNB1: RRCReconfigurationComplete
    TgNB1->>AMF: PATH SWITCH REQUEST (NGAP)
    AMF->>TgNB1: PATH SWITCH REQUEST ACKNOWLEDGE
    TgNB1->>SgNB: UE CONTEXT RELEASE (XnAP)
    Note over SgNB: 释放源小区为CHO预留的资源
```

关键差异在于：传统切换中，步骤"下发RRCReconfiguration"与"UE发起RACH"是紧邻的；而在CHO中，两者之间插入了一个**不定长的条件评估窗口**——这个窗口可能持续数毫秒到数秒，完全取决于无线环境的演化。这正是"解耦"的本质。

### 2.2 准备阶段：为什么是"一对多"

传统HO Request是一对一的，CHO的HO Request则是**一对多**的：源gNB可以同时向多个候选gNB发起`HANDOVER REQUEST`，每个候选gNB独立完成准入控制（Admission Control）、分配C-RNTI、专用preamble、DRB配置等资源，并通过`HANDOVER REQUEST ACKNOWLEDGE`返回各自的HO Command。

这里有一个重要的资源预留权衡：候选小区越多，切换鲁棒性越高（UE有更多备选），但每个候选gNB都要预留一份无线资源和上下文，**占用的资源是 N 倍**。因此源gNB的候选小区选择算法需要在"鲁棒性"与"资源效率"间取折衷，典型策略是配置1～3个候选小区，优先选择信号强度梯度最优的若干邻区。

## 三、关键IE解析：CHO配置长什么样

CHO配置承载于`RRCReconfiguration`消息中，其核心结构定义在 **TS 38.331 Section 6.3.5（RRCReconfiguration-IEs）**。理解以下IE是协议开发与抓包分析的基础。

### 3.1 IE结构图

```mermaid
flowchart TD
    A["RRCReconfiguration<br/>(消息根)"] --> B["condReconfigToAddModList<br/>条件重配列表"]
    A --> C["measConfig<br/>测量配置"]
    A --> D["secondaryCellGroupConfig<br/>(辅小区组,可选)"]

    B --> E["CondReconfigToAddMod"]
    E --> E1["condConfigId<br/>条件配置标识"]
    E --> E2["condExecutionCond<br/>执行条件"]
    E --> E3["rrcReconfigAddMod<br/>候选小区完整重配"]

    E2 --> E2a["condExecutionCond-r16"]
    E2a --> E2a1["measId<br/>引用测量对象+报告配置"]
    E2a --> E2a2["rsType: ssb / csi-rs"]

    E3 --> E3a["reconfigurationWithSync<br/>(含spCellConfig、T304等)"]
    E3 --> E3b["delta配置(相对源小区)"]

    C --> C1["measObjectToAddModList<br/>(邻频/邻区)"]
    C --> C2["reportConfigToAddModList<br/>(Event A3/A5参数)"]
    C2 --> C2a["reportConfigId"]
```

### 3.2 关键IE说明表

| IE名称 | 所在章节 | 作用说明 | 典型取值/语义 |
|--------|----------|----------|---------------|
| `condReconfigToAddModList` | 38.331 §6.3.5 | 携带一个或多个候选小区的条件重配置 | 列表长度=候选小区数，至少1项 |
| `condConfigId` | 38.331 §6.3.5 | 唯一标识一条条件配置，用于后续增删改/评估 | 整数，UE在`VarConditionalReconfig`中按此索引存储 |
| `condExecutionCond` | 38.331 §6.3.5 | 定义"何时切换"的触发条件 | 通过`measId`引用报告配置(Event A3/A5)，可AND/OR组合 |
| `rrcReconfigAddMod` | 38.331 §6.3.5 | 候选目标小区的完整RRC重配 | 内含`reconfigurationWithSync`(同步到目标) |
| `reconfigurationWithSync` | 38.331 §6.3.5 | 目标小区同步所需全部参数 | 含`spCellConfigCommon`(SSB位置)、新C-RNTI、`t304`定时器 |
| `t304` | 38.331 §6.3.5 | 切换执行(RACH)的超时定时器 | 枚举值(ms): 50/100/200/500/1000/2000 |
| `measConfig` | 38.331 §6.3.2 | 测量对象与报告配置 | `condExecutionCond`中的`measId`必须在此列表中有对应定义 |
| `VarConditionalReconfig` | 38.331 §5.3.5.5 | UE侧存储CHO配置的内部变量 | 持久保存候选配置直到执行或被释放 |

**设计意图剖析**：注意`condExecutionCond`并不直接内嵌A3偏移参数，而是通过`measId`**间接引用**`measConfig`中的`reportConfig`。这种间接引用设计使得同一个测量配置既可用于常规周期/事件测量上报，又可复用为CHO执行条件，避免了参数重复定义，也保证了CHO评估与常规测量使用**完全一致的测量量与滤波参数**，保证触发一致性。

## 四、执行条件评估：把Event A3公式交给UE

CHO执行条件本质上是把传统测量上报事件的判据，从"触发上报"改写为"触发切换执行"。最常用的是**Event A3（邻区优于服务小区一个偏移量）**。

### 4.1 Event A3进入条件公式

Event A3的进入条件（TS 38.331 §5.5.4）：

$$Mn + Ofn + Ocn - (Ms + Ofs + Ocs) > Off + Hys$$

离开条件：

$$Mn + Ofn + Ocn - (Ms + Ofs + Ocs) < Off - Hys$$

其中各参数含义：

| 参数 | 含义 |
|------|------|
| Mn | 邻区（候选目标）测量量（RSRP/RSRQ/SINR） |
| Ms | 服务小区测量量 |
| Ofn/Ofs | 邻区/服务小区的频率特定偏移 |
| Ocn/Ocs | 邻区/服务小区的小区特定偏移（CIO） |
| Off | A3偏移（a3-Offset） |
| Hys | 迟滞（Hysteresis） |
| TTT | Time-to-Trigger，条件需持续满足的时长 |

**进入与离开都需要满足TTT**，这是防止乒乓的关键机制。在CHO语境下，TTT必须谨慎设置：太短则易误触发（候选小区瞬时峰值），太长则失去CHO"提前准备、及时触发"的优势。

### 4.2 UE侧条件评估状态机

```mermaid
stateDiagram-v2
    [*] --> 存储CHO配置: 收到RRCReconfiguration(含condReconfig)
    存储CHO配置 --> 持续评估: 回RRCReconfigurationComplete
    持续评估 --> 持续评估: 无候选满足条件
    持续评估 --> 条件满足计时: 某候选满足A3进入条件
    条件满足计时 --> 持续评估: TTT内条件离开(乒乓抑制)
    条件满足计时 --> 执行切换: 持续满足达TTT
    执行切换 --> RACH成功: T304内完成随机接入
    执行切换 --> 切换失败处理: T304超时/RLF
    RACH成功 --> RRCReconfigComplete: 向目标gNB上报完成
    RRCReconfigComplete --> [*]: 切换完成,释放源资源
    切换失败处理 --> RRCReestablishment: 无其他候选/配置不允许
    切换失败处理 --> 执行切换: 选择另一未触发候选(若支持)
```

### 4.3 评估的关键约束（TS 38.331 §5.3.5.5.1）

- **一次只评估并执行一个候选**：即便多个候选同时满足条件，UE也只能选择一个执行（通常选`condConfigId`最小的或信号最优的），其余候选配置在选择瞬间即被**丢弃**。
- **配置持久性**：CHO配置存储在`VarConditionalReconfig`中，**不随服务小区质量波动而清除**，只在实际执行切换、收到新的重配或RRC释放时才删除。
- **与常规切换命令的优先级**：若CHO已配置但条件尚未满足，源gNB仍可下发一条传统HO Command（不携带条件配置），此时UE应**立即执行**该HO命令并丢弃所有CHO配置——这是网络保留的"应急接管"手段。

## 五、执行与完成：T304的生死线

当某候选的执行条件持续满足TTT后，UE进入执行阶段：

1. **应用同步配置**：UE应用选中候选的`reconfigurationWithSync`，获取目标小区SSB位置、新C-RNTI、专用PRACH preamble等。
2. **发起随机接入**：UE向目标小区发起基于非竞争（或回退到竞争）的随机接入。
3. **启动T304**：同步开始即启动`t304`定时器，作为整个执行阶段的硬性超时门限。
4. **上报完成**：RACH成功、上行同步建立后，UE向**目标gNB**发送`RRCReconfigurationComplete`。
5. **路径切换**：目标gNB向AMF发起`PATH SWITCH REQUEST`（NGAP），完成下行数据路径从源到目标的切换，并触发源gNB的`UE CONTEXT RELEASE`。

### 5.1 CHO的失败恢复机制（TS 38.331 §5.3.5.5.2）

这是CHO相比传统切换的又一鲁棒性来源。当切换执行失败（T304超时、随机接入失败或RLF），UE的行为取决于配置：

- **若还有未触发的CHO候选且配置允许**：UE可选择下一个候选继续尝试（前提是源链路也已无法维持，即发生RLF场景下的特殊处理）。
- **常规失败**：UE发起**RRC Connection Re-establishment**。注意，由于CHO在准备阶段就解除了"HO Command丢失"风险，CHO的失败更多发生在物理层（如目标小区瞬时遮挡导致RACH失败），而非命令传输层。

## 六、CHO vs 传统切换 vs DAPS：三维对比

```mermaid
flowchart LR
    subgraph Legacy["传统切换(同步串行)"]
        L1["测量上报"] --> L2["网络决策+准备"] --> L3["下发HO Cmd"] --> L4["UE立即同步"]
        L4 -.可丢失.-> L5["命令传输窗口脆弱"]
    end
    subgraph CHO["CHO(准备与执行解耦)"]
        C1["测量上报"] --> C2["网络准备多候选"] --> C3["下发配置+条件"]
        C3 --> C4["UE自主评估"]
        C4 -->|条件满足| C5["立即同步(命令早已就位)"]
    end
```

| 对比维度 | 传统HO (R15) | CHO (R16) | DAPS HO (R16) |
|----------|--------------|-----------|---------------|
| 决策方 | 网络 | UE(基于网络预设条件) | 网络 |
| 命令时机 | 执行前即时下发 | 提前下发,UE等待条件 | 执行前即时下发 |
| 命令丢失风险 | 高(高速/FR2场景) | 极低(命令已预存) | 高 |
| 中断时间 | 常规(数十ms) | 常规(类似Legacy) | 趋近0ms |
| UE复杂度 | 低 | 中(需存储多配置) | 高(双协议栈并发) |
| 资源开销 | 1x | Nx(N个候选预留) | 2x(双链路) |
| 核心目标 | 基础移动性 | **提升HO成功率** | **降低中断时延** |
| 典型场景 | 普通商用 | 高铁/FR2/高速移动 | URL CC/零中断业务 |

需要强调：CHO与DAPS**并非二选一的对立关系，而是解决不同痛点的互补技术**——CHO提升的是切换**可靠性**（降低失败率），DAPS提升的是切换**连续性**（降低中断时延）。两者在Release 16中同步引入，后续Release中还可组合使用。
## 八、从R16到R18：CHO的持续演进

CHO在R16引入后持续增强，这也是理解其完整生命周期的关键：

- **Release 16**：引入CHO基础框架，仅支持**intra-NR、intra-CU**的同频/异频切换。
- **Release 17**：扩展CHO至**inter-CU场景**（候选小区跨不同gNB-CU），并支持CHO与LTM（L1/L2 Triggered Mobility）的协同，进一步降低切换时延。
- **Release 18**：CHO进一步增强，包括**CHO与DAPS组合**、更灵活的执行条件（支持基于L1-RSRP的快速触发）、以及CHO在NTN（非地面网络）等新场景的适配。R18还在候选配置管理、失败恢复（CHO失败后选择其他候选）方面做了细化，提升了CHO在极端移动场景（如飞机NTN链路）下的鲁棒性。

这种"分阶段增强"的策略体现了3GPP一贯的演进哲学：先用一个最小可行框架解决最紧迫的成功率问题，再逐步覆盖更复杂的部署场景。

## 常见问题

**Q1: CHO与传统切换的根本区别是什么？**
A: 传统切换是"网络决定、立即执行"的串行流程，命令下发与执行紧耦合，命令传输窗口脆弱；CHO是"网络提前准备、UE自主决定何时执行"的解耦流程，切换配置预先下发并存储在UE，由UE根据预设条件（Event A3等）自主触发，从架构上消除了HO Command在切换窗口丢失的风险，显著提升高速/FR2场景的切换成功率。

**Q2: CHO的执行条件必须用Event A3吗？**
A: 不是必须，但Event A3最常用。`condExecutionCond`通过`measId`引用`reportConfig`，理论上可关联任何测量事件（A3、A5等），也可用AND/OR逻辑组合多个条件。Event A3（邻区优于服务小区一个偏移）因语义最贴近"应该切换"而被默认采用；A5（服务小区变差且邻区变好）适用于双门限控制密集城区。`rsType`还可指定基于SSB或CSI-RS的测量量。

**Q3: UE存储多个CHO候选配置会不会很占内存？**
A: 确实存在UE存储与处理开销。每个候选的`rrcReconfigAddMod`是一份完整的delta配置，UE需在`VarConditionalReconfig`中逐一存储并持续评估。这限制了实际可配置的候选数量（标准定义`maxNrofCHO-Configuration`），商用部署通常控制在2～3个，在鲁棒性与终端复杂度间取平衡。

**Q4: CHO切换执行失败后怎么办？**
A: 分两种情况（TS 38.331 §5.3.5.5.2）：若失败后源链路也已不可用（发生RLF）且仍有未触发的候选，UE可选择下一个候选继续尝试；否则UE发起RRC Connection Re-establishment。由于CHO的命令早已预存，其失败多源于物理层（目标小区瞬时遮挡致RACH失败），而非命令传输问题，因此失败恢复的触发场景与传统HO有本质区别。

**Q5: 既然有CHO为什么还需要DAPS？**
A: 两者解决不同问题：CHO提升切换**可靠性**（降低失败率），通过预存命令消除"命令丢失"，但中断时延仍与传统HO相当；DAPS提升切换**连续性**，通过双协议栈并发实现趋近0ms中断，但命令仍是即时下发。CHO适合高速移动、FR2等需高成功率的场景，DAPS适合URLLC等零中断业务。R18支持两者组合，可同时获得高可靠与低中断。

## 参考来源

1. [3GPP TS 38.331 V16.20.0 - NR; Radio Resource Control (RRC)](https://www.etsi.org/deliver/etsi_ts/138300_138399/138331/16.20.00_60/ts_138331v162000p.pdf) — §5.3.5.5 Conditional reconfiguration, §6.3.5 RRCReconfiguration-IEs, §5.5.4 Measurement events (Event A3)
2. [ShareTechnote - 5G/NR CHO (Conditional Handover)](https://www.sharetechnote.com/html/5G/5G_CHO.html) — CHO流程图与执行条件解读
3. [wirelessbrew - Conditional Handover (CHO) in 5G NR Release 16](https://wirelessbrew.com/5g-nr/conditional-handover-in-5g-nr-release16/) — CHO原理与准备/执行阶段分析
4. [arXiv:2403.04379 - Performance evaluation of conditional handover in 5G systems](https://arxiv.org/abs/2403.04379) — CHO性能评估与移动场景增益分析
5. [3glteinfo - 5G Conditional Handover Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g/conditional-handover/) — CHO完整信令流程与XnAP/NGAP交互
6. [Techplayon - 5G NR Conditional Handover (CHO)](https://www.techplayon.com/conditional-handover-cho/) — 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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)