51学通信

深度解析 3GPP TS 28.405：4.1 Management based activation in UTRAN (UTRAN中的管理驱动激活)

22分钟阅读

好的，这是系列文章的第四篇。我们将正式进入规范的核心章节——第四章，并首先深度解读4.1节，关于在3G网络（UTRAN）中，如何通过管理驱动的方式来激活QoE测量。

深度解析 3GPP TS 28.405：4.1 Management based activation in UTRAN (UTRAN中的管理驱动激活)

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“4.1 Management based activation in UTRAN”的核心章节，旨在为读者详细拆解在3G网络环境下，由网络管理侧发起的QoE测量任务，是如何一步步激活、执行、并在移动切换中保持连续，最终完成使命的全过程。

引言：当5G少女误入3G“桃花源”

我们的主角小慧，一位习惯了5G极速网络的数字原住民，在一次周末的郊野徒步中，来到了一片风景秀丽但信号覆盖较为偏远的“桃花源”。在这里，她的5G手机信号格悄然变成了“3G”。虽然略感失落，但她还是兴致勃勃地打开了“V-Stream”应用，想观看一段介绍当地风土人情的短视频。

与此同时，在千里之外的运营商网管中心，网络优化工程师老王正在关注这个著名旅游景区的网络状况。由于该区域地理位置特殊，目前主要由3G网络（UTRAN）提供覆盖。老王深知，在带宽有限的3G网络下保障视频业务的流畅度，对用户体验至关重要。因此，他早已通过域管理器（DM），针对该景区启动了一项**管理驱动的QoE测量收集（QMC）**任务。

小慧并不知道，她这次在3G网络下的视频播放行为，将成为老王网络优化工作中一份宝贵的数据样本。而TS 28.405的4.1章节，正是这次跨越时空的数据收集行动的详细执行剧本。本章，我们将跟随小慧的脚步，深入探索这套“经典”但依然重要的QoE激活机制。

1. 4.1.1 激活与上报：一探QoE任务的诞生之旅

这是整个管理驱动模式的核心流程。它描述了一个QoE测量任务从网管中心的指令，到最终在小慧手机APP上被激活的全过程。规范原文中的“Figure 4.1.1-1: QMC activation and reporting in UTRAN”以一张清晰的信令图，完美地诠释了这一旅程。我们不会重绘此图，但将严格按照其定义的13个步骤，进行逐一的深度解析。

1.1.1 核心流程拆解

步骤 1 & 2: 指令的下达 (NM → DM/EM → RNC)

  1. The NM sends activateAreaQMCJob to DM/EM that controls the impacted RNC(s), and includes the parameters: serviceType, areaScope, qoECollectionEntityAddress, pLMNTarget, qMCTarget, qoEReference and QMC configuration file.
  2. The DM/EM forwards activateAreaQMCJob to impacted RNC(s)…

这一切始于老王的操作。他在**网络管理器（NM, Network Manager）**的界面上，创建了一个名为activateAreaQMCJob的任务。

  • 场景演绎: 老王框选了“桃花源”景区的地理范围（areaScope），指定了监控的业务为DASH视频（serviceType），并设定了QoE数据上报的服务器地址，即MCE的地址（qoECollectionEntityAddress）。他还附上了一个详细的“调查问卷”——QMC配置文件（QMC configuration file），里面规定了需要APP测量的具体指标。
  • 技术解读: 这个高级指令首先发往域管理器/网元管理器（DM/EM），即“战区司令部”。DM/EM将其解析，并转发给管辖该景区的具体无线网络控制器（RNC）。RNC是3G网络的大脑，控制着多个基站（NodeB）。至此，QoE任务的前线指挥官——RNC，收到了作战指令。

步骤 3: RNC的“侦察”与等待

  1. The RNC checks for connections where the UE has the UE Application Layer Measurement Capability that match the criteria for serviceType in the activateAreaQMCJob.

收到指令后，RNC并不会盲目行动。它开始在其控制的所有通话和数据连接中，进行“侦察”。

  • 场景演绎: RNC像一个雷达，扫描着所有连接到它所管辖的基站上的手机。它的扫描目标是：那些手机是否向网络报告过自己具备“UE应用层测量能力（UE Application Layer Measurement Capability）”？
  • 技术解读: 这是一个至关重要的前提。UE必须在建立无线连接的早期阶段，就通过能力上报流程，告诉网络：“我这台设备以及安装的App，是支持3GPP QoE测量规范的”。如果一部手机没有这个能力，RNC就会直接忽略它，避免发送其无法理解的指令。当小慧的手机在3G网络下发起数据连接时，就已经完成了这个“身份报备”。

步骤 4 & 5: 精准激活 (RNC → UE → UE Application)

  1. When a connection is found…, the RNC start a UE request session …, sends the message RRCConnectionReconfiguration to the UE, and includes the following: serviceType, qoEReference and QMC configuration file.
  2. The access stratum in the UE sends the AT command +CAPPLEVMC to application level and includes the following: serviceType, qoEReference and QMC configuration file.

RNC的雷达锁定了目标——小慧的手机正在景区内，准备播放视频，且具备QoE测量能力。激活的时刻到来了。

  • 场景演绎: RNC为小慧的手机创建了一个专属的UE请求会话（UE request session）。随后，它向小慧的手机发送了一条**RRC连接重配置（RRCConnectionReconfiguration）**信令。这条信令中，悄悄地携带了QoE任务的关键信息。
  • 技术解读:
    • 步骤4: RNC通过这条RRC信令，将“作战指令”的精简版（业务类型、任务参考号、配置文件）下发给UE的通信模组（即接入层 Access Stratum）。
    • 步骤5: 通信模组收到并解析了这条特殊的RRC信令后，它并不能自己去测量视频卡顿，因为它只是个“通信兵”。它需要通知“潜伏”在操作系统上层的“V-Stream”这个“情报员”。它使用的通信方式，就是AT指令。模组会发送一条类似+CAPPLEVMC的指令，将从RRC信令中获得的任务信息，原封不动地传递给了手机的应用层（Application Level）。

步骤 6, 7 & 8: 应用的响应与会话的建立

  1. When the application in the serviceType starts, the QMC is initiated.
  2. The application layer sends the AT command +CAPPLEVMR including a recording session indication that a session has started to the access stratum.
  3. The UE sends the message MeasurementReport including the recording session indication to the RNC.

“V-Stream”应用收到了AT指令，知道了自己的“潜伏”任务已被激活。

  • 场景演绎: 小慧点击了视频的播放按钮。就在此时，“V-Stream”应用内部启动了QoE测量功能，并创建了一个记录会话（Recording Session）。这标志着实际的测量工作正式开始。
  • 技术解读:
    • 步骤7: App为了告知网络“我已开始工作”，会反向调用另一条AT指令+CAPPLEVMR，通知底层的通信模组。
    • 步骤8: 通信模组收到这条AT指令后，会立刻向RNC发送一条**测量报告（MeasurementReport）**消息。这条消息的内容很简单，就是一个“会话已开始”的指示。

步骤 9: RNC向上汇报

  1. The RNC sends a notification including the recording session indication to the NM.

RNC收到了来自小慧手机的“开工”报告，它需要向上级汇报。

  • 场景演绎: RNC向老王的网管系统（NM）发送了一个通知（Notification），报告：“目标已捕获，QoE记录会话已在用户XXX的手机上启动”。老王在自己的监控大屏上，看到了活跃的QoE会话数量加了一。
  • 技术解读: 这一步确保了整个监控系统的状态同步，让运维人员实时了解任务的执行情况。

步骤 10, 11, 12 & 13: 数据的收集与上报

  1. When the QMC is completed, the recorded information is collected in a QMC report, including qoEReference and recordingSessionId.
  2. The application layer sends the AT command +CAPPLEVMR including qoEReference and the QMC report to the access stratum.
  3. The UE sends the message MeasurementReport including qoEReference and the QMC report to the RNC.
  4. The RNC sends the QMC report to the MCE associated to the qoEReference.

小慧的视频播放结束了，或者在播放过程中触发了上报条件（如发生了一次卡顿）。

  • 场景演绎: “V-Stream”应用将这段时间记录的所有QoE数据（如初始缓冲了多久、有没有卡顿等）打包成一份QMC报告。
  • 技术解读:
    • 步骤11: App再次通过+CAPPLEVMR AT指令，将这份打包好的QMC报告，连同任务参考号（qoEReference），交给了底层的通信模组。
    • 步骤12: 通信模组将这份报告封装在一条MeasurementReport消息中，发送给了RNC。
    • 步骤13: RNC收到这份沉甸甸的数据报告后，并不做解析。它像一个忠实的“邮差”，根据报告中的qoEReference找到与之关联的MCE地址，然后将报告原封不动地转发给“情报分析中心”MCE。至此，一份来自小慧手机的真实体验数据，成功抵达了目的地。

2. 4.1.2 移动中的QoE：切换场景下的处理

小慧在景区内边走边看视频，她的手机不可避免地会发生切换（Handover）。如果因为切换导致QoE测量中断，那收集到的数据就是不完整的。因此，规范对切换场景做了周密的规定。

2.1.1 小范围移动：RNC内部切换

4.1.2.1 Handover between cells within an RNC If the mobile is inside the measurement area after the handover, the RNC sends in an indication that the UE is inside the measurement area in the RRCConnectionReconfiguration message…

  • 场景演绎: 小慧从景区大门口走到了一个观景台，她的手机从一个基站（NodeB）切换到了另一个，但这两个基站都由同一个RNC控制。
  • 技术解读: 这是最简单的情况。因为RNC是这次切换的主导者，它完全清楚小慧的QoE测量任务上下文。在发送切换指令（同样是RRCConnectionReconfiguration消息）时，RNC会检查新的小区是否仍在老王设定的“桃花源”景区这个areaScope内。如果是，它会在切换信令中加入一个特殊指示，告诉UE：“切换后，你的QoE任务继续”。如果小慧走出了景区，切换信令中就不会有这个指示，UE的应用层收到通知后，就不会再继续上报数据。

2.1.2 大范围漫游：RNC之间的切换

4.1.2.2 Handover between RNCs

这是一个更复杂但常见的情景。规范中的“Figure 4.1.2.2-1: Handling of QMC activation in case of handover in UTRAN”详细描述了此流程。

  • 场景演绎: 小慧坐上了景区的观光车，从山南开到了山北。她的手机需要从一个RNC的控制范围，切换到另一个RNC的控制范围。我们称之为源RNC和目标RNC。
  • 技术解读:
    1. 信息传递: 源RNC在向目标RNC发起切换请求（HandoverRequest）时，不能只传递常规的无线参数。它必须把小慧正在进行的QoE测量任务的“案卷”也一并传递过去，包括areaScope, qoEReference, MCE地址等关键信息。
    2. 目标决策: 目标RNC收到这份特殊的切换请求后，会进行决策。它会检查切换的目标小区是否还在areaScope之内。如果它自己不支持QoE功能，或者新的小区不在测量区域内，它可能会拒绝继续这个QoE任务。如果条件满足，它会同意切换，并接管这个QoE任务。
    3. 无缝衔接: 一旦切换完成，目标RNC就成为了新的指挥官，负责接收小慧手机后续上报的QoE数据，并将其转发给正确的MCE。整个过程对小慧和她的“V-Stream”应用来说是透明的，QoE测量得以无缝地持续进行。

3. 4.1.3 任务的终结：去激活流程

任何任务都有结束的时候。规范定义了两种主要的去激活方式。

3.1.1 强制去激活

4.1.3.1 Forced deactivation in UTRAN …the management system sends the deactivateQMCJob operation to the RNC. …the RNC sends the MeasurementControl message with the DeactivateJob request to relevant UEs.

  • 场景演绎: 老王设定的监控时间到了，或者他发现收集的数据已经足够，决定提前结束任务。
  • 技术解读: 老王通过NM/DM下发deactivateQMCJob指令。RNC收到后，会向所有正在执行此任务的UE（比如小慧的手机）发送一条**测量控制（MeasurementControl）**消息，其中包含了DeactivateJob的请求。UE的应用层收到这个指令后，就会立刻停止测量和记录。

3.1.2 记录会话的自然结束

4.1.3.2 Deactivation of recording session in UTRAN 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.

这是一个非常重要的细节，体现了规范设计的完备性。

  • 场景演绎: 假设老王设定的任务时间是下午2点到4点。小慧在3点59分开始看一段5分钟的视频。到了4点整，网络请求会话（Network Request Session）按时结束了。那么，小慧手机上的QoE测量会立刻停止吗？
  • 技术解读: 答案是不会。规范指出，记录会话（Recording Session）的生命周期与应用会话绑定。这意味着，即使网络侧的任务已经“到点下班”，小慧的“V-Stream”应用仍然会坚持把这5分钟的视频播放过程完整地记录下来，直到播放结束，然后上报最后一次数据。这确保了每一份用户体验样本的完整性，避免了数据被“拦腰斩断”。

FAQ环节

Q1：在3G UTRAN中，RNC是如何知道UE的“应用层测量能力”的？ A1：这是通过UE能力查询流程实现的。当UE首次接入网络或其能力发生变化时，网络（RNC）可以发起一个能力查询过程，向UE请求其支持的各种功能列表。UE的回复中会包含一个特定的信息元素（IE），表明它是否支持3GPP定义的QoE测量。这个信息会被RNC缓存下来，用于后续判断是否对该UE下发QoE任务。

Q2：AT指令在整个流程中扮演了什么角色？它是不是唯一的实现方式？ A2：AT指令是3GPP规范中定义的、用于应用处理器（AP）和通信处理器（CP，即基带模组）之间通信的“标准语言”。在这个流程中，它扮演了至关重要的**“桥梁”**角色，将无线空口信令（RRC）中的控制信息，准确地传递给上层APP，并反向将APP的报告传递给底层。虽然在现代智能手机操作系统中，也可能存在其他厂商自定义的API或IPC（进程间通信）机制来完成这个任务，但AT指令是3GPP定义的标准化接口，具有最好的通用性和兼容性。

Q3：为什么在RNC间的切换中，需要把QoE的上下文信息（如areaScope）都传递一遍？ A3：因为RNC是3G网络中相对独立的“诸侯”，每个RNC只了解自己辖区内的情况。源RNC和目标RNC之间没有共享的实时数据库来存放QoE任务的上下文。因此，在切换这个“权力交接”的时刻，唯一的办法就是通过切换信令，将与该UE相关的所有“案卷材料”完整地、显式地从源RNC递交给目标RNC。这确保了目标RNC在接手后，拥有足够的信息来决定是否以及如何继续这个QoE任务。

Q4：如果小慧在观看视频时，突然接到来电导致视频中断，QoE测量会发生什么？ A4：这是一个很好的实际场景问题。当电话呼入时，视频应用（V-Stream）会被置于后台或暂停。此时，应用会话（application session）暂停或终止，相应的，QoE的记录会话（Recording Session）也会暂停或结束。App可能会上报一次中断前的测量报告。当小慧挂断电话，回到App继续播放时，App会重新创建一个新的Recording Session，并向网络报告“会话开始”。这样，一次被中断的观看行为，在MCE侧会体现为两个独立的、但可以关联起来的QoE记录片段。

Q5：管理驱动的QoE测量，对RNC的性能有多大影响？ A5：影响是可控的。RNC需要增加的额外处理主要有几方面：1）解析和存储来自DM的QMCJob；2）在UE接入时检查其QoE能力；3）为满足条件的UE构造并发送带QoE参数的RRC信令；4）接收UE上报的MeasurementReport并进行转发。这些操作相对于RNC处理海量无线资源管理的核心功能来说，信令开销和计算负载都非常小。规范的设计考虑了这一点，尽量将复杂的QoE数据解析工作卸载给了MCE，RNC只做简单的判断和“邮差”式的转发，从而避免成为性能瓶颈。

关系图谱