深度解析 3GPP TS 38.423：9.1.1 基础移动性消息 (Part 2 - 数据交接与流程取消)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.1 Messages for Basic Mobility Procedures”的核心章节，特别聚焦于
SN STATUS TRANSFER(9.1.1.4) 和HANDOVER CANCEL(9.1.1.6) 这两个关键消息。本文旨在深入剖析在切换流程中，网络如何确保数据传输的无缝衔接，以及在计划有变时如何优雅地撤销操作。
1. 引言：切换的“最后一公里”与“紧急刹车”
在上一篇中，我们跟随工程师小林详细解构了切换流程的“开场白”——HANDOVER REQUEST及其响应消息。他明白了源基站和目标基站是如何通过一场严谨的信令“谈判”，为用户“李雷”的切换准备好目标侧的资源。小林感觉，切换的大局已定。
“陈工，”小林指着流程图说，“既然目标基站已经回复了ACKNOWLEDGE，控制面的路铺好了，源基站是不是就可以直接命令UE切换了？”
“控制面的路是铺好了，但用户面的‘货车’还在路上飞驰。”导师陈工打了个比方，“想象一下，就在源基站准备下发切换指令的那一刻，它手里还有一批刚从核心网收到的、准备发给李雷的数据包。如果它直接让UE切换，这些‘在途’的数据包就丢失了。同时，李雷的手机也可能正在向源基站上传数据，如果目标基站不知道收到哪里了，就会造成上行数据的重复或丢失。这‘最后一公里’的数据交接，是保证无损切换的关键。这就是SN STATUS TRANSFER消息的使命。”
“另外，”陈工话锋一转，“战场瞬息万变。如果在下达总攻命令前，突然发现敌情有变，比如目标阵地突然出现强援，或者我方发现了更好的突破口，一个优秀的指挥官必须有能力立刻踩下‘紧急刹车’，取消原定计划。HANDOVER CANCEL消息，就是源基站手中的那个‘刹车’。”
今天，我们将继续深入XnAP协议的“数据字典”，剖析这两个在切换执行阶段扮演着“临门一脚”和“安全保险”角色的关键消息，看看5G网络是如何在追求极致性能的同时，又保证了操作的极致精细和鲁棒。
2. 9.1.1.4 SN STATUS TRANSFER - 数据的“交接清单”
这个消息的核心使命，是在切换时，将源基站侧关于UE各个数据承载（DRB）的PDCP序列号（SN）和超帧号（HFN）的状态，精确地同步给目标基站。
2.1 消息结构概览
这是一个Class 2流程，由源节点单向通知目标节点，其结构相对简洁。
SN STATUS TRANSFER 消息内容 方向: source NG-RAN node → target NG-RAN node (handover)
| IE/Group Name | Presence | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|
| Message Type | M | 9.2.3.1 | YES | ignore | |
| Source NG-RAN node UE XnAP ID | M | NG-RAN node UE XnAP ID 9.2.3.16 | 源节点分配 | YES | reject |
| Target NG-RAN node UE XnAP ID | M | NG-RAN node UE XnAP ID 9.2.3.16 | 目标节点分配 | YES | reject |
| DRBs Subject To Status Transfer List | M | 9.2.1.14 | 需要传递状态的DRB列表 | YES | ignore |
| CHO Configuration | O | 9.2.2.76 | YES | ignore | |
| Mobility Information | O | BIT STRING (SIZE(32)) | YES | ignore |
2.2 核心IE深度剖析
1. DRBs Subject To Status Transfer List (待状态传递的DRB列表)
-
Presence: M
-
陈工解读：“这是整个消息的核心载荷。一个UE可以有多个数据承载（DRB），比如一个用于VoNR通话，一个用于网页浏览。这个列表就是逐一说明每个DRB的‘交接清单’。”
列表中的每一项（
DRBs Subject To Status Transfer Item）都包含了以下关键信息：DRB ID: 明确这是哪个数据承载的“清单”。DL COUNT Value(下行COUNT值):- 含义：这个值代表了源基站作为发送方的进度。它告诉目标基站：“对于这个DRB，我下一个要使用的下行PDCP COUNT值将是X”。所有小于X的COUNT值，要么已经成功被UE确认，要么正在通过数据转发通道发往目标基站。
- 作用：目标基站收到后，就知道自己应该从COUNT值X开始，为新的下行数据包编号。这确保了下行数据的连续性，避免了数据包的乱序或重复发送。
UL COUNT Value(上行COUNT值):- 含义：这个值代表了源基站作为接收方的进度。它告诉目标基站：“对于这个DRB，我期望从UE收到的下一个上行PDCP COUNT值是Y”。所有小于Y的COUNT值，都已经被源基站成功接收。
- 作用：目标基站收到后，在从UE接收到上行数据时，就可以判断哪些是重传的旧数据包（COUNT < Y），哪些是新的数据包（COUNT >= Y）。对于旧数据包，可以直接丢弃，避免了重复数据进入核心网。这保证了上行数据的完整性和唯一性。
-
Receive Status of UL PDCP SDUs(上行PDCP SDU接收状态)- 陈工的解读：“这是
UL COUNT Value的一个‘增强补丁’。UL COUNT Value只能告诉我们‘连续接收到了哪里’，但无法描述‘空洞’。例如，源基站可能收到了COUNT为1-100和102的数据包，但101因为空口丢包还没到。此时，UL COUNT值只能是101。而这个IE是一个位图（bitmap），它可以精确地描述：‘以101为基准，我实际上还额外收到了102’。目标基站拿到这个精确的‘收货地图’后，就可以生成一个更准确的PDCP状态报告给UE，只请求重传真正丢失的101，而不会让UE重传已经被收到的102，极大地提高了无线效率。”
- 陈工的解读：“这是
3. 9.1.1.6 HANDOVER CANCEL - 果断的“紧急刹车”
这是一个Class 2流程，由源基站发起，用于取消一次已经发起但尚未完成的切换。
3.1 消息结构概览
这是一个非常简洁的消息，核心在于传递“取消”的意图和原因。
HANDOVER CANCEL 消息内容 方向: source NG-RAN node → target NG-RAN node
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.2.3.1 | YES | ignore | ||
| Source NG-RAN node UE XnAP ID | M | NG-RAN node UE XnAP ID 9.2.3.16 | YES | reject | ||
| Target NG-RAN node UE XnAP ID | O | NG-RAN node UE XnAP ID 9.2.3.16 | YES | ignore | ||
| Cause | M | 9.2.3.2 | YES | ignore | ||
| Candidate Cells To Be Cancelled List | O | 0.. | YES | reject |
3.2 核心IE深度剖析
1. Cause (原因)
- Presence: M
- 陈工解读：“这是
CANCEL消息的灵魂。源基站必须告知目标基站取消切换的原因。这份‘原因报告’是SON（自组织网络）和MRO（移动性鲁棒性优化）算法的宝贵输入。”tXnRELOCprep-expiry: 源基站的切换准备定时器超时了。这通常意味着目标基站响应太慢或Xn链路存在问题。radio-reasons: 无线原因。例如，目标小区的信号突然恶化，或者源小区的信号突然变好，不再需要切换。partial-handover: 源基站认为目标基站返回的部分成功切换（只有部分承载被接纳）无法满足业务需求，决定放弃。rrm-purpose: 无线资源管理原因。例如，源基站的负载均衡算法有了新的、更优的决策。
2. Candidate Cells To Be Cancelled List (待取消的候选小区列表)
- Presence: O (Conditional)
- 陈工解读：“这是为**条件切换（CHO）**设计的精细化控制工具。在CHO中，源基站可能在同一个目标
gNB上准备了多个候选小区（例如，Cell-1和Cell-2）。如果源基站后来发现Cell-1不再适合作为候选（比如信号质量下降），但Cell-2依然有效，它就可以发送一个HANDOVER CANCEL消息，并在该IE中只列出Cell-1的CGI。目标gNB收到后，就只会释放为Cell-1准备的资源，而保留Cell-2的CHO配置。这实现了‘外科手术式’的取消，而不是‘一刀切’，极大地增强了CHO的灵活性。”
4. 总结：从“粗放”到“精细”的移动性管理
小林恍然大悟。他明白了，一个成功的切换，不仅仅是控制信令的通达，更是用户面数据状态的精确同步。SN STATUS TRANSFER就是这份同步的“蓝图”。而一个健壮的移动性系统，则必须具备处理计划变更的能力，HANDOVER CANCEL就是这个能力的体现，它为网络提供了必要的“容错”和“优化”空间。
SN STATUS TRANSFER将数据切换从可能导致丢包和乱序的“硬切换”，变成了平滑无感的“软切换”，是**无损移动性（Lossless Mobility）**的核心保障。HANDOVER CANCEL将切换决策从一个不可逆的“单向指令”，变成了一个可动态调整的“闭环过程”，是**移动性鲁棒性优化（MRO）和自组织网络（SON）**的关键使能者。
对于小林这样的开发者来说，SN STATUS TRANSFER的实现，要求对PDCP协议有深刻的理解；而HANDOVER CANCEL的实现，则要求对整个移动性决策的RRM（无线资源管理）逻辑有清晰的把握。这两个消息，完美地展现了5G XnAP协议在追求极致性能的同时，对细节的精雕细琢。
FAQ
Q1：COUNT值和PDCP SN有什么关系？
A1：COUNT是一个更长的、不会在短时间内回环的序列号。它由两部分组成：高位的HFN (Hyper Frame Number)和低位的PDCP SN (Sequence Number)。PDCP SN长度有限（如12或18位），会频繁回环。每当SN从最大值回环到0时，HFN就会加1。COUNT值是加密和完整性保护算法的输入，保证了安全性；同时它也用于无歧义的乱序检测和重排序。SN STATUS TRANSFER传递的正是这个完整的COUNT值。
Q2：HANDOVER CANCEL是一个Class 2流程，万一丢失了，目标基站不是会一直保留着为切换准备的资源吗？
A2：不会。协议设计了多重保险。目标基站在回复HANDOVER REQUEST ACKNOWLEDGE后，会启动一个自己的内部定时器。如果在该定时器超时后，UE仍未接入（因为源站已经取消了切换但CANCEL消息丢失了），目标基站会自动清理为这次“过期”的切换准备所预留的所有资源。因此，CANCEL消息是一个加速资源回收的优化，但即使它失败，网络的健壮性（通过超时机制）也能保证最终的资源一致性。
Q3：源基站何时发送SN STATUS TRANSFER消息？
A3：规范规定在源基站“冻结”其收发状态时发送。这通常发生在源基站已经完成了所有切换准备，并即将向UE发送RRCReconfiguration（切换指令）消息之前。这个时间点非常关键，既要确保传递的状态尽可能新，又要避免在传递后状态又发生了变化。
Q4：为什么HANDOVER CANCEL消息中，Target NG-RAN node UE XnAP ID是可选的（Optional）？
A4：因为在切换准备的早期阶段，即源基站刚刚发送HANDOVER REQUEST但还未收到目标基站的ACKNOWLEDGE时，源基站并不知道目标基站会为这个UE分配哪个ID。在这个时间窗口内如果需要取消，源基站只能通过Source...ID来标识这个流程。而一旦源基站收到了ACKNOWLEDGE，它就知道了Target...ID，在后续的CANCEL中就应该带上这个ID，以便目标基站更快速、更准确地定位到要取消的UE上下文。
Q5：SN STATUS TRANSFER和数据转发（Data Forwarding）是什么关系？
A5：它们是协同工作的。SN STATUS TRANSFER传递的是控制面的状态（“数据包编号到哪里了”），而数据转发是在用户面上进行的实际数据传输。在切换期间，源基站不仅会通过SN STATUS TRANSFER告知目标基站COUNT值，还会将那些已经编号但尚未得到UE确认的下行数据包，通过Xn-U接口的数据转发隧道，直接发送给目标基站。目标基站收到这些转发的数据包后，会优先发送它们，然后再根据SN STATUS TRANSFER提供的DL COUNT值，开始发送新的数据包。两者结合，才构成了完整的无损切换方案。