好的，我们继续本次的深度探索。在前一篇中，我们详细剖析了DCCF这位“数据总管家”的服务接口。我们知道，DCCF在很多场景下需要与一个名为“MFAF”的角色协作。今天，我们将揭开MFAF的神秘面纱，看看这位“万能适配器”是如何工作的。

深度解析 3GPP TS 23.288：9 MFAF Services Description (MFAF服务描述)

本文技术原理深度参考了3GPP TS 23.288 V18.9.0 (2025-03) Release 18规范中，关于“9 MFAF Services Description”的核心章节。本文旨在为读者详细阐述MFAF（消息框架适配功能）的服务化接口，揭示5G核心网如何通过这一关键的“适配层”，与运营商内部多样化的、非标准化的消息系统进行无缝集成。

在5G网络的智能化蓝图中，数据是流动的血液。3GPP定义了一套标准的服务化接口（SBI）来规范核心网内部的数据流动。然而，大型运营商的IT系统往往是一个历经多年建设的复杂生态，内部可能已经存在着一套成熟、高效的消息传递系统，例如基于Kafka, RabbitMQ, AMQP等技术的消息总线或消息框架（Messaging Framework）。

让5G核心网完全抛弃这些现有系统，全部改用SBI接口，既不现实也无必要。那么，如何让标准的5G世界与运营商“多姿多彩”的内部IT世界进行优雅的“对话”呢？MFAF (Messaging Framework Adaptor Function) 正是为此而生的“首席翻译官”和“协议转换网关”。

场景设定：运营商的数据湖平台是基于Kafka消息队列构建的。现在，网络智能团队希望将5G核心网中所有关于“用户体验（Service Experience）”的分析数据，实时地流入到Kafka的某个特定主题（Topic）中，供大数据平台进行离线分析和报表生成。直接让NWDAF去学习如何向Kafka发送消息是不现实的，这会破坏核心网架构的纯粹性。

1. MFAF的“双向翻译”：两大核心服务 (TS 23.288 Clause 9.1)

MFAF的核心工作是“双向翻译”。Table 9.1-1 概括了它的两大服务。

表格用途解读与重绘:

Table 9.1-1: NF services provided by MFAF

Service Name	Service Operations	Operation Semantics	Example Consumer(s)
Nmfaf_3daDataManagement	Configure, Deconfigure	Request / Response	DCCF, NWDAF
Nmfaf_3caDataManagement	Notify, Fetch	Subscribe / Notify	NWDAF, PCF, NSSF, AMF, SMF, NEF, AF, ADRF, LMF

这份清单揭示了MFAF的两个截然不同的“服务窗口”：

1. Nmfaf_3daDataManagement (3GPP DCCF Adaptor): 这是“从3GPP世界 到 消息框架世界”的配置服务。它的消费者是DCCF或NWDAF。通过这个服务，DCCF可以告诉MFAF：“请帮我订阅XX数据，并把收到的数据都发布到Kafka的YY主题上”。3da可以理解为“3GPP Data-producer-side Adaptor”。

2. Nmfaf_3caDataManagement (3GPP Consumer Adaptor): 这是“从消息框架世界 到 3GPP世界”的交付服务。它的消费者是所有需要通过消息框架接收数据的3GPP NF。例如，大数据平台（通过MFAF）向PCF推送数据。3ca可以理解为“3GPP Consumer-side Adaptor”。

2. Nmfaf_3daDataManagement 服务：配置“下行”数据流

这个服务允许DCCF或NWDAF像配置一个路由器一样，来配置MFAF的数据转发规则。

2.1 Configure 操作 (9.2.2)：建立翻译规则

这是核心的配置操作。DCCF通过调用此操作，向MFAF下发一条详细的“翻译和路由规则”。

Description: The consumer configures or reconfigures the MFAF to map data or analytics received by the MFAF to out-bound notification endpoints and to format and process the out-bound data or analytics.

核心输入参数解读 (Inputs, Optional):

• Data Consumer or Analytics Consumer Information: 最终收件人是谁？ 这里定义了3GPP侧的最终消费者信息，如PCF的通知地址和相关ID。

• Formatting Instructions & Processing Instructions: 数据在发送前需要做什么加工？ 这与我们之前讨论的DCCF能力一致，MFAF同样可以承担数据格式化和处理的工作。

• MFAF Notification Information: MFAF应该去哪里接收数据？

  “MFAF Notification Information” is used to identify Event Notifications received from a Data Source…If a Data Source is already supplying the data to the MFAF…is provided as an Input. If a new subscription…is needed, the MFAF Notification Information is not specified as an Input and the MFAF provides Notification Information as an output.

  这个参数非常巧妙：

  • 如果已经有一个数据流正在发往MFAF，DCCF会告诉MFAF：“请处理一下你已经收到的那个标记为XYZ的数据流”。
  • 如果需要MFAF去订阅一个新的数据流，DCCF不会提供这个参数，相反，MFAF会自己生成一个接收地址和ID，并通过输出参数返回给DCCF。DCCF随后会用这个地址去数据源（如NWDAF）那里为MFAF建立订阅。

• ADRF ID: 如果数据需要归档，可以指定ADRF的ID。

场景举例： DCCF希望将NWDAF-A产生的“用户体验”分析数据实时发送到Kafka的QoE_Analytics主题。

1. DCCF调用MFAF的Configure操作。
2. 在请求中，它并不直接指定Kafka的主题，这是MFAF的内部实现细节。相反，它可能会提供一个抽象的“外部目标标识”，或者MFAF会根据配置，知道这类数据应该被路由到Kafka。
3. 由于这是一个新的数据流，DCCF不提供MFAF Notification Information。
4. MFAF收到请求后，生成一个内部的接收地址（MFAF Notification Target Address + Correlation ID），并通过Configure操作的响应消息返回给DCCF。
5. DCCF拿到这个地址后，立即向NWDAF-A发起订阅（或修改订阅），将通知目标地址设置为MFAF返回的这个新地址。

从此，一条从NWDAF → MFAF → Kafka的数据管道就建立起来了。

2.2 Deconfigure 操作 (9.2.3)

当数据流不再需要时，DCCF调用此操作，传入之前Configure时返回的Transaction Reference Id，来删除MFAF上的这条“翻译和路由规则”。

3. Nmfaf_3caDataManagement 服务：处理“上行”数据流

这个服务定义了MFAF如何将来自消息框架的数据，以标准化的方式交付给3GPP核心网内的NF。它主要由Notify和Fetch两个操作组成，其功能与我们熟悉的Ndccf_DataManagement_Notify/Fetch非常相似。

3.1 Notify 操作 (9.3.2)

Description: Provides data or analytics or notification of availability of data or analytics to notification endpoints.

当MFAF从其背后的消息框架（如Kafka）中消费到一条需要发送给核心网的数据时，它会调用目标NF的Nmfaf_3caDataManagement_Notify服务。

• Inputs, Required: Notification Correlation Information (让消费者知道这是哪个数据流的通知)。
• Inputs, Optional: Requested Data with timestamp (数据本身) 或 Fetch Instructions (取货凭证)。

3.2 Fetch 操作 (9.3.3)

如果Notify中包含的是Fetch Instructions，消费者则会调用MFAF的Fetch服务，主动来拉取数据。

通过这两个操作，MFAF完美地扮演了一个标准化的数据提供者的角色，将非3GPP世界的复杂性完全屏蔽在了核心网之外。对于PCF来说，它无法也无需区分一个Notify是来自另一个NWDAF，还是来自DCCF，亦或是来自MFAF。它看到的，永远是标准、统一的服务接口。

4. Nmfaf_ContextManagement 服务：MFAF间的“搬家”

这是一个非常特殊的服务，仅包含一个Transfer操作，用于支持UE移动性场景下的MFAF重定位。

Service Description: This service is used to transfer MFAF UE context information to a consumer (e.g. a target MFAF). It may be triggered by a Nmfaf_3daDataManagement_Configure request.

场景举例： 一个服务于UE的特定数据流正通过A市的MFAF-A进行处理。当该UE移动到B市后，为了保证数据路径最优，DCCF决定将这个数据流的处理切换到B市的MFAF-B。此时：

1. DCCF向MFAF-A发起一个特殊的Configure请求，其中包含了MFAF Transfer Information，指示它准备“搬家”。
2. MFAF-A随后调用MFAF-B的Nmfaf_ContextManagement_Transfer服务，将与该UE相关的所有上下文信息（如订阅关系、处理状态等）打包发送给MFAF-B。
3. MFAF-B接手后，DCCF再更新数据源的通知地址，将数据流指向MFAF-B。

这个流程确保了即使在UE高速移动、服务节点切换的场景下，通过消息框架的数据流也能够实现平滑、无感知的交接。

5. 总结

第9章为我们揭示了5G核心网架构设计的巨大灵活性和前瞻性。MFAF的存在，如同在标准的“普通话”世界和各地方言之间，架起了一座座高效的“翻译桥梁”。

• 适配与解耦: MFAF将5G核心网与运营商多样化的内部消息框架彻底解耦。核心网NF只需面向标准的MFAF服务编程，而无需关心背后是Kafka还是其他任何技术，大大降低了集成复杂性。
• 双向网关: 通过3da和3ca两大服务，MFAF同时解决了数据“流入”和“流出”消息框架的双向适配问题。
• 能力继承: MFAF继承了DCCF的数据处理、格式化、Fetch模式等高级能力，使得通过消息框架的数据流同样可以享受这些“私人定制”服务。
• 支持移动性: 通过上下文迁移服务，MFAF能够适应UE移动性带来的服务节点变化，保证了服务的连续性。

MFAF虽然不是一个产生数据或分析的“智慧”节点，但它作为一个关键的“连接器”和“适配器”，极大地扩展了5G网络智能体系的应用边界，使得NWDAF产生的宝贵洞察能够轻松地与运营商的整个大数据和IT生态系统融为一体，从而释放出更大的商业价值。

---

FAQ - 常见问题解答

Q1：MFAF和NEF（网络开放功能）有什么区别？它们都是网关。 A1：MFAF和NEF都是网关，但它们的定位和应用场景完全不同。

• NEF 是面向外部第三方应用的安全网关。它暴露的是高度抽象的、业务导向的API，重点在于安全、认证、授权、计费和API管理，旨在构建一个开放的网络能力生态。
• MFAF 是面向运营商内部IT系统的协议适配网关。它主要解决的是3GPP SBI接口与内部非标准消息框架之间的协议转换和适配问题，重点在于集成和互操作，旨在打通核心网与内部数据平台的连接。 可以理解为，NEF是通往“外部世界”的大门，而MFAF是连接“内部不同部门”的走廊。

Q2：一个数据流可以同时经过DCCF和MFAF吗？它们的处理顺序是怎样的？ A2：可以，而且这是非常典型的协作模式。顺序通常是 数据源 → DCCF → MFAF → 消息框架。

1. DCCF首先扮演“总调度师”的角色，接收来自多个消费者的请求，进行去重、合并，然后向数据源发起统一的订阅。
2. 在DCCF的Ndccf_DataManagement_Subscribe请求中，消费者可以指定数据需要通过消息框架交付。
3. DCCF随后会调用MFAF的Configure服务，建立一条从MFAF到消息框架的路由。
4. 然后，DCCF向数据源订阅数据时，会将通知地址设置为MFAF的接收地址。 在这个流程中，DCCF负责“前端”的请求协调，MFAF负责“后端”的协议适配与分发。

Q3：为什么MFAF的服务要区分为3da和3ca？用一个服务不行吗？ A3：区分为3da (3GPP Data-producer-side Adaptor) 和 3ca (3GPP Consumer-side Adaptor) 是为了职责分离和接口清晰。

• 3daDataManagement 的交互发起方是3GPP NF（如DCCF），目的是配置MFAF如何处理从3GPP网络流出到消息框架的数据。这是一个管理和控制接口。
• 3caDataManagement 的交互发起方是MFAF，目的是将数据交付给3GPP NF。这是一个数据传输接口。 将配置流和数据流通过不同的服务进行分离，是服务化架构设计的最佳实践，使得接口定义更简洁，权责更清晰。

Q4：消息框架（Messaging Framework）本身是3GPP标准的一部分吗？ A4：不是。规范在 5A.3.2 节明确指出：“While the Messaging Framework is not standardized by 3GPP…”。消息框架的具体技术选型（Kafka, RabbitMQ等）及其内部实现，都属于运营商的内部事务，3GPP不作任何规定。3GPP只标准化了MFAF这个“适配器”的对外接口，即Nmfaf系列服务。这种设计保证了核心网的标准化，同时给予了运营商在内部IT架构上最大的自由度。

Q5：什么情况下会触发MFAF的上下文迁移（Context Transfer）？ A5：MFAF的上下文迁移主要与有状态的、与UE绑定的数据流处理相关，并且UE发生了移动。例如，假设MFAF正在为一个特定UE的视频流进行实时的数据格式转换，这个转换过程是有状态的。当UE移动导致其服务的UPF和SMF发生变更，进而DCCF也决定将其服务节点从MFAF-A切换到MFAF-B时，就需要将MFAF-A中关于这个视频流转换的“状态信息”迁移到MFAF-B，以保证在切换过程中视频流处理不会中断或出现错误。