51学通信

深度解析 3GPP TS 28.552：5.7 & 6.2 Common Measurements for NFs (5G云化网络的“X光片”与“核磁共振”)

18分钟阅读

好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 28.552：5.7 & 6.2 Common Measurements for NFs (5G云化网络的“X光片”与“核磁共振”)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.7 Common performance measurements for NFs”和“6.2 Virtualised resource usage measurement”的核心章节，旨在为读者提供一个关于5G云化网络基础设施性能测量的全景解析。

引言：一次“云”里雾里的性能劣化

“王哥，太诡异了！”小林指着一张性能曲线图，满脸写着不可思议，“市中心区域的AMF，昨晚突然出现大面积的用户注册时延增加、成功率下降。但我们查了所有AMF的应用层测量（5.2节），它的请求处理数、会话数都远没到瓶颈。信令追踪也显示，AMF与gNB、UDM之间的交互没有异常。这就像一个运动员，心肺功能（应用性能）明明很正常，但就是跑不快，好像被什么无形的东西拖住了后腿。”

老王看着曲线图，若有所思地问：“小林，你忘了我们现在的AMF，已经不是当年机房里那台看得见摸得着的物理盒子了。它现在是什么？”

“是……运行在云平台上的VNF（虚拟化网络功能）。”小林回答。

“这就对了！”老王在架构图上，AMF下面画出了一层——NFVI (Network Functions Virtualisation Infrastructure, 网络功能虚拟化基础设施)。“我们之前的所有测量，都是在给运动员的‘心肺功能’做检查。但我们忽略了支撑他跑步的‘骨骼肌肉’和‘能量供给’——也就是承载AMF运行的虚拟资源（VR）：vCPU、vMemory、vDisk，以及连接它们的虚拟网络。如果‘骨骼’出了问题，运动员跑不快，不是很正常吗？”

他将TS 28.552切换到5.7和6.2节。“‘Common performance measurements for NFs’和‘Virtualised resource usage measurement’，这两节就是我们为5G云化网络量身打造的‘X光片’和‘核磁共振’。它们不再关心NF的应用逻辑，而是深入底层，去透视支撑NF运行的虚拟化基础设施的健康状况。今天，我们就来学习如何通过这些‘医学影像’技术，去发现那些隐藏在‘云’里雾里的性能根因。”

1. 网络的“物理连接”：Connection data volumes of NF (5.7.2)

在深入虚拟化层之前，我们先来看一个适用于所有NF（无论物理还是虚拟）的通用测量——连接数据量。它衡量的是一个NF与外界“沟通”的总量。

5.7.2.1 Data volume of incoming bytes (DataVolum.InBytes) 5.7.2.2 Data volume of outgoing bytes (DataVolum.OutBytes) 5.7.2.3 Data volume of incoming packets (DataVolum.InPackets) 5.7.2.4 Data volume of Outgoing packets (DataVolum.OutPackets)

  • 深度解析: DataVolum...这一组测量，是从NF的网络接口层面，统计其输入和输出的总字节数和总包数。

    • Bytes (字节数): 反映了NF的网络接口带宽负载 (bps)。
    • Packets (包数): 反映了NF的网络接口处理负载 (pps)。
    • 适用范围: 规范指出，这组测量适用于f)中列出的几乎所有gNB和5GC的NF。

  • 场景化应用：识别流量异常与DDoS攻击 这些基础流量统计，是网络监控的“第一道防线”。

    • 容量监控: 通过监控AMF的DataVolum.InPackets，可以了解其信令交互的繁忙程度。如果pps持续接近其虚拟网卡（vNIC）的处理上限，就可能导致信令丢包。
    • 异常检测: 如果一个平时流量很小的NF（如NSSF），其DataVolum.InPackets突然在短时间内暴增，这可能预示着网络中存在信令风暴，甚至是遭受了DDoS（分布式拒绝服务）攻击。

2. 虚拟化资源的“X光片”：VR usage of NF (5.7.1 & 6.2)

这是诊断云化网络性能问题的核心工具。规范通过5.7.1 VR usage of NF 和 6.2 Virtualised resource usage measurement两节，从不同角度定义了对虚拟化资源（VR）的测量。

(注：5.7.1节更侧重于单个NF的VR使用情况，而6.2节则引入了.sum后缀，侧重于网络切片实例中所有NF的VR使用量的加权平均。两者原理相通，我们在此合并解读。)

5.7.1.1.1 Mean virtual CPU usage (VR.VCpuUsageMean) a) This measurement provides the mean usage of the underlying virtualized CPUs for a virtualized 3GPP NF. c) The measurement job control service producer for NF(s) receives the VcpuUsageMeanVnf.vComputeId measurement(s) (see ETSI GS IFA 027) for the VNFC instances(s) from VNFM…

5.7.1.2.1 Mean virtual memory usage (VR.VMemoryUsageMean) 5.7.1.3.1 Mean virtual disk usage (VR.VDiskUsageMean)

2.1 深度解析

这组VR... (Virtual Resource) 测量，直接反映了支撑一个VNF运行的三大虚拟资源的消耗情况。

  • 数据来源 (c项): 规范明确指出，这些测量的数据，来源于VNFM (VNF Manager)。VNFM是云管理平台（如OpenStack）的一部分，它负责VNF的生命周期管理，并能从底层Hypervisor获取到每个虚拟机（VM）或容器（Container）的资源使用情况。3GPP通过引用ETSI NFV的标准（如IFA 027），将云平台的监控能力，无缝地集成到了电信网络的性能管理体系中。

  • VR.VCpuUsageMean (虚拟CPU平均使用率): 这是最核心的虚拟资源指标。它衡量了一个VNF所分配到的vCPU资源的繁忙程度。如果vCPU使用率持续过高（如超过80%），VNF的任何应用处理都会变慢，表现为时延增加、处理能力下降。

  • VR.VMemoryUsageMean (虚拟内存平均使用率): 衡量VNF的内存消耗情况。如果内存使用率过高，可能会导致系统频繁进行内存交换（swap），严重影响性能；如果内存耗尽，则可能导致VNF进程崩溃。

  • VR.VDiskUsageMean (虚拟磁盘平均使用率): 衡量VNF用于日志、缓存等目的的存储空间使用情况。

2.2 场景化诊断：“隐形”的CPU瓶颈

回到开头的案例，小林立刻调取了昨晚故障时段AMF实例的VR.VCpuUsageMean数据。

“王哥，找到了！你看！”小林指着一条飙升到98%的红色曲线，“在用户注册时延增加的同一时间，这台AMF虚机的vCPU使用率几乎被打满了！虽然它的应用层没有过载，但它已经没有足够的‘算力’来处理新的请求了！”

洞察与行动： 这个案例完美地展示了虚拟资源测量的威力。VR.VCpuUsageMean就像一张“X光片”，清晰地照出了AMF“跑不快”的根本原因——底层计算资源耗尽。 问题根源被定位后，解决方案也变得清晰：

  1. 垂直扩容 (Scale-up): 为这台AMF虚拟机分配更多的vCPU核心。
  2. 水平扩容 (Scale-out): 新启动一个AMF虚拟机实例，并通过AMF池化的方式进行负载分担。
  3. 根因分析: 为什么CPU会耗尽？是正常的业务高峰，还是AMF的软件版本存在CPU异常消耗的缺陷？亦或是该虚机所在的物理主机上，有其他“邻居”虚机（“吵闹的邻居”问题）在抢占CPU资源？

3. 切片级的“核磁共振”：Virtualised resource usage measurement for S-NSSAI (6.2)

6.2节将虚拟资源测量提升到了一个新的高度——网络切片。

a) This measurement provides the mean usage of virtualised resource (e.g. processor, memory, disk) in single network slice instance during the granularity period. c) This measurement is generated with .sum suffix for the usage of each virtualised NF … related to single network slice instance by taking the weighted average. e) MeanProcessorUsage, MeanMemoryUsage, MeanDiskUsage

  • 深度解析: 这组测量，其名称虽然没有明确的SNSSAI后缀，但其定义中明确指出是“in single network slice instance”。它通过对属于同一个网络切片实例的所有VNF的VR.VCpuUsageMean等指标，进行加权平均，从而得出一个能够代表该切片整体虚拟资源消耗的指标。

  • 场景化应用：切片资源隔离与保障 运营商为智慧交通项目提供了一个uRLLC切片，为其分配了专属的、隔离的虚拟资源池。

    • 通过监控这个切片的MeanProcessorUsage，可以实时了解该切片所分配的vCPU资源池的整体负载情况。
    • 如果该指标持续很低，说明资源分配过多，造成了浪费。
    • 如果该指标持续很高，则说明该切片的资源池需要扩容，否则将无法满足低时延、高可靠的SLA要求。 这个测量项，是从基础设施层面，对网络切片的资源隔离性和SLA保障能力进行的一次“核磁共振”检查，确保了为VIP客户预留的“专属病房”，其内部的“氧气、电力”等基础设施供应是充足的。

结论：云化运维的“透视眼”

通过对5.7和6.2节的学习，我们掌握了诊断和评估5G云化网络基础设施性能的“透视眼”。

  1. 流量监控 (DataVolum): 提供了对NF外部交互的宏观画像，是网络流量异常检测和安全审计的“警报器”。
  2. 单NF虚拟资源 (VR.Usage): 提供了对VNF内部健康状况的“X光片”，能够精准定位由底层计算、存储资源瓶颈引发的应用性能问题。
  3. 切片级虚拟资源 (Mean...Usage): 提供了对网络切片资源池整体负载的“核磁共振”视图，是实现切片资源精细化管理和SLA保障的基石。

这套从应用层到底层、从单个NF到整个切片的分层、解耦的测量体系，是5G云化网络能够实现“高效运维”的根本保障。它使得运维人员在面对复杂的“云中”问题时，不再“云里雾里”，而是能够层层下钻，直击根源，确保5G这座建立在云平台之上的“智慧城市”永远充满活力。

FAQ 环节

Q1：这些虚拟资源使用率数据，是由VNF自己上报的，还是由云平台提供的？ A1：这些数据最终是由**云管理平台（VNFM）**提供的。VNF应用本身通常不直接感知底层的物理或虚拟CPU使用率。底层的Hypervisor（如KVM）或容器引擎（如Docker）会持续监控其上运行的VM/容器的资源消耗，并将这些数据上报给云管理平台（如OpenStack的Ceilometer）。然后，运营商的OAM系统再通过与VNFM的标准接口（ETSI NFV SOL），采集这些数据，并将其与对应的VNF实例关联起来，最终呈现为TS 28.552中定义的性能测量项。

Q2：VR.VCpuUsageMean为90%和物理服务器CPU使用率为90%，是一回事吗？ A2：不是一回事，这是云化运维中一个非常关键且容易混淆的概念。VR.VCpuUsageMean为90%，指的是这个VNF所分配到的vCPU资源，已经被用掉了90%。例如，一个VNF被分配了8个vCPU核，它的vCPU使用率是90%。但其所在的物理服务器可能有96个物理核，这台物理服务器的总CPU使用率可能只有30%。因此，VNF的vCPU瓶颈，并不等同于物理服务器的瓶颈。但是，物理服务器的CPU使用率过高（如“吵闹的邻居”问题），则会反过来影响其上所有VNF的性能。

Q3：为什么6.2节的切片资源测量要用“加权平均（weighted average）”？ A3：因为一个网络切片实例中，可能包含多个不同规模、不同重要性的VNF。例如，一个切片可能包含2个大型的vUPF实例和1个小型的vSMF实例。在计算整个切片的平均CPU使用率时，如果简单地将三者的CPU使用率相加除以3，显然是不合理的。加权平均意味着，会根据每个VNF实例所分配的vCPU核数（或其他资源量）作为“权重”，来进行计算。这样，大型vUPF实例的资源使用情况，在最终的切片平均值中会占有更大的比重，从而更真实地反映切片整体的资源消耗状况。

Q4：这些测量对于5G核心网的自动化伸缩（auto-scaling）有什么作用？ A4：这些测量是实现自动化伸缩的核心触发依据。自动化伸缩平台（通常由VNFM和NFVO实现）会持续监控这些指标。例如，可以设置一条规则：“如果一个AMF池的平均VR.VCpuUsageMean在过去10分钟内持续高于80%，则自动触发水平扩容（Scale-out），新增一个AMF实例。”反之，也可以设置规则：“如果AMF池的平均vCPU使用率在凌晨时段持续低于20%，则自动触发水平缩容（Scale-in），关闭一部分冗余的AMF实例以节省资源。”

Q5：Data volume of Outgoing packets (5.7.2.4) 和我之前学的 TB.TotNbrDlInitial (5.1.1.7.1) 都是统计发送的数据，有什么区别？ A5：它们的统计点和统计对象完全不同。DataVolum.OutPackets是在核心网NF（或gNB-CU）的网络接口上统计的，它统计的是IP包的数量，这些IP包即将被发送到传输网络上。而**TB.TotNbrDlInitial是在gNB-DU的物理层统计的，它统计的是最终在无线空口上发送的传输块（TB）**的数量。一个IP包在经过核心网和RAN的层层封装、分片后，可能会对应多个TB。前者衡量的是NF对外的网络交互负载，后者衡量的是无线空口的物理传输负载。

关系图谱