好的,我们立刻开始对3GPP TS 29.575规范的核心服务——Nadrf_DataManagement——进行深度剖析。在上一篇中,我们已经了解了ADRF的宏观服务划分。现在,我们将聚焦于其最核心、功能最丰富的Nadrf_DataManagement服务,逐一检视其令人眼花缭乱的服务操作。
深度解析 3GPP TS 29.575:4.2 Nadrf_DataManagement Service (Part 1 - 数据存储与订阅)
本文技术原理深度参考了3GPP TS 29.575 V18.8.0 (2025-03) Release 18规范中,第四章4.2节“Nadrf_DataManagement Service”的前半部分核心内容。本文旨在为读者深度剖析ADRF作为“数据保险库”的写入和订阅式写入机制,我们将详细拆解
StorageRequest、StorageSubscriptionRequest和StorageSubscriptionRemoval这三大服务操作的业务逻辑与交互流程。
引言:ADRF的数据入库艺术——“直接存款”与“定期自动转账”
ADRF作为5G网络的“中央数据银行”,其首要任务就是安全、可靠地接收和存储来自各个“储户”(DCCF, NWDAF, MFAF)的“数字资产”(数据和分析结果)。为了满足不同的存储需求,ADRF提供了两种核心的“存款”方式:
- 直接存款 (
StorageRequest): 就像我们去银行柜台办理一次性的存款。数据生产者(如NWDAF)在完成一次分析后,将生成的报告直接提交给ADRF进行存储。这是一个简单、直接的原子操作。 - 定期自动转账 (
StorageSubscriptionRequest): 就像我们设置一个银行的自动转账协议。数据消费者(如一个需要长期存档数据的NWDAF)可以委托ADRF:“请你每月初自动去‘数据源’(另一个NWDAF或DCCF)那里,把他们最新的月报取来,存入我的账户”。这是一种强大的“代理存储”或“订阅式存储”模式。
本篇文章,我们将化身为一位“数据储户”,详细学习如何办理这两种“存款”业务,以及如何取消“自动转账”协议(StorageSubscriptionRemoval)。
1. 解读第4.2.1章 Nadrf_DataManagement Service Description (服务描述)
本节从宏观上定义了该服务的消费者和架构。
3GPP TS 29.575 - 4.2.1.1 Overview
This service:
- allows NF service consumers to store data or analytics in the ADRF…
- allows NF service consumers to retrieve data or analytics from an ADRF; and
- allows NF service consumers to delete data or analytics from an ADRF.
架构图 (Figure 4.2.1.2-1) 清晰地展示了其核心消费者:
- DCCF, NWDAF, MFAF: 它们既是数据的生产者(需要存储),也是数据的消费者(需要检索),是ADRF最主要的交互方。
2. 解读第4.2.2章 Service Operations (服务操作) - 存储类操作详解
本节是功能逻辑的核心,Table 4.2.2.1-1 为我们列出了Nadrf_DataManagement服务的完整操作清单。我们将首先聚焦于前三个与“存储”相关的操作。
2.1 4.2.2.2 StorageRequest service operation (一次性存储请求)
The Nadrf_DataManagement_StorageRequest service operation is used by an NF service consumer to store data or analytics.
信令流程 (Figure 4.2.2.2.2-1: NF service consumer requesting to store data or analytics):
这张图展示了最直接的“直接存款”流程。
步骤1: 消费者 发起 POST 请求
1. POST .../data-store-records
-
场景链接: NWDAF-Analyst-01完成了一次关于A区域网络切片性能的分析,生成了一份详细的JSON格式报告。
-
动作: NWDAF向ADRF的
/data-store-records资源集合发起一个HTTPPOST请求。 -
请求体 (
NadrfDataStoreRecord): 这是“存款单”,包含了要存储的“货币”。The NadrfDataStoreRecord data structure provided in the request body shall include: one of the following:
- analytics subscription notification(s) within the “anaNotifications” attribute…
- data subscription notification within the “dataNotif” attribute…
请求体必须包含
anaNotifications(分析数据)或dataNotif(原始数据)之一。此外,还可以包含storeHandl(存储处理指令,如生命周期)和dataSetTag(数据集标签)等可选信息。
步骤2: ADRF 返回 201 Created 响应
2. "201 Created"
- ADRF收到数据后,会:
- 创建一个新的“数据存储记录”资源。
- 分配一个唯一的存储事务ID (
storeTransId)。 - 持久化存储数据。
- 响应: 返回
201 Created。Location头包含了新创建记录的URI,形如.../data-store-records/{storeTransId}。这个ID是本次“存款”的唯一“回执单号”。- 响应体中包含了已创建记录的表示。
2.2 4.2.2.3 StorageSubscriptionRequest service operation (存储订阅请求)
The Nadrf_DataManagement_StorageSubscriptionRequest service operation is used by an NF service consumer to request that the ADRF creates a subscription to data or analytics and subsequently stores notified data or analytics in the ADRF.
信令流程 (Figure 4.2.2.3.2-1: NF service consumer requesting that the ADRF subscribes...):
这张图展示了“设置定期自动转账”的流程。
步骤1: 消费者 发起 POST 请求
1. POST .../request-storage-sub
- 场景链接: NWDAF-Archivist-01的任务是长期存档某个关键业务的所有网络分析报告。这些报告由另一个NWDAF-Producer-01持续生成。
- 动作: NWDAF-Archivist向ADRF的一个自定义操作URI
/request-storage-sub发起POST请求。 - 请求体 (
NadrfDataStoreSubscription): 这是“自动转账授权书”,内容非常丰富:- 订阅属性:
anaSub(分析订阅信息)或dataSub(数据订阅信息)之一,定义了ADRF应该去订阅什么。 - 目标标识:
targetNfId或targetNfSetId之一,定义了ADRF应该去向谁订阅。 - 处理/存储指令:
formatInstruct,procInstruct,storeHandl等,定义了ADRF从源头拿到数据后,在存入自己仓库前,是否需要进行预处理。
- 订阅属性:
步骤2: ADRF 返回 200 OK 响应
2. "200 OK"
- ADRF收到请求后,会:
- 验证请求的合法性。
- 在内部创建一个“存储订阅”任务。
- 向
targetNfId(即NWDAF-Producer-01)发起一个底层的事件/数据订阅。 - 分配一个事务参考ID (
transRefId) 作为本次“自动转账协议”的编号。
- 响应: 返回
200 OK。- 响应体 (
NadrfDataStoreSubscriptionRef): 包含了这个transRefId。消费者需要保存好这个ID,用于后续取消该协议。
- 响应体 (
2.3 4.2.2.4 StorageSubscriptionRemoval service operation (存储订阅移除)
The Nadrf_DataManagement_StorageSubscriptionRemoval service operation is used by an NF service consumer to request the ADRF to remove a subscription for data or analytics.
信令流程 (Figure 4.2.2.4.2-1: NF service consumer requesting the removal of subscription(s)...):
这张图展示了“取消自动转账”的流程。
步骤1: 消费者 发起 POST 请求
1. POST .../request-storage-sub-removal
- 场景链接: 存档任务结束。
- 动作: NWDAF-Archivist向ADRF的自定义操作URI
/request-storage-sub-removal发起POST请求。 - 请求体 (
NadrfDataStoreSubscriptionRef): “取消授权书”,其中包含了之前获取的transRefId或dataSetId,以指明要取消哪个“自动转账协议”。
步骤2: ADRF 返回 204 No Content 响应
2. "204 No Content"
- ADRF收到请求后,会找到对应的存储订阅任务,并取消对上游数据源的订阅。
- 响应: 返回
204 No Content,表示“协议已成功取消”。
总结
通过对ADRF数据存储类操作的深度剖析,我们已经掌握了向这座“数据银行”存入资产的两种核心方式。
-
两种存储模式: ADRF通过
StorageRequest和StorageSubscriptionRequest两个不同的服务操作,清晰地区分了一次性数据存储和订阅式数据存储两种业务场景,提供了极大的灵活性。 -
资源与动作的分离:
- 一次性存储 (
StorageRequest) 被建模为向/data-store-records集合资源的POST操作,完全符合RESTful的资源创建语义。 - 订阅式存储 (
StorageSubscriptionRequest) 则被建模为调用一个自定义操作 (/request-storage-sub),更好地体现了其“触发一个后台长期任务”的RPC风格业务本质。
- 一次性存储 (
-
强大的代理与处理能力:
StorageSubscriptionRequest操作揭示了ADRF不仅仅是一个被动的仓库,它还能扮演主动的数据订阅代理和轻量级ETL处理器的角色,可以在数据入库前进行格式化和处理,功能非常强大。
我们已经学会了如何将数据安全地存入ADRF。在下一篇文章中,我们将把视角切换到“取款”业务,深入RetrievalRequest, RetrievalSubscribe, RetrievalNotify等操作,看看如何从这座“数据金库”中查询和订阅我们所需的信息。
FAQ
Q1:StorageRequest和StorageSubscriptionRequest在使用场景上有什么根本不同?
A1:根本区别在于数据流的发起方和控制权。
StorageRequest: 数据流由数据生产者(如NWDAF)发起和控制。生产者在自己认为合适的时机,主动将数据“推”给ADRF。StorageSubscriptionRequest: 数据流由最终的数据消费者(或其代理DCCF)发起和控制。消费者委托ADRF,主动从数据源“拉”取数据并存储。 这两种模式分别对应了“生产者推送”和“消费者驱动的拉取-存储”两种经典的数据集成模式。
Q2:在StorageSubscriptionRequest中,ADRF是如何知道去哪里订阅数据的?
A2:请求体NadrfDataStoreSubscription中包含了targetNfId(目标NF实例ID)或targetNfSetId(目标NF Set ID)字段。消费者必须指定它希望ADRF去向哪个具体的NF实例或NF Set进行订阅。ADRF会利用这个ID,通过NRF进行服务发现,找到目标NF的数据暴露接口(例如,Nnwdaf_AnalyticsInfo服务),然后发起订阅。
Q3:storeTransId和transRefId这两个ID有什么区别?
A3:它们分别对应两种不同存储操作的“回执单号”。
storeTransId: 是**StorageRequest(一次性存储)操作成功后返回的ID。它唯一标识了一个已存储的数据记录**。你可以凭这个ID去DELETE或GET这条特定的记录。transRefId: 是**StorageSubscriptionRequest(存储订阅)操作成功后返回的ID。它唯一标识了一个存储订阅协议或任务**。你可以凭这个ID去StorageSubscriptionRemoval来取消这个订阅任务,但不能用它来直接获取数据。
Q4:为什么StorageSubscriptionRequest和StorageSubscriptionRemoval要使用POST自定义操作,而不是像RetrievalSubscribe那样使用POST到集合资源的方式?
A4:这可能是一个API设计风格的选择,为了清晰地区分“数据操作”和“元数据/任务操作”。
- 所有直接操作数据本身的订阅(如检索订阅
RetrievalSubscribe),被建模为对/data-retrieval-subscriptions集合资源的POST。 - 而触发后台任务的订阅(如存储订阅
StorageSubscriptionRequest),则被建模为对一个“动作”型URI的POST。 这种区分虽然不是RESTful的唯一方式,但有助于在逻辑上将两种不同性质的订阅操作分离开来。
Q5:ADRF在执行存储订阅时,如果从上游数据源收到了大量通知,会如何处理?会成为性能瓶颈吗? A5:ADRF必须被设计为高性能、高吞吐的系统。它内部通常会有一个消息队列或缓冲池来接收来自上游数据源的通知。收到通知后,它会将数据写入任务放入一个异步处理队列,由后台的工作线程池来执行实际的持久化存储操作。这种异步、批量处理的机制,可以有效地削峰填谷,防止被突发的数据洪流冲垮,确保了其作为中央数据仓库的稳定性和可靠性。