好的，我们继续本次的深度探索，进入5G智能网络的神经末梢，解析NWDAF如何感知和赋能网络功能的服务本身。

深度解析 3GPP TS 23.288：7 Nnwdaf Services Description (Nnwdaf服务描述)

本文技术原理深度参考了3GPP TS 23.288 V18.9.0 (2025-03) Release 18规范中，关于“7 Nnwdaf Services Description”的核心章节。本文旨在为读者提供一份NWDAF对外开放的服务化接口（SBI）的“官方API文档”，系统性地梳理NWDAF“小慧”都提供了哪些标准化的“能力接口”，以及这些接口是如何支撑起我们在第6章中探讨的各种复杂分析流程的。

在前面的章节中，我们已经通过各种场景，生动地了解了NWDAF能够完成的诸多智能任务，从切片负载预测到用户移动性分析，再到PDU会话流量审计。我们知道，这些能力的实现都依赖于NWDAF与消费者（AMF, PCF, AF等）之间的交互。

那么，这些交互在技术层面是如何被精确定义的？当PCF想要“订阅”一个分析，它具体应该调用哪个服务的哪个操作？当NWDAF想要“通知”一个结果，它又该如何组织消息？

第7章正是这份最权威、最底层的“API说明书”。它从服务化架构（SBA）的视角，将NWDAF的所有能力，都封装成了一系列定义清晰、接口规范的服务。对于希望与NWDAF集成的开发者（无论是网络功能开发者还是应用开发者）来说，本章是无可替代的“开发指南”。

1. NWDAF的“能力清单”：服务概览 (TS 23.288 Clause 7.1)

7.1节通过一张核心表格 Table 7.1-1，为我们完整地展示了NWDAF对外提供的所有服务“菜单”。

Table 7.1-1 illustrates the NWDAF Services.

这张表格是理解NWDAF能力边界的“索引”。让我们逐一解读其中最重要的几个服务。

表格用途解读与重绘 (节选核心服务):

Table 7.1-1: NF services provided by NWDAF

Service Name	Service Operations	Operation Semantics	Example Consumer(s)
Nnwdaf_AnalyticsSubscription	Subscribe, Unsubscribe, Notify, Transfer	Subscribe / Notify	PCF, NSSF, AMF, SMF, NEF, AF, OAM, CEF, NWDAF, DCCF, LMF, ADRF
Nnwdaf_AnalyticsInfo	Request, ContextTransfer	Request / Response	(同上)
Nnwdaf_DataManagement	Subscribe, Notify, Fetch	Subscribe / Notify, Request / Response	NWDAF, DCCF, MFAF, ADRF
Nnwdaf_MLModelProvision	Subscribe, Unsubscribe, Notify	Subscribe / Notify	NWDAF
Nnwdaf_MLModelInfo	Request	Request / Response	NWDAF
Nnwdaf_RoamingAnalytics	Subscribe, Request, etc.	Subscribe / Notify, Request / Response	H-RE-NWDAF, V-RE-NWDAF
…	…	…	…

这份清单告诉我们，“小慧”的能力被精心打包成了几个独立的“微服务”，每个服务都聚焦于一类特定的交互模式。

2. 核心服务深度剖析

2.1 Nnwdaf_AnalyticsSubscription 服务：智能订阅的核心

这是NWDAF最核心、最常用的服务，支撑着我们在6.1.1节探讨的“订阅/通知”模式。

• Subscribe 操作 (7.2.2):

  Description: Subscribes to NWDAF analytics and optionally Analytics Accuracy Information with specific parameters.

  这是消费者发起订阅的入口。我们在6.1.3节详细讨论过的所有输入参数（Analytics ID, Target, Filter, Reporting Info等）都在这个操作的输入参数（Inputs, Required/Optional）中被精确定义。

  • Inputs, Required: (Set of) Analytics ID(s), Target of Analytics Reporting, Notification Target Address…
  • Inputs, Optional: Analytics Filter Information, Reporting Thresholds, Analytics Accuracy Request information…
  • Outputs, Required: 成功时返回Subscription Correlation ID，失败时返回错误。这个ID是后续管理（修改、删除）该订阅的唯一凭证。

• Unsubscribe 操作 (7.2.3): 消费者使用Subscribe操作返回的Subscription Correlation ID，来取消一个已经存在的订阅。

• Notify 操作 (7.2.4): 这是由NWDAF发起的操作，用于向消费者推送分析结果。

  • Inputs, Required: Notification Correlation Information (用于让消费者匹配是哪个订阅的通知)。
  • Inputs, Optional: Set of the tuple (Analytics ID, Analytics specific parameters) (即分析结果本身), Termination Request (当NWDAF决定终止该订阅时)。

• Transfer 操作 (7.2.5): 支撑6.1B节“分析订阅迁移”流程的核心操作。源NWDAF通过调用目标NWDAF的此操作，来请求转移一个或多个分析订阅。

2.2 Nnwdaf_AnalyticsInfo 服务：即时问答的窗口

这个服务支撑着“请求/响应”模式，用于一次性的分析查询。

• Request 操作 (7.3.2):

  Description: The consumer requests NWDAF operator specific analytics and optionally Analytics Accuracy Information.

  消费者通过此操作发起一次性查询。其输入参数与Subscribe操作非常相似，但不包含Notification Target Address，因为结果将通过本操作的响应消息直接返回。

  • Outputs, Required: 成功时，响应消息中直接包含set of the tuple (Analytics ID, Analytics specific parameters)，即分析结果。

• ContextTransfer 操作 (7.3.3): 支撑6.1B节“分析上下文迁移”流程的核心操作。目标NWDAF通过调用源NWDAF的此操作，来请求获取与某个订阅相关的历史上下文。

  • Inputs, Required: (Set of) Analytics context identifier(s) (用于标识需要哪个订阅的上下文)。
  • Outputs, Required: (Set of) Analytics Context (即6.1B.4中定义的详细上下文内容)。

2.3 Nnwdaf_DataManagement 服务：NWDAF间的数据交换

当NWDAF作为消费者，需要从另一个NWDAF（或DCCF）获取原始数据或中间数据（而非最终分析结果）时，会使用此服务。例如，聚合器NWDAF从下属NWDAF获取数据。

• Subscribe 操作 (7.4.2): 订阅数据。
• Fetch 操作 (7.4.5): 主动拉取数据。
• Notify 操作 (7.4.4): 用于数据提供方推送数据。

这个服务与Nnwdaf_AnalyticsSubscription的区别在于，它的关注点是“数据(Data)”本身，而AnalyticsSubscription的关注点是“分析(Analytics)”。

2.4 Nnwdaf_MLModelProvision 和 Nnwdaf_MLModelInfo 服务：AI模型的“供应链”

这两个服务共同构建了MTLF与AnLF之间的ML模型交付体系。

• Nnwdaf_MLModelProvision: 一个订阅式服务。AnLF向MTLF订阅某个分析所需的ML模型。当MTLF训练出新的或更新的模型时，会通过Notify操作主动推送给AnLF。
• Nnwdaf_MLModelInfo: 一个请求式服务。AnLF可以一次性向MTLF查询某个分析当前有哪些可用的ML模型。

3. 分析能力与服务的映射关系

Table 7.1-2是另一张至关重要的表格，它建立了分析ID (Request Description) 与分析输出内容 (Response Description) 之间的明确映射关系。

表格用途解读与重绘 (节选):

Table 7.1-2: Analytics information provided by NWDAF service

Analytics Information (分析主题)	Request Description (请求时使用的Analytics ID)	Response Description (响应中包含的内容)
Slice Load level information	Analytics ID: load level information	提供了网络切片/实例的UE注册数、PDU会话数、资源利用率等负载统计或预测。
Observed Service experience information	Analytics ID: Service Experience	提供了针对网络切片或应用的业务体验（如MOS分）的统计或预测。
UE mobility information	Analytics ID: UE Mobility	提供了UE移动性的统计或预测。
UE Abnormal behaviour information	Analytics ID: Abnormal behaviour	提供了异常行为（如被劫持、滥用）的UE列表及相关异常事件信息。
…	…	…

这张表格就像是“小慧”对外发布的“产品目录”。消费者通过查阅这张表，可以清楚地知道：

• 为了获取“切片负载信息”，我应该在请求中设置Analytics ID = "load level information"。
• 当我请求了这个ID后，我预期会在响应中收到包含“UE注册数”、“PDU会话数”等字段的数据结构。

这为不同厂商、不同NF之间的互联互通提供了统一的、无歧义的语义标准。

4. 总结

第7章通过一种高度结构化、标准化的方式，将NWDAF的所有复杂能力，解构为一系列清晰的服务化接口（SBI）。对于5G核心网而言，这一章的意义如同Web世界的RESTful API文档。

• 标准化封装: 将复杂的内部AI逻辑，封装成消费者易于理解和调用的标准服务。
• 模式分离: 清晰地区分了“订阅/通知” (AnalyticsSubscription) 和“请求/响应” (AnalyticsInfo) 两种核心交互模式，满足不同业务场景的需求。
• 职责清晰: 为分析订阅、即时查询、数据管理、模型供应、漫游交互等不同功能，定义了专门的服务，使得整个系统职责分明，易于扩展和维护。
• 语义统一: 通过Analytics ID和Table 7.1-2，为全行业定义了一套统一的“网络智能语言”，确保了不同厂商实现之间的互操作性。

理解了第7章，就相当于拿到了开启NWDAF能力宝库的“钥匙”。它将前面章节中描述的各种流程和功能，真正落实到了可以编码和实现的协议层面，是NWDAF从概念走向现实的桥梁。

---

FAQ - 常见问题解答

Q1：Nnwdaf_AnalyticsSubscription 和 Nnwdaf_AnalyticsInfo 这两个服务，我应该如何选择？ A1：选择哪个服务取决于你的应用场景的实时性和持续性需求。

• 如果你需要持续监控一个指标，并希望在指标变化或达到阈值时被动接收通知，请使用 Nnwdaf_AnalyticsSubscription 服务。例如，PCF需要7x24小时监控网络切片负载。
• 如果你只需要一次性、按需查询某个当前的或历史的分析结果，请使用 Nnwdaf_AnalyticsInfo 服务。例如，运维人员在处理告警时，需要临时查询某个UE过去的移动轨迹。

Q2：Subscription Correlation ID 和 Notification Correlation ID 有什么区别？ A2：这两个ID都是用于关联，但方向和作用不同。

• Subscription Correlation ID: 是NWDAF在接受订阅时生成的，并返回给消费者。它像一个“订阅合同号”。消费者后续如果想修改或取消这个订阅，就需要提供这个ID。
• Notification Correlation ID: 是消费者在发起订阅时提供给NWDAF的。它像一个“收件人识别码”。当NWDAF发送Notify消息时，会原样带回这个ID，这样消费者就能知道这个通知是对应于自己当初发起的哪个订阅请求（因为一个消费者可能同时有多个订阅）。

Q3：为什么需要一个单独的 Nnwdaf_DataManagement 服务？不能都用 AnalyticsSubscription 吗？ A3：设立Nnwdaf_DataManagement服务是为了区分数据（Data）和分析（Analytics）的交换。AnalyticsSubscription交换的是NWDAF处理后的最终分析成品，包含洞察和预测。而DataManagement交换的是用于生成分析的原始数据或中间数据。例如，聚合器NWDAF需要的是下属NWDAF的原始统计数据（Data），而不是已经封装好的、带置信度的最终预测报告（Analytics）。这种区分使得服务语义更清晰，接口设计更简洁。

Q4：作为一名应用开发者，如果我想使用NWDAF的能力，我需要直接调用这些gRPC-like的服务接口吗？ A4：不一定。通常情况下，第三方应用开发者会通过**NEF（网络开放功能）**来访问NWDAF。NEF会将这些核心网内部的、基于3GPP协议的服务接口，再次封装成对外部开发者更友好的、基于RESTful API或SDK的形式。开发者只需要调用NEF提供的API，而NEF会在后台负责将这些API调用转换为对Nnwdaf_AnalyticsSubscription或Nnwdaf_AnalyticsInfo等服务的调用，并处理安全、鉴权、计费等事宜。

Q5：Analytics ID 的列表是固定的吗？未来可以增加新的分析类型吗？ A5：Analytics ID的列表是随着3GPP版本的演进而不断扩展的。每个新的Release版本都可能根据行业发展和新的业务需求，增加新的标准Analytics ID。例如，Release 17和18就增加了如“Redundant Transmission Experience”、“Dispersion Analytics”等新的分析类型。此外，运营商也可以在自己的网络内部，定义和使用私有的、非标准的Analytics ID，但这需要在NWDAF和相关消费者之间进行私有协议的约定。