51学通信

深度解析 3GPP TS 29.552：5.3 Analytics Aggregation from Multiple NWDAFs (多NWDAF分析聚合)

25分钟阅读

好的，我们继续对TS 29.552规范的深度探索。在前文中，我们已经全面掌握了NWDAF如何对外暴露其分析服务，无论是直接暴露，还是通过DCCF、MFAF以及在漫游场景下的复杂协作。现在，我们将进入一个全新的维度，探讨当网络中存在多个“智慧大脑”时，它们如何协同工作，汇聚各自的洞察，从而形成一个覆盖范围更广、能力更强的“超级大脑”。

深度解析 3GPP TS 29.552：5.3 Analytics Aggregation from Multiple NWDAFs (多NWDAF分析聚合)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将深度剖析5.3节“Analytics Aggregation from Multiple NWDAFs”，为读者揭示在分区域、分领域部署多个NWDAF的场景下，一个具备聚合能力的NWDAF是如何扮演“总指挥”的角色，向上游消费者提供一个统一、全局的网络智能视图的。

前言：从“个体智慧”到“集体智慧”

随着5G网络规模的急剧扩张和业务的日益复杂化，依靠单个、中心化的“超级大脑”来分析整个网络变得越来越不现实。这不仅会带来巨大的计算和信令压力，也难以适应边缘计算和区域化运营的趋势。因此，一个更现实、更具扩展性的部署模式是：分而治之。

运营商可能会在网络中部署多个NWDAF实例，每个实例都是一个“领域专家”：

  • 按地理区域划分：一个NWDAF负责华北区的网络分析，另一个负责华东区。

  • 按分析类型划分：一个NWDAF专门负责安全相关的异常行为分析，另一个专门负责网络切片的性能分析。

  • 按网络层级划分：边缘NWDAF负责区域性的实时分析，中心NWDAF负责全局的、长周期的趋势分析。

这种分布式部署模式带来了新的挑战：当一个消费者，例如运营商的全国网络监控中心（我们称之为**“NOC”**），需要一个覆盖全国的网络拥塞态势图时，它该向谁请求呢？它不应该、也不需要去分别和几十个区域NWDAF一一对话。

为了解决这个问题，3GPP定义了分析聚合 (Analytics Aggregation) 机制。这套机制的核心是引入一个具备“聚合能力”的特殊NWDAF角色，我们称之为聚合NWDAF (Aggregator NWDAF)。它就像一个“总指挥官”或“主编”，负责接收来自消费者的全局性分析请求，将其智能地分解并发放给各个“领域专家”（下游NWDAF），然后收集、整理、汇总所有专家的报告，最终形成一份全面、统一的“战报”或“深度报道”，呈现给最终的消费者。

本篇文章，我们将聚焦于5.3节，探讨两种核心的聚合场景：

  1. 按地理区域聚合：当消费者明确指定了要分析的区域（Area of Interest）时，聚合NWDAF如何找到并协调服务于这些区域的“下属”。

  2. 按用户/会话聚合：当消费者关心的是某个特定用户或业务流，但并不知道它当前在哪个区域时，聚合NWDAF又该如何“侦察”并定位到正确的“领域专家”。

1. “分而治之，统筹全局”：分析聚合总则 (5.3.1 General)

本节为我们描绘了分析聚合的基本概念和动机。

规范原文引用 (Clause 5.3.1 General):

Analytics Aggregation refers to the case in which an NWDAF with respective capabilities aggregates the analytics provided by other NWDAFs to serve a request from an NF service consumer.

If multiple NWDAFs are deployed, an NWDAF instance may be specialized to provide Analytics for one or more Analytics event(s). Each NWDAF instance may serve a certain Area of Interest or TAI(s) and multiple NWDAFs may be needed to serve a particular Analytics event collectively. An NWDAF may have the capability to aggregate the Analytics…

‘洞察者’(Insight-AI)集群的总指挥官——我们称之为**‘洞察者-Prime’**——解释道：“我的核心职责就是‘化零为整’。NOC不需要知道我的团队里有多少个区域经理（下游NWDAF），它只需要向我下达指令，我来负责协调我的团队完成任务，并提交一份最终报告。”

这段话明确了聚合的本质：

  • 能力是关键：并非所有NWDAF都具备聚合能力。一个NWDAF必须在其NF Profile中声明自己具备"aggregation"能力，才能被消费者选为聚合NWDAF。

  • 分工是前提：聚合的存在，是基于下游NWDAF“术业有专攻”这一前提。有的专攻地理区域，有的专攻分析类型。

  • 聚合是过程：聚合NWDAF自身也可能产生分析结果，并将自己的分析与从下游收集来的分析进行合并，形成一个更全面的视图。

2. “按图索骥”：按指定区域进行聚合 (5.3.2 Analytics aggregation with provisioning of Area of Interest)

这是最常见的一种聚合场景。消费者明确知道自己关心的地理范围。

场景：国家气象局发布了超强台风预警，预计将在未来24小时内影响我国东南沿海的三个省份。运营商的NOC（作为分析消费者）需要立即获取这三个省份的网络性能预测分析，以提前做好应急预案。

此时，NOC就会向聚合NWDAF ‘洞察者-Prime’ 发起一个包含了明确“兴趣区域(Area of Interest)”的分析请求，触发 “Figure 5.3.2-1: Analytics aggregation with provisioning of Area of Interest” 所示的流程。

步骤1a-1c：消费者发起全局订阅

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

In order to obtain the specific network data analytics, the NF service consumer selects an NWDAF (e.g. NWDAF1) with aggregation capability… The NWDAF service consumer invokes Nnwdaf_AnalyticsInfo_Request or Nnwdaf_EventsSubscription_Subscribe service operations… In the request message, the analytics event, analytics filter information including the Area of Interest (e.g. TAI-1, TAI-2, TAI-n…) … are provided.

  1. 选择聚合者：NOC首先通过NRF发现一个具备聚合能力的NWDAF，即‘洞察者-Prime’。

  2. 发起请求：NOC向‘洞察者-Prime’发起一个Nnwdaf_EventsSubscription_Subscribe请求。

  3. 请求体：这份“作战指令”的核心内容是eventFilter，其中明确包含了AreaOfInterest参数，其值为覆盖东南三省所有基站的TAI（Tracking Area Identity）列表。请求的analyticsId是NETWORK_PERFORMANCE。

步骤2-5b：聚合者分解并下发任务

规范原文引用 (Step 2-5b):

The Aggregator NWDAF selects the other NWDAF instances, which collectively can cover the area of interest indicated in the request, according to the results returned by the NRF and/or the UDM, or available information obtained by other means. The Aggregator NWDAF invokes Nnwdaf_AnalyticsInfo_Request or Nnwdaf_EventsSubscription_Subscribe service operations to each selected NWDAF (e.g. NWDAF2, NWDAF3)…

收到指令后，‘洞察者-Prime’立刻开始分解任务：

  1. “作战地图”查询：‘洞察者-Prime’需要知道哪个“区域经理”（下游NWDAF）负责哪个省。它通过向NRF查询，获取一张“NWDAF能力与覆盖范围地图”。查询条件就是NOC提供的TAI列表。

  2. 任务分解：NRF的查询结果告诉它，NWDAF2负责福建省，NWDAF3负责浙江省，NWDAF4负责广东省。

  3. 下发指令：‘洞察者-Prime’随即向NWDAF2、NWDAF3、NWDAF4分别发起Nnwdaf_EventsSubscription_Subscribe请求。每个请求中的AreaOfInterest都被缩减为各自负责的省份的TAI列表。这体现了“分治”的思想。

步骤6-9b：下游NWDAF执行并上报

各个“区域经理”收到指令后，立刻开始在自己的“辖区”内进行分析。它们会收集本地AMF、OAM的数据，生成对本地网络性能的预测报告。

规范原文引用 (Step 6-9b):

The selected NWDAFs send response or notification containing the requested analytics to the Aggregator NWDAF.

当分析完成后，NWDAF2、NWDAF3、NWDAF4会分别通过Nnwdaf_EventsSubscription_Notify服务，将各自的分析报告（例如，“福建省沿海区域预计信号强度将下降20%”）上报给“总指挥”‘洞察者-Prime’。

步骤10 & 11a-11c：聚合者汇总并最终交付

规范原文引用 (Step 10 & 11a-11c):

  1. The Aggregator NWDAF aggregates the analytics received from the selected NWDAFs and the analytics of its own.

11a-11c. The Aggregator NWDAF sends a response or notification containing the aggregated output analytics for the requested Analytics event(s) to the NWDAF service consumer.

‘洞察者-Prime’的办公桌上，陆续收到了来自东南三省的分析报告。它的最后一步工作是：

  1. 信息聚合 (Step 10)：将三份报告汇总，可能会进行数据清洗、格式统一、摘要生成等处理。如果‘洞察者-Prime’自己也负责一些全国性的数据分析，它还会将自己的分析结果融合进去。

  2. 最终交付 (Step 11)：‘洞察者-Prime’将这份完整的、覆盖东南三省的“台风影响下网络性能综合预测报告”通过Nnwdaf_EventsSubscription_Notify服务，发送给NOC。

NOC收到报告后，就可以据此进行精准的资源调度和应急准备，例如，提前向沿海地区派遣应急通信车。通过这套聚合流程，NOC实现了“运筹帷幄之中，决胜千里之外”，而无需关心底层的复杂分工。

3. “大海捞针”：无指定区域的聚合 (5.3.3 Analytics aggregation without provisioning of Area of Interest)

在某些场景下，消费者关心的是某个特定的对象（如一个UE），但并不知道这个对象当前位于何处。

场景：一位全国漫游的超级VIP用户“王总”投诉手机上网慢。“王总”可能在任何地方。客服中心的顶级专家（作为分析消费者）需要立即获取“王总”当前位置的网络质量和通信模式分析，以快速定位问题。

此时，专家会向‘洞察者-Prime’发起一个不包含Area of Interest，但包含用户标识（如SUPI）的分析请求，触发 “Figure 5.3.3-1: Analytics aggregation without provisioning of Area of Interest” 所示的流程。

步骤1a-1c：发起针对特定UE的请求

与前一个场景类似，专家向‘洞察者-Prime’发起订阅，但这次eventFilter中的关键参数是supi = "SUPI-of-Mr-Wang"，而没有AreaOfInterest。

步骤2a-6：“总指挥”变身“侦探”

规范原文引用 (Step 2a-4b, 5, 6):

2a-4b. If the requested analytics requires UE location information…the Aggregator NWDAF may query UDM to discover the NWDAF serving the UE…or…determine the AMF serving the UE, then requests UE location information from the AMF…

  1. With the data obtained…, the Aggregator NWDAF may query the NRF for discovering the required NWDAF, by sending an NF discovery request including UE location or NF serving area as a filter to NRF…

收到请求后，‘洞察者-Prime’的首要任务不再是“查地图”，而是“找人”。它需要先定位到“王总”在哪里，然后才能找到为他服务的“区域经理”。

  1. 定位UE：‘洞察者-Prime’有多种方法来定位王总：

    • 查询UDM (步骤2a-2b)：UDM中可能注册了为该用户提供服务的AMF信息。‘洞察者-Prime’可以查询UDM，直接获取AMF的地址。

    • 查询AMF (步骤3a-4b)：如果知道了AMF，就可以向AMF订阅该用户的实时位置信息。

  2. 定位NWDAF (步骤6)：一旦知道了王总当前所在的TAI或Cell ID，问题就转化为了我们熟悉的“按图索骥”。‘洞察者-Prime’会拿着这个位置信息去查询NRF，找到负责该区域的下游NWDAF。

步骤7 & 8：重定向或任务下发

规范原文引用 (Step 7 & 8):

  1. If a single target NWDAF (e.g. NWDAF2) can provide the requested analytics data, the Aggregator NWDAF can redirect the Nnwdaf_AnalyticsInfo_Request to that target NWDAF or request an analytics subscription transfer to that target NWDAF.
  1. If the Aggregator NWDAF decides to request analytics from one or more target NWDAFs, the steps 2-9b of the analytics aggregation procedure in clause 5.3.2 are executed.

找到目标NWDAF（比如，发现王总正在四川，由NWDAF5负责）后，‘洞察者-Prime’有两种处理方式：

  • 重定向 (步骤7)：如果‘洞察者-Prime’认为自己在这个流程中没有必要再掺和，它可以向请求者（客服专家）返回一个HTTP 307 Temporary Redirect响应，告诉他：“请直接去找NWDAF5，它能帮你解决问题。” 这种方式更直接高效。

  • 继续代理 (步骤8)：如果‘洞察者-Prime’需要对结果进行二次处理，或者希望对消费者屏蔽下游细节，它会选择继续扮演“总指挥”的角色。此时，流程就回到了5.3.2的模式：‘洞察者-Prime’向NWDAF5下发任务，接收报告，然后交付给客服专家。

通过这套“侦察-定位-执行”的流程，即使在没有明确地理范围的情况下，聚合NWDAF也能够精准地将分析任务路由到正确的执行者，实现了对特定对象的全局追踪分析。

总结：聚合NWDAF，网络智能的“API网关”

通过对5.3节的剖析，我们看到，分析聚合机制为5G网络的智能化部署提供了强大的扩展性和抽象能力。聚合NWDAF在其中扮演的角色，非常类似于微服务架构中的“API网关”。

  • 统一入口：它为所有上游消费者提供了一个稳定、统一的分析服务入口，屏蔽了后端分布式NWDAF部署的复杂性。

  • 智能路由：它能够根据请求的内容（是指定区域，还是指定用户），智能地将请求路由到正确的下游服务提供者。

  • 结果聚合：它能够将来自多个下游服务的结果进行汇集、处理和转换，向上游提供一个一致的、整合后的视图。

  • 解耦服务：它将服务的消费者和提供者彻底解耦。下游NWDAF可以独立地增加、删除或变更，而上游消费者完全无感。

这套机制，使得运营商可以根据业务发展，灵活地部署和扩展其网络智能能力，从服务于一个城市的“小脑”，逐步演进为一个覆盖全国、分层分域、协同工作的“超级大脑集群”。

在下一篇文章中，我们将探讨一个与移动性密切相关的、同样体现了NWDAF间协同的重要流程——5.4节“Procedures for Analytics Transferring”，看看当用户在不同NWDAF服务区之间移动时，他的“智能档案”是如何被无缝交接的。

FAQ 环节

Q1：聚合NWDAF和下游NWDAF在功能上有什么区别？它们是不同类型的网元吗？

A1：它们在功能角色上有区别，但在网元类型上是相同的，都是NWDAF。一个NWDAF实例是否能成为聚合者，取决于它是否具备“聚合”这项能力。

  • 下游NWDAF：通常是标准的NWDAF，专注于执行一种或几种分析，或者服务于一个特定区域。它扮演的是“生产者”的角色。

  • 聚合NWDAF：它本身也是一个标准的NWDAF（也具备AnLF/MTLF），但除此之外，它还实现了作为“消费者”去调用其他NWDAF服务的能力，以及对收到的多个分析结果进行聚合处理的逻辑。它同时扮演着“消费者”（相对于下游NWDAF）和“生产者”（相对于上游消费者）的双重角色。

Q2：如果一个消费者请求的区域横跨了多个聚合NWDAF的服务范围，会发生什么？

A2：这是一个很好的问题，涉及到聚合的分层。3GPP标准允许多层聚合 (multi-level aggregation)。在这种情况下，可能会有一个更高层级的“超级聚合NWDAF”。这个“超级聚合者”会接收请求，将其分解给各个省级的聚合NWDAF；省级的聚合NWDAF再将其分解给市级的NWDAF。通过这种分层结构，可以构建起一个与行政或网络管理层级相匹配的、树状的分析聚合体系，从而服务于任意尺度的分析请求。

Q3：聚合NWDAF如何处理下游NWDAF的故障或超时？

A3：这是一个实现相关的问题，但规范的流程为处理这类问题提供了可能。

  1. 超时机制：聚合NWDAF在向下游发出请求时，会启动一个定时器。如果在规定时间内没有收到某个下游NWDAF的响应，它可以选择：a) 返回一个部分聚合的结果，并标注哪些区域的数据缺失；b) 返回一个错误，告知消费者请求失败。

  2. 错误处理：规范在步骤6-9b的描述中提到If the selected NWDAFs ... cannot reply or notify ... before the expiry of the time ..., they may send an error response...。下游NWDAF如果遇到问题，可以主动上报错误。聚合NWDAF收到错误后，同样可以选择是返回部分结果还是整体失败。

  3. 高可用性：在部署时，每个区域可能都会部署主备两个NWDAF实例。聚合NWDAF在发现主用实例无响应时，可以通过NRF查询并切换到备用实例。

Q4：在“无指定区域的聚合”（5.3.3节）中，为什么聚合NWDAF可以选择“重定向”？这样做有什么好处？

A4：“重定向”（HTTP 3xx响应）是一种非常高效的优化手段。好处在于：

  • 减少中间环节：一旦聚合NWDAF完成了“侦探”工作，定位到了最终的服务提供者，它就可以“功成身退”，让消费者与提供者直接建立联系。后续所有的通知都会在两者之间直接传递，不再需要经过聚合NWDAF中转。

  • 降低聚合者负载：对于聚合NWDAF来说，它只承担了一次性的发现和定位任务，而无需承担后续所有通知消息的代理转发，这大大降低了它的持续性负载。

  • 缩短通知时延：由于通知路径变短，消费者可以更快地收到分析结果。

当然，选择“重定向”的前提是，消费者能够处理HTTP重定向，并且可以直接访问下游NWDAF（网络策略允许）。如果需要保持对消费者的拓扑透明性，聚合NWDAF则会选择继续代理。

Q5：聚合NWDAF是如何发现下游NWDAF的能力和覆盖范围的？

A5：NRF (Network Repository Function) 是实现这一切的核心。每个NWDAF实例在启动时，都必须向NRF注册自己的NF Profile。这个Profile就像一张详细的“个人简历”，包含了：

  • NWDAF ID：唯一标识。

  • 支持的分析ID (supportedAnalyticsIds)：它擅长做哪些分析。

  • 服务区域 (taiList, taiRangeList等)：它的“辖区”范围。

  • 是否支持聚合 (isAggregationSupported)：它是否能当“总指挥”。

  • …等等

当聚合NWDAF需要寻找下游专家时，它会向NRF发起一个NFDiscovery请求，将它需要的“专家”的条件（如“需要支持‘网络性能’分析”且“覆盖某某TAI列表”）作为查询参数。NRF就会在其注册表中进行筛选，返回所有符合条件的NWDAF实例的列表。这个“注册-发现”机制是整个5G服务化架构动态协作的基石。

关系图谱