System and method for draining an O-Cloud node

Abstract

A method, system, and SMO and O-Cloud are provided for draining one or more O-Cloud nodes based on a recommendation from an rApp or manually by an O-Cloud administrator via a Service Management and Orchestration Framework (SMO). In particular, the method may include receiving, by an SMO function, a first request or recommendation to drain at least one O-Cloud node, the first request or recommendation being received from an rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) or from an O-Cloud administrator, sending, by the SMO function, a second request to drain the at least one O-Cloud node based on the first request or recommendation received 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 regarding whether the at least one O-Cloud node has been drained, where 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 draining nodes of an open radio access network (O-RAN) cloud (O-Cloud (O cloud)).

Background Art

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

[0003] To enable multiple vendors to provide hardware and / or software to a telecommunications system, Open Radio Access Network (O-RAN) technology has emerged. For this purpose, O-RAN decomposes RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU is a logical node that hosts sublayers of the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) of the RAN. The DU is a logical node that hosts sublayers of the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) of the RAN. The RU is a physical node that converts radio signals from an antenna into digital signals that can be transmitted to the DU through the fronthaul. Since these entities have open protocols and interfaces between them, they can be developed by various vendors.

[0004] Figure 1 shows the O-RAN architecture of related technologies. Referring to Figure 1, the RAN functions in the O-RAN architecture are controlled and optimized by the RIC. The RIC is a software-defined component that implements a modular application that facilitates multi-vendor operability required in the O-RAN system and automates and optimizes the operation of the RAN. The RIC is divided into two types: Non-Real-Time RIC (Non-RT RIC) and Near-Real-Time RIC (Near-RT RIC).

[0005] The non-real-time RIC is a control point in the non-real-time control loop and operates on a time scale exceeding one second within the framework of Service Management and Orchestration (SMO). Its functionality is implemented via modular applications called rApps (rApp 1,..., rApp N), providing policy-based guidance and enhancement across the A1 interface, which is an interface enabling communication between the non-real-time RIC and the near-real-time RIC, performing data analysis, i.e., training and inference of Artificial Intelligence / Machine Learning (AI / ML) for RAN optimization, and / or recommending configuration management actions via the O1 interface, which is an interface connecting SMO to RAN management target elements (e.g., near-real-time RIC, O-RAN Central Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0006] The near-real-time RIC operates on a time scale between 10 milliseconds and 1 second and connects via the E2 interface to the O-DU, the O-CU (which is separated into an O-CU control plane (O-CU-CP) and an O-CU user plane (O-CU-UP)), and the open evolved NodeB (O-eNB). The near-real-time RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) via a near-real-time control loop. The near-real-time RIC monitors, pauses / stops, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) through policies. For example, the near-real-time sets policy parameters for the activated functions of the E2 nodes. Further, the near-real-time RIC hosts xApps and implements functions such as quality of service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load distribution, and security. Two types of RICs operate together to optimize the O-RAN. For example, the non-real-time RIC provides, via the A1 interface, the policies, data, and AI / ML models that are executed and used by the near-real-time RIC for RAN optimization, and the near-real-time returns policy feedback (i.e., how the policies set by the non-real-time RIC function).

[0007] The SMO framework in which the non-real-time RIC is deployed manages and organizes the RAN elements. Specifically, the SMO includes Federated O-Cloud Orchestration and Management (FOCOM), the Network Function Orchestrator (NFO) that manages virtual machine (VM)-based virtual network functions (VNFs) and container (i.e., instance)-based VNFs, and the OAM as part of the SMO that manages and organizes what is called O-RAN-Cloud (O-Cloud). O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, support software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages O-Cloud from within. The O2 interface is the interface between the 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 may also send O2 telemetry data, such as O-Cloud configuration or any logical function data, energy consumption, the health status of nodes, etc., to the SMO.

[0008] In the prior art, it may be necessary to optimize O-Cloud resources in order to eliminate waste of O-Cloud resources. In particular, certain O-Cloud nodes that are created may encounter performance problems, be in an idle state, or have signs of future failure. Therefore, it is necessary to be able to proactively manage O-Cloud resources by predicting O-Cloud node failures and acting accordingly (e.g., by selecting, provisioning, and sizing resources within the O-Cloud). SUMMARY OF THE INVENTION MEANS FOR SOLVING THE PROBLEM

[0009] Exemplary embodiments of the present disclosure provide a method and system for SMO and O-Cloud to drain (deplete) one or more O-Cloud nodes based on recommendations from rApp or manually by an O-Cloud maintainer via SMO. In particular, when an O-Cloud node (group) is drained, the O-Cloud node (group) is marked as cordoned off or unschedulable. Therefore, there may be a need to relocate, migrate, or terminate its network function or components of the network function to another O-Cloud node. According to an embodiment, the request to drain an O-Cloud node (group) may be based on a recommendation (e.g., based on metric data). Thus, in the embodiments of the present disclosure, waste of O-Cloud resources can be eliminated, O-Cloud node failures can be predicted, and O-Cloud resources can be proactively managed accordingly.

[0010] According to one embodiment, it is possible to provide a method for draining one or more Open Radio Access Network (O-RAN) cloud (O-Cloud (Oクラウド)) nodes. The method includes receiving, by a Service Management and Orchestration Framework (SMO) function, a first request or recommendation for draining at least one O-Cloud node, where the first request or recommendation is received from an rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) or an O-Cloud administrator; sending, by the SMO function, to a Baseband Management Service (IMS) and / or a Deployment Management Service (DMS) via an O2 interface, a second request for draining at least one O-Cloud node based on the received first request or recommendation; and receiving, by the SMO function, a first notification from the IMS / DMS regarding whether at least one O-Cloud node has been drained, where the SMO function is at least one of Federation O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

[0011] According to one embodiment, the second request may be an instruction to drain a first O-Cloud node of at least one O-Cloud node, where the first notification indicates that the first O-Cloud node has been drained, and where the method further includes sending, by the SMO function, to the IMS / DMS via the O2 interface, a third request for draining a second O-Cloud node of at least one O-Cloud node based on the received first request or recommendation.

[0012] According to one embodiment, the first request or recommendation may be based on metric data and / or observability data received by the rApp or the O-Cloud administrator via O1-related services and / or O2-related services.

[0013] According to one embodiment, the SMO function may send to the IMS / DMS based on a determination by the SMO function to accept a first request or recommendation to drain at least one O-Cloud node.

[0014] According to one embodiment, the first notification may indicate that at least one O-Cloud node was not drained or that an exception occurred.

[0015] According to one embodiment, the first notification may indicate that at least one O-Cloud node was drained, where receiving the first notification comprises receiving, from the IMS / DMS by the SMO function via the O2 interface, the first notification that at least one O-Cloud node was drained.

[0016] According to one embodiment, the method may further include notifying, by the SMO function, the non-real-time RIC or the rApp of the O-Cloud administrator that at least one O-Cloud node was drained.

[0017] According to one embodiment, an apparatus for draining one or more Open Radio Access Network (O-RAN) Cloud (O-Cloud) nodes may be provided. The apparatus includes 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 or recommendation for draining at least one O-Cloud node by a Service Management and Orchestration Framework (SMO) function. The first request or recommendation is received from an rApp of a Non-Real-Time (Non-RT) Radio Access Network Intelligent Controller (RIC) or an O-Cloud administrator. The SMO function transmits a second request for draining at least one O-Cloud node to an Infrastructure Management Service (IMS) and / or a Deployment Management Service (DMS) via an O2 interface based on the received first request or recommendation, and is configured to receive a first notification from the IMS / DMS regarding whether at least one O-Cloud node has been drained. Here, the SMO function is at least one of Federation O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

[0018] According to one embodiment, the second request may be an instruction to drain a first O-Cloud node of at least one O-Cloud node. Here, the first notification indicates that the first O-Cloud node has been drained. Here, the at least one processor is further configured to execute computer-executable instructions for the SMO function to transmit a third request for draining a second O-Cloud node of at least one O-Cloud node to the IMS / DMS via the O2 interface based on the received first request or recommendation. The first request or recommendation may be based on metric data and / or observability data received by the rApp or the O-Cloud administrator via O1-related services and / or O2-related services.

[0019] According to one embodiment, the SMO function may send to the IMS / DMS based on the determination that the SMO function accepts a first request or recommendation for draining at least one O-Cloud node.

[0020] According to one embodiment, the first notification may indicate that at least one O-Cloud node was not drained or that an exception occurred.

[0021] According to one embodiment, the first notification may be able to indicate that at least one O-Cloud node has been drained, where at least one processor is further configured to execute computer-executable instructions to receive the first notification from the IMS / DMS via the O2 interface by the SMO function, that is, to receive the first notification that at least one O-Cloud node has been drained.

[0022] According to one embodiment, at least one processor may be further configured to execute computer-executable instructions to notify the rApp of the non-real-time RIC or the O-Cloud administrator that at least one O-Cloud node has been drained by the SMO function.

[0023] Further aspects are described in part in the following description, will become apparent in part from the description, or can be realized by the practice of the presented embodiments of the present disclosure.

Brief Description of the Drawings

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

[0025]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

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

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

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

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

[0030] Elements, operations, or instructions used in this specification should not be construed as such unless explicitly described as important or essential. Also, the articles "a" and "an" used in this specification are intended to include one or more items and may be used synonymously with "one or more". When only one item is intended, the term "one" or a similar expression is used. Also, terms such as "has", "have", "having", "include", "including", etc. used in this specification are intended to be non-limiting terms. Furthermore, the phrase "based on" is intended to mean "based, at least in part, on" unless otherwise specified. Additionally, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0031] Exemplary embodiments relate to O-Cloud resource optimization, which is a process of efficiently utilizing O-Cloud resources, selecting, provisioning, and sizing resources within the O-Cloud to eliminate waste of O-Cloud resources. According to an exemplary embodiment, network functions (NFs) within the O-Cloud are organized as VNFs / CNFs. SMO (NFO, FOCOM) handles the management and orchestration of VNFs / CNFs and the underlying O-Cloud infrastructure. The management, orchestration, and optimization functions of SMO can be enhanced by exemplary embodiments through intelligent observability analysis from VNFs / CNFs and the O-Cloud.

[0032] The non-real-time RIC can host third-party applications such as rApps within the SMO and collect and read various O1-related and O2-related observability data and metrics via O1-related services and O2-related services. These third-party rApps can be utilized in exemplary embodiments to provide guidance and / or recommendations to the NFO and FOCOM regarding the management, orchestration, and optimization of VNFs / CNFs and the underlying O-Cloud infrastructure.

[0033] Exemplary embodiments of the present invention disclosure provide a method and system for the SMO and O-Cloud to drain one or more O-Cloud nodes either based on recommendations from rApps or manually by the O-Cloud administrator via the SMO. In particular, when an O-Cloud node (group) is drained, the O-Cloud node (group) is marked as blocked or unschedulable. Therefore, there may be a need for means to relocate, migrate, or terminate its network function or components of the network function to another O-Cloud node. According to the embodiment, the request to drain an O-Cloud node (group) may be based on recommendations (e.g., based on metric data). Thus, in the embodiments of the present invention disclosure, waste of O-Cloud resources can be eliminated, O-Cloud node failures can be predicted, and the O-Cloud resources can be proactively managed accordingly.

[0034] Figure 2 is a flowchart of a method 200 for draining an O-Cloud node according to an embodiment. One of the goals of method 200 may be to drain the O-Cloud node(s) by blocking or labeling the node(s) as unschedulable, thereby safely evicting / migrating all of the network function(s) and / or its components from their respective O-Cloud node(s). The method in Figure 2 at operation S201 may be executed by an O-Cloud administrator or a user terminal of an rApp (via a non-real-time RIC), operations S202 to S203 may be executed by an SMO function (e.g., NFO and / or FOCOM), and operations S204 to S205 may be executed by an IMS / DMS. It should be understood that the O-Cloud node(s) to be drained may host network functions at the time of executing method 200.

[0035] Referring to Figure 2, draining the O-Cloud node(s) can be initiated at operation S201 by one or more rApps of a user terminal or a non-real-time RIC within the SMO. That is, the user terminal may manually provide a request to the FOCOM / NFO to drain the node, or the rApp may provide a recommendation to the FOCOM / NFO to drain the node. According to an embodiment, the rApp may be an application hosted by a non-real-time RIC within the SMO. The rApp may be from a third party. The rApp can collect and read various O1-related and O2-related observability data and metrics via O1-related services and O2-related services. Thus, in some embodiments, the rApp can be used to provide guidance and / or recommendations for the management, orchestration, and optimization of VNFs and / or container network functions (CNFs) and the underlying O-Cloud infrastructure to the NFO and FOCOM.

[0036] According to one embodiment, the rApp can drain the rApp using a data-driven approach that provides recommendations to the SMO and / or O-Cloud based on O1-related and O2-related observability data and metrics. It should be understood that in some embodiments, other data other than O1-related and O2-related observability data and metrics may be used to provide recommendations. It should be understood that there are various scenarios where it is necessary to drain the O-Cloud nodes. One exemplary scenario may be where, with the help of artificial intelligence and / or machine learning (AI / ML), the rApp can be used to provide insights regarding O-Cloud failures to the FOCOM / NFO. Thus, in some embodiments, artificial intelligence and / or machine learning (AI / ML) may be used. The rApp can predict that an O-Cloud node failure will occur and accordingly recommend to the FOCOM / NFO to drain the O-Cloud node, thereby proactively migrating the workload away from the O-Cloud node. During this NF migration, as a result of the node drain recommendation from the rApp, the network can be guaranteed service continuity and quality of service, and overall disruption can be minimized. According to one embodiment, the SMO can play a role in managing the relocation of the NF. The SMO (FOCOM / NFO) can support the ability to receive recommendations for draining the O-Cloud node(s). The SMO can support the ability to send an O-Cloud node drain request to the O-Cloud (IMS / DMS) via the O2 interface. The SMO can also support the ability to receive an O-Cloud node drain response from the O-Cloud (IMS / DMS) on the O2 interface. The request to drain the O-Cloud node(s) can be done manually or the rApp can also send the recommendation to the FOCOM / NFO. In embodiments, a data-driven approach for optimizing O-Cloud resources may be implemented.As described above, the rApp within the non-real-time RIC can utilize an AI / ML framework that can provide guidance to the FOCOM / NFO to complement its scheduling capabilities, thereby enabling the system to make more data-driven placement decisions.

[0037] When draining the O-Cloud node(s), the O-Cloud node(s) are marked as being blocked or unschedulable. Thus, there may be a need to relocate, migrate, or terminate its network function or a component of the network function to another O-Cloud node. In some embodiments, draining the O-Cloud node may include setting the O-Cloud node to maintenance mode. It should also be understood that either the IMS or the DMS may receive a request to drain the O-Cloud node. It should also be understood that either the IMS or the DMS may receive a request to drain the O-Cloud node. The components of the O-RAN architecture in FIGS. 2, 3, and 4 may be similar to the components according to FIG. 1. In other embodiments, the request to drain the node may be sent by a user (e.g., an O-Cloud administrator) via a user terminal (e.g., including an application that manages network functions and / or reserves to receive alarm events, notifications, etc. from the SMO).

[0038] As shown in FIGS. 2, 3, and 4, prior to the drain start of the O-Cloud node(s), the request to the SMO may be assumed to include the identifier (ID) of the O-Cloud node to be drained. To drain the O-Cloud node, it may be assumed based on a request from the O-Cloud administrator or a recommendation from the rApp, or based on a trigger received from the FOCOM / NFO. It can also be assumed that the data traffic from the O-Cloud node(s) that need to be drained has been moved or relocated before triggering the drain procedure. Further, according to some embodiments, the preconditions for triggering the request may include verification that the SMO and the O-Cloud are available, and that a monitoring system that can monitor O1 events and O2 events has been reserved by the O-Cloud administrator and / or the rApp. Therefore, if the existing O-Cloud node(s) are determined to be drained based on a request from the O-Cloud administrator or a recommendation from the rApp, the process may proceed.

[0039] In operation S202, the FOCOM / NFO receives and processes the request or recommendation (the first request) sent in operation S201 to drain one or more O-Cloud node(s). For example, the FOCOM / NFO can process the request or recommendation by implementing one or more logics (e.g., logics including one or more thresholds, conditions, parameters, etc. for determining whether to request the IMS / DMS to drain one or more O-Cloud node(s) in response to a request / recommendation from the O-Cloud administrator and / or the rApp) for determining whether to accept the request or recommendation. According to one embodiment, when the FOCOM / NFO receives the request, the FOCOM / NFO can determine whether the request is valid (e.g., the FOCOM / NFO can determine whether it can drain the O-Cloud node(s) requested to be drained).

[0040] In operation S203, FOCOM / NFO requests the IMS / DMS to drain one or more O-Cloud nodes based on the received first request (second request). Operation S203 may be executed when a recommendation from the rApp or a request from the O-Cloud administrator to FOCOM / NFO is accepted in operation S202. Here, FOCOM / NFO may request the IMS / DMS to drain one or more O-Cloud nodes via the O2 interface, for example, using the O2ims service or the O2dms service. Further, according to one embodiment, FOCOM / NFO may request the IMS / DMS to drain one or more O-Cloud node(s) based on the processing of operation S202 (e.g., based on its internal logic for determining to accept a request or a recommendation). Alternatively, if FOCOM / NFO determines not to accept a request / recommendation in operation S202, the process may end. According to another embodiment, FOCOM / NFO may be configured to always permit a request or a recommendation.

[0041] In operation S204, the IMS / DMS receives the request sent by FOCOM / NFO in operation S203 and performs an operation to block or mark one or more O-Cloud nodes as unschedulable, thereby draining one or more O-Cloud node(s). Thereby, the migration of the NF deployment(s) from each individual O-Cloud node can be triggered.

[0042] In operation S205, the IMS / DMS can notify FOCOM / NFO that the status of the drain request indicates, for example, that the block request has been completed or an exception has occurred. The user terminal and / or the non-real-time RIC (i.e., rApp) can also receive this status update notification (e.g., FOCOM / NFO can then notify the O-Cloud administrator or the rApp).

[0043] Operation S203, operation S204, and operation S205 may loop or be repeatedly executed for each of the one or more O-Cloud nodes identified in the first request. Further, FOCOM / NFO can determine the order in which to drain the one or more O-Cloud nodes according to a predetermined criterion or randomly, and can send a second request corresponding to each of the one or more O-Cloud nodes according to the determined order. When the O-Cloud node(s) is / are drained, all NF deployment(s) either migrate from the O-Cloud node(s) or terminate.

[0044] Figure 3 shows a detailed method for implementing the drain procedure 300 of the O-Cloud node(s) according to an embodiment, where the user terminal O-Cloud administrator sends a request. The method in Figure 3 may be manually requested by the user via the user terminal (i.e., the application installed therein). This method may be executed using FOCOM / NFO and IMS / DMS as in the embodiment shown in Figure 2 above.

[0045] In operation 301, the user terminal (O-Cloud administrator) sends a first request to FOCOM / NFO to drain the O-Cloud node(s). The first request may include an identifier of the O-Cloud node(s). This may be similar to operation S201 described in Figure 2 above.

[0046] In operation 302, FOCOM / NFO receives and processes the first request from the user terminal to drain the O-Cloud node(s). This may be similar to operation S202 described in Figure 2 above.

[0047] In operation 303, FOCOM / NFO sends a second request to drain the O-Cloud node(s) to IMS / DMS via the O2 interface based on the received first request. This may be similar to operation S203 described in Figure 2 above.

[0048] In operation 304, the IMS / DMS drains each specified node by either shutting it down or marking the O-Cloud node(s) as unschedulable. For this purpose, the IMS / DMS can mark the O-Cloud node as "unschedulable", as a result of which the scheduler within the SMO will not instantiate any new deployments (i.e., network functions) on the O-Cloud node. This may be similar to operation S204 described in FIG. 2 above.

[0049] In operation 305, in an exemplary embodiment, the IMS / DMS sends a notification regarding the status of the drain procedure to the FOCOM / NFO via the O2 interface. This can indicate either that the drain procedure has completed successfully or that an exception has occurred. If the notification indicates that the drain procedure has completed successfully, it can be understood that the requested O-Cloud node(s) within the node cluster have been shut down or marked as unschedulable and that all NF deployments have migrated to other O-Cloud node(s) within the node cluster.

[0050] According to an embodiment, exception handling can be performed. Thus, if there is an exception that occurred because the drain procedure encountered an exception (which can include, but is not limited to, an undiscovered node cluster, an unresponsive node cluster, or an unavailable node cluster, or a node cluster with insufficient resources to migrate the NF deployment), the IMS / DMS may notify the FOCOM / NFO that the drain procedure for the O-Cloud node(s) has failed. In this case, the notification can indicate that the states of the O-Cloud and the IMS / DMS are the same as before the request arrived, i.e., the resources have not been changed and the NF deployment has not migrated or ended.

[0051] In operation 306, the IMS / DMS can also (or alternatively) send a notification from operation 305 to the user terminal (application) based on, for example, whether an event is reserved for a notification from the IMS / DMS. Operations 305 and 306 may be similar to operation S205 described in FIG. 2 above.

[0052] In one embodiment, operations 303 to 306 may loop or be repeatedly executed for each of the one or more groups of O-Cloud nodes identified in the first request.

[0053] When the O-Cloud node(s) is / are drained, i.e., the O-Cloud node(s) is / are blocked or marked as unschedulable and the NF deployment(s) has / have migrated to another group of O-Cloud node instances, or the method encounters an exception, the process may end.

[0054] It should be understood that the method can be considered successful if the requested O-Cloud node(s) in the node cluster is / are blocked or marked as unschedulable and all NF deployment(s) has / have migrated to other O-Cloud node(s) in the node cluster.

[0055] Alternatively, if the states of the O-Cloud and the IMS / DMS are the same as before the request arrives, the method may be considered to have failed or encountered an error, the resources are not changed, and the NF deployment(s) does / do not migrate and does / do not end.

[0056] FIG. 4 shows a detailed method for implementing the drain procedure 300 of the O-Cloud node(s) according to an embodiment, where the recommendation is sent from the rApp. The method of FIG. 4 may be based on recommendations from the non-real-time RIC (rApp). In this method, similar to the embodiment shown in FIG. 2 above, it may be executed using FOCOM / NFO and IMS / DMS.

[0057] In operation 401, the rApp (non-real-time RIC) sends a first recommendation to the FOCOM / NFO to drain the O-Cloud node(s). The first recommendation may include the identifier of the O-Cloud node(s). This may be similar to operation S201 described in FIG. 2 above when the rApp of the non-real-time RIC sends a recommendation.

[0058] In operation 402, the FOCOM / NFO receives and processes the first recommendation from the non-real-time RIC to drain the O-Cloud node(s). This may be similar to operation S202 described in FIG. 2 above.

[0059] In operation 403, the FOCOM / NFO sends a second request to the IMS / DMS via the O2 interface to drain the O-Cloud node(s) based on the received first recommendation. This may be similar to operation S203 described in FIG. 2 above.

[0060] In operation 404, the IMS / DMS drains each specified node by blocking the O-Cloud node(s) or marking them as unschedulable. For this purpose, the IMS / DMS can mark the O-Cloud node as "unschedulable", as a result of which 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 operation S204 described in FIG. 2 above.

[0061] In operation 405, in an exemplary embodiment, the IMS / DMS sends a notification regarding the status of the drain procedure to the FOCOM / NFO via the O2 interface. This can indicate either that the drain procedure has completed successfully or that an exception has occurred. If the notification indicates that the drain procedure has completed successfully, it can be understood that the O-Cloud node(s) requested within the node cluster have been blocked or marked as unschedulable, and that all NF deployments are migrating to other O-Cloud node(s) within the node cluster.

[0062] According to an embodiment, exception handling can be performed. Thus, if there is an exception that occurred because the drain procedure encountered an exception (which can include, but is not limited to, an undiscovered node cluster, a non-responsive node cluster, or an unavailable node cluster, or a node cluster with insufficient resources to migrate the NF deployment), the IMS / DMS may notify the FOCOM / NFO that the drain procedure of the O-Cloud node(s) has failed. In this case, the notification can indicate that the states of the O-Cloud and the IMS / DMS are the same as before the request arrived, i.e., the resources have not been changed and the NF deployment has not migrated or ended.

[0063] In operation 406, the IMS / DMS can also (or alternatively) send the notification from operation 405 to a non-real-time RIC (rApp) based on, for example, whether an event is reserved for the notification from the IMS / DMS. Operations 405 and 406 may be similar to operation S405 described in FIG. 2 above.

[0064] In one embodiment, operations 403 to 406 may loop or be repeatedly executed for each of the one or more O-Cloud node groups identified in the first request.

[0065] Based on the above, it can be understood that the O-Cloud node(s) can be drained based on a request from a user terminal or based on a recommendation from an rApp based on metric data (or other data). Therefore, there may be a need for means to relocate, migrate, or terminate its network function or a component of the network function to another O-Cloud node. Thus, in embodiments of the present disclosure, waste of O-Cloud resources can be eliminated, O-Cloud node failures can be predicted, and O-Cloud resources can be proactively managed accordingly.

[0066] FIG. 5 is a diagram of an exemplary environment 500 in which the methods and systems described herein can be implemented. As shown in FIG. 5, environment 500 may include user devices 510, a platform 520, and a network 530. The devices of environment 500 can be interconnected by a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. In embodiments, any combination of the elements shown in FIG. 5 can perform any of the functions and operations described with reference to FIGS. 2-4 above.

[0067] User devices 510 include one or more devices that can receive, generate, store, process, and / or provide information related to platform 520. For example, user devices 510 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones, etc.), wearable devices (e.g., smart glasses or smart watches), or similar devices. In some implementations, user devices 510 can receive information from platform 520 and / or transmit information to platform 520.

[0068] Platform 520 includes one or more devices that can receive, generate, store, process, and / or provide information. In some implementations, platform 520 may include a cloud server or a group of cloud servers. In some implementations, platform 520 may be modularly designed to allow for the replacement of specific software components according to specific needs. Thus, platform 520 can be easily and / or quickly reconfigured for various applications.

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

[0070] Cloud computing environment 522 includes an environment that hosts platform 520. Cloud computing environment 522 can provide services such as computing, software, data access, storage, etc., without requiring knowledge of the physical location and configuration of the system(s) and / or device(s) (e.g., user device 510) hosting platform 520 by an end user. As illustrated, cloud computing environment 522 can include a group of computing resources 524 (collectively referred to as "computing resource group 524" or individually as "computing resource 524").

[0071] The computing resource 524 includes a cluster of one or more personal computers, computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resource 524 can host the platform 520. The cloud resources can include computing instances running within the computing resource 524, storage devices provided within the computing resource 524, data transfer devices provided by the computing resource 524, and the like. In some implementations, the computing resource 524 can communicate with other computing resources 524 by means of a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection.

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

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

[0074] Virtual machine 524-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Depending on its use and the degree of correspondence of the virtual machine 524-2 to any actual machine, it may be either a system virtual machine or a process virtual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can execute a single program and support a single process. In some implementations, the virtual machine 524-2 can execute on behalf of a user (e.g., user device 510) and manage the infrastructure of the cloud computing environment 522, such as data management, synchronization, or long-duration data transfer.

[0075] Virtualized storage 524-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of the computing resources 524. In some implementations, within the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization can refer to the extraction (or separation) of logical storage from physical storage so as to be able to access the storage system regardless of the physical storage or a heterogeneous structure different from it. By separating, the administrator of the storage system can be enabled to have flexibility in how to manage the storage for end users. File virtualization can eliminate the dependency between the data accessed at the file level and the location where the files are physically stored. This can enable optimization for storage usage, server integration, and / or the migration performance of non-stop files.

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

[0077] The network 530 includes one or more wired and / or wireless networks. For example, the network 530 can 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, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0078] The number and arrangement of the devices and networks shown in FIG. 5 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks with different arrangements than those shown in FIG. 5. Further, two or more of the devices shown in FIG. 5 may be implemented within a single device, or the single device shown in FIG. 5 may be implemented as multiple distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) in the environment 500 may perform one or more functions described as being performed by another set of devices in the environment 500.

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

[0080] Bus 610 includes components that enable communication between the components of device 600. Processor 620 can be implemented in hardware, firmware, or a combination of hardware and software. Processor 620 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, processor 620 includes one or more processors that can be programmed to execute a certain function. Memory 630 includes random access memory (RAM), read only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by processor 620.

[0081] The memory component 640 stores information and / or software related to the operation and use of the device 600. For example, the memory component 640 may include, together with a corresponding drive, 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 cartridge, a magnetic tape, and / or other types of non-transitory computer-readable media. The input component 650 includes components that enable the device 600 to receive information via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone), etc. Additionally, or alternatively, the input component 650 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 660 includes components that provide output information from the device 600 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0082] The communication interface 670 includes components such as a transceiver (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 600 to communicate with other devices via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection, etc. The communication interface 670 can enable the device 600 to receive information from another device and / or provide information to another device. For example, the communication interface 670 may 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.

[0083] Device 600 can execute one or more of the processes described herein. In response to a processor 620 executing software instructions stored in a non-transitory computer-readable medium, such as a memory 630 and / or a storage component 640, device 600 can execute these processes. The computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical storage device or a memory space spanning multiple physical storage devices.

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

[0085] In addition to, or instead of, software instructions, a hardwired circuit may be used to execute one or more of the processes described herein, either instead of or in combination with the software instructions. Accordingly, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0086] The number and arrangement of components shown in FIG. 6 are provided as an example. In practice, device 600 may include additional components, fewer components, different components, or components arranged differently than those shown in FIG. 6. In addition to, or instead of, a set of components of device 600 (e.g., one or more components), a different set of components of device 600 may perform one or more of the functions described as being performed by another set of components of device 600.

[0087] In an embodiment, any one of the operations or processes of FIGS. 2 to 4 can be implemented by any one of the elements shown in FIGS. 5 and 6 or using any one of the elements shown in FIGS. 5 and 6. Other embodiments are not limited thereto and may be implemented in various different architectures (e.g., bare metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, OpenStack).

[0088] The foregoing disclosure provides the figures and description but is not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the above disclosure or can be obtained from the practice of the implementation forms.

[0089] Some embodiments may relate to systems, methods, and / or computer-readable media at any technically detailed level where integration is possible. Further, one or more of the above-described components 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 can include a computer-readable non-transitory storage medium (s) having computer-readable program instructions for causing a processor to execute operations.

[0090] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes the following. That is, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves on which instructions are recorded, and any suitable combination thereof. The computer-readable storage media used herein should not be construed as being a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through an electrical wire.

[0091] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices 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 comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each respective computing / processing device.

[0092] The computer-readable program code / instructions for performing the operations may be in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in an object-oriented programming language such as Smalltalk, C++, and a procedural programming language such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions for personalizing the electronic circuit to perform the aspects or operations.

[0093] These computer-readable program instructions may be provided to the processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium storing the instructions comprises an article of manufacture including instructions for implementing the aspects of the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0094] These computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0095] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagram may represent a micro service (group), module, segment, or portion of one or more executable instructions implementing a particular logical function (group). The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions described in the blocks may be performed in a different order than that described in the figures. For example, two blocks shown in succession may actually be performed simultaneously, or substantially simultaneously, or the blocks may sometimes be performed in the reverse order depending on the functions involved. It should also be noted that each block of the block diagram and / or flowchart diagram, and combinations of blocks of the block diagram and / or flowchart diagram, can be implemented by a dedicated hardware-based system that performs a particular function or operation, or a combination of dedicated hardware and computer instructions.

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

[0097] Various aspects of the embodiments

[0098] Various further respective aspects and features of the embodiments of the present invention disclosure can be defined by the following items. Item [1]: A method for draining one or more Open Radio Access Network (O-RAN) cloud (O-Cloud (O Cloud)) nodes, comprising receiving, by a Service Management and Orchestration Framework (SMO) function, a first request or recommendation for draining at least one O-Cloud node, wherein the first request or recommendation is received from an rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) or from an O-Cloud administrator; sending, by the SMO function, a second request for draining at least one O-Cloud node to a Foundation Management Service (IMS) and / or a Deployment Management Service (DMS) via an O2 interface based on the received first request or recommendation; and receiving, from the IMS / DMS, a first notification regarding whether at least one O-Cloud node has been drained, wherein the SMO function is at least one of Federation O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO). Item [2] The second request is an instruction to drain 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 drained, and the method further comprises sending, by the SMO function, a third request for draining a second O-Cloud node of at least one O-Cloud node to the IMS / DMS via the O2 interface based on the received first request or recommendation, as described in Item [1]. Item [3] The method according to any one of Items [1] to [2], wherein the first request or recommendation is based on metric data and / or observability data received by the rApp or the O-Cloud administrator via an O1-related service and / or an O2-related service. The method according to any one of items [1] to [3], which is transmitted to IMS / DMS by the SMO function based on the determination in item [4] that the second claim accepts a first claim or recommendation for draining at least one O-Cloud node by the SMO function. The method according to any one of items [1] to [4], wherein the first notification indicates that at least one O-Cloud node has not been drained or an exception has occurred. The method according to any one of items [1] to [5], wherein the first notification indicates that at least one O-Cloud node has been drained, and receiving the first notification comprises receiving, from IMS / DMS via the O2 interface by the SMO function, the first notification that at least one O-Cloud node has been drained. The method according to item [6], further comprising notifying, by the SMO function, the rApp of the non-real-time RIC or the O-Cloud administrator that at least one O-Cloud node has been drained. An apparatus for draining one or more Open Radio Access Network (O-RAN) Cloud (O-Cloud) nodes, the apparatus comprising at least one memory storing computer-executable instructions, and at least one processor configured to execute the computer-executable instructions, the at least one processor receiving a first request or recommendation for draining at least one O-Cloud node by a Service Management and Orchestration Framework (SMO) function, the first request or recommendation being received from an rApp of a Non-Real-Time (Non-RT) Radio Intelligent Controller (RIC) or from an O-Cloud administrator, the SMO function transmitting, via an O2 interface, a second request for draining at least one O-Cloud node to an Infrastructure Management Service (IMS) and / or a Deployment Management Service (DMS) based on the received first request or recommendation, and the at least one processor being configured to receive, from the IMS / DMS, a first notification regarding whether at least one O-Cloud node has been drained, wherein the SMO function is at least one of Federation O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO). Item [9] The second request is an instruction to drain 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 drained, and wherein the at least one processor is further configured to execute computer-executable instructions to transmit, via the O2 interface by the SMO function to the IMS / DMS, a third request for draining a second O-Cloud node of at least one O-Cloud node based on the received first request or recommendation, for the apparatus according to Item [8]. Item

[10] The apparatus according to any one of Items [8] to [9], wherein the first request or recommendation is based on metric data and / or observability data received by the rApp or the O-Cloud administrator via an O1-related service and / or an O2-related service. Item

[11] The apparatus according to any one of Items [8] to

[10] , which is transmitted by the SMO function to the IMS / DMS based on the determination by the SMO function of accepting a first request or recommendation for draining at least one O-Cloud node. Item

[12] The apparatus according to any one of Items [8] to

[11] , wherein the first notification indicates that at least one O-Cloud node has not been drained or an exception has occurred. Item

[13] The first notification indicates that at least one O-Cloud node has been drained, and wherein at least one processor is further configured to execute computer-executable instructions for receiving the first notification by receiving, from the IMS / DMS via the O2 interface by the SMO function, the first notification that at least one O-Cloud node has been drained. The apparatus according to any one of Items [8] to

[12] . Item

[14] The apparatus according to Item

[13] , wherein at least one processor is further configured to execute computer-executable instructions for notifying a non-real-time RIC rApp or an O-Cloud administrator by the SMO function that at least one O-Cloud node has been drained. Item

[15] The service management and orchestration framework (SMO) function receives a first request or recommendation to drain at least one O-Cloud node, where the first request or recommendation is received from an rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC) or from an O-Cloud administrator, and the SMO function sends a second request to a base management service (IMS) and / or a deployment management service (DMS) via an O2 interface to drain at least one O-Cloud node based on the received first request or recommendation, and receives a first notification from the IMS / DMS regarding whether at least one O-Cloud node has been drained, where the SMO function records executable instructions for causing a processor to execute a method that is at least one of federated O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO) on a non-transitory computer-readable recording medium. Item

[16] The second request is an instruction to drain a first O-Cloud node of at least one O-Cloud node, where the first notification indicates that the first O-Cloud node has been drained, and the method further includes the SMO function sending a third request to the IMS / DMS via the O2 interface to drain a second O-Cloud node of at least one O-Cloud node based on the received first request or recommendation, in the non-transitory computer-readable recording medium according to Item

[15] . Item

[17] The non-transitory computer-readable recording medium according to any one of Items

[15] to

[16] , where the first request or recommendation is based on metric data and / or observability data received by the rApp or the O-Cloud administrator via O1-related services and / or O2-related services. Item

[18] The non-transitory computer-readable recording medium according to any one of Items

[15] to

[17] , which is transmitted to the IMS / DMS by the SMO function based on the determination of accepting the first request or recommendation for draining at least one O-Cloud node by the SMO function. Item

[19] The non-transitory computer-readable recording medium according to any one of Items

[15] to

[18] , wherein the first notification indicates that at least one O-Cloud node has not been drained or an exception has occurred. Item

[20] The first notification indicates that at least one O-Cloud node has been drained, and receiving the first notification comprises receiving, from the IMS / DMS via the O2 interface by the SMO function, the first notification that at least one O-Cloud node has been drained. The non-transitory computer-readable recording medium according to any one of Items

[15] to

[19] .

[0099] In light of the above teachings, it will be understood that many changes and modifications to the present disclosure are possible. It will be apparent that within the scope of the appended claims, the present disclosure may be practiced in ways other than those specifically described herein.

Claims

**Claim 1** A method for draining one or more Open Radio Access Network (O-RAN) Cloud (O-Cloud) nodes, comprising: receiving, by a Service Management and Orchestration Framework (SMO) function, a first request or recommendation for draining at least one O-Cloud node, wherein the first request or recommendation is received from an rApp of a Non-Real-Time (Non-RT) Radio Access Network Intelligent Controller (RIC) or from an O-Cloud administrator; sending, by the SMO function, a second request for draining the at least one O-Cloud node to an Infrastructure Management Service (IMS) and / or Deployment Management Service (DMS) via an O2 interface based on the received first request or recommendation; receiving, from the IMS / DMS, a first notification regarding whether the at least one O-Cloud node has been drained; and wherein the SMO function is at least one of Federation O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO). **Claim 2** The second request is an instruction to drain 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 drained, and wherein the method further comprises: sending, by the SMO function, a third request for draining a second O-Cloud node of the at least one O-Cloud node to the IMS / DMS via the O2 interface based on the received first request or recommendation. The method according to claim 1. **Claim 3** The method according to claim 1, wherein the first request or recommendation is based on metric data and / or observability data received by the rApp or the O-Cloud administrator via O1-related services and / or O2-related services. **Claim 4** The method according to claim 1, wherein the second request is sent by the SMO function to the IMS / DMS based on a determination by the SMO function to accept the first request or recommendation for draining the at least one O-Cloud node. **Claim 5** The method according to claim 1, wherein the first notification indicates that the at least one O-Cloud node was not drained or an exception occurred.

6. The first notification indicates that the at least one O-Cloud node was drained, and receiving the first notification is The method according to claim 1, comprising receiving, by the SMO function, from the IMS / DMS via the O2 interface, the first notification that the at least one O-Cloud node was drained.

7. The method according to claim 6, further comprising notifying, by the SMO function, the rApp of the non-real-time RIC or the O-Cloud administrator that the at least one O-Cloud node was drained. The method according to claim 6.

8. An apparatus for draining one or more Open Radio Access Network (O-RAN) cloud (O-Cloud) nodes, the apparatus comprising: At least one memory storing computer-executable instructions; At least one processor configured to execute the computer-executable instructions, Receiving, by a Service Management and Orchestration Framework (SMO) function, a first request or recommendation for draining at least one O-Cloud node, the first request or recommendation being received from an rApp of a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) or from an O-Cloud administrator, Sending, by the SMO function, via the O2 interface to a Baseband Management Service (IMS) and / or a Deployment Management Service (DMS), a second request for draining the at least one O-Cloud node based on the received first request or recommendation, At least one processor configured to receive from the IMS / DMS a first notification regarding whether the at least one O-Cloud node was drained; and wherein the SMO function is at least one of Federation O-Cloud Orchestration and Management (FOCOM) and Network Function Orchestration (NFO).

9. The second request is an instruction to drain a first O-Cloud node of the at least one O-Cloud node, where the first notification indicates that the first O-Cloud node has been drained, and where the at least one processor transmits, via the O2 interface by the SMO function to the IMS / DMS, a third request to drain a second O-Cloud node of the at least one O-Cloud node based on the received first request or recommendation. The apparatus according to claim 8, further configured to execute the computer-executable instructions. **Claim 10** The apparatus according to claim 8, wherein the first request or recommendation is based on metric data and / or observability data received by the rApp or the O-Cloud administrator via O1-related services and / or O2-related services. **Claim 11** The apparatus according to claim 8, wherein the second request is transmitted by the SMO function to the IMS / DMS based on the SMO function's determination to accept the first request or recommendation to drain the at least one O-Cloud node. **Claim 12** The apparatus according to claim 8, wherein the first notification indicates that the at least one O-Cloud node was not drained or that an exception occurred. **Claim 13** The first notification indicates that the at least one O-Cloud node has been drained, and where the at least one processor receives, via the O2 interface by the SMO function from the IMS / DMS, the first notification that the at least one O-Cloud node has been drained. The apparatus according to claim 8, further configured to execute the computer-executable instructions for receiving the first notification. **Claim 14** The at least one processor notifies, by the SMO function, the rApp or the O-Cloud administrator of the non-real-time RIC that the at least one O-Cloud node has been drained. The apparatus according to claim 13, further configured to execute the computer-executable instructions. **Claim 15** Receiving, by a service management and orchestration framework (SMO) function, a first request or recommendation for draining at least one O-Cloud node, wherein the first request or recommendation is received from an rApp of a non-real-time (Non-RT) RAN intelligent controller (RIC) or from an O-Cloud administrator, sending, by the SMO function, a second request for draining the at least one O-Cloud node to an infrastructure management service (IMS) and / or a deployment management service (DMS) via an O2 interface based on the received first request or recommendation, receiving, from the IMS / DMS, a first notification regarding whether the at least one O-Cloud node has been drained, and wherein the SMO function records executable instructions for causing a processor to execute a method that is at least one of federated O-Cloud orchestration and management (FOCOM) and network function orchestration (NFO) on a non-transitory computer-readable recording medium.

16. The second request is an instruction for draining 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 drained, and wherein the method further comprises: sending, by the SMO function, a third request for draining a second O-Cloud node of the at least one O-Cloud node to the IMS / DMS via the O2 interface based on the received first request or recommendation. The non-transitory computer-readable recording medium according to claim 15.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the first request or recommendation is based on metric data and / or observability data received by the rApp or the O-Cloud administrator via an O1-related service and / or an O2-related service.

18. The non-transitory computer-readable recording medium according to claim 15, which is transmitted to the IMS / DMS by the SMO function based on a determination of accepting the first request or recommendation to drain the at least one O-Cloud node by the SMO function in accordance with the second request. **Claim 19** The non-transitory computer-readable recording medium according to claim 15, wherein the first notification indicates that the at least one O-Cloud node has not been drained or an exception has occurred. **Claim 20** The first notification indicates that the at least one O-Cloud node has been drained, and receiving the first notification The non-transitory computer-readable recording medium according to claim 15, comprising receiving, by the SMO function from the IMS / DMS via the O2 interface, the first notification that the at least one O-Cloud node has been drained.

Images