O-Cloud node unblocked

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

[0004] ,

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

[0002] Systems, methods, and apparatuses consistent with exemplary embodiments of the present disclosure relate to Open Radio Access Networks (O-RANs), and more particularly, to systems, methods, and apparatuses used to uncordon one or more O-RAN cloud (O-Cloud) nodes.

Background Art

[0003] Prior to the development of O-RAN technology, radio access networks (RANs) used "closed" systems that relied on proprietary interfaces between radio units and baseband units, which limited the ability of service providers to diversify radio unit and baseband unit vendors. To provide wireless services to customers, service providers had to select a particular 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 inhibitors created barriers to new vendor entry, thereby allowing existing vendors to maintain high prices ultimately borne by service provider customers. Additionally, service providers that were highly dependent on a single supplier were exposed to cybersecurity risks associated with potential security breaches in that supplier's software.

[0004] O-RAN technology "opened" these previously compliant interfaces and protocols, thereby providing service providers with more vendor choices, 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 deployment, reduces service provider equipment costs (and thus reduces costs for service provider customers), and mitigates cybersecurity risks.

[0005] Despite these advantages of O-RAN technology, related technologies had their problems. In particular, current O-RAN technology has not been able to provide an efficient way to deactivate O-Cloud nodes.

[0006] Improvements to address such shortcomings are presented herein. These improvements may also be applicable to other technologies and telecommunications standards that use these technologies. [Overview of the project]

[0007] The following provides a simplified overview of one or more embodiments of the present disclosure to give a basic understanding of such embodiments. This overview is not a comprehensive overview of all possible embodiments, nor is it intended to identify the main or important elements of all embodiments, nor to specify the scope of any or all embodiments. Its sole purpose is to present in a simplified form some of the concepts of one or more embodiments of the present disclosure as a prelude to the more detailed descriptions presented later.

[0008] According to an exemplary embodiment, the method includes receiving a request to change the 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 corrected in response to the change in the deployable state.

[0009] According to an exemplary embodiment, the method includes sending a request to change the 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, workload, or network function to an uncordoned state in which the O-Cloud node is able to deploy at least one of an application, workload, or network function.

[0010] According to an exemplary embodiment, a device in an open radio access network (O-RAN) 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 to operate as instructed by the computer program code. The computer program code includes receive code configured to cause at least one of the at least one processor to receive a request to change the deployable state of an O-Cloud node. The computer program code includes change code configured to cause at least one of the at least one processor to change the deployable state of an O-Cloud node in response to receiving the request. The computer program code further includes transmit code configured to cause at least one of the at least one processor to send an instruction that the deployable state of the O-Cloud node has been corrected in response to the change in the deployable state.

[0011] Additional embodiments are described below, partially revealed therein, and / or can be acquired by carrying out the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0012] The above and other aspects, features, and embodiments of the present disclosure will become apparent from the following description in conjunction with the accompanying drawings. [Figure 1] This is a diagram illustrating an exemplary network device according to various embodiments of the present disclosure. [Figure 2] This is a schematic diagram illustrating an exemplary O-RAN communication system according to various embodiments of the present disclosure. [Figure 3] This figure shows an O-RAN architecture according to various embodiments of the present disclosure. [Figure 4A] This figure shows the O-Cloud identification process according to various embodiments of the present disclosure. [Figure 4B]This figure shows the O-Cloud node deblocking process according to various embodiments of the present disclosure. [Figure 5] This is an exemplary flowchart of the O-Cloud node deactivation process according to various embodiments of the present disclosure. [Modes for carrying out the invention]

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

[0014] 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 variations are possible in light of the foregoing disclosures, or such modifications and variations may be derived from the practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into another embodiment (or one or more features of another embodiment), or combined with another embodiment (or one or more features of another embodiment). In addition, it should be understood that in the flowcharts and descriptions of operation provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be changed.

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

[0016] Even if specific combinations of features are described in the claims and / or disclosed herein, 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 herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim combined with all other claims in the set of claims.

[0017] Any element, action, or command used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, where 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, use the term “one” or similar phrases. Also, where used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be non-restrictive. Additionally, the phrase “based on” is intended to mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood to include A only, B only, or both A and B.

[0018] Throughout this specification, any reference to “one embodiment,” “embodiment,” or similar language means that certain features, structures, or characteristics described in relation to the embodiments shown are included in at least one embodiment of the present solution. Therefore, throughout this specification, the phrases “in one embodiment,” “in an embodiment,” and similar language may all, though not necessarily, refer to the same embodiment.

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

[0020] Embodiments of this disclosure relate to systems, methods, and apparatus used to deactivate one or more O-Cloud nodes. Figure 1 shows an exemplary device 100 for implementing the systems, methods, and apparatus of this disclosure. 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. Device 100 may correspond to any type of known computer, server, or data processing device. For example, device 100 may include processors, personal computers (PCs), printed circuit boards (PCBs) including computing devices, minicomputers, mainframe computers, microcomputers, telephone computing devices, wired / wireless computing devices (e.g., smartphones, personal digital assistants (PDAs)), laptops, tablets, smart devices, or any other similar functional devices.

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

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

[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 device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The 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 cooperating with a DSP core, or any other such configuration. In some embodiments, certain processes and methods may be performed by circuitry specific to a given function.

[0024] Processor 120 can control the overall operation of device 100 and / or a set of components of device 100 (e.g., memory 130, storage component 140, input component 150, output component 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 other types of dynamic or static storage devices. Memory 130 can store information and / or instructions for use (e.g., execution) by processor 120.

[0026] The storage component 140 of device 100 can store information related to the operation and use of device 100, as well as / or computer-readable instructions and / or code. For example, the storage component 140 may include a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or 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-temporary computer-readable medium, together with a corresponding drive.

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

[0028] The output component 160 of device 100 may include one or more components that can 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. The communication interface 170 may include a receiver component, a transmitter component, and / or a transceiver component. The communication interface 170 may enable device 100 to establish connections with other devices (e.g., a server, another device) and / or to forward communications. Communications may be conducted via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 170 may enable device 100 to receive information from another device and / or to provide information to another device. In some embodiments, the communication interface 170 may provide communication with another device via a network such as a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), private network, ad hoc network, intranet, internet, fiber optic network, cellular network (e.g., 5G network, long-term evolution (LTE) network, 3G network, code division multiple access (CDMA) network, etc.), public land mobile network (PLMN), telephone network (e.g., public switched telephone network (PSTN)), 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, or 5G.In other embodiments, the communication interface 170 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, and the like.

[0030] Device 100 may be included in the core network 240 and may execute one or more processes as described herein. Device 100 may perform operations based on the execution of computer-readable instructions and / or code by a processor 120, which may be stored in a non-temporary computer-readable medium such as memory 130 and / or storage component 140. The computer-readable medium may refer to a non-temporary memory device. The 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 read into memory 130 and / or storage component 140 from another computer-readable medium or from another device via the communication interface 170. Computer-readable instructions and / or code stored in memory 130 and / or storage component 140, if executed by or upon execution by the processor 120, may cause device 100 to execute one or more processes described herein.

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

[0033] The number and arrangement of components shown in Figure 1 are provided as an example. In practice, there may be additional components, fewer components, different components, or components arranged differently compared to those shown in Figure 1. Furthermore, two or more 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, the 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] Figure 2 shows an exemplary O-RAN communication system 200 according to various embodiments of the present disclosure. The O-RAN communication 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 UE210s may include cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, Global Positioning System (GPS), multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electric meters, gas pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similarly functioning devices. Some of one or more UE210s may be referred to as Internet-of-Things (IoT) devices (e.g., parking meters, gas pumps, toasters, vehicles, heart monitors, etc.). One or more UE210s may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, radio unit, remote unit, mobile device, radio device, radio communication device, remote device, mobile subscriber station, access terminal, mobile terminal, radio terminal, remote terminal, handset, user agent, mobile agent, client, or any other appropriate term.

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

[0037] 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. Base stations 220A may include, and / or be referred to as, access points (APs), evolved (or evolved universal terrestrial radio access network (E-UTRAN)) node B (eNBs), next-generation node B (gNBs), or any other type of base station known to those skilled in the art, whether macrocells or large cells.

[0038] In some embodiments, O-RU220 may be connected to O-DU230 via FH link 224. FH link 224 may be a 25 Gbps line through which user plane (U-plane) and control plane (C-plane) packets are downloaded from O-DU230 to O-RU220. In some embodiments, O-DU230 may be connected to O-CU240 via midhall link 234. O-CU240 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 packets and U-plane packets may be generated from the O-CU-CP packet generator 240A and the O-CU-UP packet generator 240B, respectively. These components enable the radio access network (RAN) of a telecommunications system to connect one or more UE210s to other parts of the network.

[0039] The O-RAN communication system 200 can decompose RAN functions via O-CU240, O-DU230, and O-RU220. O-CU240 may be 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. O-DU230 may be a logical node for hosting the RAN's Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers. O-RU220 may be a physical node that converts radio signals from the antenna into digital signals that can be transmitted to O-DU230 via the "fronthaul".

[0040] Figure 3 shows an exemplary network architecture 300 that may be used in the implementation of the technology described herein. The network architecture 300 may include, for example, O-RU320, O-DU330, O-CU-CP340A, O-CU-UP340B, and service management and orchestration (SMO)360. The RAN functionality 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 to facilitate the multi-vendor operability required in the O-RAN system 300 and automate and optimize RAN operation. The RICs are classified into two types: non-real-time RICs (NRT-RICs)362 and near-real-time RICs (nRT-RICs)350.

[0041] The NRT-RIC362 is the control point of the non-real-time control loop and operates on a timescale of more than one second within the Service Management and Orchestration (SMO) framework. Its functionality is implemented by a modular application called rApp. Its functionality includes providing policies (i.e., a set of rules used to manage and control the change and / or maintenance of the state of one or more managed objects) based on guidance and enrichment across the A1 interface, which is an interface that enables communication between the NRT-RIC362 and the nRT-RIC350. An A1 policy may be a type of declarative policy expressed using a formal description that enables NRT-RIC362 within SMO360 to guide nRT-RIC350, and therefore RAN, toward a better realization of RAN intents; to perform data analysis; to train and infer artificial intelligence / machine learning (AI / ML) for RAN optimization; and / or to recommend configuration management actions on the O1 interface for managing operation and maintenance (OAM)368, which is the interface connecting SMO360 to RAN managed elements (e.g., nRT-RIC350, O-CU-CP340A, O-CU-UP340B, O-DU330, etc.).

[0042] The nRT-RIC350 is located at the edge of the RAN and operates on a timescale between 10 milliseconds and 1 second. The nRT-RIC350 connects to the O-DU330, O-CU-CP340A, O-CU-UP340B, and the Open Evolutionary NodeB (O-eNB) (not shown) via the E2 interface. The nRT-RIC350 uses the E2 interface to control the underlying RAN elements (E2 Node / Network Functions (NF)) via a near real-time control loop. The nRT-RIC350 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-RU320 via a fronthaul including the Control User Synchronization (CUS) plane and the Management (M) plane. For example, the nRT sets policy parameters for the activated functions of the E2 nodes. Furthermore, the nRT-RIC350 hosts 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 the O-RAN. For example, the NRT RIC362 provides policies, data, and AI / ML models enforced and used by the nRT RIC350 for RAN optimization via the A1 interface, and the nRT returns policy feedback (i.e., how the policies set by the NRT RIC362 are performing).

[0043] The SMO360 framework manages and orchestrates RAN element 363. Specifically, SMO360 includes Federated O-Cloud Orchestration and Management (FOCOM) 364, Network Function Orchestrator (NFO) 366 which manages virtual machine (VM)-based virtual network functions (VNFs) (not shown) and container (i.e., instance) (not shown)-based VNFs, and OAM 368 as part of SMO360 which 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 SMO360 itself. In other words, SMO360 manages the O-Cloud 370 from within. The O2 interface is the interface between SMO360 and the O-Cloud370 on which it resides. Through the O2 interface, SMO360 provides infrastructure management services (IMS)372 and deployment management services (DMS)374.

[0044] The NRT-RIC362 can create a RAN optimization policy (i.e., an A1 policy for RAN optimization to satisfy RAN intents). The NRT-RIC362 can then pass that policy to the nRT-RIC350 via the A1 interface (i.e., the A1 policy). Upon receiving the A1 policy, the nRT-RIC350 can perform the necessary controls to enforce the policy and execute them within a control loop according to the policy.

[0045] As previously mentioned, Figure 3 provides an exemplary system architecture 300 that may be used in implementing the technologies described herein. In particular, drain commands and / or shut-off commands may be executed, for example, when an O-Cloud370 node requires some kind of maintenance. A drain command can safely remove, evict, or transfer pods or instances from a node before maintenance is performed on the node. For example, drain can delete all pods on a node (with the exception that it does not delete "mirror pods"). After a drain command has been executed on a particular node, that node can be said to be "shut-off". When a node is drained or shut-off, it is operational but may not be available for scheduling, deploying, instantiating 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 network interface cards or adding physical memory hardware) can still be performed on that node. In some embodiments, when a node is shut-off, there may be "taints" associated with such a node.

[0046] In some embodiments, a block command can ensure that no new pods or instances are scheduled on the target node. That is, executing a block command can put the node into an unplanned or unschedulable state. A block command can be used to ensure that no new pods or instances are scheduled on the target node. The target node may be placed into an unplanned or unschedulable state when the node is being prepared for maintenance. When a node is in an unplanned state, other commands can be used to move pods or instances away from the target node so that maintenance can be performed on the node. In some embodiments, executing a block command removes all pods that have been placed on the target node. Thus, the scheduler can list the removed pods / instances on the new node and / or alternative node. In some embodiments, multiple nodes (e.g., a node cluster) may be drained sequentially or simultaneously or blocked. In some embodiments, nodes may be marked, flagged, or otherwise given some indicator that a node is in a drained / drained or blocked / blocked state.

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

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

[0049] Prior to the O-Cloud decision process 402 and / or the O-Cloud node deactivation process 404, the system may perform one or more preliminary processes. For example, the system may perform a preliminary process to determine whether the SMO 420 and / or the O-Cloud platform 430 are available. In some embodiments, if it is determined that the SMO 420 and the O-Cloud platform 430 are available (e.g., have sufficient computing resources available), the system proceeds to the O-Cloud decision process 402 and the O-Cloud node deactivation 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 perform a preliminary process to determine whether the O1 and O2 events are subscribed to by the cloud maintainer 410, by the NRT-RIC 422, or by both. In some embodiments, if it is determined that there are O1 and / or O2 event subscriptions, the system proceeds to the O-Cloud determination process 402 and the O-Cloud node deblocking process 404.

[0050] The O-Cloud node decision process 402 in Figure 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 one or a group of people. Furthermore, the cloud maintainer 410 may receive notifications from the SMO 420, such as notifications resulting from subscribing to receive notifications. The cloud maintainer 410 may make decisions based on the received notifications (e.g., O1 data, O2 telemetry data, etc.).

[0051] In operation 444, NRT-RIC422 may make a decision to unblock an O-Cloud node, for example, based on an rApp use case. In some embodiments, the NRT-RIC422 making the decision to unblock an O-Cloud node is an automated process with little or no human interaction. In some embodiments, SMO420 may receive a service request which may include one or more identifiers (or identification data) of O-Cloud nodes to be unblocked. SMO420 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 when making decisions about which O-Cloud nodes should be unblocked and when such O-Cloud nodes should be unblocked. For example, the decision process may use one or more AI / ML algorithms that can be trained using training data, and the decision process may use the trained AI / ML algorithms to make decisions about when and which O-Cloud nodes should be unblocked (based on input data such as O1 data, O2 telemetry data, etc.). If the cloud maintainer 410 and / or NRT-RIC 422 make a decision that one or more O-Cloud nodes should be unblocked, and if so, can execute the O-Cloud node unblocking process 404.

[0052] In some embodiments, the NRT-RIC422 may request that one or more O-Cloud nodes be unblocked when it determines that the computing load on the system has increased, and therefore additional application deployments may be required to address the increased computing load. The NRT-RIC422 may make such a determination of increased computing load (or increased CPU usage or increased CPU demand) by, for example, analyzing current network traffic, network traffic patterns, or through historical network traffic data. In some embodiments, the NRT-RIC422 periodically evaluates the computing load to respond quickly to increased computing demands. By requesting that one or more O-Cloud nodes be unblocked, additional applications can then be deployed using the subsequently unblocked O-Cloud nodes to address the increased computing load.

[0053] In some embodiments, even after an O-Cloud node has completed maintenance, it may remain unblocked until the system determines that such an O-Cloud node is necessary to address an actual or expected increase in computing demand. By keeping O-Cloud nodes unblocked, the system can conserve energy and computing 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 savings.

[0054] The O-Cloud node determination process 404 in Figure 4B can be initiated from request operation 446. Request operation 446 may include requests from the cloud maintainer 410, NRT-RIC 422, or both. In particular, in operation 448, the cloud maintainer 410 may facilitate a request to unblock one or more O-Cloud nodes. The request in operation 448 may be forwarded from a terminal (not shown) operated by the cloud maintainer 410 to FOCOM 424. Additionally or alternatively, in 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 NRT-RIC 422 to send a request to unblock one or more O-Cloud nodes. The request in operation 450 may be forwarded from RT-RIC 450 to FOCOM 424.

[0055] In some embodiments, the NRT-RIC422 and / or the 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-RIC422 and / or the cloud maintainer 410 to determine whether the O-Cloud nodes have completed maintenance so that they are available for unblocking. Additionally or alternatively, the NRT-RIC422 and / or the cloud maintainer 410 may receive troubleshooting data that can be used to determine whether one or more O-Cloud nodes have completed maintenance so that they are available for unblocking. In some embodiments, the NRT-RIC422 and / or the cloud maintainer 410 may need to make a determination or receive an instruction that an O-Cloud node has completed maintenance and is available for unblocking before a request to unblock such an O-Cloud node may be made.

[0056] A decision is made (either by the Cloud Maintainer 410 or by rApp via NRT-RIC422) that one or more existing O-Cloud nodes should be unblocked, triggering FOCOM424 to unblock a specified set of O-Cloud nodes. In response to FOCOM424 receiving one or more requests to unblock one or more O-Cloud nodes, the system may perform operation 452 to facilitate the process for FOCOM424 to unblock one or more O-Cloud nodes identified in the received requests. SMO420 may not be able to perform the process for unblocking O-Cloud nodes on its own, and therefore SMO420 may need to interact with IMS432 to unblock O-Cloud nodes. Specifically, FOCOM424 can communicate with IMS432 of the O-Cloud platform 430 using the O2 interface to unblock one or more O-Cloud nodes. For example, FOCOM424 can use the O2 IMS service to unblock one or more O-Cloud nodes. Operation 452 may be repeated in response to several requests from either or both of the cloud maintainer 410 or NRT-RIC422.

[0057] In response to FOCOM424 communicating with IMS432, the system may perform operation 454, which processes one or more requests for IMS432 to unblock O-Cloud nodes. The process proceeds to loop 456, which includes IMS432 performing operation 458, which causes IMS432 to unblock each O-Cloud node included in the request, either concurrently or sequentially. Loop 456 further includes operation 460, which causes IMS432 to mark each O-Cloud node unblocked via operation 458 as available for scheduling for one or more new workload deployments. In some embodiments, operation 458 toggles a flag, indicating that the O-Cloud node is unblocked. After all O-Cloud nodes included in the request have been processed by loop 456 (i.e., unblocked by operation 458 and marked as available for scheduling for new workload deployments by operation 460), the process proceeds to either or both operation 462 or operation 464. In operation 462, IMS432 sends one or more O-Cloud status update notifications to FOCOM424, for example, via the O2 interface. In operation 464, IMS432 sends one or more O-Cloud status update notifications to NRT-RIC422, for example, via the O2 interface. In some embodiments, the notifications in operation 464 occur only if NRT-RIC422 is subscribed to receive notifications from IMS432. Either or both of operations 462 or 464 may be included in notification operation 466, in which SMO420 is notified of or receives notification that the O-Cloud node has been unblocked. 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 detox process 404 can be used to effectively perform maintenance on one or more O-Cloud nodes that require maintenance. Specifically, the O-Cloud decision process 402 and the O-Cloud node detox process 404 can provide the ability to quickly and efficiently detox O-Cloud nodes so that they can resume NF deployments. The systems, methods, and apparatus used to provide this ability to quickly and efficiently detox O-Cloud nodes reduce the time that O-Cloud nodes are in an unplanned or unscheduled state, thereby ensuring that O-Cloud nodes are operating at maximum efficiency, increasing productivity, and providing optimal network performance. In this way, network service providers can quickly and efficiently perform updates or maintenance on O-Cloud nodes, thereby providing additional security and a higher quality network.

[0059] Figure 5 shows a flowchart of one embodiment of the O-Cloud node deactivation process 500. The process can be initiated in operation 502, when a request is received to change the deployable state of the O-Cloud node. Next, the process can proceed to operation 504, in which the deployable state of the O-Cloud node is changed in response to the receipt of the request. Finally, the process can proceed to operation 506, in which an instruction is sent indicating that the deployable state of the O-Cloud node has been corrected in response to the change in the deployable state.

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

[0061] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an exemplary technique. It is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged based on design preferences. Furthermore, some blocks may be combined or omitted. The claims of the appended methods present various block elements in a sample order and do not imply that they are limited to the specific order or hierarchy presented.

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

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

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

[0065] The computer-readable program code / instructions for performing the operation may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or 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 run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via 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) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions for personalizing the electronic circuit in order to perform an action or operation.

[0066] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a machine such that instructions executed via the processor of a computer or other programmable data processing device create means for performing 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 on which the instructions are stored includes a product containing instructions that perform the modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0067] Computer-readable program instructions may also be loaded onto a computer, another programmable device, or another device to cause a series of operational steps to be executed on the computer, another programmable device, or another device in order to generate a computer implementation process, the instructions executed on the computer, another programmable device, or another device performing the functions / operations specified in one or more blocks of a flowchart and / or block diagram.

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

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

[0070] The above disclosure also includes 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 instruction that the deployable state of the O-Cloud node has been corrected in response to the change in the deployable state.

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

[0073] (3) The method according to feature (1) or (2), wherein an O-Cloud node is unable to deploy at least one of an application, workload, or network function when it is isolated, and an O-Cloud node is able to deploy at least one of an application, workload, or network function when it is unisolated.

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

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

[0076] (6) The method according to any one of features (1) to (5), wherein receiving a request to change the deployable state of an 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) A method according to any one of features (1) to (6), wherein a request is received in response to a decision to increase the computational load.

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

[0079] (9) The method according to feature (8), further comprising receiving an instruction that the deployable state has changed to an unblocked state.

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

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

[0082] (12) The method according to any one of features (8) to (11), further comprising transmitting a 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), further comprising sending the request to the Federated O-Cloud Orchestration and Management (FOCOM) component of the Service Management and Orchestration (SMO) framework.

[0084] (14) The method of any one of features (8) to (13) by which FOCOM communicates with the Infrastructure Management Service (IMS) of the O-Cloud platform to perform a change from a blocked state to an unblocked state.

[0085] (15) A device comprising at least one memory configured to store computer program code, and at least one processor configured to access the at least one memory and to operate as instructed by the computer program code, wherein the computer program code includes: receive code configured to cause at least one of the at least one processor to receive a request to change the deployable state of an open radio access network (O-RAN) cloud (O-Cloud) node; change code configured to cause at least one of the at least one processor to change the deployable state of the O-Cloud node in response to receiving the request; and transmit code configured to cause at least one of the at least one processor to send an instruction that the deployable state of the O-Cloud node has been corrected in response to the change in the deployable state.

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

[0087] (17) The device according to feature (15) or (16), wherein the O-Cloud node is unable to deploy at least one of the applications, workloads, or network functions when isolated, and the O-Cloud node is able to deploy at least one of the applications, workloads, or network functions when unisolated.

[0088] (18) The apparatus according to any one of features (15) to (17), wherein the receiving code is further configured to cause at least one of the at least one processors to receive a request by the Infrastructure Management Services (IMS) component of the O-Cloud platform, the changing code is further configured to cause at least one of the at least one processors to change the deployable state using IMS, and the sending code is further configured to cause at least one of the at least one processors to send instructions from IMS.

[0089] (19) The apparatus according to any one of features (15) to (18), wherein the change code is further configured to cause at least one of the at least one processors to change information related to a flag or marker indicating the deployable state of an O-Cloud node.

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

Claims

1. Receiving requests to change the deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, In response to receiving the aforementioned request, the deployable state of the O-Cloud node is changed, Sending an instruction that the deployable state of the O-Cloud node has been modified in response to the change in the deployable state. A method including, A method for changing the deployable state of the O-Cloud node, comprising changing the deployable state from a blocked state to an unblocked state.

2. The O-Cloud node is unable to deploy at least one of the following in the isolated state: applications, workloads, or network functions. The method according to claim 1, wherein the O-Cloud node can deploy at least one of the applications, workloads, or network functions in the unblocked state.

3. The method according to claim 1, wherein changing the deployable state of the O-Cloud node includes changing information related to a flag or marker indicating the deployable state of the O-Cloud node.

4. The method according to 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).

5. The method according to claim 1, wherein the request is received in response to a decision to increase the computational load.

6. A method comprising sending a request to change the deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, wherein the request causes 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, workload, or network function to an unblocked state of the maintained O-Cloud node, which in the unblocked state is able to deploy at least one of the application, workload, or network function.

7. The method according to claim 6, further comprising receiving an instruction that the deployable state has changed to the unblocked state.

8. The method according to claim 7, 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 the unblocked state.

9. To receive deployable state change instructions, complete the subscription and The method of claim 7, further comprising receiving the instruction that the deployable state has been changed to the unblocked state, based on the completion of the subscription for receiving the deployable state change instruction.

10. The method according to claim 6, further comprising transmitting the request to the Federated O-Cloud Orchestration and Management (FOCOM) component of a Service Management and Orchestration (SMO) framework.

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

12. At least one memory configured to store computer program code, A device comprising: at least one processor that accesses the at least one memory and is configured to operate as instructed by the computer program code, wherein the computer program code A receive code configured to cause at least one of the above at least one processors to receive a request to change the deployable state of an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node, In response to receiving the aforementioned request, a change code configured to cause at least one of the at least one processors to change the deployable state of the O-Cloud node, A transmission code configured to cause at least one of the at least one processors to send an instruction that the deployable state of the O-Cloud node has been modified in response to the change in the deployable state, Includes, The change code is further configured to cause at least one of the at least one processors to change the deployable state from a blocked state to an unblocked state of the maintained O-Cloud node. The O-Cloud node is unable to deploy at least one of the following in the isolated state: applications, workloads, or network functions. A device in which the O-Cloud node can deploy at least one of the applications, workloads, or network functions when the O-Cloud node is unblocked.

13. The receiving code is further configured to cause at least one of the at least one processors to receive the request by the Infrastructure Management Services (IMS) component of the O-Cloud platform. The change code is further configured to cause at least one of the at least one processors to change the deployable state using the IMS, The apparatus according to claim 12, wherein the transmission code is further configured to cause at least one of the at least one processors to transmit the instruction from the IMS.

14. The apparatus according to claim 12, wherein the modification code is further configured to cause at least one of the at least one processors to modify information related to a flag or marker indicating the deployable state of the O-Cloud node.

15. The apparatus according to claim 12, wherein the request is received in response to a decision to increase the computational load.

16. The method according to claim 1, wherein a request to change the deployable state of the O-Cloud node is based on at least one of the O1 data and the O2 data.

Images