51学通信

深度解析 3GPP TS 29.552：5.2 Analytics Exposure Procedures (分析暴露流程)

25分钟阅读

深度解析 3GPP TS 29.552：5.2 Analytics Exposure Procedures (分析暴露流程)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将重点剖析规范的“第5章 信令流程”的开篇——5.1节“总则”与5.2节“分析暴露流程”，旨在为读者详细阐述5G网络的“智慧大脑”NWDAF是如何向外界提供其核心价值——网络分析洞察的。

前言：从“有什么”到“怎么用”

在上一篇文章中，我们共同探索了TS 29.552规范的第1至4章，搭建起了对NWDAF参考架构的宏观认知。我们知道了“智慧大脑”‘洞察者’(Insight-AI)拥有数据收集、分析暴露、数据存储和漫游协作等核心能力，并了解了DCCF、ADRF等关键“辅助角色”的存在。我们已经知道了它“有什么”。

现在，我们将从“有什么”迈向“怎么用”。本篇文章将正式进入规范的心脏地带——第5章“网络数据分析框架的信令流”，聚焦于开篇的5.1和5.2节。这部分内容是NWDAF所有对外服务的基石，它精确定义了其他网络功能（NF）或应用功能（AF）作为“消费者”，该如何从‘洞察者’这里获取智慧的分析结果。

为了让这些抽象的信令流程变得触手可及，让我们继续“未来科技博览会”的场景。一家名为“HoloVerse Inc.”的创新公司将在博览会上展示其旗舰产品——一款需要超高带宽、超低时延的“万人同场竞技”的AR游戏。作为游戏的开发者，他们最担心的就是在演示高峰期网络出现问题，导致游戏卡顿，体验崩塌。“HoloVerse”公司因此成为了‘洞察者’的一位重要客户，迫切需要获取网络的分析与预测信息，来保障其业务的“SLA”（服务等级协议）。

通过模拟“HoloVerse”与‘洞察者’的互动，我们将一步步拆解分析暴露的两种核心模式：订阅/通知 和 请求/响应，并理解它们在不同场景下的具体信令交互细节。

1. 流程总纲：5.1 General (总则)

第5章以一个简短的“总则”章节开篇，它如同一本书的目录，为我们指明了本章将要探索的所有领域。

规范原文引用 (Clause 5.1 General):

This clause describes the Network Data Analytics related Signalling Flows, including the procedures for analytics exposure, analytics aggregation from multiple NWDAFs, analytics context and analytics subscription transferring between different NWDAFs, ML model provisioning, data collection, specified Network Data Analytics generation and the NWDAF discovery and selection. The specific NF service operations which are used in these procedures are also provided in the procedure descriptions.

这段话为我们勾勒出了第5章的完整版图。‘洞察者’解释道：“这里列出的，就是我日常工作的全部‘剧本’。”

  • 分析暴露 (analytics exposure)：如何将我的分析结果提供给他人。（本文重点）

  • 分析聚合 (analytics aggregation)：当有多个‘我’（NWDAF）时，如何协同工作，汇总分析结果。

  • 分析传递 (analytics … transferring)：当用户移动时，如何将他的“分析档案”无缝交接给下一个‘我’。

  • ML模型供给 (ML model provisioning)：我如何获取或分发最新的机器学习模型。

  • 数据收集 (data collection)：我如何从网络中收集情报。

  • 特定分析生成 (specified Network Data Analytics generation)：针对具体的分析任务（如切片负载分析），我的详细工作步骤是什么。

  • 发现与选择 (discovery and selection)：其他同事如何找到并选择最合适的‘我’来为他们服务。

这个总览至关重要，它帮助我们建立了一个结构化的认知。今天，我们的焦点就是第一个，也是最基础的主题——分析暴露。

2. 暴露智慧的两种模式：5.2 Analytics Exposure Procedures (分析暴露流程)

‘洞察者’的智慧如果不被使用，就毫无价值。5.2节正是定义了将这些智慧“变现”的标准化流程。

规范原文引用 (Clause 5.2.1 General):

The analytics exposure procedures allow the NF service consumers (i.e. NFs, OAM and AFs) to obtain the analytics information from the NWDAF.

本节开宗明义，点出其核心目的：让分析服务的消费者（可以是网络内部的NF，也可以是运维系统OAM，或是第三方应用AF）能够从NWDAF处获得分析信息。

获取信息的方式主要有两种，‘洞察者’将其比喻为“订阅报纸”和“随时问询”。

2.1 “订阅报纸”模式：5.2.2 Network data analytics Subscribe/Unsubscribe/Notify (订阅/退订/通知)

这是最高效、最常用的一种模式。消费者预先告诉‘洞察者’自己关心什么，一旦有相关“新闻”发生，‘洞察者’就会主动将“报纸”（分析报告）送上门。

这个模式又分为两种场景：内部员工直接订阅，和外部伙伴通过“前台”（NEF）订阅。

2.1.1 内部订阅：由5GC NF、OAM或AF发起的流程 (Clause 5.2.2.1)

假设“HoloVerse”公司的AR应用功能（AF）被运营商视为“内部可信应用”，直接部署在运营商网络内部。为了实时保障游戏体验，它需要持续监控博览会主展馆的网络QoS状况。

此时，就会触发规范中 “Figure 5.2.2.1-1: Analytics Subscribe/Unsubscribe/Notify initiated by 5GC NFs, OAM or AFs” 所描绘的流程。

步骤1：发起订阅 (Invoke Nnwdaf_EventsSubscription_Subscribe)

规范原文引用 (Step 1):

In order to subscribe to notification(s) of analytics information from the NWDAF, the NF service consumer invokes Nnwdaf_EventsSubscription_Subscribe service operation by sending an HTTP POST request targeting the resource “NWDAF Events Subscriptions”. The request includes the subscribed events and may include event filter information.

“HoloVerse”的AF（作为NF service consumer）向‘洞察者’（NWDAF）发出了它的需求：“你好，‘洞察者’，我需要订阅主展馆区域的QoS可持续性分析。一旦你预测到QoS可能会无法满足我的AR游戏要求（例如，时延高于10ms），请立刻通知我。”

在技术层面，这个过程是：

  1. 动作：HoloVerse AF向NWDAF发起一个HTTP POST请求。

  2. 目标URI：请求的目标是NWDAF暴露的.../nnwdaf-eventssubscription/v1/subscriptions资源集合。

  3. 请求体 (Payload)：POST请求的消息体里包含了订阅的详细信息，这就像填写了一张“报纸订阅单”：

    • subscribedEvents: 订阅的事件/分析ID，这里是 QOS_SUSTAINABILITY。

    • eventFilter: 事件过滤器，用于明确订阅的范围。例如："areaOfInterest": "TAI-List-for-Expo-Hall"，"qosRequirement": {"latency": 10}。

    • notificationURI: 一个回调地址，告诉‘洞察者’“报纸”应该送到哪里。这是HoloVerse AF自己的一个API端点。

步骤2：订阅成功响应 (NWDAF responds)

规范原文引用 (Step 2):

The NWDAF responds to the Nnwdaf_EventsSubscription_Subscribe service operation. Upon receipt of the HTTP POST request, if the subscription is accepted to be created, the NWDAF responds to the NF service consumer with “201 Created”, and the URI of the created subscription is included in the Location header field.

‘洞察者’收到了订阅请求，检查了HoloVerse AF的权限和请求的有效性后，表示同意。

技术实现上：

  1. 动作：‘洞察者’回复一个HTTP响应。

  2. 状态码：201 Created。这是一个标准的RESTful API实践，表示“资源已成功创建”。这里创建的资源就是这个“订阅关系”本身。

  3. 响应头 (Header)：响应中最重要的部分是Location头。它的值是这个新创建的订阅资源的唯一URI，格式通常是.../subscriptions/{subscriptionId}。

这个{subscriptionId}至关重要，HoloVerse AF必须保存好它，因为后续如果想修改或取消订阅，就需要用这个ID来指明是哪个订阅。

步骤3：‘洞察者’主动通知 (Invoke Nnwdaf_EventsSubscription_Notify)

规范原文引用 (Step 3):

If the NWDAF observes the subscribed event(s), the NWDAF invokes Nnwdaf_EventsSubscription_Notify service operation to report the event(s) by sending an HTTP POST request with {notificationURI} as Notification URI.

博览会进行到下午，人流达到顶峰。‘洞察者’通过分析从AMF、SMF和UPF收集到的实时数据，其内置的ML模型预测出，在未来10分钟内，主展馆区域由于大量用户同时开启视频直播，上行链路将出现拥塞，无法再满足AR游戏所需的低时延QoS。订阅的条件被触发了！

技术实现上：

  1. 动作：‘洞察者’立刻向之前HoloVerse AF提供的notificationURI发起一个HTTP POST请求。

  2. 请求体：消息体里包含了详细的分析报告，即“今日头条”：

     
{
 
  "subscriptionId": "{subscriptionId}",
 
  "eventNotifications": [{
 
    "event": "QOS_SUSTAINABILITY",
 
    "analyticsData": {
 
      "qosSustainInfos": [{
 
        "area": "TAI-List-for-Expo-Hall",
 
        "sustainStatus": "NOT_SUSTAINABLE",
 
        "predictionTime": "now + 10 minutes"
 
      }]
 
    }
 
  }]
 
}

    HoloVerse AF收到这个通知后，它的应用逻辑可以立即被触发，例如，主动为AR游戏玩家切换到备用网络切片，或者稍微降低游戏画质以减少对时延的敏感度，从而保障核心体验。

步骤4 & 5 & 6：确认与退订

  • 步骤4 (Consumer responds)：HoloVerse AF收到通知后，回复一个204 No Content，表示“消息收到，无需多言”。这是一个简单的确认。

  • 步骤5 & 6 (Unsubscribe)：博览会结束，HoloVerse AF不再需要监控。它向步骤2中获取的Location URI (.../subscriptions/{subscriptionId}) 发起一个HTTP DELETE请求，‘洞察者’收到后删除该订阅，并回复204 No Content确认删除。至此，整个订阅生命周期结束。

2.1.2 外部订阅：通过NEF发起的流程 (Clause 5.2.2.2)

现在，我们考虑另一种情况：HoloVerse公司是一家外部的第三方合作伙伴，其应用AF部署在公有云上，无法直接访问运营商的内部网络。此时，它必须通过运营商的“安全大门”和“能力开放窗口”——NEF (Network Exposure Function) 来与‘洞察者’沟通。

这个流程由 “Figure 5.2.2.2-1: Analytics Subscribe/Unsubscribe/Notify initiated by AFs via the NEF” 描绘。

整个流程的逻辑与内部订阅完全相同，但增加了一个关键的“中间人”——NEF。

  1. AF → NEF (步骤1)：HoloVerse AF不再直接与NWDAF对话，而是向NEF的标准化API (Nnef_AnalyticsExposure_Subscribe) 发起订阅请求。

  2. NEF的职责：NEF收到请求后，会执行一系列关键的安全和管理任务：

    • 认证与授权：检查HoloVerse AF的身份凭证，确认它是否有权限订阅这项分析服务。

    • API映射/转换：NEF的外部API可能与NWDAF的内部API在格式或参数上有所不同。NEF负责进行转换。

    • 策略执行：运营商可能在NEF上配置了策略，如限制外部伙伴的请求频率。

  3. NEF → NWDAF (步骤2)：NEF验证通过后，它扮演消费者的角色，向NWDAF发起内部的Nnwdaf_EventsSubscription_Subscribe请求，这与2.1.1节的流程完全一样。

  4. 响应和通知路径：所有的响应（步骤3, 4）和后续的通知（步骤5, 6, 7, 8）都会沿着原路返回，即NWDAF -> NEF -> AF。NEF在这里起到了一个安全、可靠的“反向代理”作用。

通过NEF，运营商在开放网络能力的同时，确保了核心网的安全和可控。

2.2 “随时问询”模式：5.2.3 Network data analytics information request (信息请求)

除了订阅，消费者也可以选择一种更直接的方式：随时发起一次性的查询，立即获取当前的分析结果。

2.2.1 内部查询 (Clause 5.2.3.1)

场景：HoloVerse的现场运维工程师在后台管理界面上有一个“刷新网络状态”的按钮。他想立即知道当前展馆网络的健康度。

此时，就会触发 “Figure 5.2.3.1-1: Network data analytics info request procedure” 描绘的流程。这个流程非常简单，只有一问一答。

步骤1：发起请求 (Invoke Nnwdaf_AnalyticsInfo_Request)

规范原文引用 (Step 1):

The NF Service Consumer invokes Nnwdaf_AnalyticsInfo_Request service operation by sending an HTTP GET request targeting the resource “NWDAF Analytics”, to the NWDAF to request the analytics information. The request includes analytics identifier and related event filter information.

技术实现上：

  1. 动作：运维界面后台的AF向‘洞察者’发起一个HTTP GET请求。

  2. 目标URI：请求的目标是.../nnwdaf-analyticsinfo/v1/analytics，并通过查询参数来指定请求内容。

  3. 查询参数 (Query Parameters)：GET .../analytics?analytics-id=QOS_SUSTAINABILITY&area-of-interest=TAI-List-for-Expo-Hall

    这就像直接问：“嘿，‘洞察者’，现在主展馆的QoS可持续性怎么样？”

步骤2：立即响应 (NWDAF responds)

规范原文引用 (Step 2):

The NWDAF responds to the Nnwdaf_AnalyticsInfo_Request service operation. If the request is accepted, the response includes the requested analytics information with “200 OK”.

‘洞察者’收到请求后，立即触发AnLF（分析逻辑功能）进行计算，并将结果通过200 OK响应的消息体返回。响应体可能包含如下信息：

{"qosSustainInfos": [{"area": "...", "sustainStatus": "SUSTAINABLE"}]}

运维工程师的管理界面上立刻显示出“网络状态良好”的绿色图标。

2.2.2 外部查询：通过NEF (Clause 5.2.3.2)

与订阅模式一样，如果HoloVerse是外部应用，其一次性的查询请求也必须通过NEF。流程图 “Figure 5.2.3.2-1: Analytics Request initiated by AFs via the NEF” 展示了这一点。其逻辑与2.1.2节类似，NEF充当安全代理，将外部AF的请求（Nnef_AnalyticsExposure_Fetch）转化为对NWDAF的内部请求（Nnwdaf_AnalyticsInfo_Request），并中继响应结果。

总结：掌握与“大脑”对话的基础语言

通过对5.2节的深度剖析，我们已经掌握了与NWDAF这个“智慧大脑”进行对话的两种最基础、也是最重要的“句式”：

  1. 订阅/通知模式：适用于需要持续监控、事件驱动的场景。它的优点是高效、实时，一旦订阅，消费者就可以“坐等”通知，无需不断轮询。这是实现网络主动运维和自动化闭环的核心机制。

  2. 请求/响应模式：适用于需要按需获取、即时快照的场景。它的优点是简单、直接，可以快速获取某个时间点的网络状态分析。这为人工排障、仪表盘展示、一次性决策等场景提供了便利。

我们还理解了，无论是哪种模式，5G架构都为**内部（可信）和外部（非可信）**的消费者提供了不同的、安全的接入路径，体现了其在开放性和安全性之间的精妙平衡。

掌握了这两种基本的“对话”模式，就等于掌握了解读后续所有复杂信令流程的“语法”。在下一篇文章中，我们将进入更高级的主题——5.2.4节“通过DCCF的分析暴露”。我们将看到，当‘洞察者’的“数据助理”DCCF介入时，这些对话流程会如何演变，从而实现更高效、更具扩展性的分析服务暴露。

FAQ 环节

Q1：订阅/通知模式和请求/响应模式，在实际应用中应该如何选择？

A1：选择哪种模式取决于应用的具体需求：

  • 选择订阅/通知：当你需要对某个网络指标或状态进行持续监控，并在其发生特定变化（如超过阈值）时立即采取行动时。例如：自动化运维系统需要监控切片负载，一旦预测到拥塞就自动扩容；计费系统需要监控用户的特定业务使用事件以触发特殊计费策略。

  • 选择请求/响应：当你需要获取一个即时的、一次性的状态快照时。例如：网络运维人员在排查问题时，点击按钮查询某个用户的当前移动性预测；一个第三方应用在启动时，查询一次当前网络是否适合进行大文件下载。

Q2：NEF在分析暴露流程中扮演的角色是什么？为什么它如此重要？

A2：NEF（网络能力开放功能）是运营商网络能力的“安全网关”和“API市场”。在分析暴露流程中，它对外部AF（应用功能）至关重要，扮演多重角色：

  1. 安全屏障：NEF对外部AF进行身份验证和授权，确保只有合法的、被授权的应用才能访问网络内部的分析能力，防止核心网直接暴露在公网上。

  2. 抽象和简化：NEF可以向外部开发者提供更友好、更简单的API，隐藏内部核心网的复杂性。开发者只需与NEF的API交互，无需了解NWDAF的具体地址和内部接口细节。

  3. 策略控制与计费：运营商可以在NEF上配置各种策略，如限制某个AF的API调用频率（Rate Limiting），并对API的调用进行记录，作为向第三方开发者收费的依据。

Q3：如果一个NF同时订阅了多个分析事件，NWDAF是会分开通知还是一起通知？

A3：规范允许NWDAF将发往同一个notificationURI的多个事件通知聚合在一个HTTP POST请求中。在Nnwdaf_EventsSubscription_Notify的请求体中，eventNotifications是一个数组（list），可以包含多个独立的事件通知对象。这样做的好处是减少了信令交互的次数，提高了效率。例如，如果一个PCF同时订阅了某个用户的“移动性预测”和“QoS可持续性预测”，当这两个分析结果几乎同时生成时，NWDAF可以将它们打包在一次通知中发送给PCF。

Q4：订阅请求中的eventFilter（事件过滤器）具体有什么作用？

A4：eventFilter是订阅请求中非常关键的部分，它使得订阅变得更加精确和高效。如果没有过滤器，订阅一个UE_MOBILITY事件可能会导致NWDAF上报网络中所有用户的移动信息，这将引发信令风暴。通过使用过滤器，消费者可以精确地告诉NWDAF：“我只关心……”

  • 特定的用户：例如 supi = "..." 或 gpsi = "..."

  • 特定的区域：例如 areaOfInterest = { taiList: [...] }

  • 特定的网络切片：例如 snssai = "..."

  • 特定的应用：例如 applicationId = "..."

只有当事件与过滤器中定义的所有条件都匹配时，NWDAF才会生成并发送通知。这极大地减少了不必要的信令开销和消费者的处理负担。

Q5：为什么退订（Unsubscribe）操作使用的是HTTP DELETE方法，而不是POST？

A5：这遵循了RESTful API设计的最佳实践。在REST架构风格中，HTTP的几个主要方法（Verb）有其约定的语义：

  • POST：通常用于在服务器上创建一个新资源。在我们的场景中，POST /subscriptions就是创建一个新的订阅。

  • GET：用于读取或检索一个资源。例如，GET /analytics就是读取分析信息。

  • PUT/PATCH：用于更新或修改一个已存在的资源。例如，PUT /subscriptions/{id}可以用来修改一个订阅。

  • DELETE：用于删除一个已存在的资源。因此，DELETE /subscriptions/{id}的语义就是删除这个ID所代表的订阅，这与“退订”的业务逻辑完美匹配。

遵循这些标准约定，可以使API的设计更加清晰、直观和易于理解。

关系图谱