深度解析 3GPP TS 38.423：8.2.3 Handover Cancel (切换取消)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.2.3 Handover Cancel”的核心章节，旨在为读者提供一个关于5G切换决策动态调整机制——切换取消流程的全景视图。

1. 楔子：当完美的计划需要一剂“后悔药”

在之前的篇章中，我们的新晋工程师小林在导师陈工的引领下，已经掌握了切换准备（Handover Preparation）和序列号状态传递（SN Status Transfer）这两个关键流程。他理解了源基站A如何为“李雷”的高铁之旅精心挑选目标基站B，并做好了万全的资源准备和数据交接清单。一切似乎都朝着一次完美的切换顺利进行。

“陈工，”小林看着流程图，信心满满地说，“现在切换准备成功了，SN状态也准备传递了，下一步就是通知李雷的手机，执行切换，大功告成！”

陈工笑了笑，抛出了一个问题：“小林，现实世界的无线环境瞬息万变，远比流程图复杂。如果就在源基站A准备下发切换指令的最后一刻，发生了意外情况，我们该怎么办？比如说——”

• 场景一：风云突变。 高铁前方突然进入一个隧道入口，导致目标基站B的信号质量瞬间急剧恶化，不再是理想的切换目标。
• 场景二：峰回路转。 由于某些无线环境的改善，李雷的手机与源基站A的连接质量突然变得异常出色，切换的必要性瞬间消失了。
• 场景三：另有其人。 源基站A启动了对基站B的切换准备定时器，但迟迟未收到B的回复。A不能无限期地等待，它必须做出决断。

“在这些情况下，如果还硬着头皮执行切换，结果很可能是切换失败，导致李雷的视频会议中断。”陈工继续说道，“一个成熟的系统，不仅要有执行计划的能力，更要有优雅地终止计划、及时止损的能力。Handover Cancel（切换取消）流程，就是源基站A手中的那剂‘后悔药’。”

这一流程的根本目的，在规范的8.2.3.1节“General”中得到了精准的概括。

The Handover Cancel procedure is used to enable a source NG-RAN node to cancel an ongoing handover preparation or an already prepared handover.

这段话明确了“切换取消”的两种核心应用场景：一是取消正在进行中的准备工作，二是取消已经准备就绪但尚未执行的切换。今天，我们就来深入剖析，源基站是如何通过这个Class 2流程，来高效、可靠地实现决策的动态调整。

2. 8.2.3.1 General (概述) - “撤销”指令的适用场景

This procedure is used to enable a source NG-RAN node to cancel an ongoing handover preparation or an already prepared handover. The procedure uses UE-associated signalling.

陈工为小林逐句解读这段概述：

• “enable a source NG-RAN node to cancel…”：这句话清晰地指明了流程的发起方——源基站。切换取消的决策权掌握在源基站手中。目标基站是被动接收指令的一方，它不能主动发起取消。

• “an ongoing handover preparation” (正在进行的切换准备)：这对应我们前面提到的场景三。源基站A向目标基站B发送了HANDOVER REQUEST后，启动了TXnRELOCprep定时器。如果在定时器超时前，A基于某些新的信息（比如从UE收到了更好的测量报告，显示基站C是更优选择）决定放弃B，那么它就可以在等待B回复的过程中，主动发送HANDOVER CANCEL来撤销这个请求。

• “an already prepared handover” (已经准备好的切换)：这对应场景一和场景二。源基站A已经收到了基站B回复的HANDOVER REQUEST ACKNOWLEDGE，B侧的资源已经为李雷预留。但就在A准备通过RRC信令指挥UE切换的最后一刻，情况发生了变化。此时，A必须发送HANDOVER CANCEL通知B：“计划有变，你为李雷预留的资源可以释放给其他人用了。”

• “UE-associated signalling” (UE关联信令)：这个流程是针对特定UE的，因此消息中必须包含能够唯一标识该UE的ID（如Source NG-RAN node UE XnAP ID和Target NG-RAN node UE XnAP ID），以确保目标基站能够准确地找到并取消为该UE准备的上下文。

3. 8.2.3.2 Successful Operation (成功操作) - 一封简洁有力的“撤销函”

陈工指着规范中的Figure 8.2.3.2-1: Handover Cancel, successful operation，这是一个只有单向箭头的流程图。

“小林，还记得我们讲的Class 2流程吗？切换取消就是典型的例子。源基站A只需要向目标基站B发送一封HANDOVER CANCEL的‘撤销函’，然后就可以认为自己的任务完成了，不需要等待B回复‘收到，已处理’。这种设计非常高效，因为A可以立即去执行新的决策，比如向基站C发起新的切换准备。”

3.1 核心载体：HANDOVER CANCEL消息

The source NG-RAN node initiates the procedure by sending the HANDOVER CANCEL message to the target NG-RAN node. The source NG-RAN node shall indicate the reason for cancelling the handover by means of an appropriate cause value.

这段原文揭示了HANDOVER CANCEL消息的两个核心要素：

1. 标识UE上下文：消息中必须包含Source NG-RAN node UE XnAP ID和Target NG-RAN node UE XnAP ID，让目标基站B知道要取消的是为哪个UE准备的切换。
2. 携带Cause IE（原因值）：这是消息的灵魂所在。源基站A必须在消息中说明取消的原因。这对于网络的运维、故障定位和性能优化至关重要。

场景代入与Cause值解析：

• 如果李雷的高铁进入隧道，目标基站B信号恶化：源基站A可能会选择取消切换，Cause值可能设为radio-connection-with-ue-lost（如果与UE的连接也受影响）或者更通用的ho-failure-in-target-cell。
• 如果源基站A与UE的连接质量突然变好：A可以取消切换，Cause值可能设为rrm-purpose（无线资源管理原因）。
• 如果TXnRELOCprep定时器超时：源基站A应该发起取消，并将Cause值设为tXnRELOCprep-expiry。这能帮助网络运维人员发现目标基站B可能存在响应慢或处理能力不足的问题。

目标基站B收到HANDOVER CANCEL消息后，会立即停止为该UE准备资源的一切活动，并释放已经分配的所有资源（如无线资源、计算资源、GTP-U隧道端点等），使这些资源可以被其他用户使用。

3.2 条件切换（CHO）下的精细化取消

在基础切换中，一次HANDOVER CANCEL通常意味着整个切换流程的终止。但在更高级的条件切换场景下，XnAP提供了更精细的控制手段。

If the Candidate Cells To Be Cancelled List IE is included in the HANDOVER CANCEL message, the target NG-RAN node shall consider that the source NG-RAN node is cancelling only the handover associated to the candidate cells identified by the included NG-RAN CGI and associated to the same UE-associated signaling connection…

陈工的解读：“这是一个非常重要的细节。假设源基站A为李雷的条件切换，在同一个目标基站B上准备了两个候选小区：Cell B1和Cell B2。现在，A通过最新的测量信息发现，Cell B1所在的方向有障碍物遮挡，不再适合作为候选。但Cell B2依然是一个很好的选择。

此时，A不需要取消整个与B的切换准备。它可以发送一个HANDOVER CANCEL消息，并在其中包含一个Candidate Cells To Be Cancelled List IE，列表里只填写Cell B1的ID。

基站B收到这个消息后，就会明白：‘哦，A只是想取消Cell B1的准备，为Cell B2预留的资源需要继续保持。’这样一来，就实现了对候选小区的‘精确打击’，避免了不必要的信令开销和资源浪费，使得条件切换的管理更加灵活高效。”

4. 流程的边界：处理异常与无效指令

一个健壮的协议必须能正确处理各种异常情况和错误输入。

4.1 8.2.3.3 Unsuccessful Operation (失败操作)

Not applicable.

陈工再次强调：“和SN Status Transfer一样，作为Class 2流程，Handover Cancel从协议层面没有‘失败响应’。发送即完成。如果底层传输失败，那是SCTP层的问题。如果目标基站因为内部错误没能正确处理，它也不能回复一个失败消息。健壮性体现在它如何处理无效的取消请求。”

4.2 8.2.3.4 Abnormal Conditions (异常条件)

If the HANDOVER CANCEL message refers to a context that does not exist, the target NG-RAN node shall ignore the message.

场景代入与解析： “设想这样一种竞争情况：基站A发送了HANDOVER REQUEST给B，但迟迟没收到回复。A的TXnRELOCprep定时器超时了，于是A发送了一个HANDOVER CANCEL给B。但几乎在同时，B的HANDOVER REQUEST ACKNOWLEDGE消息因为网络延迟刚刚到达A。A会忽略这个迟到的ACK，因为它已经决定取消了。

而B呢？它在发出ACK后，就认为切换准备已经就绪，并启动了自己的定时器等待后续步骤。紧接着，它收到了A发来的HANDOVER CANCEL。B根据消息中的UE ID，找到了对应的上下文，执行取消操作，释放资源。这是一个正常的流程。

但如果A的HANDOVER CANCEL消息也因为网络延迟，在B已经因为自己的内部定时器超时而清理了UE上下文之后才到达。此时，B收到一个针对不存在的上下文的取消请求。规范要求B必须**忽略（ignore）**这个消息。这可以防止B产生不必要的错误日志或告警，保证了系统的‘沉默健壮性’。”

If the Candidate Cells To Be Cancelled List IE is included in the HANDOVER CANCEL message and the handover is not associated to a conditional handover, the target NG-RAN node shall ignore the Candidate Cells To Be Cancelled List IE.

“同样，如果B收到一个带有‘精确取消列表’的HANDOVER CANCEL，但它查询自己的记录发现，为这个UE准备的根本就不是条件切换，而是一次普通切换。那么，这个‘精确取消列表’IE就是无效的，B应该忽略这个IE，但通常会继续处理整个消息，即取消这次普通切换。”

5. 总结：切换决策的“动态修正器”

小林在笔记本上写下总结，对Handover Cancel流程有了深刻的理解。它不仅仅是一个简单的“取消”指令，更是5G网络智能化和鲁棒性的体现。

• 它是决策的修正器：赋予了源基站应对瞬息万变的无线环境的能力，能够及时撤销不再最优的切换决策，避免了不必要的切换失败。
• 它是效率的催化剂：采用Class 2流程，实现了快速、低开销的单向通知，使得源基站可以立即转向新的策略。
• 它是资源的守护者：及时通知目标基站释放不再需要的预留资源，提高了整个网络的资源利用率。
• 它是精细化管理的工具：在条件切换场景下，支持对特定候选小区的“精准取消”，展示了5G移动性管理的高度灵活性。

对于协议开发者小林来说，他需要确保在任何切换决策被废止的逻辑分支点，都能正确地触发Handover Cancel流程，并填充准确的Cause值。对于网络排障工程师来说，HANDOVER CANCEL消息中的Cause值是分析切换失败率、切换乒乓效应等问题根源的宝贵线索。

FAQ

Q1：Handover Cancel是Class 2流程，万一这条消息在网络中丢失了怎么办？ A1：首先，XnAP承载于SCTP协议之上，SCTP本身提供了可靠传输机制（确认与重传），因此消息在传输层丢失的概率极低。如果SCTP链路彻底中断，源基站会收到连接中断的通知。更重要的是，协议设计了双重保险。即使HANDOVER CANCEL消息真的意外丢失，目标基站B为UE准备的切换上下文也不会被无限期保留。它在回复HANDOVER REQUEST ACKNOWLEDGE后会启动一个内部定时器，如果在规定时间内切换没有完成（即没有收到UE Context Release消息），它会自动清理这些过期的资源。源基站A侧也同样有TXnRELOCoverall定时器来管理整个切换流程。

Q2：源基站在什么情况下会使用Cause值为partial-handover来取消切换？ A2：当目标基站在HANDOVER REQUEST ACKNOWLEDGE中回复，只能满足UE一部分PDU会话的资源请求时（即PDU Session Resources Not Admitted List非空），源基站需要做出决策。如果源基站认为，这种“部分成功”的切换会导致用户体验严重下降（比如保证视频会议的承载没建立起来），还不如不切换。这时，它就会决定取消这次已经“部分准备好”的切换，并向目标基站发送HANDOVER CANCEL，其中的Cause值就可以设置为partial-handover。

Q3：一个UE成功切换到目标小区后，源基站是否还需要向其他候选小区发送HANDOVER CANCEL？ A3：是的，这在条件切换（CHO）场景下是必须的。假设源基站为UE准备了三个候选小区B、C、D。当UE最终满足条件并成功切换到小区B后，目标基站B会通过HANDOVER SUCCESS消息通知源基站A。A收到这个消息后，就必须立即向候选基站C和D发送HANDOVER CANCEL消息，通知它们释放为该UE预留的资源。这是CHO流程完整性的一部分，确保了网络资源的及时回收。

Q4：Conditional Handover Cancel和Handover Cancel有什么区别？ A4：Handover Cancel（TS 38.423, 8.2.3）是由源基站发起的，用于取消它之前发起的切换准备。而Conditional Handover Cancel（TS 38.423, 8.2.9）是由目标基站发起的，用于取消它已经为UE准备好的条件切换配置。例如，目标基站由于O&M操作或资源调整，不再能支持之前承诺的条件切换，它就需要主动通知源基站取消这个准备。两者的发起方和使用场景完全不同。

Q5：如果在发送HANDOVER CANCEL之后，源基站立刻又想向同一个目标基站为同一个UE发起新的切换请求，可以吗？ A5：可以，但需要谨慎处理。在发送HANDOVER CANCEL之后，源基站内部应认为与该目标基站的旧流程已经终止。它可以立即发起新的HANDOVER REQUEST。然而，由于网络延迟，新旧消息可能会在目标基站侧出现乱序。目标基站需要有能力处理这种情况，例如通过检查消息中的上下文ID或内部状态，来正确识别并处理新的请求，同时忽略或正确处理可能迟到的旧流程消息。健壮的实现对于处理这种快速连续的操作至关重要。