EP4367927A1

EP4367927A1 - Cpu-aware intelligent radio controller

Info

Publication number: EP4367927A1
Application number: EP22706752.7A
Authority: EP
Inventors: Josep Xavier Salvat Lozano; Andres GARCIA-SAAVEDRA; Xi Li; Xavier COSTA-PÉREZ
Original assignee: NEC Laboratories Europe GmbH
Current assignee: NEC Laboratories Europe GmbH
Priority date: 2021-09-03
Filing date: 2022-02-02
Publication date: 2024-05-15
Also published as: EP4353004A1; WO2023030695A1; WO2023030694A1

Abstract

The present invention relates to a computer-implemented method of resource allocation for multiple virtualized base stations, vBSs (420), deployed in a shared radio computing platform (410), wherein the vBSs (420) share the same Radio Unit, RU (430), having a fixed number of Physical Resource Blocks, PRBs. With respect to an efficient utilization of both radio resources and available computing resources, the method comprises obtaining, by a radio controller, a set of metrics from the radio computing platform (410) for each of the vBSs (420) deployed; learning, by a learning agent (450) of the radio controller based on the obtained set of metrics, the traffic patterns and the CPU consumption of the vBSs (720) deployed; and computing, by the radio controller based on the knowledge of current CPU set configurations of the vBSs (420) and based on the learned traffic patterns and the CPU consumption of the vBSs (420), a CPU set configuration, L3 cache allocation and PRB assignment for each vBS (420) in such a way that at least one of the overall CPU overhead, the decoding time and SLA violations are minimized.

Description

CPU-AWARE INTELLIGENT RADIO CONTROLLER

The present invention relates to a computer-implemented method of resource allocation for multiple virtualized base stations, vBSs, deployed in a shared radio computing platform, wherein the vBSs share the same Radio Unit, RU, having a fixed number of Physical Resource Blocks, PRBs.

Furthermore, the present invention relates to a radio controller for resource allocation for multiple virtualized base stations, vBSs, deployed in a shared radio computing platform, wherein the vBSs share the same Radio Unit, RU, having a fixed number of Physical Resource Blocks, PRBs.

The fifth-generation (5G) of wireless networks promises to bring new advancements to the table, such as a massive increase in mobile data rates, a decrease in communications latency, and an increase in the perceived quality of experience by users, all while coping with the ever-increasing demand in Internet traffic. Several significant advances will be included in the new 5G network in order for it to deliver on its promises. 5G, like previous wireless network generations, would use higher frequency bands (e.g., sub 6GHz and 24GHz) and smaller cells, with more cells deployed to improve user capacity. As a result, the future 5G mobile network will be an ultra-dense mesh with seamless coverage, increased user data rates, and low latency communications.

However, a dense network comes at a significant cost in capital and operating expenses (CAPEX/OPEX). To begin, operators must deploy more radio equipment to cover the same area as cells give coverage to smaller locations. Moreover, as cells are smaller, user changes between them are more likely, making mobility management more difficult. Additionally, as the network grows, upgrading equipment and detecting faults becomes more difficult. Therefore, Mobile Network Operators (MNOs) are actively pushing to virtualize all of the mobile network's components to address the issues mentioned above.

Virtualization softwarizes network functions (NFs) (such as firewalls, load balancers, and intrusion detection systems) so that they can run on commercial off-the-shelf (COTS) hardware instead of proprietary hardware. A virtualized NF runs in a virtual environment separated from other host processes. This offers many benefits. To begin with, it frees operators from choosing a single vendor for their NFs because they now run as software. This makes it simple to upgrade, replace, and deploy NFs; in other words, virtualization allows to the orchestration of the various virtual network components. Many of the most important components of a mobile network are already virtual. In most mobile networks, the core network components (e.g., Mobility Management Entity (MME), Serving Gateway (SGW), and so on) are already virtualized. Second, virtual environments can be adapted to each NF's specific needs. A NF may need to run on a different operating system than the host or require particular libraries. Because numerous virtualized environments can be created on a single host, multiple NFs can be executed in the same location, enhancing total resource utilization.

Radio Access Networks virtualization (vRAN) is the next step toward a fully virtualized mobile network. vRAN virtualizes RAN functionality into a centralized location, resulting in lower costs due to the use of generic hardware, better resource utilization due to multiple RANs sharing the same host, and increased flexibility due to the ease with which updates and control and management operations can be performed.

It is an object of the present invention to improve and further develop a method of resource allocation for multiple vBSs and a radio controller of the initially described type in such a way that radio resources and available computing resources are utilized in an optimized way in terms of efficiency.

In accordance with the invention, the aforementioned object is accomplished by a computer-implemented method of resource allocation for multiple virtualized base stations, vBSs, deployed in a shared radio computing platform, wherein the vBSs share the same Radio Unit, RU , having a fixed number of Physical Resource Blocks, PRBs, the method comprising obtaining, by a radio controller, a set of metrics from the radio computing platform for each of the vBSs deployed; learning, by a learning agent of the radio controller based on the obtained set of metrics, the traffic patterns and the CPU consumption of the vBSs deployed; and computing, by the radio controller based on the knowledge of current CPU set configurations of the vBSs and based on the learned traffic patterns and the CPU consumption of the vBSs, a CPU set configuration, L3 cache allocation and PRB assignment for each vBS in such a way that at least one of the overall CPU overhead, the decoding time and SLA violations are minimized.

Furthermore, the aforementioned object is accomplished by a radio controller and by a tangible, non-transitory computer-readable medium according to the independent claims.

Embodiments of the invention provide a resource allocation method and a radio controller that mitigate the CPU overhead of a radio computing platform with multiple vBSs deployed. According to embodiments, the method and the controller use a learning agent which adapts the L3 cache memory, the CPU sets and PRBs allocated to each of the vBSs deployed to reduce the overhead.

According to embodiments, the present invention relates to a CPU-aware intelligent radio controller that controls the resource allocation of multiple virtualized base stations in a shared computing platform and that mitigates CPU overhead. ‘CPU- aware’ means that the controller has knowledge about the current CPU set configurations of the vBSs. In an embodiment, the method comprises a host located at the edge of a mobile network used to deploy multiple vBSs. The method may further comprise the allocation of CPU sets, L3 cache (Level3 cache memory), PRBs (Physical Resource Blocks) to multiple vBSs according to the uplink and downlink traffic and SNR (Signal to Noise ratio) of vBSs, and maintaining CPU overhead with decrease in decoding time and SLA (Service Level Aggregation) violation. The controller may use a deep reinforcement learning technique to learn the traffic pattern of CPUs of vBS and select the best configuration for assigning a best computer capacity to different vBSs, thereby addressing noisy neighbors.

According to embodiments of the invention, the computing of the CPU set configuration, L3 cache allocation and PRB assignment for each vBS may be performed by taking into account noisy neighbors. The noisy neighbor problem describes the effect that CPU usage does not scale linearly with the number of vBSs deployed, which is due to additional computing overhead caused by the system when all vBSs share the same physical CPU resources. In other words, in the context of the present disclosure, the noisy neighbor problem describes an increased resource consumption due to the resources contentions between different vBSs deployed in the same infrastructure. Current state-of-the-art techniques do not take it into account the noisy neighbor’s problem. Minimizing the overall CPU overhead is key so that more vBSs can be deployed into the system and boost revenue. Generally, it can be noted that by taking into account the noisy neighbor problem, efficiency can be increased when doing resource allocation.

According to embodiments of the invention, the radio computing platform may include some monitoring capabilities. In particular, it may be provided that the radio computing platform includes an agent that is configured to obtain the set of metrics, in particular a set of performance metrics, by performing respective measurements and to store the measurement results for the set of metrics in a metrics database. In an embodiment, the set of performance metrics of each of the vBSs includes at least one of CPU usage, uplink and downlink bitrate, buffer status report on uplink and downlink, uplink Signal-to-Noise Ratio, SNR, downlink Channel Quality Indicator, CQI, and decoding time. In addition, the metrics may include the number of cache misses per code instruction executed by a process (e.g. measured as the number of caches misses divided by the number of instructions executed during a certain period of time) and/or CPU cycles per instruction (i.e. CPU cycles divided by the number of instructions executed during a certain period of time). According to embodiments of the invention, the radio controller is configured to have access to the aforementioned metrics for each vBS deployed in the edge host.

According to embodiments of the invention, it may be provided that a limit is set to the number of PRBs that can be allocated to individual ones of the vBSs. Reducing the number of PRBs assigned to a vBS is possible since a vBS is unlikely to function at full capacity all of the time. In turn, limiting the number of PRBs that can be allocated reduces the cache usage and decoding time, thereby lowering the cost of context switching, which causes the CPU overhead. According to embodiments of the invention, it may be provided that the L3 cache memory size allocated to each vBS is adapted depending on the uplink and downlink traffic and the SNRs of the vBS deployed. By configuring the size of the L3 cache allocated to each vBS depending on the traffic patterns, the cost of the context switching will be reduced, which in turn decreases the contention between different vBS.

According to embodiments of the invention, learning the traffic patterns and the CPU consumption of the vBSs deployed is performed by the learning agent based on a training dataset using Contextual Bayesian and/or reinforcement learning techniques. The learning agent may be configured to fetch the set of metrics from the metrics database. Based thereupon, the learning agent may be configured to use a learning algorithm that operates on an input context vector including, per deployed vBS, a predicted SNR value, a predicated traffic in downlink value and a predicted traffic in uplink value.

According to embodiments of the invention, the learning agent may be configured to use a learning algorithm that produces an output action vector including, per deployed vBS, a number PRBs allocated per deployed vBS, a CPU set allocated to each deployed vBS and a L3 cache memory assigned per deployed vBS.

According to embodiments of the invention, the learning agent may be configured to compute a loss value for each pair of input context and output actions, the loss value indicating how good a particular action was that the learning agent took for a particular context. The loss value may be calculated as a mix between the packet losses, the decoding time and the CPU overhead.

According to embodiments of the invention, the learning agent may be configured to communicate the computed CPU set configuration, L3 cache allocation and PRB assignment for each vBS via the radio computing platform’s interfaces. More specifically, it may be provided that the radio controller (and thus the learning agent) has access to the radio and computing control APIs of the radio computing platform (e.g. an edge host of a mobile network) where the different vBSs will be deployed. In particular, the radio controller may have access to the following control operations and functions:

Control of the deployment of a new vBS. Access to the configuration of the deployment;

Control on the CPU set configurations of the vBS;

Control of the number of PRBs of a vBS;

Access to an interface that allows changing the L3 cache allocation per vBSs.

According to embodiments of the invention, the learning agent may be configured to run in discrete time intervals. This time intervals can be regarded as decision intervals in the sense that, at the beginning of each interval, the learning agent changes the configuration of vBSs to minimize the overall CPU overhead.

According to embodiments of the invention, the learning agent may be configured to run in a different location than the radio computing platform in a controlled environment. This has the advantage that the learning agent execution does not interfere with the execution of the vBSs, which may matter in view of the fact that the computing resources at the edge are limited (and should therefore be used by the necessary processes only, i.e. the deployed vBSs).

According to embodiments of the invention, the vBSs may be deployed in the radio computing platform by using hypervisors, which would be easy to implement as hypervisors are currently the most common virtualization technique to spawn multiple virtual machines. Alternatively, the vBSs may be deployed in the radio computing platform in containers, which would constitute a more lightweight virtualization.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the dependent claims on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the figure on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the figure, generally preferred embodiments and further developments of the teaching will be explained. In the drawing Fig. 1 is a diagram illustrating CPU consumption depending on the number of deployed vBS instances running at maximum traffic,

Fig. 2 is a schematic view illustrating the CPU topology of an intel i7 processor according to prior art, and

Fig. 3 is a diagram illustrating the CPU overhead when using different CPU sets, and

Fig. 4 is a schematic view illustrating a system architecture of a CPU-aware intelligent radio controller according to an embodiment of the present invention.

In deployment scenarios addressed by embodiments of the present invention, multiple virtualized base stations (vBSs) are installed in a single host platform, as schematically shown in Fig. 4. Despite the gains that vRAN promises when running multiple vBSs, given maximum traffic in both uplink and downlink, the CPU usage results are surprisingly high.

As can be obtained from Fig. 1 , the CPU utilization does not grow linearly with the number of virtual BS instances deployed in the system. This is counterintuitive as one would expect a linear increase because each vBS runs in a virtual environment ‘isolated’ from other host processes, e.g. in a container.

In accordance with embodiments of the present invention, it has been recognized that the primary cause of CPU overhead is due to the vBSs’ process dynamics paired with process scheduling. A vBS execution process always follows the same steps: (1) The vBS wakes up when fresh radio samples are received from the vBS’s RF (Radio Frequency) hardware; (2) it processes the radio samples; (3) it produces new radio samples and delivers them back to the RF hardware; and (4) it snoozes while waiting for more radio samples. A vBS process, in other words, is continually waking up and blocking itself. Because each process has a time constraint of a few milliseconds, the vBS logic must run exceptionally quickly. Threads in vBSs (at least those interacting with the PHY and MAC layers) are frequently given real-time priority so that the CPU scheduler in place (e.g. a Linux CPU scheduler) will always choose to run them unless they block themselves deliberately. This reduces the running delay caused by scheduler thread queues; real-time priority threads are usually appropriate for low latency applications.

Due to the tight time constraints and the wake-up-execute-snooze vBS sequence, the CPU scheduler of the system that hosts the vBSs has to handle a significant amount of work caused by context switching. When a vBS snoozes waiting for further radio samples, the CPU scheduler either switches the process running in the CPU or releases the CPU if no other process requires it. The switching action has a cost because the state of the process must be stored if the process does not complete its execution. The scheduler must save its registers and cache information so that when the execution resumes, the CPU scheduler can restore them. The overhead of storing registers is usually tiny, but saving the cache state might be substantially heavier due to the larger quantity of the data that must be saved and restored (approx, megabytes size). As a result of the high-speed switching of vBS threads, they tend to evict each other’s data as they wake up and block in few milliseconds. As a result, the cache fighting caused by too many threads degrades the overall system performance.

Although the issue described above cannot be avoided, several strategies can help reduce CPU overhead. To begin, selecting the appropriate CPU set for each vBS is critical for lowering overhead. Containers allow specifying the CPU set, which is essential for reducing cache congestion. For example, Fig. 2 shows the CPU topology of an intel i7 processor 200. Inside the processor 200, various CPU cores 210 share different cache levels.

Cache memory is the fastest but smallest memory in a computer. It is divided into three levels. Level 1 (L1) cache is the fastest memory of a computer, but its size is minimal (~ 64KB). Level 2 (L2) cache is the second fastest, and its size is a bit bigger than L1 (-256KB). Both L1 and L2 are dedicated per pair of CPU cores 210. That is, each pair of CPU cores 210 has its L1 and L2 cache memory 220. For instance, as shown in Fig. 2, L1 and L2 caches 220 are shared in pairs of CPUs {0, 4}, {1 ,5}, {2, 6}, {3, 7}. On the other hand, Level 3 (L3, also known as Las Level Cache (LLC)) cache 230 is the slowest cache memory, but its size is bigger (-16MB). In contrast with L1 and L2 cache 220, it is shared across all the CPUs 210.

As it is extremely limited in size, CPUs only load the most used values to cache memory. It is important to remark that one CPU core can usually run more than one thread. The operating system sees these threads as available CPUs. For example, if a CPU has four cores and eight threads, the OS will understand this as eight available CPUs to execute different processes. However, threads that run in the same CPU core will share L1 and L2 caches, as these are dedicated per CPU core but not per thread, as shown in Fig. 2 and as explained above.

As already mentioned above, the L1 and L2 caches 220 are shared across pairs of CPUs {0,4}, {1 ,5}, {2, 6}, {3, 7}, while all CPUs share the same L3 cache 230. The L3 cache 230 is generally separated by several cores (known as NUMA cores) in server processors. As a result, putting the separate vBSs in CPU sets that share as few caches as possible directly influences the system’s overall CPU overhead because threads will content the CPU caches less.

Fig. 3 is a diagram showing the CPU overhead when using a processor with the same design as shown Fig. 2. In the case of two vBSs deployed, they were placed in CPUs 1 and 2 (Unshared CPUs case) and CPUs 1 and 5 (Shared CPUs case). In the case of four vBSs, they were placed in CPUs 0,1 ,2,3 (Unshared CPUs) and CPUs 1 ,5,2, and 6 (Shared CPUs). As shown, the CPU use of vBSs in cores with less shared cache levels reduces the overall CPU use of the system by a significant percentage. However, an utterly unshared placement, on the other hand, would decrease the number of vBSs that can be allocated in the system. For example, with the CPU layout shown in Fig. 2, it would only be possible to allocate 4 vBSs for 8 CPUs if maximum isolation is desired. It would be ideal to find a configuration in which all of the vBSs in a system share a set number of CPUs, reducing overall CPU overhead while allowing for the deployment of more vBSs.

Second, one can decide the L3 cache allocation per vBS. As L3 is shared across all CPU cores, it is possible to limit its usage per vBS. For instance, if the L3 cache has 16MB, it can be partitioned such that 10MB are given to a first vBS and 6MB to a second vBS. L3 cache allocation also reduces the contention between vBSs. However, allocating less L3 cache memory per vBS increases the decoding time, as more cycles are needed per program instruction. In detail, less L3 cache memory available may increase the number of cache misses per instruction, but reduces the cost of context switching. To compensate the increase in the decoding time, the number of PRBs in both uplink and downlink can be adapted to the traffic that a vBS is sending or receiving. However, decreasing the PRBs reduces the amount of traffic a vBS can send or receive. This is risky in a context where traffic might have unpredictable peaks.

Embodiments of the present invention provide a novel approach for allocating at least one of CPU sets, L3 cache, and PRBs to distinct vBSs while minimizing at least one of CPU overhead, decoding time, and the possibility of violating the SLA. The solution according to embodiments of the invention learns the traffic patterns and CPU usage of the vBSs deployed in the system and selects the best configuration for them. Other comparable studies include vrAln (for reference, see Ayala-Romero, Jose A., et al. “vrAln: A deep learning approach tailoring computing and radio resources in virtualized RANs.” The 25th Annual International Conference on Mobile Computing and Networking. 2019.), which uses a deep reinforcement learning strategy to assign computer capacity to different vBS. When distributing different resources to the vBSs, embodiments of the present invention take into account the noisy neighbor problem, which is different from vrAln.

Fig. 4 schematically illustrates, in accordance with an embodiment of the present invention, a CPU aware intelligent radio controller that reduces overall CPU overhead in multitenant vRAN deployments by taking various actions. The possible implementation shown in Fig. 4 considers a radio computing platform 410 in which numerous vBS 420 use the same Radio Unit (RU) 430 (i.e. sharing the same radio resources), which has a fixed number of PRBs. Embodiments of the invention aim at finding the best configuration of the CPU set, L3 cache allocation, and PRB allocation while minimizing the overall CPU overhead, decoding time and SLA violations according to the uplink and downlink traffic and SNR of each vBS 420.

In accordance with embodiments of the invention, a host, e.g. the radio computing platform 410 shown in Fig. 4, located at the edge of a mobile network is used to deploy different vBSs, e.g. the VBs 420 shown in Fig. 4. The host includes or may be configured to communicate with a metric agent (not explicitly shown in Fig. 4), which takes different metrics from the host and the vBSs 420 currently deployed. These metrics may be saved into a metrics database 440, which may be deployed in a different location.

In detail, according to embodiments of the invention, the following metrics may be provided per vBS 420:

CPU usage of each vBS 420 deployed (in %);

Uplink and downlink bitrate (in Mbits/sec);

Buffer status report on uplink and downlink per slice, i.e. per vBS 420 deployed (in bits);

- Uplink SNR (in dB);

Downlink CQI (Channel Quality Indicator);

Decoding time (in microseconds);

Misses per instruction;

Cycles per instruction.

Apart from these metrics, embodiments of the invention also use information on the CPU topology. In detail, the following configuration parameters may be provided:

CPU topology. In detail, the number of NUMA cores, CPU cores and threads per CPU and the cache structure;

The size of L1 , L2 and L3 caches.

Finally, for each vBS 420 deployed, embodiments of the invention may also use information regarding its deployment, in particular with regard to the vBSs’ 420 network slice SLAs. As shown in Fig. 4, according to embodiments of the invention the radio controller may include a learning agent 450 that may run in a different location than the edge host, i.e. the radio computing platform 410, but can reach and has access to the radio computing platform’s 410 control interfaces. Specifically, the learning agent 450 may have access to the following control interfaces:

- Number of PRBs allocated to each vBS;

- CPU set allocated to each vBS;

- L3 cache size allocated to each vBS.

As previously stated, because a vBS 420 cannot change its logic, CPU overhead is unavoidable; however, in accordance with embodiments of the present invention it has been recognized that choosing the appropriate CPU sets, limiting the L3 cache memory and allocating the correct number of PRBs is critical in order to deploy as much vBS 420 as possible. According to embodiments of the invention, in order to configure each vBS 420 and the radio computing platform 410, the radio controller may be configured to make several crucial decisions.

First, the radio controller may be configured to learn the traffic patterns of the vBSs 420 placed in the host 410 and the relation to the CPU usage. Second, the radio controller may be configured to configure the PRBs, CPU cache and sets on each vBS 420 to reduce CPU cache contention at the cost of a minimal increase in decoding time and the possibility of violating the SLAs.

As previously stated, the traffic a vBS 420 processes is related to CPU use and the host’s 410 CPU overhead. Because a vBS 420 is unlikely to function at full capacity all of the time, the number of PRBs assigned to a vBS 420 can be reduced to reduce the cache usage and decoding time, lowering the cost of context switching, which causes the CPU overhead. As a result, the first decision that the radio controller according to an embodiment of the present invention may take is to limit the number of PRBs per vBS 420 to reduce the decoding time while decreasing the potential use of the L3 cache due to noisy neighbors. This will ensure that the host 410 has enough CPU capacity to deploy further vBS 420. Second, according to an embodiment of the invention, the radio controller may be configured to select a CPU set for any newly deployed slice, i.e. vBS, that reduces the host’s 410 CPU overhead, as CPU sets with fewer cache levels contribute less to the CPU overhead.

Finally, according to an embodiment of the invention, the radio controller may be configured to configure the size of the L3 cache allocated to each vBS 420 depending on the traffic patterns. This reduces the cost of the context switching which decreases the contention between different vBS 420.

In an embodiment, the radio controller algorithm may be based on the Contextual Bayesian learning technique. The learning agent 450 may run in discrete time intervals (that can be regarded as decision intervals) of predefined or configurable length. At the beginning of each interval, the learning agent 450 may take an action about the configuration of the vBSs 420 deployed in the edge host/radio computing platform 410.

According to embodiments of the invention, the input of the radio controller algorithm may be a context vector with at least some of the following values per vBS 420:

- Predicted SNR value: The uplink SNR and downlink CQI may be mapped to an SNR value between 0 and 1. According to an embodiment of the invention, past data from a vBS 420 can be used to create a mapping using machine learning or calibrate one vBS 420 to map them between 0 and 1. 0 means a low SNR context, and 1 mean a very high SNR context;

- Predicted traffic in downlink: The downlink traffic may be predicted as a percentage of the maximum traffic that can be achieved with the predicted SNR. As SNR sets the maximum MCS that a vBS 420 can use, it is advantageous to predict the maximum downlink traffic as a percentage of the maximum bitrate achievable with the maximum MCS that can be used. The traffic may be predicted using the data of previous intervals;

- Predicted traffic in uplink: The uplink traffic may be predicted analogously as the prediction of the downlink traffic, i.e. as a percentage of the maximum traffic that can be achieved with the predicted SNR. According to embodiments of the invention, the output of the radio controller algorithm may be a vector of actions per vBS 420 (output-actions vector) with at least some of the following values:

- Number of PRBs: Number of PRBs allocated to each vBS 420 deployed;

- CPU set: CPU set allocated to each vBS 420.

- L3 cache memory: L3 cache memory assigned per vBS 420.

According to embodiments of the present invention, the learning agent 450 may be trained in a separated and controlled environment where a loss value is computed for each pair of input context and output actions. The loss value indicates how good the actions the learning agent 450 took for that particular context were. In an embodiment it may be provided to compute the loss values as a mix between the packet losses, the decoding time and the CPU overhead. Then, the 3-tuple by the context, action, and loss value may be registered into the learning agent 450 so that the model of the computing platform 410 is further learned.

To summarize, embodiments of the present invention relate to some of the following aspects and advantages: vBSs configuration optimization approach that, taking into account noisy neighbors, aims at minimizing the CPU overhead of the system were the different vBS are deployed.

The controller adapts the cache memory size depending on the uplink and downlink traffic and SNR of each vBSs. To compensate the increase in the decoding time of the vBSs, the radio controller limits the number of PRBs of each deployed vBS to the current traffic trying to balance the risk of penalizing the SLA and the increase in the decoding time.

The controller is aware of the CPU set the different vBS are currently using and assigns the CPU set of the vBS in a way it minimizes the overall CPU overhead. In this way, the cache contention in L1 and L2 is minimized.

Many modifications and other embodiments of the invention set forth herein will come to mind to the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. A computer-implemented method of resource allocation for multiple virtualized base stations, vBSs (420), deployed in a shared radio computing platform (410), wherein the vBSs (420) share the same Radio Unit, RU (430), having a fixed number of Physical Resource Blocks, PRBs, the method comprising: obtaining, by a radio controller, a set of metrics from the radio computing platform (410) for each of the vBSs (420) deployed; learning, by a learning agent (450) of the radio controller based on the obtained set of metrics, the traffic patterns and the CPU consumption of the vBSs (420) deployed; and computing, by the radio controller based on the knowledge of current CPU set configurations of the vBSs (420) and based on the learned traffic patterns and the CPU consumption of the vBSs (420), a CPU set configuration, L3 cache allocation and PRB assignment for each vBS (420) in such a way that at least one of the overall CPU overhead, the decoding time and SLA violations are minimized.

2. The method according to claim 1 , wherein the computing of the CPU set configuration, L3 cache allocation and PRB assignment for each vBS (420) is performed by taking into account noisy neighbors.

3. The method according to claim 1 or 2, wherein the set of metrics of each of the vBSs (420) includes at least one of CPU usage, uplink and downlink bitrate, buffer status report on uplink and downlink, uplink Signal-to-Noise Ratio, SNR, downlink Channel Quality Indicator, CQI, and decoding time.

4. The method according to any of claims 1 to 3, further comprising: setting a limit to the number of PRBs that can be allocated to individual ones of the vBSs (420).

5. The method according to any of claims 1 to 4, further comprising: adapting the L3 cache memory size allocated to each vBS (420) depending on the uplink and downlink traffic and the SNRs of the vBS (420) deployed.

6. The method according to any of claims 1 to 5, wherein learning the traffic patterns and the CPU consumption of the vBSs (420) deployed is performed by the learning agent (450) based on Contextual Bayesian learning techniques.

7. The method according to any of claims 1 to 6, wherein the learning agent (450) uses a learning algorithm that operates on an input context vector including, per deployed vBS (420), a predicted SNR value, a predicated traffic in downlink value and a predicted traffic in uplink value, and wherein the learning agent (450) produces an output action vector including, per deployed vBS (420), a number PRBs allocated per deployed vBS (420), a CPU set allocated to each deployed vBS (420) and a L3 cache memory assigned per deployed vBS (420).

8. The method according to claim 7, wherein the learning agent (450) computes a loss value for each pair of input context and output actions, wherein the loss value is calculated as a mix between the packet losses, the decoding time and the CPU overhead.

9. A radio controller for resource allocation for multiple virtualized base stations, vBSs (420), deployed in a shared radio computing platform (410), wherein the vBSs (420) share the same Radio Unit, RU (430), having a fixed number of Physical Resource Blocks, PRBs, the radio controller comprising one or more processors that, alone or in combination, are configured to provide for the execution of the following steps: obtaining, by a radio controller, a set of metrics from the radio computing platform (410) for each of the vBSs (420) deployed; learning, by a learning agent (450) of the radio controller based on the obtained set of metrics, the traffic patterns and the CPU consumption of the vBSs (420) deployed; and computing, by the radio controller based on the knowledge of current CPU set configurations of the vBSs (420) and based on the learned traffic patterns and the CPU consumption of the vBSs (420), a CPU set configuration, L3 cache allocation and PRB assignment for each vBS (420) in such a way that at least one of the overall CPU overhead, the decoding time and SLA violations are minimized. - 18 -

10. The controller according to claim 9, wherein the learning agent (450) is configured to learn the traffic patterns and the CPU consumption of the vBSs (420) deployed based on Contextual Bayesian learning techniques.

11. The controller according to claim 9 or 10, wherein the radio computing platform (410) includes an agent that is configured to obtain the set of metrics by performing respective measurements and to store the measurement results for the set of metrics in a metrics database (440), and wherein the learning agent (450) is configured to fetch the set of metrics from the metrics database (440).

12. The controller according to any of claims 9 to 11 , wherein the learning agent (450) is configured to communicate the computed CPU set configuration, L3 cache allocation and PRB assignment for each vBS (420) via the radio computing platform’s (410) control interfaces.

13. The controller according to any of claims 9 to 12, wherein the learning agent (450) runs in discrete time intervals, and/or wherein the learning agent (450) runs in a different location than the radio computing platform (410) in a controlled environment.

14. The controller according to any of claims 9 to 13, wherein the vBSs (420) are deployed in the radio computing platform (410) in containers or by using hypervisors.

15. A tangible, non-transitory computer-readable medium having instructions thereon which, upon being executed by one or more processors, alone or in combination, provide for execution of a method of resource allocation for multiple virtualized base stations, vBSs (420), deployed in a shared radio computing platform (410), wherein the vBSs (420) share the same Radio Unit, RU (430), having a fixed number of Physical Resource Blocks, PRBs, the method comprising: obtaining, by a radio controller, a set of metrics from the radio computing platform (410) for each of the vBSs (420) deployed; - 19 - learning, by a learning agent (450) of the radio controller based on the obtained set of metrics, the traffic patterns and the CPU consumption of the vBSs (420) deployed; and computing, by the radio controller based on the knowledge of current CPU set configurations of the vBSs (420) and based on the learned traffic patterns and the CPU consumption of the vBSs (420), a CPU set configuration, L3 cache allocation and PRB assignment for each vBS (420) in such a way that at least one of the overall CPU overhead, the decoding time and SLA violations are minimized.