51学通信

深度解析 3GPP TS 29.552：5.4 Procedures for Analytics Transferring (分析传递流程)

23分钟阅读

好的，我们继续对TS 29.552规范的深度解构。在前几篇文章中，我们已经探讨了NWDAF如何对外提供服务，以及多个NWDAF如何聚合成一个“超级大脑”。今天，我们将聚焦于一个与5G核心特性——移动性——紧密相关的场景：当用户在网络中移动，跨越了不同NWDAF的服务边界时，关于他的“智能分析档案”是如何实现无缝、高效的交接的。

深度解析 3GPP TS 29.552：5.4 Procedures for Analytics Transferring (分析传递流程)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将深度剖析5.4节“Procedures for Analytics Transferring”，为读者揭示在用户移动性场景下，NWDAF之间是如何通过“分析上下文传递”和“分析订阅迁移”这两种核心机制，确保智能化服务的连续性和一致性的。

前言：智能如何跟上移动的脚步

移动性是通信网络的灵魂。在5G时代，用户不再仅仅是“人”，更可能是高速行驶的汽车、穿梭于城市上空的无人机。对这些高速移动的目标提供不间断的、智能化的网络服务，是5G面临的核心挑战之一。

想象一下，一辆正在接受NWDAF实时网络拥塞预测以规划最佳通信路径的自动驾驶汽车，从北京（由NWDAF-A服务）开往天津（由NWDAF-B服务）。当它跨越城市边界时，如果关于它的所有分析信息（如历史移动模式、业务流量特征、已建立的分析模型）都“丢失”了，那么新接入的NWDAF-B就需要从零开始重新学习和分析，这期间可能会出现服务中断或质量下降，对于自动驾驶等关键任务而言是不可接受的。

为了解决这个问题，3GPP在TS 29.552的5.4节中，设计了一套精密的分析传递 (Analytics Transferring) 流程。这套流程的核心目标是：让智能分析能够像用户的PDU会话一样，实现无缝切换。

本节内容主要包含两种截然不同的“交接”模式，它们由不同的角色发起，适用于不同的场景：

  1. 分析上下文传递 (Analytics Context Transfer)：由新的（目标）NWDAF发起。它像是一位新到任的“管家”，主动向前任“管家”索要服务对象的全部档案。

  2. 分析订阅迁移 (Analytics Subscription Transfer)：由旧的（源）NWDAF发起。它像是一位即将调离的“片警”，预见到自己的服务对象即将离开辖区，于是主动联系下一站的同事，提前把“户口”和“档案”移交过去。

我们将继续引入我们的主角——自动驾驶汽车**“智行一号”**，跟随它从一个NWDAF服务区到另一个服务区的旅程，来详细拆解这两种“智能交接”流程。

1. “新官上任三把火”：目标NWDAF发起的上下文传递 (5.4.1)

这种模式的触发点通常是用户的服务锚点发生了变更，例如UE上下文从一个AMF切换到了另一个AMF。新的服务网元（如新的AMF）会选择一个新的NWDAF来为该用户提供服务。

场景：“智行一号”进入天津地界，它的UE上下文由北京AMF-A切换到了天津AMF-B。AMF-B作为一个新的“分析消费者”，通过NRF发现并选择了天津本地的NWDAF-B来为“智行一号”提供网络分析服务。此时，NWDAF-B作为新上任的“管家”，需要尽快了解“智行一号”的“前世今生”。

这个过程由 “Figure 5.4.1-1: Analytics context transfer initiated by target NWDAF selected by the NWDAF service consumer” 描绘。

步骤1 & 2：新管家上岗，建立新的服务关系

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

  1. The NWDAF service consumer determines to select an NWDAF instance. The NWDAF service consumer discovers and selects the target NWDAF…
  1. To send a request for analytics subscription to the target NWDAF, the NWDAF service consumer invokes Nnwdaf_EventsSubscription_Subscribe service operation… The NWDAF service consumer includes information on the previous analytics subscription (e.g., NWDAF ID and Subscription ID)…, if available.

  1. AMF-B选择NWDAF-B (Step 1)：天津AMF-B（作为消费者）通过NRF，选择了天津NWDAF-B（目标NWDAF）。

  2. AMF-B向NWDAF-B发起订阅 (Step 2)：AMF-B向NWDAF-B发起一个新的分析订阅请求，告诉它：“请开始为‘智行一号’提供移动性预测服务。”

  3. 关键信息传递：在这次订阅请求中，AMF-B如果从AMF-A那里获得了“智行一号”之前的分析服务信息（这通常在AMF间的UE上下文转移时完成），它会把这些信息告诉NWDAF-B：“顺便说一下，之前为它服务的是北京的NWDAF-A，当时的订阅ID是XXX。”

步骤3：新管家向前任索要档案

规范原文引用 (Step 3):

If the target NWDAF decides to request an analytics context transfer from the previously used NWDAF, it invokes the Nnwdaf_AnalyticsInfo_ContextTransfer service operation by sending the HTTP GET request message targeting the resource “NWDAF Context” to the source NWDAF…

NWDAF-B收到AMF-B的请求和“前任”的信息后，立刻意识到自己可以走捷径，而不是从零开始。

  1. 动作：NWDAF-B（目标）向NWDAF-A（源）发起一个HTTP GET请求，调用Nnwdaf_AnalyticsInfo_ContextTransfer服务。

  2. 请求URI：请求的目标是源NWDAF上代表特定分析上下文的资源，例如.../nwdaf-analyticsinfo/v1/context/{contextId}。

  3. 请求意图：这就像是NWDAF-B给NWDAF-A打了个电话：“老兄，你负责的‘智行一号’现在归我管了，麻烦把它的所有历史档案传给我。”

  4. 档案内容（响应体）：NWDAF-A收到请求后，会把所有与“智行一号”相关的“分析上下文(Analytics Context)”打包，在200 OK响应中返回。这些“档案”可能包括：

    • 历史数据：如过去1小时的移动轨迹、流量使用情况。

    • 分析模型：专门为“智行一号”训练出的移动模式预测模型。

    • 统计信息：历史上的网络体验指标。

    • 数据源订阅信息：NWDAF-A为了分析“智行一号”，曾向哪些数据源（如UPF）发起了订阅。

步骤4 & 5：交接完成，旧管家清理，新管家开工

规范原文引用 (Step 4 & 5):

  1. [Optional] Source NWDAF may purge analytics context after completion of step 3a…and unsubscribes from the data source(s)…
  1. [Optional] Target NWDAF may subscribe to relevant data source(s)…

  1. 旧管家清理 (Step 4)：NWDAF-A在成功移交档案后，就完成了它的历史使命。它可以选择删除本地保存的关于“智行一号”的所有上下文信息，并取消之前为它建立的所有数据订阅，以释放资源。

  2. 新管家开工 (Step 5)：NWDAF-B拿到了完整的“档案”，它可以立即利用这些信息开始提供高质量的分析服务。例如，它会接替NWDAF-A，向“智行一号”当前所连接的天津UPF-B发起数据收集订阅，实现监控的无缝衔接。

该模式的优点：流程由新接入的服务节点（AMF-B, NWDAF-B）驱动，逻辑清晰，与5G的移动性管理流程（AMF切换）结合紧密。

2. “未雨绸缪”：源NWDAF发起的订阅迁移 (5.4.2 & 5.4.3)

这种模式更为主动和前瞻。旧的“管家”NWDAF-A通过自己的分析，预见到服务对象即将离开自己的“辖区”，于是提前为他联系好下一站的“管家”，并主动把服务关系和档案都迁移过去。

这个流程分为两个阶段：准备阶段 和 执行阶段。

场景：‘洞察者’的北京区域经理NWDAF-A，通过对“智行一号”的移动性分析，预测到它将在10分钟后驶入天津界。为了保证服务连续性，NWDAF-A决定提前启动“分析订阅迁移”流程。

2.1 准备阶段：提前打招呼 (5.4.3 Prepared analytics subscription transfer)

这个流程由 “Figure 5.4.3-1: Prepared analytics subscription transfer” 描绘。

  1. 源NWDAF预测移动 (Step 3)：NWDAF-A基于其强大的移动性预测能力，得出“‘智行一号’即将进入天津TAI-X区域”的结论。

  2. 源NWDAF发现并选择目标 (Step 4)：NWDAF-A拿着“天津TAI-X”这个地址，去NRF查询，找到了负责该区域的NWDAF-B。

  3. 发起“准备迁移”请求 (Step 5a-5b)：

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

    The source NWDAF invokes Nnwdaf_EventsSubscription_Transfer service operation by sending an HTTP POST request to the target NWDAF and the “transReqType” attribute in the request message is set to “PREPARE”.

    • 动作：NWDAF-A向NWDAF-B发起一个特殊的Nnwdaf_EventsSubscription_Transfer服务调用。

    • 关键参数：请求体中包含了一个关键参数transReqType = "PREPARE"。

    • 请求意图：“你好NWDAF-B，我有一个客户‘智行一号’马上要到你那边去了，你先准备一下。这是他的基本信息和我们之间的订阅合同。”

  4. 目标NWDAF进行准备 (Step 6a-6b, 7)：NWDAF-B收到“准备”请求后，会提前做一些准备工作。例如，它可能会提前去请求“智行一号”的分析上下文（步骤6a-6b），或者提前向天津本地的数据源（如AMF-B, UPF-B）发起预订阅（步骤7），“预热”数据链路。

2.2 执行阶段：正式交接 (5.4.2 Analytics Subscription Transfer initiated by source NWDAF)

当“智行一号”真正跨越边界的时刻到来时（例如，NWDAF-A收到了来自AMF-A的UE“去附着”或“切换出”的通知），正式的交接开始了。

这个流程由 “Figure 5.4.2-1: Analytics subscription transfer initiated by source NWDAF” 描绘。

  1. 源NWDAF确定迁移 (Step 2)：NWDAF-A确认“智行一号”已经离开其服务范围。

  2. 发起“正式迁移”请求 (Step 4)：

    规范原文引用 (Step 8a-8b in 5.4.3, referencing 5.4.2):

    The source NWDAF invokes the Nnwdaf_EventsSubscription_Transfer service operation by sending either an HTTP PUT request…with the “transReqType” attribute set to “TRANSFER”…

    • 动作：NWDAF-A再次向NWDAF-B发起Nnwdaf_EventsSubscription_Transfer服务调用（通常使用HTTP PUT来更新之前“准备”的会话）。

    • 关键参数：这次请求体中的transReqType被设置为"TRANSFER"。

    • 请求意图：“NWDAF-B，客户已经到你门口了，现在正式把他的服务订阅关系转交给你！”

  3. 目标NWDAF接管订阅 (Step 5)：NWDAF-B收到“转移”指令后，正式接管这个订阅。它会生成一个新的Subscription ID，并将这个订阅与“智行一号”的原始消费者（AMF-B）关联起来。

  4. 目标NWDAF通知消费者 (Step 6)：

    规范原文引用 (Step 6):

    Target NWDAF informs the NWDAF service consumer about the successful analytics subscription transfer using a Nnwdaf_EventsSubscription_Notify request message. A new Subscription ID…is provided…and the old Subscription Id…is provided…

    这是至关重要的一步。NWDAF-B会主动向“智行一号”的当前服务节点（AMF-B）发送一个通知，告知它：“你好AMF-B，关于‘智行一号’的分析订阅服务已经成功从NWDAF-A迁移到我这里了。旧的订阅ID是XXX，新的订阅ID是YYY。以后请用新ID与我联系。”

通过这个通知，消费者（AMF-B）就能够平滑地将其关注点从旧的NWDAF切换到新的NWDAF，实现了整个服务关系的无缝迁移。

该模式的优点：非常主动和前瞻，可以最大程度地减少甚至消除因切换带来的服务中断（“零丢包”交接）。它充分利用了NWDAF自身的预测能力，实现了智能的自我管理。

总结：让智能在移动中永不掉线

通过对5.4节的深度剖析，我们看到了3GPP为保障移动场景下智能服务连续性所设计的两套精巧机制：

  • 上下文传递（目标发起）：是一种被动但可靠的“拉（Pull）”模式。它与5G移动性管理流程紧密耦合，当服务关系变更后，新的服务者负责主动拉取历史信息。它保证了信息的完整性，但可能存在微小的时间延迟。

  • 订阅迁移（源发起）：是一种主动且前瞻的“推（Push）”模式。它利用源NWDAF的预测能力，提前准备和执行交接。它能够实现近乎零延迟的“热切换”，但更依赖于预测的准确性。

这两套机制相辅相成，共同确保了无论是普通的手机用户，还是关键任务型的物联网终端，在跨越不同网络区域时，其背后由NWDAF提供的智能化服务都能够“如影随形”，永不掉线。这正是构建一个真正智能、泛在的5G网络的关键所在。

在下一篇文章中，我们将把目光从“分析”本身转向“数据”，深入探讨5.5节“Data Collection”，详细解析‘洞察者’的“情报网”是如何通过具体的信令流程，从网络中的各个角落收集其赖以生存的数据的。

FAQ 环节

Q1：上下文传递（Context Transfer）和订阅迁移（Subscription Transfer）有什么本质区别？

A1：本质区别在于**“交接”的对象和发起者**。

  • 上下文传递：交接的是**“数据和模型”（即分析上下文），可以理解为“档案”的拷贝。它由新（目标）NWDAF**在感知到新服务关系后发起。旧的订阅关系由消费者自行终止，新的订阅关系由消费者重新建立。

  • 订阅迁移：交接的是**“服务合同”本身（即分析订阅关系），上下文通常作为迁移的一部分被附带传递。它由旧（源）NWDAF**在预见到移动即将发生时主动发起。整个迁移过程对最终消费者（如AMF）是半透明的，消费者最后只需确认服务提供方已变更即可。

Q2：源NWDAF发起的订阅迁移，其预测的准确性如何保证？如果预测错了怎么办？

A2：这是一个很好的工程实践问题。

  1. 准确性保证：NWDAF的移动性预测能力是其核心AI能力之一，其准确性依赖于模型的优劣和训练数据的质量。高质量的NWDAF能够提供相当准确的短期（如几分钟到半小时内）移动预测。

  2. 处理预测错误：如果预测错误（例如，预测车辆会去天津，结果它去了河北），准备阶段（transReqType="PREPARE"）建立的资源可以被超时或被源NWDAF主动取消。源NWDAF会发现车辆进入了另一个由NWDAF-C服务的区域，然后重新与NWDAF-C发起新的准备流程。即使没有准备，当车辆真正进入河北后，仍然可以回退到由目标AMF/NWDAF发起的上下文传递（5.4.1）流程，作为一种可靠的“兜底”机制。

Q3：在订阅迁移（5.4.2）的步骤6中，为什么目标NWDAF需要通知消费者订阅已变更？消费者自己不知道吗？

A3：消费者（如AMF-B）可能知道它正在服务的UE是从另一个AMF切换过来的，但它不知道关于这个UE的分析服务订阅关系已经在两个NWDAF之间被后台自动迁移了。消费者AMF-B最初可能仍然认为它需要向它选择的NWDAF-B发起一个全新的订阅。步骤6的通知起到了一个关键的同步和确认作用，它告诉AMF-B：“你不用再重新订阅了，我们已经把来自北京的服务关系无缝迁移过来了，这是新的订阅ID，请直接使用。” 这避免了重复订阅，并确保了消费者与正确的NWDAF服务实例进行通信。

Q4：这些传递和迁移流程会传递用户的隐私数据吗？

A4：是的，这些流程可能会传递包含用户个人信息（如SUPI）和行为模式（如移动轨迹）的数据，因此必须在严格的安全和隐私框架下进行。

  1. 网络内部：这些交互都发生在运营商信任的、安全的内部网络中，通过SEPP（安全边缘保护代理）等机制进行保护。

  2. 合规要求：所有的数据处理都必须遵守当地的法律法规（如GDPR）。运营商需要确保其NWDAF的实现和部署符合数据最小化、目的限制等原则。

  3. 分析而非原始数据：在某些情况下，传递的可能是经过处理的分析结果或模型参数，而不是原始的用户数据流，这可以在一定程度上降低隐私风险。

Q5：什么情况下会优先使用目标NWDAF发起的上下文传递（5.4.1），而不是源发起的订阅迁移（5.4.2）？

A5：通常来说，上下文传递（5.4.1）是一个更基础、更通用的流程，适用于所有AMF切换等移动性场景。而订阅迁移（5.4.2）是一个更高级、更主动的优化流程。

  • 优先使用5.4.1：在所有标准的移动性事件中，这个流程都可以作为默认的、可靠的交接机制。如果源NWDAF不具备预测能力，或者预测不准，最终都会通过这个流程来“兜底”。

  • 优先使用5.4.2：当服务对连续性要求极高（如URLLC业务），且源NWDAF具备高精度的预测能力时，会优先使用这种主动迁移的方式，以实现“零中断”的智能服务切换。例如，在可预测的路径上（如高铁、高速公路）运行的关键业务，非常适合采用这种模式。

关系图谱