51学通信

深度解析 3GPP TS 28.405：第三章 定义、符号与缩略语 (Definitions, symbols and abbreviations)

20分钟阅读

好的，这是系列文章的第三篇。我们将深入剖-析规范的第三章，这一章是理解后续所有流程和信令的基础。

深度解析 3GPP TS 28.405：第三章 定义、符号与缩略语 (Definitions, symbols and abbreviations)

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“Chapter 3 Definitions of terms, symbols and abbreviations”的核心章节，旨在为读者构建一个坚实的术语基础。理解这些基本构件，是读懂后续复杂流程图和信令交互的必备前提。

引言：学习QoE世界的“通用语言”

在前面两篇文章中，我们通过5G少女小慧的视角，对TS 28.405的使命和生态有了宏观的认识。我们知道，这份规范旨在通过一套精密的“遥控”机制，去量化和保障小慧在使用“V-Stream”应用体验VR音乐会时的真实感受。

现在，在我们深入分析那些复杂的信令流程和切换逻辑之前，必须先停下来，做一件至关重要的事情——学习这套机制的“通用语言”。第三章“定义、符号与缩略语”就是这份语言的词典。它看似简单，却是构建后续所有技术理解的基石。

忽略这些基础定义，直接去看后面的流程图，就像是不学音标就去读外文小说，必然会处处碰壁、理解偏差。因此，本章我们将放慢脚步，不仅是简单地翻译这些术语，更会通过小慧的VR音乐会场景，将每一个抽象的词汇都赋予生动的角色和具体的含义，让你彻底明白它们在整个QoE测量大戏中所扮演的角色。

1. 3.1 Terms (术语定义)：为核心概念划定边界

本节为规范中使用的关键术语提供了精确的定义。规范首先指出，大部分通用术语的定义遵循3GPP的总词典——TR 21.905。但对于本规范特有的核心概念，它会在这里给出优先定义。

1.1.1 Network session (网络会话)

Network session: A network session is used when a NF requests a UE to perform QoE Measurement Collection for a specified end user service type. Supported end user service types are defined in clause 5.8.

这是本规范在术语部分唯一定义的一个核心概念。虽然只有短短一句话，但它精确地描述了QoE测量任务在网络侧的“实体化”表现。

让我们把镜头切换到运营商的后台。网络优化工程师老王，是保障小慧所在大学城区域网络体验的负责人。当他得知“V-Stream”应用将在该区域进行VR音乐会的大规模推广时，他的首要任务就是确保网络能够支撑这种超高要求的业务。

于是，老王通过他的网络管理系统，创建了一个QoE监控任务。这个任务的目标是：“监控大学城区域内，所有使用VR业务的用户的体验质量”。

这个由老王在网络功能（NF, Network Function），具体来说是无线接入网（RAN）中所创建和维持的、贯穿整个监控周期的**“任务本身”**，就是一次 Network session。

我们可以从以下几个维度来深入理解它：

  • 发起者 (Who): 由网络功能（NF）发起。在我们的场景中，就是老王通过管理系统下发指令，由gNB（5G基站）来具体执行和创建。
  • 目标 (For Whom): 针对一个或多个UE。这个会话的目标是让UE去执行测量任务。
  • 内容 (What): 执行QoE测量收集（QoE Measurement Collection）。
  • 范围 (Scope): 针对特定的终端用户业务类型（specified end user service type），比如VR（虚拟现实）。

Network session 就像是老王下达的一道“作战命令”，它定义了这次QoE监控行动的总体目标和范围。这个命令下发到覆盖大学城的多个gNB后，这些gNB就进入了“待命”状态，随时准备寻找符合条件的用户（比如小慧）来执行具体的侦察任务。这个Session的生命周期，从老王下达指令开始，一直持续到他设定的监控时间结束或他手动终止任务为止。它是后续所有UE级会话的“父会话”。

2. 3.2 Symbols (符号)

Void.

在这一节，规范明确标注为“Void”（即“空”）。

这表明在本规范的当前版本中，没有定义任何需要特殊解释的数学符号或标记。在3GPP规范的编写实践中，这是一种标准做法。设立此章节是为了结构的完整性，如果未来的版本中需要引入特定的符号来表示复杂的公式或关系，就会填充在这一节。

对于读者而言，我们只需知道本规范的理解不涉及任何特殊的符号系统，可以放心继续。

3. 3.3 Abbreviations (缩略语)：认识QoE测量中的关键“角色”

本节是第三章的核心，它列出了贯穿全文的高频缩略语。理解它们，就像是看一部电影前，先熟悉一下演员表。我们将为每个缩略语赋予一个在小慧VR音乐会场景中的生动角色，帮助你建立一个清晰的系统架构图。

3.3.1 DM - Domain Manager (域管理器)

DM Domain Manager

角色定位：战区司令

在我们的故事里，DM 就是网络优化工程师老王进行操作的那个高级管理平台。老王手下管理着成百上千个基站，他不可能一个一个去单独配置。他需要一个“战区司令部”来帮他传达命令。

这个司令部，就是DM。老王只需在DM的图形化界面上，框选出大学城区域，选择“VR”业务类型，设定好监控时间，然后点击“开始任务”。DM就会自动将这个高级指令，翻译成底层网元（如gNB）能够听懂的语言，并分发给所有相关的“一线部队”。DM是连接“人”（运维工程师）与“系统”（大量网元）的桥梁，负责策略的下发和管理。

3.3.2 MCE - Measurement Collector Entity (测量收集实体)

MCE Measurement Collector Entity

角色定位：情报分析中心

当小慧的手机按照指令收集了宝贵的VR体验数据（比如有没有卡顿、交互延迟多高等）后，这些数据要送到哪里去呢？它们的目的地，就是MCE。

MCE是一个专门的服务器或平台，是所有QoE数据的汇集点和分析中心。你可以把它想象成一个庞大的“情报分析中心”。来自成千上万像小慧一样的用户的数据报告，都会被安全地传输到这里。

在这里，数据被进行清洗、聚合、关联分析，最终以图表、报表和告警的形式呈现给老王。老王可以在MCE的仪表盘上，直观地看到大学城区域VR音乐会业务的整体QoE大盘：平均初始延迟是多少秒？卡顿用户占比是多少？哪个小区的体验最差？没有MCE，收集上来的原始数据就像一盘散沙，无法形成决策依据。

3.3.3 NB - Node B (B节点)

NB Node B

角色定位：一线步兵 (3G时代)

NB 是3G（UMTS）网络中基站的官方名称。虽然现在已经是5G时代，但由于TS 28.405规范需要后向兼容，覆盖从3G到5G的所有网络，因此在描述通用流程或涉及UTRAN的部分时，仍然会使用这个术语。

在小慧的5G故事中，与她直接通信的物理设备是gNB (next generation Node B)。而在4G网络中，对应的角色是eNB (evolved Node B)。NB、eNB、gNB本质上都是无线接入网中最前线的单元，是直接与终端（UE）进行通信的“一线步兵”。

它们负责接收来自DM的命令，识别出辖区内像小慧这样的目标用户，通过无线信令（RRC）将测量任务“激活”，并在收到小慧手机上报的QoE数据后，将其转发给“情报分析中心”MCE。

3.3.4 QMC - QoE Measurement Collection (QoE测量收集)

QMC QoE Measurement Collection

角色定位：行动代号

QMC 不是一个实体，而是这次保障VR音乐会体验的**“整个行动本身”**的代号。当老王说“我们来启动一次QMC任务”时，他指的就是依据TS 28.405规范，执行一次完整的“体验质量测量与收集”的行动。

这个行动包含了从任务创建、下发、激活、UE测量、数据上报，到最后任务去激活的全过程。所以，你可以将QMC理解为这套机制的功能名称，是这次行动的Title。

3.3.5 QoE - Quality of Experience (体验质量)

QoE Quality of Experience

角色定位：胜利目标

QoE 是QMC这次行动的最终**“胜利目标”**。老王和他的团队所做的一切，都不是为了测量网络带宽有多高，或者PING值有多低（那些是QoS），而是为了确保小慧在戴上VR头盔后，看到的画面是流畅的、交互是跟手的、不会因为延迟而感到恶心眩晕。

QoE是用户侧的、主观的、端到端的真实感受的量化。它是衡量网络“好用不好用”的黄金标准，是整个行动的价值所在。所有收集上来的数据，最终都是为了分析、评估和提升QoE。

3.3.6 VR - Virtual Reality (虚拟现实)

VR Virtual Reality

角色定位：特定战场

VR 是这次QMC行动所聚焦的**“特定战场”**或“业务类型”。正如Scope章节所定义的，QMC还可以用于DASH（视频）和MTSI（多媒体通话）等战场。

选择VR作为战场，意味着老王下发的QMC configuration file（测量配置文件）中，包含的都是针对VR业务的特定“调查问卷”。比如，会要求小慧的“V-Stream”应用上报“头部转动到画面响应的时延”、“帧率稳定性”等VR特有的QoE指标，而不会去关心视频通话的指标。明确业务类型，是实现精准测量的基础。

通过这六个缩略语的角色化解读，我们可以清晰地构建出这样一幅图景：

战区司令(DM) 老王，为了达成 胜利目标(QoE)，针对 特定战场(VR)，发起了一次代号为 “QMC” 的行动。命令下达到了 一线步兵(gNB)，gNB激活了用户小慧的终端。小慧的终端在体验VR业务时收集的数据，被送往 情报分析中心(MCE) 进行分析，最终指导老王优化网络，赢得这场体验保卫战。

FAQ环节

Q1：在整个QoE测量架构中，DM (域管理器) 和 MCE (测量收集实体) 的关系是什么？它们可以是同一个物理设备吗？ A1：DM和MCE扮演着截然不同的角色。DM是控制面的实体，负责“发号施令”，即QoE任务的创建、修改、删除和策略下发。MCE是用户面/数据面的实体，负责“收集情报”，即接收、存储和分析从UE上报的海量QoE数据。在实际部署中，它们可以是分离的两个系统，由不同厂商提供（例如，DM可能是网络设备商的管理系统一部分，而MCE可能是一个独立的第三方大数据分析平台）。当然，在一些集成度高的解决方案中，它们也可能被部署在同一组服务器上，但在逻辑功能上必须是分离的。

Q2：“Network session”和后面章节会提到的“UE request session”、“recording session”到底是什么关系？ A2：它们是一个清晰的层级或包含关系，可以理解为“任务 → 实例 → 过程”。

  • Network session 是最顶层的，由网络侧（如gNB）为整个测量任务创建，1个任务对应1个。
  • UE request session 是中间层，当一个具体的UE（如小慧）被网络选中执行任务时，网络为她创建的一个实例，1个被测UE对应1个。
  • Recording session 是最底层，由UE上的应用程序在一次具体的业务使用中创建。例如，小慧在1小时的“UE request session”期间，可能看了3次VR音乐会，每次观看都是一个独立的“Recording session”。

Q3：为什么规范要同时保留NB, eNB, gNB这些不同代际的基站术语？ A3：这是为了确保规范的普适性和向后兼容性。3GPP标准的一个重要原则是尽可能地复用和演进现有架构。QoE测量的基本原理和需求在3G、4G、5G时代是相通的。通过定义一套统一的机制，并指明其在不同网络（UTRAN, E-UTRAN, NG-RAN）中的具体实现方式，可以使得这套功能平滑地演进，也方便了网络设备商和运营商在多代共存的网络中部署和管理QoE功能。

Q4：TS 28.405仅仅是定义了这些术语吗？还是说它也定义了这些实体（如MCE）的具体实现？ A4：这是一个非常好的问题，触及了3GPP规范的边界。TS 28.405主要定义的是这些实体之间的接口、交互流程和需要传递的信息。例如，它定义了gNB需要将QoE报告转发给MCE，报告中需要包含哪些参数。但是，它不定义MCE内部应该如何实现，比如MCE应该使用什么数据库、什么操作系统、数据分析算法是什么等等。这些内部实现留给设备商或运营商自己去发挥，这给了市场竞争和技术创新的空间。

Q5：我是一名App开发者，在这些术语中，我最需要关心的是哪几个？ A5：作为App开发者，你处在QoE测量的最末端，也是最关键的一环。你最需要关心的概念与你直接相关：

  • QoE (体验质量): 你需要知道你的App应该测量哪些指标才能真实反映用户体验。
  • VR/DASH/MTSI (业务类型): 你需要清楚你的App属于哪种业务类型，并遵循对应应用层规范（如TS 26.118 for VR）的要求来实现测量逻辑。
  • QMC (QoE测量收集): 你需要理解你的App是在参与一次QMC行动，并要能响应来自底层的激活指令（通常通过AT指令或特定API），并按要求上报数据。
  • Recording session: 你的代码需要实现这个session的管理，即在业务开始时启动测量，业务结束时停止测量，并为每次会话生成唯一的标识。

关系图谱