深度解析 3GPP TS 38.423：9.1.3 全局消息 (Part 1 - 接口的生命周期管理)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.3 Messages for Global Procedures”的核心章节。本文是该系列的第一部分，我们将聚焦于Xn接口生命周期管理的“三部曲”：
XN SETUP(9.1.3.1-3),NG-RAN NODE CONFIGURATION UPDATE(9.1.3.4-6), 和XN REMOVAL(9.1.3.13-15)，深入剖析基站间如何建立“外交关系”、保持信息同步以及最终“和平分手”。
1. 引言：从“个体”到“国家”的视角转变
在之前的篇章中，我们的工程师小林和他的导师陈工，已经全面探索了围绕着单个用户（UE）的各种XnAP流程，无论是切换、双连接还是RRC_INACTIVE态唤醒，其核心都是“UE关联信令”。然而，这些流程得以顺利运行，都有一个重要的前提：相关的基站之间已经“相互认识”，并建立了一条稳定可靠的Xn信令通道。
这天，小林在参与一次新5G基站的开通演练后，向陈工提出了一个根本性的问题：“陈工，我们之前讨论的都是基站A如何把UE切换给基站B。但基站A最初是如何知道‘B’这个邻居的存在的？它又是如何得知B的服务小区、支持频段等信息的？难道都是靠工程师手动配置吗？”
“手动配置是‘冷启动’的第一步，但一个能自我管理的智能网络，绝不能永远依赖人工。”陈工赞许道，“你已经从关注‘个体’（UE）的移动，上升到了关注‘国家’（基站）之间关系的层面。这就是我们今天要开启的全新篇章——全局流程（Global Procedures）。这些流程不与任何特定UE绑定，它们处理的是基站与基站之间的‘外交’和‘基础设施’问题。”
陈工在白板上画了两个方框，代表两个基站，并在它们之间画了一条线。“这条线就是Xn接口。它的建立、维护和拆除，构成了其完整的生命周期，而这个生命周期，正是由我们今天要学习的三个核心全局流程来管理的：”
- Xn Setup (Xn建立)：两个陌生基站的首次“建交”，交换彼此的“国情咨文”。
- NG-RAN node Configuration Update (NG-RAN节点配置更新)：已建交的“邦交国”之间，实时同步各自国内的**“重大变化”**。
- Xn Removal (Xn移除)：当合作关系不再需要时，进行的正式**“断交”**仪式。
这“建交-维交-断交”的三部曲，是所有上层移动性管理和资源协同功能得以实现的基础。
2. 9.1.3.1-3 Xn Setup - 基站间的首次“握手”
这是两个NG-RAN节点之间建立Xn接口应用层关系的第一个流程，也是所有后续协作的基石。
2.1 XN SETUP REQUEST (9.1.3.1) - 详尽的“自我介绍”
当一个新基站（gNB-New）被激活，并由运维人员配置了其邻居基站（gNB-Old）的传输层地址后，它会主动发起Xn Setup流程。
XN SETUP REQUEST 消息内容
方向: NG-RAN node₁ → NG-RAN node₂
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Message Type | M | 9.2.3.1 | |
| Global NG-RAN Node ID | M | 9.2.2.3 | 发起方的全网唯一身份标识 |
| TAI Support List | M | 9.2.3.20 | 发起方支持的跟踪区（TA）列表 |
| AMF Region Information | M | 9.2.3.83 | 发起方所连接的核心网AMF区域 |
| List of Served Cells NR/E-UTRA | O | 核心！ 发起方服务的小区详细列表 | |
| … | |||
| Partial List Indicator | O | 9.2.2.46 | 指示小区列表是否为部分列表 |
陈工的深度解读：
“这封‘建交请求’就像一份详尽的‘国情咨文’，gNB-New必须向gNB-Old坦诚地介绍自己的一切：”
Global NG-RAN Node ID: 这是gNB-New的“国家法定名称”，由PLMN ID和gNB ID组成，全网唯一。这是建立身份认同的基础。List of Served Cells: 这是最重要的附件。gNB-New会把自己管辖下的所有小区（Cells）的详细信息都列在里面，包括每个小区的CGI（全局ID）、PCI（物理小区ID）、频点、带宽、子载波间隔、广播的PLMN列表、支持的切片信息等。gNB-Old拿到这份“地图”后，才能在自己的系统中建立起对gNB-New服务范围的完整认知，并将其中的小区配置为自己的邻区。TAI Support List/AMF Region Information: 这些信息用于优化移动性。如果两个基站服务于相同的TAI或连接到同一个AMF区域，它们之间的移动性流程会更简单。
2.2 XN SETUP RESPONSE (9.1.3.2) - 对等的信息交换
这是一个Class 1流程，gNB-Old在审核通过后，必须回复响应。
The candidate NG-RAN node2 replies with the XN SETUP RESPONSE message.
XN SETUP RESPONSE消息与REQUEST消息的结构高度对称。gNB-Old在回复中，同样会附上自己的Global NG-RAN Node ID、List of Served Cells等完整信息。
陈工的解读：“Xn Setup是一个对等的信息交换过程。你把你的‘地图’给我，我也把我的‘地图’给你。这样，一次交互之后，双方就对彼此有了全面的了解，为未来的切换选路、负载均衡等决策提供了最原始、最重要的数据基础。”
2.3 XN SETUP FAILURE (9.1.3.3) - “建交”失败
如果gNB-Old无法接受gNB-New的建连请求，它会回复FAILURE消息。
CauseIE: 必须说明失败的原因，如unknown-GlobalNG-RAN-node-ID（不认识的发起方ID）、配置不兼容等。Time To WaitIE: 一个优雅的流控机制。gNB-Old可以建议gNB-New在等待一段时间后再重试，避免了无效的、频繁的重试攻击。
3. 9.1.3.4-6 NG-RAN NODE CONFIGURATION UPDATE - 网络的“朋友圈”动态
Xn Setup完成后，基站间的关系进入了“维护期”。网络是动态的，任何一方的配置变更，都必须及时通知对方。
3.1 NG-RAN NODE CONFIGURATION UPDATE (9.1.3.4) - “我变了，特此通知”
这是一个Class 1流程，用于在一个已建立的Xn接口上，同步应用层配置的增量变化。
NG-RAN NODE CONFIGURATION UPDATE 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| … | |||
| Served Cells To Add/Modify/Delete | O | 核心！ 小区列表的增、删、改 | |
| TNLA To Add/Remove/Update List | O | 传输层地址（SCTP）的增、删、改 | |
| AMF Region Information To Add/Delete | O | AMF区域信息的增、删 | |
| … |
陈工的解读：“这个流程就像基站的‘朋友圈’。一旦有任何风吹草动，必须立刻‘发个动态’通知所有‘好友’。”
- 小区增删改: 这是最常见的场景。
gNB-New新增了一个小区，就通过Served Cells To Add通知gNB-Old更新邻区表；一个小区下线了，就通过Served Cells To Delete通知gNB-Old删除邻区关系。 - 传输网络（TNLA）管理: 如果
gNB-New增加了一个新的IP地址用于Xn信令，它会通过TNLA To Add List通知gNB-Old建立新的SCTP连接。
3.2 ...UPDATE ACKNOWLEDGE (9.1.3.5) / ...FAILURE (9.1.3.6)
接收方收到UPDATE后，会执行相应的配置更新，并回复ACKNOWLEDGE表示“更新收到并已处理”。如果无法处理，则回复FAILURE并说明原因。这确保了每一次配置变更都是一个闭环、可靠的操作。
4. 9.1.3.13-15 Xn Removal - “外交关系”的终结
当两个基站间的Xn连接不再需要时（例如，其中一个站点要退服），就需要一个正式的流程来拆除它。
4.1 XN REMOVAL REQUEST (9.1.3.13) - “分手”前的最后通牒
这是一个由任意一方发起的Class 1流程。
XN REMOVAL REQUEST 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| Cause | M | |
| Xn Removal Threshold | O | 9.2.3.54 |
陈工的解读：“Xn Removal是一个受控的‘分手’流程。Cause IE说明了‘分手’原因，如o&m-intervention（运维操作）。Xn Removal Threshold IE则是一个SON特性，允许发起方提出一个‘带条件的解约’：‘如果你觉得我们这段关系的价值（Xn Benefit Value）已经低于某个门限，那就同意解约吧’，这使得网络可以自动清理低效的Xn链路。”
4.2 ...RESPONSE (9.1.3.14) / ...FAILURE (9.1.3.15)
接收方如果同意，则回复XN REMOVAL RESPONSE。双方收到确认后，便会清空与对方相关的所有应用层配置，并可以拆除底层的SCTP连接。如果不同意，则回复XN REMOVAL FAILURE。
5. 总结：从无到有，从有到优，从优到终
小林恍然大悟。他明白了，XnAP的全局流程，为基站间的“外交关系”描绘了一幅完整的生命周期画卷。
Xn Setup是**“从0到1”**的创造，它让陌生的基站建立起互信，交换了赖以协作的基础信息。NG-RAN node Configuration Update是**“从1到N”**的维护，它确保了基站间的认知与网络的动态现实时刻保持同步，是网络“自愈”和“自优化”的保障。Xn Removal则是**“从N到0”**的终结，它提供了一个优雅、受控的退出机制，确保了网络拓扑的有序演进。
这套完整的生命周期管理流程，是所有上层移动性功能（切换、双连接等）得以可靠、高效运行的坚实地基。没有稳固的“邦交”，一切上层“贸易往来”都无从谈起。
FAQ
Q1：Xn Setup和NG-RAN node Configuration Update都传递小区列表，有什么区别？
A1：Xn Setup传递的是全量的小区列表，用于初次建立邻居关系。而NG-RAN node Configuration Update传递的是增量的变化，即Add, Modify, Delete列表，用于在已有关系的基础上进行更新。UPDATE消息的粒度更细，开销更小，适用于频繁的动态调整。
Q2：基站是如何知道邻居基站的IP地址来发起Xn Setup的？
A2：这通常是通过网管系统（O&M）进行预配置的。在基站开通时，运维人员会在其配置中指定其物理邻居的IP地址列表。基站启动后，就会自动向这些地址发起SCTP连接建立和后续的Xn Setup流程。在更高级的SON方案中，也可能通过ANR（Automatic Neighbor Relation）功能，由UE上报的测量报告来自动发现未知邻居，并由网络后台触发Xn的自动建立。
Q3：Reset流程和Xn Removal流程都会清空上下文，它们有什么不同？
A3：Reset是异常恢复流程，它清空的是UE相关的动态上下文，但保留了基站间的全局配置信息。Reset后，Xn接口仍然是建立状态，可以立刻开始处理新的UE流程。而Xn Removal是接口拆除流程，它会清空所有与该Xn接口相关的信息，包括Xn Setup时交换的全局配置。Removal后，Xn接口就不存在了，两个基站恢复到“陌生人”状态。前者是“重启电脑”，后者是“格式化硬盘并拔掉网线”。
Q4：如果一个基站同时向另一个基站发起了Xn Setup请求，会发生什么？
A4：这被称为“glare case”（冲突竞争）。3GPP为此定义了明确的仲裁规则。两个基站会比较彼此的Global NG-RAN Node ID。ID值较高的一方将“获胜”，继续扮演发起者的角色；ID值较低的一方则会放弃自己的REQUEST，转为接收方的角色，处理对方的请求。这确保了最终只会建立一条唯一的Xn信令关系。
Q5：这些全局流程的执行频率是怎样的？会占用很多信令资源吗？
A5：这些流程的执行频率通常不高。Xn Setup和Xn Removal只在基站开通和退服时执行。NG-RAN node Configuration Update只在网络配置发生变更时才触发。Reset只在发生严重故障时使用。因此，相比于海量的、与UE移动性相关的流程，全局流程占用的信令资源非常小，但它们的作用却是基础性和决定性的。