SYSTEM AND METHOD FOR ISOLATION OF O-Cloud NODES

Abstract

A method and system for isolating open radio access network (O-RAN) cloud (O-Cloud) nodes is provided. The method may include receiving, by a service management and orchestration framework (SMO) function, a first request for isolating 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); sending, by the SMO function, a second request for isolating the at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS) via the O2 interface based on the received first request; and receiving, from the IMS / DMS, a first notification that the at least one O-Cloud node has been isolated, wherein the SMO function is at least one of Joint O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

Description

Technical Field

[0001] Systems and methods consistent with example embodiments of the present disclosure relate to isolating an Open Radio Access Network (O-RAN) Cloud (O-Cloud) node to prevent a scheduler from placing new deployments on the O-Cloud node. Background Art

[0002] The Radio Access Network (RAN) is an important component in a telecommunication system as it connects end-user equipment (or user devices) to the rest of the network. The RAN comprises a combination of various network elements (NEs) that connect end-user equipment to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific.

[0003] Open RAN (O-RAN) technology has emerged to enable multiple suppliers to provide hardware and / or software to telecommunications systems. For this purpose, O-RAN decomposes RAN functions into centralized units CU, distributed units DU, and radio units RU. CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP) and / or packet data convergence protocol (PDCP) sublayers of the RAN. DU is a logical node for hosting the radio link control (RLC), media access control (MAC) and physical (PHY) sublayers of the RAN. RU is a physical node that converts the radio signal from the antenna into a digital signal that can be sent to the DU through the fronthaul. Since there are open protocols and interfaces between these entities, they can be developed by different suppliers.

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

[0005] The Non-RT RIC is the control point of the non-real-time control loop and operates at a time scale greater than 1 second within the Service Management and Orchestration (SMO) framework. Its functions are implemented through modular applications called rApps (rApp 1, ... rApp N), and include: providing policy-based guidance and enrichment across the A1 interface, which is the interface that enables communication between the Non-RT RIC and the Near-RT RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and reasoning optimized for RAN; and / or recommending configuration management actions through the O1 interface, which is the interface that connects the SMO to the elements managed by the RAN (e.g., Near-RT RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0006] The Near-RT RIC operates on a time scale between 10 milliseconds and 1 second and is connected to the O-DU, O-CU (divided into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the open evolved NodeB (O-eNB) via the E2 interface. The Near-RT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) in a near real-time control loop. The Near-RT RIC monitors, pauses / stops, covers, and controls the E2 nodes (O-CU, O-DU, and O-eNB) via policies. For example, Near-RT sets policy parameters on the activated functions of the E2 node. In addition, the Near-RT RIC hosts xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load balancing, security, etc. The two types of RICs work together to optimize O-RAN. For example, the Non-RT RIC provides policies, data, and AI / ML models executed by the Near-RT RIC and used for RAN optimization through the A1 interface, and the Near-RT returns policy feedback (i.e., how the policies set by the NON-RT RIC work).

[0007] The SMO framework (Non-RT RICs are located in the SMO framework) manages and orchestrates RAN elements. In particular, SMO includes Joint O-Cloud Orchestration and Management (FOCOM); Network Function Orchestrator (NFO), which manages virtual network functions (VNFs) based on virtual machines (VMs) and container-based (i.e., instances) VNFs; and OAM, which is part of SMO that manages and orchestrates what is called the O-RAN Cloud (O-Cloud). O-Cloud is a collection of physical RAN nodes that host RICs, O-CUs and O-DUs, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, SMO manages O-Cloud from the inside. The O2 interface is the interface between the SMO and the O-Cloud where it is located. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS). The O2 interface can also send O2 telemetry data to the SMO, such as the O-Cloud configuration of the node or any logical function data, energy consumption, health status, etc.

[0008] In the related art, O-Cloud nodes may be drained for a variety of reasons, for example, an O-Cloud node may be drained before the node is shut down in order to perform hardware upgrades, software upgrades, kernel upgrades, energy efficiency or optimization processes, etc. However, a scheduler in an SMO that may be responsible for instantiating network functions in an O-Cloud node may not be aware that the node is being drained, and if the scheduler attempts to instantiate a network function in an O-Cloud node that is being drained, this may inadvertently cause an error. Therefore, there is a need to be able to indicate that an O-Cloud should not be able to be scheduled again (i.e., be in an unschedulable state). Summary of the invention

[0009] Example embodiments of the present disclosure provide a method and system for cordoning an O-Cloud node so as to mark the O-Cloud node as unschedulable. In particular, before the O-Cloud node is drained, the SMO function (e.g., at least one of FOCOM and NFO) may request the IMS / DMS to cordon the O-Cloud node, thus marking it as not being able to be scheduled again by the SMO's scheduler (i.e., unschedulable state).

[0010] Thus, example embodiments of the present disclosure may avoid scheduling errors (eg, scheduling instantiation of a network function while an O-Cloud node is being drained).

[0011] According to an embodiment, a method for isolating one or more open radio access network (O-RAN) cloud (O-Cloud) nodes is proposed. The method may include: receiving a first request for isolating at least one O-Cloud node by a service management and orchestration framework (SMO) function, the first request being received from a user terminal or from a rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC); based on the received first request, the SMO function sends a second request for isolating at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface; and receiving a first notification from the IMS / DMS that at least one O-Cloud node has been isolated, wherein the SMO function is at least one of joint O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO).

[0012] The second request may be an instruction for isolating a first O-Cloud node among at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, and the method may further include: based on the received first request, sending, by the SMO function via the O2 interface, a third request for isolating a second O-Cloud node among at least one O-Cloud node to the IMS / DMS; and receiving a second notification from the IMS / DMS that the second O-Cloud node has been isolated.

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

[0014] The second request may be sent by the SMO function to the IMS / DMS solely based on a determination by the SMO function that the first request to isolate at least one O-Cloud node is valid.

[0015] The method may further include: controlling, by the IMS / DMS based on the second request, to isolate at least one O-Cloud node so as to mark the O-Cloud node as unschedulable.

[0016] Receiving a first notification that the O-Cloud node has been isolated may also include: receiving, by the SMO function via the O2 interface, a first notification from the IMS / DMS that at least one O-Cloud node has been isolated

[0017] Receiving a first notification that an O-Cloud node has been isolated may also include: receiving, by the rApp of the Non-RT RIC, a first notification that at least one O-Cloud node has been isolated from a SMO function.

[0018] According to an embodiment, a device for isolating one or more open radio access network (O-RAN) cloud (O-Cloud) nodes is provided. The device may include: at least one processor, the at least one processor being configured to execute computer executable instructions to: receive a first request for isolating at least one O-Cloud node by a service management and orchestration framework (SMO) function, the first request being received from a user terminal or from a rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC); based on the received first request, the SMO function sends a second request for isolating at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface; and receive a first notification from the IMS / DMS that at least one O-Cloud node has been isolated, wherein the SMO function is at least one of joint O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO).

[0019] The second request may be an instruction for isolating a first O-Cloud node of at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, wherein the at least one processor is further configured to execute computer executable instructions to: based on the received first request, send, by the SMO function via the O2 interface, a third request to isolate a second O-Cloud node of the at least one O-Cloud node to the IMS / DMS; and receive a second notification from the IMS / DMS that the second O-Cloud node has been isolated.

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

[0021] The second request may be sent by the SMO function to the IMS / DMS solely based on a determination by the SMO function that the first request to isolate at least one O-Cloud node is valid.

[0022] The at least one processor may also be configured to execute computer executable instructions to: control, by the IMS / DMS based on the second request, to isolate at least one O-Cloud node to mark the O-Cloud node as unschedulable.

[0023] The at least one processor may also be configured to execute computer executable instructions to receive a first notification that the O-Cloud node has been isolated in the following manner: receiving, by the SMO function via the O2 interface, a first notification from the IMS / DMS that at least one O-Cloud node has been isolated.

[0024] The at least one processor may also be configured to execute computer executable instructions to receive a first notification that an O-Cloud node has been isolated by receiving, by the rApp of the Non-RT RIC, the first notification that at least one O-Cloud node has been isolated from the SMO function.

[0025] Additional aspects will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be achieved by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Features, aspects, and advantages of certain example embodiments of the present disclosure will now be described with reference to the drawings, wherein like reference numerals represent like elements, and wherein:

[0027] Figure 1 FIG. 1 illustrates an O-RAN architecture according to the related art;

[0028] Figure 2 is a flow chart of a method for isolating an O-Cloud node using an O2 interface between an SMO function and O-Cloud according to an embodiment;

[0029] Figure 3 is a diagram of an example environment in which the described system for isolating O-Cloud nodes may be implemented according to an example embodiment;

[0030] Figure 4 is a diagram of an example environment in which the described systems and / or methods may be implemented; and

[0031] Figure 5 is a diagram of example components of a device according to an embodiment. DETAILED DESCRIPTION

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

[0033] The foregoing disclosure provides explanation and description, but is not intended to exhaust implementations or to limit implementations to the disclosed precise form. According to the above disclosure, modifications and variations are possible, or modifications and variations can be obtained from the practice of implementations. In addition, one or more features or combinations of an embodiment can 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, in the flow charts and operational descriptions provided below, it should be understood that one or more operations can be omitted, one or more operations can be added, one or more operations can be performed (at least in part) simultaneously, and the order of one or more operations can be switched.

[0034] It is apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation. Therefore, the operation and behavior of the systems and / or methods are described without reference to the dedicated software code. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0035] Although particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features can be combined in a variety of ways not specifically recited in the claims and / or disclosed in the specification, and the disclosure of possible implementations includes combining each dependent claim with every other claim in the claim set.

[0036] Elements, behaviors or instructions used herein should not be interpreted as critical or necessary unless so explicitly described. Similarly, as used herein, "one" and "an" are intended to include one or more items and can be used interchangeably with "one or more". If only one item is intended to be included, the term "one" or similar terms are used. In addition, as used herein, the terms "have", "have", "have", "include", "include" or similar terms are open terms. In addition, unless otherwise explicitly stated, the phrase "based on" means "based at least in part". In addition, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0037] Example embodiments of the present disclosure provide a method and system for isolating an O-Cloud node so as to mark the O-Cloud node as unschedulable. In particular, before the O-Cloud is drained, the SMO function (e.g., at least one of FOCOM and NFO) can request the IMS / DMS to isolate the O-Cloud node, thereby marking it as not able to be scheduled again by the SMO's scheduler (i.e., unschedulable state). Therefore, embodiments of the present disclosure can avoid scheduling errors (e.g., scheduling instances of network functions when the O-Cloud node is being drained).

[0038] Figure 2 is a flowchart of a method of isolating an O-Cloud according to an embodiment. Figure 2 The method may be performed by a user terminal or rApp at operation S201, operations S202 to S203 may be performed by an SMO function (eg, NFO and / or FOCOM), and operations S204 to S205 may be performed by an IMS / DMS.

[0039] refer to Figure 2 , isolation of (multiple) O-Cloud nodes can be initiated at operation S201 by any user via a user terminal (e.g., including applications for managing network functions and / or subscribed to receive alarm events, notifications, etc. from the SMO), or by one or more rApps of the Non-RT RIC within the SMO. Figure 2 , Figure 3 Components and Figure 1 Similar to .

[0040] like Figure 2 , Figure 3 As illustrated in , before the isolation of the (multiple) O-Cloud nodes starts, the availability of the SMO and the availability of the O-Cloud are assumed. In some example embodiments, it can also be assumed that there is a network connection between the SMO and the O-Cloud, and there are no active deployments (network functions) on the (multiple) O-Cloud nodes, and the user terminals or rApps are subscribed to O1 and O2 events. In addition, the Non-RT RIC or the user terminal mentioned above is configured to be subscribed to receive notifications from the SMO. According to an embodiment, the request can be in the form of a trigger from the user terminal or rApps to the NFO / FOCOM. The request may also include an identifier of the isolated (multiple) O-Cloud node.

[0041] At operation S202, NFO / FOCOM receives the request (first request) sent in operation S201 for isolating one or more O-Cloud nodes. According to an embodiment, once NFO / FOCOM receives the request, it can determine whether the request is valid (e.g., NFO / FOCOM can determine whether the (multiple) O-Cloud nodes requested to be isolated can be isolated).

[0042] At operation S203, based on the received first request, NFO / FOCOM requests (second request) IMO / DMS to isolate one or more O-Cloud nodes. Here, NFO / FOCOM can request IMS / DMS to isolate one or more O-Cloud nodes via the O2 interface (e.g., using O2ims service or O2dms service).

[0043] At operation S204, the IMS / DMS receives the request sent by the NFO / FOCOM in operation S203, and performs an operation for marking one or more O-Cloud nodes as unschedulable, thereby isolating the one or more O-Cloud nodes.

[0044] At S205, the IMS / DMS may notify the NFO / FOCOM to indicate the status of the isolation request, for example, indicating that the isolation request has been completed. The user terminal and / or the Non-RT RIC (ie, rApp) may also receive this status update notification.

[0045] For each of the one or more O-Cloud nodes identified in the first request, operations S203, S204, and S205 may be performed in a loop or repeatedly. In addition, NFO / FOCOM may determine the order of isolating one or more O-Clouds according to a predetermined criterion or randomly, and may send a second request to one or more O-Cloud nodes, respectively, according to the determined order.

[0046] Figure 3 A detailed method for implementing an isolation process 300 of an O-Cloud node(s) according to an embodiment is illustrated. Figure 3 The method is executed by the user terminal (ie, the application installed therein) and / or the Non-RT RIC (rApp), and by the NFO / FOCOM and the IMS / DMS.

[0047] refer to Figure 3 , the method for implementing the isolation process 300 of O-Cloud can be triggered by or based on input from the O2 interface (e.g., O2 telemetry data). According to another embodiment, the method can take into account both the O2 telemetry data received through the O2 interface and the O1 telemetry data received through the O1 interface. For example, in the case of NF load (e.g., computer, memory usage, etc.), the rApp can collect historical load data indicators, correlate the indicators with other sources (e.g., O2 and / or O1 telemetry data), use AI / ML algorithms to predict very high (e.g., above a predetermined threshold or indicator) load time period (e.g., the next four hours), and provide predictive guidance to the NFO / FOCOM to avoid placing any critical performance sensitive loads on a particular node hosting the NF load. In this example, based on the rApp guidance, the NFO / FOCOM can determine not to schedule the workload of a particular application on the node during the time period, and / or not to schedule any new workloads on the node in a scaling operation.

[0048] In operation 301, a user terminal or a Non-RT RIC sends a first request to NFO / FOCOM for isolating (multiple) O-Cloud nodes. The first request may include an identifier of (multiple) O-Cloud nodes. This may be similar to the above Figure 2 Operation S201 described in .

[0049] In operation 302, NFO / FOCOM receives a first request from a Non-RT RIC or user terminal to drain the O-Cloud node(s). This may be similar to the above Figure 2 Operation S202 described in .

[0050] In operation 303, based on the received first request, NFO / FOCOM sends a second request for isolating the O-Cloud node(s) to the IMS / DMS via the O2 interface.

[0051] In operation 304, the IMS / DMS isolates each specific node. To do this, the IMS / DMS may mark the O-Cloud node as "unschedulable" so that the scheduler in the SMO will not instantiate any new deployments (i.e., network functions) on the O-Cloud node. This may be similar to the above Figure 2 Operation S204 described in .

[0052] In operation 305, in an exemplary embodiment, the IMS / DMS sends a confirmation notification of the completion of the emptying process to the NFO / FOCOM via the O2 interface. In operation S306, the IMS / DMS may also (or alternatively) send the notification to the Non-RT RIC (rApp) and / or the user terminal (application), for example, based on whether they are subscribed to notifications from the IMS / DMS. Operations 305 and 306 may be similar to the above. Figure 2 Operation S205 described in .

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

[0054] According to an example embodiment, the process of isolating an O-Cloud node can be prepared for execution when a trigger is received from a user terminal or a non-RT RIC (rApps), and thus, scheduling errors (e.g., scheduling an instance of a network function when the O-Cloud node is being drained) can be avoided.

[0055] Figure 4 4 is a diagram of an example environment 400 in which the systems and / or methods described herein may be implemented. Figure 4 As shown in FIG. 4 , environment 400 may include user device 410, platform 420, and network 430. The devices of environment 400 may be interconnected via wired connection, wireless connection, or a combination of wired connection and wireless connection. Figure 2 to Figure 3 Any functions and operations described can be Figure 4 Executes a combination of the elements shown in .

[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 a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a PDA, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a wireless phone, etc.), a wearable device (e.g., a pair of smart glasses, or a smart watch), or the like. In some implementations, user device 410 may receive information from platform 420 and / or send information to platform 420.

[0057] The platform 420 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, the platform 420 may include a cloud server or a group of cloud servers. In some implementations, the platform 420 may be designed to be modular so that certain software components may be swapped in or out based on specific needs. Thus, the platform 420 may be easily and / or quickly reconfigured for different use cases.

[0058] In some implementations, as shown, platform 420 can be hosted in computing environment 422. It is worth noting that although the implementations described herein describe platform 420 as being hosted in cloud computing environment 422, in some implementations, platform 420 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment), or may be partially cloud-based.

[0059] Cloud computing environment 422 includes an environment hosting platform 520. Cloud computing environment 422 can provide computing, software, data access, storage, etc., without requiring end users (e.g., user devices 410) to be aware of the physical location and configuration of the system(s) and / or device(s) hosting platform 420. As shown, cloud computing environment 422 can include a set of computing resources 424 (collectively referred to as "computing resources 424" and individually referred to as "computing resource 424").

[0060] The computing resources 424 include one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resources 424 can host the platform 420. Cloud resources can include computing instances executed in the computing resources 424, storage devices provided in the computing resources 424, data transmission devices provided by the computing resources 424, etc. In some implementations, the computing resources 424 can communicate with other computing resources 424 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0061] In addition, Figure 4As shown in , the computing resources 424 include a set of cloud resources, such as one or more applications ("APPs") 424-1, one or more virtual machines ("VMs") 424-2, virtualized storage devices ("VSs") 424-3, one or more virtual layers ("HYPs") 424-4, etc.

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

[0063] Virtual machine 424-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 424-2 can be a system virtual machine or a process virtual machine, depending on the purpose of virtual machine 424-2 and the degree of correspondence with any real machine. System virtual machines can provide a complete system platform that supports the execution of a complete operating system ("OS"). Process virtual machines can execute a single program and can support a single process. In some implementations, virtual machine 424-2 can be executed on behalf of a user (e.g., user device 410) and can manage the infrastructure of 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 using virtualization technology in the storage system or computing resource 424. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, so that the storage system can access it without relying on physical storage or heterogeneous structures. This separation may allow administrators of the storage system to have flexibility in how to manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the physical storage location of the file. This may enable optimization of the performance of storage usage, server consolidation, and / or non-disruptive file migration.

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

[0066] The network 430 includes one or more wired and / or wireless networks. For example, the network 430 may include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, or the like, and / or a combination of these or other types of networks.

[0067] Figure 4 The number and arrangement of devices and networks shown in FIG. 1 are provided as examples. In practice, there may be more than Figure 4 More devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. In addition, Figure 4 Two or more devices shown in the figure may be implemented in a single device, or Figure 4 The single device shown in the environment 400 may be implemented as multiple distributed devices. Additionally, or alternatively, a group of devices (eg, one or more devices) in the environment 400 may perform one or more functions described as being performed by another group of devices in the environment 400.

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

[0069] The bus 510 includes components that allow communication between components of the device 500. The processor 520 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 520 can be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. In some implementations, the processor 320 includes one or more processors that can be programmed to perform functions. The memory 330 includes a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, and / or optical storage) that stores information and / or instructions for use by the processor 520.

[0070] Storage component 540 stores information and / or software related to the operation and use of device 500. For example, storage component 540 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another non-transient computer-readable medium, and a corresponding drive. Input component 550 includes components that allow device 500 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). In addition, or alternatively, input component 550 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 560 includes components that provide output information from device 500 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).

[0071] The communication interface 570 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the device 500 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. The communication interface 570 can allow the device 500 to receive information from another device and / or provide information to another device. For example, the communication interface 570 can include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0072] Device 500 may execute one or more processors described herein. Device 500 may execute these processes in response to processor 520 executing software instructions stored in a non-transient computer-readable medium (such as memory 530 and / or storage component 540). Herein, a computer-readable medium is defined as a non-transient memory device. A memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

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

[0074] Additionally, or alternatively, hardwired circuitry 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 specific combination of hardware circuitry and software.

[0075] Figure 5 The number and arrangement of components shown in FIG. 5 are provided as examples. In practice, the device 500 may include more Figure 5 More components, fewer components, different components, or components arranged differently than those shown in the drawings. Additionally, or alternatively, one set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500.

[0076] In an embodiment, Figure 2 and Figure 3 Any operation or process in Figure 4 and Figure 5 It should be understood that other embodiments are not limited thereto and can be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architecture, such as Kubernetes, Docker, OpenStack, etc.).

[0077] The above disclosure provides illustration and description, but is not intended to be exhaustive of implementations or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be obtained from practice of the implementations.

[0078] Some embodiments may involve systems, methods and / or computer-readable media at any possible level of technical detail integration. In addition, one or more components described above may be implemented as instructions stored on a computer-readable medium and executed by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transient storage medium (or medium) having computer-readable program instructions stored thereon for causing the processor to perform operations.

[0079] Computer readable storage medium can be a tangible device that can save and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example, but not limited to electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the above. More specific examples of computer readable storage medium include, but are not limited to, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), portable compact disc read-only memories (CD-ROM), digital versatile discs (DVD), memory sticks, floppy disks, mechanical encoding devices (such as convex structures in punched cards or grooves, on which instructions are recorded), and any suitable combination of the above. Computer readable storage medium used in this article should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses propagated by optical fiber cables), or electrical signals transmitted by wires.

[0080] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing device / processing device, or downloaded to an external computer or external storage device via a network (e.g., 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. The network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and forwards the instructions to be stored in a computer-readable storage medium in each computing device / processing device.

[0081] The computer readable program code / instructions for performing the operation may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data of the integrated circuit system, or source code or object code written in one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as C language or similar languages). The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as an independent 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 case, the remote computer may be connected to the user's computer via any type of network (including a local area network or a wide area network), or connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, the electronic circuit system includes, for example, a programmable logic circuit system, a field programmable gate array, or a programmable logic array may execute computer readable program instructions by utilizing the state information of the computer readable program instructions to personalize the electronic circuit system so as to perform various aspects or operations.

[0082] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce an article of manufacture, so that when the instructions are executed via the processor of the computer or other programmable data processing device, a component for implementing the function / action specified in one or more boxes of the flowchart and / or block diagram is created. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct a computer, a programmable data processing device, and / or other devices to work in a specific manner, so that the computer-readable storage medium storing the instructions includes an article of manufacture, which includes instructions for implementing aspects of the function / action specified in one or more boxes of the flowchart and / or block diagram.

[0083] These computer-readable program instructions may also be loaded into a computer, other programmable data processing device, or other device to cause a series of operating steps on the computer, other programmable device, or other device to produce a computer-implemented process, whereby the instructions executed on the computer, other programmable device, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0084] The flowchart and block diagram in the figure illustrate the architecture, function and operation of the possible implementation of the computer-readable medium of the system and method according to various embodiments. In this regard, each box in the flowchart or block diagram can represent a part of a microservice, module, segment or instruction, which includes one or more executable instructions for implementing the specified (multiple) logical functions. The method, computer system and computer-readable medium may include more boxes, fewer boxes, different boxes, or boxes arranged differently compared to the boxes described in the figure. In some alternative implementations, the functions marked in the box may appear in an order inconsistent with the order marked in the figure. For example, two consecutively displayed boxes can actually be executed at the same time, or substantially at the same time, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart description and the combination of boxes in the block diagram and / or flowchart description can be implemented by a system based on special-purpose hardware, which performs the specified function or behavior, or performs a combination of special-purpose hardware and computer instructions.

[0085] It is apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods described herein do not involve specific software code - it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0086] Various aspects of the embodiments

[0087] Various other corresponding aspects and features of the embodiments of the present disclosure may be defined by the following items:

[0088] Item [1]: A method for isolating one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, the method comprising: receiving, by a service management and orchestration framework (SMO) function, a first request for isolating 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); based on the received first request, sending, by the SMO function, via an O2 interface, a second request for isolating at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS); and receiving, from the IMS / DMS, a first notification that at least one O-Cloud node has been isolated.

[0089] Item [2]: The method of item [1], wherein the second request is an instruction to isolate a first O-Cloud node among the at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, the method further comprising: based on the received first request, sending, by the SMO function via the O2 interface, a third request to isolate a second O-Cloud node among the at least one O-Cloud node to the IMS / DMS; and

[0090] A second notification is received from the IMS that the second O-Cloud node has been isolated.

[0091] Item [3]: The method according to Item [1] to Item [2], wherein the first request is triggered by an rApp of a Non-RT RIC, or by a manual request submitted via a service management and orchestration framework (SMO).

[0092] Item [4]: ​​A method according to items [1] to [3], wherein the second request is sent by NFO / FOCOM to the IMS / DMS based on a determination by NFO / FOCOM that the first request for isolating the at least one O-Cloud node is valid.

[0093] Item [5]: The method according to Item [1] to Item [4], wherein receiving a first notification that an O-Cloud node has been isolated also includes: based on a second request, the IMS / DMS controls the isolation of at least one O-Cloud node to mark the O-Cloud node as unschedulable.

[0094] Item [6]: The method according to Item [1] to Item [4], wherein receiving a first notification that an O-Cloud node has been isolated further comprises: receiving, by NFO / FOCOM via an O2 interface, a first notification from IMS / DMS that at least one O-Cloud node has been isolated.

[0095] Item [7]: The method according to Item [6], wherein receiving a first notification that an O-Cloud node has been isolated also includes: receiving, by the Non-RT RIC from the NFO / FOCOM, a first notification that at least one O-Cloud node has been isolated.

[0096] Item [8]: A device for isolating one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, the device comprising: at least one memory storing computer executable instructions; and at least one processor configured to execute the computer executable instructions to: receive a first request for isolating at least one O-Cloud node by a service management and orchestration framework (SMO) function, the first request being received from a user terminal or from an rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC); based on the received first request, send a second request for isolating at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface by the SMO function; and receive a first notification from the IMS / DMS that at least one O-Cloud node has been isolated, wherein the SMO function is at least one of joint O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO).

[0097] Item [9]: An apparatus according to Item [8], wherein the second request is an instruction for isolating a first O-Cloud node of at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, and wherein at least one processor is further configured to execute computer-executable instructions to: based on the received first request, send a third request for isolating a second O-Cloud node of at least one O-Cloud node to the IMS / DMS via the O2 interface by the SMO function; and receive a second notification from the IMS / DMS that the second O-Cloud node has been isolated.

[0098] Item

[10] : An apparatus according to any one of Items [8] to [9], wherein the first request is triggered by a rApp of a Non-RT RIC, or by a manual request submitted via a service management and orchestration framework (SMO).

[0099] Item

[11] : An apparatus according to any one of items [8] to

[10] , wherein the second request is sent by the SMO function to the IMS / DMS based on the SMO function determining that the first request for isolating at least one O-Cloud node is valid.

[0100] Item

[12] : An apparatus according to any one of items [8] to

[11] , wherein at least one processor is further configured to execute the computer executable instructions to: control by the IMS / DMS based on a second request to isolate at least one O-Cloud node to mark the O-Cloud node as unschedulable.

[0101] Item

[13] : An apparatus according to Item

[13] , wherein at least one processor is further configured to execute computer executable instructions to receive a first notification that an O-Cloud node has been isolated in the following manner: a first notification that at least one O-Cloud node has been isolated is received from an IMS / DMS via an O2 interface by a SMO function.

[0102] Item

[14] : An apparatus according to Item

[13] , wherein at least one processor is further configured to execute computer executable instructions to receive a first notification that an O-Cloud node has been isolated in the following manner: the rApp of the Non-RT RIC receives a first notification from the SMO function that at least one O-Cloud node has been isolated.

[0103] Item

[15] : A non-transitory computer-readable recording medium having instructions recorded thereon, the instructions being executable by at least one processor to cause the at least one processor to execute a method, the method comprising: receiving, by a service management and orchestration framework (SMO) function, a first request for isolating 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); based on the received first request, sending, by the SMO function, via an O2 interface, a second request for isolating at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS); and receiving, from the IMS / DMS, a first notification that at least one O-Cloud node has been isolated, wherein the SMO function is at least one of joint O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO).

[0104] Item

[16] : A non-transitory computer-readable recording medium according to Item

[15] , wherein the second request is an instruction of a first O-Cloud for isolating at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, and the method further includes: based on the received first request, sending a third request for isolating a second O-Cloud node among the at least one O-Cloud node to the IMS / DMS via the O2 interface by the SMO function; and receiving a second notification from the IMS / DMS that the second O-Cloud node has been isolated.

[0105] Item

[17] : A non-transitory computer-readable recording medium as described in any one of Items

[15] to

[16] , wherein the first request is triggered by an rApp of a Non-RT RIC, or by a manual request submitted via a service management and orchestration framework (SMO).

[0106] Item

[18] : A non-transitory computer-readable recording medium as described in any one of Items

[15] to

[17] , wherein the second request is sent by the SMO function to the IMS / DMS based on the SMO function determining that the first request for isolating at least one O-Cloud node is valid.

[0107] Item

[19] : The non-volatile computer-readable recording medium described in any one of Items

[15] to

[18] further includes: controlling by the IMS / DMS based on a second request to isolate at least one O-Cloud node to mark the O-Cloud node as unschedulable.

[0108] Item

[20] : A non-transitory computer-readable recording medium according to any one of Items

[15] to

[18] , wherein receiving a first notification that an O-Cloud node has been isolated further comprises: receiving, by the SMO function via the O2 interface, a first notification from the IMS / DMS that at least one O-Cloud node has been isolated.

[0109] It will be appreciated that numerous modifications and variations of the invention are possible in light of the above teachings.It will be apparent that within the scope of the appended clauses, the present disclosure may be practiced otherwise than as specifically described herein.

Claims

1. A method for isolating one or more Open Radio Access Network (O-RAN) cloud (O-Cloud) nodes, the method comprising: Receiving, by a service management and orchestration framework (SMO) function, a first request for isolating at least one O-Cloud node, the first request being received from a user terminal or from a rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC); Based on the received first request, the SMO function sends a second request to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface for isolating the at least one O-Cloud node; and receiving a first notification from the IMS / DMS that the at least one O-Cloud node has been isolated, The SMO function is at least one of Joint O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

2. The method of claim 1, wherein the second request is an instruction to isolate a first O-Cloud node of the at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, the method further comprising: Based on the received first request, the SMO function sends a third request to the IMS / DMS via the O2 interface for isolating a second O-Cloud node in the at least one O-Cloud node; and A second notification is received from the IMS / DMS that the second O-Cloud node has been isolated. 3 . The method according to claim 1 , wherein the first request is triggered by an rApp of the Non-RT RIC or by a manual request submitted via a service management and orchestration framework (SMO).

4. The method of claim 1, wherein the second request is sent by the SMO function to the IMS / DMS only based on a determination by the SMO function that the first request to isolate the at least one O-Cloud node is valid.

5. The method according to claim 1, further comprising: The IMS / DMS controls, based on the second request, to isolate the at least one O-Cloud node to mark the O-Cloud node as unschedulable.

6. The method of claim 1, wherein receiving the first notification that the O-Cloud node has been isolated further comprises: The first notification that the at least one O-Cloud node has been isolated is received by the SMO function from the IMS / DMS via the O2 interface.

7. The method of claim 6, wherein receiving the first notification that the O-Cloud node has been isolated further comprises: The first notification that the at least one O-Cloud node has been isolated is received by the rApp of the Non-RT RIC from the SMO function.

8. An apparatus for isolating one or more open radio access network (O-RAN) cloud (O-Cloud) nodes, the apparatus comprising: at least one memory storing computer executable instructions; as well as at least one processor configured to execute the computer-executable instructions to: Receiving, by a service management and orchestration framework (SMO) function, a first request for isolating 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); Based on the received first request, the SMO function sends a second request to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface for isolating the at least one O-Cloud node; and receiving a first notification from the IMS / DMS that the at least one O-Cloud node has been isolated, The SMO function is at least one of Joint O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

9. The apparatus of claim 8, wherein the second request is an instruction to isolate a first O-Cloud node of the at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, wherein the at least one processor is further configured to execute the computer-executable instructions to: Based on the received first request, the SMO function sends a third request to the IMS / DMS via the O2 interface for isolating a second O-Cloud node in the at least one O-Cloud node; and A second notification is received from the IMS / DMS that the second O-Cloud node has been isolated.

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

11. The apparatus of claim 8, wherein the second request is sent by the SMO function to the IMS / DMS only based on a determination by the SMO function that the first request to isolate the at least one O-Cloud node is valid.

12. The apparatus of claim 8, wherein the at least one processor is further configured to execute the computer executable instructions to: The IMS / DMS controls, based on the second request, to isolate the at least one O-Cloud node to mark the O-Cloud node as unschedulable.

13. The apparatus of claim 8, wherein the at least one processor is further configured to execute the computer-executable instructions to receive the first notification that the O-Cloud node has been isolated by: The first notification that the at least one O-Cloud node has been isolated is received by the SMO function from the IMS / DMS via the O2 interface.

14. The apparatus of claim 13, wherein the at least one processor is further configured to execute the computer executable instructions to receive the first notification that the O-Cloud node has been isolated by: The first notification that the at least one O-Cloud node has been isolated is received by the rApp of the Non-RT RIC from the SMO function.

15. A non-transitory computer-readable recording medium having instructions recorded thereon, the instructions being executable by at least one processor to cause the at least one processor to perform a method, the method comprising: Receiving, by a service management and orchestration framework (SMO) function, a first request for isolating at least one O-Cloud node, the first request being received from a user terminal or from a rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC); Based on the received first request, the SMO function sends a second request to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface for isolating the at least one O-Cloud node; and receiving a first notification from the IMS / DMS that the at least one O-Cloud node has been isolated, The SMO function is at least one of Joint O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

16. The non-transitory computer-readable recording medium of claim 15, wherein the second request is an instruction to isolate a first O-Cloud of the at least one O-Cloud node, wherein the first notification indicates that the first O-Cloud node has been isolated, the method further comprising: Based on the received first request, the SMO function sends a third request to the IMS / DMS via the O2 interface for isolating a second O-Cloud node in the at least one O-Cloud node; and A second notification is received from the IMS / DMS that the second O-Cloud node has been isolated.

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

18. The non-transitory computer-readable recording medium of claim 15, wherein the second request is sent by the SMO function to the IMS / DMS only based on a determination by the SMO function that the first request to isolate the at least one O-Cloud node is valid.

19. The non-transitory computer-readable recording medium according to claim 15, further comprising: The IMS / DMS controls, based on the second request, to isolate the at least one O-Cloud node to mark the O-Cloud node as unschedulable.

20. The non-transitory computer-readable recording medium of claim 15, wherein receiving the first notification that the O-Cloud node has been isolated further comprises: The first notification that the at least one O-Cloud node has been isolated is received by the SMO function from the IMS / DMS via the O2 interface.

Images