O-ran cloud (o-cloud) network function (NF) failure recovery

Abstract

Example embodiments of the present disclosure relate to enhanced failure recovery associated with a Network Function (NF) of an Open Radio Access Network (O-RAN) Cloud (OCloud). According to example embodiments, a system may include a Service Management and Orchestration (SMO) framework. The SMO framework may be configured to collect data associated with an O-Cloud and analyze the collected data to detect a failure associated with a first NF deployed in the O-Cloud. The failure may include at least one of: a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF. Further, based on determining the failure, the SMO framework may configure the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud.

Description

O-RAN CLOUD (O-CLOUD) NETWORK FUNCTION (NF) FAILURE RECOVERYCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to Indian Provisional Patent Application No.202541036647, filed with the Indian Patent Office on April 16, 2025, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to failure recovery of a Network Function (NF) in an Open Radio Access Network (0-RAN) Cloud (O-Cloud).BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgment 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, the hardware and / or software of a particular RAN is vendor-specific. 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, different types of NEs may beprovided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based, etc.), or could be in physical hardware form (e.g., non-VM based, etc.) Accordingly, O-RAN disaggregates the RAN functions into different entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). Since these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0005] An O-Cloud may refer to the infrastructure that supports an O-RAN deployment by, for example, providing the resources (e.g., computing units, storage, etc.) to deploy or host the disaggregated RAN components. In this regard, the O-RAN components may be implemented in the form of Network Functions (NFs), which are the logical software entities that implement the respective RAN protocols and operations. The NFs may be deployed on the O-Cloud (e.g., servers in a data center, etc.).SUMMARY

[0006] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently recover an NF failure in an O-Cloud.

[0007] According to example embodiments, a system may include a Service Management and Orchestration (SMO) framework. The SMO framework may be configured to collect data associated with an O-Cloud and analyze the collected data to detect a failure associated with a first NF deployed in the O-Cloud. The failure may include at least one of a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF. Further, based on determining the failure, the SMOframework may configure the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud.

[0008] According to example embodiments, a method may implemented by an SMO framework. The method may include collecting data associated with an O-Cloud, analyzing the collected data to detect a failure associated with a first NF deployed in the O-Cloud, and configuring the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud based on determining the failure. The failure may include at least one of: a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF.

[0009] 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

[0010] 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:

[0011] FIG. 1 illustrates a generic system configuration, according to one or more example embodiments;

[0012] FIG. 2 illustrates an example system configuration, according to one or more example embodiments;

[0013] FIG. 3 illustrates an example method, according to one or more example embodiments;

[0014] FIG. 4A to FIG. 4D illustrate various example use cases, according to one or more example embodiments;

[0015] FIG. 5 illustrates an example device / apparatus that may implement one or more example embodiments; and

[0016] FIG. 6 illustrates an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented.DETAILED DESCRIPTION

[0017] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above 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 of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. 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).

[0018] 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 limited to the described implementations. Thus, the operation and behavior of thesystems 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.

[0019] Even though particular combinations of features are disclosed in the claims and / or in the specification, these 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. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0020] 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” 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.

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

[0022] Reference throughout this specification to “one embodiment,” “embodiment,” “non-limiting exemplary embodiment,” “example embodiment,” or similar language means that aparticular 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.

[0023] 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 a particular 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.

[0024] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more technical specifications or documents associated with one or more standard organizations, such as the Open Radio Access Network (O-RAN) Alliance, the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “O-Cloud,” “NF,” “O-DU,” “O-RU,” “O-CU,” “O-CU-CP,” “SMO,” “FOCOM,” “NFO,” “RAN 0AM,” “IMS,” “DMS,” “01 interface,” “02 interface,” “02-IMS,” “02-DMS,” “PM,” “FM,” “CM,” and the like, as well as the associated features, operations, interfaces, and messages involved therein, are to be interpreted as consistent with those specified in one or more technical specifications / documents, unless being described otherwise.

[0025] As described above, an Open Radio Access Network (O-RAN) disaggregates RAN functions / components into various entities, such as an O-RAN Distributed Unit (O-DU), an O-RAN Central Unit (O-CU), and an 0-RAN Radio Unit (O-RU). Since these entities have open protocols and interfaces between them, they can be developed by different vendors thereby allowing multi-vendor interoperability.

[0026] An 0-RAN Cloud (O-Cloud) may refer to the cloud-native infrastructure that deploys or hosts at least part of the disaggregated 0-RAN entities (e.g., 0-DU, O-CU, etc.) and the associated management functions (e.g., Infrastructure Management Service (IMS), Deployment Management Service (DMS), etc.). For instance, an O-Cloud may contain one or more clusters of physical nodes (“O-Cloud clusters” herein) that form the logical resource pool(s) which provide resources (e.g., computing powers, storage, networking bandwidth, hardware accelerations, etc.) to implement the O-RAN entities and the management functions. An O-Cloud cluster (and the associated physical nodes and resources) may be managed by an orchestration platform (e.g., Kubernetes (K8s), etc.). Within the O-Cloud cluster(s), the 0-RAN components (e.g., O-CU, 0-DU, etc.) may be implemented in the form of Network Functions (NFs), which are the logical software entities that implement the respective RAN protocols and operations. Thus, the 0-RAN components that are implemented in an O-Cloud may also be referred to as the “O-RANNFs”.

[0027] Throughout the life-cycle of the NFs, one or more of the NFs may encounter various types of failure at different granularities or levels. For instance, at the infrastructure level, the NF(s) deployed in the O-Cloud may encounter failures caused by issues related to the O-Cloud infrastructure, such as workload downtime, physical node crashes due to hardware and / or software faults, resource exhaustion, and the like. Further, at the deployment / onboarding level, the NF(s) deployed (or is deploying) in the O-Cloud may experience failures caused by issues associated with the deployment and / or onboarding processes, such as misconfiguration during instantiation,corruption of software images, time outs in the handshaking process, and the like. Furthermore, at the application level, the NF(s) deployed and running in the O-Cloud environment may experience failures caused by issues associated with the execution or operation of an application associated with the NF(s), such as software bugs or vulnerabilities, software dependency failures, and the like.

[0028] An O-Cloud NF failure may have cascading negative impacts on the overall network operation, such as degrading the network performance (e.g., increasing network latency, reducing network throughput, etc.), causing network service disruptions, and in some cases, resulting in parts or the entirety of the network being unresponsive or loss of connectivity. Thus, it is critical to detect and recover (or avoid) an O-Cloud NF failure in a timely manner.

[0029] In this regard, the NF failure recovery approaches in the related art tend to focus on and address only the NF failures at one specific granularity or level. For example, the O-Cloud’ s infrastructure or resource management entity may detect the issues that may cause the infrastructure level failure, but said entity may have no visibility into the issues that may cause the deployment level and / or application level failures. As another example, the O-Cloud orchestration platform (e.g., K8s) may monitor the status of the pods and detect the issues that may cause the deployment / on-boarding level failure, but it may not detect issues that may cause the infrastructure level and / or application level failures. Namely, in the related art, various features and solutions may be implemented in the 0-RAN to detect and recover various types of NF failures in the O-Cloud. Such an approach, however, may be suboptimal and may contain various shortcomings as detailed below.

[0030] To begin with, deploying multiple, isolated detection and recovery mechanisms across different O-Cloud NF failure granularities / levels in the related art may increase the system complexity and eventually lead to operational inefficiency. For instance, since eachlayer / granularity (e.g., infrastructure, deployment / onboarding, application, etc.) relies on distinct features and mechanisms, distinct toolchain and policy sets may be required for each layer / granularity of O-Cloud NF failure, leasing to duplicated workloads (e.g., defining conditions / thresholds, recovery action playbooks, alarming / reporting interfaces, etc.) and increased risk of configuration errors. Furthermore, whenever a new NF is deployed or updated, multiple recovery features and mechanisms may need to be reviewed and adjusted accordingly, resulting in a significant operational burden and deployment efficiency.

[0031] In addition, deploying multiple, isolated detection and recovery mechanisms across different O-Cloud NF failure granularities / levels in the related art may result in delayed root-cause analysis of an O-Cloud NF failure, thereby slowing down the decision-making on the failure mitigation / recovery procedure, and may eventually lengthen the impact of the NF failure on the network operation / performance. Further, since there is no unified framework that has a comprehensive view on the O-Cloud NF failures, the failure detection and recovery mechanisms in the related art often requires significant amounts of manual intervention, such as manually data collection and processing (e.g., manually identifies and collects inter-related logs and metrics from different systems, etc.), and the like, which may further slowing down the failure detection and / or recovery and prone to human errors.

[0032] Example embodiments of the present disclosure, as described in the following, provide devices, systems, methods, and the like, that effectively and efficiently detect and recover one or more NF failures in a O-Cloud. Specifically, example embodiments provide and specify mechanisms that enable a Service Management and Orchestration (SMO) framework to collect various types of O-Cloud-related data (e.g., alarms, Performance Measurement (PM) data, Fault Management (FM) data, Configuration Management (CM) data, etc.) from various components ofthe O-Cloud (e.g., via utilizing various types of SMO Services (SMOSs), etc.), thereby enabling efficient and effective detection of the NF failure(s) of any granularities or levels. Further, the example embodiments also provide and specify mechanisms that enables the SMO framework to communicate and interoperate with various components of the O-Cloud, thereby enabling efficient and effective recovery of the NF failure(s) of any granularity or level.

[0033] 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. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0034] FIG. 1 illustrates a generic system configuration 100, according to one or more example embodiments. As illustrated in FIG. 1, the system configuration 100 includes a Service and Management Orchestration (SMO) framework 110 and an Open Radio Access Network (O-RAN) Cloud (O-Cloud) 120. It is contemplated that the configuration in FIG. 1 is merely an example provided for descriptive purposes, and the scope of the present disclosure is not limited thereto. For instance, in some example implementations, the system configuration 100 may further include an 0-RAN Radio Unit (0-RU) that enables the operations of transceiver (TRX)-array carriers linked to the network cells associated with or managed by the network functions (NFs) implemented in the O-Cloud 120, and the like, without departing from the scope of the present disclosure.

[0035] The SMO framework 110 (may also be referred to as the “SMO 110” herein) may refer to a logical entity responsible for service management, end-to-end orchestration, andautomation across the disaggregated RAN components (e.g., O-RAN Radio Unit (0-RU), O-RAN Distributed Unit (O-DU), O-RAN Control Unit (O-CU), etc.). According to example embodiments, the SMO 110 may be implemented in the software form in one or more hardware components (e.g., servers, computing devices, etc ). In some example implementations, the SMO 110 may be constituted of various software components, such as a Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) that manages or implements one or more modular applications (rApps), one or more SMO Services (SMOSs) that handle or manage different SMO Functions (SMOFs) (e.g., power saving orchestration, inventory or policy management, etc.), and the like. As further described below with reference to FIG. 2, the SMOSs that may be implemented or utilized by the SMO 110 may include a RAN Operations, Administrations, and Maintenance (0AM) (may also be referred to as the “RAN NF 0AM”) SMOS, a Federated O-Cloud Orchestration and Management (FOCOM) SMOS, and an NF Orchestration (NFO) SMOS. In this regard, descriptions such as “the SMO framework may be configured to perform an operation” can also be interpreted as “the SMO framework implements or utilizes at least one associated RIC / rApp / SMOS to perform the operation” and the like.

[0036] The O-Cloud 120 may refer to a cloud-native infrastructure that deploys or hosts at least part of the disaggregated O-RAN entities (e.g., O-DU, O-CU, etc.) and the associated management functions (e.g., Infrastructure Management Service (IMS), Deployment Management Service (DMS), etc.). For instance, the O-Cloud 120 may contain one or more O-Cloud clusters that may form the logical resource pool(s) which provide resources (e.g., computing powers, storage, networking bandwidth, hardware accelerations, etc.) to implement the O-RAN entities and the management functions. According to example embodiments, an O-Cloud cluster (and the associated physical nodes and resources) of the O-Cloud 120 may be managed by an orchestrationplatform (e.g., Kubernetes (K8s), etc.). Within the O-Cloud cluster(s), the O-RAN components (e.g., O-CU, O-DU, etc.) may be implemented in the form of Network Functions (NFs), which are the logical software entities that implement the respective RAN protocols and operations. Thus, the O-RAN components that may be implemented in an O-Cloud may also be referred to as the “O-RAN NFs”.

[0037] As illustrated in FIG. 1, the SMO 110 may be communicatively coupled to the O-Cloud 120 via an 01 interface and / or an 02 interface. These interfaces (e.g., 01, 02, etc.) may be consistent with those defined in one or more technical specifications of one or more standard organizations (e.g., the O-RAN Alliance), which provide open protocols and interfaces between the SMO 110 and O-Cloud 120, thereby enabling the SMO 110 and the O-Cloud 120 to be developed or provided by different parties (e.g., different network operators, vendors, service providers, etc.).

[0038] According to example embodiments, the SMO 110 may be configured to interoperate and coordinate with the O-Cloud 120 to manage one or more failures associated with one or more NFs implemented in the O-Cloud 120. FIG. 2 illustrates a system configuration 200 of an example use case, according to one or more example embodiments. System configuration 200 illustrates the communications and interoperations between various SMOSs of an SMO framework 210 (may also be referred to as the “SMO 210” herein) and various components in an O-Cloud 220. In this regard, it may be understood that the SMO framework 210 and O-Cloud 220 in FIG. 2 may be similar to the SMO framework 110 and O-Cloud 120 in FIG. 1, respectively.

[0039] As illustrated in FIG. 2, the SMO framework 210 may include a FOCOM 211, an NFO 212, and a RAN NF 0AM 213, which may communicatively couple to and interoperate with each other. On the other hand, the O-Cloud 220 may include an IMS 221, a DMS 222, and aplurality of NFs 223. The IMS 221 and DMS 222 may communicatively couple to and interoperate with the NFs 223 (or the physical or working nodes that implement the NFs 223).

[0040] According to example embodiments, each of the FOCOM 211, NFO 212, and ORAN 0AM 213 may be an SMOS implemented by the SMO framework 210 to communicate and interoperate with the O-Cloud 220 (or the IMS 221, DMS 222, and / or the NFs 223 implemented therein). One or more of the FOCOM 211, NFO 212, RAN NF 0 AM 213, IMS 221, DMS 222, and NFs 223 may be implemented in the software form, such as in the form of Virtualized Network Functions (VNFs), Containerized / Cloud-Native Network Functions (CNFs), and the like.

[0041] The FOCOM 211 may be configured to provide O-Cloud resources and infrastructure management (e.g., infrastructure monitoring, control, recovery, etc.) and may interface or interact with the IMS 221 of the O-Cloud 220 for resilient management. The IMS 221 may be configured to manage the infrastructure / resources (that is, infrastructure, resources, or both) of the O-Cloud 220, such as providing O-Cloud resource configuration (e.g., add, modify, and / or remove resources, etc.), life-cycle management of the O-Cloud resources (e.g., server nodes, storages, etc.), O-Cloud resource / infrastructure monitoring and fault reporting, and the like. Generally, the FOCOM 211 may determine / decide how and which O-Cloud infrastructure / resources should be managed and provide guidance / instructions to the IMS 221, and the IMS 221 may perform the management according to the guidance / instructions provided by the FOCOM 211. As illustrated in FIG. 2, the FOCOM 211 may communicate with the IMS 221 via the 02 interface, in the form of 02-IMS service.

[0042] The NFO 212 may be configured to provide management of the NFs deployed in the O-Cloud 220 (e.g., life-cycle management, deployment / redeployment management, etc.) viainteracting with the DMS 222 of the O-Cloud 220. The DMS 222 may be configured to manage one or more NT's deployed in the O-Cloud 220 (e.g., NFs 223), such as deploy / redeploy the NF(s), terminate the NF(s), monitor the NF(s) and provide fault reporting to the NFO 212, and the like. Generally, the NFO 212 may determine / decide how and which NFs should be managed and provide guidance / instructions to the DMS 222, and the DMS 222 may perform the management according to the guidance / instructions provided by the NFO 212. As illustrated in FIG. 2, the NFO 212 may communicate with the DMS 222 via the 02 interface, in the form of 02-DMS service.

[0043] The RAN NF 0AM 213 may be configured to provide one or more of: Performance Management (PM), Fault Management (FM), or Configuration Management (CM), on one or more NFs deployed in the O-Cloud 220 (e.g., NFs 223). For instance, the RAN NF 0AM 213 may continuously (or periodically) communicate with the NFs 223 (e.g., 0-DU, O-CU, etc.) via the 01 interface and collect PM data, FM data, and / or CM data associated with the NFs 223, and then provide the collected data to other SMOSs / rApps / RIC of the SMO framework 210 for further utilization, thereby providing the PM, FM, and / or CM on the NFs 223. Further, the RAN NF 0AM 213 may communicate and manage the O-RU(s) via the 01 interface. In some example implementations, the RAN NF 0AM 213 may also be referred to as the “RAN 0AM”.

[0044] In view of the above, the SMO framework 210 may implement or utilize various SMOSs to interact with various components of the O-Cloud 220, thereby managing the O-Cloud 220 in a comprehensive and efficient manner. For instance, the SMO framework 210 may implement / utilize theFOCOM211, NFO 212, and RAN NF 0AM 213 to collect various data (e.g., PM data, FM data, CM data, alarms / notifications, network Key Performance Indicators (KPIs), etc.) from the IMS 221, DMS 222, and NFs 223, via the 02 and 01 interfaces. The collected data may comprehensively define (or indicate) the status of the O-Cloud 220, enabling the SMOframework 210 to effectively and efficiently determine various types of O-Cloud NF failures. Further, upon detecting a specific type of O-Cloud NF failure (e.g., infrastructure-related O-Cloud NF failure, deployment / onboarding-related O-Cloud NF failure, application-related O-Cloud NF failure, etc.), the SMO framework210 may communicate with the respective O-Cloud component (e g., via implementing or utilizing the associated SMOS(s), etc.), thereby effectively and efficiently recovering the O-Cloud NF failure. For instance, upon detecting the infrastructure-related O-Cloud NF failure, the FOCOM 211 may be configured to communicate with the IMS 221 (via 02-IMS) to fix the infrastructure-related issues. According to example implementations, the SMO framework 210 may be configured to provide a policy and / or configuration information to the O-Cloud 220 (e.g., the FOCOM 221 may provide the policy and / or configuration information to the IMS 221, theNFO 212 may provide the policy and / or configuration information to the DMS 222, etc.).

[0045] In view of the above, example embodiments provide systems, configurations, devices, and the like, that may effectively and efficiently detect and recover an O-Cloud NF failure. Specifically, example embodiments enable an SMO framework that may efficiently and effectively interoperate with various components associated with various aspects of an O-Cloud, thereby allowing efficient and effective detection and recovery of an O-Cloud NF failure of any granularity or level. Advantageously, example embodiments of the present disclosure clarify and exemplify how to configure and utilize the O-RAN components (e.g., SMO framework, SMOS, O-Cloud, etc.) and the associated interfaces (e.g., 01, 02, etc.) to efficiently and effectively detect and recover an O-Cloud NF failure of any granularity or level, thereby reducing service disruption caused by the O-Cloud NF failure without the need for manual intervention.

[0046] Further descriptions of example methods and operations of example embodiments are provided below with reference to FIG. 3, descriptions of several example use cases are provided below with reference to FIG. 4A to FIG. 4D, and descriptions of an example device and an example environment for implementing one or more example embodiments are provided below with reference to FIG. 5 to FIG. 6, respectively.Example Methods and Operations

[0047] As described above with reference to FIG. 1, an SMO framework (or one or more SMOSs (e.g., FOCOM, NFO, RAN 0AM, etc.) associated therewith) may interoperate with various components of an O-Cloud (e.g., IMS, DMS, NFs) and perform one or more methods and operations to detect and recover an O-Cloud NF failure. Several example methods and operations are described below with reference to FIG. 3. One or more components, features, parameters, and operations involved in FIG. 3 may be similar to those described above with reference to FIG. 1 and FIG. 2, thus redundant descriptions associated therewith may be omitted below for conciseness.

[0048] For descriptive purposes, the methods and operations may be mainly described herein as being performed by one or more specific network components, although it can be understood that, in actual implementations, another related network entity(s) may perform similar / related operations, without departing from the scope of the present disclosure. For instance, an operation of the SMO framework providing a data / message to the O-Cloud may suggest or indicate an operation of the O-Cloud receiving the data / message from the SMO framework, and the like.

[0049] According to example embodiments, one or more operations of an SMO framework (or a RIC / rApp / SMOS associated therewith) may be implemented in one or more apparatuses or hardware components. For instance, the SMO framework (or one or more associated operations)may be implemented in an apparatus / device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computerexecutable instructions which, when being executed by the processor, cause the processor to perform one or more operations of the SMO framework (or the associated RIC / rApp / SMOS).

[0050] FIG. 3 illustrates an example method 300, according to one or more example embodiments. One or more operations in method 300 may be performed by an SMO framework (e.g., SMO framework 110 / 210) or one or more RICs / rApps / SMOSs associated therewith.

[0051] As illustrated in FIG. 3, at operation S310, the SMO framework may be configured to collect data associated with an O-Cloud. According to example embodiments, the SMO framework may include or implement at least one SMOS to perform operation S310. In this case, the SMOS may include at least one of: a FOCOM (e g., FOCOM 211), an NFO (e.g., NFO 212), or a RAN 0AM (e.g., RAN NF 0AM 213). According to example embodiments, the SMO framework (or the FOCOM associated therewith) may be configured to collect the data from an IMS (e.g., IMS 221) of the O-Cloud, the SMO framework (or the NFO associated therewith) may be configured to collect the data from a DMS (e.g., DMS 222) of the O-Cloud, and / or the SMO framework (or the RAN 0AM associated therewith) may be configured to collect data from one or more NFs deployed in the O-Cloud. The collected data may include, for example, data defining (or indicating) a status of the O-Cloud infrastructure / resources, data defining (or indicating) the deployment / on-boarding of an NF(s), data defining (or indicating) a status of the deployed NF(s), data defining (or indicating) the software / application of the deployed NF(s), data defining (or indicating) the network performance, data associated with an alarm / notification of a failure (or a risk of the failure), and the like. According to example embodiments, the SMO framework (or one or more SMOSs associated therewith) may be configured to repeatedly or iteratively performoperation S310 for at least a predefined period of time, thereby continuously (or periodically) collecting data associated with the O-Cloud from the respective O-Cloud components.

[0052] Upon collecting the data associated with the O-Cloud, method 300 may proceed to operation S320, at which the SMO framework may be configured to analyze the collect data to detect a failure associated with a first NF in the O-Cloud. The first NF may refer to an NF deployed in the O-Cloud, or an NF in the deployment / on-boarding process. The failure may include at least one of: a failure associated with an infrastructure of the O-Cloud (e.g., failures on the K8s components / O-Cloud hardware, workload downtime, physical node crashes due to hardware and / or software fault, resource exhaustion, etc.), a failure associated with the deployment of the first NF (e.g., deployment failure due to misconfiguration during instantiation, corruption of software images, times out in handshaking process, etc.), or a failure associated with an application of the first NF (e.g., failure due to execution or operation of the application such as software bugs or vulnerabilities, software dependency failures, the whole NF instance is corrupted / damaged, etc.).

[0053] According to example embodiments, the SMO framework may be configured to interoperate with the IMS of the O-Cloud (e.g., via the 02ims interface) to detect the failure associated with the infrastructure of the O-Cloud and / or the failure associated with the deployment of the first NF. For instance, the IMS of the O-Cloud may detect the failure associated with the infrastructure of the O-Cloud that may impact the first NF and / or the failure associated with the deployment of the first NF (e.g., NF Deployment failure based on O-Cloud / Kubernetes-related events observed within the O-Cloud infrastructure or resources), and then report the detected failure(s) to the FOCOM of the SMO framework via the 02ims interface (e.g., the FOCOM may subscribe to an 02-IMS service on the IMS, and the IMS may report the detected failure in the form of 02-IMS service provision via the 02 interface). In this regard, the SMO framework (orthe associated FOCOM) may be configured to collect data defining at least one of the failure associated with the infrastructure of the O-Cloud or the failure associated with the deployment of the first NF. Accordingly, the SMO framework may analyze the data to determine the specific type of O-Cloud NF failure associated with the first NF (if any).

[0054] According to example embodiments, the SMO framework may be configured to interoperate with the DMS of the O-Cloud (e.g., via the O2dms interface) to detect the failure associated with the failure associated with the deployment of the first NF. For instance, in addition to or in alternative to the IMS of the O-Cloud, the DMS of the O-Cloud may detect the failure associated with the deployment of the first NF (e.g., NF Deployment failure triggered by O-Cloud / Kurbemetes-related events), and then report the detected failure(s) to the NFO of the SMO framework via the O2dms interface (e.g., the NFO may subscribe to an 02-DMS service on the DMS, and the DMS may report the detected failure in the form of 02-DMS service provision via the 02 interface). In this regard, the SMO framework (or the associated NFO) may be configured to collect data defining the failure associated with the deployment of the first NF. Accordingly, the SMO framework may analyze the data to determine the specific type of O-Cloud NF failure associated with the first NF (if any).

[0055] According to example embodiments, the SMO framework may be configured to directly communicate with the NFs of the O-Cloud (including the first NF), collect data associated with the NFs, and then analyze the data to determine whether any failure occurs in any of the NFs. For instance, the SMO framework (or the associated RAN 0AM) may be configured to collect data (e g., PM data, FM data, CM data, etc.) associated with the first NF, and then detect (based on the collected data) the failure associated with the application of the first NF.

[0056] Referring still to FIG. 3, if the SMO framework detects a failure associated with the first NF, method 300 may proceed to operation S330. Otherwise, method 300 may be terminated, or alternatively, method 300 may be restarted such that the SMO framework may be configured to repeat operations S310 and S320 for at least a predefined period of time.

[0057] At operation S33O, the SMO framework may be configured to configure or instruct the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud. The second NF may include at least one of a standby or redundant NF instantiated before the failure is determined, or a new NF instantiated upon detecting the failure. According to example embodiments, the second NF may be deployed in the O-Cloud on infrastructure or resources that are different from those utilized by the first NF. In some example embodiments, the SMO framework may be configured to lock or deactivate a cell or a carrier associated with the first NF, and / or may be configured to unlock or activate a cell or a carrier associated with the second NF.

[0058] Assuming that the failure is associated with the infrastructure of the O-Cloud, the SMO framework (or the associated FOCOM) may be configured to communicate with the IMS of the O-Cloud to fix the failure associated with the infrastructure of the O-Cloud (e.g., restart the failed infrastructure / resources, perform load-balancing to reduce the load on the associated infrastructure / resources, etc.). Further, the SMO framework (or the associated FOCOM) may also be configured to determine whether additional O-Cloud resources are required for fixing the failure associated with the infrastructure of the O-Cloud, and then communicate with the IMS of the O-Cloud to provision the additional O-Cloud resources when required (e.g., when it is determined that the additional O-Cloud resources are to be provisioned for fixing the failure, etc.). Subsequently, the SMO framework (or the associated NFO) may be configured to instruct the DMS of the O-Cloud to redeploy the service associated with the first NF to the second NF (e.g.,trigger the recreation of NF Deployment / deployment of whole NF instance on the standby / redundant second NF, trigger the instantiation of the second NF and then the recreation of the NF Deployment / deployment of the whole NF instance on the instantiated second NF, etc.), thereby migrating the service associated with the first NF to the second NF.

[0059] As another example, assuming that the failure is associated with the deployment of the first NF, the DMS of the O-Cloud may automatically recreate or instantiate the second NF upon detecting the failure. Accordingly, upon receiving the associated data from the DMS and detects the same failure, the SMO framework (or the associated NFO) may communicate or instruct the DMS to redeploy the service associated with the first NF to the second NF, thereby migrating the service associated with the first NF to the second NF.

[0060] As yet another example, assuming that the failure is associated with the application of the first NF, the SMO framework (or the associated RAN 0AM) may be configured to migrate the service of the first NF to the second NF. For instance, the RAN 0AM may migrate the state information (e.g., session data, subscriber information, etc.) from the first NF to the second NF via state replication, update routing tables and network configurations to reroute the traffic from the first NF to the second NF, and the like.

[0061] Upon migrating the service of the first NF to the second NF, the SMO framework may configure the second NF (via implementing the RAN 0AM, etc.) with the required cell(s) and associated resource(s) (e.g., carriers), etc.). Once the cell(s) and the associated resource(s) are unlocked and activated, the service of the first NF is successfully recovered on the second NF and the second NF is ready to offer the associated service to the users. In this regard, upon configuring the O-Cloud to migrate the service to the second NF, the SMO framework may continue collect the data associated with the O-Cloud (e.g., collect alarms and performance counters from the O-Cloud via the 02ims and 02dms interfaces, and / or from the NF applications via the 01 interface, through subscription mechanisms.), and then determine whether the O-Cloud NF failure is successfully recovered (e.g., whether the second NF is operational and has properly connected / synchronized with the associated 0-RU to provide the migrated service, etc.).

[0062] In view of the above, example embodiments provide methods and operations that effectively and efficiently detect and recover O-Cloud NF failure. Advantageously, method and operations in FIG. 3 may be automatically implemented by an SMO framework to effectively and efficiently detect an O-Cloud NF failure of various granularities / levels and appropriately configure the O-Cloud to recover from the detected O-Cloud NF failure.

[0063] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 3 are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 3 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional advantages may be achieved, and the like, without departing from the scope of the present disclosure. Further, it can be understood that the example embodiments FIG. 3 may achieve similar technical advantages and significance described above with reference to FIG. 1 and FIG. 2, since the methods and operations in FIG. 3 may be implemented in the system configurations and devices in FIG. 1 and FIG. 2.Example Use Cases

[0064] An example use case, in which the system configurations, apparatuses, methods, and operations in FIG. 1 to FIG. 3 may be involved, are described below with reference to FIG.4 A to FIG. 4D.

[0065] Specifically, FIG. 4A to FIG. 4D illustrate a call flow of an example use case 400, according to one or more example embodiments. Example use case 400 may involve one or more RAN entities / network functions, as well as the associated mechanisms, operations, data, and the like, described above with reference to FIG. 1 to FIG. 3. For instance, as illustrated in FIG. 4A to FIG. 4D, example use case 400 may involve an SMO framework 410 (that includes a FOCOM 411, an NFO 412, and a RAN 0AM 413), an O-Cloud 420 (that includes an IMS 421, a DMS 422, an Old NF Deployment 423, and a New NF Deployment 424), and an O-RU 430. In this regard, the SMO framework 410 (and the SMOSs 411-413 included therein) may be similar to the SMO framework 210 (and the SMOSs 211-213) in FIG. 2, the O-Cloud 420 (and the IMS 421 and DMS 422) may be similar to the O-Cloud 220 (and the IMS 221 and DMS 222) in FIG. 2, the Old NF Deployment 423 and the New NF Deployment 424 may be part of the NFs 223 in FIG. 2 (and may corresponding to the first NF and second NF in method 300 of FIG. 3), and the like. For descriptive purposes, the Old NF Deployment 423 may also be referred to as the “old NF” while the New NF Deployment 424 may also be referred to as the “new NF”. The O-RU 430 may refer to the RAN entity that includes the antenna-arrays (e.g., trx-arrays, etc.) and enables the operations of antennaarray carriers linked to the network cells associated with or managed by the O-Cloud 420. In some example implementations, the O-RU 430 may handle the fronthaul and air interfaces, as well as the reporting of performance data (e.g., counters, etc.) and failures.

[0066] Generally, FIG. 4A illustrates a call flow that illustrates various O-Cloud NF failures of various granularities / levels. FIG. 4B illustrates a call flow that illustrates various operations implemented by the SMO framework 410 to detect the O-Cloud NF failures of various granularities / levels. FIG. 4C and FIG. 4D each illustrates a call flow that illustrates various operations implemented by the SMO framework 410 to recover the detected O-Cloud NF failures.The first operation / initial step in FIG. 4B may be performed or triggered subsequent to the last operation / final step in FIG. 4A, the first operation / initial step in FIG. 4C may be performed or triggered subsequent to the last operation / final step in FIG. 4B, and the first operation / initial step in FIG. 4D may be performed or triggered subsequent to the last operation / final step in FIG. 4C.

[0067] Example use case 400 may be triggered while assuming that the following preconditions are satisfied: at least one standby / redundant NF is assumed to be available upon active NF failure; the resiliency mechanisms are available to take over the operation of the cell(s) associated with an impacted / failed NF thereby restoring services to the end users with minimal disruption; O-Cloud cluster is provisioned and an NF Deployment is running; SMO framework 410 has subscribed to alarms and performance counters from the O-Cloud 420 via 02ims and / or O2dms interfaces; and SMO framework 410 has subscribed to alarms and performance counters from the NFs via 01 interface.

[0068] Referring to FIG. 4A, at optional steps la to 1c, one or more failures have occurred at the old NF 423. For instance, at step la, a failure has occurred at the old NF 423 due to one or more issues related to the O-Cloud infrastructure (e.g., workload downtime or crashes, etc.). At optional step lb, a failure has occurred at the old NF 423 due to deployment and / or on-boarding issues. At optional step 1c, a failure has occurred at the old NF 423 due to the operation and / or execution of the application associated therewith. These failures on old NF 423 may occur concurrently with one another at the same time, or may occur at different time points.

[0069] Referring next to FIG. 4B, at step 2, the SMO framework 410 may collect or receive the data associated with the O-Cloud (e g., alarms, PM data, FM data, CM data, etc.) from the O-Cloud 420 (e.g., the FOCOM 411 may collect the data from the IMS 421 via the 02-IMS interface, the NFO 412 may collect the data from the DMS 422 via the 02-DMS interface, the RAN 0AM413 may collect the data from the old NF 423 and new NF 424 via the 01 interface, etc.). Accordingly, the SMO framework 410 may analyze the data to determine whether any failure(s) have occurred at the O-Cloud 420.

[0070] Alternative step 3a illustrates that the SMO framework 410 communicates with the IMS 421 via the O2-IMS interface to detect infrastructure-related failure of the O-Cloud 420 that may impact one or more of the deployed NFs (e.g., old NF 423). Alternative steps 3b and 3c illustrates the example operations for implementing alternative step 3a. Specifically, at alternative step 3b, the IMS 421 may detect the O-Cloud infrastructure failure, such as failures associated with K8s components and / or underlying hardware. Accordingly, at alternative step 3c, the IMS 421 may report the detected O-Cloud infrastructure failure to the FOCOM 411 via the 02-IMS interface, thereby enabling the SMO framework 410 to detect the O-Cloud infrastructure failure and allowing coordinated fault management and failure recovery.

[0071] Alternative step 4a illustrates that the SMO framework 410 communicates with the IMS 421 via the 02-IMS interface and / or the DMS 422 via the 02-DMS interface, to detect NF Deployment-related failure that may impact one or more of the deployed NFs (e.g., old NF 423). Alternative steps 4b to 4e illustrate the example operations for implementing alternative step 4a. Specifically, at alternative step 4b, the IMS 421 may detect the NF Deployment failure based on, for example, K8s-related events observed within the O-Cloud infrastructure. Similarly, at alternative step 4c, the DMS 422 may detect the NF Deployment failure based on, for example, one or more observed K8s-related events. The NF Deployment failure observed by the IMS 421 may (but not necessarily) be similar to the NF Deployment failure observed by the DMS 422. Accordingly, at alternative step 4d, the IMS 421 may report the detected NF Deployment failure to the FOCOM 411 via the 02-IMS interface, thereby enabling the SMO framework 410 to detectthe NF Deployment failure and allowing coordinated fault management and failure recovery. Similarly, at alternative step 4e, the DMS 422 may report the detected NF Deployment failure to the NFO 412 via the 02-DMS interface, thereby enabling the SMO framework 410 to detect the NF Deployment failure and allowing coordinated fault management and failure recovery. In some example embodiments, the SMO framework 410 may utilize the reports or data from the IMS 421 and the DMS 422 to verify the accuracy of the detection of the NF Deployment failure, before initiating or performing the recovery operations associated therewith.

[0072] Alternative step 5 illustrates that the SMO framework 410 communicates with the deployed network functions (e.g., old NF 423) via the 01 to detect NF application failure that may impact one or more of the deployed NFs (e.g., old NF 423). As described above, the SMO framework 410 may implement the RAN 0AM 413 to collect various data (e.g., alarms, PM data, CM data, FM data, etc.) from the deployed network functions and then analyze the collected data to detect the NF application failure.

[0073] Referring next to FIG. 4C, assuming that one or more failures are detected, at step 6, the SMO framework 410 may initiate a service migration procedure to migrate a service associated with the affected / failing NF (e.g., old NF 423) to a redundant / newly instantiated NF (e.g., new NF 424), thereby restoring the service impacted by the affected / failing NF. In some example implementations, the SMO framework 410 may trigger the service migration procedure by providing policy and / or configuration details to the O-Cloud 420. For instance, the SMO framework 410 (or the associated FOCOM 411) may send the triggers, policy, and / or configuration details to the IMS 421 via the 02-IMS interface, the SMO framework 410 (or the associated NFO 412) may send the triggers, policy, and / or configuration details to the DMS 422 via the 02-DMSinterface, and the like, thereby facilitating the service migration procedure and supporting the failure recovery.

[0074] At step 7, if the SMO framework 410 determines that the impacted / failing NF (e.g., NF 423) is still reachable through the 01 interface, the SMO framework 410 (or the associated RAN 0AM 413) may communicate with the 0-RU 430 to lock, deactivate, and / or remove the cell(s) and resource(s) (e.g., carriers, etc.) associated with the impacted / failing NF.

[0075] Alternative steps 8a to 8d illustrate that the SMO framework 410 communicates with the IMS 421 via the 02-IMS interface and the DMS 422 via the 02-DMS interface during the service migration procedure to recover the O-Cloud infrastructure failure. At step 8a, the SMO framework 410 (or the associated FOCOM 411) may, in coordination with the IMS 422, automate the resolution or recovery of the O-Cloud infrastructure-related failures. At optional step 8b, if the SMO framework 410 determines that additional O-Cloud resources are needed, the SMO framework 410 (or the associated FOCOM 411) may coordinate with the IMS 421 to provision the required O-Cloud resources. Subsequently, at step 8c, the SMO framework 410 (or the associated NFO 412) may communicate with or instruct the DMS 422 (via the 02-DMS interface) to trigger the redeployment of the NF (e.g., migrate the service of the affected / failing NF to the new / redundant NF, etc.). Accordingly, at step 8d, the DMS 422 may initiate the recreation of NF Deployment or NF Deployments (e.g., redeploying the whole NF instance) on the new / redundant NF (e.g., new NF 424) or other available O-Cloud resources.

[0076] Alternative steps 9a to 9d illustrates that the SMO framework 410 communicates with the IMS 421 via the 02-IMS interface and the DMS 422 via the 02-DMS interface during the service migration procedure to recover the NF Deployment failure and / or the NF application failure. At step 9a, the SMO framework 410 (or the associated NFO 412) may instruct the DMS422 (by providing triggers, policy, and / or configuration details thereto) to trigger the redeployment of NF (e.g., recreating a standby NF deployment such as the new NF 424, etc.). Alternatively or additionally, at step 9b, the DMS 422 may automatically recreates a standby NF deployment (e.g., new NF 424) to recover services affected by the failed NF deployment. Subsequently, at step 9c, the SMO framework 410 (or the associated NFO 412) may communicate with or instruct the DMS 422 (via the 02-DMS interface) to trigger the redeployment of the NF (e.g., migrate the service of the affected / failing NF to the new / redundant NF, etc.). Accordingly, at step 9d, the DMS 422 may initiate the recreation of NF Deployment or NF Deployments (e.g., redeploying the whole NF instance) on the new / redundant NF (e.g., new NF 424) or other available O-Cloud resources.

[0077] Referring next to FIG. 4D, following the NF failure recovery (at steps 6-9c), at step 10, the SMO framework 410 (or the associated RAN 0AM 413) may communicate with the O-RU 430 to configure the redundant or new NF (e.g., new NF 424) with the required cell(s) and associated resource(s) (e.g., carriers). The cell(s) are then unlocked and activated once the associated resources are successfully configured in both the NF 424 and the 0-RU 430. Accordingly, at step 11, the service associated with the impacted / failed NF (e.g., NF 423) is migrated and recovered at the standby / new NF (e.g., new NF 424), and the standby / new NF is ready to offer the service to the users.

[0078] At step 12, the SMO framework 410 may collect data (e.g., alarms, performance counters, etc.) from the O-Cloud 420 (e.g., via the 02-IMS interface, the 02-DMS interface, the 01 interface, etc.) through subscription mechanisms. Accordingly, if the SMO framework 410 determines (based on the collected data) that the standby / new NF 424 is operation and has properly connected / synchronized with the 0-RU, and has successfully recovered the service associated withthe impacted / failing NF 423, the SMO framework 410 may determine that a successful postcondition is detected and the example use case 400 may be ended.

[0079] On the other hand, the SMO framework 410 may determine that a failure postcondition is detected if the SMO framework 410 determines (based on the collected data) one or more of the following scenarios: the standby / new NF fails during the service migration or becomes unavailable when it is due to become active; an event messaging for the flow is lost; a configuration (e.g., cell configuration, resource configuration, etc.) was not performed properly / successfully; the standby / new NF losses the configuration data from the configuration replica; the old / active NF returns to the service and the detected failure is resolved during the service migration procedure (before the service has successfully migrated to the standby / new NF); or the connectivity / functionality of the SMO framework 410 becomes unavailable. In this case, the SMO framework 410 may repeat the call flows and operations in FIG. 4A to FIG. 4D to re-attempt the service migration and failure recovery on another standby / new NF. If no other NF is available, the O-RU 430 may take an autonomous reset to attempt to recover from the failure.

[0080] It is contemplated that the configurations in FIG. 4A to FIG. 4D are merely examples, and the scope of the present disclosure is not limited thereto. Specifically, the more / less components may be involved, some of the steps may be performed in any suitable sequential manner, and the like, without departing from the scope of the present disclosure. Further, it is contemplated that the configurations, mechanisms, and operations in example use case 400 may also be implemented in difference scenarios (e.g., when a risk / possibility of a failure(s) is detected, when a planned downtime of an NF is detected, etc.), in addition to or in alternative to the described scenario where the failure(s) has occurred.

[0081] In view of the above, example embodiments provide several example use cases that illustrate and exemplify the implementations of the O-Cloud NF recovery. Specifically, the example use cases show how example embodiments of the present disclosure may be implemented in an O-RAN-based network. Advantageously, the example use cases in FIG. 4A to FIG. 4D exemplify that example embodiments can be efficiently and effectively implemented in the existing O-RAN network architecture while utilizing the existing O-RAN components and interfaces without substantive modification thereto, thereby reducing the roll-out period and implementation difficulty. It is also contemplated that the technical advantages described above with reference to FIG. 1 to FIG. 3 may be similarly applied to the example use cases in FIG. 4A to FIG. 4D, without departing from the scope of the present disclosure.Examples of Device

[0082] One or more components of the example embodiments (e.g., SMO framework, etc.), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity may be implemented in one or more devices like a server(s), and the like.

[0083] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with the SMO framework (or the associated SMOSs) 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.

[0084] FIG. 5 illustrates an embodiment of a device 500. As shown in FIG. 5, the device 500 may include a processor 510, a memory 520, a storage component 530, an input component 540, an output component 550, a communication interface 560, and a bus 570.

[0085] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 510 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 510 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.

[0086] Memory 520 includes a non-transitory computer readable medium. Memory 520 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 510. The memory 520 comprises machine-readable instructions which are executable by the processor 510. These machine-readable instructions when executed by the processor 510 cause the processor 510 to perform one or more method steps of an embodiment described above.

[0087] Storage component 530 stores information and / or software related to the operation and use of the device 500. For example, storage component 530 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.

[0088] Input component 540 is configured to receive information, such as user input. For example, the input component 540 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 540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0090] Communication interface 560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 560 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 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0091] The bus 570 acts as an interconnect between the processor 510, the memory 520, the storage component 530, the input component 540, the output component 550, and the communication interface 560 of the device 500. The bus 570 may include a wired interconnection or a wireless interconnection.

[0092] The number and arrangement of components shown in FIG. 5 are provided as an example. In practice, device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 5. Additionally, or alternatively, a set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500.Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 500 in communication with one another.Example Implementation Environment

[0093] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0094] FIG. 6 illustrates a diagram of an example environment 600 in which systems and / or methods, described herein, may be implemented. The implementation environment 600 includes a UE (User equipment) 111, a service environment 620, and a network 630. The service environment 620 includes one or more sub-environments 621. To illustrate this, FIG. 6 shows, for convenience, examples of a 1st sub-environment 621-1, a 2nd sub -environment 621-2, and an N-th sub-environment 621-N (where N is any natural number).

[0095] The UE 610 is connected to the network 630, and the network 630 is connected to the service environment 620. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 610 and the service environment 620 are connected via the network 630.

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

[0097] The example FIG. 6 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 ”

[0098] For example, the UE 610 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.

[0099] The service environment 620 is an environment that communicates with the UE 610 to provide one or more services. The service environment 620 receives information from the UE 610 and / or sends information to the UE 610. Also, the service environment 620 may generate and / or store information to be transmitted, as necessary. Also, the service environment 620 may store and / or process information that is received, as necessary. For example, the service environment 620 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.

[0100] The example FIG. 6 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."

[0101] The one or more services provided by the service environment 620 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 UE 610, a service that stores information from the UE 610, or a service that performs processing based on information from the UE 610 and returns the results of the processing.

[0102] In an embodiment, the Service Environments 620 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.

[0103] 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, when means 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 embodimentsimplemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0104] The service environment 620 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 620 can be determined as appropriate. Additionally, if the service environment 620 includes one or more sub-environments 621, the placement of devices can be determined based on predetermined policies for each sub-environment 621. For example, devices related to the first service may be placed in the 1st sub-environment 621-1, and devices related to the second service may be placed in the 2nd sub -environment 621-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 621-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 621-2. In this way, specific devices can be placed in specific sub -environments 621. Conversely, each sub-environment 621 can be specialized for a particular purpose.

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

[0106] The network 630 is a network that exchanges information between the UE 610 and the service environment 620. The network 630 includes one or more wired and / or wireless networks.

[0107] For example, the network 630 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), alocal 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.

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

[0109] The number and arrangement of devices and networks shown in FIG. 6 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.Various Aspects of Embodiments

[0110] Example embodiments introduces new parameters, attributes, mechanisms, and features that supplement and enhance the disclosures of one or more standard specifications. As a non-limiting example, example embodiments supplement and enhance at least one technical specification associated with the O-RAN Alliance (e.g., O-RAN.WG1.TR.O-RES), as detailed blow (the supplementations and enhancements provided by example embodiments are presented in table and / or bold format).

[0111] To begin with, the following is added to “7 Potential resiliency solutions” of O- RAN.WG1.TR.O-RES:&&&&&

[0112] The call flows consistent with FIG. 4A to FIG. 4D are also supplemented as Figure 7.5.3-1 of 0-RAN.WG1.TR.0-RES.

[0113] In view of the above, example embodiments introduce specified and standardized approaches for implementing the O-Cloud NF failure recovery in O-RAN-based architecture. Specifically, example embodiments clarify how specifically the components in the 0-RAN architecture (e.g., SMO, FOCOM, NFO, RAN 0AM, O-Cloud, IMS, DMS, etc.) and the existing 0-RAN interfaces (e.g., 01 interface, 02 interface, etc.) can be utilized to implement the O-Cloud NF failure recover. Accordingly, example embodiments may be implemented in the O-RAN-based networks in a clear and standardized manner to effectively and efficiently detect and recover various types of O-Cloud NF failures of various granularities and levels.

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

[0115] Specifically, 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.

[0116] Some embodiments may relate to a device, 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.

[0117] 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), electrically erasable programmable read-only memory (EEPROM), 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-readablestorage 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.

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

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

[0120] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In thelatter 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.

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

[0122] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices 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 flowchartand / or block diagram block or blocks.

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

[0124] 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 limited to the implementations. Thus, the operation and behavior of the systems and / or methods were 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.

[0125] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system comprising: a Service Management and Orchestration (SMO) framework configured to: collect data associated with an Open Radio Access Network (O- RAN) Cloud (O-Cloud); analyze the collected data to detect a failure associated with a first Network Function (NF) deployed in the O-Cloud, wherein the failure comprises at least one of: a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF; and based on determining the failure, configure the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud.Item [2] : The system according to item

[0001] , wherein the SMO framework comprises a Federated O-Cloud Management and Orchestration (FOCOM) configured to: collect, from an Infrastructure Management Service (IMS) of the O-Cloud, data defining at least one of: the failure associated with the infrastructure of the O-Cloud or the failure associated with the deployment of the first NF.Item [3]: The system according to one or more of items [l]-[2], wherein the SMO framework comprises a Network Function Orchestration (NFO) configured to: collect, from a Deployment Management Service (DMS) of the O-Cloud, data indicating the failure associated with the deployment of the first NFItem [4]: The system according to one or more of items [l]-[3], wherein the SMO framework comprises a Radio Access Network (RAN) Operations, Administrations, and Maintenance (0AM) configured to implement the RAN 0AM to: collect at least one of: a Performance Measurement (PM) data associated with the first NF, a Fault Management(FM) data associated with the first NF, or a Configuration Management (CM) data associated with the first NF; and detect, based on the collected data, the failure associated with the application of the first NF.Item [5]: The system according to item [2], wherein the FOCOM is configured to: communicate with the IMS to fix the failure associated with the infrastructure of the O-Cloud.Item [6]: The system according to item [5], wherein the FOCOM is configured to: determine whether additional O-Cloud resources are to be provisioned for fixing the failure associated with the infrastructure of the O-Cloud; and based on determining that the additional O-Cloud resources are to be provisioned, communicate with the IMS to provision the additional O-Cloud resources.Item [7]: The system according to item [3], wherein the NFO is configured to: instruct the DMS of the O-Cloud to redeploy the service associated with the first NF to the second NF.Item [8]: The system according to one or more of items

[0001] -[7], wherein the second NF comprises at least one of: a standby NF instantiated before the failure is determined, or a new NF instantiated upon detecting the failure.Item [9]: The system according to one or more of items [l]-[8], wherein: the SMO framework locks or deactivates a cell or a carrier associated with the first NF; and the SMO framework unlocks or activates a cell or a carrier associated with the second NF.Item

[0010] : The system according to one or more of items [l]-[9], wherein the second NF is deployed in the O-Cloud on infrastructure or resources that are different from those utilized by the first NF.Item

[0011] : A method comprising: collecting, by a Service Management and Orchestration (SMO) framework, data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud); analyzing, by the SMO framework, the collected data to detect a failure associated with a first Network Function (NF) deployed in the O-Cloud, wherein the failure comprises at least one of: a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF; and based on determining the failure, configuring, by the SMO framework, the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud.Item

[0012] : The method according to item

[0011] , wherein the SMO framework comprises a Federated O-Cloud Management and Orchestration (FOCOM), and wherein the method comprises: collecting, by the FOCOM and from an Infrastructure Management Service (IMS) of the O-Cloud, data defining at least one of: the failure associated with the infrastructure of the O-Cloud or the failure associated with the deployment of the first NF.Item

[0013] : The method according to one or more of items

[0011] -

[0012] , wherein the SMO framework comprises a Network Function Orchestration (NFO), and wherein the method comprises: collecting, by the NFO and from a Deployment Management Service (DMS) of the O-Cloud, data indicating the failure associated with the deployment of the first NF.Item

[0014] : The method according to one or more of items

[0011] -

[0013] , wherein the SMO framework comprises a Radio Access Network (RAN) Operations, Administrations, and Maintenance (OAM), and wherein the method comprises: collecting, by the 0AM, at least one of: a Performance Measurement (PM) data associated with the first NF, a FaultManagement (FM) data associated with the first NF, or a Configuration Management (CM) data associated with the first NF; and detecting, by the OAM and based on the collected data, the failure associated with the application of the first NF.Item

[0015] : The method according to item

[0012] , wherein the method comprises: communicate, by the FOCOM, with the IMS to fix the failure associated with the infrastructure of the O-Cloud.Item

[0016] : The method according to item

[0015] , wherein the method comprises: determining, by the FOCOM, whether additional O-Cloud resources are to be provisioned for fixing the failure associated with the infrastructure of the O-Cloud; and based on determining that the additional O-Cloud resources are to be provisioned, communicating, by the FOCOM, with the IMS to provision the additional O-Cloud resources.Item

[0017] : The method according to item

[0013] , wherein the method comprises: instructing, by the NFO, the DMS of the O-Cloud to redeploy the service associated with the first NF to the second NF.Item

[0018] : The method according to one or more of items

[0011] -

[0017] , wherein the second NF comprises at least one of: a standby NF instantiated before the failure is determined, or a new NF instantiated upon detecting the failure.Item

[0019] : The method according to one or more of items

[0011] -

[0018] , wherein: the SMO framework locks or deactivates a cell or a carrier associated with the first NF; and the SMO framework unlocks or activates a cell or a carrier associated with the second NF.Item

[0020] : The method according to one or more of items

[0011] -

[0019] , wherein the second NF is deployed in the O-Cloud on infrastructure or resources that are different from those utilized by the first NF.

[0126] It can be 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.

Claims

What is claimed is:

1. A system comprising:a Service Management and Orchestration (SMO) framework configured to:collect data associated with an Open Radio Access Network (O-RAN) Cloud (O- Cloud);analyze the collected data to detect a failure associated with a first Network Function (NF) deployed in the O-Cloud, wherein the failure comprises at least one of: a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF; and based on determining the failure, configure the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud.

2. The system according to claim 1, wherein the SMO framework comprises a Federated O-Cloud Management and Orchestration (FOCOM) configured to:collect, from an Infrastructure Management Service (IMS) of the O-Cloud, data defining at least one of: the failure associated with the infrastructure of the O-Cloud or the failure associated with the deployment of the first NF.

3. The system according to claim 1, wherein the SMO framework comprises a Network Function Orchestration (NFO) configured to:collect, from a Deployment Management Service (DMS) of the O-Cloud, data indicating the failure associated with the deployment of the first NF.

4. The system according to claim 1, wherein the SMO framework comprises a Radio Access Network (RAN) Operations, Administrations, and Maintenance (OAM) configured to implement the RAN OAM to:collect at least one of: a Performance Measurement (PM) data associated with the first NF, a Fault Management (FM) data associated with the first NF, or a Configuration Management (CM) data associated with the first NF; anddetect, based on the collected data, the failure associated with the application of the first NF.

5. The system according to claim 2, wherein the FOCOM is configured to:communicate with the IMS to fix the failure associated with the infrastructure of the O-Cloud.

6. The system according to claim 5, wherein the FOCOM is configured to:determine whether additional O-Cloud resources are to be provisioned for fixing the failure associated with the infrastructure of the O-Cloud; andbased on determining that the additional O-Cloud resources are to be provisioned, communicate with the IMS to provision the additional O-Cloud resources.

7. The system according to claim 3, wherein the NFO is configured to:instruct the DMS of the O-Cloud to redeploy the service associated with the first NF to the second NF.

8. The system according to claim 1, wherein the second NF comprises at least one of: a standby NF instantiated before the failure is determined, or a new NF instantiated upon detecting the failure.

9. The system according to claim 1, wherein:the SMO framework locks or deactivates a cell or a carrier associated with the first NF; and the SMO framework unlocks or activates a cell or a carrier associated with the second NF.

10. The system according to claim 1, wherein the second NF is deployed in the O-Cloud on infrastructure or resources that are different from those utilized by the first NF.

11. A method comprising:collecting, by a Service Management and Orchestration (SMO) framework, data associated with an Open Radio Access Network (0-RAN) Cloud (O-Cloud);analyzing, by the SMO framework, the collected data to detect a failure associated with a first Network Function (NF) deployed in the O-Cloud, wherein the failure comprises at least one of: a failure associated with an infrastructure of the O-Cloud, a failure associated with the deployment of the first NF, or a failure associated with an application of the first NF; and based on determining the failure, configuring, by the SMO framework, the O-Cloud to migrate a service associated with the first NF to a second NF in the O-Cloud.

12. The method according to claim 11, wherein the SMO framework comprises a Federated O- Cloud Management and Orchestration (FOCOM), and wherein the method comprises:collecting, by the FOCOM and from an Infrastructure Management Service (IMS) of the O-Cloud, data defining at least one of: the failure associated with the infrastructure of the O-Cloud or the failure associated with the deployment of the first NF.

13. The method according to claim 11, wherein the SMO framework comprises a Network Function Orchestration (NFO), and wherein the method comprises:collecting, by the NFO and from a Deployment Management Service (DMS) of the O-Cloud, data indicating the failure associated with the deployment of the first NF.

14. The method according to claim 11, wherein the SMO framework comprises a Radio Access Network (RAN) Operations, Administrations, and Maintenance (OAM), and wherein the method comprises:collecting, by the OAM, at least one of: a Performance Measurement (PM) data associated with the first NF, a Fault Management (FM) data associated with the first NF, or a Configuration Management (CM) data associated with the first NF; anddetecting, by the OAM and based on the collected data, the failure associated with the application of the first NF.

15. The method according to claim 12, wherein the method comprises:communicate, by the FOCOM, with the IMS to fix the failure associated with the infrastructure of the O-Cloud.

16. The method according to claim 15, wherein the method comprises:determining, by the FOCOM, whether additional O-Cloud resources are to be provisioned for fixing the failure associated with the infrastructure of the O-Cloud; and based on determining that the additional O-Cloud resources are to be provisioned, communicating, by the FOCOM, with the IMS to provision the additional O-Cloud resources.

17. The method according to claim 13, wherein the method comprises:instructing, by the NFO, the DMS of the O-Cloud to redeploy the service associated with the first NF to the second NF.

18. The method according to claim 11, wherein the second NF comprises at least one of: a standby NF instantiated before the failure is determined, or a new NF instantiated upon detecting the failure.

19. The method according to claim 11, wherein:the SMO framework locks or deactivates a cell or a carrier associated with the first NF; and the SMO framework unlocks or activates a cell or a carrier associated with the second NF.

20. The method according to claim 11, wherein the second NF is deployed in the O-Cloud on infrastructure or resources that are different from those utilized by the first NF.

Images