深度解析 3GPP TS 38.423：9.1.1 基础移动性消息 (Part 1 - 切换核心消息)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.1 Messages for Basic Mobility Procedures”的核心章节。本文是深入XnAP协议“数据字典”的第一篇，我们将聚焦于整个基础移动性管理中最为核心的交互——切换准备（Handover Preparation）所涉及的关键消息：
HANDOVER REQUEST、HANDOVER REQUEST ACKNOWLEDGE和HANDOVER PREPARATION FAILURE，逐一剖析它们的内部构造与信息元素的深层含义。
1. 引言：从“行为”到“语言”的深入
在之前的系列文章中，我们的初级工程师小林在他的导师陈工的指导下，已经全面学习了第8章定义的XnAP“行为剧本”。他知道了基站间如何进行切换准备、如何建立双连接、如何处理故障。这些流程如同精心编排的芭蕾舞，定义了每一个角色的动作和走位。
这天，小林接到了他的第一个正式开发任务：实现Handover Preparation流程的信令编解码模块。他看着第8章的流程图，感到了一丝迷茫：“陈工，我知道源基站要向目标基站发送一个HANDOVER REQUEST消息，但我不知道这封‘信’里具体要写什么？格式是怎样的？哪些是必填项，哪些是选填项？”
陈工笑了：“问得好。你已经从一个‘戏剧评论家’，转变为一个需要理解每一句台词的‘剧作家’了。第8章告诉我们‘演员该做什么’，而从第9章开始，我们将学习‘演员该说什么’。第9章**‘Elements for XnAP Communication’**，就是XnAP协议的‘官方字典’和‘语法书’。它用最精确的语言，定义了每一个信令消息的DNA。”
陈工进一步解释道：“第9章分为三个核心部分：
- 9.1节：用表格定义了每个消息由哪些‘零件’——即信息元素（IE）——组成。
- 9.2节：详细解释了每一个‘零件’（IE）的具体含义和数据结构。
- 9.3节：提供了所有消息和IE的ASN.1代码，这是我们程序员可以直接用来‘翻译’成代码的‘天书’。
今天，我们就从9.1.1 Messages for Basic Mobility Procedures入手，首先攻克最重要、也是最复杂的HANDOVER REQUEST消息，看看为了让‘李雷’在高铁上的一次无缝切换，源基站的这封‘切换申请信’到底写得有多详尽。”
2. 9.1.1.1 HANDOVER REQUEST - 一份承载着UE“前半生”的申请书
这是切换准备流程的发起消息，由源NG-RAN节点发送给目标NG-RAN节点，请求为一次切换准备资源。它的重要性不言而喻，其内容的完整性和准确性，直接决定了切换能否成功。
This message is sent by the source NG-RAN node to the target NG-RAN node to request the preparation of resources for a handover.
2.1 消息结构概览
陈工指导小林，首先要通读9.1.1.1节的整个消息表格，建立一个宏观的认识。
HANDOVER REQUEST 消息内容 方向: source NG-RAN node → target NG-RAN node
| IE/Group Name (信息元素/组名) | Presence (存在性) | Range (范围) | IE type and reference (IE类型和引用) | Semantics description (语义描述) | Criticality (关键性) | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.2.3.1 | YES | reject | ||
| Source NG-RAN node UE XnAP ID reference | M | NG-RAN node UE XnAP ID 9.2.3.16 | Allocated at the source NG-RAN node. (源节点分配) | YES | reject | |
| Cause | M | 9.2.3.2 | YES | reject | ||
| Target Cell Global ID | M | 9.2.3.25 | Includes either an E-UTRA CGI or an NR CGI. (包含E-UTRA或NR的小区全局ID) | YES | reject | |
| GUAMI | M | 9.2.3.24 | YES | reject | ||
| UE Context Information | 1 | YES | reject | |||
| >NG-C UE associated Signalling reference | M | AMF UE NGAP ID 9.2.3.26 | Allocated at the AMF on the source NG-C connection. | – | ||
| >… | … | … | ||||
| UE Context Information | M | 包含UE上下文的详细信息 | ||||
| >UE Security Capabilities | M | 9.2.3.49 | – | |||
| >AS Security Information | M | 9.2.3.50 | – | |||
| >PDU Session Resources To Be Setup List | 1 | 9.2.1.1 | 包含UL隧道信息、QoS到DRB的映射等 | – | ||
| >RRC Context | M | OCTET STRING | 透明容器，包含切换准备信息 | – | ||
| … | ||||||
| Conditional Handover Information Request | O | YES | reject | |||
| >CHO Trigger | M | ENUMERATED(…) | 指示是CHO发起还是替换 | – | ||
| … |
(注：上表仅为规范表格的简化示意，用于展示其结构，省略了大量IE以保持篇幅)
“小林你看，”陈工指着表格，“这个表格就是我们的‘开发需求文档’。每一行都定义了一个IE。Presence列告诉我们这个IE是M (Mandatory, 强制)、O (Optional, 可选)还是C (Conditional, 条件)。Criticality列则指导我们，如果收到不认识的IE该怎么办。现在，我们来挑几个最重要的‘字段’进行精讲。”
2.2 核心IE深度剖析
1. Message Type (消息类型)
- Presence: M
- 陈工解读：“这是每个消息的‘信封封面’。接收方拿到一个XnAP消息后，第一个要看的就是这个IE，它通过一个唯一的ID，告诉接收方‘我是一封切换请求信’，从而让接收方知道应该调用哪个处理函数来解析和处理后续的内容。这是所有消息交互的基础。”
2. Source/Target NG-RAN node UE XnAP ID (源/目标节点UE XnAP ID)
- Presence: M (在
REQUEST中是Source ID, 在ACKNOWLEDGE中两者都有) - 陈工解读：“这两个ID是这次UE相关的XnAP‘会话’的唯一标识。当源基站A决定要为李雷发起切换时，它会在本地为李雷创建一个XnAP上下文，并分配一个
Source...ID。目标基站B在准备好资源后，也会在本地为李雷创建上下文，并分配一个Target...ID。后续所有与这次切换相关的消息，都会带上这两个ID，就像邮件的收件人和发件人地址，确保信令能够被正确地路由到对应的UE上下文中进行处理。”
3. Cause (原因)
- Presence: M
- 陈工解读：“这是切换的‘动机’。源基站A必须明确告知B，为什么要发起这次切换。
Cause是一个枚举类型，常见的值有：radio-reasons(无线原因，如信号质量差)、resource-optimisation(资源优化)、reduce-load-in-serving-cell(为服务小区减负)等等。这个IE对于网络运维和SON算法至关重要，通过统计分析切换原因，可以深入洞察网络的移动性行为和负载状况。”
4. UE Context Information (UE上下文信息组)
- Presence: M
- 陈工解读：“这才是
REQUEST消息的‘正文’，是一个巨大的信息集合，几乎包含了UE在源基站的‘所有档案’。”UE Security Capabilities&AS Security Information: 这部分是进行安全上下文推导的“原料”。目标基站B需要根据这些信息，计算出与UE进行通信的新的安全密钥，确保切换后的通信依然是加密和受完整性保护的。PDU Session Resources To Be Setup List: 这是最核心的业务信息。它是一个列表，包含了UE当前所有激活的PDU会话的详细配置。对于每个会话，都指明了：S-NSSAI: 该会话属于哪个网络切片。QoS Flows To Be Setup List: 会话内的每个QoS流的参数（QFI, 5QI, GBR, MBR等）。Source DRB to QoS Flow Mapping List: 告知目标基站，在源站这边，这些QoS流是映射到哪个数据无线承载（DRB）上的。- 数据转发提议: 包含
DL ForwardingIE，向目标基站提议进行下行数据转发。
RRC Context: 一个“透明容器”。源基站的RRC层将它认为目标基站需要知道的RRC配置（如测量配置、MAC配置、物理层配置等）打包进去。XnAP层只负责“搬运”这个容器，而不关心其内部的具体内容。
3. 9.1.1.2 & 9.1.1.3 - “批复”与“驳回”
3.1 HANDOVER REQUEST ACKNOWLEDGE (切换准备确认)
当目标基站B成功为UE准备好资源后，它会回复此消息。
HANDOVER REQUEST ACKNOWLEDGE 消息内容
| IE/Group Name | Presence | Semantics description |
|---|---|---|
| Message Type | M | |
| Source NG-RAN node UE XnAP ID | M | 从请求中拷贝，用于关联 |
| Target NG-RAN node UE XnAP ID | M | 目标节点新分配的ID |
| PDU Session Resources Admitted List | M | 成功准备的PDU会话列表 |
| >DL Forwarding UP TNL Information | M | 关键！ 提供了用于数据转发的GTP-U隧道地址 |
| PDU Session Resources Not Admitted List | O | 未能成功准备的PDU会话列表，附带原因 |
| Target NG-RAN node to Source… Container | M | 关键！ 透明容器，包含发往UE的RRC重配指令核心 |
| … |
陈工的解读：“ACKNOWLEDGE消息的核心是反馈结果和提供执行信息。
Admitted List中的DL Forwarding UP TNL Information，就是B给A的下行数据转发‘收货地址’。Target...Container则是B交给A，让A转交给UE的‘登机牌’。A会把这个‘登机牌’封装在RRCReconfiguration消息中发给UE，指令其执行切换。”
3.2 HANDOVER PREPARATION FAILURE (切换准备失败)
当目标基站无法准备资源时，回复此消息。
HANDOVER PREPARATION FAILURE 消息内容
| IE/Group Name | Presence | Semantics description |
|---|---|---|
| Message Type | M | |
| Source NG-RAN node UE XnAP ID | M | |
| Cause | M | 关键！ 必须说明失败的原因 |
| Criticality Diagnostics | O | 提供更详细的诊断信息 |
陈工的解读：“失败消息的核心就是Cause IE。它会明确告知源基站失败的原因，如no-radio-resources-available-in-target-cell。源基站收到后，就可以根据原因，决定是重试，还是选择另一个候选小区，或者放弃切换。”
4. 总结：信令设计中的“完备与精巧”
小林通过对这三个核心切换消息的学习，对信令设计有了全新的认识。他明白了，一个看似简单的“切换”动作，背后需要如此详尽和严谨的信息交换来支撑。
HANDOVER REQUEST体现了信令设计的完备性。它必须携带足够的信息，让目标节点能够在完全不了解UE历史的情况下，为其重建一个完整的、无缝的业务环境。ACKNOWLEDGE和FAILURE则体现了闭环与反馈的重要性。它们确保了源节点的每一次请求都能得到明确的答复，从而能够进行可靠的后续决策。Transparent Container的使用，则展现了协议分层的解耦思想，使得XnAP可以专注于节点间的交互逻辑，而将复杂的RRC配置交由RRC层自身来处理。
对于小林来说，他的任务就是将这些表格中定义的每一个IE，精确地转化为代码中的数据结构，并编写严格的编解码函数，确保自己的实现能够与全球任何其他遵循此规范的设备互联互通。这正是协议开发工作的核心魅力所在——构建数字世界的通用语言。
FAQ
Q1：为什么HANDOVER REQUEST中需要包含GUAMI（Globally Unique AMF Identifier）？
A1：GUAMI用于唯一标识UE所注册的核心网AMF。目标基站在切换成功后，需要向核心网发起路径更新。通过请求中携带的GUAMI，目标基站可以知道应该将路径更新消息路由到哪个AMF。这在存在多个AMF或AMF Pool的复杂网络环境中至关重要。
Q2：PDU Session Resources To Be Setup List和DRBs To Be Setup List有什么区别？
A2：这两个IE用于不同的流程，层级也不同。PDU Session Resources...是PDU会话级的，包含了该会话的S-NSSAI、QoS流等核心网层面的信息，它出现在HANDOVER REQUEST等需要从头建立承载的流程中。而DRBs To Be Setup List是数据无线承载（DRB）级的，它通常出现在双连接的修改流程中，用于指示在已有的PDU会话下，具体要添加或修改哪些DRB。前者更宏观，后者更具体。
Q3：一个HANDOVER REQUEST ACKNOWLEDGE中，能否同时包含Admitted List和Not Admitted List？
A3：可以，并且这是非常常见的场景。这被称为部分切换（Partial Handover）。例如，UE有两个PDU会话，一个高优先级的IMS通话，一个低优先级的后台下载。目标基站可能资源紧张，只能满足IMS通话的资源请求，而无法满足下载的请求。此时，它就会在ACKNOWLEDGE中，将IMS会话放在Admitted List，将下载会话放在Not Admitted List。源基站收到后，可以根据策略决定是否继续执行这次“部分成功”的切换。
Q4：为什么HANDOVER PREPARATION FAILURE也需要一个Criticality Diagnostics IE？
A4：Cause IE通常只提供一个标准的、预定义的失败原因码。但在某些复杂的失败场景下，例如，源基站发送的REQUEST消息本身存在语法错误，导致目标基站无法解析。此时，目标基站除了回复一个通用的abstract-syntax-error的Cause之外，还可以通过Criticality Diagnostics IE，更精确地指出是REQUEST消息中的哪一个IE、哪一个字段出现了什么类型的错误。这为跨厂商互联互通的故障定位提供了极其宝贵的调试信息。
Q5：ASN.1在这些消息定义中具体起什么作用？ A5：ASN.1（Abstract Syntax Notation One）提供了一种与编程语言、硬件平台无关的、用于描述数据结构的“抽象语法”。第9.3节使用ASN.1将9.1和9.2节中表格描述的所有消息和IE，转换成了一套形式化的、无歧义的文本定义。然后，通过PER（Packed Encoding Rules）等编码规则，可以将ASN.1定义的抽象数据结构，编码成一段紧凑的、可以在网络中传输的二进制比特流。接收方再根据同样的ASN.1定义和PER规则进行解码，就能100%还原出原始的数据结构。ASN.1是实现不同厂商设备间信令互通的基石。