51学通信

深度解析 3GPP TS 29.552：5.2.5 Analytics Exposure via DCCF and MFAF (引入消息框架的分析暴露)

25分钟阅读

好的，我们继续深入TS 29.552规范的肌理。在上一篇文章中，我们详细探讨了通过DCCF这一“总调中心”来协调和优化分析服务的暴露流程。今天，我们将引入另一个关键的“适配器”角色——MFAF，探讨当网络智能需要跨越边界，与非3GPP的外部世界对话时，信令流程将如何演变。

深度解析 3GPP TS 29.552：5.2.5 Analytics Exposure via DCCF and MFAF (引入消息框架的分析暴露)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将聚焦于5.2.5节 “Analytics Exposure via DCCF and MFAF”，详细解析当分析服务的交付需要通过一个消息框架（Messaging Framework）时，MFAF（消息框架适配器功能）是如何与DCCF及其他网元协同工作，从而实现5G核心网智能与外部IT系统无缝集成的。

前言：当5G智能遇上IT世界

我们已经知道，DCCF像一个“分析服务总调中心”，有效地管理着来自网络内部众多消费者的订阅请求。然而，5G的愿景远不止于网络自身的优化。它旨在成为万物互联的基石，其网络能力，特别是富有洞察力的分析能力，对于千行百业的数字化转型至关重要。

这意味着，分析服务的消费者，可能不再是PCF、AMF这样讲着“3GPP标准普通话”的内部网元，而可能是：

  • 智慧城市的运营中心：它使用着基于Kafka或RabbitMQ等消息总线的IT平台，来汇聚交通、安防、环境等各类数据。

  • 大型企业的IT监控系统：它希望将运营商提供的网络质量分析，整合进自己的统一监控大屏。

  • 云游戏平台的后台服务器：它需要实时获取网络抖动和时延预测，以动态调整游戏码率和服务器调度。

这些外部IT系统，通常不使用3GPP定义的服务化接口，而是习惯于通过更为通用的消息框架（Messaging Framework）进行异步通信。如何在这两个异构世界之间架起一座桥梁？这正是MFAF (Messaging Framework Adaptor Function) 的核心使命。

MFAF，可以被看作是5G核心网的“首席协议翻译官”和“跨界快递员”。它驻留在网络的边缘，一面朝向3GPP核心网，说着标准的服务化接口语言；另一面朝向外部IT世界，说着消息总线的语言。

在本文中，我们将延续“未来科技博览会”的场景。市政府的“智慧城市运营中心”（我们称之为**“CityOps”**），为了保障博览会期间的公共安全和交通调度，需要实时获取会展中心区域的人流密度和拥塞预警分析。CityOps的平台是基于消息总线构建的。现在，‘洞察者’(Insight-AI)需要通过它的“总调中心”DCCF和“跨界快递员”MFAF，来满足CityOps的需求。

1. MFAF登场：一个流程，两个“适配器”服务

5.2.5节的流程建立在5.2.4节（通过DCCF暴露）的基础之上，但引入了MFAF作为最终的“交付代理”。

规范原文引用 (Clause 5.2.5 Introduction):

…upon the delivery option “Delivery via Messaging Framework ” configured on the DCCF, the 3GPP DCCF Adaptor (3da) Data Management service and 3GPP Consumer Adaptor (3ca) Data Management service of the Messaging Framework Adaptor Function (MFAF) are used to interact with the 3GPP Network and the Messaging Framework for analytics information delivery…

这段引言揭示了MFAF的“双面”特性：

  • 交付选项是关键：整个流程的触发点在于消费者的订阅请求中明确指定了deliveryOption为“通过消息框架交付”。

  • 3da (3GPP DCCF Adaptor)：这是MFAF朝向DCCF的一面，我们可以称之为“对内接口”。它负责接收来自DCCF的配置和数据通知。

  • 3ca (3GPP Consumer Adaptor)：这是MFAF朝向最终消费者（或消息框架）的一面，我们可以称之为“对外接口”。它负责将数据最终投递给消费者。

现在，让我们跟随规范的 “Figure 5.2.5-1: Analytics Exposure via DCCF and Messaging Framework”，详细拆解CityOps获取‘洞察者’分析服务的全过程。

1.1 步骤1：CityOps向DCCF发起订阅

场景：CityOps平台（作为一个经过授权的AF）的开发人员，根据运营商提供的API文档，得知需要向DCCF提交它的分析订阅请求。

这个步骤与5.2.4节的起点非常相似，但有一个至关重要的区别。

  1. 动作：CityOps AF向DCCF发起一个HTTP POST请求，调用Ndccf_DataManagement_Subscribe服务。

  2. 请求体：在NdccfAnalyticsSubscription数据结构中，除了分析ID、过滤器等信息外，它还必须包含一个关键参数：

    • deliveryOption: "MESSAGING_FRAMEWORK"。

    • msgFrameworkConnInfo: 包含了连接到消息框架所需的信息，例如Topic名称、服务器地址等。这相当于告诉DCCF：“请把‘报纸’投递到名为‘CityOps-Analytics’的信箱里”。

    • notificationUri: 在这种模式下，这个字段可能不再是传统的HTTP URL，而是代表消息框架中目标端点的一个标识符。

这个deliveryOption参数，就像是在订阅单上勾选了“特殊投递”选项，它将彻底改变后续的数据流向。

1.2 步骤2 & 3：DCCF配置MFAF - “快递员，有个新任务！”

DCCF收到订阅请求后，看到deliveryOption是MESSAGING_FRAMEWORK，它立刻明白，这次不能自己直接送货了，必须委托专业的“跨界快递员”MFAF来处理。

规范原文引用 (Step 2):

Upon the delivery option “Delivery via MFAF” configured on the DCCF, in order to create configuration of mapping data in the MFAF, the DCCF shall invoke the Nmfaf_3daDataManagement_Configure service operation by sending an HTTP POST request message…

这是整个流程中第一个全新的、核心的步骤：

  1. 动作：DCCF向MFAF发起一个HTTP POST请求，调用其“对内接口”Nmfaf_3daDataManagement_Configure。

  2. 目的：这个“配置”动作，本质上是DCCF在MFAF上创建一条**“投递规则”或“数据路由映射”**。

  3. 请求体：DCCF会将从CityOps那里收到的msgFrameworkConnInfo等投递信息，连同一个内部生成的CorrelationId，一起发送给MFAF。这就像是告诉MFAF：“以后凡是带有这个CorrelationId的数据包，都请你按照这些连接信息，投递到消息总线的那个Topic里去。”

  4. MFAF的响应 (Step 3)：MFAF收到配置请求后，会在内部建立这条路由规则，并回复DCCF一个201 Created响应。响应的Location头中会包含这个新创建的配置资源的URI，DCCF会保存它，以便将来需要修改或删除这条规则。

至此，最终的“投递路径”已经建立完毕。

1.3 步骤4 - 8：“后端”的数据准备工作

这部分流程与5.2.4节的核心逻辑是一致的。DCCF在配置完MFAF后，仍然会执行它作为“总调中心”的智能决策：

  • 步骤4 & 5a：DCCF检查是否已有其他消费者订阅了相同的实时分析。如果没有，它会继续执行步骤6a & 7a。

  • 步骤6a & 7a：DCCF代表CityOps向‘洞察者’(NWDAF)发起Nnwdaf_EventsSubscription_Subscribe请求。关键点在于：这次DCCF提供给NWDAF的notificationUri，指向的是MFAF，而不是DCCF自己。因为DCCF已经委托MFAF全权负责接收和投递。

  • 历史数据处理 (步骤5b/c, 6b/c, 7b/c)：如果CityOps请求的是历史数据，DCCF同样会智能地判断数据源是ADRF还是NWDAF，并发起相应的数据检索订阅。同样，它提供给ADRF或NWDAF的通知地址，也将指向MFAF。

  • 步骤8：在所有后端订阅都建立好之后，DCCF向CityOps回复一个201 Created响应，确认它的订阅请求已被接受和处理。

1.4 步骤9 - 12：通知的“跨界接力” - 核心数据流

这是MFAF真正发挥作用的时刻。

场景：‘洞察者’分析得出，博览会入口处人流密度即将超过预警阈值。

  1. 第一棒：NWDAF → MFAF (步骤9a, 10a)

    规范原文引用 (Step 9a):

    (conditional)When the analytics are available, the NWDAF invokes the Nnwdaf_EventsSubscription_Notify service operation by sending an HTTP POST request message to notify the analytics information to the MFAF.

    ‘洞察者’(NWDAF)生成分析报告后，它根据订阅时DCCF提供的通知地址，直接向MFAF的“对内接口”(3da)发送一个Nnwdaf_EventsSubscription_Notify通知。MFAF收到后，回复204 No Content确认。

    注意这个数据流向的优化：数据（分析通知）没有经过DCCF中转。DCCF负责前期的控制和协调（“握手”），而MFAF负责后续的数据传输（“搬运”）。这种“控制面与数据面分离”的思想，使得数据路径更短，效率更高。

  2. 第二棒：MFAF → CityOps (步骤11a, 12a)

    规范原文引用 (Step 11a):

    The MFAF invokes the Nmfaf_3caDataManagement_Notify service operation by sending HTTP POST request message(s) to send the analytics data to all notification endpoints indicated in step 1.

    MFAF收到来自NWDAF的“包裹”后，立刻执行它的核心职责：

    1. 查找规则：MFAF根据通知中包含的subscriptionId或CorrelationId，查找到步骤2中DCCF为它配置的“投递规则”。

    2. 适配与投递：规则告诉它，这个“包裹”应该投递给CityOps，并且需要使用消息总线的方式。于是，MFAF调用其“对外接口”(3ca)，将分析报告的数据内容（可能需要进行格式转换）发布到CityOps正在监听的那个消息Topic上。

    3. 抽象的交付：规范在这里只定义了MFAF需要调用Nmfaf_3caDataManagement_Notify这个逻辑操作，至于这个操作具体是如何实现为向Kafka Topic发送一条消息，还是向AMQP队列推送一条消息，则属于MFAF的内部实现，3GPP标准对此保持了开放性。

    4. 最终送达：CityOps平台上的消费者程序从消息总线上收到了这条分析报告，并触发了相应的告警和调度流程。CityOps的后台系统（作为消费者的notification endpoint）在处理完消息后，会通过某种机制（可能也是通过MFAF的反向路径）进行确认（步骤12a）。

1.5 步骤15 - 20：优雅的退场与资源清理

场景：博览会结束，CityOps不再需要网络分析数据。

  1. CityOps向DCCF退订 (步骤15, 16)：CityOps向DCCF发起DELETE请求，取消订阅。DCCF将CityOps从自己的管理列表中移除。

  2. DCCF的决策与后端清理 (步骤17a, 17b)：DCCF会判断是否还有其他消费者需要同样的服务。如果没有，它会分别向NWDAF或ADRF发起退订请求，释放后端的分析和数据检索资源。这部分与5.2.4节相同。

  3. DCCF向MFAF发起“去配置” (步骤17c, 18c)：这是至关重要的新增步骤。在清理完后端资源后，DCCF还必须通知MFAF，它之前创建的“投递规则”已经作废。

    规范原文引用 (Step 17c & 19d in other flows):

    When DCCF determines that NF service consumer mapping has to be removed from MFAF, the DCCF may invoke the Nmfaf_3daDataManagement_Deconfigure service operation by sending an HTTP DELETE request message to the MFAF.

    DCCF会向步骤3中获取的配置资源URI发起一个HTTP DELETE请求，调用Nmfaf_3daDataManagement_Deconfigure服务。MFAF收到后，会删除内部的路由映射关系，并回收相关资源。

这个“去配置”的步骤确保了整个流程的完整性，避免了MFAF中残留大量无用的“僵尸规则”。

总结：MFAF，5G智能连接世界的桥梁

通过深度剖析5.2.5节的信令流程，我们看到了一个设计精巧、高度解耦的跨域智能协作框架。MFAF的引入，为5G网络数据分析的应用场景带来了质的飞跃。

  • 实现了协议的解耦：MFAF像一个“适配层”，将5G核心网内部统一的、基于HTTP/2的服务化接口，与外部世界多样化的、基于消息总线的IT系统隔离开来。核心网的各个NF（NWDAF、DCCF）无需关心最终消费者使用何种技术栈，只需与MFAF的标准接口交互即可。

  • 提升了系统的开放性：有了MFAF，运营商可以更安全、更便捷地将其宝贵的网络分析能力开放给第三方合作伙伴和垂直行业客户，催生出丰富的创新应用，实现商业价值的变现。

  • 优化了数据交付路径：通过“控制面（DCCF）”与“数据面（MFAF）”的分离，分析通知可以直接从数据源（NWDAF）发送到交付代理（MFAF），路径更短，效率更高，更适合大规模、低延迟的数据分发场景。

  • 完善了生命周期管理：通过Configure和Deconfigure这对“孪生”操作，DCCF可以动态地管理MFAF中的数据路由规则，确保了从订阅创建到最终拆除的整个生命周期内，所有相关资源都能被正确地创建、使用和清理。

如果说DCCF是网络智能的“内部总调度”，那么MFAF就是连接内部调度系统与外部广阔世界的“国际港口”。它俩的协同工作，共同构筑了一个既高效有序又开放灵活的5G网络智能生态系统。

在下一篇文章中，我们将把目光投向一个特殊的场景——漫游。我们将探讨5.2.6节“Procedure for Analytics Exposure in Roaming Case”，看看当用户身处异国他乡时，‘洞察者’们是如何跨越运营商的边界，进行协同分析，共同保障全球用户的智能体验的。

FAQ 环节

Q1：什么是“消息框架（Messaging Framework）”？它和HTTP API有什么不同？

A1：“消息框架”是一个通用的IT术语，通常指用于在不同应用程序或服务之间进行异步通信的中间件系统，也称为消息总线或消息队列。常见的例子有Apache Kafka, RabbitMQ, ActiveMQ等。它与HTTP API的主要区别在于通信模式：

  • HTTP API：通常是同步的、请求/响应式的。客户端发起一个请求，然后阻塞等待服务器的响应。它是一种紧耦合的、点对点的通信。

  • 消息框架：是异步的、发布/订阅式的。生产者将消息发布到一个主题（Topic）或队列（Queue），然后就可以继续做其他事，无需等待消费者。消费者则从它们感兴趣的主题或队列中拉取消息。它是一种松耦合的、一对多或多对多的通信模式，非常适合分布式系统和事件驱动架构。

Q2：为什么不让NWDAF直接支持Kafka等协议，而要引入MFAF这个额外的网元？

A2：这是一个重要的架构设计决策，旨在保持核心网的简洁性和稳定性：

  1. 保持核心网协议统一：5G核心网的设计原则是采用统一的服务化架构（SBA），所有内部NF间的交互都基于HTTP/2。如果要求每个NF（如NWDAF）都去支持Kafka、AMQP等多种多样的IT协议，将极大地增加核心网元的复杂度和维护成本。

  2. 专业化分工：MFAF专门负责协议适配和外部对接，使得核心NF可以专注于其核心业务逻辑（如NWDAF专注于分析）。这种分工使得系统各部分职责更清晰，更易于独立演进和扩展。

  3. 安全隔离：MFAF作为边界网元，可以承担更多的安全职责，将外部系统的复杂性和潜在风险隔离在核心网之外，保护核心网的稳定运行。

Q3：在MFAF的流程中，DCCF看起来只是做了一次转发，它的价值体现在哪里？

A3：DCCF的价值远不止转发。即使在MFAF流程中，DCCF的**“协调”**作用依然至关重要：

  1. 订阅聚合：DCCF的核心价值——汇聚多个消费者对同一分析服务的订阅——仍然存在。即使所有订阅都通过MFAF交付，DCCF仍然能确保只向NWDAF发起一次后端的订阅，从而节省NWDAF的资源。

  2. 生命周期管理：DCCF负责整个订阅生命周期的管理，包括创建、更新和最终的拆除。特别是，它负责在合适的时候调用MFAF的_Deconfigure操作，确保MFAF中的路由规则被正确清理。没有DCCF的管理，MFAF可能会产生大量无用的“僵尸”配置。

  3. 智能路由：DCCF还负责选择合适的NWDAF和MFAF实例来服务一个请求。在一个大型网络中，可能会有多个MFAF实例，分别对接不同的外部系统，DCCF负责将订阅请求路由到正确的MFAF。

Q4：MFAF的“3da”和“3ca”服务，可以理解为它的“南向接口”和“北向接口”吗？

A4：是的，这个类比在很大程度上是准确的。

  • 3da (3GPP DCCF Adaptor) 可以被视为MFAF的**“南向接口”**。它面向3GPP核心网内部（主要是DCCF），遵循3GPP定义的服务化接口标准，负责从核心网“接收”配置和数据。

  • 3ca (3GPP Consumer Adaptor) 可以被视为MFAF的**“北向接口”**。它面向最终的消费者或外部的消息框架，其具体的协议和实现是开放的，负责向外部世界“投递”数据。

3GPP标准详细定义了“南向”的3da接口，而对“北向”的3ca接口的实现细节则保持了灵活性，以适应不同的集成需求。

Q5：如果NWDAF的分析通知发送到MFAF失败了，会发生什么？有重传机制吗？

A5：是的，3GPP的服务化架构内置了可靠性机制。基于HTTP/2的交互本身就可以利用TCP的可靠传输。此外，在应用层，规范也定义了重传和故障处理逻辑：

  1. HTTP层面的重试：如果NWDAF向MFAF发送通知的HTTP请求失败（例如，收到5xx服务器错误或超时），NWDAF的客户端实现通常会根据预设的策略进行重试。

  2. 消费者确认机制：通知的接收方（无论是MFAF还是最终的消费者）都需要回复一个确认响应（如204 No Content）。如果发送方在一定时间内没有收到确认，它会认为通知失败，并可能进行重传。

  3. 消息框架的持久化：如果MFAF将消息发布到像Kafka这样的持久化消息框架，那么消息框架本身就提供了高可靠性。即使消费者暂时离线，当它重新上线后，仍然可以从Topic中读取到错过的消息。

这些多层次的机制共同确保了分析通知能够可靠地送达。

关系图谱