Method and system for routing short message service in a network

Abstract

The present disclosure provides a method (400) and a system (108) for routing one or more SMS in a network (106). The method includes a receiving module (208) configured to receive SMS messages from at least one source and extract message metadata, including source and destination addresses. A filtering module (210) performs message filtering based on predefined whitelist and blacklist rules to classify each SMS as allowed or blocked for routing. For each allowed SMS, a query module (212) executes a mobile number portability (MNP) query to determine the current network operator. A routing module (214) identifies at least one destination entity capable of delivering each allowed SMS, selects an optimal routing path from available paths based on routing rules, and forwards each allowed SMS to the identified destination entity. The method (400) and the system (108) achieve cost-efficient fault tolerance, optimal resource utilization, and reduced maintenance overhead.

Description

METHOD AND SYSTEM FOR ROUTING SHORT MESSAGE SERVICE IN A NETWORK RESERVATION 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.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of telecommunications. More particularly, the present disclosure relates to a method and a system for routing one or more short message services (SMS) in a network.DEFINITION

[0003] The expression “Short message service (SMS),” used hereinafter in the specification, refers to text-based communications transmitted between one or more user equipments (UEs) or between a user equipment and an application server. The SMS is used for a variety of purposes, including person-to-person (P2P) messaging, application-to-person (A2P) notifications (such as appointment reminders or one-time passwords OTPs), marketing communications, alerts and similar.

[0004] The expression “Rule engine,” used hereinafter in the specification, refers to a module responsible for runtime configuration and management of routing rules and SMS filtering. The rule engine allows for dynamic and flexible routing decisions based on various criteria, such as destination, message type, customer types, and similar.

[0005] The expression “Short Message Service Center (SMSC)” used hereinafter in the specification refers to a network component that handles text message operations. The SMSC performs various text message operations, such as receiving, storing, and forwarding text messages. The SMSC serves as the primary point for handling SMS that are received from external systems, ensuring that the messages are appropriately processed and delivered to their intended recipients.

[0006] The expression “Signal Transfer Point (STP)” used hereinafter in the specification refers to a node in a Signaling System No. 7 (SS7) network that routes signaling messages between network elements, such as SMSCs, mobile switching centers (MSCs), and other network entities.

[0007] The expression “Signaling System No. 7 (SS7)” used hereinafter in the specification refers to a standard protocol for communications signaling. The SS7 enables communication between network elements and facilitates call setup, routing, SMS delivery, and other services.

[0008] The expression “Network Management System (NMS)” used hereinafter in the specification refers to a system that monitors, manages, and optimizes the performance of the network. The NMS oversees the health and functionality of the network components, such as SMSCs, STPs, and signaling links, by providing realtime insights, alerting system administrators to potential issues, and facilitating troubleshooting and maintenance activities.

[0009] These definitions are in addition to those expressed in the art.BACKGROUND

[0010] 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 presentdisclosure. 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.

[0011] In telecommunications, ensuring reliable and real-time message service delivery is essential for network operators, specifically the effective and timely delivery and routing of Short Message Service (SMS). Nowadays, SMS technology has become an integral part of personal and business communication due to its accessibility, speed, and effectiveness. As the demand for SMS services has increased, the requirements for robust SMS systems that can handle large volumes of messages efficiently, reliably, and at a lower cost have also increased.

[0012] The existing SMS systems often have inflexible and monolithic architectures, which may face significant challenges. These include limited availability, which can lead to service interruptions, high routing costs associated with message delivery, and inflexible routing mechanisms that do not adapt to changing user needs or conditions in real time. Additionally, the existing SMS systems often lack the capability to implement complex routing rules dynamically, resulting in inefficiencies and missed opportunities for optimization in message delivery.

[0013] The existing SMS delivery systems typically rely on static routing protocols and infrastructure that can become overwhelmed during peak usage, leading to delays or message loss. Furthermore, the existing systems do not offer redundancy, which can compromise service reliability. The inability to configure routing rules at runtime also restricts the adaptability of these systems to changing business requirements, market conditions, or user preferences. As a result, these limitations can hinder the effectiveness of SMS service delivery, leading to increased operational costs and reduced customer satisfaction.

[0014] There is, therefore, a need in the art to provide a method and a system that can mitigate the disadvantages of the prior art.SUMMARY OF THE DISCLOSURE

[0015] In an exemplary embodiment, a method for routing one or more short message services (SMS) in a network is described. The method includes receiving, by a receiving module, the one or more short message services (SMS) from at least one source. The method further includes extracting, by the receiving module, message metadata from each of the one or more SMS, where the message metadata includes at least a source address and a destination address. The method further includes performing, by a filtering module, message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing. The method further includes executing, by a query module, a mobile number portability (MNP) query for each SMS classified as allowed, to determine a current network operator associated with the destination address. The method further includes identifying, by a routing module, at least one messaging entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query. The method further includes selecting, by the routing module, an optimal routing path from a plurality of available routing paths for each allowed SMS. The method further includes forwarding, by the routing module, each allowed SMS to the identified at least one messaging entity via the selected optimal routing path.

[0016] In some embodiments, for selecting the optimal routing path from the plurality of available routing paths for each allowed SMS, the method includes retrieving, by the routing module, one or more applicable routing rules based on the message metadata from a database. The method further includes evaluating, by the routing module, each allowed SMS against the retrieved applicable routing rules using the results of the MNP query as routing parameters. The method further includesdetermining, by the routing module, a routing priority based on at least one of: message type or cost optimization.

[0017] In some embodiments, for performing the message filtering, the method includes comparing, by the filtering module, the source address and destination address of the one or more SMS against a predefined whitelist including one or more authorized source addresses and destination addresses and a predefined blacklist including one or more restricted source addresses and destination addresses. The method further includes classifying, by the filtering module, the one or more SMS as allowed when the source address and the destination address match any one of the one or more authorized source addresses and destination addresses within the predefined whitelist. The method further includes classifying, by the filtering module, the one or more SMS as blocked when the source address and the destination address match any one of the one or more restricted source addresses and destination addresses within the predefined blacklist.

[0018] In some embodiments, the method further includes maintaining, by a synchronization module, configuration consistency between a primary processing instance and a secondary standby instance, where the primary processing instance actively processes the one or more SMS, the secondary standby instance maintains a synchronized copy of configuration data and operational state, configuration updates applied to the primary processing instance are replicated to the secondary standby instance via a publish-subscribe messaging pattern, and upon detection of primary instance failure, the secondary standby instance automatically assumes the primary role with the current configuration state.

[0019] In some embodiments, the method further includes publishing, by the synchronization module, configuration changes to a distributed data stream when runtime modifications occur. The method further includes consuming, by the synchronization module, the configuration changes from the distributed data stream bythe secondary standby instance. The method further includes storing, by the synchronization module, deferred messages in a persistent storage during instance transition and processing, by the synchronization module, the stored deferred messages after successful role transition.

[0020] In another exemplary embodiment, a system for routing one or more short message services (SMS) in a network is described. The system includes a receiving module, a filtering module, a query module, a routing module and a synchronization module. The receiving module is configured to receive one or more short message services (SMS) from at least one source and extract message metadata from each of the one or more SMS, where the message metadata includes at least a source address and a destination address. The filtering module is configured to perform message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing. The query module is configured to execute a mobile number portability (MNP) query for each SMS classified as allowed to determine a current network operator associated with the destination address. The routing module is configured to identify at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query, select an optimal routing path from a plurality of available routing paths for each allowed SMS and forward each allowed SMS to the identified at least one destination entity via the selected optimal routing path.

[0021] In an exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to perform a method for routing one or more short message services (SMS) in a network, is described. The method includes receiving, by a receiving module, one or more short message services (SMS) from at least one source. The method furtherincludes extracting, by the receiving module, message metadata from each of the one or more SMS, where the message metadata includes at least a source address and a destination address. The method further includes performing, by a filtering module, message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing. The method further includes executing, by a query module, a mobile number portability (MNP) query for each SMS classified as allowed, to determine a current network operator associated with the destination address. The method further includes identifying, by a routing module, at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query. The method further includes selecting, by the routing module, an optimal routing path from a plurality of available routing paths for each allowed SMS. The method further includes forwarding, by the routing module, each allowed SMS to the identified at least one destination entity via the selected optimal routing path.

[0022] 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.OBJECTIVES OF THE PRESENT DISCLOSURE

[0023] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0024] An objective of the present disclosure is to provide a system and a method for routing one or more short message service (SMS) in a network.

[0025] Another objective of the present disclosure is to provide a reliable SMS hub architecture that ensures continuous availability and efficient SMS routing.

[0026] Another objective of the present disclosure is to provide a system with high availability, Virtual Internet Protocol (VlP)-based active standby implementation, along with deferred message storage in databases, thereby enhancing system reliability and resilience.

[0027] Yet another objective of the present disclosure is to support multiple interfaces, including but not limited to Hypertext Transfer Protocol (HTTP), Small Peer to Peer (SMPP), and Signalling System No. 7 (SS7), to facilitate versatile connectivity and interoperability with various communication protocols.

[0028] Another objective of the present disclosure is to provide a rule engine that enables configurable SMS filtering, including blocking and whitelisting, and customizable routing rules to adapt to different messaging requirements.

[0029] Another objective of the present disclosure is to provide a graphical user interface (GUI) for streamlined rule management, making configuration more accessible and efficient for system administrators.

[0030] Yet another objective of the present disclosure is to incorporate leastcost routing capabilities to minimize operational expenses and optimize cost efficiency in SMS delivery.

[0031] 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.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

[0032] 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 partsthroughout the different drawings. Components in the drawings are not necessarily to scale; emphasis is 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.

[0033] FIG. 1 illustrates an exemplary network architecture in which or with a system configured for routing one or more short message services (SMS) in a network may be implemented, in accordance with embodiments of the present disclosure.

[0034] FIG. 2 illustrates an exemplary block diagram of the system configured for routing the one or more SMS in the network, in accordance with embodiments of the present disclosure.

[0035] FIG. 3 illustrates an exemplary system architecture for routing the one or more SMS in the network, in accordance with an embodiment of the present disclosure.

[0036] FIG. 4 illustrates an exemplary flow diagram of a method for routing the one or more SMS in the network, in accordance with an embodiment of the present disclosure.

[0037] FIG. 5 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented.

[0038] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network Architecture102 -User(s)104 - User Equipments (UEs)106 - Network108 - System200 -Block Diagram202 - Processor(s)204 - Memory206 - Interface(s)208 - Receiving module210 - Filtering module212 - Query module214 - Routing module216 - Synchronization module218 -Database300 - System architecture302-(l-N) - Short Message Service Centers (SMSCs) 304 - Internet Protocol (IP) network306- Mobile Number Portability (MNP) database308 - International Long Distance (ILD) SMS hub cluster 310 - Signalling System No. 7 (SS7) microservice component 312 - SS7 network314 - Signal Transfer Point (STP) node316 - Network Management System (NMS)318 - Database320 - International Long Distance (ILD) engine322 - Graphical User Interface (GUI)324 - Command Line Interface (CLI)400 - Method Flow Diagram500 - Computer System510 - External Storage Device520 - Bus530 - Main Memory540 - Read Only Memory550 - Mass Storage Device560 - Communication Port(S)570 - ProcessorDETAILED DESCRIPTION

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

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

[0041] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of the 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.

[0042] 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 structurediagram, 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.

[0043] 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 like the term “comprising” as an open transition word without precluding any additional or other elements.

[0044] 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 particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0045] The terminology used herein is to describe particular embodiments only and is not intended to limit 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 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.

[0046] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0047] In telecommunications, ensuring reliable and real-time message service delivery is essential for network operators, specifically the effective and timely delivery and routing of Short Message Service (SMS). As the demand for SMS services has increased, the requirements for robust SMS systems that can handle large volumesof messages efficiently, reliably, and at a lower cost have also increased. The existing SMS systems often have inflexible and monolithic architectures which may face significant challenges. These include limited availability, which can lead to service interruptions, high routing costs associated with message delivery, and inflexible routing mechanisms that do not adapt to changing user needs or conditions in real-time. Additionally, the existing SMS systems often lack the capability to implement complex routing rules dynamically, resulting in inefficiencies and missed opportunities for optimization in message delivery.

[0048] The existing SMS delivery systems typically rely on static routing protocols and infrastructure that can become overwhelmed during peak usage times, leading to delays or message loss. Furthermore, the existing systems do not offer redundancy, which can compromise service reliability. The inability to configure routing rules at runtime also restricts the adaptability of these systems to changing business requirements, market conditions, or user preferences. As a result, these limitations can hinder the effectiveness of SMS service delivery, leading to increased operational costs and reduced customer satisfaction.

[0049] To overcome the limitations associated with conventional SMS routing techniques, the present disclosure provides a system and method for routing one or more Short Message Services (SMS) in a communication network. Unlike existing inflexible and monolithic architectures, the system implements a Virtual Internet Protocol (VTP)-based active-standby configuration, a dedicated microservice for handling Signaling System No. 7 (SS7) traffic, and a user-friendly interface for rule management. The system architecture introduces advanced functionalities that are absent in traditional solutions while significantly reducing operational costs. Furthermore, the system prevents vendor lock-in by offering flexibility to integrate with multiple International Mobile Number Portability (MNP) database providers. Thearchitecture also ensures regulatory compliance, effectively addressing challenges that conventional SMS solutions often fail to manage.

[0050] The system and method collectively deliver a robust and scalable SMS hub service that provides:I. high availability and fault tolerance through the VIP-based active- standby mechanism with deferred message storage in a database.II. support for multiple messaging interfaces, including Short Message Peer-to- Peer (SMPP), Hypertext Transfer Protocol (HTTP), and Signaling System No.7 (SS7)III. a rule engine for dynamic configuration of SMS filtering (blocking and whitelisting) and routing rules.IV. a dedicated graphical user interface (GUI) for intuitive rule management and runtime modifications.V. least-cost routing capability to optimize operational expenditures without compromising message delivery efficiency.

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

[0052] FIG. 1 illustrates an exemplary network architecture 100 in which or with a system 108 configured for routing one or more short message services (SMS) in a network 106 may be implemented, in accordance with embodiments of the present disclosure.

[0053] In an embodiment, the network architecture 100 may include one or more user equipment (UEs) 104-1, 104-2... 104-N associated with one or more users102-1, 102-2... 102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2... 102-N may be individually referred to as the user 102 and collectively referred to as the users 102. In an example, the user 102 may correspond to a network administrator or a network service provider. Similarly, a person of ordinary skill in the art will understand that 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. Although three UEs 104 are depicted in FIG. 1, however, any number of the UEs 104 may be included without departing from the scope of the ongoing description.

[0054] In an implementation, the UE 104 may function as smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE 104 may include, but is not limited to, smart phones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users 102 and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but is not limited to, intelligent, multisensing, network- connected devices, which 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.

[0055] In an embodiment, the UE 104 may include, but is not limited to, any electrical, electronic, electro-mechanical, or an equipment, or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, mobile phone, smartphone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any othercomputing device, wherein 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 102 or the entity such as touch pad, touch enabled screen, 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.

[0056] In FIG. 1, the UE 104 may establish communication with a telecommunication network 106 (interchangeably referred to as a network 106). In order to establish communication, initially, the telecommunication network 106 is configured to receive a connection request from the UE 104. In response to receiving the connection request, the telecommunication network 106 is configured to send an acknowledgment of the connection request to the UE 104. Further, a plurality of signals is transmitted in response to the connection request. Based on the connection request, the sessions are created in the telecommunication network 106. In an embodiment, the network 106 includes at least one of the 4G network, the 5G network, the 6G network, or the like. The telecommunication network 106 may enable the UE 104 to communicate with other devices in the network architecture 100 and / or with the system 108. In an embodiment, the network 106 may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network 106 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), an internet, an 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 another embodiment, the telecommunication network 106 includes, 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.

[0057] In an exemplary embodiment, the user 102 may utilize the UE 104 to interact with the system 108 via the network 106. The system 108 may provide an interactive user interface enabling the user 102 to enter commands and perform configuration operations related to message routing and filtering. In one implementation, the user interface may include a graphical user interface (GUI) that facilitates visualization, creation, modification, and management of routing rules, filtering criteria, and operational parameters of the system 108 in real time. In another implementation, the user 102 may interact with a command-line interface (CLI), which allows the users to execute configuration commands, retrieve system statistics, and perform administrative control functions through text-based inputs. The interactive interfaces allow flexible rule management, runtime configuration, and monitoring of system performance without service interruption.

[0058] Although 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.

[0059] FIG. 2 illustrates an exemplary block diagram of the system 108 configured for routing the one or more SMS in the network 106, in accordance with an embodiment of the present disclosure.

[0060] In an embodiment, the system 108 may include one or more processor(s) 202. 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 a memory 204 of the system 108. 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 a Random- Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.

[0061] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (VO), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108.

[0062] In an implementation, the system 108 may include one or more modules that are collectively utilized to route the one or more SMS. Examples of such modules may include, but are not limited to, a receiving module 208, a filtering module 210, a query module 212, a routing module 214, and a synchronization module 216. The one or more modules may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the system 108. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the one or more modules may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for theone or more modules may include a processing resource (for example, the one or more processors 202) to execute such instructions. In an embodiment, the interface(s) 206 may also provide a communication pathway for the one or more modules and other components of the system 108. Examples of such components include, but are not the processor (s) 202, the receiving module 208, the filtering module 210, the query module 212, the routing module 214, the synchronization module 216, and a database 218. In one implementation, the one or more modules may be operatively coupled to each other and to the interface(s) 206 to enable seamless data acquisition, decoding, and dispatching of received information for further handling or storage.

[0063] In an embodiment, the receiving module 208 is configured to receive the one or more SMS from at least one source. A person of ordinary skill in the art will appreciate that the term ‘SMS’ is intended to include both a single message (i.e., a single SMS) and multiple messages (i.e., a series or plurality of SMS messages), unless otherwise specified. The use of ‘SMS’ herein should be understood to encompass both individual instances of messaging and collections of messages transmitted over a communication network, irrespective of whether such messages are sent sequentially or in parallel.

[0064] In an aspect, the at least one source may include, but is not limited to, mobile networks, messaging gateways, application servers, or third-party messaging platforms. In an example, mobile networks may include public land mobile networks (PLMNs) operated by telecom service providers. In these networks, the one or more SMS are typically generated by the user devices (i.e., the UEs 104) such as mobile phones, loT devices, or modems, and are transmitted through base stations and short message service centers (SMSC) for delivery to a destination subscriber, channel or platform. Such messages may include person-to-person (P2P) texts, alerts, or notifications. Additionally, the gateways may include SMS gateways or signalling gateways operated by enterprises, aggregators, or telecom operators that provideconnectivity between application servers and telecom infrastructure. The messaging gateways often handle application-to-person (A2P) messages generated by systems such as banking servers, e-commerce platforms, government portals, or enterprise tools, which use application programming interface (APIs) or protocols such as Short Message Peer-to-Peer (SMPP) channels, or Hypertext Transfer Protocol (HTTP) to transmit bulk or transactional SMS (e.g., OTPs, promotional offers, or service alerts). Furthermore, the third-party messaging platforms may include cloud communication services, third-party enterprise hubs, or internal network components within a telecom domain (e.g., message routers or firewalls). The third-party messaging platforms generate or relay the one or more SMS on behalf of clients or applications and ensure protocol conversion, routing, and delivery through interconnected networks. In an aspect, the system 108 supports SMPP, HTTP, and SS7 protocols for receiving and handling incoming SMS traffic from the at least one source simultaneously.

[0065] In an embodiment, the receiving module 208 is configured to extract metadata from each of the one or more SMS. The message metadata includes at least a source address and a destination address. In an example, the source address may correspond to the address of an originating entity from where the one or more SMS are sent, such as a mobile subscriber number, an alphanumeric sender ID, or an application short code, while the destination address may represent the address of a terminating entity to which the one or more SMS is intended to be delivered, such as a recipient’s mobile subscriber number, an enterprise application endpoint, or a network gateway address associated with an operator or service provider. In an aspect, the message metadata may further include, but is not limited to, parameters such as message timestamp, message type (P2P or A2P), protocol type (SMPP, HTTP, or SS7), message reference ID, service center address, message priority, network identifier, and country or operator code. Upon receiving the one or more SMS, the receiving module 208 parses and decodes the incoming one or more SMS packets, extracts relevant message metadata and normalizes the extracted message data into a standardized internal formatsuitable for subsequent operations. The conversion of the one or more SMS into the standardized format allows the system 108 to handle the SMS consistently, enabling subsequent operations to process the SMS seamlessly, irrespective of the originating protocol or source entity.

[0066] In an example, an application server, such as an enterprise marketing platform or banking notification system, transmits a bulk A2P promotional such as the one or more SMS to multiple users via an SMPP connection. The message may include a commercial or informational text, such as a discount offer, or transaction alert. Upon transmission, the one or more SMS are received at the system 108 through a SMPP interface of the receiving module 208. The receiving module 208 decodes the SMPP protocol data unit (PDU) to extract relevant metadata, including the source address (for example, the alphanumeric sender ID), the destination address (for example, the mobile subscriber numbers of the recipients), message timestamp, and message reference ID. Once decoded, the receiving module 208 maps these extracted parameters according to a predefined standardized format or rule. For example, the field ‘source address’ in the SMPP PDU is mapped to a standardized “Source Address” field, and “short message” is mapped to a standardized “Message Content” field.

[0067] In an embodiment, the filtering module 210 is configured to perform message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing. The message filtering refers to an operation performed to analyze and control the flow of incoming one or more SMS based on predefined rules, policies, or attributes derived from the extracted message metadata. The message filtering ensures that only legitimate, compliant, and authorized SMS are forwarded for further processing or routing, while suspicious, invalid, or unauthorized messages are blocked or discarded. To perform message filtering, the filtering module 210 is configured to compare the source address and destination address of each SMS against a predefined whitelist, which includes one ormore authorized source addresses and destination addresses, as well as a predefined blacklist, which includes one or more restricted source addresses and destination addresses. For example, the predefined whitelist corresponds to a repository or database of authorized and trusted source and destination addresses that are permitted to transmit or receive SMS through the system 108. The one or more authorized source addresses and destination addresses within the predefined whitelist may include verified enterprise sender IDs, registered short codes, trusted operator gateways, etc., that are approved based on regulatory or business policies. Additionally, the predefined blacklist corresponds to a repository or database of restricted, unverified, or suspicious source and destination addresses that are prohibited from transmitting or receiving SMS through the system 108. The one or more restricted source addresses and destination addresses within the predefined blacklist may include spam-generating numbers, fraudulent or spoofed sender IDs, unregistered application endpoints, or entities identified as violating regulatory or operator policies. The predefined blacklist helps prevent delivery of unsolicited, malicious, or non-compliant SMS traffic, thereby ensuring network integrity and compliance with messaging regulations. In an aspect, the filtering module 210 is configured to classify one or more SMS as allowed when the source address and the destination address extracted in the message metadata match any one of the one or more authorized source addresses and destination addresses within the predefined whitelist. Conversely, the filtering module 210 is configured to classify one or more SMS as blocked when the source address and the destination address extracted in the message metadata match any one of the one or more restricted source addresses and destination addresses within the predefined blacklist. In an example, when an enterprise application transmits the one or more SMS using a sender ID ‘ABC BANK’, the filtering module 210 compares this sender ID against the predefined whitelist. If ‘ABC_BANK’ is present in the whitelist as a verified sender ID, the one or more SMS is marked as allowed. However, if one or more SMS arrive from a sender ID such as ‘DEF BANK’ that is listed in the predefined blacklist due toprior spam or policy violations, the filtering module 210 automatically classifies the one or more SMS as blocked and prevents them from further processing and routing.

[0068] In an embodiment, the query module 212 is configured to execute a mobile number portability (MNP) query for each SMS classified as allowed to determine a current network operator associated with the destination address. In an aspect, for the SMS that requires access to International Mobile Number Portability (MNP) databases, the system 108 is capable of integration with multiple vendors. The system 108 offers flexibility in integrating with various vendors for accessing IMNP databases. This vendor-agnostic approach ensures that the system 108 adapts to different regional requirements and avoids vendor lock-in, a common issue in the SMS messaging domain. In an aspect, the query module 212 (interchangeably referred to as a vendor integration component) manages the connections and communication with these vendors, retrieving the necessary MNP data. This data is used to ensure accurate routing and delivery of each allowed SMS to ported mobile numbers. The query module 212 dynamically manages connections to different MNP providers, retrieves required data, and normalizes the responses into a consistent internal format for routing decision-making.

[0069] The MNP query refers to a network lookup operation performed to identify whether the destination address is ported from its original operator to another operator and to retrieve corresponding routing parameters such as the Mobile Country Code (MCC) and Mobile Network Code (MNC). In an example, the MNP query may be in a standardized Telephone Number Mapping (ENUM)-based domain name system (DNS) query format, where the destination address is converted into an ENUM domain structure and queried against the MNP database. In operation, for each allowed SMS, the query module 212 extracts the destination address from the message metadata and initiates the MNP query towards the IMNP database. The IMNP database may be locally maintained within the system 108 or accessed through an external vendor’sMNP lookup service via standard interfaces such as HTTP. The MNP query returns the MNP query result. In an aspect, the MNP query result may include, but is not limited to, a current network operator identifier, MCC, MNC, a ported number flag, or a routing prefix associated with the destination address. The query module 212 processes the MNP query result to determine the current network operator of the destination address. The MNP query result comprises at least one of a current network operator identifier, a mobile country code (MCC), a mobile network code (MNC), a ported number flag, or a routing prefix associated with the destination address.

[0070] In an example, an enterprise application server intends to deliver one or more promotional A2P SMS to the destination address 123456789, which originally belonged to operator A. The receiving module 208 accepts the message, and the filtering module 210 classifies it as allowed for routing. Before forwarding the SMS to the routing module, the query module 212 performs the MNP query to verify whether the destination number is a ported number. The query module 212 extracts the destination address (123456789) from the message metadata and sends an MNP lookup request to the IMNP database through a standard HTTP interface. The IMNP database searches its records and identifies that the destination address has been ported from operator A to operator B. The IMNP database returns the MNP query result containing the details such as, current network operator identifier- operator B, MCC- 123, MNC:-45, ported number flag- TRUE, routing prefix- 6789.

[0071] In an embodiment, the routing module 214 is configured to identify at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query. The at least one destination entity refers to the final network element, operator, or carrier responsible for delivering each allowed SMS to the end recipient. The at least one destination entity represents the network or system to which each allowed SMS must ultimately be routed based on the destination address, result of the MNP query, routing rules etc. The at least onedestination entity may include, but is not limited to, the SMSC, signalling gateway (such as a Diameter Signaling Router (DSR), a Signaling Transfer Point (STP), or a Diameter Routing Agent (DRA)), a protocol conversion module (such as an SS7-over-IP gateway or a SIP-to-SMPP converter), or an application server (such as an SMS firewall, message hub, or a value-added service (VAS) platform). In an implementation, the filtering module 210 and the routing module 214 may operate together for the runtime configuration and SMS filtering. The routing module 214 enables dynamic and flexible routing decisions based on various criteria, including destination address, message type, or customer type. In operation, once the query module 212 provides the MNP query result, the routing module 214 compares the determined current network operator information with a set of pre-defined routing rules stored in a routing rules repository. These rules are defined based on various parameters such as destination operator, cost, latency, network type, message priority, or servicelevel agreements (SLAs) with downstream entities. The routing module 214 evaluates these routing rules and determines the at least one destination entity such as the SMSC, an SS7 microservice, a Short Message Peer-to-Peer (SMPP) client, or the application server for SMS delivery. In one aspect, the routing module 214 may maintain a routing table that maps MCC-MNC combinations to specific destination entities. For example, if the MNP query result indicates MCC-123 and MNC-45 (corresponding to operator B), the routing module 214 retrieves a routing entry linking operator B’s MCC-MNC to an SS7 microservice endpoint that handles inter-operator routing. The routing module 214 then marks the SS7 microservice as the destination entity for the corresponding delivery of each allowed SMS. In another example, if the MNP query returns MCC-404 and MNC-10 (corresponding to operator C), the routing module 214 identifies a routing entry that maps operator C’s MCC-MNC to an SMPP-based external SMSC connection. The routing module 214 then selects the corresponding SMPP (such as an SMPP transceiver bound with system ID, password, and host or port parameters) as the destination entity. Each allowed SMS is marked for delivery throughthis SMPP interface, ensuring protocol-compliant submission to operator C’s SMSC. In yet another example, if the MNP query result indicates MCC-310 and MNC-260 (corresponding to operator D), the routing module 214 retrieves a routing entry associated with an HTTP SMS delivery gateway. In this case, the routing module 214 identifies the corresponding HTTP delivery endpoint. The routing module 214 then designates the HTTP gateway as the destination entity for each allowed SMS, enabling delivery via an HTTP-based interconnect route.

[0072] In an embodiment, the routing module 214 is configured to select an optimal routing path from a plurality of available routing paths for each allowed SMS. Further, the routing module 214 is configured to forward each allowed SMS to the identified at least one destination entity via the selected optimal routing path. The plurality of available routing paths refers to two or more distinct delivery routes that the system 108 can use to forward each allowed SMS toward a destination network. The plurality of available routing paths may correspond to different terminating operators, different international or domestic SMS carriers, different signaling gateways, or alternative connectivity channels that are preconfigured in the system 108. Each routing path may differ in terms of cost, latency, operator preference, success rate, or regulatory constraints. The optimal routing path refers to the most efficient and reliable delivery route determined based on one or more routing factors such as operator availability, network congestion level, real-time latency, service cost, historical success rate, MNP-derived destination operator information, and predefined operator-specific routing policies. The optimal routing includes selecting the route with the highest evaluated priority score based on rule-engine-defined parameters. The optimal routing path ensures that each allowed SMS is delivered with minimal delay, reduced transmission cost, and maximum delivery success probability. The routing module 214 acts as an intelligent decision-making component that determines the most efficient and reliable route for message delivery based on the one or more routing factors such as network conditions, operational policies, business priorities, etc. Inorder to select the optimal routing path, the routing module 214 retrieves one or more applicable routing rules from a database such as the database 218. The one or more applicable routing rules may include, but are not limited to, destination operator, MCC, MNC, routing prefix, cost metrics, message type (P2P or A2P), service priority, network latency, reliability score, and load distribution policies. The routing module 214 evaluates each allowed SMS against the retrieved one or more applicable routing rules using the MNP query result as routing input data. Based on this evaluation, the routing module 214 determines a routing priority for each allowed SMS, considering at least one of: message type, delivery urgency, cost optimization, and service-level agreements (SLAs). The routing priority may additionally depend on one or more of: protocol availability, channel availability, network latency, hop count, load distribution, vendor preference, or rule engine parameters. The routing module 214 then identifies the routing path and the corresponding identified at least one destination entity (such as an SMSC, SS7 microservice, or SMPP client) that best meets the routing criteria. In an example, if the one or more SMS needs to be routed through the SS7 network, it is forwarded to the SS7 microservice. The SS7 microservice is responsible for handling messages that need to be transmitted over the SS7 network. The SS7 microservice encapsulates the logic for processing and routing SS7 traffic, ensuring compatibility with the telecommunications protocol. Conversely, if the message is to be relayed over SMPP (based on the routing decision), the routing module 214 selects the appropriate client channel. If more than one channel is available, the routing module 214 selects the channels in a round robin fashion.

[0073] In an exemplary scenario, when the system 108 receives the one or more SMS for a number that has been ported to operator B, the query module 212 returns the MNP query result with MCC-404 and MNC-45, indicating that the subscriber now belongs to operator B. The routing module 214 references its routing table and identifies that all messages destined for operator B should be routed via an SS7 microservice that is directly connected to the SMSC of operator B. The routing module214 selects this SS7 route as the optimal path since it provides low latency and high delivery reliability. Further, each allowed SMS is forwarded through the SS7 microservice to operator B’s SMSC for delivery. This process ensures that each allowed SMS is accurately routed to its correct operators even after number portability, while optimizing for network performance, cost efficiency, and compliance with interoperator routing regulations.

[0074] In an aspect, after forwarding the SMS, the routing module 214 may also implement error handling procedures, such as waiting for an acknowledgment from messaging entities to confirm successful receipt of the one or more SMS. The system 108 implements retries or fallback mechanisms if the forwarding fails or if the delivery status returns an error, monitoring the delivery status to confirm successful message delivery or handling any potential failures.

[0075] In an embodiment, the system 108 implements a Virtual IP-based active-standby configuration to ensure high availability and fault tolerance. The system assigns a Virtual IP (VIP) that always points to the active instance, enabling seamless traffic handling. Further, a heartbeat mechanism is used for continuous health monitoring between the active and standby instances. If the heartbeat stops or indicates failure, then the system 108 triggers an automatic switch to the standby instance, ensuring uninterrupted service.

[0076] In an embodiment, the synchronization module 216 is configured to maintain configuration consistency between a primary (active) processing instance and a secondary standby instance. The primary processing instance actively processes the one or more SMS, while the secondary standby instance continuously synchronizes data with the primary processing instance, and maintains a synchronized copy of configuration data and operational state. This redundancy and failover mechanism contribute to the unique reliability and uptime guarantees. Furthermore, the configuration updates that are applied to the primary processing instance are replicatedto the secondary standby instance via a publish-subscribe messaging pattern. The publish-subscribe messaging pattern is a communication model commonly used in distributed systems to enable asynchronous, decoupled data exchange between system components, such as the filtering module 210, the routing module 214, etc. The primary processing instance acts as a publisher, broadcasting configuration updates, state changes, and synchronization data to a message broker. The secondary standby instance acts as a subscriber, receiving those updates in real time to maintain synchronization with the primary processing instance. Upon detection of the primary processing instance failure, degradation, or scheduled maintenance event, the secondary standby instance is automatically promoted to the active role without service disruption. The failover process utilizes a heartbeat monitoring mechanism to ensure deterministic switchover within predefined thresholds. Once promoted, the secondary standby instance continues SMS processing using the most recent configuration and operational state, ensuring continuity and message delivery reliability. This activestandby redundancy architecture enables fault tolerance, minimizes downtime, and provides seamless operational continuity, thereby enhancing the overall reliability, resilience, and uptime guarantees of the system 108.

[0077] In an embodiment, the synchronization module 216 is configured to publish configuration changes to a distributed data stream when runtime modifications occur. The configuration changes refer to runtime-modifiable operational parameters that govern message processing, routing logic, filtering behaviour, and system-level control operations. The configuration changes may be triggered by network operators, service providers, or automated orchestration systems to adapt to new routing policies, regulatory requirements, or operational conditions. Such configuration changes but are not limited to, routing rules, filtering rules (blocklists or whitelists), operator-specific delivery policies, path-priority weights, load-balancing thresholds, and protocol- level parameters. In an aspect, the synchronization module 216 formats the configuration change as a structured message (such as a JSON, XML, or protocol-buffer message)and publishes it into the distributed data stream. The system 108 may use Redis Streams, Kafka, or equivalent data stream for publishing the configuration changes. Additionally, the synchronization module 216 is configured to consume the configuration changes from the distributed data stream by the secondary standby instance and store deferred messages in a persistent storage during instance transition. Further, the synchronization module 216 is configured to process the stored deferred messages after the successful role transition.

[0078] In an example, a data stream (such as a Redis Streams, Kafka, etc.) may be utilized as the distributed data stream for managing real-time synchronization events between the primary processing instance and secondary standby instances. When configuration updates occur in the primary processing instance, the synchronization module 216 publishes the updates as stream entries into the redis data stream, identified by a specific stream key. The secondary standby instance, acting as a consumer within a redis consumer group, continuously listens to the same stream and retrieves the published configuration updates in the order they are generated before. In case of a primary processing instance failure or planned switchover, the secondary standby instance processes all unacknowledged or deferred messages stored in Redis persistent storage to ensure that no configuration updates are lost. Once the secondary instance assumes the primary role, it continues consuming new messages from the stream, thereby ensuring continuous synchronization, consistency, and fault-tolerant configuration replication across system instances.

[0079] In an embodiment, the synchronization module 216 is configured to manage deferred messages during an instance role transition. The term deferred messages refers to configuration updates, routing-table modifications, whitelist or blacklist changes, or any control messages that are generated while the system 108 is undergoing a transition from the primary processing instance to the secondary standby instance. Since these messages cannot be applied immediately during the transitionwindow, they are temporarily captured and stored for later processing to ensure state consistency.

[0080] In an embodiment, the deferred messages are stored in a persistent database that supports reliable message durability and ordered retrieval. The database may include, but not limited to, for example, a Redis Stream entry, a Kafka topic partition, a or a PostgreSQL transaction log. Each deferred message is stored with metadata such as a timestamp, sequence identifier, message type, and originating component. The synchronization module 216 writes these messages to the persistent storage using an append-only, sequential commit mechanism to avoid loss during unexpected failures.

[0081] In an embodiment, a transition sequence is initiated upon detection of a primary processing instance failure or a planned maintenance event. The transition sequence includes a series of ordered steps executed to safely transfer operational responsibility from the primary processing instance to the secondary standby instance. The steps include detecting failure of the primary instance via heartbeat timeouts or health-check failures, retrieving the most recent synchronized state from the replicated configuration store, promoting the standby instance to the active state, and replaying and applying all deferred messages stored in the persistent database in chronological order.

[0082] In an embodiment, the transition sequence ensures that the newly promoted primary instance resumes message processing with a fully consistent and up-to-date configuration state. By applying deferred messages after role promotion, the system 108 preserves configuration integrity, prevents state divergence, and guarantees operational continuity without requiring operator intervention.

[0083] In an embodiment, the system 108 supports runtime configuration management, enabling configuration changes to be applied without serviceinterruption. These configuration inputs may be provided by network operators, system administrators, or external provisioning platforms through multiple control channels such as a web-based management interface, a Command-Line Interface (CLI), or a Network Management System (NMS). In an aspect, the CLI allows authorized administrators to directly modify operational parameters, update routing rules, initiate debugging commands, or trigger maintenance mode at runtime. Similarly, the NMS enables centralized management, where configuration templates, operator-specific rule sets, and performance thresholds can be pushed to the system using northbound interfaces (e.g., SNMP, NETCONF, REST-based NMS adapters). The system administrators (i.e., the user 102) may use these interfaces to revise SMS handling rules, activate promotional or time-bound routes, enforce regulatory mandates, or temporarily restrict suspicious sources. The system 108 validates these inputs, maintains version control, and applies the updated configurations in real time without disrupting ongoing SMS processing.

[0084] In an embodiment, the system 108 may include monitoring and analytics capabilities to track system performance, message delivery rates and alarms. These capabilities provide valuable tools for troubleshooting and system optimization by enabling system administrators or operators to identify and address issues promptly. Additionally, by analyzing messaging patterns and trends, the system administrators can gain insights that facilitate ongoing enhancements to both performance and reliability. This monitoring framework ensures operational stability and contributes to more efficient resource allocation and proactive management, ultimately improving the quality of service offered to end-users.

[0085] Although FIG. 2 shows exemplary components of the system 108, in other embodiments, the system 108 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of thesystem 108 may perform functions described as being performed by one or more other components of the system 108.

[0086] FIG. 3 illustrates an exemplary system architecture 300 configured to route the one or more SMS in the network, in accordance with an embodiment of the present disclosure. FIG. 3 is explained in conjunction with FIG. 1 and FIG. 2.

[0087] In an embodiment, the system architecture 300 (interchangeably referred to as SMS hub architecture 300) includes one or more short message service centers (SMSCs) 302-1, 302-2 . ,.302-N, an Internet protocol (IP) network 304, a mobile number portability (MNP) database 306 (referred to as the IMNP database in FIG.2), an international long distance (ILD) SMS hub cluster 308, a signalling system No. 7 (SS7) microservice component 310, an SS7 network 312, a signal transfer point (STP) node 314, a network management system (NMS) 316, a database 318, an international long distance (ILD)-engine cluster 320, a graphical user interface (GUI) 322 and a command line interface (CLI) 324.

[0088] In an aspect, the SMSCs 302 act as message delivery entities capable of transmitting and receiving the one or more SMS messages across operator networks. In an example, the SMSCs 302 may receive the one or more SMS from mobile networks, SMS gateways, messaging platforms, aggregators, and the like. A person of ordinary skill in the art will understand that one or more SMSCs 302-1, 302-2...302-N may be collectively referred to as the SMSC 302. In an embodiment, the SMSCs 302 are configured for storing, processing, and forwarding the one or more SMS. Further, the one or more SMSCs 302-(l-N) handles high volumes of SMS traffic and allows for scalable message routing. The SMSCs 302 may support messaging protocols, such as the SMPP, HTTP, and the SS7 protocols, for the incoming SMS traffic.

[0089] In an aspect, the SMSCs 302-(l -N) are communi cably coupled to the IP network 304, facilitating the message flow through the system architecture 300. The IPnetwork 304 forms the core communication backbone for routing the one or more SMS and connecting to various components within the system architecture 300. The IP network 304 facilitates the transmission of the one or more SMS from the SMSCs 302 to the ILD-SMS hub cluster 308, enabling real-time message processing. The IP network 304 interface may use standard protocols, such as the HTTP or the SMPP, to simplify integration between the SMSCs 302 and the ILD-SMS hub cluster 308. By using standard IP-based protocols like the SMPP or HTTP, the system architecture 300 ensures that the one or more SMS are transferred reliably between other components. Further, the incoming one or more SMS are processed and normalized into a standardized format for further routing and processing.

[0090] In an aspect, the MNP database 306 performs number portability lookups to determine the current network operator for a given destination mobile number. The MNP database 306 operates together with the vendor integration component (referred to as the query module 212 in FIG. 2) within the system architecture 300. The MNP database 306 facilitates seamless access to up-to-date information on number portability, ensuring accurate routing by identifying the current network provider associated with each recipient’s mobile number.

[0091] In an embodiment, the MNP database 306 stores operator data, which is used to determine the correct routing for the one or more SMS when recipients have ported their numbers to different carriers. By checking the MNP database 306, the system architecture 300 ensures accurate message delivery, bypassing unnecessary routing steps and directing messages to the appropriate network of the ported number.

[0092] In an aspect, the system 300 enables integration with multiple vendors. The vendor integration component manages the connections and communication with these vendors, retrieving the necessary operator data from multiple vendors, such that when the one or more SMS that require access to the MNP database 306, the vendor1integration component retrieves the necessary operator data such as MCC (Mobile Country Code), MNC (Mobile Network Code), and the like.

[0093] In an embodiment, the ILD-SMS hub cluster 308 functions as a rule engine responsible for processing, normalizing, and managing the routing decisions for the one or more received SMS messages. In operation, the one or more SMS received from various sources (such as SMSCs, gateways, or application servers) over supported interfaces like SMPP or HTTP are first processed and normalized into a standardized internal message format. Once normalized, the ILD-SMS hub cluster 308 applies filtering operations by comparing the source and destination addresses of each SMS against the predefined whitelist and blacklist. Based on the comparison, each SMS is classified as either allowed or blocked. Blocked messages are discarded or logged for compliance purposes, while allowed messages proceed to the routing decision stage. For each allowed SMS, the ILD-SMS hub cluster 308 communicates with the MNP database 306 using a Telephone Number Mapping (ENUM) interface to perform an MNP query and retrieve parameters such as the MCC and MNC associated with the destination address. After retrieving the MNP data, the ILD-SMS hub cluster 308 evaluates a set of predefined routing rules and policies, which may be configured dynamically through an administrative user interface. Based on this evaluation, the ILD-SMS hub cluster 308 determines one or more initial routing paths for each allowed SMS. In summary, the ILD-SMS hub cluster 308 acts as the core decision-making engine within the system 108 handling message normalization, filtering, MNP query execution, and rule-based routing decisions to ensure accurate, compliant, and cost-optimized SMS delivery.

[0094] In an embodiment, the ILD-SMS hub cluster 308 implements a virtual IP (VlP)-based active-standby setup to ensure high availability, reliability, and fault tolerance of SMS processing operations. The VIP-based active- standby setup includes two instances, ILD-SMSHub 1 (active) and ILD-SMSHub 2 (standby), collectivelyforming a redundant processing pair within the cluster 308. In operation, the ILD-SMSHub 1 (active instance) functions as the primary processing instance, responsible for receiving incoming one or more SMS, performing normalization, executing filtering and MNP queries, and determining the initial routing paths based on the predefined routing rules and path-selection criteria. The ILD-SMSHub 2 (standby instance) operates in a passive mode under normal conditions, maintaining a real-time synchronized copy of configuration data, routing rules, and message states from the active instance. The synchronization between the active and standby instances (ILD-SMSHub 1 (active) and ILD-SMSHub 2 (standby)) is managed through continuous data replication and heartbeat monitoring using the virtual IP address. This allows the standby instance to monitor the health status of the active instance and remain ready to take over processing responsibilities instantaneously. A heartbeat mechanism is used for continuous health monitoring between the active and standby instances. If the heartbeat stops or indicates failure, failover detection triggers an automatic switch to the standby instance, ensuring uninterrupted service.

[0095] In the event of a failure, network disruption, or scheduled maintenance affecting the active instance, the virtual IP is automatically reassigned to the standby instance, which then assumes the active role without service interruption. This seamless failover mechanism ensures uninterrupted SMS routing operations, preserves session continuity, and minimizes downtime. The VIP-based active-standby architecture of the ILD-SMS hub cluster 308 provides a robust fault-tolerant mechanism, guaranteeing continuous message processing, data consistency, under failure conditions.

[0096] In an aspect, the routing decision made by the ILD-SMS hub cluster 308 is passed to a routing manager component. The routing manager component (not shown in the FIG. 3 for the sake of simplicity) determines at least one optimal route for each of the one or more SMS, considering factors like cost. Further, the routing managercomponent determines if the one or more SMS need to be routed through the SS7 network 312 or the SMPP. Upon determining that the one or more SMS needs to be routed through the SS7 network 312, the one or more SMS is forwarded to the SS7 microservice component 310. The ILD-SMS hub cluster 308 sends the one or more SMS to the SS7 microservice component 312 using the HTTP protocol.

[0097] In an aspect, the SS7 microservice component 310 is designed to handle SS7 traffic, a protocol widely used in telecommunications networks. The SS7 microservice component 310 efficiently processes and routes each of the one or more SMS through the SS7 protocol while integrating with the rest of the system components. The SS7 microservice component 310 encapsulates the logic for processing and routing SS7 traffic, ensuring compatibility with the protocol.

[0098] In an aspect, within the SS7 microservice component 310, two frontend (FE) instances: a front-end 1 active instance (FE1 active) and a front-end 2 standby instance (FE2 standby), work in sequence to route the one or more SMS. The FE instances act as an intermediary for the one or more SMS that require SS7 transport. The FE instance takes routing instructions from the routing manager component and forwards these messages to the SS7 network 312. In this setup, FE1 active handles primary routing duties, while FE2 standby is on standby mode to take over if the active FE instance fails. This redundancy prevents service interruptions, maintaining reliable message flow even during faults.

[0099] In an aspect, the STP node 314 is a core SS7 network 312 element that routes the one or more SMS to the at least one destination entity. The STP node 314 directs messages from the SS7 network 312 to the appropriate destination by translating global addresses, balancing the message load, and ensuring network resilience through alternate routing paths.

[0100] In an aspect, the NMS 316 allows for real-time monitoring and management of the SS7 microservice component 310. This connection enables quick diagnostics and alerting for issues related to SS7 messaging.

[0101] In an embodiment, if the SMS are to be relayed over SMPP based on the routing decision, the ILD-SMS hub cluster 308 selects the appropriate channel for transmitting the one or more SMS using the SMPP protocol. If more than one channel is available, the ILD-SMS hub cluster 308 selects the channels in a round-robin fashion.

[0102] In an aspect, the ILD-SMS hub cluster 308 relays the deferred one or more SMS to the database 318 over a transmission control protocol (TCP). Once the required status update or availability of resources is confirmed, the database 318 relays the deferred message over the TCP to the ILD-SMS hub cluster 308. Subsequently, the ILD-SMS hub cluster 308 forwards the one or more SMS over the HTTP to the SS7 microservice component 310, which is responsible for further message transmission to the designated the SS7 network 312.

[0103] In an aspect, using the NMS 316, system administrators (such as the user 102) may oversee the operational health, status, and performance of the components within the system architecture 300. Using the NMS 316, the system administrators may observe the SS7 microservice component 310 over the HTTP protocol to detect and resolve any issues promptly.

[0104] In an aspect the NMS 316 may perform monitoring and analysis operations to track system performance, message delivery rates and alarms such that, the analysis and monitoring data can be used for troubleshooting, optimization, and gaining insights into messaging patterns for further improving the system 108.

[0105] In an aspect, the GUI 322 allows the system administrators to interact with and manage the system 300. Through the GUI 322, the system administrators can configure routing and filtering rules, monitor message flow, and view analytics. TheGUI 322 may provide a user-friendly platform for managing the ILD-engine cluster 320 (for example, using the HTTP protocol) and making real-time adjustments as needed.

[0106] In an aspect, the ILD-engine cluster 320 may perform as a backend node for the GUI 318. In the ILD-engine cluster 320, the two ILD instances: ILD engine 1 (Active) function as a primary backend, whereas ILD-engine 2 (Standby) functions as a backup and performs the operations if the ILD-engine 1 (active) encounters any issue.

[0107] In an aspect, the CLI 3243 provides a text-based management interface to the system administrators. The CLI 324 allows direct access to configure, control, and monitor SS7 and SMS routing settings, particularly within the SS7 microservice component 310 connected using the HTTP protocol.

[0108] FIG. 4 illustrates an exemplary flow diagram of a method 400 for routing the one or more SMS in the network 106, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIG. 2.

[0109] At step 402, the method 400 includes receiving, by the receiving module 208, the one or more SMS from the at least one source such as such as mobile networks, gateways, or other platforms.

[0110] At step 404, the method 400 includes extracting, by the receiving module 208, the message metadata from each of the one or more SMS where the message metadata includes at least the source address and the destination address;

[0111] At step 406, the method 400 includes performing, by the filtering module 210, the message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing. To perform the message filtering, the filtering module 210 is configured to compare the source address and the destination address of each allowed SMS against thepredefined whitelist, including the one or more authorized source addresses and destination addresses and the predefined blacklist, including the one or more restricted source addresses and destination addresses. Further, the filtering module 210 is configured to classify the one or more SMS as allowed when the source address and the destination address match any one of the one or more authorized source addresses and destination addresses within the predefined whitelist. Conversely, the filtering module 210 is configured to classify the one or more SMS as blocked when the source address and the destination address match any one of the one or more restricted source addresses and destination addresses within the predefined blacklist.

[0112] At step 408, the method 400 includes executing, by the query module 212, the MNP query for each SMS classified as allowed, to determine a current network operator associated with the destination address.

[0113] At step 410, the method 400 includes identifying, by the routing module 214, the at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on the result of the MNP query. The MNP query result may include but not limited to the current network operator identifier, the MCC, the MNC, the ported number flag, or the routing prefix associated with the destination address.

[0114] At step 412, the method 400 includes selecting, by the routing module 214, the optimal routing path from the plurality of available routing paths for each allowed SMS. In order to select the optimal route from the plurality of available routes for each allowed SMS, the routing module 214 is configured to retrieve the one or more applicable routing rules based on the message metadata from the database 218. Further, the routing module 214 is configured to evaluate each allowed SMS against the retrieved applicable routing rules using the result of MNP query as routing parameters and determine a routing priority based on the at least one of: message type or cost optimization. In an aspect, the routing priority may additionally depend on one or moreof: protocol availability, channel availability, network latency, hop count, load distribution, vendor preference, or rule engine parameter

[0115] At step 414, the method includes forwarding, by the routing module, each allowed SMS to the identified at least one destination entity via the selected optimal routing path.

[0116] In an aspect, the synchronization module 216 is configured to, maintain configuration consistency between a primary processing instance and a secondary standby instance, where the primary processing instance actively processes the one or more SMS and the secondary standby instance maintains a synchronized copy of configuration data and operational state. Further, configuration updates applied to the primary processing instance are replicated to the secondary standby instance via a publish-subscribe messaging pattern. Upon detection of primary processing instance failure, the secondary standby instance automatically assumes the primary role with the current configuration state.

[0117] In an aspect, the synchronization module 216 is configured to publish configuration changes to the distributed data stream (e.g, Redis data stream, kafka or other equivalent distributed data streams) when runtime modifications occur, such as changes in configuration. Additionally, the synchronization module 216 is configured to consume configuration changes from the distributed data stream by the secondary standby instance. The synchronization module 216 is further configured to store deferred messages in a persistent storage during instance transition and process the stored deferred messages after a successful role transition. This redundancy mechanism contributes to the reliability and uptime guarantees of the system 108.

[0118] FIG. 5 illustrates an example computer system 500 in which or with which the embodiments of the present disclosure may be implemented.

[0119] As shown in FIG. 5, the computer system 500 may include an external storage device 510, a bus 520, a main memory 530, a read-only memory 540, a mass storage device 550, a communication port 560, and a processor 570. A person skilled in the art will appreciate that the computer system 500 may include more than one processor 570 and communication ports 560. The processor 570 may include various modules associated with embodiments of the present disclosure.

[0120] The communication port 560 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 fibre, a serial port, a parallel port, or other existing or future ports. The communication port 560 may be chosen depending on the network 106, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 500 connects.

[0121] The memory 530 may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory 540 may be any static storage device(s), e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information, e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 570.

[0122] The mass storage 550 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, Parallel Advanced Technology Attachment (PATA) or 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).

[0123] The bus 520 communicatively couples the processor(s) 570 with the other memory, storage, and communication blocks. The bus 520 may be, e.g., aPeripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems, as well as other buses such as a front side bus (FSB), which connects the processor 570 to the computer system 500.

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

[0125] In an embodiment, the one or more modules described in the FIG. 2 such as the receiving module 208, the filtering module 210, the query module 212, the routing module 214, and the synchronization module 216 are implemented by the processor 570 of the electronic device 500. The processor 570 executes instructions stored in the memory 530 and utilizes the mass storage 550 to maintain configuration data, routing rules, temporary message buffers, and synchronization state. In an aspect, the memory 530 provides the runtime environment required for executing software components corresponding to each module, while the mass storage 550 serves as a nonvolatile repository for persistent datasets, deferred messages, and system logs.

[0126] In an exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to perform a method for routing one or more short message services (SMS) in a network, is described. The method includes receiving, by a receiving module, one or more short message services (SMS) from at least one source. The method further includes extracting, by the receiving module, message metadata from each of the oneor more SMS, where the message metadata includes at least a source address and a destination address. The method further includes performing, by a filtering module, message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing. The method further includes executing, by a query module, a mobile number portability (MNP) query for each SMS classified as allowed, to determine a current network operator associated with the destination address. The method further includes identifying, by a routing module, at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query. The method further includes selecting, by the routing module, an optimal routing path from a plurality of available routing paths for each allowed SMS. The method further includes forwarding, by the routing module, each allowed SMS to the identified at least one destination entity via the selected optimal routing path.

[0127] The present disclosure provides a technical advancement in the field of short message service (SMS) routing and hub management within communication networks. The system introduces a modular and high-availability SMS hub architecture that overcomes the rigidity and operational inefficiencies of conventional monolithic SMS hub architectures or systems. The SMS hub architecture implements a Virtual Internet Protocol (VlP)-based active-standby configuration to ensure seamless failover, high availability, and fault tolerance while maintaining continuous service operation through deferred message storage in databases. Additionally, the SMS hub architecture integrates one or more dedicated microservices for handling Signaling System No. 7 (SS7) and Short Message Peer-to-Peer (SMPP) traffic, enabling scalability and efficient processing of various message formats. Furthermore, the SMS hub architecture includes a rule engine for dynamic SMS filtering and routing, enabling intelligent decision-making based on configurable parameters, including cost, destination, and network operator. The rule engine is managed by network operators through a graphical user interface (GUI) and command-line interface (CLI) that allowreal-time configuration, rule management, and monitoring without service interruption, thereby improving system flexibility and operational control.

[0128] Additionally, the SMS hub architecture ensures vendor independence by supporting integration with multiple International Mobile Number Portability (MNP) database providers, reducing dependency on proprietary solutions and optimizing routing efficiency. Overall, the SMS hub architecture significantly enhances reliability, scalability, fault recovery, and cost optimization, while ensuring regulatory compliance and interoperability across different messaging environments, thus providing a substantial improvement over conventional SMS hub architecture.

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

[0130] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0131] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the disclosure and not as limitation.ADVANCEMENTS OF THE PRESENT DISCLOSURE

[0132] The present disclosure described herein above has several technical advantages as follows:

[0133] The present disclosure provides an optimized and flexible approach for routing Short Message Services (SMS) within a communication network, addressing the limitations of conventional monolithic and vendor- dependent SMS hub architectures.

[0134] The present disclosure provides a system architecture i.e., a SMS hub architecture that supports multiple messaging interfaces, such as hypertext transfer protocol (HTTP), Short Message Peer-to-Peer (SMPP), and Signaling System No. 7 (SS7), providing compatibility and interoperability across diverse network environments and messaging protocols.

[0135] The present disclosure provides a system architecture that implements a Virtual Internet Protocol (VlP)-based active-standby configuration that ensures high availability and fault tolerance. The standby instance continuously synchronizes operational and configuration data with the active instance, thereby enabling seamless failover during failures or maintenance activities. Deferred messages are persistently stored in a database to guarantee reliable message delivery post-recovery.

[0136] The present disclosure provides a system architecture that incorporates a graphical user interface (GUI) for intuitive rule management, allowing authorized users to create, modify, and manage SMS routing and filtering rules in real time without service disruption.

[0137] The present disclosure offers flexibility in integrating with multiple vendors to access an International Mobile Number Portability (MNP) database. This vendor-agnostic approach ensures the seamless adaptation of different regional requirements and avoids vendor lock-in issues.

[0138] The present disclosure provides a cost-effective solution to address high operational costs in SMS routing by introducing dynamic and flexible routing decisions based on multiple factors. This dynamic routing capability ensures reduced operational expenses through optimized, least-cost routing.

[0139] The present disclosure provides a dedicated rule engine that enables dynamic configuration of message filtering and routing rules. The filtering functionality supports whitelisting and blacklisting based on predefined criteria, while the routing functionality allows selection of optimal paths based on parameters such as cost, destination, and network operator.

[0140] The present disclosure provides a system architecture that supports least-cost routing, enabling cost optimization by dynamically selecting routes that minimize operational expenditure while maintaining message delivery quality.

Claims

1. CLAIMS1. A method (400) for routing one or more short message services (SMS) in a network (106), the method (400) comprising:3.receiving (402), by a receiving module (208), the one or more short message services (SMS) from at least one source;4.extracting (404), by the receiving module (208), message metadata from each of the one or more SMS, wherein the message metadata includes at least a source address and a destination address;5.performing (406), by a filtering module (210), message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing;6.executing (408), by a query module (212), a mobile number portability (MNP) query for each SMS classified as allowed, to determine a current network operator associated with the destination address;7.identifying (410), by a routing module (214), at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query;8.selecting (412), by the routing module (214), an optimal routing path from a plurality of available routing paths for each allowed SMS; and forwarding (414), by the routing module (214), each allowed SMS to the identified at least one destination entity via the selected optimal routing path.

2. The method (400) as claimed in claim 1, wherein selecting the optimal route from the plurality of available routing paths for each allowed SMS comprises:retrieving, by the routing module (214), one or more applicable routing rules based on the message metadata from a database;10.evaluating, by the routing module (214), each allowed SMS against the retrieved applicable routing rules using the result of the MNP query as routing parameters; and11.determining, by the routing module (214), a routing priority based on at least one of: message type or cost optimization.

3. The method (400) as claimed in claim 1, wherein performing the message filtering comprises:13.comparing, by the filtering module (210), the source address and destination address of the one or more SMS against a predefined whitelist comprising one or more authorized source addresses and destination addresses and a predefined blacklist comprising one or more restricted source addresses and destination addresses;14.classifying, by the filtering module (210), the one or more SMS as allowed when the source address and the destination address match any one of the one or more authorized source addresses and destination addresses within the predefined whitelist; or15.classifying, by the filtering module (210), the one or more SMS as blocked when the source address and the destination address match any one of the one or more restricted source addresses and destination addresses within the predefined blacklist.

4. The method (400) as claimed in claim 1, further comprising:maintaining, by a synchronization module (216), configuration consistency between a primary processing instance and a secondary standby instance, wherein:17.the primary processing instance actively processes the one or more SMS;18.the secondary standby instance maintains a synchronized copy of configuration data and operational state;19.configuration updates applied to the primary processing instance are replicated to the secondary standby instance via a publish-subscribe messaging pattern; and20.upon detection of primary processing instance failure, the secondary standby instance automatically assumes the primary role with the current configuration state.

5. The method (400) as claimed in claim 4, further comprising:22.publishing, by the synchronization module (216), configuration changes to a distributed data stream when runtime modifications occur;23.consuming, by the synchronization module (216), the configuration changes from the distributed data stream by the secondary standby instance;24.storing, by the synchronization module (216), deferred messages in a persistent storage during instance transition; and25.processing, by the synchronization module (216), the stored deferred messages after a successful role transition.

6. A system (108) for routing one or more short message services (SMS) in a network (106), the system (108) comprising:27.a receiving module (208) configured to:28.receive one or more short message services (SMS) from at least one source; extract message metadata from each of the one or more SMS, wherein the message metadata includes at least a source address and a destination address;29.a filtering module (210) configured to perform message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing;30.a query module (212) configured to execute a mobile number portability (MNP) query for each SMS classified as allowed, to determine a current network operator associated with the destination address;31.a routing module (214) configured to:32.identify at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query;33.select an optimal routing path from a plurality of available routing paths for each allowed SMS; and34.forward each allowed SMS to at least one destination entity via the selected optimal routing path.

7. The system (108) as claimed in claim 6, wherein to select the optimal route from the plurality of available routes for each allowed SMS, the routing module (214) is further configured to:36.retrieve one or more applicable routing rules based on the message metadata from a database;37.evaluate each allowed SMS against the retrieved applicable routing rules using the result of MNP query as routing parameters; and38.determine a routing priority based on at least one of: message type or cost optimization.

8. The system (108) as claimed in claim 6, wherein to perform the message filtering, the filtering module (210) is further configured to:39.compare the source address and the destination address of the one or more SMS against a predefined whitelist comprising one or more authorized source addresses and destination addresses, and a predefined blacklist comprising one or more restricted source addresses and destination addresses;40.classify the one or more SMS as allowed when the source address and the destination address match any one of the one or more authorized source addresses and destination addresses within the predefined whitelist; or classify the one or more SMS as blocked when the source address and the destination address match any one of the one or more restricted source addresses and destination addresses within the predefined blacklist.

9. The system (108) as claimed in claim 6, further comprises a synchronization module (216) configured to:42.maintain configuration consistency between a primary processing instance and a secondary standby instance, wherein:43.the primary processing instance actively processes the one or more SMS;44.the secondary standby instance maintains a synchronized copy of configuration data and operational state;45.configuration updates applied to the primary processing instance are replicated to the secondary standby instance via a publish-subscribe messaging pattern; and46.upon detection of primary instance failure, the secondary standby instance automatically assumes the primary role with the current configuration state.

10. The system (108) as claimed in claim 6, wherein the synchronization module (216) is further configured to:47.publish configuration changes to a distributed data stream when runtime modifications occur;48.consume the configuration changes from the distributed data stream by the secondary standby instance;49.store deferred messages in a persistent storage during instance transition; and50.process the stored deferred messages after a successful role transition.

11. 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 (400) for routing one or more short message services (SMS) in a network (106), the method (400) comprising:52.receiving (402), by a receiving module (208), the one or more short message services (SMS) from at least one source;53.extracting (404), by the receiving module (208), message metadata from each of the one or more SMS, wherein the message metadata includes at least a source address and a destination address;54.performing (406), by a filtering module (210), message filtering on the received one or more SMS based on the extracted message metadata to classify each SMS as allowed or blocked for routing;55.executing (408), by a query module (212), a mobile number portability (MNP) query for each SMS classified as allowed, to determine a current network operator associated with the destination address; identifying (410), by a routing module (214), at least one destination entity capable of delivering each allowed SMS to the determined current network operator based on result of the MNP query;56.selecting (412), by the routing module (214), an optimal routing path from a plurality of available routing paths for each allowed SMS; and forwarding (414), by the routing module (214), each allowed SMS to the identified at least one destination entity via the selected optimal routing path.

Images