好的，这是系列文章的第十篇。我们将对第五章进行一次完整的、系统性的深度解读。这一章是整个规范的“参数字典”，理解了它，就等于掌握了配置和解读所有QoE测量任务的“密钥”。
深度解析 3GPP TS 28.405：第五章 QoE测量管理参数 (The DNA of a QoE Mission)
本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，关于“Chapter 5 Quality of Experience (QoE) measurement management parameters”的全部核心章节。本文旨在为读者提供一份详尽的参数“白皮书”，我们将逐一剖析构成一个QoE测量任务的每一个“基因片段”，揭示其在实际网络运维中的精确含义与作用。
引言：从“作战计划”到“基因序列”
在过去的篇章中，我们跟随网络优化工程师老王和5G先锋用户小慧，经历了各种场景下的QoE测量任务。我们看到了老王如何制定“作战计划”（管理驱动 vs. 信令驱动），如何在不同的战场（3G/4G/5G）上部署这些计划，以及如何在激烈的战斗（切换）中保持计划的连续性。
今天，我们将深入到这些“作战计划”最核心的层面——构成计划本身的**“基因序列”**。第五章定义的每一个参数，都像是一个独特的基因，它们的不同组合，决定了一个QoE测量任务的最终形态和使命：它的目标是谁？范围在哪？要收集什么情报？情报送往何处？
我们的新场景是：小慧所在的大学与运营商合作，率先开辟了一块**“元宇宙实验网络切片”**。小慧作为首批体验者，需要在这个切片上测试一款高保真、强交互的“虚拟校园”应用。老王的任务，就是要为这次前沿测试，量身定制一个完美的QoE监控方案。他现在扮演的角色，更像是一位“基因工程师”，需要精确地设定每一个参数，来构建一个能够精准反映“元宇宙”体验质量的QoE测量任务。
让我们打开这份“基因图谱”——TS 28.405第五章，逐一解码这些决定QoE任务命运的关键参数。
1. 目的地与身份标识参数：设定任务的基本坐标
这些参数定义了一个QoE任务最基本的“收件人”和“身份ID”，是所有后续操作的基础。
1.1 5.1 QoE collection entity address (M) - 情报接收站地址
This is a parameter which defines the IP address to which the QMC records shall be transferred. Ipv4 or Ipv6 address(es) may be used.
- 参数解读: 这是整个QoE数据流的终点，即**MCE（测量收集实体）**的IP地址。它是强制性（Mandatory）参数，没有它，UE收集的所有数据都将无家可归。
- 场景演绎: 老王在创建任务时，第一个要填写的，就是公司大数据分析平台（MCE）的IP地址。这份来自小慧“虚拟校园”应用的宝贵体验数据，将被加密后，通过5G网络，精准地投递到这个地址。
1.2 5.2 QoE reference (M) - 端到端任务追踪号
The QoE reference parameter specify the network request session. The QoE reference shall be globally unique… It is used to identify the QoE measurement collection job in the traffic nodes and in the measurement collection centre.
- 参数解读: 这是整个QoE测量任务全局唯一的“身份证号”或“快递追踪号”。它由管理系统（老王这边）生成，并在整个生命周期中（从NM到gNB，再到UE，最后送到MCE）保持不变。MCE侧就是靠这个ID来区分和关联来自不同用户的、关于同一个监控任务的数据报告。
- 场景演绎: 老王为这次“元宇宙切片测试”创建的任务，被赋予了一个独一无二的
qoEReference，例如“METAVERSE_CAMPUS_BETA_001”。当MCE收到一份QoE报告，只要看到这个ID，就知道这是关于这次特定测试的，应该放入对应的数据库进行分析。
1.3 5.3 PLMN target (CM) - 目标运营商网络
This parameter defines the PLMN for which sessions shall be selected in the network request session in case of area based QMC when several PLMNs are supported in the RAN… The parameter is mandatory if network sharing is deployed.
- 参数解读: 这个参数用于网络共享场景。当多个运营商共享同一个无线接入网（RAN）时，这个参数可以指定QoE测量只针对其中某一个运营商（PLMN）的用户生效。它是条件强制（Conditionally Mandatory）的，只有在部署了网络共享时才必须配置。
- 场景演绎: 假设小慧的大学校园无线网络是由A、B两家运营商共建的。如果老王只想监控自己A运营商用户的“元宇宙”体验，他就会将
PLMN target设置为A运营商的PLMN ID。这样，即使B运营商的用户也在使用同样的应用，也不会被激活QoE测量。
2. 范围与目标参数：锁定任务的执行对象
这组参数精确定义了“对谁进行测量”和“在哪里测量”。
2.1 5.4 Area scope (CM) - 地理围栏
The area scope parameter defines the area in terms or cells or Tracking Area/Routing Area/Location Area where the QMC shall take place.
- 参数解读: 这是管理驱动模式下的核心参数，用于划定一个地理范围。这个范围可以是一系列小区的列表（Cell ID list），也可以是一个或多个跟踪区/路由区/位置区的列表（TA/RA/LA list）。
- 场景演绎: 老王将
Area scope设置为覆盖整个大学校园图书馆和信息技术大楼的几个5G小区的Cell ID列表。这样，只有当小慧进入这些指定的建筑物内使用“虚拟校园”应用时，QoE测量才会被激活。
2.2 5.6 QMC target (M) - 测量模式选择
The QMC target parameter specifies it the QMC is area based or individual UE based.
- Area based QMC (0)
- Individual UE based QMC (1)
- 参数解读: 这是一个简单的标志位，用于声明本次任务是基于区域的（管理驱动），还是基于单个UE的（信令驱动）。
- 场景演绎: 对于这次“元宇宙”测试，老王需要对作为首批体验者的小慧进行精准监控，因此他将
QMC target设置为1（Individual UE based）。如果他想了解整个校园的普遍体验，就会设置为0。
2.3 5.10 QoE Target (CM) - 精确制导的用户ID
This parameter specifies the target object (individual UE) for the QMC in case of signalling based QMC. The qoETarget parameter shall be able to carry “IMSI” or “SUPI”.
- 参数解读: 当
QMC target被设为“Individual UE based”时，这个参数就成为必填项。它包含了被测用户的唯一身份ID，在4G中是IMSI，在5G中是SUPI。 - 场景演绎: 老王在这里填入了小慧的SUPI。这张“通缉令”会被下发到核心网UDM，HSS会将其与小慧的签约档案绑定，为后续的信令驱动激活做好准备。
2.4 5.9 Slice scope (CM) - 网络切片靶心
This parameter contains a list of S-NSSAIs (Single Network Slice Selection Assistance Information). A Network Slice end to end is identified by S-NSSAI.
- 参数解读: 这是5G的标志性参数。它允许QoE测量任务绑定到特定的网络切片上。S-NSSAI是网络切片的唯一标识。
- 场景演绎: 这对老王的任务至关重要。他将
Slice scope设置为“元宇宙实验网络切片”的S-NSSAI。这样，即使小慧在同一个地点，用同一个手机，切换到普通上网切片去浏览网页，QoE测量也不会被激活。只有当她使用的数据连接（PDU Session）是建立在指定的“元宇宙切片”上时，探针才会被唤醒。这实现了对差异化服务的精准监控。
3. 内容与行为参数：定义“测什么”与“怎么测”
这组参数是QoE任务的“灵魂”，它们决定了UE侧APP的具体测量行为。
3.1 5.8 Service type (M) - 业务战场识别码
Which kind of service that shall be recorded.
- DASH (0) - MTSI (1) - VR (2)
- 参数解读: 强制性参数，用于告知UE需要监控的应用类型是视频（DASH）、多媒体通话（MTSI）还是虚拟现实（VR）。UE的底层会根据这个类型，将测量指令分发给对应的APP。
- 场景演绎: 小慧的“虚拟校园”属于VR应用，因此老王将
Service type设置为2。小慧手机的接入层收到指令后，就知道应该去唤醒那个注册了VR QoE能力的应用（即“虚拟校园”App），而不是“V-Stream”视频App。
3.2 5.5 QMC configuration file (container) (M) - 详细的调查问卷
The QMC configuration file is a container that is specified in Annex L of TS 26.247, clause 16.5 of TS 26.114 or clause 9.4 of TS 26.118.
- 参数解读: 这是最核心的内容参数。它本身是一个“容器”，里面装着具体的测量配置。而这个配置文件的格式和内容，则是由应用层规范（如TS 26.118 for VR）来定义的。TS 28.405只负责“运送”这个容器，不关心其内部细节。
- 场景演绎: 老王根据TS 26.118中关于VR QoE的定义，精心制作了一个
QMC configuration file。里面可能规定了：“需要测量MTP时延，测量频率每秒2次；需要记录交互动作（如抓取虚拟物体）的响应时延，事件触发上报；需要周期性（每分钟）上报一次平均帧率和抖动情况……” 这份详细的“调查问卷”将被原封不动地送达小慧的“虚拟校园”App。
3.3 5.7 Recording session id (M) - 应用会话流水号
This parameter shall be a 2 byte octet string. The recording session id shall be the same for the whole session in the application… The recording session id is generated by the application in the UE.
- 参数解读: 这个ID由UE上的应用程序生成，用于标识一次具体的用户使用过程。它与网络侧生成的
QoE reference不同。 - 场景演绎: 小慧在下午2点到4点之间，三次进入“虚拟校园”应用。她的App会为这三次会话分别生成三个不同的
Recording session id，例如0x0001, 0x0002, 0x0003。在上报的QoE报告中，会同时包含网络下发的QoE reference（始终是“METAVERSE_CAMPUS_BETA_001”）和App自己生成的Recording session id。这样，老王在后台就能清晰地区分出，这是小慧在哪一次具体使用过程中产生的数据。
4. 5G增强型与可选参数：为精细化运维赋能
这些参数大多是可选的（Optional）或5G NR特有的，它们为老王提供了更高级的运维“武器”。
4.1 5.12 Available RAN visible QoE metrics (O) - RAN视角的新指标
This parameter indicate available RAN visible QoE metrics to the gNB. The list of available RAN visible metrics are outside the legacy QoE configuration file. This parameter is optional and is valid for NR only.
- 参数解读: 允许管理系统告知gNB，网络支持收集一些传统的、纯应用层之外的、与RAN性能相关的QoE指标，如“应用层缓冲区液位”等。
- 场景演绎: 老王启用了这个参数，让gNB去收集小慧手机APP的缓冲区数据。这样他就可以分析，小慧感受到的卡顿，究竟是无线空口丢包导致的（缓冲区持续为空），还是应用本身处理慢导致的（缓冲区满但依然卡顿）。
4.2 5.13 MDT Alignment information (O) - 体验与无线环境的对齐
This parameter indicates the MDT measurements with which alignment of QoE measurement is required. This parameter is optional and is valid for NR only.
- 参数解读: 请求gNB将QoE测量与MDT（路测最小化）无线环境测量进行时间上的对齐。
- 场景演绎: 老王启用了此功能。当MCE收到一份报告说小慧在下午3:15:22秒经历了严重交互延迟时，他可以立刻去MDT数据平台，查询同一时刻小慧所在位置的详细无线测量数据（如信号强度、干扰水平等），实现问题的快速根因定位。
4.3 5.11 Job Id (O) & 5.14 QoE collection entity identity
Job Id (O): 一个可选的ID，用于关联多个不同的QMCJob实例，方便进行更大范围的、跨任务的统计分析。QoE collection entity identity: 用于MBS（多播广播业务）场景下的特殊参数，定义了QoE收集实体的唯一身份。
FAQ环节
Q1：QoE reference 和 Recording session id 有什么本质区别？为什么需要两个ID？
A1：它们分别代表了“任务”和“任务的执行实例”，是两个不同层面的标识。
QoE reference是网络侧生成的，标识的是一个QMC Job。它从任务创建到结束都保持不变，是“任务级”ID。Recording session id是UE应用侧生成的，标识的是一次具体的业务使用过程。用户每打开一次App，就可能是一个新的ID，是“应用会话级”ID。 之所以需要两个，是为了实现清晰的**“一对多”关联**。在MCE后台，老王可以通过QoE reference筛选出所有关于“元宇宙测试”的数据，然后再通过Recording session id进一步分析某一次特定时间段内的详细体验过程。
Q2：参数后面的(M), (CM), (O)是什么意思？对网络工程师来说意味着什么？ A2：这是参数的属性，对配置工作至关重要。
- (M) Mandatory / 强制性: 无论什么场景，创建任务时都必须提供这个参数，否则任务会失败。例如
QoE reference。 - (CM) Conditionally Mandatory / 条件强制性: 在特定条件下是强制性的。例如，
Area scope在管理驱动模式下是强制的，但信令驱动模式下可选；QoE Target在信令驱动模式下是强制的。工程师在配置时必须根据场景逻辑来判断是否需要填写。 - (O) Optional / 可选性: 这个参数是可选的，不提供也不会导致任务失败。它们通常用于实现一些增强型或特殊功能，如
MDT Alignment information。工程师可以根据自己的运维需求和网络能力，来决定是否启用这些高级功能。
Q3：Area scope 和 Slice scope 可以同时使用吗？它们如何协同工作？
A3：可以，而且在5G精细化运维中经常组合使用。它们从地理和逻辑两个维度，共同锁定目标用户。当同时配置时，一个UE必须同时满足两个条件才会被激活QoE测量：1) UE的物理位置必须在Area scope定义的地理围栏内；2) UE使用的数据连接（PDU Session）必须建立在Slice scope指定的网络切片上。这种组合可以实现极其精准的监控，例如“只监控大学城图书馆内，使用‘元宇宙切片’的用户的体验”。
Q4：为什么QMC configuration file的内容不由TS 28.405来定义？
A4：这是一种非常重要的分层解耦设计思想。TS 28.405属于管理层（OAM）规范，它的职责是定义“如何控制和传输”测量任务。而具体的“测量什么指标”、“指标如何计算”则属于应用层的范畴。将两者分开，好处巨大：未来如果出现新的VR技术，只需要更新应用层规范TS 26.118，增加新的测量指标和配置文件格式即可，而整个QoE的控制和传输框架（TS 28.405）无需改动。这种设计保证了系统的稳定性和强大的向前兼容性。
Q5：作为一名网络优化工程师，面对这么多参数，我应该从哪里开始着手设计一个QoE测量任务？ A5：可以遵循一个清晰的逻辑步骤：
- 明确目的: 是宏观监控还是个案排障？这决定了
QMC target（Area based vs. Individual）。 - 确定对象: 如果是排障，填写
QoE Target（用户SUPI）；如果是监控，划定Area scope（地理范围）。 - 锁定业务: 确定监控的是视频、通话还是VR，并设置
Service type。 - 设定终点: 填写
QoE collection entity address（MCE地址）。 - 赋予身份: 生成并配置
QoE reference（任务ID）。 - 细化内容: 根据应用层规范，制作并配置
QMC configuration file。 - （5G增强）: 如果需要，再叠加
Slice scope、MDT Alignment等高级参数。 遵循这个思路，就可以构建出一个逻辑清晰、参数完整的QoE测量任务。