51学通信

深度解析 3GPP TS 29.552：5.7.2 Network Slice (Instance) load level Analytics (网络切片实例负载水平分析)

25分钟阅读

好的，我们正式开启对TS 29.552规范核心能力——特定网络数据分析流程的逐一解构。在前一系列文章中，我们已经为‘洞察者’(Insight-AI)构建了其工作的完整框架。现在，是时候深入它的“日常工作”，看看它是如何完成一项项具体的分析任务，为5G网络注入智慧的。

我们将从5G最核心的商业价值之一——网络切片开始。

深度解析 3GPP TS 29.552：5.7.2 Network Slice (Instance) load level Analytics (网络切片实例负载水平分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.2 Network Slice (Instance) load level Analytics”的核心章节，旨在为读者详细拆解NWDAF是如何像一位精准的“资源审计师”，对网络切片的负载水平进行度量、分析与预测的。

前言：守护5G的生命线——网络切片

网络切片被誉为5G赋能垂直行业、实现商业变现的“杀手锏”。通过将一个物理网络切分为多个具有不同SLA（服务等级协议）保障的、逻辑上相互隔离的虚拟网络，运营商可以为自动驾驶、远程医疗、智能电网等多样化场景提供定制化的“专属高速公路”。

然而，这条“高速公路”是否通畅？是否即将拥堵？能否持续满足客户严苛的SLA承诺？这些问题，需要一个超越传统监控的、更具洞察力和预测能力的“交通指挥中心”来回答。这，正是‘洞察者’(Insight-AI)在网络切片场景下的核心使命。

在今天的“未来科技博览会”场景中，我们将聚焦于一项万众瞩目的、极具未来感的展示——“跨国远程手术”。为了确保手术过程中机器人手臂控制信号的极致低时延和视频画面的超高可靠性，运营商“数智网联”专门为其开通了一条名为**“UrgentCare-Slice”**的URLLC网络切片实例。

负责保障这条“生命线”的，是运营商的网络切片管理与编排系统，我们称之为**“SliceGuardian”。它的职责不仅仅是在故障发生后进行补救，更是在拥塞或性能下降发生之前**就进行预警和干预。为了获得这种“未卜先知”的能力，“SliceGuardian”将向‘洞察者’求助，请求对“UrgentCare-Slice”进行实时的负载水平分析。

本文将跟随“SliceGuardian”的视角，深入5.7.2节的信令流程，看看‘洞察者’是如何一步步收集情报、进行分析，并最终给出的那份至关重要的“切片健康度报告”的。

1. 任务简报：切片负载分析的目标与范畴

在深入具体的信令流程之前，我们首先要明确这项分析任务的目标是什么。

规范原文引用 (Clause 5.7.2 Introduction):

This procedure is used by the NF to obtain the network slice (instance) load level analytics which are calculated by the NWDAF based on the information collected from the NSACF, NRF, AMF, SMF and/or OAM. If the NF is an AF which is untrusted, the AF will request analytics via the NEF as described in clause 5.2.3.2.

‘洞察者’解读道：“我的任务很明确：通过向我的各位‘情报员’——NSACF、NRF、AMF、SMF和OAM——收集信息，为客户（如‘SliceGuardian’）计算出它所关心的特定网络切片或切片实例的负载水平。”

这段话的核心要点是：

  • 分析对象：网络切片 (Network Slice) 或更具体的网络切片实例 (Network Slice Instance)。一个切片（由S-NSSAI标识）可能在一个区域内有多个实例（由NSI ID标识）。

  • 情报来源：这份分析报告不是凭空产生的，它需要综合来自多个网元的数据。这凸显了NWDAF作为数据融合中心的价值。

  • 消费者：可以是任何NF（网络功能），例如负责切片管理的NSMF（网络切片管理功能）或高层编排器。

在信令层面，这项分析任务对应两个具体的分析ID (Analytics ID)：

  • LOAD_LEVEL_INFORMATION: 一个更通用的负载信息分析，可以用于NF负载、小区负载等，也包括了切片负载。

  • NSI_LOAD_LEVEL: 一个更专用、更精确的分析ID，专门用于获取网络切片实例的负载水平。

对于“UrgentCare-Slice”这个具体实例，‘SliceGuardian’显然会请求NSI_LOAD_LEVEL分析。

2. 行动方案：解构切片负载分析的信令全流程

现在，我们进入本节的核心——详细的信令流程。规范中的 “Figure 5.7.2-1: Procedure for Network Slice (Instance) load level Analytics” 为我们描绘了‘洞察者’完成这项任务的完整作战地图。我们将这个复杂的流程分解为三个阶段。

阶段一：任务下达与“作战地图”绘制 (步骤1 - 5)

在这一阶段，“SliceGuardian”下达任务，‘洞察者’首先要做的不是收集数据，而是弄清楚“UrgentCare-Slice”到底是由哪些“部队”（网络功能NF）组成的。

步骤1a-1c：SliceGuardian发起请求

‘SliceGuardian’向‘洞察者’发起了订阅请求：“请持续监控‘UrgentCare-Slice’（由S-NSSAI标识）的负载水平，一旦预测负载超过70%，立刻通知我。”

  • 1a (请求/响应)：如果是为了获取一次性的瞬时负载，‘SliceGuardian’会调用Nnwdaf_AnalyticsInfo_Request服务 (HTTP GET)。

  • 1b-1c (订阅/通知)：对于需要持续监控的远程手术场景，‘SliceGuardian’会调用Nnwdaf_EventsSubscription_Subscribe服务 (HTTP POST)，发起一个长期订阅。

步骤2a-2b：发现组成切片的NF

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

If the event is set to “LOAD_LEVEL_INFORMATION” or “NSI_LOAD_LEVEL”, the NWDAF invokes Nnrf_NFDiscovery_Request service operation…to discover the AMF, SMF and NSSF instance(s) relevant to the analytics filters provided in the subscription request.

‘洞察者’收到了关于“UrgentCare-Slice”的S-NSSAI。但它不知道具体是哪些AMF、SMF在为这个切片服务。于是，它向“网络户籍警官”——NRF发起了Nnrf_NFDiscovery_Request查询。

  • 查询条件：supportedSnssai = "S-NSSAI-of-UrgentCare-Slice"。

  • 查询结果：NRF返回了所有在其“户籍库”中注册过、声称自己支持该切片的AMF、SMF和NSSF的实例列表。

步骤3a-3b (可选)：从S-NSSAI到NSI ID的转换

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

(Only for “NSI_LOAD_LEVEL”) The NWDAF may invoke Nnssf_NSSelection_Get service operation…to obtain the NSI ID(s) corresponding to the S-NSSAI in the subscription request.

S-NSSAI定义了切片的“类型”，而NSI ID才是切片的“实体”。一个切片类型可能对应多个实体。为了获得更精确的负载，‘洞察者’需要知道它到底应该监控哪个实体。于是，它向**NSSF（网络切片选择功能）**求助。

  • 动作：调用Nnssf_NSSelection_Get服务。

  • 目的：将S-NSSAI映射到具体的NSI ID。NSSF会返回当前服务于该区域、该S-NSSAI的NSI ID。

步骤4a-5b：订阅NF状态变更

在绘制完“作战地图”（知道了切片由哪些NF组成）后，‘洞察者’做了一个非常智能的动作：它向NRF发起了Nnrf_NFManagement_NFStatusSubscribe订阅。

  • 订阅内容：“请监控我刚才发现的那些AMF和SMF的状态。如果它们中的任何一个变得过载、不可用，或者它们的资源使用情况发生了显著变化，请立刻通知我。”

  • 目的：这是一种主动的、事件驱动的监控。‘洞察者’无需再频繁轮询这些NF的状态，而是由NRF在状态变更时主动通知它。这大大提升了分析的实时性和效率。

至此，第一阶段完成。‘洞察者’已经清晰地掌握了“UrgentCare-Slice”的构成，并对这些组成部分的健康状况建立了主动监控。

阶段二：多源情报深度收集 (步骤6 - 12)

在这一阶段，‘洞察者’开始向各个“情报源”深入挖掘具体的负载数据。

步骤6a-7b：向AMF收集用户信息

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

The NWDAF may invoke Namf_EventExposure_Subscribe service operation…to subscribe to the notification of individual UE registration/deregistration registered to an S-NSSAI or to an S-NSSAI and NSI ID, or request the total number of UEs served by the AMF per S-NSSAI…

负载的一个关键维度是“用户数”。‘洞察者’向组成切片的每个AMF发起Namf_EventExposure_Subscribe订阅。

  • 订阅内容：“请告诉我，当前有多少个UE注册到了‘UrgentCare-Slice’上？并且，每当有新的UE注册上来，或有UE离开时，都请通知我。”

  • AMF响应 (7a-7b)：AMF会持续地上报该切片上的UE数量或变更事件。对于我们的场景，这意味着‘洞察者’可以实时知道有多少医疗设备（UE）正连接在这条生命线上。

步骤8a-9b：向SMF收集会话信息

负载的另一个关键维度是“业务会话数”。‘洞察者’向组成切片的每个SMF发起Nsmf_EventExposure_Subscribe订阅。

  • 订阅内容：“请告诉我，当前在‘UrgentCare-Slice’上建立了多少个PDU会话？并且，每当有会话建立或释放时，都请通知我。”

  • SMF响应 (9a-9b)：SMF会持续上报该切片上的PDU会话数量。对于远程手术，这可能意味着控制信令、高清视频、生命体征监测等多条并行的PDU会话。

步骤10：向OAM收集性能数据

规范原文引用 (Step 10):

The NWDAF may collect “Performance measurement” to the OAM to get the mean number of UEs registered…, mean number of PDU sessions established… and/or the resource usage information of a network slice instance…

‘洞察者’还会求助于“老大哥”——OAM（运维管理系统）。OAM拥有最全面的网络性能数据。

  • 收集内容：通过标准的管理接口（如NetConf/YANG），‘洞察者’可以从OAM获取更宏观、更底层的性能指标，例如：

    • 无线资源使用率：该切片占用的PRB（物理资源块）比例。

    • 吞吐量：该切片上的总上/下行吞吐量。

    • 时延/丢包率等KPI。

步骤11a-12b：向NSACF收集准入信息

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

The NWDAF may invoke Nnsacf_SliceEventExposure_Subscribe service operation…to request the number of UEs registered to the network slice and/or the number of PDU sessions established to the network slice.

负载水平是一个相对值（百分比），不仅需要知道“当前用了多少”，还需要知道“总共有多少”。这个“总容量”信息，最权威的来源是NSACF（网络切片准入控制功能）。

  • 订阅内容：‘洞察者’向NSACF发起Nnsacf_SliceEventExposure_Subscribe订阅，询问：“‘UrgentCare-Slice’当前已准入的用户数/会话数是多少？”

  • NSACF的作用：NSACF负责在UE请求接入切片时进行准入控制，它最清楚切片的总容量（例如，最多允许100个UE接入）和当前已使用的配额。

阶段三：分析计算与结果交付 (步骤13 - 21)

在收集了来自AMF、SMF、OAM、NSACF等多个维度的“情报”后，‘洞察者’终于凑齐了所有的“拼图”。

步骤13 & 20：负载计算

规范原文引用 (Step 13):

The NWDAF calculates the network slice (instance) load level analytics based on the data collected from AMF, SMF, NRF, NSACF and/or OAM.

这是“魔法发生”的时刻。‘洞察者’的AnLF（分析逻辑功能）开始工作：

  1. 数据融合：将UE数、会话数、资源使用率、准入容量等多个指标进行融合。

  2. 模型计算：将融合后的数据输入其内置的负载分析与预测模型。这个模型可能是一个简单的加权平均算法，也可能是一个复杂的基于时间序列预测的深度学习模型。

  3. 生成结果：模型输出最终的分析结果。这份“切片健康度报告”可能包含：

    • currentLoadLevel: 当前负载百分比，例如65。

    • predictedLoadLevel (可选): 未来（如15分钟后）的预测负载，例如85。

    • loadLevelStatus: 一个定性的描述，如"MEDIUM"或"HIGH"。

步骤14 & 21：交付报告

‘洞察者’的计算结果是：预测15分钟后，由于隔壁展台的大流量演示可能会对共享的无线资源造成冲击，“UrgentCare-Slice”的负载将达到85%，有潜在的性能抖动风险！

  • 14a/21a-21b (订阅场景)：‘洞察者’立刻通过Nnwdaf_EventsSubscription_Notify服务，向“SliceGuardian”发送通知，交付这份包含预警的分析报告。

  • 14b/21c (请求场景)：如果是一次性请求，‘洞察者’则通过Nnwdaf_AnalyticsInfo_Request的响应消息返回结果。

闭环完成：“SliceGuardian”收到预警后，立即采取行动。例如，它可以通过编排系统，为“UrgentCare-Slice”预留更多的专用无线资源，或者将隔壁展台的非关键业务进行适当限速，从而成功地将一次潜在的网络风险扼杀在摇篮里，保障了远程手术的绝对成功。

总结：从数据孤岛到智能融合

通过对5.7.2节切片负载分析流程的深度剖析，我们看到了NWDAF如何扮演一个跨领域的数据融合与智能分析中心的角色，其价值体现在：

  • 打破数据壁垒：为了计算一个小小的“负载水平”，NWDAF需要与AMF（用户面）、SMF（会话面）、OAM（资源面）、NSACF（准入面）、NRF/NSSF（管理面）等几乎所有相关的网元进行对话。它打破了传统网元之间的数据孤岛，形成了一个全局的、统一的视图。

  • 实现主动预测：NWDAF提供的不仅仅是“当前负载是65%”这样的历史数据，更重要的是“15分钟后负载将达到85%”这样的预测性洞察。这使得网络管理从被动的、事后的响应，转变为主动的、事前的干预，是实现网络自动化的关键一步。

  • 流程标准化：TS 29.552为这个复杂的多源数据融合分析过程，定义了一套清晰、标准化的信令流程。这使得不同厂商的NWDAF和NF设备能够互联互通，共同构建一个开放、协作的智能网络生态。

切片负载分析，只是‘洞察者’众多能力中的一个。但通过这“一叶”，我们足以窥见5G网络内生智能的“全豹”。在接下来的文章中，我们将继续探索5.7节中的其他分析类型，看看‘洞察者’是如何在更多维度上施展它的智慧的。

FAQ 环节

Q1：负载水平（Load Level）具体是如何定义的？是一个百分比吗？

A1：是的，负载水平通常表示为一种相对值，最直观的就是百分比。它可以是基于多种资源的负载综合计算得出的：

  • 用户数负载：当前注册用户数 / NSACF允许的最大用户数。

  • 会话数负载：当前PDU会话数 / NSACF允许的最大会话数。

  • 资源负载：当前占用的无线/传输/计算资源 / 为该切片分配的总资源。

NWDAF的实现可以根据运营商的策略，对这些不同维度的负载进行加权平均，得出一个综合的负载水平指数。最终输出给消费者的，可能是一个0-100的整数，也可能是一个枚举值（如：LOW, MEDIUM, HIGH, OVERLOADED）。

Q2：NSACF和OAM都提供资源信息，它们有什么区别？NWDAF为什么两者都需要？

A2：NSACF和OAM提供了不同层面、不同视角的信息，两者互为补充。

  • NSACF (网络切片准入控制功能)：它工作在准入控制层面，更关心“配额”和“计数”。它知道一个切片的“名义容量”（例如，被配置为最多支持1000个用户），以及当前已经“放”进来了多少用户。它的数据是离散的、基于计数的。

  • OAM (运维管理系统)：它工作在性能监控层面，更关心“实际物理资源的使用情况”。它知道无线小区的PRB利用率、UPF的CPU负载、传输链路的带宽占用等。它的数据是连续的、基于物理度量的。

NWDAF需要两者：NSACF的数据用于计算基于“配额”的负载，而OAM的数据用于计算基于“实际物理资源消耗”的负载。将两者结合，可以得到更全面、更准确的切片健康度画像。

Q3：为什么流程中需要NSSF（网络切片选择功能）？AMF不能直接处理S-NSSAI吗？

A3：AMF能够根据S-NSSAI选择一个切片，但在某些复杂场景下，需要NSSF的帮助来获取更精确的信息，特别是在分析场景中。

  • S-NSSAI到NSI ID的映射：一个S-NSSAI（如“URLLC切片”）在网络中可能被实例化为多个不同的NSI（网络切片实例），例如，一个用于远程医疗，一个用于车联网，它们可能共享部分资源但有不同的策略。NSSF是维护这种映射关系的全网权威。NWDAF为了分析特定实例的负载，就需要通过NSSF来找到正确的NSI ID。

  • 跨域选择：在更复杂的网络中，NSSF还负责跨多个AMF区域的切片选择和映射。

因此，引入NSSF可以使切片实例的选择和分析更加精准和解耦。

Q4：这个流程看起来信令交互非常多，会不会给网络带来很大的额外负担？

A4：这是一个很好的问题，也是架构设计时必须考虑的。规范通过以下几种方式来减轻信令负担：

  1. 订阅/通知模式：绝大多数交互都采用了“订阅一次，持续通知”的模式，而不是频繁的轮询。只有在状态变更时才会产生信令。

  2. 聚合与过滤：NWDAF向NF发起订阅时，可以指定精确的过滤器（如只关心某个切片），NF只需上报匹配的数据。

  3. 信息聚合：NF（如AMF）可以上报聚合后的信息（如“总用户数”），而不是每个用户的独立事件，大大减少了通知的数量。

  4. DCCF协调：虽然本节流程未画出DCCF，但在实际部署中，DCCF可以被引入，来聚合多个NWDAF对同一份数据的订阅请求。

通过这些机制，可以将信令开销控制在合理的范围内。

Q5：如果一个切片横跨了多个AMF区域，NWDAF如何处理？

A5：这正是NWDAF作为中心化分析平台的优势所在。在这种情况下：

  1. 多源发现：NWDAF在步骤2a-2b向NRF查询时，NRF会返回所有服务于该切片S-NSSAI的AMF实例列表，这些AMF可能分布在不同的区域。

  2. 并行收集：NWDAF会并行地向所有这些AMF发起数据收集订阅。

  3. 中心化聚合：NWDAF在其内部，会将从多个AMF收集来的用户数、会话数等数据进行聚合，得出一个跨区域的总负载。

这个过程对最终的消费者（如‘SliceGuardian’）是透明的。它看到的只是一个总的负载值，而无需关心这个值是由多少个AMF的数据汇总而来的。这再次体现了NWDAF打破数据孤岛、提供全局视图的核心价值。

关系图谱