好的，我们继续这场深入3GPP TS 29.552规范的旅程。在前一篇文章中，我们详细解析了5.5节，揭示了‘洞察者’(Insight-AI)是如何通过其庞大的“情报网”从5G网络的各个角落收集数据的。数据是“食粮”，但如何将食粮烹饪成佳肴，则需要“菜谱”和“厨艺”——也就是机器学习（ML）模型。

本文将聚焦于一个极具前瞻性和AI时代特色的话题，深入探讨规范的5.6节和5.6A节。我们将揭示5G网络“智慧大脑”的“大脑”——ML模型本身，是如何被创造、分发和更新的。这部分内容是实现5G网络内生智能、持续进化的核心机制。

深度解析 3GPP TS 29.552：5.6 & 5.6A 智能之脑的构建与分发 (ML模型供给与训练)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将深度剖析5.6节“ML Model provisioning procedures”和5.6A节“ML Model Training procedures”，为读者详细揭示5G网络是如何对其核心智能组件——机器学习模型，进行标准化的生命周期管理的，涵盖了模型的按需分发和委托训练两大核心流程。

前言：为“智慧大脑”安装和升级“操作系统”

我们已经知道，‘洞察者’(Insight-AI)通过分析海量数据来产生洞察。在很多高级场景下，这种分析能力并非源于简单的统计规则，而是来自复杂的机器学习模型。这些模型如同‘洞察者’的“操作系统”或“应用App”，决定了它能做什么、做得怎么样。

然而，在一个动态演进的网络中，模型绝不是一成不变的。新的网络技术、新的业务模式、新的攻击手段层出不穷，这意味着模型必须能够：

• 持续进化：需要不断用新的数据进行训练，以提升准确性。

• 按需部署：一个在总部数据中心训练好的、先进的拥塞预测模型，需要能被快速分发到网络边缘，以应对本地的突发事件。

• 协同开发：一个专注于安全分析的团队，可能需要借助另一个拥有强大计算集群的团队的能力，来训练一个资源消耗巨大的异常检测模型。

为了满足这些AI时代的需求，3GPP在TS 29.552中，专门定义了两套与ML模型生命周期管理相关的信令流程，它们共同构成了5G核心网原生的MLOps（机器学习运维）框架的基石：

1. ML模型供给 (ML Model Provisioning)：解决了**“如何分发和订阅模型”**的问题。它像一个“App Store”，允许一个NWDAF（通常是只负责推理的边缘NWDAF）从另一个拥有模型的NWDAF（通常是负责训练的中心NWDAF）那里订阅和获取最新的模型软件。

2. ML模型训练 (ML Model Training)：解决了**“如何委托和外包训练任务”**的问题。它像一个“AI代工厂”，允许一个NWDAF将模型训练这个计算密集型任务，委托给另一个拥有强大训练能力的NWDAF来完成。

为了生动地理解这两个流程，我们将引入‘洞察者’集群内部的角色分工：

• ‘洞察者-Prime’：部署在运营商总部的中心NWDAF，拥有强大的MTLF（模型训练逻辑功能），如同一个装备了海量GPU的**“AI实验室”**，负责研发和训练最高级的ML模型。

• ‘洞察者-Edge’：部署在“未来科技博览会”现场的边缘NWDAF。它资源有限，只有一个高效的AnLF（分析逻辑功能）用于实时推理，没有大规模训练能力。它的任务是执行模型，而不是创造模型。

• ‘洞察者-Security’：一个专业NWDAF，专注于网络安全分析。它有自己的算法专家，但计算资源不如‘洞察者-Prime’。

现在，让我们看看这三位“专家”是如何通过标准化的信令流程，进行高效的“AI协作”的。

---

1. “AI大脑的软件商店”：5.6 ML模型供给流程 (Provisioning)

本节的核心是定义一个NWDAF如何从另一个NWDAF那里获取它需要的ML模型。

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

The ML Model provisioning procedures allow the NF service consumers (i.e. NWDAF (MTLF+AnLF), NWDAF (AnLF)) to obtain the ML model information on the related Analytics from another NWDAF (i.e. an NWDAF containing MTLF).

这段话明确了角色的分工：

• 消费者：任何需要模型的NWDAF，无论它自己有没有训练能力(MTLF)。在我们的场景中，主要是‘洞察者-Edge’。

• 生产者：一个拥有可供分发的模型的NWDAF，它必须包含MTLF。在我们的场景中，是‘洞察者-Prime’。

场景：“未来科技博览会”即将开幕，‘洞察者-Prime’的“AI实验室”刚刚训练完成了一个全新的“V2.0版本人群流量与拥塞预测模型”，其预测精度远超旧的V1.0版。部署在现场的‘洞察者-Edge’急需这次“软件升级”，以应对即将到来的人流高峰。

此时，‘洞察者-Edge’就会启动 “Figure 5.6.2-1: ML Model Subscribe/Unsubscribe/Notify procedure” 所示的流程。

步骤1 & 2：边缘大脑发起“求新”订阅

规范原文引用 (Step 1):

In order to subscribe to ML model information, the NF service consumer invokes Nnwdaf_MLModelProvision_Subscribe service operation by sending an HTTP POST request targeting the resource “NWDAF ML Model Provision Subscriptions”…

1. 动作：‘洞察者-Edge’向‘洞察者-Prime’发起一个HTTP POST请求，调用Nnwdaf_MLModelProvision_Subscribe服务。

2. 请求体：这份“模型订阅单”中包含了精确的需求：

   • analyticsId: "USER_DATA_CONGESTION"。表明我需要的是用于用户数据拥塞分析的模型。

   • mlAnalyticsFilter (可选): 更精细的过滤器，例如areaOfInterest，表明我只需要适用于“博览会展馆”区域的模型。

   • notificationUri: ‘洞察者-Edge’自己的通知接收地址。

3. 响应 (Step 2)：‘洞察者-Prime’收到订阅后，接受请求，并回复201 Created。响应的Location头中包含了这个订阅关系的唯一ID (subscriptionId)。

步骤3 & 4：中心大脑“推送更新”

规范原文引用 (Step 3):

If the NWDAF containing MTLF determines that the subscribed ML model information is available, the NWDAF containing MTLF invokes Nnwdaf_MLModelProvision_Notify service operation to report the ML model information…

‘洞察者-Prime’的AI模型库中，USER_DATA_CONGESTION模型刚刚被更新到了V2.0。订阅条件被触发！

1. 动作：‘洞察者-Prime’立刻向‘洞察者-Edge’提供的notificationUri地址，发送一个Nnwdaf_MLModelProvision_Notify通知。

2. 通知内容：这是整个流程的核心。通知体中包含了一个ModelInfo数据结构，这就像是新软件的“发布说明和下载链接”：

    
   {
    
     "subscriptionId": "sub12345",
    
     "modelInfo": {
    
       "modelId": "CongestionModel-v2.0",
    
       "modelURI": "https://models.operator.com/congestion-v2.0.pkl",
    
       "modelMetrics": {
    
         "accuracy": 0.98,
    
         "latency": "5ms"
    
       },
    
       // ... 其他模型元数据
    
     }
    
   }
    

   • modelURI: 这不是模型文件本身，而是一个指向模型文件的下载地址。‘洞察者-Edge’需要通过这个URI去下载实际的模型文件。这避免了在核心网信令消息中传递庞大的模型文件。

   • modelMetrics: 模型的性能指标，如准确率、推理时延等，帮助消费者判断这个模型是否满足其要求。

3. 消费者确认 (Step 4)：‘洞察者-Edge’收到通知后，回复204 No Content确认。它会随即启动后台下载，并在下载和验证成功后，将自己的拥塞预测引擎无缝切换到V2.0模型。

步骤5 & 6：取消订阅

任务完成后，‘洞察者-Edge’可以向之前获取的订阅URI发起HTTP DELETE请求，取消订阅。

通过这套流程，5G网络实现了一套标准化的、类似“软件更新”的机制，确保了部署在网络各处的“小脑”们，能够持续获得来自“中央大脑”最新的AI能力赋能。

---

2. “AI能力外包服务”：5.6A ML模型训练流程 (Training)

本节则更进一步，定义了如何将“训练模型”这个动作本身，作为一项服务来进行订阅。

规范原文引用 (Clause 5.6A.1 General):

The ML Model training procedures allow the NF service consumers (i.e. NWDAF containing MTLF) to subscribe to another NWDAF (i.e. an NWDAF containing MTLF) for a trained ML model and/or the information about ML model training based on the ML model file or ML Model information provided by the consumer and the data for the training.

这里的角色分工更为专业：

• 消费者：一个拥有MTLF的NWDAF，它有算法和数据，但可能缺少计算资源。在我们的场景中，是‘洞察者-Security’。

• 生产者：一个拥有强大MTLF（计算资源）的NWDAF，能够接受委托，执行训练任务。在我们的场景中，是‘洞察者-Prime’的“AI实验室”。

场景：博览会期间出现了一种新型、复杂的DDoS攻击。‘洞察者-Security’的专家团队连夜设计出了一个基于Transformer的检测模型算法，并收集了大量的攻击流量样本。但要在短时间内完成这个模型的训练，需要数百个GPU小时的算力，远超‘洞察者-Security’自身的配置。于是，它决定将这个训练任务“外包”给“AI实验室”。

此时，‘洞察者-Security’就会启动 “Figure 5.6A.2-1: ML Model Training Subscribe/Unsubscribe/Notify procedure” 所示的流程。

步骤1 & 2：专业大脑发起“代工”请求

规范原文引用 (Step 1):

In order to subscribe to ML model and/or ML model training information, the NF service consumer invokes Nnwdaf_MLModelTraining_Subscribe service operation by sending an HTTP POST request targeting the resource “NWDAF ML Model Training Subscriptions”…

1. 动作：‘洞察者-Security’向‘洞察者-Prime’发起一个HTTP POST请求，调用Nnwdaf_MLModelTraining_Subscribe服务。

2. 请求体（核心区别）：这份“代工订单”与模型供给订阅有本质不同，它提供了“原料”和“蓝图”：

   • mlModelInfo: 包含了待训练模型的信息。这可能是一个指向未训练模型文件的URI（mlModelFile），或是一套描述模型结构的元数据。

   • trainingDataInfo: 描述了用于训练的数据在哪里。这可能是一系列指向ADRF中数据集的查询条件，或是在数据源NF上的订阅信息。

   • trainingGoal: 训练目标，例如targetAccuracy = 0.999。

3. 响应 (Step 2)：‘洞察者-Prime’的“AI实验室”评估了任务的可行性后，接受订单，回复201 Created并返回subscriptionId。

步骤3 & 4：“AI实验室”开工并交付成果

规范原文引用 (Step 3):

If the NWDAF containing MTLF determines that the subscribed ML model and/or ML model training information is available, the NWDAF containing MTLF invokes Nnwdaf_MLModelTraining_Notify service operation to report the ML model and/or ML model training information…

‘洞察者-Prime’的MTLF启动了大规模的分布式训练任务。经过数小时的计算，一个高精度的DDoS检测模型训练完成。

1. 动作：‘洞察者-Prime’向‘洞察者-Security’发送一个Nnwdaf_MLModelTraining_Notify通知。

2. 通知内容：这份“交付报告”中包含了训练的最终成果：

    
   {
    
     "subscriptionId": "sub-train-67890",
    
     "modelInfo": {
    
       "modelId": "DDoS-Transformer-v1.0-trained",
    
       "modelURI": "https://models.operator.com/ddos-transformer-v1.0.pkl",
    
       "modelMetrics": { "accuracy": 0.9995 }
    
     },
    
     "trainingReport": {
    
       "status": "COMPLETED_SUCCESSFULLY",
    
       "epochs": 1000,
    
       "finalLoss": 0.001
    
     }
    
   }
    

   通知中不仅包含了训练好的模型的下载地址，还可能包含详细的训练报告，如最终的损失值、训练时长等，供‘洞察者-Security’的专家进行评估和归档。

3. 消费者确认 (Step 4)：‘洞察者-Security’收到通知，下载并验证模型后，回复204 No Content。它现在可以将这个强大的新模型部署到线上，实时检测新型DDoS攻击。

通过这套流程，5G网络内部实现了计算资源的按需共享和调度，使得拥有算法和数据的团队，可以不必受限于自身的硬件条件，利用网络中更强大的计算能力来完成AI模型的创新和迭代。

---

总结：构筑5G内生的MLOps体系

5.6和5.6A这两节内容，虽然篇幅不长，但意义深远。它们共同为5G核心网定义了一套原生的**机器学习运维（MLOps）**信令框架，将AI模型的生命周期管理，从传统IT领域的工具链，“内化”为了网络自身的能力。

• 模型供给（Provisioning） 流程，解决了AI能力**“从中心到边缘”的规模化部署和持续更新问题。它是一套“知识分发”**系统，让先进的AI模型能够快速赋能全网。

• 模型训练（Training） 流程，解决了**“按需、弹性”的模型生产问题。它是一套“算力共享”**系统，让网络中的AI创新不再受限于本地计算资源，实现了更高效的协同开发。

这两套机制，与我们将在后续文章中深入探讨的**联邦学习（Federated Learning）**机制相结合，共同构成了5G网络“智慧大脑”自我进化、自我完善的闭环。它们使得NWDAF不再是一个静态的分析工具，而是一个能够不断学习、适应和成长的、真正意义上的“智能生命体”。这正是5G网络迈向更高阶自动化和智能化的关键所在。

在下一篇文章中，我们将继续沿着5.7节的道路前进，深入探讨规范为“特定网络数据分析”所定义的具体流程，看看‘洞察者’是如何运用我们之前讨论的所有机制，来完成一项项具体的“KPI”的，我们将从“网络切片负载水平分析”开始。

---

FAQ 环节

Q1：模型供给（5.6）和模型训练（5.6A）这两个服务最核心的区别是什么？

A1：最核心的区别在于**“订阅的对象”和“消费者的输入”**。

• 在模型供给 (Provisioning)中，消费者订阅的是一个“现成的、已训练好的模型”。它扮演的是一个被动的接收者角色，输入很简单，只需告诉生产者“我需要什么类型的模型”。

• 在模型训练 (Training)中，消费者订阅的是“训练这个动作本身”。它扮演的是一个主动的任务发布者角色，输入很复杂，需要提供“待训练的模型”、“训练所需的数据”以及“训练目标”等“原料”和“图纸”。

Q2：一个NWDAF如何知道它应该向哪个NWDAF去订阅模型或请求训练？

A2：同样是通过NRF（网络功能仓库）。当一个NWDAF（如‘洞察者-Prime’）拥有可供分发的模型或强大的训练能力时，它会在向NRF注册自己的NF Profile时，明确声明这些能力。例如，它的Profile中会包含：

• supportedAnalyticsIds: 它能为哪些分析提供模型。

• trainedMLModelInfoList: 它拥有的现成模型的列表。

• mtlfInfo: 描述其MTLF能力的详细信息，如支持的训练算法、计算资源等级等。

需要模型或训练服务的消费者（如‘洞察者-Edge’），就可以向NRF发起一个带有这些特定能力作为查询条件的NFDiscovery请求，从而找到最适合为它服务的“AI实验室”或“App Store”。

Q3：模型文件本身是否通过5G核心网的信令消息传递？

A3：通常不会。ML模型文件可能非常大，从几MB到几GB不等。在HTTP/2的信令消息中直接传递如此大的文件是极其低效且不切实际的。因此，规范采用了更现代、更解耦的方式：信令消息（如_Notify）中只传递模型的元数据(metadata)和统一资源标识符(URI)。消费者在收到通知后，通过这个URI，使用标准的HTTP GET请求，从一个专门的模型仓库（如对象存储、HTTP文件服务器）去下载实际的模型文件。这实现了控制面（信令）和数据面（模型文件传输）的分离。

Q4：MTLF（模型训练逻辑功能）为什么是NWDAF的可选功能？

A4：将MTLF设计为可选功能，是出于对部署灵活性和成本效益的考虑。

1. 资源消耗：模型训练（特别是深度学习模型）是一个计算密集型和能源密集型的任务，需要昂贵的硬件（如GPU/TPU集群）。要求在网络的每个角落都部署具备强大训练能力的NWDAF是不经济的。

2. 分层架构：更合理的架构是分层的。在中心数据中心部署少数几个拥有强大MTLF的“中央大脑”，负责耗时的训练任务；在网络边缘部署大量轻量级的、只有AnLF（分析逻辑功能）的“边缘大脑”，负责低延迟的实时推理。

模型供给（5.6）和训练（5.6A）流程，正是为了支持这种高效的分层架构而设计的。

Q5：这些流程与联邦学习（FL）是什么关系？

A5：模型供给/训练流程与联邦学习是互补的，共同构成了NWDAF MLOps工具箱。

• 模型供给/训练通常涉及中心化的训练模式。在模型训练流程中，数据信息被发送给一个中心训练者；在模型供给流程中，一个中心训练者分发模型。

• 联邦学习（FL）则是一种去中心化的训练模式。数据保留在本地（各个FL Client NWDAF），只有模型参数的更新被发送到中心（FL Server NWDAF）进行聚合。

在实际应用中，它们可以结合使用。例如，一个FL Server NWDAF可以通过联邦学习，汇集多个边缘节点的智慧，训练出一个全局模型。然后，它再通过模型供给流程，将这个经过聚合优化的全局模型，分发给所有边缘节点，以更新它们的本地模型。