51学通信

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

20分钟阅读

好的，这是系列文章的第五篇。我们继续深入第四章，解读4.2节，详细阐述在4G LTE网络中，管理驱动的QoE测量是如何实现的。这一章是理解现代移动网络QoE运维的基础。

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

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“4.2 Management based activation in LTE”的核心章节，旨在为读者深入剖析4G网络作为移动数据时代的中坚力量，是如何通过一套成熟的QoE测量激活与管理机制，来守护亿万用户的上网体验的。

引言：从3G的“温饱”到4G的“小康”

在上一篇文章中，我们跟随着小慧的脚步，在她信号不佳的“桃花源”景区，体验了一把3G UTRAN网络下的QoE测量。那是一次对“温饱”型网络体验的精细化度量。现在，故事翻开了新的一页。小慧结束了徒步，乘坐高铁返回繁华的都市。

当她抵达新建成的高铁南站时，手机信号早已满格，清晰的“4G+”标志预示着流畅的网络体验。在等车间隙，小慧习惯性地打开“V-Stream”应用，开始刷起了高清短视频。她不知道的是，这座人流密集的大型交通枢纽，正是网络优化工程师老王的重点保障区域。为了确保成千上万旅客拥有“小康”级别的视频体验，老王早已在此部署了针对4G LTE网络的管理驱动QoE测量任务。

从3G到4G，不仅仅是速率的飞跃，其网络架构和信令流程也发生了深刻的演进。核心的无线控制器（RNC）功能被“扁平化”地融入了基站（eNodeB）之中。那么，在LTE这个更高效、更扁平的架构下，QoE的测量“剧本”又将如何谱写？TS 28.405的4.2章节，为我们揭晓了答案。

1. 4.2.1 激活与上报：LTE环境下的QoE“集结号”

与UTRAN类似，本节的核心依然是描述一个QoE测量任务从创建到激活，再到数据上报的全过程。规范原文中的“Figure 4.2.1-1: QMC activation and reporting in LTE”是本节的灵魂，它描绘了一幅与3G相似但细节迥异的信令交互图。我们将沿着这张图的脉络，逐一解析这13个步骤。

1.1.1 核心流程拆解：从RNC到eNB的权力交接

步骤 1 & 2: 任务下发 (NM → DM/EM → eNB)

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

流程的起点与3G时代别无二致：老王在**网络管理器(NM)**上发起行动。

  • 场景演绎: 老王在管理平台上圈定了高铁南站的范围（areaScope），选择了DASH视频业务（serviceType），并配置了数据接收方MCE的地址（qoECollectionEntityAddress）等一系列参数。
  • 技术解读: 指令通过DM/EM下发。但这一次，指令的接收者不再是RNC，而是直接下达到了每一个覆盖高铁南站的eNB（演进型NodeB）。这是4G扁平化架构最直观的体现——eNB不仅是“一线士兵”，更兼具了部分“连排级指挥官”的智能，可以直接接收并执行来自司令部（DM/EM）的任务。

步骤 3: eNB的“精准识别”

  1. The eNB checks for connections where the UE has the UE capability that match the criteria for serviceType in the activateAreaQMCJob.

eNB收到了activateAreaQMCJob指令，它开始在自己服务的海量用户中寻找目标。

  • 场景演绎: 当小慧的手机连接到高铁站的4G网络时，eNB会检查她的“能力档案”。这个档案里记录了她的手机是否支持针对特定业务的QoE测量。
  • 技术解读: 这里的UE能力与3G时代有所不同，定义得更加具体。规范 (TS 36.331)中定义了QoE-MeasReport-capability（针对流媒体业务）和QoE-MTSI-MeasReport-capability（针对MTSI业务）。eNB会检查UE上报的这些具体能力标志，确保“好钢用在刀刃上”，只对支持并使用了目标业务的UE下发指令。

步骤 4 & 5: RRC信令激活

  1. When a connection is found…, the eNB starts 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…

eNB锁定了正在刷视频的小慧。激活流程启动。

  • 场景演绎: eNB为小慧创建了一个UE请求会话，并通过一条**RRC连接重配置（RRCConnectionReconfiguration）**信令，将QoE任务的“入场券”发给了小慧的手机。手机底层收到后，立即通过+CAPPLEVMC AT指令通知上层的“V-Stream”应用。
  • 技术解读: 这个过程在宏观上看与3G非常相似，都是通过RRC信令下发配置，再通过AT指令通知APP。但在RRC信令的内部结构上，4G LTE使用了更专有的信息元素（IE）来承载QoE配置，使其与其他的无线测量配置（如切换测量）区分得更清晰，体现了协议设计的演进。

步骤 6, 7 & 8: 应用响应与状态上报

  1. When the application in the serviceType starts, the QMC is initiated.
  2. The application layer sends the AT command +CAPPLEVMR…
  3. The UE sends the message MeasReportAppLayer including the recording session indication to the eNB.

“V-Stream”应用收到了指令，在小慧点击播放时，启动了记录会话（Recording Session）。

  • 场景演绎: App启动测量后，立即通知底层模组“我已开工”。底层模组则向eNB汇报，表明记录会话已经开始。
  • 技术解读: 关键区别出现在步骤8。在LTE中，UE用于上报应用层状态（如会话开始）和后续QoE数据的信令，有了一个专门的名字——MeasReportAppLayer（应用层测量报告）。而在3G UTRAN中，使用的是通用的MeasurementReport。这种命名的特化，表明在LTE协议设计中，应用层信息的传递被提升到了一个更正式、更专门的位置。

步骤 9: eNB向上级汇报

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

eNB收到了MeasReportAppLayer中的“开工”指示，它随即向老王的网管系统（NM）发送了一个通知。这个步骤与3G一致，确保了运维侧的状态可见性。

步骤 10 - 13: QoE数据的封装与旅程

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

视频播放结束，或者一次卡顿事件触发了上报。

  • 场景演绎: “V-Stream”应用将收集到的QoE指标打包成QMC报告，通过AT指令交给底层模组。
  • 技术解读:
    • 步骤12: 模组将这份报告封装在专门的MeasReportAppLayer消息中，发送给eNB。
    • 步骤13: eNB扮演“邮差”角色，它从信令中解析出qoEReference，并根据这个ID找到预存的MCE地址，然后将完整的QMC报告转发给MCE。这个“接收-转发”的逻辑与RNC是一致的，保证了无线网元本身的轻量化，避免了复杂的应用层数据解析。

2. 4.2.2 LTE网络中的无缝切换：保障数据的连续性

在高铁南站这样庞大而复杂的室内环境中，小慧从候车厅走到检票口，再到站台，手机必然会经历多次小区切换。TS 28.405对LTE中的切换处理同样做了详细规定。

2.2.1 eNB内部切换 (Intra-eNB Handover)

4.2.2.1 Handover between cells within an eNB When handover is made and no Recording session id is provided, the measurement area is checked.

  • 场景演绎: 小慧只是在候车厅里从A区走到了B区，手机切换的小区都属于同一个物理eNB设备管理。
  • 技术解读: 这是最简单的情况。因为整个过程都在eNB内部完成，eNB完全掌握小慧的QoE任务上下文。它只需在切换时判断新的小区是否仍在areaScope（高铁南站）内，然后决定是否继续该任务。这个过程对UE是完全透明的。

2.2.2 eNB之间的切换 (Inter-eNB Handover)

4.2.2.2 Handover between eNBs

这是保障QoE数据连续性的关键和难点。规范中的“Figure 4.2.2.2-1: Handling of QMC activation in case of handover in LTE”详细描述了此流程。

  • 场景演绎: 小慧从候车厅走到了地下换乘层，手机需要从A eNB切换到B eNB。A是源eNB，B是目标eNB。
  • 技术解读:
    1. 上下文传递 (Context Transfer): 源eNB通过X2接口（eNB之间的直接接口）向目标eNB发送HandoverRequest消息。为了让QoE任务不中断，这条消息中必须包含一个“透明容器”，里面装着小慧的QoE“案卷”，包括areaScope, qoEReference, MCE地址等。
    2. 目标eNB决策: 目标eNB收到请求后，会检查切换的目标小区是否仍在areaScope内。如果满足条件，它会在HandoverRequestAcknowledge消息中同意接管，并将QoE上下文信息存储起来。
    3. RRC信令执行: 切换流程通过RRC信令在UE侧执行完毕后，小慧的手机就正式由目标eNB提供服务。
    4. 无缝接管: 此后，小慧手机上报的所有MeasReportAppLayer消息都将发送给目标eNB。目标eNB会根据它接管过来的上下文信息，准确地将QoE报告转发给正确的MCE。通过X2接口上的上下文传递，LTE网络实现了跨eNB的QoE任务无缝切换。

3. 4.2.3 任务的终止：LTE中的谢幕方式

3.3.1 强制去激活

4.2.3.1 Forced deactivation …the eNB sends the RRCConnectionReconfiguration message … including measConfigAppLayer set to discard application layer measurement report information…

  • 场景演绎: 高铁站的高峰期已过，老王决定结束这次QoE监控。
  • 技术解读: 老王下发deactivateQMCJob指令。eNB收到后，会向小慧等正在执行任务的UE发送一条RRCConnectionReconfiguration消息。这里的实现方式比3G更“巧妙”，它不是发送一个独立的“停止”命令，而是在RRC重配置消息中，将一个名为measConfigAppLayer的字段设置为“丢弃（discard）”。UE的底层模组收到这个指示后，就会通过AT指令通知APP停止测量。

3.3.2 记录会话的自然终结

4.2.3.2 Deactivation of recording session 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 UTRAN完全一致，再次体现了规范设计对数据完整性的高度重视。即使网络侧的任务到期，只要小慧的视频还没看完，APP就会继续记录，直到应用会话结束，确保每一段用户体验都被完整地捕捉下来。

FAQ环节

Q1：相比3G UTRAN，LTE中eNB在QoE测量流程中扮演的角色有什么本质不同？ A1：本质的不同在于权责的集中。在UTRAN中，RNC是“大脑”，负责管理和决策，而NodeB是“四肢”，主要负责空口收发。QoE任务的管理和切换决策都在RNC层面。而在LTE的扁平化架构中，eNB集成了RNC的大部分功能，它既是“大脑”也是“四肢”。eNB直接接收网管指令，独立进行UE能力判断、任务激活和切换决策。这种变化使得LTE网络的信令路径更短，处理效率更高，但也对eNB的处理能力提出了更高的要求。

Q2：MeasReportAppLayer相比UTRAN的MeasurementReport，这个“AppLayer”的后缀有什么深层含义？ A2：这个后缀体现了协议设计的演进和明确化。在3G时代，MeasurementReport是一个非常通用的消息容器，可以用来上报各种无线测量结果（如信号强度、质量等），QoE数据只是搭了个“便车”。而在LTE时代，随着移动数据业务的爆发，应用层信息的传递变得越来越重要。因此，协议专门设计了MeasReportAppLayer这样一个消息，从命名上就清晰地表明其用途是“专门用于传输应用层信息”，使其与传统的物理层/无线层测量报告在逻辑上和处理上都分离开来，这是一种更清晰、更具扩展性的设计。

Q3：LTE的Inter-eNB切换主要依赖X2接口。如果两个eNB之间没有建立X2接口，QoE任务还能连续吗？ A3：这是一个非常实际的工程问题。如果eNB间没有X2接口，切换就需要通过核心网MME来完成，这被称为S1切换。在这种情况下，QoE的上下文信息就无法通过X2接口在eNB间直接传递。它需要源eNB通过S1AP消息上报给MME，再由MME通过另一条S1AP消息下发给目标eNB。虽然3GPP也定义了在S1AP消息中承载这类“透明容器”的能力，但流程会更长、时延更大。TS 28.405本章节的流程图主要展示了更高效的X2切换场景。S1切换下的QoE连续性，依赖于核心网元（MME）的正确处理和转发。

Q4：eNB如何知道小慧的手机正在使用DASH视频业务，而不是在浏览网页？ A4：eNB本身通常无法直接通过无线信号解析出用户正在使用的具体应用。它判断的依据主要有两点：1）UE能力：UE上报了支持DASH流媒体的QoE测量能力。2）业务承载：UE当前激活的数据承载（Bearer）的QCI（QoS Class Identifier）等参数，可能暗示了正在进行的是流媒体类型的业务。在更高级的5G网络中，可以通过核心网（PCF/SMF）的策略控制，将更精细的应用信息告知gNB。但在LTE的管理驱动模式下，eNB的判断相对宏观，它会给所有具备能力且正在进行数据传输的用户下发配置，最终由UE侧的APP根据自己是否是DASH业务来决定是否启动测量，这是一种网络与终端协同的判断机制。

Q5：管理驱动的QoE测量会影响我的正常网速吗？ A5：几乎不会。QoE测量对用户体验的影响被设计为最小化。首先，激活和去激活的RRC信令本身非常小，属于正常的网络控制信令，对数据传输没有影响。其次，QoE报告的上报，虽然会占用极少的上行带宽，但报告本身的数据量很小（通常为几百字节），且上报频率受到网络侧的严格控制（例如，只在卡顿时或周期性地上报）。相比于您观看高清视频所消耗的巨大下行带宽，这点上行信令开销完全可以忽略不计，不会对您的网速构成可感知的冲击。

关系图谱