Method for managing hardware resources in open RAN cloud platform, cloud platform, and computer program

Abstract

A method of managing hardware resources in an open radio access network (open RAN) cloud platform is provided. The cloud platform includes a plurality of processor cores. The cloud platform is configured to host a plurality of application processes. The method includes dynamically allocating zero or more of the plurality of processor cores to each of the plurality of application processes based on processing requirements of the respective application process.

Description

Technical Field

[0001] This invention relates to the management of hardware resources in an open radio access network cloud platform. In particular, this invention relates to a method for dynamically allocating CPU cores to application processes.

[0002] Vocabulary RAN – Radio Access Network MNO – Mobile Network Operator O-RAN – Open RAN Alliance O-DU – Open Distributed Unit O-CU – Open Central Unit O-RU – Open Radio Unit OS – Operating System GPU – Graphics Processing Unit API – Application Programming Interface SMO – Service Management and Coordination DMS – Deployment Management Service NF – Network Functions IMS – Infrastructure Management Service COTS – Commercial Spot Supply CaaS – Container as a Service CPU – Central Processing Unit TTI – Transmission Time Interval MIMO – Multiple Input Multiple Output UE – User Equipment BS – Base Station ABS – Advanced Base Station BTS – Base Transceiver Station BSS – Basic Services Set ESS – Extended Services AP – Access Point NB – Node B (Radio Base Station Receiver) eNB – Evolution Node B gNB – Next Generation Node B TRP – Transmission and Receive Point PS – Processing Server TE – Terminal Equipment MS – Mobile Station MT – Mobile Terminal UT – User Terminal SS – Subscriber Site PDA – Personal Digital Assistant CDMA – Code Division Multiple Access FDMA – Frequency Division Multiple Access TDMA – Time Division Multiple Access OFDMA – Orthogonal Frequency Division Multiple Access SC-FDMA – Single-Carrier Frequency Division Multiple Access MC-FDMA – Multi-Carrier Frequency Division Multiple Access UTRA – Universal Terrestrial Radio Access GSM – Global System for Mobile Communications GPRS – General Packet Radio Service Enhanced data rates in the evolution of EDGE–GSM IEEE – Institute of Electrical and Electronics Engineers E-UTRA – The Evolution of UTRA UMTS – Universal Mobile Telecommunications System E-UMTS – The Evolution of UMTS 3GPP – Third Generation Partnership Project DL – Downlink UL – Uplink LTE – Long Term Evolution (4G) LTE-A – Advanced LTE NR – New Radio (5G) FDD – Frequency Division Duplex TDD – Time Division Duplex CRS – Cell-Specific Reference Signal CSI-RS – Channel State Information Reference Signal FPGA – Field Programmable Gate Array ASIC – Application-Specific Integrated Circuit DSP – Digital Signal Processor CD-ROM – Compact Disc Read-Only Memory DVD-ROM – Digital Multifunction Read-Only Memory ROM – Read-Only Memory RAM – Random Access Memory EEPROM – Electrically Erasable Programmable Read-Only Memory EPROM – Erasable Programmable Read-Only Memory. Background Technology

[0003] Open RAN is a technology architecture concept designed to decouple the hardware and software components of a radio access network (RAN). It encompasses open interoperability interfaces and virtualization. In existing (non-open) RAN technologies, hardware and software components are typically proprietary. Non-open RAN equipment is often sourced from a single vendor to ensure seamless functionality, security, and efficiency. In contrast, Open RAN introduces open standards for both hardware and software, enabling interoperability across various network elements. Open RAN holds strategic importance for mobile network operators (MnOs) because it fosters vendor diversity, allowing for the integration of new vendors and enhancing supply chain resilience. It also delivers energy efficiency gains by enabling targeted improvements in specific areas of the RAN. Furthermore, Open RAN fosters innovation and competition by providing a more dynamic and efficient network environment. Additionally, it offers opportunities to collaborate with specialized vendors and facilitates resource optimization by allowing software upgrades without replacing hardware. Open RAN is crucial to MnO's long-term network innovation strategy, offering energy efficiency, supply chain diversification, enhanced resilience, and the ability to foster innovation and competition.

[0004] Figure 1 Some elements of an example open RAN system 100 implemented as a cloud computing platform (O-Cloud) are shown. The system 100 can be described by referring to the different hardware and software layers of the platform.

[0005] At the O-Cloud node layer 110, the system includes one or more physical infrastructure nodes 120A, 120N that meet O-RAN requirements. Each physical infrastructure node 120A includes compute 121, networking 122, GPU 123, and storage 124 components, as well as acceleration technologies 125 for RAN operations such as forward error correction and other compute-intensive operations offloaded to dedicated hardware. Each physical infrastructure node 120A, 120N is configured to host associated O-RAN network functions 150, 160 implemented in the Open RAN Application Layer 140. The network functions 150, 160 implemented in the Open RAN Application Layer 140 may include O-CU 160, O-DU 150, and O-RU.

[0006] At the O-Cloud hypervisor or container / OS layer 130, there is a collection of cloud functions that enable open RAN applications 150, 160 to run on one or more O-Cloud hardware nodes 120A. Cloud functions may include supporting software components such as operating systems, containers (standalone executable packages), container orchestration platforms (such as Kubernetes), container runtimes, and the like. Cloud functions may also include corresponding management and orchestration capabilities.

[0007] O-Cloud serves as a fundamental component for facilitating cloud computing capabilities within the context of RAN network functions. It comprises both hardware and software elements. Specifically, its software exposes open APIs, enabling interoperability and flexibility across solutions from different vendors. Leveraging a decoupled architecture, O-Cloud allows for hardware procurement from diverse vendors, enhancing hardware selection neutrality and flexibility. It supports Service Management and Coordination (SMO), enabling relocation decisions and selecting Deployment Management Services (DMS) for Network Function (NF) deployments. DMS handles workload placement, lifecycle management, and resource allocation within the O-Cloud node cluster, while Infrastructure Management Services (IMS) ensure the availability, reliability, and performance of the infrastructure. Furthermore, O-Cloud provides automation capabilities, improving efficiency and reducing manual intervention, ultimately supporting efficient resource utilization and scalability of RAN network functions in cloud-native environments.

[0008] O-Cloud provides a foundational platform for open RAN, enabling containerized RAN software to be implemented on any COTS hardware. To support open RAN applications, O-Cloud implements Container as a Service (CaaS). One of the key functionalities of the O-Cloud platform is scheduling (running in appropriate Pods) different RAN workloads and assigning hardware resources (such as compute, storage, and networking resources).

[0009] In existing O-Cloud solutions, dedicated hardware resources are allocated to each application process. Under high software load, the workload scheduler may allocate additional hardware resources to application processes. However, under low load, these dedicated hardware resources may not be fully utilized. This disclosure aims to address this issue.

[0010] Furthermore, in existing O-Cloud solutions, workload scheduler operations allocate hardware resources (i.e., the amount of CPU, storage, etc.) based on RAN software requirements. When CPU / storage is insufficient to support the workload, the O-Cloud scheduler scales up to allocate more CPU / storage to certain Pods. When Pod workloads decrease, the O-Cloud scheduler scales down to reduce CPU / storage resources. Currently, in passive mode, scaling up / down is still triggered by applications and actual workloads. Scaling up / down available hardware resources takes time, which can lead to potential lag between scaling up / down and changes in demand. This disclosure aims to address this issue. Summary of the Invention

[0011] A method for managing hardware resources in an Open Radio Access Network (Open RAN) cloud platform is provided. The cloud platform includes multiple processor cores. The cloud platform is configured to host multiple application processes. The method includes dynamically allocating zero or more processor cores from the multiple processor cores to each of the multiple application processes based on the processing requirements of the respective application processes.

[0012] As mentioned above, in existing O-Cloud solutions, a dedicated core is allocated to each application process, which may result in underutilization of hardware resources under low load. In contrast, the proposed method dynamically allocates a pool of processor cores, allowing zero cores to be allocated to application processes and eliminating the need for dedicated cores for each process. In this way, by freeing up previously dedicated cores, the number of cores available for allocation in the pool increases compared to existing methods. This allows workload schedulers to allocate hardware resources more efficiently.

[0013] Furthermore, this allows the workload scheduler to implement power-saving measures by placing any idle cores into power-saving mode. In existing O-Cloud solutions, dedicated cores may need to be always available and therefore cannot be placed into power-saving mode, even if their workload is low or zero. In contrast, the proposed method allows zero cores to be allocated to application processes with no workload, and unused cores in the pool can be placed into power-saving mode.

[0014] Application processes can also be referred to as "RAN workloads".

[0015] Hardware resources may include one or more central processing units, CPUs (each CPU may include one or more of multiple processor cores), network resources, and / or storage resources.

[0016] Dynamically allocated cores may be the only core assigned to an application process. In other words, there may be no statically allocated cores (dedicated cores) for an application process.

[0017] The cloud platform can be configured to host multiple network functions, and each network function can include one or more applications. Each application can include one or more application processes from a set of multiple application processes.

[0018] Dynamically allocating zero or more cores to each of multiple application processes may include allocating zero cores to an application process if the corresponding processing requirement of the application process is zero (and / or is predicted to be zero within a predetermined time period).

[0019] In other words, the method may include determining that the application process has zero processing requirements and dynamically allocating zero cores to the application (and deallocating any previously allocated cores).

[0020] The cloud platform can be a containerized cloud platform. Each application process can be hosted via a corresponding Pod managed by the containerized cloud platform.

[0021] One or more of the multiple processor cores may be dedicated cores allocated to the cloud platform's scheduler. These dedicated cores may not be part of the resource pool and therefore may not be available for allocation to multiple application processes.

[0022] The cloud platform scheduler can be called an O-cloud scheduler, or, in the case of a containerized cloud platform, a CaaS scheduler.

[0023] Each of a plurality of processor cores, which is not one or more dedicated cores, can form a resource pool. Dynamically allocating zero or more processor cores from the plurality of processor cores to each of a plurality of application processes can include dynamically allocating zero or more processor cores from the resource pool to each of the plurality of application processes.

[0024] In other words, there may not be a kernel dedicated to a specific application process, and no application process may be allowed to have a dedicated kernel.

[0025] Processor cores can be allocated to a processor core pool (all cores except those dedicated to the O-Cloud platform). Cores can be dynamically allocated from the pool to application processes. Therefore, an application process may not have any dedicated cores.

[0026] The processing requirements for each application process can include predicted processing requirements. Models can be used to predict the processing requirements for application processes.

[0027] In other words, the method may further include forecasting / predicting the load of application processes, so that processor cores can be dynamically allocated to applications based on the forecasted / predicted processing requirements of the respective application processes (instead of or attached to the instantaneous processing requirements of the respective application processes).

[0028] As mentioned above, in existing O-Cloud solutions, workload schedulers operate in a passive mode (allocating dedicated cores and dynamically responding to instantaneous demands from the RAN software to increase cores). In contrast, the proposed solution uses an artificial intelligence (AI) model to predict RAN software demands and scale up / down as expected, thereby transforming the workload scheduler in the O-Cloud platform from a passive to an active mode.

[0029] The AI ​​model can learn workload patterns from historical RAN workload data. Preferably, a large amount of historical data is used to train the AI ​​model. For example, 3-6 months of real-time network workload data can be used to train the AI ​​model. The trained AI model can predict workloads based on historical data (e.g., in the next few minutes or hours). The workload scheduler can then allocate cores to application processes based on the predicted workload to automatically perform scale-up / scale-down. In this way, the workload scheduler operates in an active mode, rather than a passive mode as before. One benefit of this solution is improved hardware utilization efficiency, making full use of COTS hardware resources and thus improving the performance of the open RAN platform.

[0030] This method can be executed by the O-Cloud scheduler. The O-Cloud scheduler can also be called the CaaS scheduler (or Kubernetes scheduler).

[0031] Network workload data can be provided for each application process (i.e., on a per-pod basis). Therefore, this model can predict the workload of each application process. The O-Cloud scheduler can then allocate CPU resources to each Pod based on the predicted workload.

[0032] In this way, the O-Cloud scheduler can allocate CPU resources more intelligently to improve resource utilization and overall efficiency.

[0033] This model can be an artificial intelligence (AI) model.

[0034] The model can be trained using historical data from the application's processing requirements.

[0035] This method can further include training a model. This model can then learn the traffic patterns for each application process (i.e., each Pod). Therefore, based on historical patterns, the model can be used to predict the future traffic load for each Pod.

[0036] The model can be based on a schedule. For example, the model can predict workload based on the time of day, the date of the week, etc.

[0037] This model can also be called an "algorithm".

[0038] Models can be trained in advance based on several months of real-time data (e.g., 3-6 months of traffic) or synthetic data. AI models can be used to generate synthetic training data.

[0039] To test and update the model, the trained model can be run in an edge center of an open RAN, and real-time traffic data can be collected over another time period (e.g., 3 months). The offline analysis can then be run again with the additional data to determine if the model is working well. The model can then be updated based on this analysis.

[0040] The model can also be fine-tuned in real time. Locally at the edge center, small (marginal) adjustments to the model configuration can be made based on real-time traffic (this fine-tuning can be applied to the model configuration rather than retraining the model, which is usually done offline).

[0041] Each of the multiple processor cores can be operational in one or more processor idle sleep states (such as C state in Intel processors). The method may also include switching a processor core to an idle sleep state based on a forecasted processing request from the corresponding application process to which one of the multiple processor cores is assigned.

[0042] When in an idle sleep state, the processing operations of this processor core can be paused. Compared to the normal state, the power consumption of this processor core can be reduced in each of one or more idle sleep states.

[0043] There may be multiple idle sleep states with different attributes. For example, in the first idle sleep state, the processor core may be able to return to normal almost immediately. In the second idle sleep state, the processor core's power consumption may be reduced compared to the first idle sleep state. However, returning to normal state may take longer compared to the first idle sleep state.

[0044] In some examples, the idle sleep state can be a C state. The idle sleep state can include states C1 through C6, where C1 is a static CPU sleep state and C6 is a dynamic CPU sleep state (which is the most efficient state for energy saving).

[0045] Based on Pod-level workloads, CPUs can be placed into idle sleep states statically or dynamically. For example, the O-Cloud Manager can place one or more cores in a C state for a predetermined period of time based on forecasted usage. In this way, the proposed method can reduce energy consumption in open RAN.

[0046] As described above, the proposed method uses AI to predict the workload of each Pod. If the AI-predicted Pod workload is zero in the next TTI (e.g., 10ms), the O-Cloud manager can put the assigned CPUs (for the corresponding Pod) to sleep, thus saving energy. In other examples, the O-Cloud manager can put one or more CPUs in the resource pool that are not allocated to the application process (i.e., the corresponding Pod) to sleep.

[0047] In some examples, the C state can be defined as a control state for cores that allows for microsleep or longer periods of operation. Therefore, the C state can be defined as an extension of the performance control state of the assigned core.

[0048] Each of the multiple processor cores can be operational in one or more power performance states (e.g., so-called "P states"). The method may also include transitioning a processor core to a power performance state based on a forecast of processing requirements from the corresponding application process to which one of the processor cores is assigned.

[0049] In other words, one or more processor cores can be statically or dynamically placed in a power performance state based on Pod-level workload.

[0050] Compared to the normal state, the power consumption of the processor core can be reduced in each of one or more power performance states.

[0051] Multiple power performance states with different attributes can exist. For example, in a first power performance state, the processor core can operate with reduced power consumption and reduced capacity. Compared to the first power performance state, in a second power performance state, the power consumption and capacity of the processor core can be further reduced.

[0052] In some examples, the power performance state can be a P state. The P state can be used for energy saving in a manner similar to the C state. If the AI-predicted Pod workload is zero in the next TTI (e.g., 10ms), the O-Cloud manager can reduce CPU frequency and voltage operation to save energy.

[0053] By using power performance states, the resource capacity of processor cores can be adjusted and utilized effectively while conserving power. In contrast, some existing technology methods simply allocate cores to Pods to meet processing requirements (thus either using cores or not using them).

[0054] By using power performance states, the proposed method can introduce tiered performance levels for assigned cores. This can be used to control energy consumption, as higher performance states consume more energy.

[0055] Processing requirements may include data processing load and / or network traffic load.

[0056] Processing requirements may include forecast data processing load and / or network traffic load.

[0057] Data processing workload can be an indication of the processing requirements of an application process (or corresponding Pod). In other words, data processing workload can be the workload of the cloud platform executing the application process of the RAN application.

[0058] Network traffic load can be an indication of network traffic handled by RAN applications. In other words, network traffic load can be the workload of the RAN applications themselves.

[0059] Each of the multiple processor cores can operate in normal mode and power-saving mode, and the method also includes: Based on the processing requirements of multiple application processes, one or more of the multiple processor cores are switched to power-saving mode; and / or Based on the processing requirements of multiple application processes, one or more of the multiple processor cores are switched from power-saving mode to normal mode (that is, if more hardware resources are needed or anticipated, the sleep core is switched to normal mode and ready to be allocated).

[0060] In other words, if no additional hardware resources are needed and forecasted, idle cores can switch to power-saving modes (e.g., "sleep").

[0061] In normal mode, this processor core can execute instructions on behalf of an application process. In power-saving mode, this processor core may not be available for instruction execution (e.g., it may be in sleep mode), or it may execute instructions at a reduced capacity.

[0062] One or more of the processor cores that switch to power-saving mode can be one or more of the processor cores that are not allocated to application processes. For example, if the cores in the resource pool are idle, they may be put into power-saving mode unless the forecast indicates that they will be needed soon.

[0063] If the cores allocated to the application process are idle and the forecast indicates that they will not be needed anytime soon, then those cores can be put into power-saving mode.

[0064] One or more power-saving modes may include: One or more processor idle sleep states (e.g., C state); and / or One or more power performance states (e.g., P states).

[0065] The predicted traffic load for each Pod can be used to help the O-Cloud manager put the CPU cores allocated to RAN applications into power-saving modes (e.g., via C-state / P-state modes), thereby saving energy.

[0066] A cloud platform may include one or more servers (preferably multiple servers). Multiple processor cores may include corresponding multiple processor cores from each server.

[0067] A resource pool can include cores from each of multiple servers.

[0068] A cloud platform is also provided that can be configured to perform any of the above methods.

[0069] A computer program containing instructions is also provided, which, when executed on a processor, cause the processor to perform any of the methods described above. Attached Figure Description

[0070] Figure 1 An example cloud platform is shown.

[0071] Figure 2 The differences between single (non-open) RAN and open RAN are shown.

[0072] Figure 3 A cloud platform for Open RAN is shown.

[0073] The present invention will be described with reference to non-limiting examples shown in the following figures.

[0074] Figure 4 An example cloud platform for Open RAN is shown.

[0075] Figure 5 The cloud platform is shown with reference to a specific example. Detailed Implementation

[0076] Prior to Open RAN, mobile networks were built by a few vendors using tightly coupled hardware and software. Interoperability between equipment from different vendors was limited, and this arrangement resulted in limited flexibility and innovation. Open RAN aims to improve upon this traditional model by decoupling hardware and software components. This enables greater flexibility, innovation, and cost-effectiveness in building and operating mobile networks.

[0077] As mentioned above, Open RAN systems decouple hardware and software within a RAN network, allowing for the separate provision of hardware and software components. To achieve this, the Open RAN Alliance has provided new standards for interaction between the hardware and software components of Open RAN systems (the term "O-RAN" generally refers to the standards defined by the Open RAN Alliance).

[0078] Figure 2 The differences between a single (non-open) RAN and an open RAN are illustrated. The following benefits can be achieved by moving from a single RAN to an open RAN: break down; Decouple hardware from software; Open ecosystem; Open interfaces; and Intelligent management.

[0079] Open RAN enables interoperability between hardware and software elements from different vendors. In doing so, Open RAN also provides resilience to MNOs by promoting vendor diversity within the network. If an element from a particular vendor ceases to function properly or needs to be permanently or temporarily removed (e.g., due to security or performance requirements), it can be replaced by an element from another vendor without significant disruption to the network.

[0080] Open RAN also offers potential energy efficiency improvements (e.g., by flexibly providing hardware to meet network requirements).

[0081] Open RAN implements function block decomposition, where baseband processing functions are separated into different blocks, allowing for contributions and innovation from various vendors. However, for true interoperability and innovation to be achieved, solutions from different vendors need to work together seamlessly. Ensuring seamless interoperability between hardware and software components across competing vendors is crucial to the success of open RAN. Decomposing RAN functions into software-based components that can be hosted on different processor architectures presents interoperability challenges in managing and coordinating these functions.

[0082] A cloud platform (sometimes referred to as "O-Cloud") serves as a fundamental component of an open RAN system. A cloud platform comprises both hardware and software components. The hardware components of a cloud platform include physical infrastructure nodes (also known as "server nodes") deployed in one or more node clusters. These provide the hardware resources necessary to support the deployment of network functions (e.g., O-RU, O-DU, and O-CU), which are implemented in software applications (also known as "client nodes") running on the cloud platform hardware.

[0083] The physical infrastructure nodes (server nodes) of a cloud platform include the physical hardware resources required to support network function deployment, while the software applications (client nodes) define the functionality of the network function deployment.

[0084] To promote interoperability and create an environment for competition and innovation, a key feature of virtualized and open RAN is that multiple hardware and software vendors can coexist within an operator's RAN domain. Standards and interfaces have been defined to enable interoperability.

[0085] Figure 3 A cloud platform for Open RAN is shown. This platform is a "containerized" cloud platform. Each of the one or more RAN applications hosted by the cloud platform consists of one or more application processes. Each application process can be hosted via a discrete container called a "Pod," which is managed by the containerized cloud platform. Each Pod represents a discrete workload. The cloud platform's manager is configured to allocate resources (such as CPU cores) to one or more Pods.

[0086] In the illustrative example, a single RAN system can host a RAN application comprising 1000 lines of code. The application software consists of a single workload and a single application package. In contrast, an open RAN system can break the code into packages of 100 lines each (application processes) and run these application processes via 10 Pods. The CaaS layer schedules Pod workloads to assigned CPU cores. One or more (typically two) CPU cores can be reserved for the CaaS scheduler, and the remainder can be allocated to Pods or adjusted within a resource pool.

[0087] If possible Figure 3 As seen in the diagram, one or more dedicated CPU cores are statically allocated for each RAN application (used to host each dedicated Pod of the corresponding application process). For Figure 3 The specific example shown illustrates the CPU core allocation as follows: CPU core CaaS platform 0, 1 CPU pool 25-31 RAN workload (application processes) Dedicated CPU core A 2, 3 B 4, 5 C 6 D 7-12 … … Z 24

[0088] RAN application vendors typically request dedicated resources for RAN application processes regardless of the RAN application's workload. Dedicated CPU cores are reserved even when no traffic is running on the Pod. Therefore, these dedicated resources are not effectively utilized if the RAN application has zero or very low workload.

[0089] Furthermore, if each RAN application hosted by the cloud platform has dedicated resources, only a small number of CPU cores can be used to form a resource pool for dynamically allocating resources to where they are needed (i.e., dynamically scheduling Pod workloads on pooled resources).

[0090] Different application processes may have different requirements for the software in a Pod. According to... Figure 3 The cloud scheduler statically allocates a fixed number of CPU cores to each Pod (each Pod is required to have a fixed number). If a Pod needs additional resources beyond the fixed allocation, these resources may need to be provided by a separate server due to security requirements. This can further limit the flexibility of the cloud platform and lead to inefficiency.

[0091] Reserved CPU cores consume relatively high power. These allocated CPU cores may be powered off when not in use to conserve energy. However, they are still assigned to application processes.

[0092] Figure 3 The cloud platform shown does not conform to the proposed method. Figure 4 The improved cloud platform is shown, which illustrates a specific example of the proposed method.

[0093] Compared to Figure 3 The cloud platform shown Figure 4 The cloud platform shown does not allocate dedicated (permanently reserved) CPU cores to specific Pods. Instead, CPU cores are provided in a resource pool, and the scheduler reactively allocates work to CPU cores based on the Pod's load level. For example, when Pod A has a high workload, cores 2 through 4 may be allocated to Pod A during the first TTI, but when Pod B has a high workload, cores 3 and 4 may be allocated to Pod B during the second TTI.

[0094] Figure 4 The cloud platform for Open RAN shown includes an intelligent workload scheduler. In this specific example, the intelligent workload scheduler (O-Cloud scheduler / CaaS scheduler) uses an AI model to predict the workflow of application processes and can assign cores based on predictions from the model.

[0095] like Figure 4 As shown, one or more CPU cores can be assigned to the O-Cloud scheduler (CaaS platform scheduler). Figure 4 In the specific example shown, two CPU cores are allocated to the O-Cloud scheduler. Besides these two CPU cores, the remaining CPU cores can form a resource pool. For Figure 4 The specific example shown illustrates the CPU core allocation as follows: CPU core CaaS platform 0, 1 CPU pool 2-31

[0096] The CaaS scheduler can schedule application processes (hosted in the respective Pods) to different CPU cores based on the traffic load each Pod is carrying. AI models can be used to learn the traffic patterns of each Pod and then predict future traffic load based on historical patterns. Therefore, the CaaS scheduler can allocate CPU resources to each Pod (i.e., scale up and scale down) based on the predicted traffic load for the next TTI (and real-time traffic measurement levels). The scheduler can intelligently allocate CPU resources to improve the CPU utilization and efficiency of the cloud platform.

[0097] Predicted traffic load on each Pod can also be used to help RAN applications put CPU cores in power-saving modes (e.g., C-state / P-state modes) to save energy.

[0098] The C and P states can respectively shut down and scale down CPU cores when not in use. Compared to existing methods that reactively put CPU cores into power-saving modes based on immediate workload, the proposed method can implement power-saving modes based on predicted workload. This can lead to improved efficiency because, based on confidence in future workloads, processor cores can be placed in deeper power-saving modes (saving more power but requiring more time to wake up). It can also lead to improved responsiveness, as the O-Cloud scheduler can preemptively wake processor cores from sleep mode based on predicted increases in workload in the near future.

[0099] AI models can be trained by providing historical network traffic load data for each application process. In the CaaS layer, analytics provide resource utilization metrics for RAN workloads. These metrics can be used to transform traffic to the Pod level to determine how much CPU workload each Pod requires (i.e., resource utilization at the Pod level).

[0100] AI can be statically trained in advance (as described above) and dynamically trained during operation. For example, 3-6 months of historical traffic data can be used to initially train the model in advance. This model can then be run at an edge center, and real-time traffic data can be collected over another 3 months using this model. Offline analysis can then be run again using the real-time traffic data to see if the AI ​​model is working as expected. Based on this analysis, the model can be fine-tuned.

[0101] Locally, small marginal configuration adjustments can be made to the model based on real-time traffic. However, this is more likely related to the choice of configuration than to the adjustment of AI model parameters.

[0102] exist Figure 4 In the example shown, the application process (RAN workload) uses only the CPU pool. No CPU cores (dedicated cores) are statically allocated to the RAN workload. The scheduler controls the entire CPU pool. In some examples, this might be 62 CPU cores (32 per server, with two reserved for the CaaS scheduler). The benefits of the proposed method (such as power saving) are more pronounced when most CPU resources are in a large pool (compared to...). Figure 3 In the example, Figure 3 In the example, only seven cores are in the CPU pool.

[0103] In some example current deployments, the cloud platform in the edge network may include two servers running a single-mode solution at the CaaS layer. These servers work together, with each server providing a master node in a standby / active configuration. The servers can synchronize together, and resource sharing can be configured between the servers, allowing the CPU pool to include CPU cores from both servers.

[0104] The benefits of the proposed method can be further increased with the number of servers, as there may then be more CPU cores in the CPU pool managed by the CaaS scheduler. For example, in a large-scale MIMO scenario, there may be five servers per node. Furthermore, due to improvements in hardware capabilities, the number of cores per server may increase over time, and the number of servers per node may also increase over time to meet the growing network demands.

[0105] AI models can be implemented on cloud platforms within edge networks (with low latency). Minor adjustments to AI models with real-time traffic data can be performed on edge networks. However, AI models can be trained and updated offline in a CaaS platform manager (CaaS Manager), which can be located in a data center within a separate network.

[0106] The CaaS manager can collect statistics and logs for each cluster. Therefore, the CaaS manager can provide training data, or it can use synthetic training data. Furthermore, the CaaS manager is well-placed to determine whether the model is working as expected. Information and logs (metric collection) can be used to aid in training / updating AI models.

[0107] In some examples, the remote CaaS manager can also adjust the AI ​​model in real time.

[0108] Figure 5 A cloud platform 501 is shown according to a specific example. The cloud platform 501 includes multiple processor cores 502A, 502B, and 502C.

[0109] Although specific embodiments have now been described, those skilled in the art will understand that various modifications and variations are possible. For example, while this disclosure is described with respect to existing network architectures, it will be understood that changes to the architecture (and / or terminology) are possible, but this disclosure may still be applicable in such cases. All features disclosed herein can be combined in any combination, even if such combination is not explicitly detailed, except for at least some mutually exclusive combinations of such features and / or steps. In particular, preferred features of the invention are applicable to all aspects of the invention and can be used in any combination. Similarly, features described in non-essential combinations may be used alone (not in combination).

[0110] A base station (BS) generally refers to a fixed station that communicates with a UE and / or another BS, exchanging various types of data and control information with that UE and the other BS. Depending on the protocol, standard, context, or technology, a BS may be referred to as an Advanced Base Station (ABS), Base Transceiver Station (BTS), Radio Base Station, Radio Transceiver, Transceiver Function, Basic Service Set (BSS), Extended Service Set (ESS), Access Point (AP), Node B (NB), eNode B (eNB), gNode B (gNB), Transmit and Receive Point (TRP), Processing Server (PS), or some other suitable term. In some examples, a base station may include two or more transceivers, which may or may not be co-located. Each transceiver may communicate on the same or different carrier frequencies within the same or different frequency bands.

[0111] For example, in the case of a server or network entity in this application, this can actually be a pair of server or network entities (a primary entity and a failover entity) for redundancy.

[0112] Examples of mobile devices include various devices that transmit and receive user data and / or various types of control information from base stations. Mobile devices may be referred to as user equipment (UE), terminal equipment (TE), mobile station (MS), mobile terminal (MT), user terminal (UT), subscriber station (SS), wireless device, personal digital assistant (PDA), wireless modem, handheld device, etc.

[0113] While the methods described above are specific to certain networks (such as 4G / LTE or 5G / NR networks) in some examples, these methods, technologies, devices, and systems can be applied to a wide variety of radio multiple access systems. Examples of multiple access systems include CDMA, FDMA, TDMA, OFDMA, SC-FDMA, and MC-FDMA. CDMA can be implemented using radio technologies such as UTRA or CDMA2000. TDMA can be implemented using radio technologies such as GSM, GPRS, or EDGE. OFDMA can be implemented using radio technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA. UTRA is part of UMTS. 3GPP LTE is part of E-UMTS using E-UTRA. 3GPP LTE uses OFDMA in the downlink and SC-FDMA in the UL. LTE-A is an evolution variant of 3GPP LTE. 3GPP NR uses OFDMA for both downlink and uplink and can operate in both FDD and TDD modes. For ease of description, it is assumed that the present invention applies to 3GPP NR. However, the technical features of the present invention are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP NR system, aspects of the present invention that are not specific to 3GPP NR can also be applied to other mobile communication systems.

[0114] Cellular communication systems comprise multiple cells. A cell refers to a geographical area to which one or more nodes provide communication services. Therefore, communicating with a specific cell may mean communicating with a gNB or node that provides communication services to that specific cell. Furthermore, the channel state / quality of a specific cell refers to the channel state / quality of the channel or communication link formed between the gNB or node providing communication services to the specific cell and the UE. The UE can measure the DL channel state received from a specific node using one or more cell-specific reference signals (CRS) transmitted on CRS resources and / or one or more channel state information reference signals (CSI-RS) transmitted on CSI-RS resources, which are assigned to the specific node by one or more antenna ports of the specific node. Meanwhile, the 3GPP system uses the concept of cells to manage radio resources and distinguishes cells associated with radio resources from cells in geographical areas.

[0115] Examples can be implemented on any suitable data processing device, such as a personal computer, laptop, mobile phone, server, virtual machine, and the like. The foregoing description of the systems and methods has been simplified for discussion purposes and is intended to provide concrete examples to illustrate the invention. Those skilled in the art will appreciate that different types of systems and methods can be used. It will be appreciated that the boundaries between logical blocks are merely illustrative, and alternative embodiments may merge logical blocks or elements, or functional alternative decompositions may be imposed on various logical blocks or elements.

[0116] It will be understood that the aforementioned functionality can be implemented as hardware and / or software as one or more corresponding modules. For example, the aforementioned functionality can be implemented as one or more software components executed by the system's processor. Alternatively, the aforementioned functionality can be implemented as hardware such as on one or more FPGAs, and / or one or more ASICs, and / or one or more DSPs, and / or other hardware arrangements. The method steps implemented in the flowcharts included herein or as described above can each be implemented by their respective corresponding modules. Furthermore, multiple method steps implemented in the flowcharts included herein or as described above can be implemented together by a single module.

[0117] Examples can be implemented through computer software or "computer programs". Storage media and transmission media carrying the computer software are also provided. The computer software may include one or more instructions or code that, when executed by a computer, cause the described methods to be performed. The computer software may be a sequence of instructions designed to execute on a computer system and may include subroutines, functions, procedures, modules, object methods, object implementations, executable applications, applets, service programs, source code, object code, shared libraries, dynamic link libraries, and / or other sequences of instructions designed to execute on a computer system. The storage medium may be a disk (such as a hard disk drive or floppy disk), an optical disk (such as a CD-ROM, DVD-ROM, or Blu-ray disc), or a memory (such as ROM, RAM, EEPROM, EPROM, flash memory, or portable / removable memory devices), etc. The transmission medium may be communication signals, data broadcasting, communication links between two or more computers, etc.

[0118] The computer program can be configured to control network entities and / or mobile devices to perform any of the methods disclosed herein. Network entities of telecommunications networks (e.g., cellular networks) configured to operate according to certain methods disclosed herein may also be provided. For example, the network entity may include a processor and at least one communication interface, particularly including one or both of a transmitter and a receiver. Mobile devices (e.g., UEs) configured to operate according to certain methods disclosed herein may also be provided. Mobile devices may also include a processor and at least one communication interface, particularly including one or both of a transmitter and a receiver.

[0119] Unless otherwise stated, each feature disclosed in this specification may be replaced by an alternative feature for the same, equivalent, or similar purpose. Therefore, unless otherwise stated, each disclosed feature is merely one example of an equivalent or similar feature in a general series.

[0120] It will be understood that although the terms “first,” “second,” etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the invention, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0121] As used herein (including in the claims), unless the context otherwise indicates, the singular form of a term herein shall be construed as including the plural form, and vice versa. For example, unless the context otherwise indicates, singular references (such as “a” or “an” (such as a mobile device, network entity, step, parameter, or message)) herein (including in the claims) mean “one or more” (e.g., one or more mobile devices, one or more network entities, one or more steps, one or more parameters, or one or more messages). Throughout the specification and claims of this disclosure, the words “comprise,” “including,” “having,” and “containing,” as well as variations of these words (e.g., “comprising” and “comprises” or the like), mean “comprising” and are not intended to exclude (and do not exclude) other components.

[0122] The use of any and all example or exemplary language (“e.g.,” “such as,” “for example,” and similar language) provided herein is intended only to better illustrate the invention and does not indicate any limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating that any unclaimed element is essential for the practice of the invention.

[0123] Any steps described in this specification may be performed in any order or simultaneously unless otherwise stated or required by the context. Furthermore, the fact that a step is described as being performed after another step does not preclude the execution of intermediate steps.

[0124] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It will be further understood that the terms used herein should be interpreted as having the same meaning as they have in the context of this specification and the relevant field, and will not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0125] Similar numbers always refer to similar elements. Therefore, identical or similar numbers can be described with reference to other accompanying figures, even if they are neither mentioned nor described in the corresponding figures. Furthermore, elements not indicated by figure labels can be described with reference to other accompanying figures.

[0126] Methods for manufacturing and / or operating any of the devices disclosed herein are also provided. These methods may include the steps of: providing each disclosed feature and / or configuring or using the corresponding feature for its stated functionality.

[0127] Typical embodiments of the invention have been disclosed in the accompanying drawings and description, and although specific terms are used, they are used in a general and descriptive sense only and are not intended to be limiting. The scope of the invention is set forth in the following claims.

Claims

1. A method for managing hardware resources in an Open Radio Access Network (Open RAN) cloud platform, wherein the cloud platform includes multiple processor cores, and wherein the cloud platform is configured to host multiple application processes, the method comprising: Based on the processing requirements of the corresponding application processes, zero or more processor cores are dynamically allocated to each of the multiple application processes.

2. The method of claim 1, wherein dynamically allocating zero or more cores to each of the plurality of applications comprises allocating zero cores to the application process if the corresponding processing requirement of the application process is zero.

3. The method according to claim 1 or claim 2, wherein the cloud platform is a containerized cloud platform, and wherein each of the application processes is hosted via a corresponding Pod managed by the containerized cloud platform.

4. The method according to any of the preceding claims, wherein one or more of the plurality of processor cores are dedicated cores allocated to the scheduler of the cloud platform.

5. The method of claim 4, wherein each of a plurality of processor cores, which is not one or more dedicated cores, forms a resource pool, and wherein dynamically allocating zero or more processor cores from the plurality of processor cores to each of the plurality of application processes includes dynamically allocating zero or more processor cores from the resource pool to each of the plurality of application processes.

6. The method according to any of the preceding claims, wherein the processing requirements of each application process include predicted processing requirements, wherein the model is used to predict the processing requirements for the application process.

7. The method according to claim 6, wherein the model is an artificial intelligence (AI) model.

8. The method of claim 6 or 7, wherein the model is trained using historical data of the application process's processing requirements or via synthetic training data.

9. The method according to any one of claims 6 to 8, wherein each of the plurality of processor cores is operable in one or more processor idle sleep states, wherein the method further comprises: Based on the predicted processing requirements of the corresponding application process to which one of the multiple processor cores is assigned, the processor core is switched to an idle sleep state.

10. The method of any one of claims 6 to 9, wherein each of the plurality of processor cores is operable in one or more power performance states, wherein the method further comprises: Based on the predicted processing requirements of the corresponding application process to which one of the multiple processor cores is assigned, the processor core is switched to a power performance state.

11. The method according to any of the preceding claims, wherein the processing requirements include data processing load and / or network traffic load.

12. The method according to any preceding claim, wherein each of the plurality of processor cores is operable in a normal mode and one or more power-saving modes, the method further comprising: Based on the processing requirements of the multiple application processes, one or more of the multiple processor cores are switched to power-saving mode; and / or Based on the processing requirements of the multiple application processes, one or more of the multiple processor cores are switched from power-saving mode to normal mode.

13. The method of claim 12, wherein the one or more power-saving modes include: One or more processors are in an idle sleep state; and / or One or more power performance states.

14. The method according to any of the preceding claims, wherein the cloud platform comprises one or more servers, preferably multiple servers, wherein the multiple processor cores comprise corresponding multiple processor cores from each server.

15. A cloud platform configured to perform the method according to any of the preceding claims.

16. A computer program comprising instructions that, when executed on a processor, cause the processor to perform the method according to any one of claims 1 to 13.

Images