深度解析 3GPP TS 38.423：8.4.9-8.4.11 网络的自感知与自优化

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.4.9 Mobility Settings Change”、“8.4.10 Resource Status Reporting Initiation”以及“8.4.11 Resource Status Reporting”这三个核心全局流程。本文旨在将这些赋予5G网络“自我感知”与“自我调节”能力的关键流程进行整合解读，揭示了网络是如何从被动响应故障，走向主动预防和优化，实现自组织网络（SON）的宏伟蓝图。

1. 引言：从“亡羊补牢”到“未雨绸缪”

在上一篇文章中，我们探讨了网络如何在移动性失败后，通过Failure Indication和Handover Report等“黑匣子”机制进行“亡羊补牢”。我们的工程师小林在他的导师陈工的指导下，成功利用这些工具定位了电竞玩家小张的游戏卡顿问题。

“陈工，我们成功了！”小林兴奋地展示着优化结果，“通过分析RLF-Report，我们调整了那两栋楼之间基站A的切换门限，小张再也没有报告过卡顿。”

“做得很好，”陈工肯定道，“但你有没有想过，这依然是一种‘消防员’式的工作模式。我们是在‘火灾’（用户投诉）发生后才去‘救火’。一个真正智能化的网络，应该是一名‘建筑防火工程师’，它的目标是在火灾发生前，就消除所有隐患。我们今天要学习的，就是XnAP协议中的‘防火’工具箱。”

陈工继续解释道：“网络中的‘火灾隐患’，就是那些不合理的参数配置和动态变化的负载。比如，两个邻区之间的切换门限设置不当，必然会导致大量的乒乓切换和掉话。一个基站的负载即将饱和，如果不及时疏导，就会造成新用户接入困难和老用户速率下降。Handover Report等流程是在事后分析‘事故原因’，而我们今天要学习的这几个全局流程，则是主动地、前瞻性地进行‘隐患排查’和‘交通疏导’。”

这套“防火”工具箱由以下几个核心流程组成：

• 8.4.9 Mobility Settings Change (移动性设置变更)：邻居基站间的“交规”协商，主动优化切换边界。
• 8.4.10 Resource Status Reporting Initiation (资源状态上报启动)：开启对邻居的“交通流量监控”。
• 8.4.11 Resource Status Reporting (资源状态上报)：周期性的“交通流量公报”，为智能决策提供数据。

这些流程共同赋予了5G网络“自感知”（Sensing）和“自优化”（Optimizing）的能力，是实现SON（Self-Organizing Networks）理念的核心基石。

2. 8.4.9 Mobility Settings Change - 邻里间的“交规”协商

场景设定： 基站A和基站B是邻居，它们之间的切换频繁。基站A的SON算法通过长期分析发现，从A切换到B的用户，有很大比例在很短时间内又切了回来（乒乓切换），或者切换成功率偏低。A判断，这可能是因为它设置的切换到B的门限太低，导致用户“过早”地被切换了过去。

2.1 8.4.9.1 General (概述)

This procedure enables an NG-RAN node to negotiate the handover trigger settings with a peer NG-RAN node controlling neighbouring cells.

陈工的解读：“这个流程的关键词是协商 (negotiate)。它不是单方面的通知，而是一场平等的对话。基站A（node1）向基站B（node2）发起请求：‘老兄，根据我的观察，我们俩之间的切换门限似乎有点问题，我建议调整一下，你看如何？’ 这是网络实现**移动性鲁棒性优化（MRO）和移动性负载均衡（MLB）**的主动手段。”

2.2 8.4.9.2 Successful Operation (成功操作) - 一场关于“门槛”的谈判

这是一个Class 1流程，请求必须得到明确的回复。

第一步：基站A发起MOBILITY CHANGE REQUEST 基站A向B发送请求，其中核心IE是SSB Offset Information。

• SSB Offset Information IE: 这个IE包含了对特定SSB区域（可以理解为特定波束覆盖区）的切换偏移量（Handover Trigger Offset）的建议修改值。
  • 陈工的解读：“‘切换偏移量’可以通俗地理解为‘好感度加成’。默认情况下，当B的信号比A好一个门限值时，UE就会被切换。如果A在请求中建议将B的偏移量调低，就相当于给B加了一个‘debuff’，让它在UE眼中‘不那么有吸引力’，UE需要B的信号好得更多，才会被切换过去，从而避免了‘过早切换’。反之，调高偏移量，则会让B‘更具吸引力’。”

第二步：基站B的评估与回复 - MOBILITY CHANGE ACKNOWLEDGE

Upon receipt, NG-RAN node2 shall evaluate if the proposed NG-RAN node2 handover trigger modification may be accepted. If NG-RAN node2 is able to successfully complete the request it shall reply with MOBILITY CHANGE ACKNOWLEDGE message.

基站B收到请求后，会评估这个建议。如果B认为这个调整对双方都有利，且符合自己的RRM策略，它就会接受修改，并回复MOBILITY CHANGE ACKNOWLEDGE。此后，两个基站间的切换边界就得到了优化。

2.3 8.4.9.3 Unsuccessful Operation (失败操作) - “谈判”破裂与“还价”

If the requested parameter modification is refused by NG-RAN node2, … NG-RAN node2 shall send the MOBILITY CHANGE FAILURE message with the Cause IE set to an appropriate value. NG-RAN node2 may include the Mobility Parameters Modification Range IE in the MOBILITY CHANGE FAILURE message…

如果B不同意A的提议（例如，B认为降低吸引力会导致自己无法分担负载），它会回复MOBILITY CHANGE FAILURE。

• Mobility Parameters Modification Range IE: 这是这个流程最智能的地方——“还价”机制。B可以在拒绝的同时，通过这个IE告诉A：“你建议的-3dB我不同意，但我可以接受的调整范围是-1dB到0dB之间。你再考虑一下？” 这使得一次失败的请求，可以转变为下一轮更精准的协商，极大地提升了SON的协同效率。

3. 8.4.10 & 8.4.11 Resource Status Reporting - 网络的“交通流量监控”

如果说Mobility Settings Change是基于历史统计的“长期调优”，那么资源状态上报就是为了**实时负载均衡（Real-time Load Balancing）**而设计的“短期决策”依据。

场景设定：基站A下的小区负载已经高达80%，濒临拥塞。此时，一个新用户请求接入。如果让其接入，可能会影响所有用户的体验。基站A需要立刻知道，它的邻居基站B是否有能力分担一部分负载。

3.1 8.4.10 Resource Status Reporting Initiation - 开启“流量监控”

这是一个Class 1流程，用于发起一次监控任务。

This procedure is used by an NG-RAN node to request the reporting of load measurements to another NG-RAN node.

RESOURCE STATUS REQUEST消息的核心IE：

• Registration Request IE: 定义了本次请求的动作。

  • start: 开启一个新的监控任务。
  • stop: 停止一个已有的监控任务。
  • add: 在一个已有的监控任务中增加要监控的小区。

• Report Characteristics IE: 这是“监控任务清单”，通过一个位图（bitmap）精确指定了需要上报哪些信息。

  the first bit, “PRB Periodic” … the second bit, “TNL Capacity Ind Periodic” … the third bit, “Composite Available Capacity Periodic” … the fourth bit, “Number of Active UEs Periodic” … the fifth bit, “RRC Connections Periodic” 陈工的解读：“你看，A可以非常精细地向B请求它需要的信息，比如：”

  • PRB利用率：无线资源的使用情况，这是最核心的负载指标。
  • TNL容量：传输网络（回传）的负载情况。空口有资源，但回传堵了也不行。
  • 可用容量：一个综合性的容量指标。
  • 活跃用户数和RRC连接数：反映了小区的繁忙程度。

• Reporting Periodicity IE: 定义了“多久报告一次”。可以是周期性的，也可以是“一次性”的快照。

B收到请求并评估自身能力后，如果同意，就回复RESOURCE STATUS RESPONSE，表示“监控已开启”。

3.2 8.4.11 Resource Status Reporting - 周期性的“流量公报”

这是一个Class 2流程，用于执行监控任务。

This procedure is initiated by an NG-RAN node to report the result of measurements admitted by the NG-RAN node following a successful Resource Status Reporting Initiation procedure.

一旦监控任务启动，基站B就会按照约定的周期，向A发送RESOURCE STATUS UPDATE消息。这个消息中包含了A在REQUEST中请求的各种负载信息。

场景代入与决策：

1. 基站A向邻居B和C发起RESOURCE STATUS REQUEST，请求周期性上报PRB利用率。
2. A持续收到来自B和C的RESOURCE STATUS UPDATE消息。
3. 当A自身负载达到80%时，它查看最新的报告，发现B的负载只有30%，而C的负载高达90%。
4. 于是，A在做切换决策时，会主动地将一些边缘用户切换到B（即使B的信号不是最优），以实现负载均衡。同时，它会避免将任何用户切换到本已拥塞的C。

这套“请求-周期性上报”的机制，为基站间的实时负载均衡提供了最直接、最有效的数据支撑。

4. 总结：SON理念的XnAP实践

小林今天学习的这三个流程，让他对SON（自组织网络）的理解从一个抽象的概念，变成了具体的信令交互。Mobility Settings Change、Resource Status Reporting Initiation和Resource Status Reporting，共同构成了XnAP协议中实现移动性优化和负载均衡的“三驾马车”。

• Mobility Settings Change 致力于长期、主动的移动性边界优化，通过邻居间的协商，从根源上减少乒乓切换和切换失败，实现MRO。
• Resource Status Reporting系列流程 则专注于短期、实时的网络负载感知，为动态的负载均衡（MLB）提供决策依据。

它们都是全局流程，其优化目标是整个小区的健康度和资源利用率，而非某个特定用户。正是这些在后台默默运行的“自感知”与“自优化”流程，使得5G网络能够应对复杂多变的无线环境和话务模型，在无需人工干预的情况下，持续保持在最优的工作状态。

FAQ

Q1：Mobility Settings Change和Handover Report (8.4.8节) 都是为了优化移动性，它们有什么区别？ A1：两者目的相同，但手段和时机完全不同。Handover Report是被动式、事后的优化。它是在一次切换失败后，网络通过分析“黑匣子”数据，来总结教训。而Mobility Settings Change是主动式、事前的优化。它是在基站通过长期统计分析，预判到切换参数可能不合理时，主动与邻居协商进行调整，目的是预防失败的发生。前者是“复盘”，后者是“推演”。

Q2：为什么Resource Status Reporting系列流程是全局流程，而不是UE关联流程？ A2：因为它们关注的是小区级别的宏观状态，而非某个特定UE的微观状态。基站A想知道的是“邻居B整个小区的负载有多高”，而不是“邻居B为某个特定UE分配了多少资源”。这些小区级的负载信息是进行负载均衡决策的基础。当MN需要将UE切换出去以降低自身负载时，它需要一个关于所有邻区负载的全局视图，才能做出最优选择。

Q3：Report Characteristics这个位图（bitmap）设计有什么好处？ A3：最大的好处是灵活性和效率。它允许请求方按需索取信息。如果一个基站只关心无线侧负载，它可以在bitmap中只设置“PRB Periodic”位为1。接收方就只需要测量和上报这一项数据，避免了测量和传输不必要的其他信息（如TNL容量），从而节省了双方的处理开销和信令带宽。

Q4：为什么Mobility Settings Change和Resource Status Reporting Initiation是Class 1流程，而Resource Status Update是Class 2流程？ A4：这取决于流程的性质。

• Mobility Settings Change和Resource Status Reporting Initiation都是一种请求或协商。发起方需要知道对方是否同意自己的提议，或者是否具备能力开启监控。因此必须有明确的成功或失败响应，所以是Class 1。
• Resource Status Update是一种周期性的状态报告。它是一种单向的信息流。发起方（上报负载的一方）不强求接收方对每一份报告都进行确认。即使偶尔丢失一份报告，在下一个周期很快就会有新的报告来更新状态。采用Class 2可以最大程度地降低周期性信令带来的网络开销。

Q5：这些SON流程在实际网络中是如何为运营商节省成本的？ A5：它们是降低网络OPEX（运营成本）的关键技术。通过自动化的移动性优化（MRO）和负载均衡（MLB），网络可以自我修复大量常见的性能问题，大大减少了需要人工介入的路测、参数调整和故障排查工作。一个自优化的网络，不仅用户体验更好，其运维成本也显著低于需要大量人工“精调”的传统网络。