51学通信

深度解析 3GPP TS 28.552：5.1.1.6 Mobility Management (Part 1 - 护航“智行一号”：Inter-gNB与Intra-gNB切换测量)

25分钟阅读

好的，我们继续进行深度拆解。

深度解析 3GPP TS 28.552：5.1.1.6 Mobility Management (Part 1 - 护航“智行一号”：Inter-gNB与Intra-gNB切换测量)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.6 Mobility Management”中基础切换测量的核心章节，旨在为读者提供一个关于5G网络最核心移动性管理——gNB间切换与gNB内切换——的性能测量全景解析。

引言：自动驾驶巴士“智行一号”的首航挑战

清晨的阳光洒在智慧城市的示范公路上，一辆充满未来感的无人驾驶巴士——“智行一号”，正准备开始它的首次公开线路试运行。车内空无一人，方向盘自动旋转，平稳地驶出车站。它的“眼睛”和“大脑”，依赖于一条永不中断的5G数据链，实时与城市交通控制中心进行高频信息交互。

在城市的网络优化中心，年轻工程师小林和他的导师老王，正紧盯着大屏幕上代表“智行一号”的光点。这次保障任务的最高指令只有一条：零中断。

“王哥，‘智行一号’即将驶出A1基站的覆盖范围，马上要进行第一次跨站切换了。”小林的声音略带紧张，“我们为它规划的专用网络切片，能保证无缝切换吗？万一失败，车辆可能会因为失去高精度定位和远程指令而紧急停车，造成交通堵塞。”

老王指着屏幕上一组正在实时更新的性能计数器，沉稳地说：“别怕，我们有‘护航舰队’。3GPP TS 28.552的5.1.1.6节，就是这支舰队的‘作战手册’。它将一次看似瞬间完成的切换，分解为‘准备-分配-执行’三大阶段，并为每个阶段都部署了精确的‘哨兵’——也就是性能测量项。通过监控这些哨兵的报告，我们能实时掌握切换的每一个细节，预判风险，并在出现问题时迅速定位。”

“今天，我们就以护航‘智行一号’的全过程为例，深入学习这本手册的第一部分：最基础也是最重要的Inter-gNB（跨站）和Intra-gNB（站内）切换测量。这不仅是保障自动驾驶、高铁上网等移动业务的关键，更是所有网络优化工程师的基本功。”

1. 跨越山海：Inter-gNB handovers (gNB间切换) 的三阶段测量 (5.1.1.6.1)

“智行一号”正以60km/h的速度行驶，即将穿越两个物理基站（gNB-A和gNB-B）的覆盖交界区。这是一次典型的Inter-gNB handover (gNB间切换)。整个过程如同一次精密的接力赛，gNB-A（源站）需要将“智行一号”这个“运动员”，平稳地交接到gNB-B（目标站）手中。规范为这次“交接棒”的全过程，设置了三道关卡的监控。

1.1 第一道关：切换准备 (Handover Preparation) - 源站的“投石问路”

当gNB-A发现“智行一号”的信号越来越弱，而来自gNB-B的信号越来越强时，它决定发起切换。这个决策阶段，就是“切换准备”。

1.1.1 准备请求数：Number of requested legacy handover preparations (5.1.1.6.1.1)

a) This measurement provides the number of legacy handover preparations requested by the source gNB.

c) On transmission of HANDOVER REQUIRED message (see TS 38.413) by the NR cell CU to the AMF, or transmission of HANDOVER REQUEST message (see TS 38.423), where the message denotes a legacy handover, by the source NR cell CU to target NR cell CU, for requesting the preparation of resources at the target NR cell CU.

e) MM.HoPrepInterReq.

  • 深度解析： 这个计数器 MM.HoPrepInterReq (Mobility Management, Handover Preparation Inter Request) 是整个切换流程的起点。它的触发点是源gNB（gNB-A）下定决心，正式向网络发出“我要切换了，请目标站准备”的请求。这个请求有两种路径：

    1. 经由AMF (NG接口): gNB-A向AMF发送HANDOVER REQUIRED消息。
    2. 直连目标gNB (Xn接口): gNB-A直接向gNB-B发送HANDOVER REQUEST消息。 无论走哪条路，只要源gNB发出了这个请求，这个计数器就加1。它代表了源站发起的切换尝试总数。

  • 场景化举例： 10:05:31，gNB-A监测到“智行一号”的上报的测量报告满足了切换条件，于是通过Xn接口向gNB-B发送了HANDOVER REQUEST消息。瞬间，gNB-A上报的MM.HoPrepInterReq计数器从99跳到了100。

1.1.2 准备成功数：Number of successful legacy handover preparations (5.1.1.6.1.2)

a) This measurement provides the number of successful legacy handover preparations received by the source NR cell CU.

c) On receipt of HANDOVER COMMAND message by the NR cell CU from the AMF (see TS 38.413), or receipt of HANDOVER REQUEST ACKNOWLEDGE message (see TS 38.423), …by the source NR cell CU from the target NR cell CU…

e) MM.HoPrepInterSucc.

  • 深度解析： 源gNB-A发出了请求，目标gNB-B会不会同意呢？MM.HoPrepInterSucc (Success) 就是衡量目标站“同意准备”的计数器。它的触发点是源gNB-A收到了肯定的答复：

    1. 来自AMF的HANDOVER COMMAND: 如果切换走NG接口，AMF会扮演“传令官”的角色。
    2. 来自目标gNB-B的HANDOVER REQUEST ACKNOWLEDGE: 如果走Xn接口，目标站会直接回复“ACK”，表示“收到，已准备好”。 这个计数器加1，意味着目标站已成功为“智行一号”预留了无线资源，切换准备阶段成功。

  • 场景化举例： 10:05:31.050，gNB-A收到了来自gNB-B的HANDOVER REQUEST ACKNOWLEDGE消息。gNB-A的MM.HoPrepInterSucc计数器立刻加1。此时，小林和老王都知道，第一次考验通过了。

1.1.3 准备失败数：Number of failed legacy handover preparations (5.1.1.6.1.3)

a) This measurement provides the number of failed legacy handover preparations received by the source NR cell CU. This measurement is split into subcounters per failure cause.

c) On receipt of HANDOVER PREPARATION FAILURE message…

e) MM.HoPrepInterFail.cause. Where cause identifies the failure cause of the handover preparations.

  • 深度解析： MM.HoPrepInterFail.cause (Failure) 是最重要的故障诊断指标之一。当源gNB-A收到了一个坏消息——HANDOVER PREPARATION FAILURE时，这个计数器就会启动。更关键的是，它会根据消息中携带的失败原因 (cause)，增加对应子计数器的值。常见的原因有：

    • Cause Radio Network: “资源不可用”、“目标小区不可达”等。
    • Cause Transport: 传输网络层问题。
    • Cause Protocol: 协议消息错误。 这个按原因细分的统计，能让优化工程师迅速定位准备失败的根源。

  • 场景化举例： 假设gNB-B因为承载媒体切片的资源已满，无法为“智行一号”预留资源。它会回复一个携带Cause: radio-resources-not-available的FAILURE消息。gNB-A收到后，其MM.HoPrepInterFail.cause_RadioResNotAvail子计数器就会加1。老王和小林看到这个计数器跳动，就会立刻明白：目标小区容量不足是切换失败的主因。

1.2 第二道关：资源分配 (Resource Allocation) - 目标站的“厉兵秣马”

现在，我们把视角切换到目标站gNB-B。当它收到gNB-A的请求时，它内部也有一套“记账”系统，这就是资源分配测量。

5.1.1.6.1.4 Number of requested legacy handover resource allocations (MM.HoResAlloInterReq) 5.1.1.6.1.5 Number of successful legacy handover resource allocations (MM.HoResAlloInterSucc) 5.1.1.6.1.6 Number of failed legacy handover resource allocations (MM.HoResAlloInterFail.cause)

  • 深度解析： 这一组三个测量项，与准备阶段的三个几乎是“镜像”关系，但它们的统计主体是目标gNB。

    • Req (请求数): 当gNB-B收到HANDOVER REQUEST消息时，MM.HoResAlloInterReq加1。它衡量了目标小区被请求作为切换目标的总次数。
    • Succ (成功数): 当gNB-B成功分配资源并发送HANDOVER REQUEST ACKNOWLEDGE消息时，MM.HoResAlloInterSucc加1。它衡量了目标小区成功提供切换资源的能力。
    • Fail (失败数): 当gNB-B因故无法分配资源并发送HANDOVER PREPARATION FAILURE消息时，MM.HoResAlloInterFail.cause根据失败原因加1。它反映了目标小区成为切换“瓶颈点”的具体原因。

  • 场景化举例： 在护航“智行一号”的成功切换中，gNB-B在收到请求时，MM.HoResAlloInterReq加1；在发送ACK时，MM.HoResAlloInterSucc加1。而在备用无人机“鹰眼-02”的失败案例中，gNB-B在收到请求时，MM.HoResAlloInterReq加1；但在发送FAILURE时，MM.HoResAlloInterFail.cause_RadioResNotAvail加1。 “小林你看，”老王强调，“源站的‘准备失败’和目标站的‘分配失败’，其实是同一事件的两面。结合两边的统计，我们可以进行交叉验证，确保数据没有错误，并从两个角度完整地还原一次失败的切换准备过程。”

1.3 第三道关：切换执行 (Handover Execution) - UE的“终极一跃”

gNB-B已经准备就绪，gNB-A收到了肯定的答复。现在，最关键的一步来了：gNB-A必须命令“智行一号”正式切换到gNB-B。这个命令发出后，直到网络确认“智行一号”成功在新家落脚，整个过程被称为“切换执行”。

1.3.1 执行请求数：Number of requested legacy handover executions (5.1.1.6.1.7)

c) On transmission of RRCReconfiguration message, where the message denotes a legacy handover, to the UE triggering the inter gNB legacy handover from the source NRCellCU to the target NRCellCU…, the counter is stepped by 1.

e) MM.HoExeInterReq.

  • 深度解析： 这是执行阶段的开始。MM.HoExeInterReq (Execution) 的触发点是源gNB-A向UE（“智行一号”）发送了包含切换指令的RRCReconfiguration消息。这条消息就像是发令枪，告诉UE：“别再听我的了，立刻去gNB-B报到！”。这个计数器衡量了网络发起了多少次最终的切换执行动作。

1.3.2 执行成功数：Number of successful legacy handover executions (5.1.1.6.1.8)

c) On receipt at the source gNB of UE CONTEXT RELEASE TS 38.423 over Xn from the target gNB following a successful handover… or, if handover is performed via NG, on receipt of UE CONTEXT RELEASE COMMAND TS 38.413 from AMF…, the counter is stepped by 1.

e) MM.HoExeInterSucc.

  • 深度解析： 如何判断UE成功在新家落脚了呢？源gNB-A自己是不知道的，它需要一个“信使”来告诉它。这个“信使”就是UE CONTEXT RELEASE（UE上下文释放）消息。当“智行一号”成功接入gNB-B后，gNB-B会通知网络（通过Xn接口直接告诉gNB-A，或通过NG接口告诉AMF再由AMF通知gNB-A），“人已到我这，你可以把他以前的档案删了”。源gNB-A收到这个释放指令，就意味着切换执行成功，MM.HoExeInterSucc计数器加1。

1.3.3 执行失败数：Number of failed legacy handover executions (5.1.1.6.1.9)

c) This counter is incremented when handover execution failures occur… The following events are counted:

  1. On reception of NGAP UE CONTEXT RELEASE COMMAND TS 38.413 from AMF indicating an unsuccessful inter gNB handover;

  2. On reception of RrcReestablishmentRequest… from the UE in the source gNB…

  3. On expiry of a Handover Execution supervision timer in the source gNB;

  4. On reception of XnAP RETRIEVE UE CONTEXT REQUEST…

e) MM.HoExeInterFail.UeCtxtRelCmd.cause; MM.HoExeInterFail.RrcReestabReq; …

  • 深度解析： 这是整个切换测量中最复杂的失败计数器，因为它需要监控多种失败场景：

    1. 核心网明确告知失败： AMF发来UE CONTEXT RELEASE COMMAND消息，但原因是切换失败。
    2. UE自己“跑”回来了： “智行一号”在前往gNB-B的路上“迷路”（无法成功接入），它可能会尝试回到原来的gNB-A。当gNB-A收到它发来的RrcReestablishmentRequest（RRC重建请求）时，就意味着切换失败了。
    3. UE失联超时： gNB-A发出了切换指令后，启动一个计时器。如果在规定时间内，既没有收到UE成功切换的消息，UE也没“跑”回来，那么就判定UE已失联，切换失败。
    4. UE在别处“复活”： UE在gNB-B接入失败，也没回到gNB-A，而是跑到了第三个基站gNB-C并尝试接入。gNB-C为了获取它的上下文，会向gNB-A发一个RETRIEVE UE CONTEXT REQUEST，这也宣告了原先的切换失败。

  • 场景化举例： “智行一号”的切换非常顺利，最终gNB-A收到了UE CONTEXT RELEASE，MM.HoExeInterSucc加1。但假设在切换过程中，公路上突然出现强烈的电磁干扰，导致“智行一号”没能成功接入gNB-B。几秒后，它回到了gNB-A的覆盖区，并发送了RrcReestablishmentRequest。gNB-A收到后，其MM.HoExeInterFail.RrcReestabReq子计数器就会加1。小林看到这个计数器增长，就能迅速判断：“切换失败的原因是空口质量问题导致UE在新小区接入失败！”

1.4 额外的诊断工具：执行时间与波束级测量

除了三大阶段的成功失败统计，规范还提供了更精细的诊断工具。

5.1.1.6.1.10 Mean Time of requested legacy handover executions (MM.HoExeInterReq.TimeMean.SNSSAI) 5.1.1.6.1.11 Max Time of requested legacy handover executions (MM.HoExeInterReq.TimeMax.SNSSAI)

这两个测量项用于统计切换中断时间，即从源gNB发出RRCReconfiguration切换指令，到收到UE成功切换的UE CONTEXT RELEASE消息之间的时长。平均中断时间和最大中断时间，直接关系到用户在切换过程中的业务中断感知（例如通话中断、视频卡顿）。对于“智行一号”这样的uRLLC业务，这个时间必须被严格控制在几毫秒之内。

5.1.1.6.1.12 Number of successful handover executions per beam pair (MM.HoExeInterSSBSucc) 5.1.1.6.1.13 Number of failed handover executions per beam pair (MM.HoExeInterSSBFail)

这是5G特有的精细化测量。它不再是统计小区到小区的切换，而是统计源小区的某个波束（SSB）到目标小区的某个波束的切换成功/失败次数。这对于优化波束级的移动性策略，解决特定角度、特定区域的“波束级切换黑洞”问题，具有不可替代的作用。

2. 内部腾挪：Intra-gNB handovers (gNB内切换) 的简化测量 (5.1.1.6.2)

当“智行一号”驶过一个路口，只是从gNB-B的1号扇区移动到了2号扇区时，它经历的是一次Intra-gNB handover (gNB内切换)。因为源小区和目标小区都属于同一个gNB，整个流程大大简化，无需通过Xn或NG接口与外部实体交互。

5.1.1.6.2.1 Number of requested legacy handover executions (MM.HoExeIntraReq) 5.1.1.6.2.2 Number of successful legacy handover executions (MM.HoExeIntraSucc)

  • 深度解析： 由于无需外部准备和资源分配，gNB内切换的测量也相应简化，只关注“执行”阶段。

    • 请求数 (MM.HoExeIntraReq): 当gNB决定进行站内切换，并向UE发送RRC Reconfiguration消息时，计数器加1。
    • 成功数 (MM.HoExeIntraSucc): 当UE成功接入目标小区，并向gNB回复RRC ReconfigurationComplete消息时，计数器加1。

  • 场景化举例： 小林观察到，当“智行一号”在gNB-B的不同扇区之间移动时，MM.HoExeIntraReq和MM.HoExeIntraSucc的计数都在平稳增长，且两者数值基本相等，说明站内切换非常健康。

结论：为无缝移动性构建的“三道防线”

“智行一号”的首航任务圆满成功，全程网络连接无一次中断。小林在复盘时，对老王佩服得五体投地。

“王哥，我明白了。5.1.1.6节为我们构建了一个完美的闭环监控体系，”小林总结道，“它就像为每一次切换部署了‘源站岗’、‘目标站岗’和‘UE跟踪岗’三道防线。”

  1. 切换准备测量：从源站视角，监控切换决策的发出与响应，是第一道防线。
  2. 资源分配测量：从目标站视角，监控资源预留的能力，是第二道防线。
  3. 切换执行测量：聚焦于UE的最终动作，监控切换的最终成败，是第三道防线。

这三道防线，配上失败原因、执行时间和波束级的精细化探针，使得5G的移动性管理不再是一个“黑盒”。无论是“智行一号”在城市道路上的飞驰，还是我们在高铁上的高速上网，背后都有这套精密的测量体系在默默护航，确保我们的数字生活永不掉线。

FAQ 环节

Q1：规范中反复提到的“legacy handover” (传统切换) 是什么意思？ A1：“Legacy handover”在这里是一个相对概念，主要是为了区别于后续章节将要介绍的更高级的切换方式，如Conditional Handover (CHO，条件切换) 和 DAPS Handover (双激活协议栈切换)。“Legacy”指的是在R15版本中定义的基础的、硬切换流程，即“先断后连”（Break-Before-Make）。这是5G移动性管理最基本的形式。

Q2：Inter-gNB切换测量的“准备”阶段和“资源分配”阶段，统计的不是同一个事件吗？为什么需要分开测量？ A2：它们统计的是同一个事件（切换准备）的不同侧面，统计主体不同，因此对于故障定位至关重要。准备测量（HoPrep）的主体是源gNB，它反映的是源gNB发起的切换请求有多少得到了成功/失败的响应。分配测量（HoResAllo）的主体是目标gNB，它反映的是目标gNB作为被请求方，其自身的资源提供能力如何。如果一个区域切换成功率低，通过对比这两个指标，我们可以快速判断问题：如果大量小区的“准备失败”都很高，但“分配失败”都很低，说明问题可能出在源gNB的参数配置或测量控制上；反之，如果某个小区的“分配失败”远高于其他小区，那么这个小区很可能就是网络中的“拥塞点”或“故障点”。

Q3：切换执行失败的判断条件看起来很复杂，哪一种是最常见的？ A3：在实际网络中，最常见的执行失败原因是第二种，即UE在源站收到RrcReestablishmentRequest（RRC重建请求）。这种情况通常被称为“切换后立即掉线（Too Late Handover）”或“切换到弱覆盖区”。它表明UE收到了切换指令，但在尝试接入目标小区的过程中，因为目标小区信号太差或干扰太强而失败，无奈之下只能尝试重连回原来的小区。这个指标的升高，是切换参数（如切换门限、迟滞时间）需要优化的一个强烈信号。

Q4：Intra-gNB（gNB内）切换为什么比Inter-gNB（gNB间）切换的测量项少得多？ A4：因为Intra-gNB切换的所有流程都发生在一个gNB的内部，它是一个“内部事务”。源小区和目标小区（通常是同一gNB的不同扇区）之间的资源协调和信息传递，都是通过设备内部接口完成的，无需经过标准化的Xn或NG接口。这使得“准备”和“资源分配”阶段变得非常快速和可靠，几乎可以视为一体。因此，规范简化了测量，只关注最终的“执行”结果，即gNB是否成功地命令UE切换，以及UE是否成功地完成了切换。

Q5：这些切换测量项，可以按S-NSSAI（网络切片）进行细分吗？ A5：非常关键的一点是，在5.1.1.6.1这个基础切换测量章节中，大部分切换计数器没有被要求按S-NSSAI进行细分，除了Mean/Max Time of requested legacy handover executions可以按切片统计中断时间。这是因为在切换的信令交互层面，很多时候是以UE为单位进行，而不是以PDU会话（及其关联的切片）为单位。但是，这并不意味着无法评估切片的移动性性能。通常，运营商会通过关联分析，将发生切换的UE与该UE当时承载的PDU会话的S-NSSAI信息进行关联，从而在后台计算出分切片的切换KPI。此外，在后续更高级的规范或版本中，对分切片移动性测量有更直接的定义。

关系图谱