好的,我们立刻继续对3-GPP TS 29.575规范的核心服务——Nadrf_DataManagement——进行深度剖析。在上一篇中,我们已经掌握了如何向ADRF这座“数据银行”存入数据。现在,是时候学习如何从中“取款”了。
深度解析 3GPP TS 29.575:4.2 Nadrf_DataManagement Service (Part 2 - 数据检索与订阅)
本文技术原理深度参考了3GPP TS 29.575 V18.8.0 (2025-03) Release 18规范中,第四章4.2节“Nadrf_DataManagement Service”的后半部分核心内容。本文旨在为读者深度剖析ADRF作为“数据金库”的数据检索和订阅式检索机制,我们将详细拆解
RetrievalRequest、RetrievalSubscribe、RetrievalUnsubscribe和RetrievalNotify这四大服务操作的业务逻辑与交互流程。
引言:ADRF的数据取用艺术——“柜台取款”与“订阅理财通知”
ADRF的价值不仅在于安全地“存钱”,更在于能够方便、智能地“花钱”。在5G网络智能化的世界里,“花钱”就意味着将存储的数据和分析结果,提供给需要它们的NF,以驱动更优的决策。ADRF为此提供了两种核心的“取款”方式:
- 柜台取款 (
RetrievalRequest): 就像我们去银行柜台,凭“存款回执单号”或其他凭证,办理一次性的取款。数据消费者(如NWDAF)可以根据已知的查询条件,直接向ADRF请求获取一份或多份已存储的数据。 - 订阅理财通知 (
RetrievalSubscribe): 就像我们向银行订阅了某种理财产品的“到账通知”。数据消费者可以告诉ADRF:“我对某种类型的新‘存款’(新存入的数据)感兴趣,一旦有符合条件的‘钱’进账,请立刻通知我。”
本篇文章,我们将化身为一位“数据投资者”,详细学习如何办理这两种“取款”业务,如何取消“理财通知”(RetrievalUnsubscribe),以及银行是如何将“到账信息”推送给我们的(RetrievalNotify)。
1. 解读第4.2.2.5章 RetrievalRequest service operation (一次性检索请求)
The Nadrf_DataManagement_RetrievalRequest service operation is used by an NF service consumer to retrieve stored data or analytics.
信令流程 (Figure 4.2.2.5.2-1: NF service consumer requesting to retrieve...):
这张图展示了最直接的“柜台取款”流程。
步骤1: 消费者 发起 GET 请求
1. GET .../data-store-records?query_parameters
- 场景链接: NWDAF需要一份历史分析报告,用于模型再训练。它知道这份报告的存储事务ID是
store-trans-id-123。 - 动作: NWDAF向ADRF的
/data-store-records资源集合发起一个HTTPGET请求。 - 查询参数 (Query Parameters): 这是实现精确检索的关键。规范指出,查询参数必须是以下三者之一:
store-trans-id: 按存储事务ID查询。fetch-correlation-ids: 按MFAF通知中的获取关联ID查询。data-set-id: 按数据集ID查询。 例如:GET .../data-store-records?store-trans-id=store-trans-id-123
步骤2: ADRF 响应
2. "200 OK" or "204 No Content"
200 OK: 查询成功。响应体是一个NadrfDataStoreRecord对象,其中包含了请求的数据(anaNotifications或dataNotif字段)。204 No Content: 未找到匹配的数据。
2. 解读第4.2.2.6章 RetrievalSubscribe service operation (检索订阅请求)
The Nadrf_DataManagement_RetrievalSubscribe service operation is used by an NF service consumer to subscribe to the ADRF to retrieve via notifications data or analytics that is stored in the ADRF…
信令流程 (Figure 4.2.2.6.2-1: NF service consumer requesting to retrieve and subscribe...):
这张图展示了“订阅理财通知”的流程。
步骤1: 消费者 发起 POST 请求
1. POST .../data-retrieval-subscriptions
- 场景链接: 一个专门负责网络切片性能监控的NWDAF,需要实时获取所有新生成的、与“NSI-Emergency”切片相关的分析报告。
- 动作: NWDAF向ADRF的
/data-retrieval-subscriptions资源集合发起POST请求。 - 请求体 (
NadrfDataRetrievalSubscription): 这是“理财通知订阅单”,内容包括:notifCorrId(M): 通知关联ID。notificationURI(M): 回调地址。- 订阅条件 (M): 以下三者之一:
anaSub: 订阅分析数据。可以指定分析事件类型、目标UE、区域等。dataSub: 订阅原始数据。可以指定数据源、数据类型等。dataSetId: 订阅特定数据集的所有更新。
步骤2: ADRF 返回 201 Created 响应
2. "201 Created"
- ADRF收到请求后,会创建一个“检索订阅”资源,并分配一个唯一的
subscriptionId。 - 响应: 返回
201 Created,Location头中包含了新创建订阅的URI,形如.../data-retrieval-subscriptions/{subscriptionId}。
3. 解读第4.2.2.8章 RetrievalNotify service operation (检索通知)
这是ADRF履行RetrievalSubscribe约定的动作。
The Nadrf_DataManagement_RetrievalNotify service operation is used by ADRF to notify NF service consumers about subscribed events related to data or analytics…
信令流程 (Figure 4.2.2.8.2-1: ADRF notifies...):
1. POST {notificationURI}: 当有新的数据通过StorageRequest存入ADRF时,ADRF会检查所有活动的检索订阅。如果发现新数据匹配了某个订阅的条件(例如,一份新的报告被标记为与“NSI-Emergency”切片相关),ADRF就会向该订阅的notificationURI发起POST请求。- 请求体 (
NadrfDataRetrievalNotification): 这个通知“包裹”的设计与MFAF的通知非常相似,同样支持“推”和“拉”两种模式:notifCorrId(M): 关联ID。- 二选一:
dataAnaNotif: 直接推送新存入的数据。fetchInstruct: 推送一个“提货单”,告知消费者有新数据可用,并提供获取地址(fetchUri)和凭证(fetchCorrIds)。
2. "204 No Content": 消费者返回204确认收到。
4. 解读第4.2.2.7章 RetrievalUnsubscribe service operation (检索退订)
The Nadrf_DataManagement_RetrievalUnsubscribe service operation is used by an NF service consumer to remove a retrieval subscription to data or analytics.
信令流程 (Figure 4.2.2.7.2-1: NF service consumer requesting to remove...):
1. DELETE .../data-retrieval-subscriptions/{subscriptionId}: 当NWDAF不再需要监控切片性能报告时,它向之前创建的订阅URI发起DELETE请求。2. "204 No Content": ADRF删除该订阅后,返回成功响应。
总结
通过对ADRF数据检索类操作的深度剖析,我们已经掌握了从这座“数据金库”中获取资产的各种方式。
-
灵活的检索模式: ADRF提供了一次性拉取 (
RetrievalRequest) 和 订阅式推送 (RetrievalSubscribe/Notify) 两种模式,满足了不同的数据消费需求。前者适用于历史数据查询,后者适用于实时数据监控。 -
强大的查询能力:
RetrievalRequest支持按多种ID(存储事务ID、获取关联ID、数据集ID)进行精确查询,为数据溯源和关联提供了便利。 -
推拉结合的通知机制:
RetrievalNotify操作同样支持直接推送小数据和通知-拉取大数据两种模式,在实时性和网络效率之间取得了良好平衡。 -
标准的生命周期管理: 检索订阅资源同样遵循
POST创建、DELETE删除的RESTful标准生命周期管理,接口清晰,行为可预测。
我们已经完整地学习了ADRF数据管理服务的“存”和“取”。在下一篇,也是本系列最终章中,我们将快速浏览最后的数据删除操作,并对Nadrf_MLModelManagement服务进行一次概览,从而为TS 29.575的解读画上圆满的句号。
FAQ
Q1:RetrievalRequest (GET) 和 RetrievalSubscribe (POST) 的核心区别是什么?
A1:核心区别在于操作的性质和持久性。
RetrievalRequest(GET) 是一个一次性、无状态的查询。它不-会在ADRF上创建任何持久化资源。你问一次,ADRF答一次,交易结束。RetrievalSubscribe(POST) 是一个创建长期订阅资源的操作。它在ADRF上创建了一个有状态的“订阅”实体。只要这个实体存在,ADRF就会在未来持续地为你提供服务(发送通知)。
Q2:RetrievalNotify中的fetchInstruct和MFAF的fetchInstruct是同一个东西吗?
A2:它们在概念和结构上是完全相同的,都包含了fetchUri, fetchCorrIds和expiry。这体现了3GPP在数据分析架构中对“通知-拉取”模式的标准化设计。消费者可以用一套统一的逻辑来处理来自MFAF的“提货单”和来自ADRF的“提货单”。
Q3:我可以通过RetrievalSubscribe订阅一个还没有被存储过的数据类型吗?
A3:可以。RetrievalSubscribe的本质是向ADRF注册一个“未来兴趣”。你告诉ADRF:“我未来对X类型的数据感兴趣”。ADRF会记下你的这个兴趣。当前仓库里可以没有任何X类型的数据。只有当未来某个时刻,一个生产者通过StorageRequest存入了一份X类型的数据时,你的订阅才会被触发,ADRF才会向你发送Notify。
Q4:一个数据记录(Data Store Record)可以同时被多个不同的检索订阅匹配并通知吗?
A4:是的。ADRF内部的匹配逻辑是独立评估每一个检索订阅的。当一条新数据入库时,ADRF会遍历所有活动的检索订阅,检查该数据是否满足每个订阅的过滤条件。如果同时满足了订阅A和订阅B的条件,那么ADRF就会分别向订阅A和订阅B的notificationURI发送Notify消息。
Q5:如果一个消费者订阅了数据,但它的notificationURI端点持续不可用,ADRF会如何处理?
A5:ADRF会像其他SBA服务提供者一样,进行有限次数的重试。如果多次重试后仍然失败,ADRF通常会将该订阅标记为“暂停(suspended)”或直接判定为无效并删除。此外,ADRF在发送Notify时,如果采用“推拉结合”模式,它只会发送轻量级的fetchInstruction。即使消费者错过了通知,只要数据在ADRF中的生命周期还未结束,消费者仍然有机会通过其他方式(例如,定期轮询或手动查询)发现并检索到这些数据。