好的，我们继续对3GPP TS 29.552规范的特定分析流程进行深度拆解。继上一篇剖析了守护5G生命线的“网络切片负载分析”之后，本篇文章将聚焦于另一个核心分析领域——观测业务体验。这不再是单纯地从网络资源视角看问题，而是切换到最终用户和应用的视角，去度量他们最真实的、端到端的“体感”。

深度解析 3GPP TS 29.552：5.7.3 Observed Service Experience Analytics (观测业务体验分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.3 Observed Service Experience Analytics”的核心章节，旨在为读者详细拆解NWDAF是如何扮演一位“首席体验官”，融合来自网络各层、应用甚至终端的数据，最终量化并预测用户真实业务体验的。

前言：超越网络KPI，回归用户“体感”

对于最终用户而言，他们并不关心网络的PRB利用率是50%还是80%，也不关心AMF的信令负载有多高。他们只关心一件事：我的App用起来爽不爽？——视频是否秒开无卡顿？游戏是否流畅低延迟？语音通话是否清晰不掉线？

这种端到端的、主观的感受，我们称之为“业务体验”。传统的网络运维（OAM）虽然能提供海量的网络KPI（关键性能指标），如吞吐量、时延、丢包率等，但这些KPI往往与用户的真实体验之间存在一道“鸿沟”。例如，即使网络平均时延很低，一次关键的、突发的网络抖动也足以毁掉一局在线竞技游戏。

为了跨越这道鸿沟，5G的“智慧大脑”‘洞察者’(Insight-AI)必须具备一项核心能力——观测业务体验分析 (Observed Service Experience Analytics)。它的任务不再是简单地报告网络指标，而是要当一名“首席体验官”，将冰冷的网络数据，转化为能够直接反映用户“体感”的、有温度的体验评分或预测。

在今天的“未来科技博览会”场景中，最热门的应用莫过于“星际穿越”云游戏体验仓。玩家戴上VR头盔，就能体验到身临其境的太空激战。该应用的开发商（我们称之为“CloudGaming Inc.”）与运营商“数智网联”签订了顶级的QoE（体验质量）保障协议。“CloudGaming Inc.”的后台应用（AF）需要实时了解其玩家在博- 览会现场的游戏体验，并在体验下降之前得到预警。

为此，“CloudGaming Inc.”的AF向‘洞察者’发起了“观测业务体验分析”的请求。本文将详细跟随这个请求的生命周期，深入5.7.3节的信令流程，看看‘洞察者’是如何调动全网资源，完成这次“端到端体感”的深度洞察的。

---

1. 任务简报：体验分析的目标与“情报源”

这项分析任务的目标是输出关于一个或一组UE在特定应用上的业务体验。其输出结果通常是一个**MOS分（Mean Opinion Score，平均主观意见分）**或其他形式的体验度量值。

规范原文引用 (Clause 5.7.3 Introduction):

This procedure is used by the NF to obtain the Service Experience analytics which are calculated by the NWDAF based on the information collected from the AMF, SMF, UPF, GMLC, AF, OAM and/or MDAF.

‘洞察者’解读道：“要当好‘首席体验官’，我必须眼观六路、耳听八方。我的情报来源是空前广泛的，几乎涵盖了从无线接入、核心网、用户面到应用层的整个业务路径。”

• 情报来源之广：

  • AMF: 提供用户移动性、连接状态等基础信息。

  • SMF: 提供PDU会话信息，如DNN、S-NSSAI、QFI，这是定位业务流的“路标”。

  • UPF: 提供最真实的用户面数据，如实际的流量、丢包、时延。

  • GMLC (网关移动定位中心): 提供更高精度的UE位置信息。

  • AF (应用功能): “CloudGaming Inc.”的应用自己会主动上报一些应用层的体验数据，如游戏渲染帧率、操作响应时延等，这是最接近“体感”的第一手资料。

  • OAM: 提供无线侧的性能数据（如RSRP, SINR）和传输网的KPI。

  • MDAF (管理数据分析功能): OAM域自身的分析功能，可以提供经过初步处理的管理域分析结果。

• 分析ID: SERVICE_EXPERIENCE

这个流程的复杂性在于，它需要将来自上述所有源头的数据进行时间同步和空间关联，最终将它们映射到一个统一的体验模型上。

---

2. 行动方案：解构业务体验分析的信令全流程

规范中的 “Figure 5.7.3-1: Procedure for Service Experience Analytics” 为我们展示了‘洞察者’完成这项复杂任务的详细步骤。我们可以将其分为三个阶段：任务启动与基础信息收集、用户面与应用层深度钻取、分析计算与交付。

阶段一：任务启动与基础信息收集 (步骤1 - 3)

“CloudGaming Inc.”的AF向‘洞察者’发起了订阅：“请为我方应用（由Application ID标识）的用户，持续监控其在博览会主展馆区域的游戏体验。一旦预测MOS分将低于4.0，请立刻通知我。”

步骤1a-1c：AF发起订阅

与之前的流程类似，AF通过Nnwdaf_AnalyticsInfo_Request（一次性查询）或Nnwdaf_EventsSubscription_Subscribe（长期订阅）发起请求，analyticsId为SERVICE_EXPERIENCE，eventFilter中包含了applicationId和areaOfInterest。

步骤2a-3b：收集UE基础信息

规范原文引用 (Step 2a-2b):

…the NWDAF may invoke Namf_EventExposure_Subscribe service operation…to subscribe to the notification of UE ID and UE location.

体验是附着在用户身上的。‘洞察者’首先需要知道“谁”和“在哪里”。

• 动作：向AMF发起Namf_EventExposure_Subscribe订阅。

• 目的：获取在指定区域内、正在使用指定应用（AMF可以通过PDU会话信息关联到应用）的UE列表及其位置信息。

• 信息流：当有符合条件的玩家进入或离开展馆时，AMF会通过_Notify（步骤3a-3b）通知‘洞察者’。

阶段二：用户面与应用层深度钻取 (步骤4 - 14)

这是整个流程最核心、也是情报来源最丰富的部分。‘洞察者’开始沿着业务流的路径，逐层深入地收集性能数据。

步骤4a-5b & 10a-11b：深入用户面 (SMF & UPF)

规范原文引用 (Step 4a-4b):

The NWDAF may invoke Nsmf_EventExposure_Subscribe service operation…to subscribe to the notification of QFI, IP filter information, DNAI, UPF information, Application ID, DNN and S-NSSAI.

1. 向SMF订阅会话信息 (4a-4b)：‘洞察者’向SMF订阅，目的是获取云游戏业务流的详细“路径信息”。SMF会返回该业务流的QFI（QoS流ID）、对应的UPF实例信息等。

2. SMF/UPF上报通知 (5a-5b)：当会话信息发生变更时，SMF会通知‘洞察者’。

3. 直接向UPF订阅性能数据 (10a-11b)：拿到UPF信息后，‘洞察者’（或通过SMF代理）可以直接向服务该游戏流的UPF发起订阅，这是最关键的数据来源之一。

   规范原文引用 (Step 10a-10b):

   …The SMF subscribes to the UPF on behalf of the NWDAF via N4 Session Reporting Rule…

   • 订阅内容：请求UPF上报该游戏流（由QFI标识）的实时性能指标，如端到端时延、抖动、丢包率、吞吐量等。

   • UPF上报 (11a-11b)：UPF会利用其强大的数据面检测能力（如TWAMP, DDP），持续地测量并将这些最真实的用户面性能数据通过Nupf_EventExposure_Notify（或通过SMF中转）上报给‘洞察者’。

步骤6a-9d：来自应用的第一手情报 (AF)

规范原文引用 (Step 6a-6b):

If the AF is trusted, the NWDAF may invoke Naf_EventExposure_Subscribe service operation…to request the service data and performance data from AF directly.

网络数据终究是间接的。最了解体验的，是应用本身。

• 向AF订阅应用层数据 (6a-6b)：‘洞察者’会反过来向“CloudGaming Inc.”的AF发起Naf_EventExposure_Subscribe订阅。

• 订阅内容：“请上报你客户端感知的游戏体验数据”。这可能包括：

  • 游戏帧率 (FPS)

  • 画面卡顿次数

  • 玩家操作到画面响应的端到端时延

• AF上报 (7a-7b)：“CloudGaming Inc.”的AF会汇总其客户端（游戏终端）上报的数据，通过_Notify提供给‘洞察者’。

• 非可信AF场景 (8a-9d)：如果AF是外部的、非可信的，这个订阅/通知的交互过程就需要通过NEF作为安全中介。

步骤12a-13b：高精度定位 (GMLC)

规范原文引用 (Step 12a-12b):

If the NF requestes fine granularity location analytics information, the NWDAF may invoke Ngmlc_Location_ProvideLocation service operation to retrieve UE Location and UE Location Accuracy…

如果体验问题与特定的、小范围的地理位置（如展馆的某个角落）强相关，‘洞察者’会向GMLC请求更高精度的定位，以进行更精细的根因分析。

步骤14a-14b：融合OAM/MDAF数据

最后，‘洞察者’还会从OAM收集无线侧的详细KPI（如信道质量CQI、资源调度信息等），以及从MDAF获取管理域的分析结论。

阶段三：分析计算与“体感”报告交付 (步骤15 - 24)

规范原文引用 (Step 15):

The NWDAF calculates the Service Experience analytics based on the data collected from AMF, SMF, UPF, GMLC, AF, OAM and/or MDAF.

‘洞察者’的办公桌上，汇集了来自网络几乎所有层面的海量、异构、多维的数据。

1. 数据融合与对齐：这是最复杂的一步。‘洞察者’需要将来自不同源、不同时间戳的数据，基于用户ID、会话ID和位置信息进行关联和对齐。

2. 体验模型计算 (Step 15)：AnLF将对齐后的数据输入到“业务体验”机器学习模型中。这个模型（例如，一个梯度提升树或神经网络）的输入是上百个维度的网络和应用层指标，输出则是一个简单直观的MOS分（1-5分）。

3. 生成预测性报告：模型不仅能计算“当前”的MOS分，更能预测“未来”的趋势。它发现，由于某个无线小区的上行干扰正在持续增强（来自OAM数据），结合UPF上报的上行丢包率开始微增，模型预测在5分钟后，游戏体验MOS分将跌破4.0。

步骤16 & 24：交付预警

‘洞察者’立刻通过Nnwdaf_EventsSubscription_Notify服务，向“CloudGaming Inc.”的AF发送预警通知。

• 通知内容：

   
  {
   
    "event": "SERVICE_EXPERIENCE",
   
    "analyticsData": {
   
      "serviceExpInfos": [{
   
        "supi": "player-123",
   
        "mos": 3.9,
   
        "prediction": true,
   
        "predictionTime": "now + 5 minutes",
   
        "rootCause": "UPLINK_INTERFERENCE"
   
      }]
   
    }
   
  }
   

  这份报告不仅告诉AF“体验即将下降”，还给出了可能的原因（上行干扰），为快速排障提供了方向。

闭环完成：“CloudGaming Inc.”的AF收到预警后，可以立即采取措施，例如，通知游戏客户端稍微降低上行码率，或者请求PCF为该用户切换到一个干扰更小的无线载波上，从而成功避免了一次游戏体验的劣化。

---

总结：从数据到体验，智能的终极闭环

5.7.3节的“观测业务体验分析”流程，是TS 29.552中最为复杂、也最能体现NWDAF核心价值的流程之一。它完美地诠释了5G网络智能化的终极目标——服务于最终的用户体验。

• 极致的数据融合能力：该流程展示了NWDAF如何打破网络分层和专业领域的壁垒，将来自控制面（AMF/SMF）、用户面（UPF）、应用层（AF）、管理面（OAM）的数据融于一炉，实现了真正的“端到端”可见性。

• 从KPI到QoE的转化：NWDAF的核心价值在于，它不仅仅是数据的搬运工和展示器，更是“翻译官”和“解读师”。它通过内置的AI模型，将海量、复杂、非结构化的网络KPI，成功“翻译”为了简单、直观、可行动的QoE（体验质量）指标。

• 赋能主动、预测性运维：业务体验分析的核心是“预测”。它使得运营商和应用提供商能够从“用户投诉、被动响应”的传统模式，升级为“预见问题、主动优化”的全新范式，极大地提升了服务质量和客户满意度。

这项能力，是运营商实现差异化竞争、保障高价值业务SLA、开拓垂直行业市场的关键技术武器。它让5G网络不再只是一个冰冷的管道，而是一个能够感知用户喜怒哀乐、并为之不断优化的“智慧生命体”。

在下一篇文章中，我们将继续探索5.7节，将目光从“业务体验”转向“网络功能自身”，看看‘洞察者’是如何监控自己“同事们”的健康状况的——5.7.4 NF load Analytics (NF负载分析)。

---

FAQ 环节

Q1：业务体验MOS分是如何计算出来的？这是一个标准化的算法吗？

A1：MOS分的计算模型不是3GPP标准化的内容，它属于NWDAF的内部实现，是各个设备商和运营商的核心竞争力所在。3GPP标准只定义了需要收集哪些输入数据，以及需要输出MOS分这个结果。至于中间的“黑盒子”——AI模型，则由厂商自行设计和训练。常见的模型包括：

• 传统模型：基于E-model等数学公式，将时延、抖动、丢包率等参数通过公式拟合出MOS分。

• 机器学习模型：通过监督学习，用大量的“网络KPI-用户主观评分”样本对，训练出一个能够自动学习复杂映射关系的ML模型（如GBDT, 神经网络）。这是目前的主流方向，因为它可以更好地捕捉非线性关系。

Q2：AF（应用功能）上报的数据可信吗？NWDAF如何处理可能不准确的应用层数据？

A2：这是一个非常重要的问题。AF上报数据的可信度，取决于AF自身的实现和运营商对AF的信任等级。

1. 信任模型：运营商会对AF进行分级。对于运营商自有的、或经过严格认证的合作伙伴AF（如本例中的“CloudGaming Inc.”），其数据被认为是可信的，会作为模型的重要输入。

2. 数据清洗与交叉验证：NWDAF的AI引擎通常会包含数据预处理模块。它可以将AF上报的数据与自己从网络侧（如UPF）测量到的数据进行交叉验证。如果发现AF上报的“丢包率为0”，而UPF却观察到大量丢包，NWDAF可以识别出这种矛盾，并降低AF数据的权重，甚至将其标记为异常。

3. 模型鲁棒性：健壮的ML模型本身对部分噪声数据就有一定的容忍度。

Q3：这个流程看起来非常复杂，实时性如何保证？

A3：保证实时性是这个流程设计的关键挑战。实现方式包括：

1. 事件驱动：绝大多数数据收集都采用订阅/通知的事件驱动模式，避免了耗时的轮询。

2. 分布式计算：NWDAF自身可以是一个分布式的系统，将数据处理和模型推理任务分发到多个节点上并行执行。

3. 边缘下沉：对于超低时延的体验保障，部分轻量级的体验分析功能可以下沉到CU/DU或UPF边缘节点，形成快速的本地闭环。核心网的NWDAF则负责更长周期、更宏观的体验趋势分析和模型训练。

4. 高效的数据管道：需要依赖高性能的网络和数据处理框架（如Spark Streaming, Flink）来支撑实时的数据流处理。

Q4：MDAF（管理数据分析功能）和NWDAF是什么关系？它们会产生功能重叠吗？

A4：MDAF和NWDAF是5G智能架构中两个不同域的分析功能，它们既有区别又有协作。

• 域不同：MDAF属于管理域（Management Domain），它主要处理来自OAM的数据，其分析结果主要服务于网络管理和运维。NWDAF属于核心网控制面（Control Plane），它主要处理来自核心网NF的信令数据和用户面数据，其分析结果主要服务于实时或准实时的网络控制和策略决策。

• 协作关系：它们是协作而非竞争关系。MDAF可以对海量的、慢变的OAM数据进行预处理和分析，将初步的分析结论（如“某区域无线环境质量长期不佳”）提供给NWDAF。NWDAF再将这个结论，与自己收集到的实时用户行为数据相结合，做出更精准的判断。在本流程中，MDAF就是NWDAF的一个重要“情报源”。

Q5：消费者在订阅SERVICE_EXPERIENCE时，可以指定只关心一部分数据源吗？

A5：消费者在订阅时不能直接指定NWDAF应该使用哪些数据源，因为“如何进行分析”是NWDAF的内部实现，对消费者是透明的。消费者能做的，是通过eventFilter来限定分析的范围和对象，例如：

• applicationId: “我只关心这个应用”。

• supi: “我只关心这个用户”。

• areaOfInterest: “我只关心这个区域”。

• qosRequirement: “我关心的体验阈值是…”。

NWDAF会根据消费者提供的这些过滤条件，智能地决定它需要启动哪些数据收集流程。例如，如果消费者没有提供applicationId，NWDAF可能就不会启动向AF收集数据的流程。这种设计将复杂性封装在了NWDAF内部，为消费者提供了更简洁的接口。