System and method for determining status of nodes in a network

Abstract

The present disclosure provides a system (108) and a method (500) for determining status of one or more nodes in a network (106) The system (108) includes a network entity (208) configured to maintain a first status table that includes the status of one or more destination nodes. The first status table is periodically updated based on a first heartbeat message received from at least one destination node. The first heartbeat message indicates an active status of the at least one node. The network entity (208) receives a request from at least one source node. The network entity (208) checks the first status table to determine the current status of each of the one or more destination nodes in response to the received request. The network entity (208) further routes the request to the at least one destination node having the active status based on checking.

Description

SYSTEM AND METHOD FOR DETERMINING STATUS OF NODES IN A NETWORKTECHNICAL FIELD

[0001] The present disclosure relates generally to the field of telecommunication networks. In particular, the present disclosure relates to a system and a method for determining status of one or more nodes in a network.DEFINITION

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

[0003] The term ‘northbound nodes’ used herein in the specification refers to network entities or systems positioned upstream relative to a Transport Load Balancer (TLB). The northbound nodes primarily represent upstream control entities that initiate requests and interact with the TLB to access resources or services provided by southbound nodes. Examples of northbound nodes may include network management systems, application servers, or user-facing applications.

[0004] The term ‘southbound nodes’ used herein in the specification refers to network systems positioned downstream relative to the TLB. The southbound nodes are responsible for handling and processing data, providing services, and responding to requests from the northbound nodes, often through the TLB. Examples of the southbound nodes may include, but are not limitedto, network functions, databases, or service endpoints directly managed or load-balanced by the TLB.

[0005] The term ‘Transport Load Balancer (TLB)’ used herein in the specification refers to a network element that facilitates load balancing and traffic distribution between one or more available southbound nodes. The TLB receives a request from the northbound nodes and routes the received request to the available southbound nodes based on predefined balancing policies and real-time health checks. The TLB is responsible for optimizing resource utilization, managing failover, and ensuring service continuity in multi-node environments.

[0006] The term ‘User Datagram Protocol (UDP)’ used herein in the specification refers to a connectionless communication protocol within an Internet Protocol (IP) suite that enables data transfer without establishing a formal session. The UDP transmits datagrams without guaranteeing delivery, order, or integrity, making it suitable for time-sensitive applications.

[0007] The term ‘status table’ used herein refers to a data structure maintained by the TLB in a database for tracking real-time operational states of a plurality of southbound nodes and / or the northbound nodes. The status table stores, updates, and retrieves per-node attributes, including health-check results, last-seen timestamps, heartbeat counters, and status indicators (e.g., active or inactive). The status table enables the TLB to make informed load-balancing and failover decisions.

[0008] The term ‘heartbeat message’ used herein refers to a Hypertext Transfer Protocol (HTTP)-based message periodically transmitted by the southbound node and / or the northbound node to the TLB to indicate their operational presence, responsiveness, and availability.

[0009] The term ‘active status’ used herein refers to the operational condition of the southbound node and / or the northbound node when the TLB has successfully received heartbeat messages or health-check responses within a valid time window. A node in active status is considered healthy, reachable, and eligible for receiving traffic from the TLB.

[0010] The term ‘inactive status’ used herein refers to the state of the southbound node and / or the northbound node when the TLB has failed to receive a heartbeat message, health-check response, or acknowledgment within a configurable timeout period. A node with inactive status is deemed unavailable or unreachable and is therefore excluded from receiving the traffic from the TLB.

[0011] The term ‘health-check interval’ used herein refers to the configurable time period within which heartbeat messages are expected to be received by the TLB from the southbound nodes and / or the northbound nodes. The health-check interval represents the allowable duration for assessing node availability and is used to determine node freshness, timeout conditions, or failover decisions.

[0012] The above-mentioned definitions are in addition to those expressed in the art.BACKGROUND

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

[0014] In modern telecommunication networks, a Transport Load Balancer (TLB) is crucial for ensuring seamless communication between network nodes by balancing incoming requests from upstream nodes (e.g., northbound nodes) and distributing them to downstream nodes (e.g., southbound nodes). Further, the TLB is crucial for managing load distribution, fault tolerance, and efficient resource allocation in dynamic network environments where high availability and reliability are required.

[0015] Existing load balancers commonly rely on stateless protocols, such as a User Datagram Protocol (UDP), for quick, connectionless data transfer between the northbound andsouthbound nodes. However, because the UDP is connectionless, it lacks built-in mechanisms for detecting southbound node availability or confirming delivery, which introduces a layer of uncertainty when southbound nodes become unresponsive or unavailable. This limitation is particularly problematic for the TLB, which cannot differentiate between an actively functioning southbound node and a down or unreachable southbound node.

[0016] Currently, there is no efficient mechanism within the TLB using an unreliable transport protocol to determine the real-time status of the southbound nodes. In a scenario, where the southbound nodes become inactive or unreachable, the TLB continues to route traffic to them, resulting in failed data transmissions, inefficiencies, and potential service delays. This inability to verify the southbound node availability increases the risk of data loss and disrupts the user experience, making it difficult for network operators to maintain optimal performance levels across the network.

[0017] Additionally, in distributed or multi-source environments, similar uncertainties may arise regarding the availability of northbound nodes. Since requests are received over a stateless protocol, the TLB has limited visibility into whether the northbound node that originated a request remains active at the time when a response is ready to be delivered. This lack of awareness may cause responses to be sent toward inactive or unreachable source nodes, resulting in unnecessary retries, packet loss, and delayed recovery operations.

[0018] Therefore, conventional techniques do not provide a reliable or coordinated mechanism for determining real-time availability of both southbound nodes and northbound nodes when communicating over unreliable transport protocols. The absence of such mechanisms increases the risk of data loss, leads to inefficient routing decisions, and complicates the ability of network operators to maintain stable and predictable performance across the network.

[0019] There is, therefore, a need for a system and a method that overcomes the limitations of the prior art.OBJECTIVES OF THE PRESENT DISCLOSURE

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

[0021] An objective of the present disclosure is to provide a system and a method for determining a status (e.g., an active status or an inactive status) of one or more nodes in a network.

[0022] Another objective of the present disclosure is to provide a mechanism that enables a Transport Load Balancer (TLB) to determine a real-time status of each of the one or more destination nodes and / or source nodes that communicate with the TLB over non-reliable transport protocols, such as a User Datagram Protocol (UDP).

[0023] Another objective of the present disclosure is to provide an HTTP-based healthcheck mechanism through which the one or more destination nodes and the one or more source nodes may periodically transmit heartbeat messages to the TLB to indicate their availability.

[0024] Another objective of the present disclosure is to enable the TLB to accurately route incoming requests from source nodes to available destination nodes, and to transmit corresponding responses from destination nodes to source nodes that are determined to be active.

[0025] Another objective of the present disclosure is to improve network efficiency and resiliency by identifying inactive destination nodes and / or inactive source nodes, ensuring that network traffic and responses are directed only to nodes that are active.

[0026] Yet another objective of the present disclosure is to reduce the risk of data loss, avoid unnecessary routing attempts, and enhance overall network reliability by maintaining updated availability information for both upstream and downstream nodes.

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

[0028] In an exemplary embodiment, the present disclosure provides a method for determining status of one or more nodes in a network. The method includes maintaining, by a network entity, a first status table that records the status of each of one or more destination nodes. Maintaining the first status table includes receiving, at a configurable time interval, a first heartbeat message from at least one destination node of the one or more destination nodes. The method further includes receiving, by the network entity, a request from at least one source node. The method further includes checking the first status table to determine the status of the at least one destination node in response to the received request. The method further includes routing the received request to the at least one destination node having an active status based on checking the first status table.

[0029] In an embodiment, the first heartbeat message is indicative of the active status of the at least one destination node from the one or more destination nodes.

[0030] In an embodiment, the received request is to be routed to the at least one destination node having the active status.

[0031] In an embodiment, the method further includes periodically updating the first status table based on the first heartbeat message received from the at least one destination node.

[0032] In an embodiment, the request is received from the at least one source node over a User Datagram Protocol (UDP).

[0033] In an embodiment, the method further includes receiving, by the network entity, a second heartbeat message from the at least one source node. The second heartbeat message is indicative of an active status of the at least one source node.

[0034] In an embodiment, the method further includes receiving, by the network entity, a response corresponding to the request from the at least one destination node and, upon receiving the response, transmitting the response to the at least one source node having the active status.

[0035] In an embodiment, the method further includes checking, by the network entity, a second status table to determine the status of the at least one source node upon receiving the response from the at least one destination node. The method further includes holding the response for a configurable time interval when the at least one source node is determined to be inactive and transmitting the response to another source node having an active status when the at least one source node remains inactive during the configurable time interval.

[0036] In an embodiment, the first heartbeat message and the second heartbeat message are Hypertext Transfer Protocol (HTTP)-based messages.

[0037] In an embodiment, the method further includes flagging the status of the at least one destination node and the at least one source node as an inactive status in the first status table and the second status table when no heartbeat message is received from the respective node within the configurable time interval.

[0038] In another exemplary embodiment, the present disclosure provides a system for determining a status of one or more nodes in a network. The system includes a network entity configured to maintain a first status table containing the status of each of one or more destination nodes. To maintain the first status table, the network entity is further configured to receive a first heartbeat message at a configurable time interval from at least one destination node of the one or more destination nodes. The network entity is further configured to receive a request from at least one source node. The network entity is further configured to check the first status table to determine the status of the at least one destination node in response to the received request. The network entity is further configured to route the received request to the at least one destination node having an active status based on checking the first status table.

[0039] In another exemplary embodiment, the present disclosure provides a user equipment (UE) communicatively coupled to a network. The coupling includes receiving, by the network, a connection request from the UE, sending, by the network, an acknowledgment of theconnection request to the UE, and transmitting a plurality of signals in response to the connection request, a status of one or more nodes in the network is determined described herein.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

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

[0041] FIG. 1 illustrates an exemplary network architecture of a system for determining a status of one or more nodes in a network, in accordance with an embodiment of the present disclosure.

[0042] FIG. 2 illustrates a block diagram of the system for determining the status of the one or more nodes in the network, in accordance with an embodiment of the present disclosure.

[0043] FIG. 3 A illustrates a system architecture for determining the status of the one or more southbound nodes in the network, in accordance with an embodiment of the present disclosure.

[0044] FIG. 3B illustrates a system architecture for determining the status of the one or more northbound nodes in the network, in accordance with an embodiment of the present disclosure

[0045] FIG. 4 illustrates an exemplary process flow for determining the status of the one or more nodes in the network, in accordance with an embodiment of the present disclosure.

[0046] FIG. 5 illustrates an exemplary flow diagram of a method for determining the status of the one or more nodes in the network, in accordance with an embodiment of the present disclosure.

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

[0048] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102-1, 102-2... 102-N - Plurality of Users104-1, 104-2... 104-N - Plurality of User Equipment (UEs)106 - Network108 - System200 - Block diagram202 - Processor(s)204 - Memory206 -Interface(s)208 - Network entity210 - Database300 - System Architecture302 - Northbound nodes302a - Source 1302b - Source 2304 - Transport Load Balancer (TLB) 306 - Southbound nodes306a - Destination 1306b - Destination 2400 - Process flow500 - Flow diagram600 - Computer system610 - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port670 - ProcessorDETAILED DESCRIPTION

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

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

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

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

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

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

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

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

[0057] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when the second-generation (2G) technology was introduced. The third generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, fifth generation (5G) technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect manydevices simultaneously. Further, 6G successor to 5G is expected to provide significantly high data speed with reduced latency, which may offer improved connectivity for a vast number of devices concurrently. The capabilities of 6G enable new types of applications and services, such as advanced augmented reality (AR) and virtual reality (VR), holographic communications, and more immersive digital experiences. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (loT) connectivity, and more efficient use of network resources. The sixth generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way of connecting and interacting with technology.

[0058] Transport Load Balancer (TLB) plays an important role in facilitating reliable communication across network nodes by balancing incoming requests from upstream sources (such as northbound nodes) and efficiently routing the incoming requests to downstream destinations (such as southbound nodes). This load distribution is crucial for managing network load, achieving fault tolerance, and optimizing resource utilization in dynamic environments that require high availability and resilience. Existing load balancers often employ stateless protocols, such as User Datagram Protocol (UDP), for rapid, connectionless data exchange between nodes. However, the connectionless nature of UDP lacks mechanisms for verifying node availability or ensuring message delivery, creating ambiguity when a southbound node becomes unresponsive or unreachable. This uncertainty poses challenges for the TLB, as it cannot reliably distinguish between the operational or active southbound node and the inactive or inaccessible southbound node.

[0059] Currently, there is no efficient mechanism within the TLB that may determine the real-time availability of downstream or the southbound nodes (destination nodes). When southbound nodes become inactive or unreachable, the TLB may continue routing requests toward that node, leading to failed data transmissions, additional retries, increased latency, and overallnetwork inefficiency. Similarly, in multi-source environments, the TLB may not be able to confirm whether upstream or a northbound node (the source node that initiated the request), remains active when the corresponding response becomes available. This creates situations where responses may be directed toward inactive or unreachable northbound nodes, resulting in unnecessary network overhead, dropped responses, and degradation in service quality.

[0060] To address the challenges associated with the above-mentioned problems, the present disclosure provides a solution in the way that the TLB may employ a policy-based Hypertext Transfer Protocol (HTTP) health-check approach to determine the availability of both destination nodes (southbound nodes) and source nodes (northbound nodes). Under this mechanism, each directly connected node may periodically transmit an HTTP-based heartbeat message to the TLB to indicate its active status. When a heartbeat message is not received from a given node within a configurable time interval or a predefined number of intervals, that node may be flagged as inactive. By maintaining updated availability information for both upstream and downstream nodes, the TLB may ensure that only active destination nodes receive traffic and that responses are transmitted only to active source nodes, thereby improving overall routing efficiency, reducing data loss, and enhancing the reliability and resilience of the network.

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

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

[0063] FIG. 1 illustrates an exemplary network architecture (100) of a system (108) for determining the status of one or more nodes in a network, in accordance with an embodiment of the present disclosure.

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

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

[0066] Additionally, in some embodiments, the UE (104) may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a headmounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one ormore in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

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

[0068] 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. The network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0069] In an embodiment, the UE (104) is communicatively coupled with the system (108) via 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. Upon establishing the connection, the system (108) is configured to determine the status of one or more destination nodes in the network (106). The UE (104) may be present at a source (i.e., at the northbound node) that may be responsible for generating at least one request corresponding to the routing of network traffic from the northbound node. The system (108) may be configured to receive the at least one request from the UE (104) via the network (106). The system (108) may be configured to route the at least one request to one or more southbound nodes based on their status.

[0070] 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).

[0071] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) configured for determining the status of the one or more nodes in the network (106), in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with FIG. 1. In an embodiment, the system (108) may be implemented at a network entity (208).

[0072] The network entity (208) may correspond to a Transport Load Balancer (TLB). The TLB may be responsible for receiving incoming requests from a source node (also referred to as a northbound node) and distributing the requests across one or more destination nodes (also referred to as southbound nodes) based on their current availability. The TLB may manage load distribution, ensure efficient utilization of downstream resources, and prevent routing of traffic to destination nodes that are inactive or unavailable. In an alternative embodiment, the TLB may also manage the availability of source nodes by monitoring their operational status and ensuring that responses received from the destination nodes are transmitted only to those source nodes that are currently active. This allows the TLB to avoid sending responses to inactive or unreachable sourcenodes and enables the system to hold or redirect responses when a source node is determined to be inactive.

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

[0074] In an embodiment, the one or more processor(s) (202) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the one or more processor(s) (202). Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the system (108). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the one or more processor(s) (202) may be processorexecutable instructions stored on a non-transitory machine-readable storage medium, and the hardware for the one or more processor(s) (202) 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 one or more processor(s) (202). In such examples, the system 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 thesystem and the processing resource. In other examples, the network entity (208) may be implemented by electronic circuitry.

[0075] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. 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 network entity (208) and a database (210).

[0076] In an embodiment, the network entity (208) is configured to determine the status of the one or more destination nodes (e.g., the one or more southbound nodes) in the network (106). In an embodiment, the one or more southbound nodes may represent network components, resources, or systems that are positioned downstream relative to the network entity (208) (also referred to as the TLB). The southbound nodes may serve as endpoints responsible for receiving and processing data, executing service-related operations, or supporting application workflows initiated by northbound nodes. The northbound nodes may route requests toward the southbound nodes through the TLB, and the southbound nodes, in turn, may provide the required computational or service-related output. Examples of such southbound nodes may include, but are not limited to, network functions, database systems, application servers, service endpoints, or any downstream node that is configured to process incoming traffic handled by the TLB.

[0077] In order to determine the status of the one or more destination nodes, the network entity (208) is configured to receive at least one request from at least one source node (also referred to as at least one northbound node). The at least one request may be received over a User Datagram Protocol (UDP) connection. In an embodiment, the request received from the northbound node may be a UDP-based request. UDP is a connectionless communication protocol that supports transmission of datagrams without establishing a persistent session, making it suitable for applications that prioritize low latency over guaranteed delivery. As the network entity (TLB) is required to handle a large volume of lightweight and time-sensitive requests, UDP enables thesource nodes to send requests quickly without the overhead of connection setup or teardown. This allows the source nodes to transmit traffic bursts efficiently, minimizes processing delays introduced by transport-layer procedures, and reduces the load on the TLB in high-throughput environments. Furthermore, the stateless nature of UDP allows the TLB to treat each request independently, which is advantageous when the network entity rapidly distribute traffic across multiple destination nodes.

[0078] The at least one request may include one or more data packets (e.g., network traffic) intended for routing to the one or more destination nodes. For example, the data packets may include control messages, service requests, application data, monitoring information, or any other network traffic intended to be processed by the one or more destination nodes. The northbound node may represent network components or systems positioned upstream relative to the TLB and typically serve as client-side or control-oriented entities that initiate communication toward the network entity (208). Such a northbound node may generate and forward the request intended for downstream processing by one or more destination nodes through the TLB. Examples of the northbound node may include, but are not limited to, network management systems, application servers, or user- facing applications.

[0079] Prior to receiving the at least one request, the network entity (208) may be configured to maintain a first status table in the database (208) associated with the network entity (208). The first status table may store the status of each of the one or more southbound nodes. The status associated with each destination node indicates whether the node is in an active state or an inactive state. The node that is in the active state indicates its availability to process the received request. The node that is in the inactive state indicates its non-availability to process the received request. In an embodiment, to maintain the first status table, the network entity (208) may receive a first heartbeat message at a configurable time interval from at least one destination node of the one or more destination nodes. The configurable time interval may represent a predefined duration within which each destination node is expected to transmit its heartbeat message to the network entity (208). The time interval may be set by an administrator based on system requirements,network load, or the criticality of the services handled by the destination nodes. For example, the configurable time interval may be set to 5 seconds in a high-availability environment where rapid detection of node failure is required, or it may be configured as 30 seconds, 1 minute, or any other suitable duration in networks where traffic patterns are less intensive. The time interval may also be dynamically adjustable by the administrator or a control function to accommodate changing network conditions or operational policies.

[0080] In an embodiment, the first heartbeat message may correspond to a Hypertext Transfer Protocol (HTTP)-based message. Such a message may include basic header information, a status indicator, a timestamp, or a minimal payload necessary to confirm that the destination node is active. As HTTP is widely supported and operates over standard network interfaces, using the HTTP-based message allows for simple implementation, easy integration with existing systems, and reliable communication across different network environments.

[0081] Based on the first heartbeat message received from the at least one destination node of the one or more destination nodes, the network entity (208) may periodically update the first status table. To further elaborate, in order to periodically update the first status table, the network entity (208) may use an HTTP-based health-check mechanism. In the HTTP-based health-check mechanism, the network entity (208) receives a periodic heartbeat message from at least one destination node of the one or more destination nodes that is in an active state. Each heartbeat message may include node information, such as a node identifier (ID) and an active status of the respective node. The heartbeat messages may be received regularly, either based on a configurable time interval or for a configurable number of times. For example, the configurable time interval may be set to 5 seconds, 10 seconds, or 30 seconds, during which each destination node is expected to transmit at least one heartbeat message to indicate that it remains active. Alternatively, the network entity (208) may expect a heartbeat message to be received a predefined number of times, such as three consecutive intervals, before confirming that the destination node is active or determining that the node has become inactive. These periodic heartbeat messages allow the network entity (208) to maintain an up-to-date view of node availability and ensure that the firststatus table accurately reflects the operational state of each destination node. In an embodiment, the network entity (208) may maintain only a limited amount of status information in the first status table to ensure storage efficiency, such that outdated or unnecessary entries are discarded or overwritten as new heartbeat information becomes available. For example, the TLB may retain only the most recent heartbeat entry per destination node to minimize storage consumption while still maintaining an accurate, up-to-date view of node availability.

[0082] When the network entity (208) receives the at least one request from the at least one northbound node, the network entity (208) may check the first status table to identify which of the nodes are flagged with the active status. Checking the first status table may include reading the most recent status entry stored for each destination node and determining whether the node has been marked as active based on the heartbeat messages previously received from that node. In an embodiment, when the network entity (208) receives the first heartbeat message from the at least one destination node of the one or more destination nodes, the network entity (208) flags that particular destination node with the active status in the first status table, indicating that the at least one destination node is available and capable of handling the at least one request (e.g., the network traffic). The first status table is then updated accordingly to reflect the active status.

[0083] Alternatively, when the network entity (208) does not receive the first heartbeat message from the at least one destination node of the one or more destination nodes within the configurable time interval or for a configurable number of times, the network entity (208) flags the corresponding destination node with the inactive status in the first status table. During the checking operation, the network entity (208) may identify such nodes as unavailable based on their last recorded status entry. The inactive status indicates that the node is either unresponsive or unavailable for handling the network traffic. The status is then updated in the first status table accordingly to reflect the inactive status.

[0084] The network entity (208) may then route the at least one request to the at least one node having the active status. Routing the request may include selecting, from the first status table, the at least one destination node that is currently marked as active and forwarding the requesttoward such node for further processing. In an embodiment, the network entity (208) may examine the status information stored in the first status table, identify the destination node that is available, and direct the incoming network traffic to that node to ensure that the request is processed by a responsive and operational downstream resource. The selective routing prevents the TLB from sending traffic to nodes that are inactive or unreachable, thereby reducing unnecessary retransmissions, avoiding processing delays, and improving overall network efficiency. In some embodiments, when multiple destination nodes are identified as active, the network entity (208) may choose any of the active nodes based on predefined policies, such as load distribution criteria or node priority.

[0085] In an alternative embodiment, in addition to maintaining the first status table for monitoring the availability of one or more destination nodes, the network entity (208) may also be configured to maintain a second status table that records the status of one or more source nodes. The second status table may store status information associated with upstream nodes (e.g., northbound nodes) that transmit requests to the network entity (208). Monitoring the availability of source nodes is important because, in stateless communication environments, a source node that initiates a request may become inactive or disconnected by the time a corresponding response is ready. Without visibility into the source node’s availability, the network entity (208) may send the response to an unreachable node, leading to wasted network resources, failed deliveries, and potential service degradation. Each entry in the second status table may reflect whether a corresponding source node is currently active or inactive, based on heartbeat messages received from that node.

[0086] To determine the availability of the source nodes, the network entity (208) may receive a second heartbeat message from at least one source node at a configurable time interval. Similar to the first heartbeat message received from the destination nodes, the second heartbeat message may be an HTTP-based message that includes node information such as a node ID, a timestamp, and an indication of the active status of the source node. The network entity (208) may periodically update the second status table based on the second heartbeat messages received,ensuring that the status information remains current while maintaining only a limited amount of status data to preserve storage efficiency.

[0087] Upon receiving a response corresponding to the request from the at least one destination node, the network entity (208) may check the second status table to determine whether the source node that originally transmitted the request remains active. If the source node is flagged with the active status, the network entity (208) may directly transmit the response to that source node. The response may include data or information generated as part of processing the original request, such as processed payload data, status information, acknowledgment messages, results of service execution, or any output generated by the destination node in response to the incoming network traffic. This ensures that responses are sent only to upstream nodes that are available to receive and process them, thereby reducing unnecessary transmission attempts and preventing potential loss of potential information.

[0088] In an embodiment, when the network entity (208) determines that the source node is inactive, based on the absence of heartbeat messages within a configurable time interval, the network entity (208) may hold the response for a configurable time interval. Holding the response allows the source node an opportunity to regain active status by sending a subsequent heartbeat message during the holding period. When the source node becomes active within the holding interval, the network entity (208) may transmit the response to that node. For example, the holding interval (configurable time interval for holding the response) may be configured as 5 seconds, during which the network entity (208) temporarily stores the response in the database and waits for the source node to retransmit a heartbeat message. If the source node becomes active again within those 5 seconds, the network entity (208) may immediately forward the response to that node. In an embodiment, the holding interval may be dynamically adjustable based on network conditions, node behavior, traffic load, or administrative policies, allowing the system to adapt the waiting time to operational requirements.

[0089] Alternatively, when the source node remains inactive throughout the configurable holding interval, the network entity (208) may transmit the response to another source node that isflagged with the active status in the second status table. In certain deployment scenarios, multiple source nodes may share a common role, function, or service context and may be configured to receive or process the same category of responses. For example, a group of source nodes may operate as redundant controllers, monitoring agents, or load-generating entities that are collectively capable of consuming the response generated by the destination node. In such cases, redirecting the response to an alternative active source node ensures that the output of the downstream processing is not lost and continues to be utilized by an appropriate upstream entity. The redirection of response to the alternative active source node ensures continuity of communication and prevents loss of critical information, especially in environments where multiple upstream nodes may be capable of consuming the response. Thus, by maintaining separate status tables and processing heartbeat messages from both northbound and southbound nodes, the network entity (208) ensures reliable request routing and response delivery even when communicating over non-reliable, stateless transport protocols such as UDP.

[0090] In an alternative embodiment, when the network entity (208) determines that the source node (304) remains inactive even after the expiration of the configurable holding interval, the network entity (208) may optionally notify the destination node that the corresponding source node is unavailable. Such a notification enables the destination node to take corrective actions, such as discarding the prepared response, logging the event, initiating a retry handling procedure, or adjusting its resource allocation. This optional feedback mechanism ensures that downstream nodes are aware of upstream unavailability, thereby improving system coordination, preventing unnecessary resource consumption, and enhancing overall network robustness.

[0091] In an embodiment, the database (210) associated with the network entity (208) (TLB) includes data (e.g., the first status table, the second status table, network traffic, status information of the one or more southbound nodes, status information of the one or more northbound nodes, request information, etc.) that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engine (208).

[0092] 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).

[0093] FIG. 3 A illustrates a system architecture (300 A) for determining the status of the one or more southbound nodes in the network (106), in accordance with an embodiment of the present disclosure. FIG. 3 A is explained in conjunction with FIGS. 1 -2. Examples of the network (106) may include a Fourth Generation (4G) network, the 5G network, a Sixth-Generation network (6G) network, and the like.

[0094] The system architecture (300A) includes at least one source (302), a TLB (304), and one or more southbound nodes (306) (destination 1 306-a, destination 2306-b) that are directly connected to the TLB (304) over an unreliable transport protocol, such as UDP. In an aspect, the at least one source (302) may correspond to the at least one northbound node that may be responsible for generating the UDP-based request. The UDP-based request may include data packets, such as audio data, video streaming data, telemetry data, or similar time-sensitive information. UDP is a connectionless protocol that enables fast and lightweight data transfer without the overhead of connection establishment, making it suitable for applications requiring low-latency or burst-based transmission. The source (302) may represent various types of network elements, application servers, or user-facing applications that need to send network traffic downstream to other nodes (e.g., the southbound nodes) in the network.

[0095] The UDP-based request generated by the source (302) (northbound node) is directed towards the TLB (304). In an aspect, the TLB (304) may be responsible for distributing network load or traffic based on the status (e.g., active status or inactive status) of the one or more southbound nodes (306). The TLB (304) acts as an intermediary and ensures that only active southbound nodes receive the UDP-based request, thereby enhancing network reliability andefficiency. The TLB (304) routes the incoming UDP-based request from the source node (302) to at least one southbound node with active status, which is currently operational to handle the traffic.

[0096] The status of each southbound node is determined using the HTTP-based healthcheck mechanism implemented at the TLB (304). The health-check mechanism may include receiving the HTTP-based heartbeat message (also referred to as an API call) from at least one southbound node of the one or more directly connected southbound nodes (306) to the TLB (304). Each heartbeat message is indicative of the active status of the respective southbound node. If TLB (304) does not receive the HTTP-based heartbeat message (e.g., the first heartbeat message) from the at least one southbound node for a configurable time interval or for a configured number of cycles then, the at least one southbound node may be declared as inactive or unavailable southbound node. In other words, the API call indicates the availability of the directly connected southbound nodes. Based on the health-check mechanism, the TLB (304) may determine whether it can handle UDP-based requests received from the source (302) (e.g., the at least one northbound node) or not. This mechanism ensures that the TLB (304) only routes data packets (e.g., the network traffic) to the southbound nodes that are currently available or have active status.

[0097] The one or more southbound nodes (306) (also referred to destination nodes) include destination 1 (306a) and destination 2 (306b), each of which has an associated status that reflects its availability in the network. In the example shown in FIG. 3 A, the destination 1 (306a) marked with an ‘X’, indicating an inactive status of at least one southbound node from the one or more southbound nodes (306) directly connected to the TLB (304). This means that the southbound node in destination 1 (306a) is either unresponsive or unavailable, possibly due to network issues, maintenance, or downtime. The inactive status prevents the TLB (304) from routing traffic to this unavailable node, thus avoiding potential packet loss or failed communication. Further, the destination 2 (306b) is marked with ’, indicating its active status. This indicates that the southbound node in the destination 2 (306b) is operational, responsive, and capable of receiving and processing the network traffic. The TLB (304) may therefore route incoming UDP-basedrequests from the source (302) to destination 2 (306b) since it is the currently available and operational node.

[0098] Therefore, by continuously receiving availability signals from each directly connected southbound node, the TLB (304) maintains an accurate and real-time understanding of the readiness of downstream nodes. This prevents traffic from being routed to nodes that are unreachable or malfunctioning, thereby reducing packet loss, improving service continuity, and enhancing overall network reliability. Additionally, because the mechanism functions effectively over a stateless and unreliable protocol such as UDP, it enables low-latency traffic distribution while still ensuring dependable node selection. This proactive and lightweight monitoring framework optimizes network efficiency, minimizes recovery time in the event of node failures, and contributes to improved resource utilization throughout the system.

[0099] FIG. 3B illustrates a system architecture (300B) for determining the status of the one or more northbound nodes in the network (106), in accordance with an embodiment of the present disclosure. FIG. 3B is explained in conjunction with FIGS. 1 - 3A. Similar to the southbound-monitoring scenario shown in FIG. 3 A, FIG. 3B shows an alternative embodiment in which the TLB (304) additionally monitors the availability of multiple upstream nodes (i.e., northbound nodes or source nodes) that send requests to the TLB (304) over an unreliable transport protocol, such as UDP. In an embodiment, the TLB (304) further includes an internal memory (304a) configured to store responses received from southbound nodes when corresponding source nodes are unavailable.

[0100] The system architecture (300B) includes one or more source nodes (302), the TLB (304), and one or more directly connected southbound nodes (306). The source nodes (302) may include, for example, Source 1 (302a) and Source 2 (302b), each functioning as a northbound node capable of transmitting UDP-based requests to the TLB (304). In an embodiment, the source nodes (302) may correspond to network management systems, application servers, control-plane entities, or user-facing applications responsible for generating upstream traffic. A set of multiple sources(302a, 302b...302N) may collectively be referred to as the source node (302) or the at least one northbound node.

[0101] Each source node (302) may generate a UDP-based request that is transmitted to the TLB (304). In an example, as depicted in FIG. 3B, Source 1 (302a) is associated with a checkmark (‘ ”), indicating that the node is currently in an active status, whereas Source 2 (302b) is associated with an “X”, indicating that the node is inactive or unavailable. In an embodiment, the active or inactive status of the northbound nodes may be determined through a periodic HTTPbased heartbeat mechanism similar to the one used for southbound nodes. The source nodes (302) may periodically send a second heartbeat message (e.g., an HTTP-based API call) to the TLB (304), where each heartbeat indicates the availability or unavailability of the respective northbound node.

[0102] In an embodiment, the TLB (304) may maintain a second status table that records the active status and inactive status of each of the northbound nodes based on the heartbeat messages received. When a heartbeat message (second heartbeat message) is received from a northbound node within a configurable time interval, that particular northbound node is flagged as active in the second status table. Conversely, when no second heartbeat message is received from a northbound node for a configurable number of intervals, the TLB (304) may update the second status table to flag that northbound node as inactive.

[0103] In an embodiment, the TLB (304) may utilize the second status table to determine whether a northbound node is available to receive responses corresponding to the UDP-based requests previously transmitted. When a response is received from a southbound node while the corresponding source node is inactive, the TLB (304) may store the response in the internal memory (304a) for a configurable holding interval. This ensures that responses routed from the southbound nodes are delivered only to northbound nodes that are currently active and capable of receiving the communication. If the source node becomes active within the configurable holding interval, the TLB (304) retrieves the stored response from the internal memory (304a) and transmits the response to the source node. In this manner, the system architecture 300B preventsresponse delivery failures caused by sending packets to upstream nodes that may have gone offline, crashed, or become unreachable.

[0104] In an alternative embodiment, when the TLB (304) determines that the source node remains inactive beyond the configurable holding interval, the TLB (304) may optionally notify the corresponding destination node that the intended source node is unavailable to receive the response. Such a notification enables the destination node to take appropriate actions, such as discarding the response, recording the event, adjusting its scheduling workflow, or reallocating processing resources. This feedback mechanism enhances synchronization between the southbound and northbound components of the system, minimizes unnecessary retries or buffering at the destination node, and contributes to more efficient end-to-end network behavior.

[0105] On the downstream side, similar to FIG. 3A, FIG. 3B also includes directly connected southbound nodes (306), such as Destination 1 (306a) and Destination 2 (306b). As depicted, Destination 1 (306a) is marked with an “X” (inactive), while Destination 2 (306b) is marked with a ‘ ” (active). The downstream status information is derived using the first heartbeat message from the southbound nodes and maintained in the first status table at the TLB (304). FIG.3B collectively illustrates a scenario where the TLB (304) maintains two independent status tables, one for source nodes and one for destination nodes, ensuring reliable upstream and downstream routing.

[0106] In an alternative embodiment, when the TLB (304) receives a response from the southbound node corresponding to the request originally sent by the northbound node, the southbound node may temporarily act as a “source” node for the response path, and the northbound node may act as a “destination” node. In such a scenario, the logical direction of communication is reversed. For example, the southbound node may act as the source node (originating the response), and the northbound node may act as the destination node (receiving the response).

[0107] Such embodiment is particularly important in environments where responses from downstream nodes may be forwarded with high reliability. Before transmitting the response to theoriginal northbound node, the TLB (304) may check the second status table to verify whether the target northbound node remains active. If the source node has transitioned to an inactive state, the TLB may hold the response for a configurable time interval or redirect the response to another active northbound node capable of receiving or processing the data.

[0108] The system architecture 300B provides several significant benefits. By incorporating health-check mechanisms for both northbound and southbound nodes, the TLB (304) maintains a synchronized, real-time view of bidirectional node availability. This ensures that requests are routed only to active downstream nodes, responses are transmitted only to active upstream nodes, packet loss is minimized in both directions, and failover handling becomes seamless for both request and response paths. The network achieves higher resiliency, fault tolerance, and service continuity. By maintaining separate status tables and supporting dynamic role reversal for nodes, the system provides a robust and flexible framework suitable for nextgeneration networks (e.g., 4G, 5G, 6G) where both high-speed UDP communication and reliable availability tracking are required.

[0109] FIG. 4 illustrates an exemplary process flow (400) for determining the status of one or more nodes in the network (106), in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 1 - 3.

[0110] At step 402, the TLB (304) receives a health-check API call (e.g., a first heartbeat message) from the directly connected one or more southbound nodes. In other words, the directly connected one or more southbound nodes send the API message to the TLB (304), declaring their availability and operational status.

[0111] At step 404, after receiving the health-check API call, the TLB (304) checks the current status of each southbound node. In particular, the detection process involves the HTTPbased health-check mechanism where the TLB (304) receives the HTTP-based heartbeat message from at least one southbound node of the one or more directly connected southbound nodes. Each HTTP-based heartbeat message indicates the active status of the at least one southbound node fromthe one or more southbound nodes. If the TLB (304) receives the HTTP-based heartbeat message from the at least one southbound node within the configured time interval or for the configured number of times, the status of the respective at least one southbound node is considered active. Alternatively, if there is no heartbeat message from the at least one southbound node within the configured time interval or for the configured number of times, then the status of the respective at least one southbound node is considered as inactive. The HTTP-based health-check process is essential for assessing the connectivity and availability of each southbound node in real-time.

[0112] At step 406, the TLB (304) checks the status of each southbound node based on the detection results from the previous step. If the status of the southbound node is determined to be active, the process proceeds to step 408.

[0113] At step 408, if the TLB (304) has identified the at least one southbound node as active, it flags the at least one southbound node as available for serving the UDP-based request. This means that the TLB (304) may route the incoming traffic from the source (302) to the at least one active southbound node, ensuring efficient load balancing across the network. The availability of the at least one southbound node for the UDP-based request implies that the at least one node is in a healthy state and ready to process data packets. By marking the southbound node as available, the TLB (304) optimizes network performance by routing the UDP-based request (e.g., network traffic) only to operational destinations.

[0114] At step 410, if the TLB (304) determines that the at least one southbound node is inactive, it flags the at least one southbound node as unavailable for serving the UDP-based request. This designation prevents the TLB (410) from sending the network traffic to unresponsive or non-functional southbound nodes, thereby avoiding packet loss and enhancing network reliability. The southbound node indicated as unavailable ensures that network resources are not wasted on nodes that cannot process requests, contributing to more effective load distribution.

[0115] The health-check mechanism helps in maintaining an accurate and real-time status table for the one or more southbound nodes, ensuring better monitoring and reliability of thesystem (108). In an embodiment, the status table (first status table) refers to a structured data table or grid maintained by the system (108) that records the current status (e.g., active status or inactive status) of each southbound node. Each entry in the first status table represents the real-time availability information of a specific southbound node. The first status table allows the system (108) to quickly identify which nodes are operational and can handle requests, enabling effective monitoring, efficient routing, and reliable decision-making. This real-time status table is essential for the TLB (304) to make informed decisions about where to direct network traffic based on the current health and availability of the one or more southbound nodes.

[0116] FIG. 5 illustrates an exemplary method (500) for determining the status of one or more nodes in the network (106), in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1 -4. The method (500) is executed by the network entity (208), such as the TLB (304).

[0117] At step (502), the network entity (208) maintains a first status table that stores the status (e.g., active or inactive) of each of the one or more destination nodes. The first status table may be stored in a memory (204) or database (210) associated with the network entity (208).

[0118] To maintain the first status table, at step (504), the network entity (208) receives a first heartbeat message at a configurable time interval from at least one destination node. The first heartbeat message may be an HTTP-based message indicating the active status of the corresponding destination node. The configurable time interval may vary based on system requirements (e.g., every 2 seconds, 5 seconds, etc.). Upon receiving the first heartbeat message, the network entity (208) periodically updates the first status table to mark the corresponding destination node as active.

[0119] At step (506), the network entity (208) receives a request from at least one source node. In an embodiment, the request is received over a UDP connection. In an embodiment, the source node corresponds to a northbound node that generates data packets intended to be routedto one or more destination nodes. The one or more destination nodes corresponds to the one or more southbound nodes.

[0120] At step (508), the network entity (208) checks the first status table upon receiving the request. The checking operation includes identifying the current status (active or inactive) of the at least one destination node to which the request is to be routed. The network entity (208) determines whether the at least one destination node is active based on the information updated in the first status table at step (504).

[0121] At step (510), the network entity (208) routes the received request to at least one destination node having an active status based on the result of checking the first status table. In an embodiment, routing the request only to active nodes prevents failed transmissions and ensures that network traffic is forwarded to nodes that are available and responsive.

[0122] In an alternative embodiment, apart from determining the status of destination nodes (southbound nodes), the network entity (208) may also be configured to determine the status of source nodes (northbound nodes). To determine the status of source node, the network entity (208) receives a second heartbeat message from the source node. The second heartbeat message, which may also be an HTTP-based message, indicates the active status of the source node. This information may be stored in a second status table, which stores the status of all source nodes.

[0123] Upon routing the request to the active destination node, the network entity (208) may receive a response corresponding to the request from that destination node. The response may include processed output, acknowledgements, or service-related information generated by the destination node. When the response is received, the network entity (208) transmits the response back to the source node, provided that the source node is marked active in the second status table.

[0124] In an embodiment, when the source node is determined to be inactive, based on the absence of the second heartbeat message within the configurable time interval, the network entity (208) may hold the response for a configurable period. This holding interval allows the sourcenode to potentially become active again. For example, the network entity may hold the response for 5 seconds, waiting for a heartbeat update from the source node. If the source node becomes active during this interval, the response is transmitted to that source node.

[0125] If the source node remains inactive beyond the configurable time interval (holding interval), the network entity (208) may transmit the response to another source node having the active status. This ensures the response is not lost and may be consumed by another upstream node capable of processing the result.

[0126] In an embodiment, the network entity (208) may flag the status of destination nodes and source nodes as inactive in their respective status tables when no heartbeat message is received from them within the configurable time interval. Flagging ensures that traffic is not routed, or responses are not transmitted to unresponsive nodes.

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

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

[0129] In an embodiment, the communication port (660) may be any of an RS -232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication port (660) may be chosen depending on the network (106), such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects.

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

[0131] In an embodiment, the mass storage (650) may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PAT A) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or FireWire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).

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

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

[0134] The present disclosure provides significant technical advancements in achieving reliable, real-time availability determination of network nodes in environments that rely onstateless and non-reliable transport protocols, such as UDP. Conventional TLBs lack mechanisms to verify the operational status of upstream or downstream nodes, resulting in the possibility of routing traffic to unresponsive destination nodes or transmitting responses to inactive source nodes. Such limitations contribute to packet loss, increased service latency, and inefficient utilization of network resources. The present disclosure overcomes these deficiencies by introducing a network entity equipped with an HTTP-based heartbeat mechanism that enables the dynamic, periodic assessment of the availability of both destination nodes (southbound) and source nodes (northbound). A key technical enhancement lies in the ability of the network entity (TLB) to maintain one or more status tables that store real-time node availability states based on heartbeat messages received at configurable intervals. By updating the status tables dynamically and flagging nodes as active or inactive without requiring connection-oriented signaling, the system ensures accurate routing of incoming UDP-based requests only to destination nodes that are currently operational. Similarly, by incorporating a secondary heartbeat mechanism for source nodes, the network entity enables intelligent response handling, including response holding, conditional retransmission, and failover to alternate source nodes when the originally requesting node becomes inactive.

[0135] This dual-direction health-validation framework provides a substantial improvement over existing approaches by offering end-to-end reliability in otherwise connectionless communication flows. The present disclosure also improves scalability by allowing large numbers of nodes to be monitored using lightweight, standardized HTTP-based heartbeats while maintaining storage efficiency through controlled, size-conscious status table management. Collectively, these technical advancements increase routing precision, minimize service interruptions, prevent loss of critical responses, enhance fault tolerance, and strengthen overall network robustness in distributed, latency-sensitive, and high-availability communication systems.

[0136] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is notlimited 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.ADVANTAGES OF THE PRESENT DISCLOSURE

[0137] The present disclosure provides a method and a system for determining the status (e.g., an active status or an inactive status) of one or more nodes in a network, thereby enabling accurate and real-time availability assessment across distributed network environments.

[0138] The present disclosure provides a mechanism for direct identification of the unavailability of destination nodes (e.g., southbound nodes) that are connected to a Transport Load Balancer (TLB) over a non-reliable transport protocol such as UDP. By using an HTTP-based health-check mechanism, the system quickly detects when a destination node becomes inactive or unreachable, minimizing routing errors and data transmission failures.

[0139] The present disclosure provides an API-based framework that allows the directly connected destination nodes to periodically transmit HTTP-based heartbeat messages to the TLB. These periodic updates ensure that the TLB maintains a real-time and accurate first status table representing the availability of every destination node.

[0140] The present disclosure enables the TLB to route incoming network traffic from at least one source node only to destination nodes with an active status. This reduces the risk of data loss, prevents failed communication attempts, and improves overall network reliability by ensuring that only available nodes receive traffic.

[0141] The present disclosure also provides a mechanism to determine the availability of source nodes (e.g., northbound nodes) by using a second heartbeat message and maintaining a second status table. This dual-direction monitoring ensures that responses generated by destination nodes are transmitted only to source nodes that are currently active and capable of receiving them.

[0142] The present disclosure improves fault tolerance by enabling the TLB to temporarily hold a response when the source node becomes inactive and subsequently deliver the response when the source node resumes activity. If the source node remains inactive, the system can automatically redirect the response to another active source node, thereby preventing the loss of critical information and ensuring continuity of operations.

[0143] The present disclosure achieves storage efficiency by maintaining status information in compact, size-controlled status tables. This controlled table size allows the system to scale across a large number of source and destination nodes without imposing excessive memory overhead.

Claims

CLAIMSWe claim:

1. A method (500) for determining a status of one or more nodes in a network (106), the method (500) comprising:maintaining (502), by a network entity (208), a first status table comprising the status of each of one or more destination nodes, wherein maintaining the first status table comprises:receiving (504), by the network entity (208), a first heartbeat message at a configurable time interval from at least one destination node of the one or more destination nodes;receiving (506), by the network entity (208), a request from at least one source node; checking (508), by the network entity (208), the first status table to determine the status of the at least one destination node in response to the received request; androuting (510), by the network entity (208), the received request to the at least one destination node having an active status based on checking the first status table.

2. The method (500) as claimed in claim 1, wherein the first heartbeat message is indicative of the active status of the at least one destination node from the one or more destination nodes.

3. The method (500) as claimed in claim 1, wherein the received request is to be routed to the at least one destination node having the active status.

4. The method (500) as claimed in claim 1, further comprising:periodically updating, by the network entity (208), the first status table based on the first heartbeat message received from the at least one destination node of the one or more destination nodes.

5. The method (500) as claimed in claim 1, wherein the request is received from the at least one source node over a User Datagram Protocol (UDP).

6. The method (500) as claimed in claim 1, further comprising:receiving, by the network entity (208), a second heartbeat message from the at least one source node, wherein the second heartbeat message is indicative of the active status of the at least one source node.

7. The method (500) as claimed in claim 6, further comprising:receiving, by the network entity (208), a response corresponding to the request from the at least one destination node; andupon receiving, transmitting, by the network entity (208), the response to the at least one source node having the active status.

8. The method (500) as claimed in claim 7, further comprising:checking, by the network entity (208), a second status table to determine the status of the at least one source node upon receiving the response from the at least one destination node; holding, by the network entity (208), the response corresponding to the request for a configurable time interval when the at least one source node is determined to be inactive; and transmitting, by the network entity (208), the response to another source node having an active status when the at least one source node remains inactive during the configurable time interval.

9. The method (500) as claimed in claim 1, wherein the first heartbeat message and the second heartbeat message are Hypertext Transfer Protocol (HTTP)-based messages.

10. The method (500) as claimed in claim 1, further comprising:flagging, by the network entity (208), the status of the at least one destination node and the at least one source node as an inactive status in the first status table and the second status table, when no heartbeat message is received from the at least one destination node and the at least one source node within the configurable time interval.

11. A system (108) for determining a status of one or more nodes in a network (106), the system (108) comprising:a network entity (208), wherein the network entity (208) is configured to:maintain a first status table comprising the status of each of one or more destination nodes, wherein to maintain the first status table, the network entity (208) is configured to:receive a first heartbeat message at a configurable time interval from at least one destination node of the one or more destination nodes;receive a request from at least one source node;check the first status table to determine the status of the at least one destination node in response to the received request; androute the received request to the at least one destination node having an active status based on checking the first status table.

12. The system (108) as claimed in claim 11, wherein the first heartbeat message is indicative of the active status of the at least one destination node from the one or more destination nodes, and wherein the received request is to be routed to the at least one destination node having the active status.

13. The system (108) as claimed in claim 11, wherein the network entity (208) is further configured to:periodically update the first status table based on the first heartbeat message received from the at least one destination node of the one or more destination nodes.

14. The system (108) as claimed in claim 11, further comprising:receiving, by the network entity (208), a second heartbeat message from the at least one source node, wherein the second heartbeat message is indicative of the active status of the at least one source node.

15. The system (108) as claimed in claim 14, wherein the network entity (208) is further configured to:receive a response corresponding to the request from the at least one destination node; andupon receiving, transmit the response to the at least one source node having the active status.

16. The system (108) as claimed in claim 15, wherein the network entity (208) is further configured to:check a second status table to determine the status of the at least one source node upon receiving the response from the at least one destination node;hold the response corresponding to the request for a configurable time interval when the at least one source node is determined to be inactive; andtransmit the response to another source node having an active status when the at least one source node remains inactive during the configurable time interval.

17. The system (108) as claimed in claim 11, wherein the first heartbeat message and the second heartbeat message are Hypertext Transfer Protocol (HTTP)-based messages, and wherein the request is received from the at least one source node over a User Datagram Protocol (UDP).

18. The system (108) as claimed in claim 11, the network entity (208) is further configured to:flag the status of the at least one destination node and the at least one source node as an inactive status in the first status table and the second status table, when no heartbeat message isreceived from the at least one destination node and the at least one source node within the configurable time interval.

19. A user equipment (UE) (104) communicatively coupled to a network (106), the coupling comprises steps of:receiving, by the network (106), a connection request from the UE (104);sending, by the network (106), an acknowledgment of the connection request to the UE (104); andtransmitting a plurality of signals in response to the connection request, wherein a status of one or more nodes in the network (106) is determined by a method (500) as claimed in claim 1.

Images