深度解析 3GPP TS 38.423：8.4.2 NG-RAN node Configuration Update (网络的“动态心跳”)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.4.2 NG-RAN node Configuration Update”的核心章节。本文旨在为读者深入剖析在Xn接口建立之后，两个NG-RAN节点如何通过这一关键的全局流程，实时同步彼此的配置变更，保持网络拓扑的“新鲜度”，从而确保移动性管理、负载均衡和资源协同的持续高效。

1. 引言：从“静态快照”到“实时同步”

在上一篇文章中，我们见证了两个互不相识的5G基站——gNB-New和gNB-Old——通过严谨的Xn Setup流程，完成了首次“建交”。它们交换了详尽的“名片”和“能力清单”，对彼此的服务范围、无线能力等静态配置有了一个全面的了解。这就像为网络拓扑拍摄了一张高清的“快照”。

我们的工程师小林兴奋地对导师陈工说：“陈工，现在gNB-New和gNB-Old已经‘认识’了，是不是就可以高枕无忧地开始处理用户切换了？”

“高枕无忧？在通信世界里，唯一不变的就是‘变化’本身。”陈工笑着摇了摇头，“Xn Setup提供的仅仅是那一瞬间的静态快照。但网络是一个活生生的有机体，运营商随时可能进行扩容、升级、维护和优化。如果gNB-New今天新增了一个小区，或者gNB-Old为了节能，在午夜关闭了某个扇区，而它们彼此之间还拿着那张‘旧照片’按图索骥，会发生什么？”

小林立刻反应过来：“那切换决策就会基于过时的信息！比如，gNB-Old可能会尝试把用户切换到一个gNB-New上已经不存在的小区，导致切换失败。”

“完全正确！”陈工肯定道，“为了让这张‘快照’始终保持最新，基站之间必须有一个‘动态心跳’机制，定期或在发生变化时，立即通知所有邻居：‘我变了！’。这个机制，就是我们今天要学习的NG-RAN node Configuration Update流程。它确保了基站间的认知与物理网络的现实始终保持同步，是所有高级网络功能得以稳定运行的基石。”

2. 8.4.2.1 General (概述) - 保持“朋友圈”信息常新

The purpose of the NG-RAN node Configuration Update procedure is to update application level configuration data needed for two NG-RAN nodes to interoperate correctly over the Xn-C interface. The procedure uses non UE-associated signalling.

陈工为小林解读了这段概述，指出了其与Xn Setup的异同：

• 共同点：

  • 目的相似：都是为了交换应用层配置数据，确保Xn接口的正确互操作。
  • 信令性质相同：都是**非UE关联（non UE-associated）**的全局流程，处理的是基站级的系统信息，与任何特定用户无关。

• 根本区别：

  • Xn Setup是从无到有的创建过程，用于建立一个Xn接口实例。
  • Configuration Update是从有到新的更新过程，作用于一个已经建立的Xn接口之上，用于同步增量变化。

“你可以把Xn Setup想象成你和朋友第一次互加微信，交换了所有个人信息，”陈工打了个比方，“而Configuration Update就是你的朋友换了头像、改了签名或者发了一条新的朋友圈动态，微信系统会立刻通知你。这个流程，就是XnAP协议的‘朋友圈更新’机制。”

3. 8.4.2.2 Successful Operation (成功操作) - “变更通知”的详细解读

这是一个Class 1流程，发起方发出更新通知后，需要接收方回复一个确认，确保变更信息已被对方收到并理解。这个流程可以由Xn接口的任意一端发起。

The NG-RAN node1 initiates the procedure by sending the NG-RAN NODE CONFIGURATION UPDATE message to a peer NG-RAN node2.

3.2.1 核心功能：小区列表的增、删、改

网络中最频繁的变化莫过于小区的生命周期管理。NG-RAN NODE CONFIGURATION UPDATE消息的核心，就是围绕小区列表的动态维护。

场景代入：gNB-New在成功与gNB-Old建连后，网络持续进行着优化。

• 场景A：新增小区 (Add)

  If Served Cells NR To Add IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node2 shall add cell information according to the information in the Served Cell Information NR IE. 运维人员在gNB-New上激活了一个新的小区，用于覆盖一个新建的商业区。gNB-New会立即向gNB-Old发送UPDATE消息，其中包含Served Cells NR To Add IE。这个IE里是新小区的完整配置信息（CGI, PCI, TAC, 频点, 带宽等）。gNB-Old收到后，就会将这个新小区加入到自己的邻区数据库中，未来在做切换决策时，就可以考虑这个新的切换目标了。

• 场景B：修改小区 (Modify) 运营商决定将gNB-New下的某个小区的跟踪区码（TAC）进行变更。gNB-New会发送UPDATE消息，其中包含Served Cells NR To Modify IE。

  If Served Cells NR To Modify IE is contained… NG-RAN node2 shall modify information of cell indicated by Old NR-CGI IE according to the information in the Served Cell Information NR IE. 陈工提醒小林：“注意，这里的‘修改’操作，是整体替换。gNB-New会提供该小区的完整新配置，而不仅仅是变化的TAC值。gNB-Old收到后，会根据Old NR-CGI找到对应的小区记录，然后用收到的新信息将其完全覆盖。这简化了协议处理，避免了复杂的字段级比对。”

• 场景C：删除小区 (Delete) gNB-New上的一个小区因为硬件故障或计划性维护需要下线。gNB-New会发送UPDATE消息，其中包含Served Cells NR To Delete IE，里面是要删除小区的CGI。gNB-Old收到后，会立即将这个小区从其邻区列表中移除，确保不会再有用户被错误地切换到这个已经不可用的小区。

3.2.2 传输网络管理 (TNLA) - 扩建或拆除“信息高速路”

Xn接口的信令需要承载在SCTP连接上。当基站的传输网络配置发生变化时，也需要通过这个流程来同步。

If the TNLA To Add List IE is included in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node2 shall, if supported, use it to establish the TNL association(s) with the NG-RAN node1. If the TNLA To Remove List IE is included… the NG-RAN node2 shall, if supported, initiate removal of the TNL association(s)… If the TNLA To Update List IE is included… the NG-RAN node2 shall, if supported, update the TNL association(s)…

场景代入：为了提升与gNB-Old之间的信令带宽和可靠性，gNB-New的运维人员为其增加了一个新的IP地址用于Xn连接。

1. gNB-New会发送UPDATE消息，其中包含TNLA To Add List，列出了这个新的IP地址。
2. gNB-Old收到后，会尝试与这个新地址建立一条新的SCTP连接。
3. 在响应消息NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE中，gNB-Old会报告这条新连接的建立结果（成功或失败）。

同样，当需要移除某个IP地址或更新其用途时，也会使用TNLA To Remove List和TNLA To Update List。这个机制保证了Xn接口的底层传输路径能够被灵活、动态地管理。

3.2.3 动态覆盖调整 - 网络的“智能呼吸”

这是5G网络智能化，特别是节能特性的重要体现。

If the Coverage Modification List IE is present in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node2 may use the information in the Cell Coverage State IE to identify the cell deployment configuration enabled by the NG-RAN node1…

场景代入：时间来到午夜，gNB-New所覆盖的商业区人流量骤减。为了节省能耗，gNB-New的SON（自组织网络）功能决定关闭该小区的部分扇区或波束。

1. gNB-New向gNB-Old发送UPDATE消息，其中包含Coverage Modification List IE。
2. 这个列表中，Cell Coverage State IE的值不再是active，而是可能指示“部分激活”或“睡眠”等状态。SSB Coverage Modification List则可以精细到关闭哪些SSB波束。
3. gNB-Old收到这个通知后，就知道了gNB-New的这个小区目前处于“半睡”状态。它在做切换决策时，就会避免将用户切换到这个小区，或者只将低需求的UE切换过去。当早晨人流恢复，gNB-New重新激活所有覆盖后，它会再次发送UPDATE消息，通知gNB-Old“我已完全醒来”。

这个流程使得基站间的负载均衡和移动性管理能够与动态的节能策略紧密联动，实现了网络性能与能耗的智能平衡。

3.2.4 其他重要信息同步

UPDATE流程还承载了其他多种信息的同步，例如：

• AMF Region Information To Add/Delete: 当基站接入新的核心网AMF区域或与之解耦时，需要通知邻居。
• Cell and Capacity Assistance Information: 基站可以向邻居请求或提供小区容量辅助信息，帮助邻居更精准地评估切换目标。
• Partial List Indicator: 与Xn Setup一样，当更新的小区列表过长时，可以使用这个标志进行分批更新。

4. 8.4.2.3 & 8.4.2.4 (失败与异常) - 当“更新”无法同步

4.4.2.3 Unsuccessful Operation (失败操作)

If the NG-RAN node2 cannot accept the update it shall respond with the NG-RAN NODE CONFIGURATION UPDATE FAILURE message and appropriate cause value.

如果接收方gNB-Old无法接受这次更新（例如，请求添加的小区参数与自身配置冲突，或者内部资源不足无法处理），它会回复NG-RAN NODE CONFIGURATION UPDATE FAILURE。

• Time To Wait IE: 与Xn Setup类似，失败消息中可以携带这个IE，建议发起方稍后再试。

4.4.2.4 Abnormal Conditions (异常条件)

If the NG-RAN node1 after initiating NG-RAN node Configuration Update procedure receives neither NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message nor … FAILURE message, the NG-RAN node1 may reinitiate the … procedure…

如果发起方gNB-New在定时器超时后没有收到任何回复，它可以选择重发UPDATE消息。这保证了在瞬时的网络抖动导致信令丢失时，重要的配置更新最终能够被同步。

5. 总结：动态网络协同的生命线

NG-RAN node Configuration Update流程是XnAP全局流程中的核心维护机制。它将Xn Setup建立的静态关系，转变为一个能够实时反映网络物理和逻辑变化的动态关系。

• 它是网络拓扑的“心跳”：确保了每个基站对其邻居的认知始终是最新、最准确的，这是所有移动性管理和RRM算法正确决策的基础。
• 它是多维度管理的“总线”：一个流程同时承载了小区生命周期、传输网络、核心网关联、动态覆盖等多个维度的信息更新，设计高度集成和高效。
• 它是SON功能的“使能者”：自动的小区增删、动态的节能覆盖调整等高级SON功能，都依赖于这个流程来将其决策结果通告给邻居节点，实现全网的协同优化。

对于小林这样的工程师来说，深刻理解Configuration Update流程，意味着能够从根本上理解分布式RAN系统的动态协同本质。在处理由于邻区关系错误、传输链路变更或节能特性导致的切换失败等问题时，分析UPDATE及其响应消息，将是定位问题的最直接手段。

FAQ

Q1：NG-RAN node Configuration Update和Cell Activation (8.4.3节) 有什么区别？ A1：两者都与小区的激活状态有关，但目的和发起场景不同。Configuration Update用于一个基站向邻居通告自己管理的小区状态发生了变化（如从激活到去激活），这是一个信息同步过程。而Cell Activation是用于一个基站请求另一个基站将它某个已经去激活（例如为了节能）的小区重新激活起来。前者是“我告诉你我的状态变了”，后者是“我请求你改变你的状态”。

Q2：如果一个UPDATE消息丢失，而后续又有一个新的UPDATE消息，网络状态会混乱吗？ A2：通常不会。因为UPDATE流程（特别是小区修改）采用的是全量替换的原则。假设第一个关于小区A的TAC修改的UPDATE消息丢失了。之后，该小区又发生了一次PCI修改，触发了第二个UPDATE。这个新消息会携带小区A的完整最新配置（包含新的TAC和新的PCI）。接收方收到后，会用这个最新配置完全覆盖本地的旧记录，从而使双方状态最终达成一致。

Q3：UPDATE流程是否会影响正在进行的UE业务？ A3：UPDATE流程本身是后台的非UE关联信令，不会直接影响UE业务。但它所同步的信息，会影响未来的决策，从而间接影响业务。例如，如果一个基站没有及时收到邻居小区被删除的UPDATE，它可能会将一个正在通话的UE切换到这个已不存在的小区，导致通话中断。因此，这个流程的及时性和可靠性对保障用户体验至关重要。

Q4：为什么在UPDATE消息中还需要同步AMF区域信息？这难道不是核心网的事情吗？ A4：这是为了优化移动性。一个AMF区域内的移动（Intra-AMF Mobility）和跨AMF区域的移动（Inter-AMF Mobility）在核心网层面处理的复杂性不同。基站在做切换决策时，如果知道某个目标小区与自己属于同一个AMF区域，它会更倾向于选择这个目标，因为后续的路径更新流程会更简单、更快速。UPDATE流程确保了基站拥有其邻居最新的AMF归属信息，从而做出更优的切换决策。

Q5：Partial List Indicator在UPDATE流程中的实际应用是怎样的？ A5：假设一个大型基站需要一次性更新100个小区的参数。如果一次性将这100个小区的完整信息打包成一个UPDATE消息，可能会超过底层传输协议的MTU（最大传输单元）限制，导致消息分片或发送失败。此时，发起方可以先发送一个包含前50个小区信息的UPDATE消息，并设置Partial List Indicator。接收方收到后，知道这只是部分列表，会回复ACKNOWLEDGE。然后发起方再发送第二个UPDATE消息，包含后50个小区的信息。通过这种方式，完成了大规模配置的可靠、分批同步。