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 完整信令时序图

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结构图

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说明表

设计意图剖析：注意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$$

其中各参数含义：

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

4.2 UE侧条件评估状态机

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：三维对比

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

需要强调：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) — §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) — CHO流程图与执行条件解读
3. wirelessbrew - Conditional Handover (CHO) in 5G NR Release 16 — CHO原理与准备/执行阶段分析
4. arXiv:2403.04379 - Performance evaluation of conditional handover in 5G systems — CHO性能评估与移动场景增益分析
5. 3glteinfo - 5G Conditional Handover Procedure Call Flow — CHO完整信令流程与XnAP/NGAP交互
6. Techplayon - 5G NR 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 等场景全覆盖。