51学通信

深度解析 3GPP TS 28.405：4.6 Signalling based activation in NR (Part 2 - 切换与去激活)

17分钟阅读

好的，这是系列文章的第九篇，也是4.6节解读的第二部分。我们将聚焦于5G NR信令驱动模式下最复杂的场景之一：切换。

深度解析 3GPP TS 28.405：4.6 Signalling based activation in NR (Part 2 - 切换与去激活)

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“4.6.2 Handling of measurement collection at handover in NR”和“4.6.3 Deactivation of measurement collection for a UE in NR”的核心章节。本文旨在为读者深入剖析，在5G高速移动场景下，针对单个用户的QoE测量任务是如何通过NG接口上的精密上下文传递，实现跨gNB的无缝迁移，并最终优雅地完成其生命周期的。

引言：飞驰的高铁与永不掉线的“体验探针”

在Part 1中，我们见证了网络优化工程师老王如何利用5G核心网的“实时订阅”能力，为在咖啡馆里玩XR云游戏的小慧，部署了精准的QoE监控。现在，挑战升级了。小慧结束了在咖啡馆的休闲时光，登上了一趟时速350公里的高铁。

在飞驰的列车上，她依然沉浸在《星际穿越》的XR世界里。这对5G网络提出了终极考验：不仅要提供超高带宽和超低时延，还要在基站（gNB）之间进行毫秒级的快速切换，以保证业务的连续性。对于老王而言，他的挑战同样艰巨：如何确保那个为小慧部署的、用于定位偶发卡顿的QoE“体验探针”，不会在频繁的切换中“掉线”或“失忆”？

TS 28.405的4.6.2节，就是这份“高铁作战预案”。它详细规定了在NG接口（连接gNB与核心网AMF的接口）上，QoE测量任务的上下文是如何像接力棒一样，在源gNB与目标gNB之间精准传递的。

1. 4.6.2.1 NG接口切换：QoE上下文的“神圣交接”

4.6.2.1 NG Based Handover for Signalling Based Activation The figure 4.6.2.1-1 and the text below describe the handling at NG Based handover between gNBs for Signalling Based Activation case.

这是信令驱动模式下切换场景的核心。规范中的“Figure 4.6.2.1-1: Handling of QMC activation example in case of NG Based handover in NR for Signalling Based Activation”以一张包含11个步骤的信令图，完美呈现了这场“神圣交接”的仪式。

1.1.1 核心流程拆解

场景设定: 小慧乘坐的高铁正从**源gNB（Source gNB）的覆盖范围，驶向目标gNB（Target gNB）**的覆盖范围。切换即将发生。

步骤 1: 源gNB发起切换请求 (Source gNB → AMF)

  1. Source gNB sends the message HANDOVER REQUIRED to AMF. The message includes the Source to Target Transparent Container which contains qoEReference, serviceType, measConfigAppLayerId, areaScope, measCollEntityIPAddress, qoEMeasurementStatus, sliceSupportListQMC, nGRANTraceId, availableRANVisibleqoEMetrics and containerForAppLayerMeasConfig.
  • 场景演绎: 源gNB通过测量报告（MR）发现，小慧的手机信号强度正在减弱，而邻近的目标gNB信号正在增强。它决定发起切换。
  • 技术解读: 源gNB向AMF发送一条**HANDOVER REQUIRED（需要切换）的NGAP消息。这条消息的核心，在于它携带了一个名为“源到目标透明容器（Source to Target Transparent Container）”**的“行李箱”。源gNB将小慧的QoE测量任务的所有“案卷材料”——从任务ID（qoEReference）到切片信息（sliceSupportListQMC），再到MCE地址和配置文件——全部打包放进了这个“行李箱”。这个容器之所以被称为“透明”，是因为对于中转站AMF来说，它通常不关心里面装了什么，它的任务只是把箱子原封不动地转交。

步骤 2: AMF转发请求 (AMF → Target gNB)

  1. AMF sends the message HANDOVER REQUEST to the Target gNB. The message includes the Source to Target Transparent Container which contains the same parameters as in step 1.
  • 场景演绎: AMF收到了源gNB的请求，它像一个高效的“调度员”，立即向目标gNB发送了一条**HANDOVER REQUEST（切换请求）**消息。
  • 技术解读: AMF将那个来自源gNB的、装满了QoE上下文的“透明容器”，完整地放入了这条新的请求消息中，发往目标gNB。AMF在这里扮演了关键的路由和中继角色。

步骤 3 & 4: 目标gNB的决策与响应

  1. The target gNB checks if the measurements to be continued or not.
  2. The target gNB sends the message HANDOVER REQUEST ACKNOWLEDGE to the AMF.
  • 场景演绎: 目标gNB收到了这个特殊的切换请求。它打开“行李箱”，审阅里面的QoE“案卷”。
  • 技术解读: 目标gNB需要做出一系列决策：
    • 能力检查: 我自己是否支持QoE测量这个功能？
    • 资源检查: 我当前的负荷是否允许接纳这个带有额外测量任务的用户？
    • 策略检查: 如果任务中包含areaScope，切换后的新小区是否仍在指定的测量区域内？ 如果所有检查都通过，目标gNB就在本地为小慧创建UE上下文，并将QoE任务信息存储起来。随后，它向AMF回复一条**HANDOVER REQUEST ACKNOWLEDGE（切换请求确认）**消息，表示：“人我要了，QoE任务我也接了！”

步骤 5: AMF下达切换命令

  1. The AMF sends the message HANDOVER COMMAND to the source gNB.
  • 技术解读: AMF收到目标gNB的确认后，立即向源gNB下达**HANDOVER COMMAND（切换命令）**，通知它可以执行切换了。

步骤 6 & 7: 空口的执行与完成

  1. The source gNB sends the message RRCREconfiguration to the UE.
  2. The UE sends the message RRCReconfigurationComplete to the gNB.
  • 场景演绎: 源gNB通过RRC信令，命令小慧的手机切换到目标gNB。小慧的手机执行切换，并向新的“上级”——目标gNB，回复一条RRCReconfigurationComplete消息，报告切换完成。
  • 技术解读: 从这一刻起，小慧的手机就正式由目标gNB提供服务了。整个切换过程在几十毫秒内完成，小慧在XR游戏中的体验几乎不受影响。

步骤 8之后: 在新大陆继续使命

  1. When the ongoing QMC is completed or end of periodic reporting is reached…
  2. The application layer sends the AT command +CAPPLEVMRNR…
  3. The UE sends the message MeasurementReportAppLayer…to the gNB.
  4. The gNB translates the qoECollectionEntityIdentity into qoECollectionEntityAddress and sends the QMC report to the MCE…
  • 场景演绎: 切换完成后，小慧的XR游戏仍在继续。当又一次卡顿发生时，她的手机APP会像往常一样生成QoE报告。
  • 技术解读:
    • 无缝上报: 手机APP将报告通过AT指令和MeasurementReportAppLayer消息，上报给了目标gNB。
    • 精准转发: 目标gNB因为在切换时已经继承了完整的QoE上下文，所以它清楚地知道这份报告应该发往哪个MCE地址。它 dutifully地扮演“邮差”角色，将报告转发出去。
    • 使命必达: 最终，这份在切换后产生的数据，依然准确无误地抵达了老王的分析平台。QoE“体验探针”成功实现了跨gNB的无缝迁移。

2. 4.6.3 任务的终结：5G时代的优雅谢幕

当监控任务需要结束时，其流程与4G LTE的信令驱动模式在逻辑上高度一致，但承载在5G的网元和接口之上。

2.2.1 预设时间到达 (Pre-set time has elapsed in NR)

4.6.3.1 Pre-set time has elapsed in NR When the pre-set time is elapsed, the gNB sets the network request session to ended, but do not delete the UE request session id…

  • 技术解读: 任务的生命周期由核心网（AMF/UDM）管理。当预设时间到达，AMF会更新小慧的UE上下文，不再包含此QoE任务。gNB侧也会将对应的会话标记为结束，但会“延迟删除”会话ID，以接收可能仍在途中的最后报告，确保数据颗粒归仓。

2.2.2 强制去激活 (Forced deactivation in NR)

4.6.3.2 Forced deactivation in NR …the management system sends the deactivateQMCJob operation to the UDM that propgates to the AMF/gNB.

  • 技术解读: 老王通过MnS接口发送deactivateQMCJob操作，指令经由UDM到达AMF。AMF会通过UE CONTEXT MODIFICATION REQUEST消息通知gNB。gNB收到后，会向UE发送RRCReconfiguration信令，其中包含measConfigAppLayer设置为“丢弃”或类似的指令，来终止UE侧的测量。

2.2.3 记录会话的自然终结 (Deactivation of recording session in NR)

4.6.3.3 Deactivation of recording session in NR Regardless of whether the pre-set time has elapsed or not, the recording session continues to be active until the session for the application is ended.

这条“黄金法则”贯穿3G、4G、5G，始终不变。它强调了以应用会话为准的数据完整性原则，是QoE测量设计的核心理念之一。

FAQ环节

Q1：5G的NG接口切换与4G的X2/S1切换，在传递QoE上下文方面有什么本质不同？ A1：本质的不同在于AMF角色的中心化。在4G中，高效的X2切换是eNB之间的“点对点”交互，MME不直接参与上下文传递。只有在X2不可用时，才会回退到需要MME深度参与的S1切换。而在5G的NG切换（特指X2n接口不可用的场景）中，AMF始终是切换流程的中心协调者。所有的切换请求和上下文传递都必须经过AMF。这种设计简化了gNB之间的接口依赖，使得网络拓扑管理更简单，但也对AMF的处理能力和可靠性提出了更高要求。QoE上下文作为UE上下文的一部分，其传递路径也因此变得更为统一和标准化。

Q2：“源到目标透明容器”为什么对AMF是“透明”的？这样做有什么好处？ A2：AMF对其“透明”，意味着AMF在转发这个容器时，不需要解析其内部的具体内容。它只把它当作一个需要从源gNB原封不动搬运到目标gNB的“黑盒子”。好处主要有两点：

  1. 解耦与可扩展性: AMF的功能被严格限定在移动性管理和会话管理，它不需要去理解和处理应用层的QoE测量参数。未来如果QoE规范增加了新的参数，只需要gNB进行升级即可，AMF无需任何改动，这大大增强了系统的演进能力。
  2. 效率: AMF无需进行复杂的解析和处理，只需进行简单的拷贝和转发，这降低了AMF的处理开销，保证了切换流程的高效性。

Q3：如果在切换过程中，目标gNB因为资源不足等原因，决定不继续QoE测量任务，会发生什么？ A3：这是一个很好的异常场景。目标gNB会在步骤3的决策阶段，决定不接纳QoE任务。它仍然会同意UE的切换（因为保障通信连续性是最高优先级），但在回复给AMF的HANDOVER REQUEST ACKNOWLEDGE消息中，它会通过特定的信元或省略QoE相关参数的方式，表明自己不会继续QoE任务。源gNB和AMF在收到这个响应后，会知道QoE任务在切换后已经终止。UE切换到目标gNB后，由于目标gNB不会再下发任何QoE相关的配置，UE侧的测量也会自然停止。

Q4：为什么强制去激活的指令需要经过UDM和AMF，而不是像管理驱动那样直接发给gNB？ A4：因为在信令驱动模式下，QoE任务的“主权”在核心网。任务的创建、修改和删除，都必须在用户数据的“事实源头”——UDM中进行。如果允许管理系统绕过核心网直接去gNB删除一个由核心网下发的任务，就会导致状态不一致：gNB上的任务被删了，但UDM和AMF的记录里还存在，下次UE移动到新的gNB，任务又会被重新激活。因此，必须遵循“谁创建，谁删除”的原则，保证整个系统状态的同步和一致性。

Q5：高铁场景下的切换非常频繁，这种复杂的上下文传递会不会影响切换成功率？ A5：影响极小。5G的NGAP协议和gNB的实现都为高速移动性场景做了深度优化。QoE上下文的数据量很小，在“透明容器”中只占很小一部分，相比于UE的无线承载、安全上下文等核心信息，其增加的信令开销微乎其微。整个切换流程被设计为在几十毫秒内完成。因此，携带QoE上下文并不会对高铁场景下的切换成功率和切换时延构成可感知的负面影响。这正是5G网络强大能力的体现。

关系图谱