51学通信

深度解析 3GPP TS 29.530：5.3 Naf_VFLInference Service (垂直联邦学习推理服务)

23分钟阅读

好的，我们继续拆解下一章节。

深度解析 3GPP TS 29.530：5.3 Naf_VFLInference Service (垂直联邦学习推理服务)

本文技术原理深度参考了 3GPP TS 29.530 V1.0.0 (2025-09) Release 19 规范，我们将聚焦于第5.3章，对 Naf_VFLInference 服务进行全面而深入的拆解。本章定义了当AF作为VFL客户端时，如何响应和参与由NF服务消费者发起的模型推理（Inference）任务。

在上一章中，“天穹智脑”的Team Alpha成功地实现了Naf_VFLTraining服务，让我们的AI平台学会了如何作为一名优秀的合作者，参与到了“智慧城市交通大脑”模型的联邦训练中。经过数周的协同努力，一个能够精准预测交通拥堵的模型V1.0已经成功诞生。

首席架构师Dr. Evelyn Reed在项目周会上对团队的成果表示了祝贺，但她随即提出了新的挑战：“模型训练好了，就像我们打造了一把锋利的手术刀。但手术刀的价值在于使用它进行精准的手术。现在，我们的任务是实现Naf_VFLInference服务——教会‘天穹智脑’如何挥舞这把刀，在瞬息万变的城市交通中，做出实时、精准的判断。模型训练是‘十年磨一剑’，而模型推理则是‘电光火石’间的决胜。让我们开始吧！”

1. 5.3.1 Service Description - 服务的核心使命与架构

本节从宏观上描述了Naf_VFLInference服务的宗旨、架构和关键参与者。

1.1 5.3.1.1 Overview - 实时协同的智能洞察

规范原文引用 (Clause 5.3.1.1 Overview) The Naf_VFLInference service as defined in 3GPP TS 23.288, is provided by the trusted Application Function (AF) or untrusted Application Function (AF) acting as VFL client. This service allows the NF service consumers acting as VFL servers:

  • to subscribe to and unsubscribe from different VFL inference events;
  • to modify VFL inference subscriptions; and
  • be notified about events for corresponding VFL inference subscriptions.

这段概述为我们划定了几个关键点：

  • AF的角色: 与训练服务一样，AF在这里依然是VFL客户端 (VFL client)。它是一个协同推理的参与者，而不是主导者。
  • NF消费者的角色: 规范明确指出，服务消费者（如NWDAF）在这里扮演VFL服务器 (VFL servers) 的角色。这可能初看有些令人困惑，但这里的“Server”应理解为“推理任务的中心协调者或汇聚点”。
  • 核心功能: 服务围绕着订阅 (Subscription) 模型展开，允许消费者创建、修改、删除推理事件的订阅，并最终被动地接收（被通知）推理结果。

“智慧城市交通大脑”场景升级：紧急救援“生命通道”

为了更好地理解推理服务的实时性和协同性，我们将场景升级：

  • 突发事件: 一辆名为“救护先锋01”的救护车接到紧急任务，需要以最快速度从A点穿过市区到达B点的医院。
  • 挑战: 城市交通系统需要在救护车到达前，精准预测其路径上每个路口的实时车流变化，并提前调整信号灯，开辟出一条“绿色生命通道”。
  • 协同推理: 这就需要城市交通管理局NWDAF（VFL协调者）、“天穹智脑”AF（拥有群体移动性预测能力）和**“智行一号”车联网AF**（拥有救护车实时轨迹和周边车辆动态）三方，利用之前训练好的VFL模型，进行一次联合实时推理。

1.2 5.3.1.2 Service Architecture - 智能协作的两种模式

本节通过两幅架构图，清晰地展示了Naf_VFLInference服务在5G网络中的两种部署和交互模式。

Figure 5.3.1.2-1: Reference Architecture for the Naf_VFLInference service; SBI representation

这幅图展示了可信AF (Trusted AF) 场景下的服务化接口（SBI）表示。

  • 解读: 在这张图中，AF（我们的“天穹智脑”）与NWDAF都位于核心网内部，被认为是相互信任的。它们之间可以直接通过5G核心网的服务总线进行通信。NWDAF可以直接向AF发起Naf_VFLInference服务调用。这是一种高效、直接的内部协作模式。

Figure 5.3.1.2-2: Reference Architecture for the Naf_VFLinference service: reference point representation

这幅图展示了非可信AF (Untrusted AF) 场景下的参考点表示。

  • 解读: 在这张图中，AF位于运营商网络之外（例如，“智行一号”车联网的云平台）。它被视为非可信的。此时，所有的交互都必须通过NEF (Network Exposure Function) 这个安全网关。NWDAF想要调用“智行一号”AF的Naf_VFLInference服务，必须先把请求发给NEF，NEF进行安全策略检查、API转换后，再将请求暴露给外部的AF。反之亦然。这是一种安全、可控的跨域协作模式。

下表总结了这两种架构模式：

架构模式AF信任模型交互路径适用场景
SBI RepresentationTrusted AF (可信)NWDAF <--> AF (直接交互)运营商自建的AI平台（如“天穹智脑”）与内部NWDAF的协作。
Reference PointUntrusted AF (非可信)NWDAF <--> NEF <--> AF (通过NEF代理)运营商与第三方合作伙伴（如车联网公司）的AI平台进行跨域联邦推理。

1.3 5.3.1.3 Network Functions - 明确各方职责

本节进一步明确了架构中各个网络功能（NF）的职责。

规范原文引用 (Clause 5.3.1.3.1 Network Data Analytics Function (AF)) The Application Function (AF), provides VFL inference for different analytic events to NF service consumers. The Application Function (AF) allows NF service consumers to subscribe to and unsubscribe from one-time, periodic notification or notification when a VFL inference event is detected.

  • AF的职责:
    1. 提供VFL推理能力: AF是推理计算的执行者之一。
    2. 管理推理订阅: AF必须支持一次性、周期性或事件触发式的推理通知订阅。这为服务消费者提供了极大的灵活性。

规范原文引用 (Clause 5.3.1.3.2 NF Service Consumers) The Network Data Analytics Function (NWDAF) and Network Exposure Function (NEF) support (un)subscription to the notification of different VFL inference events.

  • NF消费者的职责:
    • NWDAF/NEF: 负责发起和管理对VFL推理事件通知的订阅与取消订阅。它们是推理任务的需求方和发起方。

2. 5.3.2 Service Operations - 服务操作的详细流程

与训练服务类似，本节是技术实现的核心，定义了Naf_VFLInference服务的具体操作和交互流程。

2.1 5.3.2.1 Introduction - 操作总览

Table 5.3.2.1-1: Operations of the Naf_VFLInference service为我们列出了该服务的所有操作。

Service operation nameDescriptionInitiated by
Naf_VFLInference_SubscribeThis service operation is used by an NF service consumer to request AF VFL client(s) to subscribe to VFL inference events.NF service consumer (NWDAF,NEF)
Naf_VFLInference_UnsubscribeThis service operation is used by an NF service consumer to unsubscribe to VFL inference event notifications.NF service consumer (NWDAF,NEF)
Naf_VFLInference_NotifyThis service operation is used by the AF to notify the VFL inference results to the NF service consumer instance which has subscribed to the event report service.AF

表格解读:

  • 三大操作: 同样是Subscribe, Unsubscribe, Notify，构成了推理服务的完整生命周期。
  • 发起方: 订阅和取消订阅由消费者（NWDAF/NEF）发起，而结果通知由AF发起。这与VFL训练服务的角色分工完全一致，体现了3GPP规范设计的一致性。

2.2 5.3.2.2 Naf_VFLInference_Subscribe - 订阅推理事件

这是“生命通道”任务启动的第一步。城市交通管理局NWDAF需要向“天穹智脑”和“智行一号”AF发起推理订阅，让它们开始协同工作。

2.2.2.2.2 Subscription for VFL inference event notifications (创建订阅)

流程图: Figure 5.3.2.2.2-1: NF service consumer subscribes to VFL inference notifications

  1. NF service consumer → AF: 1. POST ../subscriptions
  2. AF → NF service consumer: 2. "201 Created"

流程深度解析:

规范原文引用 (Clause 5.3.2.2.2) The NF service consumer shall invoke the Naf_VFLInference_Subscribe service operation to request AF VFL client(s) to subscribe to VFL inference event notification(s). The NF service consumer shall send an HTTP POST request with “{apiRoot}/naf-vflinference//subscriptions” as Resource URI…

  • 动作: NWDAF通过POST请求到/subscriptions集合资源来创建一个新的推理订阅。
  • 载荷 (VflInferSub data structure): 这是请求的核心，即**“推理任务书”**。
    • notifUri: 必选。NWDAF提供的回调地址，用于接收推理结果。
    • notifCorreId: 必选。通知关联ID。
    • vflInferAnaSubs: 必选。描述了订阅的分析事件，比如“预测analyticId-001（路口拥堵）”。
    • vflReportInfo: 可选。VFL报告信息，可以指定报告的频率、触发条件等。一个关键的内部属性是immRep (Immediate Reporting)。
    • vflInferReq: 可选。VFL推理要求，可以指定对推理的特定条件。

规范原文引用 (Clause 5.3.2.2.2) If the immediate reporting indication in the “immRep” attribute within the “ReportingInformation” structure in the “vflReportInfo” attribute sets to “true” during the event subscription, the AF shall include the intermediate VFL inference results of the subscribed events, if available, as the “vflInferResults” attribute in the HTTP POST response.

  • 立即报告 (Immediate Reporting): 这是一个非常重要的特性。如果在POST请求中，immRep标志位被设为true，这意味着NWDAF不仅想建立一个长期订阅，还希望立即得到一次推理结果。此时，AF在返回201 Created响应的同时，响应体中就会直接带上第一份推理结果（如果能立即计算出来的话）。这兼顾了一次性查询和长期订阅两种场景，设计非常巧妙。

场景再现:

  1. “救护先锋01”出发，车载GPS将其路线规划route-123发送给城市NWDAF。
  2. NWDAF立即向“天穹智脑”的.../naf-vflinference/v1/subscriptions端点发起POST请求。
  3. 请求体中包含了：
    • notifUri: https://nwdaf.gov/ambulance-notif
    • vflInferAnaSubs: 指定使用“交通拥堵预测模型”，并附上route-123作为推理上下文。
    • vflReportInfo: 设置immRep=true，并要求每10秒报告一次最新预测。
  4. “天穹智脑”收到请求，立即基于其掌握的群体移动性数据，对route-123沿线的交通状况进行初步计算，生成了第一份预测报告。
  5. 它向NWDAF返回201 Created响应，Location头中包含新订阅的URI /subscriptions/sub-ambulance-01，同时响应体中直接包含了这份热乎的预测报告。

2.2.2.2.3 & 2.2.2.2.4 Update & Partial update (更新订阅)

与训练服务一样，推理订阅也支持PUT（全量更新）和PATCH（部分更新）操作。

场景再现:

  • “救护先锋01”在途中遇到临时道路施工，偏离了原定路线，新的路线为route-123-revised。
  • NWDAF立即向.../subscriptions/sub-ambulance-01发送一个PATCH请求，只更新vflInferAnaSubs字段中的路线信息。
  • “天穹智脑”收到后，无缝地将推理目标切换到新路线上，并返回200 OK或204 No Content，整个过程对上层业务透明。

2.3 5.3.2.3 Naf_VFLInference_Unsubscribe - 取消推理

规范原文引用 (Clause 5.3.2.3.2 Unsubscribe from VFL inference notifications) The NF service consumer shall invoke the Naf_VFLInference_Unsubscribe service operation…shall send an HTTP DELETE request with: “{apiRoot}/naf-vflinference//subscriptions/{subscriptionId}” as Resource URI…

流程深度解析:

  • 动作: 当“救护先锋01”安全抵达医院，任务结束。NWDAF向.../subscriptions/sub-ambulance-01发送一个DELETE请求。
  • 响应: “天穹智脑”收到请求后，停止对该路线的监控和推理，释放资源，并返回204 No Content。

2.4 5.3.2.4 Naf_VFLInference_Notify - 通知推理结果

这是AF在此服务中唯一的主动操作，也是整个协同推理价值的最终体现。

流程图: Figure 5.3.2.4.2-1: AF notifies the subscribed VFL inference event

  1. AF → NF service consumer: 1. POST {notificationURI}
  2. NF service consumer → AF: 2. "204 No Content"

流程深度解析:

规范原文引用 (Clause 5.3.2.4.2 Notification about subscribed event) The AF shall invoke the Naf_VFLInference_Notify service operation to notify about a subscribed VFL inference event. The AF shall send an HTTP POST request with “{notifUri}“…The VflInferNotif data structure provided in the request body that shall include:

  • a notification correlation identifier as “notifCorreId” attribute. And may include:
  • description of the notified event as “vflInferResults ” attribute;
  • cause for termination…
  • 动作: “天穹智脑”根据订阅中vflReportInfo的要求（比如每10秒），主动向NWDAF提供的notifUri (https://nwdaf.gov/ambulance-notif) 发送POST请求。
  • 载荷 (VflInferNotif): 这是**“推理结果报告”**。
    • notifCorreId: 必选，用于关联订阅。
    • vflInferResults: 推理结果。这是“天穹智脑”贡献的“智慧”。比如，它可能报告：“根据群体移动性分析，未来5分钟内，XX路口的行人流量将增加30%，可能影响救护车通行。”
    • termCauses: 终止原因。如果“天穹智脑”因内部故障等原因无法继续提供推理，它可以在最后一次通知中附上终止原因。

场景闭环:

  1. 在“救护先锋01”行驶过程中，“天穹智脑”和“智行一号”AF每10秒就向城市NWDAF的notifUri发送一次Notify。
  2. NWDAF汇聚来自各方的vflInferResults，形成一个全局、实时的交通态势图。
  3. 基于这个全局视图，NWDAF向交通信号灯控制系统下达指令，提前将救护车路径上的信号灯变为绿色。
  4. 最终，“救护先锋01”一路畅通，成功挽救了生命。任务结束后，NWDAF发送DELETE请求，整个协同推理闭环完美结束。

3. 总结：实时协同，赋能精准决策

通过对5.3章的深度拆解，我们清晰地看到了Naf_VFLInference服务如何将VFL模型从一个静态的产物，转化为一个能够实时响应、协同工作的动态智能体。

  • 灵活的订阅模式: 同时支持一次性查询 (immRep=true) 和长期订阅，满足了不同业务场景的需求。
  • 标准的生命周期管理: 同样采用POST /subscriptions（创建）、PUT/PATCH /subscriptions/{id}（更新）、DELETE /subscriptions/{id}（删除）的RESTful模式，清晰、一致且易于实现。
  • 价值的最终交付: Notify操作是整个联邦学习价值链的最后一环，它将分散在各处的“数据”经过协同训练和推理，最终转化为有价值的“洞察”，并主动推送给决策系统。

Team Alpha成功地理解了Naf_VFLInference服务的精髓。他们认识到，这个服务不仅是技术的实现，更是“天穹智脑”兑现其“智能、实时、可靠”承诺的关键。有了这个服务，训练出的模型才能真正地走向应用，为5G网络和垂直行业赋能。

4. FAQ 环节

Q1：Naf_VFLInference和Naf_Inference（将在5.5章讲解）的核心区别是什么？

A1：核心区别在于推理模式和AF的角色。

  • Naf_VFLInference: 是协同式、分布式推理。AF扮演VFL客户端，是众多推理参与方之一。它只贡献自己基于本地数据的部分计算结果，最终结果由协调者（如NWDAF）汇聚而成。适用于数据不能汇集，需要多方共同决策的场景。
  • Naf_Inference: 是集中式推理。AF扮演VFL服务器（即中心推理引擎）。它独立拥有完整的模型和所需数据，直接接收推理请求，并独立计算出最终结果返回给消费者。适用于数据可以集中，由一个强大中心提供AI能力的场景。

Q2：在Naf_VFLInference_Subscribe时，vflReportInfo这个参数具体有什么作用？

A2：vflReportInfo是一个非常重要的数据结构，它定义了AF如何以及何时应该发送Notify通知。它源自TS 29.523（策略控制事件暴露服务）中的ReportingInformation类型，包含了丰富的报告策略，例如：

  • immRep (Immediate Reporting): 如前所述，请求立即返回一次报告。
  • repPeriod (Reporting Period): 定义报告的周期，比如每10秒一次。
  • sampRatio (Sampling Ratio): 采样率，比如只对10%的事件进行报告。
  • Event Triggers: 定义触发报告的特定事件，比如“仅当预测的拥堵等级超过阈值4时才报告”。 通过这个参数，NF消费者可以非常精细地控制通知的频率和时机，从而在获取信息和控制信令开销之间取得平衡。

Q3：为什么Table 5.3.1-1中，NWDAF被描述为acting as VFL servers？它不是消费者吗？

A3：这里的“server”不是指HTTP协议中的服务器，而是指在VFL业务逻辑中的**“中心协调者”**角色。在VFL推理任务中，需要一个中心节点来发起任务、向所有VFL客户端（如AF）分发推理请求、收集并聚合各方的中间结果，最终形成全局预测。NWDAF或NEF扮演的就是这个角色。因此，从业务逻辑上看，它们是VFL的“Server”。而从SBI接口调用关系上看，它们是Naf_VFLInference服务的“Consumer”（消费者），因为它们在调用AF提供的服务。理解这种角色区分是关键。

Q4：如果一个VFL推理任务有多个AF参与，NWDAF是需要向每个AF都发送一次Subscribe请求吗？

A4：是的。NWDAF作为协调者，需要独立地与每一个VFL客户端（AF）建立订阅关系。例如，在我们的“生命通道”场景中，NWDAF需要：

  1. 向“天穹智脑”AF的/subscriptions端点发送一个POST请求，建立sub-ambulance-01。
  2. 向“智行一号”AF的/subscriptions端点发送另一个POST请求，建立sub-ambulance-02。 之后，NWDAF会从两个不同的通知回调地址，分别收到来自两个AF的Notify，然后在自己的逻辑中进行结果的聚合。

Q5：Naf_VFLInference_Notify的响应204 No Content表示消费者已经处理了推理结果吗？

A5：不表示。204 No Content仅仅是对HTTP POST请求的一个传输层确认，意思是“你的通知消息我已经成功收到了，消息格式正确，我已存好”。它不代表消费者（NWDAF）已经完成了对通知内容的业务逻辑处理（比如，聚合结果、调整信号灯）。这种设计将传输确认与业务处理解耦，使得通知机制非常轻量和高效。AF发送通知后，只要收到204，就可以认为通知已成功送达，然后继续下一次的推理计算，而无需等待消费者完成复杂的后续业务流程。

关系图谱