51学通信

深度解析 3GPP TS 29.552：5.7.4 NF load Analytics (网络功能负载分析)

22分钟阅读

好的，我们继续对TS 29.552规范中特定分析流程的探索。在前文中，我们已经从“网络资源”（切片负载）和“用户体感”（业务体验）这两个宏观视角，审视了‘洞察者’(Insight-AI)的能力。现在，我们将把镜头拉近，聚焦于构成5G网络的基石——网络功能（NF）本身，看看‘洞察者’是如何扮演一位“系统健康监测师”，对它的“同事们”进行负载分析，确保整个核心网体系的稳定与高效。

深度解析 3GPP TS 29.552：5.7.4 NF load Analytics (网络功能负载分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.4 NF load Analytics”的核心章节，旨在为读者详细拆解NWDAF是如何监控、分析并预测单个或一组网络功能（NF）的负载状况，从而为智能化的网络运维和流量调度提供关键决策依据。

前言：5G网络的“亚健康”诊断

在云原生、服务化的5G核心网中，成百上千的网络功能（NF）实例像一个个高速运转的齿轮，相互协作，共同支撑着庞大的网络业务。任何一个“齿轮”（NF实例）如果出现“亚健康”状态——即负载过高，都可能引发连锁反应，导致业务时延增加、处理失败，甚至引发局部雪崩。

传统的监控系统或许能在NF的CPU使用率达到95%时发出告警，但那时往往为时已晚，业务质量已经受到了影响。5G的智能化运维追求的是更高境界：在负载达到临界点之前，就预测到趋势，并主动采取措施。

这正是‘洞察者’(Insight-AI)在“NF负载分析”场景下的核心价值。它不仅仅是看CPU、内存这些表面的资源指标，更是要深入理解NF的“业务负载”——它正在处理多少用户、多少会话、多大的流量？这些负载的增长趋势如何？

在今天的“未来科技博览会”场景中，远程手术和云游戏等高价值业务的SLA保障，高度依赖于一组关键的**UPF（用户面功能）**集群的性能。运营商的网络自动化平台（我们称之为“Auto-Ops”）作为‘洞察者’的客户，需要实时监控这组UPF集群的负载状况，以便在某个UPF实例即将过载时，能自动地将新的业务流量引导到其他空闲的实例上，实现智能的负载均衡。

本文将跟随“Auto-Ops”的视角，深入5.7.4节的信令流程，看看‘洞察者’是如何对UPF集群进行一次全面的“健康体检”和“未来趋势预测”的。

1. 任务简报：NF负载分析的目标与方法

这项分析任务的目标非常明确：为消费者提供一个或一组特定NF的当前及未来负载信息。

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

This procedure is used by the NWDAF service consumer (may be an NF, or the OAM) to obtain the NF load analytics which are calculated by the NWDAF based on the information collected from the NRF and/or the OAM, may also collect UE input data via the AF (for the untrusted AF via the NEF). If target NF type is UPF, the NWDAF may collect the information from UPF.

‘洞察者’总结道：“我的任务是诊断我的同事们（其他NF）是否‘压力山大’。我的诊断方法是‘望闻问切’，综合多种信息来源。”

  • 分析对象 (Target NF): 可以是任何类型的NF，如AMF, SMF, UPF等。可以指定单个NF实例，也可以指定一个NF Set或NF类型。

  • 核心情报来源:

    • NRF: 这是最关键的信息源之一。因为所有NF在注册时，都会向NRF上报自己的NF Profile，其中就包含了NF负载信息 (nfLoad)。NRF还支持NF状态的订阅，能实时通知负载变化。

    • OAM: 提供NF底层的、物理/虚拟资源的性能指标，如CPU、内存、网络IO等。

    • UPF自身: 对于UPF这类用户面网元，‘洞察者’还可以直接（或通过SMF）订阅其更精细的业务负载信息，如吞吐量、会话数等。

    • AF: 在某些特定场景，AF可以提供与NF负载相关的应用层信息，例如，一个视频AF可以告诉NWDAF：“我即将向某个UPF服务的区域推送一个超高清视频流”，这是一个非常有价值的负载预测输入。

  • 分析ID: NF_LOAD

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

规范中的 “Figure 5.7.4-1: Procedure for NF load Analytics” 描绘了‘洞察者’进行这次“健康体检”的详细流程。我们将这个流程分解为三个主要步骤。

阶段一：基础信息的收集与监控 (步骤1 - 5)

“Auto-Ops”向‘洞察者’发起订阅：“请持续监控UPF集群（由nfSetId标识）的负载。一旦预测任何实例的负载将超过80%，立刻通知我。”

步骤1a-1c：Auto-Ops发起订阅

“Auto-Ops”（作为消费者）通过Nnwdaf_AnalyticsInfo_Request或Nnwdaf_EventsSubscription_Subscribe发起请求，analyticsId为NF_LOAD，eventFilter中包含了目标NF的信息，如nfSetId = "UPF-Cluster-for-Expo"。

步骤2a-2b：从NRF获取初始“体检报告”

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

The NWDAF may invoke Nnrf_NFDiscovery_Request service operation…to obtain the initial NF profile which contains NF status and may contains NF load information.

‘洞察者’首先需要获取UPF集群的“初始健康快照”。

  • 动作: 向NRF发起Nnrf_NFDiscovery_Request请求。

  • 目的: 获取UPF集群中所有成员实例的NF Profile。每个Profile中都可能包含一个nfLoad字段，这是NF自身上报的负载百分比。这就像是获取了每个UPF的“自我感觉”。

步骤3：从OAM获取“体检硬指标”

规范原文引用 (Step 3):

The NWDAF may collect “Performance measurement” to the OAM to get the NF resource usage information…and/or may collect the NF resource configuration change information…

“自我感觉”可能不准，还需要客观的“生理指标”。

  • 动作: ‘洞察者’向OAM查询。

  • 目的: 获取UPF实例所部署的物理机或虚拟机的资源使用情况，如CPU利用率、内存占用、网络带宽等。这些是硬性的、底层的资源负载指标。

步骤4a-5b：向NRF建立“实时心电监护”

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

The NWDAF may invoke Nnrf_NFManagement_NFStatusSubscribe service operation…to subscribe to the NF status and/or NF load information.

获取了初始快照还不够，‘洞察者’需要持续监控负载变化。

  • 动作: 向NRF发起Nnrf_NFManagement_NFStatusSubscribe订阅。

  • 订阅内容: “请监控UPF集群中所有实例的状态和负载信息。一旦它们的nfLoad或nfStatus发生变化，立刻通知我。”

  • 信息流 (5a-5b): 当某个UPF实例因为业务量增加，自己更新了在NRF中的nfLoad值时，NRF会立刻通过_Notify通知‘洞察者’。这建立起了一个高效的、事件驱动的负载变化感知机制。

阶段二：特定NF的深度钻取 (步骤6 - 10，以UPF为例)

对于像UPF这样的关键NF，仅有NRF和OAM的宏观数据可能还不够精细。‘洞察者’需要深入其业务层面，进行更深度的“病理分析”。

步骤6：深入UPF业务负载

规范原文引用 (Step 6):

If the target NF type is UPF, the NWDAF may subscribe to collect traffic usage report information from UPF either via the SMF … or directly to the UPF…

‘洞察者’可以通过两种方式获取UPF的精细业务负载：

  1. 通过SMF代理 (6a1-6a4): ‘洞察者’向管理该UPF的SMF发起订阅，SMF再通过N4接口配置UPF进行流量上报。

  2. 直接向UPF订阅 (6b1-6b2): 如果UPF支持，‘洞察者’可以直接调用其Nupf_EventExposure_Subscribe服务。

  • 订阅内容: 请求UPF上报更细粒度的业务指标，例如：

    • 总吞吐量 (Throughput)

    • 数据包速率 (Packet Rate)

    • 活跃PDU会话数 (Number of PDU Sessions)

  • UPF上报 (6c1-6c2): UPF会周期性地或在满足阈值时，通过_Notify向‘洞察者’上报这些详细的业务负载指标。

步骤7-10：融合应用层意图 (AF)

‘洞察者’还可以引入一个非常强大的预测输入——应用层的先验信息。

  • 动作: 向相关的AF（如视频平台、云游戏平台）发起Naf_EventExposure_Subscribe订阅。

  • 订阅内容: “请上报你的‘用户集体行为’(Collective Behaviour of UEs)信息。”

  • 信息流 (7a-10d): 例如，视频AF可以通知‘洞察者’：“在接下来的5分钟内，我预计将有1000个用户在博览会区域请求4K视频流。” 这个信息对于预测UPF的流量负载激增，具有极高的价值。

阶段三：分析计算与决策支持 (步骤11 - 19)

规范原文引用 (Step 11):

The NWDAF calculates the NF load analytics based on the data collected from NRF, OAM, UPF and/or AF.

‘洞察者’汇集了所有情报：NRF上报的nfLoad（NF的“主观感受”）、OAM上报的资源利用率（“客观生理指标”）、UPF上报的业务数据（“工作量清单”）以及AF上报的未来业务意图（“未来工作计划”）。

  1. 分析计算 (Step 11): ‘洞察者’的AnLF将这些多维数据输入其“NF负载预测模型”。该模型不仅能评估当前负载，更能基于历史趋势和AF的意图信息，预测未来的负载曲线。

    • 模型输出: “UPF-instance-3的当前综合负载为75%，预计在5分钟后，由于视频业务高峰，负载将达到92%。”

  2. 交付预警 (Step 12 & 19): ‘洞察者’立刻通过Nnwdaf_EventsSubscription_Notify服务，向“Auto-Ops”平台发送预警。

闭环完成：“Auto-Ops”收到预警后，立即触发自动化工作流：

  1. 它向SMF发送指令，要求后续新建的PDU会话，不再分配给即将过载的UPF-instance-3。

  2. 它甚至可以主动触发部分非实时业务（如后台下载）的PDU会话，从UPF-instance-3平滑地重定位到其他空闲的UPF实例上。

通过这个智能的预测与调度闭环，成功地避免了UPF-instance-3的过载，保障了博览会所有业务的稳定性，实现了真正意义上的自动化、预测性网络运维。

总结：从被动监控到主动治理

5.7.4节的NF负载分析流程，是NWDAF赋能网络自动化的一个典型范例。它深刻地体现了从传统运维到智能化运维的转变：

  • 信息维度的转变：从单一依赖OAM的底层资源指标，转变为**融合控制面（NRF）、管理面（OAM）、用户面（UPF）和应用层（AF）**的多维数据视图，分析更全面、更贴近业务。

  • 分析能力的转变：从简单的“阈值告警”（负载已经超过90%），转变为基于趋势和意图的预测性分析（负载将要超过80%），为主动干预赢得了宝贵的时间窗口。

  • 运维模式的转变：分析结果不再仅仅是发给运维人员的一封告警邮件，而是可以被自动化平台（如编排器、SDN控制器）直接消费的、结构化的API响应。这打通了“分析-决策-执行”的自动化闭环，是实现“零接触运维 (Zero-touch)”的关键环节。

通过为网络中的每一个功能单元（NF）配备一位“AI健康顾问”，NWDAF确保了整个5G云原生网络的健壮性和弹性，使其能够从容应对动态、复杂的业务挑战。

在下一篇文章中，我们将继续沿着5.7节的探索之路，转向另一个关键的分析领域——5.7.5 Network Performance Analytics (网络性能分析)，看看‘洞察者’是如何从一个更宏观的视角，去度量一个区域或全网的整体性能健康度的。

FAQ 环节

Q1：NF自己上报的负载（nfLoad in NRF）和NWDAF计算的负载，哪个更准？

A1：两者各有侧重，互为补充。

  • NF自报负载 (nfLoad): 是NF内部根据其自身关键处理资源的占用情况（如CPU、会话容量、TPS等）计算得出的一个综合值。它最了解自己的核心瓶颈，但可能无法感知到外部环境的变化。

  • NWDAF计算的负载: 是一个更宏观、更具预测性的分析结果。NWDAF不仅考虑NF的自报值，还融合了OAM的底层资源数据、历史负载趋势、甚至未来可预见的业务请求（来自AF）等外部信息。因此，NWDAF的分析结果，特别是在预测未来负载方面，通常比NF的瞬时自报值更有价值。

Q2：对于AMF或SMF这类信令处理型的NF，NWDAF会关注哪些负载指标？

A2：对于AMF/SMF这类NF，‘洞察者’关注的“工作量”主要体现在信令处理上。除了通用的CPU/内存指标，NWDAF会重点收集和分析以下业务负载指标：

  • For AMF:

    • 注册用户数 (Number of registered UEs)

    • PDU会话数 (Number of PDU sessions)

    • 信令速率 (e.g., Registrations per second, Service Requests per second)

  • For SMF:

    • 活跃PDU会话数 (Number of active PDU sessions)

    • 会话建立/释放速率 (Session establishment rate)

    • 与UPF的N4会话数

通过对这些指标的趋势分析，NWDAF可以预测AMF或SMF何时可能达到其信令处理能力的瓶颈。

Q3：流程图中提到了AF可以提供“用户集体行为”信息，这在现实中是如何实现的？

A3：这是一个非常强大且具有前瞻性的功能。现实中，大型内容提供商或应用服务商（如视频网站、云游戏平台）通常对自己平台的用户行为有很强的预测能力。例如：

  • 热点事件：一场重要的体育赛事直播即将开始，视频平台可以提前通过Naf_EventExposure接口通知运营商的NWDAF：“预计在晚上8点，北京区域将有百万级用户请求观看高清直播流。”

  • 软件更新：一个流行的App计划在凌晨2点向大量用户推送一个大型更新包。

这些“应用层意图”信息，对于网络侧进行负载预测和资源准备是“金矿”般的数据。通过标准化的接口将这些信息提供给NWDAF，实现了应用与网络的智能协同。

Q4：如果一个NF实例（如UPF-3）发生故障，而不是过载，这个流程能感知到吗？

A4：是的，这个流程完全可以感知到NF故障。这主要通过步骤4a-5b，即向NRF订阅NF状态变更来实现。

  • 心跳机制：每个NF实例都需要定期向NRF发送“心跳”消息来更新自己的状态（NFHeartBeat）。

  • 故障检测：如果NRF在一段时间内没有收到UPF-3的心跳，它会将其状态标记为UNAVAILABLE或SUSPENDED。

  • 状态通知：由于‘洞察者’已经订阅了UPF集群的状态变更，NRF会立刻向‘洞察者’发送一个_Notify通知，告知“UPF-3状态变更为UNAVAILABLE”。

‘洞察者’收到这个故障通知后，可以立即在其分析结果中将UPF-3标记为不可用，并通知“Auto-Ops”平台隔离该故障实例。

Q5：NF负载分析的结果，除了用于负载均衡，还有其他用途吗？

A5：NF负载分析是一个基础性的、非常有价值的分析能力，其结果用途广泛：

  • 容量规划与预测：通过分析长期的负载增长趋势，可以为网络的扩容和升级提供精确的数据支持。

  • 智能节能：在业务低谷期，如果NWDAF预测到一组NF的负载将持续处于低位，可以通知编排器将部分NF实例缩容或置于休眠状态，以节省能源。

  • 网络切片资源管理：NF负载是计算切片负载的重要输入之一。一个切片的负载，是其组成的所有NF实例负载的综合体现。

  • 根因分析：当业务出现问题时，NF负载分析结果可以帮助快速定位瓶颈是在无线侧、传输侧还是核心网的某个NF上。

关系图谱