51学通信

深度解析 3GPP TS 29.552：Ch 1-4 初始篇 & 参考架构 (The Foundation & Reference Architecture)

34分钟阅读

好的，遵照您的指令，我将接续上一篇的总结文章，从第一章开始，对规范进行逐节的深度拆解。由于第1、2、3章内容非常简短，根据规则，我将它们与第4章（第一个具有实质内容的章节）合并在一篇文章中进行解读，以确保文章的深度和完整性。

深度解析 3GPP TS 29.552：Ch 1-4 初始篇 & 参考架构 (The Foundation & Reference Architecture)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范。本文将首先对第1、2、3章进行概要性解读，为后续内容奠定基础，然后将深度剖析作为核心内容的“第4章 参考架构 (Reference Architecture)”，旨在为读者构建一个关于NWDAF如何在其生态系统中定位并与世界互动的坚实框架。

前言：开启逐层探索之旅

在上一篇《全景概览》中，我们与“数智网联”运营商的AI运维专家——‘洞察者’(Insight-AI)一起，鸟瞰了3GPP TS 29.552规范的宏伟蓝图。我们理解了这份规范作为5G“智慧大脑”NWDAF的“神经系统布线图”，其核心使命是定义详尽的信令流程，让智能真正落地。

现在，我们将开启一段更为细致的探索之旅。我们将像剥洋葱一样，从规范的第一页开始，逐章、逐节、逐段地深入其内部，不放过任何一个技术细节。

本次的旅程将从规范的起点——第1、2、3章开始。这三章虽然简短，却如同任何一部鸿篇巨著的序言、参考文献和名词解释，是理解后续所有复杂情节的基础。我们将快速而精准地消化它们，然后将主要精力聚焦于本次的“主菜”——第4章“参考架构”。这一章定义了‘洞察者’赖以生存和工作的“物理空间”和“组织架构”，理解了它，我们才能明白数据从何而来，洞察向何处而去。

让我们再次跟随‘洞察者’的视角，从这份规范的“第一行代码”读起。

1. 奠定基石：规范的“序章” (Chapters 1-3)

每一份严谨的工程文档，都始于对其边界、依赖和语言的精确界定。TS 29.552的第1至3章正是扮演了这样的角色。

1.1 第1章：范围 (Scope) - 划定‘洞察者’的“职权范围”

规范的开篇第一章，用最精炼的语言定义了它的边界。

规范原文引用 (Clause 1 Scope):

The present document specifies detailed call flows of Network Data Analytics and the related data collection over the Nnwdaf, Nsmf, Nnsacf, Namf, Nnrf, Nnssf, Nnef, Naf, Ndccf, Nadrf, Nmfaf, Nudm, Nupf and Ngmlc service-based interfaces and/or from OAM, and their relationship with the flow level signalling in 5G system.

‘洞察者’解读道：“这第一段话，就像是我的岗位职责说明书。它明确告诉我，我的工作内容就是通过一系列标准化的‘沟通渠道’（服务化接口），与其他同事（5GC网元）进行对话，以完成数据分析和收集任务。”

这段话的核心信息点如下：

  • 核心内容：详细的信令调用流程 (detailed call flows)。这表明本规范是Stage 3的实现级文档，关注的是“如何做”的细节。

  • 核心主题：网络数据分析 (Network Data Analytics) 和相关的数据收集 (related data collection)。

  • 交互对象：列出了一长串的接口名称，如Nnwdaf, Nsmf, Namf等。这些接口名称遵循3GPP的服务化接口命名规范，即N<NF Name>。例如，Nsmf代表与SMF交互的接口，Namf代表与AMF交互的接口。这份长长的列表彰显了NWDAF作为网络智能核心的地位——它几乎需要与所有关键网元进行互动。

  • 交互方式：通过服务化接口 (service-based interfaces) 或从OAM获取。这明确了数据来源的两大主要渠道：5G核心网内部的服务化接口，以及传统的运维管理域。

此外，本章还有两个非常重要的附注 (NOTE)：

规范原文引用 (Clause 1 Scope - NOTE 1 & 2):

NOTE 1: The call flows depicted in this Technical Specification do not cover all traffic cases.

NOTE 2: There is no data collected from the PCF by the NWDAF defined in this Release of the specification.

‘洞察者’提醒道：“这两点是工程师在实践中必须注意的‘免责声明’和‘版本特性’。”

  • NOTE 1 意味着规范给出的是典型和基础的流程，实际网络中的复杂组合场景可能需要基于这些基础流程进行扩展或适配。它为协议栈的实现和网络部署留下了定的灵活性。

  • NOTE 2 是一个关键的版本限制说明。它明确指出，在本规范的当前版本（Release 18）中，没有定义NWDAF从PCF（策略控制功能）收集数据的流程。这意味着，虽然NWDAF可以向PCF提供分析结果以影响策略决策，但它不能反过来从PCF那里获取策略相关的数据作为分析输入。这是设计网络分析方案时必须考虑的一个重要约束。

1.2 第2章：参考文献 (References) - ‘洞察者’的“知识库索引”

第二章列出了本规范所引用和依赖的所有其他3GPP及外部文档。对于初学者来说，这看起来可能像一个枯燥的列表，但‘洞察者’却视之为“知识图谱的入口”。

“如果说TS 29.552是我的‘行动手册’，那么第2章的参考文献就是指向我的‘教科书’、‘字典’和‘架构蓝图’的索引。没有它们，‘行动手册’里的很多指令是无法理解的。”

我们不必逐一阅读所有文献，但理解其中几个关键参考文献与本规范的关系至关重要：

  • ** 3GPP TS 23.288: “Architecture enhancements for 5G System (5GS) to support network data analytics services”：这是NWDAF的Stage 2规范**，是理解一切的起点。它定义了NWDAF的功能、架构和高层逻辑，是我们上一篇文章《全景概览》的核心参考。TS 29.552的所有流程都是为了实现TS 23.288中定义的场景。

  • ** 3GPP TS 23.501: “System Architecture for the 5G System; Stage 2”：这是整个5G系统的架构规范**。NWDAF是5G系统的一员，本规范定义了NWDAF的所有“同事”（AMF, SMF, UPF等）以及它们的基本职责和关系。

  • ** 3GPP TS 29.520: “5G System; Network Data Analytics Services; Stage 3”：这份规范与TS 29.552是“孪生兄弟”。如果说TS 29.552定义的是“流程”（信令交互的顺序和逻辑），那么TS 29.520定义的就是“语言”**——即Nnwdaf服务化接口的OpenAPI定义，包括所有数据结构、参数、API路径和操作的精确模型。开发人员在写代码时，会直接使用TS 29.520定义的YAML文件。

  • ** 3GPP TS 29.574: “5G System; Data Collection Coordination Services; Stage 3”** 和 ** 3GPP TS 29.575: “5G System; Analytics Data Repository Services; Stage 3”**：这两份规范分别定义了‘洞察者’的“数据助理”DCCF和“记忆数据库”ADRF的服务API。当TS 29.552的流程图中出现与DCCF或ADRF的交互时，具体的接口调用细节就要到这两份规范中去查找。

通过理解这个引用关系，我们建立了一个清晰的知识层次：从5G系统架构(23.501)，到NWDAF功能架构(23.288)，再到具体的信令流程(29.552)和API定义(29.520)，形成了一个完整的知识体系。

1.3 第3章：定义、符号和缩略语 (Definitions, symbols and abbreviations) - ‘洞察者’的“行话速查表”

第三章是本规范的“字典”，定义了所有关键术语和缩略语。在通信行业，精准地掌握缩略语是高效沟通的基础。‘洞察者’建议我们重点关注以下几个将在后续文章中高频出现的“热词”：

  • NWDAF (Network Data Analytics Function)：网络数据分析功能，我们的主角，5G网络的“智慧大脑”。

  • DCCF (Data Collection Coordination Function)：数据收集协调功能，NWDAF的“数据助理”，负责优化和协调对数据源的访问。

  • ADRF (Analytics Data Repository Function)：分析数据仓库功能，NWDAF的“记忆数据库”，用于存储和检索历史数据与分析结果。

  • AnLF (Analytics Logical Function)：分析逻辑功能。这是NWDAF的“计算核心”，负责执行实际的分析和预测算法。一个NWDAF实例内部必须包含一个AnLF。

  • MTLF (Model Training Logical Function)：模型训练逻辑功能。这是NWDAF的“学习引擎”，负责训练、验证和更新机器学习模型。一个NWDAF实例可能包含一个MTLF，这意味着并非所有NWDAF都有模型训练能力，有些可能只负责执行分析（推理）。

  • FL (Federated Learning)：联邦学习。一种分布式的机器学习技术，可以在保护数据隐私的前提下协同训练模型。

掌握了这些基础术语，我们就有了阅读和理解后续复杂信令流程的“钥匙”。

2. 智能的蓝图：第4章 深度解析参考架构

在完成了“序章”的热身之后，我们正式进入第4章“参考架构”。这一章是TS 29.552的“世界观设定”，它通过一系列简洁的架构图，描绘了‘洞察者’（NWDAF）的工作环境和核心交互模式。

为了让架构变得鲜活，让我们设定一个贯穿本章的场景：“未来科技博览会”。

这是一个在大型会展中心举办的盛会，充满了需要极致网络体验的应用，如全息投影、AR导航、无人机巡检、海量观众直播等。“数智网联”运营商部署了‘洞察者’系统，来确保这次活动的网络万无一失。

2.1 总则 (Section 4.1 General) - ‘洞察者’的三大核心职能

本节开宗明义，指出了NWDAF与网络中其他实体交互的三大目的。

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

For the enablement of network data analytics services, the NWDAF interacts with different entities for different purposes:

  • Data Collection:

a) collecting Data from OAM, MDAF and/or 5GC NFs (e.g. AMF);

…

  • Analytics Exposure:

a) Exposing Analytics to 5GC NFs;

…

  • Storing and Retrieving data in ADRF.

这三大职能构成了‘洞察者’工作的完整闭环：

  1. 输入 (Data Collection)：从网络各个角落收集数据。

  2. 处理 (Analytics)：在NWDAF内部进行分析（这部分是NWDAF的内部实现，非本规范重点）。

  3. 输出 (Analytics Exposure)：将分析结果提供给需要它的消费者。

  4. 记忆 (Storing and Retrieving)：将有价值的数据和分析结果长期保存，用于未来的学习和回溯。

接下来，我们将结合“未来科技博览会”场景，逐一剖析这几个环节的参考架构。

2.2 数据收集架构 (Section 4.2 Data Collection) - ‘洞察者’的“情报网”

‘洞察者’要想做出精准的预测，首先需要一个强大、高效的情报收集网络。规范中的**“Figure 4.2-1: Data Collection Architecture”**为我们展示了这张网络的结构。

场景：预测博览会入口处的人流高峰

博览会开幕在即，‘洞察者’的首要任务是预测入口A区域的人流高峰，以便网络能够提前进行资源扩容。为此，它需要多源情报：

  • AMF：该区域当前附着的用户数、用户移动模式。

  • SMF：用户建立的数据会话类型（是小流量的AR导航还是大流量的视频上传）。

  • OAM：入口A附近基站的无线资源利用率（PRB Usage）。

  • UPF：流经该区域的总数据流量。

现在，我们对照Figure 4.2-1，看看‘洞察者’如何获取这些情报：

  • 数据源 (Data Source NF)：图的右侧，代表了AMF, SMF, OAM等数据提供方。它们是情报的源头。

  • NWDAF：图的左侧，是情报的消费者和分析者，即‘洞察者’本身。

  • 直接路径 (Nnwdaf → Nn-whatever)：最简单的路径是NWDAF直接与数据源建立连接。例如，通过Nnamf接口直接向AMF订阅位置更新事件。这条路径简单直接，适用于一对一的简单场景。

然而，当网络变得复杂时，直接连接会暴露问题。比如，‘洞察者’内部有两个团队，一个负责移动性分析，一个负责拥塞分析，它们都需要AMF的位置数据。如果两个团队都去订阅，会给AMF带来双倍的信令负荷。为此，架构中引入了“中间人”角色。

  • DCCF (Data Collection Coordination Function)：图中的DCCF，正是为了解决上述问题而生的“数据助理”。它可以接收来自多个消费方（比如不同的NWDAF实例）的数据请求，然后进行协调和聚合。DCCF会发现两个团队都需要同样的数据，于是它只向AMF发起一次订阅，然后将收到的数据分发给两个团队。这极大地提升了数据收集的效率，降低了对数据源网元的信令冲击。

  • ADRF (Analytics Data Repository Function)：‘洞察者’在分析入口A人流时，会想：“去年这里也办过一个类似的展会，当时的数据是怎样的？” 这时，它就可以通过Nadrf接口向ADRF查询。ADRF存储了历史数据，是‘洞察者’进行趋势分析和模型训练的宝贵“记忆粮仓”。

  • MFAF (Messaging Framework Adaptor Function)：在某些异构网络环境中，可能存在需要通过非标准化的消息总线（Messaging Framework）进行交互的情况。MFAF此时就充当“翻译官”，将3GPP标准的服务化接口调用转换为消息总线上的消息，反之亦然，实现了系统的兼容和集成。

通过这个灵活的架构，‘洞察者’可以根据需要，选择最高效的路径来构建其覆盖全网的“情报网”。

2.3 分析暴露架构 (Section 4.3 Analytics Exposure) - ‘洞察者’的“指挥中心”

分析出结果后，‘洞察者’需要将这些富有价值的“洞察”传递出去，转化为实际的网络行动。**“Figure 4.3-1: Analytics Exposing Architecture”**展示了分析结果的输出路径。

场景：发布拥塞预警，主动优化网络

‘洞察者’综合分析后，得出结论：上午9点，入口A区域的4G网络将出现拥塞，但新建的5G毫米波网络资源尚有富余。它需要立即发布这个“指挥命令”。

  • 分析消费者 (Analytics consumer)：图的左侧，代表了需要分析结果的网元，如PCF、NSSF、AMF等。它们是“指挥命令”的接收者和执行者。

  • NWDAF：图的右侧，是分析结果的生产者，即‘洞察者’的“指挥中心”。

与数据收集架构类似，分析暴露的路径也是对称的：

  • 直接暴露：分析消费者可以直接通过Nnwdaf_EventsSubscription服务向NWDAF订阅分析事件。例如，PCF可以订阅“用户数据拥塞分析”，一旦‘洞察者’预测到拥塞，就会立即通知PCF。

  • 通过DCCF/MFAF暴露：在某些场景下，分析结果的传递也可以通过DCCF进行协调，或者通过MFAF进行协议适配。例如，一个外部的第三方应用（AF）希望获取网络拥塞信息，它可能通过NEF（网络能力开放功能）接入，而NEF在内部可能通过DCCF来获取NWDAF的分析结果。

在这个场景中，‘洞察者’会向PCF和AMF发布它的分析结果：

  1. 通知PCF：PCF收到拥塞预警后，可以制定新的策略，通过5G的ATSSS（Access Traffic Steering, Switching and Splitting）特性，将一部分符合条件的双连接用户的数据流量，从拥塞的4G网络主动迁移到空闲的5G毫米波网络上。

  2. 通知AMF：AMF收到通知后，可以在进行移动性管理决策时，优先引导新接入的用户驻留到5G网络上，从而分担4G的压力。

通过这个闭环，‘洞察者’的“预测”成功转化为了“行动”，实现了网络的主动、智能优化。

2.4 数据存储与漫游 (Sections 4.4 & 4.5) - ‘洞察者’的“档案馆”与“大使馆”

  • 4.4 数据存储和检索 (Data Storage and Retrieval)

    “Figure 4.4-1” 再次明确了ADRF的角色。它不仅仅是NWDAF的私有存储，而是网络中一个公共的分析数据存储库。任何授权的NF，都可以将数据存入ADRF或从中检索。这为实现跨NF、跨时间周期的复杂关联分析提供了可能。例如，SMF可以将某个区域的会话建立成功率存入ADRF，‘洞察者’在进行网络质量分析时，可以将SMF的数据与自己收集的无线侧数据进行关联，从而得出更深刻的结论。

  • 4.5 漫游架构 (Roaming architecture for data collection and analytics exposure)

    场景：为博览会的国际VIP提供漫游保障

    一位来自海外合作运营商“GlobalConnect”的VIP嘉宾正在使用AR导航。为了保证其体验，需要对其进行网络分析。但根据隐私法规，VIP的详细数据不能随意在运营商之间传递。

    “Figure 4.5-1” 定义的漫游架构解决了这个问题。它引入了RE-NWDAF (Roaming Exchange NWDAF)，可以看作是各自运营商部署在网络边界的“数据分析大使馆”。

    • V-PLMN (Visited PLMN)：VIP所在的“数智网联”网络。

    • H-PLMN (Home PLMN)：“GlobalConnect”网络。

    • V-RE-NWDAF：‘洞察者’系统中的漫游交换模块。

    • H-RE-NWDAF：“GlobalConnect”的漫游交换模块。

    交互流程可能是这样的：

    1. ‘洞察者’（通过V-RE-NWDAF）想了解该VIP是否订购了高级漫游服务。它不能直接查询H-PLMN的用户数据库UDM。

    2. 于是，它向“GlobalConnect”的H-RE-NWDAF发起一个高级别的分析请求，例如“请提供该用户的漫游服务等级分析”。

    3. H-RE-NWDAF在H-PLMN内部进行分析，并依据漫游协议和用户授权（这是关键，规范强调the H-RE-NWDAF is the enforcement point to check user consent），返回一个结果，如“该用户为白金漫游用户，请予以最高QoS保障”。

    通过这种方式，在不泄露底层敏感数据的前提下，实现了运营商之间的智能协同，共同保障了漫游用户的体验。

总结：奠定理解一切流程的基础

通过对TS 29.552规范前四章的深度解读，我们为后续的探索之旅构建了坚实的知识地基。

  • 我们通过第1-3章明确了规范的范围、依赖和语言，知道了‘洞察者’的职责边界，并掌握了与它沟通的基本词汇。

  • 我们通过第4章的参考架构，理解了‘洞察者’工作的核心逻辑闭环：通过灵活高效的“情报网”收集数据，在内部进行智能处理，再通过“指挥中心”将洞察转化为行动。我们还了解了它的“档案馆”（ADRF）和“大使馆”（RE-NWDAF）是如何支持长期学习和跨域协作的。

这个架构是理解后续所有信令流程的“地图”。当我们深入到第5章，看到Ndccf_DataManagement_Subscribe或Nnwdaf_EventsSubscription_Notify这样的具体服务调用时，我们将能够立刻将它们对应到这张“地图”上的相应位置，明白这次调用的发起者、接收者、目的以及它在整个智能闭环中所处的位置。

在下一篇文章中，我们将正式踏入规范的心脏地带——第5章，从5.1 General和5.2 Analytics Exposure Procedures开始，逐一剖析‘洞察者’是如何通过具体的“对话”（信令流程）来向外提供它宝贵的分析服务的。敬请期待！

FAQ 环节

Q1：为什么需要DCCF（数据收集协调功能）？让NWDAF直接与各个NF交互不是更简单吗？

A1：在简单的网络或分析场景中，NWDAF直接与NF交互确实可行。但随着网络规模和分析复杂度的增加，引入DCCF能带来巨大好处：

  1. 降低信令风暴风险：一个运营商可能部署多个NWDAF实例，分别用于不同的分析目的（如安全、切片、移动性）。如果没有DCCF，这些NWDAF可能会重复向同一个AMF订阅相同的数据，造成不必要的信令开销和AMF的性能压力。

  2. 解耦与灵活性：DCCF将数据消费者（NWDAF）和数据生产者（如AMF）解耦。NWDAF只需向DCCF表达“我需要什么数据”，而无需关心具体由哪个AMF实例提供。DCCF负责发现和选择最佳的数据源，这使得网络拓扑变化时，上层分析应用无需修改。

  3. 功能增强：DCCF可以提供一些增强功能，比如数据缓存、格式转换、数据预处理等，进一步为NWDAF减负。

因此，DCCF是实现大规模、高效、可扩展网络数据分析的关键优化组件。

Q2：缩略语中的AnLF（分析逻辑功能）和MTLF（模型训练逻辑功能）是什么关系？它们和NWDAF是什么关系？

A2：AnLF和MTLF可以理解为NWDAF内部的两个核心逻辑模块，共同构成了NWDAF的智能核心。

  • NWDAF 是一个完整的网络功能实体。

  • AnLF (Analytics Logical Function) 是NWDAF的“推理引擎”或“执行大脑”。它负责执行已经训练好的模型和分析算法，根据输入数据实时地生成分析结果。所有的NWDAF实例都必须具备AnLF。

  • MTLF (Model Training Logical Function) 是NWDAF的“学习引擎”或“训练中心”。它负责收集数据、训练、评估和更新机器学习模型。MTLF通常需要消耗大量的计算资源。因此，不是所有的NWDAF实例都需要具备MTLF。在实际部署中，可能只有少数几个中心的NWDAF具备MTLF，负责训练出全局模型，然后通过模型下发（Model Provisioning）流程，将模型分发给网络中只具备AnLF的、更轻量级的NWDAF实例去执行。

Q3：ADRF（分析数据仓库功能）和传统的大数据平台或数据湖有什么区别？

A3：ADRF在功能上与大数据平台有相似之处，都是用于数据存储和查询。但它的特殊性在于其原生于5G核心网架构：

  1. 标准化的服务接口：ADRF通过3GPP定义的Nadrf服务化接口与5G网元进行交互，所有接口的API、数据模型都是标准化的。这使得任何符合标准的NF（如NWDAF, DCCF）都可以无缝地与其集成，而传统的大数据平台通常使用私有或IT领域的接口，需要进行额外的适配开发。

  2. 为网络分析场景优化：ADRF的设计和要求会更多地考虑通信网络的特点，如对SUPI、GPSI等用户标识的处理，对TAI、Cell ID等网络位置信息的索引和查询优化，以及对用户数据隐私和安全性的严格要求。

  3. 生态系统集成：作为5G核心网的一员，ADRF可以被NRF注册和发现，其运维管理也可以被纳入统一的5G网络管理体系中。它不仅仅是一个IT系统，更是5G网络内生能力的一部分。

Q4：在漫游场景下，用户数据的隐私是如何保障的？V-PLMN的NWDAF能看到漫游用户的原始数据吗？

A4：漫游场景下的隐私保障是架构设计的重中之重。TS 29.552的漫游架构通过RE-NWDAF作为“网关”来严格控制信息交换的粒度。通常情况下，V-PLMN的NWDAF不能也无权获取漫游用户的原始、详细数据。交互遵循以下原则：

  1. H-PLMN主导：用户的归属网络（H-PLMN）是用户数据和策略的最终控制者。H-RE-NWDAF是检查用户是否同意共享分析信息的策略执行点。

  2. 分析结果交换而非原始数据交换：V-PLMN通常向H-PLMN请求的是高级别的“分析结果”或“洞察”，而非原始数据。例如，V-PLMN请求“该用户的业务偏好”，H-PLMN内部NWDAF分析后，可能只返回“偏好高清视频”这样一个标签，而不会返回用户的具体浏览历史。

  3. 协议约定：运营商之间的漫游协议会详细规定哪些类型的分析信息可以交换，交换的频率和条件是什么。

通过这种机制，既实现了保障漫游用户体验所需的智能协同，又最大限度地保护了用户的隐私。

Q5：TS 29.552规范的范围(Scope)中提到了很多NF接口，如Nsmf, Namf, Npcf。这种服务化接口的命名规则是什么？

A5：这是5G核心网服务化架构（SBA）的一套标准命名规则，理解它有助于快速识别接口的功能。命名格式通常是N<Producer NF Name>_<Service Name>。

  • N<Producer NF Name> 是接口的前缀，N代表“Network Function”，后面跟着提供服务的网络功能（Producer）的缩写。例如：

    • Nsmf: 由SMF提供的服务接口。

    • Namf: 由AMF提供的服务接口。

    • Npcf: 由PCF提供的服务接口。

    • Nnwdaf: 由NWDAF提供的服务接口。

  • <Service Name> 是具体的服务名称，描述了该服务的功能。例如：

    • Nsmf_EventExposure: SMF提供的事件暴露服务。

    • Nnwdaf_EventsSubscription: NWDAF提供的分析事件订阅服务。

因此，当NWDAF作为消费者，需要从SMF获取数据时，它会调用Nsmf_EventExposure服务。当PCF作为消费者，需要从NWDAF获取分析结果时，它会调用Nnwdaf_EventsSubscription服务。这套清晰的命名规则使得5G服务化接口的职责和关系一目了然。

关系图谱