Method and system for transmitting emergency short message service in a network

Abstract

The disclosure provides a method (500) and a system (108) for transmitting emergency short message service (SMS) in a network (106). The method includes receiving an emergency SMS from UE (104). The method includes retrieving an HPLMN of the UE (104) from a QNPDB (306). The method includes initiating a request to an HSS (308) to obtain the UE's location information, which includes a cell-specific identifier (NRCGID) and visited network information (VPLMN). The method includes determining the type of network to which the UE (104) is currently attached and retrieving the location information accordingly. The method includes identifying SMSC (s) (304-2) based on the retrieved location information. The method includes transmitting the emergency SMS to the determined SMSC(s) (304-2), ensuring seamless delivery and effective handling of emergency communications. The method and the system enhance reliability and accuracy in routing emergency SMS across diverse network environments.

Description

METHOD AND SYSTEM FOR TRANSMITTING EMERGENCY SHORT MESSAGE SERVICE IN A NETWORKRESERVATION 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 transmitting emergency short message service (SMS) in a network.DEFINITION

[0003] The expression ‘Emergency short message service (SMS)’ as used hereinafter in the specification refers to a text message sent by a user or a subscriber to designated numbers (e.g., 112) to request assistance during emergencies.

[0004] The expression ‘Emergency SMS Gateway (ESG)’, as used hereinafter in the specification, refers to a server or a network entity responsible for handling and routing the emergency SMS. The ESG extracts the subscriber's location data, determines the appropriate emergency entity, and ensures the successful delivery of the emergency SMS in a network.

[0005] The expression ‘Public Safety Answering Point (PSAP)’ as used hereinafter in the specification refers to a centralized emergency response center or emergency entity that receives and manages emergency communications, such as SMS or calls, routed by the ESG. The PSAP connects the subscriber to appropriate emergency services based on their location.

[0006] The expression ‘New Radio Cell Global Identifier (NRCGID)’ as used hereinafter in the specification refers to a unique identifier for a specific 5G cell in the network. The NRCGID helps to determine the subscriber's location within the 5G network, enabling accurate routing of emergency SMS to the relevant PSAP or emergency entity.

[0007] The expression ‘Sh User-Data-Request’ as used hereinafter in the specification refers to a command or a signaling request sent by the ESG to a Home Subscriber Server (HSS) to fetch the subscriber’s location information, including visited network and cell-specific identifiers, essential for routing emergency messages.

[0008] The expression ‘Sh User-Data- Answer (Sh-UDA)’ as used hereinafter in the specification refers to a command or a response sent by the HSS to the ESG in response to the Sh-UDR. The Sh-UDA includes the subscriber's location details, such as visited public land mobile network (VPLMN) information.

[0009] The expression ‘Configuration repository’, as used hereinafter in the specification, refers to a module that may perform as a repository or database. The configuration repository may store PSAP mappings, configuration data, and NRCellGloballds (NRCGIDs), enabling the ESG to determine the appropriate PSAPs based on the subscriber’s location and network details. Additionally, the configuration repository may also handle configuration updates, synchronization with other network elements, enabling reliable and seamless operation across the network.

[0010] The expression ‘QNPDB’ as used hereinafter in the specification refers to a Query Network Portability Database, which is a centralized repository configured to store, manage, and provide mobile number portability (MNP) related routing information. The QNPDB maintains mappings between Mobile Station International Subscriber Directory Number (MSISDNs) and their corresponding home or recipient networks, along with portability indicators, routing prefixes, and associated network identifiers.

[0011] The expression ‘NAPTR query’ as used hereinafter in the specification refers to a Naming Authority Pointer (NAPTR) domain name system (DNS) lookup request that is executed in the QNPDB to obtain service-specific routing information associated with a given identifier, such as the MSISDN. The NAPTR query is utilized to retrieve structured data records containing parameters such as the subscriber’s Home Public Land Mobile Network (HPLMN) information, including Mobile Country Code (MCC) and Mobile Network Code (MNC), portability status, and routing domain details from the QNPDB.

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

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

[0014] Emergency Short Message Service (SMS) is a vital feature in telecommunications that enables subscribers to send concise text messages during emergencies, ensuring quick and reliable communication with public safety entities,such as Public Safety Answering Points (PSAPs). The emergency SMS feature enables subscribers to seek help in urgent scenarios when voice calls may not be feasible due to various conditions, such as environmental noise or network congestion. Emergency SMS is often prioritized within a network to ensure rapid delivery, even under heavy traffic conditions.

[0015] Currently, an Emergency SMS Gateway (ESG) is used to route emergency SMS messages to the emergency centers. The ESG facilitates the delivery of emergency SMS by determining the subscriber's location and routing the message to their associated PSAP or Short Message Service Centre (SMSC).

[0016] However, in the existing technique, a significant challenge arises in the ESG for subscribers connected to a fifth-generation (5G) network. In the existing technique, the ESG fails to deliver the emergency SMS when the subscribers are connected to the 5G network. This failure may occur due to the differences in the architecture of the 5G network compared to other networks (for example, fourth generation (4G) network). Additionally, the reason for these failures is the dependency of current ESG implementations on signaling and location-routing protocols, specifically designed for 4G networks. As a result, when the subscriber is connected to the 5G network, these mechanisms may not function correctly, leading to incomplete routing or dropped messages. This failure may disrupt emergency communication pathways and potentially result in threatening consequences for subscribers who cannot transmit vital information during emergencies.

[0017] 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

[0018] In an exemplary embodiment, a method for transmitting emergency short message services (SMS) in a network is described. The method includesreceiving, by a first network entity, at least one emergency SMS from at least one user equipment (UE), where the at least one emergency SMS includes a source address and a destination address. The method further includes forwarding, by the first network entity, the at least one emergency SMS, including the source address and the destination address, to a second network entity. The method further includes retrieving, by the second network entity, a first network identifier based on the received source address from a network database upon receiving the at least one emergency SMS. The method further includes initiating, by the second network entity, at least one location request to a third network entity, where the at least one location request includes one or more network parameters and the retrieved first network identifier. The method further includes receiving, by the second network entity, at least one response from the second network entity, where the at least one response includes location information of the at least one UE, including a second network identifier and a third network identifier. The method further includes determining, by the second network entity, a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier. The method further includes modifying, by the second network entity, the destination address of the at least one emergency SMS by replacing it with the determined destination identifier and transmitting the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

[0019] In some embodiments, the method further includes receiving, by the second network entity, a first acknowledgment message from the at least one destination entity and transmitting a second acknowledgment message to the first network entity based on the received first acknowledgment message.

[0020] In some embodiments, the one or more network parameters include at least one of a data reference, a destination reference and a list of network nodes required to process the at least one location request.

[0021] In some embodiments, upon receiving the at least one location request, the third network entity determines a network type associated with the at least one UE based on the received one or more network parameters and the retrieved first network identifier, wherein, based on the determined network type, the third network entity initiates a location information retrieval process.

[0022] In some embodiments, the first network identifier is at least a Home Public Land Mobile Network (HPLMN), the second network identifier is at least a Visited Public Land Mobile Network (VPLMN), and the third network identifier is at least a Network Routing Cell Global Identifier (NRCGID) of the at least one UE.

[0023] In some embodiments, the third network entity is at least a Home Subscriber Server (HSS).

[0024] In another exemplary embodiment, a system for transmitting emergency short message services (SMS) in a network. The system includes a first network entity and a second network entity. The first network entity is configured to receive at least one emergency SMS from at least one user equipment (UE), where the at least one emergency SMS comprises a source address and a destination address and forward the at least one emergency SMS, including the source address and the destination address, to a second network entity. The second network entity includes a processing engine and a memory coupled to the processing engine. The processing engine is configured to retrieve a first network identifier based on the received source address from a network database upon receiving the at least one emergency SMS. The processing engine is further configured to initiate at least one location request to a third network entity, where the at least one location request comprises one or more network parameters and the retrieved first network identifier. The processing engine is further configured to receive at least one response from the third network entity, where the at least one response includes location information of the at least one UE, including a second network identifier and a third network identifier. The processing engine isfurther configured to determine a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier. The processing engine is further configured to modify the destination address of the at least one emergency SMS by replacing it with the determined destination identifier and transmit the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

[0025] In an exemplary embodiment, the present disclosure discloses 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 perform a method for transmitting emergency short message services (SMS) in a network is described. The method includes receiving, by a first network entity, at least one emergency SMS from at least one user equipment (UE), where the at least one emergency SMS includes a source address and a destination address. The method further includes forwarding, by the first network entity, the at least one emergency SMS, including the source address and the destination address, to a second network entity. The method includes retrieving, by the second network entity, a first network identifier based on the received source address from a network database upon receiving the at least one emergency SMS. The method further includes initiating, by the second network entity, at least one location request to a third network entity, where the at least one location request includes one or more network parameters and the retrieved first network identifier. The method further includes receiving, by the second network entity, at least one response from the second network entity, where the at least one response includes location information of the at least one UE, including a second network identifier and a third network identifier. The method further includes determining, by the second network entity, a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier. The method further includes modifying, by the second network entity, the destination address of the at least one emergency SMS byreplacing it with the determined destination identifier and transmitting the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

[0026] 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

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

[0028] An objective of the present disclosure is to provide a system and a method for transmitting emergency short message service (SMS) in a network.

[0029] Another objective of the present disclosure is to provide a system that enables transmitting the emergency SMS when a subscriber is attached or connected to fifth-generation (5G) or sixth-generation (6G) networks, ensuring successful delivery to appropriate emergency entities such as Public Safety Answering Points (PSAPs).

[0030] Yet another objective of the present disclosure is to enable an emergency SMS gateway (ESG) to fetch and process 5G cell (location data) of a subscriber or visited public land mobile network (VPLMN) data in Sh-User Data Request (Sh-UDR).

[0031] Yet another objective of the present disclosure is to ensure robust and efficient handling of the emergency SMS through redundancy, such as distributing messages to multiple SMSCs in a round-robin manner to enhance reliability and network efficiency.

[0032] Yet another objective of the present disclosure is to enhance emergency service routing accuracy by enabling the ESG to determine a correct PSAP using celllevel identifiers.

[0033] 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

[0034] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale; emphasis 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.

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

[0036] FIG. 2 illustrates an exemplary block diagram of the system configured for transmitting emergency SMS in the network, in accordance with embodiments of the present disclosure.

[0037] FIG. 3 illustrates an exemplary system architecture for transmitting emergency SMS in the network, in accordance with an embodiment of the present disclosure.

[0038] FIG. 4 illustrates an exemplary process flow for transmitting emergency SMS in the network, in accordance with an embodiment of the present disclosure.

[0039] FIG. 5 illustrates an exemplary flow diagram of a method for transmitting emergency SMS in the network, in accordance with an embodiment of the present disclosure.

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

[0041] 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 - Processing Engine210 - Database300 - System Architecture 302 - Emergency Short Message Service (SMS) Gateway304, 304-1, 304-2 - Short Message Service Centre (SMSC)306 - Query Network Portability Database (QNPDB)308 - Home Subscriber Server (HSS)310 - Configuration Repository 312 - Public Safety Answering Point (PS AP)400 - Process flow diagram500 - Method Flow Diagram600 - Computer System610 - External Storage Device 620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port(S)670 - ProcessorDETAILED DESCRIPTION

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

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

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

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

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

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

[0048] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on 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.

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

[0050] Emergency SMS Gateway (ESG) is traditionally employed to route emergency short message service (SMS) messages by determining the subscriber’s location and forwarding the message to the appropriate Public Safety Answering Point (PSAP) or Short Message Service Centre (SMSC). However, existing ESG implementations encounter significant challenges when handling emergency SMS for subscribers connected to fifth-generation (5G) networks. In such scenarios, the ESG is unable to complete message delivery, primarily due to architectural differences between 5G and earlier-generation networks (e.g., fourth-generation (4G) networks). Furthermore, current ESG solutions rely on signaling and location-routing procedures designed specifically for 4G systems, which become non-functional or ineffective when the subscriber is registered in a 5G environment. As a result, routing failures, incomplete message transmission, and dropped emergency SMS may occur, jeopardizing critical communication channels and potentially causing life-threatening consequences for subscribers unable to convey essential information during emergencies.

[0051] To overcome these limitations, the present disclosure introduces a method and a system for enabling emergency SMS transmission in 5G and sixthgeneration (6G) networks. The method enables the ESG with the capability to reliably determine location and route emergency SMS to the appropriate PSAP or SMSC even when the subscriber is attached to a 5G or 6G network. This ensures uninterrupted emergency communication, significantly improving reliability, service continuity, and user safety of the ESG.

[0052] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings 1-6.

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

[0054] As illustrated in FIG. 1 , the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2... 104-N associated with one or more users 102-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 collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2... 104-N may be collectively referred to as the UE 104 or the UEs 104. Although only three UE 104 are depicted in FIG. 1, however, any number of the UE 104 may be included without departing from the scope of the ongoing description.

[0055] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a 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 not limited to, intelligent, multisensing, network- connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud- computing system or any other device that is network-connected.

[0056] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, 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 an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.

[0057] In an embodiment, the network 106 may include at least one of a Fourth Generation (4G) network, a Fifth Generation (5G) network, a Sixth Generation (6G) network, or the like. The network 106 may enable the UE 104 to communicate with other devices in the network architecture 100 and / or with the system 108. 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), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0058] In an embodiment, the network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodesthat transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, a wireless network, a wired network, 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.

[0059] In an embodiment, the UE 104 is communicatively coupled with the network 106. The network 106 may receive a connection request from the UE 104. The network 106 may send an acknowledgment of the connection request to the UE 104. The UE 104 may transmit a plurality of signals in response to the connection request.

[0060] In an embodiment, the UE 104 participates in communication with the system 108 through the network 106 when initiating an emergency Short Message Service (SMS). Upon transmission of the emergency SMS by the UE 104, the system 108 may receive associated control-plane and user-plane signaling required for emergency message delivery. Based on the received signaling, the system 108 may identify that the service request corresponds to an emergency SMS procedure. The system 108 may further determine one or more contextual parameters necessary for emergency routing, such as the UE’s location, the serving Radio Access Technology (e.g., LTE or 5G NR), cell identity, and subscription attributes. The system 108 may obtain such contextual parameters by interacting with one or more network functions. Using the information, the system 108 may execute a corresponding mapping, routing, or decision-making procedure to correctly associate the emergency SMS with a Public Safety Answering Point (PSAP) and ensure successful delivery of the emergency SMS.

[0061] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may includefewer 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.

[0062] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for transmitting emergency SMS in the network 106, in accordance with embodiments of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1.

[0063] 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 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 transmit the emergency SMS in the network. 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.

[0064] 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 (I / O), storage devices, and the like.

[0065] In an embodiment, the interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communicationpathway for one or more components of the system 108. Examples of such components include, but are not limited to, a processing engine 208 and a database 210.

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

[0067] The emergency SMS (interchangeably referred to as an emergency message) is a text communication initiated by a user (such as the user 102) or subscriber to report an emergency situation (for e.g., medical emergencies, accidents, natural disasters, security threats, or any condition where voice communication is not possible) to an emergency center, (such as police, ambulance, fire department, and the like) to request immediate help during critical situations. The emergency SMS is treated as a higher-priority SMS in the network 106 to ensure successful delivery, even during network congestion, such that it reaches the appropriate authorities based on the user’s location, network availability, and regulatory rules.

[0068] In an embodiment, a first network entity is configured to receive at least one emergency SMS, including a source address and a destination address, from at least one user equipment (UE) such as the UE 104. The first network entity may be a short message service center (SMSC), a network message platform, or other network entities. The first network entity (e.g., the SMSC) in networks plays a central role in the storage, forwarding, and delivery of SMS. The first network entity interacts with various network elements, including a Mobile Switching Center (MSC), Home Location Register (HLR), Base Station System (BSS), and other SMSCs, to ensure the efficient and reliable delivery of SMS between mobile subscribers, such as the users 102, or other network entities or nodes within the same network or across different networks.

[0069] When the user 102 initiates the at least one emergency SMS, the at least one UE 104 generates a Mobile Application Part Mobile-Originated Forward Short Message (MAP-MO-FSM) and assigns a Mobile Station International Subscriber Directory Number (MSISDN) as the source address and 112 as the destination address. The at least one UE 104 then transmits the at least one emergency SMS in the form of MAP-MO-FSM towards the first network entity (i.e., the SMSC) using a MAP protocol. The MAP-MO-FSM is a standardized signaling message format used in the core networks (4G, 5G) to forward mobile-originated SMS, such as the at least one emergency SMS, to the first network entity (SMSC). The MAP-MO-FSM signaling message ensures that at least one emergency SMS is transported reliably from an access layer to the first network entity (SMSC) in a standardized, interoperable manner. The first network entity (SMSC) acts as the first mandatory relay point for the at least one emergency SMS. In an aspect, when the UE 104 sends at least one emergency SMS, the selection of the first network entity (SMSC) is determined by a configuration that is stored in a Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM) associated with the at least one UE 104. The SIM or USIM includes a predefined address corresponding to the first network entity, which is stored in aService Center Address (SCA) field and may be provisioned by a mobile operator. The at least one UE 104 may use this SCA to route the at least one emergency SMS towards the first network entity (i.e., the SMSC). It should be noted that the destination address 112 is a standardized emergency short code that represents a universally recognized endpoint for requesting immediate assistance from emergency service providers such as police, fire, or medical agencies, and serves as the designated trigger for routing the at least one emergency SMS to further network entities.

[0070] In an aspect, upon receiving the at least one emergency SMS, the first network entity (i.e., SMSC) extracts the source address and the destination address from the MAP-MO-FSM and performs a destination number analysis. In this analysis, the first network entity (i.e., SMSC) evaluates the destination address (e.g., 112) based on preconfigured routing tables, emergency short-code mappings, and operator- defined digital analysis rules to determine whether the incoming SMS corresponds to an emergency communication request. Additionally, the first network entity (i.e., SMSC) checks the destination address against its internal database and identifies that the short code “112” represents a standardized emergency service endpoint and it requires special routing toward an emergency handling function. After determining that the SMS is an emergency message, the first network entity (i.e., SMSC) converts the received MAP-formatted message into a Short Message Peer-to-Peer (SMPP) protocol structure, namely a Deliver- SM-Request PDU. The Deliver-SM-Request PDU is an SMPP container used by the SMSC to deliver mobile-originated SMS messages to external applications. This PDU encapsulates all relevant SMS attributes, including the subscriber’s MSISDN as the source address, the emergency short code (112) as the destination address, message payload, data coding scheme, timestamp, and other mandatory SMPP parameters. Once the Deliver-SM-Request PDU is constructed, the first network entity (i.e., SMSC) forwards the at least one emergency SMS over an SMPP interface to a second network entity. During this forwarding, the first networkentity (i.e., SMSC) preserves the original source MSISDN and the emergency destination number.

[0071] In an aspect, the second network entity may represent or correspond to an Emergency SMS Gateway (ESG) server. The ESG server is a network node that facilitates the sending of the at least one emergency SMS, notifications and alerts to other SMSCs or emergency centers such as public safety answering points (PSAP). The ESG server is configured to act as a specialized routing and decision-making network node for emergency SMS traffic, ensuring its accurate delivery to the appropriate emergency centers. The ESG server may be equipped to interface with multiple network functions across 4G, 5G, and 6G systems. In an implementation, the processing engine 208 may be implemented or embedded in the second network entity (ESG server).

[0072] In an embodiment, upon receiving the at least one emergency SMS from the first network entity (SMSC), the second network entity (ESG server) is configured to retrieve a first network identifier corresponding to the at least one UE 104 based on the received source address from a network database (for example, the database 210). In an example, the database 210 may be a Query Network Portability Database (QNPDB), which stores portability and routing information of the at least one UE 104, including mappings between MSISDNs and their corresponding home networks. The QNPDB may act as a centralized repository that enables efficient real-time querying to determine the correct terminating network for a given MSISDN. The QNPDB ensures that signaling messages, location requests, and SMS delivery functions are routed to the appropriate operator network, regardless of number portability. By providing accurate portability and routing data, the QNPDB supports seamless inter-operator communication and prevents misrouting or delivery failures for the at least one UE 104. The first network identifier represents Home Public Land Mobile Network (HPLMN), which is the primary or home mobile network to which the at least one UE104, is originally registered. The HPLMN determines the core network responsible for subscriber authentication, mobility management, and service provisioning. The HPLMN is uniquely represented by a combination of a Mobile Country Code (MCC) and a Mobile Network Code (MNC), which together identify the home country and home mobile network operator of the at least one UE 104.

[0073] In an example, upon receiving the at least one emergency SMS, the second network entity (i.e., the ESG server) initiates a query towards the QNPDB (network database 210) to retrieve the HPLMN of the at least one UE 104, based on the source address (i.e., MSISDN). The second network entity (i.e., the ESG server) performs a lookup operation in the QNPDB (database 210) using a Naming Authority Pointer (NAPTR) query protocol. The NAPTR query protocol is used for resolving telephone numbers into service-specific routing information. The NAPTR query enables the second network entity (i.e., the ESG server) to map the MSISDN of the at least one UE 104 to its home network information by following a standardized ENUM (E.164 Number Mapping) resolution procedure.

[0074] During the lookup operation, the NAPTR query translates the MSISDN into a format suitable for ENUM processing and searches for the associated MCC and MNC in the QNPDB. The MCC identifies the country of the home network, while the MNC specifies the exact mobile operator within that country. The QNPDB then processes the query and returns a NAPTR-response containing the resolved HPLMN information corresponding to the source address of the at least one UE 104.

[0075] In an embodiment, after receiving the NAPTR-response, the second network entity (i.e., the ESG server) is configured to initiate at least one location request towards a third network entity. The third network entity corresponds to a subscriber database such as a Home Subscriber Server (HSS). The HSS may be identified based on the retrieved first network identifier, i.e., the HPLMN. F or example, the MCC and MNC associated with the at least one UE 104 is used to determine theHSS, that stores mobility, roaming, and authentication-related data of at least one UE 104. The second network entity (i.e., the ESG server) constructs the at least one location request as a Sh User-Data-Request (Sh-UDR) that serves as a command or a signaling request to obtain real-time location information of the at least one UE 104.

[0076] In an aspect, the second network entity (ESG) includes one or more network parameters for e.g., specific Attribute- Value Pairs (A VPs) in the at least one location request (Sh-UDR) to define the nature of the location request. The one or more network parameters may include, but are not limited to, a data reference, a destination reference and a list of network nodes required to process at least one location request. In an example, the ESG server initiates the Sh-UDR towards the HSS with the data reference set to "User-Location" to specify the type of data being requested from the HSS and the destination-reference or realm set to the retrieved first network identifier (i.e., HPLMN) of the at least one UE 104, to ensure the at least one location request is routed to the correct HSS. Furthermore, the Sh-UDR includes a “Current-Location” A VP set to “InitiateActiveLocationRetrieval,” indicating that the third network entity (HSS) should actively retrieve the most current location of at least one UE 104. The list of network nodes, such as “Requested-Nodes” AVP, is set to “AMF, MME,” indicating that the HSS must query either the Access and Mobility Management Function (AMF) in a 5G network or the Mobility Management Entity (MME) in a 4G network based on the UE’s current registration state.

[0077] In an embodiment, upon receiving the upon receiving the at least one location request, the third network entity (HSS) determines a network type associated with the at least one UE 104 based on the received one or more network parameters and the retrieved first network identifier. Further, based on the determined network type, the third network entity initiates a location information retrieval process. The network type (e.g., LTE / 4G or NR / 5G) is inferred from the subscriber’s mobility information and registration status maintained in the HSS. In the location informationretrieval process, the third network entity (HSS) communicates with underlying mobility management nodes such as the MME in 4G or the AMF in 5G to obtain the most recent location information of the at least one UE 104. For example, if the at least one UE 104 is attached to the 4G network, the HSS triggers an Insert Subscriber Data Request (IDR) message towards the MME to retrieve the current location of the at least one UE 104. Conversely, if the at least one UE 104 is attached to the 5G network, the HSS invokes a Namf EventExposure Subscribe message towards the AMF. The Namf_EventExposure service in the 5G network is used to retrieve real-time information about the UE’s mobility and location events.

[0078] In an embodiment, the second network entity (ESG server) is configured to receive at least one response from the third network entity. The at least one response may include, but is not limited to, a location information of the at least one UE, including second network identifier and a third network identifier. The second network identifier is a Visited Public Land Mobile Network (VPLMN), and the third network identifier is a NR Cell Global Identifier (NRCGID) of the at least one UE 104. The VPLMN represents the mobile network in which the at least one UE 104 is currently registered while roaming outside its home network. It enables the second network entity to identify the visited operator domain (based on MCC and MNC) where the at least one UE 104 is presently attached. The NRCGID uniquely identifies the specific 5G NR cell serving the at least one UE 104. The NRCGID is derived from the combination of the PLMN ID and the NR Cell ID, allowing for the precise localization of the at least one UE 104 at the cell level within the visited network.

[0079] In an aspect, after retrieving the active location details from the respective serving network nodes (MME for 4G or AMF for 5G), the third network entity (HSS) compiles the obtained location information into an Sh User-Data-Answer (Sh-UDA). The Sh-UDA is a command or signaling response sent by the HSS to the1ESG server in reply to the previously received Sh-UDR. The third network entity (HSS) transmits the Sh-UDA to the second network entity (ESG server).

[0080] In an example, when the at least one UE 104 is attached to the 5G network, the third network entity (HSS) collects the active location information from the AMF through the Namf EventExposure service. The AMF provides the 5G- specific location parameters, including the NRCGID of the serving NR cell and the VPLMN indicating the network in which the at least one UE 104 is currently registered. These parameters reflect the real-time 5G mobility state of the at least one UE 104. Conversely, when the at least one UE 104 is attached to a 4G network, the third network entity (HSS) retrieves the active location information by initiating IDR towards the MME. Upon receiving the IDR, the MME compiles and returns the required mobility information in the form of a 5GS Location Info AVP. This AVP includes key parameters such as the NRCGID, which uniquely identifies the serving NR cell; the Visited Public Land Mobile Network (VPLMN), representing the operator network where the UE is currently registered; the Tracking Area Identity (TAI) or Tracking Area Code (TAC), indicating the tracking area associated with the UE; and the NR Cell ID corresponding to the specific radio cell serving the UE. These parameters collectively represent the real-time radio and mobility state of the at least one UE 104.

[0081] In this manner, depending on the determined network type of the at least one UE 104, the third network entity (HSS) aggregates the received mobility information into the Sh-UDA and transmits it back to the second network entity (ESG server).

[0082] In an embodiment, the second network entity (i.e., the ESG server) is configured to determine a destination identifier corresponding to at least one destination entity based on the received second network identifier (VPLMN) and the third network identifier (NRCGID) included in the location information. The destination identifier refers to a routing identifier that enables the second network entity(i.e., the ESG server) to select the at least one destination entity, such as the PSAP or destination SMSC configured for long-code delivery. Using the NRCGID received in the Sh-UDA, the second network entity (i.e., the ESG server) queries a configuration repository to identify the state or geographical region associated with the serving NR cell. Each state or region has a preconfigured PSAP long code mapped to it. When a match is found, the ESG retrieves the corresponding long code for the identified PSAP, which becomes the destination identifier for delivering the at least one emergency SMS. If the NRCGID is not present in the configuration repository, the second network entity (i.e., the ESG server) uses the VPLMN information (derived from MCC and MNC) to determine the PSAPs mapped to that visited operator domain and selects the appropriate long code from the VPLMN-level mapping.

[0083] In an embodiment, after determining the destination identifier (configured long code), the second network entity (i.e., the ESG server) is configured to modify the destination address (the emergency short code “112”) that is received in the at least one emergency SMS by replacing it with the determined destination identifier (long code). Further, the second network entity (i.e., the ESG server) is configured to modify the destination address in the at least one emergency SMS by replacing it from short code 112 to the determined destination identifier (configured long code of the PSAP). Furthermore, the modified emergency SMS is formatted as a Submit SM Request PDU to be sent via the SMPP protocol.

[0084] In an embodiment, the second network entity is configured to transmit the at least one emergency SMS utilizing the determined destination identifier to the at least one destination entity. In an example, after formatting the emergency SMS to Submit SM Request PDU, the ESG server sends the Submit SM Request PDU to one or more SMSCs.

[0085] In an aspect, the at least one emergency SMS is distributed between the one or more SMSCs in a round-robin mechanism, ensuring balanced utilization ofnetwork resources and avoiding overloading of any single SMSC. The round-robin mechanism refers to a sequential load- distribution method where the ESG server maintains an ordered list of SMSCs configured for long-code delivery and, for each incoming emergency SMS, selects the next SMSC in the list in a cyclic manner. For example, if two SMSCs such as SMSC-1 and SMSC-2 are available, the first emergency SMS is sent to SMSC-1, the next to SMSC-2, and subsequent messages continue alternating in the same order. This prevents bottlenecks and guarantees fairness in message routing.

[0086] In an embodiment, the second network entity (ESG server) is configured to receive a first acknowledgment message from the at least one destination entity. For example, after processing, the one or more SMSCs sends back a Submit SM Response PDU to the ESG server. This response includes a status code indicating whether the at least one emergency SMS was successfully delivered or if there were any errors. Further, the second network entity (ESG server) transmits a second acknowledgment message to the first network entity based on the received first acknowledgment message. For example, the ESG server takes the received status code received in the Submit SM Response PDU and sends it back to the SMSC from which the at least one emergency SMS was forwarded in a Deliver SM Response PDU. Once the SMSC receives the Deliver SM Response PDU from the ESG server, it acknowledges the at least one UE 104 by sending a Mobile Originated Forward Short Message Acknowledgment (MAP-MO-FSM-ACK). This acknowledgment informs the at least one UE 104 that the at least one emergency SMS has been processed and delivered successfully.

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

[0088] FIG. 3 illustrates an exemplary system architecture 300 configured for transmitting the emergency SMS in the network 106, in accordance with an embodiment of the present disclosure. FIG. 3 is explained in conjunction with FIGS. 1 and 2.

[0089] In an embodiment, the system architecture 300 includes the ESG 302 (referred to as the second network entity or ESG server in FIG.2), the SMSC 304 (referred to as the first network entity in FIG.2), the QNPDB 306, the HSS 308 (referred to as the third network entity in FIG.2), a configuration repository 310 and the PSAP 312 (one of an example of the at least one destination entity as described earlier in FIG.2).

[0090] In an embodiment, the at least one UE 104 originates the at least one emergency SMS (i.e., MAP-MO-FSM) towards the SMSC 304 with the source address as the UE’s MSISDN and the destination address as 112. The SMSC 304 performs destination number analysis and forwards the at least one emergency SMS (Deliver SM request PDU) over the SMPP interface towards the ESG 302 while maintaining the source and destination addresses of the at least one emergency SMS.

[0091] In an embodiment, for the source address received in the at least one emergency SMS, the ESG 304 queries the QNPDB 306 by initiating the NAPTR query to retrieve the HPLMN i.e., the MCC and the MNC (referred to as the first network identifier in FIG. 2) of the at least one UE 104. The ESG 304 receives the NAPTR- response and processes it to fetch the HPLMN of at least one UE 104.

[0092] In an embodiment, to retrieve VPLMN (referred to as the second network identifier in FIG. 2) and cell location information, the ESG 302 initiates the Sh-UDR towards the HSS 308 using the diameter protocol. In the Sh-UDR, the ESG302 sets the data reference to “User-Location,” and the destination realm is set to the retrieved HPLMN of at least one UE 104.

[0093] In an aspect, the ESG 302 sends the Sh-UDR with “Current-Location” A VP set to InitiateActiveLocationRetrieval and Requested-Nodes AVP set to “AMF, MME” such that when the at least one UE 104 is attached to 4G network, the HSS 308 invokes IDR towards the MME to retrieve the active location of the at least one UE 104. Additionally, when the at least one UE 104 is attached in the 5G network, the HSS 308 invokes the IE Namf EventExposure subscribe towards the AMF to retrieve the active location of the at least one UE as the 5G network subscriber.

[0094] In an aspect, upon completion of the location retrieval process, the HSS 308 sends the Sh-UDA message to the ESG 302, the Sh-UDA containing the 5GS Location Information of the at least one UE 104. Based on the received 5GS Location Information, the ESG 302 retrieves the corresponding NRCGID from the configuration repository 310 via a file transfer protocol (FTP) interface. Once the NRCGID is obtained, the ESG 302 determines the state associated with the fetched NRCGID and subsequently identifies the long code that is mapped to an appropriate PSAP. This enables the ESG 302 to route the at least one emergency SMS to the correct PSAP. In an aspect, if the NRCGID is not present in the configuration repository 310 indicating that the cell-level mapping is unavailable the ESG 302 falls back to a VPLMN-based mapping procedure. In such a case, the ESG 302 determines the appropriate PSAPs mapped to the identified VPLMN and selects one or more PSAPs based on predefined routing rules.

[0095] In an aspect, once the appropriate PSAP 312 is identified, the ESG 302 updates the routing information of the at least one emergency SMS. Specifically, the ESG 302 replaces the original destination address ‘ 112’ with the long code configured for the selected PSAP. This long code represents the actual terminating address used for delivering the at least one emergency SMS messages.

[0096] After updating the destination address, the ESG 302 reformats the at least one emergency SMS into an SMPP protocol format Submit SM Request PDU. The Submit SM PDU encapsulates essential parameters including the modified destination address (long code), the original MSISDN of the at least one UE 104 as the source address, the message content, and additional delivery attributes required for transmission toward the PSAP.

[0097] In an aspect, the ESG 302 forwards the generated Submit SM Request PDU to one of the configured PSAPs 312. When multiple PSAP instances are available, the ESG 302 distributes the Submit SM messages using a round-robin mechanism to ensure balanced load distribution and optimized handling of emergency messages across multiple PSAP nodes.

[0098] FIG. 4 illustrates another exemplary process flow diagram 400 for transmitting the emergency SMS in the network 106, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1-3.

[0099] At step 402, the at least one UE 104 originates MAP-MO-FSM towards the SMSC 304-1 with source address as UE’s MSISDN and destination address as 112. The MAP-MO-FSM (Mobile-Originated Forward Short Message) is a standardized signaling message format used in the core networks (4G, 5G) to forward mobile- originated SMS, such as the at least one emergency SMS, to the SMSC 304-1. The MAP-MO-FSM signaling message ensures that the at least one emergency SMS is transported reliably from the access layer to the SMSC 304-1 in a standardized, interoperable manner.

[0100] At step 404, the SMSC 304-1 performs destination number analysis and forwards the at least one emergency SMS (Deliver SM request PDU) over SMPP interface towards the ESG 302. The Deliver SM request PDU is a standardized SMPPPDU that carries information such as the source address (the UE’s MSISDN), the original destination address (112), message pay load, and additional metadata.

[0101] At step 406, for the source address received in the at least one emergency SMS, the ESG 302 sends a NAPTR request to the QNPDB 306 to retrieve the HPLMN information (MCC, MNC) of the at least one UE 104. The NAPTR request is a standardized DNS query used to retrieve service-specific routing information based on a given identifier, such as the MSISDN of the at least one UE 104. In networks, the NAPTR requests are commonly used to perform number portability and domain discovery by querying specialized databases such as the QNPDB 306. The NAPTR request enables the ESG 302 to accurately determine the home network domain of the at least one UE 104. The retrieved MCC and MNC allow the ESG 302 to identify the correct HSS associated with the profile of the at least one UE 104, ensuring that the subsequent Sh-UDR location request is routed to the appropriate subscriber database for location retrieval.

[0102] At step 408, the ESG 302 receives the NAPTR-Response and processes the NAPTR-Response to fetch HPLMN information, specifically the MCC and MNC associated with the source address (MSISDN) of the at least one UE 104. The NAPTR- Response contains service records that map the mobile number of the at least one UE 104 to its home operator domain. By parsing these records, the ESG 302 determines the exact home network of the at least one UE 104. The NAPTR-Response enables precise subscriber domain identification, which is essential for reliable emergency SMS routing and location determination.

[0103] At step 410, the ESG 302 initiates the Sh-UDR towards the HSS 308 with data-reference set to “User-Location” and destination-realm set to HPLMN. The Sh-UDR is a Diameter-based signaling request used by the ESG 302 to obtain realtime subscriber location information from the HSS 308. By specifying “User- Location” as the data-reference, the ESG 302 explicitly instructs the HSS 308 toretrieve the most current location of the at least one UE 104. Further, setting the destination-realm to the subscriber’s HPLMN ensures that the request is correctly routed to the authoritative home subscriber database, even when the at least one UE 104 is roaming or when number portability is involved. The Sh-UDR serves as the primary trigger for the HSS 308 to collect and return accurate and network- verified location information.

[0104] In an embodiment, the ESG 302 includes two key Attribute- Value Pairs (A VPs) in the Sh-UDR Current-Location AVP and Requested-Nodes AVP to specify how the HSS 308 must retrieve the subscriber’s active location. The Current-Location AVP, set to InitiateActiveLocationRetrieval, instructs the HSS 308 to actively obtain the most recent, real-time location of the at least one UE 104 instead of relying on cached or previously stored location records. This ensures that the HSS 308 triggers a fresh lookup from the serving network node so the ESG 302 receives accurate and up- to-date details such as the current cell ID, tracking area, and visited PLMN. Further, the Requested-Nodes AVP, set to “AMF, MME”, indicates the specific core network entities from which the HSS 308 should retrieve the location. When the at least one UE 104 is attached to a 4G network, the inclusion of MME prompts the HSS 308 to invoke the IDR towards the MME, enabling retrieval of active LTE location information. Conversely, when the subscriber is attached to a 5G network, the inclusion of AMF instructs the HSS 308 to initiate a Namf EventExposure Subscribe request towards the AMF to obtain the current location of the at least one UE 104. These AVPs ensure that the HSS 308 selects the correct procedure based on the access technology of the at least one UE 104, enabling accurate and technology-aware delivery of emergency SMS routing information.

[0105] At step 412, the Sh-UDA is the response message sent by the HSS 308 to the ESG 302 in reply to the previously issued Sh-UDR. The Sh-UDA carries the retrieved 5G Location Information of the at least one UE 104, which may includeparameters such as the VPLMN, NRCGID, TAI, and the serving NR Cell ID. The Sh- UDA is delivered over the Diameter Sh interface and conveys the most current and network- validated mobility data obtained by the HSS 308 through its interaction with the AMF or the MME. Upon receiving the Sh-UDA, the ESG 302 extracts the locationspecific identifiers required for routing the emergency SMS. Additionally, the ESG uses the NRCGID received in the Sh-UDA to query the configuration repository 310, enabling the ESG 302 to determine the associated site or PSAP mapping required for correct long-code routing of the at least one emergency SMS.

[0106] At step 414, the ESG 302 transmits the Submit SM Request PDU to the SMSC 304-2, which is identified as the destination-side SMSC responsible for long- code delivery. The SMSC 304-2 is configured to handle routing and termination of messages addressed to PSAP long codes, therefore, it serves as the appropriate downstream delivery entity for forwarding the at least one emergency SMS toward the designated PSAP. The Submit SM Request PDU is an SMPP protocol message used by the ESG 302 to submit the at least one emergency SMS to the destination-side SMSC 304-2 for further delivery. The Submit_SM PDU encapsulates all necessary SMS transport elements, including the source address (UE’s MSISDN), the modified destination address (PSAP long code), message payload, and protocol-specific routing attributes. The Submit SM Request PDU ensures that the at least one emergency SMS is correctly routed, formatted, and queued for termination toward the appropriate PSAP, thereby enabling reliable delivery of emergency communications through standardized SMPP signaling.

[0107] At step 416, upon successful submission of the at least one emergency SMS, the SMSC 304-2 (associated with long code delivery) transmits a Submit SM Response PDU to the ESG 302. The Submit SM Response PDU includes a command status field that indicates whether the corresponding Submit SM request PDU was successfully processed or if an error condition occurred duringhandling. Additionally, the response PDU may embed a unique message identifier (Message_ID) allocated by the SMSC 304-2, enabling downstream tracking, correlation, and auditing of the submitted emergency SMS. This response message enables the ESG 302 to verify the successful receipt and processing of the emergency SMS by the SMSC 304-2, supporting reliable message-delivery supervision and ensuring robust emergency-communication handling.

[0108] At step 418, the ESG 302 transmits a Deliver SM Response PDU back to the SMSC 304-1. The Deliver_SM_Response serves as an acknowledgement indicating that the ESG 302 has successfully received and processed the delivered message. The response may include, among other parameters, a command status field reflecting whether the Deliver_SM was handled without errors, thereby enabling the SMSC 304-1 to update its delivery-state records. This acknowledgement ensures proper completion of the message-delivery loop and supports reliable forwarding and tracking of incoming SMS messages within the emergency communication workflow.

[0109] At step 420, the SMSC 304-1 transmits a MAP-MO-FSM-ACK message to the at least one UE 104 as a signaling-layer acknowledgement indicating successful handling of the MAP-MO-FSM. The MAP-MO-FSM-ACK message confirms that the previously submitted emergency SMS has been accepted and processed by the ESG 302 without encountering delivery-blocking errors. This acknowledgement enables the UE 104 to conclude the MAP-based SMS submission, ensuring end-to-end reliability for emergency SMS communication.

[0110] FIG. 5 illustrates an exemplary flow diagram of a method for transmitting emergency SMS in the network 106, in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS.l and 2.

[0111] At step 502, the method 500 includes receiving, by the first network entity, the at least one emergency SMS from the at least one UE 104. The at least one emergency SMS includes the source address and the destination address.

[0112] At step 504, the method 500 includes forwarding, by the first network entity, the at least one emergency SMS, including the source address and the destination address, to the second network entity.

[0113] At step 506, the method 500 includes retrieving, by the second network entity, the first network identifier corresponding to the at least one UE 104 based on the received source address from the network database upon receiving in the at least one emergency SMS. In an example, the first network identifier is the HPLMN.

[0114] At step 508, the method 500 includes initiating, by the second network entity, the at least one location request towards the third network entity. In an example, the third network entity is the HSS. The at least one location request includes the one or more network parameters and the retrieved first network identifier. In one aspect, the one or more network parameters may include, but are not limited to, the location reference to indicate the type of location information requested and a list of network nodes required to process at least one location request. In an aspect, upon receiving the at least one location request, the third network entity determines the network type associated with the at least one UE 104 based on the received one or more network parameters and the retrieved first network identifier. Further, based on the determined network type, the third network entity initiates the location information retrieval process.

[0115] At step 510, the method 500 includes receiving, by the second network entity, the at least one response from the third network entity, where the at least one response includes location information of the at least one UE 104. The location information includes a second network identifier and a third network identifier. In anexample, the second network identifier is the VPLMN, and the third network identifier is the NRCGID of the at least one UE 104.

[0116] At step 512, the method 500 includes determining, by the second network entity, the destination identifier corresponding to the at least one destination entity based on the at least one of the received second network identifier and third network identifier.

[0117] At step 514, the method 500 includes modifying, by the second network entity, the destination address of the at least one emergency SMS by replacing it with the determined destination identifier.

[0118] At step 516, the method 500 includes transmitting, by the second network entity, the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

[0119] In an aspect, the second network entity receives the first acknowledgment message (Submit SM Response) from at least one destination entity. Based on the received first acknowledgment message, the second network entity transmits the second acknowledgment message (Deliver SM response) to the first network entity. Further, the first network entity sends the MAP-MO-FSM-ACK to the at least one UE 104, confirming the successful delivery of the at least one emergency SMS.

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

[0121] As shown in FIG. 6, the computer system 600 may include an external storage device 610, a bus 620, a main memory 630, a read-only memory 640, a mass storage device 650, communication port(s) 660, and a processor 670. A person skilled in the art will appreciate that the computer system 600 may include more than oneprocessor and communication ports. The processor 670 may include various modules associated with embodiments of the present disclosure. The communication port(s) 660 may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 660 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 600 connects.

[0122] In an embodiment, the main memory 630 may be a Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 640 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 670. The mass storage device 650 may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device 650 includes, but is 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 Lirewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.

[0123] In an embodiment, the bus 620 communicatively couples the processor 670 with the other memory, storage, and communication blocks. The bus 620 may be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, 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 a front side bus (FSB), which connects the processor 670 to the computer system 600.

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

[0125] In an exemplary embodiment, the present disclosure discloses 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 perform a method for transmitting emergency short message services (SMS) in a network is described. The method includes receiving, by a first network entity, at least one emergency SMS from at least one user equipment (UE), where the at least one emergency SMS includes a source address and a destination address. The method further includes forwarding, by the first network entity, the at least one emergency SMS, including the source address and the destination address, to a second network entity. The method includes retrieving, by the second network entity, a first network identifier based on the received source address from a network database upon receiving the at least one emergency SMS. The method further includes initiating, by the second network entity, at least one location request to a third network entity, where the at least one location request includes one or more network parameters and the retrieved first network identifier. The method further includes receiving, by the second network entity, at least one response from the second network entity, where the at least one response includes location information of the at least one UE, including a second network identifier and a third network identifier. The method further includes determining, by the second network entity, a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier. The method further includes modifying, by the second network entity, the destination address of the at least one emergency SMS by replacing it with the determined destination identifier and transmitting the at least oneemergency SMS to the at least one destination entity utilizing the determined destination identifier.

[0126] The present disclosure provides a technical advancement in the field of emergency short message service (SMS) delivery in next-generation communication networks. Traditional emergency SMS mechanisms rely heavily on legacy LTE location retrieval procedures, which fail when a user equipment (UE) is attached to fifth-generation (5G) or sixth-generation (6G) networks due to the absence of MME- based location reporting and SGs-based SMS transport. This limitation results in unsuccessful routing of emergency SMS and inability to determine the appropriate Public Safety Answering Point (PSAP).

[0127] The method introduces an enhanced emergency SMS gateway (ESG) architecture capable of dynamically invoking both MME-based and AMF-based location retrieval procedures using Sh-User-Data-Request (Sh-UDR) with active location retrieval triggers. By intelligently leveraging NRCellGloballd (NRCGI), E- UTRAN Cell Global Identifier (ECGI), or visited public land mobile network (VPLMN) identifiers, the ESG ensures accurate geographic mapping and precise PSAP selection. The method enables seamless emergency SMS delivery for UEs attached to 4G, 5G, or 6G networks, eliminates failures arising from missing MME contexts, improves routing accuracy, reduces message delivery latency, and significantly enhances the reliability of emergency communication services.

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

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

[0130] 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

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

[0132] The present disclosure enables an emergency short message service (SMS) gateway (ESG) to successfully route emergency SMS to the appropriate public safety answering points (PSAPs) or short message Service Centre (SMSC) when a subscriber is attached to a fifth-generation (5G) network or a sixth-generation (6G) network, ensuring uninterrupted emergency communication

[0133] The present disclosure enhances the accuracy of routing emergency SMS by dynamically retrieving the subscriber's location and network information, including cell-specific identifiers (NRCellGloballd) and visited public land mobile network (VPLMN) data.

[0134] The present disclosure reduces potential delays in emergency SMS delivery by utilizing real-time location retrieval mechanisms, thereby supporting faster response times during critical situations.

[0135] The present disclosure provides a scalable and configurable system for mapping PSAPs and long codes, allowing for easy adaptation to changes in network configurations or regulatory requirements.

[0136] The present disclosure enhances operational resilience by enabling the ESG to intelligently route emergency SMS messages using cell-level identifiers or VPLMN information, thereby ensuring accurate PSAP selection.

Claims

We claim:

1. A method (500) for transmitting emergency short message services (SMS) in a network (106), the method (500) comprising: receiving (502), by a first network entity, at least one emergency SMS from at least one user equipment (UE) (104), wherein the at least one emergency SMS comprises a source address and a destination address; forwarding (504), by the first network entity, the at least one emergency SMS, including the source address and the destination address, to a second network entity; retrieving (506), by the second network entity, a first network identifier corresponding to the at least one UE (104) based on the received source address from a network database upon receiving in the at least one emergency SMS; initiating (508), by the second network entity, at least one location request towards a third network entity, wherein the at least one location request comprises one or more network parameters and the retrieved first network identifier; receiving (510), by the second network entity, at least one response from the third network entity, wherein the at least one response comprises location information of the at least one UE (104), including a second network identifier and a third network identifier; determining (512), by the second network entity, a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier; modifying (514), by the second network entity, the destination address of the at least one emergency SMS by replacing it with the determined destination identifier; andtransmitting (516), by the second network entity, the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

2. The method (500) as claimed in claim 1, further comprising: receiving, by the second network entity, a first acknowledgment message from the at least one destination entity; and transmitting, by the second network entity, a second acknowledgment message to the first network entity based on the received first acknowledgment message.

3. The method (500) as claimed in claim 1, wherein one or more network parameters include at least one of a data reference, a destination reference and a list of network nodes required to process the at least one location request.

4. The method (500) as claimed in claim 1, wherein upon receiving the at least one location request, the third network entity determines a network type associated with the at least one UE (104) based on the received one or more network parameters and the retrieved first network identifier, wherein based on the determined network type, the third network entity initiates a location information retrieval process.

5. The method (500) as claimed in claim 1, wherein the first network identifier is at least a Home Public Land Mobile Network (HPLMN), the second network identifier is at least a Visited Public Land Mobile Network (VPLMN), and the third network identifier is at least a Network Routing Cell Global Identifier (NRCGID) of the at least one UE (104).

6. The method (500) as claimed in claim 1, wherein the third network entity is at least a Home Subscriber Server (HSS).

7. A system (108) for transmitting emergency short message services (SMS) in a network (106), the system (108) comprising: a first network entity configured to receive at least one emergency SMS from at least one user equipment (UE) (104), wherein the at least one emergency SMS comprises a source address and a destination address; and forward the at least one emergency SMS, including the source address and the destination address to a second network entity; a second network entity comprising a processing engine (208) and a memory (204) coupled to the processing engine (208), wherein the processing engine (208) at the second network entity is configured to: retrieve a first network identifier corresponding to the at least one UE (104) based on the received source address from a network database upon receiving in the at least one emergency SMS; initiate at least one location request towards a third network entity, wherein the at least one location request comprises one or more network parameters and the retrieved first network identifier; receive at least one response from the third network entity, wherein the at least one response comprises location information of the at least one UE (104), including a second network identifier and a third network identifier; determine a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier; modify the destination address of the at least one emergency SMS by replacing it with the determined destination identifier; andtransmit the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

8. The system (108) as claimed in claim 7, wherein the processing engine (208) is further configured to: receive a first acknowledgment message from the at least one destination entity; and transmit a second acknowledgment message to the first network entity based on the received first acknowledgment message.

9. The system (108) as claimed in claim 7, wherein one or more network parameters include at least one of a data reference, a destination reference and a list of network nodes required to process the at least one location request.

10. The system (108) as claimed in claim 7, wherein upon receiving the at least one location request, the third network entity determines a network type associated with the at least one UE (104) based on the received one or more network parameters and the retrieved first network identifier, wherein based on the determined network type, the third network entity initiates a location information retrieval process. .

11. The system (108) as claimed in claim 7, wherein the first network identifier is at least a Home Public Land Mobile Network (HPLMN), the second network identifier is at least a Visited Public Land Mobile Network (VPLMN) and the third network identifier is at least a Network Routing Cell Global Identifier (NRCGID) of the at least one UE (104).

12. The system (108) as claimed in claim 7, wherein the third network entity is at least a Home Subscriber Server (HSS).

13. A computer program product comprising a non- transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method (500) for transmitting at least one emergency short message service (SMS) in a network (106), the method comprising: receiving (502), by a first network entity, at least one emergency SMS from at least one user equipment (UE) (104), wherein the at least one emergency SMS comprises a source address and a destination address; forwarding (504), by the first network entity, the at least one emergency SMS, including the source address and the destination address, to a second network entity; retrieving (506), by the second network entity, a first network identifier corresponding to the at least one UE (104) based on the received source address from a network database upon receiving in the at least one emergency SMS; initiating (508), by the second network entity, at least one location request towards a third network entity, wherein the at least one location request comprises one or more network parameters and the retrieved first network identifier; receiving (510), by the second network entity, at least one response from the third network entity, wherein the at least one response comprises location information of the at least one UE (104), including a second network identifier and a third network identifier; determining (512), by the second network entity, a destination identifier corresponding to at least one destination entity based on at least one of the received second network identifier and third network identifier; modifying (514), by the second network entity, the destination address of the at least one emergency SMS by replacing it with the determined destination identifier; andtransmitting (516), by the second network entity, the at least one emergency SMS to the at least one destination entity utilizing the determined destination identifier.

Images