System and method for blocking cloud nodes

Abstract

A method and system for shutting down an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node is provided. The method may include receiving, by a Service Management and Orchestration Framework (SMO) function, a first request to shut down at least one O-Cloud node, the first request being received from a user terminal or an rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC); sending, by the SMO function, a second request to shut down the at least one O-Cloud node via an O2 interface to an Infrastructure Management Service (IMS) and / or a Deployment Management Service (DMS) based on the received first request; and receiving a first notification from the IMS / DMS that the at least one O-Cloud node has been shut down, wherein the SMO function is at least one of a Federated O-Cloud Orchestration and Management (FOCOM) and a Network Function Orchestration (NFO).

Description

Technical Field

[0001] Systems and methods consistent with exemplary embodiments of the present disclosure relate to blocking an O-Cloud node to prevent a scheduler from placing a new deployment on an open radio access network (O-RAN) cloud (O-RAN Cloud: O-Cloud) node.

Background Art

[0002] A radio access network (RAN) is an important component in a telecommunication system for connecting an end-user device (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect the end-user device to the core network. Conventionally, the hardware and / or software of a particular RAN is vendor-specific.

[0003] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to telecommunications systems. For this purpose, O-RAN divides the RAN functionality into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU is a logical node for hosting the RAN's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. The DU is a logical node for hosting the RAN's Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers. The RU is a physical node that converts radio signals from antennas into digital signals that can be transmitted to the DU via fronthaul. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

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

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

[0006] The quasi-RT RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, O-CU (divided into the O-CU control plane (O-CU-CP) and O-CU user plane (O-CU-UP)), and open evolved node B (O-eNB) via the E2 interface. The quasi-RT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) via a quasi-real-time control loop. The quasi-RT RIC monitors, pauses / terminates, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) via policies. For example, the quasi-RT sets policy parameters for activated functions of the E2 node. Furthermore, the quasi-RT RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs collaborate to optimize O-RAN. For example, a non-RT RIC provides policies, data, and AI / ML models to be executed and used by a quasi-RT RIC for RAN optimization via the A1 interface, and the quasi-RT returns policy feedback (i.e., how the policies set by the non-RT RIC are performing).

[0007] The SMO framework, in which non-RT RICs reside, manages and orchestrates RAN elements. Specifically, SMO includes Federated O-Cloud Orchestration and Management (FOCOM), a Network Function Orchestrator (NFO) that manages virtual machine (VM)-based virtual network functions (VNFs) and container (i.e., instance)-based VNFs, and OAM as part of SMO, which manages and orchestrates what is called the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of RICs, O-CUs, and O-DUs, supporting software components (e.g., operating systems and runtime environments), and physical RAN nodes that host SMO itself. In other words, SMO manages the O-Cloud from within. The O2 interface is the interface between SMO and the O-Cloud in which it resides. Through the O2 interface, the SMO provides Infrastructure Management Services (IMS) and Deployment Management Services (DMS). The O2 interface can also transmit O2 telemetry data to the SMO, such as O2 cloud configuration or arbitrary logical function data, energy consumption, node health status, etc.

[0008] In related technologies, OCloud nodes may be released for various reasons, for example, to allow hardware upgrades, software upgrades, kernel upgrades, energy efficiency or optimization processes to run before node shutdown. However, a scheduler in SMO, which may be responsible for instantiating network functions within an OCloud node, may not be aware that the node has been released, which could inadvertently cause errors when the scheduler attempts to instantiate network functions within an OCloud node that has been released. Therefore, it is necessary to be able to indicate that an OCloud node should no longer be schedulable (i.e., is in an unschedulable state). [Overview of the project]

[0009] Exemplary embodiments of this disclosure provide methods and systems for blocking an O-cloud node in order to mark it as unschedulable. In particular, before the O-cloud node is released, an SMO function (e.g., at least one of FOCOM and NFO) may request the IMS / DMS to block the O-cloud node, thereby marking it as unschedulable (i.e., unschedulable) by the SMO's scheduler.

[0010] Therefore, exemplary embodiments of this disclosure can avoid scheduling errors (e.g., scheduling the instantiation of a network function when a cloud node is free).

[0011] According to the embodiment, a method can be provided for blocking one or more open radio access network (O-RAN) cloud (O-Cloud) nodes. The method may include: receiving a first request by a Service Management and Orchestration Framework (SMO) function to block at least one O-Cloud node, the first request being received from a user terminal or from an rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC); the SMO function sending a second request to an Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via an O2 interface to block at least one O-Cloud node based on the received first request; and receiving a first notification from the IMS / DMS that at least one O-Cloud node has been blocked, the SMO function being at least one of Federated O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

[0012] The second request may be an instruction to block a first O-cloud node of at least one O-cloud node, the first notification indicating that the first O-cloud node has been blocked, and the method may further include, by the SMO function, sending a third request to the IMS / DMS via the O2 interface to block a second O-cloud node of at least one O-cloud node based on the received first request, and receiving a second notification from the IMS / DMS that the second O-cloud node has been blocked.

[0013] The first request may be triggered by a non-RT RIC rApp or by a submitted manual request via the Service Management and Orchestration Framework (SMO).

[0014] The second request may only be sent to IMS / DMS by the SMO function, based on the SMO function determining that the first request to block at least one O cloud node is valid.

[0015] The method may further include controlling the IMS / DMS to shut down at least one O-cloud node based on a second request and mark the O-cloud node as unschedulable.

[0016] Receiving the first notification that an O cloud node has been blocked may further include, by the SMO function, receiving the first notification from the IMS / DMS via the O2 interface that at least one O cloud node has been blocked.

[0017] Receiving the first notification that an O cloud node has been shut down may further include receiving the first notification from the SMO function via a non-RT RIC rApp that at least one O cloud node has been shut down.

[0018] According to the embodiment, a device can be provided for blocking one or more open radio access network (O-RAN) cloud (O-Cloud) nodes. The device may include at least one processor configured to execute computer executable instructions to receive a first request, which is a first request received from a user terminal or from the rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC), via a Service Management and Orchestration Framework (SMO) function, for blocking at least one O-Cloud node, and to send a second request to the Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via the O2 interface, based on the received first request, for blocking at least one O-Cloud node, and to receive a first notification from the IMS / DMS that at least one O-Cloud node has been blocked, where the SMO function is at least one of Federated O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

[0019] The second request may be an instruction to block the first O-cloud node of at least one O-cloud node, the first notification indicating that the first O-cloud node has been blocked, and at least one processor may be further configured by an SMO function to execute a computer executable instruction to send a third request to the IMS / DMS via the O2 interface to block the second O-cloud node of at least one O-cloud node based on the received first request, and to receive a second notification from the IMS / DMS that the second O-cloud node has been blocked.

[0020] The first request may be triggered by a non-RT RIC rApp or by a manual request submitted via the Service Management and Orchestration Framework (SMO).

[0021] The second request can be sent to the IMS / DMS only by the SMO function based on determining that a first request for blocking at least one O cloud node is valid by the SMO function.

[0022] At least one processor may be further configured to execute computer-executable instructions for controlling, based on the second request, at least one O cloud node to be blocked by the IMS / DMS so as to mark the O cloud node as unschedulable.

[0023] At least one processor may be further configured to execute computer-executable instructions for receiving a first notification that at least one O cloud node has been blocked by receiving, via the O2 interface, from the IMS / DMS, the first notification that at least one O cloud node has been blocked by the SMO function.

[0024] At least one processor may be further configured to execute computer-executable instructions for receiving a first notification that at least one O cloud node has been blocked by receiving, from the SMO function, the first notification that at least one O cloud node has been blocked by a non-RT RIC's rApp.

[0025] Additional aspects are in part described in the following description, in part will become apparent from the description, or may be realized by the practice of the presented embodiments of the disclosure.

Brief Description of the Drawings

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

[0027] [Figure 1] FIG. shows an O-RAN architecture according to the prior art.

[0028] [Figure 2] A flowchart of a method for blocking an O cloud node using an O2 interface between an SMO function and an O cloud according to one embodiment.

[0029] [Figure 3] A diagram of an exemplary environment in which the system described herein for blocking an O cloud node can be implemented, according to one embodiment.

[0030] [Figure 4] A diagram of an exemplary environment in which the system and / or method described herein can be implemented.

[0031] [Figure 5] A diagram of exemplary components of a device, according to one embodiment.

MODE FOR CARRYING OUT THE INVENTION

[0032] The following detailed description of exemplary embodiments refers to the accompanying drawings. Like reference numerals in different drawings may identify the same or similar elements.

[0033] The foregoing disclosure provides examples and explanations, but is not intended to be exhaustive or to limit the disclosed implementation forms to the exact form. Modifications and variations are possible in light of the above disclosure or can be obtained from the implementation of the implementation forms. Furthermore, one or more features or components of one embodiment may be incorporated into (or combined with) another embodiment (or one or more features of another embodiment). In addition, 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 executed (at least partially) simultaneously, or the order of one or more operations may be interchanged.

[0034] 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, in this specification, the operation and behavior of the systems and / or methods are described without reference to specific software code. It will be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0035] 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 can 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.

[0036] 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, the term “one” or similar language should be used. Also, terms such as “has,” “have,” “having,” “include,” and “including” as used herein are intended to be non-restrictive. Furthermore, the phrase “based on” should mean “at least partially based on” unless otherwise specified. Additionally, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood to include A only, B only, or both A and B.

[0037] Exemplary embodiments of the present disclosure provide a method and system for blocking an O-cloud node to mark it as unschedulable. In particular, before the O-cloud node is released, an SMO function (e.g., at least one of FOCOM and NFO) can request the IMS / DMS to block the O-cloud node, thereby marking it as unschedulable (i.e., unschedulable) by the SMO's scheduler. Thus, embodiments of the present disclosure can avoid scheduling errors (e.g., scheduling the instantiation of a network function when the O-cloud node is released).

[0038] Figure 2 is a flowchart of a method for blocking an O cloud node according to one embodiment. The method in operation S201 in Figure 2 may be performed by a user terminal or rApp, operations S202-S203 may be performed by an SMO function (e.g., NFO and / or FOCOM), and operations S204-S205 may be performed by an IMS / DMS.

[0039] Referring to Figure 2, the isolation of one or more O-cloud nodes may be initiated in S201 by a user via a user terminal (e.g., including an application for managing network functions and / or subscribed to receive alarm events, notifications, etc. from the SMO) or by one or more rApps of non-RT RICs within the SMO. The components of the O-RAN architecture in Figures 2 and 3 are the same as those in Figure 1.

[0040] As shown in Figures 2 and 3, the availability of the SMO and the O-Cloud are assumed before the initiation of blocking of the O-Cloud node(s). In some exemplary embodiments, it can also be assumed that the O-Cloud node(s) are idle. Furthermore, it can be assumed that there is network connectivity between the SMO and the O-Cloud, that there are no active deployments (network functions) on the O-Cloud node(s), and that the user terminal or rApp is subscribed to O1 and O2 events. Furthermore, non-RT RICs or the aforementioned user terminals are configured to be subscribed to receive notifications from the SMO. According to one embodiment, the request may take the form of a trigger from the user terminal or rApp to NFO / FOCOM. The request may also include an identifier for the O-Cloud node(s) to be blocked.

[0041] In operation S202, NFO / FOCOM receives a request (first request) sent in operation S201 to block one or more O cloud nodes (one or more). According to one embodiment, upon receiving the request, NFO / FOCOM can determine whether the request is valid (for example, NFO / FOCOM can determine whether it can block the O cloud node (one or more) that has been requested to be blocked).

[0042] In operation S203, NFO / FOCOM requests IMS / DMS to block one or more O-Cloud nodes based on the first request received (second request). Here, NFO / FOCOM may request IMS / DMS to block one or more O-Cloud nodes via the O2 interface, for example, by using the O2ims service or O2dms service.

[0043] In operation S204, IMS / DMS receives the request sent by NFO / FOCOM in operation S203 and performs the action of marking one or more O cloud nodes as unschedulable, thereby blocking the aforementioned one or more O cloud nodes.

[0044] In operation S205, the IMS / DMS can notify the NFO / FOCOM to indicate the status of the blocking request, for example, that the blocking request has been completed. User terminals and / or non-RT RICs (i.e., rApps) can also receive this status update notification.

[0045] Operations S203, S204, and S205 may be looped or repeatedly executed for each of the one or more O-cloud nodes identified in the first request. Furthermore, NFO / FOCOM may determine an order for blocking one or more O-cloud nodes according to predetermined criteria or randomly, and may send a second request corresponding to each of the one or more O-cloud nodes according to this determined order.

[0046] Figure 3 shows a detailed method for implementing the isolation procedure 300 for one or more cloud nodes according to one embodiment. The method in Figure 3 is performed by a user terminal (i.e., the application installed thereon) and / or a non-RT RIC (rApp), as well as NFO / FOCOM and IMS / DMS.

[0047] Referring to Figure 3, the method for implementing the O cloud node isolation procedure 300 may be triggered by, or based on, input from the O2 interface (e.g., O2 telemetry data). According to another embodiment, the method may consider both O2 telemetry data received via the O2 interface and O1 telemetry data received via the O1 interface. For example, in the case of an NF load (e.g., compute, memory usage, etc.), rApp may take historical load data metrics, correlate the metrics with other sources (e.g., O2 and / or O1 telemetry data), use an AI / ML algorithm to predict a period of very high load (e.g., above a given threshold or metric) (e.g., the next 4 hours), and provide predictive guidance to NFO / FOCOM not to place critical performance-sensitive workloads on a particular node hosting the NF load. In this example, based on the rApp guidance, NFO / FOCOM may decide not to schedule a particular application workload on the node and / or schedule new workloads on that node during that period in scale-out operation.

[0048] In operation 301, the user terminal or non-RT RIC sends a first request to NFO / FOCOM to block one or more O cloud nodes. The first request may include an identifier for one or more O cloud nodes. This may be the same as operation S201 described in Figure 2 above.

[0049] In operation 302, NFO / FOCOM receives a first request from a non-RT RIC or user terminal to release one or more O cloud nodes. This may be the same as operation S202 described in Figure 2 above.

[0050] In operation 303, NFO / FOCOM sends a second request to IMS / DMS via the O2 interface to block one or more O cloud nodes based on the first request received. This may be the same as operation S203 described in Figure 2 above.

[0051] In operation 304, IMS / DMS shuts down each specified node. For this purpose, IMS / DMS can mark the O-cloud nodes as "unschedulable" so that the scheduler in SMO does not instantiate any new deployments (i.e., network functions) on the O-cloud nodes. This may be the same as operation S204 described in Figure 2 above.

[0052] In operation 305, in an exemplary embodiment, the IMS / DMS sends a notification to the NFO / FOCOM via the O2 interface acknowledging the completed blocking procedure. In operation S306, the IMS / DMS may similarly (or instead) send notifications to, for example, non-RT RICs (rApps) and / or user terminals (applications) based on whether they are subscribed to notifications from the IMS / DMS. Operations 305 and 306 may be similar to operation S205 described in Figure 2 above.

[0053] In one embodiment, operations 303-306 may be looped or repeatedly executed for each of the one or more O-cloud nodes identified in the first request.

[0054] According to an exemplary embodiment, the process of shutting down the O-cloud node can be easily performed upon receiving a trigger from a user terminal or a non-RT RIC (rApp), thus avoiding scheduling errors (e.g., scheduling the instantiation of network functions when the O-cloud node is free).

[0055] Figure 4 is a diagram of an exemplary environment 400 in which the systems and / or methods described herein may be implemented. As shown in Figure 4, the environment 400 may include a user device 410, a platform 420, and a network 430. The devices in environment 400 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described above with reference to Figures 2-3 may be performed by any combination of the elements shown in Figure 4.

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

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

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

[0059] The cloud computing environment 422 includes an environment that hosts platform 520. The cloud computing environment 422 may provide services such as computation, software, data access, and storage that do not require the end user's (e.g., user device 410) knowledge of the physical location and configuration of the system(s) and / or device(s) that host platform 420. As shown in the figure, the cloud computing environment 422 may include a group of computing resources 424 (collectively referred to as “computing resources 424” and individually referred to as “computing resources 424”).

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

[0061] As further shown in Figure 4, the computing resources 424 include a group of cloud resources such as one or more applications ("Applications: APPs") 424-1, one or more virtual machines ("Virtual Machines: VMs") 424-2, virtualized storage ("Virtualized Storage: VSs") 424-3, and one or more hypervisors ("Hypervisors: HYPs") 424-4.

[0062] Application 424-1 includes one or more software applications that may be provided to or accessed by the user device 410. Application 424-1 eliminates the need to install and run software applications on the user device 410. For example, Application 424-1 may include software related to platform 420 and / or any other software that may be provided via the cloud computing environment 422. In some implementations, one application 424-1 may send and receive information to and from one or more other applications 424-1 via a virtual machine 424-2.

[0063] A virtual machine 424-2 includes software implementations of a machine (e.g., a computer) that runs programs like a physical machine. Depending on its intended use and the degree to which it matches any actual machine, a virtual machine 424-2 may be either a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("Operating System: OS"). A process virtual machine may run a single program and support a single process. In some implementations, a virtual machine 424-2 may run on behalf of a user (e.g., a user device 410) and manage the infrastructure of a cloud computing environment 422, such as data management, synchronization, or long-term data transfer.

[0064] Virtualized storage 424-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of the computing resource 424. In some implementations, in the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the extraction (or separation) of logical storage from physical storage so that the storage system can be accessed regardless of whether it is physical storage or heterogeneous. Separation gives the administrator of the storage system flexibility in how the administrator manages the storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and the location where the file is physically stored. This can enable optimization of storage usage, server consolidation, and / or performance of non-disruptive file migration.

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

[0066] Network 430 includes one or more wired and / or wireless networks. For example, Network 430 may include cellular networks (e.g., Fifth Generation (5G) networks, Long-Term Evolution (LTE) networks, Third Generation (3G) networks, Code Division Multiple Access (CDMA) networks, etc.), Public Land Mobile Networks (PLMN), Local Area Networks (LAN), Wide Area Networks (WAN), Metropolitan Area Networks (MAN), telephone networks (e.g., Public Switched Telephone Networks (PSTN)), private networks, ad hoc networks, intranets, the Internet, fiber optic-based networks, etc., and / or combinations of these or other types of networks.

[0067] The number and arrangement of devices and networks shown in Figure 4 are provided as an example. In practice, there may be more additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently than those shown in Figure 4. Furthermore, two or more devices shown in Figure 4 may be implemented within a single device, or a single device shown in Figure 4 may be implemented as multiple distributed devices. In addition, or instead, a set of devices in environment 400 (e.g., one or more devices) may perform one or more functions that are described as being performed by another set of devices in environment 400.

[0068] Figure 5 shows an exemplary component of device 500. Device 500 may correspond to user device 410 and / or platform 420. As shown in Figure 5, device 500 may include a bus 510, a processor 520, memory 530, storage component 540, input component 550, output component 560, and communication interface 570.

[0069] Bus 510 includes components that enable communication between components of device 500. The processor 520 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 520 may be a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Accelerated Processing Unit (APU), microprocessor, microcontroller, Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), or another type of processing component. In some implementations, the processor 520 includes one or more processors that can be programmed to perform functions. The memory 330 comprises random access memory (RAM), read-only memory (ROM), and / or other forms of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions used by the processor 520.

[0070] The storage component 540 stores information and / or software related to the operation and use of device 500. For example, the storage component 540 may include, together with a corresponding drive, 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 floppy disk, a cartridge, magnetic tape, and / or another type of non-temporary computer-readable media. The input component 550 includes components that enable device 500 to receive information via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or microphone). In addition, or instead, the input component 550 may include sensors for sensing information (e.g., Global Positioning System (GPS) components, accelerometers, gyroscopes, and / or actuators). The output component 560 includes components that provide output information from the device 500 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

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

[0072] Device 500 may perform one or more processes described herein. Device 500 may perform these processes in response to the processor 520 executing software instructions stored in a non-temporary computer-readable medium such as memory 530 and / or storage component 540. A computer-readable medium is defined herein as a non-temporary memory device. A memory device includes a memory space within a single physical storage device or a memory space that extends across multiple physical storage devices.

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

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

[0075] The number and arrangement of components shown in Figure 5 are provided as an example. In practice, device 500 may contain more, fewer, different, or differently arranged components than those shown in Figure 5. In addition, or instead, a set of components of device 500 (e.g., one or more components) may perform one or more functions that are described as being performed by another set of components of device 500.

[0076] In the embodiments, any of the operations or processes shown in Figures 2 and 3 may be carried out by or using any one of the elements shown in Figures 4 and 5. It is understood that other embodiments may be implemented in a variety of different architectures, without limitation, such as bare-metal architectures or any cloud-based architecture or deployment architecture such as Kubernetes, Docker, or OpenStack.

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

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

[0079] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may be, 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 multipurpose discs (DVDs), 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 transmitting media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0080] The computer-readable program instructions described herein may 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 transmitting copper cables, transmitting optical fibers, wireless transmitters, 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.

[0081] Computer-readable program code / instructions for performing an operation may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, 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. Computer-readable program instructions can 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) can execute computer-readable program instructions by personalizing the electronic circuit using state information of computer-readable program instructions in order to perform an action or operation.

[0082] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device to generate a machine, thereby generating means for instructions executed via the processor of the computer or other programmable data processing device to implement functions / operations specified in one or more blocks of a flowchart and / or block diagram, or both. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a particular manner, thereby including a product in which the computer-readable storage medium internally storing the instructions includes instructions that implement modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram, or both.

[0083] These computer-readable program instructions can also be loaded into a computer, another programmable device, or another device to generate a computer implementation process that, as a result, is executed on the computer, another programmable device, or another device, performing functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0084] 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 a flowchart or block diagram may represent a microservice(s), module, segment, or part of an instruction set containing one or more executable instructions for implementing a specified logical function(s). Methods, computer systems, and computer-readable media may include more or fewer blocks, different blocks, or blocks arranged differently than those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in an order different from the order shown in the figures. For example, two consecutively shown blocks may actually be executed simultaneously or substantially simultaneously, or blocks may sometimes be executed in reverse order depending on the functionality involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0085] 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, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0086] Various embodiments

[0087] Various further embodiments and features of the embodiments of this disclosure can be defined by the following items. Item [1]: A method for blocking one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, comprising: receiving a first request by Network Function Orchestration (NFO) and / or Federated O-Cloud Orchestration and Management (FOCOM) to block at least one O-Cloud node, the first request being received from a user terminal or from a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC); the NFO / FOCOM sending a second request via an O2 interface to an Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) to block at least one O-Cloud node based on the received first request; and receiving a first notification from the IMS / DMS that at least one O-Cloud node has been blocked. Item [2]: The second request is an instruction to block the first O-cloud node of at least one O-cloud node, the first notification indicates that the first O-cloud node has been blocked, and the method is for NFO / FOCOM to send a third request to IMS / DMS via the O2 interface to block the second O-cloud node of at least one O-cloud node based on the received first request, IMS receives a second notification that the second O-cloud node has been blocked, The method described in item 1, further including the method described in item 1. Item [3]: The method described in Item [1] or [2], wherein the first request is triggered by a non-RT RIC modular application (rApp) or by a manual request submitted via a Service Management and Orchestration Framework (SMO). Item [4]: ​​The method described in any one of items [1] to [3], wherein the second request is sent only by NFO / FOCOM to IMS / DMS based on NFO / FOCOM determining that the first request to block at least one O cloud node is valid. Item [5]: The method of any one of items [1] to [4], further comprising controlling IMS / DMS to shut down at least one O cloud node based on a second request in order to mark the O cloud node as unschedulable. Item [6]: The method of any one of items [1] to [4], further comprising receiving a first notification that an O cloud node has been blocked by NFO / FOCOM from IMS / DMS via the O2 interface that at least one O cloud node has been blocked. Item [7]: The method of Item [6], further comprising receiving a first notification from NFO / FOCOM that at least one cloud node has been shut down by a non-RT RIC. Item [8]: Device for blocking one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, comprising a service management and orchestration framework (SMO) function, which receives a first request from a user terminal or from an rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC), and which, by the SMO function, sends a second request to an Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via an O2 interface to block at least one O-Cloud node based on the received first request, and which comprises at least one processor configured to execute a computer executable instruction to receive a first notification from the IMS / DMS that at least one O-Cloud node has been blocked, wherein the SMO function is at least one of federated O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO). Item [9]: The apparatus as described in Item [8], wherein a second request is an instruction to block a first O-cloud node of at least one O-cloud node, a first notification indicates that the first O-cloud node has been blocked, and at least one processor is further configured by an SMO function to execute a computer executable instruction to send a third request to the IMS / DMS via the O2 interface to block a second O-cloud node of at least one O-cloud node based on the received first request, and to receive a second notification from the IMS / DMS that the second O-cloud node has been blocked. Item

[10] : The device described in Item [8] or [9], whose first request is triggered by a non-RT RIC rApp or by a manual request submitted via a Service Management and Orchestration Framework (SMO). Item

[11] : The device described in any one of items [8] to

[10] , which is sent to the IMS / DMS only by the SMO function, based on the SMO function determining that the first request to block at least one O cloud node is valid. Item

[12] : The device described in any one of items [8] to

[11] , further configured to execute computer executable instructions to control IMS / DMS to shut down at least one O cloud node on a second request in order to mark the O cloud node as unschedulable. Item

[13] : The apparatus according to any one of items [8] to

[11] , further configured to execute a computer executable instruction for receiving a first notification that an O cloud node has been shut down, by receiving a first notification from the IMS / DMS via the O2 interface via the SMO function that at least one O cloud node has been shut down. Item

[14] : The apparatus described in Item

[13] , further configured to execute a computer executable instruction for receiving a first notification that at least one O cloud node has been shut down, by receiving a first notification from the SMO function by rApp of a non-RT RIC that at least one O cloud node has been shut down. Item

[15] : A non-temporary computer-readable storage medium recording instructions executable by at least one processor for causing at least one processor to perform a method comprising: receiving a first request by a Service Management and Orchestration Framework (SMO) function to shut down at least one O-cloud node, the first request being received from a user terminal or from an rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC); the SMO function sending a second request via an O2 interface to an Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) to shut down at least one O-cloud node based on the received first request; and receiving a first notification from the IMS / DMS that at least one O-cloud node has been shut down, wherein the SMO function is at least one of Federated O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO). Item

[16] : The non-temporary computer-readable storage medium described in Item

[15] , further comprising: a second request being an instruction to block a first O-cloud node of at least one O-cloud node; a first notification indicating that the first O-cloud node has been blocked; and a method which includes, by an SMO function, sending a third request to the IMS / DMS via the O2 interface to block a second O-cloud node of at least one O-cloud node based on the received first request; and receiving a second notification from the IMS / DMS that the second O-cloud node has been blocked. Item

[17] : A non-temporary computer-readable storage medium as described in Item

[15] or

[16] , the first request of which is triggered by a non-RT RIC rApp or by a manual request submitted via a Service Management and Orchestration Framework (SMO). Item

[18] : A non-temporary computer-readable storage medium described in any one of items

[15] to

[17] , which is sent to the IMS / DMS only by the SMO function, based on the SMO function determining that the first request to block at least one O cloud node is valid. Item

[19] : A non-temporary computer-readable storage medium as described in any one of items

[15] to

[18] , further comprising controlling IMS / DMS to shut down at least one O cloud node on a second request in order to mark the O cloud node as unschedulable. Item

[20] : A non-temporary computer-readable storage medium as described in any one of items

[15] to

[18] , further comprising receiving a first notification that an O cloud node has been shut down, via the O2 interface by the SMO function, from the IMS / DMS, that at least one O cloud node has been shut down.

[0088] In light of the above teachings, it can be seen that many modifications and variations of this disclosure are possible. Within the scope of the attached clauses, it will be apparent that this disclosure may be implemented in ways other than those specifically described herein.

Claims

1. A method for blocking one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, The Service Management and Orchestration Framework (SMO) function receives a first request to isolate at least one O-cloud node, wherein the first request is received from a user terminal or from the rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC), The SMO function transmits a second request to the Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via the O2 interface to isolate the at least one O cloud node based on the first request received. The SMO function receives a first notification from the IMS / DMS that at least one O-cloud node has been blocked, Includes, A method wherein the SMO function is at least one of federated cloud orchestration and management (FOCOM) and network function orchestration (NFO).

2. The second request is an instruction to shut down the first O-cloud node among the at least one O-cloud node, the first notification indicates that the first O-cloud node has been shut down, and the method is The SMO function transmits a third request to the IMS / DMS via the O2 interface to block the second O-cloud node among the at least one O-cloud node based on the received first request, The IMS / DMS receives a second notification that the second O-cloud node has been blocked, The method according to claim 1, further comprising:

3. The method according to claim 1, wherein the first request is triggered by the rApp of the non-RT RIC or by a manual request submitted via a Service Management and Orchestration Framework (SMO).

4. The method according to claim 1, wherein the second request is transmitted to the IMS / DMS only by the SMO function based on the SMO function determining that the first request to block the at least one O-cloud node is valid.

5. The method according to claim 1, further comprising controlling the IMS / DMS to shut down at least one O-cloud node on the second request in order to mark the O-cloud node as unschedulable.

6. Receiving the first notification that the O cloud node has been shut down, The SMO function receives the first notification from the IMS / DMS via the O2 interface that at least one O cloud node has been blocked. The method according to claim 1, further comprising:

7. Receiving the first notification that the O cloud node has been shut down, In response to receiving the first notification from the rApp, the rApp of the non-RT RIC receives the first notification from the SMO function that at least one O-cloud node has been blocked. The method according to claim 6, further comprising:

8. A device for blocking one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, wherein the device is A first request to isolate at least one O-cloud node by a Service Management and Orchestration Framework (SMO) function, which receives a first request from a user terminal or from the rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC), The SMO function sends a second request to the Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via the O2 interface to isolate the at least one O cloud node based on the first request received. The SMO function executes the computer executable instruction to receive a first notification from the IMS / DMS that at least one O-cloud node has been blocked. It is configured in such a way, An apparatus in which the SMO function is at least one of federated cloud orchestration and management (FOCOM) and network function orchestration (NFO).

9. The second request is an instruction to shut down the first O-cloud node among the at least one O-cloud node, the first notification indicates that the first O-cloud node has been shut down, and the device, The SMO function transmits a third request to the IMS / DMS via the O2 interface to block the second O-cloud node among the at least one O-cloud node based on the first request received. The IMS / DMS receives a second notification that the second O-cloud node has been blocked. The apparatus according to claim 8, further configured as follows.

10. The apparatus according to claim 8, wherein the first request is triggered by the rApp of the non-RT RIC or by a manual request submitted via the Service Management and Orchestration Framework (SMO).

11. The apparatus according to claim 8, wherein the second request is transmitted to the IMS / DMS only by the SMO function based on the SMO function determining that the first request to block the at least one O-cloud node is valid.

12. The aforementioned device is The IMS / DMS controls the blocking of at least one O-cloud node based on the second request in order to mark the O-cloud node as unschedulable. The apparatus according to claim 8, further configured as follows.

13. The aforementioned device is The SMO function receives the first notification from the IMS / DMS via the O2 interface that at least one O-cloud node has been blocked, thereby receiving the first notification that the O-cloud node has been blocked. The apparatus according to claim 8, further configured as follows.

14. The aforementioned device is In response to receiving the first notification from the rApp, the non-RT RIC receives the first notification from the SMO function that at least one O-cloud node has been blocked, thereby receiving the first notification that the O-cloud node has been blocked. The apparatus according to claim 13, further configured as follows.

15. At least one processor, The Service Management and Orchestration Framework (SMO) function receives a first request to isolate at least one O-cloud node, wherein the first request is received from a user terminal or from the rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC), The SMO function transmits a second request to the Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via the O2 interface to isolate the at least one O cloud node based on the first request received. The SMO function receives a first notification from the IMS / DMS that at least one O-cloud node has been blocked, Includes, A computer program recording instructions executable by at least one processor for causing the SMO function to perform a method in which the SMO function is at least one of federated cloud orchestration and management (FOCOM) and network function orchestration (NFO).

16. The second request is an instruction to shut down the first O-cloud node among the at least one O-cloud node, the first notification indicates that the first O-cloud node has been shut down, and the method is The SMO function transmits a third request to the IMS / DMS via the O2 interface to block the second O-cloud node among the at least one O-cloud node based on the first request received, The IMS / DMS receives a second notification that the second O-cloud node has been blocked, The computer program according to claim 15, further comprising:

17. The computer program according to claim 15, wherein the first request is triggered by the rApp of the non-RT RIC or by a manual request submitted via a Service Management and Orchestration Framework (SMO).

18. The computer program according to claim 15, wherein the second request is transmitted to the IMS / DMS only by the SMO function based on the SMO function determining that the first request to block the at least one O-cloud node is valid.

19. The IMS / DMS controls the blocking of at least one O-cloud node based on the second request in order to mark the O-cloud node as unschedulable. The computer program according to claim 15, further comprising:

20. Receiving the first notification that the O cloud node has been shut down, The SMO function receives the first notification from the IMS / DMS via the O2 interface that at least one O cloud node has been disconnected. The computer program according to claim 15, further comprising:

Images