深度解析 3GPP TS 38.423：8.1 & 8.2.1 基本流程与切换准备
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.1 Elementary procedures”和“8.2.1 Handover Preparation”的核心章节。本文旨在为读者清晰地展现XnAP协议所有交互的基本单元分类，并以最核心的切换准备流程为例，进行深入、场景化的拆解。
1. XnAP世界的“对话范式”
在上一篇文章中，我们跟随初级工程师小林和他的导师陈工，学习了XnAP协议的“词汇表”（第3章）和“语法规则”（第4-7章）。现在，小林已经对XnAP协议的设计原则有了宏观的认识。
“陈工，”小林充满期待地问，“我已经理解了协议的‘立法精神’，现在是不是可以学习具体的‘法律条文’了？”
陈工点点头，打开规范翻到第8章：“没错。第8章‘XnAP procedures’是整部规范的心脏。它定义了基站之间为了完成各种协作任务所需要进行的全部‘对话’。而8.1节‘Elementary procedures’（基本流程），就是这些对话的最基本分类，相当于教你识别‘陈述句’和‘疑问句’。掌握了这个分类，你才能理解每个流程的设计意图。”
2. XnAP流程的两大阵营：Class 1 与 Class 2
陈工指着8.1节的开篇文字：
In the following tables, all EPs are divided into Class 1 and Class 2 EPs.
“小林，你看，所有XnAP的交互单元，也就是我们之前在第3章学过的‘基本流程’（EP），都被分成了两大类：Class 1和Class 2。这两种分类的核心区别在于：交互是否需要一个明确的结果反馈。”
2.1 Class 1 基本流程：有问必答的严谨对话
陈工首先指向了Table 8.1-1: Class 1 Elementary Procedures。
“Class 1流程，可以理解为‘有问必答’式的交互。发起方发送一个请求消息，接收方在处理后，必须回复一个结果——要么是‘成功’，要么是‘失败’。这种模式确保了流程的闭环和状态的同步，适用于所有需要协商和确认的关键操作。”
为了让小林有更直观的认识，陈工让他仔细看这张表，并解释了其核心结构。
表 8.1-1: Class 1 基本流程 (注：为保证完整性，此处将规范中分布在多页的完整表格进行重绘)
| Elementary Procedure (基本流程) | Initiating Message (发起消息) | Successful Outcome Response message (成功响应消息) | Unsuccessful Outcome Response message (失败响应消息) |
|---|---|---|---|
| Handover Preparation (切换准备) | HANDOVER REQUEST | HANDOVER REQUEST ACKNOWLEDGE | HANDOVER PREPARATION FAILURE |
| Retrieve UE Context (UE上下文检索) | RETRIEVE UE CONTEXT REQUEST | RETRIEVE UE CONTEXT RESPONSE | RETRIEVE UE CONTEXT FAILURE |
| S-NG-RAN node Addition Preparation (S节点添加准备) | S-NODE ADDITION REQUEST | S-NODE ADDITION REQUEST ACKNOWLEDGE | S-NODE ADDITION REQUEST REJECT |
| M-NG-RAN node initiated S-NG-RAN node Modification Preparation (M节点发起的S节点修改准备) | S-NODE MODIFICATION REQUEST | S-NODE MODIFICATION REQUEST ACKNOWLEDGE | S-NODE MODIFICATION REQUEST REJECT |
| S-NG-RAN node initiated S-NG-RAN node Modification (S节点发起的S节点修改) | S-NODE MODIFICATION REQUIRED | S-NODE MODIFICATION CONFIRM | S-NODE MODIFICATION REFUSE |
| S-NG-RAN node initiated S-NG-RAN node Change (S节点发起的S节点变更) | S-NODE CHANGE REQUIRED | S-NODE CHANGE CONFIRM | S-NODE CHANGE REFUSE |
| M-NG-RAN node initiated S-NG-RAN node Release (M节点发起的S节点释放) | S-NODE RELEASE REQUEST | S-NODE RELEASE REQUEST ACKNOWLEDGE | S-NODE RELEASE REJECT |
| S-NG-RAN node initiated S-NG-RAN node Release (S节点发起的S节点释放) | S-NODE RELEASE REQUIRED | S-NODE RELEASE CONFIRM | |
| Xn Setup (Xn建立) | XN SETUP REQUEST | XN SETUP RESPONSE | XN SETUP FAILURE |
| NG-RAN node Configuration Update (NG-RAN节点配置更新) | NG-RAN NODE CONFIGURATION UPDATE | NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE | NG-RAN NODE CONFIGURATION UPDATE FAILURE |
| Cell Activation (小区激活) | CELL ACTIVATION REQUEST | CELL ACTIVATION RESPONSE | CELL ACTIVATION FAILURE |
| Reset (重置) | RESET REQUEST | RESET RESPONSE | |
| Xn Removal (Xn移除) | XN REMOVAL REQUEST | XN REMOVAL RESPONSE | XN REMOVAL FAILURE |
| E-UTRA - NR Cell Resource Coordination (E-UTRA-NR小区资源协调) | E-UTRA - NR CELL RESOURCE COORDINATION REQUEST | E-UTRA - NR CELL RESOURCE COORDINATION RESPONSE | |
| Resource Status Reporting Initiation (资源状态上报启动) | RESOURCE STATUS REQUEST | RESOURCE STATUS RESPONSE | RESOURCE STATUS FAILURE |
| Mobility Settings Change (移动性设置变更) | MOBILITY CHANGE REQUEST | MOBILITY CHANGE ACKNOWLEDGE | MOBILITY CHANGE FAILURE |
| IAB Transport Migration Management (IAB传输迁移管理) | IAB TRANSPORT MIGRATION MANAGEMENT REQUEST | IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE | IAB TRANSPORT MIGRATION MANAGEMENT REJECT |
| IAB Transport Migration Modification (IAB传输迁移修改) | IAB TRANSPORT MIGRATION MODIFICATION REQUEST | IAB TRANSPORT MIGRATION MODIFICATION RESPONSE | |
| IAB Resource Coordination (IAB资源协调) | IAB RESOURCE COORDINATION REQUEST | IAB RESOURCE COORDINATION RESPONSE | |
| Partial UE Context Transfer (部分UE上下文传输) | PARTIAL UE CONTEXT TRANSFER | PARTIAL UE CONTEXT TRANSFER ACKNOWLEDGE | PARTIAL UE CONTEXT TRANSFER FAILURE |
| Data Collection Reporting Initiation (数据采集上报启动) | DATA COLLECTION REQUEST | DATA COLLECTION RESPONSE | DATA COLLECTION FAILURE |
场景代入：“我们再回到‘李雷’的高铁场景。源基站A要将李雷切换到目标基站B。A必须知道B是否同意接收、是否已经为李雷准备好了资源。所以，‘切换准备’（Handover Preparation）流程必须是Class 1。A发送HANDOVER REQUEST，如果B一切就绪，就回复HANDOVER REQUEST ACKNOWLEDGE，A就可以继续后续的切换执行步骤。如果B资源紧张，无法接收李雷，它就必须回复HANDOVER PREPARATION FAILURE，并附上原因，比如‘目标小区资源不可用’。A收到失败消息后，就知道这次切换尝试失败了，可能会选择另一个候选基站C。”
2.2 Class 2 基本流程：单向通知的简洁交互
接着，陈工展示了Table 8.1-2: Class 2 Elementary Procedures。
“Class 2流程，则是‘单向通知’式的交互。发起方只管发送消息，不期望、也不等待接收方的回复。这种模式非常高效，适用于那些信息传递本身即是目的、不需要协商或确认的场景。”
表 8.1-2: Class 2 基本流程 (注：根据规范原文重绘)
| Elementary Procedure (基本流程) | Initiating Message (发起消息) |
|---|---|
| Handover Cancel (切换取消) | HANDOVER CANCEL |
| SN Status Transfer (SN状态传递) | SN STATUS TRANSFER |
| RAN Paging (RAN寻呼) | RAN PAGING |
| Xn-U Address Indication (Xn-U地址指示) | XN-U ADDRESS INDICATION |
| S-NG-RAN node Reconfiguration Completion (S节点重配完成) | S-NODE RECONFIGURATION COMPLETE |
| S-NG-RAN node Counter Check (S节点计数器检查) | S-NODE COUNTER CHECK REQUEST |
| UE Context Release (UE上下文释放) | UE CONTEXT RELEASE |
| RRC Transfer (RRC传输) | RRC TRANSFER |
| Error Indication (错误指示) | ERROR INDICATION |
| Notification Control Indication (通知控制指示) | NOTIFICATION CONTROL INDICATION |
| Activity Notification (活动通知) | ACTIVITY NOTIFICATION |
| Secondary RAT Data Usage Report (第二RAT数据使用报告) | SECONDARY RAT DATA USAGE REPORT |
| Trace Start (跟踪开始) | TRACE START |
| Deactivate Trace (去激活跟踪) | DEACTIVATE TRACE |
| Handover Success (切换成功) | HANDOVER SUCCESS |
| Conditional Handover Cancel (条件切换取消) | CONDITIONAL HANDOVER CANCEL |
| Early Status Transfer (早期状态传递) | EARLY STATUS TRANSFER |
| Failure Indication (失败指示) | FAILURE INDICATION |
| Handover Report (切换报告) | HANDOVER REPORT |
| Resource Status Reporting (资源状态上报) | RESOURCE STATUS UPDATE |
| Access And Mobility Indication (接入与移动性指示) | ACCESS AND MOBILITY INDICATION |
| Cell Traffic Trace (小区流量跟踪) | CELL TRAFFIC TRACE |
| RAN Multicast Group Paging (RAN多播组寻呼) | RAN MULTICAST GROUP PAGING |
| SCG Failure Information Report (SCG失败信息报告) | SCG FAILURE INFORMATION REPORT |
| SCG Failure Transfer (SCG失败传递) | SCG FAILURE TRANSFER |
| F1-C Traffic Transfer (F1-C流量传输) | F1-C TRAFFIC TRANSFER |
| Retrieve UE Context Confirm (UE上下文检索确认) | RETRIEVE UE CONTEXT CONFIRM |
| Conditional PSCell Change Cancel (条件PSCell变更取消) | CONDITIONAL PSCELL CHANGE CANCEL |
| RACH Indication (RACH指示) | RACH INDICATION |
| Data Collection Reporting (数据采集上报) | DATA COLLECTION UPDATE |
场景代入：“还是李雷的切换场景。在基站A准备将李雷交给基站B时，为了保证数据传输的连续性，A需要把已发送和已接收数据包的PDCP序列号（SN）告诉B。这个动作就是‘SN状态传递’（SN Status Transfer）。A只管把这个状态信息打包成SN STATUS TRANSFER消息发给B就行，它不需要等B回复‘我收到了，正在处理’。A发送完毕后，就可以继续执行自己的后续动作了。这种‘发后不理’的模式，极大地提升了流程的效率。”
“好了，小林。”陈工总结道，“现在你已经掌握了XnAP流程的两种基本‘对话范式’。理论学习到此为止，现在我们立刻进入实战，深入剖析第一个，也是最重要的Class 1流程——8.2.1 切换准备 (Handover Preparation)。”
3. 深入实战：8.2.1 Handover Preparation (切换准备)
切换准备是保障移动性的基石，其目标是在UE真正接入目标小区之前，在目标基站侧完成所有必要的资源预留和上下文准备工作。
3.1 8.2.1.1 General (概述)
This procedure is used to establish necessary resources in an NG-RAN node for an incoming handover. If the procedure concerns a conditional handover, parallel transactions are allowed. Possible parallel requests are identified by the target cell ID when the source UE AP IDs are the same.
陈工为小林划出重点：“这一段概述非常精炼，包含三大信息点：”
- 核心目的：为即将到来的切换，在目标基站建立必要的资源。
- 并发特例：明确指出了条件切换（CHO）场景下，允许并行处理。源基站可以同时向多个候选目标基站发起切换准备。
- 并行识别：系统通过“相同的UE ID + 不同的目标小区ID”来识别这些并行的请求。
3.2 8.2.1.2 Successful Operation (成功操作)
陈工指向规范中的Figure 8.2.1.2-1: Handover Preparation, successful operation：“你看，最简单的成功流程就是这一来一回。但魔鬼藏在细节中，我们来看看HANDOVER REQUEST这个‘快递包裹’里到底装了些什么，以及目标基站收到后都做了哪些事。”
场景再现： 李雷乘坐的高铁正以350km/h的速度从基站A（源）的覆盖区驶向基站B（目标）。
第一步：源基站发起请求
The source NG-RAN node initiates the procedure by sending the HANDOVER REQUEST message to the target NG-RAN node. When the source NG-RAN node sends the HANDOVER REQUEST message, it shall start the timer TXnRELOCprep.
陈工的解读：“基站A的RRC层通过测量报告判断需要切换，于是触发XnAP层向基站B发送HANDOVER REQUEST消息。同时，它启动了一个名为TXnRELOCprep的定时器。这个定时器就像一个‘沙漏’，如果沙子漏完之前还没收到基站B的回复，基站A就认为这次请求超时失败了，会采取补救措施。”
HANDOVER REQUEST消息是XnAP中内容最丰富的消息之一，它携带了UE的完整“家底”，主要包括：
-
UE上下文信息 (UE Context Information)：
- 安全信息 (AS Security Information)：包括用于计算目标侧安全密钥的各种参数。基站B需要这些信息来预先计算出与UE通信的新密钥，确保切换后通信的无缝和安全。
- UE能力 (UE Security Capabilities, UE Radio Capability)：告诉基站B，李雷的手机支持哪些加密算法、支持哪些频段和特性，以便B为其配置最合适的功能。
- PDU会话资源列表 (PDU Session Resources To Be Setup List)：这是核心中的核心。李雷正在进行视频会议和文件下载，这对应着不同的PDU会话。这个列表详细描述了每个PDU会话的QoS要求（如视频会议需要低时延、文件下载需要高带宽）、数据转发地址等信息。
- RRC上下文 (RRC Context)：一个“黑盒子”，里面装着源基站A认为目标基站B需要知道的、关于UE的RRC配置信息。
-
目标小区ID (Target Cell Global ID)：明确告诉基站B，希望切换到它的哪个具体的小区。
第二步：目标基站处理请求并响应
基站B收到请求后，会进行一系列复杂的“入学准备”工作：
-
资源准入控制 (Admission Control)：基站B会检查自己是否有足够的资源（如PRB、调度容量等）来满足李雷所有业务的QoS要求。如果连视频会议的最低要求都满足不了，它就会拒绝这次切换。
-
资源预留：如果准入通过，基站B会为李雷预留无线资源，并准备好RRC配置信息。
-
安全密钥计算：利用请求中带来的安全信息，计算出新的AS层安全密钥。
-
准备数据转发隧道：
For each QoS flow for which the source NG-RAN node proposes to perform forwarding of downlink data, the source NG-RAN node shall include the DL Forwarding IE set to “DL forwarding proposed”… For each PDU session for which the target NG-RAN node decides to admit the data forwarding for at least one QoS flow, the target NG-RAN node may include the PDU Session level DL data forwarding UP TNL Information IE…
陈工的解读：“这是保证数据零丢失的关键。基站A在请求中会提议：‘对于这些数据流，我准备把没发完的数据转给你’。基站B如果同意，就会在回复中提供一个GTP-U隧道的地址（
UP TNL Information），相当于给A一个‘收货地址’。切换执行时，A就会把‘在途’的数据包通过这个隧道发给B。”
完成所有准备后，基站B会回复HANDOVER REQUEST ACKNOWLEDGE消息。这个消息中主要包含：
- PDU会话资源准入列表 (PDU Session Resources Admitted List)：告诉基站A，哪些业务的资源已经准备好了，以及对应的数据转发“收货地址”。
- PDU会话资源拒绝列表 (PDU Session Resources Not Admitted List)：如果某些业务无法满足，会在这里列出并说明原因。
- 目标侧RRC容器 (Target NG-RAN node To Source NG-RAN node Transparent Container)：这是另一个“黑盒子”，里面装着基站B为UE准备好的
RRCReconfiguration消息的核心部分。基站A会把这个容器“原封不动”地嵌入到它发给UE的切换指令中。
第三步：源基站完成准备
Upon reception of the HANDOVER REQUEST ACKNOWLEDGE message, the source NG-RAN node shall stop the timer TXnRELOCprep and terminate the Handover Preparation procedure. If the procedure was initiated for an immediate handover, the source NG-RAN node shall start the timer TXnRELOCoverall.
陈工的解读：“基站A收到成功的响应后，会停止‘沙漏’TXnRELOCprep，因为准备阶段已经成功完成。然后，它会启动一个新的、更长的‘沙漏’TXnRELOCoverall，用于监控整个切换流程（包括UE接入目标小区）是否在规定时间内完成。至此，XnAP的切换准备流程宣告结束，球被踢给了RRC层，由源基站向UE下发切换指令。”
4. 异常处理：切换准备的“B计划”
4.1 8.2.1.3 Unsuccessful Operation (失败操作)
If the target NG-RAN node does not admit at least one PDU session resource, or a failure occurs during the Handover Preparation, the target NG-RAN node shall send the HANDOVER PREPARATION FAILURE message to the source NG-RAN node. The message shall contain the Cause IE with an appropriate value.
陈工的解读：“如果基站B在资源准入控制时发现自己‘家底’不够，无法承接李雷的任何一项业务，或者发生了其他内部错误，它就必须回复HANDOVER PREPARATION FAILURE，并明确告知失败原因，如no-radio-resources-available-in-target-cell。这是Class 1流程的应有之义。”
4.2 8.2.1.4 Abnormal Conditions (异常条件)
陈工的解读：“异常情况主要有两种：”
-
定时器超时：如前所述，如果基站A的
TXnRELOCprep定时器超时，它会认为目标基站B“失联”或无响应，将主动取消此次切换准备，并可能触发对B的故障检测。 -
安全能力不匹配：
If the supported algorithms for encryption defined in the UE Security Capabilities IE … do not match any allowed algorithms defined in the configured list of allowed encryption algorithms in the NG-RAN node …, the NG-RAN node shall reject the procedure using the HANDOVER PREPARATION FAILURE message.
“如果基站A发来的信息显示，李雷的手机支持的加密算法，基站B一个都不支持，那么安全的通信就无法建立。这就像两个特工对不上暗号，接头失败。此时，基站B必须拒绝切换。”
5. 总结：承上启下的关键一步
小林听完陈工的讲解，茅塞顿开。他明白了，8.1节是对XnAP所有“对话”模式的顶层划分，为理解协议行为提供了框架。而8.2.1节的切换准备流程，则是这个框架下最生动、最关键的一个实例。它完美地展示了Class 1流程的严谨性，以及XnAP协议是如何通过精确的IE定义和严密的流程步骤，在两个基站之间高效、可靠地传递UE上下文，为上层无线移动性功能提供坚实支撑的。
这堂“入职第一课”让小林深刻认识到，理解协议不仅仅是看懂信令的一来一回，更是要理解其背后的设计原则、服务边界和异常处理逻辑。只有这样，才能在未来的开发和调试工作中游刃有余。
FAQ
Q1：TXnRELOCprep和TXnRELOCoverall这两个定时器有什么区别和联系？
A1：两者都是源基站在切换过程中启动的定时器。TXnRELOCprep用于监控切换准备阶段，从发送HANDOVER REQUEST开始，到收到HANDOVER REQUEST ACKNOWLEDGE或FAILURE结束。它确保了准备阶段能在规定时间内完成。而TXnRELOCoverall用于监控整个切换流程，从准备成功（收到ACK）后开始，直到UE成功接入目标小区（或最终切换失败）为止。它保证了整个切换过程不会无限期地挂起，避免UE上下文在源站和目标站长期冗余。
Q2：为什么UE Context Release（UE上下文释放）是一个Class 2流程，它难道不需要源基站确认“已释放”吗？
A2：UE Context Release通常由目标基站（在切换成功后）或新的基站（在RRC重建立成功后）触发，用于通知源/旧基站可以释放相关资源了。这是一个单向的“清理通知”。源/旧基站收到后执行清理即可，它是否成功释放，对于发起方（新基站）来说并不关心，也不影响后续流程。因此，为了效率，它被设计为Class 2流程。如果源/旧基站没有收到这个消息，其自身的资源管理机制（如TXnRELOCoverall超时）最终也会清理掉过期的UE上下文。
Q3：在双连接（DC）场景下，添加一个次节点（SN）的流程和切换流程有什么相似之处？
A3：两者非常相似。S-NODE ADDITION PREPARATION流程本质上也是一个资源准备过程，主节点（MN）扮演着类似源基站的角色，次节点（SN）扮演着类似目标基站的角色。MN也需要向SN发送一个包含UE上下文信息（安全、QoS、能力等）的请求消息（S-NODE ADDITION REQUEST），SN进行资源准入和准备，并回复确认或拒绝消息。它们都是Class 1流程，核心都是在一个新的节点上为UE预先建立上下文和资源。
Q4：HANDOVER REQUEST消息中的RRC Context为什么被称为“透明容器”？
A4：所谓“透明”，是指XnAP协议本身不解析、不修改这个容器里的内容。这个容器里装的是RRC协议层面的信息。源基站的RRC层将它需要传递给目标基站RRC层的信息打包好，交给XnAP层。XnAP层就像一个不关心包裹内容的快递员，只是把这个“包裹”安全地从源站送到目标站。目标站的XnAP层收到后，再把这个“包裹”原封不动地交给自己的RRC层去拆解和使用。这种设计体现了协议分层的思想，让各层专注于自己的职责。
Q5：如果一个HANDOVER REQUEST消息中包含了多个PDU会话，目标基站是否可以只同意其中一部分？
A5：是的，完全可以。这是XnAP切换准备流程非常灵活的一点。目标基站会对PDU Session Resources To Be Setup List中的每一个PDU会话进行独立的准入判断。对于可以满足QoS要求的PDU会话，它会将其资源配置信息放入响应消息的PDU Session Resources Admitted List中；对于由于资源不足或其他原因无法满足的，则会放入PDU Session Resources Not Admitted List中，并附上失败原因。源基站收到响应后，可以根据“战果”（成功了几个PDU会话）来决定是否继续执行这次“部分成功”的切换。