<!-- title: 条件切换：消除切换的时间赛跑 -->

# 条件切换（CHO）：5G 如何把切换扳机交给手机自己

> 本文是「移动性管理原理」系列第 3 轮。前面我们拆解了寻呼、TAU、切换流程、测量事件 A3、Xn 切换等"经典动作"。这一篇，我们把镜头拉近到一个更微妙的问题：**传统切换为什么会在高速、高频段场景下频繁失败？5G 又用什么样的机制从根上化解它？** 答案就是 R16 引入的**条件切换（Conditional Handover，CHO）**。

---

## 一、从一个真实场景说起：高铁上的"切换丢人"

想象你坐在时速 350 公里的高铁上，正和朋友视频通话。列车穿过一个隧道口的瞬间，手机上的信号格子从 4 格跳到 1 格，然后通话中断了——这不是运营商"小气"不给你信号，而是**切换来晚了**。

在通信工程师的语言里，这叫 **too-late handover（过晚切换）**：网络还没来得及把你的连接搬到下一个小区，当前小区的信号就已经塌方，手机跟丢了。

为了理解 CHO 为什么出现，我们必须先看清传统切换到底卡在哪。

## 二、传统切换的"时间赛跑"困境

### 2.1 一场被时间绑架的接力赛

传统切换（5G 里叫 baseline handover，本质是 RRC 同步重配）可以拆成一句口诀：**"测量—上报—决策—下令—执行"**。这五个动作必须**串行**完成，而前四个都依赖当前服务小区的链路还活着。

用一张时序图看清楚这条"接力链"在哪里容易断：

```mermaid
sequenceDiagram
    participant UE as 手机(UE)
    participant S as 源gNB
    participant T as 目标gNB

    Note over UE,S: 阶段0:链路正在快速恶化...
    UE->>S: ① 测量报告(发现邻区更好)
    Note right of S: ② 源gNB决策,选目标
    S->>T: ③ HO Request(请求准入)
    T-->>S: ④ HO Request Ack(资源预留)
    S->>UE: ⑤ HO Command(切换命令)
    Note left of UE: ⑥ UE收到命令才执行切换

    rect rgba(255,80,80,0.15)
    Note over UE,S: 危险窗口:从①到⑤全程依赖源链路<br/>若此刻信号已塌方→RLF(无线链路失败)
    end
```

这张图里藏着一个致命的**依赖链**：从测量报告上报（①），到切换命令成功送达（⑤），中间任何一刻源小区链路断了，整个流程就崩盘。问题是，**手机最需要切换的时候，恰恰是源链路最差的时候**——这是传统切换无法回避的内在矛盾。

### 2.2 三种典型翻车姿势

业界把切换失败的典型形态归为三类，它们都和"时间赛跑"直接相关：

| 失败类型 | 发生时机 | 根因 |
|---------|---------|------|
| **过晚切换（too late）** | RLF 发生在切换命令之前 | 决策慢，信号塌方时命令还没到 |
| **过早切换（too early）** | 切换刚完成又掉回原小区 | 触发太激进，乒乓效应 |
| **切到错小区（to wrong cell）** | 目标选择错误 | 测量上报有滞后，选了瞬时最优而非稳定最优 |

### 2.3 为什么 5G 让这个问题更尖锐

| 维度 | 4G LTE | 5G NR |
|------|--------|-------|
| 典型频段 | 低频（700M~2.6G） | 中频 + **毫米波/FR2（28G以上）** |
| 小区半径 | 较大（数百米~公里） | 更小（尤其是高频/微站） |
| 信号变化速率 | 相对平缓 | **极快**（绕过一根柱子就可能掉 20dB） |
| 切换频率 | 较低 | **显著升高** |

简单算一笔账：当信号以每秒 30dB 的速度下跌时，留给"测量—决策—下令"的整个信令预算可能只有 **几十到几百毫秒**。而传统切换端到端的空口+回传时延，往往就吃掉了这个预算的一大半。**余量为负，必败。**

这就逼出了一个反向思考：**既然"等链路差了再切"注定来不及，那能不能趁链路还好的时候，先把切换该办的事全部办完，只把"扣扳机"这一下留给最后一刻？**

这就是 CHO 的设计哲学。

## 三、CHO 的核心思想：把决策权下放给 UE

### 3.1 一句话定义

> **条件切换（CHO）**：网络提前把一个或多个候选目标小区的切换配置连同"执行条件"一起下发给 UE；UE 持续评估这些条件，**一旦某个候选满足条件，UE 自主执行切换，无需网络再发命令。**

关键转变可以用一个对比概括：

- **传统切换**："先下令，后执行"——执行与否、何时执行，由网络说了算。
- **条件切换**："先准备，后触发"——资源提前备好，**何时扣扳机由 UE 自己判断**。

### 3.2 类比理解：把登机牌提前打出来

传统切换像"到了机场再买票"——万一路上堵车（链路恶化），就赶不上飞机（切换失败）。

CHO 像"提前办好值机、打好登机牌、选好座位"，你只需要在**自己判断合适的时间**走向登机口（条件满足），登机口（目标小区）早已为你留好位置（资源预留）。哪怕你在候机厅多等一会儿也没关系，因为登机牌已经攥在手里了。

这个"提前备好资源 + 自主择机执行"的双解耦，正是 CHO 的全部精髓。

## 四、CHO 三阶段信令时序详解

CHO 把切换拆成**准备（Preparation）、执行（Execution）、完成（Completion）**三个清晰阶段。下面这张时序图是本文的核心，请仔细看每个阶段做了什么、谁主动：

```mermaid
sequenceDiagram
    autonumber
    participant UE as 手机(UE)
    participant S as 源gNB
    participant T1 as 候选gNB-1
    participant T2 as 候选gNB-2

    Note over UE,S: ═══ 准备阶段 Preparation ═══
    UE->>S: 测量报告(邻区列表)
    S->>T1: HO Request
    S->>T2: HO Request
    T1-->>S: HO Request Ack(预留C-RNTI/专用preamble)
    T2-->>S: HO Request Ack(预留资源)
    S->>UE: RRC Reconfiguration(CHO命令:<br/>含2个候选配置+各自执行条件)
    Note right of UE: UE保存配置,不切换,继续测量

    Note over UE,S: ═══ 执行阶段 Execution ═══
    Note left of UE: UE持续评估条件...<br/>候选-2满足A3事件+TTT
    UE->>T2: 专用preamble随机接入(RACH)
    T2-->>UE: 随机接入响应(TA调整)
    Note left of UE: UE同步到T2,单向下行,不回源

    Note over UE,T1: ═══ 完成阶段 Completion ═══
    UE->>T2: RRC Reconfiguration Complete
    T2->>S: HANDOVER SUCCESS(通知成功)
    S->>T1: CANCEL(释放候选-1预留资源)
    Note over S: 源gNB转发/清理用户上下文
```

逐阶段拆解这背后的"为什么"：

### 4.1 准备阶段：广撒网，先备好干粮

- **源 gNB 并行向多个候选小区发 HO Request**——这是 CHO 和传统切换最大的不同之一。传统切换通常只盯着一个目标；CHO 可以同时准备多个候选，相当于"撒网"。
- 每个候选目标都做**准入控制**，并预留关键资源：**C-RNTI（小区无线网络临时标识）、专用 preamble（随机接入前导）、上行授权**等。注意，此时资源处于"挂起/预留"状态，UE 还没真正接入。
- 源 gNB 把所有候选配置打包进**一条 RRC Reconfiguration**（即 CHO command）下发给 UE。**这条命令必须在源链路还好的时候送达**——这正是 CHO 把"时间赛跑"化解掉的关键一步。

> 💡 **为什么强调"链路还好的时候发"？** 因为传统切换失败的高发点就是"命令发不出去/收不到"。CHO 把这条最脆弱的命令**前移**到信号好的时段，从根上消除这个失败模式。

### 4.2 执行阶段：UE 自主择机扣扳机

- UE 收到 CHO 命令后**不立即切换**，而是挂上候选配置，继续在源小区正常通信、持续测量。
- 当某个候选小区的**执行条件**被满足（典型是 A3 事件 + 触发时间 TTT），UE 立刻向该候选发起**随机接入**，用的是提前预留好的专用 preamble，所以接入又快又不会和别人撞车。
- **一旦开始执行，UE 不会再回头等源小区**——这是 CHO 的一条铁律（下文详解）。

### 4.3 完成阶段：善后与回收

- UE 在目标侧完成 RACH、发送 **RRC Reconfiguration Complete**，切换完成。
- 目标 gNB 通知源 gNB 切换成功，源 gNB 随后**取消（cancel）其他候选小区的预留资源**，避免资源白白占着。
- 上下文、转发数据随之清理（数据转发机制与 Xn 切换类似，此处不展开）。

## 五、执行条件详解：UE 用什么标准"扣扳机"

UE 拿到的每个候选配置里，都绑着一个"执行条件"。条件本质上是**一个或多个测量事件的组合**，配合迟滞（Hysteresis）和触发时间（TTT）两个"防抖"参数。

### 5.1 三种最常用的执行条件事件

| 事件 | 触发含义 | CHO 中常用场景 |
|------|---------|---------------|
| **A3** | 邻区质量比服务小区**高出偏移量** | 最常用，相对判决"谁更好" |
| **A4** | 邻区质量**高于绝对门限** | 用于覆盖受限、找强信号 |
| **A5** | 服务小区**低于门限** 且 邻区**高于门限** | 双条件，适合边缘/恶化场景 |

### 5.2 用公式看 A3 事件的"进出门"

以最常用的 A3 为例，UE 进入触发状态的条件（用 RSRP 衡量）：

$$M_n + O_{fn} + O_{cn} - H_{ys} > M_p + O_{fp} + O_{cp} + O_{ff}$$

离开触发状态（取消）的条件：

$$M_n + O_{fn} + O_{cn} + H_{ys} < M_p + O_{fp} + O_{cp} + O_{ff}$$

其中：

- $M_n$：邻区（候选目标）测量值
- $M_p$：服务小区测量值
- $H_{ys}$：迟滞，防止在临界点反复横跳
- $O_{ff}$：A3 偏移量，控制切换"激进/保守"
- $O_{fn}, O_{fp}$：频率特定偏移（异频时才有意义）
- $O_{cn}, O_{cp}$：小区特定偏移（可对特定邻区加权）

> **关键直觉**：$H_{ys}$（迟滞）让"进入"门槛高于"离开"门槛，形成一个**死区**——信号在死区里抖动时，UE 不会一会儿触发一会儿取消。配合 TTT（条件必须**持续**满足若干毫秒才生效），就构成了双重防抖，专门用来压制乒乓效应。

### 5.3 多条件与多候选的灵活组合

CHO 允许给一个候选配置多个执行条件（"任一满足即触发"），也允许给 UE 配多个候选。这就形成一个"**谁先达标先切谁**"的并发评估逻辑：

```mermaid
flowchart TD
    A[UE持有CHO配置:<br/>候选1,候选2,候选3] --> B{持续并行评估各候选条件}
    B -->|候选1满足 A3+TTT| C1[执行→候选1]
    B -->|候选2满足 A4+TTT| C2[执行→候选2]
    B -->|候选3满足 A5+TTT| C3[执行→候选3]
    B -->|多个同时满足| D{按配置优先级选择}
    D --> C1
    C1 --> E[执行成功后,丢弃其余候选配置]
    C2 --> E
    C3 --> E
    E --> F[网络侧释放其他候选预留资源]
    style C1 fill:#cfe8d8
    style E fill:#fde2cf
```

这种"广撒网 + 抢答式执行"的设计，在覆盖复杂、信号跳变剧烈的场景（如 FR2 高频、室内微站、高铁）特别有效——**无论哪个候选最先达标，UE 都能第一时间切过去**，而不是死等一个可能永远不达标的目标。

## 六、CHO 的铁律：执行是"单程票"

这是 CHO 最容易被误解、但工程上最关键的一条性质：

> **一旦 UE 开始执行 CHO（向某个候选发起随机接入），就不再回头评估源小区，也不会切换到其他候选。这是一张"单程票"。**

为什么这么设计？

- 如果允许"半途反悔"，UE 在切换中途返回源小区，会造成**源侧上下文状态混乱**、数据错乱。
- 任意性越小，行为越可预测，网络侧的资源管理和计数才不会乱。

这带来的**重要推论**是：CHO **不能**被网络"中途撤销后让 UE 老老实实待在源小区"——网络要中止一个未执行的 CHO，必须通过新一轮 RRC 重配来更新或释放配置。所以 CHO 的可靠性，本质上押注在"准备阶段把候选选对"上。如果候选小区本身就有问题，UE 执行后会 RLF，进入 RRC 重建流程（前面文章讲过 RRC 重建正是掉线手机的自救术）。

## 七、CHO vs 传统切换：一表看清差异

| 维度 | 传统切换（baseline） | 条件切换（CHO） |
|------|---------------------|-----------------|
| **决策主体** | 网络（gNB） | **UE 自主**（按预设条件） |
| **执行时机** | 收到命令立即执行 | **条件满足后才执行** |
| **命令下发时机** | 链路已变差时 | **链路仍好时提前下发** |
| **候选目标数** | 通常 1 个 | **可多个并发准备** |
| **链路突变鲁棒性** | 差，易 RLF | **强**，化解过晚切换 |
| **乒乓抑制** | 依赖 A3 参数调优 | **迟滞 + TTT + 多候选**多重抑制 |
| **空口信令开销** | 每次切换一整套 | 准备提前，执行期信令更少 |
| **失败回退** | 切换失败→重建 | 单程票，失败→重建 |
| **典型场景** | 一般移动、低频大站 | **高频/高速/密集微站/边缘** |

## 八、CHO vs DAPS：5G 移动性增强的"两兄弟"

R16 还引入了另一个明星机制 **DAPS（Dual Active Protocol Stack，双激活协议栈）切换**，初学者很容易和 CHO 搞混。它们的出发点不同、解决的问题也不同，最好放在一起对比理解：

```mermaid
flowchart LR
    subgraph 传统切换
      A1[源链路] -- 切换瞬间 --> A2[空窗] --> A3[目标链路]
    end
    subgraph CHO
      B1[源链路<br/>+提前下发配置] --> B2[UE自决<br/>择机切走] --> B3[目标链路]
    end
    subgraph DAPS
      C1[源链路] --> C2[源+目标<br/>双链路并行] --> C3[断源留目标]
    end
    style A2 fill:#ffd6d6
    style C2 fill:#d6e8ff
```

| 维度 | 条件切换 CHO | DAPS 双激活协议栈 |
|------|-------------|------------------|
| **核心思想** | 提前准备 + 条件触发 | 切换期间**同时保持源+目标两条链路** |
| **中断时延** | 减小（准备提前）但仍是单链路切换 | **趋近零中断**（双链路重叠） |
| **解决的主要痛点** | 过晚切换、命令丢失、乒乓 | **中断时延、数据转发连续性** |
| **UE 复杂度** | 中（需并发评估多条件） | **高**（需双套收发/协议栈） |
| **触发方式** | UE 按条件自主触发 | 网络下令，UE 双链路工作 |
| **典型场景** | 高频/高速/移动鲁棒性 | **URLLC、对时延零容忍业务** |
| **可否组合** | ✅ 可以 | ✅ 可以（DAPS + 条件执行 = 双重增益） |

一句话区分：**CHO 解决"切得对、切得稳"，DAPS 解决"切得快、不断流"。** 两者还能组合使用——用 DAPS 的双链路保障零中断，再用 CHO 的条件触发决定何时切，鱼与熊掌兼得。

## 九、实战连接：工程师调试时会撞上什么

理论讲到这，落到现网和调测台，CHO 在哪些地方会被你"摸到"？

### 9.1 看日志：找 CHO 的"指纹"

在 UE 侧 log 或 gNB 侧信令跟踪里，CHO 的标志是 RRC Reconfiguration 里出现 **`condReconfigToAddModList`**（条件重配列表），每个条目带一个 `condExecutionCond`（执行条件）。只要看到这个 IE，就知道这条重配是 CHO 命令而非普通切换。

### 9.2 常见调测陷阱

1. **"配了 CHO 却一直不切"** —— 多半是执行条件设得太严（A3 偏移 $O_{ff}$ 过大、TTT 过长），候选小区虽然变好但始终进不了触发门。调试时先核对 A3 公式里各偏移量的实际取值。
2. **"切过去马上又掉"** —— 候选目标小区本身准入有问题或资源不足。CHO 把扳机交给 UE，但**候选选得对不对**仍是源 gNB 的责任，这部分要回看准备阶段的 HO Request Ack 是否正常、目标侧负载如何。
3. **"多候选资源占用过高"** —— CHO 广撒网会临时占用多个候选的资源。候选数配得过多、取消不够及时，会造成目标侧资源浪费，需要平衡候选数与资源开销。
4. **误以为 CHO 能"反悔"** —— 调试时若想模拟"切到一半回退"，要清楚 CHO 是单程票，这种场景实际会走 RRC 重建，别在日志里找不到"CHO cancel by UE"而困惑。

### 9.3 移动鲁棒性优化（MRO）的搭档

现网里，过晚/过早/错小区切换的自动识别与参数自愈，由**移动鲁棒性优化（MRO）**这套自组织网络（SON）机制负责。CHO 与 MRO 是互补关系：MRO 负责调对参数（TTT、迟滞、偏移），CHO 负责在参数给定后把执行做得更稳。两者结合，才是 5G 高速移动不掉话的完整答案。

## 十、一句话总结

CHO 的全部智慧，可以用一个公式化的判断浓缩：

$$\text{切换可靠性} = \underbrace{\text{准备充分}}_{\text{提前下发+多候选}} \times \underbrace{\text{触发精准}}_{\text{UE自决+条件+TTT}}$$

它没有发明新的空口技术，而是**重新分配了"何时由谁做决定"的责任**——把最脆弱的"下令"环节前移到链路好的时候，把"执行"的主动权交给离信号最近、反应最快的 UE。这种**用机制设计换时间裕量**的思路，正是 5G 应对高频段、高速移动挑战的核心范式之一。

---

## 常见问题

**Q1：CHO 和测量事件 A3 是什么关系？A3 不是一直在用吗？**
A：A3 是一种**测量事件**（描述"邻区比服务小区好多少"的判据），传统切换和 CHO 都用它。区别在于**谁基于 A3 做决定**：传统切换里，UE 上报 A3，由 gNB 决策并下令；CHO 里，A3 作为执行条件**直接交给 UE**，UE 满足 A3+TTT 就自主切换，不再等网络下令。

**Q2：CHO 配了多个候选，如果两个候选同时满足条件怎么办？**
A：网络在配置时会为候选设置优先级/顺序。当多个候选同时满足条件时，UE 按**配置中规定的优先级**选择一个执行，不会"双切"。执行成功后，其余候选配置被丢弃，网络侧释放对应资源。

**Q3：CHO 执行后如果目标小区也失败了，怎么办？**
A：因为 CHO 是单程票，UE 不会"回退"到源小区。如果目标侧也出问题导致 RLF，UE 会进入 **RRC 连接重建**流程（即"掉线手机的自救术"），尝试重新建立连接。这也是为什么 CHO 的准备阶段把候选选对至关重要。

**Q4：既然 DAPS 中断更小，为什么不全部用 DAPS，还要 CHO？**
A：DAPS 要求 UE 同时维持两套收发链路和协议栈，**终端复杂度、功耗、成本都高得多**，主要留给对时延零容忍的 URLLC 类业务。CHO 复杂度中等、普适性强，更适合作为高频/高速场景的"主力切换增强"。两者定位不同，且可以组合使用。

**Q5：4G LTE 能用 CHO 吗？**
A：可以。CHO 虽在 NR（R16）中成名，但同样的条件切换机制也适用于 E-UTRA（即 4G LTE）。运营商在 LTE↔NR 互操作、以及高铁等 LTE 覆盖场景中，也会部署 CHO 以提升切换鲁棒性。

---

## 参考来源

1. [5G NR Conditional Handover (CHO) — Techplayon](https://www.techplayon.com/conditional-handover-cho/) — CHO 在 NR R16 中的引入背景与基本流程的英文讲解。
2. [5G/NR CHO (Conditional Handover) — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_CHO.html) — 经典通信学习站，含 CHO 流程与信令图解。
3. [Conditional Handover in 5G: Principles, Future Use Cases and FR2 Performance（arXiv 预印本）](https://arxiv.org/abs/2204.01283) — 学术论文，系统阐述 CHO 原理、用例及高频段（FR2）性能分析。
4. [Rel-18 中的条件切换（CHO）增强实现原理讲解与分析 — 知乎](https://zhuanlan.zhihu.com/p/705449599) — 中文深度解读，覆盖 R16 基础与 R18 的多候选/多条件增强。
5. [5G NR 中的条件切换（CHO）— CSDN 博客](https://blog.csdn.net/kangzenghui_liu/article/details/141207584) — 中文实操向，含准备/执行/完成三阶段流程说明。
6. [What is Conditional Handover? — RF Essentials](https://rfessentials.com/resources/rf-glossary/conditional-handover/) — "准备与执行分离"核心定义的简明词条。

---
> 本文由「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)