深度解析 3GPP TS 38.423：9.1.3 全局消息 (Part 2 - 网络自优化的“传感器”与“调节器”)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.1.3 Messages for Global Procedures”的核心章节。本文是该系列的第二部分，我们将聚焦于支撑自组织网络（SON）的两大核心功能——移动性优化和负载均衡——所依赖的关键消息：
FAILURE INDICATION(9.1.3.16),HANDOVER REPORT(9.1.3.17),RESOURCE STATUS(9.1.3.18-21) 和MOBILITY CHANGE(9.1.3.22-24) 系列消息。
1. 引言：赋予网络“思考”与“行动”的能力
在上一篇中，我们探讨了Xn接口如何通过Setup, Update, Removal等流程，建立并维护其生命周期。这为基站间的协同搭建了稳固的“舞台”。然而，一个智能化的网络，不仅需要“舞台”，更需要能在舞台上自主“表演”和“调整”的“演员”。
我们的工程师小林在观摩了网络的自动化运维平台后，对导师陈工提出了新的疑问：“陈工，我看到平台上有许多关于‘移动性鲁棒性优化（MRO）’和‘移动性负载均衡（MLB）’的曲线在自动调整。我知道这是SON（自组织网络）的功能，但这些自动化的背后，基站之间究竟在‘聊’些什么，才让它们能够如此‘心有灵犀’地协同优化呢？“
陈工赞许道：“你已经触及了5G网络‘自治’能力的信令核心。SON不是一个黑盒子，它的每一个决策，都源于对网络状态的精确感知和节点间的有效协商。今天，我们就来解构SON在Xn接口上的‘语言’。这些全局消息，就是网络进行自我诊断、自我调节的‘传感器’和‘调节器’。”
我们将聚焦于四组关键的全局消息，它们共同构成了网络自优化的闭环：
FAILURE INDICATION/HANDOVER REPORT: 网络的**“故障感知器”**，负责捕获和上报移动性失败事件，是MRO的“输入”。MOBILITY CHANGE系列消息: 网络的**“移动性调节器”**，用于在邻居基站间协商和修改切换参数，是MRO的“输出”。RESOURCE STATUS系列消息: 网络的**“负载传感器”**，用于实时监控邻居小区的资源使用情况，是MLB的“输入”。- (MLB的“输出”通常是调整切换参数，因此也归结到
MOBILITY CHANGE流程)
2. 9.1.3.16 & 9.1.3.17 - 移动性“黑匣子”：感知失败
这两个消息我们在流程篇（8.4.7/8.4.8）已经介绍过，这里我们从消息结构的角度再次审视，深入其“语言”细节。
2.1 FAILURE INDICATION (9.1.3.16) - 原始的“事故现场”快报
当UE在一个新基站gNB-B处重建立连接后，gNB-B会向其掉话前的旧基站gNB-A发送此消息。
FAILURE INDICATION 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| CHOICE Initiating condition | M | 失败的类型 | |
| >RRC Reestab | M | RRC重建立场景 | |
| >>CHOICE RRC Reestab Initiated Reporting | M | ||
| >>>UE RLF Report Container | M | UE RLF Report 9.2.2.59 | 核心！ UE上报的“黑匣子”数据 |
陈工的解读：“FAILURE INDICATION消息的核心就是这个UE RLF Report Container。它是一个透明容器，原封不动地装着UE上报的RLF报告。这份报告包含了掉话前瞬间的无线环境快照：服务小区的信号质量、所有邻区的信号质量等。gNB-A收到这份‘原始物证’后，就可以启动内部的MRO算法进行根本原因分析（RCA）。”
2.2 HANDOVER REPORT (9.1.3.17) - 深度分析后的“定性报告”
当一个基站（如gNB-A）通过分析FAILURE INDICATION或其他信息，判定一次切换存在问题时，它会向当初做出切换决策的基站（如gNB-C）发送此报告。
HANDOVER REPORT 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Handover Report Type | M | ENUMERATED (HO too early, HO to wrong cell, …) | 核心！ 对失败的定性结论 |
| Handover Cause | M | Cause 9.2.3.2 | 当初切换的原因 |
| Source cell CGI / Target cell CGI | M | 当初切换的源/目标小区 | |
| Re-establishment cell CGI | C | UE最终重建立到的小区 | |
| UE RLF Report Container | O | 附上原始的“黑匣子”证据 |
陈工的解读：“HANDOVER REPORT比FAILURE INDICATION更进了一步。它不再只是传递原始数据，而是给出了一个明确的定性结论 (Handover Report Type)，比如‘切换太早’或‘切换到错误小区’。这相当于一份‘事故调查报告’，直接告诉决策节点‘你的上次决策有问题’。接收方（gNB-C）的MRO算法可以直接根据这个结论，来调整其对gNB-A的切换参数。”
3. 9.1.3.22-24 MOBILITY CHANGE - 移动性的“参数调节器”
当基站通过MRO算法分析HANDOVER REPORT后，认为需要调整切换参数时，MOBILITY CHANGE系列消息就登场了。
3.1 MOBILITY CHANGE REQUEST (9.1.3.22) - “我们来谈谈边界线”
MOBILITY CHANGE REQUEST 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| NG-RAN node1/2 Cell ID | M | 协商双方的小区ID | |
| CHOICE Mobility Change | M | ||
| >SSB Offset Information | O | SSB Offset Information 9.2.2.77 | 核心！ 建议修改的切换偏移量 |
陈工的解读：“这是MRO优化的‘执行’环节。gNB-C在收到‘切换太早’的报告后，决定让UE更晚地切换到gNB-A。于是它向gNB-A发起REQUEST，通过SSB Offset Information IE，建议降低gNB-A在其邻区配置中的偏移量。这相当于告诉A：‘请你把自己变得不那么有吸引力一点，这样用户就不会过早地被你吸引过去。’”
3.2 ... ACKNOWLEDGE (9.1.3.23) / ... FAILURE (9.1.3.24) - “同意”或“还价”
MOBILITY CHANGE ACKNOWLEDGE: 如果gNB-A同意了这个参数修改，就回复此消息。双方的切换边界随即更新。MOBILITY CHANGE FAILURE: 如果gNB-A不同意，则回复此消息。Mobility Parameters Modification RangeIE: 这是一个精巧的**“还价”机制**。gNB-A可以在拒绝的同时，告诉gNB-C：“你建议的-3dB太多了，但我可以接受-1dB到0dB的调整”。这使得协商可以继续，而不是一次性谈崩。
4. 9.1.3.18-21 RESOURCE STATUS - 网络的“负载传感器”
这组消息是实现移动性负载均衡（MLB）的核心工具。
4.1 RESOURCE STATUS REQUEST (9.1.3.18) - “请开始你的汇报”
RESOURCE STATUS REQUEST 消息内容
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| Registration Request | M | ENUMERATED (start, stop, add) | |
| Report Characteristics | C | BIT STRING (SIZE(32)) | 核心！ 指定要汇报哪些负载指标 |
| Reporting Periodicity | O | ENUMERATED (500ms, 1000ms, …) |
陈工的解读：“这是基站A向邻居B发起的‘负载监控任务书’。Report Characteristics这个位图是关键，A可以像点菜一样，精确地要求B汇报：”
PRB Periodic: 无线PRB利用率。TNL Capacity Ind Periodic: 传输网络负载。Number of Active UEs Periodic: 活跃用户数。RRC Connections Periodic: RRC连接数。
4.2 ... RESPONSE (9.1.3.19) / ... FAILURE (9.1.3.20)
B如果同意开启监控，则回复RESPONSE；如果无法满足（如不支持某个指标的测量），则回复FAILURE。
4.3 RESOURCE STATUS UPDATE (9.1.3.21) - “这是我最新的负载报告”
一旦监控任务开启，B就会按照约定的Reporting Periodicity，周期性地向A发送RESOURCE STATUS UPDATE消息。
RESOURCE STATUS UPDATE 消息内容
| IE/Group Name | Presence | IE type and reference |
|---|---|---|
| … | ||
| Cell Measurement Result | M | |
| >>Radio Resource Status | O | 9.2.2.50 (包含各类PRB使用率) |
| >>TNL Capacity Indicator | O | 9.2.2.49 |
| >>Number of Active UEs | O | 9.2.2.62 |
| >>RRC Connections | O | 9.2.2.56 |
MLB决策的闭环:
- A持续收到来自B和C的
UPDATE。 - 当A自身负载过高时，它查询最新的报告，发现B负载很低。
- A通过
MOBILITY CHANGE REQUEST，临时提高B在A邻区配置中的偏移量，让B变得“更有吸引力”。 - 边缘用户因此被更早地切换到B，A的负载得到分担。
- 当网络负载恢复正常后，A再通过
MOBILITY CHANGE流程将参数恢复原状。
5. 总结：构建自愈、自优的智能网络
小林在学完这些流程后，对SON的理解从一个抽象的概念，变成了具体的信令交互。Failure Indication、Handover Report、Mobility Change和Resource Status系列消息，共同构成了XnAP协议中实现移动性优化和负载均衡的“四驾马车”。
- 感知层 (
Failure Indication,Resource Status Update)：负责从网络中收集最原始的故障和负载数据，是网络的“眼睛”和“耳朵”。 - 分析层 (SON算法，厂商实现)：对感知层的数据进行分析，诊断问题，并制定优化策略。
- 决策/协商层 (
Handover Report,Mobility Change Request,Resource Status Request)：将分析结果转化为具体的信令请求，在节点间进行通告和协商。 - 执行层 (
Mobility Change Acknowledge): 最终执行协商一致的参数调整。
这套完整的闭环机制，使得5G网络能够应对复杂多变的无线环境和话务模型，在无需人工干预的情况下，持续保持在最优的工作状态，真正实现了从“连接”到“智能连接”的飞跃。
FAQ
Q1：Failure Indication和Handover Report都是全局流程，网络如何知道它们是关于哪个UE的？
A1：尽管它们是非UE关联的，但消息内容中包含了可以追溯到UE的信息。例如，Failure Indication中的UE RLF Report包含了UE掉话前的C-RNTI和小区ID。Handover Report中也包含了当初切换的源/目标小区ID和C-RNTI。接收方可以通过这些信息，在自己的历史记录中查找，从而关联到具体的UE移动性事件。
Q2：MRO和MLB都是通过调整切换参数来实现的，它们之间会不会产生冲突？ A2：会，这是SON设计中的一个经典难题。MRO的目标是提升连接稳定性，它可能会倾向于让UE“晚一点”切换。而MLB的目标是均衡负载，它可能会希望UE“早一点”切换到一个空闲的小区。两者的目标可能完全相反。解决这个冲突，依赖于设备商复杂的SON仲裁算法，例如，设定一个规则：当网络处于低负载时，MRO的优先级更高；当网络出现拥塞时，MLB的优先级更高。
Q3：RESOURCE STATUS UPDATE是周期性上报的，会不会产生很大的信令开销？
A3：会产生一定的开销，但这是可控的。首先，UPDATE消息本身非常紧凑。其次，上报的**周期 (Reporting Periodicity)**是可配置的，运营商可以在协调的实时性和信令开销之间做出权衡。对于负载变化平缓的网络，可以设置较长的上报周期（如数秒）；对于负载变化剧烈的热点区域，则可以设置较短的周期（如几百毫秒）。
Q4：为什么Mobility Settings Change是一个独立的流程，而不是直接通过NG-RAN node Configuration Update来修改切换参数？
A4：这是一个关于所有权和协商的精妙设计。Configuration Update用于一个节点更新自己的配置信息并通知邻居。而Mobility Settings Change用于一个节点请求另一个节点去修改那个节点自己的配置。切换参数（如小区偏移CIO）是存储在源基站的邻区关系表中的，它决定了源基站何时发起切换。因此，当目标基站认为切换时机不当时，它不能直接去修改源基站的配置，只能通过Mobility Change流程向源基站发起协商，请求对方进行修改。
Q5：这些SON流程是否需要所有厂商的设备都支持才能工作？
A5：是的，为了达到最佳效果，需要邻居基站都支持这些流程。这些流程都被定义在XnAP协议中，是标准化的。如果一个厂商的设备不支持Mobility Change，那么它就无法与邻居进行自动化的切换参数协商，MRO的闭环就会中断。在异厂商组网（Multi-vendor）的环境中，这些SON流程的互操作性是网络能否实现自动化运维的关键之一。