51学通信

深度解析 3GPP TS 23.288：6.1ABC NWDAF高级协作：聚合、迁移与发现

21分钟阅读

好的，我们继续启程，探索3GPP TS 23.288规范中更为精妙的协作机制。

深度解析 3GPP TS 23.288：6.1A/B/C NWDAF高级协作：聚合、迁移与发现

本文技术原理深度参考了3GPP TS 23.288 V18.9.0 (2025-03) Release 18规范中，关于“6.1A Analytics aggregation from multiple NWDAFs”、“6.1B Transfer of analytics context and analytics subscription”以及“6.1C NWDAF Registration/Deregistration in UDM”的核心章节。本文旨在为读者揭示在复杂的、多实例部署的5G网络中，NWDAF“智慧大脑”们是如何实现团队协作、无缝交接以及高效自我展示的。

在上一篇文章中，我们探讨了单个NWDAF“小慧”如何向消费者提供分析服务的标准流程。然而，在真实的、覆盖广阔地域的运营商网络中，不可能只有一个“小慧”在工作。相反，网络中存在着一个由成百上千个“小慧”实例组成的庞大“智慧城市群”。这就引出了一系列更深层次的问题：

  • 当一个任务超出单个“小慧”的“视野”时，如何汇集多个“小慧”的智慧来完成？
  • 当用户在不同“小慧”的管辖区之间移动时，如何保证对他的智能服务不会中断和降级？
  • 在茫茫“人海”中，如何才能最快地找到正在为特定用户服务的那个“小慧”？

本章，我们将聚焦于规范第6章中的三个关键子章节，解答上述问题。我们将引入一个贯穿全文的场景：一位VIP商务人士“王总”，正乘坐一列时速350公里的智能高铁，从A市前往B市。他正在进行一场至关重要的跨国视频会议。保障“王总”在全程高速移动中的会议体验，是对运营商网络智能化水平的终极考验，也完美地诠释了本章所要阐述的高级协作机制。

1. 分析聚合 (Analytics Aggregation): 汇聚全局视野的团队智慧 (TS 23.288 Clause 6.1A)

“王总”的高铁之旅横跨A市和B市，这两个城市分别由NWDAF-A和NWDAF-B负责。运营商的省级网络监控中心（一个NF消费者）需要一个全局视图，来预测整条高铁线路未来的网络负载，以进行统一的资源调度。任何单个NWDAF都无法独立完成此任务。此时，分析聚合机制应运而生。

In a multiple NWDAF deployment scenario, an NWDAF instance may be specialized to provide Analytics for one or more Analytics IDs… An NWDAF may have the capability to support the aggregation of Analytics (per Analytics ID) received from other NWDAFs, possibly with Analytics generated by itself.

这段原文揭示了聚合的核心思想：网络中存在一个特殊的“领导”角色——聚合器NWDAF (Aggregator NWDAF)。它本身也是一个NWDAF实例，但具备一项特殊能力：聚合其他NWDAF的分析结果，形成一个更高维度、更广范围的洞察。

1.1 聚合器NWDAF的角色定义

Aggregator NWDAF or aggregation point:

  • Is an NWDAF instance with additional capabilities to aggregate output analytics provided by other NWDAFs.
  • Is able to divide the area of interest, if received from the consumer, into sub area of interest based on the serving area of each NWDAF to be requested for analytics…
  • Has “analytics aggregation capability” registered in its NF Profile within the NRF.

“领导”的能力体现在：

  • 聚合能力：能将多个下属的“分报告”整合成一份“总报告”。
  • 任务分解能力：能将一个覆盖“A市到B市高铁线”的大任务，智能地分解为“A市段”和“B市段”两个子任务，并派发给对应的下属。
  • 身份公开：它在NRF（网络功能存储库）的注册信息里，会明确标注自己拥有“analytics aggregation capability”这项“领导技能”。

1.2 聚合流程实战

让我们跟随省级监控中心和“聚合器小慧”的脚步，看看聚合流程是如何运作的（参考 Figure 6.1A.3.1-1: Procedure for analytics aggregation）。

  1. 发现并选择“领导”: 省级监控中心（消费者）向NRF查询，要求找到一个既能提供“切片负载预测”服务，又具备“聚合能力”的NWDAF。NRF返回了“聚合器小慧”的地址。

  2. 下达宏观任务: 监控中心向“聚合器小慧”发起订阅，请求覆盖从A市到B市整条高铁线路（Area of Interest）的切片负载预测。

  3. “领导”分解任务: “聚合器小慧”收到任务后，分析了请求的地理范围。它通过查询NRF或本地配置，发现这个范围横跨了下属NWDAF-A和NWDAF-B的服务区。于是，它将任务一分为二。

  4. 派发子任务:

    Aggregator NWDAF (e.g. NWDAF1) invokes Nnwdaf_AnalyticsInfo_Request or Nnwdaf_AnalyticsSubscription_Subscribe service operation from each of the NWDAFs discovered/determined in step 3 (e.g. NWDAF2 and NWDAF3).

    “聚合器小慧”分别向NWDAF-A和NWDAF-B发起订阅：

    • 对NWDAF-A：“请为我提供高铁线路A市段的切片负载预测。”
    • 对NWDAF-B：“请为我提供高铁线路B市段的切片负载预测。” 在派发任务时，它还可能要求下属们提供“分析元数据信息(Analytics Metadata Information)”，比如每个预测结果是基于多少数据样本生成的，这有助于它在后续聚合时进行加权处理，使最终结果更科学。

  5. 下属执行并汇报: NWDAF-A和NWDAF-B各自完成自己的分析任务，并将结果上报给“聚合器小慧”。

  6. “领导”整合报告:

    Aggregator NWDAF (e.g. NWDAF1) aggregates received Analytics information, i.e. generates a single output analytics based on the multiple analytics outputs and, optionally, the “analytics metadata information” received…

    “聚合器小慧”将来自A市和B市的两份报告进行合并、加权、平滑处理，最终形成一份覆盖整条线路的、连贯的、宏观的负载预测报告。

  7. 向上级提交最终成果: “聚合器小慧”将这份聚合后的分析结果，通过Notify消息发送给省级监控中心。

通过这套精密的“总-分-总”协作模式，NWDAF体系成功地将局部洞察汇聚成了全局智慧，满足了超越单个NWDAF服务范围的复杂分析需求。

2. 分析订阅与上下文迁移：智慧的无缝“接力” (TS 23.288 Clause 6.1B)

“王总”的高铁飞速行驶，即将从A市的AMF覆盖范围切换到B市的AMF。为了保证服务连续性，关于“王总”的所有网络上下文（包括他正在接受的NWDAF分析服务）都需要从A市的源AMF迁移到B市的目标AMF。

此时，目标AMF接收到上下文后发现，前任AMF曾为“王总”订阅了NWDAF-A的移动性分析服务。现在“王总”来到了B市，由NWDAF-B服务更佳。如何将这项智能服务从NWDAF-A平滑地“交接”给NWDAF-B，同时又不让“王总”的业务体验有任何感知？这就是分析订阅与上下文迁移机制要解决的问题。

In a multiple NWDAFs deployment scenario, procedures for transfer of analytics context and analytics subscription can be used to support the target NWDAF to produce the needed analytics.

2.1 迁移的两种触发方式

  • 消费者发起 (Consumer-initiated): 如上述场景，目标AMF发现需要更换NWDAF，于是主动向新的NWDAF-B发起订阅，并在请求中包含了“前任”NWDAF-A的信息，从而触发一次上下文迁移。
  • 源NWDAF发起 (Source-initiated): NWDAF-A自己通过订阅AMF的事件，得知“王总”即将离开自己的服务区。为了“服务到家”，它会主动寻找“王总”的下一站——NWDAF-B，并发起一次主动的“客户交接”。

2.2 “客户交接”流程实战

我们以更智能的源NWDAF发起的迁移流程为例进行解读 (参考 Figure 6.1B.2.2-1)。

  1. 预判与决策: NWDAF-A通过分析“王总”的移动轨迹，预测到他即将进入NWDAF-B的服务区。它决定将关于“王总”的所有分析订阅都移交给NWDAF-B。

  2. 发现“接任者”: NWDAF-A通过NRF发现并选择了NWDAF-B作为目标。

  3. 发送迁移请求:

    Source NWDAF requests, using Nnwdaf_AnalyticsSubscription_Transfer Request service operation, a transfer of the analytics subscription(s) determined in step 2 to the target NWDAF.

    NWDAF-A向NWDAF-B发送一个Nnwdaf_AnalyticsSubscription_Transfer请求，这个请求像一个打包好的“交接箱”，里面包含了原始订阅的所有信息：谁订阅的（AMF）、订阅了什么（移动性分析）、具体要求是什么。

  4. “接任者”接受并通知客户: NWDAF-B收到并接受了这次“客户转交”。关键的一步是：

    Target NWDAF informs the analytics consumer about the successful analytics subscription transfer using a Nnwdaf_AnalyticsSubscription_Notify message. A new Subscription Correlation ID…is provided…and the old Subscription Correlation ID…is provided…

    NWDAF-B会直接联系最终的客户（即B市的目标AMF），发送一个Notify通知：“你好，关于‘王总’的移动性分析服务，现在由我（NWDAF-B）接手了。这是你的新订阅ID，旧的ID是xxx，请更新你的记录。” 这确保了AMF能够无缝地将后续的交互对象从A切换到B。

  5. “交接档案”：上下文迁移: 订阅关系交接完成后，更重要的是“记忆”的交接。

    [Conditional] If “analytics context identifier(s)” had been included…the target NWDAF requests the “analytics context”. The analytics context transfer procedure is specified in clause 6.1B.3.

    NWDAF-B会向NWDAF-A发起**上下文迁移 (Nnwdaf_AnalyticsInfo_ContextTransfer)**请求，索要关于“王总”的全部“历史档案”。

    这份“档案”内容丰富 (Clause 6.1B.4)，包括：

    • Pending output Analytics: 还没来得及发送的分析结果。
    • Historical output analytics information: 历史分析报告。
    • Data related to Analytics: 相关的历史原始数据。
    • ML Model related information: 之前分析时所使用的ML模型信息。

通过这个流程，NWDAF-B不仅接手了服务，还继承了NWDAF-A关于“王总”的全部“记忆”。它无需从零开始重新收集数据和分析，保证了分析服务的连续性和高质量，从而确保了“王总”在跨区切换时，网络智能化服务“零中断”。

3. 在UDM中注册：让“专家”更容易被找到 (TS 23.288 Clause 6.1C)

在庞大的网络中，为特定用户寻找服务NWDAF有时会像大海捞针。虽然可以通过NRF进行基于位置的复杂查询，但有没有更直接的“快捷方式”呢？答案是肯定的。

The procedures in this clause are applicable to UE-related analytics…where the NWDAF is configured to register in UDM for the UEs that it is serving…This enables NWDAF service consumers to discover the NWDAF instance that is already serving the UE for one or more Analytics ID(s).

这就是在UDM中注册机制。UDM是存储每个用户签约数据和动态上下文的“个人档案中心”。该机制允许正在为某个用户提供服务的NWDAF，去这个用户的“档案”里贴一张“便签”，声明自己的存在。

3.1 注册与发现流程

场景举例：

  1. 注册 (Nudm_UECM_Registration): 当NWDAF-A开始为“王总”提供移动性分析服务时，它会主动向UDM发送一个Nudm_UECM_Registration请求，内容为：“为SUPI=王总，就Analytics ID=UE Mobility这个主题，我（NWDAF-A）正在提供服务。” UDM会将这条信息记录在“王总”的档案中。

  2. 发现: 稍后，PCF也想为“王总”获取移动性分析。它不再需要去NRF进行复杂的区域查询，而是直接向UDM发起一个简单的查询：“请问有没有NWDAF在为‘王总’提供移动性分析？”

  3. 直接定位: UDM查阅档案，发现NWDAF-A的“便签”，于是直接将NWDAF-A的地址告诉PCF。

这个机制将原本复杂的、可能涉及多步的服务发现过程，简化为一步精准的查询，极大地提升了发现效率，降低了信令开销。

  1. 注销 (Nudm_UECM_Deregistration): 当NWDAF-A不再为“王总”服务时（例如，服务迁移给了NWDAF-B，或订阅结束），它会负责任地向UDM发送注销请求，撕掉自己的“便签”，保持用户档案的整洁和准确。

FAQ - 常见问题解答

Q1：聚合器NWDAF (Aggregator NWDAF) 和普通NWDAF有什么本质区别？ A1：本质上，聚合器NWDAF首先是一个功能完备的NWDAF。它的特殊之处在于具备了**“ analytics aggregation capability”**这项在NRF中注册的“领导技能”。这使得它能够：1) 作为消费者，去发现、订阅并处理来自其他NWDAF的分析结果；2) 作为生产者，将多个来源的分析结果进行智能合并，生成一个更高层次、更广范围的聚合分析结果，再提供给它的消费者。普通NWDAF通常只分析来自NF或OAM的原始数据，而聚合器NWDAF的主要“原材料”是其他NWDAF的分析成品。

Q2：分析订阅迁移（Analytics Subscription Transfer）和UE上下文迁移（UE Context Transfer）有什么关系？ A2：它们是两个不同层面但紧密关联的流程。UE上下文迁移是AMF/SMF层面的流程，当UE移动导致服务节点变更时，将UE的会话、安全、QoS等上下文从源节点迁移到目标节点。分析订阅迁移可以看作是UE上下文迁移在网络智能层面的延伸。当UE上下文迁移发生后，目标AMF/SMF会发现它继承了一个指向旧NWDAF的分析订阅，此时就需要触发分析订阅迁移，将智能服务也“迁移”到新的、更合适的NWDAF上，以保证智能化服务的连续性。

Q3：为什么要迁移“分析上下文（Analytics Context）”？让新的NWDAF从头开始分析不行吗？ A3：让新的NWDAF从头开始分析，会导致服务质量的**“冷启动”**问题。例如，对于需要基于历史行为进行预测的分析（如移动性预测），新NWDAF没有历史数据，其初始预测的准确性会非常低。通过迁移分析上下文，目标NWDAF可以立即获得关于用户的历史分析结果、相关数据摘要、甚至是之前使用的ML模型信息，它能够“站在巨人的肩膀上”，立即提供高质量、高精度的分析服务，对用户而言体验是无缝的。

Q4：在UDM中注册NWDAF信息是强制的吗？什么情况下会使用这个功能？ A4：这不是强制的，而是一个可选的优化机制。它主要适用于UE相关的分析。当一个NWDAF开始为一个或多个特定的UE提供长期分析服务时，它“可以”去UDM注册。这样做的好处是，后续其他任何NF如果也想为同一个UE请求相同的分析服务，就可以通过一次简单的UDM查询直接找到这个NWDAF，避免了通过NRF进行可能更复杂的、基于位置或其他属性的发现流程，从而提高了服务发现的效率。

Q5：如果一个聚合请求覆盖的区域内，部分NWDAF响应很快，部分很慢，聚合器NWDAF会怎么办？ A5：这是一个很好的实际问题。规范在流程中考虑了超时和错误处理。聚合器NWDAF在向各个下属NWDAF派发子任务时，会根据原始请求中的time when analytics information is needed参数，设定一个更短的内部截止时间（T2）。如果在T2时间内，某个下属NWDAF没有响应，或者返回了错误（如无法分析），聚合器NWDAF有多种处理策略：1) 不等了，基于已收到的部分结果生成一个可能不完整的聚合报告；2) 上报延迟，向最终消费者报告一个“修订后的等待时间”，请求更多的时间；3) 返回部分成功的结果，并注明哪些区域的数据缺失。具体行为取决于运营商的策略配置。

关系图谱