System and method for automatic switchover to backup node during database failure

Abstract

The present disclosure provides a system (102) and method (500) for ensuring service continuity in a network (108) through automatic switchover to one or more backup nodes (304) upon detection of database failure. The method (500) involves continuously monitoring health parameters of a first database (210A) associated with a primary node (304A) to detect anomalies or failures. Once a failure is identified, a switchover request is transmitted to the backup nodes (304) for evaluation. Each backup node determines the availability of its associated database (210) and, upon confirming readiness, transmits a notification to a processing engine (208). In response to the notification, the processing engine initiates an automatic switchover by updating one or more attributes of the selected backup node (304), thereby promoting it to an active operational role. This seamless transition ensures uninterrupted network performance, eliminates manual intervention, and enhances fault tolerance and system resilience against database outages.

Description

SYSTEM AND METHOD FOR AUTOMATIC SWITCHOVER TO BACKUP NODE DURING DATABASE FAIEURERESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to JIO PLATFORMS LIMITED or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.FIELD OF DISCLOSURE

[0002] The present disclosure generally relates to the field of telecommunication networks. More particularly, the present disclosure relates to automatic switchover mechanisms for network function nodes, such as binding support function (BSF) instances, based on database health monitoring and rolebased instance promotion to maintain uninterrupted network operations.DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The expression ‘Network Function (NF)’ used hereinafter in the specification refers to a logical entity in a communication network, such as a 5G Core (5GC) network, configured to provide a specific set of services, operations, or processing capabilities in accordance with standardized network architecture. The NF may be implemented in hardware, software, or a combination thereof, and may communicate with other NFs.

[0005] The expression ‘Binding Support Function (BSF)’ used hereinafter in the specification refers to a network function in the 5G Core network that provides service binding and discovery capabilities. The BSF is configured to store, manage, and provide binding information that maps a subscriber’s or device’s application function (AF) requests to the corresponding policy control function (PCF) instances. The BSF may interact with other NFs via standardized interfaces, and may maintain database records for binding information, NF discovery, and policy- related parameters.

[0006] The expression ‘Switchover’ used hereinafter in the specification refers to a process of shifting operations from a primary network function to a standby network function or a spare network function to ensure high availability and minimal disruption.

[0007] The expression ‘Primary Node’ used hereinafter in the specification refers to an active network element or functional entity responsible for performing a primary operational role within a high-availability configuration. The primary node handles live traffic, manages the main database, and processes requests in real time. It is typically the source for data replication to backup nodes to ensure service continuity in case of failure.

[0008] The expression ‘Standby Node’ used hereinafter in the specification refers to a network element or functional entity maintained in a synchronized or near-synchronized state with the primary node. The standby node remains idle under normal conditions but is ready to take over the primary node’s operational role through a switchover or failover process in the event of a failure or planned maintenance.

[0009] The expression ‘Spare Node’ used hereinafter in the specification refers to a network element or functional entity that is not actively participating in primary or standby operations under normal conditions but can be activated and provisioned to assume the role of a standby or primary node as required. The spare node maybe utilized during extended outages, maintenance windows, or scaling operations to provide additional redundancy.

[0010] The expression ‘Active Node’ used hereinafter in the specification refers to a network element or functional entity currently engaged in handling live traffic, executing control-plane or user-plane operations, and managing associated databases or resources. The active node may be a primary node or, in certain configurations, a load-sharing node working in parallel with another active node.

[0011] The expression ‘Backup Node’ used hereinafter in the specification refers to a network element or functional entity maintained with synchronized or periodically updated data from an active node. The backup node’s primary role is to replace or supplement the active node in the event of failure, degradation, or planned switchover. A backup node may operate as a standby node, a spare node, or a dedicated disaster recovery node, depending on the system architecture.

[0012] The expression “primary site” used hereinafter in the specification refers to a main location where the core operations and primary instance of a database are hosted and managed. The primary site is a central hub for data processing, storage, and access.

[0013] The expression “redundant site” used hereinafter in the specification refers to a backup location enabled to provide continuity of operations if the primary site is unavailable due to failure, maintenance, or other disruptions.

[0014] The expression ‘High Availability State Manager (HSM)’ as used in the specification refers to a network entity responsible for managing the state of database instances, coordinating failover and switchover operations, and ensuring that all network entities remain available and consistent throughout failure and switchover operations.

[0015] The expression ‘Health Parameters’ used hereinafter in the specification refers to one or more measurable indicators that reflect the operational status, performance, and reliability of a system component, such as a database,network function, or server. The health parameters include, but are not limited to, connectivity status, query responsiveness, backup status, replication status, error rates, resource utilization (e.g., memory, storage), and log file integrity.

[0016] These definitions are in addition to those expressed in the art.BACKGROUND OF DISCLOSURE

[0017] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0018] In a network architecture that ensures high availability and resilience, various network functions (NFs) are employed, each fulfilling specific roles within a cluster configuration. These NFs are categorized into distinct roles, specifically active NF, standby NF, and spare NF, each serving critical functions to maintain operational integrity and service continuity. The active NF serves as a primary operational node within a cluster. The active NF is responsible for processing all network traffic and managing requests. The active NF typically interacts with a database (DB) to fulfil these requests and maintain operational data. The standby NF functions as a backup to the active NF. The standby NF remains passive during normal operations but is fully synchronized with the active NF. The spare NF represents an additional backup resource that is not continuously synchronized with the active NF. The spare NF provides an additional layer of fault tolerance by being available for activation when both the active and standby NFs fail.

[0019] In the network, each NF is coupled with a dedicated database serving as a centralized repository for storing data. The database may be accessible to multiple NFs and applications across the network. The database maintains data consistency and integrity, ensuring all NFs and applications interact with the samedata. The databases allow multiple NFs to access and modify data concurrently. The functioning of the NF depends heavily on the availability and operational statuses of the database. The database may sometimes face outages or disruptions that impact the functioning of the NFs, leading to service downtime. The database outages may occur due to hardware failure, software issues, network problems and application errors. If the database becomes inaccessible due to failure or other issues, the NF cannot retrieve or update the data it needs to process incoming requests. A database failure may cause the NF to become unresponsive, resulting in downtime or degraded user service quality. Therefore, it is required to implement a database redundancy and resilience strategy to mitigate a risk of service downtime and degraded user service quality caused by database outages.

[0020] In conventional approaches, the database outages are tackled by employing manual backup processes and manual monitoring. The manual monitoring may involve checking a health of the database, performance and resource usage to detect potential issues. Network administrators may carry out the manual backup procedures at specified intervals which consume both time and effort. Moreover, the manual backup procedures may involve manually configuring a backup database and restoring a primary database. The restoration and backup process may be complex and restrains a user from accessing the data stored in the database. Further, proper management and monitoring of the databases associated with the backup nodes (NFs) are crucial for seamless and effective communication in the network. The conventional approaches face difficulties in maintaining backup nodes for huge network users. Manual maintenance and management of the backup nodes are prone to errors, leading to incorrect configurations, prolonged downtime, or data inconsistencies.

[0021] There is, therefore, a need in the art to overcome the deficiencies of the prior arts.OBJECTIVES OF THE PRESENT DISCLOSURE

[0022] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as listed below.

[0023] An objective of the present disclosure is to provide a system and a method for implementing an automatic switchover to one or more backup nodes during a network database failure.

[0024] Another objective of the present disclosure is to provide a system and a method for performing automatic health checks for databases in a network.

[0025] Another objective of the present disclosure is to provide a system and a method for determining a switchover of databases based on database health in a network.

[0026] Another objective of the present disclosure is to provide a system and a method for maintaining high availability and reliability of network functions (NFs) during database failure in a network.

[0027] An objective of the present disclosure is to provide a system and a method that automatically switches over to a standby NF or a spare NF upon a database failure of an active NF.

[0028] Another objective of the present disclosure is to provide a system and a method that ensures high availability and resilience of NFs within a network.

[0029] Another objective of the present disclosure is to provide a system and a method that eliminates a need for manual intervention during switchover due to database failures.

[0030] Another objective of the present disclosure is to provide a system and a method that provides a robust mechanism for maintaining an uptime of a network and performance.

[0031] Another objective of the present disclosure is to provide a system and a method that allows seamless failover and recovery without disrupting a user experience.

[0032] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.SUMMARY

[0033] In an exemplary embodiment, the present invention discloses a method for performing automatic switchover to at least one backup node on detection of database failure in a network. The method includes monitoring, by a processing engine, a plurality of health parameters of a first database associated with a primary node. The method includes detecting, by the processing engine, a failure of the first database based on the monitored plurality of health parameters. The method includes communicating, by the processing engine, at least one switchover request towards all backup nodes. The method also includes determining, by the at least one backup node, an availability of at least one database associated with the at least one backup node. The method also includes notifying, by the at least one backup node, the processing engine on determining the availability of the at least one database by sending a notification. The method also includes on receiving the notification from the at least one backup node, performing, by the processing engine, an automatic switchover to the at least one backup node by updating at least one attribute associated with the at least one backup node based on the at least one switchover request.

[0034] In some embodiments, the at least one backup node includes a standby node and a spare node.

[0035] In some embodiments, the at least one attribute includes a role of the at least one backup node.

[0036] In some embodiments, the plurality of health parameters includes a database connectivity, a database query responsiveness, and a database backup status.

[0037] In some embodiments, the method further includes sending, by the standby node, a second request towards the spare node upon determining that the at least one database associated with the standby node is unavailable.

[0038] In some embodiments, the spare node is configured to perform a set of steps. The step includes receiving, by the spare node, the at least one switchover request from the processing engine and the second request from the standby node. The step further includes determining, by the spare node, a time interval between the reception of the at least one switchover request and the second request. The step further includes comparing, by the spare node, the determined time interval with a configurable time interval. The step further includes transmitting, by the spare node, at least one switchover notification to the processing engine if the determined time interval is less than the configurable time interval.

[0039] In some embodiments, the processing engine determines a number of backup nodes available for switchover. If the number of backup nodes for the switchover is one, the processing engine switchovers directly to a spare node.

[0040] In an exemplary embodiment, a system for implementing automatic switchover to at least one backup node on a database failure in a network is disclosed. The system includes at least one high-availability state manager (HSM). The at least one HSM includes a memory. The at least one HSM further includes a processing engine coupled to the memory and is configured to execute instructions stored in the memory to monitor a plurality of health parameters of a first database associated with a primary node. The processing engine is further configured to detect a failure of the first database based on the monitored plurality of health parameters. The processing engine is further configured to communicate at least one switchover request towards all backup nodes. The at least one HSM further includes the at least one backup node configured to cooperate with the at least oneHSM to receive the at least one switchover request. The at least one backup node is configured to: determine an availability of at least one database associated with the at least one backup node. The at least one backup node is further configured to: notify the processing engine on determining the availability of the at least one database by sending a notification. On receiving the notification from the at least one backup node, the processing engine is configured to perform an automatic switchover to the at least one backup node by updating at least one attribute associated with the at least one backup node based on the at least one switchover request.

[0041] In some embodiments, the at least one backup node includes a standby node and a spare node.

[0042] In some embodiments, the at least one attribute includes a role of the at least one backup node.

[0043] In some embodiments, the plurality of health parameters includes a database connectivity, a database query responsiveness, and a database backup status.

[0044] In some embodiments, the standby node is configured to send a second request towards the spare node upon determining that the at least one database associated with the standby node is unavailable.

[0045] In some embodiments, the spare node is configured to receive the at least one switchover request from the processing engine and the second request from the standby node. The spare node is further configured to: determine a time interval between the reception of the at least one switchover request and the second request. The spare node is further configured to compare the determined time interval with a configurable time interval. The spare node is further configured to transmit at least one switchover notification to the processing engine if the determined time interval is less than the configurable time interval.

[0046] In some embodiments, the processing engine determines a number of backup nodes available for switchover and if the number of backup nodes for the switchover is one, the processing engine switchovers directly to a spare node.

[0047] In an exemplary embodiment, a user equipment communicatively coupled with a network is disclosed. The coupling includes receiving, by the network, a connection request from the user equipment. The coupling further includes sending, by the network, an acknowledgment of the connection request to the user equipment. The coupling further includes transmitting a plurality of signals in response to the connection request. An automatic switchover to at least one backup node on detection of database failure is performed by a system. The system includes at least one high-availability state manager (HSM). The at least one HSM includes a memory. The at least one HSM further includes a processing engine coupled to the memory and is configured to execute instructions stored in the memory to monitor a plurality of health parameters of a first database associated with a primary node. The processing engine is further configured to detect a failure of the first database based on the monitored plurality of health parameters. The processing engine is further configured to communicate at least one switchover request towards all backup nodes. The at least one HSM further includes the at least one backup node configured to cooperate with the at least one HSM to receive the at least one switchover request. The at least one backup node is configured to: determine an availability of at least one database associated with the at least one backup node. The at least one backup node is further configured to: notify the processing engine on determining the availability of the at least one database by sending a notification. On receiving the notification from the at least one backup node, the processing engine is configured to perform an automatic switchover to the at least one backup node by updating at least one attribute associated with the at least one backup node based on the at least one switchover request.

[0048] In an exemplary embodiment, a computer program product including a non-transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to execute amethod for performing automatic switchover to at least one backup node on a database failure in a network. The method includes monitoring, by a processing engine, a plurality of health parameters of a first database associated with a primary node. The method further includes detecting, by the processing engine, a failure of the first database based on the monitored plurality of health parameters. The method further includes communicating, by the processing engine, at least one switchover request towards all backup nodes. The method also includes determining, by the at least one backup node, an availability of at least one database associated with the at least one backup node. The method also includes notifying, by the at least one backup node, the processing engine on determining the availability of the at least one database by sending a notification. The method also includes on receiving the notification from the at least one backup node, performing, by the processing engine, an automatic switchover to the at least one backup node by updating at least one attribute associated with the at least one backup node based on the at least one switchover request.

[0049] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.BRIEF DESCRIPTION OF DRAWINGS

[0050] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0051] FIG. 1 illustrates an exemplary network architecture implementing a system to perform automatic switchover to at least one backup node on detection of database failure in a network, in accordance with embodiments of the present disclosure.

[0052] FIG. 2 illustrates an exemplary block diagram of the system for performing the automatic switchover to the at least one backup node on detection of database failure in the network, in accordance with embodiments of the present disclosure.

[0053] FIG. 3 illustrates an exemplary system architecture for performing the automatic switchover to the at least one backup node on detection of the database failure in the network, in accordance with embodiments of the present disclosure.

[0054] FIG. 4 illustrates exemplary flow diagram representing a process of automatic switchover to the at least one backup node on detection of the database failure in the network, in accordance with embodiments of the present disclosure.

[0055] FIG. 5 illustrates an exemplary flowchart of a method for performing the automatic switchover to the at least one backup node on the database failure in the network, in accordance with embodiments of the present disclosure.

[0056] FIG. 6 illustrates an exemplary computer system in which or with which the system and method may be implemented, in accordance with embodiments of the present disclosure.

[0057] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network Architecture106-1, 106-2. . . 106-N - Plurality of Users108 - Network200 - Block Diagram202 - Processor(s)204 - Memory206 - Interface(s)208 - Processing Engine210 - Database210A - First Database210B - Second Database212 - Monitoring Module214 - Failure Detection Module216 - Failover Control Module300 -System Architecture302 - High Availability State Manager (HSM)302A - Active High Availability State Manager (HSM)302B - Standby High Availability State Manager (HSM)302C - Spare High Availability State Manager (HSM)304A - Primary Node304 - Backup Nodes304B - Standby Node304C - Spare Node306A - Primary Site306B - Redundant Site400 - Process500 - Method Flowchart600 - Computer System610 - External Storage Device620 - Bus630 - Main Memory640 - Read-Only Memory650 - Mass Storage Device660 - Communication Ports670 - ProcessorDETAILED DESCRIPTION OF DISCLOSURE

[0058] In the following description, for the purposes of explanation, various specific details are set forth to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosureare described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0059] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0060] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.

[0061] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0062] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, thesubject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0063] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0064] The terminology used herein is to describe embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a” “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on thedescribed embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0065] As used herein, an “electronic device” or “portable electronic device” or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device can receive and / or transmitting one or parameters, performing function / s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and / or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0066] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

[0067] In a network architecture, various network functions (NFs) are employed to ensure high availability and resilience. These NFs are organized into a cluster configuration, where they are assigned, specific roles categorized as active NF, standby NF, and spare NF. Each role plays a crucial part in maintaining an overall operational integrity and service continuity of a network. The active NF functions as a primary node within a cluster. The active NF is responsible for managing and processing all incoming network traffic and requests. The active NF interacts directly with a database to retrieve and update operational data necessary for its tasks. A primary role of the active NF is to handle live traffic and ensure that user requests are processed efficiently and correctly. As a main operational node, the active NF is critical for a day-to-day functionality of the network. The standby NF serves as a backup to the active NF. Although the standby NF remains idle or passive during normal operations, the standby NF stays fully synchronized with the active NF to ensure that it has up-to-date data and configurations. In the event of a failure or issue with the active NF, the standby NF is ready to take over its responsibilities. This setup ensures minimal disruption to a service, as the standby NF can quickly assume the role of the active NF with little to no downtime. The spare NF is prepared to take over in cases where both the active NF and the standby NF experience failures simultaneously. The spare NF is a critical component of the network’s resilience strategy, ensuring that there is always a fallback option available to maintain network operations.

[0068] The capability of NFs to effectively process and handle incoming requests is directly tied to the availability and performance of the database. When the database experiences a failure, it impairs NF’s ability to access and manage the necessary data, leading to significant service disruptions and a decline in user experience quality. The impact of such a database failure may manifest as delays in processing requests, errors in data handling, or complete unavailability of services, all of which undermine the network’s reliability and operational efficiency.

[0069] Conventional approaches for monitoring and analyzing database downtime and performance involve manual and labour-intensive procedures. Theseapproaches typically lack the capability for real-time monitoring, meaning that issues are often detected and addressed only after significant damage has occurred. Manual analysis of performance metrics and downtime incidents requires considerable time and effort, which delays the identification and resolution of problems. Errors during manual recovery, such as incorrect configurations or oversight of critical issues, may prolong the downtime and result in incomplete or improper restoration of database services. Consequently, the network experiences prolonged interruptions, impacting operational performance and user satisfaction. These issues highlight a need for more automated and responsive solutions to monitor, diagnose, and recover from database issues to ensure continuous and reliable service.

[0070] To address the challenges in the conventional approaches, the present disclosure enables an automatic switchover to a backup node during a database failure.

[0071] In an embodiment, the present disclosure provides a system and a method for implementing automatic switchover to one or more backup nodes on detection of the database failure in a network. The method includes detecting a failure of a first database by monitoring a plurality of health parameters associated with the first database and initiating a switchover on the detection of the failure of the first database by selecting at least one backup node based on a set of criteria associated with each of the one or more backup nodes. The method includes sending a switchover request to the selected backup node . The method includes determining a status of a second database associated with the selected backup node. On determining an active status of the second database, the method includes switching to the selected backup node.

[0072] The present disclosure discloses a system that performs automated database health checks, intelligent decision-making processes, and automatic switchover mechanisms to enhance the reliability and availability of the network functions. The disclosed system continuously performs automated health checks onthe database to monitor its operational status and performance metrics. These health checks are performed to identify any anomalies, failures, or performance degradation promptly. Upon detecting a potential issue, the system evaluates a current role and configuration of the database to determine an appropriate response.

[0073] In an event of the database failure or significant issue, the system decides whether a switchover to a backup instance (network node) is necessary. The decision is based on real-time data from the health checks and specific requirements of system’s configuration. Following this evaluation, the system automatically initiates a switchover to a designated backup database instance, ensuring that the NFs managing network traffic maintain uninterrupted access to a fully operational database.

[0074] By employing a combination of automated health monitoring, dynamic decision-making, and seamless failover capabilities, the system ensures high availability and reliability of the database service. By eliminating manual intervention during the database failures, the system significantly enhances operational efficiency and minimizes service disruptions.

[0075] The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1- FIG. 6.

[0076] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (102) to perform automatic switchover to at least one backup node (not shown) on detection of database failure in a network (108), in accordance with embodiments of the present disclosure.

[0077] Referring to FIG. 1, the network architecture (100) may include one or more user equipment (UEs) (104-1, 104-2... 104-N) that may be associated with one or more users (106-1, 106-2... 106-N) and the system (102) in an environment. In an embodiment, the one or more UEs (104-1, 104-2... 104-N) may be communicated to the system (102) through the network (108). A person of ordinary skill in the art will understand that the one or more UEs (104-1, 104-2... 104-N)may be individually referred to as the UE (104) and collectively referred to as the UEs (104). A person of ordinary skill in the art will appreciate that the terms “computing device(s)” and “UE” may be used interchangeably throughout the disclosure. Although three UEs (104) are depicted in the FIG. 1, however any number of the UE (104) may be included without departing from the scope of the ongoing description. Similarly, a person of ordinary skill in the art will understand that the one or more users (106-1, 106-2... 106-N) may be individually referred to as the user (106) and collectively referred to as the users (106).

[0078] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such embodiment, the UE (104) may include, but is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting systems, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users (106) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not be limited to, intelligent multi-sensing, network-connected devices that can integrate seamlessly with each other and / or with a central server or a cloud-computing system or any other device that is network-connected.

[0079] In an embodiment, the UE (104) may include but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a global positioning system (GPS) device, a laptop, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like.

[0080] In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electro-mechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a general-purpose computer, a desktop, a personal digital assistant, a mainframe computer, or any other computing device. In another embodiment, the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (106) or the entity such as a touchpad, a touch -enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

[0081] Referring to FIG. 1, the UE (104) may operate based on a set of executable instructions residing within its operating system. The executable instructions are configured to facilitate session establishment, maintain connectivity with serving network functions (NFs), and seamlessly resume ongoing communication sessions when a switchover occurs between network function instances during database failure recovery.

[0082] In an embodiment, the UE (104) may communicate with the system (102) through the network (108) for sending or receiving various types of data. In an embodiment, the network (108) may include at least one of a 5G network, a 6G network, or the like. The network (108) may enable the UE (104) to communicate with other devices in the network architecture (100) and / or with the system (102). The network (108) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (108) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a virtual private network (VPN), the Internet or the like.

[0083] In an embodiment, the network (108) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (108) may also include, by way of example but not limitation, one or more of a radio access network (RAN), a wireless network, a wired network, the internet, the intranet, a public network, a private network, a packet-switched network, a circuit- switched network, an ad hoc network, an infrastructure network, a public-switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. In an embodiment, the system (102) may be connected to backend servers (not shown).

[0084] Although the FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0085] FIG. 2 illustrates an exemplary block diagram of the system (102) for performing the automatic switchover to the at least one backup node (not shown) on the detection of the database failure in the network (108), in accordance with embodiments of the present disclosure. FIG. 2 with reference to FIG. 1, illustrates the system (102), that includes one or more processor(s) (202), a memory (204), an interface(s) (206), a processing engine (208), and a database (210).

[0086] The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s)(202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the system (102). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device, including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read-only memory (EPROM), flash memory, and the like.

[0087] In an embodiment, the interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output devices (RO), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (102). The interface(s) (206) may also provide a communication pathway for one or more components of the system (102). Examples of such components include, but are not limited to, the processing engine (208) and the database (210).

[0088] In an embodiment, the processing engine (208) may be implemented as a combination of hardware and programming, for example, programmable instructions, to implement one or more functionalities of the processing engine (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non-transitory machine -readable storage medium, and the hardware for the processing engine (208) may comprise a processing resource, for example, one or more processors, to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine (208). In such examples, the system (102) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate butaccessible to the system (102) and the processing resource. In other examples, the processing engine (208) may be implemented by electronic circuitry.

[0089] In an embodiment, the database (210) may include data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208). In an embodiment, the database (210) may be separate from the system (102). In an embodiment, the database (210) may store data that may be generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208). In an embodiment, the database (210) may be indicative of including, but not limited to, a relational database, a distributed database, a cloudbased database, or the like. In an exemplary embodiment, the processing engine (208) may include one or more units having functions that may include, but are not limited to, testing, storage, and peripheral functions, such as a wireless communication unit for remote operation and the like.

[0090] In an embodiment, the processing engine (208) may be employed in the NF. In an aspect, the NF may be, but is not limited to, an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a charging function (CHF), a policy control function (PCF), an authentication server function (AUSF), a unified data management (UDM), and so forth. In a preferred embodiment, the NF may be a binding support function (BSF).

[0091] In an embodiment, the processing engine (208) may include a plurality of functional modules that perform one or more operations for implementing the automatic switchover to the at least one backup node on the database failure in the network (108). The functional modules may include, but are not limited to, a monitoring module (212), a failure detection module (214) and a failover control module (216). In an embodiment, the database failures handled by the system (102) may be classified into different types, including hardware -level failures such as disk crashes or storage subsystem errors, software or application-level failures such as process crashes, memory leaks, or unresponsive query engines, network orconnectivity failures such as link loss, excessive latency, or packet drops, performance degradation failures such as slow query response time, throughput bottlenecks, or replication lag, and data consistency or integrity failures such as corrupted records, replication conflicts, or checksum mismatches. The monitoring module (212) is configured to monitor a plurality of health parameters (hereinafter referred to as the health parameters) of a first database (not shown) associated with a primary node (not shown). In an embodiment, monitoring the health parameters enable timely detection of anomalies, failures, or performance degradation, thereby facilitating proactive maintenance or switchover operations. In an embodiment, the anomalies or failures detected by the monitoring module (212) may include, but are not limited to, latency anomalies such as excessive query response times or sudden spikes in transaction delay, throughput anomalies such as sustained reduction in input / output operations or query execution rate, resource utilization anomalies such as abnormal memory consumption, CPU saturation, or storage exhaustion, errorrate anomalies such as unusually high numbers of failed transactions, aborted queries, or replication errors, connectivity failures such as loss of communication between the primary node and dependent services, and data integrity anomalies such as checksum mismatches, replication inconsistencies, or corrupted records. These anomalies may be indicative of hardware faults, software malfunctions, network disturbances, or consistency issues, and their timely detection enables the system (102) to initiate corrective or switchover actions. The health parameters may include, but not be limited to, a database connectivity, a database query responsiveness, a database backup status, and other health checks defined by the system (102). The health checks ensure that a server has an up-to-date understanding of an operational status of the database (210). In an example, the database connectivity may refer to a status of a connection between the database (210) and the NFs. The database status may refer to an overall health and operational state of the database (210). The backup status may refer to a current state and reliability of database backups. The replication status may refer to accuracy and timeliness of data replication across NF instances. In some embodiments, each health parameter may be associated with one or moremeasurement techniques and threshold values that define a degraded state or a failure condition. For instance, database connectivity may be tracked by periodic heartbeat or ping messages, with a failure declared if a configurable number of consecutive attempts are missed within a given time window. Query responsiveness may be measured by issuing test queries and recording response times, where a warning threshold may be triggered if response time exceeds, for example, 500 milliseconds, and a failure threshold may be declared if the response time consistently exceeds 2 seconds for a sustained duration. Backup status may be monitored by verifying timestamps and integrity of the most recent backups, with a failure triggered if no valid backup is detected within a policy-defined interval such as 24 hours. Replication status may be monitored by evaluating replication lag or log sequence number differences between the primary and secondary databases, with a failure declared if the lag exceeds a predefined threshold (e.g., 10 seconds of delay or 100 MB of unapplied logs). In some embodiments, the monitoring module (212) may further classify health states into levels such as “healthy,” “degraded,” or “failed” to distinguish between transient slowdowns and critical outages. For example, if query responsiveness slows from 100 milliseconds to 800 milliseconds for over 60 seconds, the monitoring module may mark the database as degraded and generate an alert, whereas if responsiveness exceeds 2 seconds for more than 120 seconds, the monitoring module may classify the database as failed and trigger the failover control module (216) to initiate switchover.

[0092] In an exemplary implementation, the monitoring module (212) may be configured to execute one or more diagnostic routines at predefined intervals or in response to trigger events to assess the health parameters of the first database associated with the primary node. The diagnostic routines may include, but are not limited to, heartbeat checks, query execution test, transaction log verification, and so forth. For example, the heartbeat checks may be performed by sending a lightweight query to the first database associated with the primary node to verify that the first database is online and responsive with an expected latency threshold. In another implementation, the monitoring module (212) may utilize machinelearning techniques, for example, anomaly detection models or predictive analytics trained on historical system data, to proactively identify potential failures. In yet another implementation, the monitoring module (212) may combine statistical evaluation, rule-based logic, and machine learning models in a hybrid approach to achieve more accurate and adaptive health assessment of the first database.

[0093] In an embodiment, the monitoring may be performed through active probing techniques, where the monitoring module (212) transmits test queries or connection requests to the first database and evaluates corresponding response metrics, such as but not limited to, a round-trip latency, a query execution time, a connection acceptance status, and so forth. In another embodiment, the monitoring module (212) may perform passive monitoring by subscribing to databasegenerated logs, replication events, or status notifications, thereby capturing realtime operational data without introducing additional load on the first database. The monitoring module (212) is configured to transmit the monitored health parameters of the first database to the failure detection module (214).

[0094] The failure detection module (214) is communicatively coupled to the monitoring module (212) to receive the monitored health parameters of the first database associated with the primary node. The failure detection module (214) is configured to detect a failure of the first database based on the monitored health parameters. In an exemplary embodiment, the failure detection module (214) may be configured to analyze the monitored health parameters received from the monitoring module (212) to determine whether the first database associated with the primary node is operating within acceptable operational limits. The failure detection module (214) may be configured to compare values of the monitored health parameters, such as, but not limited to, query response latency, replication lag, connection availability, error rate, and transaction success ratio, against a set of predefined threshold values or dynamically learned baselines. In some embodiments, the failure detection module (214) may rely on a combination of periodic polling and event-driven triggers to evaluate health conditions. Periodic polling may be performed at configurable intervals (e.g., every 5 to 30 seconds) toquery the monitoring module (212) for updated health parameters, while event- driven triggers may be generated immediately when a parameter crosses a warning or failure threshold, thereby enabling faster detection. To reduce false positives, the failure detection module (214) may employ a fault-tolerance window or sliding time window analysis, wherein a parameter must exceed its threshold for a continuous duration (e.g., three consecutive failed checks within 15 seconds) before a failure is declared. In scenarios where multiple failure criteria are simultaneously met, the module may prioritize the most critical condition, such as complete loss of connectivity, over less severe degradations such as increased query latency. For example, if query response latency exceeds 2 seconds for 120 seconds while replication lag simultaneously exceeds 5 seconds, the failure detection module (214) may classify the overall state as a database failure based on the higher- severity responsiveness metric and initiate failure reporting to the spare node. If the value of any monitored health parameter exceeds the corresponding predefined threshold for a continuous duration (e.g., exceeding a specified fault-tolerance window), the failure detection module (214) may be configured to classify such condition as a potential failure event.

[0095] In another embodiment, a weighted scoring or rules-based decision engine may be employed, where deviation of multiple health parameters from the corresponding predefined thresholds are aggregated to produce a composite health score. If the composite health score falls below a predefined failure threshold, the failure detection module (214) may determine that the first database associated with the primary node is in a failed or degraded operational state. Upon detecting the failure of the first database associated with the primary node, the failure detection module (214) is configured to initiate a switchover process by transmitting a switchover request to one or more backup nodes over a communication network. A switchover request is a predefined message or signal sent by the failure detection module to inform the backup nodes that the primary database has failed and that one or more backup nodes should assume the operational role of the failed database. The switchover request typically includes information such as the identity of thefailed database, the time and cause of failure detection, the current replication or synchronization status, and instructions for the backup node to assume the primary role. The purpose of the switchover request is to enable automatic, coordinated, and timely promotion of a backup node to ensure continuity of service, maintain data consistency, and prevent service disruption to clients or user equipment. In an embodiment, the switchover process may be carried out using different underlying mechanisms depending on the system configuration. In one case, the switchover is enabled through a database replication mechanism, where a backup node continuously maintains a synchronized copy of the primary database and is promoted upon receiving the switchover request. In another case, the switchover may be achieved using a failover clustering mechanism, in which a cluster manager or distributed coordinator. In yet another case, the switchover may be performed using a custom orchestration algorithm, where the failure detection module (214) applies selection criteria such as synchronization freshness, node priority, or geographic proximity to determine which backup node assumes the operational role. The communication of the switchover request may utilize predefined failover protocols or cluster communication frameworks, such as heartbeat signaling, leader-election protocols, or control application programming interfaces (APIs).

[0096] The backup nodes may include, but are not limited to, a standby node, a spare node, and so forth. In an embodiment, the standby node refers to a network element or functional entity maintained in a synchronized or near-synchronized state with the primary node. The standby node remains idle under normal conditions but is ready to take over the primary node’s operational role through a switchover or failover process in the event of a failure or planned maintenance. In an embodiment, the spare node refers to a network element or functional entity that is not actively participating in primary or standby operations under normal conditions but can be activated and provisioned to assume the role of a standby or primary node as required. The spare node may be utilized during extended outages, maintenance windows, or scaling operations to provide additional redundancy.

[0097] The communication network may include, but not limited to, a local area network (LAN), a wide area network (WAN), wireless networks, and so forth. In an exemplary embodiment, the switchover request may be encapsulated in a predefined protocol message (e.g., a hypertext transfer protocol (HTTP)Zhypertext transfer protocol secure (HTTPS) application programming interface (API) call, a google remote procedure call (gRPC) request, a transmission control protocol (TCP) socket message, or a message bus event) that includes one or more of: an identifier of a failed database, a role and configuration of the failed database prior to failure, a time and cause of failure detection, synchronization or replication status at the time of failure, instructions to assume an operational role of the failed database, and so forth. In some embodiments, the switchover request may be transmitted using a central communication protocol or messaging system, such as a Representational State Transfer (REST)-based HTTP / HTTPS API call to all backup nodes for status verification, or via a publish-subscribe (Pub / Sub) message bus that broadcasts the failure event to all subscribed backup nodes simultaneously. The use of a standardized communication protocol ensures interoperability across heterogeneous network functions, while enabling consistent and reliable delivery of switchover instructions. For example, in one implementation, the failure detection module (214) may invoke a REST API endpoint exposed by the standby and spare nodes to request status updates and readiness confirmation before authorizing the switchover. In another implementation, the module may publish a failure event onto a message bus, where both the standby and spare nodes are subscribers, thereby achieving low-latency and scalable dissemination of the switchover request.

[0098] In an embodiment, the failure detection module (214) is configured to determine a number of backup nodes available for the switchover before transmitting the switchover request to the one or more backup nodes. In an exemplary embodiment, the failure detection module (214) may be configured to determine the number of available backup nodes for the switchover by reading node registration information from a backup node list or registry maintained in thememory (204). In an embodiment, each time a backup node is added to the memory (204), the system (102) registers an identifier (e.g., node ID, network address) of the corresponding backup node in this backup node list. The backup node list may be maintained by a central controller, the processing engine (208), or a distributed cluster manager. The failure detection module (214) may be configured to retrieve the list of all backup nodes currently registered in the system (102) and verify their operational state, connectivity, and readiness to perform the switchover. The failure detection module (214) may be further configured to count a total number of unique entries in the backup node list that meet an availability criterion for the switchover, where each entry corresponds to an eligible backup node. If the count of eligible backup nodes for the switchover is one, the failure detection module (214) determines that only one backup node is available for the switchover, and therefore initiates a direct switchover to the spare node through a first switchover channel. The term “direct switchover” refers to a one-to-one switchover operation where the system bypasses arbitration or coordination logic and directly activates the spare node as the new primary. The “first switchover channel” may correspond to a predefined control channel or dedicated communication path between the failure detection module (214) and the spare node, such as a reserved Transmission Control Protocol (TCP)ZUser Datagram Protocol (UDP) port, a cluster-internal signaling channel, or a direct API call, which ensures immediate takeover without negotiation.

[0099] In another embodiment, if the count of the eligible backup nodes for the switchover is more than one, the failure detection module (214) is configured to transmit the switchover request to the one or more backup nodes. In this scenario, the “switchover request” may be transmitted either as a broadcast / multicast message to all eligible backup nodes or as parallel unicast requests to each backup node. The backup nodes may then coordinate via a cluster manager, consensus algorithm, or internal priority rules to determine which node assumes the role of the new primary. This allows flexible handling of multi-node availability while ensuring fault-tolerant continuity of service.

[0100] The at least one backup node is configured to cooperate with the at least one high availability state manager (HSM) to receive the at least one switchover request. The cooperation may include establishing and maintaining a persistent communication channel between the at least one backup node and the at least one HSM to ensure that state-change notifications, including switchover requests, are reliably transmitted and received in real time. Upon detecting a triggering condition (e.g., active node failure, database unavailability, loss of heartbeat signals, orbreach of performance thresholds), the HSM generates the switchover request. The backup node receives the switchover request through its designated HSM interface module, which is a software or firmware component responsible for listening to a HSM communication channel.

[0101] The at least one backup node is configured to determine an availability of at least one database (210) associated with the at least one backup node. For example, the standby node is configured to determine the availability of the first database associated with the standby node. In an exemplary embodiment, upon receiving a request to verify database availability, the backup node (e.g., the standby node) initiates a connectivity verification process with the database (210) linked to the corresponding backup node. The connectivity verification process may include, but is not limited to, performing a network reachability check, such as issuing an internet control message protocol (ICMP) echo request or transmission control protocol (TCP) handshake to a database endpoint; initiating an authentication procedure with the database (210) using preconfigured credentials to validate access permissions; and / or executing one or more diagnostic or test queries to confirm that the database (210) is capable of responding to operational requests within a predefined latency threshold. In certain embodiments, the backup node may log and timestamp each stage of the connectivity verification to facilitate fault diagnostics and historical analysis. For instance, if the first database responds successfully to a simple “SELECT 1” query within an acceptable response time (e.g., less than 100 milliseconds), the backup node may determine that the first database is available and operational.

[0102] Upon confirming the availability status of the database (210) associated with the backup node, the backup node is configured to transmit a notification to the failover control module (216). In one embodiment, the notification is generated as a structured message (e.g., JavaScript object notation (JSON), extensible markup language (XML), or protocol-specific signaling packet) containing identifiers of the backup node, current health metrics (e.g., database uptime, query latency, connection health score), and a confirmation flag indicating readiness to assume active operations. The notification may be transmitted over a secure communication channel, such as transport layer security (TLS) over TCP / IP, to ensure integrity and authenticity.

[0103] Upon receiving the notification from the backup node, the failover control module (216) may be configured to validate an authenticity and freshness of received information (e.g., by checking digital signatures ortimestamps) to avoid stale or spoofed failover triggers. If the notification meets a predetermined switchover criteria (such as database availability >= 99%, connectivity latency <=50 ms, and absence of unresolved errors), the failover control module (216) initiates an automatic switchover process.

[0104] The switchover process includes updating at least one attribute of the backup node in a central state registry. In one example, a “role” attribute of the backup node is updated from STANDBY to PRIMARY, while the role of the previously active node is changed from PRIMARY to STANDBY or OFFLINE. This update may be propagated to dependent system components (e.g., load balancers, application servers, DNS resolvers) so that subsequent client requests are routed to the newly activated backup node without manual intervention. In addition to the role attribute, other attributes may also be updated, such as the database’s active IP address or virtual IP (VIP) binding, replication status (e.g., switching from read-only replica to read-write mode), and synchronization metadata (e.g., last replicated transaction ID). These updates ensure that the backup node is promoted to a fully functional primary database node, capable of handling both read and write transactions. The update may be propagated to dependent system components (e.g.,load balancers, application servers, DNS resolvers) so that subsequent client requests are routed to the newly activated backup node without manual intervention. For instance, in one scenario, the standby node’s role changes from “standby” to “primary,” its replication mode switches from follower to leader, and its network endpoint is advertised to the system components to reflect its new operational status.

[0105] In an exemplary embodiment, instead of waiting for the failover control module (216) to initiate the switchover process, the backup node itself may proactively transmit the switchover request to a state manager (i.e., HSM) assigned for the corresponding backup node. This switchover request may be triggered when the backup node detects that the primary node has become unresponsive beyond a defined threshold (e.g., heartbeat timeout of 5 seconds) and the database (210) associated with the backup node is confirmed to be operational.

[0106] In an embodiment, the switchover request may include a node’s readiness state, a last synchronization timestamp with primary node’s database, and a proposed transition command (e.g., “ASSUME PRIMARY ROLE”). The state manager, upon verifying a legitimacy of the switchover request (for instance, ensuring that requesting backup node’s database is fully synchronized and consistent), initiates a role transition procedure. The transition may include, but not limited to, role update in cluster metadata, routing table / domain name system (DNS) update. For example, in a cloud-based financial transaction system, if a primary database node located in data center A experiences a network outage, a backup node in data center B detects the outage, verifies that its replica database is fully synchronized, and sends a switchover request to the state manager. In an embodiment, synchronization between the primary database and one or more backup databases may be implemented using synchronous replication, asynchronous replication, or a semi-synchronous hybrid approach, depending on performance and consistency requirements. In synchronous replication, every transaction committed on the primary node is simultaneously committed on the backup node before acknowledging success to the client, thereby ensuring zero dataloss at the cost of additional latency. In asynchronous replication, transactions are first committed on the primary node and then propagated to the backup nodes with minimal impact on transaction latency; however, this may introduce a replication lag that creates a small window of potential data loss if a failure occurs. In semi- synchronous replication, the primary node waits for at least one backup node to acknowledge receipt of a transaction before confirming commit, thereby balancing latency and durability. To address time lag or latency concerns, the monitoring module (212) and state manager may maintain and evaluate the last synchronization timestamp of each backup node and apply predefined thresholds to determine eligibility for promotion. A backup node that does not meet synchronization freshness criteria is excluded from switchover, thereby ensuring that only a sufficiently up-to-date replica can be promoted to primary without compromising data integrity. The state manager validates the request, updates a cluster state so that the data center B is now the primary, and redirects all payment processing traffic to it within seconds, thereby maintaining uninterrupted service.

[0107] In another embodiment, upon determining that the at least one database (210) associated with the standby node is unavailable, the standby node is configured to transmit a second request towards the spare node. In an embodiment, the second request is the switchover request transmitted from the standby node to the spare node via a second switchover channel. For instance, when the standby node executes its periodic health check or heartbeat monitoring routine for its associated first database, the standby node may detect one or more failure indicators, such as an inability to establish a database connection, missing or corrupted data files, abnormal response latency exceeding a predefined threshold, receipt of explicit error codes from a database engine, and so forth. Upon detection of such conditions, the standby node constructs the second request. In some scenarios, the standby node may be unable to immediately take over as the primary node because it either lacks an up-to-date replicated dataset, has insufficient resources to handle the expected traffic load, or is itself in a degraded operational state. In such cases, the responsibility is escalated to the spare node, which isprovisioned as an additional failover resource with synchronized replication and sufficient capacity to assume the primary role. If both the standby and spare nodes are unavailable, the system may trigger higher-level recovery procedures, such as rerouting traffic to a disaster recovery site or invoking administrative intervention. For example, if the standby node detects that its replication lag exceeds a predefined threshold, indicating stale or incomplete data, it may forward the switchover request to the spare node to ensure that client connections are maintained with minimal disruption.

[0108] For example, if the database status at the standby node is determined to be unavailable, inaccessible, or otherwise non-operational, the standby node constructs a secondary failover request that includes an indication of the database unavailability. The standby node then transmits this request to at least one spare instance within a cluster, enabling the spare instance to perform a subsequent availability determination for its associated database (i.e., a second database) and, if deemed operational, initiate a takeover of the active role. As part of this process, the spare node is configured e.g., through predefined policies, configuration files, or orchestration scripts) to check the operational status and connectivity of the second database before proceeding. The configuration may include rules or scripts that define the sequence of checks to be performed, such as validating database connectivity, replication lag, or transaction integrity. These checks may be implemented using built-in health-check agents, periodic polling routines, or event- driven triggers that are automatically executed when a switchover request is received. Upon confirming proper availability, the spare node may transmit a request to a HSM to authorize and trigger the transition from the spare node to the active role.

[0109] Prior to initiating the switchover, the spare node is configured to determine a number of active replication channels between the primary node, the standby node, and the spare node. The spare node may determine the number of replication channels by reading channel configuration data or real-time replication status information from the memory (204).

[0110] In an embodiment, if the number of replication channels is equal to one, the spare node proceeds directly to initiate the switchover from the spare node to the active role, provided that the associated geo-distributed database (second database) associated with the spare node is in a proper operational state and database connectivity is intact. In such an embodiment, the switchover is executed immediately upon receipt of the switchover request from the failure detection module (214) without waiting for a confirmation or second request from the standby node.

[0111] In another embodiment, if the number of replication channels is greater than one (e.g., two channels), the spare node is configured to wait until both the switchover request from the failure detection module (214) and the second request from the standby node are received. Upon receiving both requests, the spare node is configured to record timestamps for each reception event using an internal high- precision clock or timer module (e.g., T1 for the switchover request, T2 for the second request). The spare node is further configured to determine a time interval between the requests by computing an absolute difference between T1 and T2. The spare node is configured to compare the determined time interval with a configurable time interval stored in the memory (204) (e.g., 10 seconds). If the determined time interval is less than the configurable time interval and a geo DB (i.e., second database) status associated with the spare node is proper with connectivity intact, the spare node is configured to transmit the switchover request to the failover control module (216). The failover control module (216) is configured to initiate the switchover from a local database (first database) to the geo DB, thereby transitioning the spare node into a “spare-active” state to serve network traffic. In another embodiment, if the determined time interval exceeds the configurable time interval or the geo DB status is improper, the primary node remains active, and the switchover request is discarded to avoid unnecessary or redundant failover operations. In some embodiments, the configurable time interval may be set or adjusted by a network administrator, an orchestration or management console, or automatically by the failure detection module (214) based on predefinedpolicies. The predefined policies may include conditions derived from service level agreements (SLAs), redundancy requirements, or workload criticality. The configurable time interval may further be dynamically tuned in response to observed system conditions such as network latency, replication delays across the channels, or historical failover events. The choice of the configurable time interval impacts the failover process: a shorter interval allows the spare node to trigger switchover rapidly, thereby reducing downtime but with an increased risk of false failover in cases of transient channel delays; whereas a longer interval avoids false triggers during temporary replication lag but may increase recovery time in the event of an actual failure. For example, in a geo-redundant BSF deployment requiring stringent availability, the configurable time interval may be set to 100 milliseconds to ensure immediate failover, while in a batch-oriented NF replication scenario the interval may be extended to several seconds to balance stability and availability.

[0112] FIG. 3 illustrates an exemplary system architecture (300) for performing the automatic switchover to the at least one backup node (304) on detection of the database failure in the network (108), in accordance with embodiments of the present disclosure.

[0113] FIG. 3 with reference to FIG. 1 and FIG. 2, illustrates the system architecture (300) that may include one or more high availability state managers (HSMs) (302A, 302B, 302C), one or more nodes (304A, 304B, 304C) and one or more databases (210A, 210B). The one or more HSMs (302A, 302B, 302C) may be coupled to the one or more nodes (304A, 304B, 304C). The one or more nodes (304A, 304B, 304C) may be coupled to the one or more databases (210A, 210B). The HSMs (302A, 302B, 302C) are configured to ensure continuous operation and reliability of network systems by managing and orchestrating a state of the NFs (304A, 304B, 304C). The HSMs (302A, 302B, 302C) monitor the health and status of the nodes (304A, 304B, 304C) and the databases (210A, 210B), coordinate failover processes by determining when to switch between a primary node (304A), a standby node (304B), and a spare node (304C), and ensure synchronization acrossNFs. In an embodiment, the primary node (304A), the standby node (304B) and the spare node (304C) corresponds to an active NF, a standby NF and a spare NF.

[0114] The HSMs (302A, 302B, 302C) automate the recovery process to minimize downtime and human error, maintain detailed logs for analysis and troubleshooting, and make informed decisions based on real-time data to maintain high availability and system stability. In an embodiment, the system may include a data integrity mechanism to ensure that no committed transaction is lost and no partially executed transaction is promoted during failover. This may be achieved by using transaction logging techniques, such as write-ahead logs or redo / undo records, in which all operations are first recorded in a durable log before being applied to the database. During failover, the backup node applies any pending log entries so that its state is brought to a consistent point before assuming the role of the primary. To manage unprocessed or in-flight data, the system may temporarily buffer incoming client requests in a queue until the switchover is complete, and then replay those requests against the new primary. In some cases, techniques such as idempotent transaction processing or two-phase commit protocols may be used to avoid duplicate execution or partial completion of transactions during the transition.

[0115] The system may further implement fault detection and recovery protocols that define how failures are identified, classified, and resolved. Fault detection may involve continuous monitoring of system health parameters, heartbeat exchanges, or threshold-based anomaly detection. Recovery protocols may specify a series of actions, such as confirming the occurrence of the fault, selecting an eligible backup node, validating synchronization status, and then promoting the backup node to primary role. These protocols are designed to ensure that failover occurs in a controlled and predictable manner, thereby maintaining service availability and preserving data consistency.

[0116] In an aspect, the one or more HSMs (302A, 302B, 302C) may include an active HSM (302A), a standby HSM (302B) and a spare HSM (302C). The activeHSM (302A) may be coupled with the primary node (304A). Similarly, the standby HSM (302B) and the spare HSM (302C) are coupled with the standby node (304B) and the spare node (304C), respectively. The HSMs (302A, 302B, 302C) may be managing the high availability of the nodes (304A, 304B, 304C). For example, managing includes a failover management, a health monitoring and a state synchronization. The HSMs (302A, 302B, 302C) may continuously monitor a status ofthe nodes (304A, 304B, 304C). For example, the status of the nodes (304A, 304B, 304C) may include active and inactive. The active HSM (302A) may monitor the status of the primary node (304A). The primary node (304A) may be configured to handle active network tasks. The standby node (304B) may be configured to remain in a standby state, ready to take over if the primary node (304A) fails or requires maintenance. The spare node (304C) may be configured to serve as an additional backup resource, which may be activated in response to specific conditions or demands to ensure continuous network service and reliability.

[0117] In an aspect, the system architecture (300) includes a primary site (306A) and a redundant site (306B). The primary site (306A) refers to a main operational location where core components of the system (102) are actively running and performing their designated functions. The primary site (306A) is a central hub of a network infrastructure where most of the critical activities take place. The primary site (306A) includes the active HSM (302A), the standby HSM (302B), the primary node (304A), the standby node (304B) and the first database (210A). The primary node (304 A) and the standby node (304B) may be communicatively coupled with the first database (210A). The active HSM (302A) oversees the real-time management and coordination of network functions and failover processes. The active HSM (302A) is coupled to the primary node (304A). The primary node (304A) performs primary processing tasks and handles all incoming network traffic and requests. It is directly communicatively coupled with the first database (210A) and relies on the first database (210A) for operational data.

[0118] The standby HSM (302B) remains ready, prepared to take over the responsibilities of the active HSM (302A) if it fails or becomes unavailable. Thestandby node (304B) is a backup to the primary node (304A). The standby node (304B) remains synchronized with the primary node (304A), ensuring that the standby node (304B) has up-to-date data and configurations. If the primary node (304A) fails, the standby node (304B) may take over its role, ensuring that service continuity is maintained. In an embodiment, a setup of the primary site (306A) ensures that the system (102) can effectively manage operations, handle failovers, and maintain high availability.

[0119] The redundant site (306B) in the network architecture serves as a backup location that ensures continuity and resilience of services in case the primary site (306A) encounters issues. The redundant site (306B) is designed to provide high availability and disaster recovery capabilities by duplicating critical components and functionalities. The redundant site (306B) may include the spare HSM (302C), the spare node (304C) and the second database (210B). The spare node (304C) may be communicatively coupled with the second database (21 OB). The redundant site (306B) includes one or more backup nodes (304) in an automatic switchover process of the database (210A or 21 OB).

[0120] FIG. 4 illustrates an exemplary flow diagram representing a process (400) of the automatic switchover to the at least one backup node (304) on detection of the database failure in the network (108), in accordance with embodiments of the present disclosure.

[0121] At step (402), the process (400) includes operating the primary node (304 A) to serve client requests. The primary node (304 A) may may monitor the health parameters of the first database (210A). The primary node (304A) may conduct a health check for the first database (210A). In an aspect, the health parameters may include, but not limited to, the database connectivity, the replication status, the backup status, the query performance, and the transaction performance. The health parameters are monitored to ensure up-to-date operations of the first database (210A). For example, the database connectivity may include an active state, an inactive state and a disconnected state. In an embodiment, the activestate may indicate live, ongoing connection between the nodes (304A, 304B, 304C) and the database (210). An idle status of the database (210) may be the inactive state. The disconnected state represents a lost connection between the nodes (304A, 304B, 304C) and the database (210).

[0122] At step (404), the process (400) includes determining, by the primary node (304A), whether the first database (210A) associated with the primary node (304 A) is available or not based on the monitored health parameters of the first database (210A). In this step, the primary node (304 A) may perform an automatic switchover to the one or more backup nodes (304) if the first database (210A) is not available due to any technical issues. The one or more backup nodes (304) may be the standby node (304B) or the spare node (304C). In an aspect, the data connectivity parameters are monitored to perform the switchover from the primary node (304A) to the one or more backup nodes (304). For example, if the first database (210A) connectivity is active, then the primary node (304A) may handle one or more incoming traffic in the network (108). The incoming traffic may include one or more user requests from the UE (104). In another example, if the first database (210A) connectivity is inactive, then the primary node (304A) may perform the automatic switchover to the standby node (304B) or the spare node (304C). If the first database (210A) is not available, the process (400) proceeds to step (406). If the first database (210A) is available, the process (400) continues normal operation without initiating the switchover.

[0123] At step (406), the process (400) includes initiating replication of information about the first database (210A) associated with the primary node (304A) to the standby node (304B).

[0124] At step (408), the process (400) includes triggering, by the primary node (304A), one or more second requests (a second switchover request) for replicating the information about the first database (210A) associated with the primary node (304A) to the spare node (304C). In an embodiment, the one or more requests to the standby node (304B) and the spare node (304C) are sent simultaneously fromthe primary node (304A). In another embodiment, the second request to the spare node (304C) may be transmitted if the number of backup nodes (304) for the switchover is 1. In an aspect, the one or more requests may include a data transmission request, a communication request, a backup request, and a replication request. For example, the replication request includes copying and synchronization data between a primary (first database (210A)) and a replica (second database (21 OB)).

[0125] In an aspect, the one or more requests may include one or more essential parameters. For example, the essential parameters may include a database identifier, a replication type, a replication method, a log file, and so forth. In another aspect, the primary node (304A) may set a flag value based on the database connectivity status and may monitor the flag value to determine whether to perform an automatic switchover to the one or more backup nodes (304). For example, the flag value may be set to “TRUE” to indicate an active connection. The primary node (304A) may monitor the replication of information from the first database (210A) through the first switchover channel (i.e, switchover A channel), which ensures that the transition of database roles is managed in high-availability configurations. For instance, the first switchover channel may facilitate the transition of the first database (210A) associated with the primary node (304A) to the second database (210B) associated with the spare node (304C) via the primary node (304A) to the standby node (304B) or the spare node (304C).

[0126] At step (410), the process (400) includes determining, by the standby node (304B), whether its associated first database (210A) is available by exchanging a number of signals with the first database (210A). If the first database (210A) of the standby node (304B) is available, the process (400) proceeds to step (412). If the first database (210A) of the standby node (304B) is not available, the process (400) proceeds to step (414).

[0127] At step (412), the process (400) includes transmitting, by the standby node (304B), a request to the HSM to perform a switchover of the standby node(304B) to the active role. The HSM may be the standby HSM (302B). For example, the standby HSM (302B) may initiate the switchover by assigning the standby node (304B) as the primary node (304A).

[0128] At step (414), the process (400) includes replicating the first database (210A) information by the standby node (304B) to the spare node (304C) over the second switchover channel (i.e., switchover HS channel). The second switchover channel may manage the high-availability configurations of the database switchover. For example, the second switchover channel may facilitate the transition of the first database (210A) to the second database (21 OB) via the standby node (304B) to the spare node (304C).

[0129] At step (416), the process (400) includes receiving, at the spare node (304C), both a first switchover message and a second switchover message within a predefined time interval. The reception of the first switchover message and the second switchover message triggers a verification of database availability for the spare node (304C). In one example, the spare node (304C) may receive one or more requests for replicating the information from the first database (210A). The spare node (304C) may check a source of each request by examining a replication channel, which may include the first switchover channel (e.g., from the primary node (304A) to the spare node (304C)) or a second switchover channel (e.g., from the standby node (304B) to the spare node (304C)). For example, if only one replication channel exists, the request may be determined to have originated from the primary node (304A), in which case the spare node (304C) may perform the switchover process without waiting for the second request.

[0130] In another example, if two requests are expected but only one request has been received, the spare node (304C) may wait for the second request. The first request may be received via the first switchover channel from the primary node (304 A) to the spare node (304C), and the second request may be received via the second switchover channel from the standby node (304B) to the spare node (304C). Upon receiving the second request, and if both replication channels remain active,it may be determined that both the primary node (304A) and the standby node (304B) are unavailable. The spare node (304C) may determine the time interval between the requests from the primary node (304A) and the standby node (304B), which may be calculated as the time difference between the first request and the second request. If the time interval is less than the configurable time interval (e.g., one second, one minute, one hour, or, for example, 100 minutes), the spare node (304C) may proceed to perform the automatic switchover as in step (420). The configurable time interval may be predefined during initialization of the switchover process. If the time interval exceeds the configurable time interval, the spare node (304C) may determine that the switchover has already occurred and may drop the switchover process as in step (422).

[0131] At step (418), the process (400) includes determining whether the second database (210B) associated with the spare node (304C) is available. If the second database (210B) is available, the process (400) proceeds to step (420). If the second database (210B) is not available, the process (400) proceeds to step (422).

[0132] At step (420), the process (400) includes transmitting a request to the HSM to perform the switchover process from the first database (210A) to the second database (210B), thereby promoting the spare node (304C) to the active role .

[0133] At step (422), the process (400) includes maintaining the currently primary node (304A) in the active role without performing the switchover.

[0134] FIG. 5 illustrates an exemplary flowchart of a method (500) for performing the automatic switchover to the at least one backup node (304) on the database failure in the network (108). FIG. 5, with reference to FIG. 1, FIG. 2, FIG.3, and FIG. 4, illustrates the method (500) for performing the automatic switchover to the at least one backup node (304) by using the processing engine (208) of the system (102).

[0135] At step (502), the method (500) includes monitoring, by the processing engine (208), the health parameters of the first database (210A) associated with theprimary node (304A). The health parameters include the database connectivity, the database query responsiveness, and the database backup status.

[0136] At step (504), the method (500) includes detecting, by the processing engine (208), the failure of the first database (210A) based on the monitored health parameters.

[0137] At step (506), the method (500) includes communicating, by the processing engine (208), the at least one switchover request towards all backup nodes (304). In an embodiment, before communicating the switchover request to all backup nodes (304), the processing engine (208) determines the number of backup nodes (304) available for the switchover. If the number of backup nodes for the switchover is one, the processing engine (208) switchovers directly to the spare node (304C).

[0138] At step (508), the method (500) includes determining, by the at least one backup node (304), the availability of at least one database (210) associated with the at least one backup node (304). In an embodiment, the at least one backup node (304) includes the standby node (304B) and the spare node (304C).

[0139] At step (510), the method (500) includes notifying, by the at least one backup node (304), the processing engine (208) on determining the availability of the at least one database (210) by sending the notification.

[0140] At step (512), the method (500) includes on receiving the notification from the at least one backup node (304), performing, by the processing engine (208), the automatic switchover to the at least one backup node (304) by updating the at least one attribute associated with the at least one backup node (304) based on the at least one switchover request. The at least one attribute includes a role of the at least one backup node (304).

[0141] In an embodiment, the method (500) includes sending, by the standby node (304B), the second request towards the spare node (304C) upon determining that the at least one database (210) associated with the standby node (304B) isunavailable. The spare node (304C) is configured to receive the at least one switchover request from the processing engine (208) and the second request from the standby node (304B). The spare node (304C) further determines the time interval between the reception of the at least one switchover request and the second request. The spare node (304C) further compares the determined time interval with the configurable time interval. The spare node (304C) further transmits the at least one switchover notification to the processing engine (208) if the determined time interval is less than the configurable time interval.

[0142] FIG. 6 illustrates an exemplary computer system (600) in which, or with which, the system (102) and the method (500) of the present disclosure may be implemented. As shown in FIG. 6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read-only memory (640), a mass storage device (650), a communication port (660), and a processor (670) . A person skilled in the art will appreciate that the computer system (600) may include more than one processor (670) and the communication ports (660). The processor (670) may include various modules associated with embodiments of the present disclosure.

[0143] In an embodiment, the external storage device (610) may be any device that is commonly known in the art, such as, but not limited to, a memory card, a memory stick, a solid-state drive, a hard disk drive (HDD), and so forth.

[0144] In an embodiment, the bus (620) may be communicatively coupled with the processor(s) (670) with the other memory, storage, and communication blocks. The bus (620) may be, e.g., a peripheral component interconnect (PCI) / PCI Extended (PCI-X) bus, a small computer system interface (SCSI), a universal serial bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (670) to the computer system (600).

[0145] In an embodiment, the main memory (630) may be a random-access memory (RAM), or any other dynamic storage device commonly known in the art.The Read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor (670).

[0146] In an embodiment, the mass storage device (650) may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, a parallel advanced technology attachment (PATA) or a serial advanced technology attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having universal serial bus (USB) and / or Firewire interfaces), one or more optical discs, redundant array of independent disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).

[0147] Further, the communication port (660) may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port (660) may be chosen depending on the network (108), such a local area network (LAN), wide area network (WAN), or any network to which the computer system (600) connects.

[0148] Optionally, operator and administrative interfaces, e.g., a display, a keyboard, a joystick, and a cursor control device, may also be coupled to the bus (620) to support a direct operator interaction with the computer system (600). Other operator and administrative interfaces may be provided through network connections connected through the communication port (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.

[0149] The exemplary computer system (600) is configured to execute a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause theone or more processors to perform a method for performing automatic switchover to at least one backup node on a database failure in a network. The method includes monitoring, by a processing engine, a plurality of health parameters of a first database associated with a primary node. The method includes detecting, by the processing engine, a failure of the first database based on the monitored plurality of health parameters. The method includes communicating, by the processing engine, at least one switchover request towards all backup nodes. The method also includes determining, by the at least one backup node, an availability of at least one database associated with the at least one backup node. The method also includes notifying, by the at least one backup node, the processing engine on determining the availability of the at least one database by sending a notification. The method also includes on receiving the notification from the at least one backup node, performing, by the processing engine, an automatic switchover to the at least one backup node by updating at least one attribute associated with the at least one backup node based on the at least one switchover request.

[0150] In an exemplary embodiment, a user equipment communicatively coupled with a network is disclosed. The coupling includes receiving, by the network, a connection request from the user equipment. The coupling further includes sending, by the network, an acknowledgment of the connection request to the user equipment. The coupling further includes transmitting a plurality of signals in response to the connection request. An automatic switchover to at least one backup node on detection of database failure is performed by a system. To ensure service continuity, the switchover process is designed to minimize disruption to the user’s ongoing sessions. For example, session persistence mechanisms such as state replication, sticky sessions, or session rehydration from the database backup may be employed to allow the user equipment to continue communication seamlessly without requiring a fresh re-login or call setup. In this manner, the failover handling system not only restores backend functionality but also manages reconnection and session persistence to preserve the end-user experience during failover scenarios. The system includes at least one high-availability state manager (HSM). The at leastone HSM further includes a memory. The at least one HSM further includes a processing engine coupled to the memory and is configured to execute instructions stored in the memory to monitor a plurality of health parameters of a first database associated with a primary node. The processing engine is further configured to detect a failure of the first database based on the monitored plurality of health parameters. The processing engine is further configured to communicate at least one switchover request towards all backup nodes. The at least one HSM further includes the at least one backup node is configured to cooperate with the at least one HSM to receive the at least one switchover request. The at least one backup node is configured to: determine an availability of at least one database associated with the at least one backup node. The at least one backup node is further configured to: notify the processing engine on determining the availability of the at least one database by sending a notification. On receiving the notification from the at least one backup node, the processing engine is configured to perform an automatic switchover to the at least one backup node by updating at least one attribute associated with the at least one backup node based on the at least one switchover request.

[0151] The present disclosure provides a technical advancement in the field of high-availability management for database -dependent network functions in telecommunication networks by introducing an automated, role-aware switchover mechanism that operates upon detection of database failure without requiring manual intervention. Database-dependent network functions refers to network functions within a telecommunication system that rely on continuous access to a backend database in order to perform their control-plane or user-plane operations. Examples include functions such as the Home Subscriber Server (HSS), Unified Data Management (UDM), Policy Control Function (PCF), Authentication Server Function (AUSF), Charging Function (CHF), and other core functions that store, retrieve, or update subscriber data, session state, authentication vectors, charging records, or policy rules. These functions cannot operate correctly if the associated database becomes unavailable, since their decision-making and service deliverydirectly depend on timely database access. This advancement is achieved through a high-availability state manager (HSM) and a processing engine configured to continuously monitor multiple database health parameters, including database connectivity, query responsiveness, and backup status, associated with an active network function instance, such as a Binding Support Function (BSF). Upon detecting a database failure, the processing engine transmits switchover requests to all backup nodes, including standby and spare instances, which independently verify their own database availability. The standby node, if found healthy, requests promotion to active status; otherwise, it forwards the request to the spare node. The spare node evaluates the timeliness of the received requests using a configurable time interval and, if healthy, promotes itself to active status to serve network traffic. This hierarchical and coordinated backup node promotion ensures uninterrupted service continuity, minimizes downtime, and maintains user experience even during database outages. By integrating real-time database health monitoring, distributed decision-making, and automated role reassignment across clustered network function instances, the invention overcomes existing limitations of manual recovery and non-database-aware failover mechanisms, thereby enhancing operational resilience in next-generation telecommunication networks.

[0152] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.TECHNICAL ADVANTAGES OF THE PRESENT DISCLOSURE

[0153] As is evident from above, the present disclosure described herein above has several technical advantages including:• enabling automatic switchover to one or more backup nodes during database failure, thereby reducing service downtime and ensuring uninterrupted network operation.• performing continuous and automated database health checks in the network, thus enabling proactive detection of failures without manual intervention.• determining switchover decisions based on real-time database health, ensuring that only backup nodes with confirmed database availability are promoted to active status. • maintaining high availability and reliability of network function (NF) instances during database outages, thereby improving service resilience and user experience.• enabling tracking of automatic switchover progression through a comprehensive logging mechanism, thereby facilitating troubleshooting, audit compliance, and operational transparency.

Claims

CLAIMS1. A method (500) for performing automatic switchover to at least one backup node (304) on detection of database failure in a network (108), the method (500) comprising: monitoring, by a processing engine (208), a plurality of health parameters of a first database (210A) associated with a primary node (304A); detecting, by the processing engine (208), a failure of the first database (210A) based on the monitored plurality of health parameters; communicating, by the processing engine (208), at least one switchover request towards all backup nodes (304); determining, by the at least one backup node (304), an availability of at least one database (210) associated with the at least one backup node (304); notifying, by the at least one backup node (304), the processing engine (208) on determining the availability of the at least one database (210) by sending a notification; and on receiving the notification from the at least one backup node (304), performing, by the processing engine (208), an automatic switchover to the at least one backup node (304) by updating at least one attribute associated with the at least one backup node (304) based on the at least one switchover request.

2. The method (500) as claimed in claim 1, wherein the at least one backup node (304) comprises a standby node (304B) and a spare node (304C).

3. The method (500) as claimed in claim 1, wherein the at least one attribute includes a role of the at least one backup node (304).

4. The method (500) as claimed in claim 1, wherein the plurality of health parameters comprises a database connectivity, a database query responsiveness, and a database backup status.

5. The method (500) as claimed in claim 2, further comprising: sending, by the standby node (304B), a second request towards the spare node (304C) upon determining that the at least one database (210) associated with the standby node (304B) is unavailable.

6. The method (500) as claimed in claim 5, wherein the spare node (304C) is configured to perform a set of steps comprising: receiving, by the spare node (304C), the at least one switchover request from the processing engine (208) and the second request from the standby node (304B); determining, by the spare node (304C), a time interval between the reception of the at least one switchover request and the second request; comparing, by the spare node (304C), the determined time interval with a configurable time interval; and transmitting, by the spare node (304C), at least one switchover notification to the processing engine (208)if the determined time interval is less than the configurable time interval.

7. The method (500) as claimed in claim 1, wherein the processing engine (208) determines a number of backup nodes (304) available for switchover; and if the number of backup nodes (304) for switchover is one, the processing engine (208) switchovers directly to a spare node (304C).

8. A system (102) for implementing automatic switchover to at least one backup node (304) on adatabase failure in anetwork (108), the system (102) comprising:at least one high-availability state manager (HSM) (302), wherein the at least one HSM (302) further comprises: a memory (204); a processing engine (208) coupled to the memory (204) and is configured to execute instructions stored in the memory (204) to: monitor a plurality of health parameters of a first database (210A) associated with a primary node (304A); detect a failure of the first database (210A) based on the monitored plurality of health parameters; communicate at least one switchover request towards all backup nodes (304); the at least one backup node (304) is configured to cooperate with the at least one HSM (302) to receive the at least one switchover request and is configured to: determine an availability of at least one database (210) associated with the at least one backup node (304); and notify the processing engine (208) on determining the availability of the at least one database (210) by sending a notification; and on receiving the notification from the at least one backup node (304), the processing engine (208) is configured to perform an automatic switchover to the at least one backup node (304) by updating at least one attribute associated with the at least one backup node (304) based on the at least one switchover request.

9. The system (102) as claimed in claim 8, wherein the at least one backup node (304) comprises a standby node (304B) and a spare node (304C).

10. The system (102) as claimed in claim 8, wherein the at least one attribute includes a role of the at least one backup node (304).

11. The system (102) as claimed in claim 8, wherein the plurality of health parameters comprises a database connectivity, a database query responsiveness, and a database backup status.

12. The system (102) as claimed in claim 9, wherein the standby node (304B) is configured to: send a second request towards the spare node (304C) upon determining that the at least one database (210) associated with the standby node (304B) is unavailable.

13. The system (102) as claimed in claim 12, wherein the spare node (304C) is configured to: receive the at least one switchover request from the processing engine (208) and the second request from the standby node (304B); determine a time interval between the reception of the at least one switchover request and the second request; compare the determined time interval with a configurable time interval; and transmit at least one switchover notification to the processing engine (208) if the determined time interval is less than the configurable time interval.

14. The system (102) as claimed in claim 8, wherein the processing engine (208) determines a number of backup nodes (304) available for switchover; and if the number of backup nodes (304) for switchover is one, the processing engine (208) switchovers directly to a spare node (304C).

15. A user equipment (104) communicatively coupled with a network (108), the coupling comprises steps of: receiving, by the network (108), a connection request from the user equipment (104); sending, by the network (108), an acknowledgment of the connection request to the user equipment (104); and transmitting a plurality of signals in response to the connection request, wherein performing automatic switchover to at least one backup node (304) on detection of database failure is performed by a system (102) as claimed in claim 8.

16. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method (500) for performing automatic switchover to at least one backup node (304) on a database failure in a network (108), the method (500) comprising: monitoring, by a processing engine (208), a plurality of health parameters of a first database (210A) associated with a primary node (304A); detecting, by the processing engine (208), a failure of the first database (210A) based on the monitored plurality of health parameters; communicating, by the processing engine (208), at least one switchover request towards all backup nodes (304); determining, by the at least one backup node (304), an availability of at least one database (210) associated with the at least one backup node (304); notifying, by the at least one backup node (304), the processing engine (208) on determining the availability of the at least one database (210) by sending a notification; andon receiving the notification from the at least one backup node (304), performing, by the processing engine (208), an automatic switchover to the at least one backup node (304) by updating at least one attribute associated with the at least one backup node (304) based on the at least one switchover request.

Images