---
标题: 先签好字再搬家：条件切换 CHO
作者: 爱卫生
封面: "[[封面1.png]]"
封面裁剪: false
原文地址:
打开评论: true
仅粉丝可评论: false
摘要: 高铁以350公里的时速掠过基站群，手机每隔十几秒就要完成一次小区交接。奇怪的是，掉话偏偏集中在交接的瞬间——网络明明“看到”了邻区变强，也按流程下了切换命令，链路还是断了。
---

# 先签好字再搬家：条件切换 CHO

<!-- title: 先签好字再搬家：条件切换 CHO -->

高铁以350公里的时速掠过基站群，手机每隔十几秒就要完成一次小区交接。奇怪的是，掉话偏偏集中在交接的瞬间——网络明明“看到”了邻区变强，也按流程下了切换命令，链路还是断了。这不是参数没调好，而是传统切换的机制里藏着一个结构性缺陷：**它总把最关键的一步，留到链路最脆弱的时刻才做。**

条件切换（Conditional Handover，业内通称CHO）就是冲着这个缺陷来的。它的思路说出来极简单：**把“签字”和“生效”拆开**——合同提前签好，触发条件一到自动生效，不再请示任何人。本文从传统切换的时间账算起，讲清楚CHO为什么这样设计、信令怎么走、代价是什么、现网调试要避开哪些坑。

## 一、先算一笔时间账：传统切换慢在哪

回顾一次传统切换，它是一条串行流水线：

1. **测量**：终端持续测量服务小区和邻区的信号；
2. **上报**：某个测量事件被触发（通常还要求条件持续满足一段“触发持续时间”，几十到几百毫秒），终端才发测量报告；
3. **判决与准备**：源基站决定切换，跨基站协商，目标基站做准入、预留资源；
4. **命令下发**：切换命令经空口发给终端，消息大时还要分段传输；
5. **执行**：终端断开源小区，向目标发起随机接入，网络再把数据通路改道。

整条流水线走完，通常是上百毫秒的量级。低速城区里这笔开销无伤大雅，但把手机放到高铁上，账就变了。

这里要先分清无线信号的**两个时间尺度**。慢变量是平均信号强度：它随手机离开基站的位置平滑下滑，时间尺度是秒级；快变量是深衰落和遮挡：多径相消、列车车身掠过、毫米波波束被手挡住，都能让信号在毫秒级时间内塌陷一二十个分贝。粗算一下：3.5吉赫兹频段、350公里时速下，多普勒频移约等于

$$f_d = \frac{v}{\lambda} \approx \frac{97\ \text{m/s}}{0.086\ \text{m}} \approx 1100\ \text{Hz}$$

对应信道起伏的相关时间只有毫秒量级。也就是说，**切换流水线是按“气候”（慢变量）做的决策，命令却要在一个“天气”（快变量）瞬息万变的环境里送达**。测量报告在上行变弱的路上发出，切换命令在下行变弱的路上返回，一旦命令送达的那一刻恰好撞上深衰落，终端收不全、校验不过，等它反应过来时源小区已经没了——切换失败，直接变成无线链路失败。

参数调优能缓解，但拧到极限就会撞墙：触发持续时间调小、偏移调小，切换确实变快了，代价是乒乓切换激增，两部基站之间来回倒腾，信令风暴反过来拖垮整片区域。**慢变量尺度上的机制，追不上快变量尺度上的风险——这就是传统切换在高速场景的天花板。**

## 二、切换失败的三种死法

工程上把切换失败归纳成三类，诊断时先对号入座：

```mermaid
flowchart TD
    A["切换为什么会失败"] --> B["过晚切换"]
    A --> C["过早切换"]
    A --> D["切错小区"]
    B --> B1["命令还没到 源链路先断"]
    B1 --> B2["掉线后重建"]
    C --> C1["刚切过去目标就塌"]
    C1 --> C2["掉回源侧重建"]
    D --> D1["切进覆盖洞或孤岛"]
    D1 --> D2["很快再次失败"]
```

| 失败类型 | 何时发生 | 典型现场 | 典型后果 | 条件切换能否缓解 |
|---|---|---|---|---|
| 过晚切换 | 命令还在路上，源链路已断 | 高速移动、小区边缘陡降 | 先掉线，再重建 | 正中靶心，首要设计目标 |
| 过早切换 | 切换完成，目标随即变差 | 目标是孤岛或覆盖洞 | 很快再失败，常弹回源 | 靠多候选兜底部分缓解 |
| 切错小区 | 测量混淆或邻区配置不当 | 邻区漏配、混乱的站间距 | 重建甚至掉话 | 靠合理的准备门限规避 |

注意一个关键事实：**高速场景的失败几乎全是“过晚”型**。而“过晚”不是哪个环节出了故障，恰恰是每个环节都正常工作的结果——只是每个环节都慢了一拍，加起来就输给了物理速度。这解释了为什么单纯调参救不了高铁：参数调优在“拧螺丝”，而机制本身需要“换结构”。

## 三、CHO的核心思想：把准备和执行拆开

传统切换里，“准备”和“执行”是背靠背的：网络先决定、再准备、再命令、终端立刻执行，四件事挤在同一时刻、共用一条正在变差的链路。

CHO做了一个干净利落的解耦——**准备提前到链路健康时完成，执行延后到条件满足时发生**。用一个买房的类比：

- **传统切换**像每次搬家都现走全流程：发现房价要涨→联系中介→看房→签约→拿钥匙。流程走到一半，旧房子先拆了，你只能在瓦砾上打电话报警（重建）。
- **CHO**像你提前把周边三套备选房**都签好了带生效条款的合同**：条款写明“只要旧房租金刚涨过你5%，我就自动搬进你家”，钥匙已经拿在手里。哪套条件先满足，你拎包就住哪套，全程不用再给任何人打电话。

这里面藏着一个更深的设计决策：**执行时刻的裁决权，从网络下沉到了终端**。为什么？因为在“哪一刻条件刚好满足”这件事上，手里握着实时测量的终端才是信息最充分的一方；网络看到的测量报告永远是过去时，等它加工完、决策完、再传回来，窗口可能已经关了。传统切换中“网络决定何时执行”，CHO里变成“网络决定准备什么，终端决定何时执行”——审批前置，放行本地化。

| 维度 | 传统切换 | 条件切换CHO | DAPS切换 |
|---|---|---|---|
| 准备时机 | 判决后临时准备 | 提前并行准备多个候选（最多8个） | 同传统，先准备 |
| 执行决策者 | 网络（命令一到就动） | 终端（条件满足即动） | 网络 |
| 执行时有切换命令吗 | 有 | 没有 | 有 |
| 执行瞬间与源小区 | 断开后再接目标 | 断开后再接目标 | 接目标的同时保持源 |
| 主要针对的痛点 | — | 过晚切换导致的失败 | 切换瞬间的数据中断 |
| 典型场景 | 城区低速 | 高铁、高速、毫米波 | 语音等时延敏感业务 |

顺带澄清一个最容易混的点：**CHO仍然是“先断后连”的硬切换**，它没有消灭断开瞬间，只是把决策时延压到了零；它也不是CDMA时代的软切换——软切换靠多条链路同时通信换取平滑，CHO靠把关键信令挪到安全时刻换取可靠性，两条完全不同的路。

## 四、信令流程：一份“待生效合同”怎么签

### 准备阶段：趁健康，一次签好几份

```mermaid
sequenceDiagram
    participant U as 手机
    participant S as 源基站
    participant A as 候选基站甲
    participant B as 候选基站乙
    U->>S: 测量报告（邻区渐强）
    S->>A: 切换准备请求（并行）
    S->>B: 切换准备请求（并行）
    A->>S: 同意并预留资源
    B->>S: 同意并预留资源
    S->>U: 重配置（候选配置加生效条件）
    U->>S: 配置完成确认
    Note over S,A: 待生效合同此时全部签妥
```

这一阶段有两个与传统切换截然不同的特征。第一，**准备是并行多份的**：源基站可以同时和多个候选基站走准备流程，每家都各自做准入、预留资源、生成一份完整的目标小区配置。一个终端最多可以携带8个候选——相当于同时握有8把备选钥匙。第二，**终端收到配置后并不执行**，只是存起来，继续留在源小区正常收发。这份“待生效合同”里写着三样东西：完整的目标配置、生效条件、以及为快速接入准备好的专用随机接入资源。

### 执行阶段：条件一到，自助放行

```mermaid
sequenceDiagram
    participant U as 手机
    participant S as 源基站
    participant A as 候选基站甲
    participant B as 候选基站乙
    U->>U: 本地评估 甲的条件满足
    U->>A: 向甲发起专用随机接入
    A->>U: 接入响应
    U->>A: 切换完成确认
    A->>S: 路径转换（数据改道）
    S->>B: 释放乙的预留资源
    Note over U: 条件满足后直达目标 无网络指令
```

终端在本地持续评估存好的生效条件，哪个候选先满足，就立刻用它携带的专用随机接入资源直奔该小区。从“条件满足”到“接入新小区”，**全程没有任何网络指令参与**——传统切换里最容易被衰落打断的那段往返信令，在这里被整个消灭了。终端开始向目标同步后就不再监测源小区；成功接入后，其余候选配置自动作废，源基站还会通知其余候选基站释放预留（这就是标准里所谓的“条件切换取消”）。

### 终端视角：一台小型状态机

```mermaid
flowchart TD
    S["收到候选配置"] --> W{"候选条件满足？"}
    W -->|否| K["留在源小区继续评估"]
    K --> W
    W -->|是| X["停止评估 向该候选发起接入"]
    X --> Y["其余候选配置自动作废"]
    S --> F["执行前发生链路失败"]
    F --> G["重建时若路过候选小区<br/>可直接用它恢复"]
```

右下这条分支值得单独说：如果链路在执行前就断了，“合同”会不会作废？标准的设计是留了一手——终端在重建时若发现可选小区恰好是某个已配置的候选，可以尝试直接用那份准备好的配置恢复连接，而不是退回漫长的完整重建。据公开发表的仿真研究，在毫米波频段的某些场景下，切换失败后依靠这套恢复机制挽回的比例能超过80%——本该发生的掉话，被提前签好的合同接住了。

## 五、生效条款怎么写：执行条件的原理

CHO的执行条件复用了测量事件这套“语言”，最常用的是两类：

**A3事件（相对比较）**：邻区变得比服务小区好出一定余量。进入条件是

$$M_n > M_s + \mathrm{Off} + \mathrm{Hys}$$

离开条件是

$$M_n < M_s + \mathrm{Off} - \mathrm{Hys}$$

其中 $M_n$、$M_s$ 分别是邻区和服务小区的测量结果（分贝域），Off是偏移，Hys是迟滞。三个量都在分贝域，比较的是“相对强弱”。此外条件必须**持续满足一段触发持续时间（TTT）**才算数，而送进判决的测量值还要先经过一层平滑滤波：

$$F_n = (1-\alpha)\,F_{n-1} + \alpha\,M_n,\qquad \alpha = \frac{1}{2^{k/4}}$$

滤波系数 $k$ 越大，曲线越平滑、越迟钝；越小越灵敏、越毛糙。

为什么执行条件偏爱A3这类**相对比较**，而不是“信号低于某个绝对门限”的单边条件？因为相对比较自带对共模衰落的免疫力：列车钻进隧道，服务小区和邻区一起变差，它们的“差值”基本不变，A3不会被误触发；而绝对门限类条件会被这种整体性波动搅得心神不宁。更保守的选择是A5事件——要求“服务小区跌破门限一 **且** 邻区升破门限二”两个条件同时成立，宁可不切，不乱切。一个执行条件还允许同时挂两个触发事件、并行评估多种测量量（信号强度、质量、信噪比），具体的灵活程度取决于终端上报的能力。

标准甚至把这个思路推得更远：在卫星通信这类场景里，信号强弱不再能反映“该不该切”（卫星是移动的，覆盖区整体漂移），于是出现了**基于位置、基于时间**的执行条件——“开到这个坐标就切”“到了这个时刻就切”。原理一以贯之：把“什么时候执行”写成一个终端可以本地判定的谓词。

## 六、代价与边界：天下没有白签的合同

CHO不是免费午餐，它的代价主要有三笔：

1. **资源预占的浪费**。8个候选都按正式切换的标准预留了资源和上下文，最后往往只有一个被用上，其余全是“占坑不入座”。这靠两条措施约束：一是合理控制候选数量与准备时机（准备太早，候选在终端用上之前就已过期；准备太晚，又失去提前量的意义）；二是取消机制兜底——切换完成后立即释放其余候选，必要时网络也可以主动撤销某个候选。
2. **参数空间翻倍**。原本一套切换参数，现在变成“什么情况下开始准备”（测量上报侧）与“什么情况下执行”（生效条件侧）两条线，各自有偏移、迟滞、TTT，组合空间成倍膨胀，调优工作量显著增加。
3. **对基站间接口的依赖**。CHO只支持基站之间直接协商的切换；需要核心网参与的基站间切换形态并不在支持范围内。换句话说，它是“邻里之间先签好约”，走不通邻里关系的场景用不上。

边界上还有两条容易踩线的：同一候选小区上，CHO配置**不能**与DAPS（双活协议栈）配置叠加使用——两者是并行的两种切换增强思路，不是可拼装的组合；另外，若网络在CHO待命期间下发了普通切换命令，**普通命令优先**，终端立即执行，不再等条件。此外，双向互通场景同样适用这套机制，它的适用面覆盖新空口与4G空口之间的互通切换。

## 七、现网与实战：哪里开、怎么调、别踩什么

**什么场景值得开CHO**？判断标准一句话：链路状态变化的速度，是否快到让“测量—上报—命令”这条往返链路变得不可靠。典型的是高铁、高速公路、地铁隧道这类高速移动场景；其次是毫米波部署——波束窄、距离短、对遮挡极度敏感，信号以毫秒级塌陷，传统切换的往返信令根本追不上；再就是工业控制、车联网这类“一次非计划掉线都嫌多”的高可靠场景——CHO虽然没有改善链路预算本身，但它把风险最大的信令挪到了时间轴上最安全的位置，这笔账对可靠业务非常划算。

**调试时最容易栽的五个坑**：

1. **统计口径变了**。CHO执行阶段没有切换命令，传统“命令下发→完成确认”的KPI统计口径对不上号，评估要改看候选小区的随机接入与路径转换。很多优化新手在这里得出“CHO成功率奇怪”的错误结论，其实是尺子用错了。
2. **两套参数要分家**。准备触发的A3与执行条件的A3是两条独立的线。执行条件的偏移如果照抄普通切换的典型值（如3分贝），在高速场景可能仍然偏晚；工程上常把执行条件配得更灵敏一些——因为执行的成本极低（只是随机接入），而错过执行的成本极高（掉话）。这是一条经验取向，不是标准规定。
3. **候选数量是资源杠杆**。候选拉满8个，等于沿线所有邻站都为一个终端占着资源；热点区域大量终端同时携带候选时，预占总量可观。候选数量的取舍本质是“保险费率”的取舍。
4. **“准备好却没用上”是诊断信号**。如果统计显示大量终端在携带候选配置期间发生重建，说明准备门限偏晚——合同签好了，但旧房子塌得比预期更早。
5. **别把CHO当不掉话的银弹**。它压缩的是“过晚”型失败，对“过早”和“切错”帮助有限；极端场景（基站间链路本身故障、孤岛小区）该失败还是会失败。

还有一个延伸方向值得知道：CHO这套“提前准备、自主执行”的原理，后来被推广到了双连接架构下的辅小区变更（业内称CPAC），以及把切换决策下沉到更低协议层的进一步演进——**把关键决策尽可能早地准备、尽可能晚地、在离信息最近的地方执行**，这已经是移动性管理的通用设计哲学，和计算领域“边缘计算”的思想殊途同归。

## 常见问题

**Q: 条件切换CHO和CDMA时代的软切换是一回事吗？**
A: 不是。软切换让终端同时与多个小区通信，靠宏分集实现“无缝”，代价是频谱和设备开销；CHO仍然是先断后连的硬切换，它只是把切换命令提前下发、把执行决策移到终端本地，用“零信令往返”换可靠性。一个改的是物理连接形态，一个改的是决策时序。

**Q: CHO和DAPS切换有什么区别？能否同时用？**
A: CHO解决“谁来决定何时执行”，DAPS解决“执行瞬间断不断”——DAPS让终端在接入目标小区的同时保持与源小区的收发，把中断时间压到接近零，代价是终端需要双套协议栈处理能力。针对同一候选小区，两者不能叠加配置，网络二选一。

**Q: 准备了8个候选最后只用了1个，资源不就白占了吗？**
A: 对，这就是CHO的主要代价。实际部署中靠三件事平衡：按场景收窄候选数量、把准备门限定在“确有较大概率被用上”的水平、切换完成后立即释放其余预留。高速沿线这类候选命中率高的场景，浪费率反而低。

**Q: 终端本地判断执行，判错了怎么办？**
A: 执行失败或执行后链路迅速失败，终端走重建流程，必要时可尝试向其他候选恢复。同时终端并没有拿到“不可撤销的授权”——网络保留对候选的取消权，可随时通过重配置或取消流程收回某份“合同”。自治的是执行时机，不是执行资格。

**Q: 为什么高铁场景下CHO特别有效？**
A: 因为高铁的失败几乎全是“过晚”型：切换窗口以秒计，而传统流水线的耗时与之同量级，任何一环慢半拍就出局。CHO把整段命令往返从执行路径上删掉，执行动作只剩一次几毫秒的随机接入，把“能不能赶上”的问题变成了“条件何时满足”的问题——物理速度不再能劫持决策链路。

## 参考来源

1. [Conditional Handover (CHO) in 5G NR — ShareTechnote](https://www.sharetechnote.com/html/5G/5G_CHO.html) — CHO与传统切换的根本差异、四阶段信令流程、候选配置与终端能力细节，讲解最系统
2. [5G NR Conditional handover (CHO) — Techplayon](https://www.techplayon.com/conditional-handover-cho/) — CHO引入背景、多候选并行准备与取消流程、卫星通信与无线回传场景延展
3. [Conditional Handover in 5G NR Explained — Telco & Beyond](https://telcoandbeyond.com/conditional-handover-in-5g-nr/) — 从“链路最弱时送命令”的视角剖析CHO的修复逻辑与A3/A5执行条件、参数调优陷阱
4. [Conditional Handover in 5G: Principles, Use Cases and FR2 Performance (arXiv)](https://arxiv.org/pdf/2204.01283v1) — 公开仿真研究：毫米波场景下切换失败后依靠CHO恢复机制的比例可超80%
5. [Conditional Handover in 5G (IEEE Xplore)](https://ieeexplore.ieee.org/document/9824571) — 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 等场景全覆盖。

![[知识星球二维码.png]]