A system and method for shutting down O-Cloud nodes during idle time to conserve energy.

Abstract

A method and system for shutting down an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node is provided. The method includes receiving, by FOCOM, a first request to drain the O-Cloud node, where the first request is received from a user terminal or a non-real-time (Non-RT) RAN Intelligent Controller (RIC) based on an analysis of O2 telemetry data, sending, by FOCOM to an IMS via an O2 interface, a second request to drain the O-Cloud node based on the received first request, receiving, by FOCOM, a third request to shut down the drained O-Cloud node, where the third request is received from the user terminal or the Non-RT RIC, sending, by FOCOM, a fourth request to shut down the O-Cloud based on the received third request to the IMS, and receiving, from the IMS, a notification that the O-Cloud node has been shut down.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority based on Singapore Patent Application No. 10202204268W, filed with the Singapore Patent Office on April 22, 2022, the disclosure of which is incorporated herein in its entirety by reference.

[0002] Systems and methods consistent with exemplary embodiments of the present disclosure relate to draining and shutting down an open radio access network (O - RAN) cloud (O - Cloud) node during idle time to conserve energy consumption.

Background Art

[0003] A radio access network (RAN) is an important component in a telecommunication system as it connects 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 the core network. Conventionally, the hardware and / or software of a particular RAN is vendor - specific.

[0004] Open RAN (O-RAN) technology emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. For this purpose, O-RAN decomposes RAN functions into centralized units (CUs), distributed units (DUs), and radio units (RUs). A CU is a logical node for hosting the RAN's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. A DU is a logical node for hosting the RAN's Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers. An RU is a physical node that converts radio signals from antennas into digital signals that can be transmitted to the DU via the fronthaul. These entities, having open protocols and interfaces between them, can be developed by various vendors.

[0005] 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 divided into two types: non-real-time RIC (Non-RT RIC) and near-real-time RIC (Near-RT RIC).

[0006] Non-RT RICs are the control point of the non-real-time control loop and operate on a timescale of over one second within the Service Management and Orchestration (SMO) framework. Their functionality is implemented via modular applications called rApps (rApp1, ..., rApp N in Figure 1), which include providing policy-based guidance and augmentation across the A1 interface, which is an interface enabling communication between Non-RT RICs and Near-RT RICs; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions via the O1 interface, which is an interface connecting SMO to RAN managed elements (e.g., Near-RT RICs, O-RA centralized units (O-CUs), O-RAN distributed units (O-DUs), etc.).

[0007] Near-RT RICs operate on a timescale between 10 milliseconds and 1 second and connect to O-DUs, O-CUs (decomposed into O-CU control planes (O-CU-CP) and O-CU user planes (O-CU-UP)), and Open Evolved NodeBs (O-eNBs) via E2 interfaces. Near-RT RICs use E2 interfaces to control underlying RAN elements (E2 nodes / network functions (NF)) via a near real-time control loop. Near-RT RICs monitor, pause / abstain, override, and control E2 nodes (O-CUs, O-DUs, and O-eNBs) via policies. For example, Near-RT sets policy parameters for activated functions of E2 nodes. Furthermore, Near-RT RICs host xApps to implement features such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs collaborate to optimize O-RAN. For example, a Non-RT RIC provides policies, data, and AI / ML models to be executed and used by a Near-RT RIC for RAN optimization via the A1 interface, and the Near-RT RIC returns policy feedback (i.e., how the policies set by the Non-RT RIC are performing).

[0008] The SMO framework on which the Non-RT RIC resides manages and orchestrates RAN elements. Specifically, SMO includes Federated O-Cloud Orchestration and Management (FOCOM); Network Function Orchestrator (NFO) which manages virtual machine (VM)-based virtual network functions (VNFs) and container (i.e., instance)-based VNFs; and OAM as part of SMO which manages and orchestrates what is called the O-Ran Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes hosting the RIC, O-CUs, and O-DUs, supporting software components (e.g., operating systems and runtime environments), and SMO itself. In other words, SMO manages the O-Cloud from within. The O2 interface is the interface between 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). The O2 interface can also send O2 telemetry data to the SMO, such as O-Cloud configuration or arbitrary logical function data, energy consumption, node health status, etc.

[0009] E2 nodes (i.e., virtualized / containerized instances of network functions) are deployed (i.e., hosted) on the O-Cloud infrastructure (i.e., one or more O-Cloud nodes). However, if only a small number of network functions are deployed on O-Cloud or during idle time, these network functions may be deployed across multiple nodes, and multiple unused (idle) nodes may be in a normal or full-power state and therefore consuming a relatively large amount of energy. [Overview of the project] [Means for solving the problem]

[0010] According to the embodiment, a system and method are provided for draining and shutting down one or more O-Cloud nodes in the O-Cloud infrastructure of a telecommunications network, the draining of one or more O-Cloud nodes is based on determining and analyzing the performance of at least one O-Cloud node, or at least one virtual network function hosted thereon. When the system and method receives a request to drain at least one O-Cloud node, it prepares to process the drain request within the SMO and to request the IMS to control the implementation of the drain request, the IMS controls the O-Cloud infrastructure to drain at least one O-Cloud node and report the state of the drained O-Cloud node to the SMO. The drained at least one O-Cloud node can then be shut down to save energy. Monitoring and analyzing O2 telemetry data of the O-Cloud infrastructure has the advantage that O-Cloud nodes can be drained and shut down during idle time to provide more energy-efficient O-RAN functionality.

[0011] According to one embodiment, a method for shutting down an open radio access network (O-RAN) cloud (O-Cloud) node includes receiving a first request by FOCOM (Federated O-Cloud Orchestration and Management) to drain the O-Cloud node, the first request being received from a user terminal or a non-real-time (Non-RT) RAN intelligent controller (RIC) based on analysis of O2 telemetry data; sending a second request by FOCOM to the Infrastructure Management Service (IMS) via the O2 interface to drain the O-Cloud node based on the received first request; receiving a third request by FOCOM to shut down the drained O-Cloud node, the third request being received from a user terminal or a Non-RT RIC; sending a fourth request by FOCOM to the IMS via the O2 interface to shut down the O-Cloud node based on the received third request; and receiving a notification from the IMS that the O-Cloud node has been shut down.

[0012] According to one embodiment, a system for shutting down an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node includes at least one first memory storing a first instruction and at least one processor implementing FOCOM, wherein the at least one processor is configured to execute the stored first instruction and receive a first request to drain an O-Cloud node, the first request being received from a user terminal or a non-real-time (Non-RT) RAN intelligent controller (RIC) based on an analysis of O2 telemetry data; send a second request to an Infrastructure Management Service (IMS) via the O2 interface to drain an O-Cloud node based on the received first request; receive a third request to shut down the drained O-Cloud node, the third request being received from a user terminal or a Non-RT RIC; send a fourth request to an IMS via the O2 interface to shut down an O-Cloud node based on the received third request; and receive a notification from the IMS that the O-Cloud node has been shut down.

[0013] According to one embodiment, at least one non-transient computer-readable recording medium records instructions executable by at least one processor for executing a method for shutting down an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, the method comprising: receiving a first request by FOCOM (Federated O-Cloud Orchestration and Management) to drain an O-Cloud node, the first request being received from a user terminal or a non-real-time (Non-RT) RAN intelligent controller (RIC) based on an analysis of O2 telemetry data; sending a second request by FOCOM to the Infrastructure Management Service (IMS) via the O2 interface to drain an O-Cloud node based on the received first request; and receiving a third request by FOCOM to shut down the drained O-Cloud node, the third request being received from a user terminal or a Non-RT This includes receiving from the RIC, sending a fourth request to the IMS via the O2 interface via FOCOM to shut down the O-Cloud node based on the received third request, and receiving notification from the IMS that the O-Cloud node has been shut down.

[0014] Further embodiments are partially described below, partially apparent from the description, or may be realized by the practice of the embodiments presented in this disclosure.

[0015] Features, aspects, and advantages of specific exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which similar reference numerals indicate similar elements. [Brief explanation of the drawing]

[0016] [Figure 1] This diagram shows an O-RAN architecture using conventional technology. [Figure 2]This is a flowchart of a method for draining and shutting down an O-Cloud node using an O2 interface between FOCOM and O-Cloud, according to one embodiment. [Figure 3] This is a diagram of an exemplary environment in which the system described herein can be implemented for draining and shutting down O-Cloud nodes according to one embodiment. [Figure 4] This is a diagram of an exemplary environment in which the system described herein can be implemented for the drain procedure of an O-Cloud node according to one embodiment. [Figure 5] This is a diagram of an exemplary environment in which the systems and / or methods described herein can be implemented. [Figure 6] This is a diagram of an exemplary component of a device according to one embodiment. [Modes for carrying out the invention]

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

[0018] The foregoing disclosures are illustrative and illustrative, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and alterations are possible in light of the foregoing disclosures, or may be derived from implementation practice. 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 will be understood that in the flowcharts and operation descriptions provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be changed.

[0019] It will be apparent that the systems and / or methods described herein may be implemented in various forms, such as hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limiting to the implementation. 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.

[0020] Certain combinations of features are described in the claims and / or disclosed herein, but these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically described in the claims and / or disclosed in the specification. Each dependent claim listed below may directly depend on only one claim, but in the disclosure of possible implementations, each dependent claim is included in combination with all the other claims in the set of claims.

[0021] Elements, operations, or instructions used in this specification should not be construed as important or essential unless explicitly described. Also, as used in this specification, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the term "one" or a similar term is used. Also, as used in this specification, terms such as "has," "have," "having," "include," "including," etc. are intended to be non-limiting terms. Further, the phrase "based on" is intended to 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 to include only A, only B, or both A and B.

[0022] Exemplary embodiments of the present disclosure provide a method and system for draining and shutting down O-Cloud nodes during idle time to save energy consumption. In particular, when there are few network functions deployed on O-Cloud, the network function placement is optimized for limited O-Cloud nodes on O-Cloud, and the remaining O-Cloud nodes can be shut down and relocated to save energy consumption during O-Cloud node idle time.

[0023] FIG. 2 is a flowchart of a method for draining and shutting down an O-Cloud node using an O2 interface between FOCOM and O-Cloud according to an embodiment. The method of FIG. 2 (at least operations 202-206) is executed by FOCOM.

[0024] Referring to FIG. 2, the drain and shutdown of the O-Cloud node may be initiated at 201 by the user via a user terminal (e.g., including an application for managing network functions and / or subscribed to receive alarm events, notifications, etc. from the SMO), or by one or more rApps of the Non-RT RIC within the SMO. The components of the O-RAN architecture in FIGS. 2, 3, and 4 are the same as those according to FIG. 1.

[0025] As shown in FIGS. 2, 3, and 4, prior to the initiation of the drain and shutdown of the O-Cloud node, the availability of the SMO and the availability of the O-Cloud are assumed. Further, the Non-RT RIC or the aforementioned user terminal is configured to receive notifications from the SMO and subscribe to receive O2-IMS alarm event notifications. Thus, the Non-RT RIC and / or the user terminal (e.g., an application installed on the user terminal) can receive and analyze O2 telemetry data to determine the O-Cloud node for hardware drain and hardware shutdown.

[0026] According to one embodiment, the decision to drain and then shut down an O-Cloud node may be based on O2 data (or O2 telemetry data) received via the O2 interface, such as O-Cloud configuration information (e.g., single node or cluster, number of microservices or network functions running on each node), energy consumption (e.g., CPU load, power consumption), and hardware usage (e.g., memory usage). According to another embodiment, the decision to drain and then shut down an O-Cloud node may be based on both O2 data and O1 data (or O1 telemetry data) received via the O1 interface, such as traffic data (or traffic pattern data), physical resource block (PRB) usage, and the number of users. For example, the decision may be based on a prediction of the number of microservices or network functions required over a subsequent predetermined period (e.g., the next hour), and a policy may be generated accordingly. In operation 201, a user (via an application running on the user terminal), an application within the user terminal, or an rApp within the Non-RT RIC decides and requests to drain one or more O-Cloud nodes based on the received O2 and / or O1 data (for example, based on that analysis). The request (or service request) is sent from the user terminal or Non-RT RIC to FOCOM and includes the identifier of each O-Cloud node to be drained.

[0027] In operation 202, FOCOM receives a request (first request) to drain one or more O-Cloud nodes, and in operation 203, FOCOM requests IMS to drain one or more O-Cloud nodes based on the received first request (second request). Here, FOCOM may request IMS to drain one or more O-Cloud nodes via the O2 interface, for example using the O2ims service. Operation 203 may be looped or executed repeatedly for each of the one or more O-Cloud nodes identified in the first request. Furthermore, FOCOM may determine the order in which to drain one or more O-Cloud nodes according to predetermined criteria or randomly, and may send corresponding second requests to one or more O-Cloud nodes according to this determined order. FOCOM may then receive a status update notification from IMS indicating the status of the drain request, for example, indicating that the drain is complete. Here, user terminals (i.e., applications installed therein) and / or Non-RT RICs (i.e., rApps) may also receive status update notifications.

[0028] In operation 204, FOCOM receives a request (third request) to shut down one or more O-Cloud nodes drained from a user terminal or Non-RT RIC (i.e., rApp), and in operation 205, FOCOM requests IMS to shut down one or more O-Cloud nodes based on the received third request (fourth request). The third request may include identifiers of the one or more O-Cloud nodes to be shut down. Operation 205 may be looped or executed repeatedly for each of the one or more O-Cloud nodes to be shut down. Furthermore, FOCOM may determine an order for shutting down one or more O-Cloud nodes according to a predetermined criterion or randomly, and may send a corresponding fourth request to one or more O-Cloud nodes according to this determined order.

[0029] In operation 206, FOCOM receives notification from IMS that one or more O-Cloud nodes have been shut down. User terminals (i.e., applications installed therein) and / or Non-RT RICs (i.e., rApps) may also receive this notification.

[0030] Figure 3 shows a detailed method for implementing the drain procedure for an O-Cloud node according to one embodiment. The method in Figure 3 is performed by a user terminal (i.e., the application installed therein) and / or a Non-RT RIC (rApp), as well as FOCOM and IMS.

[0031] Referring to Figure 3, the method for implementing the drain procedure 300 of the O-Cloud node may be triggered by or based on input from the O2 interface (e.g., O2 telemetry data). According to another embodiment, the method can consider both O2 telemetry data received via the O2 interface and O1 telemetry data received via the O1 interface.

[0032] A user, the application installed on the user terminal, or a Non-RT RIC (rApp) analyzes the received O2 telemetry data and / or O1 telemetry data and decides whether to drain and shut down the O-Cloud node based on that analysis. For example, telemetry data indicating idle status or a small number of instantiated network functions may be determined as grounds for draining and shutting down the O-Cloud node. In an exemplary embodiment, the analysis may include a comparison of at least one key performance indicator (KPI) relating to the performance of the O-Cloud node with a corresponding threshold. Based on the comparison, the user terminal or Non-RT RIC (e.g., one or more rApps of a Non-RT RIC) decides whether to drain and shut down the O-Cloud node.

[0033] In operation 301, the user terminal or Non-RT RIC sends a first request to FOCOM to drain the O-Cloud node that has been determined to be shut down, as described above. The first request may include the identifier of the O-Cloud node.

[0034] In operation 302, FOCOM receives a first request from the Non-RT RIC or user terminal to drain an O-Cloud node.

[0035] In operation 303, FOCOM via the O2 interface sends a second request to IMS to drain an O-Cloud node based on the first request it received.

[0036] In operation 304, IMS drains each specified node. For this purpose, IMS can determine whether any network functions (NFs) deployed on a particular O-Cloud node that is to be drained and shut down should be redeployed to another node, or can simply be terminated without redeployment. If the NFs are still needed, IMS controls the redeployment of the NFs to another O-Cloud node that should not be shut down and notifies FOCOM, Non-RT RIC, and / or user terminals (applications) of the redeployment.

[0037] In operation 305, in an exemplary embodiment, the IMS sends a notification to the FOCOM via the O2 interface acknowledging the completed drain procedure. The IMS may also (or instead) send notifications to the Non-RT RIC (rApp) and / or user terminal (application), for example, based on whether they are subscribed to notifications from the IMS.

[0038] Figure 4 shows a detailed method for implementing the O-Cloud node shutdown procedure 400 according to one embodiment. The method in Figure 4 is performed by a user terminal (i.e., the application installed therein) and / or Non-RT RIC (rApp), as well as FOCOM and IMS.

[0039] Referring to Figure 4, in operation 401, the user terminal (application) or Non-RT RIC (rApp) requests FOCOM to shut down the O-Cloud node (third request).

[0040] In operation 402, FOCOM receives a third request to shut down the O-Cloud node. The request may be sent via the O2 interface.

[0041] In operation 403, FOCOM sends a fourth request to IMS to shut down the specified O-Cloud node.

[0042] In operation 404, IMS shuts down the specified O-Cloud node based on the fourth request, where the O-Cloud node has been drained beforehand using the method shown in Figure 3.

[0043] In operation 405, IMS sends a notification to FOCOM via the O2 interface acknowledging the completion of the shutdown procedure. IMS may also (or instead) send notifications to Non-RT RIC(rApp) and / or user terminals (applications), for example, based on whether they are subscribed to notifications from IMS.

[0044] Figure 5 is a diagram of an exemplary environment 500 in which the system and / or method described herein may be implemented. As shown in Figure 5, the environment 500 may include a user device 510, a platform 520, and a network 530. The devices in environment 500 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described above with reference to Figures 2 to 4 may be performed by any combination of the elements shown in Figure 5.

[0045] The user device 510 includes one or more devices that can receive, generate, store, process, and / or provide information related to the platform 520. For example, the user device 510 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 510 may receive information from and / or transmit information to the platform 520.

[0046] Platform 520 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 520 may include a cloud server or a group of cloud servers. In some implementations, Platform 520 may be designed modularly so that specific software components can be swapped in or out according to specific needs. Thus, Platform 520 can be easily and / or quickly reconfigured for various applications.

[0047] In some implementations, as shown in the figures, platform 520 may be hosted in a cloud computing environment 522. In particular, the implementations described herein are described with platform 520 hosted in a cloud computing environment 522, but in some implementations, platform 520 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment) or may be partially cloud-based.

[0048] The cloud computing environment 522 includes an environment that hosts platform 520. The cloud computing environment 522 can provide services such as computing, software, data access, and storage that do not require end-user (e.g., user device 510) knowledge of the physical location and configuration of the system and / or device hosting platform 520. As shown in the diagram, the cloud computing environment 522 may include a group of computing resources 524 (collectively referred to as "computing resources 524" or individually as "computing resources 524").

[0049] Computational resources 524 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 524 can host platform 520. Cloud resources may include computing instances running on computing resources 524, storage devices provided on computing resources 524, and data transfer devices provided by computing resources 524. In some implementations, computing resources 524 can communicate with other computing resources 524 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0050] As further shown in Figure 5, the computing resource 524 includes a group of cloud resources such as one or more applications ("APP") 524-1, one or more virtual machines ("VM") 524-2, virtualized storage ("VS") 524-3, and one or more hypervisors ("HYP") 524-4.

[0051] Application 524-1 includes one or more software applications that are provided to or can be accessed by the user device 510. Application 524-1 can eliminate the need to install and run software applications on the user device 510. For example, Application 524-1 may include any other software that can be provided through the software associated with the platform 520 and / or the cloud computing environment 522. In some implementations, one application 524-1 can send and receive information to and from one or more other applications 524-1 via a virtual machine 524-2.

[0052] A virtual machine 524-2 includes a software implementation of a machine (e.g., a computer) that runs programs like a physical machine. Depending on the use and degree of correspondence between the virtual machine 524-2 and any physical machine, the virtual machine 524-2 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 524-2 can run on behalf of a user (e.g., a user device 510) and manage the infrastructure of a cloud computing environment 522, such as data management, synchronization, or long-term data transfer.

[0053] Virtualized storage 524-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of the compute resource 524. In some implementations, within the context of a storage system, the types of virtualization can include block virtualization and file virtualization. Block virtualization can refer to extracting (or separating) logical storage from physical storage so that the storage system can be accessed regardless of whether it is physical storage or a heterogeneous structure. Separation gives storage system administrators flexibility in how to manage 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 can enable optimization of storage usage, server consolidation, and / or performance of non-disruptive file movement.

[0054] Hypervisor 524-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 524. Hypervisor 524-4 can present a virtual operating platform to guest operating systems and manage the execution of guest operating systems. Multiple instances of various operating systems can share virtualized hardware resources.

[0055] Network 530 includes one or more wired and / or wireless networks. For example, Network 530 may include cellular networks (e.g., 5G networks, long-term evolution (LTE) networks, 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, and / or combinations of these or other types of networks.

[0056] The number and arrangement of devices and networks shown in Figure 5 are provided as an example. In practice, there may be more 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 5. Furthermore, two or more devices shown in Figure 5 may be implemented within a single device, or a single device shown in Figure 5 may be implemented as multiple distributed devices. In addition, or instead, a set of devices in environment 500 (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 500.

[0057] Figure 6 shows an exemplary component of device 600. Device 600 may correspond to user device 510 and / or platform 520. As shown in Figure 6, device 600 may include a bus 610, a processor 620, memory 630, storage component 640, input component 650, output component 660, and communication interface 670.

[0058] Bus 610 includes components that enable communication between components of device 600. Processor 620 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 620 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other types of processing components. In some implementations, processor 620 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 other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions for use by the processor 620.

[0059] The storage component 640 stores information and / or software related to the operation and use of device 600. For example, the storage component 640, along with a corresponding drive, may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact discs (CDs), digital versatile discs (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-temporary computer-readable media. The input component 650 includes components that enable device 600 to receive information via user input (e.g., touchscreen displays, keyboards, keypads, mice, buttons, switches, and / or microphones). In addition, or instead, the input component 650 may include sensors for sensing information (e.g., global positioning system (GPS) components, accelerometers, gyroscopes, and / or actuators). The output component 660 includes components that provide output information from the device 600 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0060] The communication interface 670 includes transceiver-like components (e.g., transceivers and / or separate receivers and transmitters) that enable device 600 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 670 can also enable device 600 to receive information from and / or provide information to other devices. For example, the communication interface 670 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.

[0061] Device 600 can perform one or more processes described herein. Device 600 can perform these processes in response to the processor 620 executing software instructions stored in a non-temporary computer-readable medium, such as memory 630 and / or storage component 640. 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 that extends across multiple physical storage devices.

[0062] Software instructions may be read into memory 630 and / or storage component 640 from another computer-readable medium or from another device via the communication interface 670. When executed, the software instructions stored in memory 630 and / or storage component 640 can cause the processor 620 to execute one or more processes described herein.

[0063] In addition, or instead, hardwired circuits may be used in place 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.

[0064] The number and arrangement of components shown in Figure 6 are provided as an example. In practice, device 600 may include more components, fewer components, different components, or components in different arrangements compared to the device shown in Figure 6. In addition, or instead, a set of components of device 600 (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 600.

[0065] In the embodiments, any of the actions or processes shown in Figures 2, 3, and 4 may be carried out by or using any one of the elements shown in Figures 5 and 6. Other embodiments are not limited thereto and can be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, or OpenStack).

[0066] According to exemplary embodiments, energy savings are achieved by draining and shutting down O-cloud nodes during idle time. For example, if there are only a few network functions deployed or that need to be deployed on the O-Cloud, the network function placement on the O-Cloud is optimized for the limited number of O-Cloud nodes, and the remaining O-Cloud nodes are shut down to conserve energy consumption during O-Cloud node idle time. O-Cloud resources can also be drained to move network functions to other O-Cloud nodes. The foregoing disclosures are illustrative and explanatory, but are not intended to be exhaustive or to limit implementations to the exact form disclosed. Modifications and alterations are possible in light of the foregoing disclosures, or may be derived from implementation practices.

[0067] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail relating to integration. Furthermore, one or more of the above components may be implemented as instructions stored in computer-readable media and executable by at least one processor (and / or include at least one processor). The computer-readable media may include computer-readable non-temporary storage media (or more) having computer-readable program instructions for causing a processor to perform an action.

[0068] 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, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, 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 punched cards or grooved raised structures with instructions recorded inside, and any suitable combination of the above. The computer-readable storage media used herein should not be interpreted 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.

[0069] The computer-readable program instructions described herein can be downloaded to each computing / processing device from a computer-readable storage medium or from 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 the respective computing / processing device.

[0070] The computer-readable program code / instructions for performing an operation may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or integrated circuit configuration data, or it may be source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed 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 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) can execute computer-readable program instructions by personalizing the electronic circuit using state information of computer-readable program instructions in order to perform an action or operation.

[0071] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device in order to produce a machine, and as a result, instructions executed via the processor of the 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. 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 storing the instructions includes a product containing instructions that implements modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0072] These computer-readable program instructions can also be loaded into a computer, other programmable device, or other device to cause a series of operational steps to be performed on the computer, other programmable device, or other device, thereby generating a computer implementation process in which the instructions executed on the computer, other programmable device, or other device implement the functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0073] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media in various embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice, module, segment, or part of an instruction set, comprising one or more executable instructions that implement a specified logical function. The methods, computer systems, and computer-readable media may include more blocks, fewer blocks, different blocks, or blocks in different arrangements than 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 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, as well as any combination of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0074] It will be apparent that the systems and / or methods described herein may be implemented in various forms, such as hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limiting to the 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 method for shutting down an Open Radio Access Network (O-RAN) Cloud node, FOCOM (Federated O-Cloud Orchestration and Management) receives a first request to drain an O-Cloud node, the first request being received from a user terminal or from a non-real-time (Non-RT) RAN intelligent controller (RIC) based on an analysis of O1 and O2 telemetry data. The FOCOM transmits a second request to the Infrastructure Management Service (IMS) via the O2 interface to drain the O-Cloud node based on the first request it received, The FOCOM receives a third request to shut down the drained O-Cloud node, the third request being received from the user terminal or the Non-RT RIC. The FOCOM transmits a fourth request to the IMS via the O2 interface to shut down the O-Cloud node based on the received third request, A method comprising: receiving a notification from the IMS via the FOCOM that the O-Cloud node has been shut down.

2. The user terminal or the Non-RT RIC receives the O1 data and the O2 telemetry data, The user terminal or the Non-RT RIC decides to shut down the O-Cloud node based on the received O1 data and the received O2 telemetry data, The method according to claim 1, further comprising:

3. The method according to claim 2, wherein the determination includes receiving user input from the user terminal to shut down the O-Cloud based on the received O1 data and the received O2 telemetry data.

4. The above determination involves analyzing the received O1 data and the received O2 telemetry data using the Non-RT RIC, The Non-RT RIC determines, based on the received O1 data and the received O2 telemetry data, to shut down the O-Cloud node, The method according to claim 2.

5. Based on the second requirement, the IMS is controlled to drain the O-Cloud node, The IMS further includes controlling the drained O-Cloud node to shut down based on the fourth request, The method according to claim 1.

6. The IMS further includes controlling the relocation of network functions deployed on the O-Cloud node to another O-Cloud node. The method according to claim 5.

7. The further includes receiving notification from the IMS, via at least one of the FOCOM and the Non-RT RIC, that the O-Cloud node has been drained. The method according to claim 1.

8. A system for shutting down an Open Radio Access Network (O-RAN) Cloud node, A first memory for storing a first instruction, A system including at least one first processor implementing FOCOM (Federated O-Cloud Orchestration and Management), The at least one first processor executes the stored first instruction, Receiving a first request to drain an O-Cloud node, the first request being received from a user terminal or from a non-real-time (Non-RT) RAN intelligent controller (RIC) based on an analysis of O1 data and O2 telemetry data, Sending a second request to the Infrastructure Management Service (IMS) via the O2 interface to drain the O-Cloud node based on the first request received, Receiving a third request to shut down the drained O-Cloud node, the third request being received from the user terminal or from the Non-RT RIC, To send a fourth request to the IMS via the O2 interface to shut down the O-Cloud node based on the received third request, A system configured to receive a notification from the IMS that the O-Cloud node has been shut down.

9. A second memory for storing a second instruction, At least one second processor implementing the Non-RT RIC, which executes the second instruction, The O1 data and the O2 telemetry data are received, The received O1 data and the received O2 telemetry data are analyzed. The system further includes at least one second processor configured to determine which O-Cloud node should be shut down based on the received O1 data and the received O2 telemetry data. The system according to claim 8.

10. The system according to claim 8, wherein the first request is received from the user terminal based on user input to the user terminal for shutting down the O-Cloud node.

11. A third memory for storing a third instruction, At least one third processor that implements the IMS, which executes the third instruction, Based on the second request, control the O-Cloud node to drain, The system further includes at least one third processor configured to control the shutdown of the drained O-Cloud node based on the fourth request, The system according to claim 8.

12. The at least one third processor executes the third instruction, The system according to claim 11, configured to control the relocation of network functions deployed on the O-Cloud node to another O-Cloud node.

13. The at least one first processor executes the first instruction, The system according to claim 8, configured to receive notification from the IMS that an O-Cloud node has been drained.

14. At least one non-temporary computer-readable recording medium recording instructions that are executable by at least one processor for performing a method for shutting down an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, wherein the method is FOCOM (Federated O-Cloud Orchestration and Management) receives a first request to drain an O-Cloud node, the first request being received from a user terminal or a non-real-time (Non-RT) RAN intelligent controller (RIC) based on an analysis of O1 data and O2 telemetry data. The FOCOM transmits a second request to the Infrastructure Management Service (IMS) via the O2 interface to drain the O-Cloud node based on the first request it received, The FOCOM receives a third request to shut down the drained O-Cloud node, the third request being received from the user terminal or the Non-RT RIC. The FOCOM transmits a fourth request to the IMS via the O2 interface to shut down the O-Cloud node based on the received third request, A non-transient computer-readable recording medium comprising: receiving a notification from the IMS via the FOCOM that the O-Cloud node has been shut down; and at least one non-transient computer-readable recording medium.

15. The method includes receiving the O1 data and the O2 telemetry data via the user terminal or the Non-RT RIC, The user terminal or the Non-RT RIC further determines, based on the received O1 data and the received O2 telemetry data, to shut down the O-Cloud node. The at least one non-temporary computer-readable recording medium according to claim 14.

16. The determination described above includes the user terminal receiving user input to shut down the O-Cloud based on the received O1 data and the received O2 telemetry data, for at least one non-temporary computer-readable recording medium according to claim 15.

17. The above decision is, The Non-RT RIC analyzes the received O1 data and the received O2 telemetry data, The Non-RT RIC determines, based on the received O1 data and the received O2 telemetry data, to shut down the O-Cloud node, The at least one non-temporary computer-readable recording medium according to claim 16.

18. The method involves the IMS controlling the draining of the O-Cloud node based on the second request, The IMS further includes controlling the drained O-Cloud node to shut down based on the fourth request, The at least one non-temporary computer-readable recording medium according to claim 15.

19. The method further includes controlling the IMS to relocate network functions deployed on the O-Cloud node to another O-Cloud node. The at least one non-temporary computer-readable recording medium according to claim 18.

20. The method further includes receiving notification from the IMS, by at least one of the FOCOM and the NRT RIC, that the O-Cloud node has been drained. The at least one non-temporary computer-readable recording medium according to claim 19.

Images