51学通信

深度解析 3GPP TS 29.576：4.2 Nmfaf_3daDataManagement Service (数据管道配置服务)

14分钟阅读

好的，我们立刻进入对3GPP TS 29.576规范第四章核心部分的深度剖析。在上一篇中，我们已经掌握了MFAF的宏观架构和其独特的双服务模型。现在，我们将聚焦于第一个核心服务——Nmfaf_3daDataManagement，详细探索“数据管道”是如何被设计和搭建的。

深度解析 3GPP TS 29.576：4.2 Nmfaf_3daDataManagement Service (数据管道配置服务)

本文技术原理深度参考了3GPP TS 29.576 V18.6.0 (2025-03) Release 18规范中，第四章4.2节“Nmfaf_3daDataManagement Service”的全部核心内容。本文旨在为读者深度剖析MFAF的“配置入口”服务，我们将详细拆解Configure和Deconfigure这两个核心服务操作的业务逻辑、交互流程，揭示一个从数据源到数据消费者的端到端数据处理管道是如何被精确配置和管理的。

引言：“乐高”式的数据管道搭建

想象一下，MFAF是一个拥有各种数据处理模块（如格式转换、过滤、聚合等）的“乐高”积木盒。Nmfaf_3daDataManagement服务，就是提供给“设计师”（DCCF或NWDAF）的一份“搭建指南”和操作界面。设计师可以通过这个界面，挑选合适的积木模块，将它们拼接起来，搭建出一个个定制化的“数据模型”——即数据管道。

本篇文章，我们将化身为这位“设计师”，学习如何使用Configure操作来搭建一个新的数据管道，如何通过Update来修改它，以及如何通过Deconfigure来拆除它。我们将以“数智分析师-阿尔法”（NWDAF）希望搭建一条“用户移动模式分析管道”为例，全程追踪这个“乐高模型”的搭建过程。

1. 解读第4.2.1章 Nmfaf_3daDataManagement Service Description (服务描述)

本节从宏观上定义了该服务的消费者和架构。

3GPP TS 29.576 - 4.2.1.1 Overview

The Nmfaf_3daDataManagement service… is provided by the Messaging Framework Adaptor Function (MFAF). This service:

  • allows NF consumers to configure or reconfigure the MFAF to map data or analytics… to out-bound notification endpoints; and
  • allows NF consumers to reconfigure the MFAF to stop mapping data or analytics…
  • 核心功能: 配置(configure)、重配置(reconfigure) 和 停止(stop) 从MFAF输入到输出的数据/分析映射。

架构图 (Figure 4.2.1.2-1) 清晰地展示了：

  • 服务提供者: MFAF
  • 服务消费者: DCCF和NWDAF

2. 解读第4.2.2章 Service Operations (服务操作)

本节是功能逻辑的核心，定义了“设计师”可以执行的具体动作。

Table 4.2.2.1-1: Operations of the Nmfaf_3daDataManagement Service

Service operation nameDescriptionInitiated by
Configure…configure or reconfigure the MFAF to map data…NF service consumer (DCCF, NWDAF)
Deconfigure…stop mapping data…NF service consumer (DCCF, NWDAF)

2.1 4.2.2.2 Configure service operation (配置服务操作)

Configure操作是整个数据管道的“创世纪”。它包含了初始创建和后续更新两种场景。

4.2.2.2.2 Initial configuration (初始配置)

Figure 4.2.2.2.2-1: NF service consumer create the configuration

信令流程剖析: 步骤1: DCCF/NWDAF 发起 POST 请求

1. POST .../configurations

  • 场景链接: “数智分析师-阿尔法”（NWDAF）需要搭建一条管道，用于收集A区域内用户的移动性事件，并将其发送给一个内部的“轨迹分析引擎”（一个通知端点）。
  • 动作: NWDAF向MFAF的/configurations资源集合发起一个HTTP POST请求。
  • 请求体 (MfafConfiguration): 这是“搭建图纸”，其核心是一个名为messageConfigurations的数组，允许一次性配置多个数据流。

MessageConfiguration (单个数据流配置) 的深度剖析:

The MessageConfiguration data type shall include:

  1. a notification URI… as “notificationURI” attribute; and
  2. …a Notification Correlation ID… as “correId” attribute; and may include:
  3. the formatting instructions as “formatInstruct” attribute;
  4. the processing instructions as “procInstruct” attribute…
  5. the MFAF notification information to identify the Event Notifications received from the… Data Source NF… as “mfafNotiInfo” attribute;

这份“图纸”包含了搭建一个数据管道所需的所有信息：

  • notificationURI (M): 出口。处理完的数据应该发往哪里。
  • correId (C): 关联ID。用于消费者识别收到的数据属于哪个配置任务。
  • mfafNotiInfo (O): 入口。MFAF应该去监听哪个数据源的哪个通知。它内部包含了数据源的标识和它发布的通知的标识。
  • formatInstruct (O): 格式化模块。对数据进行格式转换的指令。
  • procInstruct (O): 处理模块。对数据进行处理（如过滤、聚合）的指令。

步骤2: MFAF 返回 201 Created 响应

2. 201 Created

  • MFAF收到并成功解析“图纸”后，会在内部：
    1. 创建并存储这个配置。
    2. 分配一个唯一的事务参考ID (transRefId)。
    3. 根据mfafNotiInfo，向指定的数据源（如AMF）发起底层的事件订阅。
  • 响应: 返回201 Created，Location头中包含了新创建配置的URI，形如.../configurations/{transRefId}。响应体中可能还包含MFAF补充的信息（例如，如果请求中没有提供mfafNotiInfo，MFAF可以自己决定一个）。
4.2.2.2.3 Update the configuration (更新配置)

Figure 4.2.2.2.3-1: NF service consumer updates configuration

信令流程剖析:

  • 1. PUT .../configurations/{transRefId}: 消费者向一个已存在的配置URI发起PUT请求，请求体是更新后的完整MfafConfiguration对象。
  • 2a. "200 OK"或2b. "204 No Content": MFAF成功更新配置后，返回成功响应。

场景链接: “阿尔法”现在不仅要监控A区，还要监控B区。它会向之前创建的配置URI (.../configurations/{transRefId}) 发起一个PUT请求，请求体中的mfafNotiInfo会更新，包含对B区事件的订阅。

2.2 4.2.2.3 Deconfigure service operation (去配置服务操作)

Deconfigure操作是数据管道的“拆除”指令。

Figure 4.2.2.3.2-1: NF service consumer stops mapping data or analytics

信令流程剖析: 步骤1: DCCF/NWDAF 发起 DELETE 请求

1. DELETE .../configurations/{transRefId}

  • 场景链接: 对A区和B区的移动模式分析任务结束。
  • 动作: NWDAF向代表该任务的配置URI (.../configurations/{transRefId}) 发起一个HTTP DELETE请求。

步骤2: MFAF 返回 204 No Content 响应

2. "204 No Content"

  • MFAF收到请求后，会：
    1. 删除这个配置资源。
    2. 级联取消所有与此配置相关的底层数据源订阅。
  • 响应: 返回204 No Content，表示“拆除”成功。

总结

通过对4.2节Nmfaf_3daDataManagement服务的深度解读，我们已经完全掌握了MFAF作为“数据管道工”的“操作台”是如何工作的。

  1. 配置即资源: MFAF的数据处理流程被抽象为一个个可管理的“配置资源”。每个资源由一个唯一的transRefId标识。

  2. 标准的生命周期管理: 规范通过POST创建、PUT更新、DELETE删除这一套标准的RESTful动词，实现了对配置资源完整的生命周期管理，接口设计清晰且符合业界实践。

  3. 声明式的管道定义: Configure操作的核心是提交一个声明式的配置（MfafConfiguration）。消费者只需描述“我想要什么”（数据源、处理逻辑、目的地），而无需关心MFAF内部是如何实现这些步骤的。这种声明式的方法，是实现高度解耦和灵活性的关键。

  4. 原子性的管理单元: 每个配置资源（transRefId）都代表了一个端到端的、独立的原子性数据流任务。这使得对复杂数据分析任务的管理变得模块化和简单化。

我们已经学会了如何搭建、修改和拆除MFAF的数据管道。在下一篇文章中，我们将把视角切换到管道的“出口”，深入4.3节Nmfaf_3caDataManagement服务，看看当数据在管道中处理完成后，是如何被精准地分发给最终消费者的。

FAQ

Q1：Configure操作中的messageConfigurations为什么是一个数组？ A1：设计成数组是为了支持批量配置和复杂数据流。一个数据分析任务可能需要将来自同一个数据源（如AMF的移动性事件）的数据，经过不同的处理后，发送到不同的目的地。例如，一份原始位置数据，可能需要：

  • 一份直接转发给实时告警系统（配置1）。
  • 一份经过轨迹聚合后，发送给历史分析系统（配置2）。 通过在一个MfafConfiguration中包含一个messageConfigurations数组，DCCF/NWDAF可以在一次API调用中，为同一个数据输入源，定义多个并行的输出数据流，极大地提升了配置的灵活性和效率。

Q2：如果Configure请求中没有提供mfafNotiInfo（数据源信息），MFAF会怎么做？ A2：规范指出：“…if no MFAF notification information has been provided in the request, determine the MFAF notification information and add it to the configuration…”。这意味着MFAF具备一定的“智能推断”能力。例如，如果配置中要求对“用户体验数据”进行处理，MFAF可能会根据其内部的知识库或默认配置，自动推断出它应该去向网络中的NWDAF订阅SVC_EXPERIENCE事件。这个推断出的mfafNotiInfo会包含在201 Created的响应体中返回给消费者，实现了配置的简化。

Q3：procInstruct（处理指令）和formatInstruct（格式化指令）的具体内容是什么？ A3：这两者都复用了TS 29.574 (DCCF) 中定义的数据类型。它们的内容可以是高度结构化的指令。

  • formatInstruct: 可能包含诸如“将数据从XML转换为JSON”、“移除某些敏感字段”、“对时间戳进行格式化”等指令。
  • procInstruct: 可能包含更复杂的逻辑，如“只上报移动距离超过1公里的事件”、“将1分钟内的所有QoS数据聚合成一个平均值”等。 这些指令的具体语法和能力，定义了MFAF这个“加工车间”的实际加工能力。

Q4：Configure操作成功后，MFAF会立即开始从数据源拉取数据吗？ A4：不一定。Configure操作成功，只代表MFAF已经接受并存储了配置，并可能已经向数据源发起了订阅。但真正的数据流开始产生，需要等待数据源侧有实际的事件发生。例如，即使MFAF已经向AMF订阅了A区域的移动性事件，也只有当该区域内真的有UE发生移动时，AMF才会向MFAF发送通知，数据管道中才开始有数据流动。

Q5：Deconfigure操作会立即生效吗？如果当时正有数据在管道中处理，会怎么样？ A5：Deconfigure（DELETE请求）一旦被MFAF成功处理（返回204 No Content），该配置在逻辑上就已失效。MFAF会立即取消对上游数据源的订阅。对于当时正在管道中处理的数据，MFAF的实现可以有两种策略：1）立即丢弃：中断所有处理，直接丢弃在途数据。2）优雅终止：处理完当前正在处理的数据批次，并将其发送出去，但不再接收任何新的数据。规范通常不限制这种实现细节，但“立即丢棄”是更简单和常见的实现。

关系图谱