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

Abstract

The invention discloses a method for managing hardware resources in an open RAN cloud platform, a cloud platform, an open RAN application and a computer program. A method of managing hardware resources in an open radio access network, open RAN cloud platform is provided. The cloud platform is configured to host open RAN applications at a radio site. The open RAN application comprises one or more application processes. The method includes transmitting hardware resource status data from a manager of the cloud platform to the open RAN application.

Description

Technical Field

[0001] This invention relates to the management of hardware resources in an open radio access network (RAN) cloud platform. In particular, this invention relates to a method for sharing hardware resource status data between the cloud platform and open RAN applications.

[0002] Glossary RAN—Radio Access Network MNO – Mobile Network Operator O-RAN – Open RAN Alliance O-DU—Open Distributed Unit O-CU — Open Centralized Unit O-RU – Open Radio Unit OS - Operating System GPU—Graphics Processing Unit API—Application Programming Interface SMO – Service Management and Orchestration DMS - Deployment Management Service NF - Network Functions IMS – Infrastructure Management Services COTS – Off-The-Shelf Commercial Products CaaS – Container as a Service CPU — Central Processing Unit 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 — Evolved Node B gNB - Next Generation Node B TRP - Transmission and Receive Point PS — Handling the 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 EDGE – Enhanced Data Rate Evolution of 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 Long Term Evolution 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—Optical Disc Read-Only Memory DVD-ROM—Digital Multifunction Optical Disc 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 technical architecture concept designed to decouple the hardware and software components of a radio access network (RAN). It encompasses open interoperable 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 between various network components. Open RAN is strategically important 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 facilitates 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 hardware replacement. Open RAN is crucial in MNOs' long-term network innovation strategies, offering energy efficiency, supply chain diversification, enhanced resilience, and facilitating innovation and competition.

[0004] Figure 1 The illustration shows some components of an exemplary open RAN system 100, which is implemented as a cloud computing platform (O-Cloud). The system 100 can be described with reference to 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 and 120N that comply with O-RAN requirements. Each physical infrastructure node 120A includes compute 121, networking 122, GPU 123, and storage 124 components, along with 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 and 120N is configured to host associated O-RAN network functions 150 and 160, which are implemented at the Open RAN application layer 140. The network functions 150 and 160 implemented at the Open RAN application layer 140 may include O-CU 160, O-DU 150, and O-RU.

[0006] In the O-Cloud hypervisor or container / OS layer 130, there exists a set of cloud functions to enable open RAN applications 150 and 160 to run on one or more O-Cloud hardware nodes 120A. These cloud functions may include supporting software components such as operating systems, containers (standalone executable software packages), container orchestration platforms (such as Kubernetes), and container runtimes. The 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 various vendor solutions. Leveraging a decoupled architecture, O-Cloud allows for hardware procurement from different vendors, promoting hardware neutrality and flexibility. It supports Service Management and Orchestration (SMO), enabling attribution decisions and the selection of 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 human intervention, ultimately supporting efficient resource utilization and scalability of RAN network functions in a cloud-native environment.

[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 functions of the O-Cloud platform is to schedule different RAN workloads (running in corresponding Pods) and allocate hardware resources (such as compute, storage, and networking resources).

[0009] In existing O-Cloud solutions, the workload scheduler allocates hardware resources (i.e., the number of CPUs, storage devices, etc.) based on the requirements of the RAN software. When CPUs / storage devices are insufficient to support the workload, the O-Cloud scheduler scales up to allocate more CPUs / storage devices to certain Pods. When the workload of a Pod decreases, the O-Cloud scheduler scales down to reduce CPU / storage resources. This scaling up / down is triggered by the application and the actual workload. In this way, hardware resources can be flexibly allocated to each application process. Some RAN applications fully utilize the flexibility provided by the cloud platform and request a large amount of additional resources for extra functionality. However, in some cases, this can lead to the RAN application monopolizing available resources. The workload scheduler may allocate such a high proportion of available hardware resources to a single application process that the workload scheduler cannot allocate enough resources to other applications, or even perform its own functions correctly. This disclosure aims to address this problem. Summary of the Invention

[0010] A method is provided for managing hardware resources in an Open Radio Access Network (Open RAN) cloud platform. The cloud platform is configured to host Open RAN applications. The Open RAN applications may include one or more application processes. The method may include transmitting hardware resource status data from the master node of the cloud platform to the Open RAN applications.

[0011] The cloud platform can be configured to host the Open RAN application at a radio site. The method may include transmitting hardware resource status data from the master node of the cloud platform to the Open RAN application at the radio site. In other words, the physical server of the cloud platform may be located in the same geographical location as the radio equipment controlled by the RAN application (e.g., a physical antenna associated with an O-RU of a base station).

[0012] The master node can be a Kubernetes (RTM) master node.

[0013] The Open RAN application may be one of several Open RAN applications hosted on the cloud platform (e.g., at the radio station).

[0014] The hardware resource state data can be transmitted via a representational state transition application programming interface.

[0015] A REST API is a convenient way to transmit hardware resource status data. Advantageously, REST APIs are relatively simple to implement. However, the interface can be any API.

[0016] In some examples, the API (e.g., a REST API) can be used to send alerts from the master node of the cloud platform to the Open RAN application. However, the API can also be used for other purposes. For example, alerts may trigger logs, which can also be transmitted via the API. The API can be used to transmit various hardware resource status data. The API may facilitate the platform's ability to quickly identify and locate problems.

[0017] The hardware resource status data may include log data.

[0018] Advantageously, by transmitting log data between the cloud platform and RAN applications, platform logs can be included in application logs, and vice versa. Logs can be used to correlate CaaS layer activities with application layer activities, which aids in problem diagnosis. Therefore, software issues can be debugged more easily.

[0019] The hardware resource status data may include hardware resource utilization statistics.

[0020] The hardware resource utilization statistics may include the hardware resource utilization associated with each application process.

[0021] The hardware resource status data may include alarms indicating that the hardware resource utilization associated with the open RAN application is higher than a threshold.

[0022] The method may also include transmitting an instruction from the open RAN application to the master node of the cloud platform that the open RAN application has received the alert and is taking action to reduce the utilization of hardware resources associated with the open RAN application.

[0023] One or more of the described methods can be executed by the cloud controller.

[0024] The master node may be a first master node in active mode. The cloud platform may also include a second master node in standby mode. The cloud platform may be configured to perform a master node switchover action upon detecting a cloud platform performance condition, unless the master node switchover action is suppressed. The master node switchover action may include switching the first master node to standby mode and switching the second master node to active mode. The method may also include identifying the cloud platform performance condition. The method may also include suppressing the master node switchover action (e.g., for a predetermined period of time) based on the indication that the open RAN application has received the alert and is taking action to reduce the utilization of hardware resources associated with the open RAN application.

[0025] Master node failover is typically performed automatically when a problem is detected to attempt and resolve it. For example, if the master node is already paused (e.g., due to a software failure), switching the standby master node to active may resolve the issue. However, if the problem is caused by resource scarcity, the failover action will not resolve the issue (and will only lead to further instability).

[0026] Two servers can have the same number of CPU cores, and resources can be shared between them. Therefore, switching the master node between servers may not solve the problem.

[0027] In other words, even if a problem exists (e.g., a heartbeat issue), the cloud platform can suppress master node failover. The cloud platform can determine that the RAN application is a likely cause of the performance condition (e.g., by linking the performance condition to an alarm). The cloud platform can further determine that the RAN application is taking action to remedy the situation (e.g., by recognizing the indication that the open RAN application has received the alarm and is taking action to reduce the utilization of the hardware resources associated with the open RAN application), and therefore the performance condition may be resolved quickly without a failover.

[0028] The first and second master nodes can be Kubernetes master nodes.

[0029] The cloud platform performance status may include the loss of synchronization of the heartbeat signal between the first master node in active mode and the second master node in standby mode.

[0030] The cloud platform may include multiple servers. A first server among the multiple servers may include the first master node. A second server among the multiple servers may include the second master node.

[0031] The method may also include measuring the utilization of hardware resources associated with each application process (i.e., at the Pod level).

[0032] The hardware resource utilization statistics and / or log data may include the hardware resource utilization associated with each application process.

[0033] The hardware resource utilization associated with the open RAN application can be calculated based on the hardware resource utilization associated with each application process.

[0034] The method may further include calculating the hardware resource utilization associated with the open RAN application based on the hardware resource utilization associated with each application process.

[0035] The method may further include determining that the hardware resource utilization associated with the open RAN application is higher than the threshold.

[0036] The cloud platform may include multiple processor cores. Each application process may be allocated zero or more cores. The hardware resource utilization associated with each application process can be determined based on the CPU utilization of the zero or more cores allocated to the corresponding application process.

[0037] One or more of the plurality of processor cores may be dedicated cores assigned to the manager of the cloud platform.

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

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

[0040] 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.

[0041] One or more of the described methods can be executed by the RAN application.

[0042] The method may further include reducing the processing requirements of the open RAN application based on the alarm (i.e., in response to the alarm) to reduce the utilization of hardware resources associated with the open RAN application.

[0043] Reducing the processing requirements of the Open RAN application may include reducing the frequency of probes used to collect network performance metrics associated with the Open RAN application.

[0044] In this context, "network performance metric" can be understood to refer to a performance metric associated with the telecommunications network served by the RAN application (i.e., the radio network of the base station), rather than a performance metric associated with the network (which may be a wired network) that provides the connection to the cloud platform.

[0045] The method may further include calculating the hardware resource utilization associated with the Open RAN application based on the hardware resource utilization associated with each application process, and determining whether the hardware resource utilization associated with the Open RAN application is higher than the threshold. Remedial action can be taken in response to the determination rather than the alarm. In other words, the application can self-regulate based on hardware resource status data.

[0046] A cloud platform configured to perform the above methods is also provided.

[0047] An Open Radio Access Network (Open RAN) application is also provided. The Open RAN application includes instructions that, when executed on a processor, cause the processor to perform the methods described above.

[0048] A computer program is also provided. The computer program includes instructions that, when executed on a processor of a cloud platform, cause the cloud platform to perform the described method. Attached Figure Description

[0049] Figure 1 The illustration shows an example cloud platform.

[0050] Figure 2 The diagram illustrates the differences between a single (non-open) RAN and an open RAN.

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

[0052] Figure 3 The diagram illustrates an example Open RAN CaaS layer architecture.

[0053] Figure 4 The illustration shows a specific example of CPU core allocation.

[0054] Figure 5 The flowchart illustrates a method based on a specific example.

[0055] Figure 6 The illustration shows a cloud platform based on a specific example. Detailed Implementation

[0056] Prior to Open RAN, mobile networks were built by a small number of vendors with tightly coupled hardware and software. Interoperability between equipment from different vendors was limited, and this arrangement resulted in limited flexibility and innovation. One goal of Open RAN is 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.

[0057] In some existing single-RAN technology examples, 2G, 4G, and 5G RAN applications may all run on a single server. This can lead to a lack of scalability, which is addressed in the open RAN example.

[0058] As mentioned above, Open RAN systems decouple the hardware and software in a RAN network and allow hardware and software components to be supplied separately. To achieve this, the Open RAN Alliance has provided new standards for the interaction between the hardware and software components of Open RAN systems (the term "O-RAN" generally refers to the standards specified by the Open RAN Alliance).

[0059] Figure 2 The diagram illustrates the differences between a single (non-open) RAN and an open RAN. The following benefits can be achieved by migrating from a single RAN to an open RAN: Disaggregation; Decouple HW from SW; Open ecosystem; Open interfaces; and Intelligent management.

[0060] Open RAN enables interoperability of hardware and software components from different vendors. By doing so, Open RAN also provides resilience to MNOs by promoting vendor diversity in the network. If a component 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 a component from another vendor without causing major network disruption.

[0061] Open RAN also offers potential energy efficiency improvements, such as by flexibly supplying hardware to meet network requirements.

[0062] Open RAN implements function block decoupling, where baseband processing functions are separated into different blocks, allowing for contributions and innovation from various vendors. However, true interoperability and innovation require solutions from different vendors to work together seamlessly. Ensuring seamless interoperability between hardware and software components across competing vendors is crucial to the success of Open RAN. Decoupling RAN functions into software-based components that can be hosted on different processor architectures introduces interoperability challenges when managing and orchestrating these functions.

[0063] A cloud platform, sometimes referred to as "O-Cloud," is 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 deployed in one or more node clusters (also known as "server nodes"). These provide the hardware resources required to support network function deployments (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.

[0064] 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 functions deployed by the network functions.

[0065] To facilitate interoperability and create an environment for competition and innovation, a key feature of virtualized and open RAN is the ability for multiple hardware and software vendors to coexist in an operator's RAN domain. Standards and interfaces have been defined to enable interoperability.

[0066] Figure 3The diagram illustrates an example Open RAN CaaS layer architecture. (Example:) Figure 3 As shown, each radio station has one or more Kubernetes master nodes and one or more worker nodes. Two CPU cores can be reserved for each Kubernetes worker node and master node.

[0067] The master node defines the Kubernetes control plane and is responsible for managing worker nodes and Pods in the cluster. In the example shown, the master node includes an API server, scheduler, Kube controller manager, cloud controller manager, and key-value store. The master node also exposes a user interface and a command-line interface (Kubectl).

[0068] The one or more worker nodes host container Pods as components of application workloads. In the example shown, a worker node may host or support a pair of RAN application Pods, namely a first Pod and a second Pod. The first Pod includes a first container and a second container. The second Pod includes a third container. Worker nodes also include components such as Docker, Kubelet, and Kube-proxy.

[0069] In some open RAN deployments, instability issues at the CaaS (Container as a Service) layer (such as Kubernetes control plane switching) are caused by specific open RAN applications. In some concrete examples, 2G GSM RAN applications have disrupted the stability of the cloud platform and affected the network performance of that RAN application as well as other RAN applications on the cloud platform. This instability can adversely impact the customer experience.

[0070] Root cause analysis of these instability issues revealed that the Kubernetes controller failover was not due to a problem originating from the CaaS layer, but rather because the RAN application (in this specific example, the GSM probe of the GSM RAN application) was overusing CPU resources. At least two CPUs need to be reserved for the CaaS layer / OS. However, the RAN application's overuse of CPU resources meant that only limited CPU resources were available for the CaaS layer. Due to this CaaS layer resource scarcity, the Kubernetes controller may experience a loss of heartbeat synchronization between the active and standby master nodes. This loss of synchronization triggers a Kubernetes master node failover (i.e., the active master node switches to standby, and the standby master node switches to active). This issue has been observed in field deployments.

[0071] Typically, synchronization between the active and standby master nodes is unaffected by the resource utilization of RAN applications. However, some RAN application processes may consume excessive resources.

[0072] In a specific example, the GSM probe responsible for collecting performance metrics and sending them to the base station controller in the data center might be overusing resources. 4G and 5G RAN applications running in the same cluster might have CPUs dedicated to RAN workloads for those applications. Therefore, the GSM probe cannot access those resources (even if they are not fully utilized) and instead draws CPU workloads from the CPU pool. This can lead to a shortage of CPUs available for the platform, potentially resulting in lost heartbeat synchronization and triggering a handover.

[0073] The switching of active / standby master nodes should be smooth. However, switching due to loss of heartbeat synchronization can lead to instability of the CaaS platform, which affects the KPIs of RAN applications (especially the 2G GSM KPIs themselves).

[0074] In some examples, CPU cores allocated to the CaaS layer (for the master node) are not strictly reserved and dedicated to the CaaS layer, but are shared to some extent. These CPU cores reside in a shared CPU pool. Therefore, resource scarcity can have a significant impact on the stability of the CaaS layer.

[0075] In other examples, the two CPU cores allocated to the CaaS layer are truly dedicated and reserved. Nevertheless, GSM probes may utilize other pooled resources at excessively high levels, which could lead to instability in any case.

[0076] In some examples, CaaS platforms are configured to prioritize the applications they host at the expense of CaaS layer functionality, which may be delayed or reduced. However, the loss of some functionality (e.g., heartbeat synchronization) has a significant impact on the entire platform. Some CaaS platforms cannot prioritize specific CaaS platform functionality at the expense of the available resources of the hosted applications.

[0077] Instability issues caused by application processes can be intermittent. For example, the utilization rate of GSM probes may not always cause problems, but issues may occur at time intervals. This could be because the probes collect metrics at time intervals.

[0078] When the GSM probe unnecessarily uses the CPU and triggers a switchover, the platform may appear to function normally for a period of time after the switchover. Then, the same problem may be observed with the new active master node.

[0079] If instability is observed in the CaaS layer, the OS may also be unstable. This could affect other applications hosted by the platform, even those that do not utilize significant hardware resources.

[0080] The proposed method addresses these issues by transmitting hardware resource status data between the cloud platform master node and RAN applications. RAN applications can set resource utilization thresholds for specific applications or sub-functions. For example, a 2G GSM RAN application can enforce CPU utilization limits for 2G GSM probes.

[0081] Current CaaS platforms do not provide applications with visibility into how many resources each Pod is using. Therefore, a specific example of the proposed method provides a resource utilization visibility metric. In this way, hardware resource utilization data, such as CPU utilization per Pod, can be provided to the RAN application layer. The CaaS layer has visibility into the resource utilization of each Pod, and the proposed method extends this visibility to the application layer.

[0082] Application developers can improve their applications based on new data from the platform. This new data can include alerts, logs, CPU usage, and other data, which is sent to the application via API.

[0083] As mentioned above, the cloud platform can share hardware resource status data with RAN applications and rely on RAN applications to monitor resource utilization. Alternatively, if a CPU utilization threshold is reached, the CaaS layer can send an alert to the RAN application. The RAN application can receive this alert and reduce probe activity. The CaaS layer can send alerts via a REST API. In this way, the RAN application can avoid excessive resource utilization, thereby avoiding Kubernetes controller resource exhaustion and triggering failover.

[0084] Alerts can be configured to be triggered by multiple different events. For example, if the utilization of a 2G GSM Pod exceeds 80%, this might trigger an alert. This alert can be sent to the 2G GSM application via a REST API to notify the application of the issue. The application can receive the alert and adjust its data collection / optimization behavior to reduce CPU usage caused by the 2G probe, and send a confirmation to the CaaS platform. In response, the CaaS platform can ensure that the switchover does not occur unnecessarily (or too frequently).

[0085] The CaaS layer has access to Pod-level metrics (e.g., CPU statistics). In other words, the CaaS layer knows not only the GSM CPU utilization, but also the CPU utilization of all Pods.

[0086] Alert thresholds can be configurable. For example, the threshold could be 90% of dedicated resources, or 80% if pooled resources are used. GSM CPU metric percentages can indicate how much dedicated resource is being used at the Pod level, which can vary depending on how much CPU pooled resource is allocated. Therefore, percentage thresholds can be configured differently at the Pod level depending on application requirements.

[0087] If the threshold is exceeded, the RAN application can address the issue by, for example, reducing the probe interval.

[0088] In the example above, it was found that the probe used for GSM performance measurement consumed excessive CPU resources. This is likely due to the probe running too frequently. This specific example relates to a 2G GSM RAN application. However, this issue is not unique to 2G GSM RAN applications and can occur in any RAN application.

[0089] In some examples, 4G and 5G RAN applications may contribute to instability. These RAN applications may allocate dedicated pods to CPUs, even if these pods do not have any running workloads. Therefore, these RAN applications may also contribute to resource scarcity by limiting the resources available in the pool.

[0090] The proposed method can be implemented in a CaaS platform, a RAN application, or (preferably) both. The CaaS platform can monitor resource utilization and send an alert to the RAN application when resource utilization exceeds a threshold. The GSM RAN application can receive the alert and reduce resource utilization in response.

[0091] In another example, the CaaS platform can send resource utilization data to RAN applications. RAN applications can monitor resource utilization, identify whether it exceeds a threshold, and reduce resource utilization as a response.

[0092] In existing CaaS cloud platforms, there is currently no communication between the CaaS layer and RAN applications regarding hardware resource status data (e.g., resource utilization statistics and / or alarms). Therefore, RAN applications may be unaware of any problems caused by excessive resource utilization within the cloud platform. The proposed method provides a communication mechanism between the platform and applications to provide this data. This communication mechanism can be provided in the form of an API (such as a REST API).

[0093] In addition to addressing the identified problems, the proposed method can improve the debugging of RAN application and CaaS layer issues by sharing logs between RAN applications and the CaaS layer. In existing single RANs, all components are supplied by the same vendor. These components have hardware with built-in internal communication and are therefore easy to debug. In contrast, in some existing open RAN ecosystems, debugging information is not shared as freely between components. An example of the proposed method addresses this issue by sharing logs on a new API.

[0094] In addition to alerts and logs, the CaaS layer can also provide statistical information to the application layer via API.

[0095] RAN applications can be modified to receive and process hardware resource status data from the CaaS layer and take appropriate actions. For example, RAN applications can monitor and respond to alarms, incorporate CaaS logs into their own logs, and / or analyze statistics.

[0096] In a specific example, the CaaS master node can receive the following confirmation from the RAN application layer: the RAN application has received an alert and is taking action to mitigate excessive CPU usage. The CaaS master node can receive this confirmation and understand that the RAN application (e.g., a 2G GSM application) is taking action to mitigate excessive CPU usage. Therefore, the CaaS master node can suppress the switch to a standby master node, even if there may be issues with heartbeats between master nodes.

[0097] It should be noted that the CaaS layer may not actively suppress handover in all cases. Legitimate issues should still lead to a master node handover. However, in response to issues with identifiable causes that are already being remedied by RAN applications, the CaaS layer will not trigger a handover. In this way, unnecessary instability is avoided. However, instability caused by genuine issues can still be resolved through handover in the usual way.

[0098] GSM RAN applications can be allocated hardware resources on the same server as the active master node (e.g., server 1). Excessive CPU utilization on server 1 can lead to resource depletion and directly impact the active master node. However, this problem can also occur when GSM RAN applications are allocated hardware resources on servers different from the active master node. Resources are shared between servers, so excessive CPU usage on any server can lead to resource depletion for the active master node. Furthermore, heartbeats are bidirectional between the active and standby master nodes, so any resource depletion on the same server as the standby master node (e.g., server 2) can also cause a loss of heartbeat synchronization.

[0099] In a specific example, the active master node manages a cluster on a server. However, hardware resources are pooled and reside on multiple different servers. Problems (e.g., heartbeat synchronization loss) may be triggered when application processes (e.g., 2G GSM probes) consume excessive CPU cores and CPU utilization reaches a certain threshold. This can lead to resource depletion and trigger a switchover from the active master node to a standby master node on a different server. This unnecessary switchover can lead to further instability and a loss of user service quality. The root cause of this problem consists of two parts: 1) the RAN application consumes too many resources and is unaware of the impact on the CaaS layer; and 2) the CaaS layer is overly sensitive to problems caused by application resource depletion and unnecessarily triggers a switchover. The proposed method addresses the first problem by sharing hardware resource status data from the CaaS layer to the application layer. The proposed method addresses the second problem by receiving confirmation of actions being taken by the RAN application from the CaaS layer and suppressing the switchover.

[0100] refer to Figure 4 This illustrates a specific example of CPU core allocation. For example... Figure 4 As shown, the cloud platform may include two servers, each with 32 cores. The two cores on each server can be allocated to the CaaS layer (e.g., the active master node on server 1 and the standby master node on server 2).

[0101] like Figure 4 As shown, server 1 can be used to deploy 4G and 5G Pods, and GSM Pods can be allocated to server 2. Some RAN application vendors request dedicated CPU resources for each Pod allocation. Therefore, as can be seen on server 1, only 2 CPU cores are available for the CaaS layer, and there is almost no CPU pool. This can lead to a lack of flexibility and resource scarcity.

[0102] The master node manages the workload of the Pods. The master node can schedule tasks using resources on either server 1 or server 2. Server 1 has an active master node, and server 2 has a standby master node. Both servers have a small amount of CPU resources in the resource pool for scheduling.

[0103] In some existing Kubernetes Open RAN deployments, the master node resides in a remote data center, while the worker nodes reside in the edge network. This ensures sufficient resources for the master node but may introduce latency issues between the master and worker nodes. In contrast, the proposed system provides both the master and worker nodes on the same server cluster within the edge network.

[0104] In some specific examples, the proposed method employs a single-node solution, where each cluster (an edge deployment of each geographically co-located server) provides only one worker node.

[0105] Figure 5 The diagram illustrates a flowchart of an example method for managing hardware resources in an open RAN cloud platform that includes multiple processor cores. The cloud platform is configured to host multiple application processes. The method includes: At step 501: Based on the processing requirements of the corresponding application process, zero or more processor cores from the plurality of processor cores are dynamically allocated to each of the plurality of application processes.

[0106] Figure 6 The illustration shows a cloud platform 601 according to a specific example. The cloud platform 601 includes multiple processor cores 602A, 602B, and 602C.

[0107] 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 relative to existing network architectures, it should be understood that changes to the architecture (and / or nomenclature) are possible, but this disclosure still applies in such cases. All features disclosed herein can be combined in any combination, except for combinations where at least some of such features and / or steps are mutually exclusive, even if such combinations are not explicitly detailed. In particular, preferred features of the invention apply to all aspects of the invention and can be used in any combination. Similarly, features described in non-essential combinations can be used alone (in non-combined form).

[0108] A base station (BS) generally refers to a fixed station that communicates with a UE and / or another BS and exchanges various data and control information with the UE and another BS. 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 other suitable terms depending on the protocol, standard, context, or technology. In some examples, a base station may include two or more transceivers that can be co-located or non-co-located. Each transceiver can communicate on the same or different carrier frequencies and in the same or different frequency bands.

[0109] When this application refers to a server or network entity, for example, it may actually be a pair of server or network entities (primary and failover) for redundancy.

[0110] Examples of mobile devices include various devices that transmit user data and / or various control information to and 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.

[0111] 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 are applicable to a wide range 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 uplink. LTE-A is an evolution of 3GPP LTE. 3GPP NR employs OFDMA in both the 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 based on a mobile communication system corresponding to a 3GPP NR system, aspects of the present invention not specific to 3GPP NR are applicable to other mobile communication systems.

[0112] Cellular communication systems comprise multiple cells. A cell refers to a geographical area to which one or more nodes provide communication services. Therefore, communication with a specific cell can mean communication with a gNB or node providing 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 that specific cell and the UE. The UE can measure the downlink channel state received from a specific node using (multiple) cell-specific reference signals ((multiple) CRS) transmitted on CRS resources and / or (multiple) channel state information reference signals ((multiple) CSI-RS) transmitted by (multiple) antenna ports allocated to that specific node on that specific node. Meanwhile, the 3GPP system uses the concept of cells to manage radio resources and distinguishes between cells associated with radio resources and cells in geographical areas.

[0113] The examples described can be executed on any suitable data processing device, such as a personal computer, laptop, mobile phone, server, virtual machine, etc. The above description of the systems and methods has been simplified for the sake of discussion and is intended to provide specific examples illustrating the invention. Those skilled in the art will understand that different types of systems and methods can be used. It should be understood that the boundaries between logical blocks are merely illustrative, and alternative embodiments may combine logical blocks or elements, or may impose alternative functional decompositions on various logical blocks or elements.

[0114] It should be understood that the above-described functions can be implemented as hardware and / or software as one or more corresponding modules. For example, the above-described functions can be implemented as one or more software components executed by the system's processor. Alternatively, the above-described functions 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 the method steps described above, can each be implemented by their respective corresponding modules. Furthermore, multiple method steps implemented in the flowcharts included herein, or multiple method steps described above, can be implemented together by a single module.

[0115] The example can be implemented by computer software or a "computer program". 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 method 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 applets, 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 a communication signal, data broadcast, a communication link between two or more computers, etc.

[0116] The computer program can be configured to control network entities and / or mobile devices to perform any of the methods disclosed herein. A network entity for a telecommunications network (e.g., a cellular network) is also provided, configured to operate according to some of the methods disclosed herein. For example, the network entity may include a processor and at least one communication interface, which in particular includes one or both of a transmitter and a receiver. A mobile device (e.g., a UE) is also provided, configured to operate according to some of the methods disclosed herein. The mobile device may also include a processor and at least one communication interface, which in particular includes one or both of a transmitter and a receiver.

[0117] Each feature disclosed in this specification, unless otherwise stated, can be replaced by alternative features serving the same, equivalent, or similar purpose. Therefore, unless otherwise stated, each disclosed feature is merely one example among a series of equivalent or similar features.

[0118] It should 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, a first element may be referred to as a second element without departing from the scope of the invention, 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.

[0119] As used herein, including in the claims, unless the context otherwise indicates, the singular form of a term herein shall be construed to include the plural form, and vice versa. For example, unless the context otherwise indicates, singular references herein (including in the claims), such as “a (or an)” (e.g., a mobile device, a network entity, a step, a parameter, or a message) 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 “comprising,” “including,” “having,” “containing,” and variations thereof, such as “comprising” and “including having,” or similar words, mean “comprising” and are not intended to (and will not) exclude other components.

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

[0121] Any steps described in this specification may be performed in any order or simultaneously unless the description or context requires otherwise. Furthermore, when a step is described as being performed after a step, this does not preclude the execution of intermediate steps.

[0122] 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 should also be understood that the terms used herein shall be interpreted as having the same meaning as in the context of this specification and related art, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0123] The same reference numerals refer to the same element throughout. Therefore, the same or similar reference numerals may also be described with reference to other accompanying drawings, even if they are not mentioned or described in the corresponding drawings. Furthermore, elements not indicated by reference numerals may be described with reference to other accompanying drawings.

[0124] A method for manufacturing and / or operating any of the devices disclosed herein is also provided. The method may include steps of providing each disclosed feature and / or configuring or using the respective feature to achieve its stated function.

[0125] Typical embodiments of the invention have been disclosed in the accompanying drawings and description, and although specific terminology has been used, it is used only in a general and descriptive sense and not for limiting purposes. 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 and an open RAN cloud platform, wherein the cloud platform is configured to host open RAN applications at radio sites, wherein the open RAN applications include one or more application processes, the method comprising: Hardware resource status data is transmitted from the master node of the cloud platform at the radio station to the open RAN application.

2. The method of claim 1, wherein the open RAN application is one of a plurality of open RAN applications hosted by the cloud platform at the radio site.

3. The method of claim 1 or 2, wherein the hardware resource state data is transmitted via a Representational State Transition Application Programming Interface (REST API).

4. The method as described in any of the preceding claims, wherein the hardware resource status data includes log data.

5. The method as described in any of the preceding claims, wherein the hardware resource status data includes hardware resource utilization statistics.

6. The method of claim 5, wherein the hardware resource utilization statistics include hardware resource utilization associated with each application process.

7. The method of any of the preceding claims, wherein the hardware resource status data includes an alarm indicating that the hardware resource utilization associated with the open RAN application is higher than a threshold.

8. The method of claim 7, further comprising: The Open RAN application sends the following instruction to the master node of the cloud platform: The Open RAN application has received the alert and is taking action to reduce the utilization of hardware resources associated with the Open RAN application.

9. The method of claim 8, wherein the master node is a first master node in active mode, and wherein the cloud platform further includes a second master node in standby mode, wherein the cloud platform is configured to perform a master node switchover action upon detecting a cloud platform performance status, unless the master node switchover action is suppressed, wherein the master node switchover action includes switching the first master node to standby mode and switching the second master node to active mode, the method further comprising: Identify the performance status of the cloud platform; as well as The master node switching action is suppressed based on the indication that the Open RAN application has received the alert and is taking action to reduce the utilization of hardware resources associated with the Open RAN application.

10. The method of claim 9, wherein the cloud platform performance status includes the loss of synchronization of heartbeat signals between the first master node in active mode and the second master node in standby mode.

11. The method of any one of claims 4 to 10, further comprising: Measure the hardware resource utilization associated with each application process. The hardware resource utilization statistics and / or log data mentioned therein include the hardware resource utilization associated with each application process, and / or The hardware resource utilization associated with the open RAN application is calculated based on the hardware resource utilization associated with each application process.

12. The method of claim 11, wherein the cloud platform includes a plurality of processor cores, wherein each application process is allocated zero or more cores, and wherein the hardware resource utilization associated with each application process is determined based on the CPU utilization of the central processing unit allocated to the zero or more cores of the respective application process.

13. The method of claim 12, wherein one or more of the plurality of processor cores are dedicated cores allocated to the cloud platform.

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

15. The method of any one of claims 12 to 14, wherein the cloud platform comprises one or more servers, and wherein the plurality of processor cores comprises a respective plurality of processor cores from each server.

16. The method of any of the preceding claims, wherein the cloud platform is a containerized cloud platform, and wherein each application process is hosted via a corresponding Pod managed by the containerized cloud platform.

17. The method of claim 7 or 8, further comprising: The processing requirements of the Open RAN application are reduced based on the alarm, thereby reducing the utilization of hardware resources associated with the Open RAN application.

18. The method of claim 17, wherein reducing the processing requirements of the open RAN application includes reducing the frequency of probes used to collect network performance metrics associated with the open RAN application.

19. A cloud platform configured to perform the method of any one of claims 1 to 16.

20. An open radio access network, an open RAN application, comprising instructions that, when executed on a processor, cause the processor to perform the method of any one of claims 1 to 8 or 17 to 18.

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

Images