51学通信

深度解析 3GPP TS 28.405：第一章 Scope (范围) & 第二章 References (参考文献)

24分钟阅读

好的，我们马上开始对3GPP TS 28.405规范进行逐章拆解。

这是系列文章的第二篇，将聚焦于规范的第一章 (Scope) 和 第二章 (References)。由于这两章内容较为简短，根据指令要求，我们将它们合并在一篇文章中进行深度解读，并为后续章节的学习打下坚实的术语和背景基础。

深度解析 3GPP TS 28.405：第一章 Scope (范围) & 第二章 References (参考文献)

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“Chapter 1 Scope”和“Chapter 2 References”的核心章节，旨在为读者清晰界定本规范的技术边界、核心任务，并梳理其在庞大的3GPP规范体系中的位置。

引言：为极致体验划定蓝图

在上一篇的概览中，我们认识了5G冲浪达人小慧，并了解了TS 28.405规范如何像一个幕后导演，默默地指挥着网络和终端，以保障她的最终用户体验（QoE）。从本篇文章开始，我们将手持放大镜，逐一审视这位“导演”手中的剧本——也就是规范的每一个章节。

今天，我们的焦点是剧本的开篇：范围（Scope）和参考文献（References）。

这或许是任何技术规范中最容易被一览而过的部分，但对于真正的技术专家而言，它们恰恰是理解一份规范灵魂的钥匙。Scope章节定义了规范的“权力边界”——它明确了自己做什么，不做什么。而References章节则描绘了它的“社交网络”——它依赖哪些“朋友”（其他规范）的支撑，又为哪些后续工作提供了基础。

为了更好地理解这一点，我们为小慧设定一个新场景：她所钟爱的视频App“V-Stream”即将上线一项名为“沉浸式VR音乐会”的新功能，这对网络体验提出了前所未有的挑战。作为合作方，运营商需要在新功能上线前，精准评估并保障其在5G网络下的QoE。现在，让我们看看TS 28.405的第一、二章，是如何为这次行动划定清晰蓝图的。

1. 第一章 Scope (范围)：明确QoE测量的核心任务与边界

Scope章节虽然简短，但字字珠玑，它精确地定义了本规范的核心工作。

1.1 核心功能：定义QoE收集的“方法论”

The present document addresses the mechanisms used for the function Quality of Experience (QoE) measurement collection in 3GPP networks. The measurements that are collected are DASH, MTSI and Virtual Reality (VR) (see TS 26.118) measurements.

这段话是Scope的开篇，也是整篇规范的基石。让我们逐一拆解其中的关键词：

  • “mechanisms used for the function”: 这是理解本规范定位的关键。它强调了规范内容是**“机制”，也就是一套流程、方法和协议。它并非要去发明或定义具体的QoE指标（比如“视频卡顿率”到底如何计算），而是要回答一个管理层面的问题：“如何让终端上的应用程序去测量这些指标，并如何**将测量结果安全可靠地送回网络侧？”。它是一套操作手册，而非一本理论教科书。

  • “QoE measurement collection”: 再次强调了目标是收集**体验质量（QoE）**数据。这与网络层的服务质量（QoS）有着本质区别。网络可以保障10ms的低时延（QoS），但小慧在VR音乐会中可能因为应用渲染问题依然感到眩晕（QoE差）。本规范旨在打通这“最后一公里”，获取能反映小慧真实感受的应用层数据。

  • “in 3GPP networks”: 这明确了规范的适用范围，涵盖了从3G (UTRAN)、4G (LTE) 到5G (NR) 的所有3GPP主流网络技术。虽然我们的故事主角小慧用的是5G，但其中的原理和流程在4G网络中同样适用，体现了标准的延续性和向后兼容性。

  • “DASH, MTSI and Virtual Reality (VR) measurements”: 这清晰地列出了规范当前主要关注的三大业务领域。

    • DASH (Dynamic Adaptive Streaming over HTTP)：这是目前绝大多数视频应用的基石。小慧平时刷短视频、追剧，背后都是DASH技术在根据她当前的网络状况动态调整视频码率。运营商关心的QoE指标可能包括：初始播放时延、卡顿次数/时长、平均视频码率等。
    • MTSI (Multimedia Telephony Service for IMS)：主要指IMS体系下的多媒体电话业务，如我们常用的VoLTE/VoNR视频通话。其QoE指标更关注实时交互体验，如音视频同步、通话建立时延、清晰度等。
    • Virtual Reality (VR)：这是QoE要求最为严苛的业务，也是小慧即将体验的新功能。它不仅对带宽和时延要求高，更对稳定性、抖动以及应用与网络的协同（如边缘计算）有极高要求。其独特的QoE指标如MTP时延 (Motion-to-Photon Latency)，即从头部转动到VR眼镜中画面更新的全部时延，是衡量VR体验好坏的核心。

1.2 核心流程：定义QoE任务的完整生命周期

The function includes collecting QoE information from UEs frequenting a specified area or an individual UE for a specified end user service/end user service type. The document describes the activation and deactivation of a network request session, UE request session and recording session and also the reporting of recorded information.

这段话进一步描绘了规范所定义“机制”的具体内涵，即一个QoE测量任务从诞生到消亡的完整生命周期管理。

  • “collecting QoE information from UEs frequenting a specified area or an individual UE”: 这里揭示了QoE测量的两种基本触发模式，我们在概览中已经提及：

    • Area-based (基于区域): 对应a specified area。运营商可以针对一个热点区域，如小慧所在的大学城，发起一个QoE测量任务。所有进入该区域并使用目标业务（如V-Stream的VR音乐会）的用户，都可能被“激活”进行QoE上报。这通常对应管理驱动激活 (Management Based Activation) 模式。
    • UE-based (基于个体): 对应an individual UE。如果小慧是“沉浸式VR音乐会”的首批内测用户，运营商为了提供重点保障和收集首批体验数据，可以创建一个只针对她一个人的QoE测量任务。这通常对应信令驱动激活 (Signalling Based Activation) 模式。

  • “activation and deactivation”: 明确了规范内容将包含任务的激活与去激活流程。如何开始一个任务，以及如何在任务完成后（或需要强制终止时）干净地结束它，都是规范的核心内容。

  • “network request session, UE request session and recording session”: 这是三个非常重要的层级概念，是理解后续流程的关键，我们有必要在这里进行第一次深度剖析：

    • Network Request Session (网络请求会话): 这是从无线网络侧（RAN，如gNB） 角度看的任务。当网管下发一个区域性测量任务时，gNB会建立一个Network Request Session。这个会话是“一对多”的，它作为一个“任务容器”，管理着所有进入该区域并满足条件的UE。它的生命周期从网管下发任务开始，到任务超时或被网管取消结束。
    • UE Request Session (UE请求会话): 这是针对单个UE的任务实例。当小慧的手机进入任务区域并被gNB选中后，gNB会为她专门创建一个UE Request Session。这个会话是“一对一”的。它的生命周期与小慧在此次任务中的参与过程绑定，当小慧离开区域或任务被终止时，她的UE Request Session就会结束。
    • Recording Session (记录会话): 这是从UE上的应用程序角度看的。当小慧的手机应用层收到测量指令后，她打开“V-Stream”开始体验VR音乐会时，APP内部会启动一个Recording Session。这个会话与具体的业务使用过程绑定。小慧开始播放，Recording Session开始；她退出播放，Recording Session结束。一次UE Request Session中，可能会包含多次Recording Session（例如，小慧反复进入退出VR音乐会）。

  • “reporting of recorded information”: 最后，规范明确了它还会定义信息上报的机制。APP测量到的数据，如何打包、通过什么信令、在什么时机上报给网络，这些都在TS 28.405的管辖范围之内。

综上所述，第一章Scope为我们描绘了一幅清晰的作战地图：TS 28.405的核心，就是定义一套管理和信令机制，用于控制（激活/去激活）特定区域或特定UE，在进行DASH、MTSI、VR等业务时，启动应用层QoE数据的记录与上报。

2. 第二章 References (参考文献)：构建规范的生态系统

如果说Scope是定义“我是谁”，那么References就是定义“我的朋友们是谁”。在3GPP这个由数千个规范组成的庞大世界里，没有任何一个规范是孤立存在的。它们相互引用、相互依赖，共同构建起一个复杂而精密的通信系统。TS 28.405的References章节，就是它在3GPP世界中的“社交关系图”。

对于工程师来说，读懂References，意味着你能够：

  • 追根溯源：知道某个概念或参数的权威定义源自何处。
  • 理解协同：明白当前规范是如何与其他功能模块（如RRC层、核心网）配合工作的。
  • 快速定位：在遇到问题时，能迅速找到相关的底层或应用层规范进行深入研究。

我们不必逐一列出所有参考文献，而是选取其中最关键的几类“朋友”，来理解TS 28.405是如何与它们协同工作的。

2.1 “上级指导”类规范：定义需求与概念

3GPP TS 28.404: “Telecommunication management;Quality of Experience (QoE) measurement collection; Concepts, use cases and requirements”.

TS 28.404是TS 28.405的“父规范”或“需求规范”。你可以这样理解：

  • TS 28.404 (Why & What): 它回答了“为什么要做QoE测量”以及“需要具备哪些基本能力”。它从运营商的运维需求出发，定义了各种用例（Use Case），比如我们提到的小慧的VR音乐会保障场景，并提出了高阶的功能需求（Requirements）。
  • TS 28.405 (How): 它则是对TS 28.404中提出的需求的具体技术实现。它回答了“如何实现这些用例和需求”，将高阶概念落地为具体的参数、信令和流程。

在阅读TS 28.405时如果对某个功能的背景或目的感到困惑，回溯到TS 28.404中寻找对应的Use Case，往往能豁然开朗。

2.2 “应用层伙伴”类规范：定义测量指标

3GPP TS 26.247: “Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)“. 3GPP TS 26.118: “Virtual Reality (VR) profiles for streaming applications”.

这两份规范是TS 28.405在应用层的亲密伙伴。我们在Scope中提到，TS 28.405不定义具体的QoE指标，那么这些指标在哪里定义呢？答案就在这里。

  • TS 26.247 定义了DASH视频流的各种细节，其中就包括了关于QoE测量的附录，详细规定了视频应用需要测量哪些参数（比如卡顿事件、缓冲区水位等），以及如何将这些测量结果打包成报告。
  • TS 26.118 类似地，专门针对VR流媒体应用，定义了其性能指标和QoE测量参数，比如我们之前提到的MTP时延相关的测量。

当TS 28.405在流程中提到下发QMC configuration file时，这个配置文件的具体格式和内容，实际上就是由TS 26.247或TS 26.118等应用层规范来定义的。TS 28.405负责“运送”这份“调查问卷”，而问卷的具体题目则由这些“应用层伙伴”来出。

2.3 “无线传输”类规范：定义承载信令

3GPP TS 36.331: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC) protocol specification”. 3GPP TS 38.331: “NR; Radio Resource Control (RRC); Protocol specification”.

这两份规范分别是LTE和NR的无线资源控制（RRC）层协议规范。它们是QoE测量任务能够最终触达终端的“运输载体”。 当gNB决定要激活小慧手机的QoE测量功能时，它需要将测量配置信息（如serviceType, qoEReference等）告知UE。这个告知的动作，就是通过构造一条RRCReconfiguration（RRC连接重配置）信令来完成的。 TS 28.405定义了需要放在信令中的**“货物”（即QoE相关的各个信息元素IE），而TS 38.331/36.331则定义了运送这些货物的“卡车”**（RRCReconfiguration消息的整体结构和发送规则）。没有RRC层的支持，QoE激活指令就无法从gNB传送到UE。

2.4 “终端接口”类规范：定义应用与底层的桥梁

3GPP TS 27.007: “AT command set for User Equipment (UE)“.

这份规范看似不起眼，却扮演着至关重要的“桥梁”角色。我们知道，RRC信令是由UE的通信模组（基带芯片）接收和解析的。但是，真正执行QoE测量的是上层的应用程序（如V-Stream App）。那么，模组如何将网络下发的测量指令通知给App呢？ 答案就是AT指令。 TS 27.007定义了一套标准的AT指令集。当通信模组解析RRCReconfiguration消息，发现其中包含QoE测量配置时，它就会通过内部接口，向运行App的操作系统发送一条预定义好的AT指令（例如+CAPPLEVMCNR）。操作系统再将这条指令和相关参数传递给已经注册监听的V-Stream App。 这样，一条从网管出发的指令，经过核心网、gNB、RRC信令，最终通过AT指令这座桥，成功抵达了终端应用程序的内部，完成了控制链路的闭环。

通过梳理这些参考文献，我们看到TS 28.405并非孤军奋战，而是作为一个承上启下的“管理中枢”，与需求、应用、无线、核心网、终端接口等各个领域的规范紧密协作，共同完成了QoE测量这一复杂的多层穿越任务。

FAQ环节

Q1：为什么TS 28.405只关注DASH, MTSI, VR这三种业务？未来会扩展吗？ A1：3GPP标准的发展是需求驱动的。DASH（视频）、MTSI（通话）和VR是当前及可预见的未来移动网络上最消耗资源、对体验最敏感、商业价值最高的几类业务，因此成为了标准优先关注的对象。随着技术发展，如果未来出现了新的杀手级应用（如大规模触觉互联网、全息通信等），并且业界对其QoE测量有共同的标准化需求，那么TS 28.405的Scope完全有可能在新的Release中进行扩展，以涵盖这些新业务类型。

Q2：阅读TS 28.405时，我应该以什么样的顺序去阅读它的参考文献？ A2：一个高效的阅读顺序是：首先，阅读“上级指导”类规范如TS 28.404，理解整个功能的背景和目标。然后，精读TS 28.405本身，掌握核心流程和信令。当遇到具体的QoE测量参数（如QMC配置文件）时，再去查阅“应用层伙伴”类规范如TS 26.247。当涉及到与无线层交互的细节时，再对照“无线传输”类规范如TS 38.331中的相关信元定义。最后，如果想理解终端内部的实现机制，可以参考TS 27.007。这种“由上到下，按需查阅”的方式，可以让你在不迷失于细节的同时，建立起立体的知识框架。

Q3：Scope中提到的三个Session（Network/UE/Recording）概念非常重要，能再用一个比喻来解释吗？ A3：当然可以。我们可以把一次区域性的QoE测量任务比作一次“随堂测试”。

  • Network Request Session 就像是老师在某个教室（Area Scope）宣布：“从现在到下课，对所有同学进行一次数学测验”。这个“测验任务”本身就是Network Request Session。
  • UE Request Session 则是针对具体某个学生（如小慧）的。当小慧走进这个教室，老师发给她一张试卷时，针对她的“测验实例”就开始了，这就是UE Request Session。
  • Recording Session 则是小慧真正在答题的过程。她可能拿到试卷后，先思考了5分钟，然后开始答题，中途又停笔休息了一会儿，最后交卷。她每次“提笔答题”的过程，就是一次Recording Session。一次测验（UE Request Session）中，她可能会有好几次答题和停顿。

Q4：为什么需要一个单独的参考文献章节，而不是在正文中直接说明引用来源？ A4：这是一种规范化的写作方式，有几个好处。首先，它使得规范的管理和版本演进更加清晰。当被引用的规范升级时，只需在参考文献列表中更新版本号，而不需要修改正文各处。其次，它提供了一个集中的索引，方便读者快速了解本规范的技术依赖全景。最后，它让正文部分可以更专注于流程和逻辑的描述，避免了频繁的交叉引用干扰阅读的流畅性。

Q5：作为一名开发者或测试工程师，理解Scope和References对我有什么实际帮助？ A5：非常有帮助。理解Scope可以让你在项目初期就明确，你的产品（无论是基站、核心网元还是终端App）需要实现的功能边界在哪里，避免做无用功或功能遗漏。理解References则是在你进行具体设计、开发和联调时最重要的指南。例如，App开发者需要根据TS 26.247来实现QoE指标的计算和打包；基站开发者需要根据TS 38.331来构造正确的RRC信令；而端到端的测试工程师，则需要对整个链条上的所有相关规范都有所了解，才能在出现问题时，快速判断问题出在哪个环节。

关系图谱