Apparatus and method for providing resource management policies in a telecommunications system

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] Apparatus and methods consistent with example embodiments of the present disclosure relate to evaluating, controlling, and enforcing resource management control policies created by modular applications (rApps) hosted in a Radio Access Network (RAN) Intelligent Controller (RIC) within a Service Management and Orchestration (SMO) framework of a telecommunications network, and more particularly, to a method, apparatus, and a non-transitory computer-readable storage medium storing instructions for performing the control and implementation of at least one resource management policy for allocating O-Cloud Computing resources to one or more Centralized Units (CUs). [Background technology]

[0002] The Radio Access Network (RAN) is a key component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices 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 for telecommunications systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), distributed units (DUs), and radio units (RUs). The 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. The DU is a logical node for hosting the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the fronthaul. These entities have open protocols and interfaces between them, allowing them to be developed by various vendors.

[0004] Figure 1 shows the O-RAN architecture of related technology. Referring to Figure 1, RAN functions in the O-RAN architecture are controlled and optimized by RICs. RICs are software-defined components that implement modular applications to facilitate the multi-vendor operability required in O-RAN systems and to automate and optimize RAN operations. RICs are divided into two types: NRT-RICs (non-real-time RICs) and nRT-RICs (near real-time RICs).

[0005] The NRT RIC is the control point for non-real-time control loops and operates on sub-second timescales within a 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 the interface enabling communication between the NRT-RIC and the nRT RIC; performing data analytics, artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the O1 interface, which is the interface connecting the SMO to RAN management elements (e.g., nRT RIC, O-RAN 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 connects to the O-DU, the O-CU (separated into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the open evolved Node B (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 near-real-time control loops. The nRT RIC monitors, suspends / stops, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) through policies. For example, the 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 over the A1 interface that are enforced and used by the nRT RIC for RAN optimization, and the nRT returns policy feedback (i.e., how the policies set by the NRT RIC are performing).

[0007] The SMO framework, in which the NRT-RIC resides, 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 physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating systems and runtime environments), 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 in 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 the related art monitors the traffic of a CU to determine whether to scale up or down its instantiation. That is, the autoscaling in the related art can scale up or down a deployed O-CU application (or instance) based on traffic usage. However, this approach provides insufficient O-Cloud resource management in the event of a sudden traffic surge because the resource management is limited to autoscaling within the same data center without considering the resource status and load of the underlying hardware infrastructure. As a result, a sudden traffic surge in a single data center may cause resource shortages when all O-CU applications attempt to scale up. In other words, despite underutilized server infrastructure (e.g., data centers) in the topology of the O-RAN network, O-CU autoscaling is centralized within its own data center. Summary of the Invention

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

[0010] According to one embodiment, 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 comprises: a memory that stores instructions; and at least one processor within the SMO framework for implementing the RIC, wherein the at least one processor is configured to execute the instructions to: receive data from an Open RAN (O-RAN) Convergence Unit (O-CU) within 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 within 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 at least one physical location within the O-Cloud Computing environment based on the comparison and the evaluation.

[0011] The 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 with a second predetermined threshold, and determine to scale down by terminating the additional O-CU based on the comparison.

[0012] The resource management policy may be for allocating O-Cloud computing resources to scale the O-CU Control Plane (CP) based on at least one compared performance indicator including a performance indicator of the O-CU CP, and the resource management policy is for allocating O-Cloud computing resources to scale the O-CU User Plane (UP) based on at least one compared performance indicator including a performance indicator of the O-CU User Plane (UP).

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

[0014] The at least one processor may be further configured to execute instructions for creating a resource management policy based on location information of the at least one physical host to consider shortest paths for moving traffic based on available resources.

[0015] The at least one processor may be further configured to execute instructions to implement a failsafe policy in which, based on the 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.

[0016] The resource management policy may be for upscaling the O-CU by instantiating additional O-CUs on physical hosts in a data center different from the O-CU's data center based on the assessed resource state of physical hosts in 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 disk drive usage of the at least one physical host.

[0018] According to another embodiment, a method for implementing a resource control mechanism executed 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 from an Open RAN (O-RAN) Centralized Unit (O-CU) in an O-Cloud computing environment, the data 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 a 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 in at least one physical location within the O-Cloud computing environment based on the comparison and evaluation.

[0019] According to another embodiment, a non-transitory computer-readable storage medium in a Service Management and Orchestration (SMO) framework of a telecommunications network has stored thereon instructions executable by at least one processor to perform a method for implementing a resource control mechanism, the method may include receiving data from an Open RAN (O-RAN) Centralization Unit (O-CU) in an O-Cloud computing environment, the data 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 a resource state 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 in at least one physical location in the O-Cloud computing environment based on the comparison and evaluation.

[0020] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

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

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

[0023] [Figure 3] FIG. 2 is a diagram of exemplary components of a device according to one embodiment.

[0024] [Figure 4] FIG. 1 is a diagram of a system architecture according to one embodiment.

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

[0026] [Figure 6] FIG. 2 illustrates information flow according to one embodiment.

[0027] [Figure 7] 1 illustrates a flowchart of a method for creating a resource management policy for allocating O-Cloud computing resources for scaling an O-CU, according to one embodiment.

[0028] [Figure 8] 1 illustrates a flowchart of a method for creating a resource management policy for allocating O-Cloud computing resources to scale up an O-CU, according to one embodiment.

[0029] [Figure 9] 1 illustrates a flowchart of a method for creating a resource management policy for allocating O-Cloud computing resources to scale down an O-CU, according to one embodiment.

[0030] [Figure 10] FIG. 1 is a diagram of an exemplary environment for upscaling an O-CU.

[0031] [Figure 11] FIG. 1 is a diagram of an exemplary environment for downscaling an O-CU.

[0032] [Figure 12] 10 shows a table illustrating the resource status of a vCU server in an O-cloud computing environment. DETAILED DESCRIPTION OF THE INVENTION

[0033] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which 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 implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Moreover, one or more features or components of one embodiment may be incorporated into or combined with other embodiments (or one or more features of other embodiments). Additionally, in the flowcharts and descriptions of operations provided below, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may occur (at least partially) concurrently, and the order of one or more operations may be rearranged.

[0035] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will 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 herein, these combinations do not limit the disclosure of possible implementations. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0037] No element, act, or instruction used herein should be construed as critical or required unless explicitly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc. are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0038] Exemplary embodiments of the present disclosure provide a modular application (rApp) that is hosted in a Radio Access Network (RAN) Intelligent Controller (RIC) and provides auto-scaling of the O-CU that considers both traffic utilization indicators and the underlying hardware resources of the O-Cloud infrastructure in which the O-CU is deployed to determine where to scale the O-CU across the network topology. As a result, the rApp-based O-CU auto-scaling according to exemplary embodiments can decide to scale up the O-CU in different data centers based on the resource conditions of the data centers, so that a sudden traffic surge does not result in resource shortages in a single data center.

[0039] The rApp according to an exemplary embodiment calculates or determines how many new application instantiations or resources are required taking into account O-CU performance indicators as well as cloud resources, and selects a cloud cluster on which to deploy the new application (e.g., O-CU control plane and / or user plane) instantiations.

[0040] Methods and apparatus according to example embodiments provide for a more balanced utilization of O-Cloud computing resources in an O-Cloud environment to enable an energy-efficient network.

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

[0042] User device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to 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 wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or similar device. In some implementations, user device 210 may receive information from and / or transmit information to 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, such that particular software components can be swapped in or out depending on particular needs. Thus, platform 220 may be easily and / or quickly reconfigured for different uses.

[0044] In some implementations, as shown, platform 220 may be hosted in a cloud computing environment 222. In particular, although the implementations described herein describe platform 220 as being hosted within cloud computing environment 222, in some implementations 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 that hosts platform 220. Cloud computing environment 222 can provide services, such as computing, software, data access, and storage, 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. As shown, cloud computing environment 222 can include a collection of computing resources 224 (collectively referred to as “computing resources 224” and individually referred to as “computing resource 224”).

[0046] Computing resources 224 include 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 resources 224 may host platform 220. Cloud resources may include compute instances running within computing resources 224, storage devices provided within computing resources 224, data transfer devices provided by computing resources 224, etc. In some implementations, computing resources 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 FIG. 2, computing resources 224 include 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 user device 210. Application 224-1 can eliminate the need for a software application to be installed and run on user device 210. For example, application 224-1 can include software associated with platform 220 and / or any other software that can be provided via cloud computing environment 222. In some implementations, one application 224-1 can send information to or receive information from one or more other applications 224-1 via virtual machine 224-2.

[0049] Virtual machine 224-2 includes a software-implemented machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 224-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which virtual machine 224-2 matches an actual 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 execute a single program and support a single process. In some implementations, virtual machine 224-2 may run on behalf of a user (e.g., user device 210) and manage the infrastructure of 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 computing resources 224. In some implementations, in the context of storage systems, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage such that the storage system can be accessed regardless of the physical storage or heterogeneous structure. The separation may allow administrators flexibility in how they manage the storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable optimization of storage usage, server consolidation, and / or performing non-disruptive file movements.

[0051] Hypervisor 224-4 can provide hardware virtualization technology that allows 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 systems and can manage the execution of the guest operating systems. Multiple instances of different operating systems can share virtualized hardware resources.

[0052] Network 230 may include one or more wired and / or wireless networks. For example, network 230 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, an optical fiber-based network, 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 an example. 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 arranged differently from 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 (e.g., one or more devices) of environment 300 may perform one or more functions that are described as being performed by another set of devices of environment 300.

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

[0055] The bus 310 includes components that enable communication between the components of the device 300. The processor 320 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 320 may 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 another type of processing component. In some implementations, the processor 320 includes one or more processors that can be programmed to perform functions. The memory 330 includes random access memory (RAM), 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 340 stores information and / or software related to the operation and use of the device 300. For example, the storage component 340 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 cartridge, a magnetic tape, and / or other type of non-transitory computer-readable medium, along with a corresponding drive. The input component 350 includes components that enable the device 300 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a 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 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] Communications interface 370 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 370 may enable device 300 to receive information from and / or provide information to another device. For example, communications 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 a non-transitory computer-readable medium, such as memory 330 and / or storage component 340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space across multiple physical storage devices.

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

[0060] Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more of the processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry 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, fewer, different, or differently arranged components than those shown in Figure 4. Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions that are described as being performed by another set of components of device 300.

[0062] In an embodiment, any one of the operations or processes of FIGS. 5-12 may be implemented by or using any one of the elements shown in FIGS.

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

[0064] That is, the O-CU is assigned to a specific topology within the O-RAN network. This topology location may be, for example, a data center. Such a data center houses the physical hardware server infrastructure that hosts the O-Cloud environment; more specifically, the data center houses at least one virtualized CU (vCU) server hosting virtual machines that run the O-CU applications of a vCU cluster. A vCU cluster may be hosted on at least one vCU server in at least one data center.

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

[0066] The physical host may, for example, host at least one O-CU node and / or a cluster of O-CU nodes of the O-RAN, where the O-CU node is an O-CU of the O-RAN network according to Figures 1 to 5 that runs O-CU applications in the O-Cloud Computing environment.

[0067] As shown in FIG. 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 obtain performance indicators (or key performance indicators (KPIs)) via the E2 interface. The set of performance indicators can 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 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 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 sub-interfaces 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 sub-interfaces for connecting to the C-plane and U-plane of the O-CU, respectively.

[0069] FIG. 6 illustrates an exemplary data center environment containing a vCU server hosting a cluster of O-CUs. At least one O-DU is connected to the O-CU. The O-DU includes baseband processing and can support one or more cells. This means that the location of the O-DU 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 topology hierarchy of the wireless network resulting from the locations of the radio antennas forming the cells. For example, a cell in Yokohama is wirelessly controlled by a vCU cluster hosted by at least one vCU server in the Yokohama data center. In this way, the O-Cloud environment is independent of network topology, but the data center hosting the vCU cluster has a predetermined geographic location based on the network topology in the real world.

[0070] A modular application (rApp) monitors the performance of each O-CU in the vCu cluster and controls and implements resource management policies based on performance indicators of the C-plane and U-plane applications of the O-CUs in each vCu cluster. For example, performance indicators for an O-CU UP may include at least one of the amount of traffic passing through the O-CU UP or the number of active devices connected to the O-CU. Performance indicators 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 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, for example, how much memory is used, processor load, how much hard disk drive space is 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 illustrates information flow according to one embodiment. Referring to Figure 6, performance indicators of 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 according to one embodiment via at least one of the E2, A1, and O2 interfaces. In one or more embodiments, the O-CU CP requests O-CU UP performance indicators from the O-CU UP and sends them to the rApp.

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

[0073] In step 702, the 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 threshold and the second threshold 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 O-CU to be scaled). The modular application (rApp) receives the resource state from the at least one physical host to house the O-Cloud computing resources that are ready to be allocated 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 regardless of the result of the comparison in step 702.

[0075] The resource state may include, for example, at least one of processor load, memory usage, hard disk drive usage, etc. of at least one physical host in the topology of the O-RAN network. Furthermore, the resource state may be pushed to the rApp (e.g., periodically or continuously) or pulled by the rApp (e.g., by periodic request, by event-triggered request (e.g., based on the threshold determination of step 702), etc.). By way of example, the resource state may be obtained from a "resource status request / response" information element (IE) conforming to 3GPP standards.

[0076] In step 704, the modular application (rApp) creates a 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 O-CU in at least one physical location within the O-Cloud computing environment based on the comparison (e.g., in step 702) and the evaluation (e.g., in step 703). By way of example, the decision to scale can be based on the comparison in step 702, and the decision of the server or data center location within the O-Cloud platform at which to instantiate the O-CU for each scaling can be based on the evaluation in step 703.

[0077] As an example, the Yokohama data center houses at least one vCU that servers host vCU cluster 01, as shown in Figure 5. When a sudden spike in connected / active user equipment (UE) or traffic occurs, a modular application (rApp) compares its performance indicators with one or more thresholds and evaluates the topological containment of the spike by using resource state metrics, i.e., "resource state request / response" IEs, based on the O-RAN network topology. In this case, if the performance indicator exceeds the threshold per comparison but the resource state evaluation (e.g., comparison with one or more resource thresholds against which the determination of hardware / cloud resource availability 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 can evaluate the resource state of other data centers to determine another data center with sufficient resource availability to scale up the O-CU. Here, the rApp can also consider other factors, such as location information, to determine a location for O-CU instantiation that would provide the shortest path for moving traffic.

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

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

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

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

[0082] For example, according to the upscaling flow of FIG. 8, if there is an unpredictable event that causes a sudden spike in UE traffic or any other factor that requires upscaling 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 may be a set of commands for allocating 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 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 in a location different from the location of the original O-CU.

[0083] If the vCU server hardware infrastructure resources reach their maximum level in the Yokohama data center, a modular application (rApp) retrieves and evaluates the resource status of the vCU servers hosting, for example, vCU Cluster 02 in Kawasaki or any other location next 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 vCU servers based on a predetermined perimeter around the location of Data Center 01 within the Yokohama area.

[0085] To this end, unused resources of vCU servers in data centers, particularly data centers located near Data Center 01, can be utilized 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 for instantiating a new O-CU application 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 the O-CU normally hosted in the Yokohama data center.

[0087] 9 shows a flowchart of a method 900 of creating a resource management policy for allocating O-Cloud computing resources to scale down an O-CU, according to one embodiment. Referring to FIG. 9, similar to step 701, a modular application (rApp) obtains performance indicators of O-RAN functions in step 901. In step 902, similar to step 702, the modular application (rApp) compares the performance indicators with a first threshold for downscaling. Here, 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 or have been allocated to the O-CU.

[0089] Similar to Figures 7 and 8, the resource status may be obtained, for example, by a "Resource Status Response" IE or other resource status that may include one of 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 for allocating O-Cloud computing resources of at least one physical host to one or more O-CU nodes based on the comparison (e.g., in step 902) and the evaluation (e.g., in step 903) to downscale the O-CU in at least one physical location within the O-Cloud computing environment.

[0091] As an example, an O-CU may be connected to a maximum of 18,000 UEs. The UEs are hosted in three separate pods, each configured to host 6000 UEs. If the O-CU is loaded with only 200 UEs (e.g., based on the comparison in step 902), two of the three pods will be terminated by the resource management policy.

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

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

[0094] In a further embodiment, the resource management policies may include policies for allocating pre-instantiated O-Cloud Computing resources. These resources may be, for example, pre-instantiated pods hosted on vCU servers. These pre-instantiated pods may be linked to the O-CU without having to execute resource management policies to instantiate new pods for additional O-CU applications. Linking pre-instantiated O-Cloud Computing resources saves instantiation time lag (e.g., approximately 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, which is energy efficient and enables 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 states to create resource management policies for terminating rich O-CU applications on an O-CU, regardless of the location of the physical host on which the rich O-CU is running. This means, for example, that an O-CU application on an O-CU in the Yokohama datacenter running on a vCU server in the Kawasaki datacenter will be terminated by the resource management policies in the same way as a rich O-CU application on an O-CU in the Yokohama datacenter.

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

[0098] 10 and 11 are diagrams of exemplary embodiments of "upscale operations" and "downscale operations," respectively, controlled and implemented by modular applications (rApps), according to one or more embodiments.

[0099] Referring to FIG. 10, a 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 pulled by the rApp (e.g., by periodic request, by event-triggered request (e.g., threshold determination), etc.). Based on the obtained performance indicators, the modular application (rApp) compares the performance indicators with thresholds to trigger a scaling request or command. In the case of FIG. 10, the request or command is a scale-up request. Furthermore, the modular application (rApp) obtains resource status from physical hosts in the O-RAN network topology. This may include the physical host(s) running the O-CU to be scaled and other physical host(s) that may be capable of accommodating additional O-CU applications of the O-CU. Furthermore, the modular application (rApp) obtains transport details, for example, to select a physical host with 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 transport details based on a comparison of performance indicators to thresholds.

[0100] 10, for example, the 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 from the O-DU, such as active UEs, UE traffic, data throughput, etc. Similarly, resource status can be obtained via 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, an 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] The performance indicators are varied and the list is not exhaustive. For example, the 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, traffic of each of the user functions 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, a KPI can be the traffic status of an O-CU U-plane application, for example, if the O-CU U-plane application is designed to carry ~6Gbps traffic for each microservice pod. In this case, a threshold can 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] Additionally, the performance indicators may include at least one system operation KPI, for example, the number of UEs connected to the O-CU U-plane pod and / or an O-CU internal system trigger overload threshold.

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

[0106] The resource state may include the most suitable location according to the O-RAN network topology, which may include, for example, a preferred location based on at least one of the hardware infrastructure capabilities of at least one vCU server, transfer speed, and traffic routing. Events for selecting a predetermined location of a data center are not limited to the above examples. Selecting a preferred physical location in the O-RAN network may include at least one of the most suitable location described above and / or a predetermined physical location of a mobile operator, for example, a specific location in case of a major disruption of O-cloud computing (e.g., a natural disaster, etc.).

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

[0108] 10 , the modular application (rApp) may include: comparing key performance indicators (KPIs) of each of the O-CU C-plane and U-plane with corresponding thresholds; obtaining and evaluating resource states; and instantiating only O-CU applications that need to be upscaled based on the comparison and evaluation. This means that, based on the compared performance indicators including the performance indicator of the O-CU control plane (CP), the resource management policy is for allocating O-Cloud computing resources to scale the O-CU CP; and, based on the compared at least one performance indicator including the performance indicator of the O-CU user plane (UP), the resource management policy is for allocating O-Cloud computing resources to scale the O-CU UP.

[0109] FIG. 11 illustrates a diagram of an exemplary embodiment of a "downscale operation" controlled and implemented by a modular application (rApp) according to an exemplary embodiment. Similar to FIG. 10, the modular application (rApp) obtains performance indicators of O-RAN network functions. Accordingly, the modular application (rApp) compares the performance indicators with a first threshold to trigger a termination request for the rich O-CU. Furthermore, the modular application (rApp) obtains the resource status of the rich O-CU and / or the resource status of the physical host housing the rich O-CU or a portion thereof. Based on the resource status and transport details of the physical host(s), which may be in different locations, the modular application (rApp) creates a resource management policy for terminating the rich O-CU.

[0110] 11 , a modular application (rApp) can create resource management policies, including 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 according to exemplary embodiments. 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] 11 , the modular application (rApp) may include selecting at least one of an O-CU C-plane application or an O-CU U-plane application, comparing a key performance indicator (KPI) of the application with a threshold, obtaining and evaluating a resource state, and terminating only the O-CU application that needs to be downscaled based on the comparison and evaluation. This means that, based on the compared performance indicators including a performance indicator of the O-CU control plane (CP), the resource management policy is for allocating O-Cloud computing resources to scale the O-CU CP, and based on the compared at least one performance indicator including a performance indicator of the O-CU user plane (UP), the resource management policy is for allocating O-Cloud computing resources to scale the O-CU UP.

[0112] 12 shows a table illustrating resource states of vCU servers in the O-cloud computing environment. The resource state for each vCU server may include the percentage of used cores out of the total number of available cores for each vCU server, the percentage of used cores out of the number of isolated cores for each vCU server, the percentage of used cores out of the number of dedicated cores for each 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 in the vCU cluster, and the operational status of the vCU server.

[0113] According to embodiments, an apparatus and method are provided for evaluating, controlling, and enforcing resource management control policies created by a modular application rApp hosted in a Radio Access Network (RAN) Intelligent Controller (RIC), where the policies implement scaling of an O-CU based on consideration of the resource state of the underlying cloud hardware resources. As a result, efficient scaling and operation of O-CU instantiations 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 disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

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

[0116] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: 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 disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or groove ridge structures having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), 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 fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A 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 for storage in a computer-readable storage medium in the respective computing / processing device.

[0118] The computer-readable program code / instructions for carrying out operations may be either source code or object-oriented programming languages 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 programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone 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 wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, an electronic circuit, including, for example, 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 the computer-readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0119] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, to produce a machine. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0120] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions, running on the computer, other programmable apparatus, or other device, implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0121] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than shown in the figures. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes 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 a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 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, comprising: a memory for storing instructions; and at least one processor within the SMO framework for implementing the RIC, the at least one processor comprising: receiving data from an Open RAN (O-RAN) Concentration Unit (O-CU) in an O-Cloud Computing environment, the data 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 resource status of at least one physical host in the O-cloud computing environment; creating a resource management policy for allocating O-Cloud computing resources of the at least one physical host to scale the O-CU in at least one physical location within the O-Cloud computing environment based on the comparison and the evaluation; configured to execute the instructions to 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 at least one processor receiving additional performance indicators of the O-CU; comparing the additional performance indicator of the O-CU to a second predetermined threshold; determining to scale down by terminating the additional O-CU based on the comparison; and and further configured to execute the instructions to:

10. The apparatus of 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 at least one performance indicator including a performance indicator of the O-CU CP; The apparatus of 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 at least one performance indicator including a performance indicator of the O-CU UP.

4. The apparatus of claim 3 , wherein the performance indicators of the O-CUP CP include a number of connected devices, and the performance indicators of the O-CU UP include an amount of traffic or a number of active devices.

5. The at least one processor 10. The apparatus of claim 1, further configured to execute the instructions to create the resource management policy based on location information of the at least one physical host to consider shortest paths for moving traffic based on available resources.

6. The at least one processor and further configured to execute the instructions to implement a fail-safe policy in which, based on the N O-CUs instantiated according to the resource management policy, a single additional redundancy is instantiated as a fail-safe for the N instantiated O-CUs.

10. The apparatus of claim 1.

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

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

9. 1. A method for implementing a resource control mechanism executed 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, comprising: receiving data from an Open RAN (O-RAN) Concentration Unit (O-CU) in an O-Cloud Computing environment, the data 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 resource status of at least one physical host in the O-cloud computing environment; creating a resource management policy for allocating O-Cloud computing resources of the at least one physical host to scale the O-CU in at least one physical location within the O-Cloud computing environment based on the comparison and the evaluation; A method comprising:

10. the resource management policy is for allocating O-Cloud computing resources to scale up the O-CU by instantiating additional O-CUs; The method comprises: receiving additional performance indicators of the O-CU; comparing the additional performance indicator of the O-CU to a second predetermined threshold; determining to scale down by terminating the additional O-CU based on the comparison; and The method of 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 at least one performance indicator including a performance indicator of the O-CU CP; 10. The method of 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 at least one performance indicator including a performance indicator of the O-CU UP.

12. The method of claim 9 , wherein the performance indicators of the O-CUP CP include the number of connected devices, and the performance indicators of the O-CU UP include the amount of traffic or the number of active devices.

13. generating the resource management policy 10. The method of claim 9, further comprising creating the resource management policy based on location information of the at least one physical host to consider shortest paths for moving traffic based on available resources.

14. 10. The method of claim 9, further comprising: 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.

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

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

17. 1. A non-transitory computer-readable storage medium within a service management and orchestration (SMO) framework for a telecommunications network, the non-transitory computer-readable storage medium having instructions executable by at least one processor to perform a method for implementing a resource control mechanism, The method comprises: receiving data from an Open RAN (O-RAN) Concentration Unit (O-CU) in an O-Cloud Computing environment, the data 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 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 in at least one physical location within the O-Cloud computing environment based on the comparison and the evaluation. A non-transitory computer-readable recording medium.

18. The method comprises: receiving additional performance indicators of the O-CU; comparing the additional performance indicator of the O-CU to a second predetermined threshold; determining to scale down by terminating the additional O-CU based on the comparison; and 20. The non-transitory computer-readable storage medium of claim 17, further comprising:

19. generating the resource management policy 20. The non-transitory computer-readable storage medium of claim 17, further comprising creating the resource management policy based on location information of the at least one physical host to consider a shortest path for moving traffic based on available resources.

20. 18. The non-transitory computer-readable storage medium of claim 17, wherein the resource management policy is for upscaling the O-CU by instantiating additional O-CUs on physical hosts in a data center different from the data center of the O-CU based on the assessed resource states of physical hosts in the data center of the O-CU.

Images