Apparatus and method for providing resource management policies in telecommunication systems

Abstract

An apparatus and method for implementing an rApp-based resource control mechanism for scaling network functions is provided. The apparatus includes a memory that stores instructions and at least one processor, the at least one processor being configured to execute the instructions to: receive data from an O-CU in an O-Cloud computing environment, the data including at least one performance indicator including a performance indicator of the O-CU; compare the at least one performance indicator to a first predetermined threshold; receive and evaluate a resource state of at least one physical host in the O-Cloud computing environment; and create a resource management policy for allocating O-Cloud computing resources of the at least one physical host to scale the O-CU in the at least one physical location in the O-Cloud computing environment based on the comparison and evaluation.

Description

Technical Field

[0001] Apparatuses and methods consistent with exemplary 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 of a telecommunication network, and more particularly, to a method, apparatus, and non-transitory computer-readable storage medium storing instructions for controlling and implementing at least one resource management policy for allocating O-cloud computing resources to one or more Central Units (CUs).

Background Art

[0002] A Radio Access Network (RAN) is an important component in a telecommunication system for connecting end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices to a core network. Conventionally, 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 for telecommunications systems. For this purpose, O-RAN decomposes RAN functions into centralized units (CUs), distributed units (DUs), and radio units (RUs). CUs are logical nodes for hosting the RAN's Radio Resource Control (RRC), Service Data Adaptive Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. DUs are logical nodes for hosting the RAN's Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) sublayers. RUs are physical nodes that convert radio signals from antennas into digital signals that can be transmitted to the DUs via fronthaul. Because these entities have open protocols and interfaces between them, they can be developed by various vendors.

[0004] Figure 1 shows the O-RAN architecture of the related technology. Referring to Figure 1, the RAN functionality in the O-RAN architecture is controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to facilitate the multi-vendor operability required in O-RAN systems and to automate and optimize RAN operation. RICs are classified into two types: NRT-RIC (non-real-time RIC) and nRT-RIC (near real-time RIC).

[0005] The NRT RIC is the control point of the non-real-time control loop and operates on a timescale of more than one second within the Service Management and Orchestration (SMO) framework. Its functions are implemented through modular applications called rApps (rApp1, ..., rAppN in Figure 1) and include providing policy-based guidance and enrichment over the A1 interface, which is an interface that enables communication between the NRT-RIC and the nRT RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference to optimize the RAN; and / or recommending configuration management actions over the O1 interface, which is an interface that connects the SMO to RAN management elements (e.g., nRT RIC, O-RA Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0006] The nRT RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, O-CU (separated into the O-CU control plane (O-CU-CP) and O-CU user plane (O-CU-UP)), and Open Evolved Node B (O-eNB) via the E2 interface. The nRT RIC uses the E2 interface to control the underlying RAN elements (E2 node / network function (NF)) via a near real-time control loop. The nRT RIC monitors, pauses / stops, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) through policies. For example, nRT sets policy parameters for activated functions of the E2 nodes. Furthermore, the nRT RIC hosts xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize the O-RAN. For example, the NRT RIC provides policies, data, and AI / ML models enforced and used by the nRT RIC for RAN optimization via the A1 interface, and the nRT returns policy feedback (i.e., how the policies set by the NRT RIC are performing).

[0007] The SMO framework on which the NRT-RIC is located manages and coordinates RAN elements. Specifically, the SMO manages and orchestrates what is called the O-RAN cloud (O-cloud). The O-cloud is a collection of RICs, O-CUs and O-DUs, supporting software components (e.g., operating systems and runtime environments), and the physical RAN nodes that host 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 on which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS).

[0008] The O-Cloud resource control mechanism in related technologies monitors CU traffic and determines whether to expand or shrink its instantiation. In other words, the autoscaling in related technologies can expand or shrink deployed O-CU applications (or instances) based on traffic usage. However, this approach provides inadequate O-Cloud resource management in the event of sudden traffic spikes because resource management is limited to autoscaling within the same data center without considering the status and load of the underlying hardware infrastructure resources. As a result, a sudden traffic surge in a single data center can cause resource shortages when all O-CU applications attempt to scale up. In other words, O-CU autoscaling is concentrated within its own data center, despite the presence of unused server infrastructure (e.g., data centers) within the O-RAN network topology. [Overview of the project]

[0009] According to the embodiment, a system and method are provided for evaluating, controlling, and executing a centralized resource management control policy created by a modular application (rApp) hosted within a Radio Access Network (RAN) Intelligent Controller (RIC), the modular application controls and implements the allocation and reallocation of O-cloud resources by collecting at least one O-RAN resource indicator across the entire O-RAN network topology, comparing O-RAN performance indicators based on predetermined thresholds, and evaluating the resource status of physical hosts within the O-RAN network topology, thereby enabling more balanced utilization of O-cloud computing resources and energy-efficient network operation.

[0010] According to one 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 for a Telecommunications Network, the device comprising a memory for storing instructions and at least one processor within the SMO framework for implementing the RIC, wherein the at least one processor is configured to execute instructions for: receiving data from an Open RAN (O-RAN) Central Unit (O-CU) in an O-cloud computing environment, including at least one performance indicator including a performance indicator of the O-CU; comparing the at least one performance indicator to a first predetermined threshold; receiving and evaluating the resource status of at least one physical host in the O-cloud computing environment; and 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, based on the comparison and evaluation.

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

[0012] A resource management policy may be for allocating O-Cloud computing resources to scale an O-CU control plane (CP) based on at least one compared performance indicator, including an O-CU control plane (CP) performance indicator, and a resource management policy may be for allocating O-Cloud computing resources to scale an O-CU user plane (UP) based on at least one compared performance indicator, including an O-CU user plane (UP) performance indicator.

[0013] The performance indicator for O-CU CP may include the number of connected devices, while the performance indicator for O-CU UP may include the amount of traffic or the number of active devices.

[0014] At least one processor may be further configured to execute instructions for creating resource management policies based on the location information of at least one physical host, in order to consider the shortest path for moving traffic based on available resources.

[0015] At least one processor may be further configured to execute instructions for implementing a failsafe policy in which, based on N O-CUs instantiated according to a resource management policy, a single additional redundancy is instantiated as a failsafe for the N instantiated O-CUs.

[0016] Resource management policies may be designed to upscale O-CUs by instantiating additional O-CUs on physical hosts in a different data center than the O-CU data center, based on the evaluated resource state of the physical hosts within the O-CU data center.

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

[0018] According to another embodiment, a method for implementing a resource control mechanism, which is performed by an application hosted in a Radio Access Network (RAN) Intelligent Controller (RIC) within a Service Management and Orchestration (SMO) framework for a telecommunications network, may include: receiving data from an Open RAN (O-RAN) Central Unit (O-CU) in an O-cloud computing environment, which includes at least one performance indicator, including an O-CU performance indicator; comparing at least one performance indicator to a first predetermined threshold; receiving and evaluating the resource status of at least one physical host in the O-cloud computing environment; and, based on the comparison and evaluation, creating a resource management policy for allocating O-cloud computing resources of at least one physical host to scale an O-CU at at least one physical location in the O-cloud computing environment.

[0019] According to another embodiment, a non-temporary computer-readable recording medium in a service management and orchestration (SMO) framework for a telecommunications network records instructions executable by at least one processor for performing a method of implementing a resource control mechanism, the method of receiving data from an open RAN (O-RAN) central unit (O-CU) in an O-cloud computing environment, including at least one performance indicator including an O-CU performance indicator; comparing at least one performance indicator to a first predetermined threshold; receiving and evaluating the resource state of at least one physical host in the O-cloud computing environment; and, based on the comparison and evaluation, creating a resource management policy for allocating O-cloud computing resources of at least one physical host to scale an O-CU at at least one physical location in the O-cloud computing environment.

[0020] The features, aspects, and advantages of specific exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals indicate like elements.

Brief Description of the Drawings

[0021] [Figure 1] It is a diagram showing an O-RAN architecture in the related art.

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

[0023] [Figure 3] It is a diagram of exemplary components of a device according to an embodiment.

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

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

[0026] [Figure 6] It is a diagram showing the flow of information according to an embodiment.

[0027] [Figure 7] It shows a flowchart of a method for creating a resource management policy for allocating O-cloud computing resources to scale an O-CU according to an embodiment. [[ID=4​​​​​​

[0029] [Figure 9] A flowchart illustrating a method for creating a resource management policy to allocate O-cloud computing resources to scale down an O-CU, according to one embodiment, is shown.

[0030] [Figure 10] This is a diagram illustrating an exemplary environment for upscaling O-CU.

[0031] [Figure 11] This is a diagram illustrating an exemplary environment for downscaling O-CU.

[0032] [Figure 12] This table shows the resource status of vCU servers in an O-cloud computing environment. [Modes for carrying out the invention]

[0033] A detailed description of exemplary embodiments follows with reference to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0034] The foregoing disclosures provide examples and explanations, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or can be derived from the practice of the implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, it should be understood that in the flowcharts and descriptions of operation provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

[0035] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation form. Therefore, the operation and behavior of the systems and / or methods have been described herein without reference to specific software code. It will be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0036] While specific combinations of features are described in the claims and / or disclosed herein, these combinations do not limit the disclosure of possible implementations. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed herein. Each of the dependent claims listed below may directly depend on only one claim, but the disclosure of possible implementations includes each dependent claim combined with all other claims in the set of claims.

[0037] Any element, action, or command used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, as used herein, the articles “a” and “an” are intended to include one or more items and may be used synonymously with “one or more.” When only one item is intended, the term “one” or similar language is used. Also, as used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be open-ended terms. Furthermore, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Additionally, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0038] An exemplary embodiment of this disclosure provides a modular application (rApp) that hosts in a Radio Access Network (RAN) Intelligent Controller (RIC) and provides automatic scaling of O-CUs, taking into account both traffic utilization indicators and the underlying hardware resources of the O-Cloud infrastructure on which the O-CUs are deployed, in order to determine where the O-CUs should be scaled across the entire network topology. As a result, the rApp-based O-CU autoscaling in the exemplary embodiment can decide to scale up O-CUs in different data centers based on the resource state of the data centers, so that a sudden traffic surge does not lead to resource shortages in a single data center.

[0039] In an exemplary embodiment, the rApp calculates or determines how many new application instanceizations or resources are needed, taking into account O-CU performance indicators and cloud resources, and selects a cloud cluster to deploy the new application (e.g., O-CU control plane and / or user plane) instanceizations.

[0040] The methods and apparatus according to exemplary embodiments enable a more balanced use of O-cloud computing resources in an O-cloud environment to facilitate energy-efficient networks.

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

[0042] The user device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to the platform 220. For example, the user device 210 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones, etc.), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some implementations, the user device 210 may receive information from and / or transmit information to the platform 220.

[0043] Platform 220 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 220 may include a cloud server or a group of cloud servers. In some implementations, Platform 220 may be designed to be modular so that certain software components can be swapped in or swapped out as needed. Thus, Platform 220 can be easily and / or quickly reconfigured for different uses.

[0044] In some implementations, as shown in the figure, platform 220 may be hosted in a cloud computing environment 222. In particular, the implementations described herein describe platform 220 as being hosted within a cloud computing environment 222, but in some implementations, platform 220 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment), or it may be partially cloud-based.

[0045] The cloud computing environment 222 includes an environment that hosts platform 220. The cloud computing environment 222 can provide services that do not require end-user (e.g., user device 210) knowledge of the physical location and configuration of the systems and / or devices that host platform 220, such as computing, software, data access, and storage. As illustrated, the cloud computing environment 222 may include a group of computing resources 224 (collectively referred to as “computing resources 224” and individually as “computing resources 224”).

[0046] Computing resource 224 includes one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resource 224 can host platform 220. Cloud resources may include computing instances running within computing resource 224, storage devices located within computing resource 224, and data transfer devices provided by computing resource 224. In some implementations, computing resource 224 may communicate with other computing resources 224 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0047] As further shown in Figure 2, the computing resource 224 includes a group 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, and one or more hypervisors ("HYP") 224-4.

[0048] Application 224-1 includes one or more software applications that can be provided or accessed by the user device 210. Application 224-1 can eliminate the need to install and run software applications on the user device 210. For example, Application 224-1 may 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 may send and receive information with one or more other applications 224-1 via a virtual machine 224-2.

[0049] A virtual machine 224-2 includes a machine (e.g., a computer) in the form of a software implementation that runs programs like a physical machine. Depending on its application and the degree to which the virtual machine 224-2 corresponds to an actual machine, it may be either a system virtual machine or a process virtual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can run a single program and can support a single process. In some implementations, the virtual machine 224-2 may run on behalf of a user (e.g., a user device 210) and may manage the infrastructure of a cloud computing environment 222, such as data management, synchronization, or long-term data transfer.

[0050] Virtualized storage 224-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage systems or devices of the computing resources 224. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization can refer to the extraction (or isolation) of logical storage from physical storage so that the storage system can be accessed regardless of whether it is physical storage or heterogeneous. Isolation may allow administrators flexibility in how the storage system manages storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and where the files are physically stored. This may enable optimized storage usage, server consolidation, and / or non-disruptive file movement.

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

[0052] Network 230 includes one or more wired and / or wireless networks. For example, Network 230 may include cellular networks (e.g., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), telephone networks (e.g., public switched telephone networks (PSTNs)), private networks, ad hoc networks, intranets, the Internet, fiber optic-based networks, etc., and / or combinations of these or other types of networks.

[0053] The number and arrangement of devices and networks shown in Figure 2 are provided as examples. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements than those shown in Figure 2. Furthermore, two or more devices shown in Figure 3 may be implemented within a single device, or a single device shown in Figure 3 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices in environment 300 (e.g., one or more devices) may perform one or more functions that are described as being performed by another set of devices in environment 300.

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

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

[0056] The storage component 340 stores information and / or software related to the operation and use of device 300. For example, the storage component 340, along with a corresponding drive, may include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital multipurpose disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other types of non-temporary computer-readable media. The input component 350 includes components that enable device 300 to receive information via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone). Additionally or alternatively, the input component 350 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, an accelerometer, a gyroscope, and / or actuators). The output component 360 includes components that provide output information from device 300 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0057] The communication interface 370 includes transceiver-like components (e.g., a transceiver and / or separate receivers and transmitters) that enable device 300 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 370 may enable device 300 to receive information from and / or provide information to other devices. For example, the communication interface 370 may include Ethernet interfaces, optical interfaces, coaxial interfaces, infrared interfaces, radio frequency (RF) interfaces, Universal Serial Bus (USB) interfaces, Wi-Fi interfaces, cellular network interfaces, and the like.

[0058] Device 300 can perform one or more processes as described herein. Device 300 can perform these processes in response to a processor 320 that executes software instructions stored in a non-temporary computer-readable medium, such as memory 330 and / or storage component 340. Computer-readable medium is defined herein as a non-temporary memory device. A memory device includes a memory space within a single physical storage device or a memory space spanning multiple physical storage devices.

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

[0060] Additionally or alternatively, hardwired circuits may be used instead of, or in combination with, software instructions to perform one or more processes described herein. Therefore, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0061] The number and arrangement of components shown in Figure 4 are provided as an example. In practice, device 300 may include additional components, fewer components, different components, or components in different arrangements than those shown in Figure 4. Additionally or alternatively, a set of components of device 300 (e.g., one or more components) may perform one or more functions that are described as being performed by another set of components of device 300.

[0062] In the embodiment, any one of the operations or processes shown in Figures 5 to 12 may be implemented by or using any one of the elements shown in Figures 3 and 4.

[0063] Figure 4 is a diagram of a system architecture according to an exemplary embodiment. Referring to 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 central 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 mentioned above, the O-CU is an application deployed on a cloud platform (O-cloud) and instantiated on a physical host (i.e., a server) in a data center.

[0064] In other words, an O-CU is assigned to a specific topology within the O-RAN network. This topology 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 hosting virtual machine that runs the O-CU application of the vCU cluster. The vCU cluster may be hosted on at least one vCU server within at least one data center.

[0065] At least one vCU server is a physical host with computing resources 224 in the O-cloud computing environment, for example, as shown in Figure 6. The data center is, for example, the location of at least one such physical host within the O-cloud computing environment (as shown in Figure 6).

[0066] A physical host, for example, hosts at least one O-CU node and / or a cluster of O-CU nodes in the O-RAN. An O-CU node is an O-CU in the O-RAN network as shown in Figures 1 to 5, which runs O-CU applications in the O-cloud computing environment.

[0067] As shown in Figure 1, the various network elements and RICs 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 acquire performance indicators (or key performance indicators (KPIs)) via the E2 interface. The performance indicator set may relate to one or more cells, slices, QoS classes, or specific UEs. For this purpose, the near-RT RIC can be directly connected to the O-eNB, the O-CU's control plane (C-plane), the O-CU's user plane (U-plane), and the O-DU. In the O-CU, the C-plane and U-plane perform control and user functions, respectively. The C-plane and U-plane are connected via the E1 interface. The C-plane and U-plane are also connected to the O-DU via the F1 interface by dedicated subinterfaces F1-u and F2-c, respectively. The O-CU communicates with other O-CUs via the Xn(X2) interface, which connects different gNBs and / or eNBs. Furthermore, the NG interface connects the gNB to the 5G core. Both the Xn(X2) and NG interfaces have dedicated subinterfaces for connecting to the O-CU's C-plane and U-plane, respectively.

[0069] Figure 6 is a diagram of an exemplary environment in a data center housing vCU servers that host a cluster of O-CUs. At least one O-DU is connected to an O-CU. The O-DU includes baseband processing and can support one or more cells. This means that the location housing the O-DUs hosted on at least one vDU server, and the location of the vCU cluster hosted by at least one vCU server, are predetermined according to the overall network topology of cells and beams, based on the topological hierarchy of the radio network resulting from the locations of the radio antennas that form the cells. For example, the Yokohama cell is radio controlled by a vCU cluster hosted by at least one vCU server in the Yokohama data center. Thus, the O-cloud environment is network topology independent, but the data center housing the vCU cluster has a predetermined geographical location based on the network topology in the real world.

[0070] A modular application (rApp) monitors the performance of each O-CU within the vCu cluster and controls and implements resource management policies based on performance indicators for the C-plane and U-plane applications of each O-CU within the vCu cluster. For example, the performance indicator for an O-CU UP may include at least one of the following: the amount of traffic passing through the O-CU UP or the number of active devices connected to the O-CU. The performance indicator for an O-CU CP may include the number of devices connected to the O-CU. Furthermore, 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 on which the O-CU C / U-plane is instantiated. This information may include, for example, how much memory is being used, processor load, and how much hard disk drive space is being used. The rApp can receive performance indicators and resource information from at least one of the E2, A1, and O2 interfaces.

[0071] Figure 6 shows the information flow in one embodiment. Referring to Figure 6, performance indicators for the O-CU C-plane (CP) and O-CU U-plane (UP), as well as cloud resource information (or status), are provided to the rApp in one embodiment via at least one of the E2, A1, and O2 interfaces. In one or more embodiments, the O-CU CP requests the O-CU UP performance indicator from the O-CU UP and sends it to the rApp.

[0072] Figure 7 shows a flowchart of a method 700 for creating a resource management policy according to one embodiment. Referring to Figure 7, in step 701, the modular application (rApp) receives performance indicators for the O-RAN function. These performance indicators for the O-RAN function may include, for example, performance indicators for the O-CU U-plane, which may include the amount of traffic or the number of active devices, and / or performance indicators for the O-CU C-plane, which may include relevant parameters (e.g., the number of connected devices) to trigger whether the O-CU should be upscaled or downscaled.

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

[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 housing the scaling O-CUs). The modular application (rApp) receives the resource state from at least one physical host to house the O-cloud computing resources that are ready to be allocated to or have been allocated to the O-CUs. In some embodiments, step 703 may be performed based on or in response to the comparison in step 702, but 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 regardless of the result of the comparison in step 702.

[0075] Resource status may include, for example, at least one of the following: processor load, memory usage, hard disk drive usage, etc., of at least one physical host in the topology of the O-RAN network. Furthermore, resource status may be pushed to rApp (e.g., periodically or continuously) or pulled by rApp (e.g., by periodic requests, by event-triggered requests (e.g., based on threshold determination in step 702), etc.). For example, 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 for scaling O-CUs at at least one physical location within the O-cloud computing environment by allocating O-cloud computing resources from at least one physical host to one or more O-CU nodes, based on comparisons (e.g., in step 702) and evaluations (e.g., in step 703). For example, the scaling decision may be based on the comparison in step 702, and the decision of which server or data center location within the O-cloud platform instantiates the O-CU for each scaling may be based on the evaluation in step 703.

[0077] As an example, the Yokohama data center houses at least one vCU that server-hosts vCU cluster 01, as shown in Figure 5. If a sudden spike occurs in equipment (UE) or traffic among connected / active users, the modular application (rApp) evaluates the topological confinement of the spike by comparing its performance indicators to one or more thresholds and using resource state metrics, i.e., "resource state request / response" IE, based on the O-RAN network topology. In this case, if the performance indicators exceed the threshold with each comparison, but the resource state evaluation (e.g., comparison with one or more resource thresholds where the availability of hardware / cloud resources for O-CU instantiation is determined) indicates that the Yokohama data center does not have sufficient resources for newly instantiated O-CUs, the rApp can evaluate the resource state of other data centers to determine another data center that has sufficient resource availability to scale up the O-CUs. Here, the rApp may also consider other factors, such as location information, to determine the location for O-CU instantiation, which will provide the shortest path for moving the traffic.

[0078] According to an exemplary embodiment, rApp can provide policies to an operational support system (OSS) to generate scaling configurations and control the scaling process.

[0079] Figure 8 shows a flowchart of Method 800 for creating a resource management policy for allocating O-Cloud computing resources to scale up an O-CU, according to one embodiment. Referring to Figure 8, as in step 701, the modular application (rApp) obtains performance indicators of the O-RAN functionality in step 801. In step 802, as in step 702, the modular application (rApp) compares the performance indicators to a second threshold for upscaling. The second threshold for upscaling may be the same as the first threshold for downscaling. However, both thresholds may differ from each other to provide a more flexible upscaling or downscaling procedure.

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

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

[0082] For example, according to the upscaling flow in Figure 8, if there is an unpredictable event that causes a sudden spike in UE traffic or any other factor that necessitates upscaling the O-CU in the Yokohama area, the modular application (rApp) obtains a "resource state response" IE or other resource state. Based on the evaluation of this resource state, the modular application (rApp) creates a resource management policy. The resource management policy may be a set of commands for allocating O-cloud resources from other vCU clusters in the network topology to vCU cluster 01 in the Yokohama area. In other words, the resource management policy is a set of commands for instantiating a new O-CU application on at least one vCU server. The vCU server for instantiating the new O-CU application may be located in a different location from the original O-CU.

[0083] If the vCU server hardware infrastructure resources reach their maximum level in the Yokohama data center, the modular application (rApp) will retrieve and evaluate the resource status of vCU servers hosting other locations, such as vCU cluster 02 in Kawasaki, or adjacent to vCU cluster 01 in the Yokohama area.

[0084] For example, a modular application (rApp) uses a "resource status request / response" IE to evaluate and determine the status of a vCU server based on a predetermined perimeter around the location of data center 01 within the Yokohama area.

[0085] For this purpose, unused resources of vCU servers in data centers, particularly those located near data center 01, can be used to allocate those hardware infrastructure resources to 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 O-CU running on vCU cluster 01 in the Yokohama area on a vCU server in vCU cluster 02 in Kawasaki.

[0086] This has the advantage that if the Yokohama data center reaches its maximum hardware resource limit, other data centers closer to Yokohama can use their unused hardware resources to instantiate new O-CU applications for O-CU that would normally be hosted in the Yokohama data center.

[0087] Figure 9 shows a flowchart of a method 900 for creating a resource management policy to allocate O-cloud computing resources to scale down an O-CU, according to one embodiment. Referring to Figure 9, similar to step 701, the modular application (rApp) obtains performance indicators of the O-RAN functionality in step 901. In step 902, similar to step 702, the modular application (rApp) compares the performance indicators to a first threshold for downscaling, where the first threshold may be a threshold that triggers a downscaling 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 that houses O-cloud computing resources that are ready to be allocated to or have been allocated to the O-CU.

[0089] Similar to Figures 7 and 8, resource status can be obtained, for example, by a “resource status response” IE, or by other resource statuses which may include one of the following: processor load, memory usage, and hard disk drive usage of at least one physical node.

[0090] In step 904, the modular application (rApp) creates a resource management policy to downscale the O-CU at at least one physical location within the O-cloud computing environment by allocating O-cloud computing resources from at least one physical host to one or more O-CU nodes, based on comparisons (e.g., in step 902) and evaluations (e.g., in step 903).

[0091] For example, O-CU can be connected to up to 18,000 UEs. The UEs are hosted in three separate pods, each configured to host 6,000 UEs. If the load on O-CU is only 200 UEs (based on the comparison in step 902, for example), two of the three pods will be terminated by the resource management policy.

[0092] Furthermore, in conventional resource control mechanisms, the O-CU always maintains three pods in its basic configuration. Therefore, a minimal resource management policy to shut down two pods saves energy in the operation of the O-RAN network.

[0093] In a further embodiment, the resource management policy may include fail-safe downscaling by applying "N+1" redundancy. This means, for example, that two pods are used despite a load of only 200 UEs, with N+1 pods being hot spares kept in standby mode to be linked to the O-CU. Furthermore, if 12,000 UEs are hosted on two O-CU pods or instantiations, the resource management fail-safe policy in the exemplary embodiment may apply "N+1" redundancy (i.e., three pods) instead of N+N redundancy, thereby achieving the minimum possible configuration and optimized / reduced energy requirements.

[0094] In a further embodiment, the resource management policy may include a policy for allocating pre-instantiated O-cloud computing resources. These resources are, for example, pre-instantiated pods hosted on a vCU server. These pre-instantiated pods can be linked to the O-CU without requiring the resource management policy to run to instantiate new pods for additional O-CU applications. Linking pre-instantiated O-cloud computing resources saves instantiation time lag (e.g., about 20 seconds) because linking pre-instantiated pods occurs within a fraction of a second.

[0095] In further embodiments, the resource management policy may include deploying "N+1" redundancy and linking pre-instantiated pods to the O-CU. This resource management policy is energy-efficient and enables flexible and rapid 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) retrieves and evaluates resource states to create resource management policies for terminating an O-CU rich O-CU application, regardless of the location of the physical host running the rich O-CU. This means, for example, that an O-CU application in an O-CU in the Yokohama data center running on a vCU server in the Kawasaki data center will be terminated by the resource management policy, just like a rich O-CU application in an O-CU within the Yokohama data center.

[0097] This resource management policy, which involves downscaling hardware resources based on their resource state within an O-RAN network topology, is more energy-efficient and provides resource management across the entire O-RAN network topology.

[0098] Figures 10 and 11 illustrate exemplary embodiments of "upscale operation" and "downscale operation," respectively, controlled and implemented by a modular application (rApp), according to one or more embodiments.

[0099] Referring to Figure 10, the modular application (rApp) obtains performance indicators of the O-RAN functionality. These performance indicators can be pushed to the rApp (e.g., periodically or continuously) or pulled by the rApp (e.g., by periodic requests, event-triggered requests (e.g., threshold determination)). Based on the obtained performance indicators, the modular application (rApp) compares these indicators to a threshold to trigger a scaling request or command. In Figure 10, the request or command is a scale-up request. Furthermore, the modular application (rApp) obtains resource status from physical hosts within the O-RAN network topology. This may include the physical host(s) running the O-CUs being scaled and other physical hosts(s) that may be capable of supporting additional O-CU applications for the O-CUs. Additionally, the modular application (rApp) obtains transport details to select the physical host with the lowest latency (e.g., the shortest path to the physical host of the O-CU being scaled). Modular applications can obtain and / or evaluate transport details based on a comparison of performance indicators with thresholds.

[0100] Referring further to Figure 10, for example, a modular rAPP may communicate with the O-CU CP via the E2 and E1 interfaces to obtain O-CU UP performance indicators, and with the O-CU CP via the F1 interface to obtain performance indicators such as active UE, UE traffic, and data throughput from the O-DU. Similarly, resource status can be obtained by a "resource status request / response" IE.

[0101] In another example, a modular rAPP can 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 upscaling request threshold is reached, and the resource status of at least one physical host is evaluated. Based on the evaluation, a new pod is instantiated, or a previously instantiated pod is linked to the O-CU that has reached 75% of its capacity.

[0102] Performance indicators are diverse, and the list is not exhaustive. For example, at least one performance indicator may include, among others, a key performance indicator (KPI) of the wireless network layer, the transport network layer interface connecting the O-CU's U-plane or C-plane, the traffic for each of the user functions running on the O-CU's U-plane, and at least one O-RAN system operation KPI of the O-CU.

[0103] For example, the KPI could be the traffic status of the O-CU U-plane application usage, for instance, if the O-CU U-plane application is designed to carry ~6Gbps of traffic to each microservice pod. In this case, a threshold could be set for the traffic of at least one user application running 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 pod and / or the O-CU internal system trigger overload threshold.

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

[0106] The resource state may include the most appropriate 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 capabilities of at least one vCU server, transfer speed, and traffic routing. The events for selecting a given location in the data center are not limited to the examples above. Selecting a preferred physical location within the O-RAN network may include at least one of the most appropriate locations described above, and / or a given physical location for a mobile operator, for example, a specific location in the event of a major disruption to O-cloud computing (e.g., a natural disaster).

[0107] For example, a modular application (rApp) may create a resource management policy that includes determining where, how much, and / or which new O-CU applications (e.g., pods or microservice instantiations) should be instantiated. Based on a comparison of performance indicators, it may select at least one vCU server or at least one vCU cluster in at least one data center to deploy new application instantiations or resources (e.g., by evaluating resource states that allow determining the most appropriate location, the most appropriate server, and the most appropriate amount of pods to be instantiated).

[0108] Referring further to Figure 10, a modular application (rApp) may include comparing key performance indicators (KPIs) of the O-CU's C-plane and U-plane with corresponding thresholds, acquiring and evaluating resource status, and instantiating only the O-CU applications that need to be upscaled based on the comparison and evaluation. This means that a resource management policy may allocate O-cloud computing resources to scale the O-CU CP based on compared performance indicators, including performance indicators of the O-CU control plane (CP), and a resource management policy may allocate O-cloud computing resources to scale the O-CU UP based on at least one compared performance indicator, including performance indicators of the O-CU user plane (UP).

[0109] Figure 11 shows an exemplary embodiment of a “downscaling operation” controlled and implemented by a modular application (rApp) according to an exemplary embodiment. Similar to Figure 10, the modular application (rApp) acquires performance indicators of the O-RAN network function. The modular application (rApp) then compares the performance indicators to a first threshold to trigger a termination request for the abundant O-CU. Furthermore, the modular application (rApp) acquires the resource state of the abundant O-CU and / or the resource state of the physical host housing the abundant O-CU or part thereof. Based on the resource state and transport details of the physical host(s), which may be located at different locations, the modular application (rApp) creates a resource management policy for terminating the abundant O-CU.

[0110] Referring further to Figure 11, a modular application (rApp) can create resource management policies that include fail-safe configurations. For example, instead of N+N redundancy, N+1 redundancy for fail-safe purposes can be configured as a result of the flexibility provided by the resource control mechanism in the exemplary embodiment. As a result, robust and energy-efficient operation of the RAN in an O-cloud environment can be achieved. This reduction in O-cloud resources enables more energy-efficient operation of the O-RAN.

[0111] Referring further to Figure 11, a modular application (rApp) may include selecting at least one of the O-CU's C-plane applications or O-CU's U-plane applications, comparing the application's key performance indicators (KPIs) to thresholds, acquiring and evaluating resource status, and terminating only the O-CU applications that need to be downscaled based on the comparison and evaluation. This means that a resource management policy may allocate O-cloud computing resources to scale the O-CU CP based on compared performance indicators, including performance indicators for the O-CU control plane (CP), and a resource management policy may allocate O-cloud computing resources to scale the O-CU UP based on at least one compared performance indicator, including performance indicators for the O-CU user plane (UP).

[0112] Figure 12 shows a table illustrating the resource status of vCU servers in an O-cloud computing environment. The resource status for each vCU server may include the percentage of cores in use out of the total number of available cores per vCU server, the percentage of cores in use out of the number of isolated cores per vCU server, the percentage of cores in use out of the number of dedicated cores per vCU server, the CPU status for each vCU server, the hard disk allocation for each vCU server, the system usage for each vCU server, the role of the vCU server within the vCU cluster, and the operational status of the vCU server.

[0113] According to the embodiment, a device and method are provided 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), the policy implementing O-CU scaling based on consideration of the resource state of the underlying cloud hardware resources. As a result, efficient scaling and operation of O-CU instanceization can be achieved, and hardware resource shortages in a particular cluster or data center (e.g., due to traffic surges) can be prevented.

[0114] The foregoing disclosures provide examples and explanations, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or can be derived from the practice of the implementations.

[0115] Some embodiments may relate to systems, methods, and / or computer-readable media in integration at any possible level of technical detail. Furthermore, one or more of the components described above 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-temporary storage medium (or more mediums) having computer-readable program instructions for causing a processor to perform an operation.

[0116] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved structures having instructions recorded therein, and any suitable combination thereof. The computer-readable storage media used herein should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

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

[0118] The computer-readable program code / instructions for performing an operation may be source code or an object-oriented programming language written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object code such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar languages. The computer-readable program instructions may run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may 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 it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions for personalizing the electronic circuit in order to perform an action or operation.

[0119] These computer-readable program instructions can be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device so that instructions executed via the processor of a computer or other programmable data processing device create means for implementing functions / operations specified in one or more blocks of a flowchart and / or block diagram, thereby enabling the manufacture of a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct computers, programmable data processing devices, and / or other devices to function in a particular way, and as a result, the computer-readable storage medium on which the instructions are stored includes a product containing instructions that implements modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0120] Computer-readable program instructions can also be loaded into a computer, other programmable data processing device, or other device to generate a computer implementation process by causing the instructions executed on the computer, other programmable device, or other device to perform a series of operational steps on the computer, other programmable device, or other device so that they implement a function / operation specified in one or more blocks of a flowchart and / or block diagram.

[0121] The flowcharts and block diagrams in the figures illustrate the architecture, functions, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction containing one or more executable instructions for implementing a specified logical function(s). Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in a different order than shown in the figures. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0122] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to any particular implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

Claims

1. A device for implementing applications hosted in a Radio Access Network (RAN) Intelligent Controller (RIC) within a Service Management and Orchestration (SMO) framework for telecommunications networks, Memory for storing instructions, The RIC comprises at least one processor within the SMO framework for implementing the RIC, and the at least one processor is Receiving data from an Open RAN (O-RAN) Central Unit (O-CU) in an O-Cloud Computing Environment, including at least one performance indicator, including the performance indicator of the O-CU; Comparing the at least one performance indicator with a first predetermined threshold, The O-receives and evaluates the resource status of at least one physical host within the cloud computing environment, Based on the comparison and evaluation, a resource management policy is created for allocating O-cloud computing resources of the at least one physical host in order to scale the O-CU at at least one physical location within the O-cloud computing environment. It is configured to execute the aforementioned instructions for performing the following: The at least one physical location is selected from the plurality of physical locations based on the evaluation, according to the location information of the plurality of physical locations. Device.

2. The resource management policy is for allocating O-cloud computing resources to scale up the O-CU by instantiating additional O-CUs. The aforementioned at least one processor is Receiving an additional performance indicator of the O-CU, wherein the additional performance indicator corresponds to the same performance metric as the at least one performance indicator, but at a later point in time. The additional performance indicator of the O-CU is compared with a second predetermined threshold that is different from the first predetermined threshold, Based on the above comparison, it is decided to scale down by terminating the additional OCU, It is further configured to execute the aforementioned instructions for performing the above. The apparatus according to claim 1.

3. The resource management policy is for allocating O-cloud computing resources to scale the O-CU control plane (CP) based on the compared performance indicators, including the performance indicators of the O-CU control plane (CP). The apparatus according to claim 1, wherein the resource management policy is for allocating O-cloud computing resources to scale the O-CU user plane (UP) based on the compared performance indicators, including the performance indicators of the O-CU user plane (UP).

4. The apparatus according to claim 3, wherein the performance indicator of the O-CU CP includes the number of connected devices, and the performance indicator of the O-CU UP includes the amount of traffic or the number of active devices.

5. The aforementioned at least one processor is The apparatus according to claim 1, further configured to execute the instructions for creating the resource management policy based on the location information of at least one physical host, in order to consider the shortest path for moving traffic based on available resources.

6. The aforementioned at least one processor is The system is further configured to execute the instructions for implementing a failsafe policy in which, based on N O-CUs instantiated according to the resource management policy, a single additional redundancy is instantiated as a failsafe for the N instantiated O-CUs, where N is an integer greater than 1. The apparatus according to claim 1.

7. The apparatus according to claim 1, wherein the resource management policy is for upscaling the O-CU by instantiating additional O-CUs on physical hosts in a different data center from the O-CU's data center, based on the evaluated resource state of the O-CU's physical hosts in the O-CU's data center.

8. The apparatus according to claim 1, wherein the resource state of the at least one physical host includes at least one of the hardware processor load, memory usage, and hard disk drive usage of the at least one physical host.

9. A method for implementing a resource control mechanism, which is executed by an application hosted within a Radio Access Network (RAN) Intelligent Controller (RIC) in a Telecommunications Network Service Management and Orchestration (SMO) framework, Receiving data from an Open RAN (O-RAN) Central Unit (O-CU) in an O-Cloud Computing Environment, including at least one performance indicator, including the performance indicator of the O-CU; Comparing the at least one performance indicator with a first predetermined threshold, The O-receives and evaluates the resource status of at least one physical host within the cloud computing environment, Based on the comparison and evaluation, a resource management policy is created for allocating O-cloud computing resources of the at least one physical host in order to scale the O-CU at at least one physical location within the O-cloud computing environment. Includes, A method in which the at least one physical location is selected from among the plurality of physical locations based on the evaluation, according to the location information of the plurality of physical locations.

10. The resource management policy is for allocating O-cloud computing resources to scale up the O-CU by instantiating additional O-CUs. The aforementioned method, Receiving an additional performance indicator of the O-CU, wherein the additional performance indicator corresponds to the same performance metric as the at least one performance indicator, but at a later point in time. The additional performance indicator of the O-CU is compared with a second predetermined threshold that is different from the first predetermined threshold, Based on the above comparison, it is decided to scale down by terminating the additional OCU, The method according to claim 9, further comprising:

11. The resource management policy is for allocating O-cloud computing resources to scale the O-CU control plane (CP) based on the compared performance indicators, including the performance indicators of the O-CU control plane (CP). The method according to claim 9, wherein the resource management policy is for allocating O-cloud computing resources to scale the O-CU user plane (UP) based on the compared performance indicators, including the performance indicators of the O-CU user plane (UP).

12. The method according to claim 11, wherein the performance indicator of the O-CU CP includes the number of connected devices, and the performance indicator of the O-CU UP includes the amount of traffic or the number of active devices.

13. Generating the aforementioned resource management policy means The method according to claim 9, comprising creating the resource management policy based on the location information of at least one physical host in order to consider the shortest path for moving traffic based on available resources.

14. The method according to claim 9, further comprising implementing a failsafe policy in which, based on N O-CUs instantiated in accordance with the resource management policy, a single additional redundancy is instantiated as a failsafe for the N instantiated O-CUs, where N is an integer greater than 1.

15. The method according to claim 9, wherein the resource management policy is for upscaling the O-CU by instantiating additional O-CUs on physical hosts in a different data center from the O-CU's data center, based on the evaluated resource state of the O-CU's physical hosts in the O-CU's data center.

16. The method according to claim 9, wherein the resource state of the at least one physical host includes at least one of the hardware processor load, memory usage, and hard disk drive usage of the at least one physical host.

17. A non-temporary computer-readable recording medium within a service management and orchestration (SMO) framework for telecommunications networks, which records instructions executable by at least one processor for implementing a method for implementing a resource control mechanism, The aforementioned method, From an Open RAN (O-RAN) Central Unit (O-CU) in an O-Cloud Computing Environment, at least one performance indicator, including the performance indicator of the O-CU, Receiving data including caterer, Comparing the at least one performance indicator with a first predetermined threshold, The O-receives and evaluates the resource status of at least one physical host within the cloud computing environment, Based on the comparison and evaluation, this includes creating a resource management policy for allocating O-cloud computing resources of the at least one physical host in order to scale the O-CU at at least one physical location within the O-cloud computing environment. The at least one physical location is selected from among the multiple physical locations based on the evaluation, according to the location information of the multiple physical locations. Non-temporary computer-readable recording medium.

18. The aforementioned method, Receiving an additional performance indicator of the O-CU, wherein the additional performance indicator corresponds to the same performance metric as the at least one performance indicator, but at a later point in time. The additional performance indicator of the O-CU is compared with a second predetermined threshold that is different from the first predetermined threshold, Based on the above comparison, it is decided to scale down by terminating the additional OCU, A non-temporary computer-readable recording medium according to claim 17, further comprising:

19. Generating the aforementioned resource management policy means The non-temporary computer-readable recording medium according to claim 17, comprising creating the resource management policy based on the location information of at least one physical host in order to consider the shortest path for moving traffic based on available resources.

20. The non-temporary computer-readable recording medium according to claim 17, wherein the resource management policy is for upscaling the O-CU by instantiating additional O-CUs on physical hosts in a different data center from the O-CU's data center, based on the evaluated resource state of the O-CU's physical hosts in the O-CU's data center.

Images