条件切换CHO信令全链拆解：从候选预配置到UE自治执行

一、为什么需要条件切换（CHO）

传统5G NR切换（Baseline Handover）遵循一个朴素的串行模型：源gNB根据测量报告决定切换目标 → 通过Xn/N2接口完成目标侧准备 → 源gNB下发 RRCReconfiguration（内含 reconfigurationWithSync） → UE立即同步到目标小区并执行切换。这条链路的致命弱点在于：从测量报告上报到切换命令下发的这段空口往返时延内，无线信道可能已发生剧烈变化。尤其在高速移动（高铁、车联网）或FR2毫米波频段（信号易受遮挡、波动剧烈）场景下，经常出现"切换命令下发时目标小区已经变差"甚至"源链路在切换命令送达前就已中断"的窘境，导致切换失败、无线链路失败（RLF）乃至RRC重建。

为解决这一"决策与执行之间的信道鸿沟"，3GPP在 Rel-16 引入了条件切换（Conditional Handover，CHO），定义于 TS 38.331（NR RRC协议规范）、TS 38.300（NR总体描述）以及 TS 38.423（Xn接口应用层，XnAP）/ TS 38.413（NG接口应用层，NGAP）。CHO的核心思想可以一句话概括：

网络预先为UE准备好多个候选目标小区及其切换配置，并附带"执行条件"，下发后UE不再等待网络指令，而是自行持续评估条件，一旦某个候选小区满足条件，UE立即自治执行切换。

这把传统切换中"网络决策—网络下发—UE执行"的串行强耦合，解耦为"网络预配置 + UE自治判断"，把切换执行点交给了对无线质量感知最敏锐的UE自己，从而显著提升切换成功率、降低切换失败与RLF概率。

需要强调的是，本文聚焦的是 TS 38.331 中CHO的具体信令机制与IE结构（Rel-16基线，并涵盖Rel-18增强），而非泛泛的移动性架构演进。下面我们从传统切换与CHO的对比切入，逐步拆解完整信令链路。

二、CHO与传统切换的对比

三、CHO的三个阶段总览

CHO全过程可清晰划分为三个阶段，每个阶段在不同接口、不同网元上发生：

1. 准备阶段（Preparation）：源gNB通过XnAP HANDOVER REQUEST 向多个候选gNB发起切换准备，各候选gNB准入后回 HANDOVER REQUEST ACKNOWLEDGE，返回各自候选小区的切换命令（RRCReconfiguration，含 reconfigurationWithSync）。
2. 配置与评估阶段（Configuration & Evaluation）：源gNB把所有候选小区的配置与执行条件打包成单条 RRCReconfiguration（携带 condReconfigToAddModList-r16）下发给UE；UE存储全部候选配置，继续在源小区正常收发数据，同时对每个候选小区持续评估执行条件。
3. 执行与完成阶段（Execution & Completion）：UE判定某候选小区满足执行条件后，应用该候选的存储配置、发起RACH接入，并向目标小区发送 RRCReconfigurationComplete；目标侧通过 HANDOVER SUCCESS 通知源gNB，随后发起路径切换（Path Switch），源gNB撤销未被选中的候选小区并释放UE上下文。

下面是Xn接口下CHO的完整信令时序图：

sequenceDiagram
    participant UE
    participant SgNB as 源gNB(SpCell)
    participant C1 as 候选gNB-1
    participant C2 as 候选gNB-2
    participant AMF

    UE->>SgNB: MeasurementReport(测量事件A3/A5上报)
    Note over SgNB: 决策采用CHO<br/>选定候选小区列表(C1, C2)
    par 并行准备
        SgNB->>C1: XnAP: HANDOVER REQUEST(候选1准备)
        SgNB->>C2: XnAP: HANDOVER REQUEST(候选2准备)
    end
    par 准入应答
        C1-->>SgNB: HANDOVER REQUEST ACK(候选1 HO Command)
        C2-->>SgNB: HANDOVER REQUEST ACK(候选2 HO Command)
    end
    Note over SgNB: 拼装单条RRCReconfiguration<br/>含condReconfigToAddModList
    SgNB->>UE: RRCReconfiguration(CHO配置:候选列表+执行条件)
    Note over UE: 存储所有候选配置<br/>启动条件评估,仍驻留源小区收发
    loop 持续测量评估
        UE->>UE: 逐候选评估执行条件(A3/A5)
    end
    Note over UE: 候选1执行条件满足→CHO执行
    UE->>UE: 应用候选1存储配置(reconfigurationWithSync)
    UE->>C1: RACH(随机接入)+RRCReconfigurationComplete
    C1->>SgNB: XnAP: HANDOVER SUCCESS(UE已接入候选1)
    C1->>AMF: NGAP: PATH SWITCH REQUEST(路径切换)
    AMF-->>C1: PATH SWITCH REQUEST ACKNOWLEDGE
    Note over SgNB: 撤销未被选中的候选
    SgNB->>C2: XnAP: HANDOVER CANCEL(释放候选2)
    C1->>SgNB: XnAP: UE CONTEXT RELEASE
    Note over SgNB: 释放源UE上下文与剩余资源

四、关键信令消息与IE拆解

4.1 RRCReconfiguration中的CHO信元结构

CHO在RRC层最核心的载体是 RRCReconfiguration 消息中的 conditionalReconfiguration-r16 字段（位于 RRCReconfiguration-IEs）。其ASN.1顶层结构（TS 38.331 §6.3.2）如下：

ConditionalReconfiguration-r16 ::= SEQUENCE {
    attemptCondReconfig-r16            ENUMERATED {true}            OPTIONAL,
    condReconfigToAddModList-r16       CondReconfigToAddModList-r16 OPTIONAL,
    condReconfigToRemoveList-r16       CondReconfigToRemoveList-r16 OPTIONAL,
    ...
}

CondReconfigToAddModList-r16 ::= SEQUENCE (SIZE(1..maxNrofCondCells-r16))
                                  OF CondReconfigToAddMod-r16

CondReconfigToAddMod-r16 ::= SEQUENCE {
    condReconfigId-r16                 CHO-IE-Identity,          -- 候选唯一标识
    rrcReconfiguration-r16             RRCReconfiguration        OPTIONAL, -- 该候选完整RRC配置
    secondaryCellGroupConfig-r16       OCTET STRING              OPTIONAL  -- 辅小区组配置(DC)
}

其中： - attemptCondReconfig-r16：布尔标志，指示UE"尝试"条件重配。源gNB用它要求UE进入条件评估模式。 - condReconfigToAddModList-r16：候选小区列表，每个表项描述一个候选小区的完整切换配置。maxNrofCondCells-r16 限定了同时配置的候选小区上限（Rel-16默认上限为8）。 - condReconfigId-r16：CHO-IE-Identity 类型，为每个候选小区分配一个唯一标识，用于后续UE上报选中候选、网络撤销候选等操作。 - rrcReconfiguration-r16：嵌套一个完整的 RRCReconfiguration 消息，其内部携带 reconfigurationWithSync（目标小区同步信息：PCI、SSB、RACH配置、TA、新C-RNTI等）。这相当于把"传统切换命令"完整地打包进每个候选表项。 - condReconfigToRemoveList-r16：用于撤销（withdraw）已配置的候选小区，例如源gNB判断某候选资源紧张时主动移除。

下图展示了一个含2个候选小区的CHO RRCReconfiguration 消息IE树状结构：

graph TD
    A[RRCReconfiguration] --> B[reconfigurationWithSync? 无,可选]
    A --> C[conditionalReconfiguration-r16]
    A --> D[measConfig-r16 持续测量配置]
    C --> E[attemptCondReconfig-r16 = true]
    C --> F[condReconfigToAddModList-r16]
    F --> G1[CondReconfigToAddMod #1]
    F --> G2[CondReconfigToAddMod #2]
    G1 --> H1[condReconfigId-r16 = 1]
    G1 --> I1[rrcReconfiguration-r16<br/>含reconfigurationWithSync→候选1同步参数]
    G1 --> J1[执行条件: condEventA3 cond-rsrp]
    G2 --> H2[condReconfigId-r16 = 2]
    G2 --> I2[rrcReconfiguration-r16<br/>含reconfigurationWithSync→候选2同步参数]
    G2 --> J2[执行条件: condEventA5 cond-rsrq]
    style C fill:#e1f5ff
    style F fill:#fff4e1

4.2 执行条件（condExecutionConfig）的语义

CHO最巧妙的设计在于"执行条件"。每个候选小区绑定一个执行条件，由UE自行评估。执行条件本质上是一类测量事件（TS 38.331 §5.5.4/§5.5.5定义的事件A系列），CHO复用 事件A3 和 事件A5 两种，封装在 CondExecutionConfig-r16 中：

CondExecutionConfig-r16 ::= SEQUENCE {
    condExecutionConfigId-r16          CHO-IE-Identity,
    condExecutionCond-r16              CHOICE {
        condEventA3-r16                CondEventA3-r16,
        condEventA5-r16                CondEventA5-r16
    },
    hysteresis-r16                     Hysteresis,
    timeToTrigger-r16                  TimeToTrigger,
    ...
}

各参数含义见下表：

事件A3执行条件公式（CHO中最常用）：

Mn + Ofn + Ocn − Hys  >  Mp + Ofp + Ocp + Off

其中 Mn 为候选小区测量值，Mp 为服务小区（SpCell）测量值，Ofn/Ofp 为频率偏移，Ocn/Ocp 为小区偏移，Off 为A3偏移，Hys 为迟滞。当该不等式持续满足 timeToTrigger 时间后，UE判定该候选满足执行条件。

事件A5执行条件公式（双重判据，适合源链路劣化场景）：

条件1: Mp + Hys < Thresh1     (服务小区低于阈值1)
条件2: Mn + Ofn + Ocn − Hys > Thresh2   (候选小区高于阈值2)

A5同时要求源链路变差和候选链路变好，更适合作为"防御性"切换触发。

五、UE侧条件评估与执行状态机

CHO执行逻辑完全驻留在UE RRC层。下图刻画了UE从接收CHO配置到执行切换的状态流转：

stateDiagram-v2
    [*] --> 已存储CHO配置
    已存储CHO配置 --> 条件评估中: 启动逐候选测量评估
    条件评估中 --> 条件评估中: 条件未满足(继续驻留源小区)
    条件评估中 --> 执行切换: 某候选条件满足且持续TTT
    条件评估中 --> 配置撤销: 收到condReconfigToRemoveList
    配置撤销 --> 条件评估中: 仍有候选
    配置撤销 --> [*]: 无候选,退出CHO
    执行切换 --> 切换成功: RACH+RRCReconfigurationComplete成功
    执行切换 --> CHO失败: T304超时(接入失败)
    切换成功 --> [*]: 释放所有候选配置,接入目标
    CHO失败 --> RRC重建: 回退到RRCReestablishment
    CHO失败 --> [*]: 评估是否仍有候选可重试

UE执行CHO的关键行为规则（TS 38.331 §5.3.4.x）：

1. 存储而非执行：收到CHO配置后，UE不立即执行任何切换，而是把每个候选的完整 rrcReconfiguration-r16 连同其执行条件存储下来。
2. 持续测量：UE继续维持与源小区的连接，正常上下行收发，并按 measConfig 持续测量候选小区。注意，此时UE不再需要为切换而上报MeasurementReport触发网络决策（但常规测量上报可继续）。
3. 首个满足者优先：UE对每个候选独立评估执行条件。当多个候选同时满足条件时，UE按预定义优先级选择第一个满足条件的候选（通常按 condReconfigId 顺序或配置中的优先级）。
4. 原子化执行：一旦决定执行某候选，UE停止评估其他候选，断开源链路L1/L2，应用该候选存储的 reconfigurationWithSync（含新C-RNTI、TA、RACH资源），向候选小区发起RACH，启动定时器 T304。
5. 完成与清理：RACH成功并通过 RRCReconfigurationComplete 后，UE释放所有存储的CHO候选配置，切换完成。整个执行过程中只应用一个候选的配置，不会叠加多个候选。

六、网络侧准备与完成机制

6.1 多候选并行准备（XnAP）

源gNB决定启用CHO后，会基于测量报告与邻区关系，选定多个候选小区，并通过XnAP 并行向各候选gNB发起 HANDOVER REQUEST。各候选gNB完成准入、分配资源、生成各自的HO Command后，回 HANDOVER REQUEST ACKNOWLEDGE。源gNB收集齐所有候选的HO Command后，统一拼装成一条 RRCReconfiguration 下发。这一"多候选并行准备 + 单消息下发"的设计，把多次网络交互压缩到一次，既降低了空口信令次数，又把切换执行权下放给UE。

当源gNB与候选gNB之间无Xn接口（或跨PLMN）时，CHO可经NG-AP（N2）准备：源gNB向AMF发送 HANDOVER REQUIRED（携带多个目标小区ID），AMF向各目标gNB转发 HANDOVER REQUEST，应答反向返回，流程类似但多经AMF一跳。

6.2 候选撤销（Candidate Withdrawal）

CHO允许源gNB在UE执行前主动撤销已配置的候选小区。当某候选gNB资源紧张（如负载升高、发生故障）时，它会通过 HANDOVER PREPARATION FAILURE 或专用通知告知源gNB，源gNB随即下发携带 condReconfigToRemoveList-r16 的 RRCReconfiguration，UE收到后删除对应候选配置、停止对其评估。这避免了UE切换到一个已不可用的目标小区。撤销机制是CHO区别于传统切换的另一关键韧性设计。

6.3 路径切换与未选中候选释放

UE接入被选中候选（设为C1）并发送 RRCReconfigurationComplete 后，C1向源gNB发送XnAP HANDOVER SUCCESS，告知"UE已成功接入C1"。随后：

• C1 发起 PATH SWITCH REQUEST（NG-AP）给AMF，将N3/N9用户面路径从源gNB切换到C1；AMF回 PATH SWITCH REQUEST ACKNOWLEDGE。
• 源gNB 收到路径切换完成通知后，向未被选中的候选（如C2）发送 HANDOVER CANCEL，释放其上为该UE预留的资源；同时源gNB收到C1的 UE CONTEXT RELEASE 后释放本侧UE上下文。

七、数据前转与失败处理

7.1 数据前转时机

传统切换中，源gNB在切换命令下发后即开始向目标前转下行PDCP SDU（含状态前转）。而CHO中，由于UE执行时刻不确定，前转需谨慎：

• 前转隧道可预先建立，但实际数据前转延迟到UE执行时刻（即源gNB收到 HANDOVER SUCCESS 时）才启动到被选中的目标。这避免了向多个候选同时前转造成的冗余开销与乱序风险。
• 为降低切换中断，Rel-16允许对最可能被选中的候选预先建立前转隧道，但数据流动仍受控于执行事件。

7.2 失败处理

CHO引入了更细的失败处理逻辑：

• 执行期失败（T304超时）：UE执行某候选后若在T304内RACH或同步失败，UE判定CHO失败。此时UE不立即RLF重建，而是检查是否仍有其他已存储候选满足条件，若满足可尝试下一个候选；若所有候选均不可用，则触发RRC重建。
• 配置期RLF：若UE在条件评估期间（尚未执行）发生源链路RLF，UE可优先尝试评估CHO候选（若有候选满足条件），从而"自救"完成切换，避免直接RLF。
• 源gNB侧超时：源gNB维护候选有效期，若超长时间未收到 HANDOVER SUCCESS，会主动撤销候选并清理资源。

这种"失败后仍可尝试其他候选"的容错机制，正是CHO提升鲁棒性的根本所在。

八、Rel-18增强：CHO + CPC、CHO + LTM与CA/DC扩展

CHO在Rel-16落地后，Rel-17/Rel-18持续增强，TS 38.331/38.300/38.423 相应章节演进：

• CPC（Conditional PSCell Change，条件PSCell变更）：将CHO条件执行思想扩展到双连接（DC）的辅节点PSCell变更。Rel-16即引入，Rel-18完善与CHO联合（ConditionalReconfiguration 同时承载CHO候选与CPC候选）。
• CHO + LTM（L1/L2 Triggered Mobility）：Rel-18引入L1/L2触发的移动性（基于MAC CE快速切换，TS 38.321/38.300），CHO可与LTM结合，进一步把切换时延压到亚帧级。
• CA（载波聚合）下的CHO：候选小区可包含SCell配置，支持切换同时完成SCell增删。
• CHO触发条件丰富：Rel-18引入基于L1-RSRP/SINR的更快条件评估，缩短TTT。

九、抓包识别与排错实战

9.1 抓包识别要点

在Wireshark/Tshark中识别CHO流程，关键看以下特征：

1. XnAP消息：同一UE短时间内出现多条 HANDOVER REQUEST（向不同gNB-DU/gNB），随后多条 HANDOVER REQUEST ACKNOWLEDGE，这是多候选并行准备的指纹。
2. RRCReconfiguration：在 conditionalReconfiguration 字段中解析到 condReconfigToAddModList（多条目）且 attemptCondReconfig = true，即可确认是CHO而非普通重配/普通切换。
3. 无立即 RRCReconfigurationComplete：传统切换中UE收到 reconfigurationWithSync 后立即接入并回Complete；CHO中UE先存储，期间可能继续上/下行数据，过一段时间才在目标小区出现 RRCReconfigurationComplete，且源小区无对应应答。
4. HANDOVER SUCCESS + HANDOVER CANCEL 同时出现：成功接入一个候选（SUCCESS）的同时，向其他候选发CANCEL，这是CHO完成的标志。

9.2 常见故障点与排错

CHO的设计体现了3GPP移动性管理的一次范式转变：从"网络中心化决策"走向"网络预配置 + 终端自治"。其设计意图可归纳为三点：

1. 消除决策-执行时延窗口：把切换执行权交给实时感知信道的UE，使执行点与真实信道质量对齐，根治"命令到时目标已变差"的顽疾。
2. 冗余容错提升鲁棒性：多候选 + 失败可重试 + 候选撤销机制，让切换从"单点成败"变为"多候选兜底"，显著降低RLF。
3. 解耦网络与终端职责：网络负责资源准备与条件设定，终端负责实时判断与执行，二者解耦后各自优化，契合6G时代超密集组网、高速移动、URLLC等对移动性的极致要求。

理解CHO的关键，在于把握"单消息多候选预配置 + UE自治条件评估 + 失败多候选兜底"这一核心机制链，以及它在TS 38.331 conditionalReconfiguration 信元、TS 38.423 XnAP多候选准备、TS 38.300移动性总述三处的协同定义。

常见问题

Q1：CHO和传统切换最本质的区别是什么？ A：传统切换中，源gNB决策后下发切换命令、UE立即执行，决策与执行之间存在空口往返时延窗口，信道可能已变化；而CHO中，源gNB提前下发多个候选小区配置与执行条件，UE存储后自行评估，条件满足时才自治执行。本质区别在于"执行触发权"从网络转移到了UE，且目标从单一变为多候选。

Q2：UE如何决定切换到多个满足条件候选中的哪一个？ A：当多个候选小区的执行条件同时满足时，UE按标准定义的优先级选择——通常是按 condReconfigId 顺序或RRC配置中指定的优先级，选择第一个满足条件的候选执行。一旦开始执行，UE即停止评估其他候选，原子化地应用被选候选的配置。

Q3：CHO中数据前转和传统切换有何不同？ A：传统切换在切换命令下发后立即向单一目标前转数据；CHO中前转隧道可预先为多个候选建立，但实际数据前转延迟到UE执行时刻，且只向被UE选中的那个目标前转，避免向多候选冗余前转造成的开销与乱序。厂商可对最可能被选中的候选预先前转以降低中断。

Q4：如果UE执行某候选失败（T304超时）会怎样？ A：UE不会立即RLF重建。它会先检查是否仍有其他已存储候选小区满足执行条件，若有则尝试下一个候选；若所有候选均不可用，才触发RRC重建。这种"失败可重试其他候选"的机制正是CHO鲁棒性的来源。

Q5：CHO需要网络和终端分别支持什么？ A：网络侧（gNB）需支持XnAP/NGAP多候选并行准备与撤销（HANDOVER REQUEST×N、HANDOVER CANCEL、condReconfigToRemoveList）；终端侧需支持TS 38.331 Rel-16的 conditionalReconfiguration 信元解析、多候选配置存储、自治条件评估（A3/A5）与原子化执行。UE能力通过 ue-CapabilityRRC-Parameters 中的CHO能力信元上报。

参考来源

1. 3GPP TS 38.331 V18.6.0 - NR; Radio Resource Control (RRC) protocol specification — §5.3.4 条件重配过程、§5.5 测量事件、§6.3 ConditionalReconfiguration/CondReconfigToAddModList 信元定义
2. 3GPP TS 38.300 V18.x - NR; NR and NG-RAN Overall Description — §9.2.3 条件切换（CHO）总体描述、移动性管理框架
3. iTechSpec - TS 38.331 ConditionalReconfiguration / CondReconfigToAddModList 信元ASN.1 — CHO相关IE精确ASN.1结构查询
4. ShareTechnote - 5G/NR CHO (Conditional Handover) — CHO机制图文讲解与执行条件分析
5. 3glteinfo - 5G Conditional Handover Procedure Call Flow — CHO Xn/N2信令流程与时序拆解

本文由「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 等场景全覆盖。