Control plane failure recovery in a network

Abstract

Provided are apparatus, method, and device for automatically perform control plane failure recovery. According to example embodiments, the apparatus may be configured to: receive, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmit the first LCM request to a first control plane node; detect a failure at the first control plane node; receive, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmit the second LCM request to a second control plane node.

Description

CONTROL PLANE FAILURE RECOVERY IN A NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No.63 / 739,751, filed with the U.S. Patent and Trademark Office on December 30, 2024, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to recovery of control plane failure in a telecommunications network.BACKGROUND

[0003] The information disclosed in this background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] A radio access network (RAN) is an important component in a telecommunications 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-users to a core network. Traditionally, hardware and / or software of a particular RAN is vendor specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, differenttypes of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based), or could be in physical hardware form (e.g., non-VM based).SUMMARY

[0006] Example embodiments of the present disclosure automatically perform control plane failure recovery. As such, example embodiments of the present disclosure provide a solution to recover from control plane failures, and to reduce impacts that may result from such failures.

[0007] According to example embodiments, an apparatus is provided. The apparatus may be configured to: receive, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmit the first LCM request to a first control plane node; detect a failure at the first control plane node; receive, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmit the second LCM request to a second control plane node.

[0008] According to example embodiments, a method is provided. The method may include: receiving, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmitting the first LCM request to a first control plane node; detecting a failure at the first control plane node; receiving, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving thesecond LCM request and in response to detecting the failure at the first control plane node, transmitting the second LCM request to a second control plane node.

[0009] According to example embodiments, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium may have recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method including: receiving, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmitting the first LCM request to a first control plane node; detecting a failure at the first control plane node; receiving, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmitting the second LCM request to a second control plane node.

[0010] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0012] FIG. 1A illustrates an example system architecture, according to one or more example embodiments;

[0013] FIG. IB illustrates a block diagram of an example configuration of a network function (NF) deployment under a containerized platform, according to one or more example embodiments;

[0014] FIG. 2 illustrates a flow diagram of an example method for performing control plane failure recovery, according to one or more example embodiments;

[0015] FIG. 3 illustrates a flow diagram of an example method for transmitting a second LCM request, according to one or more example embodiments;

[0016] FIG. 4 illustrates a flow diagram of an example method for performing control plane failure recovery, according to one or more example embodiments;

[0017] FIG. 5 illustrates a flow sequence of an example use case for performing control plane failure recovery, according to one or more example embodiments;

[0018] FIG. 6 illustrates an embodiment of a device for implementing one or more example embodiments; and

[0019] FIG. 7 is a diagram of an example of implementation environment in which systems and / or method, described herein, may be implemented.DETAILED DESCRIPTION

[0020] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features ofanother embodiment). Additionally, the flowchart and description of operations provided below relate to at least one of the embodiments in the present disclosure. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part). Further, the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the present disclosure.

[0021] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods should not limit their implementations. Thus, 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 may be designed to implement the systems and / or methods based on the description herein.

[0022] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, the particular combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

[0023] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” (inother words, nouns not mentioned in the plural) are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B. Further still, where only one item is intended, the term “one” or similar language is used.

[0024] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0025] Reference throughout this specification to “one embodiment,” “an embodiment,” “non-limiting exemplary embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

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

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

[0028] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (0-RAN) Alliance standard organization, and the like. For instance, the terms “IMS”, “DMS”, “FOCOM”, “NFO”, “NF”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless described otherwise.

[0029] Further, although some embodiments of the present disclosure may be described herein with reference specific components of 5G system, it can be understood that the scope of the present disclosure should not be limited thereto. Specifically, example embodiments of the present disclosure may also apply to any suitable network elements in any suitable telecommunications system, such as a 4G LTE system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0030] As described above, 0-RAN technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. To this end, 0-RANdisaggregates the RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0031] In this regard, the Kubernetes control plane is an important aspect of O-RAN, as the Kubernetes control plane is responsible for orchestrating and monitoring the entire cluster of network nodes in the network.

[0032] The Kubernetes control plane may be subjected to failures due to various reasons, including, but not limited to: master node failure, key-value data store node failure, transport network failure, load balancer failure, control plane upgrade failure, and the like.

[0033] Master node failure may refer to a failure wherein a master node, which is configured to host critical control plane components (e.g., API server, controller manager, scheduler, etc ), becomes unavailable, impacting orchestration and monitoring capabilities of the Kubernetes control plane. Key-value data store node failure may refer to a failure wherein a distributed key-value store (e.g., etcd, etc.) that stores cluster state data experiences failure, potentially leading to data unavailability or inconsistency. Transport network failure may refer to a failure wherein the communication between control plane components and worker nodes is disrupted, resulting in delayed or lost updates to cluster state. Load balancer failure may refer to afailure wherein a load balancer experiences failure, preventing access to the API Server and impacting administrative tasks and orchestration. Control plane upgrade failure may refer to a failure wherein an issue occurs during a Kubemetes control plane upgrade, causing temporary or prolonged service interruptions.

[0034] Failures of Kubemetes control plane may significantly disrupt cloud services, with impacts varying depending on the failure. Examples of impacts resulting from Kubemetes control plane failures include, but not limited to: Service Lifecycle Management (LCM) stops, functionality degradation, service interruption, performance monitoring halt, reduced redundancy risk, and the like.

[0035] LCM stops may include a situation where deployment or scaling of Network Functions (NFs) may be interrupted, delaying new service launches or updates. Functionality degradation may include a situation where critical control functions (e.g., scheduling, state updates, monitoring, etc.) may be suspended, affecting system stability, and where NF functionality may degrade if control plane services cannot reconcile or manage resources. Service interruption may include a situation where services are temporary interrupted, impacting end-user experience. Performance monitoring halt may include a situation where system health and performance metrics are unable to be monitored, increasing risks for service level agreement (SLA) violations and troubleshooting delays. Reduced redundancy risk may include a situation where redundant components (e.g., in high-availability configurations) may experience failures, reducing fault tolerance and increasing vulnerability to further issues.

[0036] In view of the above, there is a need for a solution to recover from Kubemetes control plane failures, and to reduce impacts that may result from such failures.

[0037] Accordingly, apparatus, system, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically perform control plane failure recovery.

[0038] According to example embodiments, the apparatus may be configured to receive a first lifecycle management (LCM) request associated with a network function (NF) deployment, and transmit such first LCM request to a first control plane node. Then at a later time, the apparatus may detect a failure at the first control plane node, and subsequently receive a second lifecycle management (LCM) request associated with the NF deployment. In this regard, in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, the apparatus may transmit the second LCM request to a second control plane node.

[0039] Ultimately, example embodiments of the present disclosure automatically perform control plane failure recovery, which provide a solution to recover from control plane failures and reduce impacts that may result from such failures.

[0040] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0041] Further descriptions of the features, components, configuration, operations, and implementations of the system of the present disclosure, according to one or more embodiments, are provided in the following.Example System Architecture

[0042] FIG. 1A illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG. 1A, the system architecture may include at least oneService Management and Orchestration (SMO) framework 110 that includes at least one non-real-time RAN Intelligent Controller (Non-RT RIC) 120, at least one near-real-time RIC (Near-RT RIC) 130, at least one O-RAN Centralized Unit (O-CU) that may be disaggregated into an O-CU control plane (O-CU-CP) 140 and an O-CU user plane (O-CU-UP) 150, at least one open evolved NodeB (O-eNB), at least one O-RAN Distributed Unit (O-DU) 170, at least one O-RAN Radio Unit (O-RU) 180, and at least one O-RAN Cloud (O-Cloud) 190. The components may be communicatively coupled to another component(s) within the system architecture via a respective interface(s).

[0043] It is contemplated that the system architecture may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some implementations, the system architecture may further include a plurality of O-DUs, a plurality of O-RUs, and the like.

[0044] The RAN functions in the system may be controlled and optimized by at least one RIC. The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability, as well as to automate and optimize RAN operations. As shown in FIG. 1 A, the RIC may be divided into two types, i.e., the Non-RT RIC 120 and the Near-RT RIC 130. In the following, descriptions of the Non-RT RIC 120 are provided, followed by the descriptions of the Near-RT RIC 130.

[0045] The Non-RT RIC 120 may refer to a logical function within the SMO framework 110 that drives the content carried across the Al interface to enable non-real-time control and optimization of RAN elements and resources. The Al interface may refer to a logical interface between the Non-RT RIC 120 and the Near-RT RIC 130, which enables the Non-RT RIC 120 toprovide policy-based guidance (obj ective, resource) to the Near-RT RIC 130 and enables the Near-RT RIC 130 to provide one or more feedbacks to the Non-RT RIC 120 to monitor the status of one or more policies.

[0046] In some example, implementations, the Non-RT RIC 120 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO framework 110. The functionalities of the Non-RT RIC 120 may include, for example, providing policy-based guidance and enrichment across the Al interface, performing data analytics, Artificial Intelligence / Machine Learning (AI / ML) models training and inference for RAN optimization, and / or recommending configuration management actions. As further described below, the Non-RT RIC 120 may access or communicate with other SMO framework functionalities or components via Al interface, 01 interface, 02 interface, and one or more interfaces associated with one or more open fronthaul planes.

[0047] According to example embodiments, the functionalities of the Non-RT RIC 120 may be implemented through at least one modular, Non-RT RIC application, such as an rApp (not shown). The rApp may leverage the functionalities available in the SMO framework 110 and / or the Non-RT RIC 120 to provide value added services related to RAN operation and optimization, such as policy management, radio resource management, data analytics, and providing enrichment information. In some implementations, the Non-RT RIC 120 may implement a plurality of rApps.

[0048] According to example embodiments, the Non-RT RIC 120 may include a Non-RT RIC framework that may be configured to provide or implement one or more services to the rApp through R1 interface. The R1 interface may refer to an open logical interface between the rApp and the Non-RT RIC framework. The R1 interface supports the exchange of data or information,as well as the collection and delivery of data between the rApp and the Non-RT RIC framework. The one or more services, which may also be referred to as “R1 services” herein, may include policy management services, service registration and discovery services, authentication and authorization services, AI / ML workflow services, RAN OAM-related services, Al related services, and 02 related services. The R1 interface allows multi-vendor rApps to manage or add the R1 services, and facilitate inter-connection between rApps and Non-RT RIC framework supplied by different vendors.

[0049] According to example embodiments, the rApp may be configured to manage one or more policies that are provided to the Near-RT RIC 130 over the Al interface. Said policies may be referred to as “Al policies” herein, and are declarative policies that contain statements on policy objectives and policy resources applicable to one or more network nodes (e.g., one or more UEs, one or more network cells, etc.). Specifically, the one or more Al policies may consist of a scope identifier and one or more policy statements. The scope identifier may represent what the policy statements are to be applied on (e.g. UEs, QoS flows, or cells). The policy statements may define the goals or objectives of the policy and may include information associated with policy objectives and policy resources. In an example, the Al policies may include Quality of Service (QoS) requirements and Energy Saving (ES) requirements, specifying, for example, new QoS Class Identifier (QCI) parameters that an xApp should follow / utilize, and energy saving aggressiveness. By including the policy objectives in the policy statements, the quality of experience can be optimized for UEs or QoS flows that are identified either explicitly by, for example, a UE identifier or a QoS identifier, or implicitly by, for example, a group identifier from which the Near-RT RIC 230 can deduce a set of UEs. On the other hand, by including the policyresources in the policy statements, UEs can be configured to avoid certain cells and / or the radio network can be optimized in specific areas.

[0050] The rApp (or the Non-RT RIC framework within the Non-RT RIC 120) may provide the one or more Al policies to the Near-RT RIC 130, thereby providing guidance to the Near-RT RIC 130 towards one or more objectives or goals defined in the RAN intent. The RAN intent may refer to the high-level operational or business goal(s) to be achieved by the RAN, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to fulfill for all users or for a subset of users in a given area over at least a predefined period of time.

[0051] According to example embodiments, the rApp may be configured to perform one or more policy management operations to provision and manage one or more Al policies in the Near-RT RIC 130. Specifically, the rApp may be configured to create, update and delete one or more Al policies in the Near-RT RIC 130. For instance, the rApp may query the presence, content and run-time status of one or more Al policies in the Near-RT RIC 130.

[0052] According to example embodiments, the rApp may be configured to receive, from the Near-RT RIC via the Al interface, one or more feedback associated with one or more Al policies (“Al policy feedback” herein). Similarly, the rApp may be configured to receive one or more observables (e.g., events, counters, etc.) provided by the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-DU 170, and / or the O-RU 180 over the 01 interface. Accordingly, the rApp may be configured to continuously (or periodically) manage the one or more Al policies based on the Al policy feedback(s) and / or the observables provided over the 01 interface. For instance, the rApp may continuously (or periodically) evaluate the impact or effectiveness of the one or more Alpolicies towards the fulfdlment of the RAN intent and then configure or update the one or more Al policies accordingly.

[0053] In addition to the communication with the Near-RT-RIC 130 via the Al interface, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may communicate with the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and the O-RU 180 via the 01 interface. In this regard, the 01 interface may refer to a logical interface between the SMO framework 110, the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and the O-RU 180, which enables the SMO framework 110 (as well as the Non-RT RIC 120 and the rApp implemented therein) to provide Fault, Configuration, Accounting, Performance, and Security (FCAPS) and other management operations, such as network monitoring, network discovery, and the like, to the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and / or the O-RU 180. Additionally, the 01 interface enables the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the O-DU 170, and / or the O-RU 180 to provide information or observable(s) that may be utilized by the Non-RT RIC 120 (or the rApp) to manage the Al policy(s), to train one or more AI / ML models, and the like.

[0054] Further, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may communicate with the O-Cloud 190 via the 02 interface. In this regard, the 02 interface may refer to a logical interface between the SMO framework 110 and the O-Cloud 190, which may be a collection of physical RAN nodes that host the Non-RT RIC 120, the Near-RT RIC 130, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170, the supporting software components (e.g., the operating systems and runtime environments), and theSMO framework 110 itself. In other words, the SMO framework 110 may manage the O-Cloud 190 from within, and the 02 interface may be the interface between the SMO framework 110 and the O-Cloud 190 it resides in. Through the 02 interface, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 190.

[0055] More specifically, the SMO framework 110 may include network functions, Federated O-Cloud Management and Orchestration (FOCOM) and Network Function Orchestrator (NFO), configured to communicate with and manage the O-Cloud 190. The FOCOM may be responsible for managing the infrastructure (e.g., clouds, data centers, clusters, etc.) on which the networks are deployed, while the NFO may orchestrate the deployments of the O-RAN workloads such as O-CU (O-CU-CP 140 / O-CU-UP 150), O-DU 170, and Near-RT RIC 130. Further, the FOCOM and NFO may communicate with the IMS and DMS in the O-Cloud 190 in order to manage the O-Cloud 190.

[0056] In particular, the O-Cloud 190 may include software components, Infrastructure Management Services (IMS) and Deployment Management Services (DMS). The IMS may be responsible for allocation of physical resource in the O-Cloud 190 based on the requests received from the SMO framework 110 (i.e., FOCOM and / or NFO), as well as tracking and management of said resources. More specifically, the IMS may be responsible for building inventories (physical / logical) and sharing said inventories with the SMO framework 110, where the SMO framework 110 may receive information related to said inventories from the IMS, update its inventory according to such information, and make requests to allocate resources based on the inventory updates. The DMS may be responsible for management of deployment lifecycle. Morespecifically, the DMS may deploy O-RAN network functions on the allocated resources of the infrastructure, as well as monitor the status of said network functions. The DMS may be scaled up and down according to the demand of the network function.

[0057] Further, according to example embodiments, the SMO 110 may configure and deploy one or more network functions (NFs) to the O-Cloud 190 under a containerized platform, such as a Kubernetes containerized platform.

[0058] FIG. IB illustrates a block diagram of an example configuration of a network function (NF) deployment under a containerized platform, according to one or more example embodiments.

[0059] As illustrated in FIG. IB, the network node 900 may include a plurality of containers 911-912 and 921-922. The NF may be disaggregated or scattered among the plurality of containers 911-912 and 921-922. For instance, the containerized NF may be segregated according to the type of operations. For instance, the functionalities or operations associated with a first function of the NF may be scattered among the containers 811-812, while the functionalities or operations associated with a second function of the NF may be scattered among the containers 821-822.

[0060] According to example embodiments, the network node 900 may include a Kubernetes (K8s) node, and the containers may be grouped or aggregated in a respective pod. In the example embodiment of FIG. IB, the containers 911-912 are included in a first pod 910, while the containers 921-922 are included in a second pod 920.

[0061] The plurality of pods in the network node 900 may share the same resources (e.g., CPU, memory, etc.) provided by the network node 900. The resources being allocated for the NFmay be managed by adjusting the associated pods and / or containers. For instance, the resources may be scaled up by increasing the number of containers and / or pods associated therewith, may be scaled down by decreasing the number of containers and / or pods associated therewith, or the like.

[0062] In some implementations, the network node 900 may refer to a component, a module, or a physical hardware (e.g., a server, etc.) including suitable components or resources (e.g., CPU, memory, storage, bandwidth, etc.) for hosting and executing the containerized NF. Alternatively, the network node 900 may refer to a collection of resources (e.g., CPU, memory, etc.) for hosting and executing the containerized NF, and may be presented in the form of virtual machines.

[0063] In this regard, the FOCOM at the SMO 110 may transmit a request to the IMS at the O-Cloud 190 to create an O-Cloud node cluster, where such O-Cloud node cluster may include a plurality of nodes. The plurality of nodes within the O-Cloud node cluster may include a plurality of worker nodes and a plurality of control plane (master) nodes. The worker node may include a network node that is hosting containerized NFs (i.e., in the similar manner as described above in relation to network node 900). The control plane node may include a network node that is hosting control plane components (e g., API server, controller manager, scheduler, etc), where the control plane node (through the control plane) may communicate with each of the plurality of worker nodes within the same O-Cloud node cluster in order to control and manage the containers within said worker nodes.

[0064] Accordingly, the IMS may create the O-Cloud node cluster including the plurality of nodes, and the DMS may communicate with and manage each of the plurality of control planenodes in accordance with requests from the NFO at the SMO 110 (e g., lifecycle management requests).

[0065] It is understood that the configuration illustrated in FIG. IB is simplified for descriptive purposes, and is not intended to limit the scope of the present disclosure. Specifically, in practice, the network node 900 may include any suitable components for hosting and executing a plurality of pods, while the number of pods may be greater than two and the number of containers included in each pod may be greater than two, without departing from the scope of the present disclosure. Further, it can be understood that the containerized NF may be hosted or deployed in a plurality of the network node, in a similar manner as described above. Furthermore, it can be understood that multiple network node may include the same containers (or pods) in order to provide network redundancy thereby improving the network availability.

[0066] Returning to FIG. 1A, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) may communicate with the 0-RU 180 via an open fronthaul (O-FH) management plane (M-Plane) interface. In this regard, the O-FH M-Plane may enable the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp implemented therein) to perform one or more FCAPS operations on the O-RU 180.

[0067] Next, the descriptions of the Near-RT RIC 130 are provided. The Near-RT RIC 130 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 130 may provide the near-real-time control and optimization via fine-grained (e.g., UE basis, Cell basis) data collection and actions over the E2 interface. In some example, implementations, the Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170 via the E2 interface. The Near-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) over a near-real-time control loop.

[0068] According to example embodiments, the Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes (e.g., the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170, etc.) via one or more policies (e.g., Al policies). For example, the Near-RT RIC 130 may receive the one or more Al policies from the Non-RT RIC 120 (or the rApp implemented therein) and then configure or set one or more policy parameters associated with the one or more Al policies on activated functions of the E2 nodes. Further, the Near-RT RIC 130 may host one or more applications, such as the xApp (not shown), to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, and the like.

[0069] In this regard, the xApp may consist of one or more microservices, which may be independent of the Near-RT RIC 130 and may be provided by any third party. The E2 interface enables a direct association between the xApp and other RAN functionalities (e.g., the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, and the O-DU 170, etc.), thereby enabling the xApp to provide information or data to the RAN functionalities for further utilization. According to example embodiments, the Near-RT RIC 130 may consist of multiple xApps and a set of platform functions that are commonly used to support the specific functions hosted by the multiple xApps. In this regard, the Near-RT RIC platform may communicate with the xApp(s) via one or more application programming interfaces (APIs). Further, the Near-RT RIC platform may be configuredto route Al policy management messages to the registered xApps based on Al policy type and operator policies.

[0070] According to example embodiments, the Near-RT RIC 130 may implement the xApp to configure one or more parameters and then provide the one or more configured parameters to the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-eNB 160, the 0-DU 170, and / or the 0-RU 180. According to example embodiments, the xApp may be configured to adjust or configure any one or more parameters.

[0071] According to example embodiments, the xApp may be configured to adjust or configure one or more of the above-described parameters and optimize said one or more parameters according to the current Al policy(s) and the current network condition(s) (e g., load, energy consumption, etc.), thereby providing controlling latency and throughput that fulfills the QoS requirement(s) and / or the energy saving requirement(s).

[0072] According to example embodiments, the xApp may be configured to perform the one or more control operations via the E2 interface. For instance, the xApp may be configured to perform 0-DU E2 control and send one or more associated commands to the O-DU 170. Accordingly, the O-DU 170 may control the associated O-RU(s) or cell(s). As another example, the xApp may be configured to perform O-CU E2 control, where the O-CU (O-CU-CP 140 / O-CU-UP 150) may send the one or more associated commands to the 0-DU 170, and the 0-DU 170 may then control the associated O-RU(s) or cell(s). Accordingly, the 0-DU 170 may in the end shape the E2 control and policy.

[0073] Next, the descriptions of the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-DU 170, and the 0-RU 180 are provided. Generally, the O-CU (O-CU-CP 140 / O-CU-UP 150), the O-DU170, and the O-RU 180 may constitute a base station, such as a gNodeB (gNB) of 5G NR or a node in Next Generation Radio Access Network (NG-RAN), an Evolved Node B (eNodeB) of a 4G LTE network, a base station of a 6G network, and the like.

[0074] The communication between the O-CU and the O-DU 170 may be performed via an Fl interface, in particular, the communication between the O-CU-CP 140 and the O-DU 170 may be performed via an Fl-c interface, while the communication between the O-CU-UP 150 and the O-DU 170 may be performed via an Fl-u interface. The communication between the O-DU 170 and the O-RU 180 may be performed via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces. In some implementations, the C, U, and S planes may be consolidated and referred to as the “CUS-plane”. According to example embodiments, the system may include a plurality of O-DUs 170, and the O-CU may be communicatively coupled to the plurality of O-DUs via the Fl interface. Similarly, the system may include a plurality of O-RUs 180, and the O-DU 170 may be communicatively coupled to the plurality of O-RUs via one or more of the O-FH C / U / S / M plane interfaces.

[0075] According to example embodiments, the O-CU (O-CU-CP 140 / O-CU-UP 150) and the O-DU 170 may be defined in software form and may be deployed in one or more network nodes. For instance, the O-CU (O-CU-CP 140 / O-CU-UP 150) and the O-DU 170 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and / or cloud-native function (CNF), and the like. According to example embodiments, the O-CU (O-CU-CP 140 / O-CU-UP 150) and the O-DU 170 may be deployed in the same network node (e.g., same server) and / or may be located at a similar geographical location (e.g., be deployed in different servers in the same data center). According to example embodiments, the O-CU (O-CU-CP 140 / 0-CU-UP 150) and the O-DU 170 maybe deployed in different network nodes and / or may be located at different geographical locations. For instance, the O-CU (O-CU-CP 140 / O-CU-UP 150) may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 170 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0076] The O-DU 170 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks (e g., RLC layer, MAC layer, Physical Layer, etc.) accordingly. As an example, the O-DU 170 may perform one or more scheduling operations. The O-CU (O-CU-CP 140 / O-CU-UP 150) may communicatively couple the O-DU 170 to a core network (e g., 4G Evolved Packet Core (EPC) network, 5G Core network, etc.) and may receive the radio signals from the O-DU 170, thereby providing operation or support for higher layers of protocol stacks (e.g., PDCP layer, RRC layer, etc.) accordingly.

[0077] As described above, according to example embodiments, the O-CU may include an O-CU control plane (O-CU-CP) 140 and an O-CU user plane (O-CU-UP) 150. The O-CU-CP 140 may refer to the logical node that hosts or implements the RRC and the control plane part of the PDCP protocol, and may be responsible for managing the signaling between the core network and the radio network, handling tasks such as session management, radio bearer control, and mobility management. On the other hand, the O-CU-UP 150 may refer to the logical node that hosts or implements the user plane part of the PDCP protocol and the SDAP protocol, and may be responsible for managing the data traffic and the transmission of user data packets. The O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via the El interface.

[0078] Further, a single O-DU 170 may host or serve multiple network cells formed by multiple O-RUs 180. According to example embodiments, the O-DU 170 may implement various radio technologies, such as massive multiple-input multiple-output (MEMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU (O-CU-CP 140 / O-CU-UP 150). In some implementations, the O-DU 170 may concurrently host or serve hundreds (e.g., 512, etc.) of cells at a time.

[0079] The O-RU 180 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 170. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may include a macro cell, a micro cell, a pico cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which the O-RU 180, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein.

[0080] According to example embodiments, the O-DU 170 may be configured to control or instruct the associated O-RU(s) via one or more of the O-FH C / U / S / M plane interfaces. For instance, the O-DU 170 may instruct the O-RU 180 to enter the sleep mode via the O-FH C / U / S plane interfaces. On the other hand, the capability exchange between the O-DU 170 and the O-RU 180 may be performed via the O-FH M-plane interface. As an example, the O-RU 180 may inform the O-DU 170 of the amount of time it requires to maintain in the sleep mode in order to save an amount of energy.Example Operations for Recovery of Kubernetes Control Plane Failure in the PresentDisclosure

[0081] In the following, several example operations are performable by the apparatus of one or more example embodiments of the present disclosure are described with reference to FIG.2 to FIG. 5.

[0082] FIG. 2 illustrates a flow diagram of an example method 200 for performing control plane failure recovery, according to one or more example embodiments. One or more operations in method 200 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to perform control plane failure recovery.

[0083] According to example embodiments, the apparatus may include a Deployment Management Services (DMS) of an O-Cloud. The DMS may act as a load balancer in the O-Cloud.

[0084] As illustrated in FIG. 2, at operation S210, the apparatus may be configured to receive a first lifecycle management (LCM) request.

[0085] The first LCM request may be associated with a network function (NF) deployment. According to example embodiments, the first LCM request may include a request associated with lifecycle management (LCM) of the NF deployed under a Kubemetes containerized platform in the network, such as a request to update, create, delete, and the like an element (pod, container, etc.) of the Kubernetes containerized platform.

[0086] For example, the first LCM request may include a request to scale up deployment of an NF (container) at a particular network node (e.g., worker node).

[0087] According to example embodiments, the first LCM request may be received from a Service Management and Orchestration (SMO). In particular, for example, the first LCM requestmay be received from a Network Function Orchestrator (NFO) of the SMO. The method then proceeds to operation S220.

[0088] At operation S220, in response to receiving the first LCM request, the apparatus may be configured to transmit the first LCM request to a first control plane node.

[0089] The first control plane node may include a network node that is hosting control plane components (e.g., API server, controller manager, scheduler, etc) of a containerized platform, where such control plane node (through the control plane) may communicate with each of a plurality of worker nodes within the same node cluster in order to control and manage the containers within said worker nodes. The method then proceeds to operation S230.

[0090] At operation S230, the apparatus may be configured to receive a response from the first control plane node.

[0091] In particular, according to example embodiments, in response to receiving the first LCM request from the apparatus during operation S220, the first control plane node may be configured to perform operations in accordance with the first LCM request. For example, the first control plane node may communicate with and control a particular network node (e.g., worker node) to scale up deployment of an NF (container) at such particular network node.

[0092] Subsequently, the first control plane node may be configured to transmit a response to the apparatus. Here, the response may include information associated with the operations performed in accordance with the first LCM request. For example, in response to a successful scale up deployment of an NF (container) at the particular network node, the first control plane node may be configured to transmit a response to the apparatus, indicating that the scaling up of the NF (container) at the particular network node been successfully completed.

[0093] Accordingly, the apparatus may be configured to receive such response from the first control plane node.

[0094] According to example embodiments, in response to receiving the response, the apparatus may forward the response to the SMO. According to example embodiments, the response may be forwarded to the NFO of the SMO. The method then proceeds to operation S240.

[0095] At operation S240, the apparatus may be configured to detect a failure at the first control plane node.

[0096] The failure may include any kind of failures associated with a control plane at the first control plane node. The failure may also include a failure occurring within a node cluster. For example, the failure may be associated with master node failure, key-value data store node failure, transport network failure, load balancer failure, control plane upgrade failure, and the like.

[0097] Master node failure may refer to a failure wherein a master node, which is configured to host critical control plane components (e.g., API server, controller manager, scheduler, etc.), becomes unavailable, impacting orchestration and monitoring capabilities of the Kubemetes control plane. Key-value data store node failure may refer to a failure wherein a distributed key-value store (e.g., etcd, etc.) that stores cluster state data experiences failure, potentially leading to data unavailability or inconsistency. Transport network failure may refer to a failure wherein the communication between control plane components and worker nodes is disrupted, resulting in delayed or lost updates to cluster state. Load balancer failure may refer to a failure wherein a load balancer experiences failure, preventing access to the API Server and impacting administrative tasks and orchestration. Control plane upgrade failure may refer to afailure wherein an issue occurs during a Kubemetes control plane upgrade, causing temporary or prolonged service interruptions.

[0098] According to example embodiments, the apparatus (e.g., DMS) itself may detect the failure. According to example embodiments, the IMS of the O-Cloud may detect the failure, and may transmit a notification including information associated with such failure to the apparatus (e.g., DMS).

[0099] According to example embodiments, the failure may have occurred and be detected after the first control plane node transmitted the response to the apparatus. The method then proceeds to operation S250.

[0100] At operation S250, the apparatus may be configured to receive a second lifecycle management (LCM) request.

[0101] The second LCM request may be associated with a network function (NF) deployment. According to example embodiments, the second LCM request may include a request associated with lifecycle management (LCM) of the NF deployed under a Kubemetes containerized platform in the network, such as a request to update, create, delete, and the like an element (pod, container, etc.) of the Kubemetes containerized platform.

[0102] For example, the second LCM request may include a request to scale down deployment of an NF (container) at a particular network node (e.g., worker node).

[0103] According to example embodiments, the second LCM request may be received from the SMO. In particular, for example, the second LCM request may be received from the NFO of the SMO. The method then proceeds to operation S260.

[0104] At operation S260, in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, the apparatus may be configured to transmit the second LCM request to a second control plane node different from the first control plane node.

[0105] The second control plane node may include a network node that is hosting control plane components (e.g., API server, controller manager, scheduler, etc) of a containerized platform, where such control plane node (through the control plane) may communicate with each of a plurality of worker nodes within the same node cluster in order to control and manage the containers within said worker nodes.

[0106] Further, according to example embodiments, the second control plane node may be comprised in the same O-Cloud node cluster as the first control plane node.

[0107] FIG. 3 illustrates a flow diagram of an example method 300 for transmitting a second LCM request, according to one or more example embodiments. One or more operations of method 300 may be part of operation S260 in method 200, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0108] As illustrated in FIG. 3, at operation S310, the apparatus may be configured to select a control plane node from a node cluster that is not experiencing failure. The node cluster may include a node cluster which the first control plane node resides in (i.e., the first control plane node and the selected control plane node (second control plane node) may reside in the same node cluster).

[0109] In particular, in response to detecting the failure at the first control plane node and in response to receiving the second LCM request, the apparatus may search for an alternate controlplane node (alternate from the first control plane node that is experiencing failure) that is within the same node cluster as the first control plane node, to which the second LCM request would be transmitted to in order to implement the lifecycle management operations.

[0110] As such, according to example embodiments, the apparatus may select a control plane node that is from the same node cluster (e.g., O-Cloud node cluster) which the first control plane node resides in, and that is not experiencing failure (there may be other nodes within the same node cluster that is also experiencing failure).

[0111] The apparatus may use any appropriate methods and / or standards for selecting such control plane node. The method then proceeds to operation S320.

[0112] At operation S320, the apparatus may be configured to transmit the second LCM request to the selected control plane node.

[0113] Accordingly, the second LCM request may be transmitted to a second control plane node. The method then proceeds to operation S270.

[0114] At operation S270, the apparatus may be configured to receive a response from the second control plane node.

[0115] In particular, according to example embodiments, in response to receiving the second LCM request from the apparatus during operation S260, the second control plane node may be configured to perform operations in accordance with the second LCM request. Subsequently, the second control plane node may be configured to transmit a response to the apparatus. Here, the response may include information associated with the operations performed in accordance with the second LCM request.

[0116] In particular, according to example embodiments, in response to receiving the second LCM request from the apparatus during operation S260, the second control plane node may be configured to perform operations in accordance with the second LCM request (i.e., instead of the first control plane node that is experiencing failure). For example, the second control plane node may communicate with and control a particular network node (e.g., worker node) to scale down deployment of an NF (container) at such particular network node.

[0117] Subsequently, the second control plane node may be configured to transmit a response to the apparatus. Here, the response may include information associated with the operations performed in accordance with the second LCM request. For example, in response to a successful scale down deployment of an NF (container) at the particular network node, the second control plane node may be configured to transmit a response to the apparatus, indicating that the scaling down of the NF (container) at the particular network node been successfully completed.

[0118] Accordingly, the apparatus may be configured to receive such response from the second control plane node.

[0119] According to example embodiments, in response to receiving the response, the apparatus may forward the response to the SMO. According to example embodiments, the response may be forwarded to the NFO of the SMO. The method then proceeds to operation S280.

[0120] At operation S280, the apparatus may be configured to transmit a notification to the SMO.

[0121] The notification may include information associated with the detected failure at the first control plane node, such that the SMO (and / or an operator at the SMO) may performoperations to resolve the failure at the first control plane node and return the first control plane node back to operational state.

[0122] According to example embodiments, the notification may be transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.

[0123] According to example embodiments, the apparatus (e.g., DMS) itself may transmit the notification (e.g., in response to detecting the failure at the first control plane node). According to example embodiments, the IMS of the O-Cloud may transmit the notification (e.g., in response to detecting the failure at the first control plane node).

[0124] Upon performing operation S280, the method 200 may be ended or be terminated. Alternatively, method 200 may return to operation S210, such that the apparatus may be configured to repeatedly perform, for at least a predetermined amount of time, the receiving the first LCM request (at operation S210), the transmitting the first LCM request (at operation S220), the receiving the response (at operation S230), the detecting the failure (at operation S240), the receiving the second LCM request (at operation S250), the transmitting the second LCM request (at operation S260), the receiving the response (at operation S270), and the transmitting the notification (at operation S280).

[0125] For example, the apparatus may receive a third LCM request, and then restart the above operations to perform the receiving the third LCM request (at operation S210), the transmitting the third LCM request (to the second control plane node) (at operation S220), the receiving the response (from the second control plane node) (at operation S230), the detecting the failure (at the second control plane node) (at operation S240), the receiving the fourth LCM request (at operation S250), the transmitting the fourth LCM request (to a third control plane node) (atoperation S260), the receiving the response (from the third control plane node) (at operation S270), and the transmitting the notification (at operation S280).

[0126] Accordingly, the above processes provide a solution to recover from Kubemetes control plane failures, and to reduce impacts that may result from such failures.

[0127] In particular, the above processes enable the network to automatically recover from a control plane failure, while maintaining integrity of the control plane’s state and context and ensuring seamless operation in light of the failure. More specifically, the above processes enable the SMO to continue to provide LCM requests to the O-Cloud (i.e., DMS) as usual, where the DMS will automatically assign the LCM requests to the available control plane node and away from the failed control plane node, without interruptions to the operations of the SMO or to the service of the network.

[0128] Here, according to example embodiments, virtualized network function (VNF) / containerized and / or cloud-native function (CNF) may have already been deployed prior to the operations in method 200, where VNF / CNF performance and fault management are in place and active, and where workload scheduling policy and resource constraint have been configured.

[0129] FIG. 4 illustrates a flow diagram of an example method 400 for performing control plane failure recovery, according to one or more example embodiments. One or more operations in method 400 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to perform control plane failure recovery.

[0130] According to example embodiments, the apparatus may include a Deployment Management Services (DMS) of an O-Cloud. The DMS may act as a load balancer in the O-Cloud.

[0131] As shown in FIG. 4, one or more operations in method 400 may be similar to one or more operations in method 200. Thus, similar descriptions are omitted for conciseness.

[0132] As illustrated in FIG. 4, at operation S410, the apparatus may be configured to receive a first lifecycle management (LCM) request, in the similar manner as operation S210 in method 200. The method then proceeds to operation S420.

[0133] At operation S420, the apparatus may be configured to transmit the first LCM request to a first control plane node, in the similar manner as operation S220 in method 200. The method then proceeds to operation S430.

[0134] At operation S430, the apparatus may be configured to determine whether a response is received from the first control plane node. According to example embodiments, the apparatus may determine whether a response is received from the first control plane node within a time threshold. The time threshold may be predefined.

[0135] In this regard, in response to determining that the response is not received from the first control plane node within a time threshold, the apparatus may determine that a failure has occurred at the first control plane node (i.e., detect failure at the first control plane node), and the method then proceeds to operation S440.

[0136] On the other hand, in response to determining that the response is received from the first control plane node within a time threshold, the apparatus may determine that a failure has not occurred at the first control plane node, and the method then proceeds to end. In this regard, according to example embodiments, the method may continue in the similar manner as operation S230 to S280 as described above in relation to method 200, where the response is received from the first control plane node at operation S230.

[0137] At operation S440, the apparatus may be configured to re-transmit the first LCM request to another (second) control plane node. The operations S440 may be similar to operation S260, where the apparatus may select another (second) control plane node from the same node cluster as the first control plane node to re-transmit the first LCM request to.

[0138] Subsequently, the method then returns to operation S430 to determine whether a response is received from the another (second) control plane node. Here, if the response is not received from the another (second) control plane node, the method then repeats operation S440 to re-transmit the first LCM request to another (third) control plane node.

[0139] FIG. 5 illustrates a flow sequence of an example use case for performing control plane failure recovery, according to one or more example embodiments. As shown in FIG. 5, the flow sequence may involve a Federated O-Cloud Management and Orchestration (FOCOM) 501, a Network Function Orchestrator (NFO) 502, an Infrastructure Management Services (IMS) 503, a Deployment Management Services (DMS) 504, a first control plane node (CPN) 505, and a second control plane node (CPN) 506. The FOCOM 501, NFO 502, IMS 503, DMS 504, first CPN 505 and second CPN 506 may be similar to the FOCOM, NFO, IMS, DMS, and control plane node described above in relation to FIG. 1 and FIG. 2, where the FOCOM 501 and NFO 502 may be comprised in an SMO, and where the IMS 503, DMS 504, first CPN 505 and second CPN 506 may be comprised in an O-Cloud. Further, one or more operations in FIG. 5 may involve or may be part of one or more operations described above with reference to FIG. 2 and FIG. 4.

[0140] At step 1, the FOCOM 501 may transmit an instruction to the IMS 503 to create a node cluster comprising a plurality of control plane nodes.

[0141] At step 2, the NFO 502 may transmit an LCM request to the DMS 504, where the DMS 504 may then transmit the LCM request to the first CPN 505 at step 3, in the similar manner as described above in relation to operations S210 to S220 in method 200.

[0142] Once the first CPN 505 performs operations associated with the LCM request, the first CPN 505 may transmit a response to the DMS 504 at step 4, where the DMS 504 may then forward the response to the NFO 502 at step 5, in the similar manner as described above in relation to operation S230 in method 200.

[0143] At step 6, a failure may occur at the first CPN 505, where such failure may be detected by the IMS 503 and the DMS 504 at steps 7 and 8, respectively, in the similar manner as described above in relation to operation S240 in method 200.

[0144] At step 9, the NFO 502 may transmit another LCM request to the DMS 504, where the DMS 504 may then transmit such LCM request to the second CPN 506 at step 10, in the similar manner as described above in relation to operations S250 to S260 in method 200.

[0145] Once the second CPN 506 performs operations associated with the LCM request, the second CPN 506 may transmit a response to the DMS 504 at step 11, where the DMS 504 may then forward the response to the NFO 502 at step 12, in the similar manner as described above in relation to operation S270 in method 200.

[0146] At step 13, the IMS 503 may transmit an alarm (notification) regarding the detected failure at the first CPN 505 to theFOCOM 501, in the similar manner as described above in relation to operation S280 in method 200.Various Aspects of Embodiments

[0147] In view of the above, example embodiments of the present disclosure provide a solution to recover from Kubernetes control plane failures, and reduce impacts that may result from such failures.

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

[0149] Some embodiments may relate to a system, a method, and / or a computer readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer readable medium and executable by at least one processor (and / or may include at least one processor). The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out operations.

[0150] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory(SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0151] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, 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 in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0152] Computer readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the"C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a standalone software package, partly on the user's computer and partly 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 the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0153] These computer readable program instructions may be provided to a 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 the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0154] The computer readable program instructions may also be loaded onto a computer,other programmable data processing 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 the flowchart and / or block diagram block or blocks.

[0155] The flowchart 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 diagrams may represent a microservice(s) module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0156] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software.The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code-it being understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0157] One or more components of the system of the example embodiments (e.g., DMS, etc.), as well as the operations associated therewith (e.g., one or more operations in FIG. 2 to FIG.5, etc.), may be implemented in one or more systems, devices, or hardware components, such as one or more servers, and the like. In the following, descriptions of a device in which the systems or components of the example embodiments may be implemented are provided. It is contemplated that one or more operations or methods described above with reference to FIG. 2 to FIG. 5 may be performed by the device. For instance, the one or more operations or methods may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0158] FIG. 6 illustrates an embodiment of a device 600 for implementing one or more example embodiments. As shown in FIG. 6, the device 600 includes a processor 610, a memory 620, a storage component 630, an input component 640, an output component 650, a communication interface 660, and a bus 670.

[0159] The processor 610, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 610 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and one or more single core processors, a distributed processing system, or the like. Theprocessor 610 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0160] Memory 620 includes a non-transitory computer readable medium. Memory 620 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 610. The memory 620 comprises machine-readable instructions which are executable by the processor 610. These machine-readable instructions when executed by the processor 610 causes the processor 610 to perform one or more method steps of an embodiment described herein.

[0161] Storage component 630 stores information and / or software related to the operation and use of the device 600. For example, storage component 630 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0162] Input component 640 is configured to receive information, such as user input. For example, the input component 640 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 640 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0163] Output component 650 is configured to provide output information from the device 600. For example, the output component 650 may be, but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0164] Communication interface 660 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 660 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 600 and other devices. In other words, the standard of the communication interface 660 is not limited.

[0165] The bus 670 acts as an interconnect between the processor 610, the memory 620, the storage component 630, the input component 640, the output component 650, and the communication interface 660 of the device 600. The bus 670 may include a wired interconnection or a wireless interconnection.

[0166] 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 differently arranged components than those shown in FIG. 6. Additionally, or alternatively, a set of components (e.g., one or more components) of device 600 may perform one or more functions described as being performed by another set of components of device 600. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of device 600 in communication with one another.

[0167] Further, according to example embodiments, the device 600 may include one or more elements from the system architecture described above in relation to FIG. 1. For example, the device 700 may include the DMS.

[0168] In the present disclosure, specific tasks may be performed using AI / ML (Artificial Intelligence / Machine Learning) models. An AI / ML model is a model generated using one or more Al technologies, one or more ML algorithm or both, and generates output data based on input data. This output data is used to perform tasks. Tasks performed using AI / ML models include those generally referred to as intellectual tasks, such as classification, prediction, natural language processing, etc.

[0169] Although Al and ML are explained separately, ML is a technology included in Al. In ML, instead of being explicitly programmed for a specific task, systems can improve their performance over time by identifying patterns and making inferences from training data. Typically, the generation of ML models includes data collection, model training, and model inference. Data collection involves gathering and preprocessing data to be used for training and inference. Model training involves developing and validating models using the collected data. Model inference involves applying the trained models to new data to generate new output data and perform tasks.

[0170] Machine learning includes various types of learning methods such as supervised learning, unsupervised learning, reinforcement learning, semi-supervised learning, self-supervised learning, transductive learning, transfer learning, meta learning, and the like. These types of learning methods can be appropriately selected according to the embodiments. Unless otherwise specified, the application of types not mentioned in this description is not precluded. Additionally, the structure of ML models may vary depending on the embodiments and learning methods, andis not limited to the methods disclosed. Furthermore, ML includes deep learning, which uses models that include neural networks. Deep learning models may include, for example, deep neural networks (DNNs), convolutional neural networks (CNNs), etc.

[0171] It should be noted that the ALML models presented hereinafter are examples and are not limited to the illustrated AI / ML models. They can be modified or altered by using different Al or ML algorithms. The configuration of the neural network is not limited to the configuration disclosed in the present disclosure and can be modified.

[0172] FIG. 7 is a diagram of an example of implementation environment 700 in which systems and / or method, described herein, may be implemented. The implementation environment 700 includes a UE (User equipment) 710, a service environment 720, and a network 730. The service environment 720 include one or more sub-environments 721. To illustrate this, FIG. 7 shows, for convenience, examples of a 1st sub-environment 721-1, a 2nd sub-environment 721-2, and an N-th sub-environment 721-N (where N is any natural number).

[0173] The UE 710 is connected to the network 730, and the network 730 is connected to the service environment 720. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 710 and the service environment 720 are connected via the network 730.

[0174] The UE 710 is a device that communicates with the service environment 720. The UE 710 receives information from the service environment 720 and / or sends information to the service environment 720. Also, the UE 710 may generate and / or store information to be transmitted, as necessary. Also, the UE 710 may store and / or process information that is received, as necessary.

[0175] The example figure 7 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE ”

[0176] For example, the UE 710 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0177] The service environment 720 is an environment that communicates with the UE 710 to provide one or more services. The service environment 720 receives information from the UE 710 and / or sends information to the UE 710. Also, the service environment 720 may generate and / or store information to be transmitted, as necessary. Also, the service environment 720 may store and / or process information that is received, as necessary. For example, the service environment 720 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0178] The example figure 7 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the"service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment.”

[0179] The one or more services provided by the service environment 720 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the HE 710, a service that stores information from the HE 710, or a service that performs processing based on information from the HE 710 and returns the results of the processing.

[0180] In an embodiment, the Service Environments 720 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0181] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, whenmeans of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0182] The service environment 720 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 720 can be determined as appropriate. Additionally, if the service environment 720 includes one or more sub-environments 721, the placement of devices can be determined based on predetermined policies for each sub-environment 721. For example, devices related to the first service may be placed in the 1st sub-environment 721-1, and devices related to the second service may be placed in the 2nd sub -environment 721-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 721-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 721-2. In this way, specific devices can be placed in specific sub -environments 721. Conversely, each sub-environment 721 can be specialized for a particular purpose.

[0183] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0184] The network 730 is a network that exchanges information between the UE 710 and the service environment 720. The network 730 includes one or more wired and / or wireless networks.

[0185] For example, the network 730 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., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0186] The network 730 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 730 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 720 could be in the core network, in which case the network 730 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0187] The number and arrangement of devices and networks shown in FIG. 7 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.

[0188] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: An apparatus that may be configured to: receive, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmit the first LCM request to a first control plane node; detect a failureat the first control plane node; receive, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmit the second LCM request to a second control plane node.Item [2]: The apparatus according to item [1], wherein the first LCM request and the second LCM request may include a request associated with lifecycle management (LCM) of the NF deployed under a Kubemetes containerized platform in a network.Item [3]: The apparatus according to one of items [l]-[2], wherein the apparatus may be configured to transmit the second LCM request to the second control plane node by: selecting a control plane node from a node cluster which the first control plane node resides in that is not experiencing failure; and transmitting the second LCM request to the selected control plane node.Item [4]: The apparatus according to one of items [l]-[3], wherein the apparatus may be further configured to transmit, to the SMO, a notification including information associated with the detected failure at the first control plane node.Item [5]: The apparatus according to item [4], wherein the notification may be transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.Item [6]: The apparatus according to one of items [I]-[5], wherein the first LCM request and the second LCM request may be received from a Network Function Orchestrator (NFO) of the SMO.Item [7]: The apparatus according to one of items [l]-[6], wherein the apparatus may include a Deployment Management Services (DMS) of an O-Cloud.Item [8]: A method that may include: receiving, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmitting the first LCM request to a first control plane node; detecting a failure at the first control plane node; receiving, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmitting the second LCM request to a second control plane node.Item [9]: The method according to item [8], wherein the first LCM request and the second LCM request may include a request associated with lifecycle management (LCM) of the NF deployed under a Kubemetes containerized platform in a network.Item

[0010] : The method according to one of items [8]-[9], wherein the transmitting the second LCM request to the second control plane node may include: selecting a control plane node from a node cluster which the first control plane node resides in that is not experiencing failure; and transmitting the second LCM request to the selected control plane node.Item

[0011] : The method according to one of items [8]-

[0010] , wherein the method may further include transmitting, to the SMO, a notification including information associated with the detected failure at the first control plane node.Item

[0012] : The method according to item

[0011] , wherein the notification may be transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.Item

[0013] : The method according to one of items [8]-

[0012] , wherein the first LCM request and the second LCM request may be received from a Network Function Orchestrator (NFO) of the SMO.Item

[0014] : The method according to one of items [8]-

[0013] , wherein the method may be performed by a Deployment Management Services (DMS) of an O-Cloud.Item

[0015] : A non-transitory computer-readable recording medium that may have recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method including: receiving, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment; in response to receiving the first LCM request, transmitting the first LCM request to a first control plane node; detecting a failure at the first control plane node; receiving, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; and in response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmitting the second LCM request to a second control plane node.Item

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the first LCM request and the second LCM request may include a request associated with lifecycle management (LCM) of the NF deployed under a Kubemetes containerized platform in a network.Item

[0017] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0016] , wherein the transmitting the second LCM request to the second control plane node may include: selecting a control plane node from a node cluster whichthe first control plane node resides in that is not experiencing failure; and transmitting the second LCM request to the selected control plane node.Item

[0018] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0017] , wherein the method may further include transmitting, to the SMO, a notification including information associated with the detected failure at the first control plane node.Item

[0019] : The non-transitory computer-readable recording medium according to item

[0018] , wherein the notification may be transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.Item

[0020] : The non-transitory computer-readable recording medium according to one of items

[0015] -

[0019] , wherein the first LCM request and the second LCM request may be received from a Network Function Orchestrator (NFO) of the SMO.

[0189] It is understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.Additional Disclosure

[0190] 5.3.x Kubemetes Control Plane Failure

[0191] 5.3.x.1 Description

[0192] The Kubemetes Control Plane is responsible for orchestrating and monitoring the entire cluster. However, control plane failures can occur due to various reasons, including but not limited to:

[0193] Master Node Failure: A master node that hosts critical control plane components (e.g., API Server, Controller Manager, Scheduler) becomes unavailable, impacting orchestration and monitoring capabilities.

[0194] Key-Value Data Store Node Failure: The distributed key-value store (e g., etcd or other implementations) that stores cluster state data experiences failure, potentially leading to data unavailability or inconsistency.

[0195] Transport Network Failure: Communication between control plane components and worker nodes is disrupted, resulting in delayed or lost updates to cluster state.

[0196] Load Balancer Failure: A load balancer failure can prevent access to the API Server, impacting administrative tasks and orchestration.

[0197] Control Plane Upgrading Failure: Issues during a Kubemetes control plane upgrade can cause temporary or prolonged service interruptions.

[0198] 5.3.x.2 Service Impact

[0199] Control plane failures can significantly disrupt cloud services, with impacts varying depending on the failure type:

[0200] Service Lifecycle Management (LCM) Stops:

[0201] Deployment or scaling of Network Functions (NFs) may be interrupted, delaying new service launches or updates.

[0202] Functionality Degradation:

[0203] Critical control functions (e.g., scheduling, state updates, or monitoring) are suspended, affecting system stability.

[0204] NF functionality may degrade if control plane services cannot reconcile or manage resources.

[0205] Service Interruption:

[0206] Recovery efforts for control plane failures may cause temporary service interruptions, impacting end-user experience.

[0207] Performance Monitoring Halts:

[0208] Inability to monitor system health and performance metrics increases risks for SLA violations and troubleshooting delays.

[0209] Increased Risk Due to Reduced Redundancy:

[0210] Failure of redundant components (e g., in high-availability configurations) reduces fault tolerance, increasing vulnerability to further issues.

[0211] 7.x.2 Description and UML Diagrams

[0212] s

[0213] @startuml

[0214] Autonumber

[0215] skinparam sequenceArrowThickness 2

[0216] skinparam ParticipantPadding 5

[0217] skinparam BoxPadding 10

[0218] ' Group IMS and NFO into SMO

[0219] box "SMO" #gold

[0220] participant FOCOM as "FOCOM"

[0221] participant NFO as "NFO"

[0222] end box

[0223] 1Group DMS and Control Planes into O-Cloud

[0224] box "O-Cloud" #lightseagreen

[0225] participant IMS as "IMS"

[0226] participant DMS as "DMS / load balancer"

[0227] participant CPI as "Control plane node 1"

[0228] participant CP2 as "Control plane node 2"

[0229] end box

[0230] ' Only the new operations

[0231] FOCOM -> IMS: Create O-Cloud node cluster, and K8S control plane nodes

[0232] NFO -> DMS: K8S NF Deployment LCM request

[0233] DMS -> CPI : K8S NF Deployment LCM request

[0234] CPl-> DMS : K8S NF Deployment LCM response

[0235] DMS --> NFO: K8S NF Deployment LCM response

[0236] CPI -> CPI : Control plane node 1 fails

[0237] IMS -> IMS : Detect control plane node 1 failure

[0238] DMS -> DMS : Detect control plane node 1 failure

[0239] NFO -> DMS: K8S NF Deployment LCM request

[0240] DMS -> CP2: K8S NF Deployment LCM request

[0241] CP2— > DMS : K8S NF Deployment LCM response

[0242] DMS — > NFO: K8S NF Deployment LCM response

[0243] IMS -> FOCOM: Alarm control plane nodel failure

[0244] @enduml

Claims

What is claimed is:

1. An apparatus configured to:receive, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment;in response to receiving the first LCM request, transmit the first LCM request to a first control plane node;detect a failure at the first control plane node;receive, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; andin response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmit the second LCM request to a second control plane node.

2. The apparatus according to claim 1, wherein the first LCM request and the second LCM request comprises a request associated with lifecycle management (LCM) of the NF deployed under a Kubernetes containerized platform in a network.

3. The apparatus according to claim 1, wherein the apparatus is configured to transmit the second LCM request to the second control plane node by: selecting a control plane node from a node cluster which the first control plane node resides in that is not experiencing failure; and transmitting the second LCM request to the selected control plane node.

4. The apparatus according to claim 1 , wherein the apparatus is further configured to transmit, to the SMO, a notification including information associated with the detected failure at the first control plane node.

5. The apparatus according to claim 4, wherein the notification is transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.

6. The apparatus according to claim 1, wherein the first LCM request and the second LCM request are received from a Network Function Orchestrator (NFO) of the SMO.

7. The apparatus according to claim 1, wherein the apparatus comprises a Deployment Management Services (DMS) of an O-Cloud.

8. A method comprising:receiving, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment;in response to receiving the first LCM request, transmitting the first LCM request to a first control plane node;detecting a failure at the first control plane node;receiving, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; andin response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmitting the second LCM request to a second control plane node.

9. The method according to claim 8, wherein the first LCM request and the second LCM request comprises a request associated with lifecycle management (LCM) of the NF deployed under a Kubernetes containerized platform in a network.

10. The method according to claim 8, wherein the transmitting the second LCM request to the second control plane node comprises: selecting a control plane node from a node cluster which the first control plane node resides in that is not experiencing failure; and transmitting the second LCM request to the selected control plane node.

11. The method according to claim 8, wherein the method further comprises transmitting, to the SMO, a notification including information associated with the detected failure at the first control plane node.

12. The method according to claim 11, wherein the notification is transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.

13. The method according to claim 8, wherein the first LCM request and the second LCM request are received from a Network Function Orchestrator (NFO) of the SMO.

14. The method according to claim 8, wherein the method is performed by a Deployment Management Services (DMS) of an O-Cloud.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising:receiving, from a Service Management and Orchestration (SMO), a first lifecycle management (LCM) request associated with a network function (NF) deployment;in response to receiving the first LCM request, transmitting the first LCM request to a first control plane node;detecting a failure at the first control plane node;receiving, from the SMO, a second lifecycle management (LCM) request associated with the NF deployment; andin response to receiving the second LCM request and in response to detecting the failure at the first control plane node, transmitting the second LCM request to a second control plane node.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the first LCM request and the second LCM request comprises a request associated with lifecycle management (LCM) of the NF deployed under a Kubernetes containerized platform in a network.

17. The non-transitory computer-readable recording medium according to claim 15, wherein the transmitting the second LCM request to the second control plane node comprises: selecting a control plane node from a node cluster which the first control plane node resides in that is not experiencing failure; and transmitting the second LCM request to the selected control plane node.

18. The non-transitory computer-readable recording medium according to claim 15, wherein the method further comprises transmitting, to the SMO, a notification including information associated with the detected failure at the first control plane node.

19. The non-transitory computer-readable recording medium according to claim 18, wherein the notification is transmitted to a Federated O-Cloud Management and Orchestration (FOCOM) of the SMO.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the first LCM request and the second LCM request are received from a Network Function Orchestrator (NFO) of the SMO.

Images