深度解析 3GPP TS 38.423：8.4.3-8.4.6 Xn接口的生命周期管理与异常处理

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.4.3 Cell Activation”、“8.4.4 Reset”、“8.4.5 Error Indication”以及“8.4.6 Xn Removal”这四个核心全局流程。本文旨在将这些管理Xn接口从激活、故障恢复到最终拆除的完整生命周期流程进行整合解读，为读者揭示5G基站间“外交关系”的建立、维护、修复与终结。

1. 引言：从“建交”到“邦交正常化”再到“断交”

在上一篇文章中，我们见证了两个陌生的5G基站gNB-New和gNB-Old通过Xn Setup流程，完成了历史性的首次“握手建交”。它们交换了彼此的详细配置，为未来的一切协同工作奠定了基础。我们的工程师小林在他的导师陈工的指导下，也学会了如何通过Configuration Update流程来同步这些信息的动态变化。

“陈工，”小林在一次深夜的网络维护演练后，疲惫地揉了揉眼睛，“我发现网络运维远不止是添加和修改配置。今天凌晨，为了节能，我们远程‘关闭’了一个园区的部分小区；上周，一个基站因为雷击导致软件状态错乱，我们需要紧急恢复它和邻居的关系；还有一次，我们发现一个友商的基站总是发一些格式不规范的消息过来。最后，下个月我们还要退服一个老旧的站点。这些复杂的‘外交事件’，XnAP协议是如何处理的？”

陈工赞许地看着求知欲旺盛的小林：“你提出的这些，恰恰是Xn Setup和Configuration Update之外，保证网络7x24小时健壮运行的另外三大支柱。一个成熟的‘外交体系’，不仅要有建交和互通消息的机制，更要有应对各种突发状况的预案。”

他接着说道：“Xn Setup只是建立了邦交，而我们今天要学习的，是如何实现‘邦交正常化’的日常管理，以及在极端情况下的‘关系重置’和‘和平分手’。这套组合拳包括：”

• 8.4.3 Cell Activation (小区激活)：节能后，如何礼貌地请求邻居“开灯营业”。
• 8.4.4 Reset (重置)：遭遇重大灾难（如软件崩溃）后，如何启动“一键恢复”，重建信任。
• 8.4.5 Error Indication (错误指示)：收到“格式错误的信件”时，如何优雅地指出对方的错误。
• 8.4.6 Xn Removal (Xn移除)：当合作关系寿终正寝时，如何进行一场正式的“断交”仪式。

这些全局流程，共同构成了Xn接口从诞生、运行、故障到消亡的完整生命周期管理闭环，是5G网络高可用性和高可维护性的重要保障。

2. 8.4.3 Cell Activation (小区激活) - 节能后的“晨间唤醒”

场景设定： 为了响应国家的“双碳”号召，运营商部署了智能节能方案。在深夜，人流量稀少的工业园区，基站gNB-Old自动将其中的一个小区Cell-Old-1切换到了“睡眠”模式（deactivated）。这个状态已经通过Configuration Update流程通知了邻居gNB-New。

清晨，随着第一批员工上班，gNB-New监测到其边缘用户信号质量下降，并且预测到他们即将移动到Cell-Old-1的覆盖范围。此时，gNB-New需要主动“唤醒”这个沉睡的小区。

2.1 8.4.3.1 General (概述)

The purpose of the Cell Activation procedure is to enable an NG-RAN node to request a neighbouring NG-RAN node to switch on all the SSB beams or only some of the SSB beams within one or more cells, previously reported as inactive due to energy saving.

陈工的解读：“这个流程的核心是请求 (request)，而不是通知。gNB-New作为发起方，向gNB-Old提出一个请求：‘老兄，你那个因为节能而关闭的Cell-Old-1，现在该起来干活了！’。更精细的是，这个请求可以具体到只激活小区中的部分SSB波束，实现了更细粒度的、按需的覆盖激活。”

2.2 8.4.3.2 & 8.4.3.3 (成功与失败操作) - 一场有来有回的“唤醒”对话

这是一个Class 1流程，gNB-New发出请求后，必须等待gNB-Old的明确答复。

第一步：gNB-New发起CELL ACTIVATION REQUEST 消息中包含Cells to be Activated IE，明确指出需要唤醒的小区列表（通过CGI）。对于NR小区，还可以包含SSBs to be Activated List，进行波束级的精确唤醒。

第二步：gNB-Old的响应

• 成功 (CELL ACTIVATION RESPONSE): gNB-Old收到请求后，执行激活操作，并在响应消息中告知gNB-New，哪些小区（或波束）已经成功激活。

  The NG-RAN node2 … shall indicate in the CELL ACTIVATION RESPONSE message for which cells the request was fulfilled.

• 失败 (CELL ACTIVATION FAILURE): 如果gNB-Old因为某些原因（如正在进行维护、硬件故障）无法激活请求的小区，它会回复失败消息，并附上原因。

与Configuration Update的交互：

The NG-RAN node2 shall not send the NG-RAN CONFIGURATION UPDATE message to the NG-RAN node1 just for the reason of the cell(s) … changing cell … activation state, as the receipt of the CELL ACTIVATION RESPONSE message … is used to update the information…

陈工强调：“这是一个非常重要的实现细节。gNB-Old在成功激活小区后，不需要再额外发送一个Configuration Update去通告这个状态变化。因为CELL ACTIVATION RESPONSE消息本身就已经起到了确认和状态同步的作用。gNB-New收到这个响应，就直接更新本地数据库，认为该小区已激活。这避免了不必要的信令冗余。”

3. 8.4.4 Reset (重置) - 灾难恢复的“一键重启”

场景设定： gNB-Old遭遇了一次严重的雷击，虽然硬件重启了，但其内存中关于与gNB-New之间所有进行中的UE连接（例如，几十个处于切换准备状态的UE上下文）全部丢失或错乱。此时，双方的“账本”已经完全对不上了。

3.1 8.4.4.1 General (概述)

The purpose of the Reset procedure is to align the resources in the NG-RAN node1 and the NG-RAN node2 in the event of an abnormal failure. The procedure either resets the Xn interface or selected UE contexts.

陈工的解读：“Reset是XnAP中最‘严厉’的流程之一，是应对灾难性故障、确保状态最终一致的‘最后手段’。它有两种模式：‘全面格式化’和‘定点清除’。”

3.2 8.4.4.2 Successful Operation (成功操作) - 两种模式的“重启”

RESET REQUEST消息由故障恢复的一方（比如gNB-Old）发起。

模式一：Full Reset (完全重置)

if the RESET REQUEST message indicates full reset the NG-RAN node2 shall abort any other ongoing procedures over Xn … delete all the context information related to the NG-RAN node1 … and release the corresponding resources.

• 触发场景：基站级的严重故障，导致所有或大量上下文丢失。
• 动作：gNB-Old向gNB-New发送RESET REQUEST，类型为full reset。gNB-New收到后，必须立即中止与gNB-Old之间的所有XnAP流程，并删除所有与gNB-Old相关的UE上下文（例如，从gNB-Old切换过来的UE），释放所有相关资源。然后回复RESET RESPONSE。
• 效果：Xn接口的应用层被恢复到了“出厂设置”（除了Xn Setup时交换的全局配置），双方可以重新开始。

模式二：Partial Reset (部分重置)

if the RESET REQUEST message indicates partial reset, the NG-RAN node2 shall abort any other ongoing procedures only for the indicated UE associated signalling connections … and release the corresponding resources.

• 触发场景：影响了一部分特定UE的局部故障，或者需要批量清理一组“僵尸”连接。
• 动作：gNB-Old向gNB-New发送RESET REQUEST，类型为partial reset，并附上一个UE contexts to be released List，其中包含了需要清理的UE的XnAP ID列表。gNB-New只清理这个列表上指定的UE上下文。
• 效果：实现了“外科手术式”的定点清除，未受影响的UE业务可以继续，最大程度地减小了故障对业务的冲击。

4. 8.4.5 Error Indication (错误指示) - 协议交互的“语法纠错”

场景设定： gNB-New升级到了一个新的软件版本，但其中存在一个bug，导致它在构造某个XnAP消息时，加入了一个gNB-Old（老版本）不认识的可选IE。

4.1 8.4.5.1 General (概述)

The Error Indication procedure is initiated by an NG-RAN node to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message.

陈工的解读：“Error Indication是一个通用的、轻量级的‘纠错’机制。它的核心应用场景是：当一个节点收到一个消息，发现其中有无法理解或不符合语法规则的部分，但这个错误又不至于导致整个流程失败时，就可以通过这个流程来‘提醒’对方。它特别适用于对Class 2流程（没有失败消息）的错误反馈。”

4.2 8.4.5.2 Successful Operation (成功操作) - 一份详细的“Bug报告”

这是一个Class 2流程。gNB-Old在检测到错误后，向gNB-New发送ERROR INDICATION消息。

ERROR INDICATION消息的核心IE：

• Cause IE: 指出错误的大致类型，例如abstract-syntax-error（抽象语法错误）。
• Criticality Diagnostics IE: 这是“Bug报告”的精华所在。它会详细指出：
  • 是哪个流程（Procedure Code）的消息出了问题。
  • 是哪个IE（IE ID）无法理解。
  • 错误的类型是not-understood（不认识）还是missing（缺失）。

场景代入：gNB-Old收到了gNB-New发来的包含未知IE的RESOURCE STATUS UPDATE消息（Class 2）。它无法回复FAILURE，于是向gNB-New发送一个ERROR INDICATION，其中Criticality Diagnostics指明了那个不认识的IE的ID和not-understood的错误类型。gNB-New的开发人员看到这个日志，就能快速定位到版本兼容性的bug。

5. 8.4.6 Xn Removal (Xn移除) - 有序的“和平分手”

场景设定： 运营商决定将老旧的gNB-Old站点退服，替换为更先进的设备。在退服之前，需要断开它与所有邻居（包括gNB-New）的Xn连接。

5.1 8.4.6.1 General (概述)

The purpose of the Xn Removal procedure is to remove the interface instance between two NG-RAN nodes in a controlled manner.

陈工的解读：“Xn Removal是Xn Setup的逆过程。它不是粗暴地拔掉网线，而是一个受控的（controlled）、优雅的‘分手’流程。通过这个流程，双方可以同步地清空彼此的应用层配置，确保在连接物理断开前，逻辑上已经完全解耦。”

5.2 8.4.6.2 Successful Operation (成功操作) - “断交”的最后通牒

这是一个Class 1流程，需要双方确认。

1. gNB-Old发起XN REMOVAL REQUEST: 在准备退服前，gNB-Old向gNB-New发送移除请求。
2. Xn Removal Threshold IE (可选):

   If the Xn Removal Threshold IE is included… the candidate NG-RAN node2 shall, if supported, accept to remove the interface instance… if the Xn Benefit Value of the interface instance… is lower than the value of the Xn Removal Threshold IE. “这是一个非常智能的SON特性。gNB-Old可以提出一个‘带条件的断交’：‘如果你认为我们之间的关系价值（Xn Benefit Value，可能基于交互流量、切换成功率等计算）已经低于某个门限（Threshold），那么就同意分手吧’。这使得网络可以自动修剪掉那些低效、不必要的Xn连接。”

3. gNB-New回复XN REMOVAL RESPONSE: gNB-New收到请求并同意后，回复响应。
4. 拆除连接: gNB-Old收到响应后，就可以安全地拆除底层的SCTP连接，并删除所有与gNB-New相关的配置。gNB-New在回复后也执行同样的操作。

至此，两个基站的“外交关系”正式、和平地结束。

6. 总结：构建一个自愈、自优的RAN网络

小林在学完这些流程后，对网络的健壮性有了全新的认识。他明白了，一个电信级的网络系统，其伟大之处不仅在于它在正常情况下能跑多快，更在于它在遭遇各种异常和生命周期事件时，都有一套标准、可靠的预案来应对。

• Cell Activation 实现了性能与能耗的动态平衡。
• Reset 提供了灾难恢复的终极保障。
• Error Indication 构筑了协议健壮性的微观防线。
• Xn Removal 完成了网络拓扑生命周期的闭环管理。

这些全局流程，共同确保了5G NG-RAN不是一个僵化的、脆弱的集合体，而是一个能够动态适应、自我修复、平滑演进的智能化、弹性化网络。它们是保障万千用户（如“李雷”和“小张”）无感知体验的、隐藏在冰山之下的巨大基石。

FAQ

Q1：Cell Activation和SON（自组织网络）有什么关系？ A1：Cell Activation是SON中**节能（Energy Saving, ES）功能的一个关键执行环节。SON的ES算法会根据话务模型、时间等因素，做出关闭某个小区的决策。这个决策的结果会通过Configuration Update通知邻居。而当SON的负载均衡（Load Balancing, LB）**算法或者另一个基站的RRM算法认为需要重新激活该小区时，就会触发Cell Activation流程。因此，这个流程是跨节点SON功能协同的重要信令基础。

Q2：Reset流程会中断正在通话的用户吗？ A2：会。Reset是一个非常“重”的操作。如果是Full Reset，接收方会删除所有与发起方相关的UE上下文，这意味着所有正在进行切换、双连接或者锚定在发起方的RRC_INACTIVE用户都会被强制中断连接。如果是Partial Reset，则只会中断列表中指定的UE。正因为其影响巨大，Reset只应在发生严重异常、无法通过其他手段恢复状态一致性时才被使用。

Q3：Error Indication和标准的FAILURE消息（如HANDOVER PREPARATION FAILURE）有什么核心区别？ A3：核心区别在于适用场景和对流程的影响。FAILURE消息是Class 1流程的一部分，用于明确地、正式地终止一个正在进行的流程，并告知失败。而Error Indication是一个独立的Class 2流程，它不终止任何流程，只是一个“事后”的错误通告。它主要用于两种情况：1）对Class 2消息中的错误进行反馈（因为Class 2没有FAILURE消息）；2）对Class 1消息中非致命的、可忽略的错误进行提醒，而无需中断整个流程。

Q4：为什么Xn Removal需要一个RESPONSE，而UE Context Release却不需要？ A4：这取决于操作的可逆性和对等性。Xn Removal是一个对等节点间的“断交”协议，一旦完成，所有应用层配置都将被删除，这是一个影响深远且通常不可逆的操作。因此，必须通过请求-响应机制，确保双方都已准备就绪并同步执行。而UE Context Release是一个“清理”通知，通常由新节点向旧节点发起。即使旧节点没有收到，其自身的超时机制最终也会清理资源。这个操作的失败只会导致资源暂时的占用，而不会破坏整个网络拓扑的认知，因此可以采用更轻量的Class 2流程。

Q5：一个基站如何计算Xn Benefit Value来决定是否同意Xn Removal？ A5：3GPP规范本身没有定义Xn Benefit Value的具体计算方法，这留给了设备商的实现（implementation specific）。通常，一个基站会综合多个KPI来评估一个Xn链路的“价值”，例如：

• 信令流量：该Xn链路上每秒的XnAP消息数量。
• 移动性性能：通过该Xn链路执行的切换/双连接的次数和成功率。
• 数据转发量：在切换过程中，通过该Xn-U接口转发的数据总量。
• 业务类型：该链路上承载的高优先级（如VoNR）业务的比例。 如果一个Xn链路长期处于低活动状态，上述指标都非常低，那么其“Benefit Value”就会很低，当收到带有阈值的Xn Removal Request时，就可能会被自动修剪掉。