Apparatus and method for providing resource management policies in telecommunication system

Abstract

An apparatus and method are provided for implementing an rApp-based resource control mechanism to scale network functions. The apparatus may include: a memory storing instructions; and at least one processor configured to execute the instructions to: receive data including at least one performance metric from an O-CU in an O-cloud computing environment, where the at least one performance metric includes a performance metric of the O-CU; comparing the at least one performance indicator with a first predetermined threshold; receiving and evaluating a resource state of at least one physical host in the O-cloud computing environment; and based on the comparison and the evaluation, creating a resource management policy for allocating O-cloud computing resources of the at least one physical host to scale the O-CU at at least one physical location in the O-cloud computing environment.

Description

Technical Field

[0001] Apparatus and methods consistent with example embodiments of the present disclosure relate to the evaluation, control, and execution of resource management control policies created by a modular application (rApp) hosted in a radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework for a telecommunications network, and more particularly, to a method, apparatus, and non-transitory computer-readable storage medium for storing instructions for executing control and implementation of at least one resource management policy for allocating O-cloud computing resources to one or more centralized units (CUs). Background Art

[0002] The Radio Access Network (RAN) is an important component in a telecommunication system as it connects the end-user equipment (or user equipment) to the rest of the network. The RAN comprises a combination of various network elements (NEs) that connect the end-user equipment to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific.

[0003] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. To this end, O-RAN decomposes RAN functions into centralized units (CU), distributed units (DU), and radio units (RU). CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. DU is a logical node for hosting the radio link control (RLC), media access control (MAC), and physical (PHY) sublayers of the RAN. RU is a physical node that converts the radio signal from the antenna into a digital signal, which can be sent to the DU via the FrontHaul. Since there are open protocols and interfaces between these entities, they can be developed by different vendors.

[0004] Figure 1 The O-RAN architecture of the related art is shown. Figure 1 , RAN functions in the O-RAN architecture are controlled and optimized by RIC. RIC is a software-defined component that implements modular applications to facilitate multi-vendor operability required in O-RAN systems, as well as to automate and optimize RAN operations. RIC is divided into two types: non-real-time RIC (NRT RIC) and near real-time RIC (nRT RIC).

[0005] NRT RIC is the control point of non-real-time control loops, operating on a time scale greater than 1 second within the Service Management and Orchestration (SMO) framework. Its functionality is implemented through modular applications called rApps ( Figure 1 rApp 1, ..., rAppN), and includes: providing policy-based guidance and enriched functions through the A1 interface, which is an interface that enables communication between NRT RIC and nRTRIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and reasoning for RAN optimization; and / or recommending configuration management actions through the O1 interface, which is an interface that connects the SMO to the RAN management unit (e.g., nRTRIC, O-RA centralized unit (O-CU), O-RAN distributed unit (O-DU), etc.).

[0006] The nRT RIC operates on a time scale between 10 milliseconds and 1 second and is connected to the O-DU, O-CU (decomposed into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the open evolved NodeB (O-eNB) via the E2 interface. The nRT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) through a near real-time control loop. The nRT RIC monitors, pauses / stops, covers, and controls the E2 nodes (O-CU, O-DU, and O-eNB) via policies. For example, the nRT sets policy parameters for activation functions of the E2 nodes. In addition, the nRT RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc. The two types of RICs work together to optimize O-RAN. For example, NRT RIC provides policies, data, and AI / ML models enforced and used by nRT RIC for RAN optimization through the A1 interface, and nRT returns policy feedback (i.e., how the policies set by NRT RIC are working).

[0007] The NRT RIC is located within the SMO framework, which manages and orchestrates the RAN elements. Specifically, the SMO manages and orchestrates the so-called O-Ran cloud (O-cloud). The O-cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating system and runtime environment), and the SMO itself. In other words, the SMO manages the O-cloud from within. The O2 interface is the interface between the SMO and the O-cloud where it is located. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).

[0008] The O-cloud resource control mechanism in the prior art monitors the CU's business to determine whether to expand or shrink its instances. That is, the automatic scaling of the related art can expand or shrink the deployed O-CU applications (or instances) based on the business usage rate. However, this approach cannot provide sufficient O-cloud resource management in the event of a sudden business surge, because resource management is limited to automatic scaling within the same data center, without considering the resource status and load of the underlying hardware infrastructure. Therefore, a sudden business surge in a single data center may cause resource shortages because all O-CU applications are trying to expand. In other words, although there is unused server infrastructure (e.g., data centers) within the topology of the O-RAN network, O-CU automatic scaling is concentrated within its own data center. Summary of the invention

[0009] According to an embodiment, a system and method are provided for a centralized resource management control policy created by a modular application (rApp) hosted in a radio access network (RAN) intelligent controller (RIC), wherein the modular application collects at least one O-RAN resource metric across an entire O-RAN network topology, compares performance metrics of the O-RAN based on predetermined thresholds, and controls and implements allocation and reallocation of O-cloud resources by evaluating resource status of physical hosts within the O-RAN network topology, thereby achieving a more balanced utilization of O-cloud computing resources to allow energy-efficient network operation.

[0010] According to an embodiment, a device for implementing an application hosted in a radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework of a telecommunications network, the device comprising: a memory storing instructions; and at least one processor within the SMO framework for implementing the RIC, the at least one processor being configured to execute instructions to: receive data including at least one performance indicator from an open RAN (O-RAN) centralized unit (O-CU) in an O-cloud computing environment, wherein the at least one performance indicator includes a performance indicator of the O-CU; compare the at least one performance indicator with a first predetermined threshold; receive and evaluate a resource status of at least one physical host in the O-cloud computing environment; and create a resource management policy based on the comparison and evaluation, the resource management policy being used to allocate O-cloud computing resources of the at least one physical host to scale the O-CU in at least one physical location in the O-cloud computing environment.

[0011] At least one processor may be configured to execute instructions to: receive an additional performance indicator of the O-CU, compare the additional performance indicator of the O-CU to a second predetermined threshold, and determine to scale out by terminating the additional O-CU based on the comparison.

[0012] Based on at least one performance indicator being compared including a performance indicator of an O-CU control plane (CP), a resource management policy can be used to allocate O-cloud computing resources to scale the O-CU CP; and based on at least one performance indicator being compared including a performance indicator of an O-CU user plane (UP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU UP.

[0013] The performance indicators of the O-CU CP may include the number of connected devices, and the performance indicators of the O-CU UP may include the traffic volume or the number of active devices.

[0014] The at least one processor may also be configured to execute instructions to: create a resource management policy based on location information of the at least one physical host to move traffic considering a shortest path based on available resources.

[0015] The at least one processor may also be configured to execute instructions to: implement a fail-safe strategy based on the N number of instantiated O-CUs according to the resource management strategy, in which a single additional redundancy is instantiated as fail-safe for the N number of instantiated O-CUs.

[0016] Based on the assessed resource status of physical hosts in the O-CU's data center, resource management policies may be used to scale out the O-CU by instantiating additional O-CUs at physical hosts at data centers different from the O-CU's data center.

[0017] The resource status of the at least one physical host may include: processor load, memory usage, and hard drive usage of the at least one physical host.

[0018] According to another embodiment, a method for implementing a resource control mechanism, performed by an application hosted in a radio access network (RAN) intelligent controller (RIC) within a service management and orchestration (SMO) framework of a telecommunications network, may include: receiving data including at least one performance indicator from an open RAN (O-RAN) centralized unit (O-CU) in an O-cloud computing environment, wherein the at least one performance indicator includes a performance indicator of the O-CU; comparing the at least one performance indicator with a first predetermined threshold; receiving and evaluating a resource status of at least one physical host in the O-cloud computing environment; and creating a resource management policy based on the comparison and evaluation, the resource management policy being used to allocate O-cloud computing resources of the at least one physical host to scale the O-CU in at least one physical location in the O-cloud computing environment.

[0019] According to another embodiment, a non-transitory computer-readable recording medium within a service management and orchestration (SMO) framework of a telecommunications network has instructions recorded thereon, the instructions being executable by at least one processor to perform a method for implementing a resource control mechanism, the method may include: receiving data including at least one performance indicator from an open RAN (O-RAN) centralized unit (O-CU) in an O-cloud computing environment, wherein the at least one performance indicator includes a performance indicator of the O-CU; comparing the at least one performance indicator with a first predetermined threshold; receiving and evaluating a resource status of at least one physical host in the O-cloud computing environment; and creating a resource management policy based on the comparison and evaluation, the resource management policy being used to allocate O-cloud computing resources of the at least one physical host to scale the O-CU in at least one physical location in the O-cloud computing environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0021] Figure 1 The O-RAN architecture in the related art is shown;

[0022] Figure 2 is a diagram of an example environment in which the systems and / or methods described herein may be implemented;

[0023] Figure 3 is a diagram of example components of a device according to an embodiment;

[0024] Figure 4 is a diagram of a system architecture according to an embodiment;

[0025] Figure 5 is a diagram of an example environment of an O-RAN node in which the systems and / or methods described herein may be implemented;

[0026] Figure 6 is a diagram illustrating the flow of information according to an embodiment;

[0027] Figure 7 A flow chart showing a method of creating a resource management policy for allocating O-cloud computing resources to scale an O-CU according to an embodiment;

[0028] Figure 8 A flowchart of a method for creating a resource management policy for allocating O-cloud computing resources to expand an O-CU according to an embodiment is shown;

[0029] Fig. 9 A flowchart of a method for creating a resource management policy for allocating O-cloud computing resources to reduce O-CU according to an embodiment is shown;

[0030] Fig.10 is a diagram of an example environment for scaling up an O-CU;

[0031] Fig.11 is a diagram of an example environment for scaling down an O-CU; and

[0032] Fig.12 A table showing the resource status of vCU servers in an O-cloud computing environment is shown. DETAILED DESCRIPTION

[0033] The following detailed description of example embodiments refers to the accompanying drawings.The same reference numbers in different drawings may identify the same or similar elements.

[0034] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the disclosed precise form. In view of the above disclosure, modifications and variations are possible, or can be obtained from the practice of implementation. In addition, one or more features or components of an embodiment can be incorporated into another embodiment or combined with another embodiment (or one or more features of another embodiment). In addition, in the flow charts and operational descriptions provided below, it should be understood that one or more operations can be omitted, one or more operations can be added, one or more operations can be performed simultaneously (at least in part), and the order of one or more operations can be switched.

[0035] It will be apparent that the systems and / or methods described herein can be implemented using various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not a limitation of the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software codes. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0036] Although particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not explicitly recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.

[0037] Unless explicitly described, any element, action, or instruction used in this document should not be considered critical or essential. In addition, as used herein, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more". Figure 1 When referring to an item, the term "a" or similar language is used. In addition, as used herein, the terms "having," "having," "containing," "including," "comprising," and the like are intended to be open-ended terms. Furthermore, unless otherwise expressly stated, the phrase "based on" is intended to mean "based at least in part on." Furthermore, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0038] Example embodiments of the present disclosure provide a modular application (rApp) hosted in a radio access network (RAN) intelligent controller (RIC), and provide automatic scaling of an O-CU that considers business usage metrics and the underlying hardware resources of the O-cloud infrastructure on which the O-CU is deployed to determine where to scale the O-CU in the entire network topology. Therefore, a sudden surge in business does not cause a shortage of resources at a single data center, because the rApp-based O-CU automatic scaling according to the example embodiment is based on the resource status of the data center and can determine to scale the O-CU at different data centers.

[0039] The rApp according to an example embodiment considers O-CU performance indicators and cloud resources to calculate or determine how many new application instances or resources are needed, and selects a cloud cluster to deploy new application (e.g., O-CU control plane and / or user plane) instances.

[0040] Methods and apparatus according to example embodiments enable a more balanced usage of O-cloud computing resources of an O-cloud environment so as to allow for energy efficient networks.

[0041] Figure 2 2 is a diagram of an example environment 200 in which systems and / or methods described herein may be implemented. Figure 3 As shown, environment 200 may include user device 210, platform 220, and network 220. The devices of environment 200 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. Figures 4 to 12 Any functions and operations described can be performed by Figure 3 Any combination of the elements shown in .

[0042] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 220. For example, user device 210 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or the like. In some implementations, user device 210 may receive information from platform 220 and / or send information to platform 220.

[0043] The platform 220 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, the platform 220 may include a cloud server or a group of cloud servers. In some implementations, the platform 220 may be designed to be modular so that certain software components may be swapped in or out depending on specific needs. Therefore, the platform 220 may be easily and / or quickly reconfigured for different purposes.

[0044] In some implementations, as shown, the platform 220 can be hosted in a cloud computing environment 222. It is worth noting that while the implementations described herein describe the platform 220 as being hosted in a cloud computing environment 222, in some implementations, the platform 220 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0045] Cloud computing environment 222 includes an environment hosting platform 220. Cloud computing environment 222 can provide computing, software, data access, storage, and other services that do not require end users (e.g., user devices 210) to be aware of the physical location and configuration of the (multiple) systems and / or (multiple) devices hosting platform 220. As shown, cloud computing environment 222 can include a set of computing resources 224 (collectively, "computing resources 224" and individually, "computing resources 224").

[0046] The computing resources 224 include one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resources 224 can host the platform 220. Cloud resources can include computing instances executed in the computing resources 224, storage devices provided in the computing resources 224, data transmission devices provided by the computing resources 224, etc. In some implementations, the computing resources 224 can communicate with other computing resources 224 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0047] like Figure 2As further shown in FIG. 1 , the computing resources 224 include a set of cloud resources, such as one or more applications (“APP”) 224 - 1 , one or more virtual machines (“VM”) 224 - 2 , virtualized storage (“VS”) 224 - 3 , one or more hypervisors (“HYP”) 224 - 4 , and the like.

[0048] The applications 224-1 include one or more software applications that can be provided to or accessed by the user device 210. The applications 224-1 can eliminate the need to install and execute software applications on the user device 210. For example, the applications 224-1 can include software associated with the platform 220 and / or any other software that can be provided via the cloud computing environment 222. In some implementations, one application 224-1 can send information to / receive information from one or more other applications 224-1 via the virtual machine 224-2.

[0049] Virtual machine 224-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 224-2 can be a system virtual machine or a process virtual machine, depending on the use of virtual machine 224-2 and the degree of correspondence with any real machine. System virtual machines can provide a complete system platform that supports the execution of a complete operating system ("OS"). Process virtual machines can execute a single program and can support a single process. In some implementations, virtual machine 224-2 can execute on behalf of a user (e.g., user device 210) and can manage the infrastructure of cloud computing environment 222, such as data management, synchronization, or long-duration data transfer.

[0050] Virtualized storage 224-3 includes one or more storage systems and / or one or more devices using virtualization technology in the storage system or device of computing resource 224. In some implementations, in the context of storage systems, virtualization types may include block virtualization and file virtualization. Block virtualization may refer to abstracting (or separating) logical storage from physical storage so that the storage system can be accessed without considering physical storage or heterogeneous structures. Separation may allow administrators of storage systems to flexibly manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the location of the file's physical storage. This may achieve optimization of storage usage, server consolidation, and / or performance of non-disruptive file migration.

[0051] Hypervisor 224-4 can provide hardware virtualization technology, allowing multiple operating systems (e.g., "guest operating systems") to execute concurrently on a host computer (such as computing resource 224). Hypervisor 224-4 can present a virtual operating platform to the guest operating systems and can manage the execution of the guest operating systems. Multiple instances of multiple operating systems can share virtualized hardware resources.

[0052] The network 220 includes one or more wired and / or wireless networks. For example, the network 220 may include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, etc., and / or a combination of these or other types of networks.

[0053] Figure 2 The number and arrangement of devices and networks shown in the figure are provided as examples. In practice, there may be Figure 2 Additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in . In addition, Figure 3 Two or more of the devices shown in may be implemented in a single device, or Figure 3 The single device shown in can be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) of environment 300 can perform one or more functions described as being performed by another set of devices of environment 300.

[0054] Figure 4 300 is a diagram of example components of device 300. Device 300 may correspond to user device 210 and / or platform 220. Figure 4 As shown, device 300 may include a bus 310 , a processor 320 , a memory 320 , a storage component 330 , an input component 350 , an output component 360 , and a communication interface 370 .

[0055] The bus 310 includes components that allow communication between components of the device 300. The processor 320 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 320 can be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other types of processing components. In some implementations, the processor 320 includes one or more processors that can be programmed to perform functions. The memory 320 includes a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 320.

[0056] The storage component 330 stores information and / or software related to the operation and use of the device 300. For example, the storage component 330 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette tape, and / or another type of non-transitory computer-readable medium, and a corresponding drive. The input component 350 includes components that allow the device 300 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). In addition, or alternatively, the input component 350 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 360 includes components that provide output information from the device 300 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).

[0057] The communication interface 370 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 370 can allow the device 300 to receive information from another device and / or provide information to another device. For example, the communication interface 370 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0058] Device 300 may perform one or more processes described herein. Device 300 may perform these processes in response to processor 320 executing software instructions stored by non-transitory computer-readable media (such as memory 320 and / or storage component 330). Computer-readable media is defined herein as non-transitory memory devices. Memory devices include memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0059] The software instructions may be read into memory 320 and / or storage component 330 from another computer-readable medium or from another device via communication interface 370. When executed, the software instructions stored in memory 320 and / or storage component 330 may cause processor 320 to perform one or more processes described herein.

[0060] Additionally, or alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to perform one or more of the processes described herein.Thus, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0061] Figure 4 The number and arrangement of components shown in FIG. 3 are provided as examples. In practice, device 300 may include more Figure 4 The components shown in the figure may include additional components, fewer components, different components, or components arranged differently. In addition, or alternatively, a component set (e.g., one or more components) of the device 300 can perform one or more functions described as being performed by another component set of the device 300.

[0062] In an embodiment, Figures 5 to 12 Any operation or process in Figure 3 and 4 Any of the elements shown in the Figure 3 and 4 It can be implemented by any of the elements shown in .

[0063] Figure 4 is a diagram of a system architecture according to an example embodiment. Figure 4 The system architecture includes an open radio access network (O-RAN) radio unit (O-RU), an O-RAN distributed unit (O-DU), an O-RAN centralized unit (O-CU), and an application (rApp) hosted in an O-RAN intelligent controller (RIC) for managing O-CU resource utilization based on cloud resource availability. As described above, the O-CU is an application deployed in a cloud platform (O-cloud) and instantiated on a physical host (i.e., server) in a data center.

[0064] That is, the O-CU is assigned to a specific topology in the O-RAN network. This topological location is, for example, a data center. Such a data center houses the physical hardware server infrastructure that hosts the O-cloud environment, and more specifically, the data center houses at least one virtualized CU (vCU) server that hosts a virtual machine running an O-CU application of a vCU cluster. The vCU cluster can be hosted on at least one vCU server in at least one data center.

[0065] like Figure 6 As shown, at least one vCU server is, for example, a physical host that includes computing resources 224 of an O-cloud computing environment. A data center is, for example, at least one physical host location (such as Figure 6 ).

[0066] A physical host, for example, hosts at least one O-CU node and / or O-CU node cluster of O-RAN. An O-CU node is based on Figures 1 to 5 The O-CU of the O-RAN network runs the O-CU application in the O-cloud computing environment.

[0067] like Figure 1 As shown in , various network elements and RIC of the O-RAN architecture are connected via interfaces including A1, O1, O2, CU-plane, M-plane, F1, E1, E2, X2 and Xn.

[0068] The near-RT RIC can obtain performance indicators (or key performance indicators (KPIs)) via the E2 interface. The set of performance indicators can be about one or more cells, slices, QoS classes, or specific UEs. To this end, the near-RT RIC can be directly connected to the O-eNB, the control plane (C-plane) of the O-CU, the user plane (U-plane) of the O-CU, and the O-DU. In the O-CU, the C-plane and the U-plane run control and user functions accordingly. The C-plane and the U-plane are connected via the E1 interface. In addition, the C-plane and the U-plane are connected to the O-DU via the F1 interface, and have dedicated sub-interfaces F1-u and F2-c respectively. The O-CU communicates with other O-CUs via the Xn (X2) interface connecting different gNBs and / or eNBs. In addition, the NG interface connects the gNB to the 5G core. Both the Xn (X2) and NG interfaces have dedicated sub-interfaces connected to the C-plane and U-plane of the O-CU, respectively.

[0069] Figure 6is a diagram of an example environment of a data center housing a vCU server hosting an O-CU cluster. At least one O-DU is connected to the O-CU. The O-DU includes baseband processing and is capable of supporting one or more cells. This means that, based on the topological hierarchy of the radio network generated by the positions of the radio antennas forming the cells, the locations of the O-DUs hosted on at least one vDU server, and the locations of the vCU clusters hosted by at least one vCU server are predetermined according to the overall network topology of cells and beams. For example, a cell in Yokohama is controlled by a vCU cluster radio hosted by at least one vCU server in a data center located in Yokohama. Therefore, although the O-Cloud environment does not rely on network topology, the data center housing the vCU cluster has a predetermined geographical location based on the network topology in the real world.

[0070] The modular application (rApp) monitors the performance of each O-CU in the vCU cluster, and controls and implements resource management policies based on the performance indicators of the C-plane of the O-CU and the U-plane applications in each vCU cluster. For example, the performance indicators of the O-CU UP may include at least one of the traffic volume through the O-CU UP or the number of active devices connected to the O-CU. The performance indicators of the O-CU CP may include the number of devices connected to the O-CU. In addition, the rApp implements resource management policies based on C / U-plane statistics, including cloud resource information or status. Cloud resource information is information about the resource utilization of the underlying cloud infrastructure (i.e., physical nodes) of the cluster in which the O-CU C / U-plane is instantiated. This information may include, by example, the amount of memory being used, the processor load, the amount of hard drive space being used, etc. The rApp can receive performance indicators and resource information from at least one of the E2, A1, and O2 interfaces.

[0071] Figure 6 Schematic diagram showing the information flow according to an embodiment. Figure 6 According to an embodiment, performance indicators of the O-CU C-Plane (CP) and O-CU U-Plane (UP), and cloud resource information (or status) are provided to the rApp via at least one of the E2, A1, and O2 interfaces. In one or more embodiments, the O-CU CP will request the O-CU UP performance indicators from the O-CU UP and send them to the rApp.

[0072] Figure 7 FIG. 7 is a flowchart of a method 700 for creating a resource management policy according to an embodiment. Figure 7In step 701, the modular application (rApp) receives a performance indicator of an O-RAN function. The performance indicator of the O-RAN function is, for example, a performance indicator of an O-CU U-plane, which may include traffic volume or the number of active devices and / or a performance indicator of an O-CU C-plane, which may include, for example, relevant parameters (e.g., the number of connected devices) to trigger whether the O-CU should be scaled up or down.

[0073] In step 702, the performance indicator is compared with a threshold value to determine whether the modular application (rApp) should request or control the execution of scaling of the O-CU. Here, for the comparison in step 702, the threshold value may be a first threshold value that triggers a scale-down request from the modular application (rApp) or a second threshold value that triggers a scale-up request from the modular application (rApp). The first threshold value and the second threshold value may be the same threshold value or different threshold values.

[0074] In step 703, the modular application (rApp) receives and evaluates the resource state of at least one physical host (e.g., a physical host that houses the O-CU to be scaled). The modular application (rApp) receives the resource state from at least one physical host for housing the O-cloud computing resources that are ready to be allocated to or have been allocated to the O-CU. In some embodiments, step 703 may be performed based on or in response to the comparison in step 702, although it should be understood that one or more other embodiments are not limited thereto. For example, in another embodiment, the resource state may be received independently or without regard to the result of the comparison in step 702.

[0075] The resource status may include, for example, at least one of a processor load, memory usage, hard drive usage, etc., of at least one physical host within the topology of the O-RAN network. In addition, the resource status may be pushed to the rApp (e.g., periodically or continuously) or may be pulled by the rApp (e.g., by a periodic request, by an event-triggered request (e.g., based on the threshold determination of step 702), etc.). By way of example, the resource status may be obtained from a "Resource Status Request / Response" information element (IE) compliant with the 3GPP standard.

[0076] In step 704, the modular application (rApp) creates a resource management policy based on the comparison (e.g., in step 702) and the evaluation (e.g., in step 703), the resource management policy for allocating O-cloud computing resources of at least one physical host to one or more O-CU nodes to scale the resource management policy of the O-CU at at least one physical location in the O-cloud computing environment. By way of example, the determination of scaling can be based on the comparison of step 702, and the determination of the server or data center location of the instantiated O-CU in the O-cloud platform according to the scaling can be based on the evaluation of step 703.

[0077] By way of example, the data center in Yokohama houses at least one vCU server hosting vCU cluster 01, such as Figure 5 As shown. If there is a sudden surge in connected / active user equipment (UE) or services, the modular application (rApp) compares the performance indicator(s) to one or more thresholds and evaluates the topological limits of the peak by using a metric of resource status based on the O-RAN network topology (i.e., "Resource Status Request / Response" IE). In this case, if the performance indicator exceeds the threshold as compared, but the resource status evaluation (e.g., comparison with one or more resource thresholds, based on which a determination of the availability of hardware / cloud resources for O-CU instantiation is made) indicates that the Yokohama data center does not have sufficient resources for the newly instantiated O-CU, the rApp may evaluate the resource status of other data centers to determine another data center with sufficient resource availability to expand the O-CU. Here, the rApp may also consider other factors (such as location information) to determine a location for O-CU instantiation that provides the shortest path for mobile services.

[0078] According to an example embodiment, the rApp may provide policies to an operations support system (OSS) to generate scaling configurations and controls to perform scaling.

[0079] Figure 8 FIG. 8 is a flowchart of a method 800 for creating a resource management policy for allocating O-cloud computing resources to expand an O-CU according to an embodiment. Figure 8 , similar to step 701, the modular application (rApp) obtains the performance indicator of the O-RAN function in step 801. In step 802, similar to step 702, the modular application (rApp) compares the performance indicator with a second threshold for scaling up. The second threshold for scaling up may be the same as the first threshold for scaling down. However, the two thresholds may be different from each other to provide a more flexible scaling up or scaling down process.

[0080] In step 803 , the modular application (rApp) obtains and evaluates the resource status of at least one physical host accommodating O-cloud computing resources that are ready to be allocated to or have been allocated to the O-CU.

[0081] In step 804, the modular application (rApp) creates a resource management policy based on the comparison (e.g., in step 802) and the evaluation (e.g., in step 803), the resource management policy being used to allocate O-cloud computing resources of at least one physical host to scale out the O-CU in at least one physical location in the O-cloud computing environment.

[0082] By example, according to Figure 8 In the expansion process, in the event that there is an unforeseen event causing a sudden surge in UE traffic or any other factor that makes it necessary to expand the O-CU in the Yokohama area, the modular application (rApp) obtains a "resource status response" IE or other resource status. Based on the evaluation of the resource status, the modular application (rApp) creates a resource management policy. The resource management policy can be a set of commands to allocate O-cloud resources of other vCU clusters in the network topology to the vCU cluster 01 in the Yokohama area. In other words, the resource management policy is a set of commands to instantiate a new O-CU application on at least one vCU server. The (multiple) vCU servers that instantiate the new O-CU application can be located at a location different from the location of the original O-CU.

[0083] In the event that the vCU server hardware infrastructure resources at the data center in Yokohama reach the maximum level, the modular application (rApp) obtains and evaluates the resource status of the vCU server hosting the vCU cluster 02 at any other location beside the vCU cluster 01 in, for example, Kawasaki or Yokohama area.

[0084] For example, the modular application (rApp) uses the "Resource Status Request / Response" IE to evaluate and determine the status of the vCU servers based on a predetermined perimeter around the location of the data center 01 in the Yokohama area.

[0085] To this end, unused resources of the data center, especially vCU servers of data centers located near the data center 01, can be used to allocate their hardware infrastructure resources to the data center 01 in the Yokohama area. For example, a modular application (rApp) creates a resource management policy to instantiate a new O-CU application for an O-CU running on the vCU cluster 01 in the Yokohama area on a vCU server of the vCU cluster 02 in Kawasaki.

[0086] The benefit of this is that if the data center in Yokohama reaches its maximum hardware resource limit, other data centers close to Yokohama can use their unused hardware resources to instantiate new O-CU applications for the O-CUs that are normally hosted in the data center in Yokohama.

[0087] Fig. 9 FIG. 9 is a flowchart of a method 900 for creating a resource management policy for allocating O-cloud computing resources to reduce the size of an O-CU according to an embodiment. Fig. 9 , similar to step 701, the modular application (rApp) obtains the performance indicator of the O-RAN function in step 901. In step 902, similar to step 702, the modular application (rApp) compares the performance indicator with a first threshold for reduction. Here, the first threshold may be a threshold that triggers a reduction request from the modular application (rApp).

[0088] In step 903 , the modular application (rApp) receives and evaluates the resource status of at least one physical host housing O-cloud computing resources that are ready to be allocated or have been allocated to the O-CU.

[0089] and Figure 7 and Figure 8 Similarly, resource status may be obtained, for example, via a "resource status response" IE or other resource status, which may include one of processor load, memory usage, and hard drive usage of at least one physical node.

[0090] In step 904, the modular application (rApp) creates a resource management policy based on the comparison (e.g., in step 902) and the evaluation (e.g., in step 903), the resource management policy being used to allocate O-cloud computing resources of at least one physical host to one or more O-CU nodes to scale down the O-CUs in at least one physical location in the O-cloud computing environment.

[0091] By way of example, the O-CU may be connected to a maximum of 18,000 UEs. The UEs are hosted in three separate container groups, each configured to host 6,000 UEs. If the load of the O-CU (e.g., based on the comparison in step 902) is only 200 UEs, two of the three container groups are terminated by the resource management policy.

[0092] In addition, in the resource control mechanism in the prior art, the O-CU always maintains three container groups in its basic configuration. Therefore, the minimum resource management strategy of shutting down two container groups saves energy in the operation of the O-RAN network.

[0093] In further embodiments, the resource management strategy may include fail-safe scaling down by applying "N+1" redundancy. This means, for example, that although the load is only 200 UEs, two container groups are still used, where the N+1 container group can be a hot standby that is linked to the O-CU in a standby state. Furthermore, in the case of 12,000 UEs hosted on two O-CU container groups or instances, the resource management fail-safe strategy according to the example embodiments may apply "N+1" redundancy (i.e., three container groups) instead of N+N redundancy, thereby achieving the smallest possible configuration and optimal / reduced energy requirements.

[0094] In another embodiment, the resource management policy may include a policy for allocating pre-instantiated O-cloud computing resources. These resources are, for example, pre-instantiated container groups hosted on vCU servers. These pre-instantiated container groups can be linked to the O-CU without executing resource management policies to instantiate new container groups for additional O-CU applications. The linking of pre-instantiated O-cloud computing resources saves instantiation time lag (e.g., approximately 20 seconds) because linking pre-instantiated container groups is completed in a fraction of a second.

[0095] In another embodiment, the resource management strategy may include deploying "N+1" redundancy and linking pre-instantiated container groups to the O-CU. This resource management strategy is energy-efficient and allows for flexible and fast allocation of O-cloud computing resources for fail-safe operation of the O-RAN network.

[0096] According to one or more embodiments, a modular application (rApp) obtains and evaluates resource status to create a resource management policy to terminate the rich O-CU application of the O-CU, regardless of the location of the physical host running the rich O-CU. This means that, for example, the O-CU application of the O-CU in the Yokohama data center running on the vCU server in the Kawasaki data center is terminated by the resource management policy in the same manner as the rich O-CU application in the O-CU in the Yokohama data center.

[0097] This resource management strategy of reducing hardware resources based on the resource status of hardware resources in the O-RAN network topology is more energy-efficient and provides resource management within the entire O-RAN network topology.

[0098] Fig.10 and 11 is a diagram of example embodiments of a "scale-in operation" and a "scale-down operation" respectively controlled and implemented by a modular application (rApp) in accordance with one or more embodiments.

[0099] refer to Fig.10, the modular application (rApp) obtains performance indicators of O-RAN functions. The performance indicators can be pushed to the rApp (e.g., periodically or continuously), or can be pulled by the rApp (e.g., through periodic requests, through event-triggered requests (e.g., threshold determination), etc.). Based on the obtained performance indicators, the modular application (rApp) compares the performance indicators to a threshold in order to trigger a scaling request or command. Fig.10 The request or command in this case is an expansion request. In addition, the modular application (rApp) obtains resource status from physical hosts within the O-RAN network topology. This may include (multiple) physical hosts running the O-CU to be scaled and (multiple) other physical hosts that may be able to accommodate additional O-CU applications of the O-CU. In addition, the modular application (rApp) obtains transmission details in order to select a physical host with, for example, the lowest latency (e.g., the shortest path to the physical host of the O-CU to be scaled). The modular application may obtain and / or evaluate the transmission details based on a comparison of a performance metric with a threshold.

[0100] Still reference Fig.10 For example, the modular rAPP can communicate with the O-CU CP via the E2 and E1 interfaces to obtain O-CU UP performance indicators, and obtain performance indicators from the O-DU via the F1 interface, such as active UEs, UE traffic, data throughput, etc. Similarly, the resource status can be obtained through the "Resource Status Request / Response" IE.

[0101] In another example, the modular rAPP may communicate with the O-CU CP via the E2 and E1 interfaces to obtain the information element "Gnb-Cu-Up status indication". When the O-CU U-plane reaches 75% of its capacity, the threshold for scale-out request is reached, and the resource status of at least one physical host is evaluated. Based on the evaluation, a new container group is instantiated or a pre-instantiated container group is linked to the O-CU that has reached 75% of its capacity.

[0102] The performance indicators are varied and the list is not exhaustive. For example, at least one performance indicator may include, among others, a key performance indicator (KPI) of the radio network layer, a transport network layer interface connecting the U-plane or C-plane of the O-CU, a service for each user function executed on the U-plane of the O-CU, at least one O-RAN system operation KPI of the O-CU, etc.

[0103] For example, the KPI may be the service status of the U-plane application usage of the O-CU, for example, if the U-plane application of the O-CU is designed to carry ≤6Gbps of service for each microservice container group. In this case, the threshold may be set for the service of at least one user application executed on the user plane (U-plane) of at least one O-Cu node.

[0104] Furthermore, the performance indicator may include at least one system operation KPI, such as the number of UEs connected to the O-CU U-plane container group and / or an O-CU internal system trigger overload threshold.

[0105] The resource state may be a computing performance indicator, in particular a computing performance indicator related to an O-cloud environment. The resource state (or state) of at least one physical host may include at least one of a processor load, a memory usage, and a hard drive usage of at least one physical host.

[0106] The resource status may include the most suitable location according to the O-RAN network topology, which may include a preferred location based on, for example, at least one of the hardware infrastructure capacity of at least one vCU server, transmission speed, and service routing. The events used to select the predetermined location of the data center are diverse and are not limited to the above examples. Selecting a preferred physical location in the O-RAN network may include at least one of the above-mentioned most suitable locations and / or predetermined physical locations of the mobile operator, for example, a specific location in the event of a major disruption of O-cloud computing (e.g., a natural disaster, etc.).

[0107] For example, a modular application (rApp) can create a resource management policy that can include: determining where, how many, and / or which new O-CU applications (e.g., container groups or microservice instances) should be instantiated. Comparing and selecting at least one vCU server or at least one vCU cluster in at least one data center to deploy new application instances or resources based on performance indicators (e.g., evaluating resource states that allow determining the most appropriate location, the most appropriate server, and the most appropriate number of container groups to be instantiated).

[0108] Still reference Fig.10, the modular application (rApp) may include: comparing a key performance indicator (KPI) of each of the C-plane and the U-plane of the O-CU with a corresponding threshold; obtaining and evaluating a resource status, and instantiating only the O-CU application that needs to be expanded based on the comparison and evaluation. This means that based on the compared performance indicators including the performance indicators of the O-CU control plane (CP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU CP, and based on at least one of the compared performance indicators including the performance indicators of the O-CU user plane (UP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU UP.

[0109] Fig.11 A diagram showing an example embodiment of a "zoom out operation" controlled and implemented by a modular application (rApp) according to an example embodiment. Fig.10 Similarly, the modular application (rApp) obtains a performance indicator of the O-RAN network function. Therefore, the modular application (rApp) compares the performance indicator with a first threshold to trigger a termination request for the rich O-CU. In addition, the modular application (rApp) obtains a resource status of the rich O-CU and / or a resource status of a physical host housing the rich O-CU or a portion thereof. Based on the resource status and the transfer details of the possibly differently located (multiple) physical hosts, the modular application (rApp) creates a resource management policy to terminate the rich O-CU.

[0110] Still reference Fig.11 , modular applications (rApps) can create resource management policies including fail-safe configurations. For example, due to the flexibility provided by the control mechanism of resources according to example embodiments, N+1 redundancy can be configured for fail-safe, rather than N+N redundancy. Therefore, robust and energy-efficient operation of the RAN in an O-cloud environment can be achieved. The reduction of O-cloud resources allows the O-RAN to operate more energy-efficiently.

[0111] Still reference Fig.11 , the modular application (rApp) may include: selecting at least one of the C-plane application of the O-CU or the U-plane application of the O-CU; comparing the key performance indicator (KPI) of the application with a threshold; obtaining and evaluating the resource status, and terminating only the O-CU application that needs to be scaled down based on the comparison and evaluation. This means that based on the compared performance indicators including the performance indicators of the O-CU control plane (CP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU CP, and based on the compared performance indicators including the performance indicators of the O-CU user plane (UP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU UP.

[0112] Fig.12A table showing the resource status of vCU servers in an O-cloud computing environment is shown. The resource status of each vCU server may include the percentage of cores being used out of the total number of available cores for each vCU server, the percentage of cores being used out of the number of isolated cores for each vCU server, the percentage of cores being used out of the number of dedicated cores for each vCU server, the CPU status of each vCU server, the hard disk allocation for each vCU server, the system usage of each vCU server, the role of the vCU server within the vCU cluster, and the operational status of the vCU server.

[0113] According to an embodiment, an apparatus and method for evaluating, controlling and executing resource management control policies created by a modular application rApp hosted in a radio access network (RAN) intelligent controller (RIC) is provided, wherein these policies implement scaling of O-CU based on consideration of the resource status of the underlying cloud hardware resources. Therefore, efficient scaling and operation of O-CU instances can be achieved, and hardware resource shortages (e.g., due to a surge in business) of a particular cluster or data center can be prevented.

[0114] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations.

[0115] Some embodiments may involve systems, methods, and / or computer-readable media at any possible level of technical detail integration. In addition, one or more of the above components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium) having computer-readable program instructions thereon for causing a processor to perform operations.

[0116] Computer readable storage medium can be a tangible device that can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer readable storage medium includes the following items: portable computer floppy disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device (e.g., a punch card or a raised structure in a groove on which instructions are recorded), and any suitable combination of the foregoing. The computer readable storage medium used in this article should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by a fiber optic cable), or an electrical signal sent by a wire.

[0117] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network, and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0118] The computer readable program code / instruction for performing the operation can be an assembly instruction, an instruction set architecture (ISA) instruction, a machine instruction, a machine-related instruction, a microcode, a firmware instruction, a state setting data, a configuration data for an integrated circuit system, or a source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and a process programming language (such as "C" programming language or similar programming language). The computer readable program instruction can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, by using the Internet of an Internet service provider). In some embodiments, an electronic circuit system (including, for example, a programmable logic circuit system, a field programmable gate array (FPGA), or a programmable logic array (PLA)) can be personalized by using the state information of the computer readable program instruction to execute the computer readable program instruction so as to perform aspects or operations.

[0119] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a component for implementing the function / action specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct a computer, a programmable data processing device, and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having instructions stored therein includes a manufactured product, which includes instructions, and the instructions implement aspects of the function / action specified in one or more boxes of the flowchart and / or block diagram.

[0120] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0121] Flowchart and block diagram in the figure show the possible implementation architecture, function and operation of the system, method and computer-readable medium according to various embodiments.In this regard, each frame in the flow chart or block diagram can represent a part of a module, segment or instruction, which includes one or more executable instructions for realizing (multiple) specified logical functions.The method, computer system and computer-readable medium may include additional frames, fewer frames, different frames or frames of different arrangements than the frames shown in the figure.In some alternative implementations, the function pointed out in the frame may not occur in the order pointed out in the figure.For example, two frames shown continuously can actually be performed concurrently or substantially concurrently, or these frames can sometimes be performed in reverse order, depending on the function involved.It should also be noted that each frame in the block diagram and / or flow chart and the combination of frames in the block diagram and / or flow chart can be realized by a dedicated hardware system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0122] It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code - it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. An apparatus for implementing an application hosted in a Radio Access Network (RAN) Intelligent Controller (RIC) within a Service Management and Orchestration (SMO) framework of a telecommunications network, the apparatus comprising: a memory for storing instructions; as well as at least one processor within the SMO framework for implementing the RIC, the at least one processor being configured to execute the instructions to: receiving data including at least one performance indicator from an open RAN (O-RAN) centralized unit (O-CU) in an O-cloud computing environment, wherein the at least one performance indicator includes a performance indicator of the O-CU; comparing the at least one performance indicator to a first predetermined threshold; Receiving and evaluating a resource status of at least one physical host in the O-cloud computing environment; as well as A resource management policy is created based on the comparison and the evaluation, the resource management policy being used to allocate O-cloud computing resources of the at least one physical host to scale the O-CU at at least one physical location in the O-cloud computing environment.

2. The device according to claim 1, wherein: The resource management policy is used to allocate O-cloud computing resources to expand the O-CU by instantiating additional O-CUs; and The at least one processor is further configured to execute the instructions to: receiving additional performance indicators of the O-CU, comparing the additional performance indicator of the O-CU with a second predetermined threshold, and A determination is made based on the comparison to scale down by terminating the additional O-CU.

3. The device according to claim 1, wherein: Based on the at least one performance indicator being compared including a performance indicator of an O-CU control plane (CP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU CP; and Based on the at least one performance indicator being compared comprising a performance indicator of an O-CU user plane (UP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU UP. 4 . The apparatus according to claim 3 , wherein the performance indicator of the O-CUP CP comprises the number of connected devices, and the performance indicator of the O-CU UP comprises the traffic volume or the number of active devices.

5. The apparatus of claim 1 , wherein the at least one processor is further configured to execute the instructions to: The resource management policy is created based on the location information of the at least one physical host to move traffic considering the shortest path based on available resources.

6. The apparatus of claim 1 , wherein the at least one processor is further configured to execute the instructions to: Based on the N number of instantiated O-CUs according to the resource management policy, a fail-safe strategy is implemented in which a single additional redundancy is instantiated as fail-safe for the N number of instantiated O-CUs.

7. The apparatus of claim 1 , wherein based on the evaluated resource states of physical hosts in a data center of the O-CU, the resource management policy is used to scale out the O-CU by instantiating additional O-CUs at physical hosts at a data center different from the data center of the O-CU.

8. The apparatus according to claim 1, wherein the resource status of the at least one physical host comprises: Processor load, memory usage, and hard drive usage of the at least one physical host.

9. A method of implementing a resource control mechanism performed by an application hosted in a Radio Access Network (RAN) Intelligent Controller (RIC) within a Service Management and Orchestration (SMO) framework of a telecommunications network, the method comprising: receiving data including at least one performance indicator from an open RAN (O-RAN) centralized unit (O-CU) in an O-cloud computing environment, wherein the at least one performance indicator includes a performance indicator of the O-CU; comparing the at least one performance indicator to a first predetermined threshold; Receiving and evaluating a resource status of at least one physical host in the O-cloud computing environment; as well as A resource management policy is created based on the comparison and the evaluation, the resource management policy being used to allocate O-cloud computing resources of the at least one physical host to scale the O-CU at at least one physical location in the O-cloud computing environment.

10. The method according to claim 9, wherein: The resource management policy is used to allocate O-cloud computing resources to expand the O-CU by instantiating additional O-CUs; and The method further comprises: receiving additional performance indicators of the O-CU, comparing the additional performance indicator of the O-CU with a second predetermined threshold, and A determination is made based on the comparison to scale down by terminating the additional O-CU.

11. The method according to claim 9, wherein: Based on the at least one performance indicator being compared including a performance indicator of an O-CU control plane (CP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU CP; and Based on the at least one performance indicator being compared comprising a performance indicator of an O-CU user plane (UP), the resource management policy is used to allocate O-cloud computing resources to scale the O-CU UP. 12 . The method according to claim 9 , wherein the performance indicator of the O-CUP CP comprises the number of connected devices, and the performance indicator of the O-CUP UP comprises the traffic volume or the number of active devices.

13. The method of claim 9, wherein creating the resource management policy comprises: The resource management policy is created based on the location information of the at least one physical host to move traffic considering the shortest path based on available resources.

14. The method according to claim 9, further comprising: Based on the N number of instantiated O-CUs according to the resource management policy, a fail-safe strategy is implemented in which a single additional redundancy is instantiated as fail-safe for the N number of instantiated O-CUs.

15. The method of claim 9, wherein based on the evaluated resource status of physical hosts in a data center of the O-CU, the resource management policy is used to scale out the O-CU by instantiating additional O-CUs at physical hosts at a data center different from the data center of the O-CU.

16. The method according to claim 9, wherein the resource status of the at least one physical host comprises: Processor load, memory usage, and hard drive usage of the at least one physical host.

17. A non-transitory computer-readable recording medium within a service management and orchestration (SMO) framework of a telecommunications network, having instructions recorded thereon, the instructions being executable by at least one processor to perform a method for implementing a resource control mechanism, the method comprising: receiving data including at least one performance indicator from an open RAN (O-RAN) centralized unit (O-CU) in an O-cloud computing environment, wherein the at least one performance indicator includes a performance indicator of the O-CU; comparing the at least one performance indicator to a first predetermined threshold; Receiving and evaluating a resource status of at least one physical host in the O-cloud computing environment; as well as A resource management policy is created based on the comparison and the evaluation, the resource management policy being used to allocate O-cloud computing resources of the at least one physical host to scale the O-CU at at least one physical location in the O-cloud computing environment.

18. The non-transitory computer readable recording medium of claim 17, wherein the method further comprises: receiving additional performance indicators of the O-CU, comparing the additional performance indicator of the O-CU with a second predetermined threshold, and A determination is made based on the comparison to scale down by terminating the additional O-CU.

19. The non-transitory computer-readable recording medium of claim 17, wherein creating the resource management policy comprises: The resource management policy is created based on the location information of the at least one physical host to move traffic considering the shortest path based on available resources.

20. The non-transitory computer-readable recording medium of claim 17, wherein based on the evaluated resource status of physical hosts in a data center of the O-CU, the resource management policy is used to expand the O-CU by instantiating additional O-CUs at physical hosts at a data center different from the data center of the O-CU.

Images