好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 28.552：5.1.1.25 Measurements related to MRO (移动性鲁棒性优化测量)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.25 Measurements related to MRO”的核心章节，旨在为读者提供一个关于5G网络如何实现移动性自优化的性能测量全景解析。

引言：永不迷航的“赛车手”

在上一篇中，我们护航了高铁上的商务精英李杰，体验了5G与4G间的“无感切换”。那次保障任务，依赖的是网络优化工程师们预先精心规划的邻区关系和切换参数。但老王在复盘时提出了一个更深层次的问题：“小林，城市是在不断生长的，新的楼宇、新的基站、新的干扰源层出不穷。我们不可能永远跟在后面‘手动’调整切换参数。有没有一种方法，能让网络自己学会如何‘开车’，像一个经验丰富的F1赛车手，能够自主感知赛道变化，并动态调整自己的驾驶策略，永远跑在最佳路线上？”

小林的眼睛一亮：“自优化网络（SON）！”

“没错！”老王肯定道，“而SON中最核心的应用之一，就是MRO (Mobility Robustness Optimization，移动性鲁棒性优化)。MRO的目标，就是让网络通过分析UE的移动性行为和失败事件，自动检测并修正不合理的切换参数，从而最大限度地减少掉话和乒乓切换。”

他将TS 28.552翻到了5.1.1.25节。“要让‘赛车手’学会自动驾驶，首先要给它装上一双‘慧眼’和一套‘复盘系统’。这一节，‘Measurements related to MRO’，就是为MRO功能量身打造的‘数据采集传感器’。它不再像之前的切换测量那样，只统计成功或失败的次数，而是深入到失败的‘案发现场’，去分析每一次失败的具体模式——是‘开早了’、‘开晚了’，还是‘开错了道’。”

这篇文章，我们将化身为“AI驾驶教练”，通过解读MRO相关的核心测量项，揭示5G网络是如何从一次次失败的移动事件中学习、进化，最终实现“永不迷航”的。

1. 切换失败的“三宗罪”：Too Early, Too Late, To Wrong Cell

MRO的核心思想，是将切换失败事件，根据其发生前后的UE行为，归因为三种经典的失败模式。

1.1 “开早了”的急刹车：Handover failures related to MRO for intra-system mobility (5.1.1.25.1 - Too Early)

a) This measurement provides the number of handover failure events related to MRO detected during the intra-system mobility within 5GS… The measurement includes separate counters for various handover failure types, classified as “Intra-system too early handover”… c) The measurements of too early handovers… are obtained respectively by accumulating the number of failure events detected by gNB during the intra-system mobility within 5GS. e) HO.IntraSys.TooEarly

1.1.1 深度解析与场景定义

Too Early Handover (切换过早)，顾名思义，就是源小区过早地将UE切换到了一个信号尚不具备优势的目标小区。

“案发现场”还原：

1. UE从小区A切换到小区B。
2. 切换后很短的时间内（例如1-2秒），UE在小区B发生了无线链路失败（RLF）。
3. UE尝试进行RRC重建，并且成功地在原来的小区A重建了连接。

MRO的逻辑判断： 既然UE在切换后短时间内就在新家“活不下去”，并且还能轻松地“跑回”老家，这强烈地暗示了当初的切换决策是错误的、是过早的。目标小区B的信号，并没有想象中那么好，或者至少没有稳定到足以承载业务。

测量项HO.IntraSys.TooEarly 就是专门捕获这种“切过去又跑回来”的事件的计数器。

1.1.2 场景化举例：十字路口的“假信号”

“智行一号”自动驾驶巴士行驶到一个十字路口，这里是基站A和基站B的软覆盖交界区。由于建筑物的反射，基站B的一个旁瓣信号瞬间很强，触发了切换。

• 10:30:15：巴士从A切换到B。
• 10:30:16：巴士驶过反射点，B的信号迅速衰落，导致RLF。
• 10:30:16.5：巴士在原基站A的强信号覆盖下，成功完成RRC重建。

gNB的MRO功能模块检测到这个完整的事件链，立刻将HO.IntraSys.TooEarly计数器加1。

洞察与自优化： 如果一个邻区关系（A→B）的TooEarly计数持续增多，SON系统就会自动采取行动，例如：调高从A切换到B的切换门限（A3 Event的offset和hysteresis），让UE在B的信号变得“更强、更稳定”之后再进行切换，避免被瞬时的“假信号”所迷惑。

1.2 “开晚了”的追尾：Too Late Handover

a) …classified as … “Intra-system too late handover”… e) HO.IntraSys.TooLate

1.2.1 深度解析与场景定义

Too Late Handover (切换过晚)，指的是源小区迟迟不发起切换，导致UE在源小区的信号已经极差的情况下才开始切换，最终因为信号太弱而导致切换失败。

“案发现场”还原：

1. UE在小区A的信号覆盖边缘，信号质量持续恶化。
2. 小区A没有及时发起切换。
3. UE在小区A发生了无线链路失败（RLF）。
4. UE尝试进行RRC重建，并且成功地在一个邻近的小区B重建了连接。

MRO的逻辑判断： 既然UE在老家“活不下去”了（RLF），并且最终成功地在邻居B家“安了家”，这强烈地暗示了如果小区A能早一点发起向B的切换，这次RLF本可以避免。

测量项HO.IntraSys.TooLate 就是专门捕获这种“在老家掉线，在邻居家复活”的事件的计数器。

1.2.2 场景化举例：进入地下车库的“最后一秒”

李杰驾车进入公司地下车库的入口坡道。地面上的基站A信号正在迅速衰减，而车库内的室内覆盖基站B的信号正在增强。

• 基站A的切换门限设置得过低，迟迟没有触发向B的切换。
• 14:05:20：车辆进入坡道深处，A的信号彻底中断，发生RLF。
• 14:05:21：车辆继续前行，完全进入B的覆盖范围，成功在B小区重建了RRC连接。

MRO功能模块检测到此事件，将HO.IntraSys.TooLate计数器加1。

洞察与自优化： 如果一个邻区关系（A→B）的TooLate计数持续增多，SON系统就会采取与Too Early相反的行动：调低从A切换到B的切换门限，或者缩短测量和触发的延迟，让切换能够更早、更及时地发生，避免UE在源小区的弱覆盖边缘“苦苦挣扎”。

1.3 “开错了道”的迷茫：Handover to Wrong Cell

a) …classified as … “Intra-system handover to wrong cell”. e) HO.IntraSys.ToWrongCell

1.3.1 深度解析与场景定义

Handover to Wrong Cell (切换到错误小区)，指的是源小区将UE切换到了一个“次优”的小区B，而实际上存在一个信号更好的“最优”小区C。

“案发现场”还原：

1. UE从小区A切换到小区B。
2. 切换后很短的时间内，UE在小区B又再次发起切换，并成功切换到了另一个小区C。
3. （可选的更强证据）UE在切换到C之前的测量报告显示，C的信号强度远强于B。

MRO的逻辑判断： 刚搬到B家，立刻又搬去了C家，这说明B只是一个“中转站”，当初直接搬到C家才是最佳选择。这暴露了源小区A的邻区策略或UE的测量配置可能存在问题，导致它没有及时发现信号更好的C小区。

测量项HO.IntraSys.ToWrongCell 就是捕获这种“连续跳跃”事件的计数器。

1.3.2 场景化举例：高架桥下的“选择困难症”

“智行一号”行驶在高架桥下，这里同时受到来自桥上基站B和地面基站C的信号。

• 基站A根据历史数据，错误地将B配置为更高优先级的邻区。
• 11:15:40：巴士从A切换到桥上的B。
• 11:15:41：巴士发现地面C的信号远强于B，立刻又发起了向C的切换。
• 11:15:42：巴士成功切换到C。

MRO功能模块检测到这次快速的连续切换，将HO.IntraSys.ToWrongCell计数器加1，并记录下这个“错误”的邻区对（A→B）和“正确”的邻区对（A→C）。

洞察与自优化： 如果ToWrongCell事件频繁发生在一个邻区关系（A→B）上，并且后续总是切换到C，SON系统就会自动调整邻区列表（NCL）的优先级，将C的优先级调高，甚至在某些情况下，自动删除错误的邻区关系（A→B）。

2. 跨系统的“疑难杂症”：Inter-system MRO & Unnecessary HO & Ping-Pong

MRO的监控范围不仅限于5G系统内部，也延伸到了5G与4G（EPS）的互操作，以及其他移动性问题。

5.1.1.25.2 Handover failures related to MRO for inter-system mobility (HO.InterSys.TooEarly, HO.InterSys.TooLate)

这组测量将Too Early和Too Late的分析方法，应用到了5G与4G之间的切换场景，帮助优化跨系统切换的参数。

5.1.1.25.3 Unnecessary handovers for inter-system mobility (HO.InterSys.Unnecessary)

深度解析： 捕获“不必要的切换”。例如，UE从一个信号很好的5G小区，被切换到了4G小区，不久后又因为5G信号依然很好而切回。这说明5G→4G的切换门限可能过于敏感，造成了不必要的系统间“抖动”。

5.1.1.25.4 Handover ping-pong for inter-system mobility (HO.InterSys.PingPong)

深度解析： 捕获“乒乓切换”。即UE在很短时间内，在5G小区A和4G小区B之间来回切换。这通常发生在两个系统覆盖边界信号强度相当的区域，说明切换的迟滞参数（hysteresis）设置得太小，无法形成稳定的连接。

3. 精细到“光束”的诊断：Per Beam-Cell Pair MRO (5.1.1.25.5 - 5.1.1.25.8)

规范的精细化不止于此，它还将MRO的分析粒度，从小区级，进一步深化到了波束级。

5.1.1.25.5 Handover failures per beam-cell pair related to MRO for intra-system mobility a) This measurement provides the number of handover failure events per beam-cell pair (source beam… and target cell) e) HO.IntraSys.bTooEarly.NCI, HO.IntraSys.bTooLate.NCI, …

深度解析： 这组测量项HO.IntraSys.b...（b代表beam）的维度是“源波束 + 目标小区”。它统计的是，当UE在上一个服务波束是beam X的情况下，发生的Too Early/Too Late/To Wrong Cell的次数。 这使得优化可以达到前所未有的精度。例如，我们可能会发现，只有当用户从基站A的3号波束向基站B切换时，Too Late的比例才特别高。这说明问题可能并非出在整个小区的切换参数上，而仅仅是3号波束的覆盖边缘存在特殊问题，我们只需要针对性地调整这个特定波束的测量上报策略即可。

结论：MRO测量——赋予网络自我进化的“大脑”

通过对MRO相关测量的学习，小林终于明白了5G网络是如何从“人工驾驶”迈向“自动驾驶”的。

“王哥，我懂了。MRO测量体系，就像是给网络这个‘赛车手’安装了一套完整的‘车载诊断和学习系统’。”

1. 事件归因引擎: 它将模糊的“掉话”，精准地归因为Too Early, Too Late, To Wrong Cell等可操作的失败模式。
2. 多维度诊断: 从系统内到系统间，从小区级到波束级，提供了从宏观到微观的全方位诊断能力。
3. 自优化闭环: 这些测量结果，是SON/MRO算法的“养料”。算法通过持续分析这些数据，就能自动调整切换参数、优化邻区关系，形成一个“发现问题-分析问题-解决问题”的自优化闭环。

这套体系，让网络不再是一个被动执行静态配置的“机器”，而是一个能够从自身错误中学习、不断适应环境变化的“智能体”。正是有了这颗自我进化的“大脑”，才使得像“智行一号”、远程手术这样的严苛移动性场景，得以成为现实。

---

FAQ 环节

Q1：MRO测量的Too Early, Too Late等事件，是由UE上报的，还是gNB自己判断的？ A1：是由gNB侧的MRO功能实体根据一系列事件链来综合判断的。UE只会上报基础的测量报告（RSRP/RSRQ）和在发生RLF后的RRC重建请求。gNB的MRO模块会像一个侦探一样，将这些来自不同时间点的、看似孤立的事件串联起来。例如，它会记录下一次成功的A→B切换，如果在短时间内又收到了来自同一个UE在A小区的重建请求，MRO就会将这两个事件关联，并判定为一次Too Early事件。

Q2：HO.IntraSys.ToWrongCell（切换到错误小区）和HO.InterSys.PingPong（乒乓切换）有什么区别？ A2：它们描述的失败模式不同。ToWrongCell 描述的是一次“三角恋”：UE从A切到B，然后立刻又切到C。它反映的是A→B这个邻区选择的次优性。而**PingPong** 描述的是一次“二人转”：UE在A和B之间来回切换。它反映的是A和B这两个小区之间切换判决的不稳定性，通常是由于切换迟滞参数设置过小。

Q3：为什么MRO的测量项里没有“成功”的计数？ A3：因为MRO（移动性鲁棒性优化）的核心目标是诊断和减少失败，它的关注点天生就在于“哪里出了问题”以及“为什么出问题”。成功的切换由我们之前学习的常规切换测量（如MM.HoExeInterSucc）来统计，用于计算宏观的成功率KPI。而MRO测量则深入到失败的样本中，进行更精细的分类和归因，其目的是为“自优化”提供输入，而非简单的性能考核。

Q4：Per Beam-Cell Pair（每波束-小区对）的MRO测量，对硬件和处理能力的要求是不是很高？ A4：是的，这要求gNB具备更强的处理和存储能力。gNB不仅要记录每一次切换的源小区和目标小区，还要精确地记录下切换前UE的最后一个服务波束是哪一个。当发生MRO事件（如Too Late）时，gNB需要回溯UE的历史信息，将这次失败与之前的服务波束进行关联。这对于需要处理海量用户和高频移动事件的gNB来说，是一个不小的挑战。因此，这种精细化的测量通常是高端设备才具备的功能，并且运营商可能会根据网络负载，选择性地开启它。

Q5：MRO能完全替代人工优化吗？ A5：MRO是人工优化的强大助手和自动化工具，但不能完全替代。MRO非常擅长处理基于明确规则和本地信息的参数调整，如优化切换门限、迟滞、邻区优先级等。但它很难处理一些需要全局视野和复杂意图理解的问题，例如：1）大范围的网络规划调整，如新建基站。2）涉及多网、多频的复杂协同策略。3）由外部非通信因素（如节假日人流潮汐）引起的规律性问题预测。在这些场景下，依然需要经验丰富的网络优化工程师，结合MRO提供的数据和更宏观的网络洞察，做出最终的决策。