51学通信

深度解析 3GPP TS 29.552：5.2.4 Analytics Exposure via DCCF (通过DCCF的分析暴露)

22分钟阅读

好的，我们继续进行深度拆解。接续上一篇对分析暴露基础流程的探讨，本文将聚焦于一个更高级、更具扩展性的机制——通过数据收集协调功能（DCCF）进行分析暴露。

深度解析 3GPP TS 29.552：5.2.4 Analytics Exposure via DCCF (通过DCCF的分析暴露)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将深度剖析5.2.4节 “Analytics Exposure via DCCF”，旨在为读者详细阐述在复杂的5G网络中，如何引入DCCF这一“协调中心”来优化和管理分析服务的订阅与分发流程，从而构建一个更高效、更具扩展性的网络智能生态。

前言：从“单线联系”到“总调中心”

在上一篇文章中，我们掌握了分析消费者（如PCF、AF）与NWDAF进行“对话”的两种基本模式：高效的“订阅/通知”和直接的“请求/响应”。这些流程如同“单线联系”，清晰地定义了一对一的交互。然而，在一个庞大而繁忙的5G网络中，情况远比这复杂。

让我们回到“未来科技博览会”的场景。会场中不仅有“HoloVerse”的AR游戏，还有“DroneLogistics”的无人机巡检队，以及“AutoDrive”的自动驾驶接驳车队。它们都对主展馆区域的网络质量和稳定性有着极高的要求。如果这三家公司的应用（AF）都分别向‘洞察者’(Insight-AI)订阅相同的网络分析服务（例如，区域用户拥塞情况），‘洞察者’就需要为每一个订阅者维护一个独立的订阅关系，并可能重复执行相同的分析计算。当消费者数量激增时，‘洞察者’将不堪重负。

为了解决这个问题，5G架构引入了一个至关重要的角色——DCCF (Data Collection Coordination Function)。在数据收集中，我们称它为“数据助理”；而在分析暴露的场景下，它更像是一个**“分析服务总调中心”或“订阅代理”**。它站在众多消费者和‘洞察者’之间，负责统一接收、管理和分发分析订阅，极大地提升了整个系统的效率和可扩展性。

本文将聚焦于规范5.2.4节，详细拆解当DCCF介入后，分析暴露的信令流程是如何演变的。我们将看到，这个“总调中心”是如何智能地处理实时数据与历史数据请求，并为所有客户提供无缝服务的。

1. DCCF介入：分析暴露流程的“升维”

5.2.4节的核心，是定义了消费者如何通过DCCF来间接地订阅NWDAF的分析服务。

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

This procedure is used by NF service consumer(s) based on local configuration, to subscribe/unsubscribe to NWDAF analytics event(s) via the DCCF, and upon the delivery option “Delivery via DCCF” configured on the DCCF, also used by DCCF to notify the NF service consumer(s) of the analytics information via the DCCF if subscribed before.

这段话明确了几个关键前提：

  • 配置决定路径：消费者是直接访问NWDAF还是通过DCCF，是由运营商的“本地配置 (local configuration)”决定的。这意味着在网络部署时，就可以规划好哪些服务的订阅应该走DCCF这条“高速公路”。

  • DCCF的双重角色：DCCF既是订阅请求的接收者，也是后续分析通知的分发者。它完整地代理了消费者与NWDAF之间的交互。

为了完整地理解这个流程，我们将跟随规范中的 “Figure 5.2.4-1: Analytics Exposure via DCCF”，一步步拆解“HoloVerse”公司向DCCF订阅分析服务的全过程。

1.1 步骤1：消费者向DCCF发起订阅

场景：“HoloVerse”的AR游戏应用（AF）根据网络配置，得知它应该向DCCF这个“总调中心”提交它的网络监控需求。

规范原文引用 (Step 1):

In order to subscribe to notification(s) of analytics exposure via the DCCF based on local configuration, the NF service consumer invokes the Ndccf_DataManagement_Subscribe service operation by sending an HTTP POST request message targeting the resource “DCCF Analytics Subscriptions”, the HTTP POST message shall include the NdccfAnalyticsSubscription data structure as request body…

这个步骤的技术细节是：

  1. 动作：HoloVerse AF向DCCF发起一个HTTP POST请求。

  2. 目标URI：请求的目标不再是NWDAF，而是DCCF暴露的.../ndccf-datamanagement/v1/subscriptions资源。注意接口名称从nnwdaf变成了ndccf。

  3. 请求体：消息体中包含了NdccfAnalyticsSubscription数据结构，其内容与直接订阅NWDAF时类似，包括了希望订阅的分析ID (analyticsId)、过滤条件（如areaOfInterest）和通知地址（notificationUri）。

HoloVerse AF的需求单（请求体）写着：“我需要主展馆区域的‘用户拥塞’(USER_DATA_CONGESTION)分析，一旦拥塞等级达到‘高’，请通知我。”

1.2 步骤2 & 3a：DCCF的智能决策 - “我需要新的情报吗？”

这是DCCF发挥其“协调”核心价值的关键步骤。收到HoloVerse AF的请求后，DCCF不会立刻无脑转发给‘洞察者’。它会先进行一系列内部的“思考”。

规范原文引用 (Step 2 & 3a):

  1. The DCCF keeps track of the analytics actively being collected for the Analytics Subscription it is coordinating… The DCCF may then determine whether certain historical analytics data may be available…

3a. The DCCF shall determine whether the analytics requested are already being collected. If the requested analytics are already being collected…, the DCCF adds the new NF service consumer to the list of NF service consumers that are subscribed…

DCCF的决策逻辑可以简化为以下流程：

  1. 检查缓存/现有订阅：DCCF会检查自己的“订阅清单”，看看是否已经有其他消费者（比如“DroneLogistics”）正在订阅完全相同或非常相似的分析服务。

  2. 处理历史数据请求：DCCF还会判断请求是针对未来的实时数据，还是过去的“历史数据”。如果是历史数据，它会查询ADRF或NWDAF的“档案馆”。(我们将在后续步骤详细讨论历史数据)

  3. 做出决策：

    • 情况一（完全匹配）：如果“DroneLogistics”已经订阅了主展馆区域的“高”等级拥塞告警，DCCF发现HoloVerse的需求完全一样。此时，DCCF不需要向‘洞察者’发起任何新的请求。它只需在自己的通知列表里，把HoloVerse AF的通知地址也加上。然后直接跳到步骤6，向HoloVerse确认订阅成功。

    • 情况二（部分匹配/需要更新）：如果“DroneLogistics”订阅的是“中”等级拥塞告警，而HoloVerse需要“高”等级。DCCF可能会向‘洞察者’发起一个HTTP PUT请求，更新其现有订阅，将告警阈值调整为同时覆盖“中”和“高”。

    • 情况三（全新请求）：如果HoloVerse是第一个对这个分析服务提需求的，那么DCCF就必须代表它向‘洞察者’发起一个新的订阅。

1.3 步骤4a & 5a：DCCF向NWDAF发起订阅 (针对实时数据)

假设是上述的“情况三”，HoloVerse是第一个吃螃蟹的人。

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

If the analytics requested at step 1 are not already available yet, the DCCF shall invoke the Nnwdaf_EventsSubscription_Subscribe service operation by sending an HTTP POST request message…to the NWDAF…

这个过程就是我们将上一篇文章中5.2.2.1节的流程，由DCCF来扮演“消费者”的角色：

  1. 动作：DCCF向‘洞察者’(NWDAF)发起一个HTTP POST请求，调用Nnwdaf_EventsSubscription_Subscribe服务。

  2. 请求内容：请求体里的内容源自HoloVerse的需求，即订阅主展馆区域的USER_DATA_CONGESTION分析。

  3. 注意：DCCF提供给NWDAF的通知地址(notificationUri)是DCCF自己的地址，而不是HoloVerse的。因为后续‘洞察者’只需要通知DCCF这个“总调中心”即可。

  4. NWDAF响应 (Step 5a)：‘洞察者’接受订阅后，会回复201 Created给DCCF，并返回这个订阅的subscriptionId。DCCF会将这个ID与HoloVerse的原始请求关联起来。

1.4 步骤3b/c, 4b/c, 5b/c：处理历史数据请求

场景：“AutoDrive”公司的工程师想要复盘昨天上午的自动驾驶接驳车网络体验，他们需要获取昨天上午9点到10点主展馆区域的QoS分析报告。这是一个对历史数据的请求。

DCCF收到这个请求后，会进入历史数据处理分支。

规范原文引用 (Step 3b, 4b, 5b & 3c, 4c, 5c):

3b. If the historical analytics data handling is applicable, and the DCCF determine to retrieve analytics data from the ADRF…

4b. …the DCCF shall invoke the Nadrf_DataManagement_RetrievalSubscribe service operation…

3c. If …the DCCF determine to retrieve analytics data from the NWDAF…

4c. …the DCCF may invoke the Nnwdaf_EventsSubscription_Subscribe service operation…or Nnwdaf_AnalyticsInfo_Request request…

DCCF知道历史数据可能存储在两个地方：

  • ADRF (档案馆)：如果数据已经被归档到ADRF，DCCF会执行步骤4b，向ADRF发起Nadrf_DataManagement_RetrievalSubscribe请求，从“档案馆”里检索数据。

  • NWDAF (短期记忆)：‘洞察者’自己可能也会缓存近期的分析结果。如果DCCF认为数据还在NWDAF那里，它会执行步骤4c，向NWDAF发起请求（可以通过订阅一次性事件，或直接GET请求）。

这个决策过程体现了DCCF作为“协调中心”的智能性，它了解整个数据分析生态的“数据地图”。

1.5 步骤6 - 12：通知的汇聚与分发

这是DCCF价值的最终体现。

场景：下午3点，‘洞察者’预测到主展馆即将发生网络拥塞。

  1. NWDAF通知DCCF (Step 7a, 8a)：‘洞察者’只会发送一条通知给DCCF这个“总调中心”，告诉它：“主展馆拥塞等级为‘高’”。DCCF收到后回复204 No Content确认。

  2. DCCF分发通知 (Step 9, 10)：DCCF收到这条通知后，立刻查询自己的“订阅清单”。它发现“HoloVerse”和“DroneLogistics”都订阅了这个告警。于是，DCCF会分别向HoloVerse的通知地址和DroneLogistics的通知地址发送Ndccf_DataManagement_Notify通知。

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

    According to Formatting Instructions provided by the NF service consumer, multiple notifications from a NWDAF can be combined in a single Ndccf_DataManagement_Notify… Alternatively, a notification can instruct the analytics notification endpoint to fetch the analytics from the DCCF.

    这个NOTE非常关键，它揭示了DCCF的两个高级分发能力：

    • 格式化与聚合：如果HoloVerse要求的数据格式是JSON，而DroneLogistics要求XML，DCCF可以负责进行格式转换。DCCF还可以将来自多个不同NWDAF的多个通知，聚合成一个通知发给消费者。

    • Fetch机制 (步骤11, 12)：如果分析报告非常大（例如，一个包含数千个用户移动轨迹的详细文件），直接放在通知里会造成消息体过大。此时，DCCF的通知（步骤9）可以只包含一个摘要和“取件码”，告诉消费者：“拥塞报告已生成，请在1小时内凭此ID来我这里（DCCF）获取。” 消费者收到后，再通过一个HTTP GET请求（Ndccf_DataManagement_Fetch）来主动拉取完整的报告。

1.6 步骤13 - 16：智能的退订管理

场景：“HoloVerse”的应用下线，它向DCCF发起了退订请求。

  1. 消费者退订DCCF (Step 13, 14)：HoloVerse向DCCF发起DELETE请求，取消它的订阅。DCCF收到后，将HoloVerse从它的通知列表中移除，并回复确认。

  2. DCCF的智能决策 (Step 15a, 15b)：DCCF在移除HoloVerse后，会再次检查它的“订阅清单”。

    • 如果发现还有“DroneLogistics”在订阅同样的服务，DCCF什么也不做。它与‘洞察者’之间的订阅关系保持不变。

    • 如果发现HoloVerse是最后一个订阅者，移除它之后，这张清单就空了。此时，DCCF才会向‘洞察者’(NWDAF)发起Nnwdaf_EventsSubscription_Unsubscribe请求（步骤15a），或者向ADRF发起Nadrf_DataManagement_RetrievalUnSubscribe请求（步骤15b），取消后端的订阅，从而释放网络和系统资源。

这个过程完美地体现了DCCF作为资源协调者的角色，它确保了只有在真正需要时，分析服务才会被激活。

总结：DCCF，构建可扩展智能网络的粘合剂

通过对5.2.4节的深度解构，我们清晰地看到了DCCF在分析暴露流程中不可或缺的价值。它不仅仅是一个简单的消息转发器，更是一个智能的协调者、优化者和管理者。

  • 对消费者而言，DCCF提供了一个稳定、统一的服务接入点。消费者无需关心后端NWDAF的复杂部署，只需与DCCF交互即可。

  • 对NWDAF而言，DCCF如同一个“防火墙”和“负载均衡器”，将成千上万的前端订阅请求，收敛为少数几条经过优化的后端订阅，极大地减轻了NWDAF的信令处理和计算压力。

  • 对整个网络而言，DCCF通过其智能的订阅生命周期管理和资源协调能力，避免了信令风暴，提升了系统整体的效率和可扩展性，是构建大规模、运营商级网络智能生态的关键“粘合剂”。

在下一篇文章中，我们将继续探讨5.2.5节 “Analytics Exposure via DCCF and MFAF”，看看当消息框架适配器MFAF也加入这个流程后，整个交互会变得如何更加灵活，以适应更多样化的网络集成场景。

FAQ 环节

Q1：DCCF是专门为分析暴露设计的吗？它和数据收集有什么关系？

A1：DCCF (Data Collection Coordination Function) 的设计初衷是为了协调数据收集，其名称也反映了这一点。然而，由于其作为“中间人”的协调、代理和聚合能力具有通用性，3GPP标准将其能力也扩展到了分析暴露的场景。因此，DCCF扮演着双重角色：

  1. 在数据收集中：它汇聚来自NWDAF等消费者的“数据需求”，统一向AMF、SMF等数据源发起订阅。

  2. 在分析暴露中：它汇聚来自PCF、AF等消费者的“分析需求”，统一向NWDAF发起订阅。

这两个场景的架构和流程是高度对称的，DCCF在其中都起到了降低信令负载、解耦系统和提升效率的核心作用。

Q2：在实际部署中，DCCF是必须和NWDAF一起部署的吗？

A2：不是必须的。DCCF是一个可选的网络功能。运营商可以根据网络规模和业务复杂性来决定部署策略：

  • 小型或简单网络：可能不部署DCCF，所有的分析消费者直接与NWDAF进行交互。

  • 大型或复杂网络：强烈建议部署DCCF。当网络中存在大量分析消费者（例如，众多的AF、PCF实例）和/或多个NWDAF实例时，DCCF的协调优化能力将带来巨大的性能和管理优势。

Q3：DCCF是如何知道历史数据存储在ADRF还是NWDAF的？

A3：这是通过DCCF的数据画像注册与发现机制实现的。在规范5.5.2节 “Data collection profile registration”中定义了相关流程：NWDAF或ADRF在收集或存储了某些数据后，可以主动向DCCF注册一个“数据画像(profile)”，告知DCCF“我这里存有关于某区域、某时间段的某类型数据”。DCCF会维护这样一张“数据地图”。当它收到一个历史数据请求时，就会查询这张地图，从而智能地决策应该向ADRF还是NWDAF去请求数据。

Q4：为什么规范在步骤9的NOTE中提到了“Formatting Instructions”？这有什么实际用途？

A4：“Formatting Instructions”（格式化指令）是一个非常实用和灵活的设计。它允许消费者在订阅时，告知DCCF它希望收到的通知是什么样的。这有多种用途：

  1. 数据格式适配：一个消费者可能希望收到JSON格式的通知，另一个可能需要Protobuf格式。DCCF可以根据指令进行转换。

  2. 信息详略控制：一个用于仪表盘展示的消费者可能只需要一个总体的拥塞等级（“高”），而一个用于根因分析的运维系统可能需要详细的指标数据（PRB利用率、用户数等）。消费者可以在订阅时指定通知的详细程度。

  3. 自定义聚合：消费者可以指示DCCF将来自不同源的多个通知聚合成一个，并以特定的结构呈现。

这个机制使得DCCF不仅仅是代理，更是一个轻量级的数据处理和适配平台，增强了整个框架的灵活性。

Q5：消费者如何知道自己应该连接到哪个DCCF实例？

A5：与5G中所有网络功能的发现机制一样，这通常是通过NRF (Network Repository Function) 实现的。当一个消费者（如AF）需要寻找DCCF时，它会向NRF发起一个NF发现请求，请求中可以包含它所需要的DCCF的能力、支持的区域等信息。NRF会返回一个或多个符合条件的DCCF实例的地址（Endpoint FQDN/IP）。消费者可以根据返回的列表，选择一个DCCF实例进行交互。这个发现和选择的过程，确保了系统的动态性和高可用性。

关系图谱