Resiliency for open radio access network-centralized unit

Abstract

An apparatus is disclosed. The apparatus analyzes data, received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP), associated with the first O-CU-CP. The apparatus detects a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP. The apparatus determines to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure. The apparatus transmits, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of each O-DU. The apparatus receives, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed. The apparatus configures, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.

Description

RESILIENCY FOR OPEN RADIO ACCESS NETWORK-CENTRALIZED UNITCROSS-REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims priority to India Provisional Application No. 202411100163, filed on December 17, 2024, and India Non-Pro visional Application No. 202411100163, filed on April 30, 2025, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to resiliency for an Open Radio Access Network (O-RAN)- Centralized Unit (O-CU).BACKGROUND

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

[0004] In the context of telecommunication systems, a gNodeB (gNB), also referred to as a Next Generation Node B, serves as a base station within a Fifth Generation (5G) network architecture. The gNB supersedes an Evolved Node B (eNodeB) utilized in Long Term Evolution (LTE) networks. The gNB is configured for the transmission and reception of radio signals to and from a User Equipment (UE). Additionally, the gNB performs a variety of critical functions, including data transmission scheduling, radio resource management, and mobility management. The architecture of the gNB may include one or more Centralized Units (CUs), multiple Distributed Units (DUs), and several Radio Units (RUs).SUMMARY

[0005] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the disclosure nor is it intended for determining the scope of the disclosure.

[0006] According to one embodiment of the present disclosure, an apparatus is disclosed. The apparatus is configured to analyze data received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP). The received data is associated with the first O-CU-CP. The apparatus is configured to detect a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP. The apparatus is configured to determine to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure. The apparatus is configured to transmit, to each O-Distributed Unit (0-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of each 0-DU. The apparatus is configured to receive, from each 0-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed. The apparatus is configured to configure, each 0-DU, to connect with the at least one second O-CU- CP based on the result notification.

[0007] According to another embodiment of the present disclosure, a method is disclosed. The method includes analyzing data received from a first Open Radio Access Network (ORAN)- Centralized Unit Control Plane (O-CU-CP). The received data is associated with the first O-CU- CP. The method includes detecting a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP. The method includes determining to switch services from thefirst O-CU-CP to at least one second O-CU-CP in response to detection of the failure. The method includes transmitting, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of each O-DU. The method includes receiving, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed. The method includes configuring, each O- DU, to connect with the at least one second O-CU-CP based on the result notification.

[0008] According to another embodiment of the present disclosure, a non-transitory computer- readable medium is disclosed. The non-transitory computer-readable medium stores instructions. The instructions when executed by one or more processors, cause the one or more processors to analyze data received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP). The received data is associated with the first O-CU-CP. The instructions further cause the one or more processors to detect a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP. The instructions further cause the one or more processors to determine to switch services from the first O-CU-CP to at least one second O-CU- CP in response to detection of the failure. The instructions further cause one or more processors to transmit, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of each O-DU. The instructions further cause one or more processors to receive, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed. The instructions further cause one or more processors to configure, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] 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:FIG. 1 illustrates a disaggregated architecture of a Next Generation Node B (gNB), according to the state of the art;FIG. 2 illustrates an enhanced resiliency use case for an Open Radio Access Network (O- RAN)-Centralized Unit (O-CU) and associated partial O-CU failure, according to an embodiment as disclosed herein;FIG. 3 illustrates an O-CU-Control Plane (O-CU-CP) resiliency scenario in case of an 01 failure, according to an embodiment as disclosed herein;FIGS. 4A to 4D illustrate an O-CU-CP resiliency scenario in case of the O-CU-CP failure within 0-RAN networks, according to an embodiment as disclosed herein;FIG. 5 illustrates a flow chart of an example method, according to an embodiment as disclosed herein; andFIG. 6 illustrates a diagram of example components of an apparatus, according to an embodiment as disclosed herein.DETAILED DESCRIPTION

[0010] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from practice of theimplementations. 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 at least one of the embodiments in the present disclosure. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

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

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

[0013] 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” (in other words, nouns not mentioned in the plural) are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B.

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

[0015] Resiliency recovery for an Open Radio Access Network (O-RAN)-Centralized Unit CU (O-CU) in the telecommunication systems is essential for maintaining service continuity in an O- RAN architecture. The resiliency recovery may involve implementing redundancy through one or more backup systems and load balancing to ensure availability. One or more continuous monitoring tools may detect faults and trigger alerts, allowing for quick responses. In addition, automated recovery mechanisms, such as self-healing and failover protocols, enable the O-CU to restart or reroute processes without human intervention. Regular data backups and consistency checks help maintain data integrity during recovery. In other words, the resiliency recovery for the O-CU in the telecommunication systems involves implementing strategies to ensure that thetelecommunication system may recover quickly from failures, maintain service availability, and protect data integrity.

[0016] A disaggregated architecture is defined in the Third Generation Partnership Project (3GPP) decomposing a Next Generation Node B (gNodeB or gNB) into multiple logical entities. FIG. 1 illustrates the disaggregated architecture of a gNB 100, according to the state of the art. The multiple logical entities may include one or more first units 102 and one or more second units 104. The one or more first units 102 may be represented by at least one distributed unit (referred to as gNB-DU). The one or more second units 104 may be represented by a centralized unit (referred to as gNB-CU). The gNB-CU may be further split into a CU Control Plane (CP) part, also referred to as a gNB-CU-CP, and a CU User Plane (UP) part, also referred to as a gNB-CU-UP. Such a split enables the implementation of the CU-CP and CU-UP parts in different locations. For example, such a split of the gNB 100 into the plurality of logical entities enables flexibility, scalability, and efficiency in the deployment and operation of fifth generation (5G) networks. The disaggregated architecture of the gNB 100 may also include a Radio Unit (gNB-RU), not shown in FIG. 1.

[0017] The gNB-RU may be responsible for radio transmission and reception of signals. The gNB- RU may include physical Radio Frequency (RF) components such as antennas, power amplifiers, and analog-to-digital converters. The gNB-RU may be located at a cell site or a radio tower, close to the antennas. Further, the gNB-DU may perform baseband processing functions such as physical layer processing, channel coding, and modulation / demodulation. For example, the gNB-DU may host a Radio Link Control (RLC), a Medium Access Control (MAC) layer, and a Physical (PHY) layer. The gNB-DU may also perform scheduling operations. Multiple gNB-RUs may beconnected to a single gNB-DU, allowing for centralized processing of multiple radio units. Multiple gNB-DUs may be connected to a single gNB-CU. The gNB-CU may be responsible for higher-layer processing functions such as radio resource management, mobility management, and connection management. The gNB-CU may provide a centralized control point for multiple gNB- DUs, enabling network-wide coordination and optimization.

[0018] According to one configuration, the gNB-DU may host multiple cells (for example, a maximum of 512 as per current specifications). The gNB-CU-CP may host Packet Data Convergence Protocol -Control Plane part (PDCP-c) and Radio Resource Control (RRC) layers. The scheduling operation takes place at the gNB-DU. The gNB-CU-CP may host one or more gNB-DUs and one or more gNB-CU-UPs. Also, the gNB-CU-UP may host Packet Data Convergence Protocol-User Plane part (PDCP-U) and Service Data Adaptation Protocols (SDAP). More specifically, 3GPP Radio Access Network (RAN)3 cardinality for a fifth-generation (5G) gNB defines that the gNB 100 may only include one gNB-CU-CP. There may be an “n” number of gNB-DUs controlled by a gNB-CU-CP. Further, there may be ‘m” number of gNB-CU-UP controlled by the gNB-CU-CP in the gNB 100. Also, one gNB-DU may be served by multiple gNB-CU-UPs. The various entities and / or network functions within the gNB 100 may communicate via one or more interfaces. The one or more interfaces include an Fl-C interface, an Fl-U interface, and an El interface. The Fl-C interface is a control plane interface between the gNB-CU and the gNB-DU within the gNB 100. The Fl-C interface is used for signaling and control messages related to radio resource management, mobility management, and configuration management. The Fl-C interface facilitates coordination between the gNB-CU and the gNB-DU for efficient network operation and service delivery. The Fl-U interface is a user plane interfacebetween the gNB-CU and the gNB-DU in the gNB 100 architecture. The Fl-U interface is responsible for transporting user data packets between the gNB-CU and the gNB-DU. The Fl-U interface handles user plane data processing, including packet forwarding, Quality of Service (QoS) management, and encryption / decryption functions. The El interface in the gNB 100 connects the gNB-CU-UP entity with the gNB-CU-CP. Particularly, the gNB-CU-UP may communicate with the gNB-CU-CP over an El-C interface. Further, the gNB-CU-CP may communicate with the gNB -DU over the Fl -C interface.

[0019] FIG. 2 illustrates an enhanced resiliency use case 200 for an O-CU and associated partial O-CU failure, according to an embodiment as disclosed herein. FIG. 2 illustrates a system behavior pertaining to the enhanced resiliency for the O-CU, enabling one or more network operators to utilize a resiliency framework via a Service Management and Orchestration (SMO). The one or more network operators may utilize the resiliency framework to identify one or more partial O- CU failures and corresponding service interruptions (e.g., cell(s) disruptions). The one or more network operators may also utilize the resiliency framework to execute one or more appropriate recovery actions to restore one or more services. The enhanced resiliency may be applicable when an 01 interface between the SMO and the O-CU remains operational, despite the O-CU encountering other issues that lead to service degradation. Thus, the illustrated use cases may be essential for ensuring network resiliency and mitigating service disruptions resulting from failures.

[0020] The enhanced resiliency use case 200 may involve an SMO framework (referred to as the SMO) and one or more 0-RAN Network Functions (NFs). The SMO may serve as a Management Service (MnS) consumer 202, and one or more O-RAN NFs may serve as MnS producers 204, 206. In one embodiment, the MnS producers 204, 206 may correspond to a first O-CU and a secondO-CU, respectively. Examples associated with the enhanced resiliency may include, but are not limited to, a complete NF (e.g., O-Distributed Unit (O-DU), an O-CU-CP, or an O-CU-UP) failure, and an 01 interface failure as one category and the rest of the partial failures as other category.

[0021] This enhanced resiliency use case 200 illustrates the interactions between these entities within the context of enhanced resiliency, as outlined in Table 1.Table 1

[0022] FIG. 3 illustrates an O-CU-CP resiliency scenario 300 in case of 01 failure, according to an embodiment as disclosed herein. The O-CU-CP resiliency scenario 300 outlines an intended system behavior for enhanced resiliency within an O-CU-CP framework. Enhanced resiliency applies in scenarios where the management of the O-CU-CP as an MnS producer loses connectivity to the 01 interface, indicating either a complete network function failure or a Management Plane (01) failure. The O-CU-CP resiliency scenario 300 is essential for enhancing the resilience of the 01 interface through the integration of robust monitoring, failover mechanisms, and redundancy.

[0023] The O-CU-CP resiliency scenario 300 may involve an SMO framework (referred to as the SMO) and one or more O-RAN Network Functions (NFs). The SMO may serve as a Management Service (MnS) consumer 302, and one or more O-RAN NFs may serve as MnS producers 304, 306, and 308. In one embodiment, the MnS producers 304, 306, and 308 may correspond to a first O-CU-CP, a second O-CU-CP, and an 0-DU, respectively.

[0024] The scenario 300 illustrates the activities and interactions of the above-mentioned entities within the framework of enhanced resiliency, as detailed in the accompanying Table 2.Table 2

[0025] FIGS. 4A to 4D illustrate an O-CU-CP resiliency scenario 400 in case of the O-CU-CP failure within 0-RAN networks, according to an embodiment as disclosed herein. The O-CU-CP resiliency scenario 400 may involve various entities. Such entities may include an operator 402, a SMO 404, a first O-CU-CP 406, a second O-CU-CP 408, an 0-DU 410, and an 0-RU 412. The SMO 404 may be similar to the SMO 202 and the SMO 302. The SMO 404 may assign initial roles (active, standby) to O-CU-CPs (for example, the first O-CU-CP 406, and the second O-CU- CP 408) or resiliency pairs based on operator decisions. The SMO 404 may facilitate high-level decision-making during failures and resiliency scenarios, including managing the O-CU-CPs during partial or complete failures, interface disruptions, and planned maintenance. The SMO 404 may enable service recovery by transitioning operations from an active O-CU-CP to a standby O- CU-CP, minimizing service disruption for end users. The O-CU-CPs (i.e., the first O-CU-CP 406 and the second O-CU-CP 408) receive cell-related configurations from the SMO 404 and cellavailability details from the O-DU(s) 410. Based on the resource availability reported by the O- DU 410 and a desired cell availability specified by the SMO 404, the O-CU-CP may manage an activation or a deactivation of cells in the O-DU 410 via the Fl interface. The O-CU-CP may periodically report one or more alarms and one or more Performance Management (PM) counters to the SMO 404 via the 01 interface. The active and standby O-CU-CPs may be essential for resiliency, allowing the SMO 404 to configure the standby O-CU-CP to restore services after failure. This transition may activate the affected cells, and ensure minimal service disruption for users. The O-DU 410 may represent each of the plurality of O-DUs connected to the O-CU-CPs 406, 408. The O-DU(s) 410 are vital for recovery operations during resiliency scenarios. If the 01 interface remains operational, the SMO 404 may analyze 0AM data to identify O-CU-CP failures and reconfigure the O-DUs 410 to migrate services to the standby O-CU-CP, minimizing disruption. The 0-RU 412 may enable the operation of [tr]x-array carriers linked to the cells managed by the O-DU 410 in conjunction with the O-CU-CPs 406, 408. Additionally, the 0-RU 412 may play a crucial role in maintaining the front haul and air interfaces, working in coordination with the O-DU 410 to support the recovery of the cells managed by the O-CU-CPs 406, 408.

[0026] The O-CU-CP resiliency scenario 400 may illustrate a solution for the SMO 404 to manage the O-CU-CP failure and to restore services to the best possible level.

[0027] The resiliency mechanisms may be designed to take over the operation of the cell(s) associated with the connected O-DUs 410, restoring services to end users with minimal disruption.

[0028] The solution illustrated in FIGS. 4A-4D may be based on assumptions that in the event of an active O-CU-CP failure, at least one standby O-CU-CP may be available to ensure service recovery for users.

[0029] The O-CU-CP resiliency scenario 400 may correspond to complete or partial failures of the O-CU-CP, performance degradation, and other critical issues. The primary goal of the O-CU- CP resiliency scenario 400 is to ensure the continued operational integrity of the O-RU 412 and the 0-DU 410, even in the event of an active O-CU-CP failure or disruptions such as interface failures (e.g., Fl, E2, and 01).

[0030] The following preconditions 414 may be applicable for the implementation of the O-CU- CP resiliency scenario 400:• The SMO 404 has configured the first O-CU-CP 406 to take an active role with up and running an 01 interface towards the SMO 404.• A Fl interface between the first O-CU-CP 406 and the 0-DU 410 is established.• The SMO 404 has subscribed to alarms and performance counters from the first O- CU-CP 406.• The SMO 404 has configured the second O-CU-CP 408 to take a standby role with up and running the 01 interface towards the SMO 404 or not configured at all.

[0031] At step 416, the O-CU-CP resiliency scenario / use case may begin based on above preconditions.

[0032] Step 418 may correspond to a detection of a first O-CU-CP failure. The first O-CU-CP failure may either be complete or partial.

[0033] At step 420, the SMO 404 may analyse the alarms and PM counters to detect and identify the failure of the first O-CU-CP 406.

[0034] At step 422, the SMO 404 may decide to switch services from the first O-CU-CP 406 to the second O-CU-CP 408 upon detecting the partial and / or the complete failure in the first O-CU-CP 406. For example, the SMO 404 detects partial first O-CU-CP failure based on the alarms and / or PM counters that may be received through the 01 interface from the first O-CU-CP 406. In one embodiment, the SMO 404 may compare the alarms and / or the PM counters with corresponding threshold values to identify the partial and / or complete failure in the first O-CU-CP 406.

[0035] At step 424, the SMO 404 may perform a continuous loop based procedure to remove one or more cells associated with each O-DU associated with the affected first O-CU-CP 406. Within said loop based procedure, at step 426, the SMO 404 may initiate another continuous loop based procedure for each cell to remove and / or deactivate a carrier. For example, at step 428, the SMO 404 may deactivate a cell. The SMO 404 may send a command through the 01 interface to deactivate the cell. The SMO 404 may also optionally remove the deactivated cell. The SMO 404 may also request the O-DU 410 to remove the corresponding resources associated with the deactivated cell. In response, at step 430, the cell deactivation and removal may be performed between the first O-CU-CP 406 and the O-DU 410. In one embodiment, the cell deactivation removal may occur between the first O-CU-CP 406 and the O-DU 410 via the Fl interface.

[0036] At step 432, the O-DU 410 may deactivate the [tr]x-array-carrier(s) associated with the cell(s) managed by the first O-CU-CP 406. The process for deactivating the [tr]x-array-carrier(s) is incorporated herein by reference from Figure 15.3.2-0b of 0-RAN.WG4.MP specification. The O-DU 410 may receive notifications regarding an outcome of the deactivation operation of the [tr]x-array-carrier(s).

[0037] At step 434, for the cell(s) configurations, the 0-DU 410 may send a result notification to the SMO 404 via the 01 interface. The result notification may indicate whether the request(s) were successfully fulfilled, partially fulfilled, or failed.

[0038] Furthermore, the steps 428 to 434 may be applicable if the first O-CU-CP 406 has a partial failure or performance degradation at the same time. However, the first O-CU-CP 406 is still accessible or configurable through the 01 interface. Alternatively, if the first O-CU-CP 406 is completely failed then the SMO 404 may configure each of the O-DUs 410 that are connected to the first O-CU-CP 406 to terminate or remove the Fl interface. This means that the Fl interface between the first O-CU-CP 404 and associated O-DUs 410 may be terminated, and the associated cell(s) may be removed as specified in 3GPP TS 38.472 and 38.473 on Fl AP specifications.

[0039] Step 436 may correspond to continuous loop based procedure for cell creation and activation for each 0-DU intended to cooperate with the second O-CU-CP 408. Furthermore, step 438 may correspond to a continuous loop based procedure for each cell that require creation and activation of the particular 0-DU 410.

[0040] At step 440, the SMO 404 may configure the 0-DU 410 to connect with the second O-CU- CP 408. The SMO 404 may provide a Transport Network Layer (TNL) configuration associated with the second O-CU-CP 408 to the 0-DU 410. For example, the SMO 404 may provide necessary details such as transport parameters, connection requirements, and configurations for performance management. In one embodiment, the 0-DU 410 may inform the results of the above operations to the SMO 404 through the 01 interface. Further, at step 442, an enabler for Fl establishment may occur between the 0-DU 410 and the second O-CU-CP 408.

[0041] At step 444, the SMO 404 may configure the second O-CU-CP 408 to get the second O- CU-CP 408 into the service path. The SMO 404 may create and configure the cell(s) to the second O-CU-CP 408 through the 01 interface. The second O-CU-CP 408 may be provided with the necessary configuration including transport details, cell(s) configuration, configuration needed to connect with the 0-DU 410, configuration for performance management, and so on. In one embodiment, the second O-CU-CP 408 may inform the results of the step 444 to the SMO 404 through the 01 interface. The SMO 404 may create cell(s) objects, if needed.

[0042] At step 446, the SMO 404 may manage the setup of cell(s) and corresponding carrier(s) resources in the 0-DU 410, which are associated with the respective cell(s) managed by the second O-CU-CP 408. The 0-DU 410 may inform the results of the step 446 to the SMO 404 through the 01 interface.

[0043] Further, at step 448, there may be Fl messaging between the second O-CU-CP 408 and the 0-DU 410 if the Fl is established.

[0044] At step 450, the 0-DU 410 may configure and activate the [tr]x-array-carrier(s) on the O- RU 412 in accordance with the activation sequence incorporated herein by reference from Figure 15.3.2-0a of the 0-RAN.WG4.MP.

[0045] At step 452, the SMO 404 may send an activation request for the cell(s) configured successfully in Steps 444 and 446 to the second O-CU-CP 408. In one embodiment, the second O- CU-CP 408 may confirm the reception of the activation request from the SMO 404 through the 01 interface. Further, at step 454, the Fl messaging occurs between the second O-CU-CP 408 and the 0-DU 410. The Fl messaging may occur if the Fl interface is established, for the cell reported by the O-DU 410 to O-CU in step 442.

[0046] At step 456, for the cell(s) activation request in step 444, the second O-CU-CP 408 may notify the SMO 404 of the activation status of the cell(s) via the 01 interface. In one embodiment, the standby O-CU-CP i.e., the second O-CU-CP 408 may notify that the second O-CU-CP 408 is ready to offer services. Further, there may be a communication between the second O-CU-CP 408 and the 0-RU 412 that the cell(s) associated with the second O-CU-CP 408 and corresponding carrier(s) are fully operational and ready to deliver services, as illustrated by step 458.

[0047] At step 460, the SMO 404 may subscribe and collect the alarms and the performance counters from the second O-CU-CP 408 via the 01 interface.

[0048] The steps 440 to 450 may be performed for each cell and each 0-DU 410, and the process may wait till all the steps 440 to 454 are successfully completed.

[0049] The O-CU-CP resiliency scenario 400 may end when the standby O-CU-CP, i.e., the second O-CU-CP 408 shown in the flow diagram may take over for the previously active O-CU- CP, i.e., the first O-CU-CP 406.

[0050] On a successful post-condition, the 0-DU 410 may be connected to the newly active O- CU-CP, i.e., the second O-CU-CP 408. The second O-CU-CP 408 may be operational and properly connected and synchronised with the 0-DU 410.

[0051] FIG. 5 illustrates a flow chart of an example method 500, according to an embodiment as disclosed herein. The method 500 may be performed by the SMO 404.

[0052] At step 501, the SMO 404 may subscribe to receive data associated with the first O-CU- CP 406.

[0053] At step 502, the SMO 404 may be configured to receive the data associated with the firstO-CU-CP 406. The data may include at least one of the one or more alarms and the one or moreperformance counters. The SMO 404 may be configured to receive the data from the first O-CU- CP 406. In an embodiment, the SMO 404 may be configured to receive the at least one of the one or more alarms and the one or more performance counters via the 01 interface. In an example, the one or more alarms and the one or more performance counters may correspond to alarms and performance counters as defined in WG10 01 alarms specification, and WG4 Management Plane (MP) specifications. The data may also include PM counters which may be defined in at least one of WG10 01 PMeas, WG4 MP specification, WG3 E2 Service Model (SM) specification, and WG4 Control, User, and Synchronization (CUS) Plane specification. Further, the one or more alarms and the one or more performance counters may be uniquely used for both complete or partial failure of the node (for example, the first O-CU-CP 406), the interface (for example, the 01 interface), and other parts of the network.

[0054] The one or more alarms may also include O-DU / O-CU-CP specific alarms which may be based on 3GPP TS 28.111. Furthermore, the one or more alarms may include 0-RU specific alarms that are defined in WG4 MP specification (Clause 11 and Annex A). Moreover, the one or more alarms may include 01 alarms. Definitions and attributes of an 01 alarm list are defined in clauses of 7.3.2.1 and 7.3.2.2, and a format of the 01 alarm records is specified in clause 6.5 of 3GPP TS 28.111. In one or more embodiments, the one or more alarms may also include 0-RU alarms that may be mapped with a probable cause of an alarm defined in 3GPP TS 28.111. The SMO 404 may use the one or more performance counters and Key Performance Indicators (KPIs) defined in WG10 01 Performance measurement specification, 3GPP TS 28.552, 3GPP TS 28.554, and WG4MP (Clause 10 and Annex B).

[0055] Further, prior to receipt of the data, the SMO 404 may be configured to perform a plurality of operations which is discussed in the subsequent paragraphs. The SMO 404 may be configured to configure the first O-CU-CP 406 as an active O-CU-CP and at least one second O-CU-CP (for example, the second O-CU-CP 408) as a standby O-CU-CP. In one embodiment, the at least one second O-CU-CP 408 may be created and deployed based on the detection of the failure of the first O-CU-CP 406. The at least one second O-CU-CP 408 may be configured to maintain the 01 interface with the SMO 404. Further, the SMO 404 may be configured to subscribe to receive the at least one of the one or more alarms and the one or more performance counters from the first O- CU-CP 406.

[0056] At step 504, the SMO 404 may be configured to analyze the data received from the first O- CU-CP 406.

[0057] At step 506, the SMO 404 may be configured to detect a failure of the first O-CU-CP 406 based on the analysis of the data associated with the first O-CU-CP 406.

[0058] In an example, the SMO 404 may be configured to detect the failures and manage the resiliency by either recovering the failed (partial / complete) NFs / nodes, interfaces, transport links, network elements, cloud, and so on. The SMO 404 may be configured to decide based on one or more of the received data, an operator’s policy, and the capability of the services provided by the SMO 404. The decision may depend on a topology as defined in WG10 TE&IV specification, a deployment (hierarchical / hybrid) as defined WG100AM Architecture specification and WG4 M- Plane specification (Clause 5), capabilities of the nodes (Network Functions(NFs) / Network Elements (Nes)), and interface capabilities. In case of a hierarchical deployment, the SMO 404 may communicate with the O-RU 412 through the O-DU 410. Further, in case of a hybriddeployment, the SMO 404 may directly communicate with the O-RU 412 through the Fronthaul (FH) M-Plane interface. Thus, if one O-DU fail, then the SMO 404 may configure a "configured client info" container so that the O-RU 412 may establish a call home to another O-DU. Here, the SMO 404 may deliver the transport details of back-up / standby O-DU(s) directly using the FH M- Plane interface.

[0059] Further, if the partial or complete failure is detected by the SMO 404, the SMO 404 may operate further based on the following conditions:• If the O-DU or the O-CU (O-CU-CP / O-CU-UP) completely failed, then the SMO 404 may lose the 01 interface connection. Further, the 01 interface failure may be detected using heartbeat mechanism defined in Clause 6.6 of WG1001 interface specification. The complete failure may be classified as complete network function failure (still Operations, Administration, and Maintenance (0AM) running with the 01 interface running), both the 0AM and network function failure (lead to 01 interface failure), transport link failure, etc. Whenever the 0AM is failed, the 01 interface failure is detected. When the NF is failed, then the Fl interface connection failure is detected. When the Network Element (NE) (NF + 0AM) is failed, the complete failure along with interface failure is detected by the SMO 404.• The partial failures may be one of software failure, configuration failure, missing configuration, one of the card failures, service impacting and non-service impacting failures, etc. For example, service impacting failure may be detected when all configurations are performed correctly, and only carrier configurations are failed. The other failure may include missing files and configuration during software upgrade. Further, other issues may be software mismatch, interference, etc.• The SMO 404 may consider the interface failure in case of the complete failure. For example, during an O-DU complete failure, the SMO 404 may communicate with the O-CU-CP through the 01 interface and confirm if the O-DU 410 failed or the 01 interface failed. Since the O- DU 410 complete failure results in both 01 and Fl interface failures. In this case, the SMO 404 may confirm with the O-CU-CP 406 via the 01 interface that the O-CU-CP 406 is unable to communicate with the O-DU 410 through the Fl interface. Further, the SMO 404 may be unable to communicate with the O-DU 410 via the 01 interface. Thus, this configuration assists the SMO 404 in detecting the O-DU complete failure.• In case of partial failure, the interface connection from failed NF / nodes may be available, hence, the SMO 404 may easily detect and recover the failure. For example, software reset / upgrade as defined in WG4 MP specification (O-RU) and WG10 01 interface specification (for NFs like O-DU, O-CU-CP, and O-CU-UP)).

[0060] At step 508, the SMO 404 may be configured to determine to switch services from the first O-CU-CP 406 to the at least one second O-CU-CP 408 in response to the detection of the failure.

[0061] At step 510, the SMO 404 may be configured to transmit a request to deactivate one or more corresponding cells of each O-DU 410. The SMO 404 may transmit the request to each O- DU 410 associated with the first O-CU-CP 406.

[0062] At step 512, the SMO 404 may be configured to receive a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed. The SMO 404 may be configured to receive the result notification from each O-DU 410.

[0063] The inclusion of failover strategies ensures that if one component fails, another can take over seamlessly. This redundancy is crucial for maintaining service levels and preventing totaloutages, which can severely affect users. In an example, the failure may be a partial failure, a complete failure, or one of one or more interface failures.

[0064] In an embodiment, in response to determining to switch services from the first O-CU-CP 406 to the at least one second O-CU-CP 408 and prior to receipt of the result notification, the SMO 404 may be configured to send a request to remove the one or more corresponding cells. The SMO 404 may be configured to send the request to each 0-DU 410. Further, the received result notification may indicate one of a successful removal or failed removal of the one or more corresponding cells.

[0065] At step 514, the SMO 404 may be configured to configure, each O-DU 410, to connect with the at least one second O-CU-CP 408 based on the result notification. In an embodiment, for configuring each O-DU 410 to connect to the at least one second O-CU-CP 408, the SMO 404 may be configured to transmit at least one of one or more transport parameters, one or more connection requirements, and one or more configurations, to each O-DU 410. Herein, the at least one of one or more transport parameters, one or more connection requirements, and one or more configurations may be associated with the at least one second O-CU-CP 408.

[0066] Further, in response to configuring each O-DU 410, the SMO 404 may be configured to receive a response to the configuration from each O-DU 410.

[0067] In an embodiment, in response to receipt of the response to the configuration, the SMO 404 may be configured to configure one or more cells to the at least one second O-CU-CP 408. To configure the one or more cells, the SMO 404 may be configured to perform a plurality of operations as discussed in the subsequent paragraphs. In one embodiment, the SMO 404 may configure the one or more cells and associated carriers in each of the O-DUs 410. Furthermore,once each of the O-DUs 410 is configured with the cell(s) and associated carriers resources, each of the O-DUs 410 may handshake with the at least one second O-CU-CP 408 for the cell(s) activation using Fl AP procedures defined in 3GPP TS 38.473. The SMO 404 may be configured to transmit at least one of the one or more transport parameters, one or more connection requirements, and one or more configurations to the at least one second O-CU-CP 408. The SMO 404 may be configured to create one or more cell objects / instances associated with each of the one or more cells to be configured. The SMO 404 may be configured to maintain a set of the one or more cells based on the corresponding one or more cell objects / instances.

[0068] Further, the SMO 404 may be configured to receive a result of configuration of the one or more cells. The SMO 404 may be configured to receive the result of configuration from the at least one second O-CU-CP 408. In response to the result of configuration of the one or more cells, the SMO 404 may be configured to subscribe to receive the at least one of the one or more alarms and the one or more performance counters from the at least one second O-CU-CP 408.

[0069] FIG. 6 illustrates a diagram of example components of the apparatus 600, according to an embodiment as disclosed herein. As shown in FIG. 6, the apparatus 600 comprises a processor 610, a memory 620, a storage component 630, an input component 640, an output component 650, a communication interface 660, and a bus 670. In one embodiment, the apparatus 600 may relate to any network device, as shown in previous FIGS. 2 to 5. For example, the apparatus 600 may correspond to one of the SMO 202, the first O-CU 204, the second O-CU 206, the SMO 302, the first O-CU-CP 304, the second O-CU-CP 306, the O-DU 308, the SMO 404, the first O-CU-CP406, the second O-CU-CP 408, the O-DU 410, and the O-RU 412.

[0070] The processor 610, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 610 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 610 may be a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), an Accelerated Processing Unit (APU), an Application-Specific Integrated Circuit (ASIC), or another type of processing component.

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

[0072] The storage component 630 stores information and / or software related to the operation and use of the apparatus 600. For example, the storage component 630 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a Compact Disc (CD), a Digital Versatile Disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

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

[0074] The output component 650 is configured to provide output information from the apparatus 600. For example, the output component 650 may be, but is not limited to, a display, a speaker, instructions to an external device, and / or one or more Light-Emitting Diodes (LEDs).

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

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

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

[0078] Examples of the techniques and apparatus described herein include, but are not limited to, the following enumerated embodiments:[1] An apparatus configured to: analyze data, received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP), associated with the first O-CU-CP; detect a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP; determine to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure; transmit, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of the each O-DU; receive, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed; and configure, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.[2] The apparatus as described in [1], wherein prior to analyzing the data associated with the first O-CU-CP, the apparatus is configured to: receive, from the first O-CU-CP, the data comprising at least one of one or more alarms and one or more performance counters.[3] The apparatus as described in any one of [1] to [2], wherein prior to receipt of the data, the apparatus:configures the first O-CU-CP as an active O-CU-CP and the at least one second O-CU-CP as a standby O-CU-CP, wherein the at least one second O-CU-CP is created and deployed based on detection of the failure of the first O-CU-CP, and wherein the at least one second O-CU-CP is configured to maintain an 01 interface with the apparatus.[4] The apparatus as described in any one of [1] to [3], wherein prior to receipt of the at least one of the one or more alarms and the one or more performance counters, the apparatus is configured to: subscribe to receive the at least one of the one or more alarms and the one or more performance counters from the first O-CU-CP.[5] The apparatus as described in any one of

[0001] to [4], wherein in response to determining to switch services from the first O-CU-CP to the at least one second O-CU-CP and prior to receipt of the result notification, the apparatus is configured to: send, to each 0-DU, a request to remove the one or more corresponding cells; wherein the received result notification indicates one of a successful removal or a failed removal of the one or more corresponding cells.[6] The apparatus as described in any one of [1] to [5], wherein to receive the at least one of the one or more alarms and the one or more performance counters, the apparatus is configured to: receive, from the first O-CU-CP, the at least one of the one or more alarms and the one or more performance counters via an 01 interface.[7] The apparatus as described in any one of [1] to [6], wherein to configure each 0-DU to connect to the at least one second O-CU-CP, the apparatus is configured to:transmit, to each O-DU, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations associated with the at least one second O-CU-CP.[8] The apparatus as described in any one of [1] to [7], wherein in response to configure, each O-DU, to connect with the at least one second O-CU-CP, the apparatus is configured to: receive, from each O-DU, a response to the configuration; configure one or more cells to the at least one second O-CU-CP; receive, from the at least one second O-CU-CP, a result of configuration of the one or more cells; and subscribe to receive at least one of one or more alarms and one or more performance counters from the at least one second O-CU-CP.[9] The apparatus as described in any one of [1] to [8], wherein to configure the one or more cells, the apparatus is configured to: transmit, to the at least one second O-CU-CP, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations.

[0010] The apparatus as described in any one of [1] to [9], wherein to configure the one or more cells, the apparatus is configured to: create one or more cell objects associated with each of the one or more cells to be configured; and maintain a set of the one or more cells based on the corresponding one or more cell objects.

[0011] A method comprising:analyzing data, received from a first Open Radio Access Network (ORAN)-CentralizedUnit Control Plane (O-CU-CP), associated with the first O-CU-CP; detecting a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP; determining to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure; transmitting, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of the each O-DU; receiving, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed; and configuring, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.

[0012] The method as described in

[0011] , wherein prior to analyzing the data associated with the first O-CU-CP, the apparatus is configured to: receiving, from the first O-CU-CP, the data comprising at least one of one or more alarms and one or more performance counters.

[0013] The method as described in any one of

[0011] to

[0012] , wherein prior to receipt of the data, the method comprises: configuring the first O-CU-CP as an active O-CU-CP and the at least one second O-CU- CP as a standby O-CU-CP, wherein the at least one second O-CU-CP is created and deployed based on detection of the failure of the first O-CU-CP, and wherein the at least one second O-CU- CP is configured to maintain an 01 interface with a Service Management and Orchestration (SMO).

[0014] The method as described in any one of

[0011] to

[0013] , wherein prior to receipt of the at least one of the one or more alarms and the one or more performance counters, the method comprises: subscribing to receive the at least one of the one or more alarms and the one or more performance counters from the first O-CU-CP.

[0015] The method as described in any one of

[0011] to

[0014] , wherein in response to determining to switch services from the first O-CU-CP to the at least one second O-CU-CP and prior to receipt of the result notification, the method comprises: sending, to each O-DU, a request to remove the one or more corresponding cells; wherein the received result notification indicates one of a successful removal or a failed removal of the one or more corresponding cells.

[0016] The method as described in any one of

[0011] to

[0015] , wherein receiving the at least one of the one or more alarms and the one or more performance counters comprises: receiving, from the first O-CU-CP, the at least one of the one or more alarms and the one or more performance counters via an 01 interface.

[0017] The method as described in any one of

[0011] to

[0016] , wherein configuring each 0-DU to connect to the at least one second O-CU-CP comprises: transmitting, to each 0-DU, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations associated with the at least one second O-CU-CP.

[0018] The method as described in any one of

[0011] to

[0017] , wherein in response to configuring, each 0-DU, to connect with the at least one second O-CU-CP, the method comprises: receiving, from each 0-DU, a response to the configuration.configuring one or more cells to the at least one second O-CU-CP; receiving, from the at least one second O-CU-CP, a result of configuration of the one or more cells; and subscribing to receive at least one of one or more alarms and one or more performance counters from at least one second O-CU-CP.

[0019] The method as described in any one of

[0011] to

[0018] , wherein configuring the one or more cells comprises: transmitting, to the at least one second O-CU-CP, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations.

[0020] The method as described in any one of

[0011] to

[0019] , wherein configuring the one or more cells comprises: creating one or more cell objects associated with each of the one or more cells to be configured; and maintaining a set of the one or more cells based on the corresponding one or more cell objects.

[0021] A non-transitory computer-readable medium storing instructions that when executed by one or more processors, cause the one or more processors to: analyze data, received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP), associated with the first O-CU-CP; detect a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP;determine to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure; transmit, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of the each O-DU; receive, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed; and configure, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.

[0079] The present disclosure i.e., the disclosed method 500 and the apparatus 600 have several advantages over the existing mechanism, for example, which are stated below: a. Enhanced network resiliency: By implementing enhanced resiliency measures, the network may withstand various types of failures without a significant impact on service quality. This ensures that communication remains stable, fostering user trust and satisfaction. b. Service restoration: The present disclosure enables rapid identification and execution of recovery actions, which means that services may be restored quickly after a disruption. This minimizes downtime and maintains the continuity of critical operations for users. c. Operational continuity: The 01 interface’s operational status during failures ensures that essential management functions may continue, even if other components experience issues. This continuity is vital for maintaining overall network performance and reliability.d. Proactive monitoring: The integration of robust monitoring tools may enable realtime detection of anomalies and potential failures. This proactive approach may allow network operators to address issues before they escalate into major disruptions, enhancing overall network health. e. Robust Failover mechanisms: The inclusion of failover strategies ensures that if one component fails, another may take over seamlessly. This redundancy is crucial for maintaining service levels and preventing total outages, which may severely affect users. f. Improved operator efficiency: The streamlined processes for identifying and addressing failures allow operators to manage the network more effectively. This efficiency may reduce the workload on technical staff and enables them to focus on strategic initiatives rather than reactive problem-solving. g. Mitigation of service disruptions: With a focus on resiliency, the present disclosure may significantly reduce the likelihood and impact of service interruptions. This proactive stance not only improves user experience but also strengthens the network’s reputation for reliability and responsiveness.

[0080] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements can be at least one of a hardware device or a combination of hardware devices and software modules.

[0081] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, variousworking modifications may be made to the method in order to implement the inventive concept as taught herein.

[0082] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

[0083] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[0084] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

[0085] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from thegeneric concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

We Claim:

1. An apparatus configured to: analyze data, received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP), associated with the first O-CU-CP; detect a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP; determine to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure; transmit, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of the each O-DU; receive, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed; and configure, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.

2. The apparatus as claimed in claim 1, wherein prior to analyzing the data associated with the first O-CU-CP, the apparatus is configured to: receive, from the first O-CU-CP, the data comprising at least one of one or more alarms and one or more performance counters.

3. The apparatus as claimed in claim 1, wherein the apparatus:configures the first O-CU-CP as an active O-CU-CP and the at least one second O-CU-CP as a standby O-CU-CP, wherein the at least one second O-CU-CP is created and deployed based on detection of the failure of the first O-CU-CP, and wherein the at least one second O-CU-CP is configured to maintain an 01 interface with the apparatus.

4. The apparatus as claimed in claim 2, wherein prior to receipt of the at least one of the one or more alarms and the one or more performance counters, the apparatus is configured to: subscribe to receive the at least one of the one or more alarms and the one or more performance counters from the first O-CU-CP.

5. The apparatus as claimed in claim 1, wherein in response to determining to switch services from the first O-CU-CP to the at least one second O-CU-CP and prior to receipt of the result notification, the apparatus is configured to: send, to each 0-DU, a request to remove the one or more corresponding cells; wherein the received result notification indicates one of a successful removal or a failed removal of the one or more corresponding cells.

6. The apparatus as claimed in claim 2, wherein to receive the at least one of the one or more alarms and the one or more performance counters, the apparatus is configured to: receive, from the first O-CU-CP, the at least one of the one or more alarms and the one or more performance counters via an 01 interface.

7. The apparatus as claimed in claim 1, wherein to configure each O-DU to connect to the at least one second O-CU-CP, the apparatus is configured to: transmit, to each O-DU, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations associated with the at least one second O-CU-CP.

8. The apparatus as claimed in claim 1, wherein in response to configuring, each O-DU, to connect with the at least one second O-CU-CP, the apparatus is configured to: receive, from each O-DU, a response to the configuration; configure one or more cells to the at least one second O-CU-CP; receive, from the at least one second O-CU-CP, a result of configuration of the one or more cells; and subscribe to receive at least one of one or more alarms and one or more performance counters from the at least one second O-CU-CP.

9. The apparatus as claimed in claim 8, wherein to configure the one or more cells, the apparatus is configured to: transmit, to the at least one second O-CU-CP, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations.

10. The apparatus as claimed in claim 8, wherein to configure the one or more cells, the apparatus is configured to:create one or more cell objects associated with each of the one or more cells to be configured; and maintain a set of the one or more cells based on the corresponding one or more cell objects.

11. A method comprising: analyzing data, received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP), associated with the first O-CU-CP; detecting a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP; determining to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure; transmitting, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of the each O-DU; receiving, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed; and configuring, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.

12. The method as claimed in claim 11, wherein prior to analyzing the data associated with the first O-CU-CP, the apparatus is configured to: receiving, from the first O-CU-CP, the data comprising at least one of one or more alarms and one or more performance counters.

13. The method as claimed in claim 11, wherein the method comprises: configuring the first O-CU-CP as an active O-CU-CP and the at least one second O-CU- CP as a standby O-CU-CP, wherein the at least one second O-CU-CP is created and deployed based on detection of the failure of the first O-CU-CP, and wherein the at least one second O-CU- CP is configured to maintain an 01 interface with a Service Management and Orchestration (SMO).

14. The method as claimed in claim 12, wherein prior to receipt of the at least one of the one or more alarms and the one or more performance counters, the method comprises: subscribing to receive the at least one of the one or more alarms and the one or more performance counters from the first O-CU-CP.

15. The method as claimed in claim 11, wherein in response to determining to switch services from the first O-CU-CP to the at least one second O-CU-CP and prior to receipt of the result notification, the method comprises: sending, to each 0-DU, a request to remove the one or more corresponding cells; wherein the received result notification indicates one of a successful removal or a failed removal of the one or more corresponding cells.

16. The method as claimed in claim 12, wherein receiving the at least one of the one or more alarms and the one or more performance counters comprises:receiving, from the first O-CU-CP, the at least one of the one or more alarms and the one or more performance counters via an 01 interface.

17. The method as claimed in claim 11, wherein configuring each 0-DU to connect to the at least one second O-CU-CP comprises: transmitting, to each 0-DU, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations associated with the at least one second O-CU-CP.

18. The method as claimed in claim 11 , wherein in response to configuring, each 0-DU, to connect with the at least one second O-CU-CP, the method comprises: receiving, from each 0-DU, a response to the configuration. configuring one or more cells to the at least one second O-CU-CP; receiving, from the at least one second O-CU-CP, a result of configuration of the one or more cells; and subscribing to receive at least one of one or more alarms and one or more performance counters from at least one second O-CU-CP.

19. The method as claimed in claim 18, wherein configuring the one or more cells comprises: transmitting, to the at least one second O-CU-CP, at least one of one or more transport parameters, one or more connection requirements, and one or more configurations.

20. The method as claimed in claim 18, wherein configuring the one or more cells comprises: creating one or more cell objects associated with each of the one or more cells to be configured; and maintaining a set of the one or more cells based on the corresponding one or more cell objects.

21. A non-transitory computer-readable medium storing instructions that when executed by one or more processors, cause the one or more processors to: analyze data, received from a first Open Radio Access Network (ORAN)-Centralized Unit Control Plane (O-CU-CP), associated with the first O-CU-CP; detect a failure of the first O-CU-CP based on the analysis of the data associated with the first O-CU-CP; determine to switch services from the first O-CU-CP to at least one second O-CU-CP in response to detection of the failure; transmit, to each O-Distributed Unit (O-DU) associated with the first O-CU-CP, a request to deactivate one or more corresponding cells of the each O-DU; receive, from each O-DU, a result notification indicating whether the request to deactivate is one of fully completed, partially completed, or has failed; and configure, each O-DU, to connect with the at least one second O-CU-CP based on the result notification.

Images