# 条件切换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与传统切换的对比 | 对比维度 | 传统切换（Baseline HO） | 条件切换（CHO） | |---------|----------------------|----------------| | 决策主体 | 源gNB单向决策，下发后立即执行 | 源gNB预配置，UE基于条件自治执行 | | 目标小区数量 | 单一目标小区（1个） | 多个候选小区（最多 `maxNrofCondCells-r16` 个） | | 切换命令下发时机 | 网络判断时刻立即下发 | 提前下发，UE存储后等待条件满足 | | 执行触发 | 收到命令即执行（无延迟） | UE评估测量条件满足后执行（有条件） | | 执行时延 | 含网络侧决策与空口往返时延 | 仅UE本地评估时延（亚毫秒级） | | 抗信道波动能力 | 弱（决策与执行间存在时延窗口） | 强（执行点贴近真实信道质量） | | 信令开销 | 每次切换1次Xn/N2准备+1条RRC | 1次准备多个候选+1条RRC（含候选列表） | | 数据前转（forwarding） | 切换命令下发后即开始前转 | 执行时刻才前转到被选中的目标 | | 适用场景 | 低速、信道稳定 | 高速移动、FR2、边缘覆盖、URLLC | ## 三、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的完整信令时序图： ```mermaid 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
选定候选小区列表(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
含condReconfigToAddModList SgNB->>UE: RRCReconfiguration(CHO配置:候选列表+执行条件) Note over UE: 存储所有候选配置
启动条件评估,仍驻留源小区收发 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树状结构： ```mermaid 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
含reconfigurationWithSync→候选1同步参数] G1 --> J1[执行条件: condEventA3 cond-rsrp] G2 --> H2[condReconfigId-r16 = 2] G2 --> I2[rrcReconfiguration-r16
含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, ... } ``` 各参数含义见下表： | IE字段 | 类型 | 含义与作用 | |--------|------|-----------| | `condReconfigId-r16` | CHO-IE-Identity | 候选小区唯一标识，关联候选与执行条件 | | `condEventA3-r16` | 条目 | 候选小区测量值优于(服务小区+偏移)，对应事件A3 | | `condEventA5-r16` | 条目 | 服务小区变差且候选变好，对应事件A5 | | `cond-rsrp/cond-rsrq/cond-sinr` | 测量量选择 | 选择用于评估的测量量(RSRP/RSRQ/SINR) | | `hysteresis-r16` | Hysteresis(0~30) | 迟滞值，避免条件在临界点频繁抖动 | | `timeToTrigger-r16` | TimeToTrigger(0~5120ms) | 触发时间窗，条件需持续满足TTT才算触发 | | `a3-Offset / a5-Threshold1/2` | 偏移/阈值 | A3偏移量、A5双阈值 | **事件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配置到执行切换的状态流转： ```mermaid 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 常见故障点与排错 | 故障现象 | 可能原因 | 排错思路 | |---------|---------|---------| | UE收到CHO配置但从不执行 | 执行条件参数过严（offset过大、TTT过长） | 检查 `condEventA3.a3-Offset`、`timeToTrigger`；核对候选小区测量值是否达标 | | UE执行某候选后T304超时 | 候选小区RACH资源失效或PCI/SSB配置错误 | 核对候选 `reconfigurationWithSync` 中RACH配置、SSB index；检查候选gNB实际是否仍准入 | | 多候选均不满足条件导致长期驻留弱源 | 候选选择过少或邻区漏配 | 检查源gNB的候选小区选择算法与ANR邻区；增大候选数 | | 撤销候选后UE仍尝试该候选 | `condReconfigToRemoveList` 未被UE正确处理 | 检查RRC消息是否成功送达（源链路质量）；核对 `condReconfigId` 匹配 | | 切换后用户面中断过长 | 前转隧道未预建或路径切换延迟 | 检查 `HANDOVER SUCCESS` 与 `PATH SWITCH REQUEST` 时序；评估预先前转策略 | ## 十、设计意图总结 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](https://www.3gpp.org/dynareport/38331.htm) — §5.3.4 条件重配过程、§5.5 测量事件、§6.3 ConditionalReconfiguration/CondReconfigToAddModList 信元定义 2. [3GPP TS 38.300 V18.x - NR; NR and NG-RAN Overall Description](https://www.3gpp.org/dynareport/38300.htm) — §9.2.3 条件切换（CHO）总体描述、移动性管理框架 3. [iTechSpec - TS 38.331 ConditionalReconfiguration / CondReconfigToAddModList 信元ASN.1](https://itecspec.com/3gpp/38.331/s/conditionalreconfiguration) — CHO相关IE精确ASN.1结构查询 4. [ShareTechnote - 5G/NR CHO (Conditional Handover)](https://www.sharetechnote.com/html/5G/5G_CHO.html) — CHO机制图文讲解与执行条件分析 5. [3glteinfo - 5G Conditional Handover Procedure Call Flow](https://www.3glteinfo.com/call-flows/5g/conditional-handover/) — 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 等场景全覆盖。