51学通信

深度解析 3GPP TS 29.552：5.5 Data Collection (数据收集流程)

22分钟阅读

好的，我们继续深入TS 29.552规范的脉络。在前几篇文章中，我们已经系统地探讨了NWDAF如何将它的“智慧”（分析结果）提供给外界。现在，我们将调转方向，探究这些智慧的源头——数据。本文将深入解析规范的5.5节，揭示‘洞察者’(Insight-AI)是如何构建其庞大“情报网”，从5G网络的各个角落收集其赖以生存的原始数据的。

深度解析 3GPP TS 29.552：5.5 Data Collection (数据收集流程)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将深度剖析5.5节“Data Collection”，为读者详细揭示NWDAF作为数据消费者，是如何通过标准化的服务化接口，从各个网络功能（NF）订阅和获取事件与数据，以及如何通过DCCF等协调实体，实现一个高效、有序、可扩展的数据收集框架的。

前言：智慧的食粮——数据从何而来

任何强大的人工智能，其根基都是海量、高质量的数据。对于5G的“智慧大脑”NWDAF而言，更是如此。没有精准、实时的网络数据作为“食粮”，‘洞察者’的一切分析和预测都将是无源之水、无本之木。

我们已经知道，‘洞- 察者’需要的数据来源极其广泛，涵盖了核心网的各个网元（AMF, SMF, UPF等）、传统的运维系统OAM，甚至是第三方的应用功能AF。那么，它究竟是通过怎样的“对话”机制来获取这些数据的呢？

这正是5.5节要回答的核心问题。这一节内容是整个网络数据分析体系的“输入端”，它定义了一系列标准化的数据收集流程。我们将再次回到“未来科技博览会”的场景，但这次，我们的视角将聚焦于‘洞察者’为了做出精准预测，在幕后所做的繁杂而有序的“情报收集”工作。

本篇文章将重点拆解以下几个核心的数据收集模式：

  1. 直接收集：NWDAF作为“特工”，直接向数据源（如AMF）发起订阅，获取第一手情报。

  2. 通过DCCF协调收集：NWDAF将收集任务委托给“数据助理”DCCF，由DCCF统一协调，避免重复劳动和信令风暴。

  3. 通过消息框架收集：在复杂的集成环境中，如何通过DCCF和“跨界快递员”MFAF，从外部消息总线系统中收集数据。

  4. 漫游场景下的数据收集：当需要分析的用户身处海外时，如何通过“大使馆”RE-NWDAF，合规地从到访地网络获取数据。

1. “一线特工”模式：直接从NF收集数据 (5.5.1)

这是最基础、最直接的数据收集模式。NWDAF扮演一个主动的消费者角色，直接向提供数据的NF（我们称之为“数据源NF”）发起订阅。

场景：为了预测博览会人流的移动趋势，‘洞察者’需要实时获取用户的位置变更事件。这些情报的核心来源是AMF（接入和移动性管理功能）。

此时，就会触发规范中 “Figure 5.5.1.1-1: Event Exposure Subscribe/Unsubscribe for NFs” 所描绘的流程。

步骤1a & 2a (可选)：用户授权检查

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

If data is to be collected for a user, the user consent has not been checked by the data consumer, if the local policy and regulations require to check user consent, the NWDAF shall invoke the Nudm_SDM_Get service operation…

在收集任何涉及个人用户的数据之前，隐私和合规是第一道红线。

  1. 动作：如果本地策略要求，‘洞- 察者’(NWDAF)必须首先向**UDM（统一数据管理）**发起一个Nudm_SDM_Get请求，查询目标用户的“用户授权”信息。

  2. 目的：确认用户是否同意运营商收集并使用其位置等数据用于网络分析和优化。

  3. UDM响应 (Step 2a)：UDM返回该用户的授权状态。如果用户未授权，‘洞- 察者’在后续步骤中，必须将该用户从数据收集的目标列表中排除。

步骤1b & 2b (可选)：订阅授权变更

为了确保授权状态的实时性，‘洞察者’还可以向UDM订阅用户授权信息的变更通知。这样，一旦用户通过手机App修改了他的隐私设置，UDM就会立刻通知‘洞察者’。

步骤3 & 4：发起数据事件订阅

规范原文引用 (Step 3):

In order to subscribe to notifications…of data events from the data source NF (e.g. UDM, AMF, SMF, NEF, AF), the NWDAF invokes the Nnf_EventExposure_Subscribe service operation by sending an HTTP POST (or PUT, for modification) request…

授权检查通过后，‘洞察者’正式开始它的“情报订阅”工作。

  1. 动作：‘洞察者’向AMF发起一个HTTP POST请求，调用其Namf_EventExposure_Subscribe服务。

  2. 请求体：在订阅请求中，‘洞察者’明确它的需求：

    • EventID: LOCATION_REPORT (位置上报)

    • TargetOfEventReporting: 指定目标用户，可以是单个用户（supi = "...")，也可以是一个区域内的所有用户 (anyUeInArea = { taiList: [...] })。

    • NotificationTargetAddress: ‘洞察者’自己的通知接收地址。

  3. AMF响应 (Step 4)：AMF收到订阅后，如果接受，则回复201 Created，并返回一个SubscriptionID，用于后续管理。

步骤5 - 8：接收通知与退订

规范原文引用 (Step 5):

If the NF observes the subscribed event(s), the NF invokes Nnf_EventExposure_Notify service operation to report the event(s) by sending an HTTP POST request…

  1. AMF上报事件 (Step 5)：当博览会场内的一位用户从A基站移动到B基站时，AMF会观测到这个位置变更事件。由于这个事件匹配了‘洞察者’的订阅条件，AMF会立刻向‘洞察者’提供的通知地址发送一个Namf_EventExposure_Notify通知。

  2. 通知内容：通知中包含了事件的详细信息，如用户ID、新的位置（Cell ID或TAI）、时间戳等。

  3. NWDAF确认 (Step 6b in subsequent flow)：‘洞察者’收到情报后，回复一个204 No Content表示确认。

  4. 退订 (Step 7 & 8)：分析任务结束后，‘洞察者’向AMF发起HTTP DELETE请求，取消订阅，释放AMF侧的资源。

这个流程具有普适性。‘洞察者’可以用完全相同的方式，向SMF订阅PDU会话建立事件 (Nsmf_EventExposure)，向PCF订阅策略变更事件 (尽管5.5.1没有明确列出，但逻辑是通用的)，向AF订阅应用层信息 (Naf_EventExposure) 等。

2. “总调中心”模式：通过DCCF协调收集 (5.5.3)

直接收集模式简单，但当“一线特工”太多时，就会造成混乱。为此，5G架构引入了DCCF来扮演“情报总协调官”的角色。

场景：博览会网络优化需要多个NWDAF实例协同工作。NWDAF-Mobility专职做移动性分析，NWDAF-Congestion专职做拥塞分析。它们都需要来自AMF的用户位置数据。

为了避免两个NWDAF都去“骚扰”AMF，它们都将数据收集任务委托给了DCCF。这个流程由 “Figure 5.5.3.1-1: Data Collection via DCCF” 描绘。

这个流程的结构，与我们之前在5.2.4节分析的“通过DCCF的分析暴露”流程惊人地相似，只是方向相反。

  1. NWDAF → DCCF (Step 1)：NWDAF-Mobility和NWDAF-Congestion分别向DCCF发起Ndccf_DataManagement_Subscribe请求，表达它们的数据需求。

  2. DCCF的智能协调 (Step 4, 5a)：DCCF收到两个请求后，发现它们都需要AMF的位置数据。于是，它执行了订阅聚合：只向AMF发起一次Namf_EventExposure_Subscribe订阅（Step 6a, 7a）。

  3. AMF → DCCF (Step 9a, 10a)：当用户位置变更时，AMF只向DCCF这个“总协调官”发送一次通知。

  4. DCCF → NWDAFs (Step 11, 12)：DCCF收到通知后，查询自己的“分发表”，发现NWDAF-Mobility和NWDAF-Congestion都需要这份情报，于是将通知分别转发给它们两个。

这个流程的核心价值在于效率。通过DCCF的协调，极大地降低了数据源NF的信令负载，并简化了数据消费者NWDAF的管理逻辑。

规范原文引用 (Step 4 NOTE 1):

If the contents of the subscription already perfectly match the new request then the update is performed simply to authorize the new source NF…

这个附注揭示了DCCF的一个高级特性：如果订阅已存在，DCCF可能只需要向数据源NF发送一个简单的“更新”请求，告诉它：“之前那个订阅，现在多了一个接收方”，而无需重新发送完整的订阅参数。这进一步提升了信令效率。

2.1 通过DCCF和MFAF收集数据 (5.5.3.2)

当数据源是一个位于外部IT系统，只能通过消息总线通信时，流程就需要DCCF和MFAF协同工作。这部分由 “Figure 5.5.3.2-1: Data Collection via DCCF and via Messaging Framework” 描绘。

场景：博览会部署了一套第三方的室内定位系统，该系统通过Kafka消息总线发布高精度的用户位置信息。‘洞察者’需要收集这些信息。

这个流程与5.2.5节“通过DCCF和MFAF暴露”同样是镜像关系：

  1. NWDAF → DCCF：‘洞察者’向DCCF发起订阅，并在请求中指明deliveryOption为MESSAGING_FRAMEWORK，并提供Kafka的连接信息。

  2. DCCF → MFAF：DCCF调用MFAF的_Configure服务，让MFAF去订阅Kafka的Topic，并告诉MFAF：“收到数据后，请通过3GPP接口通知我。”

  3. 数据流：当室内定位系统发布新位置到Kafka时，MFAF（作为Kafka消费者）获取到消息，然后将其转换为标准的_Notify通知，发送给DCCF。

  4. DCCF → NWDAF：DCCF再将这个通知转发给‘洞察者’。

通过这套复杂的“接力”，成功地将来自非3GPP系统的、基于消息总线的数据，无缝地集成到了5G核心网的数据收集中，极大地扩展了NWDAF的数据来源。

3. “跨国情报”：漫游场景下的数据收集 (5.5.4)

当需要分析的用户漫游到海外时，数据收集变得更加敏感和复杂。

3.1 收集出境用户在海外的数据 (5.5.4.1 Outbound roaming)

场景：“数智网联”的VIP用户“美美”漫游到了“GlobalConnect”网络。‘洞察者’需要了解她在当地的数据使用情况，以进行欺诈检测分析。

这个流程由 “Figure 5.5.4.1-1: data collection by H-RE-NWDAF from V-RE-NWDAF” 描绘。

  1. HPLMN侧：‘洞察者’（通过其“大使馆”H-RE-NWDAF）首先检查用户授权（Step 1）。

  2. HPLMN → VPLMN：H-RE-NWDAF向“GlobalConnect”的“大使馆”V-RE-NWDAF发起一个Nnwdaf_RoamingData_Subscribe请求（Step 3），请求订阅美美在VPLMN的数据使用事件。

  3. VPLMN侧：V-RE-NWDAF收到请求后，会检查漫游协议，确认是否被授权提供此类数据（Step 4a）。

  4. VPLMN内部收集：授权通过后，V-RE-NWDAF会在其内部，向本地的SMF/UPF发起数据收集订阅（Step 5）。

  5. 数据上报：当美美产生数据流量时，本地SMF/UPF将数据上报给V-RE-NWDAF，V-RE-NWDAF再对数据进行可能的“脱敏”处理（Step 6），然后通过Nnwdaf_RoamingData_Notify通知，将数据发送回HPLMN的H-RE-NWDAF（Step 7）。

3.2 收集入境用户在本地的数据 (5.5.4.2 Inbound roaming)

这个流程正好相反，是V-RE-NWDAF向H-RE-NWDAF请求数据，用于服务漫游到本地的Mr. Smith。这通常不是为了收集VPLMN的本地数据，而是为了获取HPLMN才能提供的、与用户相关的上下文数据（如签约信息），这些数据将作为在VPLMN进行分析的输入。流程与5.5.4.1对称，此处不再赘述。

总结：构建智能的基石

通过对5.5节的全面解析，我们看到了NWDAF数据收集框架的层次化、模块化和灵活性。

  • 分层的交互模式：从最简单的直接订阅，到通过DCCF进行协调，再到通过MFAF进行跨域适配，规范为不同复杂度的场景提供了不同的解决方案。

  • 隐私合规为先：所有涉及用户数据的收集，都将用户授权（User Consent）作为前置检查条件，体现了5G架构对隐私保护的重视。

  • 统一的事件暴露模型：无论是AMF、SMF还是AF，它们都通过一套统一的_EventExposure服务模型来提供数据，这大大简化了NWDAF作为消费者的实现复杂度。

  • 漫游场景的严谨设计：通过RE-NWDAF作为唯一的出入口，并强制进行漫游协议和用户授权检查，确保了跨国数据交换的安全、合规与可控。

数据收集是网络智能的第一步，也是最关键的一步。TS 29.552的5.5节，正是为这一步提供了坚实、可靠、可扩展的标准化流程，为‘洞察者’源源不断地输送着构建智慧的“食粮”。

在下一篇文章中，我们将探讨一个非常前沿的话题——5.6节“ML Model provisioning procedures”，看看NWDAF的“大脑”——机器学习模型，是如何在不同的NWDAF实例之间进行分发和共享的。

FAQ 环节

Q1：NWDAF可以直接从UPF收集数据吗？为什么流程图中经常看到通过SMF？

A1：NWDAF可以直接从UPF收集数据，也可以通过SMF间接收集。这两种方式有不同的适用场景：

  1. 通过SMF（控制面路径）：UPF是用户面网元，通常不直接暴露控制面接口给其他核心网NF。SMF作为PDU会话的控制者，管理着UPF上的会话规则。NWDAF向SMF订阅事件，SMF再通过N4接口向UPF下发报告规则，UPF将数据上报给SMF，SMF再转发给NWDAF。这是标准的、控制面驱动的方式。

  2. 直接从UPF（用户面/控制面混合路径）：在某些场景下，为了更高的效率或更丰富的数据，标准也定义了UPF可以直接向NWDAF暴露事件的服务（Nupf_EventExposure）。这需要UPF具备相应的服务化接口能力。这种方式路径更短，但对UPF的要求更高。

Q2：5.5.1节的流程图和5.2.2节的流程图看起来非常相似，它们有什么区别？

A2：它们确实非常相似，因为它们都遵循了5G SBA通用的订阅/通知模式。但它们的角色和视角是相反的：

  • 5.2.2 (分析暴露)：NWDAF是生产者(Producer)，其他NF是消费者(Consumer)。流程是消费者调用Nnwdaf_EventsSubscription_Subscribe服务，NWDAF通过_Notify提供分析结果。

  • 5.5.1 (数据收集)：NWDAF是消费者(Consumer)，其他NF（如AMF, SMF）是生产者(Producer)。流程是NWDAF调用N<NF>_EventExposure_Subscribe服务，数据源NF通过_Notify提供原始数据。

理解这种角色的互换，是掌握SBA架构“一切皆服务”思想的关键。

Q3：DCCF会缓存收集到的数据吗？

A3：DCCF可以缓存数据，但这不是它的强制功能。规范允许DCCF进行缓存以优化性能。例如，当DCCF从AMF收到一个位置更新通知后，它可以将这个通知缓存一小段时间。如果在这段时间内，有另一个NWDAF也来请求同样的数据（通过一次性GET请求），DCCF就可以直接从缓存中返回结果，而无需再次打扰AMF。然而，缓存的策略（缓存多久、缓存什么）属于DCCF的内部实现，由设备商自行决定。

Q4：在漫游数据收集中，HPLMN能获取到VPLMN的哪些数据？有限制吗？

A4：HPLMN能够获取哪些数据，受到漫游协议和VPLMN的本地策略的严格限制。V-RE-NWDAF是这个策略的执行点。通常，VPLMN只会提供与HPLMN用户直接相关的、经过聚合或脱敏的数据，而不会暴露其网络的内部拓扑、性能指标等敏感信息。例如，HPLMN可以请求其用户“美美”的数据使用总量，但VPLMN不太可能提供“美美”所在基站的PRB利用率这种涉及VPLMN网络自身运行状态的详细信息。数据共享的粒度和范围，是运营商之间商业谈判和技术约定的核心内容。

Q5：数据收集的实时性能如何？能满足URLLC等场景的需求吗？

A5：通过SBA的订阅/通知机制，数据收集可以达到准实时的水平，时延通常在秒级到亚秒级，这取决于数据源NF的处理能力和网络的传输时延。对于大多数网络优化和策略控制场景，这个实时性是足够的。但对于需要毫秒级甚至微秒级闭环控制的URLLC场景（如无线资源调度），这种核心网层面的数据收集-分析-决策闭环可能过长。这类超低时延的智能，通常需要将部分分析和决策能力下沉到RAN（无线接入网）或UPF边缘节点，形成更短、更快的“反射弧”。核心网的NWDAF则更多地负责中长周期的、更宏观的智能决策。

关系图谱