System and method for detecting stale sessions in a network

Abstract

A system (108) and a method (700) for detecting stale sessions in a network (106) is described Initially, a receiving unit (210) receives data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. Further, a monitoring unit (212) monitors an activity of the one or more sessions based on the received data packets at a configurable time interval. Further, the detection unit (214) detects at least one stale session from the one or more sessions based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

Description

SYSTEM AND METHOD FOR DETECTING STALE SESSIONS 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 (JPL) 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. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of communication systems. More particularly, the present disclosure relates to a system and method for detecting stale sessions.DEFINITION

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

[0004] The term ‘SMPP’ as used herein, refers to a Short Message Peer-to-Peer Protocol. The SMPP is a telecommunications industry protocol for exchanging Short Message Services (SMS) over the internet.

[0005] The term ‘MNP_UPC_GW’ as used herein, refers to a Mobile Number Portability Unique Porting Code Gateway. The MNP UPC GW is a gateway node in the network, which manages communication sessions with an MNP Clearing House (MCH). The MNP UPC GW performs tasks such as session monitoring, stale session detection, and resource management to ensure reliable message delivery.

[0006] The term ‘MCH’ as used herein, refers to the MNP Clearing House. The MCH is a peer node responsible for establishing and maintaining communication sessions with the gateway node. The MCH exchanges short message data, signaling information, and heartbeat messages as part of session management.

[0007] The term ‘Mobile Number Portability (MNP)’ as used herein, refers to a telecommunications service that enables a subscriber to retain an existing mobile number while switching from one service provider to another.

[0008] The term ‘TCP’ as used herein, refers to a Transmission Control Protocol. The TCP is a standard communication protocol used for reliable data transmission between devices in a network. The TCP ensures the sequential deliveryof packets and is used as the underlying transport protocol for the SMPP communication.

[0009] The term ‘active sessions’ as used herein, refers to the total number of ongoing communication sessions managed by the MNP_UPC_GW at any given time. Each session actively exchanges data or is monitored for activity.

[0010] The term ‘stale session’ as used herein, refers to a session that is no longer actively maintained between the MNP_UPC_GW (e.g., the gateway) and the MCH (e.g., the peer node). This may occur due to network issues, prolonged inactivity, or communication failures.

[0011] The term ‘last activity timestamp’ as used herein, refers to a record associated with each session that indicates the most recent time a packet was received or transmitted for the session. This timestamp is used to determine session activity and identify stale sessions in a timer-based detection mode.

[0012] The term ‘timer-based stale detection technique’ as used herein, refers to a technique for detecting a stale session by periodically evaluating the last activity timestamp associated with a communication session using a timer or scheduler, and determining session inactivity when the last activity timestamp exceeds a configurable inactivity period.

[0013] The term ‘heartbeat-based stale detection technique’ as used herein, refers to a technique for detecting a stale session by transmitting periodic heartbeat messages from the gateway to the peer node and determining session inactivity when responses to a predefined number of consecutive heartbeat messages are not received within a configurable time interval

[0014] The term ‘heartbeat message’ (interchangeably used as an Enquire Link Short Message (SM)) as used herein, refers to a periodic signaling message sent by the gateway to the peer node to check the responsiveness and operational status of the session. A session is declared as stale if no consecutive heartbeat messages are received within a configured time interval.

[0015] The term ‘activity’ as used herein, refers to communication indicative of operational use of a session, including exchange of data packets between the gateway and the peer node during normal session operation. Activity represents the presence of communication events, indicating that a session remains active.

[0016] The term ‘connection count’ as used herein, refers to a number of active communication sessions concurrently established between the gateway and one or more peer nodes at a given time.

[0017] The term ‘configurable flag’ as used herein, refers to a control parameter used by the gateway to automatically select between different stale session detection techniques based on one or more operational conditions.

[0018] The term ‘SMSC’ as used herein, refers to a Short Message Service Center. The SMSC is a portion of a mobile phone network that handles text message operations. The SMSC is responsible for receiving, storing, routing and forwarding SMS messages from mobile handsets.

[0019] The term ‘UPC’ as used herein, refers to a Unique Porting Code associated with a Mobile Number Portability request. The UPC may include a predefined sequence of alphanumeric characters used to uniquely identify and authorize a porting transaction between service providers. However, the length, structure, and encoding of the UPC may vary depending on regulatory requirements or operator-specific implementations.BACKGROUND

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

[0021] In modern telecommunication networks, Short Message Peer-to-Peer (SMPP) protocol is commonly used for communication between Mobile Number Portability Unique Porting Code Gateways (MNP_UPC_GW) and MNP Clearing Houses (MCH). The SMPP operates over the Transmission Control Protocol (TCP) to facilitate the reliable exchange of short messages. However, TCP connections may become stale due to various factors, including network fluctuations, congestion, packet loss, and firewall rules, idle session timeouts, keep-alive timeout conditions, or intermediate network device behavior that disrupts communication without properly terminating the connection.

[0022] In an SMPP session between a client and server, stale connections frequently arise, rendering the session inactive and unresponsive. When such stale sessions occur, subsequent messages from the client may become untraceable and ultimately lost. The issue is particularly critical in the MNP port-out workflows, where the loss of messages can result in significant service disruptions, operational inefficiencies, and outages in production environments.

[0023] Existing techniques for detecting and managing stale sessions typically rely on network-level mechanisms or static monitoring techniques. Such techniques are often inadequate for application-level environments, as they do not dynamically evaluate session activity or adapt detection behavior based on operational conditions of SMPP-based systems.

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

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

[0026] An objective of the present is to provide a system and a method for detecting stale sessions between a Mobile Number Portability Unique Porting Code Gateway (MNP_UPC_GW) (gateway) and an MNP Clearing House (MCH) (peer node) to ensure high service availability and reliability.

[0027] Another objective of the present disclosure is to optimize the detection flow by dynamically switching between a timer-based stale detection technique and a heartbeat-based stale detection technique based on tracking the number of active clients (e.g., MCH) connected to the UPCGW.

[0028] Another objective of the present disclosure is to optimize resource utilization by efficiently identifying and clearing stale sessions, thereby reducing system overhead and improving session management.

[0029] Yet another objective of the present disclosure is to minimize service disruptions by enabling seamless re-establishment of cleared sessions via an autoconnect feature, ensuring communication continuity.

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

[0031] In an exemplary embodiment, a method for detecting a stale session in a network is disclosed. The method includes receiving, by a receiving unit, data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. The method includes monitoring, by a monitoring unit, an activity of the one or more sessions based on the received data packets at a configurable time interval. Based on monitoring the activity, the method includes detecting, by a detection unit, at least one stale session from the one or more sessions. The at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

[0032] In some embodiments, the method includes automatically switching, by the detection unit and via a configurable flag, between the timer-based stale detection technique and the heartbeat-based stale detection technique for detecting the at least one stale session.

[0033] In some embodiments, the automatically switching includes selecting, by the detection unit, the timer-based stale detection technique to detect the at least one stale session when a connection count of the peer node connected to the gateway is below a configurable threshold.

[0034] In some embodiments, the automatically switching includes selecting, by the detection unit, the heartbeat-based stale detection technique when the connection count of the peer node connected to the gateway is equal to the configurable threshold.

[0035] In some embodiments, detecting the at least one stale session based on the timer-based stale detection technique includes activating, by the detection unit, a first timer at the gateway to evaluate a last activity timestamp associated with the one or more sessions between the gateway and the peer node, the last activity timestamp is periodically updated upon exchange of the data packets between the gateway and the peer node. The method further includes comparing, by a comparing unit, the last activity timestamp of each session with a configurable inactivity period, and declaring, by the detection unit, at least one session as the stale session when the last activity timestamp exceeds the configurable inactivity period.

[0036] In some embodiments, detecting the at least one stale session based on the heartbeat-based stale detection technique includes activating, by the detection unit, a second timer to detect whether the connection count of the peer node connected to the gateway is equal to the configurable threshold. Upon detection, the method includes periodically transmitting, by a transmission unit, a heartbeat message from the gateway to the peer node, and declaring, by the detection unit, at least one session as the stale session when a predefined number of consecutive heartbeat responses are not received from the peer node within a configurable time interval.

[0037] In some embodiments, the method further includes clearing, by the detection unit, the at least one detected stale session from the gateway, decrementing, by the detection unit, the connection count by a preconfigured value upon clearing the at least one detected stale session to make a connection slot available for a subsequent connection re-establishment, and re-establishing, by the detection unit, the subsequent connection on the peer node based on the available connection slot.

[0038] In some embodiments, the activity of the one or more sessions includes exchange of data packets between the gateway and the peer node, indicative of session operation.

[0039] In another exemplary embodiment, a system for detecting a stale session in a network is disclosed. The system includes a receiving unit configured to receive data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. The system includes a monitoring unit configured to monitor an activity of the one or more sessions based on the received data packets at a configurable time interval. The system further includes a detection unit configured to detect at least one stale session from the one or more sessions based on monitoring the activity. The at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

[0040] In yet another exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to perform a method for detecting a stale session in a network. The method includes receiving, by a receiving unit, data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. The method includes monitoring, by a monitoring unit, an activity of the one or more sessions based on the received data packets at a configurable time interval. Based on monitoring the activity, the method includes detecting, by a detection unit, at least one stale session from the one or more sessions. The at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

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

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

[0043] FIG. 1 illustrates an exemplary network architecture implementing a system for detecting a stale session in a network, in accordance with an embodiment of the present disclosure.

[0044] FIG. 2 illustrates an exemplary block diagram of the system, in accordance with an embodiment of the present disclosure.

[0045] FIG. 3 illustrates an exemplary system architecture for detecting the stale session in the network, in accordance with an embodiment of the present disclosure.

[0046] FIG. 4A illustrates an exemplary system architecture depicting connectivity between a Short Message Service Center (SMSC) and one or more MNP-UPC gateways (UPCGWs) communicating with a Mobile Number Portability Clearing House (MCH) vendor 1 infrastructure, in accordance with an embodiment of the present disclosure.

[0047] FIG. 4B illustrates another exemplary system architecture depicting connectivity between the SMSC and one or more MNP -UPC gateways communicating with a MCH vendor 2 infrastructure, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure.

[0048] FIG. 5A illustrates an exemplary process flow for detecting the stale session based on a timer-based stale detection technique, in accordance with an embodiment of the present disclosure.

[0049] FIG. 5B illustrates an exemplary process flow for updating a last activity timestamp for each session based on incoming and outgoing communication events, in accordance with an embodiment of the present disclosure.

[0050] FIG. 6 illustrates an exemplary process flow for detecting the stale session based on a heartbeat-based stale detection technique, in accordance with an embodiment of the present disclosure.

[0051] FIG. 7 illustrates an exemplary flow diagram of a method for detecting the stale session, in accordance with an embodiment of the present disclosure.

[0052] FIG. 8 illustrates an exemplary block diagram of a computer system in which or with which embodiments of the present disclosure may be implemented.

[0053] 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 - Receiving unit212 - Monitoring unit214 - Detecting unit216 - Comparing unit218 - Transmission unit220, 312 - Database300, 400A, 400B - System Architecture302 - Subscriber304 - Core Network306 - Evolved Node B (eNodeB)308 - Short Message Service Centre (SMSC)310 - Mobile Number Portability Unique Porting Code Gateway (MNP UPC GW) 314 - Short Message Peer-to-Peer Protocol (SMPP) vendor 1316 - SMPP vendor 2402a, 402b - SMSC 8 super core location404, 408 - Unique Porting Code Gateway (UPCGW)406, 410 - Mobile Number Portability Clearing House (MCH)500A, 500B, 600 - Process flow700 - Flow diagram800 - Computer System810 - External Storage Device820 - Bus830 - Main Memory840 - Read Only Memory850 - Mass Storage Device860 - Communication Port870 - ProcessorDETAILED DESCRIPTION

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

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

[0056] 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 specificdetails. 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.

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

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

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

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

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

[0062] In telecommunication networks supporting Mobile Number Portability (MNP) operations, communication between a Mobile Number Portability Unique Porting Code Gateway (MNP_UPC_GW) and a Mobile Number Portability Clearing House (MCH) is typically performed using a Short Message Peer-to-Peer (SMPP) protocol operating over a Transmission Control Protocol (TCP). While TCP provides reliable packet delivery, there exists a possibility that TCP connections may become stale due to multiple operational factors such as network fluctuations, congestion, packet loss, firewall rules, or other communication irregularities. As a result, there arises a need to continuously determine and maintain the health of communication sessions to ensure high service availability.

[0063] In an SMPP session established between communicating nodes, frequent observations have indicated that SMPP sessions may become stale, effectively rendering the session inactive and unusable. When such a condition occurs, subsequent messages transmitted from a client node may become untraceable and may eventually be lost. Furthermore, TCP sessions may transition into a stale condition without providing any explicit notification to the application layer. The absence of such notification prevents timely corrective action by the application, thereby allowing nonfunctional sessions to persist within the system.

[0064] When encountered in production deployments, particularly within Mobile Number Portability (MNP) port-out workflows, stale SMPP sessions may lead to serious operational issues, including message delivery failures, service disruptions,and large-scale outages. The persistence of undetected stale sessions adversely impacts reliability of communication between the MNP UPC GW and the MCH, thereby affecting overall system performance and operational continuity.

[0065] To address these challenges, the present disclosure provides a system and a method for detecting stale communication sessions between the MNP UPC GW (e.g., gateway) and the MCH (e.g., peer node). The present disclosure provides a method for tracking stale sessions such that inactive or non-responsive sessions do not linger within the system. By identifying and managing stale sessions in a timely manner, smooth functioning of the application with vendor nodes is ensured, thereby improving operational reliability.

[0066] The present disclosure provides a configurable flag that dynamically switches between a timer-based stale detection technique and a heartbeat-based stale detection technique for stale session detection, based on tracking the number of active clients (e.g., MCH) connected to the UPCGW. The timer-based stale detection technique detects stale sessions by monitoring session activity, while the heartbeatbased stale detection technique optimizes tracking by selectively monitoring sessions based on operational criteria. The optimized technique ensures that not all sessions are continuously tracked; instead, sessions that meet predefined conditions, such as reaching a maximum allowed connection count, are selectively evaluated. Consequently, the detection process becomes more resource-efficient while maintaining the reliability benefits provided by the primary detection approach.

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

[0068] FIG. 1 illustrates an exemplary network architecture (100) implementing a system (108) for detecting stale session in a network, in accordance with an embodiment of the present disclosure.

[0069] 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 individually referred to as the user (102) and 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 individually referred to as the UE (104) and collectively referred to as the UEs (104). Although three UEs (104) are depicted in FIG. 1, however, any number of the user equipments (104) may be included without departing from the scope of the ongoing description. In an embodiment, each UE (104) may have a unique identifier attribute associated therewith. In an embodiment, the unique identifier attribute may be indicative of at least one of a Mobile Station International Subscriber Directory Number (MSISDN), International Mobile Equipment Identity (IMEI)number, an International Mobile Subscriber Identity (IMSI), a Subscriber Permanent Identifier (SUPI), and the like.

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

[0071] In an embodiment, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, 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 a wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electro-mechanical, or an equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. In addition, 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 touch pad, 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.

[0072] In FIG. 1, the UE (104) may communicate with the system (108) via a network (106) to send data (e.g., data packets) to the system (108). The system (108) is configured to detect the stale session based on the received data from the UE (104). In an embodiment, the network (106) may include at least one of a Fifth Generation (5G) network, a Sixth Generation (6G) network, or the like. The network (106) may enable the UEs (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. 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 nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth.

[0073] In an embodiment, the UE (104) may be communicatively coupled with the network (106). The system (108) may receive a connection request from the UE (104). The system (108) 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. Once the connection is established, the system (108) may detect stale session in the network (106). A process of detecting the stale session is explained in greater detail in conjunction with the FIGS. 2 - 8.

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

[0075] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for detecting the stale session in the network (106), in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with the FIGs. 1.

[0076] In an embodiment, the stale session may refer to a communication session established between the MNP-UPC-GW (gateway) and the MCH (peer node) that remains logically active at a protocol level but is no longer operational due to the absence of communication activity or responsiveness. Such a stale session may occur when there is no activity, i.e., no data packets are exchanged between the communicating nodes for a prolonged duration, when expected responses are not received within a configured time interval, or when the underlying transport connection is disrupted without notification to an application layer. Although the session may continue to appear established from a protocol perspective, the session is effectively non-functional and incapable of reliably transmitting or receiving messages. Therefore, to maintain continuity of communication and prevent persistence of non-functionalsessions, the system (108) may be configured to monitor activity associated with communication sessions and detect stale sessions based on the absence of activity or lack of responsiveness between communicating nodes (e.g., MNP-UPC-GW and MCH).

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

[0078] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processing engine (208), a receiving unit (210), a monitoring unit (212), a detecting unit (214), a comparing unit (216), a transmission unit (218), and a database (220).

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

[0080] In an embodiment, the database (220) may store data (e.g., session-related information, connection status data, last activity timestamps, configurable thresholds, heartbeat monitoring records, etc.) that may be generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208). In an embodiment, the database (220) may be indicative of including, but not limited to, a relational database, a distributed database, a cloud-based database, or the like. In an exemplary embodiment, the processing engine (208) may include one or more units having functions that may include, but are not limited to, testing, storage, and peripheral functions, such as a wireless communication unit for remote operation, and the like.

[0081] In an embodiment, the processing engine (208) may be configured to detect at least one stale session at the application end (e.g., at the MNP-UPC-GW side). The processing engine (208) may be implemented at the MNP-UPC-GW (gateway). In order to detect the at least one stale session, the receiving unit (210) may receive data packets associated with one or more sessions from a peer node (e.g., the MCH) connected to a gateway (e.g., the MNP-UPC-GW) over a communication protocol (e.g., the SMPP). The MNP-UPC-GW may operate as an application-layer gateway responsible for managing communication sessions and routing porting -related messages between network entities and one or more MNP Clearing Houses (MCHs). The MCH may act as a peer system that exchanges signaling and short message data with the gateway to support mobile number portability operations. The SMPP protocol, operating over TCP, enables the reliable exchange of short message signaling between the gateway and the peer node. Examples of data packets may include SMPP protocol data units such as submit short message requests, deliver short message notifications, enquire link requests and responses, bind or unbind messages, acknowledgement messages, or any other signaling or communication packets exchanged between the gateway and the peer node during normal session operation.

[0082] Further, the monitoring unit (212) may be configured to monitor an activity of the one or more sessions based on the received data packets at a configurable time interval. The activity of the one or more sessions includes the exchange of data packets between the gateway and the peer node, indicative of session operation. In an embodiment, the configurable time interval may represent a predefined monitoring duration within which communication activity associated with each session is evaluated. The configurable time interval may be dynamically set or modified based on operational requirements, system load conditions, or deployment-specific configurations. For example, the configurable time interval may range from a few seconds to several minutes depending on expected communication behavior betweenthe gateway and the peer node. In some implementations, the interval may be configured as 30 seconds, 60 seconds, 120 seconds, or any other suitable duration defined by an operator or system configuration.

[0083] The monitoring involves analyzing the data packets exchanged between the gateway (e.g., MNP-UPC-GW) and the peer node (e.g., MCH) to ensure that the sessions remain active and functional. In an embodiment, the monitoring unit (212) may track communication events associated with each session, including incoming packets received from the peer node and outgoing packets transmitted from the gateway. Based on such communication events, the monitoring unit (212) may determine whether continuous interaction is occurring between the communicating nodes within the configurable time interval. Absence of data packet exchange for a duration exceeding the configured interval may indicate potential inactivity of a session.

[0084] Based on monitoring the activity, the detection unit (214) may be configured to detect the at least one stale session from the one or more sessions. In an embodiment, the at least one stale session may be detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique. The selection of the stale detection technique may depend on operational conditions associated with the gateway, such as a number of active sessions or connection dynamics between the gateway and the peer node. The timer-based stale detection technique may enable identification of stale sessions by evaluating inactivity associated with communication events. In an embodiment, inactivity may correspond to an absence of incoming or outgoing data packets over a session for a configurable duration despite the session remaining logically established. Such communication events may include receipt of protocol messages, transmission of requests or responses, acknowledgements, or other signaling exchanges between the gateway and the peer node. The heartbeat-based stale detection technique may enable verification of session responsiveness through periodic signaling exchanges. By employing one or more of the detection techniques, the detection unit (214) may ensure timely identification of non-functional sessions while maintaining efficient utilization of system resources.

[0085] In an embodiment, the detection unit (214) may be configured to automatically switch, via a configurable flag, between the timer-based stale detection technique and the heartbeat-based stale detection technique for detecting the at least one stale session. In an embodiment, the configurable flag may act as a control parameter that enables dynamic selection of an appropriate stale detection technique based on operational conditions associated with the gateway and the peer node. In an embodiment, the configurable flag may be initialized during system startup and may be automatically modified during runtime based on one or more operational conditions associated with the gateway. Such operational conditions may include, for example, anumber of active communication sessions, connection establishment or termination events, traffic load variations, resource utilization levels, or changes in session responsiveness characteristics. The automatic modification of the configurable flag enables dynamic switching between stale detection techniques without manual intervention. Such automatic switching allows the system to adapt stale session detection behavior in accordance with varying communication loads, thereby improving detection efficiency while maintaining reliable monitoring of active sessions.

[0086] In an embodiment, the detection unit (212) may be configured to select the timer-based stale detection technique to detect the at least one stale session when a connection count of the peer node connected to the gateway is below a configurable threshold. The connection count may represent a number of active communication sessions currently established between the gateway and the peer node at a given time. For example, the gateway may maintain multiple concurrent SMPP sessions with one or more MCH nodes, and the connection count may correspond to the total number of such active sessions, such as 2, 5, 8, etc. The configurable threshold may define a limit beyond which monitoring all sessions individually may increase processing overhead and may be set based on deployment requirements. For example, the configurable threshold (i.e., the maximum connections limit) may be set to 10, although other values may be used without limitation. When the connection count (i.e., total number of MCH clients connected to UPCGW) remains below the configurable threshold (e.g., less than 10 connections), the monitoring unit (212) may monitor activity associated with each session individually using the timer-based stale detection technique, as system resource utilization remains within manageable limits. In such scenarios, periodic evaluation of session activity enables accurate identification of inactive sessions without imposing significant processing or memory overhead on the gateway.

[0087] In an embodiment, the detection unit (214) may be configured to select the heartbeat-based stale detection technique when the connection count of the peer node connected to the gateway is equal to the configurable threshold. For example, when the configurable threshold is set to 10, and the number of connections or established sessions reaches 10 or more, the detection unit (214) may automatically switch to the heartbeat-based stale detection technique. In such conditions, monitoring the activity of every individual session using timer-based evaluation may increase computational overhead and resource consumption at the gateway. Accordingly, the heartbeat-based stale detection technique may selectively verify responsiveness of sessions by transmitting periodic heartbeat messages to the peer node and evaluating corresponding responses. This approach enables efficient detection of stale sessions in scenarios involving higher connection densities, such as when the gateway maintains10, 20, 50, or more concurrent sessions, thereby optimizing resource utilization while maintaining reliable session health monitoring.

[0088] In an embodiment, to detect the at least one stale session based on the timer- based stale detection technique, the detection unit (214) may be configured to activate a first timer at the gateway to evaluate a last activity timestamp associated with the one or more sessions between the gateway and the peer node. The last activity timestamp is updated upon exchange of data packets between the gateway and the peer node. In an embodiment, the last activity timestamp may be maintained for each of the one or more sessions established between the gateway and the peer node. The last activity timestamp may represent a record indicating a most recent communication event associated with a session and may be used to determine whether the session remains active. In an embodiment, the last activity timestamp may be updated whenever data packets are exchanged between the gateway and the peer node, including when a packet is received from the peer node or transmitted from the gateway. For example, exchanging SMPP protocol messages, such as submit short message requests, delivery reports, acknowledgement messages, or other signaling packets, may result in updating the last activity timestamp to a current system time, indicating continued activity.

[0089] Further, the comparing unit (216) may be configured to compare the last activity timestamp of each session with a configurable inactivity period. The configurable inactivity period may represent a predefined duration used to determine whether a session has remained inactive (i.e., no data packet exchange) beyond an acceptable limit. For example, the inactivity period may be configured as 30 seconds, 60 seconds, 120 seconds, or several minutes, depending on deployment requirements, expected traffic frequency, or operator configuration. The comparison may be performed periodically upon execution of the first timer to continuously evaluate the session activity status.

[0090] Further, the detection unit (214) may declare at least one session as a stale session when the last activity timestamp exceeds the configurable inactivity period. In such a scenario, the absence of packet exchange within the configured duration may indicate that the session is no longer operational even though it may appear logically established at the protocol level. For example, if no communication is observed for more than the configured inactivity period, such as 60 seconds or 120 seconds, the session may be identified as stale and may subsequently be processed for corrective actions, including session clearance or re-establishment.

[0091] In other words, the timer-based stale detection is performed by a timer or scheduler and relies on the traffic (data packets) from the peer node (e.g., the MCH). For this, the application runs the timer or scheduler to check the last activity (e.g., last activity timestamp) on the one or more active sessions and compare it with aconfigurable time period at the application. The last activity timestamp is kept updated with each incoming / outgoing packet. If the last activity timestamp exceeds the configurable time period during a timer run, inactivity is detected, and the session is declared stale.

[0092] In an embodiment, to detect the at least one stale session based on the heartbeat-based stale detection technique, the detection unit (214) may be configured to activate a second timer to detect whether the connection count of the peer node connected to the gateway is equal to the configurable threshold. The second timer may periodically evaluate the number of active communication sessions established between the gateway and the peer node to determine whether conditions for applying the heartbeat-based stale detection technique are satisfied. For example, when the configurable threshold is defined as 10 active sessions, and the gateway maintains 10 or more concurrent sessions, the detection unit (214) may initiate the heartbeat-based stale detection technique to efficiently monitor session responsiveness under higher connection loads.

[0093] Further, the transmission unit (218) may be configured to periodically transmit a heartbeat message from the gateway to the peer node upon detection. The heartbeat message may correspond to a signaling message used to verify session health without requiring an exchange of application traffic. In an embodiment, the heartbeat message may include SMPP enquire link messages or equivalent keep-alive signaling packets transmitted at predefined intervals, such as every 30 seconds, 60 seconds, or another configurable duration. Periodic transmission of the heartbeat message enables the gateway to actively confirm whether the peer node remains responsive even when normal message traffic is absent.

[0094] Further, the detection unit (214) may declare at least one session as the stale session when a predefined number of consecutive heartbeat responses are not received from the peer node within a configurable time interval. For example, if responses to three consecutive heartbeat messages are not received within the configured interval, the session may be determined to be non-responsive and identified as stale. Such determination allows the system (108) to detect silent connection failures that may occur due to network interruptions, transport-level disconnections, or peerside issues, even though the session may appear logically established at the protocol level.

[0095] In other words, the heartbeat-based stale detection may be performed by a periodic timer at the MNP UPC GW, which may ensure whether a current count of connections with the MCH has reached the maximum number of configured connections. In such a scenario, the MNP UPC GW may monitor the inactivity with the help of initiating a heartbeat message (e.g., an Enquire Eink Short Messages (SM)) towards the intended MCH. On failure to receive at least three consecutive heartbeatmessages within the configurable time period, the MNP UPC GW may mark the session as stale.

[0096] The detection unit (214) may be further configured to clear (destroy) the at least one detected stale session from the gateway by releasing system resources associated with the stale session. Upon clearing the at least one detected stale session, the detection unit (214) may further decrease the connection count by a preconfigured value (e.g., by 1) to make a connection slot available for a subsequent connection reestablishment. The detection unit (214) may notify the peer node (e.g., the MCH) about the available connection slot.

[0097] The detection unit (214) may further re-establish the subsequent connection on the peer node based on the available connection slot using an autoconnect feature. The auto-connect feature is a technique implemented at the peer node to ensure seamless re-establishment of sessions that have been cleared due to being identified as stale. The auto-connect feature is crucial in maintaining high service availability and minimizing disruptions in communication. When the stale session is cleared, the auto-connect feature at the peer node automatically initiates re-establishing the connection with the gateway. This eliminates the need for manual intervention or reliance on external triggers to restore communication.

[0098] In an embodiment, the configurable flag is introduced to intelligently toggle between different techniques for stale session detection based on the active connection dynamics of the UPCGW. In an embodiment, the configurable flag is set to the timer-based stale detection technique by default at system startup, designating it as the preferred stale session detection mode. The configurable flag may be dynamically modified at runtime, enabling the system to adapt to changes in the number of active client connections.

[0099] In an embodiment, the timer-based stale detection technique is particularly beneficial in scenarios where the UPCGW has a manageable number of client connections, such as 10 or fewer. In such cases, the system resources, including memory and CPU, are sufficient to handle stale session detection for all active connections without significantly impacting performance.

[0100] However, when the number of active client connections reaches equal to the configurable threshold (e.g., 10 connections), the configurable flag may dynamically switch to the heartbeat-based stale detection technique, which optimizes stale session detection by conditionally monitoring specific sessions instead of all active connections. The heartbeat-based stale detection technique reduces the overall resource consumption, including memory and CPU utilization, thereby maintaining system efficiency under higher connection loads.

[0101] By tracking the number of active client connections, the UPCGW may intelligently decide when to toggle between the timer-based stale detection techniqueand the heartbeat-based stale detection technique, ensuring that the stale session detection remains efficient and scalable under varying operational conditions. The dynamic selection of stale detection techniques provides flexibility to balance performance and resource utilization based on the active connection dynamics. Thus, the configurable stale session detection technique enables the UPCGW to optimize its operations by automatically selecting the most suitable technique for detecting the stale session based on the number of active client connections. This approach ensures enhanced system performance, scalability, and resource efficiency across a wide range of deployment scenarios.

[0102] 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 the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0103] FIG. 3 illustrates an exemplary system architecture (300) for detecting the stale session in the network, in accordance with an embodiment of the present disclosure. FIG. 3 is explained in conjunction with the FIGs. 1 and 2.

[0104] Referring to FIG. 3, the system architecture (300) may be integrated with an MNP UPC GW (310). The MNP UPC GW (310) may act as an applicationlayer gateway configured to manage communication sessions with one or more MCH nodes. The integration of the MNP-UPC gateway (310) may be done directly using the SMSC for port-related activities.

[0105] In an embodiment, a subscriber (302) may be attached to a core network (304). The core network (304) may be at least one of a Fourth-Generation (4G) network, a Fifth-Generation (5G) network, or a Sixth-Generation (6G) network. The subscriber (302) may include one or more user equipments (104-1, 104-2... 104-N). A person of ordinary skill in the art will understand that one or more user equipments (104-1, 104-2... 104-N) may be collectively referred to as the UE (104).

[0106] In an embodiment, the core network (304) may enable the subscriber (302) to communicate with other devices in the system architecture (300). The core network (304) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the core network (304) 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 (EAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0107] In an embodiment, the eNodeB (306) serves as the radio access node in the 4G network, facilitating the connection between the UE (104) and the core network(304). Similarly, in the 5G network, the radio access node may be served by a gNodeB (not shown in the present FIG. 3).

[0108] In an embodiment, Mobile Station International Subscriber Directory Number (MSISDN) range provisioning may be done via a pre-loaded Excel sheet at start-up, while runtime addition / deletion and other Move, Add, Change, or Delete / Disconnection (MACD) operations may be executed through an application Command-Line Interface (CLI). This data may be stored in a cache and a Database (DB) (312) for quick retrieval and efficient session handling. The stored data may further support monitoring and management of communication sessions established between the MNP UPC GW (gateway) (310) and SMPP vendor systems (e.g., SMPP vendor 1 (314) and SMPP vendor 2 (316)).

[0109] In an embodiment, the subscriber (302) may initiate a Short Message Service (SMS) toward a predefined service short code associated with a mobile number portability request for initiating a port-out process. For example, the short code may correspond to a regulatory or operator-defined porting service number (e.g., 1900). In case the subscriber (302) is attached to 4G, SMS may be received from an Internet Protocol Short Message Gateway (IPSMGW) and may be forwarded to the MNP UPC GW (310) by a serving SMSC (308) over the SMPP. In case the subscriber (302) is attached to 5G, SMS may be received from a Short Message Service Function (SMSF) and may be forwarded to the MNP-UPC-GW (310) by the serving SMSC (not shown in the present FIG. 3) on the SMPP.

[0110] On receipt of the SMS, the MNP-UPC-GW (310) may perform a DB query to look up whether an A-Party MSISDN belongs to SMPP vendor 1 (314) or SMPP vendor 2 (316). Based on the series, the MNP-UPC-GW (310) may route the SMS to the respective vendor (e.g., vendor 1 or vendor 2) over the SMPP. In an embodiment, SMPP vendor 1 (314) and SMPP vendor 2 (316) may correspond to external MNP Clearing House (MCH) systems or vendor-operated platforms responsible for processing porting-related requests associated with different operator regions, number series, or service providers. The MNP-UPC-GW (310) may maintain one or more SMPP communication sessions with each vendor system to enable continuous exchange of signaling messages required for Mobile Number Portability operations. Such multiple concurrent SMPP sessions established with the respective vendor systems may be monitored by the gateway to ensure session health and reliability of message delivery.

[0111] In an embodiment, communication between the MNP-UPC-GW (310) and the SMPP vendors (314, 316) may be established through one or more SMPP sessions operating over TCP connections. The MNP-UPC-GW (310) may maintain multiple concurrent sessions with the respective vendor systems to support porting-related message exchange. During operation, some of these sessions may become1inactive or non-responsive while still appearing logically established at the protocol level. Accordingly, the MNP UPC GW (310) may include the processing engine (208) configured to monitor activity associated with the established sessions and detect stale sessions using timer-based and heartbeat-based stale detection techniques, as described in subsequent embodiments of the present disclosure.

[0112] In an embodiment, detecting stale sessions at the application level enables the MNP UPC GW (310) to identify non-functional communication links that are not detectable solely through transport-layer mechanisms. Upon detection, corrective actions such as session clearance and re-establishment may be performed to maintain continuity of message delivery between the gateway and the SMPP vendor systems, thereby improving the reliability of Mobile Number Portability (MNP) operations.

[0113] FIG. 4A illustrates an exemplary system architecture (400A) depicting connectivity between a Short Message Service Center (SMSC) and one or more MNP-UPC gateways (UPCGWs) communicating with a Mobile Number Portability Clearing House (MCH) vendor 1 infrastructure. FIG. 4A is explained in conjunction with the FIGs. 1, 2, and 3.

[0114] In an embodiment, the SMSC may be configured in an 8 super core location. The 8 super core configuration may represent a distributed deployment in which multiple geographically separated core network sites operate in coordination to provide redundancy, load distribution, and high availability for message processing. Such distributed deployment enables traffic originating from different regions to be handled by corresponding UPCGW instances while maintaining continuity of service during node or site failures.

[0115] The architecture (400A) involves the interaction between the SMSC (402a) and multiple UPC Gateways (UPCGWs) (404-1, 404-2, 404-3, and 404-4). These UPCGWs are distributed across different locations or cities (e.g., UPCGW 01 city x, UPCGW 02 city x, UPCGW 01 city y, UPCGW 02 city y). Each UPCGW is connected to multiple Mobile Number Portability Clearing Houses (MCHs) (406-1, 406-2, 406-3, and 406-4) that serve various roles in the system. In an embodiment, vendor 1 infrastructure may correspond to an external clearing house platform operated by a third-party service provider responsible for processing mobile number portability transactions across multiple operators or service regions. The vendor infrastructure may include geographically distributed active and standby nodes configured to ensure high availability and failover support. For example, MCH PR active S 1 city y and MCH PR active S2 city y (406-1, 406-2) may represent the primary active systems configured to handle porting requests, while MCH DR Standby S 1 city w and MCH DR Standby S2 city w (406-3, 406-4) may represent disaster recovery standby systems that are available in case of failures in the primary active systems.

[0116] The TRX (1 session) mechanism ensures reliable and secure communication between the UPCGW s (404- 1 , 404-2, 404-3 , and 404-4) and the MCHs (406-1, 406-2, 406-3, and 406-4). Internal communication between the UPCGWs and the MCHs enables seamless routing of porting requests and messages to the appropriate MCHs. However, the connections between the UPCGWs (404-1, 404-2, 404-3, and 404-4) and the MCHs (406-1, 406-2, 406-3, and 406-4) are susceptible to becoming stale over time due to network or system inconsistencies. In particular, due to the long-lived nature of such sessions and varying network conditions, certain sessions may become inactive or non-responsive while still appearing logically established.

[0117] To mitigate the risk of stale connections, the system employs periodic monitoring and detection techniques to identify and remove inactive or stale connections. In accordance with the present disclosure, the system (108) may continuously monitor the communication sessions established between the UPCGW instances and the MCH systems to determine session activity and responsiveness. The monitoring enables detection of stale sessions that may arise due to network interruptions, packet loss, congestion, or transport-layer inconsistencies.

[0118] Upon detection of a stale session, corrective actions such as session clearance, resource release, and subsequent connection re-establishment may be initiated to maintain reliable communication between the UPCGW and the MCH vendor systems. Accordingly, the exemplary architecture 400A illustrated in FIG. 4A provides an operational environment in which stale session detection techniques described in the present disclosure may be implemented to ensure uninterrupted execution of mobile number portability workflows.

[0119] FIG. 4B illustrates an exemplary system architecture (400B) depicting connectivity between the SMSC and one or more MNP -UPC gateways (UPCGWs) communicating with a MCH vendor 2 infrastructure, in accordance with an embodiment of the present disclosure. FIG. 4B is explained in conjunction with the FIGs. 1, 2, 3, and 4A. In an embodiment, the SMSC may be configured in an 8 super core location, representing a distributed deployment of multiple coordinated core network sites that provide redundancy, traffic distribution, and service continuity across geographically separated regions.

[0120] The architecture (400B) involves the interaction between the SMSC (402b) and multiple UPC Gateways (UPCGWs) (408-1, 408-2, 408-3, and 408-4), distributed across different locations or cities (e.g., UPCGW 01 city x, UPCGW 02 city x, UPCGW 01 city y, UPCGW 02 city y). Each UPCGW is connected to multiple MCHs (410-1 to 410-8), which are categorized into active and standby servers, handling both Transmission (TX) and Reception (RX) sessions. In an embodiment, vendor 2 infrastructure may correspond to an external clearing house platform implemented using segregated transmission and reception session handling, whereinseparate communication channels are maintained for outbound and inbound message flows. Such architecture enables parallel processing, load distribution, and operational isolation between message transmission and reception paths.

[0121] For example, MCH PR city z - Active server 1-TX (410-1) and MCH PR city z - Active server 1-RX (410-2) may handle primary active transmission and reception sessions. Further, MCH PR city z - Active server 2-TX (410-3) and MCH PR city z - Active server 2-RX (410-4) may serve as an additional active system to enhance redundancy and load balancing. Further, MCH DR city x - Standby server 1-TX (410-5) and MCH DR city x - Standby server 1-RX (410-6) may act as a disaster recovery system, available to take over in case of failure in active servers. Additionally, MCH DR city x - Standby server 2-TX (410-7) and MCH DR city x - Standby server 2-RX (410-8) may provide additional standby redundancy for disaster recovery scenarios.

[0122] In an embodiment, the internal communication between the UPCGWs and the MCHs ensures smooth coordination when routing, processing messages, or porting requests. Communication between the UPCGW s and the MCHs is handled over distinct TX (2 sessions) and RX (2 sessions) channels, ensuring reliable data flow and fault tolerance. Due to the persistent nature of these sessions and varying network conditions, certain TX or RX sessions may become inactive or non-responsive while remaining logically established, thereby increasing the likelihood of stale session conditions.

[0123] The architecture (400B) emphasizes high availability and redundancy through the use of multiple active and standby servers distributed across different cities. In accordance with the present disclosure, the UPCGWs may include the processing engine (208) that continuously monitors activity associated with the communication sessions established with the vendor 2 infrastructure and applies stale session detection techniques, including timer-based and heartbeat-based detection, similar to those described for vendor 1 architecture in FIG. 4A. Detection and removal of stale sessions across both transmission and reception channels improve the reliability of message exchange and ensure the uninterrupted execution of mobile number portability workflows irrespective of vendor-specific deployment models.

[0124] FIG. 5A illustrates an exemplary process flow (500A) for detecting the stale session based on the timer-based stale detection technique, in accordance with an embodiment of the present disclosure. FIG. 5A is explained in conjunction with the FIGs. 1, 2, 3, 4A, and 4B. In an embodiment, the stale session detection may be performed by the processing engine (208) of the system (108) at the application level (e.g., at the MNP-UPC-GW side).

[0125] With reference to FIG. 5A, in order to detect the stale session based on the timer-based stale detection technique, at step 502, a timer (e.g., a first timer) may be activated during application setup or initialization. The timer may operate as ascheduler configured to periodically trigger evaluation of session activity across all active communication sessions maintained by the gateway. In an embodiment, the timer may start automatically upon establishment of SMPP connectivity or application startup and may run continuously throughout system operation to ensure uninterrupted monitoring of session health.

[0126] At step 504, the timer may monitor session inactivity for each active session. The monitoring may involve tracking a last activity timestamp associated with each session. The timestamp reflects the most recent exchange of data packets between the gateway and the peer node. The last activity timestamp may be updated whenever incoming or outgoing traffic is observed, thereby ensuring that even minimal communication activity is captured. The monitoring process may be performed periodically at configurable intervals so that inactivity conditions may be detected in near real time.

[0127] At step 506, a check may be performed to determine whether the last activity time exceeds an idle duration. In other words, the processing engine (208) may calculate the elapsed time between a current system timestamp and the stored last activity timestamp for a session and compare the elapsed time against a configurable inactivity threshold. The inactivity threshold may be configurable based on deployment requirements, such as network latency conditions or expected traffic frequency. For example, the inactivity threshold may be set to values such as 30 seconds, 60 seconds, 120 seconds, or any other suitable duration depending on operational requirements. The last activity timestamp may correspond to the most recent instance at which a data packet was exchanged between the gateway and the peer node, for example, when a porting-related SMPP message is received from the MCH or when a response message is transmitted by the gateway. When the elapsed duration exceeds the configured threshold, the session may be considered inactive despite remaining logically established at the protocol level.

[0128] At step 508, if the session is determined to remain active (i.e., the idle duration has not been exceeded), the process may continue monitoring the session without interruption. The timer may proceed to evaluate subsequent sessions in sequence or during the next scheduled monitoring cycle, thereby ensuring continuous supervision of all active sessions without impacting ongoing message processing.

[0129] At step 510, when a session surpasses the idle duration without any detected activity (i.e., no exchange of data packets), the processing engine (208) may identify and declare the session as a stale session. Such identification indicates that the communication link is no longer responsive even though the underlying TCP or protocol session may still appear established, thereby preventing further reliable message exchange.

[0130] At step 512, the processing engine (208) may perform a cleanup process for the stale session. The cleanup process may include releasing allocated resources associated with the session, such as memory buffers, socket connections, scheduler entries, or session context information. Following cleanup, the stale session may be terminated or destroyed to free system resources and enable establishment of a new session, thereby maintaining optimal performance, preventing resource exhaustion, and ensuring continued availability of communication channels.

[0131] FIG. 5B illustrates an exemplary process flow (500B) for updating the last activity timestamp for each session based on incoming and outgoing communication events, as mentioned in step 504 of FIG. 5A. FIG. 5B is explained in conjunction with the FIGs. 1, 2, 3, 4A, 4B, and 5A. The process of updating the last activity timestamp may be performed by the processing engine (208) of the system (108). The process ensures accurate tracking of session activity to enable reliable detection of stale sessions using the timer-based stale detection technique.

[0132] With reference to FIG. 5B, at step 514, the last activity timestamp associated with a session may be updated whenever an incoming or outgoing communication event occurs. The timestamp may correspond to a system -generated time value representing the most recent activity observed on the session. Continuous updating of the timestamp ensures that the monitoring mechanism maintains an accurate indication of session responsiveness. This ensures that the system keeps an accurate record of when the session was last active.

[0133] At step 516, when the session receives an incoming request, such as a data packet or signaling message from a peer node (e.g., the MCH), the processing engine (208) updates the last activity timestamp to a current timestamp. Such incoming requests may include porting-related SMPP messages, delivery acknowledgments, or other protocol-level communications exchanged during normal operation.

[0134] At step 518, when the session initiates an outgoing request toward the peer node or another network entity, the last activity timestamp may again be updated to reflect the occurrence of outbound communication. Updating the timestamp during outgoing transmission ensures that session activity is recognized even when traffic originates from the gateway side.

[0135] At step 520, when the session transmits an outgoing response, such as a reply generated in response to a previously received request, the last activity timestamp may be updated to capture the response activity associated with the session lifecycle.

[0136] At step 522, when an incoming response corresponding to an earlier outgoing request is received from the peer node, the system updates the last activity timestamp to reflect successful completion of the communication exchange. Accordingly, the process ensures that the timestamp consistently represents the mostrecent interaction occurring over the session, thereby enabling accurate determination of inactivity during timer-based stale session detection.

[0137] In an embodiment, the timer-based stale detection technique is beneficial when the UPCGW has fewer clients (e.g., the MCH) connecting to it. With a manageable number of client connections, even if the stale detection happens for all the active connections, it may not impact the system as much. It may be well within the limits of utilization.

[0138] In an overall aspect, the timer-based stale detection technique may consider the following statements:

[0139] The timer-based stale detection technique works with the help of a timer or a scheduling mechanism. This timer resides at the UPCGW application end and is responsible for tracking the health of the active sessions maintained at its end. This monitoring of the session state happens at regular intervals at MNP_UPC_GW. Active sessions are listed and managed at the application whenever MCH establishes SMPP connection as a client. This connection is then marked and maintained at the application so that the timer can be applied on these sessions. Multiple criteria may be used to find the last activity on the session. One such criteria is that whenever a packet is received on the session from MCH, UPCGW updates the last activity timestamp to the current timestamp. Whenever new packets arrive, this timestamp keeps on updating. Also, whenever the UPCGW needs to respond back to any of the received packets, it updates the activity timestamp again with the current timestamp. So, this timestamp is ensured to be updated at the slightest incoming / outgoing event that takes place at UPCGW in the form of packet communication. Once the last activity timestamp is ensured to be updated to the latest timestamp, the timer may now work to check whether this timestamp was old enough to surpass the time period configured at UPCGW. If the condition is met, the UPCGW suspects that particular session to be stale and marks it up for session cleanup and resource clearance. But the condition is self-healed as the MCH, acting as the client in this scenario, may re-initiate the connection with the UPCGW, thus reinstating the services again.

[0140] FIG. 6 illustrates an exemplary process flow (600) for detecting the stale session based on the heartbeat-based stale detection technique, in accordance with an embodiment of the present disclosure. FIG. 6 is explained in conjunction with the FIGs.1, 2, 3, 4A, 4B, 5A, and 5B. In an embodiment, the stale session detection may be performed by the processing engine (208) of the system (108) at the application level (e.g., at the MNP-UPC-GW side).

[0141] At step 602, a timer (e.g., a second timer) is activated to decide whether to send a heartbeat message (e.g., enquire link short messages) towards the MCH. The timer may periodically evaluate session conditions to decide whether heartbeat-based validation is required. In an embodiment, the decision to initiate heartbeat messagingmay depend on whether a number of active MCH connection sessions has reached a preconfigured allowed connection count. For example, when the gateway maintains a high number of concurrent sessions (e.g., 10 or more active sessions), selective heartbeat monitoring may be enabled to optimize processing and resource utilization.

[0142] At step 604, a check may be performed to monitor only those sessions whose connection count has reached the configured threshold (e.g., maximum allowed active sessions). The processing engine (208) may determine whether the current active connection count equals or exceeds the predefined limit. If the threshold condition is not satisfied, the system may continue normal monitoring without initiating heartbeat validation, thereby reducing unnecessary signaling overhead.

[0143] At step 606, once the connection count reaches the configured threshold, the system may transmit ‘n’ consecutive enquire link Short Messages (SMs) periodically toward the MCH. For example, three consecutive heartbeat messages may be transmitted at defined intervals (e.g., every 5 seconds or 10 seconds). These heartbeat messages serve as application-level probes configured to verify the responsiveness of the session and confirm that bidirectional communication remains operational.

[0144] At step 608, a check is performed to determine whether responses to the ‘n’ consecutive enquire link SMs have been received from the peer node within a configured response window. If valid responses are received, the session may be considered active and monitoring may continue without interruption. However, upon determining a failure to receive ‘n’ consecutive responses within the configured time period, the process flow (600) proceeds to step 610.

[0145] At step 610, upon determining that the expected heartbeat responses have not been received within the configured time interval, the session may be declared stale. The stale session may thereafter be terminated and associated resources, including memory allocations, socket bindings, and session context information, may be released to optimize system performance. Following session termination, the active connection count may be decremented (e.g., by one), thereby freeing a connection slot for subsequent connection establishment. In an embodiment, since the MCH operates as a client entity, an auto-connect mechanism at the MCH side may automatically attempt re-establishment of the cleared connection, thereby restoring communication without manual intervention.

[0146] In an embodiment, the heartbeat-based stale detection technique may be beneficial since it optimizes the detection flow and hence may be chosen when the number of clients in the setup is high. That way, detection may happen conditionally for specific sessions and not for all, thus reducing the memory and CPU requirements.

[0147] In an overall aspect, the heartbeat-based stale detection technique may consider the following statements:

[0148] The heartbeat-based stale detection technique works with the help of a timer or a scheduling mechanism. But the timer may be executed only when the number of MCH active connection counts is equal to the configured allowed number of connections. This configuration is done at startup for each MCH vendor. Once this condition is met, only the UPCGW application may initiate an Enquire Link SM packet periodically at a configured time period towards MCH. If ‘n’ (e.g., three) consecutive Enquire Link SM responses fail within a configured time period, that particular session may be marked as stale. After that, the session may be destroyed from the UPCGW, and the MCH may be notified. After the session clearance, the active connection count may be decremented by 1, and the connection slot may once again be available for further connection establishment. Since the MCH is the client, it has the auto-connect feature that ensures the connection is restored.

[0149] FIG. 7 illustrates an exemplary flow diagram of a method (700) for detecting the stale session, in accordance with an embodiment of the present disclosure. FIG. 7 is explained in conjunction with the FIGs. 1, 2, 3, 4A, 4B, 5 A, 5B and 6. In an embodiment, the stale session detection may be performed by various units of the processing engine (208) at the application level (e.g., at the MNP-UPC-GW side).

[0150] At step 702, the receiving unit (210) may receive data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. The data packets may include, but are not limited to, signaling messages, protocol messages, or application traffic exchanged during normal operation of mobile number portability workflows.

[0151] At step 704, the monitoring unit (212) may monitor an activity of the one or more sessions based on the received data packets at a configurable time interval. In some embodiments, the activity of the one or more sessions includes the exchange of data packets between the gateway and the peer node, indicative of session operation.

[0152] At step 706, the detection unit (214) may detect at least one stale session from the one or more sessions. In an embodiment, the at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

[0153] In some embodiments, the detection unit (214) may automatically switch, via a configurable flag, between the timer-based stale detection technique and the heartbeat-based stale detection technique for detecting the at least one stale session. The configurable flag may dynamically control the selection of an appropriate detection approach based on the operational conditions (e.g., the number of connections to the MCH).

[0154] In some embodiments, the detection unit (214) may be configured to select the timer-based stale detection technique to detect the at least one stale session when a connection count of the peer node connected to the gateway is below aconfigurable threshold. This mode or technique may enable continuous monitoring of activity timestamps across sessions when the number of active connections remains manageable.

[0155] In some embodiments, the detection unit (214) may be configured to select the heartbeat-based stale detection technique when the connection count of the peer node connected to the gateway is equal to the configurable threshold. This selection may reduce processing overhead by selectively validating session responsiveness using heartbeat signaling when connection density increases.

[0156] In some embodiments, to detect the at least one stale session based on the timer-based stale detection technique, the detection unit (214) may be configured to activate a first timer at the gateway to evaluate a last activity timestamp associated with the one or more sessions between the gateway and the peer node, the last activity timestamp is updated upon exchange of data packets between the gateway and the peer node. The comparing unit (216) may be configured to compare the last activity timestamp of each session with a configurable inactivity period. The detection unit (214) may be configured to declare at least one session as a stale session when the last activity timestamp exceeds the configurable inactivity period.

[0157] In some embodiments, to detect the at least one stale session based on the heartbeat-based stale detection technique, the detection unit (214) may be configured to activate a second timer to detect whether the connection count of the peer node connected to the gateway is equal to the configurable threshold. Upon detection, the transmission unit (218) may be configured to periodically transmit a heartbeat message from the gateway to the peer node. The detection unit (214) may be configured to declare at least one session as the stale session when a predefined number of consecutive heartbeat responses are not received from the peer node within a configurable time interval.

[0158] In some embodiments, the detection unit (214) may be further configured to clear the at least one detected stale session from the gateway, decrement the connection count by a preconfigured value upon clearing the at least one detected stale session to make a connection slot available for a subsequent connection reestablishment, and re-establish the subsequent connection on the peer node based on the available connection slot.

[0159] The present disclosure enables identification of inactive sessions that may remain undetected by transport-layer monitoring mechanisms, thereby preventing message loss and service disruption. By dynamically switching between timer-based stale detection and heartbeat-based stale detection techniques based on active connection conditions, the method (700) optimizes utilization of processing resources while maintaining reliable session supervision. Further, timely clearance of stale sessions and automatic availability of connection slots facilitate seamless re-establishment of communication sessions, improving system stability, operational efficiency, and service availability in mobile number portability workflows. The disclosed approach, therefore, enhances the reliability of long-lived SMPP communication sessions across diverse vendor deployments and network environments.

[0160] FIG. 8 illustrates an exemplary computer system (800) in which or with which embodiments of the present disclosure may be implemented.

[0161] As shown in FIG. 8, the computer system (800) may include an external storage device (810), a bus (820), a main memory (830), a read-only memory (840), a mass storage device (850), communication port(s) (860), and a processor (870). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (870) may include various modules associated with embodiments of the present disclosure. The communication port(s) (860) 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) (860) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects.

[0162] The main memory (830) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (840) 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 (870). The mass storage device (850) may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device (850) 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 Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks.

[0163] The bus (820) communicatively couples the processor (870) with the other memory, storage, and communication blocks. The bus (820) 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 as a front side bus (FSB), which connects the processor (870) to the computer system.

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

[0165] In an exemplary embodiment, a system for detecting a stale session in a network is disclosed. The system includes a receiving unit configured to receive data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. The system includes a monitoring unit configured to monitor an activity of the one or more sessions based on the received data packets at a configurable time interval. The system further includes a detection unit configured to detect at least one stale session from the one or more sessions based on monitoring the activity. The at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

[0166] In another exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to perform a method for detecting a stale session in a network. The method includes receiving, by a receiving unit, data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol. The method includes monitoring, by a monitoring unit, an activity of the one or more sessions based on the received data packets at a configurable time interval. Based on monitoring the activity, the method includes detecting, by a detection unit, at least one stale session from the one or more sessions. The at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

[0167] While the foregoing describes various embodiments of the invention, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof. The scope of the disclosure 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.

[0168] 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 programsrecorded 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.

[0169] The present disclosure provides a technical advancement in applicationlevel session management by enabling adaptive detection and handling of stale communication sessions established between a gateway and a peer node over the SMPP communication protocol. Unlike conventional approaches that rely primarily on transport- layer mechanisms, which may fail to identify inactive yet logically established sessions, the present disclosure provides coordinated timer-based and heartbeat-based stale detection techniques operating at the application layer. The present disclosure further enables dynamic switching between the detection techniques based on active connection conditions through the configurable flag, thereby optimizing monitoring operations according to system load. The present approach reduces undetected session failures, prevents message loss, and minimizes unnecessary resource consumption caused by lingering inactive connections. Additionally, automated clearance of stale sessions and availability of connection slots for reestablishment improve service continuity and operational reliability. Consequently, the present disclosure enhances system stability, improves processing efficiency, reduces signaling and computational overhead, and provides scalable and reliable communication session management across heterogeneous vendor deployments and network environments.

[0170] 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 is to be implemented merely as illustrative of the disclosure and not as a limitation.ADVANTAGES OF THE PRESENT DISCLOSURE

[0171] The present disclosure provides a system and a method to detect and eliminate the stale session between the MNP-UPC-GW (e.g., gateway) and the MCH (e.g., peer node). The present disclosure ensures that no lingering sessions affect the system's performance. This facilitates smooth and uninterrupted communication between the application and the vendor node, enhancing overall system reliability.

[0172] The present disclosure provides one or more techniques for stale session detection that allow adaptive selection based on real-time system dynamics. In an embodiment, the timer-based stale detection technique is particularly beneficial in environments with fewer client connections, ensuring comprehensive tracking withoutimpacting system performance. In an embodiment, the heartbeat-based stale detection technique is ideal for larger setups, where its conditional tracking approach reduces system overhead while maintaining detection accuracy.

[0173] The present disclosure provides an optimized approach (e.g., the heartbeat-based stale-detection technique) for stale session tracking by monitoring sessions that meet specific criteria, such as exceeding the maximum allowed session count. In an embodiment, the heartbeat-based stale detection technique minimizes resource consumption by focusing only on relevant sessions. In an embodiment, the optimized approach significantly reduces memory and CPU usage while still ensuring the same level of stale session detection, making it ideal for scenarios with a high number of client connections.

Claims

CLAIMSWe claim:

1. A method (700) for detecting a stale session in a network (106), the method (700) comprising:receiving (702), by a receiving unit (210), data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol;monitoring (704), by a monitoring unit (212), an activity of the one or more sessions based on the received data packets at a configurable time interval; and based on monitoring the activity, detecting (706), by a detection unit (214), at least one stale session from the one or more sessions, wherein the at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

2. The method (700) as claimed in claim 1, comprising:automatically switching, by the detection unit (214) and via a configurable flag, between the timer-based stale detection technique and the heartbeat-based stale detection technique for detecting the at least one stale session.

3. The method (700) as claimed in claim 2, wherein the automatically switching comprises:selecting, by the detection unit (214), the timer-based stale detection technique to detect the at least one stale session when a connection count of the peer node connected to the gateway is below a configurable threshold.

4. The method (700) as claimed in claim 2, wherein the automatically switching comprises:selecting, by the detection unit (214), the heartbeat-based stale detection technique when the connection count of the peer node connected to the gateway is equal to the configurable threshold.

5. The method (700) as claimed in claim 3, wherein detecting the at least one stale session based on the timer-based stale detection technique comprises:activating, by the detection unit (214), a first timer at the gateway to evaluate a last activity timestamp associated with the one or more sessions between the gateway and the peer node, wherein the last activity timestamp is periodically updated upon exchange of the data packets between the gateway and the peer node;comparing, by a comparing unit (216), the last activity timestamp of each session with a configurable inactivity period; anddeclaring, by the detection unit (214), at least one session as the stale session when the last activity timestamp exceeds the configurable inactivity period.

6. The method (700) as claimed in claim 4, wherein detecting the at least one stale session based on the heartbeat-based stale detection technique comprises:activating, by the detection unit (214), a second timer to detect whether the connection count of the peer node connected to the gateway is equal to the configurable threshold;upon detection, periodically transmitting, by a transmission unit (216), a heartbeat message from the gateway to the peer node; anddeclaring, by the detection unit (214), at least one session as the stale session when a predefined number of consecutive heartbeat responses are not received from the peer node within a configurable time interval.

7. The method (700) as claimed in claim 1, further comprising:clearing, by the detection unit (214), the at least one detected stale session from the gateway;decrementing, by the detection unit (214), the connection count by a preconfigured value upon clearing the at least one detected stale session to make a connection slot available for a subsequent connection re-establishment; andre-establishing, by the detection unit (214), the subsequent connection on the peer node based on the available connection slot.

8. The method (700) as claimed in claim 1, wherein the activity of the one or more sessions comprises the exchange of data packets between the gateway and the peer node, indicative of session operation.

9. A system (108) for detecting a stale session in a network (106), the system (108) comprising:a receiving unit (210) configured to receive data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol;a monitoring unit (212) configured to monitor an activity of the one or more sessions based on the received data packets at a configurable time interval; anda detection unit (214) configured to detect at least one stale session from the one or more sessions based on monitoring the activity, wherein the at least one stalesession is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

10. The system (108) as claimed in claim 9, wherein the detection unit (214) is configured to automatically switch between the timer-based stale detection technique and the heartbeat-based stale detection technique via a configurable flag to detect at least one stale session.

11. The system (108) as claimed in claim 10, wherein the detection unit (214) is configured to select the timer-based stale detection technique to detect the at least one stale session when a connection count of the peer node connected to the gateway is below a configurable threshold.

12. The system (108) as claimed in claim 10, wherein the detection unit (214) is configured to select the heartbeat-based stale detection technique when the connection count of the peer node connected to the gateway is equal to the configurable threshold.

13. The system (108) as claimed in claim 11, wherein to detect the at least one stale session based on the timer-based stale detection technique,the detection unit (214) is configured to activate a first timer at the gateway to evaluate a last activity timestamp associated with the one or more sessions between the gateway and the peer node, wherein the last activity timestamp is updated upon exchange of data packets between the gateway and the peer node;a comparing unit (216) is configured to compare the last activity timestamp of each session with a configurable inactivity period; andthe detection unit (214) is configured to declare at least one session as a stale session when the last activity timestamp exceeds the configurable inactivity period.

14. The system (108) as claimed in claim 12, wherein to detect the at least one stale session based on the heartbeat-based stale detection technique,the detection unit (214) is configured to activate a second timer to detect whether the connection count of the peer node connected to the gateway is equal to the configurable threshold;a transmission unit (216) is configured to periodically transmit a heartbeat message from the gateway to the peer node upon detection; andthe detection unit (214) is configured to declare at least one session as the stale session when a predefined number of consecutive heartbeat responses are not received from the peer node within a configurable time interval.

15. The system (108) as claimed in claim 9, wherein the detection unit (214) is further configured to:clear the at least one detected stale session from the gateway;decrement the connection count by a preconfigured value upon clearing the at least one detected stale session to make a connection slot available for a subsequent connection re-establishment; andre-establish the subsequent connection on the peer node based on the available connection slot.

16. The system (108) as claimed in claim 9, wherein the activity of the one or more sessions comprises the exchange of data packets between the gateway and the peer node, indicative of session operation.

17. 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 (700) for detecting a stale session in a network (106), the method (700) comprising:receiving, by a receiving unit (210), data packets associated with one or more sessions from a peer node connected to a gateway over a communication protocol; monitoring, by a monitoring unit (212), an activity of the one or more sessions based on the received data packets at a configurable time interval; andbased on monitoring the activity, detecting, by a detection unit (214), at least one stale session from the one or more sessions, wherein the at least one stale session is detected based on at least one of a timer-based stale detection technique and a heartbeat-based stale detection technique.

Images