CN117835254A - 由网络节点执行的方法和网络节点 - Google Patents

Abstract

本申请关于一种由网络节点执行的方法和网络节点，所述方法包括：获取与基站的分布单元DU对应的多个小区的小区容量相关信息；基于所述小区容量相关信息，确定所述多个小区的预测小区容量，用于所述基站，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。同时，可以使用人工智能模型来执行上述由网络节点执行的方法。

Description

由网络节点执行的方法和网络节点

技术领域

本申请涉及无线通信领域，具体而言，本申请涉及一种由网络节点执行的方法和网络节点及由基站执行的方法和基站。

背景技术

在4G/5G系统中，小区容量配置会影响基站的分布单元(Distributed Unit，DU)中央处理单元(Central Processing Unit，CPU)资源利用率。当前，小区容量配置是静态配置，配置值可以通过各个小区平分共享的CPU资源，并在满足最差情况(worst case)的情况下确定小区容量配置。然而，静态配置的小区容量配置不能动态变化，但在实际部署场景中，小区容量需求却是随着时间和空间动态而变化的，如图1中所示，小区容量需求在白天和夜晚会发生变化。因此，小区容量配置对CPU资源使用以及用户接入小区有重要影响。

如何更好地进行小区容量配置，更好地满足通信需求，是本领域技术人员一直在努力研究的技术问题。

发明内容

本申请的目的旨在至少能解决现有通信方式中的技术缺陷之一，以更好地满足通信需求。为了实现该目的，本申请提出的技术方案如下。

根据本申请实施例的第一方面，提供了一种由网络节点执行的方法，包括：获取与基站的分布单元DU对应的多个小区的小区容量相关信息；基于所述小区容量相关信息，确定所述多个小区的预测小区容量，用于所述基站，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

可选地，基于所述小区容量相关信息，确定所述多个小区的预测小区容量的步骤包括：基于所述小区容量相关信息，确定在每个小区对应不同小区容量时所述DU对应的小区容量和；基于满足设定条件的小区容量和，确定所述多个小区的预测小区容量。

可选地，满足设定条件的小区容量和为确定出的各小区容量和中最大的小区容量和。

可选地，所述小区容量相关信息中包括目标小区容量。

可选地，基于所述小区容量相关信息，确定在每个小区对应不同小区容量时所述DU对应的小区容量和的步骤包括：基于每个小区对应的目标小区容量和当前小区容量，确定每个小区对应的当前小区容量中的每个小区容量参数的权重；基于每个小区对应的当前小区容量以及当前小区容量中的每个小区容量参数的权重，确定所述DU对应的当前小区容量和。

可选地，每个小区的目标小区容量是基于利用相应小区在本次预设周期的实际小区容量以及在上一预设周期估计的目标小区容量确定的。

可选地，基于满足设定条件的小区容量和，确定每个小区的预测小区容量的步骤包括：判断所述DU对应的当前小区容量和是否满足设定条件；若是，则将每个小区对应的当前小区容量确定为所述多个小区的预测小区容量；否则，更新每个小区对应的当前小区容量，并基于每个小区更新后的当前小区容量确定所述DU对应的当前小区容量和。

可选地，判断所述DU对应的当前小区容量和是否满足设定条件的步骤包括：当所述DU对应的当前小区容量和与上一次确定的小区容量和的差不大于设定阈值，或小区容量更新次数达到更新次数上限时，确认当前小区容量和满足设定条件。

可选地，更新每个小区对应的当前小区容量的步骤包括：基于每个小区对应的当前小区容量，预测每个小区的处理模块中，每个时间敏感模块占用的中央处理单元CPU资源；以及基于预测出的每个小区的每个时间敏感模块占用的CPU资源，更新每个小区对应的当前小区容量。

可选地，基于预测出的每个小区的每个时间敏感模块占用的CPU资源，更新每个小区对应的当前小区容量的步骤包括：在每个小区的每个时间敏感模块占用的CPU资源不大于相应的资源占用上限值的条件下，更新每个小区对应的当前小区容量。

可选地，基于每个小区对应的当前小区容量，预测每个小区的处理模块中，每个时间敏感模块占用的CPU资源的步骤包括：基于每个小区对应的当前小区容量，利用神经网络模型预测每个小区的处理模块中的每个时间敏感模块占用的CPU资源。

可选地，所述方法还包括：基于所述多个小区的预测小区容量，确定所述DU的空闲CPU资源，用于所述基站根据所述空闲CPU资源，针对所述多个小区中的时间不敏感模块分配CPU资源。

可选地，基于所述多个小区的预测小区容量，确定所述DU的空闲CPU资源的步骤包括：基于所述多个小区的预测小区容量，利用神经网络模型确定每个小区的处理模块中，时间敏感模块占用的CPU资源；基于时间敏感模块占用的CPU资源以及时间敏感模块运行的起始时间，确定DU的空闲CPU资源。

可选地，确定DU的空闲CPU资源的步骤包括：基于时间敏感模块占用的CPU资源以及时间敏感模块运行的起始时间，确定时间敏感模块运行的结束时间；基于时序相邻的时间敏感模块运行的起始时间和结束时间，确定空闲CPU资源。

可选地，所述方法还包括：基于每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息，对所述神经网络模型进行训练。

可选地，所述小区容量包括下述至少一项：最多支持的用户设备UE个数；最多支持的配置探测参考信号SRS的UE个数；最多支持的多用户调度MU候选UE个数；最多支持的MU层数。

可选地，所述网络节点包括：基站、开放式无线接入网O-RAN中的无线接入网智能控制器RIC。

可选地，获取与基站的DU对应的多个小区的小区容量相关信息的步骤包括：从基站的DU获取对应的多个小区的小区容量相关信息，其中，所述方法还包括：将所述预测小区容量发送给所述基站，用于所述基站根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

可选地，所述小区容量相关信息包括下述至少一项：小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息、以及小区的目标小区容量。

根据本申请实施例的第二方面，提供了一种由基站执行的方法，包括：获取所述基站的分布单元DU对应的多个小区的预测小区容量，所述预测小区容量是基于DU对应的多个小区的小区容量相关信息确定的；以及根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

可选地，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量的步骤包括：确定DU对应的多个小区中的每个小区的优先级；以及根据每个小区的优先级，利用所述预测小区容量，针对各个小区分配小区容量。

可选地，根据每个小区的优先级，利用所述预测小区容量，针对各个小区分配小区容量的步骤包括：按照小区的优先级，依次针对每个小区进行以下操作：如果当前小区的优先级为高优先级，或者当前小区的优先级为低优先级且剩余的CPU资源不小于预设阈值，则基于所述预测小区容量为当前小区分配小区容量，并更新剩余的CPU资源；如果当前小区的优先级为低优先级且剩余的CPU资源小于所述预设阈值，则根据剩余的CPU资源确定当前小区的更新小区容量，基于所述更新小区容量为当前小区分配小区容量，并更新剩余的CPU资源。

可选地，所述方法还包括：获取DU的空闲CPU资源，所述空闲CPU资源是基于所述预测小区容量确定的；以及根据DU的空闲CPU资源，针对每个小区的处理模块中的时间不敏感模块分配DU的空闲CPU资源。

可选地，根据DU的空闲CPU资源，针对每个小区的处理模块中的时间不敏感模块分配DU的空闲CPU资源的步骤包括：对每个小区的处理模块中的时间不敏感模块进行拆分，得到关于所述多个小区的多个时间不敏感子模块；根据DU的空闲CPU资源，针对所述多个时间不敏感子模块中的每一个子模块分配DU的空闲CPU资源

根据本申请实施例的第三方面，提供了一种网络节点，包括：收发器；以及处理器，与所述收发器耦接，并被配置为执行如上所述的由网络节点执行的方法。

根据本申请实施例的第四方面，提供了一种基站，包括：收发器；以及处理器，与所述收发器耦接，并被配置为执行如上所述的由基站执行的方法。

根据本申请实施例的第五方面，提供了一种电子设备，包括：至少一个处理器；以及至少一个存储计算机可执行指令的存储器，其中，所述计算机可执行指令在被所述至少一个处理器运行时，促使所述至少一个处理器执行如上所述的方法。

根据本申请实施例的第六方面，提供了一种存储指令的计算机可读存储介质，其中，当所述指令被至少一个处理器运行时，促使所述至少一个处理器执行如上所述的方法。

本申请实施例提供的技术方案带来的有益效果，将在后文中结合具体的可选实施例进行说明，或者可以从对实施例的描述中获悉，或者可以通过实施例的实施而习知。

附图说明

为了更清楚、容易地说明和理解本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1示出了小区容量需求变化示意图；

图2示出了静态小区容量配置与实时小区容量需求之间的关系示意图；

图3是示出根据本申请的示例性实施例的由网络节点执行的方法的流程图；

图4是示出根据本申请的示例性实施例的DU向网络节点上报实际小区容量和对应的实际占用的CPU资源的过程的示意图；

图5是示出根据本申请的示例性实施例的基于小区容量相关信息确定所述多个小区的预测小区容量的过程的流程图；

图6是示出根据本申请的示例性实施例的确定在每个小区对应一种小区容量时所述DU对应的小区容量和的过程的流程图；

图7是示出根据本申请的示例性实施例的基于满足设定条件的小区容量和确定所述多个小区的预测小区容量的过程的流程图；

图8是示出根据本申请的示例性实施例的更新每个小区对应的当前小区容量的过程的流程图；

图9是示出根据本申请的示例性实施例的更新每个小区的当前小区容量的详细过程的流程图；

图10A是示出根据本申请的示例性实施例的对神经网络模型进行训练的示意图；

图10B是示出根据本申请的示例性实施例的临时小区容量优化过程的示意图；

图10C是示出根据本申请的示例性实施例的确定空闲CPU资源的过程的示意图；

图10D是示出根据本申请的示例性实施例的基于AI的小区容量决策确定多个小区的预测小区容量和空闲CPU资源的过程的示意图；

图10E是示出根据本申请的示例性实施例的基于AI的小区容量决策确定多个小区的预测小区容量的过程的详细示意图；

图11是示出根据本申请的示例性实施例的由基站执行的方法的流程图；

图12是示出根据根据本申请的示例性实施例的确定DU的每个小区的优先级的过程的流程图；

图13是示出根据本申请的示例性实施例的针对每个小区分配小区容量的过程的流程图；

图14A是示出针对每个时间不敏感子模块分配空闲CPU资源的过程的流程图；

图14B是示出现有技术与本申请的方法进行对比结果的示图；

图15A是示出根据本申请的示例性实施例的基于AI的小区容量决策确定和应用多个小区的预测小区容量和空闲CPU资源的总的处理流程图。

图15B是示出了根据本申请的示例性实施例的网络节点的框图；

图16是示出了根据本申请的示例性实施例的基站的框图；

图17是示出用于对现有方法与本申请的方法进行对比的示例场景的示图；

图18是示出针对图17所示出的示例场景的现有方法与本申请的方法的效果对比图；和

图19是示出用于对现有方法与本申请的方法进行对比的另一示例场景的示图。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”可以实现为“A”，或者实现为“B”，或者实现为“A和B”。在描述多个(两个或两个以上)项目时，如果没有明确限定多个项目之间的关系，这多个项目之间可以是指多个项目中的一个、多个或者全部，例如，对于“参数A包括A1、A2、A3”的描述，可以实现为参数A包括A1或A2或A3，还可以实现为参数A包括参数A1、A2、A3这三项中的至少两项。

如背景技术部分中所述，4G/5G系统中，小区容量配置会影响DU的CPU资源利用率，其中，小区容量配置包括以下小区容量参数中的至少一项：

1.最多支持的用户设备(User Equipment，UE)个数，也可以称为无线资源控制(Radio Resource Control，RRC)-UE：该参数影响CPU资源利用率并影响UE能否接入到小区；

2.最多的支持配置探测参考信号(Sounding Reference Signal，SRS)的UE个数(SRS-UE)：该参数影响CPU资源利用率以及小区吞吐量；

3.最多支持的多用户调度(Multi-User，MU)候选UE个数，也可以称为半正交用户选择(Semi-orthogonality User Selection，SUS)-UE：该参数影响CPU资源利用率以及小区吞吐量；以及

4.最多支持的MU层数(MU-Layer)：该参数影响CPU资源利用率以及小区吞吐量。

当前，小区容量配置是静态小区容量配置，但静态小区容量配置无法适应如图1中所示的实时小区容量需求的动态变化，进而存在如下问题：

1.当小区容量需求低于小区容量配置时(如图2中的空白直方图部分所示)，CPU资源被浪费，从而导致单个小区的硬件成本增加；

2.当小区容量需求高于小区容量配置时(如图2中的灰色直方图部分所示)，小区的容量不足，即实时小区容量需求无法被满足，导致部分UE无法接入小区或者小区吞吐量降低。

此外，静态小区容量配置是通过遍历多种配置参数的组合进行CPU资源利用率测试来得到的，该配置方案还存在复杂度过高的问题。由于配置参数的组合个数过多，导致CPU资源利用率测试过程需要使用的时间开销过大，且人力成本过高，另外，每次当代码发生变化时(例如新增特性或者功能增强时)，已有的静态小区容量配置就会失效，需要重新进行上述测试过程，如下表1中所示的对于某个小区的情况：

[表1]

也就是说，对于该小区而言，如果不对上述的四种小区容量参数降采样，则需要测试最大157286400种小区容量配置，即，测试157286400种小区容量参数组合，当每个DU包括多个小区时，则总测试量将成几何增长。显然，上述配置方案无法应用于正常的系统开发中，需要对上述的四种小区容量参数降采样(即只选择其中的部分参数进行测试)，但是这样又会导致小区容量配置的精确度大幅度降低。

图3是示出根据本申请示例性实施例的由网络节点执行的方法的流程图。网络节点可以是下一代基站(gNB，也可被称为基站、数据单元等)、开放式无线接入网(Open RadioSccess Network O-RAN)中的无线接入网智能控制器(RAN Intelligent Controller，RIC)、或者支持通用复杂计算的通用CPU。例如，网络节点可以是人工智能(ArtificialIntelligence，AI)服务器。网络节点可以从其它的网络节点(例如基站)接收各种信息，根据接收的信息确定小区容量，并将确定的小区容量下发给基站，或者网络节点本身可以是基站，并且可自身收集各种信息，根据接收的信息确定小区容量，并基于确定的小区容量针对每个小区分配小区容量。在本申请中，这里提及的“小区容量”与以上提及的“小区容量配置”具有相同的含义，可以互换使用。本申请实施例中的DU也可以称为数字化单元(DigitalUnit)。

如图3中所示，在步骤S310，获取与基站的DU对应的多个小区的小区容量相关信息。

在本申请的示例性实施例中，所述小区容量相关信息可包括DU上安装的用于每个小区的处理模块(即软件模块)的处理模块限制(也可称为软件模块限制)，其中，处理模块限制包括以下项中的至少一项：处理模块的标识ID、处理模块类型、表示CPU资源限制的限制格式、处理模块运行起始时间、处理模块运行结束时间、处理模块运行时长，其中，处理模块类型表示处理模块是时间关键模块、非时间关键模块和时间不敏感模块中的一种类型。

在本申请的一种示例性实施例中，当执行所述方法的网络节点是基站时，在网络节点(例如，基站)启动时，从本地获取每个小区的每个处理模块的处理模块限制，其中，DU上安装的用于每个小区的处理模块按照时间敏感度被分类为时间关键模块、非时间关键模块和时间不敏感模块，其中，时间关键模块和非时间关键模块可被称为时间敏感模块。在本申请的另一种示例性实施例中，当执行所述方法的网络节点是除了基站以外的其他网络设备(例如，O-RAN中的RIC)，网络节点可从基站(例如基站的DU)获取每个小区的每个处理模块的处理模块限制。

具体地讲，基站的一个DU可以对应于多个小区，该DU上安装有用于该多个小区的处理模块(即软件模块)，在基站启动时，这些小区被构建，进而用于这些小区的处理模块会根据需求占用DU的CPU资源，DU可按照其上安装的用于每个小区的处理模块对时间敏感的程度将处理模块分类为时间敏感模块和时间不敏感模块，其中，时间不敏感模块表示对时间不敏感的模块，其使用CPU资源的优先级低，该模块可利用CPU空闲资源来完成任务；时间敏感模块表示对时间敏感的模块，其使用CPU资源的优先级高，该模块在运行时占用CPU资源的时间小于或等于一个预设上限值，该预设上限值可以小于或等于一个传输时间间隔(Transmission Time Interval，TTI)。

进一步地，时间敏感模块可按照对时间敏感的程度被进一步分类为时间关键模块和非时间关键模块，其中，时间关键模块表示这样的模块：该模块在运行时占用CPU资源的时间小于或等于一个预设上限值，该预设上限值小于一个TTI，且该模块运行时的起始时间和结束具有严格要求，另外，每个模块可具有不同的时间上限值；非时间关键模块表示这样的模块：该模块在运行占用CPU资源的时间小于或等于一个预设上限值，该预设上限值等于一个TTI，换句话说，对非时间关键模块的限制更侧重于运行时占用CPU资源的运行时长(即小于或等于一个TTI)，而对时间关键模块的限制更侧重于运行时的起始时间和结束时间。此外，对于DU下的不同小区，DU上存在的处理模块的集合也不完全相同，例如，一个小区可能存在两个时间关键模块、一个非时间关键模块和一个时间不敏感模块，而另一个小区可能存在一个时间关键模块、一个非时间关键模块，而不存在时间不敏感模块。

综上，网络节点可获取每个处理模块的处理模块限制，例如，可按照如下表2中所示的格式获取处理模块限制。

[表2]

在表2中，每个处理模块具有相应的模块ID，用于标识每个处理模块。每个处理模块被分类到一种模块类型，即，时间关键模块、非时间关键模块或时间不敏感模块。每种处理模块都有对应的限制格式，即使是具有相同模块类型的两个处理模块，也可能具有不同的限制格式，例如，虽然模块#1和模块#3具有相同的模块类型(即，都是时间关键模块)，但是模块#1的限制格式为格式1，模块#3的限制格式为格式3。每个限制格式表示相应的CPU资源限制，例如，格式1表示的CPU资源限制是对起始时间和运行时长有具体的要求(例如，起始时间为0.1TTI，运行时长小于第一预设上限值(该上限值小于1TTI))，格式3表示的CPU资源限制是对结束时间和运行时长有具体的要求(例如，结束时间为0.5TTI，运行时长小于第二预设上限值(该上限值小于1TTI))。对于时间不敏感模块而言，可以将其限制格式设置为一个统一的格式，例如，格式0，表示对CPU资源没有具体的限制，其起始时间、结束时间和运行时间可以是任意值。格式K用于表示一个DU上安装的用于多个小区的处理模块占用CPU资源的时间之和需要小于最大CPU资源(max_cpu_resource)，其中，processing_time_k表示处理模块k占用CPU资源的时间，k是大于等于1且小于或等于K的整数，其中，K是多个小区的处理模块的数量，max_cpu_resource＝num_of_cpu_cores×TTI_length×cpu_main_frequency，其中，num_of_cpu_cores表示DU的CPU核的数量，TTI_length表示一个TTI的长度，cpu_main_frequency表示CPU总频。然而，表2仅用于处理模块限制的一种示例，本申请不限于此，处理模块限制可以被表示为任何形式，只要该形式能够体现出类似于表2中涵盖的信息就可以。

此外，所述小区容量相关信息包括以下项中的至少一项：小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息、以及小区的目标小区容量。

在本情况的一种示例性实施例中，当执行所述方法的网络节点是基站时，在网络节点(例如，基站)启动后，按照预设周期，获取DU的每个小区的本次预设周期的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息、以及DU针对本次预设周期估计的每个小区的目标小区容量。

具体地讲，在网络节点(即基站)启动后，网络节点搜集每个小区的实际小区容量和实际占用的CPU资源(即与该实际小区容量对应的占用的CPU资源)，然后用于后续使用的神经网络模型的训练。一个小区的实际小区容量可表示为{RRC-UE,SRS-UE,SUS-UE,MU-Layer}集合；实际占用的CPU资源与该实际小区容量相对应，表示DU上安装的用于该小区的处理模块的CPU资源占用情况，例如该小区对应的实际占用的CPU资源可表示为{模块#1＝xxx(CPU周期)，模块#2＝xxx(CPU周期)，…}。在本申请中，针对与DU的一个CPU资源池对应的多个小区，搜集每个小区的实际小区容量和与之对应的实际占用的CPU资源。另外，网络节点按照预设周期(例如10个TTI)进行搜集，例如在预设周期(例如10个TTI)内搜集每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息，以用于后续神经网络模型的训练。

此外，在获取实际小区容量和对应的实际占用的CPU资源时，还需要获取针对本次预设周期(例如10个TTI)估计的每个小区的目标小区容量。在本申请中，每个小区的目标小区容量是基于利用相应小区在本次预设周期的实际小区容量以及在上一次预设周期估计的目标小区容量确定的。

具体地讲，可根据以下等式(1)来确定每个小区的目标小区容量：

target_cell_capacity_cur#c＝α×target_cell_capacity_pre#c+(1-α)×real_cell_capacity#c (1)

其中，target_cell_capacity_cur#c表示第c个小区的本次预设周期的目标小区容量，target_cell_capacity_pre#c表示第c个小区的上一次预设周期的目标小区容量，real_cell_capacity#c表示第c个小区的本次预设周期的实际小区容量，α表示配置的系数，其是设置的，例如，可将α设置为0.6，但本申请不限于此。

此外，在网络节点启动以后第一次确定一个小区的目标小区容量时，由于不存在针对上一次预设周期估计的相应小区的目标小区容量，因此，将本次预设周期的实际小区容量设置为本次预设周期的目标小区容量。

在本申请的另一种示例性实施例中，当执行所述方法的网络节点是除了基站以外的其他网络设备(例如，O-RAN中的RIC)时，在基站启动以后，网络节点按照预设周期，从基站(例如基站的DU)获取DU的每个小区的本次预设周期的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息、以及DU针对本次预设周期估计的每个小区的目标小区容量。

具体地讲，在基站启动后，DU搜集每个小区的实际小区容量和实际占用的CPU资源(即与该实际小区容量对应的所占用的CPU资源)，然后上报给网络节点用于后续使用的神经网络模型训练。此外，在本申请中，针对与DU的一个CPU资源池对应的多个小区，基站按照预设周期将每次预测周期内搜集的每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息一起上报给网络节点，如图4中所示，基站(如DU)将与同一个CPU资源池对应的多个小区的实际小区容量和对应的实际占用的CPU资源一起上报给网络节点。此外，在获取实际小区容量和对应的实际占用的CPU资源时，网络节点还需要从基站获取针对本次预设周期(例如10个TTI)估计的每个小区的目标小区容量，由于以上已经对目标小区容量进行了详细描述，这里不再对此进行赘述。

综上，在网络节点是除了基站以外的其他网络设备(例如，O-RAN中的RIC)时，获取与基站的DU对应的多个小区的小区容量相关信息的步骤可包括：从基站的DU获取对应的多个小区的小区容量相关信息。

返回参照图3，在步骤S320，基于所述小区容量相关信息，确定所述多个小区的预测小区容量，用于所述基站，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。下面结合图5对此进行描述。

图5是示出根据本申请示例性实施例的基于所述小区容量相关信息确定所述多个小区的预测小区容量的过程的流程图。

如图5中所示，首先，在步骤S510，基于所述小区容量相关信息，确定在每个小区对应不同小区容量时所述DU对应的小区容量和。下面将参照图6来描述在每个小区对应于一种小区容量时所述DU对应的小区容量和的过程。图6是示出根据本申请的示例性实施例的确定在每个小区对应一种小区容量时所述DU对应的小区容量和的过程的流程图。

虽然图6中未示出，但是在本申请的示例性实施例中，在进行图6的过程时，首先要完成初始化过程。

具体地讲，首先，设置所述多个小区的临时小区容量。例如，可以根据在步骤S310获取的每个小区的目标小区容量来设置所述多个小区的临时小区容量。详细地，利用获取的每个小区的目标小区容量来设置多个小区的一个总的目标小区容量target_cell_capacity，详细地，获取的每个小区的目标小区容量是一个由F个小区容量参数组成的参数集，其中，F是大于或等于1的正整数，在以上的示例中，F是4，即，参数集为{RRC-UE,SRS-UE,SUS-UE,MU-Layer}，因此，当DU控制所述多个小区(例如C个小区)时，可利用获取的这C个小区中的每个小区的目标小区容量组成包含N＝F×C个小区容量参数的一个参数集target_cell_capacity(即一个总的目标小区容量)，其中，该参数集中的第n个参数可被表示为target_cell_capacity#n，n是大于或等于1且小于或等于N的整数。此时，可定义一个与总的目标小区容量target_cell_capacity具有相同数量个参数的临时小区容量temp_cell_capacity，并且将初始的临时小区容量temp_cell_capacity设置为与总的目标小区容量target_cell_capacity相同，但是本申请对设置初始的临时小区容量temp_cell_capacity的方法不作具体限定，例如，可将初始的临时小区容量temp_cell_capacity设置为其它值。

此外，在该初始化过程中，还需要设置临时小区容量中的每个小区容量参数的权重。具体地讲，可以设置一个权重数组weight，该权重数组weight的长度为N，也就是，在DU下共享同一个CPU资源池的多个小区的小区容量参数的总数，即，N＝F×C，如上所述，F表示每个小区的小区容量参数的数量，C表示在DU下共享同一个CPU资源池的小区的数量，并且，该权重数组weight中的第n个权重weight#n对应于临时小区容量temp_cell_capacity中的第n个参数temp_cell_capacity#n，并且weight#n的初始值等于1/N，此外，为了在后续不断更新权重数组weight，还设置了一个基础步长basic_step，该基础步长basic_step可被灵活调整，例如，可将该基础步长basic_step设置为0.2，但是本申请不限于此。

在初始化以后，在步骤S610，基于每个小区对应的目标小区容量和当前小区容量，确定每个小区对应的当前小区容量中的每个小区容量参数的权重。

在本申请的示例性实施例中，提及每个小区对应的当前小区容量时表示在描述每个小区时该小区临时的小区容量，多个小区中的每个小区的当前小区容量一起可构成在以上初始化过程中提及的临时小区容量，例如，如果存在3个小区，每个小区的当前小区容量由4个小区容量参数来配置，则临时小区容量可以表示为由这3个小区的12个小区容量参数组成的参数集，其中，该参数集中的每个小区容量参数。在此情况下，由于临时小区容量中包含了每个小区的当前小区容量的小区容量参数，因此，换句话说，确定每个小区对应的当前小区容量中的每个小区容量参数的权重就是确定临时小区容量中的每个小区容量参数的权重。

具体地讲，首先，在进行了以上初始化以后，根据以下等式(2)确定临时小区容量中的第n个小区容量参数的差值：

diff#n＝target_cell_capacity#n–temp_cell_capacity#n (2)

然后，根据以下等式(3)更新与临时小区容量中的第n个小区容量参数对应的权重weight#n：

weight#n＝weight#n+basic_step×diff#n/N (3)

其中，当临时小区容量中的第n个小区容量参数temp_cell_capacity#n小于总的目标小区容量中的第n个小区容量参数target_cell_capacity#n时，diff#n为正，相应地，权重weight#n将被增加，并且temp_cell_capacity#n与target_cell_capacity#n之间的差异diff#n越大，则权重weight#n被增加的幅度也越大；反之，temp_cell_capacity#n大于target_cell_capacity#n时，权重weight#n将被相应地减小。

此外，在根据以上的等式(2)和(3)确定了权重数组weight中的每一个权重以后，对于每个权重，还可以按照以下等式(4)进行归一化处理：

至此，即可确定出每个小区对应的当前小区容量中的每个小区容量参数的权重。

在步骤S620，基于每个小区对应的当前小区容量以及当前小区容量中的每个小区容量参数的权重，确定所述DU对应的当前小区容量和。

如上所述，临时小区容量是由每个小区对应的当前小区容量组成，因此，在本申请的示例性实施例中，DU对应的当前小区容量和是根据多个小区中的每一个小区的当前小区容量确定的，因此也可被称为临时小区容量加权和。

具体地讲，根据以下等式(5)确定DU对应的当前小区容量和(即临时小区容量加权和)capacity_sum：

其中，temp_cell_capacity#n表示临时小区容量中的第n个小区容量参数，weight#n表示该第n个小区容量参数对应的权重。

以上描述了在每个小区对应一种小区容量(即临时小区容量中的每个小区容量参数取一种对应值)时确定DU对应的当前小区容量和(即临时小区容量加权和)的过程，但是为了确定最佳的临时小区容量需要不断地更新临时小区容量中的每个小区容量参数(即使得每个小区对应不同小区容量)以得到对应的小区容量和(即临时小区容量加权和)，也就是说，需要确定在每个小区对应不同小区容量时DU对应的小区容量和(即临时小区容量加权和)。该更新过程将在以下的步骤S520中进行具体描述。

返回参照图5，在步骤S520，基于满足设定条件的小区容量和，确定所述多个小区的预测小区容量。下面参照图7对此进行描述。

图7是示出根据本申请的示例性实施例的基于满足设定条件的小区容量和确定所述多个小区的预测小区容量的过程的流程图。

参照图7，在步骤S710，判断所述DU对应的当前小区容量和是否满足设定条件。

具体地讲，在以上参照图6确定了在每个小区对应一种小区容量时所述DU对应的小区容量和以后，需要判断该小区容量和是否满足设定条件。判断所述DU对应的当前小区容量和是否满足设定条件的步骤包括：当所述DU对应的当前小区容量和与上一次确定的小区容量和的差不大于设定阈值，或小区容量更新次数达到更新次数上限时，确认当前小区容量和满足设定条件。

具体地讲，如果以下条件判断式(6)不成立，则表示当前小区容量和满足设定条件，并进行到步骤S720：

capacity_sum#l–capacity_sum#(l-1)>capacity_sum_gain_thre且l＜L (6)

其中，capacity_sum#l表示第l次更新过程确定的与DU对应的当前小区容量和(即临时小区容量加权和)。capacity_sum#(l-1)表示第(l-1)次更新过程确定的与DU对应的小区容量和(针对第l次的上一次确定的临时小区容量加权和)。capacity_sum_gain_thre表示加权和增益门限，即以上所述的设定阈值，其是可配置的，例如，可配置为0。L为上述的更新次数上限，其是可配置的，例如，可配置为200，l是大于2且小于或等于L的整数。

在步骤S720，可将每个小区对应的当前小区容量确定为所述多个小区的预测小区容量，即，将由多个小区中的每个小区的当前小区容量组成的当前的临时小区容量temp_cell_capacity，确定为所述预测小区容量predicted_cell_capacity。

此外，如果以上判断式(6)成立，即如果DU对应的当前小区容量和与上一次确定的小区容量和的差小于或等于设定阈值，并且小区容量更新次数未达到更新次数上限，则说明DU对应的当前小区容量和不满足设定条件，因此进行到步骤S730。

在步骤S730，更新每个小区对应的当前小区容量。下面参照图8描述更新每个小区对应的当前小区容量的过程。

具体地讲，如图8中所示，在步骤S810，基于每个小区对应的当前小区容量，预测每个小区的处理模块中，每个时间敏感模块(即时间关键模块或非时间关键模块)占用的CPU资源。

在本申请的示例性实施例中，基于每个小区对应的当前小区容量，预测每个小区的软件模块中，每个时间敏感模块占用的CPU资源的步骤包括：基于每个小区对应的当前小区容量，利用神经网络模型预测每个小区的软件模块中的每个时间敏感模块占用的CPU资源。

如图10A中所示，所述神经网络模型是基于DU的每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息训练得到的，经过训练，该神经网络模型具有根据小区容量预测每个时间敏感模块(即时间关键模块或非时间关键模块)占用CPU资源的情况的能力。在本申请中，在起始阶段，最早用于上述预测过程的神经网络模型可以是网络节点经过长时间训练得到的模型，并且在后续应用过程中，网络节点可按照预定训练周期，应用获取的每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息对神经网络模型进行训练。例如，网络节点可按照长度为10个TTI的预设周期获取每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息，然后按照长度为200个TTI的预定训练周期，应用先后20次(即200/10＝20次)获取的每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息对神经网络模型进行训练，其中，每次获取的与DU对应的多个小区的实际小区容量被组成一维数组，且与该次获取的每个小区的实际小区容量对应的占用的CPU资源的信息也被组成一维数组，然后它们被输入到神经网络模型，其中，被用于进行神经网络模型训练的占用的CPU资源需要用以上描述的处理模块限制进行标注，以使得神经网络模型能够获知每个时间关键模块、非时间关键模块和时间不敏感模块分别占用的CPU资源。另外，网络节点可在每次训练完神经网络模型以后将训练的神经网络模型应用于上述预测过程，也可以在进行多次训练以后将训练的神经网络模型应用于上述预测过程，此外，虽然在以上描述中，上述预定训练周期不同于网络节点获取每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息的预设周期，但是上述预定训练周期也可以与该预设周期相同，也就是说，网络节点可在每次获取了每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息以后，就对神经网络模型进行训练。此外，神经网络模型可以是前馈神经网络模型，但是本申请对神经网络模型的具体实现方式不作具体限定。

在这里，可用CPU_res_calculator表示训练好的神经网络模型，其也可被称为CPU资源计算器。由于训练好的神经网络模型具有根据小区容量预测每个时间敏感模块(即时间关键模块和非时间关键模块)占用CPU资源的情况的能力，并且如上所述每个小区的当前小区容量可被总体表示为临时小区容量temp_cell_capacity，因此，CPU_res_calculator(temp_cell_capacity)表示神经网络模型CPU_res_calculator基于输入的临时小区容量temp_cell_capacity预测的每个小区的时间敏感模块占用的CPU资源，即，可以基于每个小区对应的当前小区容量，利用神经网络模型预测每个小区的软件模块中的每个时间敏感模块占用的CPU资源。

这里使用神经网络模型预测每个小区的时间关键模块和非时间关键模块占用的CPU资源，可以帮助确定小区容量的安全边界，确保多个小区的预测小区容量不会造成CPU资源的枯竭甚而影响实时系统的正常运转，从而使预测小区容量可以安全地尽可能地逼近总的目标小区容量(即由DU上报的针对本次预设周期估计的每一个小区的的目标小区容量确定的总的目标小区容量)，以最大效率地使用有限的CPU资源。

在步骤S820，基于预测出的每个小区的每个时间敏感模块占用的CPU资源，更新每个小区对应的当前小区容量。

具体地讲，基于预测出的每个小区的每个时间敏感模块占用的CPU资源，更新每个小区对应的当前小区容量的步骤包括：在每个小区的每个时间敏感模块占用的CPU资源不大于相应的资源占用上限值的条件下，更新每个小区对应的当前小区容量。下面参照图9对此进行描述。

图9是示出根据本申请的示例性实施例的更新每个小区的当前小区容量的详细过程的流程图。

在步骤S910，确定每个小区的时间敏感模块(即时间关键模块和非时间关键模块)占用的CPU资源与相应的资源占用上限值之间的占用资源差。

具体地讲，根据以下等式(7)针对每个时间敏感模块确定上述占用资源差(或约束函数)：

res_diff#m＝CPU_res#m–upper_limit#m (7)

其中，upper_limit#m表示第m个时间敏感模块的资源占用上限值，其中，网络节点可按照以上的表2所示的形式获取每个时间敏感模块的资源占用上限值。CPU_res#m表示第m个时间敏感模块占用的CPU资源，它是从通过如上所述的CPU_res_calculator(temp_cell_capacity)预测出的每个小区的时间敏感模块占用的CPU资源中确定的，例如，网络节点可根据按照以上的表2所示处理模块限制中的模块ID和模块类型，从CPU_res_calculator(temp_cell_capacity)预测出的每个小区的时间敏感模块占用的CPU资源中确定第m个时间敏感模块占用的CPU资源。res_diff#m表示第m个时间敏感模块占用的CPU资源CPU_res#m与第m个时间敏感模块的资源占用上限值之间的资源差。因此，根据以上的等式(7)，可确定出每一个时间敏感模块的占用资源差，假设对于DU下的多个小区，一共存在M个时间敏感模块(即总共M个时间关键模块和非时间关键模块)，则相应地存在M个占用资源差，从而形成一个长度为M的占用资源差数组res_diff，其中，M是大于或等于2的整数。

在步骤S920，在保持每个时间敏感模块的占用资源差为非正值的条件下，更新临时小区容量，可避免CPU资源耗尽。

在本申请的示例性实施例中，可将顺序二次规划(Sequential QuadraticProgramming，SQP)优化方法应用于步骤S920，SQP优化方法可在存在约束条件的情况下完成对非线性系统的优化任务。

具体地讲，利用SQP优化方法，如图10B中所示，不断调整临时小区容量temp_cell_capacity，且每次调整临时小区容量temp_cell_capacity以后，基于该临时小区容量temp_cell_capacity，利用神经网络模型预测每个时间敏感模块的占用的CPU资源，在保持每个时间敏感模块的占用资源差为非正值的条件下(即在保持占用资源差数组res_diff中的每个元素为非正值的约束条件下)，使得利用以上的等式(5)确定的临时小区容量加权和capacity_sum最大化，此时将在临时小区容量加权和capacity_sum最大化时的临时小区容量确定为更新后的临时小区容量，即确定为每个小区更新后的当前小区容量。由于权重数组weight的计算已经考虑了临时小区容量中的各个小区容量参数的调整需求，而在使临时小区容量加权和capacity_sum最大化的过程中，更大的权重将导致更大的调整后的临时小区容量temp_cell_capacity，因此，SQP优化方法可以实现对临时小区容量temp_cell_capacity的优化调整。

返回参照图7，在更新了每个小区对应的当前小区容量以后，在步骤S740，基于每个小区更新后的当前小区容量确定所述DU对应的当前小区容量和，即重新执行以上参照图6的步骤S610和S620描述的过程，因此这里不再进行赘述。在基于每个小区更新后的当前小区容量确定所述DU对应的当前小区容量和以后，返回到步骤S710重新进行判断。

通过在保持每个时间敏感模块的占用资源差为非正值的条件下更新每个小区对应的当前小区容量，使得有限CPU资源所导致的限制被充分考虑，从而使得最终更新结果(也就是，通过最终更新过程调整后的临时小区容量temp_cell_capacity的结果，即，预测小区容量predicted_cell_capacity)可以在安全的前提下不断接近所有小区的目标小区容量，更具体地讲，在每次更新每个小区的当前小区容量(即临时小区容量temp_cell_capacity)以后，权重weight会根据该更新后的临时小区容量temp_cell_capacity与总的目标小区容量(即系统期望的理想值)之间的差值diff得到更新，例如，第n个权重weight#n更新的方向(增加或减小)反应了临时小区容量中的第n个小区容量参数被期望增加或减小，而第n个权重weight#n更新后的绝对值，反映了第n个小区容量参数被期望调整的幅度，也就是说，更新后的第n个权重weight#n携带了第n个小区容量参数调整的信息以进行下一次临时小区容量的更新过程，从而使得临时小区容量不断接近总的目标小区容量(即系统期望的理想值)。

另外，在以上描述图7的步骤S710时，基于等式(6)来判断当前小区容量和是否满足设定条件，如果满足，则通过步骤S720将每个小区的当前小区容量确定为所述多个小区的预测小区容量，如果不满足，则通过步骤S730和S740更新每个小区对应的当前小区容量，并基于每个小区更新后的当前小区容量重新确定所述DU对应的当前小区容量和。但是本申请不限于此，本申请还可以不采用等式(6)进行判断，而是利用步骤S730和S740多次更新每个小区对应的当前小区容量并基于每个小区更新后的当前小区容量重新确定所述DU对应的当前小区容量和，从而获得L组临时小区容量，然后从这L组小区容量中选择小区容量和最大的一组临时小区容量作为所述多个小区的预测小区容量。也就是说，判断是否已确定了预定数量个小区容量和；若是，则将与所述预定数量个小区容量和中的满足设定条件的小区容量和对应的每个小区的当前小区容量确定为所述多个小区的预测小区容量；否则，更新每个小区对应的当前小区容量，并基于每个小区更新后的当前小区容量确定所述DU对应的当前小区容量和。

通过以上描述可知，满足设定条件的小区容量和实际上是确定出的各小区容量和中最大的小区容量和。

返回参照图3，在执行了步骤S320以后，可确定出所述多个小区的预测小区容量。如果网络节点是基站，则网络节点可根据预测小区容量，针对所述多个小区中的每一个小区分配小区容量。如果网络节点是除了基站以外的其他网络设备(例如，O-RAN中的RIC)，则网络节点可将确定的预测小区容量predicted_cell_capacity发送给基站，用于所述基站根据所述预测小区容量predicted_cell_capacity，针对所述多个小区中的每一个小区分配小区容量，该过程将在后续进行具体描述。

如上所述，在DU上安装的用于每个小区的处理模块(即软件模块)被分类为时间敏感模块(即时间关键模块和非时间关键模块)和时间不敏感模块，其中的时间不敏感模块的调度执行并没有固定的时序要求，因此可以比较自由地利用空闲CPU资源完成处理，从而进一步提高CPU资源利用效率。因此，网络节点可基于确定的预测小区容量来确定DU的空闲CPU资源，用于基站针对时间不敏感模块分配确定的空闲CPU资源，以帮助DU实现更高效率的CPU资源调度。

因此，图3所描述的由网络节点执行的方法还可包括：基于所述多个小区的预测小区容量，确定DU的空闲CPU资源，用于基站根据空闲CPU资源，针对所述多个小区中的时间不敏感模块分配CPU资源。

具体地讲，基于所述多个小区的预测小区容量，确定DU的空闲CPU资源的步骤包括：基于所述多个小区的预测小区容量，利用神经网络模型确定每个小区的处理模块中，时间敏感模块占用的CPU资源。

在本申请的示例性实施例中，与以上在步骤S810描述的基于临时小区容量temp_cell_capacity利用神经网络模型CPU_res_calculator预测每个小区的时间敏感模块占用的CPU资源类似，如图10C中所示，可将预测小区容量输入到神经网络模型(即CPU资源计算器)中，以可通过CPU_res_calculator(predicted_cell_capacity)预测出每个小区的时间敏感模块占用的CPU资源，其中，DU下的所有小区的M个时间敏感模块中的第m个时间敏感模块(即时间关键模块或非时间关键模块)占用的CPU资源可被表示为used_resource_module#m，如图10C中所示，预测出的时间敏感模块(如模块#0、模块#1和模块#2)占用了部分CPU资源。

此外，基于所述多个小区的预测小区容量，确定DU的空闲CPU资源的步骤还包括：基于时间敏感模块占用的CPU资源以及时间敏感模块运行的起始时间，确定DU的空闲CPU资源。

具体地讲，首先，基于时间敏感模块占用的CPU资源以及时间敏感模块运行的起始时间，确定时间敏感模块运行的结束时间。也就是，对于DU下的所有小区的M个时间敏感模块中的第m个时间敏感模块而言，网络节点可基于第m个时间敏感模块占用的CPU资源used_resource_module#m以及获取的小区容量相关信息中涉及的第m个时间敏感模块的起始时间start_time_module#m，利用以下等式(8)确定第m个时间敏感模块的结束时间：

end_time_module#m＝start_time_module#m+used_resource_module#m (8)

然后，基于时序相邻的时间敏感模块运行的起始时间和结束时间，确定空闲CPU资源。具体地，对于时序上连续的两个时间敏感模块module#t与module#(t+1)，可以确定出空闲CPU资源的起始时间idle_start#i与结束时间idle_end#i，其中，idle_start#i＝end_time_module#t，idle_end#i＝start_time_module#(t+1)，其中，end_time_module#t表示第t个模块module#t的结束时间，start_time_module#(t+1)表示第(t+1)个模块module#(t+1)的起始时间。如图10C中所示，在时间敏感模块(即时间关键模块和/或非时间关键模块)占用的CPU资源之间的CPU资源就是空闲CPU资源。

此后，可将确定的空闲CPU资源(例如{idle_start#i,idle_end#i})聚合形成空闲资源清单，即，关于确定的空闲CPU资源的信息，用于基站能够根据该关于确定的空闲CPU资源的信息，完成对时间不敏感模块的调度执行，从而实现更高效率的CPU资源调度。

以上参照图3至图10C详细地描述了网络节点确定多个小区的预测小区容量的过程以及确定空闲CPU资源的过程(这两个过程可被统称为基于AI的小区容量决策过程)，下面参照图10D和图10E对进行基于AI的小区容量决策过程进行总的描述。

图10D是示出根据本申请的示例性实施例的基于AI的小区容量决策确定多个小区的预测小区容量和空闲CPU资源的过程的示意图。图10E是示出根据本申请的示例性实施例的基于AI的小区容量决策确定多个小区的预测小区容量的过程的详细示意图。

如图10D和图10E中所示，基于AI的小区容量决策过程由两部分组成，即，神经网络模型和小区容量决策过程。基于AI的小区容量决策过程的输入为：小区的处理模块限制、小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息、以及小区的目标小区容量。基于AI的小区容量决策过程如下：

步骤(1)：基于AI的小区容量决策过程可基于输入的小区的处理模块限制、以及小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息周期性地对神经网络模型进行训练(图10D未示出)。

步骤(2)：基于AI的小区容量决策过程利用小区的目标小区容量针对多个小区设置一个临时小区容量；

步骤(3)：根据目标小区容量和临时小区容量针对临时小区容量中的每个小区容量参数确定权重(例如根据以上等式(2)、(3)和(4)计算)；

步骤(4)：基于临时小区容量利用训练后的神经网络模型预测每个时间敏感模块占用的CPU资源，根据预测出的每个时间敏感模块占用的CPU资源，确定每个时间敏感模块与相应上限值之间的占用资源差(例如根据以上等式(7)计算)，并在保持每个时间敏感模块的占用资源差为非正值的情况下，调整临时小区容量中的小区容量参数使得小区容量和(例如根据以上等式(5)计算)最大化；

步骤(5)：如果确定的小区容量和不满足设定条件(例如判断式(6)成立成立)，则返回到步骤(3)根据此时的临时小区容量重新执行步骤(3)，以更新临时小区容量中的每个小区容量参数的权重，并顺序执行后续步骤；如果确定的小区容量和满足设定条件(例如判断式(6)不成立)，则将此时的临时小区容量确定为多个小区的预测小区容量；

步骤(6)：根据确定的预测小区容量，基于神经网络模型预测每个时间敏感模块的占用的CPU资源，并基于预测的每个时间敏感模块占用的CPU资源和每个时间敏感模块的起始时间来确定空闲CPU资源。

通过以上过程，基于AI的小区容量决策过程最终可输出多个小区的预测小区容量和空闲CPU资源。

以上参照图3至图10E描述了确定多个小区的预测小区容量和空闲CPU资源的构成，下面将参照附图描述由基站执行的方法。

图11是示出根据本申请的示例性实施例的由基站执行的方法的流程图。

如图11中所示，在步骤S1110，获取所述基站的分布单元DU对应的多个小区的预测小区容量，所述预测小区容量是基于DU对应的多个小区的小区容量相关信息确定的。

如以上参照图3所描述的，所述多个小区的预测小区容量是由多个小区中的每一个小区的小区容量的参数集{RRC-UE,SRS-UE,SUS-UE,MU-Layer}组成的参数集，例如，如果存在C个小区，每个小区的小区容量由F个小区容量参数，则所述C个小区的预测小区容量是一个具有F×C个小区容量参数的参数集。

此外，步骤S1110获取的预测小区容量可以是在基站作为网络节点执行以上参照图3描述的方法时确定的预测小区容量。可选地，步骤S1110获取的预测小区容量也可以是基站从执行以上参照图3描述的方法的网络节点获取的。由于以上已经参照图3描述了基于小区容量相关信息确定DU对应的多个小区的预测小区容量的过程，因此这里不再进行赘述。

在步骤S1120，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

根据所述预测小区容量，针对每一个小区分配小区容量的步骤包括：确定DU的每个小区的优先级。下面参照图12对此进行描述。

图12是示出根据根据本申请的示例性实施例的确定DU的每个小区的优先级的过程的流程图。

如图12所示，在步骤S1210，根据每个小区的总业务量确定每个小区的排序因子。例如，可根据以下等式(9)确定每个小区的排序因子：

counter#c＝bo_size#c (9)

其中，counter#c表示第c个小区的排序因子，bo_size#c表示第c个小区的总业务量。

在步骤S1220，根据排序因子对所述多个小区进行降序排列，得到排序的小区列表，也就是说，将DU下的所述多个小区按照排序因子counter降序排列，形成排序的小区列表sorted_cell_list。

在步骤S1230，将所述小区列表中的最后预设数量个小区设置为低优先级，并将所述小区列表中的其余小区设置为高优先级。其中，所述预设数量是可配置的。至此，即可确定出DU的每个小区的优先级，但是本申请可通过改变排序因子counter#c来实现小区的动态排序，从而动态地改变小区的优先级，使得小区能够应用更合理的小区容量。

具体地讲，例如，可在经过可配置的预设更新周期以后或者在发生突发事件时或者根据用户需求，按照预设规则改变具有低优先级的小区的排序因子。例如，可经过可配置的预设更新周期以后或者在发生突发事件时或者根据用户需求，使所有低优先级的小区的排序因子增加1，即更新所有低优先级的小区的排序因子。然后重新执行步骤S1220，由于重新确定的每个小区的排序因子与原来的排序因子存在差异，因此，在步骤S1230根据排序因子对多个小区进行降序排序后得到的排序的小区列表可能会发生变化，进而导致小区的优先级发生变化，从而达到动态调整小区优先级的目的。也就是说，重新通过步骤S1220至S1230来执行优先级确定操作。此外，以上描述了一种对小区进行动态排序的方法，但是本申请不限于此，可根据不同的运营商需求按照不同标准来执行小区排序操作，从而确定具有高优先级需求的小区，例如，如果多个小区的覆盖范围内将举行重要会议或者赛事活动，则运营商可将该多个小区按照一定规则排列在小区列表的前边(即具有高优先级)，并将其他小区排列在小区列表的后边(即具有低优先级)，又或者，运营商可将具有VIP用户的小区排列在小区列表的前边(即具有高优先级)，并将具有普通用户的其他小区排列在小区列表的后边(即具有低优先级)，以上仅是示例性的，任何可对DU下的多个小区进行排序并分配优先级的方法均可应用于本申请。

根据所述预测小区容量，针对多个小区中的每一个小区分配小区容量的步骤还包括：根据每个小区的优先级，利用所述预测小区容量，针对各个小区分配小区容量。

具体地讲，根据每个小区的优先级，利用所述预测小区容量，针对每个小区分配小区容量的步骤包括：按照小区的优先级，依次针对每个小区进行以下操作：如果当前小区的优先级为高优先级，或者当前小区的优先级为低优先级且剩余的CPU资源不小于预设阈值，则基于所述预测小区容量为当前小区分配小区容量，并更新剩余的CPU资源；如果当前小区的优先级为低优先级且剩余的CPU资源小于所述预设阈值，则根据剩余的CPU资源确定当前小区的更新小区容量(即将被应用于当前小区的保护小区容量)，基于所述更新小区容量(即所述保护小区容量)为当前小区分配小区容量，并更新剩余的CPU资源。下面参照图13对此进行详细描述。

图13是示出根据本申请的示例性实施例的针对每个小区分配小区容量的过程的流程图。

如图13中所示，在步骤S1310，将小区ID设置为0，即从排序后的小区列表中的排在首位的小区开始进行后续操作。

在步骤S1320，判断当前小区是否为低优先级。如果当前小区的优先级不是低优先级(即当前小区的优先级是高优先级)，则进行到步骤S1330，将预测小区容量中的与当前小区对应的小区容量应用于当前小区，然后进行到步骤S1340，确定小区列表是否还有未分配小区容量的小区。如果小区列表为空，则结束，否则进行到步骤S1350，进行更新剩余的CPU资源，并更新小区ID，即，使小区ID加1，然后返回到步骤S1320以针对小区列表中的下一个小区分配小区容量。

如果在步骤S1320确定出当前小区是低优先级，则进行到步骤S1360，判断剩余的CPU资源是否小于预设门限值，其中，该预设门限值是可配置的。如果剩余的CPU资源不小于所述预设门限值，则进行到步骤S1330，即将预测小区容量中的与当前小区对应的小区容量应用于当前小区。

如果在步骤S1360确定出剩余的CPU资源小于所述预设门限值，则进行到步骤S1370，根据剩余的CPU资源确定当前小区的更新小区容量(即将被应用于当前小区的保护小区容量)，并在步骤S1380将确定的更新小区容量(即确定的保护小区容量)分配给当前小区，并进行到步骤S1340。其中，更新小区容量(即保护小区容量)小于预测小区容量中的与当前小区对应的小区容量，例如，如果当前小区是低优先级且剩余的CPU资源小于所述预设门限值，则仅停止运行DU上安装的当前小区的部分软件模块(主要与SUS-UE和MU_Layer参数有关)，但是停止部分软件模块并不会响应基本的小区功能，例如，在预测小区容量中的与当前小区对应的小区容量中，MU_Layer为8，当调度第3个MU_Layer时将使得剩余的CPU资源小于所述预设门限值，因此，其余的5个MU_Layer将被跳过以避免CPU资源枯竭，并且在确定更新小区容量(即保护小区容量)时将MU_Layer被重新设置为3，因此，更新小区容量小于预测小区容量中的与当前小区对应的小区容量，换句话说，更新小区容量中的小区容量参数的值(例如SUS-UE和MU_Layer的值)小于预测小区容量中的与当前小区对应的小区容量中的相应小区容量参数的值。

此外，在以上参照图13描述的针对每个小区应用小区容量的过程中所使用的排序的小区列表可根据参照图12描述的更新过程被更新，也可以不被更新。

通过参照图12和图13描述的关于步骤S1130的详细过程，可实时监控CPU资源的使用情况，如果发现存在CPU资源枯竭的风险，将保护小区容量应用于低优先级小区，从而避免CPU资源枯竭，消除潜在的小区崩溃风险。

此外，由基站执行的所述方法还可包括：获取DU的空闲CPU资源，所述空闲CPU资源是基于所述预测小区容量确定的；以及根据DU的空闲CPU资源，针对每个小区的处理模块中的时间不敏感模块分配DU的空闲CPU资源。

具体地，在这里，获取的空闲CPU资源可以是在基站作为网络节点执行以上参照图3描述的方法时确定的空闲CPU资源。可选地，在这里，获取的空闲CPU资源也可以是基站从执行以上参照图3描述的方法的网络节点获取的。由于以上已经参照图3描述了基于所述预测小区容量确定DU的空闲CPU资源的过程，因此，这里不再进行赘述。

在本申请的示例性实施例中，根据DU的空闲CPU资源，针对每个小区的处理模块(即软件模块)中的时间不敏感模块分配DU的空闲CPU资源的步骤包括：对每个小区的处理模块中的时间不敏感模块进行拆分，得到关于所述多个小区的多个时间不敏感子模块；根据DU的空闲CPU资源，针对所述多个时间不敏感子模块中的每一个子模块分配DU的空闲CPU资源。下面参照图14A和图14B详细描述对每个时间不敏感子模块分配空闲CPU资源的过程。

图14A是示出针对每个时间不敏感子模块分配空闲CPU资源的过程的流程图。

如图14A中所示，在步骤S1410，设置空闲资源索引Index＝1，即从空闲资源列表中的第一个空闲资源开始分配。

在步骤S1420，遍历所述多个时间不敏感子模块中的所有未分配资源的时间不敏感子模块，以寻找所需资源小于具有索引Index的当前空闲资源。

在步骤S1430，确定所有未分配资源的时间不敏感子模块中是否存在所需资源小于当前空闲资源的时间不敏感子模块。如果存在，则进行到步骤S1440，将当前空闲资源分配给所需资源小于当前空闲资源的一个时间不敏感子模块，并从空闲资源列表中删除当前空闲资源，然后进行到步骤S1450。

在步骤S1450，将步骤S1440中分配了资源的时间不敏感子模块设置为资源已分配状态，然后进行到步骤S1460。

在步骤S1460，确定空闲资源列表是否为空或者是否不存在尚未分配资源的时间不敏感子模块。

如果在步骤S1460，确定出空闲资源列表为空或者不存在尚未分配资源的时间不敏感子模块，则结束，否则，进行到步骤S1470，更新空闲资源索引Index，例如，使Index加1，即开始针对空闲资源列表中的下一个空闲资源进行分配，并返回到步骤S1420。

如果在步骤S1430确定出所有未分配资源的时间不敏感子模块中不存在所需资源小于当前空闲资源的时间不敏感子模块，则进行到步骤S1480，确定当前空闲资源是否是空闲资源列表中的最后一个空闲资源。

如果在步骤S1480确定出当前空闲资源是空闲资源列表中的最后一个空闲资源，则结束，否则，进行到步骤S1490，从空闲资源列表中删除当前空闲资源，并更新空闲资源索引Index，例如，使Index加1，即开始针对空闲资源列表中的下一个空闲资源进行分配。

通过以上空闲资源的分配，可使每个时间不敏感子模块尽可能地分配到空闲资源，从而提高碎片CPU资源的使用率。如图14B的(a)所示，现有技术中，时间不敏感模块1+2+3是一个大的处理模块，其单独占用了核心#2的一部分资源，然而在核心#0和核心#1的资源中间存在着空闲CPU资源，这些空闲CPU资源没有被充分利用，从而造成CPU资源的浪费，其CPU资源的使用率比较低，然而，如图14B的(b)所示，通过利用本申请的以上方法，可将时间不敏感模块拆分为时间不敏感子模块1、2和3，然后将核心#0和核心#1的资源中间存在的空闲资源分配给这些时间不敏感子模块1、2和3，而使得核心#2不被时间不敏感模块占用，提高碎片CPU资源的使用率。

图15A是示出本申请的示例性实施例的基于AI的小区容量决策确定和应用多个小区的预测小区容量和空闲CPU资源的总的处理流程图。在图15A中，虚线箭头表示数据流，实线箭头表示处理流。

如图15A中所示，首先，在步骤S1501，基站对共享一个CPU资源池的多个小区的处理模块(即软件模块)进行分类，将处理模块分类为时间关键模块、非时间关键模块和时间不敏感模块，其中，时间关键模块和非时间关键模块可被称为时间敏感模块，由于以上已经参照图3对此进行了详细描述，因此这里不再进行赘述。

在步骤S1502，基站向网络节点上报各个处理模块的处理模块限制，例如，可按照以上的表2所示的格式上报处理模块限制。

在步骤S1503，基站收集实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息，例如，可采用如图4所示的方式向网络节点上报这些信息。

在步骤S1508，网络节点根据获取的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息来训练神经网络模型，并且在训练期间还需要用到处理模块限制。以上已经参照图3对此进行了描述，这里不再进行赘述。训练好的神经网络模型会根据以上描述的临时小区容量预测每个时间敏感模块占用的CPU资源，并将预测出的每个时间敏感模块占用的CPU资源用于步骤S1505和S1506，以确定预测小区容量。

在步骤S1504，基站预测每个小区的目标小区容量，并将每个小区的目标小区容量上报给网络节点，例如，可根据历史信息和当前的实际小区容量确定目标小区容量，例如可根据以上的等式(1)来确定每个小区的目标小区容量。

在步骤S1505和步骤S1506，通过迭代地执行小区容量更新并判断更新后的小区容量是否可作为预测小区容量，以最终确定多个小区的预测小区容量，并且网络节点将确定的预测小区容量发送给基站。由于以上已经参照图5对此进行了详细描述，因此这里不再进行赘述。

在步骤S1507，基站根据获取的预测小区容量来针对每个小区分配小区容量。

在步骤S1509，网络节点根据预测小区容量，利用神经网络模型确定每个时间敏感模块占用的CPU资源，然后结合获取的处理模块限制中的每个时间敏感模块的起始时间来确定空闲CPU资源，形成空闲资源清单，并下发给基站。

在步骤S1510，基站将每个小区的时间不敏感模块拆分为多个时间不敏感子模块，并利用获取的空闲资源清单，针对多个时间不敏感子模块分配空闲CPU资源。

在步骤S1511，基站判断系统是否为活动状态，如果是则返回到步骤S1503，根据预设周期重新收集并上报实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息，然后执行后续处理。

由于以上步骤S1501至S1510已经参照图3至图14B进行了详细描述，因此这里不再对其细节进行赘述。

此外，在以上描述过程中，虽然步骤S1501、S1502、S1503、S1504、S1507、S1510和S1511由基站执行，步骤S1505、S1506、S1508、S1509由网络节点执行，但是根据先前的描述，网络节点执行的步骤可以由基站执行，或者基站执行的部分步骤可以由网络节点执行，本申请对此不作具体限定。

图15B是示出了根据本申请的示例性实施例的网络节点1500的框图。

如图15B中所示，网络节点1500包括收发器1510和处理器1520，其中，处理器1520与收发器1510耦接，并被配置为执行以上参照图3至图10E描述的由网络节点执行的方法。关于上述由网络节点执行的方法的操作的细节，可参见图3至图10E的描述，这里都不再赘述。

图16是示出了根据本申请的示例性实施例的基站1600的框图。

如图16中所示，基站1600包括收发器1610和处理器1620，其中，处理器1620与收发器1610耦接，并被配置为执行以上参照图11至图14B描述的由基站执行的方法。关于上述由基站执行的方法的操作的细节，可参见图11至图14B的描述，这里都不再赘述。

本申请提出的方法使得网络节点可以根据小区容量需求以及CPU资源占用情况，智能地调整同一个CPU资源池上的多个小区的容量，来实现CPU资源和小区容量的动态平衡，达到最大化CPU资源利用率，从而降低单个小区硬件成本的效果，并达到满足动态变化的小区容量需求，从而提升用户接入成功率以及提升小区吞吐量的效果。

以上分别描述了本申请的由网络节点执行的方法和对应的网络节点以及由基站执行的方法和对应的基站，下面按照三种不同场景来对比在应用本申请提出的方法时的效果与应用现有技术时的效果。

场景1：采用静态小区容量配置，不管实时小区需求如何，每个小区容量配置始终保持不变，考虑到CPU总资源是固定的，所以为了确保每个小区在大部分时间都可以满足需求，所以预留CPU资源会较多，导致最后一个CPU可以支持的小区数受限，单小区成本增加。如图17中的(a)和(b)所示，小区1和小区2由于实际容量需求小，所以导致CPU资源浪费。

采用本申请提出的方法，动态地调整每个小区的小区容量配置，进而保证所有小区整体容量最优，进而支持更多地小区，降低了单小区基站成本。

如图18中的(a)和(b)所示，与传统方案(静态小区容量配置)相比，本申请提出的方法对基站整体CPU利用率有44％的提升，在小区最大支持能力不变的情况下，单基站小区支持数提高了80％(5→9)，且并未发生小区各功能模块对于CPU使用超出具体限制而崩溃的现象。

场景2：在各小区采用静态小区容量配置时，在CPU资源不变的情况下，基站中无法满足各小区实时小区容量需求动态变化的需求。如图19中所示，当各个小区在不同时间段上实时小区容量需求出现变化时，对于静态小区容量配置，就会造成某一小区资源满载而同一基站(同一CPU内)下的另外小区资源冗余的情况，这样就会造成高负载小区中用户体验差(包括间歇性语音通话，下载速率低，不好的网页浏览/游戏/视频体验等)以及CPU资源(基站整体能力)的浪费(因为空闲小区由于固定的资源配置，依旧占用了CPU的固定资源而并没有用户需要小区调度)。

针对场景2，本申请通过动态监控资源需求，针对各小区当前所需的容量需求进行动态调整，既保证三个小区总CPU资源满足，同时又可以动态地提高小区2的小区容量配置，以适应实时需求。本申请提出的方法与现有技术的方案相比的结果如下表3所示(假设每个CPU内包括3个小区)：

[表3]

现有技术的方法	本申请提出的方法
		小区1:{400,128,42,16}	小区1:{150,64,24,4}
小区2:{400,128,42,16}	小区2:{500,128,42,16}
		小区3:{400,128,42,16}	小区3:{300,64,32,8}

场景3：当基站软件进行版本迭代更新时，由于硬件资源占用与软件模块的配置呈现非线性对应关系，对于各小区之前已经设定好的小区容量配置，可能已经不能适用于更新后的基站版本，且对每次测试的最终配置结果并不能保证是最佳方案，并且无法通过固定公式预测，只能重新通过大量且多维的配置测试进行重新配置，期间会消耗大量的人力物力，工作重复性很高，解决方式效率很低，产品的更新周期也会受到影响。

针对场景3，本申请提出的方法能够在原有训练模型的基础上，找到更新后的最优解，并且基于神经网络模型的持续性迭代训练，针对软件的更新也能对硬件资源使用与软件模块配置的对应关系进行及时的调整，在与传统人力测试效果相同的情况下，利用机器代替人力，既大大降低了人力成本，也不再对产品的版本迭代周期产生负面影响。具体分析如下：

(1)如以上的表1中所示，在多维配置参数的测试中，测试用例数量呈指数型递增，为避免消耗过多的人力及物力资源，只能进行采样测试，即使使用此种方式，也需要占用长时间的人力去进行这种重复性测试，且以固定间隔采样的配置取值，并不能保证资源的有效利用，而本申请提出的基于神经网络模型的方案既能够完美取代传统测试，神经网络模型模型也能相对准确的得出硬件资源占用与软件模块的配置的非线性对应关系，从而提高了配置准确度：

(2)实现各小区的动态资源调整，必须依靠神经网络模型提供的硬件资源占用与软件模块的配置的非线性对应关系，才能在提高基站整体能力的同时，确保CPU资源的正常使用。

此外，根据本申请的实施例，还可以提供一种电子设备，包括：至少一个处理器；以及至少一个存储计算机可执行指令的存储器，其中，所述计算机可执行指令在被所述至少一个处理器运行时，促使所述至少一个处理器执行以上述的由网络节点执行的方法或由基站执行的方法。

上述多个模块中的至少一个可以通过AI模型实现。与AI相关联的功能可以通过非易失性存储器、易失性存储器和处理器来执行。

作为示例，电子设备可以是PC计算机、平板装置、个人数字助理、智能手机、或其他能够执行上述指令集合的装置。这里，电子设备并非必须是单个的电子设备，还可以是任何能够单独或联合执行上述指令(或指令集)的装置或电路的集合体。电子设备还可以是集成控制系统或系统管理器的一部分，或者可被配置为与本地或远程(例如，经由无线传输)以接口互联的便携式电子设备。处理器可以包括一个或多个处理器。此时，一个或多个处理器可以是通用处理器，例如中央处理器(CPU)、应用处理器(AP)等，仅用于图形的处理器(例如图形处理器(GPU)、视觉处理器(VPU)和/或AI专用处理器(例如神经处理单元(NPU))。一个或多个处理器根据存储在非易失性存储器和易失性存储器中的预定义操作规则或AI模型来控制输入数据的处理。预定义的操作规则或AI模型可通过训练或学习提供。这里，通过学习提供意味着，通过将学习算法应用于多个学习数据，形成具有期望特性的预定义操作规则或AI模型。学习可以在根据实施例的执行AI的设备本身中执行，和/或可以通过单独的服务器/设备/系统来实现。

学习算法是使用多个学习数据来训练预定目标设备(例如，机器人)以使得、允许或控制目标设备做出确定或预测的方法。学习算法的例子包括但不限于有监督学习、无监督学习、半监督学习或强化学习。

AI模型可以通过训练获得。这里，“通过训练获得”是指通过训练算法训练具有多个训练数据的基本AI模型，从而获得预定义的操作规则或AI模型，所述操作规则或AI模型配置为执行所需的特征(或目的)。

作为示例，AI模型可以包括多个神经网络层。所述多个神经网络层中的每一个包括多个权重值，并且通过在前一层的计算结果和所述多个权重值之间的计算来执行神经网络计算。神经网络的例子包括但不限于卷积神经网络(CNN)、深度神经网络(DNN)、递归神经网络(RNN)、受限玻尔兹曼机(RBM)、深度置信网络(DBN)、双向递归深度神经网络(BRDNN)、生成式对抗网络(GAN)和深度Q网络。

处理器可运行存储在存储器中的指令或代码，其中，存储器还可以存储数据。指令和数据还可经由网络接口装置而通过网络被发送和接收，其中，网络接口装置可采用任何已知的传输协议。

存储器可与处理器集成为一体，例如，将RAM或闪存布置在集成电路微处理器等之内。此外，存储器可包括独立的装置，诸如，外部盘驱动、存储阵列或任何数据库系统可使用的其他存储装置。存储器和处理器可在操作上进行耦合，或者可例如通过I/O端口、网络连接等互相通信，使得处理器能够读取存储在存储器中的文件。

此外，电子设备还可包括视频显示器(诸如，液晶显示器)和用户交互接口(诸如，键盘、鼠标、触摸输入装置等)。电子设备的所有组件可经由总线和/或网络而彼此连接。

根据本申请的实施例，还可提供一种存储指令的计算机可读存储介质，其中，当所述指令由至少一个处理器执行时，促使所述至少一个处理器执行根据本申请示例性实施例的上述的由网络节点执行的方法或由基站执行的方法。这里的计算机可读存储介质的示例包括：只读存储器(ROM)、随机存取可编程只读存储器(PROM)、电可擦除可编程只读存储器(EEPROM)、随机存取存储器(RAM)、动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、闪存、非易失性存储器、CD-ROM、CD-R、CD+R、CD-RW、CD+RW、DVD-ROM、DVD-R、DVD+R、DVD-RW、DVD+RW、DVD-RAM、BD-ROM、BD-R、BD-R LTH、BD-RE、蓝光或光盘存储器、硬盘驱动器(HDD)、固态硬盘(SSD)、卡式存储器(诸如，多媒体卡、安全数字(SD)卡或极速数字(XD)卡)、磁带、软盘、磁光数据存储装置、光学数据存储装置、硬盘、固态盘以及任何其他装置，所述任何其他装置被配置为以非暂时性方式存储计算机程序以及任何相关联的数据、数据文件和数据结构并将所述计算机程序以及任何相关联的数据、数据文件和数据结构提供给处理器或计算机使得处理器或计算机能执行所述计算机程序。上述计算机可读存储介质中的指令或计算机程序可在诸如客户端、主机、代理装置、服务器等计算机设备中部署的环境中运行，此外，在一个示例中，计算机程序以及任何相关联的数据、数据文件和数据结构分布在联网的计算机系统上，使得计算机程序以及任何相关联的数据、数据文件和数据结构通过一个或多个处理器或计算机以分布式方式存储、访问和执行。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (27)

1.一种由网络节点执行的方法，包括：

获取与基站的分布单元DU对应的多个小区的小区容量相关信息；

基于所述小区容量相关信息，确定所述多个小区的预测小区容量，用于所述基站，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

2.如权利要求1所述的方法，其中，基于所述小区容量相关信息，确定所述多个小区的预测小区容量的步骤包括：

基于所述小区容量相关信息，确定在每个小区对应不同小区容量时所述DU对应的小区容量和；

基于满足设定条件的小区容量和，确定所述多个小区的预测小区容量。

3.如权利要求2所述的方法，其中，满足设定条件的小区容量和为确定出的各小区容量和中最大的小区容量和。

4.如权利要求2或3所述的方法，其中，所述小区容量相关信息中包括目标小区容量；

基于所述小区容量相关信息，确定在每个小区对应不同小区容量时所述DU对应的小区容量和的步骤包括：

基于每个小区对应的目标小区容量和当前小区容量，确定每个小区对应的当前小区容量中的每个小区容量参数的权重；

基于每个小区对应的当前小区容量以及当前小区容量中的每个小区容量参数的权重，确定所述DU对应的当前小区容量和。

5.如权利要求4所述的方法，其中，每个小区的目标小区容量是基于利用相应小区在本次预设周期的实际小区容量以及在上一预设周期估计的目标小区容量确定的。

6.如权利要求2-5中任一项所述的方法，其中，基于满足设定条件的小区容量和，确定每个小区的预测小区容量的步骤包括：

判断所述DU对应的当前小区容量和是否满足设定条件；

若是，则将每个小区对应的当前小区容量确定为所述多个小区的预测小区容量；

否则，更新每个小区对应的当前小区容量，并基于每个小区更新后的当前小区容量确定所述DU对应的当前小区容量和。

7.如权利要求6所述的方法，其中，判断所述DU对应的当前小区容量和是否满足设定条件的步骤包括：

当所述DU对应的当前小区容量和与上一次确定的小区容量和的差不大于设定阈值，或小区容量更新次数达到更新次数上限时，确认当前小区容量和满足设定条件。

8.如权利要求6或7所述的方法，其中，更新每个小区对应的当前小区容量的步骤包括：

基于每个小区对应的当前小区容量，预测每个小区的处理模块中，每个时间敏感模块占用的中央处理单元CPU资源；以及

基于预测出的每个小区的每个时间敏感模块占用的CPU资源，更新每个小区对应的当前小区容量。

9.如权利要求8所述的方法，其中，基于预测出的每个小区的每个时间敏感模块占用的CPU资源，更新每个小区对应的当前小区容量的步骤包括：

在每个小区的每个时间敏感模块占用的CPU资源不大于相应的资源占用上限值的条件下，更新每个小区对应的当前小区容量。

10.如权利要求8或9所述的方法，其中，基于每个小区对应的当前小区容量，预测每个小区的处理模块中，每个时间敏感模块占用的CPU资源的步骤包括：

基于每个小区对应的当前小区容量，利用神经网络模型预测每个小区的处理模块中的每个时间敏感模块占用的CPU资源。

11.如权利要求1-10中任一项所述的方法，还包括：

基于所述多个小区的预测小区容量，确定所述DU的空闲CPU资源，用于所述基站根据所述空闲CPU资源，针对所述多个小区中的时间不敏感模块分配CPU资源。

12.如权利要求11所述的方法，其中，基于所述多个小区的预测小区容量，确定所述DU的空闲CPU资源的步骤包括：

基于所述多个小区的预测小区容量，利用神经网络模型确定每个小区的处理模块中，时间敏感模块占用的CPU资源；

基于时间敏感模块占用的CPU资源以及时间敏感模块运行的起始时间，确定DU的空闲CPU资源。

13.如权利要求12所述的方法，其中，确定DU的空闲CPU资源的步骤包括：

基于时间敏感模块占用的CPU资源以及时间敏感模块运行的起始时间，确定时间敏感模块运行的结束时间；

基于时序相邻的时间敏感模块运行的起始时间和结束时间，确定空闲CPU资源。

14.如权利要求10、12-13中任一项所述的方法，还包括：

基于每个小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息，对所述神经网络模型进行训练。

15.如权利要求1-14中任一项所述的方法，其中，所述小区容量包括下述至少一项：

最多支持的用户设备UE个数；最多支持的配置探测参考信号SRS的UE个数；最多支持的多用户调度MU候选UE个数；最多支持的MU层数。

16.如权利要求1-15中任一项所述的方法，所述网络节点包括：基站、开放式无线接入网O-RAN中的无线接入网智能控制器RIC。

17.如权利要求1-16中任一项所述的方法，其中，获取与基站的DU对应的多个小区的小区容量相关信息的步骤包括：

从基站的DU获取对应的多个小区的小区容量相关信息，

其中，所述方法还包括：

将所述预测小区容量发送给所述基站，用于所述基站根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

18.如权利要求1-17中任一项所述的方法，其中，所述小区容量相关信息包括下述至少一项：

小区的实际小区容量和关于与实际小区容量对应的占用的CPU资源的信息、以及小区的目标小区容量。

19.一种由基站执行的方法，包括：

获取所述基站的分布单元DU对应的多个小区的预测小区容量，所述预测小区容量是基于DU对应的多个小区的小区容量相关信息确定的；以及

根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量。

20.如权利要求19所述的方法，其中，根据所述预测小区容量，针对所述多个小区中的每一个小区分配小区容量的步骤包括：

确定DU对应的多个小区中的每个小区的优先级；以及

根据每个小区的优先级，利用所述预测小区容量，针对各个小区分配小区容量。

21.如权利要求20所述的方法，其中，根据每个小区的优先级，利用所述预测小区容量，针对各个小区分配小区容量的步骤包括：按照小区的优先级，依次针对每个小区进行以下操作：

如果当前小区的优先级为高优先级，或者当前小区的优先级为低优先级且剩余的CPU资源不小于预设阈值，则基于所述预测小区容量为当前小区分配小区容量，并更新剩余的CPU资源；

如果当前小区的优先级为低优先级且剩余的CPU资源小于所述预设阈值，则根据剩余的CPU资源确定当前小区的更新小区容量，基于所述更新小区容量为当前小区分配小区容量，并更新剩余的CPU资源。

22.如权利要求19-21中任一项所述的方法，还包括：

获取DU的空闲CPU资源，所述空闲CPU资源是基于所述预测小区容量确定的；以及

根据DU的空闲CPU资源，针对每个小区的处理模块中的时间不敏感模块分配DU的空闲CPU资源。

23.如权利要求22所述的方法，其中，根据DU的空闲CPU资源，针对每个小区的处理模块中的时间不敏感模块分配DU的空闲CPU资源的步骤包括：

对每个小区的处理模块中的时间不敏感模块进行拆分，得到关于所述多个小区的多个时间不敏感子模块；

根据DU的空闲CPU资源，针对所述多个时间不敏感子模块中的每一个子模块分配DU的空闲CPU资源。

24.一种网络节点，包括：

收发器；以及

处理器，与所述收发器耦接，并被配置为执行如权利要求1至18中的任意一项所述的方法。

25.一种基站，包括：

收发器；以及

处理器，与所述收发器耦接，并被配置为执行如权利要求19至23中的任意一项所述的方法。

26.一种电子设备，包括：

至少一个处理器；以及

至少一个存储计算机可执行指令的存储器，

其中，所述计算机可执行指令在被所述至少一个处理器运行时，促使所述至少一个处理器执行如权利要求1至23中的任意一项所述的方法。

27.一种存储指令的计算机可读存储介质，其中，当所述指令被至少一个处理器运行时，促使所述至少一个处理器执行如权利要求1至23中的任意一项所述的方法。