深度解析 3GPP TS 38.423：3-7章 基础构件与通用原则

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“3 Definitions, symbols and abbreviations”、“4 General”、“5 XnAP services”、“6 Services expected from signalling transport”以及“7 Functions of XnAP”这五个核心基础章节。本文旨在将这些看似零散但至关重要的“协议元规则”整合解读，为读者揭示XnAP协议的内部逻辑、设计哲学与服务边界。

1. 引言：协议工程师的“入职第一课”

在上一篇的总体概述中，我们已经了解了XnAP协议是5G基站间的“社交语言”，保障了“李雷”在高铁上的无缝通信体验。现在，让我们切换视角，引入一位新的主角——小林，一位刚刚加入5G协议栈开发团队的初级工程师。他的导师，经验丰富的陈工，交给他一份任务：在深入研究具体的切换流程（第8章）之前，必须先彻底吃透38.423规范的第3到第7章。

小林初看之下有些疑惑，这些章节没有复杂的信令流程图，多是定义、原则和分类，似乎有些“务虚”。陈工笑着说：“盖万丈高楼，必先固其基。这几章就是XnAP这座大厦的地基。如果你不理解协议的‘立法原则’、‘通用语言’和‘服务边界’，直接去看具体流程，就像一个不懂语法的学生去阅读莎士比亚原著，必然会处处碰壁，甚至产生错误的理解。今天，我就带你上这堂‘入职第一课’，学习如何正确地解读一份3GPP应用层协议。”

本文将跟随陈工和小林的对话，将第3章到第7章的内容融会贯通，从一个协议设计者和实现者的角度，深入剖析XnAP协议赖以构建的基石。

2. 第3章 Definitions, symbols and abbreviations (定义、符号与缩略语) - 统一的语言是协作的开始

陈工打开规范，指着第3章对小林说：“我们团队开发XnAP协议栈，第一件事就是把这一章所有的定义和缩略语，转化成我们代码里的常量、枚举和数据结构。为什么？因为这是我们与全世界所有其他厂商设备对话的‘共同语言’。”

2.1 Definitions - 概念的精确界定

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905.

陈工解释道：“你看，规范首先确立了一个原则：大部分通用术语遵循‘3GPP大字典’TR 21.905。但如果38.423对某个术语有更具体的定义，那么在本规范内，‘本地法’大于‘通用法’。这种精确性是避免产生歧义的关键。”

他指着几个关键定义，开始为小林讲解：

• Elementary Procedure (基本流程, EP)

  Elementary Procedure: XnAP protocol consists of Elementary Procedures (EPs). An XnAP Elementary Procedure is a unit of interaction between two NG-RAN nodes. An EP consists of an initiating message and possibly a response message. Two kinds of EPs are used:

  • Class 1: Elementary Procedures with response (success or failure),
  • Class 2: Elementary Procedures without response.

  陈工的解读：“小林，你要记住，XnAP的所有功能都是由一个个‘基本流程’构成的。一个EP就是为了完成一件小事，两个基站之间的一次完整‘对话’。比如，你问我‘在吗？’，我回答‘在’，这就是一个Class 1流程，有问有答。如果我只是通知你‘下班了’，然后就走了，不需要你回复，这就是一个Class 2流程。在XnAP里，‘切换准备’就是典型的Class 1，因为源基站必须知道目标基站是否准备好了。而‘SN状态传递’是Class 2，源基站只是把数据包序列号状态单向通知给目标基站，不需要对方确认‘收到’。”

• Conditional Handover (条件切换, CHO)

  Conditional Handover: As defined in TS 38.300.

  陈工的解读：“这个定义直接引用了38.300。这意味着要理解CHO的完整概念，你必须去读上游规范。简单说，传统切换是‘现在马上切换到B小区’。而条件切换是源基站提前告诉UE：‘你准备好，如果将来满足条件X（比如B小区的信号比A好很多），你就自己切换到B，不用再问我了’。这为高速移动场景提供了更快的切换执行，XnAP必须支持这种更智能的切换准备流程。”

• NG-RAN node

  NG-RAN node: as defined in TS 38.300.

  陈工的解读：“这是我们协议交互的主体。在5G SA网络里，它就是gNB。但在一些混合组网场景下，它也可能是ng-eNB（接入5G核心网的4G基站）。所以，我们的代码在处理时，必须能兼容这两种节点类型。这个定义看似简单，却划定了我们协议的适用对象。”

2.2 Abbreviations - 效率的密码

陈工翻到3.2节，屏幕上是密密麻麻的缩略语列表，如AMF, CGI, EN-DC, M-NG-RAN node等。

陈工的解读：“小林，这些缩略语就是我们通信工程师的‘黑话’，也是提高沟通效率的‘密码’。在信令消息中，我们用高度压缩的IE名称来传递复杂概念，这背后都对应着这些缩略语。你必须对它们了如指掌，看到M-NG-RAN node就要立刻反应过来这是双连接中的主基站，看到S-NSSAI就要知道这是网络切片选择辅助信息。把这个列表打印出来，贴在你的工位上，直到它们成为你的第二天性。”

3. 第4章 General (通用原则) - 协议的“立法精神”与“语法规则”

“理解了词汇，我们就要学习语法和法律了。”陈工将规范翻到第4章，“这一章定义了协议的行为准则，特别是如何处理异常和版本演进，这是保证我们开发的协议栈健壮、稳定、且能与未来版本兼容的关键。”

3.1 Procedure specification principles - “shall”与“if supported”的法律效力

The procedure text indicates that the receiving node “shall” perform a certain function Y under a certain condition. If the receiving node supports procedure X but cannot perform functionality Y requested in the initiating message of a Class 1 EP, the receiving node shall respond with the message used to report unsuccessful outcome for this procedure, containing an appropriate cause value.

The procedure text indicates that the receiving node “shall, if supported,” perform a certain function Y under a certain condition. If the receiving node supports procedure X, but does not support functionality Y, the receiving node shall proceed with the execution of the EP, possibly informing the requesting node about the not supported functionality.

陈工的解读：“这是整个规范中最需要仔细揣摩的两个句子，堪称协议的‘强制法’和‘授权法’。”

• shall (必须)： “小林，看到’shall’，就如同看到了法律里的‘必须’。这意味着，任何一个声称支持XnAP协议的设备，都必须实现这个功能。如果一个基站收到了一个它声称支持的流程请求，但由于某种原因（比如资源不足）无法完成其中‘shall’规定的动作，它不能沉默，必须回复一个失败消息，并给出明确的失败原因（cause value）。这是强制性义务。”

• shall, if supported (如果支持，则必须)：“这个短语是为可选功能设计的。比如，某个Rel-18新增的、非常酷炫的节能特性。规范允许厂商暂时不支持这个特性。但是，如果你决定要实现它（‘if supported’），那么你的实现方式就必须严格遵守规范的规定（‘shall’）。这确保了可选功能一旦实现，其行为也是标准化的，能被其他厂商的设备正确理解和交互。”

3.2 Forwards and backwards compatibility - 穿越时空的兼容艺术

The forwards and backwards compatibility of the protocol is assured by a mechanism where all current and future messages, and IEs or groups of related IEs, include ID and criticality fields that are coded in a standard format that will not be changed in the future. These parts can always be decoded regardless of the standard version.

陈工的解读：“想象一下，你们团队用的是Rel-18的协议栈，而另一个城市的团队用的是Rel-17的。你们之间通信，怎么保证不出问题？这就是前后向兼容性的艺术，核心机制就是 TLV (Tag-Length-Value) 编码思想的体现，在这里具体化为 IE ID + Criticality + Length + Value 的结构。”

他画了一张图：

| IE ID | Criticality | Length | Value (IE的具体内容) |

• IE ID：每个信息元素的唯一“身份证号”。
• Criticality (关键性)：这是兼容性的灵魂。它告诉接收方，如果我不认识这个IE（因为我的版本比较老），我应该怎么办？
  • reject：拒绝。整个消息都有问题，我无法解析，必须拒绝整个流程。
  • ignore：忽略。这个不认识的IE对我来说不重要，我可以跳过它，继续处理消息中我认识的其他部分。
  • notify：通知。我忽略了这个不认识的IE，并继续处理流程，但我会发个消息告诉你，我忽略了某个东西。

场景代入：“假设Rel-18的HANDOVER REQUEST消息增加了一个可选的IE，叫‘高铁场景优化建议’，它的Criticality被设为‘ignore’。当你的Rel-18基站把这个消息发给Rel-17的基站时，Rel-17基站解析到这个IE，发现IE ID不认识，它查看Criticality是‘ignore’，于是它就根据Length字段跳过这个IE的数据，继续处理后面的它认识的IE，整个切换流程不受影响。这就是后向兼容性（新版本兼容老版本）。反之，你的Rel-18设备也能正确解析Rel-17发来的、不含这个新IE的消息，这就是前向兼容性（老版本兼容新版本）。这个机制保证了网络可以平滑升级。”

4. 第5/6/7章 Services, Transport, Functions - 服务的边界与依赖

陈工快速地翻过这三章，对小林说：“这三章非常简短，但它们共同定义了XnAP的服务模型、对底层的依赖，以及自身功能的顶层归属，是我们理解协议边界的窗口。”

4.1 XnAP procedure modules (第5.1节) - 业务的分类管理

The Xn interface XnAP procedures are divided into two modules as follows:

1. XnAP Basic Mobility Procedures;
2. XnAP Global Procedures;

陈工的解读：“这是从功能角度对所有流程进行的高层分类。‘Basic Mobility Procedures’处理的是与单个用户（UE）相关的移动性事件，比如李雷的切换。而‘Global Procedures’处理的是基站间‘建交’和‘系统维护’级别的事件，与任何特定用户无关，比如两个基站第一次建立Xn连接。这种模块化划分，在我们设计软件架构时也很有用，可以把UE相关的上下文处理逻辑和全局的配置管理逻辑分离开来。”

4.2 Parallel transactions (第5.2节) - 并发操作的规则

Unless explicitly indicated in the procedure specification, at any instance in time one protocol peer shall have a maximum of one ongoing XnAP procedure related to a certain UE.

陈工的解读：“这是一个重要的并发控制原则。通常情况下，为了避免状态混乱，对于同一个UE，一个基站只能向另一个基站发起一个XnAP流程。比如，不能同时对李雷发起切换和双连接添加。但是，规范也留了口子——‘Unless explicitly indicated’（除非明确指出）。条件切换（CHO）就是一个例外，它明确允许为一个UE向多个目标小区并行发起多个切换准备流程。理解这个规则，对于我们处理多线程和资源锁非常有帮助。”

4.3 Services expected from signalling transport (第6章) - 对“快递公司”的要求

The signalling connection shall provide in sequence delivery of XnAP messages. XnAP shall be notified if the signalling connection breaks. Xn signalling transport is specified in TS 38.422.

陈工的解读：“这一章定义了XnAP对底层传输协议的‘服务等级协议’(SLA)。XnAP作为‘客户’，它对承载它的‘快递公司’（由38.422定义的SCTP/IP）提出了两个核心要求：

1. 按序送达 (in-sequence delivery)：我按1, 2, 3的顺序发出的信件，你必须按1, 2, 3的顺序送到。SCTP协议的多流特性天然保证了这一点。
2. 故障通知 (notified if breaks)：如果运送的道路断了，你必须马上通知我。这样我（XnAP）才能知道对方已经失联，并触发相应的异常处理流程。 这体现了协议分层的解耦思想：XnAP专注于应用逻辑，而将可靠传输的任务委托给下层。”

4.4 Functions of XnAP (第7章) - 职责的归属

The functions of XnAP are specified in TS 38.420.

陈工的解读：“这是一个纯粹的‘指路牌’。它告诉我们，如果你想从更高层面了解XnAP协议需要实现哪些功能，请去查阅TS 38.420。这再次强调了我们之前谈到的规范层级关系，强化了你阅读规范时的导航能力。”

5. 总结：打通协议理解的“任督二脉”

陈工合上规范，对小林总结道：“你看，我们花了很长时间研读了这几个看似简单的章节。现在，你应该明白了，它们共同为XnAP协议构建了一个严谨的‘世界观’：”

• 第3章 定义了这个世界通用的“语言和词汇”。
• 第4章 确立了这个世界运行的“法律和语法”，尤其是兼容性原则。
• 第5章 划分了这个世界的核心“业务领域”（移动性和全局管理），并规定了“行为准则”（并发控制）。
• 第6章和第7章 则明确了这个世界与“外部世界”（底层传输和上层功能定义）的关系和依赖。

“掌握了这些，你才真正具备了解读后续复杂信令流程的基础。从明天开始，我们再去看第8章的具体流程时，你就会发现，每一个流程的设计，每一个IE的选择，都遵循着我们今天所学的这些基本原则。这堂‘入职第一课’，就是为你打通理解3GPP协议的‘任督二脉’。”

从下一篇文章开始，我们将正式进入第8章，从第一个基本流程——“Handover Preparation”开始，看一看在这些原则的指导下，一场精彩的基站间切换大戏是如何上演的。

FAQ

Q1：为什么规范要区分Class 1和Class 2两种基本流程？ A1：这是基于交互模型的不同需求。Class 1流程用于需要确认或协商的场景，发送方必须等待接收方的响应（成功或失败）才能进行下一步操作，这确保了双方状态的同步，例如切换准备。Class 2流程用于单向通知或状态传递，发送方不关心接收方是否处理完毕，这可以简化流程、降低时延，例如SN状态传递，源站只是尽快将信息发出，无需等待确认。

Q2：如果一个旧版本的基站收到了一个包含不认识的、关键性（Criticality）为reject的IE的消息，它会怎么做？ A2：根据4.2节的兼容性原则，当接收方遇到一个它不认识的IE，并且该IE的Criticality被标记为reject时，它必须认为整个消息都是无法处理的。如果这是一个Class 1流程的请求消息，接收方必须回复对应的失败消息，并在原因值中指出错误原因（如“Abstract Syntax Error”）。这是一种保护机制，防止因无法理解关键信息而导致网络状态不一致或产生更严重的问题。

Q3：XnAP协议本身是否是有状态的？ A3：是的，XnAP是典型的有状态协议。例如，在一个切换流程中，源基站和目标基站都会为特定的UE建立一个临时的“XnAP上下文”，记录当前流程的状态（如“切换准备中”、“切换已完成”）。第5.2节关于“并行事务”的规定，正是为了管理和保护这些与UE相关的状态，避免并发操作导致的状态冲突。

Q4：为什么规范要在第4.3节专门定义Procedure、Message、IE的命名格式？ A4：这是为了保证整个规范文档乃至所有3GPP规范的风格一致性和可读性。通过标准化的命名约定（如Procedure Name用大写首字母驼峰法+“procedure”，MESSAGE NAME全大写+“message”），读者可以仅从名称上就快速分辨出一个标识符的类型，这极大地提高了阅读和理解规范的效率，也便于自动化工具进行解析。

Q5：从第3章到第7章，可以看出XnAP协议设计最重要的原则是什么？ A5：最重要的原则可以概括为明确性、健壮性和可扩展性。明确性通过严格的定义（第3章）和规约原则（第4.1章）来保证；健壮性通过对底层传输的明确要求（第6章）和错误处理机制（隐含在流程设计中）来体现；而可扩展性则是通过精巧的前后向兼容性机制（第4.2章）来保障，使得协议可以在不断演进的3GPP版本中平滑地增加新功能，而不会破坏现有网络的运行。