51学通信

深度解析 3GPP TS 28.405：4.3 Signalling based activation in UTRAN (UTRAN中的信令驱动激活)

20分钟阅读

好的，这是系列文章的第六篇。我们将进入一个全新的领域：信令驱动激活。本篇将聚焦于4.3节，详细解析在3G UTRAN网络中，如何针对单个特定用户，通过核心网信令来精准启动QoE测量任务。

深度解析 3GPP TS 28.405：4.3 Signalling based activation in UTRAN (UTRAN中的信令驱动激活)

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“4.3 Signalling based activation in UTRAN”的核心章节，旨在为读者揭示一种与管理驱动截然不同的QoE激活模式。我们将探索核心网是如何扮演“幕后推手”，将测量任务像“密令”一样精准植入特定用户的通信流程之中的。

引言：从“广撒网”到“精确制导”

在前几篇文章中，我们跟随网络优化工程师老王，体验了管理驱动的QoE测量。无论是3G景区的“温饱”保障，还是4G高铁站的“小康”监控，其核心逻辑都是**“对地观测”**——在特定区域撒下一张大网，捕获所有符合条件用户的体验数据。这种“广撒网”的方式，非常适合宏观地了解一个区域的整体网络健康度。

然而，新的挑战出现了。我们的主角小慧，作为“V-Stream”应用的忠实用户，最近升级成了VIP会员。她向客服投诉，称自己每天下午在学校图书馆自习时，观看教学视频的体验很差，频繁卡顿，严重影响学习效率。但奇怪的是，图书馆里其他普通用户的网络体验似乎是正常的。

这个投诉工单，很快转到了老王的案头。此时，如果再使用管理驱动的方式对整个图书馆区域进行监控，不仅效率低下，也无法解释为何只有小慧的体验出了问题。老王需要一把“手术刀”，或者说一枚“精确制导导弹”，能够只针对小慧这一个用户，在她特定的时间、特定的地点、使用特定业务时，进行一次深度的QoE“探查”。

这，就是信令驱动激活（Signalling based activation）模式的用武之地。它不再对地，而是对人。TS 28.405的4.3章节，为我们详细描绘了在3G UTRAN网络中，这枚“制导导弹”是如何从发射到命中目标的完整弹道。

1. 4.3.1 激活流程：一场由核心网主导的“秘密行动”

信令驱动激活的核心，在于**核心网（Core Network）**的深度参与。整个激活过程不再由无线侧的RNC唱主角，而是由用户数据的管理者——**HSS（归属签约用户服务器）**和会话/移动性的管理者——MSC Server/SGSN来主导。

规范中并没有为这一节提供独立的流程图，但其描述的流程与第15页的图（尽管标题仍为activateAreaQMCJob，但流程涉及HSS，是信令驱动的典型特征）高度相关。我们将结合规范文本，分步解析这场“秘密行动”。

1.1.1 核心流程拆解

步骤 1 & 2: 锁定目标 (NM → DM/EM → HSS)

In Signalling based activation, the QoE measurement collection is sent to the UE from the OAM via CN. The messages from EMS propagated to HSS, MSE Server/SGSN and RNC. QoE measurement collection activation request is propagated to UE. When HSS activates the QoE measurement collection for a job…

与管理驱动不同，这次老王在网络管理器（NM）上创建任务时，areaScope（区域范围）不再是必填项，取而代之的是一个至关重要的参数：Individual UE Id，即小慧的唯一身份标识（如IMSI）。

  • 场景演绎: 老王在他的系统里，创建了一个针对小慧IMSI的QoE测量任务。这个指令通过DM/EM，并没有直接发给基站控制器RNC，而是发往了移动网络的心脏——核心网，第一站就是HSS (Home Subscriber Server)。
  • 技术解读: HSS是运营商存放所有用户签约数据和档案的中央数据库。老王的这个操作，相当于给小慧的“数字档案”里，贴上了一张“特殊便签”，上面写着：“此用户需要进行VR业务的QoE测量，具体测量要求见附件（QMC配置文件）”。

步骤 3 & 4: 档案的下发与“潜伏”

When HSS activates the QoE measurement collection for a job, the MSC Server/SGSN can send the QoE measurement collection to the UE through RNC…

HSS自己并不会直接与UE通信，它需要一个“外勤特工”来传递信息。这个特工就是MSC Server（移动交换中心服务器，负责电路域业务）或SGSN（服务GPRS支持节点，负责分组域业务）。

  • 场景演绎: 小慧在图书馆打开手机，她的手机会向网络发起位置更新（Location Update）流程，告诉网络“我在这里”。这个信令会触发MSC/SGSN向HSS请求或更新小慧的用户数据。
  • 技术解读: 就在这次正常的数据同步过程中，HSS会将那张“特殊便签”——即QoE测量任务的配置信息——通过**Insert Subscriber Data**（插入签约用户数据）这样的操作，下发给当前为小慧提供服务的MSC/SGSN。现在，MSC/SGSN的内存里，也存有了关于小慧的QoE“密令”。它进入了“潜伏”状态，等待合适的时机。

步骤 5: “密令”的传递 (MSC Server/SGSN → RNC)

…the MSC Server/SGSN can send the QoE measurement collection to the UE through RNC, the following configuration parameters shall be included in the message: serviceType, areaScope, qoECollectionEntityAddress, pLMNTarget, qoETarget, qoEReference and QMC configuration file.

时机很快就来了。小慧在图书馆打开了“V-Stream”应用，准备看视频。她的手机需要建立一条数据连接。

  • 场景演绎: 在为小慧建立数据业务通道的过程中，MSC/SGSN发现了内存中潜伏的“密令”。于是，它在与RNC的交互信令中，悄悄地加入了一个特殊指令。在3GPP规范体系中，这个指令通常封装在**CN INVOKE TRACE（核心网调用跟踪）**或类似的RANAP信令中。
  • 技术解读: 这条信令将完整的QoE任务配置（包括serviceType、MCE地址、QMC config file等）从核心网传递给了无线接入网的RNC。至此，RNC才第一次知道，自己需要对小慧这个特定的用户进行QoE测量。与管理驱动模式下RNC是任务的“始作俑者”不同，在这里，RNC只是一个忠实的“信使”和“执行者”。

步骤 6 - 16: 熟悉的激活与上报流程

从RNC收到核心网指令的那一刻起，后续的流程就与我们在4.1节中学习的管理驱动模式几乎完全一样了。

  • RNC checks if the UE capability matches the criteria… (RNC检查UE能力)
  • RNC starts a UE request session … sends the message RRCConnectionReconfiguration to the UE… (RNC通过RRC信令激活UE)
  • The access stratum in the UE sends the AT command … to application level… (UE底层通过AT指令通知APP)
  • The application starts … sends the AT command … that a session has started… (APP响应并报告会话开始)
  • … (后续的数据上报、RNC转发给MCE等)
  • 场景演绎: RNC收到了来自核心网的指令后，立刻检查小慧的手机是否具备QoE测量能力。确认无误后，它通过RRCConnectionReconfiguration信令将任务下发。小慧手机的底层模组收到后，通过AT指令唤醒了“V-Stream”应用。当小慧开始播放视频时，App启动记录会话，并通过底层信令向RNC报告，RNC再将数据转发给MCE。
  • 技术解读: 这一系列的激活、上报、转发流程，其底层的RRC信令、AT指令、MeasurementReport消息都与管理驱动模式完全复用。这体现了3GPP规范设计的模块化和可重用性原则。无论QoE任务的源头是来自网管的“区域广播”，还是来自核心网的“单点密令”，一旦任务抵达RNC，其后续在无线侧的执行流程都是标准化的。

2. 4.3.2 切换处理：复用成熟的上下文传递机制

See clause 4.1.2.

规范在本节给出了一个清晰的指引：关于信令驱动激活模式下的切换处理，请直接参考4.1.2节（即管理驱动模式下的切换处理）。

  • 技术解读: 为什么可以直接复用？因为切换的本质是UE上下文（UE Context）的迁移。这个上下文中包含了UE的身份、安全信息、无线配置、业务承载等所有信息。QoE测量任务的配置，一旦被RNC激活并为UE创建了UE request session，它就成为了这个UE上下文的一部分。
  • 无论是RNC内部切换，还是跨RNC的切换，切换流程的核心都是将这个UE上下文从源小区/源RNC，安全完整地迁移到目标小区/目标RNC。QoE任务的“案卷”就存放在这个上下文中。因此，管理驱动模式下那套成熟的、通过HandoverRequest信令传递QoE上下文的机制，对于信令驱动模式是完全适用的。目标RNC并不关心这个QoE任务最初是如何发起的，它只需要从源RNC那里接收到完整的上下文，就可以无缝地接管这个任务。

3. 4.3.3 任务的终结：指令的撤销与会话的自然凋亡

3.3.1 预设时间到达 (Pre-set time has elapsed in UTRAN)

When the pre-set time is elapsed, the HSS or SGSN and the RNC sets the network request session to ended, but do not delete the UE request session id…

  • 场景演绎: 老王在创建任务时，设定了监控时间为下午2点到5点。到了5点整，任务自动结束。
  • 技术解读: 任务的生命周期管理主要在HSS或MSC/SGSN层面进行。当计时器到期，这些核心网元会标记该任务结束，并且在后续的用户数据同步或会话建立中，不再向RNC下发这个QoE任务配置。对于已经激活的RNC，它也会将对应的Network/UE request session标记为结束。但同样，为了保证数据完整性，它不会立即删除会话ID，而是会等待可能仍在途中的最后一份QoE报告。

3.3.2 强制去激活 (Forced deactivation in UTRAN)

…the management system sends the deactivateQoEJob operation to the HSS or SGSN, that propagate it to the RNC.

  • 场景演绎: 下午4点，老王已经从小慧手机上报的数据中发现了问题的蛛丝马迹，决定提前结束监控。
  • 技术解读: 老王通过NM/DM下发deactivateQoEJob指令，并指定小慧的IMSI。这次，指令同样是发往HSS或SGSN。核心网元收到后，会立即“撤销”在小慧档案里贴的那张“特殊便签”，并主动通知当前为小慧服务的RNC终止该任务。RNC收到指令后，执行与管理驱动模式下相同的去激活流程，即通过MeasurementControl消息通知UE停止测量。

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

See clause 4.1.3.3.

这里再次引用了之前的条款。其核心思想不变：应用会话的完整性优先。无论网络侧的任务是因为超时还是被强制终止，只要小慧的视频还在播放，App就会坚持完成这次播放过程的记录和上报，善始善善终。

FAQ环节

Q1：信令驱动激活相比管理驱动，最大的优势和劣势是什么？ A1：最大的优势是精准性和灵活性。它可以针对单个用户（如VIP、投诉用户）发起测量，不受地理位置限制，只要用户在网络内，就可以被追踪。这对于个案问题定位、VIP用户保障、新业务白名单测试等场景至关重要。最大的劣势是它对核心网的依赖更强，流程更长，涉及的网元更多（NM → DM → HSS → MSC/SGSN → RNC → UE），任何一个环节出问题都可能导致激活失败。同时，它不适合进行大范围、普遍性的网络质量监控。

Q2：HSS在信令驱动激活中扮演了什么关键角色？ A2：HSS是信令驱动激活的**“源头”和“档案库”**。它将来自网管的、非实时的管理指令，转化为了可以附着在用户身份档案上的、半永久性的“特殊属性”。当用户在网络中移动和发起业务（如位置更新）时，HSS通过标准的3GPP接口（如MAP或Diameter）将这个“特殊属性”动态地“注入”到服务该用户的核心网节点（MSC/SGSN）中，从而触发后续的激活流程。没有HSS作为用户数据的集中管理者，这种跨越时空的精准任务下发就无法实现。

Q3：为什么从核心网发往RNC的指令会使用CN INVOKE TRACE（核心网调用跟踪）这样的信令？“Trace”是什么意思？ A3：“Trace”在这里的含义是“追踪”或“跟踪”。在电信网络运维中，“Trace”是一个非常重要的功能，用于对特定用户或特定业务的信令流程和数据包进行端到端的详细记录，以供故障排查和性能分析。QoE测量本质上也是一种对用户体验的深度“追踪”。因此，3GPP规范巧妙地复用了“Trace”功能的信令框架来承载QoE的激活指令。这样做的好处是无需再定义一套全新的、从核心网到无线网的信令接口，降低了协议的复杂性。

Q4：如果老王为小慧激活了一个信令驱动任务，但小慧当时手机处于关机状态，会发生什么？ A4：任务不会丢失。QoE测量任务的配置信息会“静态地”存储在HSS中小慧的用户档案里。当小慧下次开机，她的手机会执行附着（Attach）和位置更新（Location Update）流程。正是在这个流程中，MSC/SGSN会从HSS同步最新的用户档案，从而获取到这个QoE任务配置。然后，只要小慧开始使用目标业务（如看视频），激活流程就会被触发。这种机制确保了任务下发的可靠性，不受用户暂时离线的状态影响。

Q5：信令驱动激活是否只适用于3G UTRAN？在4G和5G网络中是怎样的？ A5：不是的。信令驱动激活是一种通用的思想，在4G LTE和5G NR网络中有其对应的、更高效的实现。在4G中，HSS会将任务下发给MME（移动性管理实体）；在5G中，UDM（统一数据管理）会将任务下发给AMF（接入与移动性管理功能）。核心网“注入”任务给无线网的接口也相应地演进为S1AP（4G）和NGAP（5G）。虽然具体的网元和协议名称变了，但“由核心网用户数据中心发起，经移动性管理节点传递，最终在无线侧激活UE”这一核心逻辑是一脉相承的。我们将在后续章节详细解读LTE和NR中的信令驱动流程。

关系图谱