WO2025017685A1

WO2025017685A1 - Method and system for synchronizing account information between primary site and disaster recovery site

Info

Publication number: WO2025017685A1
Application number: PCT/IN2024/051252
Authority: WO
Inventors: Vikash Agrawal; Aayush Bhatnagar; Dinesh Kumar YADAV
Original assignee: Jio Platforms Ltd
Current assignee: Jio Platforms Ltd
Priority date: 2023-07-17
Filing date: 2024-07-15
Publication date: 2025-01-23
Anticipated expiration: 2026-01-17

Abstract

The present disclosure relates to a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site The method includes receiving, via a front-end module [304] at the primary site, an account modification request from an originating management system, storing a set of data associated with the received account modification request in a first database [206], and continuously monitoring the first database [206] for the set of data to process the account modification request by processor [208]. The method further includes transmitting the set of data associated with the account modification request from the primary synchronization application to a DR synchronization application via a communication channel. The method further includes storing the set of data associated with the account modification request into a second database [212] for processing and synchronization at DR site.

Description

METHOD AND SYSTEM FOR SYNCHRONIZING ACCOUNT INFORMATION BETWEEN PRIMARY SITE AND DISASTER RECOVERY SITE

FIELD OF INVENTION

[0001] The present disclosure relates generally to the field of wireless communication systems. More particularly, the present disclosure relates to systems and methods for synchronisation of account information between primary site and disaster recovery (DR) site.

BACKGROUND

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

[0003] Wireless communication technology has rapidly evolved over the past few decades, with each generation bringing significant improvements and advancements. The first generation of wireless communication technology was based on analog technology and offered only voice services. However, with the advent of the second-generation (2G) technology, digital communication and data services became possible, and text messaging was introduced. 3G technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth-generation (4G) technology revolutionized wireless communication with faster data speeds, better network coverage, and improved security. Currently, the fifth-generation (5G) technology is being deployed, promising even faster data speeds, low latency, and the ability to connect multiple devices simultaneously. With each generation, wireless communication technology has become more advanced, sophisticated, and capable of delivering more services to its users.

[0004] In the current existing solutions, synchronizing account information data adds complexity to the overall system architecture. It requires implementing mechanisms to replicate and keep data consistent between two separate systems (primary and DR sites) and ensuring their consistent state requires additional operational overhead, increasing the complexity of system management. This complexity can make the system more challenging to design, deploy, and maintain. It may also introduce additional points of failure and increase the risk of data inconsistencies or synchronization errors. Also, the existing process of synchronizing account information data between primary and DR sites introduces additional latency. The time it takes to replicate data and ensure consistency can impact system performance, especially for real-time applications or timesensitive operations. The latency introduced by synchronization can result in delays and reduced responsiveness, affecting the overall user experience. Further, for existing techniques synchronization processes are not immune to errors or failures. In scenarios where data corruption occurs at the primary site, the corrupted data can potentially be replicated at the DR sites, rendering the failover ineffective. Further, primary and DR sites require additional network bandwidth and computational resources. The continuous synchronization of data can consume significant resources, impacting the performance and scalability of the system. Organizations need to allocate sufficient resources to support the synchronization process effectively, ensuring that it does not degrade the overall system performance. Further, the existing solution, synchronization of account information data relies on stable and reliable network connectivity between primary and redundant sites. If the network connection experiences disruptions or failures, synchronization may be delayed or disrupted, impacting the failover capabilities. Organizations must have robust networking infrastructure and backup measures in place to ensure continuous synchronization even in the event of network issues.

[0005] Therefore, considering the foregoing discussion, there exists a need to overcome the aforementioned drawbacks. Thus, there exists an imperative need in the art to provide a method and system for synchronisation of account information between primary site and disaster recovery (DR) site.

OBJECTS OF THE INVENTION

[0006] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.

[0007] It is an object of the present disclosure to provide system and method for synchronizing account information between a primary site and a disaster recovery (DR) site.

[0008] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that automates the process of updating account modifications, thereby reducing manual intervention and the risk of human errors.

[0009] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that ensures real-time or near-real-time synchronization, enabling swift response to operational requirements or customer needs.

[0010] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that enhances the reliability of the service by minimizing service disruptions during the failover process from the primary site to the DR site.

[0011] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that simplifies the management of the system by automating the synchronization process, thereby reducing operational overhead and complexity.

[0012] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that supports a seamless failover process by ensuring that the DR site has up-to-date account information, thus maintaining service availability and reliability during primary site outages.

[0013] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that facilitates efficient handling of SMS service account modifications in an IP Multimedia Subsystem (IMS) network, thereby ensuring the integrity and consistency of the service.

[0014] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that utilizes a communication channel for transmitting account modification data, thereby enabling secure and reliable data transfer between the two sites.

[0015] It is yet another object of the present disclosure to provide a system and method for synchronizing account information between a primary site and a disaster recovery (DR) site that employs a synchronization application to monitor and process account modification requests, thereby ensuring efficient and accurate synchronization of account information.

SUMMARY OF THE DISCLOSURE

[0016] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.

[0017] An aspect of the present disclosure relates to a method for synchronizing account information between a primary site and a disaster recovery (DR) site. The method includes receiving, by a receiving unit via a Front-End module of the primary site, an account modification request from an originating management system. Further, the method includes, storing, by a storage unit, a set of data associated with the received account modification request into a first database. The method further encompasses, continuously monitoring, by a processor using a primary site synchronization application, the first database for the set of data to process the account modification request. The method further includes, transmitting, by a transmitting unit, the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel. The method further encompasses storing, by the storage unit via the DR site synchronization application, the set of data associated with the account modification request into a second database for processing and synchronization at the DR site.

[0018] In an aspect of the present disclosure, the method further includes acknowledging, by the processor, the account modification request by sending a success response to the originating management system.

[0019] In an aspect of the present disclosure, the account modification request includes at least one of addition of a new account or deletion of an existing account.

[0020] In an aspect of the present disclosure, the originating management system includes but is not limited to a group consisting of an Element Management System (EMS), a Network Management System (NMS), a Command Line Interface (CLI), a web interface, and an Application Programming Interface (API). [0021] In an aspect of the present disclosure, the account modification request is stored into the first database along with a zone name identifier.

[0022] In an aspect of the present disclosure, the DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.

[0023] In an aspect of the present disclosure, the method further includes processing, by the processor, the account modification request data by an Application to Peer- IP short message gateway (A2P-IPSMGW) module at the primary site upon the set of data associated with the account modification request is stored into the first database.

[0024] In an aspect of the present disclosure includes processing, by the processor, the account modification request data by an A2P-IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database.

[0025] In an aspect of the present disclosure, the account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.

[0026] In an aspect of the present disclosure, the originating management system communicates with the front-end module via a RESTful interface.

[0027] Another aspect of the present disclosure relates to a system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network. The system includes a receiving unit configured to receive, via a front-end module at the primary site, an account modification request from an originating management system. The system further includes a storage unit, configured to store a set of data associated with the received account modification request into a first database. Furthermore, the system includes a processor, configured to continuously monitor, using a primary site sync application, the first database for the set of data to process the account modification request. The system further includes a transmitting unit, configured to transmit the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel. Further, the system includes a storage unit, configured to store, via the DR site synchronization application, the set of data associated with the account modification request into a second database for processing and synchronization at the DR site. [0028] Yet another aspect of the present disclosure relates to a non-transitory computer-readable storage medium storing instructions for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network. The instructions include an executable code which when executed by a processor, may cause the processor to receive an account modification request from an originating management system; store a set of data associated with the received account modification request into a first database; continuously monitor the first database for the set of data to process the account modification request; transmit the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel; and store the set of data associated with the account modification request into a second database for processing and synchronization at the DR site.

BRIEF DESCRIPTION OF DRAWINGS

[0029] 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 disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0030] FIG. 1 illustrates an exemplary architecture for implementing of a system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, in accordance with exemplary embodiments of the present disclosure.

[0031] FIG. 2 illustrates a block diagram of the system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, in accordance with exemplary embodiments of the present disclosure.

[0032] FIG. 3 illustrates an exemplary sequence diagram for synchronizing account information between a primary site and a disaster recovery (DR) site, in accordance with exemplary embodiments of the present disclosure. [0033] FIG. 4 illustrates an exemplary method flow chart for synchronizing account information between a primary site and a disaster recovery (DR) site, in accordance with exemplary embodiments of the present disclosure.

[0034] FIG. 5 illustrates an exemplary block diagram of a computing device upon which an embodiment of the present disclosure may be implemented, in accordance with exemplary embodiments of the present disclosure.

[0035] The foregoing shall be more apparent from the following more detailed description of the disclosure.

DESCRIPTION

[0036] In the following description, for the purposes of explanation, various specific details are set forth in order 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 disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

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

[0038] 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 the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of 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.

[0039] 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 in order to avoid obscuring the embodiments.

[0040] Also, it is noted that individual embodiments may be described as a process which 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.

[0041] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject 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 — in a manner similar to the term “comprising” as an open transition word — without precluding any additional or other elements.

[0042] 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 is capable of receiving 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.

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

[0044] IP Short Message Gateway (IPSMGW) plays a crucial role in modern communication networks by enabling the seamless exchange of short messages over IP protocols. Unlike traditional SMS gateways that rely on circuit-switched networks, IPSMGW leverages the flexibility and efficiency of IP-based communication. By converting Short Message Service (SMS) into IP packets, IPSMGW facilitates the transmission of text messages over the internet or private IP networks. This technology not only enhances the speed and reliability of message delivery but also opens up opportunities for innovative messaging applications and services.

[0045] One of the key advantages of IPSMGW is its ability to bridge the gap between different types of networks. It acts as a bridge between the circuit-switched SMS networks and IP networks, ensuring interoperability between legacy systems and modern IP -based communication platforms. This seamless integration is essential for global communication, allowing users on various networks and devices to exchange messages effortlessly. IPSMGW serves as a vital component in enabling cross-network messaging services, enhancing connectivity and communication experiences for users worldwide. Furthermore, IPSMGW enhances the security and privacy of SMS messages transmitted over IP networks. By employing encryption techniques and secure protocols, IPSMGW ensures that sensitive information remains protected during transmission. This heightened security is crucial, especially in business and enterprise communication, where confidentiality is paramount. IPSMGW's ability to provide a secure channel for SMS messages contributes to the overall integrity of communication networks, instilling confidence in users regarding the confidentiality and privacy of their messages.

[0046] As discussed in background section, in the current existing solutions, synchronizing account information data adds complexity to the overall system architecture. It requires implementing mechanisms to replicate and keep data consistent between two separate systems (primary and DR sites) and ensuring their consistent state requires additional operational overhead, increasing the complexity of system management. This complexity can make the system more challenging to design, deploy, and maintain. It may also introduce additional points of failure and increase the risk of data inconsistencies or synchronization errors. Also, the existing process of synchronizing account information data between primary and DR sites introduces additional latency. The time it takes to replicate data and ensure consistency can impact system performance, especially for real-time applications or time-sensitive operations. The latency introduced by synchronization can result in delays and reduced responsiveness, affecting the overall user experience. Further, for existing techniques synchronization processes are not immune to errors or failures. In scenarios where data corruption occurs at the primary site, the corrupted data can potentially be replicated at the DR sites, rendering the failover ineffective. Further, primary and DR sites require additional network bandwidth and computational resources. The continuous synchronization of data can consume significant resources, impacting the performance and scalability of the system. Organizations need to allocate sufficient resources to support the synchronization process effectively, ensuring that it does not degrade the overall system performance. Further, the existing solution, synchronization of account information data relies on stable and reliable network connectivity between primary and redundant sites. If the network connection experiences disruptions or failures, synchronization may be delayed or disrupted, impacting the failover capabilities. Organizations must have robust networking infrastructure and backup measures in place to ensure continuous synchronization even in the event of network issues.

[0047] To overcome these and other inherent problems in the art, the present disclosure proposes a solution of automating the synchronization process between a primary site and a disaster recovery (DR) site in a communication network. The proposed method and system streamline the process of updating account information, such as adding a new account or deleting an existing account, by automatically replicating changes from the primary site to the DR site. This automation reduces the complexity of the overall system architecture, as it eliminates the need for manual intervention and the associated operational overhead. Furthermore, the present disclosure addresses the issue of latency in synchronization by continuously monitoring the primary site's database for changes and promptly transmitting the relevant data to the DR site. This real-time or near-real-time synchronization ensures that the DR site is always up-to-date, minimizing delays and improving the responsiveness of the system during failover scenarios. To overcome the problem of potential data corruption and synchronization errors, the proposed solution includes a mechanism for acknowledging successful data transmission. The DR synchronization application sends an acknowledgment response upon successfully receiving the account modification request data, ensuring the integrity of the data replicated at the DR site. Regarding resource consumption, the present disclosure introduces an efficient synchronization mechanism that reduces the need for excessive network bandwidth and computational resources. By optimizing the data transmission process and employing a selective synchronization approach, the system ensures that only necessary data is replicated, thereby minimizing the impact on system performance and scalability. Lastly, the solution addresses the issue of network dependency by employing a robust communication channel for data transmission. The use of a reliable communication channel, such as an HTTP2 channel, ensures that synchronization can continue even in the face of network disruptions, enhancing the failover capabilities of the system.

[0048] It would be appreciated by the person skilled in the art that the present disclosure offers a comprehensive solution to the problems identified in the existing art by automating and optimizing the synchronization process between primary and DR sites, thereby improving system reliability, performance, and resilience.

[0049] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0050] FIG. 1 illustrates an exemplary architecture [100] for implementing of a system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, in accordance with exemplary implementations of the present disclosure. The architecture [100] comprises A2P-IPSMGW [102] comprising an Element Management System (EMS) [104], a Signalling Transfer Point (STP) [106], a Diameter Routing Agent (DRA) [108], a Home Subscriber Server (HSS) [110], a database 1 [112], a database 2 [114], a Mobile Number Portability Database (MNPDB) [116], and an internal short messaging entity (Internal ESMEs) [118], Also, all of the components/ units of the architecture [100] are assumed to be connected to each other unless otherwise indicated below.

[0051] A2P-IPSMGW (Application to Peer IP Short Message gateway) [102]: Unlike traditional SMS gateways that rely on circuit-switched networks, IPSMGW leverages the flexibility and efficiency of IP-based communication. By converting Short Message Service (SMS) into IP packets, IPSMGW facilitates the transmission of text messages over the internet or private IP networks. This technology not only enhances the speed and reliability of message delivery but also opens up opportunities for innovative messaging applications and services. A2P -IPSMGW is a term used to describe an SMS message sent from a software application (run by an enterprise or business) to a person's phone.

[0052] EMS (Element Management System) [104]: A software system used for managing and monitoring network elements or devices within a telecommunications network.

[0053] STP (Signalling Transfer Point) [106]: A network node used in the SS7 (Signalling System No. 7) telecommunications protocol to route signalling messages between signalling endpoints.

[0054] DRA (Diameter Routing Agent) [108]: A network element responsible for routing Diameter protocol messages within telecommunications networks, often used in IMS and LTE networks.

[0055] HSS (Home Subscriber Server) [110]: A core component in LTE and IMS networks that stores subscriber-related information, such as user profiles, authentication data, and service subscriptions.

[0056] Database 1 [112]: A database such as but not limited to Cassandra database, manages large amounts of data across servers.

[0057] Database 2 [114]: A database that streams data, such as but not limited to Redis, is a data structure that, among other functions, can effectively manage data consumption, persist data when consumers are offline with a data fail-safe, and create a data channel between many producers and consumers. [0058] MNP DB (Mobile Number Portability Database) [116]: A database service that allows mobile phone users to retain their phone numbers when switching between different service providers.

[0059] Internal External Short Messaging Entity (ESME) [118]: An external application that connects to a Short Message Service Centre (SMSC) to engage in the sending or receiving of SMS messages.

[0060] SMPP (Short Message Peer-to-Peer): A protocol used in the telecommunications industry for exchanging SMS messages between Short Message Service Centres (SMSCs) and SMS application systems.

[0061] REST (Representational State Transfer): An architectural style for designing networked applications, commonly used in web services development.

[0062] SIP (Session Initiation Protocol): SIP is a signalling protocol used for initiating, maintaining, and terminating real-time sessions in IP -based communication networks. It is commonly used for voice and video calls, instant messaging, and multimedia conferencing over the Internet. SIP allows devices to establish communication sessions and negotiate the parameters of the session, such as codecs, media types, and session duration.

[0063] Referring to FIG. 2, an exemplary block diagram of a system [200] is shown, in accordance with the exemplary embodiments of the present invention. The system [200] comprises at least one receiving unit [202], at least one storage unit [204], at least one first database [206], at least one processor [208], at least one transmitting unit [210] and at least one second database [212], Also, all of the components/ units of the system [200] are assumed to be connected to each other unless otherwise indicated below. Also, in FIG. 2 only a few units are shown, however, the system [200] may comprise multiple such units or the system [200] may comprise any such numbers of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system [200] may be present in a user device to implement the features of the present invention. The system [200] may be a part of the server device / or may be independent of but in communication with the server device. In another implementation, the system [200] may be a part of the exemplary system architecture as shown in FIG. 1, in accordance with exemplary embodiments of the present disclosure. In another implementation, the system [200] may be a part of the exemplary sequence diagram for synchronizing account information between a primary site and a disaster recovery (DR) site as shown is FIG. 3. Therefore, description of FIG. 2 and description of FIG. 3 compliments each other and should be read together.

[0064] The system [200] for synchronization of account information between the primary site and disaster recovery (DR) site comprises a receiving unit [202], The receiving unit [202] is configured to receive, via a front-end module [304] at the primary site, an account modification request from an originating management system. In an exemplary aspect, Application to Peer IP Short Message gateway (A2P-IPSMGW) and Short Message Service Centre (SMSC) are integrated to form an integrated unit, and in the integrated unit the SMSC acts as a front-end module [304] to receive message or account info from EMS over MAP interface. In an exemplary aspect, element management system (EMS) acts like a user interface (UI) to receive account information, add account information, update account information from external short messaging entity (ESME). In an exemplary aspect, the front-end module [304] is configured to receive a command from command line interface (CLI) for account info/update/add.

[0065] The account modification request could involve actions such as the addition of a new account or the deletion of an existing account within the communication network. The originating management system from which the account modification request is received may include systems such as an Element Management System (EMS), a Network Management System (NMS), a Command Line Interface (CLI), a web interface, or an Application Programming Interface (API). The receiving unit [202] serves as the initial entry point for the request and is responsible for triggering a series of processes that will ensure the account modification is reflected not only at the primary site but also synchronized with the DR site to maintain consistency across the network's operational databases.

[0066] The storage unit [204] is communicatively coupled to the receiving unit [202], The storage unit [204] is configured to store a set of data associated with the received account modification request into a first database [206] such as but not limited to Redis stream. Upon receiving an account modification request, the storage unit [204] captures and secures all the relevant data pertaining to this request, including any details necessary for the modification of the account such as the account number, user information, and the specific changes to be implemented. The first database [206], which could be a system like Redis Stream, is then used as a repository for the data. [0067] The processor [208] is communicatively coupled to the storage unit [204], The processor [208] is configured to continuously monitor, using a primary site sync application, the first database [206], for the set of data to process the account modification request. In an exemplary aspect, sync applications are present in their respective A2P-IPSMGW. The sync applications communicate between each other to keep the respective A2P IPSMGW updated. As soon as a new account modification request is stored in the first database [206], the processor [208], through the primary site sync application, initiates the synchronization procedure. This involves preparing the data for transmission to the disaster recovery (DR) site to ensure that both the primary and DR sites maintain up-to-date and consistent account information.

[0068] The transmitting unit [210] is communicatively coupled to the processor [208], The transmitting unit [210] is configured to transmit the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel. The transmitting unit [210] serves as the bridge for secure data transfer, ensuring that the modifications made at the primary site are accurately and promptly reflected at the DR site. The use of a communication channel in this process is designed to guarantee a reliable and efficient exchange of data, which is critical for the integrity and availability of account information, especially during failover scenarios when the DR site is required to take over operations seamlessly. The DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.

[0069] A communication channel refers to a medium used for the transmission of information from one point to another. This can encompass a variety of physical and logical pathways that facilitate data exchange, that include but not limited only to copper wires and Fiber optic cables to wireless connections like Wi-Fi or satellite links. The communication channel is further defined by its ability to carry signals, which can be in the form of electrical voltages, radio waves, or light pulses, depending on the technology in use. These signals represent the information being communicated, which can include voice, video, text, or other types of data. The choice of a communication channel is influenced by factors such as the volume of data to be transferred, the speed at which the transfer must occur, the required reliability, and the distance over which the communication must happen.

[0070] Communication channels can be simple, involving direct and point-to-point connections, or highly complex, incorporating numerous interconnected networks and nodes that allow for the global exchange of data. In digital networks, the term also applies to logical channels created through software, which can route data over various physical mediums and across different network layers. The nature of the communication channel can vary; it might be a network connection using standard internet protocols such as TCP/IP, which are foundational for both internal and external network communications. In scenarios where web services are involved, HTTP or HTTP2 protocols are often utilized due to their stateless nature and efficiency, particularly when the system employs RESTful APIs for interactions.

[0071] The storage unit [204] is further configured to store, via the DR site synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site. The DR site synchronization application facilitates in managing the data transfer and storage process, ensuring that the data received is accurately stored in the second database [212] thus, the DR site have an up-to-date copy of the account information, ready to be used in case the primary site becomes unavailable. The synchronization process is designed to be seamless, with the storage unit [204] at the DR site automatically updating its database (such as the second database [212]) whenever changes are made at the primary site, thereby ensuring continuous synchronization and data integrity.

[0072] Further, the storage unit [204] is configured to store the received account modification request data and a zone name associated with the request into a first database [206], In a preferred implementation, the first database [206] is a Redis database.

[0073] The processor [208] is further configured to process the account modification request data by an application to peer - IP short message gateway (A2P-IPSMGW) module at the primary site upon the set of data associated with the account modification request is stored into the first database [206], Once the account modification request data is securely stored in the first database [206], The A2P-IPSMGW [102] facilitates in handling the SMS service-related decisions and operations within the IP Multimedia Subsystem (IMS) network at the primary site. The processing by the A2P-IPSMGW module ensures that the account modifications are accurately reflected in the system, maintaining the integrity and up-to-datedness of the account information within the primary site's IMS network, the processor [208] is configured to process the account modification request data by an A2P-IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database [212], [0074] The processor [208] is further configured to acknowledge the account modification request by sending a success response to the originating management system.

[0075] The account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.

[0076] The originating management system communicates with the front-end module [304] via a RESTful interface.

[0077] A person skilled in the art would appreciate that the above listed features are only exemplary and do not restrict the present disclosure in any possible manner. In an exemplary implementation, the features listed above may be considered to be in the order of their importance.

[0078] FIG. 3 illustrates an exemplary sequence diagram for synchronizing account information between a primary site and a disaster recovery (DR) site, in accordance with exemplary embodiments of the present disclosure.

[0079] At step SI, the Element Management System (EMS) [302] initiates an add or update operation for an ESME (External Short Messaging Entity) account, transmitting this request to the front-end module [304], In an exemplary aspect, element management system (EMS) acts like a user interface (UI) to receive account information, add account information, update account information from external short messaging entity (ESME). In an exemplary aspect, the front-end module [304] is configured to receive a command from command line interface (CLI) for account info/update/add.

[0080] Moving on to step S2, the front-End module [304] processes this request and consequently stores the ESME details within the database Cluster (such as the first database [206]), which represents the first point of data entry in the system, functioning as the initial database. The first database [206] includes such as but not limited to remote dictionary server (Redis) that also acts like a cache. In an exemplary aspect, the primary database cluster such as Redis acts as a publishing/sub scribing system for streaming.

[0081] At step S3, following the receipt and processing of the account modification details, the front-End module [304] sends back a confirmation in the form of a 200 OK response to the EMS [302], indicating the successful reception and handling of the request. [0082] Then at step S4, the A2P-IPSMGW [102] interacts with the first database [206], for retrieving the details of the ESME account modification from the first database [206],

[0083] In step S5, the A2P-IPSMGW [102] takes further action based on the retrieved information to add or update the ESME Configuration [312] accordingly, implementing the changes within the network's operational parameters.

[0084] At step S6, the process involves the first database [206], interacting with the DR Sync Application [310], The data is read from the first database [206] and shared with the primary sync application [308], ensuring the details are queued for synchronization.

[0085] Proceeding to step S7, the Primary Sync Application [308] uses an HTTP2 communication protocol to securely transmit the ESME account details to the DR Sync Application [310], The step facilitates in ensuring that the disaster recovery site has the most up-to-date information, maintaining consistency across the network's nodes.

[0086] Thereafter, at step S8, the DR Sync Application [310] confirms the successful reception of the transmitted data by sending back a 200 OK response to the Primary Sync Application [308], In an exemplary aspect, disaster recovery (DR) (A2PIPSMGW) listens to disaster recovery (DR) database cluster such as but not limited to Redis Cluster for processing the received data. Further, in an exemplary aspect, Application to Peer IP Short Message gateway (A2P-IPSMGW) and Short Message Service Centre (SMSC) are integrated to form an integrated unit, and in the integrated unit the SMSC acts as a front-end module [304] to receive message or account info from EMS over MAP interface.

[0087] Lastly at step S9, the DR Sync Application [310] stores the added/updated ESME account data into a second database [212] for processing and synchronization at the DR site.

[0088] Referring to FIG. 4 an exemplary method flow diagram [400], for synchronizing account information between a primary site and a disaster recovery (DR) site, in accordance with exemplary embodiments of the present disclosure is shown. In an implementation the method is performed by the system [200], Further, in an implementation, the system [200] (partially or as a whole) may be present in a server device or in a user device to implement the features of the present disclosure. [0089] At step [404], the method comprises receiving, by a receiving unit [202] via a front-end module [304] at the primary site, an account modification request from an originating management system. The account modification request could involve actions such as the addition of a new account or the deletion of an existing account within the communication network. The originating management system from which the account modification request is received may include systems such as an Element Management System (EMS), a Network Management System (NMS), a Command Line Interface (CLI), a web interface, or an Application Programming Interface (API). The receiving unit [202] serves as the initial entry point for the request and is responsible for triggering a series of processes that will ensure the account modification is reflected not only at the primary site but also synchronized with the DR site to maintain consistency across the network's operational databases.

[0090] Next, at step [406], the method encompasses storing, by a storage unit [204], a set of data associated with the received account modification request into a first database [206], Upon receiving an account modification request, the storage unit [204] captures and secures all the relevant data pertaining to this request, including any details necessary for the modification of the account such as the account number, user information, and the specific changes to be implemented. The first database [206], which could be a system like Redis Stream, is then used as a repository for the data.

[0091] Now, at step [408], the method comprises continuously monitoring, by a processor [208] using a primary site synchronization application, the first database [206], for the set of data to process the account modification request. As soon as a new account modification request is stored in the first database [206], the processor [208], through the primary site sync application, initiates the synchronization procedure. This involves preparing the data for transmission to the disaster recovery (DR) site to ensure that both the primary and DR sites maintain up-to-date and consistent account information.

[0092] Further, at step [410], the method encompasses transmitting, by a transmitting unit [210], the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel. The transmitting unit [210] serves as the bridge for secure data transfer, ensuring that the modifications made at the primary site are accurately and promptly reflected at the DR site. The use of a communication channel in this process is designed to guarantee a reliable and efficient exchange of data, which is critical for the integrity and availability of account information, especially during failover scenarios when the DR site is required to take over operations seamlessly. The DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.

[0093] Furthermore, at step [412], the method comprising storing, by the storage unit [204] via the DR synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site. The DR site synchronization application facilitates in managing the data transfer and storage process, ensuring that the data received is accurately stored in the second database [212] thus, the DR site have an up-to-date copy of the account information, ready to be used in case the primary site becomes unavailable. The synchronization process is designed to be seamless, with the storage unit [204] at the DR site automatically updating its database (such as the second database [212]) whenever changes are made at the primary site, thereby ensuring continuous synchronization and data integrity.

[0094] Thereafter, the process terminates at step [414]

[0095] FIG. 5 illustrates an exemplary block diagram of a computing device [500] (also referred to herein as a computer system [500]) upon which an embodiment of the present disclosure may be implemented. In an implementation, the computing device implements the method for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network using the system [200], In another implementation, the computing device itself implements the method for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network by using one or more units configured within the computing device, wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.

[0096] The computing device [500] may include a bus [502] or other communication mechanism for communicating information, and a processor [504] coupled with bus [502] for processing information. The processor [504] may be, for example, a general-purpose microprocessor. The computing device [500] may also include a main memory [506], such as a random-access memory (RAM), or other dynamic storage device, coupled to the bus [502] for storing information and instructions to be executed by the processor [504], The main memory [506] also may be used for storing temporary variables or other intermediate information during execution of the instructions to be executed by the processor [504], Such instructions, when stored in non-transitory storage media accessible to the processor [504], render the computing device [500] into a special-purpose machine that is customized to perform the operations specified in the instructions. The computing device [500] further includes a read only memory (ROM) [508] or other static storage device coupled to the bus [502] for storing static information and instructions for the processor [504],

[0097] A storage device [510], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [502] for storing information and instructions. The computing device [500] may be coupled via the bus [502] to a display [512], such as a cathode ray tube (CRT), for displaying information to a computer user. An input device [514], including alphanumeric and other keys, may be coupled to the bus [502] for communicating information and command selections to the processor [504], Another type of user input device may be a cursor controller [516], such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor [504], and for controlling cursor movement on the display [512], This inputs device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.

[0098] The computing device [500] may implement the techniques described herein using customized hard-wired logic, one or more Application-Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs), firmware and/or program logic which in combination with the computing device [500] causes or programs the computing device [500] to be a specialpurpose machine. According to one embodiment, the techniques herein are performed by the computing device [500] in response to the processor [504] executing one or more sequences of one or more instructions contained in the main memory [506], Such instructions may be read into the main memory [506] from another storage medium, such as the storage device [510], Execution of the sequences of instructions contained in the main memory [506] causes the processor [504] to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0099] The computing device [500] also may include a communication interface [518] coupled to the bus [502], The communication interface [518] provides a two-way data communication coupling to a network link [520] that is connected to a local network [522], For example, the communication interface [518] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface [518] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [518] sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0100] The computing device[500] can send messages and receive data, including program code, through the network(s), the network link [520] and the communication interface 518. In the Internet example, a server [530] might transmit a requested code for an application program through the Internet [528], the Internet Service Provider (ISP) [526], the local network [522], host [524] and the communication interface [518], The received code may be executed by the processor [504] as it is received, and/or stored in the storage device [510], or other non-volatile storage for later execution.

[0101] The computing device [500] encompasses a wide range of electronic devices capable of processing data and performing computations. Examples of computing device [500] include, but are not limited only to, personal computers, laptops, tablets, smartphones, servers, and embedded systems. The devices may operate independently or as part of a network and can perform a variety of tasks such as data storage, retrieval, and analysis. Additionally, computing device [500] may include peripheral devices, such as monitors, keyboards, and printers, as well as integrated components within larger electronic systems, showcasing their versatility in various technological applications.

[0102] Yet another aspect of the present disclosure relates to a non-transitory computer-readable storage medium storing instructions for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network. The instructions include an executable code which when executed by a processor, may cause the processor to receive an account modification request from an originating management system; store a set of data associated with the received account modification request into a first database such as but not limited to Redis stream; continuously monitor the first database for the set of data to process the account modification request; transmit the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel; and store the set of data associated with the account modification request into a second database for processing and synchronization at the DR site. [0103] As is evident from the above, the present disclosure provides a technically advanced solution by using the Synchronization Client process communication to add any account in primary site along with an update in the DR site.

[0104] It should be noted that the terms "first", "second", "primary", "secondary", "target" and the like, herein do not denote any order, ranking, quantity, or importance, but rather are used to distinguish one element from another.

[0105] Further, in accordance with the present disclosure, it is to be acknowledged that the functionality described for the various the components/units can be implemented interchangeably. While specific embodiments may disclose a particular functionality of these units for clarity, it is recognized that various configurations and combinations thereof are within the scope of the disclosure. The functionality of specific units as disclosed in the disclosure should not be construed as limiting the scope of the present disclosure. Consequently, alternative arrangements and substitutions of units, provided they achieve the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.

[0106] While considerable emphasis has been placed herein on the disclosed embodiments, it will be appreciated that many embodiments can be made and that many changes can be made to the embodiments without departing from the principles of the present disclosure. These and other changes in the embodiments of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

Claims

I/We Claim:

1. A method for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, the method comprising: receiving, by a receiving unit [202] via a front-end module [304] at the primary site, an account modification request from an originating management system; storing, by a storage unit [204], a set of data associated with the received account modification request into a first database [206]; continuously monitoring, by a processor [208] using a primary site synchronization application, the first database [206] for the set of data to process the account modification request; transmitting, by a transmitting unit [210], the set of data associated with the account modification request from the primary site synchronization application to a DR site synchronization application via a communication channel; and storing, by the storage unit [204] via the DR synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site.

2. The method as claimed in claim 1, further comprises acknowledging, by the processor [208], the account modification request by sending a success response to the originating management system.

3. The method as claimed in claim 1, wherein the account modification request comprises at least one of addition of a new account or deletion of an existing account.

4. The method as claimed in claim 1, wherein the originating management system is selected from a group consisting of an Element Management System (EMS), a Network Management System (NMS), a Command Line Interface (CLI), a web interface, and an Application Programming Interface (API).

5. The method as claimed in claim 1, wherein the account modification request is stored into the first database [206] along with a zone name identifier.

6. The method as claimed in claim 1, wherein the DR site synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.

7. The method as claimed in claim 1, further comprising processing, by the processor [208], the account modification request data by an A2P- IP short message gateway (IPSMGW) module at the primary site upon the set of data associated with the account modification request is stored into the first database [206],

8. The method as claimed in claim 1, further comprising processing, by the processor [208], the account modification request data by an A2P -IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database [212],

9. The method as claimed in claim 1, wherein the account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.

10. The method as claimed in claim 1, wherein the originating management system communicates with the front-end module [304] via a RESTful interface.

11. A system for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, the system comprising: a receiving unit [202] configured to receive, via a front-end module [304] at the primary site, an account modification request from an originating management system; a storage unit [204], configured to store a set of data associated with the received account modification request into a first database [206]; a processor [208], configured to continuously monitor, using a primary site sync application, the first database [206] for the set of data to process the account modification request; a transmitting unit [210], configured to transmit the set of data associated with the account modification request from the primary synchronization application to a DR synchronization application via a communication channel; and the storage unit [204], configured to store, via the DR synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site.

12. The system as claimed in claim 11, wherein the processor [208] is further configured to acknowledge the account modification request by sending a success response to the originating management system.

13. The system as claimed in claim 11, wherein the account modification request comprises at least one of addition of a new account or deletion of an existing account.

14. The system as claimed in claim 11, wherein the originating management system is selected from a group consisting of Element Management System (EMS), Network Management System (NMS), Command Line Interface (CLI), web interface, and an Application Programming Interface (API).

15. The system as claimed in claim 11, wherein the account modification request is stored into the first database [206] along with a zone name identifier.

16. The system as claimed in claim 11, wherein the DR synchronization application sends an acknowledgment response upon successfully receiving the account modification request data via the communication channel.

17. The system as claimed in claim 11, wherein the processor [208] is configured to process the account modification request data by an application to peer - IP short message gateway (A2P-IPSMGW) module at the primary site upon the set of data associated with the account modification request is stored into the first database [206],

18. The system as claimed in claim 11, wherein the processor [208] is configured to process the account modification request data by an A2P-IPSMGW module at the DR site upon the set of data associated with the account modification request is stored into the second database [212],

19. The system as claimed in claim 11, wherein the account modification request corresponds to SMS service account modifications in an IP Multimedia Subsystem (IMS) network.

20. The system as claimed in claim 11, wherein the originating management system communicates with the front-end module [304] via a RESTful interface.

21. A non-transitory computer-readable storage medium storing instruction for synchronizing account information between a primary site and a disaster recovery (DR) site in a communication network, the storage medium comprising executable code which, when executed by one or more units of a system, causes: a receiving unit [202] to receive, via a front-end module [304] at the primary site, an account modification request from an originating management system; a storage unit [204] to store a set of data associated with the received account modification request into a first database [206]; a processor [208] to continuously monitor, uasing a primary site sync application, the first database [206] for the set of data to process the account modification request; a transmitting unit [210] to transmit the set of data associated with the account modification request from the primary synchronization application to a DR synchronization application via a communication channel; and the storage unit [204] to store, via the DR synchronization application, the set of data associated with the account modification request into a second database [212] for processing and synchronization at the DR site.