The present disclosure relates to a wireless communication system, and more specifically relates to managing a plurality of network nodes during a radio access network (RAN) failure event.
BACKGROUND
[0002] A failure/disaster of a radio access network (RAN) element or an evolved node B (eNB) element may include, for example, a Base band Unit (BBU) software crashes, physical connectivity failure or power failure. According to existing mechanisms, a recovery of the RAN element and/or recovery from data interruption from such failure/disaster in the RAN/eNB element(s) is performed by using information of user equipment/identity (UE) stored at mobility management entity (MME) of a core network. Some of the prior art references are given below:
[0003] WO2016206366A1 relates to the field of communication technologies, such as communication state recovery involving SGW failures.
[0004] US20110235505A1 relates generally to mobile broadband networking technologies, such as the Evolved 3GPP Packet Switched Domain that provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN).
[0005] In a non-patent literature entitled "Disaster Recovery Overview", a Junos Space cluster allows to maintain high availability and scalability in network management solution. However, because all nodes in a cluster need to be within the same subnet, they are typically deployed in the same data centre or within the same campus. But we can easily recover a cluster from a disaster at a location by mirroring the original Junos Space installation on a cluster to another cluster at a geographically different location. So, if the main Junos Space site fails due to a disaster such as an earthquake, the other site can take over. Hence, the physical installation of the disaster recovery setup is typically a set of two geographically separate clusters: the active or main site (that is, the local site) and the standby or backup site (that is, the remote site).

[0006] In another non-patent literature entitled "SurvSec Security Architecture for Reliable Surveillance WSN Recovery from Base Station Failure", the problem of reliable recovery from a BS failure is addressed by proposing a new security architecture called Surveillance Security (SurvSec). SurvSec continuously monitors the network for security threats and stores data related to node security, detects, and authenticates the new BS, and recovers the stored data at the new BS. SurvSec includes encryption for security-related information using an efficient dynamic secret sharing algorithm, where previous work has high computations for dynamic secret sharing. SurvSec includes compromised nodes detection protocol against collaborative work of attackers working at the same time where previous works have been inefficient against collaborative work of attackers working at the same time.
[0007] According to aforementioned prior arts and/or existing mechanism(s), the failure management and disaster recovery during failure event of the eNB, MME and UE are based the UE information stored in the MME. However, this solution is not optimum/efficient, since the recovered UE information from the affected MME is not accurate and/or recovery is time-consuming. In light of the above-stated discussion, there is a need to overcome the above stated disadvantages.
OBJECT OF THE DISCLOSURE
[0008] A principal object of the present disclosure is to provide a failure recovery management system and method for radio access networks.
[0009] Another object of the present disclosure is to provide a method for disaster recovery of a 5G Access Network Function (NF) by implementing a stateless running database for storing UE (user equipment) context and performing parallel computing of standby node authentication and replacement of failed instance with standby node.
[0010] Another object of the present disclosure is to provide dedicated stateless and stateful databases for maintaining the NF, the UE context and state oftheNF.

[0011] Yet another object of the present disclosure is to provide a method for zero down time recovery of 5G Access network function, using an additional run-time database for storing the UE context and a standby network node.
SUMMARY
[0012] Accordingly, the present disclosure provides a method for managing a plurality of network nodes during a radio access network (RAN) failure. The method includes maintaining a first contextual information and second contextual information of at least one user equipment (UE) and said plurality of network nodes. The first contextual information indicates active configurations of said at least one UE and at least one first network node. Further, the method includes detecting a failure event of said at least one first network node. Furthermore, the method includes identifying said second contextual information of said at least one UE and said at least one first network node corresponding to said at least one failed first network node and replacing said at least one failed first network node with at least one second network node using said second contextual information. The second contextual information indicates failure configurations of said at least one UE and said at least one failed first network node.
[0013] The first contextual information and second contextual information are maintained in a run-time database configured for real-time processing of said plurality of network nodes.
[0014] The at least one first network node is an active network element and said at least one second network node is a standby network node.
[0015] The method further includes validating said failure of said at least one first network node, transmitting said second contextual information to said at least one second network node and dynamically changing a state of said standby network node to said active network node state.
[0016] The first contextual information and second contextual information are associated with ingress handler, wherein said ingress handler comprises internet protocol (IP) addresses of said plurality of network nodes and wherein

said ingress handler comprises a virtual IP address of a cluster comprising of a physical and logical resources of computing, storing, and networking of said first contextual information and second contextual information.
[0017] Accordingly, the present disclosure provides failure recovery management system for managing a plurality of network nodes during a radio access network (RAN) failure. The system comprises a connector configured to transmit and receive data between said plurality of network nodes, a run-time database configured to maintain a first contextual information of at least one user equipment (UE) and at least one first network node from said plurality of network nodes, wherein said first contextual information indicates active configurations of said at least one UE and said at least one first network node, and a failure recovery management unit connected to said connector and said run-time database. The failure recovery management unit is configured to detect a failure of said at least one first network node, identify a second contextual information of said at least one UE and said at least one first network node corresponding to said detected failure of said at least one first network node, wherein said second contextual information indicates failure configurations of said at least one UE and said at least one first network node, and replace said at least one failed first network node with at least one second network node using said second contextual information.
[0018] These and other aspects herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the invention herein without departing from the spirit thereof.
BRIEF DESCRIPTION OF FIGURES
[0019] The invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the drawings. The invention herein will be better understood from the following description with reference to the drawings, in which:

[0020] FIG. 1 illustrates an O-RAN system (or O-RAN), according to present disclosure.
[0021] FIG. 2 illustrates a failure recovery management system, according to present disclosure.
[0022] FIG. 3 is a sequence diagram illustrating a communication between failure recovery management unit and network nodes, according to present disclosure.
[0023] FIG. 4 is a flowchart illustrating a method for failure recovery management of a plurality of network nodes, according to present disclosure.
DETAILED DESCRIPTION
[0024] In the following detailed description of the invention, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be obvious to a person skilled in the art that the invention may be practiced with or without these specific details. In other instances, well known methods, procedures and components have not been described in details so as not to unnecessarily obscure aspects of the invention.
[0025] Furthermore, it will be clear that the invention is not limited to these alternatives only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art, without parting from the scope of the invention.
[0026] The accompanying drawings are used to help easily understand various technical features and it should be understood that the alternatives presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.
[0027] Standard networking terms and abbreviation:

[0028] Networking Device: (acting as client device) Network devices, or networking hardware, are physical devices that are required for communication and interaction between hardware on a computer network.
[0029] 5G Access network functions (NFs): (CU, DU, CU-UP, CU-CP).
[0030] UE context: User Entity information maintained when UE in active state.
[0031] Ingress handler: An Ingress may be configured to give Services externally reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure an edge router or additional frontends to help handle the traffic. Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type = NodePort or Service.Type = LoadBalancer.
[0032] gNB: New Radio (NR) Base stations which have capability to interface with 5G Core named as NG-CN over NG-C/U (NG2/NG3) interface as well as 4G Core known as Evolved Packet Core (EPC) over Sl-C/U interface.
[0033] LTE eNB: An LTE eNB is evolved eNodeB that can support connectivity to EPC as well as NG-CN.
[0034] Non-standalone NR: It is a 5G Network deployment configuration, where a gNB needs an LTE eNodeB as an anchor for control plane connectivity to 4G EPC or LTE eNB as anchor for control plane connectivity to NG-CN.
[0035] Standalone NR: It is a 5G Network deployment configuration where gNB does not need any assistance for connectivity to core Network, it can connect by its own to NG-CN over NG2 and NG3 interfaces.
[0036] Non-standalone E-UTRA: It is a 5G Network deployment configuration where the LTE eNB requires a gNB as anchor for control plane connectivity to NG-CN.
[0037] Standalone E-UTRA: It is a typical 4G network deployment where a 4G LTE eNB connects to EPC.

[0038] Xn Interface: It is a logical interface which interconnects the New RAN nodes i.e., it interconnects gNB to gNB and LTE eNB to gNB and vice versa.
[0039] Referring now to the drawings, and more particularly to FIGS. 1 through 4.
[0040] FIG. 1 illustrates an O-RAN system (or O-RAN) 100 according to present disclosure.
[0041] A radio access network (RAN) is a part of a telecommunications system which connects individual devices to other parts of a network through radio connections. The RAN provides a connection of user equipment (UE) such as mobile phone or computer with a core network of the telecommunication systems. The RAN is an essential part of access layer in the telecommunication systems which utilizes base stations (such as e node B , g node B) for establishing radio connections. The O-RAN (Open-Radio Access Network) 100 is an evolved version of prior radio access networks, makes the prior radio access networks more open and smarter than previous generations. The O-RAN provides real-time analytics that drive embedded machine learning systems and artificial intelligence back end modules to empower network intelligence. Further, the O-RAN includes virtualized network nodes with open and standardized interfaces. The open interfaces are essential to enable smaller vendors and operators to quickly introduce their own services, or enables operators to customize the network to suit their own unique needs. Open interfaces also enable multivendor deployments, enabling a more competitive and vibrant supplier ecosystem. Similarly, open-source software and hardware reference designs enable faster, more democratic and permission-less innovation. Further, the O-RAN introduces a self-driving network by utilizing new learning-based technologies to automate operational network functions. These learning-based technologies make the O-RAN intelligent. Embedded intelligence, applied at both component and network levels, enables dynamic local radio resource allocation and optimizes network wide efficiency. In combination with O-RAN's open interfaces, Al-optimized closed-loop automation is a new era for network operations.

[0042] The O-RAN 100 may comprise a Service Management and Orchestrator (SMO) (can also be termed as "Service Management and Orchestration Framework") 102, a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) 104 residing in the SMO 102, a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) 106, an Open Evolved NodeB (O-eNB) 108 and a plurality of network nodes (or network elements (NE)) 110 (110a, 110b, 110c,
HOd, HOe HOn) comprising at least one of an Open Central Unit Control
Plane (O-CU-CP) 110a, an Open Central Unit User Plane (O-CU-UP) 110b, an Open Distributed Unit (O-DU) 110c, an Open Radio Unit (O-RU) llOd and an Open Cloud (O-Cloud) llOe.
[0043] Further, 5G Access Network Functions (NFs) (interchangeably be referred as network nodes) is one of components of the ORAN 100 in that the O-CU or CU (interchangeably be referred as 110a) comprises less time-sensitive packet processing functions and the O-DU or DU (interchangeably be referred as 110c) comprises real-time, baseband processing functions. The DU 110c can be centralized or located near a cell site, the CU-CP 110a and the CU-UP 110b are to provide control plane and user plane handling.
[0044] The SMO 102 is configured to provide SMO functions/services such as data collection and provisioning services of the ORAN 100. The data collection of the SMO 102 may include, for example, data related to a bandwidth of a wireless communication network and at least one of a plurality of user equipments (not shown in figures). That is, the SMO 102 oversees all the orchestration aspects, failure/recovery management and automation of ORAN elements and resource and supports 01, Al and 02 interfaces.
[0045] The Non-RT-RIC 104 is a logical function that enables non-real¬time control and optimization of the ORAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in the Near-RT RIC 106. It is a part of the SMO framework 102 and communicates to the Near-RT RIC using the Al interface. The Near-RT-RIC 106 is a logical function that enables near-real-time control and optimization of the O-RAN elements and resources via fine-grained data collection and actions

over E2 interface. Non-Real Time (Non-RT) control functionality (> Is) and Near-Real Time (Near-RT) control functions (< Is) are decoupled in an RIC (RAN Intelligent Controller). The Non-RT functions include service and policy management, RAN analytics and model-training for some of the near-RT RIC functionality, and non-RT RIC optimization.
[0046] The SMO 102 identifies a failure network element software component and services via interface through a set of microservices named x-Apps. The Non-RT-RIC 104 uses a plurality of x-Apps to achieve optimization by performing specific tasks such as monitoring the network, disaster recovery of failure nodes (interchangeably used as failure network element), resilient in nodes present in the radio access network. In response to identifying the failure in the network element, the Non-RT-RIC 104 transmits an authorization request to retrieve information from a run-time database (as detailed in FIG.2).
[0047] The O-eNB 108 is hardware aspect of a fourth generation RAN that communicates with at least one of the plurality of user equipments (not shown in figures) via wireless communication networks such as a mobile phone network. The O-eNB 108 is a base station and may also be referred to as e.g., evolved Node B ("eNB"), "eNodeB", "NodeB", "B node", gNB, or BTS (Base Transceiver Station), depending on the technology and terminology used. The O-eNB is a logical node that handles transmission and reception of signals associated with a plurality of cells (not shown in figures). The O-eNB 108 supports 01 and E2 interfaces to communicate with the SMO 102 and the Near-RT-RIC 106 respectively.
[0048] Further, the O-CU (Open Central Unit) is a logical node hosting RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol) and PDCP (Packet Data Convergence Protocol). The O-CU is a disaggregated O-CU and includes two sub-components: O-CU-CP 110a and O-CU-UP 110b. The O-CU-CP 110a is a logical node hosting the RRC and the control plane part of the PDCP. The O-CU-CP 110a supports 01, E2, Fl-c, El, X2-c, Xn-c and NG-c interfaces for interaction with other components/entities.

[0049] Similarly, the O-CU-UP 110b is a logical node hosting the user plane part of the PDCP and the SDAP and uses 01, El, E2, Fl-u, X2-u, NG-u and Xn-u interfaces.
[0050] The O-DU 110c is a logical node hosting RLC/MAC (Medium access control)/High-PHY layers based on a lower layer functional split and supports 01, E2, Fl-c, Fl-u, OFH CUS-Plane and OFH M-Plane interfaces.
[0051] The O-RU llOd is a logical node hosting Low-PHY layer and RF (Radio Frequency) processing based on a lower layer functional split. This is similar to 3GPP's "TRP (Transmission And Reception Point)" or "RRH (Remote Radio Head)" but more specific in including the Low-PHY layer (FFT/iFFT, PRACH (Physical Random Access Channel) extraction). The O-RU llOd utilizes OFH CUS-Plane and OFH M-Plane interfaces.
[0052] The O-Cloud 1 lOe is a collection of physical RAN nodes (that host various RICs, CUs, and DUs), software components (such as operating systems and runtime environments) and the SMO 102, where the SMO manages and orchestrates the O-Cloud 1 lOe from within via 02 interface.
[0053] Now referring to the various interfaces used in the ORAN 100 as mentioned above.
[0054] The 01 interface is element operations and management interface between management entities in the SMO 102 and O-RAN managed elements, for operation and management, by which FCAPS (fault, configuration, accounting, performance, security) management, Software management, File management shall be achieved. The O-RAN managed elements include the Near RT-RIC 106, the O-CU (the O-CU-CP 110a and the O-CU-UP 110b), the O-DU 110c, the O-RU llOd and the O-eNB 108. The management and orchestration functions are received by the aforesaid O-RAN managed elements via the 01 interface. The SMO 102 in turn receives data from the O-RAN managed elements via the 01 interface for AI model training.
[0055] The 02 interface is a cloud management interface, where the SMO 102 communicates with the O-Cloud HOe it resides in. Typically, operators that

are connected to the O-Cloud 1 lOe can then operate and maintain the O-RAN 100 with the 01 or 02 interfaces.
[0056] The Al interface enables communication between the Non-RT-RIC 104 and the Near-RT-RIC 106 and supports policy management, machine learning and enrichment information transfer to assist and train AI and machine learning in the Near-RT-RIC 106.
[0057] The El interface connects the two disaggregated O-CUs i.e., the O-CU-CP 110a and the O-CU-UP 110b and transfers configuration data (to ensure interoperability) and capacity information between the O-CU-CP 110a and the O-CU-UP 110b. The capacity information is sent from the O-CU-UP 110b to the O-CU-CP 110a and includes the status of the O-CU-UP 110b.
[0058] The Near-RT-RIC 106 connects to the O-CU-CP 110a, the O-CU-UP 110b, the O-DU 110c and the O-eNB 108 (combinedly called as an E2 node) with the E2 interface for data collection. The E2 node can connect only to one Near-RT-RIC, but one Near-RT-RIC can connect to multiple E2 nodes. Typically, protocols that go over the E2 interface are control plane protocols that control and optimize the elements of the E2 node and the resources they use.
[0059] The Fl-c and Fl-u interfaces (combinedly an Fl interface) connect the O-CU-CP 110a and the O-CU-UP 110b to the O-DU 110c to exchange data about frequency resource sharing and network statuses. One O-CU can communicate with multiple O-DUs via Fl interfaces.
[0060] Open fronthaul interfaces i.e., the OFH CUS-Plane (Open Fronthaul Control, User, Synchronization Plane) and the OFH M-Plane (Open Fronthaul Management Plane) connect the O-DU 110c and the O-RU HOd. The OFH CUS-Plane is multi-functional, where the control and user features transfer control signals and user data respectively and the synchronization feature synchronizes activities between multiple RAN devices. The OFH M-Plane optionally connects the O-RU HOd to the SMO 102. The O-DU 110c uses the OFH M-Plane to manage the O-RU HOd, while the SMO 102 can provide FCAPS (fault, configuration, accounting, performance, security) services to the O-RUllOd.

[0061] The X2 interface is broken into the X2-c interface and the X2-u interface. The former is for the control plane and the latter is for the user plane that send information between compatible deployments, such as a 4G network's eNBs or between an eNB and a 5G network's en-gNB.
[0062] Similarly, an Xn interface is also broken into the Xn-c interface and the Xn-u interface to transfer control and user plane information respectively between next generation NodeBs (gNBs) or between ng-eNBs or between the two different deployments.
[0063] The NG-c (control plane interface) and the NG-u (user plane interface) connect the O-CU-CP 110a and the O-CU-UP 110b respectively to a 5G core. The control plane information is transmitted to the 5G access and mobility management function (AMF) that receives connection and session information from the user equipment and the user plane information is relayed to a 5Guser plane function (UPF), which handles tunnelling, routing and forwarding.
[0064] Advantageously, the SMO 102 may be configured to provide a failure management and disaster recovery of the plurality of network nodes 110a-HOe during the failure event of the base station (i.e., O-eNB 108), MME and UE using a standby network node 212 and UE context information stored in a stateful (run-time) database 210, as describe below in FIG. 2.
[0065] Unlike to conventional mechanism that is deployed/belong to the 5G core component, the proposed mechanism deploys the failure recovery management system towards the 5G Access Network.
[0066] FIG. 2 illustrates various hardware elements of a failure recovery management system 200 communicating with at least one UE (user equipment) 214.
[0067] Referring to FIG. 2, the failure recovery management system 200 includes a connector 202, a failure recovery management unit 204, a storage unit 206, an ingress handler 208, the run-time database (or run-time database cluster) 210 configured to store a first contextual information and a second contextual information of the at least one UE 214 (or UE 214) and the plurality of network nodes (or network elements (NE)) 110a-l lOe and 212.

[0068] The failure recovery management system 200 maintains contextual information of N+l connecting network nodes, wherein 'N' is the active nodes (i.e., 110a-l lOe) and '+1' is a standby node (standby network node) (i.e., 212).
[0069] The first contextual information indicates active configurations of the at least one UE 214 and at least one first network node 110a-l lOe. The active configurations indicate a state (i.e., active state) of a plurality of network functions and associated configurations executed at the at least one UE 214 and the at least one first network node 110a-l lOe prior to the failure event of the RAN/the at least one first network node 110a-l lOe.
[0070] The failure recovery management unit 204 may be configured to detect the failure event (or failure) of the at least one first network node 110a-HOe. In response to detecting the failure event, the failure recovery management unit 204 may be configured to identify the second contextual information of the at least one UE 214 and the at least one first network node (HOa-llOe), corresponding to the at least one failed first network node HOa-llOe from the run-time database 210.
[0071] The second contextual information indicates failed configurations of the at least one UE 214 and the at least one failed first network node 110a-HOe. The failed configurations indicate a state (failure state) of the plurality of network functions and associated configurations executed at the at least one UE 214 and the at least one first network node HOa-llOe during the failure event of the RAN/at the at least one failed first network node 110a-l lOe.
[0072] Furthermore, the failure recovery management unit 204 may be configured to replace (i.e., update/configure) the at least one failed first network node HOa-llOe with at least one second network node 212 (i.e., standby network node) using the second contextual information.
[0073] Additionally, the failure recovery management unit 204 may be configured validate the failure of the at least one first network node HOa-llOe, transmit the second contextual information to the at least one second network node 212 and dynamically change a state of the at least one second network node (standby network node) 212 to an active network node.

[0074] Unlike to conventional systems, a dedicated run-time database 210 is configured to maintain the first and second contextual information of the UE 214 and the plurality of network nodes HOa-llOe and 212, irrespective of states (active/standby) of the plurality of network nodes HOa-llOe and 212. Accordingly, the failure recovery management unit 204 may configured to provide a faster (zero delay) deployment of the at least one second network node 212 during the failure event(s).
[0075] For example, a standby base band unit (BBU) node is presented into the access network in ready state. Thus, the failure recovery management unit 204 may be configured to replace the standby BBU node at the place of failed node by maintaining and identifying the context detail of failed node through the run-time database 210 and further configure the first contextual information of the UE 214 to configurations of the standby BBU node.
[0076] The run-time database 210 may use a real-time processing to execute workloads with constant change in state (active/standby) in connection with the plurality of network nodes HOa-llOe and 212, for updating running configuration within the wireless communication network.
[0077] Further, the ingress handler 208 may be configured to maintain the IP (Internet Protocol) address of the N+l connecting nodes and virtual IP address of a cluster comprising of a physical and logical resources of computing, storing, and networking of the failure recovery management system 200.
[0078] In some aspects, the failure recovery management unit 204 may be configured to apply a distributed message queuing and parallel computing process to perform multiple operations (such as maintaining, identifying, fault detection, etc.,) simultaneously, while configuring the at least one second network node 212.
[0079] The connector 202 may be configured to assist the communication of instructions/messages between the plurality of network nodes HOa-llOe and 212, the at least one UE 214 and other hardware elements of the failure recovery management system 200. For example, a message queue provides temporarily stored messages, and endpoints that allow software components to connect to the

queue to send and receive messages. The messages are usually small, and can be things like requests, replies, error messages.
[0080] The storage unit 206 may store the first and second contextual information, programs and data necessary for the operation of the failure recovery management system 200. The storage unit 206 may be composed of a storage medium such as SQL and NO-SQL wherein SQL is stateful and NO-SQL is stateless, any data which is maintained at producer side is called stateful and any data which maintained at consumer-side is called stateless. Also, there may be a plurality of storage units 206.
[0081] Unlike to conventional mechanism, the proposed failure recovery management system 200 provides backup mechanism and analytics for disaster recovery at the Access Network as the standby network node and the run-time database 210 storing context information, update standby system information into SMO 102 via the interface.
[0082] FIG. 3 is sequence diagram 300 illustrating a communication between the failure recovery management unit 204 (residing in the SMO 102) and network nodes 110 and 212, according to present disclosure.
[0083] In some aspects, the failure recovery management unit 204 may be implemented as NMS/EMS of the SMO 102. In general, a network management system (NMS) is an application or set of applications that lets network engineers manage a network's independent components inside a bigger network management framework and performs several key functions. On the other hand, an element management system (EMS) manages specific types of one or more network elements (or nodes) within a telecommunication management network (TMN). In most cases, it is the job of the EMS within a network element to manage functions and capabilities, but not necessarily traffic. The EMS communicates upward to higher-level systems of network management (NMS), to manage the traffic between itself and other network nodes. The EMS is a critical part of the telecommunications management solution. One reason is that the EMS is the only exposed network element within the TMN and acts as the mediator of

the information. It also controls the network nodes within a network management system.
[0084] The SMO 102 relates to network function framework and orchestrator, where the NMS/EMS maintains heartbeat of the NFs, to identify the failure in active nodes, and the SMO receives the failure active node detection information from the NMS. This is described at step 1.
[0085] At step 2, the failure node information is then transmitted by the SMO to the at least one second network node 212 (i.e., standby network node), while failure in any of the at least one first network node HOa-llOe (i.e., active nodes).
[0086] Further, at step 3, the at least one second network node 212 may be configured to identify and retrieve the running configuration (i.e., the second contextual information) of the at least one failed first network node HOa-llOe, stored in the run-time database 210 (UE context and state of the network functions).
[0087] In response to step 3, the at least one second network node 212 may get enabled (i.e., change state to ready or active state), at step 4, and replace, at step 5, any of the at least one failed first network node HOa-llOe with the at least one second network node 212 using the second contextual information i.e., by swapping active node to standby network node and vice versa.
[0088] FIG. 4 is a flowchart 400 illustrating a method for failure recovery management of the plurality of network nodes. It may be noted that in order to explain the method steps of the flowchart 400, references will be made to the elements explained in FIGs. 1, 2 and 3.
[0089] At step 402, the method includes maintaining the first contextual information and the second contextual information of the at least one user equipment (UE) 214 and the plurality of network nodes 110a-l lOe and 212, where the first contextual information indicates active configurations of the at least one UE 214 and at least one first network node 110a-1 lOe.
[0090] At step 404, the method includes detecting a failure event of the at least one first network node 110a-l lOe.

[0091] Further, at step 406, the method includes identifying the second contextual information of the at least one UE 214 and the at least one first network node HOa-llOe corresponding to the at least one failed first network node 110a-HOe. The second contextual information indicates failure configurations of the at least one UE 214 and the at least one failed first network node 110a-l lOe.
[0092] Further, at step 408, the method includes replacing the at least one failed first network node 110a-l lOe with the at least one second network node 212 using the second contextual information.
[0093] It may be noted that the flowchart 400 is explained to have above stated process steps, however, those skilled in the art would appreciate that the flowchart 400 may have more/less number of process steps which may enable all the above stated implementations of the present disclosure.
[0094] The various actions, acts, blocks, steps, or the like in the flow chart and sequence diagrams may be performed in the order presented, in a different order or simultaneously. Further, in some implementations, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the present disclosure.
[0095] The embodiments disclosed herein can be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.
[0096] It will be apparent to those skilled in the art that other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention. While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above-de scribed embodiment, method, and examples, but by all embodiments and methods within the scope of the invention. It is intended that the specification and examples be

considered as exemplary, with the true scope of the invention being indicated by the claims.
[0097] The methods and processes described herein may have fewer or additional steps or states and the steps or states may be performed in a different order. Not all steps or states need to be reached. The methods and processes described herein may be embodied in, and fully or partially automated via, software code modules executed by one or more general purpose computers. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in whole or in part in specialized computer hardware.
[0098] The results of the disclosed methods may be stored in any type of computer data repository, storage medium such as SQL and NO-SQL wherein SQL is stateful and NO-SQL is stateless, any data which is maintained at producer side is called stateful and any data which maintained at consumer-side is called stateless.
[0099] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.
[00100] Moreover, the various illustrative logical blocks and
modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic

device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general-purpose processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
[00101] The elements of a method, process, routine, or algorithm
described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.
[00102] Conditional language used herein, such as, among others,
"can," "may," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain alternatives include, while other alternatives do not

include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more alternatives or that one or more alternatives necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular alternative. The terms "comprising," "including," "having," and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list.
[00103] Disjunctive language such as the phrase "at least one of X,
Y, Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain alternatives require at least one of X, at least one of Y, or at least one of Z to each be present.
[00104] While the detailed description has shown, described, and
pointed out novel features as applied to various alternatives, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the scope of the disclosure. As can be recognized, certain alternatives described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.

CLAIMS
We Claim:

1. A method for managing a plurality of network nodes (HOa-llOe and 212)
during a radio access network (RAN) failure, the method comprising:
maintaining a first contextual information and a second contextual information of at least one user equipment (UE) (214) and said plurality of network nodes (HOa-llOe and 212), wherein said first contextual information indicates active configurations of said at least one UE (214) and at least one first network node (110a-l lOe);
detecting a failure event of said at least one first network node (110a-llOe);
identifying said second contextual information of said at least one UE (214) and said at least one first network node (110a-l lOe) corresponding to said at least one failed first network node (HOa-llOe), wherein said second contextual information indicates failure configurations of said at least one UE (214) and said at least one failed first network node (110a-l lOe); and
replacing said at least one failed first network node (HOa-llOe) with at least one second network node (212) using said second contextual information.
2. The method as claimed in claim 1, wherein said first contextual information and said second contextual information are maintained in a run-time database configured for real-time processing of said plurality of network nodes.
3. The method as claimed in claim 1, wherein said at least one first network node is an active network node and said at least one second network node is a standby network node.
4. The method as claimed in claims 1 and 3, wherein the method comprises:
validating said failure of said at least one first network node;

transmitting said second contextual information to said at least one second network node; and
dynamically changing a state of said standby network node to said active network node.
5. The method as claimed in claim 1, wherein said first contextual information and
second contextual information are associated with an ingress handler (208),
wherein said ingress handler comprises internet protocol (IP) addresses of said
plurality of network nodes and wherein said ingress handler comprises a virtual IP
address of a cluster comprising of a physical and logical resources of computing,
storing, and networking of said first contextual information and second contextual
information.
6. A failure recovery management system (200) for managing a plurality of
network nodes (110a-l lOe and 212) during a radio access network (RAN) failure,
the system (200) comprising:
a connector (202) configured to transmit and receive data between said plurality of network nodes (110a-l lOe and 212),
a run-time database (210) configured to maintain a first contextual information of at least one user equipment (UE) (214) and at least one first network node (HOa-llOe) from said plurality of network nodes (HOa-llOe and 212), wherein said first contextual information indicates active configurations of said at least one UE (214) and said at least one first network node (HOa-llOe), and
a failure recovery management unit (204) connected to said connector (202) and said run-time database (210) and is configured to:
detect a failure of said at least one first network node (110a-l lOe);
identify a second contextual information of said at least one UE
(214) and said at least one first network node (HOa-llOe) corresponding
to said detected failure of said at least one first network node (110a-l lOe),
wherein said second contextual information indicates failure

configurations of said at least one UE (214) and said at least one first network node (110a-l lOe); and
replace said at least one failed first network node (110a-l lOe) with at least one second network node (212) using said second contextual information.
7. The system as claimed in claim 6, wherein said first contextual information and said second contextual information are maintained in the run-time database (210) for real-time processing of said plurality of network nodes.
8. The system as claimed in claim 6, wherein said at least one first network node is an active network node and said at least one second network node is a standby network node.
9. The system as claimed in claims 6 and 8, wherein the failure recovery
management unit (204) is further configured to:
validate said failure of said at least one first network node;
transmit said second contextual information to said at least one second network node; and
dynamically change a state of said standby network node to said active network node.
10. The system as claimed in claim 6, wherein said first contextual information
and second contextual information are associated with an ingress handler (208),
wherein said ingress handler comprises internet protocol (IP) addresses of said
plurality of network nodes and wherein said ingress handler comprises a virtual IP
address of a cluster comprising of a physical and logical resources of computing,
storing, and networking of said first contextual information and second contextual
information.