WO2023061584A1

WO2023061584A1 - Numerology aware cloud resource scheduling

Info

Publication number: WO2023061584A1
Application number: PCT/EP2021/078363
Authority: WO
Inventors: Johan Eker; Victor MILLNERT; Edgard FIALLOS
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-10-13
Filing date: 2021-10-13
Publication date: 2023-04-20

Abstract

A workload scheduler for a cloud RAN is configured to take into account the numerology of the various cloud RAN tasks and the cloud RAN task submission process is modified to include information about the numerology associated with a cloud RAN task to be scheduled. Taking the numerology into account during scheduling allows the scheduler to group cloud RAN tasks with the same numerology to share the same GPUs or other accelerators, which in turn allows the task schedule to reach a higher utilization and predictability.

Description

NUMEROLOGY AWARE CLOUD RESOURCE SCHEDULING

TECHNICAL FIELD

The present disclosure relates generally to a cloud-based communication networks and, more particularly to resource scheduling for deploying virtualized radio access networks (RANs) in a cloud computing environment.

BACKGROUND

Cloud technology has swiftly transformed the information and communications technology (ICT) industry and it is continuing to spread to new areas. Many traditional ICT applications have relaxed timing or performance requirements and are suitable for cloud deployment. Cloud systems are usually built on top on large scale commodity servers, typically x86 based systems. Different kinds of accelerators and new software scheduling techniques are needed to apply the cloud concepts outside the traditional ICT domain to more mission critical use cases such as telecom, industrial automation and real-time analytics.

Network Function Virtualization (NFV) is a virtualization technology for communication networks that eschews proprietary hardware and implements network functions (NFs) in the communication network as software running on industry-standard servers supported by high volume storage. A virtual network function (VNF) or containerized network function (CNF) implemented as a software component can be deployed at essentially any location within a cloud infrastructure without the need of installing new equipment. NFV enables rapid deployment of new services, ease of scalability, and reduced redundancy in the NFs.

The Internet Engineering Task Force (IETF) NFV initiative is standardizing a virtual networking infrastructure and a VNF architecture for wireless communication networks. The main focus is currently on core network (CN) functions, such as a virtual Internet Protocol (IP) Multimedia Subsystem (vIMS), virtual Evolved packet Core (vEPC), and virtual Mobility Management Entity (vMME). However, the possibility of moving Radio Access Network (RAN) functions to the cloud is being explored. It is known for example, to divide the functions of a 5G NodeB (gNB) in a 5G network, also known as a base station, into two parts: a Radio Unit (RU) and a baseband unit (BBU). The RU serves as the radio part of the base station and contains the radio frequency (RF) circuitry and antennas for transmitting signals to and receiving signals from user equipment (UEs) over a wireless communication channel. The BBU serves as the control part of the base station. The BBU processes signals transmitted and received by the gNB and handles most control functions, such as scheduling, power control, etc. In this split architecture, the BBUs can be pooled and shared by multiple RUs.

Cloud RAN is a new architecture for RANs where the certain RAN functions (e.g., the BBU), known as cloud RAN tasks, are moved into the cloud and realized using commercial- off-the-shelf (COTS) hardware. While commodity servers are becoming increasingly powerful, they still fall short for certain tasks compared to existing proprietary solutions. Moving RAN functions to the cloud currently involves a trade-off between efficiency of computations provided by proprietary solutions and lower capital expenditures (capex) for operators when using COTS hardware. To get reasonable performance from COTS hardware, the software architecture and resource scheduling must be carefully designed. In particular the COTS hardware must be augmented with accelerators, e.g., Graphics Processing Units (GPUs), Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs). These accelerators are typically challenging to share efficiently in multi-user/multi-tenant/multi-service setting, since they lack support for preempting and resuming jobs as is done on standard Central Processing Units (CPUs).

SUMMARY

The present disclosure relates to workload scheduling in a cloud RAN to improve utilization efficiency of the accelerators and reduce missed deadlines. In embodiments of the present disclosure, cloud RAN tasks having the same numerology are grouped together and share the same GPU or other accelerator. The cloud RAN task submission is augmented with information regarding the numerology associated with the cloud RAN tasks being deployed. The workload scheduler schedules the cloud RAN tasks on a server that is either empty or hosts other cloud RAN tasks associated with the same numerology. By grouping tasks with the same numerologies to share computational resources and “’tagging” different GPUS to handle tasks with different numerologies, a beneficial resource pooling effect is achieved that results in reduced idle time, greater resource utilization and fewer missed deadlines.

A first aspect of the disclosure comprises methods implemented by a workload scheduler in a cloud RAN. In one embodiment, the method comprises receiving a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology. The request includes an indication of the numerology associated with the cloud RAN task to be scheduled. The method further comprises scheduling the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology of the cloud RAN task.

A second aspect of the disclosure comprises a workload scheduler for a cloud RAN. The workload scheduler is configured to receive a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology. The request includes an indication of the numerology associated with the cloud RAN task to be scheduled. The workload scheduler is further configured to schedule the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task.

A third aspect of the disclosure comprises a workload scheduler for a cloud RAN. The workload scheduler comprises network interface circuitry for communicating with network devices over a communication network and processing circuitry. The processing circuitry is configured to receive a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology. The request includes an indication of the numerology associated with the cloud RAN task to be scheduled. The processing circuitry is further configured to schedule the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task. A fourth aspect of the disclosure comprises a computer program for a workload scheduler in a cloud RAN configured to perform task scheduling. The computer program comprises executable instructions that, when executed by processing circuitry in the workload scheduler, causes the workload scheduler to perform the method according to the first aspect.

A fifth aspect of the disclosure comprises a carrier containing a computer program according to the fourth aspect. The carrier is one of an electronic signal, optical signal, radio signal, or a non-transitory computer readable storage medium.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates a cloud infrastructure model for a wireless communication network.

Figure 2 illustrates an exemplary cloud RAN architecture for a wireless communication network

Figure 3 illustrates different numerologies used in a wireless communication network.

Figure 4 illustrates an agnostic workload scheduler in a cloud RAN for scheduling cloud RAN tasks for processing signals with different numerologies.

Figure 5 illustrates execution times and release times for GPU accelerated computations for different numerologies.

Figure 6 illustrates GPU utilization in a server processing signals with different numerologies.

Figure 7 illustrates a numerology-aware workload scheduler in a cloud environment for scheduling cloud RAN tasks for processing signals with different numerologies.

Figure 8 illustrates GPU utilization in a server processing signals with the same numerologies.

Figure 9 illustrates a method implemented by a numerology-aware workload scheduler configured to schedule cloud RAN tasks with different numerologies.

Figure 10 illustrates an embodiment of a numerology-aware workload scheduler configured to schedule cloud RAN tasks with different numerologies. Figure 11 illustrates another embodiment of a numerology-aware workload scheduler configured to schedule cloud RAN tasks with different numerologies.

DETAILED DESCRIPTION

The present disclosure relates generally to workload scheduling in a cloud RAN to improve utilization efficiency and reduce missed deadlines. The cloud RAN tasks may comprise any network function or service. The cloud RAN tasks may, for example, be implemented in the cloud as VNFs and/or CNFs, or on bare metal servers. The workload scheduler is responsible for scheduling the cloud RAN tasks on available resources in the cloud, referred to herein as computational resources. In embodiments of the present disclosure, the workload scheduler of the cloud RAN is configured to take into account the numerology of the various cloud RAN tasks and the cloud RAN task submission process is modified to include information about the numerology associated with a cloud RAN task to be scheduled. Taking the numerology into account during scheduling allows the scheduler to group cloud RAN tasks with the same numerology to share the same GPUs or other accelerators, which in turn allows the task schedule to reach a higher utilization and predictability.

Figure 1 illustrates an exemplary cloud computing model 10 for a communication network using virtualized NFs (VNFs) 25 and containerized NFs (CNFs) 35. Instead of proprietary hardware, the cloud computing model 10 uses industry standard servers, high volume storage and generic networking hardware that are organized into one or more data centers 15. The physical resources of the data centers 15 are shared via a virtualization layer (e.g., OpenStack or VMware) 20 that provides infrastructure as a service (laaS) and/or a containerization layer (e.g., Kubernetes) 30 that provides containers as a service (CaaS). The containerization layer 30 may be deployed on bare metal (BM) or on a virtual machine (VM) provided by the virtualization layer 20. The various NFs in a communication network are implemented as software running on a VM provided by a virtualization layer 20, or in a container provided by a containerization layer 30. The cloud computing model 10 provides ubiquitous, on-demand access to cloud resources that enables rapid provisioning and configuration of VNFs 25 and CNFs 35.

A NFV Management and Orchestration (MANO) architecture provides a framework for the management and orchestration of the network resources including computing, networking, storage, virtual machine (VM) and container resources. NFV MANO includes three main components: a Virtualized Infrastructure Manager (VIM) 40, a NFV Orchestrator 45 and a Virtual NF Manager (VNFM) 50. The VIM 40 is responsible for controlling, managing, and monitoring the compute, storage, and network hardware provided by the datacenter. The NFV Orchestrator 45 is responsible for resource coordination including the creation, allocation and termination of VMs and containers that are used by the VNFs. The VNFM 50 is responsible for the life cycle management of VNFs and CNFs. VNFM 50 operations include instantiation of VNFs/CNFs 25, 35, scaling of VNFs/CNFs 25, 35, updating and/or upgrading VNFs/CNFs 25, 35 and termination of VNFs/CNFs 25, 35. A VNFM 50 can be assigned to either a single VNF/CNF 25, 35 instance or to multiple VNF/CNF 25, 35 instances. The VNFs/CNFs 25, 35 managed by a VNFM 50 can be all of the same type of NF or a mix of different types of NFs.

While network operators have focused primarily on virtualization of core network functions, such as the vIMS, vEPC and vMME, NFV offers a new alternative, known as Cloud RAN, to conventional RAN architectures based on proprietary hardware. In a Cloud RAN, certain RAN functions are moved into the cloud and implemented using generic, commercial off-the-shelf (COTS) hardware. The virtualized RAN functions are implemented as microservices in containers that can be deployed and managed according to cloud-native principles.

Figure 2 illustrates an exemplary Cloud RAN architecture. Essentially, the BBU resources are virtualized, moved into the cloud and implemented using COTS servers. The BBUs are typically part of a BBU pool shared by multiple RUs. The centralization of BBU equipment in the cloud helps lower the total cost of hardware and is more easily scalable. In the embodiment shown in Figure 2, the vBBll is further divided into a virtualized data unit (vDU) 120 and a virtualized central unit (vCU) 110. The vDU 120 is typically implemented in an edge network close to the Rll while the vCU 110 can be centralized. The vDU 120 is connected to one or more Rlls by a fronthaul network, such as an optical fiber network, and is responsible for most baseband processing tasks, some of which require accelerators to meet stringent latency requirements, and for Ultra Reliable Low Latency Communications (URLLC). Exemplary processing tasks handled by the vDU 120 include Layer 1 (L1) processing, Medium Access Control (MAC) and Radio Link Control (RLC) processing, and scheduling. The vDU 120 further includes a RU interface for communications with the RU. The L1 processing includes Physical Downlink Control Channel (PDCCH) signal processing, Physical Downlink Shared Channel (PDSCH) signal processing, Physical Uplink Shared Channel (PUSCH) signal processing, Sounding Reference Signal (SRS) processing and beamforming weight (BFw) calculations.

Processing of the PDSCH, PUSCH, SRS and BFw calculations typically require accelerators to meet low latency requirements. These processes are highlighted in figure 2 by a box drawn with a bold line. The vCU 110 is located between the vDU 120 and core network in the processing pipeline and aggregates packet flows for many vDUs 120. The vCU 110 communicates with the vDU 120 over a midhaul network (F1) and with the core network over a backhaul network. The midhaul and backhaul networks may comprise IP networks.

One of the key cell configuration parameters in 5G RAN is numerology. The five numerologies currently defined in the Third Generation Partnership Project (3GPP) standards for 5G are shown in Table 1 below.

Table 1 : 3GPP Numerologies The choice of numerology for a RAN is generally driven by the wave propagation model of the deployment frequency, as illustrated in Figure 3. In a high band, for example, more phase noise is observed and therefore greater carrier separation is required (e.g., 120KHz or numerology 3). On the other hand, when targeting sub-6GHz deployment, a 30KHz sub-carrier separation (numerology 1) is better suited to the task. This in turn provides us with a sense of the largest possible cell radius and rough HARQ latency based on a 500ps Transmission Time Interval (TTI). These numerologies serve the purpose of configuring the baseband to meet given latency and QoS requirements. In 5G deployments, the numerology configuration is typically assigned statically upon deployment.

Figure 4 illustrates scheduling of cloud RAN tasks by generic workload scheduler 60 in a cloud environment, such as Kubernetes, Open Stack or bare metal. The cloud RAN task may be implemented as a function, container or VM. A workload scheduler 60 receives a request from a network operator or network node to start a new cloud RAN task. As used herein, the term cloud RAN task refers to a VNF, which may be realized by a set of microservices implemented by a container or VM. The workload scheduler 60 may be implemented as part of the orchestrator 45 in the cloud model shown in Figure 1. When the workload scheduler 60 receives the request, it schedules the cloud RAN task on an available computational resource, (e.g., server). In Figure 4, the computational resources comprise four servers 70, denoted as Servers A-D, with GPU acceleration and associated storage (not shown). Other types of accelerators could be used in place of GPUs 80. The GPUs 80 for a given server 70 is shared by all tasks assigned to the server.

The workload scheduler 60 allocates computational resources to the cloud RAN tasks being scheduled. State-of-the-art workload schedulers 60 typically place workloads to meet resource requirements, e.g., availability of GPU 80, sufficient amount of Random Access Memory (RAM), desired CPU instruction set, etc. It also typically considers affinity/anti-affinity, and utilization level. In the example shown in Figure 4, Tasks 1-3 are placed on Server A, Task 4 and 5 are place on Server B, Tasks 6 and 7 are placed on Server C and task 8 is placed on Server D. The server 70 and GPU 80 assigned to the task represents computational resources for implementing the cloud RAN tasks. The tasks are placed without consideration of the numerology so servers A, B & C may be assigned tasks with different numerologies.

Standard workload schedulers 60 do not consider the timing requirements and the periodicity of signals being processed. A workload scheduler 60 that considers the utilization level only would gladly place workloads together as long as the utilization level does not exceed 100%. Figure 5 shows examples of how the accelerator utilization would look for the different numerologies when the execution-time corresponds to 50% utilization. The up- arrow shows when the jobs are released. The shaded bars show the execution times for each cloud RAN task, which in this example equals 50% of the total time for each numerology. Each shaded bar represents one iteration of the cloud RAN task, referred to herein as a job. A job must be done before the next job for the same task is released. It is possible to use processing deadlines that are shorter than the period time.

It has been discovered that scheduling tasks associated with different numerologies impacts utilizations rates and/or performance indicators (e.g., number of missed deadlines) negatively. Figure 6 shows three scenarios where cloud RAN tasks associated with different numerologies are placed together on the same server 70 and sharing a GPU 80. The shaded bars show the execution times for each cloud RAN task, which in this example equals 50% of the total time for each numerology. The numeric labels indicate an iteration of the cloud RAN task, i.e., referred to herein as a job.

In 6a, cloud RAN tasks associated with numerologies 0 and 1, referred to TaskO and Taskl , share the same GPU 80. Job1 for both tasks are released at the same time, but the GPU 80 can only process one job at a time. The GPU 80 processes Job1 for Taskl first, followed by Job1 for TaskO, then Job2 for Taskl and then Job2 for TaskO. By the time the GPU 80 reaches Job3 for TaskO, it has already overrun the deadline.

In 6b, cloud RAN tasks associated with numerologies 0 and 2, referred to TaskO and Task2, share the same GPU 80. Job1 for both tasks are released at the same time, but the GPU 80 can only process one job at a time. The GPU 80 processes Job1 for Task2 first, followed by Job1 for TaskO, then Job2 and Job3 for Task2 and then Job2 for TaskO. By the time the GPU 80 reaches Job2 for Task2, it has already overrun the deadline.

In 6c, cloud RAN tasks associated with numerologies 1 and 2, referred to Taskl and Task2, share the same GPU 80. Job1 for both tasks are released at the same time, but the GPU 80 can only process one job at a time. The GPU 80 processes Job1 for Task2 first, followed by Job1 for Taskl, then Job2 and Job3 for Task2, then Job2 for Taskl , then Job4 for Task 2, then Job3 for Taskl, then Job5 - Job6 for Taask2. By the time the GPU 80 reaches Job5 for Task2, it has already overrun the deadline.

In Figures 6a - 6c, the utilization of the GPU 80 does not reach 100% but processing deadlines are missed in all three cases because the GPU 80, unlike an ordinary CPU, is not preemptable and jobs run to completion (or can be stopped, but not easily resumed). It is a well-known real-time scheduling result that 100% utilization is possible for a task set with harmonic frequencies like we have with the 5G numerology. However, achieving high utilization requires preemption.

One aspect of the disclosure is to address the problem with missing task-deadlines (and/or inefficient use of GPU resources in a cloud RAN setting) by grouping tasks with the same numerology on the same server 70 and sharing the same GPU 80. In order to facilitate grouping of cloud RAN task, the cloud RAN task submission is augmented with information regarding the numerology associated with cloud RAN tasks being deployed. The workload scheduler 60 then tries to place the tasks at a server 70 that is either empty or already hosts a cloud RAN task having the same numerology. By grouping tasks with the same numerologies to share computational resources and “’tagging” different GPUS to handle tasks with different numerologies, a beneficial resource pooling effect is achieved that results in reduced idle time, greater resource utilization and fewer missed deadlines.

Figure 7 illustrates scheduling of cloud RAN tasks by numerology-aware workload scheduler 60 in a cloud environment, such as Kubernetes, Open Stack or bare metal. The numerology-aware workload scheduler 60 receives a request from a network operator to start a new cloud RAN task. The request includes an indication of a numerology associated with the cloud RAN task. The cloud RAN task may be implemented by a container or VM. The cloud RAN task, may for example, comprise baseband processing for a cell in the wireless communications network configured to transmit and receive signals using the indicated numerology. When the workload scheduler 60 receives the request, it schedules the cloud RAN task on an available computational resource that is not currently used for another tasks associated with a different numerology. In Figure 7, the computational resources comprise four servers 70, denoted as Server A - Server D, with GPU acceleration and associated storage (not shown). Servers A - D are assigned tasks associated with numerologies 0 - 3 respectively. As previously noted, other types of accelerators could be used in place of GPUs 80. The servers 70 may comprise containers, virtual machines (VMs) or bare metal servers. The GPU 80 is shared by all cloud RAN tasks assigned to the server 70. In allocating the computational resources, the workload scheduler 60 groups tasks with the same numerology together and avoids allocating the same computational resources to cloud RAN tasks with different numerologies. By grouping cloud RAN tasks with the same numerology together, it is possible to increase the resource utilization of the GPUs while at the same time ensuring that processing deadlines will be met. In the example shown in Figure 7, the new task is associated with numerology 1 , so it is assigned to Server B, which is assigned other cloud RAN tasks with the same numerology.

Figure 8 illustrates an exemplary schedule where two tasks, referred to as Task 1 and Task 2, both with numerology 0 are placed on the same server and share the same GPU 80. The utilization rate is 100% and no processing deadlines are missed. The first job for Tasks 1 and 2 are released at the same time. Because each job takes 50% of the total time between consecutive releases, the GPU 80 is able to complete both jobs before Job2 is released by Tasks 1 and 2. Therefore, 100% utilization is achieved without overrunning any deadlines.

Figure 9 illustrates an exemplary method 200 implemented by a workload scheduler 60 in a cloud RAN. The workload scheduler 60 receives a request from a network operator or network node to schedule a cloud RAN task for processing signals transmitted and received using a given numerology (210). The request includes an indication of the numerology associated with the cloud RAN task to be scheduled. The method further comprises scheduling the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task (220). The method optionally comprises deploying a container or virtual machine to perform the cloud RAN task. (230).

In some embodiment of the method 200, scheduling the cloud RAN task to computational resources in the cloud infrastructure comprises selecting, based on the indicated numerology, the computational resources for the cloud RAN task; and allocating the cloud RAN task to the selected computational resources.

In some embodiment of the method 200, scheduling the cloud RAN task on computational resources in the cloud infrastructure comprises scheduling the cloud RAN task on computational resources shared with one or more other cloud RAN tasks having the same numerology.

In some embodiment of the method 200, the computational resources are shared only with other cloud RAN tasks having the same numerology.

In some embodiment of the method 200, wherein scheduling the cloud RAN task on computational resources in the cloud infrastructure comprises scheduling the cloud RAN task on computational resources not shared with another cloud RAN task having a different numerology.

In some embodiment of the method 200, the cloud RAN task comprises baseband processing in a virtual distributed unit (vDU).

In some embodiment of the method 200, the computational resources comprise a central processing unit and at least one co-processing unit for accelerating certain computations.

In some embodiment of the method 200, the co-processing unit comprises a graphics processing unit (GPU). An apparatus can perform any of the methods herein described by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

Figure 10 illustrates an exemplary numerology-aware workload scheduler 300 according to an embodiment. The workload scheduler 300 comprises a receiving unit 310, a scheduling unit 320 and an optional deploying unit 330. The various units 310-330 can be implemented by hardware and/or by software code that is executed by one or more processors or processing circuits. The receiving unit 310 is configured to receive a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology. The request includes an indication of the numerology associated with the cloud RAN task to be scheduled. The scheduling unit 320 is configured to schedule the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task. The optional deploying unit 330 is configured to deploy a container or virtual machine to perform the cloud RAN task. Figure 11 illustrates an exemplary workload scheduler 400 for a cloud RAN 100 configured to implement a numerology-aware workload scheduling of cloud RAN tasks . The workload scheduler 400 generally comprises network interface circuitry 420 for communicating with network devices over a communication network, processing circuitry 430 for controlling the operation of the workload scheduler 400 and memory 440 for storing programs and data needed by the workload scheduler 400.

The network interface circuitry 420 couples the workload scheduler 400 to a communication network for communication with other network devices to manage cloud resources in the cloud RAN 100 and to receiving scheduling requests from network operators. The network interface circuitry 420 may comprise a wired or wireless interface operating according to any standard, such as the Ethernet, Wireless Fidelity (WiFi) and Synchronous Optical Networking (SONET) standards.

The processing circuitry 430 controls the overall operation workload scheduler 400. The processing circuitry 430 may comprise one or more microprocessors, hardware, firmware, or a combination thereof. The processing circuitry 430 is configured to perform workload scheduling as herein described. In one embodiment, the processing circuitry 430 is configured to perform the method of Figure 9.

Memory 440 comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuitry 430 for operation. Memory 440 may comprise any tangible, non-transitory computer-readable storage medium for storing data including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. Memory 440 stores computer program 450 comprising executable instructions that configure the processing circuitry 430 to implement the method 200 according to Figure 9 as described herein. A computer program 450 in this regard may comprise one or more code modules corresponding to the means or units described above. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a ROM, erasable programmable read only memory (EPROM) or flash memory. Temporary data generated during operation may be stored in a volatile memory, such as a random access memory (RAM). In some embodiments, computer program 450 for configuring the processing circuitry 430 as herein described may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program 450 may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs. A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of an apparatus, cause the apparatus to perform as described above.

Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. This computer program product may be stored on a computer readable recording medium.

Claims

CLAIMS Claims:

1. A method (200) implemented by a workload scheduler in a cloud infrastructure of deploying cloud radio access network (RAN) tasks in the cloud infrastructure, the method comprising: receiving a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology, wherein the request includes an indication of the numerology associated with the cloud RAN task to be deployed; and scheduling the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task.

2. The method (200) of claim 1 , wherein scheduling the cloud RAN task to computational resources in the cloud infrastructure comprises: selecting, based on the indicated numerology, the computational resources for the cloud RAN task; and allocating the cloud RAN task to the selected computational resources.

3. The method (200) of claim 1 or 2, wherein scheduling the cloud RAN task on computational resources in the cloud infrastructure comprises scheduling the cloud RAN task on computational resources shared with one or more other cloud RAN tasks having the same numerology.

4. The method (200) of any one of claims 1 -3, wherein the computational resources are shared only with other cloud RAN tasks having the same numerology.

5. The method (200) of any one of claims 1 -4, wherein scheduling the cloud RAN task on computational resources in the cloud infrastructure comprises scheduling the cloud RAN task on computational resources not shared with other cloud RAN tasks having a different numerology.

6. The method (200) of any one of claims 1 - 5, wherein the cloud RAN task comprises baseband processing for a virtual distributed unit (vDU).

7. The method (200) of any one of claims 1 - 6, wherein the computational resources comprise a central processing unit and at least one co-processing unit for accelerating computations.

8. The method (200) of claim 7, wherein the co-processing unit comprises a graphics processing unit (GPU).

9. The method of any one of claims 1 - 9, further comprising deploying a container or virtual machine to perform the cloud RAN task.

10. A workload scheduler (60, 300, 400) configured to deploy cloud radio access network (RAN) resources in a cloud infrastructure, the workload scheduler being configured to: receive a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology, wherein the request includes an indication of the numerology associated with the cloud RAN task to be deployed; and schedule the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task.

11. The workload scheduler (60, 300, 400) of claim 10, further configured to perform the method of any one of claim 2 - 10.

12. A workload scheduler (60, 300, 400) configured to deploy cloud radio access network (RAN) resources in a cloud infrastructure, the workload scheduler comprising: network interface circuitry (420) for communicating with network devices over a communication network; and processing circuitry (430) configured to: receive a request to schedule a cloud RAN task for processing signals transmitted and received using a given numerology, wherein the request includes an indication of the numerology associated with the cloud RAN task to be deployed; and schedule the cloud RAN task on computational resources in the cloud infrastructure selected based on the indicated numerology associated with the cloud RAN task.

13. The workload scheduler (60, 300, 400) of claim 12, wherein the processing circuitry is further configured to perform the method of any one of claim 2 - 9.

14. A computer program (450) comprising instructions that, when executed by processing circuitry in a workload scheduler (60, 300, 400) in a cloud infrastructure, causes the workload scheduler to perform the method of any one of embodiments 1 - 9.

15. A carrier containing the computer program (450) of embodiment 14, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

18

16. A non-transitory computer-readable storage medium (450) containing a computer program comprising executable instructions that, when executed by a processing circuit in a workload scheduler in a cloud infrastructure causes the workload scheduler to perform any one of the methods of embodiments 1 - 9.

19