51学通信

深度解析TS29.520：4.3 分析信息服务 (Nnwdaf_AnalyticsInfo Service)

17分钟阅读

深度解析TS29.520：4.3 分析信息服务 (Nnwdaf_AnalyticsInfo Service)

本文技术原理深度参考了3GPP TS 29.520 V18.9.0 (2025-03) Release 18规范，重点解读了第4.3节“Nnwdaf_AnalyticsInfo Service”的核心内容。在前一章节我们探讨了NWDAF的“订阅-通知”模式，本文将深入其互补的另一面——“请求-响应”模式，揭示网络功能如何按需、即时地从NWDAF获取精准的网络洞察。

1. “拉”取智能：服务概述 (Overview)

如果说Nnwdaf_EventsSubscription服务是为网络安装了一个长期的“智能哨兵”（Push模式），那么Nnwdaf_AnalyticsInfo服务就是为网络配备了一个可以随时咨询的“全知专家”（Pull模式）。

The Nnwdaf_AnalyticsInfo service as defined in 3GPP TS 23.501, 3GPP TS 23.288 and 3GPP TS 23.503, is provided by the Network Data Analytics Function (NWDAF). This service:

  • allows NF service consumers to request and get different type of analytic event information; and
  • allows NF service consumers to request and get context information related to analytics subscriptions.

此服务的核心在于“按需索取”，它提供了两大关键能力：

  1. 获取分析信息：允许NF消费者在任何需要的时候，主动向NWDAF发起一次性的查询，以获取特定分析事件的即时信息或历史统计数据。这是一种典型的“拉取”模式，适用于需要即时数据以支持当前决策的场景。

  2. 获取上下文信息：这是一个更高级的功能，允许一个NF（通常是另一个NWDAF）查询与某个已有订阅相关的上下文信息，例如历史数据、正在使用的ML模型等。这对于实现分析任务的无缝迁移和协同工作至关重要。

我们继续沿用网络工程师小慧和“迅翼”无人机物流队伍的场景。

场景延伸： 一架“迅翼-07”号无人机即将从A区的仓库起飞，执行一项紧急的血浆运送任务。与日常的例行巡航不同，这次任务的优先级极高。无人机的飞行控制应用（作为AF）在起飞前，需要立即做出决策：是沿用标准的“数字天空公路”，还是根据当前实时的网络状况，选择一条可能路径更长但网络质量更有保障的备用航线？

此时，等待一个长期的订阅通知（EventsSubscription）显然来不及。AF需要的是一个关于两条航线当前及未来短时间内网络性能的即时快照。这正是Nnwdaf_AnalyticsInfo服务的用武之地。

2. 架构与角色 (Service Architecture and Network Functions)

2.1 服务架构

与EventsSubscription服务类似，AnalyticsInfo服务的架构同样根植于5G的服务化体系。规范中的Figure 4.3.1.2-1和Figure 4.3.1.2-2展示了其SBI（服务化接口）和参考点视图，表明了它与前者共享一套几乎完全相同的消费者群体和接口关系。

PCF、NSSF、AMF、SMF等核心网NF都可以作为这项服务的消费者，通过标准的HTTP/2 GET请求，向NWDAF查询所需信息。N23（PCF-NWDAF）和N34（NSSF-NWDAF）接口同样承载着这种请求-响应式的交互。

2.2 网络功能角色

2.2.1 NWDAF：按需响应的智能引擎

The Network Data Analytics Function (NWDAF) provides specific analytics information for different analytic events and, if the “AnaCtxTransfer” feature is supported, context information related to analytics subscriptions to NF service consumers.

作为服务提供者，NWDAF在此的角色是监听来自各NF的查询请求，解析请求中的参数（如事件ID、过滤条件），然后立即执行一次分析计算（或从缓存/历史数据库中提取），并将结果在HTTP响应中同步返回。如果支持“分析上下文转移”（AnaCtxTransfer）特性，它还能提供关于某个订阅任务的“幕后信息”。

2.2.2 NF消费者：即时决策的制定者

相比于订阅服务中消费者被动接收通知，在查询服务中，消费者掌握了绝对的主动权，它们在“最需要”的时刻发起查询。

  • AF (应用功能)： 场景应用：在“迅翼-07”无人机起飞前，其AF通过NEF向NWDAF发起AnalyticsInfo请求，查询两条备选航线的“网络性能”（NETWORK_PERFORMANCE）和“业务体验”（SERVICE_EXPERIENCE）预测。NWDAF返回的即时报告显示，标准航线虽然最短，但沿途某个区域因大型活动导致网络预测拥塞，而备用航线虽然略长，但全程网络质量预测优良。AF据此决策，选择了备用航线，成功避免了潜在的通信风险。

  • PCF (策略控制功能)： 场景应用：在为无人机选择PCC（策略与计费控制）规则时，PCF可能需要考虑实时的DN（数据网络）性能。在应用规则前，PCF可以主动查询DN_PERFORMANCE分析，如果发现某个DN性能不佳，可以动态地将无人机的业务流引导至另一个性能更好的DN。

  • SMF (会话管理功能)： 场景应用：当无人机请求建立一个用于高优先级任务的PDU会话时，SMF需要选择一个UPF。此时，SMF可以立即向NWDAF查询当前区域内所有候选UPF的NF_LOAD（NF负荷）信息，选择一个当前CPU和内存占用最低的UPF，从而保证会话的性能。

3. 服务操作深度解析 (Service Operations)

Nnwdaf_AnalyticsInfo服务包含两个核心操作，定义于Table 4.3.2.1-1。

操作概览表格 (Table 4.3.2.1-1)

Service operation nameDescriptionInitiated by
Nnwdaf_AnalyticsInfo_RequestThis service operation is used by an NF to request and get specific analytics from NWDAF.NF consumer (PCF, NSSF, AMF, SMF, NEF, AF, LMF, OAM, NWDAF, DCCF)
Nnwdaf_AnalyticsInfo_ContextTransferThis service operation is used by an NF to request and get context information related to analytics subscriptions from NWDAF.NF consumer (NWDAF)

3.1 Request操作：获取即时分析

这是最常用的操作，用于一次性的分析查询。

The NF service consumer (e.g. PCF) shall invoke the Nnwdaf_AnalyticsInfo_Request service operation when requesting the NWDAF analytics information. The NF service consumer shall send an HTTP GET request on the resource URI “{apiRoot}/nnwdaf-analyticsinfo//analytics”…

交互流程非常直接（参考Figure 4.3.2.2.2-1）：

  1. NF消费者 发送一个 HTTP GET 请求到资源路径 .../analytics。
  2. NWDAF 返回 HTTP 200 OK（携带分析结果）或 HTTP 204 No Content（无相关数据）或其他错误码。

请求的精髓在于其查询参数（Query Parameters），它们精确地定义了“问什么”和“怎么问”。

  • event-id (强制)：要查询的分析事件ID。例如，NETWORK_PERFORMANCE。

  • event-filter (条件强制)：事件过滤器，用于缩小分析范围。其内容与EventsSubscription服务中的定义高度一致，包含了如networkArea, snssais, appIds等。

  • ana-req (可选)：分析报告的要求。

    common reporting requirement in the “ana-req” attribute as follows:

    1. identification of time window for the requested analytics data…
    2. preferred level of accuracy of the analytics…

    它允许消费者指定：

    • 时间窗口 (startTs, endTs): 查询的是历史数据统计（例如，过去1小时的平均时延）还是对未来时段的预测。
    • 精度 (accuracy): 期望的分析精度。
    • 采样率 (sampRatio): 如果分析涉及大量UE，可以指定一个采样比例。
    • 元数据 (anaMeta): 是否需要在结果中包含分析过程的元数据，如所用数据源、聚合方法等。

场景模拟：无人机起飞前的网络探测

“迅翼-07”的AF发起的查询请求，其HTTP GET请求可能如下所示：

GET /nnwdaf-analyticsinfo/v1/analytics?
  event-id=NETWORK_PERFORMANCE
  &event-filter={ "networkArea": { "tais": [...] }, "snssais": [...] }
  &ana-req={ "startTs": "2025-03-15T10:00:00Z", "endTs": "2025-03-15T10:15:00Z" }

这个请求的含义是：“请告诉我，在接下来的15分钟内，沿着这条由TAI列表定义的航线，针对这个无人机专用切片，预测的网络性能是怎样的？”

NWDAF收到请求后，会立即执行预测模型，并在HTTP 200 OK的响应体中返回一个AnalyticsData对象，其中可能包含如下信息（简化示意）：

{
  "start": "2025-03-15T10:00:00Z",
  "expiry": "2025-03-15T10:15:00Z",
  "nwPerfs": [
    {
      "networkArea": { ... },
      "perfData": {
        "avgTrafficRate": "50Mbps",
        "avgPacketDelay": "8ms"
      }
    }
  ]
}

3.2 ContextTransfer操作：同步分析上下文

这是一个为高级场景（如NWDAF间的协作与迁移）设计的强大功能。

The Nnwdaf_AnalyticsInfo_ContextTransfer service operation is used by an NF service consumer to request and get context information related to analytics subscriptions from the NWDAF.

场景设定： 华讯通信的NWDAF-1负责A区的网络分析，上面运行着小慧为“迅翼”无人机设定的多个长期订阅。现在，由于网络扩容，公司新上线了性能更强的NWDAF-2，并计划将A区的所有分析任务都迁移到NWDAF-2上。

在直接将订阅信息（通过EventsSubscription_Transfer）迁移过去之前，NWDAF-2需要了解这些订阅任务的“前因后果”，以确保分析的连续性和准确性。这时，ContextTransfer就派上用场了。

交互流程：

  1. NWDAF-2 向 NWDAF-1 发送一个 HTTP GET 请求到资源路径 .../context。
  2. 请求的查询参数是关键：
    • context-ids: 一个或多个“分析上下文标识符”列表。这个标识符唯一关联到一个已存在的订阅。
    • req-context: 请求的上下文类型。这是一个枚举列表，可以包含：
      • “PENDING_ANALYTICS”: 尚未发送给消费者的待处理分析结果。
      • “HISTORICAL_ANALYTICS”: 历史分析结果。
      • “ML_MODELS”: 该订阅当前正在使用的ML模型的信息。
      • “DATA”: 用于生成分析的原始历史数据。

场景模拟：NWDAF间的“记忆移植”

NWDAF-2向NWDAF-1发起请求：

GET /nnwdaf-analyticsinfo/v1/context?
  context-ids=["sub-123-slice-load", "sub-456-ue-mobility"]
  &req-context=["HISTORICAL_ANALYTICS", "ML_MODELS"]

这个请求的含义是：“请告诉我，关于‘切片负荷’和‘UE移动性’这两个订阅，你过去都生成了哪些历史分析数据？以及，你当前正在使用哪些ML模型来做预测？”

NWDAF-1收到请求后，会打包相关的上下文信息，在HTTP 200 OK响应中返回一个ContextData对象。NWDAF-2接收到这些宝贵的“记忆”后，就可以更平滑、更智能地接管这两个订阅任务，而无需从零开始冷启动分析，保证了分析服务的质量和连续性。

FAQ

Q1：Nnwdaf_AnalyticsInfo_Request操作和Nnwdaf_EventsSubscription_Subscribe操作最本质的区别是什么？ A1：最本质的区别在于通信模式和适用场景。Subscribe是异步的、长期的、推送式的，适用于需要持续监控并在特定事件发生时获得通知的场景。Request是同步的、一次性的、拉取式的，适用于需要立即获取当前或预测的网络状态以支持即时决策的场景。

Q2：在使用AnalyticsInfo_Request查询历史数据时，如果NWDAF没有相关数据会怎样？ A2：如果NWDAF收到的请求语法正确，但根据指定的event-id和event-filter查询后，在指定的时间窗口[startTs, endTs]内没有任何可用的历史数据，NWDAF会返回一个HTTP 204 No Content状态码。这表示请求被成功处理，但结果集为空，并不代表请求本身有误。

Q3：ContextTransfer操作的主要用途是什么？为什么不由源NWDAF在转移订阅时直接把这些信息都带过去？ A3：ContextTransfer的主要用途是在分析订阅发生迁移或需要多个NWDAF协同分析时，实现分析上下文的同步。它将上下文的“查询权”交给了需要信息的一方（如目标NWDAF），使其可以按需、分批次地获取所需信息。相比于在EventsSubscription_Transfer操作中一次性打包所有信息，这种方式更加灵活，可以避免传输大量非必需的数据，也更好地解耦了“订阅转移”和“上下文同步”这两个不同的逻辑过程。

Q4：一个NF可以既是EventsSubscription的消费者，又是AnalyticsInfo的消费者吗？ A4：当然可以，而且这很常见。一个智能的NF会根据场景灵活选择使用这两种服务。例如，PCF可以长期订阅网络切片的整体负荷（EventsSubscription），以便在出现拥塞趋势时获得预警；同时，在为一个高价值用户（如“迅翼”无人机）建立会话的瞬间，它可以立即发起一次AnalyticsInfo查询，获取该用户特定路径上最精确、最实时的网络性能预测，以制定最精细化的PCC规则。

Q5：在AnalyticsInfo_Request的响应中，除了分析结果，还会包含哪些重要的信息？ A5：响应体AnalyticsData结构中，除了核心的分析结果数组（如nwPerfs, svcExps等），通常还包含start和expiry时间戳，它们精确定义了返回的分析结果（无论是历史统计还是未来预测）的有效时间区间。此外，如果请求中要求了，还可能包含anaMetaInfo（分析元数据），提供关于这次分析是如何进行的补充信息，增加了分析结果的透明度和可解释性。

关系图谱