Unblocking O-CLOUD node

Abstract

The method includes receiving a request to change a deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, changing the deployable state of the O-Cloud node in response to receiving the request, and sending an indication that the deployable state of the O-Cloud node has been modified in response to changing the deployable state.

Description

[Technical field]

[0001] This application claims priority to Singapore Provisional Patent Application No. 10202250829N, filed in the Singapore Patent Office on August 25, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Systems, methods, and apparatus consistent with example embodiments of the present disclosure relate to Open Radio Access Networks (O-RAN), and more specifically, to systems, methods, and apparatus used to uncordon one or more O-RAN Cloud nodes. [Background technology]

[0003] Prior to the development of O-RAN technology, radio access networks (RANs) used “closed” systems that relied on proprietary interfaces between radio and baseband units, which limited the ability of service providers to diversify their radio and baseband unit vendors. To provide wireless services to their customers, service providers were required to select a specific vendor and make significant investments in that vendor’s equipment. Changing from one vendor to another was a burdensome and often prohibitively expensive option for service providers. These inhibiting factors created barriers to entry for new vendors, thereby allowing incumbents to maintain high prices that were ultimately borne by the service provider’s customers. Additionally, service providers that are heavily reliant on a single supplier may be exposed to cybersecurity risks associated with potential security breaches to that supplier’s software.

[0004] O-RAN technology has "opened up" these previously appropriate interfaces and protocols, thereby giving service providers more choice in vendors, greater flexibility in deployment options, and new capabilities such as automation, analytics, and network slicing. O-RAN technology removes barriers to entry, increases supplier competition, fosters innovation, enables rapid multi-vendor deployments, reduces capital costs for service providers (and therefore reduces costs for their customers), and reduces cybersecurity risks.

[0005] Despite these advantages of O-RAN technology, there are problems with the related O-RAN technology, especially the current O-RAN technology cannot provide an efficient way to unblock O-Cloud nodes.

[0006] Improvements are presented herein to address such deficiencies, which may also be applicable to other technologies and telecommunications standards that use these technologies. Summary of the Invention

[0007] The following presents a simplified summary of one or more embodiments of the present disclosure in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all possible embodiments, and is not intended to identify key or critical elements of all embodiments or to delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments of the present disclosure in a simplified form as a prelude to the more detailed description that is presented later.

[0008] According to an example embodiment, a method includes receiving a request to change a deployable state of an O-Cloud node. The method includes changing the deployable state of the O-Cloud node in response to receiving the request. The method further includes sending an indication that the deployable state of the O-Cloud node has been modified in response to changing the deployable state.

[0009] According to an example embodiment, a method includes sending a request to change a deployable state of an O-Cloud node, the request causing the deployable state of the O-Cloud node to change from a cordoned state, in which the O-Cloud node is unable to deploy at least one of an application, a workload, or a network function, to an uncordoned state, in which the O-Cloud node is able to deploy at least one of an application, a workload, or a network function.

[0010] According to an example embodiment, an apparatus in an Open Radio Access Network (O-RAN), the apparatus includes at least one memory configured to store computer program code, and at least one processor configured to access the at least one memory and operate as instructed by the computer program code. The computer program code includes a receiving code configured to cause at least one of the at least one processor to receive a request to change a deployable state of an O-Cloud node. The computer program code includes a modifying code configured to cause at least one of the at least one processor to modify the deployable state of the O-Cloud node in response to receiving the request. The computer program code further includes a transmitting code configured to cause at least one of the at least one processor to transmit an indication that the deployable state of the O-Cloud node has been modified in response to modifying the deployable state.

[0011] Additional embodiments will be set forth in the description that follows, and in part will be obvious from the description, and / or may be learned by practice of the illustrated embodiments of the present disclosure. [Brief description of the drawings]

[0012] The above and other aspects, features, and modes of embodiments of the present disclosure will become apparent from the following description taken in conjunction with the accompanying drawings. [Figure 1] FIG. 2 is a diagram of an exemplary network device in accordance with various embodiments of the present disclosure. [Diagram 2] FIG. 1 is a schematic diagram of an example O-RAN communication system, in accordance with various embodiments of the present disclosure. [Diagram 3] FIG. 1 illustrates an O-RAN architecture, in accordance with various embodiments of the present disclosure. [Figure 4A] FIG. 1 illustrates an O-Cloud identification process according to various embodiments of the present disclosure. [Figure 4B]FIG. 1 illustrates an O-Cloud node unblocking process according to various embodiments of the present disclosure. [Diagram 5] 1 illustrates an example flowchart of an O-Cloud node unblocking process, according to various embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0014] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementation 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. Furthermore, one or more features or components of one embodiment may be incorporated in or combined with another embodiment (or one or more features of another embodiment). In addition, it is understood that in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be permuted.

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

[0016] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may 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.

[0017] No element, act, or instruction used herein should be construed as critical or required unless expressly 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." When only one item is intended, the term "one" or similar phrases are used. Also, as used herein, terms such as "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically 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 only A, only B, or both A and B.

[0018] Throughout this specification, reference to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Thus, throughout this specification, the phrases "in one embodiment," "in an embodiment," and similar language may, but do not necessarily, all refer to the same embodiment.

[0019] Moreover, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. In light of the description herein, one skilled in the art will recognize that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0020] Embodiments of the present disclosure are directed to systems, methods, and apparatus used to unblock one or more O-Cloud nodes. FIG. 1 is a diagram of an example device 100 for implementing the systems, methods, and apparatus of the present disclosure. The device 100 can implement any of the applications disclosed herein, as well as any O-RAN RIC, and any Artificial Intelligence / Machine Learning (AI / ML) framework. The device 100 may correspond to any type of known computer, server, or data processing device. For example, the device 100 may include a processor, a personal computer (PC), a printed circuit board (PCB) including a computing device, a minicomputer, a mainframe computer, a microcomputer, a telephone computing device, a wired / wireless computing device (e.g., a smartphone, a personal digital assistant (PDA)), a laptop, a tablet, a smart device, or any other similarly functional device.

[0021] In some embodiments, as shown in FIG. 1, device 100 may include a set of components, such as a processor 120, a memory 130, a storage component 140, an input component 150, an output component 160, and a communication interface 170.

[0022] Bus 110 may comprise one or more components that enable communication between a set of components of device 100. For example, bus 110 may be a communication bus, a crossover bar, a network, etc. Although bus 110 is shown in FIG. 1 as a single line, bus 110 may be implemented using multiple (two or more) connections between a set of components of device 100. The disclosure is not limited in this respect.

[0023] Device 100 may include one or more processors, such as processor 120. Processor 120 may be implemented in hardware, firmware, and / or a combination of hardware and software. For example, processor 120 may include 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), a general-purpose single-chip or multi-chip processor, or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. Processor 120 may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some embodiments, particular processes and methods may be performed by circuitry that is specific to a given function.

[0024] The processor 120 may control the overall operation of the device 100 and / or a set of components of the device 100 (eg, memory 130, storage components 140, input components 150, output components 160, and communication interface 170).

[0025] Device 100 may further comprise memory 130. In some embodiments, memory 130 may include random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory, magnetic memory, optical memory, and / or another type of dynamic or static storage device. Memory 130 may store information and / or instructions for use (e.g., execution) by processor 120.

[0026] Storage component 140 of device 100 may store information and / or computer-readable instructions and / or code related to the operation and use of device 100. For example, storage component 140 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 disc (CD), a digital versatile disc (DVD), a universal serial bus (USB) flash drive, a Personal Computer Memory Card International Association (PCMCIA) card, a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

[0027] Device 100 may further comprise input component 150. Input component 150 may include one or more components that enable device 100 to receive information via user input, etc. (e.g., a touch screen, a keyboard, a keypad, a mouse, a stylus, a button, a switch, a microphone, a camera, etc.) Alternatively or additionally, input component 150 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.).

[0028] Output components 160 of device 100 may include one or more components that may provide output information from device 100 (e.g., a display, a liquid crystal display (LCD), a light-emitting diode (LED), an organic light emitting diode (OLED), a haptic feedback device, a speaker, etc.).

[0029] Device 100 may further comprise a communication interface 170. Communication interface 170 may include a receiver component, a transmitter component, and / or a transceiver component. Communication interface 170 may enable device 100 to establish connections and / or transfer communications with other devices (e.g., a server, another device). The communications may occur via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 170 may enable device 100 to receive information from another device and / or provide information to another device. In some embodiments, communication interface 170 may provide communication with another device over a network, such as a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a private network, an ad-hoc network, an intranet, the Internet, an optical fiber based network, 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 telephone network (e.g., a Public Switched Telephone Network (PSTN)), etc., and / or a combination of these or other types of networks. Alternatively or additionally, the communication interface 170 may enable communication with another device via a device-to-device (D2D) communication link, such as FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi, LTE, 5G, etc.In other embodiments, communication interface 170 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, or the like.

[0030] The device 100 may be included in the core network 240 and may perform one or more processes described herein. The device 100 may perform operations based on the processor 120 executing computer-readable instructions and / or code that may be stored by a non-transitory computer-readable medium, such as the memory 130 and / or the storage component 140. A computer-readable medium may refer to a non-transitory memory device. A memory device may include memory space within a single physical storage device and / or memory space distributed across multiple physical storage devices.

[0031] Computer readable instructions and / or code may be loaded into memory 130 and / or storage component 140 from another computer readable medium or from another device via communications interface 170. The computer readable instructions and / or code stored in memory 130 and / or storage component 140, when executed by processor 120, may cause device 100 to perform one or more processes described herein.

[0032] Alternatively, or in addition, hardwired circuitry may be used in place of, or in combination with, software instructions to implement one or more processes described herein. Thus, the embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0033] The number and arrangement of components shown in Figure 1 are provided as an example. In practice, there may be additional, fewer, different, or differently arranged components than those shown in Figure 1. Furthermore, two or more of the components shown in Figure 1 may be implemented within a single component, or a single component shown in Figure 1 may be implemented as multiple distributed components. Additionally or alternatively, a set of components (one or more) shown in Figure 1 may perform one or more functions that are described as being performed by another set of components shown in Figure 1.

[0034] 2 illustrates an example O-RAN communications system 200 in accordance with various embodiments of the present disclosure. The O-RAN communications system 200 may include one or more user equipment (UE) 210, one or more O-RAN radio units (O-RU) 220 including one or more base stations 220a, one or more O-RAN distribution units (O-DU) 230, and one or more O-RAN centralized units (O-CU) 240.

[0035] Examples of UE 210 may include a cellular phone, a smartphone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system (GPS), a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similarly functioning device. Some of the one or more UEs 210 may be referred to as Internet-of-Things (IoT) devices (e.g., a parking meter, a gas pump, a toaster, a vehicle, a heart monitor, etc.). One or more UEs 210 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a radio unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile agent, a client, or some other suitable terminology.

[0036] One or more base stations 220A of the O-RU 220 may wirelessly communicate with one or more UEs 210. Each base station of the one or more base stations 220A may provide communication coverage to one or more UEs 210 located within the geographic coverage area of ​​that base station 220A. In some embodiments, as shown in FIG. 2, the base station 220A may transmit one or more beamformed signals to one or more UEs 210 in one or more transmit directions. The one or more UEs 210 may receive the beamformed signals from the base station 220A in one or more receive directions. Alternatively or additionally, the one or more UEs 210 may transmit beamformed signals to the base station 220 in one or more transmit directions. The base station 220A may receive the beamformed signals from the one or more UEs 210 in one or more receive directions.

[0037] The one or more base stations 220A may include macrocells (e.g., high-power cellular base stations) and / or small cells (e.g., low-power cellular base stations). Small cells may include femtocells, picocells, and microcells. The base station 220A, whether a macrocell or a large cell, may include and / or be referred to as an access point (AP), an evolved (or evolved universal terrestrial radio access network (E-UTRAN)) Node B (eNB), a next generation Node B (gNB), or any other type of base station known to one skilled in the art.

[0038] In some embodiments, the O-RU 220 may be connected to the O-DU 230 via an FH link 224. The FH link 224 may be a 25 Gbps line through which user plane (U-plane) and control plane (C-plane) packets are downloaded from the O-DU 230 to the O-RU 220. In some embodiments, the O-DU 230 may be connected to the O-CU 240 via a midhaul link 234. The O-CU 240 may include an O-CU control plane (O-CU-CP) packet generator 240A and an O-CU user plane (O-CU-UP) packet generator 240B. C-plane and U-plane packets may originate from the O-CU-CP packet generator 240A and the O-CU-UP packet generator 240B, respectively. These components enable a radio access network (RAN) of a telecommunications system to connect one or more UEs 210 to other parts of the network.

[0039] The O-RAN communication system 200 can decompose the RAN functions via the O-CU 240, the O-DU 230, and the O-RU 220. The O-CU 240 can be 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 O-DU 230 can be a logical node hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The O-RU 220 can be a physical node that converts radio signals from the antennas into digital signals that can be transmitted to the O-DU 230 via the "fronthaul".

[0040] FIG. 3 illustrates an example network architecture 300 that may be used in implementing the techniques described herein. The network architecture 300 may include, for example, an O-RU 320, an O-DU 330, an O-CU-CP 340A, an O-CU-UP 340B, and a service management and orchestration (SMO) 360. The RAN functions in the O-RAN architecture 300 may be controlled and optimized by one or more radio access network intelligent controllers (RICs). The RICs are software-defined components that implement modular applications and automate and optimize RAN operations to facilitate the multi-vendor operability required in the O-RAN system 300. The RICs are divided into two types: non-real-time RICs (NRT-RICs) 362 and near-real-time RICs (nRT-RICs) 350.

[0041] The NRT RIC 362 is the control point for non-real-time control loops and operates on time scales greater than one second within a Service Management and Orchestration (SMO) framework. Its functionality is implemented by modular applications called rApps. Functions include providing policies (i.e., sets of rules used to manage and control the change and / or maintenance of state of one or more managed objects) based on guidance and enrichment over the A1 interface, which is an interface that enables communication between the NRT-RIC 362 and the nRT-RIC 350. The A1 policies may be a type of declarative policy expressed using formal descriptions that enable the NRT-RIC 362 in the SMO 360 to guide the nRT-RIC 350, and therefore the RAN, towards better realization of the RAN intent; perform data analytics; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommend configuration management actions over the O1 interface to manage operation and maintenance (OAM) 368, which is the interface that connects the SMO 360 to the RAN managed elements (e.g., nRT-RIC 350, O-CU-CP 340A, O-CU-UP 340B, O-DU 330, etc.).

[0042] The nRT-RIC 350 sits at the edge of the RAN and operates on a timescale between 10 ms and 1 sec. The nRT-RIC 350 connects to the O-DU 330, O-CU-CP 340A, O-CU-UP 340B, and Open Evolved NodeB (O-eNB) (not shown) via the E2 interface. The nRT-RIC 350 uses the E2 interface to control the underlying RAN elements (E2 nodes / Network Functions (NFs)) via near real-time control loops. The nRT-RIC 350 monitors, pauses / stops, overrides, and controls the E2 nodes (O-CU-CP, O-CU-UP, O-DU, and O-eNB) via policies, and the O-DU connects to the O-RU 320 via a fronthaul that includes a Control User Synchronization (CUS) plane and a Management (M) plane. For example, the nRT sets policy parameters for activated functions of the E2 nodes. Additionally, the nRT-RIC 350 hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, etc. The two types of RICs work together to optimize O-RAN. For example, the NRT RIC 362 provides policies, data, and AI / ML models that are enforced and used by the nRT RIC 350 for RAN optimization over the A1 interface, and the nRT returns policy feedback (i.e., how the policies set by the NRT RIC 362 are performing).

[0043] The SMO 360 framework manages and orchestrates the RAN elements 363. Specifically, the SMO 360 includes a Federated O-Cloud Orchestration and Management (FOCOM) 364, a Network Function Orchestrator (NFO) 366 that manages Virtual Machines (VM)-based Virtual Network Functions (VNFs) (not shown) and Container (i.e., instance) (not shown)-based VNFs, and an OAM 368 as part of the SMO 360 that manages and orchestrates what is called the O-Ran Cloud (O-Cloud) 370. The O-Cloud 370 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 360 itself. In other words, the SMO 360 manages the O-Cloud 370 from within. The O2 interface is the interface between the SMO 360 and the O-Cloud 370 in which it resides. Through the O2 interface, the SMO 360 provides infrastructure management services (IMS) 372 and deployment management services (DMS) 374.

[0044] The NRT-RIC 362 may create a RAN optimization policy (i.e., an A1 policy for RAN optimization to satisfy the RAN intent). The NRT-RIC 362 may then pass the policy to the nRT-RIC 350 via an A1 interface (i.e., the A1 policy). Upon receiving the A1 policy, the nRT-RIC 350 may perform control to enforce the policy and execute in a control loop according to the policy.

[0045] As mentioned above, FIG. 3 provides an example system architecture 300 that may be used in implementing the techniques described herein. In particular, for example, when a node of the O-Cloud 370 requires any type of maintenance, a drain command and / or a shut-off command may be executed. The drain command may safely remove, evict, or transfer pods or instances from the node before maintenance is performed on the node. For example, the drain may remove all pods of the node (but there may be an exception of not removing "mirror pods"). After the drain command is executed on a particular node, the node may be said to be "shut-off". When a node is in a drained or shut-off state, the node may be up and running but unavailable for scheduling, deployment, instantiation, etc. of processes or pods. When a node is shut-off, new instances or pods cannot be created on the shut-off node, but maintenance (e.g., hardware maintenance such as changing a network interface card or adding physical memory hardware) can still be performed on the node. In some embodiments, when a node is shut-off, there may be a "taint" associated with such a node.

[0046] In some embodiments, the shutoff command can ensure that no new pods or instances are scheduled on the target node. That is, execution of the shutoff command can put the node in an unplannable or unschedulable state. The shutoff command can be used to ensure that no new pods or instances are scheduled on the target node. The target node can be placed in an unplannable or unschedulable state when the node is being prepared for maintenance. When the node is in an unplannable state, other commands can be used to move pods or instances off the target node so that maintenance can be performed on the node. In some embodiments, execution of the shutoff command removes all pods placed on the target node. In this way, the scheduler can list the removed pods / instances on the new node and / or the replacement node. In some embodiments, multiple nodes (e.g., node clusters) may be drained or shut down sequentially or simultaneously. In some embodiments, the node may be marked, flagged, or otherwise given some indicator that the node is in a drained / drained state or a shut down / shut down state.

[0047] After the maintenance on the node is completed, an unblocking command may enable scheduling of the node again. In some embodiments, after maintenance on a node is performed, the node must be unblocked so that the node can resume workload deployment on the node. After execution of the unblocking command for one or more nodes, pods or instances may be scheduled to such nodes, and pods or instances may be added or placed on such nodes. With reference to FIG. 3, SMO 360 may be used to unblock one or more O-Cloud nodes. The process of unblocking one or more O-Cloud nodes using SMO 360 may be triggered, initiated, or occur by either a manual process or an automatic process. After an O-Cloud node is unblocked, Network Functions (NF) deployment or application deployment may be resumed on the node. For example, one or more and / or one or more VNF deployments (and / or Physical Network Functions (PNF)) may be resumed on the unblocked node. In some embodiments, multiple nodes (e.g., a node cluster) may be unblocked consecutively or simultaneously. In some embodiments, some type of mark, flag, or other indicator may be added or removed to indicate that the node is in an unblocked or unblocked state.

[0048] 4A and 4B respectively illustrate the operations involved in an example O-Cloud decision process 402 and an example O-Cloud node unblocking process 404. As shown in FIG. 4A and 4B, there may be one or more personnel 410 (e.g., cloud maintainer 410), SMO 420, and O-Cloud platform 430. SMO 420 may include NRT-RIC 422 and FOCOM 424, and O-Cloud platform 430 may include IMS 432.

[0049] Prior to the O-Cloud determination process 402 and / or the O-Cloud node unblocking process 404, the system may execute one or more preliminary processes. For example, the system may execute a preliminary process to determine whether the SMO 420 and / or the O-Cloud platform 430 are available. In some embodiments, if a determination is made that the SMO 420 and the O-Cloud platform 430 are available (e.g., have sufficient computational resources accessible), the system proceeds to the O-Cloud determination process 402 and the O-Cloud node unblocking process 404. Alternatively, this process may be omitted and it may be assumed that the SMO 420 and the O-Cloud platform 430 are available. Additionally or alternatively, the system may execute a preliminary process to determine whether the O1 and O2 events are subscribed to by the cloud maintainer 410, the NRT-RIC 422, or both. In some embodiments, if a determination is made that there is an O1 and / or O2 event subscription, the system proceeds to an O-Cloud determination process 402 and an O-Cloud node unblocking process 404 .

[0050] The O-Cloud node decision process 402 of FIG. 4A may include either or both of operation 442 or operation 444. In operation 442, the cloud maintainer 410 may make a decision to unblock one or more O-Cloud nodes. In some embodiments, the cloud maintainer 410 making the decision to unblock one or more O-Cloud nodes is a manual process performed by a person or group of people. Additionally, the cloud maintainer 410 may receive notifications from the SMO 420, and the cloud maintainer 410 may receive notifications such as a result of subscribing to receive notifications. The cloud maintainer 410 may make a decision based on the received notifications (e.g., O1 data, O2 telemetry data, etc.).

[0051] In operation 444, the NRT-RIC 422 may make a decision to unblock an O-Cloud node, for example, based on an rApp use case. In some embodiments, the NRT-RIC 422 making the decision to unblock an O-Cloud node is an automated process with little or no human interaction. In some embodiments, the SMO 420 may receive a service request, which may include one or more identifiers (or identification data) of the O-Cloud node to be unblocked. The SMO 420 may use the received identification data to identify which of the one or more O-Cloud nodes to unblock. Additionally or alternatively, the process may use other criteria or pre-programmed conditions in making the decision regarding which O-Cloud node should be unblocked as well as when such O-Cloud node should be unblocked. For example, the decision process can use one or more AI / ML algorithms that can be trained using training data, and the decision process can use the trained AI / ML algorithms to make a decision regarding when and which O-Cloud nodes should be unblocked (e.g., based on input data such as O1 data, O2 telemetry data, etc.) If and when the cloud maintainer 410 and / or the NRT-RIC 422 make a determination that one or more O-Cloud nodes should be unblocked, the O-Cloud node unblocking process 404 can be executed.

[0052] In some embodiments, the NRT-RIC 422 may request one or more O-Cloud nodes to be unblocked when it determines that the computational load on the system has increased, and thus may require deployment of additional applications to address the increased computational load. The NRT-RIC 422 may make such a determination of increased computational load (or increased CPU usage or increased CPU demand), for example, by analyzing current network traffic, network traffic patterns, or via historical network traffic data. In some embodiments, the NRT-RIC 422 periodically evaluates the computational load to respond quickly to increased computational demands. By requesting one or more O-Cloud nodes to be unblocked, the subsequently unblocked O-Cloud nodes may be used to deploy additional applications to address the increased computational load.

[0053] In some embodiments, even if an O-Cloud node completes maintenance, the O-Cloud node may remain in an unblocked state until the system makes a determination that such an O-Cloud node is needed to handle an actual or expected increase in computational demand. By keeping the O-Cloud node in an unblocked state, the system can conserve energy and computational resources, thereby optimizing system performance to use an appropriate number of O-Cloud nodes based on actual or expected network traffic. This dynamic allocation of O-Cloud nodes allows the system to conserve energy when network traffic is low and increase resource allocation when network traffic is high, thereby providing a system that enables high quality network performance with optimal energy conservation.

[0054] The O-Cloud node determination process 404 of FIG. 4B may begin with a request operation 446. At the request operation 446, there may be a request from the cloud maintainer 410, the NRT-RIC 422, or both. In particular, at operation 448, the cloud maintainer 410 may facilitate a request to unblock one or more O-Cloud nodes. The request of operation 448 may be forwarded from a terminal (not shown) operated by the cloud maintainer 410 to the FOCOM 424. Additionally or alternatively, at operation 450, the NRT-RIC 422 may facilitate a request to unblock one or more O-Cloud nodes. In some embodiments, one or more rApps may use the NRT-RIC 422 to send a request to unblock one or more O-Cloud nodes. The request of operation 450 may be forwarded from the RT-RIC 450 to the FOCOM 424.

[0055] In some embodiments, the NRT-RIC 422 and / or cloud maintainer 410 may receive telemetry data while one or more O-Cloud nodes are in a blocked state. The received telemetry data may be used by the NRT-RIC 422 and / or cloud maintainer 410 to determine whether an O-Cloud node has completed maintenance such that the O-Cloud node is available to be unblocked. Additionally or alternatively, the NRT-RIC 422 and / or cloud maintainer 410 may receive troubleshooting data that may be used to determine whether one or more O-Cloud nodes have completed maintenance such that the O-Cloud node is available to be unblocked. In some embodiments, the NRT-RIC 422 and / or cloud maintainer 410 may need to make a determination or receive an indication that an O-Cloud node has completed maintenance and is available to be unblocked before a request to unblock such O-Cloud node can be made.

[0056] A decision may be made (either by the cloud maintainer 410 or by an rApp via the NRT-RIC 422) that one or more existing O-Cloud nodes should be unblocked, triggering the FOCOM 424 to unblock the specified set of O-Cloud nodes. In response to the FOCOM 424 receiving one or more requests to unblock one or more O-Cloud nodes, the system may perform an operation 452 that facilitates a process for the FOCOM 424 to unblock one or more O-Cloud nodes identified in the received request. The SMO 420 may not be able to perform the process to unblock an O-Cloud node by itself, and therefore the SMO 420 may need to interact with the IMS 432 to unblock the O-Cloud node. The FOCOM 424 may specifically use an O2 interface to communicate with the IMS 432 of the O-Cloud platform 430 to unblock one or more O-Cloud nodes. For example, the FOCOM 424 can unblock one or more O-Cloud nodes using the O2 IMS service. Operation 452 can be repeated for several requests from either or both the cloud maintainer 410 or the NRT-RIC 422.

[0057] In response to FOCOM 424 communicating with IMS 432, the system may perform operation 454 in which IMS 432 processes one or more requests to unblock an O-Cloud node. The process proceeds to loop 456. Loop 456 includes IMS 432 performing operation 458 in which IMS 432 unblocks each O-Cloud node included in the request, either simultaneously or sequentially. Loop 456 further includes operation 460 in which IMS 432 marks each O-Cloud node unblocked via operation 458 as schedulable for one or more new workload deployments. In some embodiments, operation 458 toggles a flag such that the O-Cloud node is indicated as unblocked. After all O-Cloud nodes included in the request have been processed by loop 456 (i.e., unblocked via operation 458 and marked as schedulable for new workload deployments via operation 460), the process proceeds to either or both of operation 462 or operation 464. In operation 462, the IMS 432 sends one or more O-Cloud status update notifications to the FOCOM 424, for example, via the O2 interface. In operation 464, the IMS 432 sends one or more O-Cloud status update notifications to the NRT-RIC 422, for example, via the O2 interface. In some embodiments, the notification in operation 464 occurs only if the NRT-RIC 422 subscribes to receive notifications from the IMS 432. Either or both of operations 462 or 464 may be included in a notification operation 466 in which the SMO 420 is notified of or receives notification of the O-Cloud node unblocking completion. After operation 466, the unblocked O-Cloud node is advantageously ready for one or more new workload deployments, i.e., the unblocked O-Cloud node is available.

[0058] The O-Cloud decision process 402 and the O-Cloud node unblocking process 404 may be used to efficiently perform maintenance on one or more O-Cloud nodes that require maintenance. In particular, the O-Cloud decision process 402 and the O-Cloud node unblocking process 404 may provide the ability to quickly and efficiently unblock an O-Cloud node so that the O-Cloud node can resume NF deployment. The systems, methods, and apparatus used to provide this ability to quickly and efficiently unblock an O-Cloud node may reduce the time that the O-Cloud node is in an unplannable or unschedulable state, thereby ensuring that the O-Cloud node is operating at maximum efficiency, increasing productivity and providing optimal performance of the network. In this manner, network service providers may quickly and efficiently perform updates or maintenance on the O-Cloud node, thereby providing additional security and a higher quality network.

[0059] 5 illustrates a flow chart of one embodiment of an O-Cloud node unblocking process 500. The process may begin at operation 502 where a request to change the deployable state of an O-Cloud node is received. The process may then proceed to operation 504 where the deployable state of the O-Cloud node is changed in response to receiving the request. Finally, the process may proceed to operation 506 where an indication is sent that the deployable state of the O-Cloud node has been modified in response to changing the deployable state.

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

[0061] It is understood that the particular order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an exemplary approach. It is understood that the particular order or hierarchy of blocks in the processes / flowcharts may be rearranged based on design preferences. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the particular order or hierarchy presented.

[0062] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail integration. 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(s) having computer-readable program instructions for causing a processor to perform operations.

[0063] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but 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 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 disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in a groove on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be interpreted as being transitory signals per se, such as electric 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.

[0064] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to the respective 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.

[0065] The computer readable program code / instructions for carrying out the operations may be either source code or object code 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-oriented programming languages ​​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 via 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., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0066] These computer readable program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to generate a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored on a computer readable storage medium capable of directing 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 includes a product including instructions implementing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

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

[0068] 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 part of instructions that includes one or more executable instructions for implementing a particular logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to the blocks shown in the figures. In some alternative implementations, the functions described in the blocks may occur in a different order than that described in the figures. For example, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, 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, may be implemented by a dedicated hardware-based system that executes the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

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

[0070] The above disclosure also encompasses the embodiments listed below.

[0071] (1) The method may include receiving a request to change the deployable state of an O-Cloud node, changing the deployable state of the O-Cloud node in response to receiving the request, and sending an indication that the deployable state of the O-Cloud node has been modified in response to changing the deployable state.

[0072] (2) The method according to feature (1), wherein changing the deployable state of the O-Cloud node includes changing the deployable state from a blocked state to an unblocked state.

[0073] (3) A method according to feature (1) or (2), wherein the O-Cloud node is unable to deploy at least one of an application, a workload, or a network function in a blocked state, and the O-Cloud node is able to deploy at least one of an application, a workload, or a network function in an unblocked state.

[0074] (4) A method according to any one of features (1) to (3), wherein changing the deployable state of the O-Cloud node includes changing information associated with a flag or marker indicating the deployable state of the O-Cloud node.

[0075] (5) The method according to any one of features (1) to (4), wherein the receiving, modifying, and transmitting are performed by an Infrastructure Management Service (IMS) of the O-Cloud platform.

[0076] (6) A method according to any one of features (1) to (5), wherein receiving a request to change the deployable state of the O-Cloud node includes receiving a request from at least one of a user terminal or a non-real-time radio access network intelligent controller (NRT-RIC).

[0077] (7) The method of any one of features (1) to (6), wherein the request is received in response to a determination of an increase in computational load.

[0078] (8) The method may include sending a request to change the deployable state of the O-Cloud node, the request causing the deployable state of the O-Cloud node to change from a blocked state, in which the O-Cloud node is unable to deploy at least one of an application, a workload, or a network function, to an unblocked state, in which the O-Cloud node is able to deploy at least one of an application, a workload, or a network function.

[0079] (9) The method of any one of (8) to (9), further comprising receiving an indication that the deployable state has changed to an unblocked state.

[0080] (10) The method of any one of features (8) or (9), wherein receiving the instruction includes receiving information relating to an updated flag or marker indicating that the deployable state of the O-Cloud node is in an unblocked state.

[0081] (11) The method of any one of features (8) to (10), further including completing a subscription to receive the deployable state change instruction, and receiving an indication that the deployable state has changed to an unblocked state based on the completing the subscription to receive the deployable state change instruction.

[0082] (12) The method of any one of features (8) to (11), wherein sending the request further includes sending the request from at least one of a user terminal or a non-real-time radio access network intelligent controller (NRT-RIC).

[0083] (13) The method according to any one of features (8) to (12), wherein sending the request further includes sending the request to a Federated O-Cloud Orchestration and Management (FOCOM) component of a Service Management and Orchestration (SMO) framework.

[0084] (14) A method according to any one of features (8) to (13), wherein the FOCOM communicates with an Infrastructure Management Service (IMS) of the O-Cloud platform to execute a change from a blocked state to an unblocked state.

[0085] (15) An apparatus including at least one memory configured to store computer program code; and at least one processor configured to access the at least one memory and operate as instructed by the computer program code, the computer program code including: a receiving code configured to cause at least one of the at least one processor to receive a request to change a deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node; a modifying code configured to, in response to receiving the request, cause at least one of the at least one processor to change the deployable state of the O-Cloud node; and a transmitting code configured to, in response to changing the deployable state, cause at least one of the at least one processor to transmit an indication that the deployable state of the O-Cloud node has been modified.

[0086] (16) The apparatus of feature (15), wherein the change code is further configured to cause at least one of the at least one processor to change the deployable state from a blocked state to an unblocked state.

[0087] (17) The apparatus described in feature (15) or (16), wherein the O-Cloud node is unable to deploy at least one of an application, a workload, or a network function in a blocked state, and the O-Cloud node is able to deploy at least one of an application, a workload, or a network function in an unblocked state.

[0088] (18) The apparatus of any one of features (15) to (17), wherein the receiving code is further configured to cause at least one of the at least one processor to receive the request by an Infrastructure Management Services (IMS) component of the O-Cloud platform, the modifying code is further configured to cause at least one of the at least one processor to modify the deployable state using the IMS, and the transmitting code is further configured to cause at least one of the at least one processor to transmit the instruction from the IMS.

[0089] (19) The apparatus described in any one of features (15) to (18), wherein the modification code is further configured to cause at least one of the at least one processor to modify information associated with a flag or marker indicating a deployable state of the O-Cloud node.

[0090] (20) The apparatus of any one of features (15) to (19), wherein the request is received in response to a determination of an increase in computational load.

Claims

1. Receiving a request to change a deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node; modifying the deployable state of the O-Cloud node in response to receiving the request; sending an indication that the deployable state of the O-Cloud node has been modified in response to changing the deployable state; A method comprising:

2. The method of claim 1 , wherein changing the deployable state of the O-Cloud node comprises changing the deployable state from a blocked state to an unblocked state.

3. The O-Cloud node is unable to deploy at least one of an application, a workload, or a network function in the blocked state; The method of claim 2 , wherein the O-Cloud node is capable of deploying at least one of the applications, the workloads, or the network functions in the unblocked state.

4. The method of claim 1 , wherein changing the deployable state of the O-Cloud node comprises changing information associated with a flag or marker indicating the deployable state of the O-Cloud node.

5. The method of claim 1 , wherein the receiving, modifying, and transmitting are performed by an Infrastructure Management Service (IMS) of an O-Cloud platform.

6. 2. The method of claim 1, wherein receiving the request to change the deployable state of the O-Cloud node includes receiving the request from at least one of a user terminal or a Non-Real-Time Radio Access Network Intelligent Controller (NRT-RIC).

7. The method of claim 1 , wherein the request is received in response to a determination of an increased computational load.

8. 1. A method comprising: transmitting a request to change a deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, the request causing the deployable state of the O-Cloud node to change from a blocked state, in which the O-Cloud node is unable to deploy at least one of an application, a workload, or a network function, to an unblocked state, in which the O-Cloud node is able to deploy at least one of the application, the workload, or the network function.

9. The method of claim 8 , further comprising receiving an indication that the deployable state has changed to the unblocked state.

10. 10. The method of claim 9, wherein receiving the indication comprises receiving information relating to an updated flag or marker indicating that the deployable state of the O-Cloud node is in the unblocked state.

11. completing a subscription to receive deployable state change instructions; 10. The method of claim 9, further comprising receiving the indication that the deployable state has changed to the unblocked state based on completing the subscription to receive the deployable state change indication.

12. 10. The method of claim 8, wherein the transmitting the request further comprises transmitting the request from at least one of a user terminal or a Non-Real-Time Radio Access Network Intelligent Controller (NRT-RIC).

13. 10. The method of claim 8, wherein the sending the request further comprises sending the request to a Federated O-Cloud Orchestration and Management (FOCOM) component of a Service Management and Orchestration (SMO) framework.

14. The method of claim 8, wherein the FOCOM communicates with an Infrastructure Management Service (IMS) of an O-Cloud platform that performs the change from the blocked state to the unblocked state.

15. at least one memory configured to store computer program code; at least one processor configured to access the at least one memory and operate as instructed by the computer program code, the computer program code comprising: receiving code configured to cause at least one of the at least one processor to receive a request to change a deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node; modification code configured to, in response to receiving the request, cause at least one of the at least one processor to modify the deployable state of the O-Cloud node; a transmitting code configured to, in response to changing the deployable state, cause at least one of the at least one processor to transmit an indication that the deployable state of the O-Cloud node has been modified; At least one processor including: An apparatus comprising:

16. 16. The apparatus of claim 15, wherein the change code is further configured to cause at least one of the at least one processor to change the deployable state from a blocked state to an unblocked state.

17. The O-Cloud node is unable to deploy at least one of an application, a workload, or a network function in the blocked state; The apparatus of claim 16, wherein the O-Cloud node is capable of deploying at least one of the applications, the workloads, or the network functions in an unblocked state.

18. the receiving code is further configured to cause at least one of the at least one processor to receive the request by an Infrastructure Management Services (IMS) component of an O-Cloud platform; the modification code is further configured to cause at least one of the at least one processor to modify the deployable state using the IMS; 16. The apparatus of claim 15, wherein the transmitting code is further configured to cause at least one of the at least one processor to transmit the indication from the IMS.

19. 16. The apparatus of claim 15, wherein the modification code is further configured to cause at least one of the at least one processor to modify information associated with a flag or marker indicating the deployable state of the O-Cloud node.

20. The apparatus of claim 15 , wherein the request is received in response to a determination of an increase in computational load.

Images