51学通信

深度解析 3GPP TS 29.575：4.2 & 4.3 ADRF数据与模型管理 (最终章)

13分钟阅读

好的，我们即将完成对3GPP TS 29.575的深度解读之旅。在前文中，我们已经全面掌握了Nadrf_DataManagement服务的存储与检索机制。现在，我们将完成最后一块拼图：数据的删除，并对另一个核心服务Nadrf_MLModelManagement进行一次精炼的总结。

深度解析 3GPP TS 29.575：4.2 & 4.3 ADRF数据与模型管理 (最终章)

本文技术原理深度参考了3GPP TS 29.575 V18.8.0 (2025-03) Release 18规范中，第四章4.2.2.9节“Nadrf_DataManagement_Delete service operation”和4.3节“Nadrf_MLModelManagement Service”的核心内容。本文是TS 29.575解读的最终章，旨在为读者完整呈现ADRF数据生命周期的最后一个环节——数据删除，并概览其另一大核心能力——机器学习模型管理，从而为ADRF这座“记忆宫殿”的探索画上圆满的句号。

引言：从“入库”到“销毁”——数据生命周期的闭环与AI模型的“军火库”

数据如流水，有源头，有汇聚，也应有“入海口”。一个健康的数据仓库，不仅要能高效地存取数据，更要有清晰、可控的数据销毁机制，以避免数据无限膨胀，并满足合规性要求（如GDPR）。本篇文章将首先带领我们探索ADRF数据生命周期的最后一环——Delete操作，看看“数据银行”是如何执行“销账”操作的。

随后，我们将把目光投向ADRF的另一个“宝库”——机器学习模型仓库。随着5G网络智能化程度的加深，ML模型已成为与数据同等重要的核心资产。我们将概览Nadrf_MLModelManagement服务，看看ADRF是如何扮演“AI军火库管理员”的角色，对这些珍贵的“智能武器”进行入库、检索和退役管理的。

1. 解读第4.2.2.9章 Delete service operation (数据删除操作)

The Nadrf_DataManagement_Delete service operation is used by an NF service consumer to delete stored data or analytics.

ADRF提供了两种灵活的删除模式，以满足不同的管理需求。

1.1 按“存储事务ID”删除 (Figure 4.2.2.9.2-1)

4.2.2.9.2 Requesting removal of stored data or analytics

  • 核心功能: 根据**storeTransId**，精确地删除某一次StorageRequest操作所存入的数据记录。
  • API实现: DELETE .../data-store-records/{storeTransId}
  • 场景链接: NWDAF在一次分析任务中，存入了一份临时的中间数据，并记录了其storeTransId。任务完成后，NWDAF通过调用这个DELETE API，将这份不再需要的中间数据从ADRF中精确地清理掉。
  • 响应: 204 No Content表示成功删除。404 Not Found表示该记录不存在。

1.2 按“数据/分析规范”批量删除 (Figure 4.2.2.9.3-1)

4.2.2.9.3 Requesting removal of stored data or analytics using data or analytics specification

  • 核心功能: 根据一组条件，批量删除匹配的所有数据。这是一种极其强大的“定点清除”能力。
  • API实现: POST .../remove-stored-data-analytics (自定义操作)
  • 请求体 (NadrfStoredDataSpec): 这个“删除指令”可以包含：
    • timePeriod: 指定一个时间窗口，删除在此期间收集的数据。
    • dataSpec或anaSpec: 指定数据的类型或分析的类型。
    • dataSetId: 指定要删除的整个数据集。
  • 场景链接: 运营商的运维策略规定：“所有非关键业务的服务体验分析报告，只保留30天”。一个自动化的运维脚本会每天执行一次，调用这个POST API，请求体中设置timePeriod为30天前的那个24小时，并设置anaSpec为“服务体验分析”，从而实现对过期数据的自动滚动删除。
  • 响应: 204 No Content表示成功匹配并删除了数据（即使没有匹配到数据，操作本身也算成功）。

2. 解读第4.3章 Nadrf_MLModelManagement Service - AI模型的“军火库”

随着网络AI（NW-AI）和机器学习（ML）在5G中的深入应用，ML模型本身也成为了需要被集中管理的核心资产。Nadrf_MLModelManagement服务正是为此而生。

4.3.1.1 Overview

The Nadrf_MLModelManagement service… is provided by the Analytics Data Repository Function (ADRF). This service:

  • allows NF service consumers to store ML model(s) in the ADRF;
  • allows NF service consumers to retrieve ML model(s) from an ADRF; and
  • allows NF service consumers to delete ML model(s) from an ADRF.

架构图 (Figure 4.3.1.2-1) 清晰地表明，该服务的主要（甚至是唯一）消费者是NWDAF。

2.1 服务操作概览 (Table 4.3.2.1-1)

Service operation nameDescriptionInitiated by
StorageRequest…store or update ML model(s).NF service consumer (NWDAF)
RetrievalRequest…retrieve stored ML model(s)…NF service consumer (NWDAF)
Delete…delete stored ML model(s)…NF service consumer (NWDAF)

该服务的操作集相对简洁，就是对ML模型进行基本的增、查、删 (CRUD) 操作。

2.2 核心流程与API

  • 存储模型 (StorageRequest):

    • API: POST .../mlmodel-store-records
    • 流程: NWDAF中的MTLF（模型训练逻辑功能）在训练完成一个新模型后，调用此API。请求体中包含了模型的元数据（mlModelInfo，如模型地址、大小、适用范围等）或模型文件本身（mlModels）。ADRF为其分配一个storeTransId并持久化存储。

  • 检索模型 (RetrievalRequest):

    • API: GET .../mlmodel-store-records
    • 流程: NWDAF中的ANLF（分析逻辑功能）在需要执行推理任务时，调用此API。可以通过store-trans-id或model-unique-ids（模型的唯一ID）来查询。ADRF返回模型的元数据，包括模型的存储地址（mlFileAddr）。ANLF再根据这个地址去下载模型文件。

  • 删除模型 (Delete):

    • API: DELETE .../mlmodel-store-records/{storeTransId} 或 POST .../remove-stored-mlmodel
    • 流程: 当一个模型被新版本替代或不再使用时，NWDAF可以调用DELETE API将其从ADRF中“退役”。同样支持按storeTransId精确删除，或按modelUniqueId批量删除。

总结与宣告

通过对ADRF数据删除操作和ML模型管理服务的最终解读，我们为TS 29.575的探索之旅画上了圆满的句号。

  1. 完整的数据生命周期: Delete操作为ADRF中的数据提供了精确（按ID）和批量（按规范）两种销毁方式，与存储、检索、订阅操作共同构成了数据从诞生到消亡的完整生命周期管理闭环。

  2. 专业的ML模型管理: Nadrf_MLModelManagement服务将ML模型作为一等公民进行管理，提供了专用的存储、检索和删除接口。这标志着3GPP架构正式拥抱了MLOps思想，为5G网络的AI原生演进提供了坚实的数据和模型基础。

  3. ADRF的双重核心: ADRF不仅仅是“大数据”的仓库，更是“大模型”的仓库。它通过Nadrf_DataManagement和Nadrf_MLModelManagement两大服务，共同构成了5G网络智能化的“记忆与智慧中枢”。

至此，我们对3GPP TS 29.575规范的系列深度解读已全部完成。 我们从ADRF作为“记忆宫殿”的宏大构想出发，深入到了其“数据馆”和“模型馆”的每一个房间，详细学习了其中的“藏品”管理规程。

这份规范是5G网络区别于前几代通信网络，迈向“智能化”和“数据驱动”的核心基石之一。深刻理解ADRF，就是理解5G如何沉淀其网络智慧，并将其转化为持续优化和创新的动力源泉。

FAQ

Q1：数据删除操作Delete会触发通知吗？ A1：会的。这是一个非常重要的机制。规范在Nadrf_DataManagement_RetrievalNotify服务操作（4.2.2.8.3节）和ADRF Alert Notification（5.1.5.3节）中定义了“删除告警”机制。当一个NF在存储数据时（StorageRequest），可以在storeHandl（存储处理）信息中提供一个delNotifUri（删除通知URI）。当这份数据即将被ADRF（例如，因为生命周期到期）删除时，ADRF会向这个delNotifUri发送一个告警通知。这给了数据的原始生产者一个“最后的机会”，在数据被永久删除前，可以选择将其再次取回或备份。

Q2：Nadrf_MLModelManagement服务存储的是模型文件本身，还是模型的地址？ A2：两者都支持。StorageRequest的请求体NadrfMLModelStoreRecord中，可以包含mlModels（直接嵌入Base64编码的模型二进制文件）或mlModelInfo（包含模型的mlFileAddr，即模型的URL地址）。

  • 对于较小的模型，可以直接嵌入。
  • 对于大型模型（可能达到GB级别），更常见的做法是，NWDAF先将模型文件上传到一个对象存储（如S3），然后在StorageRequest中只提供该模型的URL。ADRF会记录这个URL，或者根据策略，异步地从该URL下载模型到自己的内部存储中。

Q3：Nadrf_MLModelManagement服务有订阅功能吗？ A3：在当前版本的TS 29.575中，Nadrf_MLModelManagement服务没有定义订阅/通知机制。它只提供了CRUD（创建、读取、更新、删除）操作。这意味着，如果一个ANLF需要知道是否有新模型可用，它需要定期去轮询（Poll） ADRF的GET /mlmodel-store-records接口。这可能是因为ML模型的更新频率通常远低于网络分析数据，因此一个简单的轮询机制在当前阶段被认为是足够的。

Q4：为什么删除操作有两种API：DELETE /{id}和POST /action？ A4：这同样是为了区分操作的语义和能力。

  • DELETE /data-store-records/{storeTransId}: 这是标准的RESTful删除，目标是一个明确的、单一的资源。它的语义清晰，符合HTTP规范。
  • POST /remove-stored-data-analytics: 这是一个自定义操作，它需要一个复杂的请求体（NadrfStoredDataSpec）来描述一个批量删除的条件。这种复杂的、非幂等的操作，不适合用简单的DELETE方法来表达。使用POST来触发一个“批量删除动作”，是更灵活和强大的设计。

Q5：ADRF的两个服务，它们的API是独立的吗？ A5：是的，它们是两个完全独立的API，有各自的apiName（nadrf-datamanagement和nadrf-mlmodelmanagement）和独立的OpenAPI定义文件。这意味着它们可以作为两个独立的微服务来部署和演进。一个运营商甚至可以选择只部署Nadrf_DataManagement服务，如果它当前的网络智能化水平还未达到需要集中管理ML模型的阶段。这种解耦提供了部署上的灵活性。

关系图谱