51学通信

深度解析 3GPP TS 29.530：5.5 Naf_Inference Service (中心化模型推理服务)

20分钟阅读

好的，我们继续拆解Naf_Inference服务，这是“天穹智脑”对外提供智慧的最终出口。

深度解析 3GPP TS 29.530：5.5 Naf_Inference Service (中心化模型推理服务)

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

至此，“天穹智脑”AI平台已经硕果累累。通过Naf_Training服务，它成功为“未来之声”音乐节训练出了高精度的“大规模人群动态网络负载预测模型V1.0”，并获得了唯一的身份标识model-music-fest-v1.0。模型已经存放在“天穹智脑”的模型仓库中，蓄势待发。

首席架构师Dr. Evelyn Reed在音乐节保障项目启动会上，对负责网络实时优化的Team Delta说：“模型已经就位，现在轮到你们了。Naf_Inference服务，就是连接静态模型和动态网络的桥梁。它不是简单的API调用，而是将我们的智慧实时注入网络脉搏的关键通道。客户需要的不是模型本身，而是模型在每一分、每一秒给出的精准洞察。我们的任务，就是构建一个7x24小时不间断、毫秒级响应的‘AI问询台’。”

1. 5.5.1 Service Description - 服务的核心使命

本节高度概括了Naf_Inference服务的核心能力，即对外提供按需的、实时的AI推理服务。

规范原文引用 (Clause 5.5.1 Service Description) The Naf_Inference service as defined in 3GPP TS 23.288, is provided by the Application Function (AF) acting as VFL server. This service allows the NF service consumers:

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

核心解读:

  • AF的角色: AF在这里的角色是VFL Server，再次强调，这应被广义地理解为“中心推理服务提供者”。“天穹智脑”现在是持有并运行AI模型的权威实体。
  • 服务模式: 与Naf_Training服务类似，Naf_Inference同样是基于订阅/通知模型。NF消费者（如NWDAF, OAM, PCF等）可以向AF订阅特定的推理事件，并在事件发生或周期性地收到包含推理结果的通知。这使得AF成为了一个可编程的、事件驱动的“智能引擎”。

“未来之声”音乐节场景实战:

  • 背景: 音乐节即将开幕，OAM和NWDAF需要利用model-music-fest-v1.0模型，对现场网络进行实时监控和预测性优化。
  • 需求:
    1. 宏观态势感知 (OAM): OAM希望每5分钟获取一次未来1小时内，整个奥体中心区域的无线负载热力图预测，用于全局资源调度。
    2. 微观主动优化 (NWDAF): NWDAF希望对核心舞台区域的几个重点小区进行持续监控，一旦预测到任何小区的PRB利用率在未来15分钟内将超过80%，就立即收到告警和优化建议。

这两个需求，一个偏向周期性的宏观报告，一个偏向事件触发式的微观告警，都将通过Naf_Inference服务来实现。

2. 5.5.2 Service Operations - “AI问询台”的工作流程

本节详细定义了Naf_Inference服务的操作接口和交互流程，即“AI问询台”如何接收、处理和响应来自全网的“咨询”。

2.1 5.5.2.1 Introduction - 操作总览

Table 5.5.2-1: Naf_Inference Service Operations为我们展示了本服务的操作全集。

Service Operation NameDescriptionInitiated by
Naf_Inference_SubscribeThis service operation is used by an NF service consumer to subscribe to, or modify a subscription in the AF for Inference event notifications.NF Consumer (i.e., NWDAF, NEF)
Naf_Inference_UnsubscribeThis service operation is used by an NF service consumer to unsubscribe from Inference event notifications.NF Consumer (i.e., NWDAF, NEF)
Naf_Inference_NotifyThis service operation is used by the AF to report Inference related event(s) to the NF service consumer which has subscribed to the event report service.AF

表格解读:

  • 熟悉的配方: 依然是Subscribe, Unsubscribe, Notify这“三驾马车”，驱动着服务的整个生命周期。这种设计的一致性大大降低了5G核心网的整体复杂性。
  • 主动与被动: Subscribe和Unsubscribe由消费者发起，代表“提出咨询请求”和“结束咨询”。Notify由AF发起，代表“主动告知答案”。

2.2 5.5.2.2 Naf_Inference_Subscribe - 建立推理订阅

这是网络功能向“天穹智脑”提出“问题清单”的时刻。

2.2.2.2.2 Inference Subscription Creation (创建订阅)

流程图: Figure 5.5.2.2.2-1: Procedure for Inference subscription，展示了标准的HTTP POST创建资源流程。

流程深度解析:

规范原文引用 (Clause 5.5.2.2.2) In order to subscribe to Inference event notifications, the NF service consumer shall send an HTTP POST request to the AF targeting the URI of the “Inference Subscriptions” collection resource, with the request body including the InferEventsSubsc data structure.

  • 动作: 消费者（如OAM）向“天穹智脑”的.../naf-inference/v1/subscriptions端点发送POST请求。
  • 载荷 (InferEventsSubsc): 这是**“推理任务委托书”**，其核心字段包括：
    • events: 订阅的事件。每个事件都包含了需要哪个模型、针对什么目标进行推理。
      • anaEvent: 要预测的分析事件，如LOAD。
      • modelId: 关键字段！ 明确指定使用哪个模型，例如"model-music-fest-v1.0"。
      • tgtUe: 推理的目标，可以是特定的区域ID（如“奥体中心”）、小区列表、或用户群。
    • reportingInformation: 报告信息。与Naf_VFLInference中的repPeriod, immRep, eventTriggers等类似，用于定义何时以及如何发送通知。
    • notifUri: 接收推理结果的回调地址。

规范原文引用 (Clause 5.5.2.2.2) If the VFL server is a trusted AF:

  • If no VFL model is already trained, the VFL server initiates VFL Training by sending Nnwdaf_VFLTraining_Subscribe towards NWDAF(s) acting as VFL Client(s).
  • 智能联动: 规范在这里引入了一个非常智能的联动机制。如果消费者请求推理，但发现“天穹智脑”并没有训练好的模型，它可以反向发起一个训练请求！这体现了AF的高度自主性和智能化。当然，这更多是针对VFL场景的描述，但在中心化场景下，AF也可以根据预设策略，自动触发Naf_Training流程。

场景再现 (OAM的宏观态势订阅):

  1. OAM系统构建了一个InferEventsSubsc JSON对象，其中：
    • events数组中包含一个元素，指定modelId: "model-music-fest-v1.0"，tgtUe为“奥体中心区域ID”。
    • reportingInformation中设置repPeriod: "300s"（300秒，即5分钟）。
    • notifUri为https://oam.operator.com/notif/heatmap。
  2. OAM向“天穹智脑”的/subscriptions端点发送POST请求。
  3. “天穹智脑”接收请求，验证模型ID存在且可用，创建了一个新的推理任务，并返回201 Created和订阅URI /subscriptions/sub-heatmap-01。
  4. 从此，一个后台任务启动，每5分钟就调用一次模型，生成一份热力图预测，并通过Notify发送给OAM。

场景再现 (NWDAF的微观告警订阅):

  1. NWDAF构建了另一个InferEventsSubsc JSON对象，其中：
    • events中指定了modelId和几个重点小区的ID。
    • reportingInformation中设置了eventTriggers，条件为“预测的PRB利用率 > 80%”。
    • notifUri为https://nwdaf.operator.com/notif/congestion-alarm。
  2. NWDAF也发送了POST请求，创建了另一个订阅/subscriptions/sub-alarm-02。
  3. “天穹智脑”为这几个小区启动了持续的、高频的滚动预测。但只要预测值低于80%，它就保持沉默，不产生任何信令。

2.2.2.2.3 Modification of an existing subscription (更新订阅)

流程图: Figure 5.5.2.2.3-1: Modification of an existing subscription，展示了标准的PUT/PATCH更新流程。

场景再现:

  • 音乐节主舞台人流超预期，NWDAF决定将告警阈值从80%临时调低到70%，以获得更早的预警。
  • NWDAF向.../subscriptions/sub-alarm-02发送一个PATCH请求，只更新reportingInformation中的eventTriggers字段。
  • “天穹智脑”动态调整了告警判断逻辑，返回200 OK。

2.3 5.5.2.3 Naf_Inference_Unsubscribe - 结束推理任务

流程图: Figure 5.5.2.3.2-1: NF service consumer unsubscribes from inference notifications，展示了标准的DELETE流程。

场景再现:

  • 音乐节圆满落幕，人群散去，网络恢复常态。
  • OAM和NWDAF分别向sub-heatmap-01和sub-alarm-02发送DELETE请求。
  • “天穹智脑”停止了所有相关的推理任务，释放了计算资源，并返回204 No Content。

2.4 5.5.2.4 Naf_Inference_Notify - 主动推送“智慧洞察”

这是“AI问询台”给出答案的时刻，也是所有前期工作价值的最终体现。

流程图: Figure 5.5.2.4.2-1: AF notifies the subscribed inference event，展示了AF主动POST通知的标准流程。

流程深度解析:

规范原文引用 (Clause 5.5.2.4.2 Inference Notification) In order to notify a previously subscribed service consumer on Inference event(s), the AF shall send an HTTP POST request to the NF service consumer with the request URI set to “{notifUri}”… and the request body including the TrainEventsNotif data structure.

  • 动作: “天穹智脑”根据订阅的报告策略，主动向消费者提供的notifUri发送POST请求。
  • 载荷: 规范原文此处有误，应为InferEventsNotif或类似的推理通知数据结构（可能在后续版本中修正，我们根据上下文理解其意图）。这个**“推理结果报告”**包含了：
    • notifId / notifCorreId: 通知ID或订阅关联ID。
    • inferResults: 核心价值所在！ 包含了推理的结果。例如：
      • 对于OAM的热力图订阅，inferResults可能是一个JSON数组，每个元素包含{cellId, predictedLoad, timestamp}。
      • 对于NWDAF的告警订阅，inferResults可能包含{cellId, predictedLoad: 82%, suggestedAction: "redirect_traffic_to_cell_B"}。

场景闭环:

  1. 宏观态势: 音乐会高潮时段，“天穹智脑”每5分钟就向OAM的notifUri发送一次包含上百个小区负载预测值的Notify。OAM的网管大屏上，热力图实时刷新，指导后台的资源池进行动态扩容。
  2. 微观告警: 突然，“天穹智脑”的滚动预测发现，主舞台正前方的cell-A01在10分钟后的负载将飙升至85%。这触发了NWDAF的告警订阅。
  3. “天穹智脑”立即向NWDAF的notifUri发送了一个紧急Notify，其中包含了对cell-A01的拥塞预警。
  4. NWDAF收到告警，立即联动PCF（策略控制功能），对进入该小区的新用户进行轻微的限速，同时引导部分用户切换到邻近小区，成功地将一场潜在的网络拥塞化解于无形。

3. 总结：AIaaS闭环的最后一公里

通过对5.5章的深度剖析，我们看到Naf_Inference服务构成了“AI能力即服务”从模型生产到价值变现的最后一公里。它使得AF不再是一个仅仅存储模型的“仓库”，而是一个能够对外提供实时、智能、按需服务的“智慧引擎”。

  • 将模型转化为服务: 通过Subscribe操作，将一个静态的modelId与一个动态的业务需求（tgtUe, reportingInformation）绑定，从而将模型激活为一个可用的网络服务。
  • 灵活的“推”模式: Notify机制使得AF能够将洞察力“推送”到最需要它的地方，无论是周期性的报告还是事件触发的告警，都实现了信息的“主动赋能”。
  • 驱动网络自动化: Naf_Inference的输出结果，可以直接作为其他网络功能（如OAM, NWDAF, PCF, SON）执行自动化策略的输入，是实现“自动驾驶网络”感知-分析-决策-执行（MAPE）闭环中，从“分析”到“决策”的关键一步。

Team Delta成功地构建了“天穹智脑”的“AI问询台”。这个问询台不仅能回答问题，更能主动发现问题、预见未来，并将这些宝贵的洞察力实时地传递给网络中的每一个决策者，让整个5G网络因AI而变得更加智能、高效和可靠。

至此，我们已经完整地剖析了TS 29.530规范第4章和第5章定义的四大核心服务。我们已经从宏观上理解了AF在5G AI生态中的所有角色和能力。从下一篇文章开始，我们将深入规范的第6章，拿起“显微镜”，去观察构成这些宏伟服务的每一个“细胞”——具体的数据模型和API定义。

4. FAQ 环节

Q1：Naf_Inference和Naf_VFLInference的API设计几乎一样，我如何区分它们？

A1：您可以通过**API的apiName**来区分。根据Table 5.1-1，它们的URI是不同的：

  • Naf_Inference: .../{apiRoot}/naf-inference/v1/...
  • Naf_VFLInference: .../{apiRoot}/naf-vflinference/v1/... 尽管它们的Subscribe/Unsubscribe/Notify流程非常相似，但由于服务的apiName不同，它们是两个完全独立的API端点。这种设计的好处是，开发者可以使用同一套客户端逻辑框架来与这两个服务交互，只需更改目标URI和请求体中的具体数据结构即可。

Q2：在Naf_Inference_Subscribe时，我可以不指定modelId吗？

A2：通常情况下，modelId是必须指定的，因为消费者需要明确告诉AF使用哪个模型来进行推理。这保证了推理结果的可预测性和一致性。但在一些非常高级的场景中，规范可能会允许消费者只描述它需要解决的问题（比如提供anaEvent和useCaseCxt），而由AF自主选择最合适的模型来执行推理。这被称为“模型即服务”的更高阶形态，AF内部需要有一个智能的“模型调度器”。TS 29.530的当前版本可能没有明确支持这种模式，但这是未来演进的一个可能方向。

Q3：Naf_Inference_Subscribe是否支持一次性、同步的推理请求？

A3：是的，通过在reportingInformation中设置immRep=true（请求立即报告），Subscribe操作可以模拟一次同步的Request/Response调用。消费者发送POST请求后，如果AF能立即计算出结果，就会在201 Created的响应体中直接带回第一份inferResults。这种“一次性订阅”的设计非常优雅，因为它用一个统一的Subscribe接口，同时满足了“查询一次”和“长期监控”两种需求，避免了再额外定义一个独立的Request操作。

Q4：如果“天穹智脑”AF发现它所依赖的model-music-fest-v1.0模型已经过时或性能下降，它会怎么办？

A4：这是一个很好的关于模型生命周期管理的问题。“天穹智脑”作为一个先进的AI平台，内部应该有**模型监控（Model Monitoring）和持续部署（Continuous Deployment）**的机制。

  1. 主动通知: 当AF发现模型性能下降时，它可以主动向所有订阅了该模型的消费者发送一次Naf_Inference_Notify，在通知中附上一个termCause，如MODEL_OUTDATED，并终止该订阅。
  2. 自动再训练: 更理想的情况下，AF的内部监控系统在发现模型性能下降后，可以自动触发一次新的Naf_Training流程，使用最新的数据重新训练出model-music-fest-v2.0。
  3. 无缝更新: 模型V2.0上线后，AF可以通知消费者，建议他们更新订阅，改用新的modelId。或者在某些高级实现中，AF可以对消费者透明地完成模型的“热切换”。

Q5：Naf_Inference服务的消费者只能是NWDAF或OAM吗？

A5：不是。理论上，5G核心网中任何经过授权的NF都可以成为Naf_Inference服务的消费者。例如：

  • PCF (Policy Control Function): 可以订阅用户移动性预测，以便为用户制定更精准的QoS策略。
  • AMF (Access and Mobility Management Function): 可以订阅负载预测，以做出更智能的MME（在5G中是AMF）选择或重定向决策。
  • SON (Self-Organizing Networks) Function: 可以订阅各种网络性能预测，以执行自动化的邻区关系优化、负载均衡等。 Naf_Inference服务的目标，就是让AF成为一个对全网开放的、通用的“AI能力中心”，任何需要智能决策的NF都可以来此“问询”。

关系图谱