System and method for managing transport layer connection in a network

Abstract

The present disclosure provides a system (108) and a method (600) for managing a transport layer connection between a source node (302) and a destination node (306) in a network (106). The system (108) includes a receiving unit (202) configured to receive at least one request from an external system for configuring at least one of a new source node and a new destination node. The system (108) includes a processing unit (208) configured to extract one or more parameters from the received at least one request, configure at least one of the new source node and the new destination node based on the one or more extracted parameters, establish a transport layer connection between the new configured source node and the new configured destination node, and manage data flow between the new configured source node and the new configured destination node over the established transport layer connection.

Description

SYSTEM AND METHOD FOR MANAGING TRANSPORT LAYER CONNECTION IN A NETWORKRESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of telecommunications. In particular, it relates to a system and a method for managing at least one transport layer connection between a source node and a destination node in a network.DEFINITION

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

[0004] The term “Transport Load Balancer (TLB)” used hereinafter in the specification refers to a load balancer that operates at the transport layer of the Open Systems Interconnection (OSI) model. The TLB manages incoming traffic at the transport layer using various protocols, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). The TLB distributes the incoming traffic across multiple sources or destinations based on transport layer information, such as an internet protocol (IP) address and port number.

[0005] The term “Transmission Control Protocol (TCP)” used hereinafter in the specification refers to a connection-oriented transport layer protocol that enables communication between devices over a network. The TCP allows full-duplex communication, which permits both sender and receiver to send and receive data simultaneously.

[0006] The term “User Datagram Protocol (UDP)” used hereinafter in the specification refers to a transport layer protocol that allows low- latency, connectionless communication between devices in IP networks. The UDP is often used for applications where speed is prioritized over reliability.

[0007] The term “Stream Control Transmission Protocol (SCTP)” used hereinafter in the specification refers to a transport layer protocol that enables multiple message streams within a single connection. The SCTP is designed for high-reliability and sequencing applications, such as telecommunication signaling.

[0008] The term “Internet Protocol (IP)” used hereinafter in the specification refers to a network layer protocol in the OSI model, responsible for addressing, packetizing, and routing data across packet-switched networks, including the Internet. The IP operates at Layer 3 (network layer) and provides the foundation for communication across interconnected devices. The IP ensures that data packets can be delivered from the source host to the destination host based on their unique IP addresses.

[0009] The term “Layer 4 (L4)” used hereinafter in the specification refers to the fourth layer (Transport Layer) in the OSI model, responsible for the reliable transfer of data between the end systems (hosts) across a network. L4 lies directly above the Network Layer (layer 3) and provides a communication service to applications, ensuring the data transmitted between devices is delivered reliably, in order, and without errors (if applicable). L4 handles tasks such as flow control, error detection,segmentation, and reassembly of data.

[0010] The term “Remote Authentication Dial-In User Service (RADIUS)” used hereinafter in the specification refers to an application-layer protocol used for providing centralized authentication, authorization, and accounting for users accessing the network.

[0011] The term “Diameter protocol” used hereinafter in the specification refers to an authentication, authorization, and accounting (AAA) protocol configured to replace and extend the RADIUS protocol. The diameter protocol provides more robust and secure capabilities and manages network access, data usage, and service billing in various communication systems, including IP-based networks, telecommunications, and wireless systems.

[0012] The term “Mobile Application Part (MAP)” used hereinafter in the specification refers to a protocol used in Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) networks for messaging and roaming, allowing different network nodes to communicate within mobile telecommunications.

[0013] The term “northbound node” used hereinafter in the specification refers to a source-side node that communicates in an upstream direction within a layered network architecture. The northbound node is responsible for sending requests or initiating transport-layer connections.

[0014] The term “southbound node” used hereinafter in the specification refers to a destination-side node that communicates in a downstream direction within the layered network architecture. The southbound node receives and processes incoming transport layer connections from the northbound node.

[0015] The term “listening port” used hereinafter in the specification refers toa transport layer endpoint on which a system or node actively listens for incoming connection requests. The listening port is defined by a combination of an IP address and a port number.

[0016] The term “Application Programming Interface (API)” used hereinafter in the specification refers to a set of software-defined rules and interfaces that allow external systems to programmatically configure source nodes and destination nodes by providing parameters such as IP addresses, port numbers, and protocol information.

[0017] The term “connection request” used hereinafter in the specification refers to a transport-layer request initiated by a source node (northbound node) for establishing a communication path with a destination node using protocols such as TCP, UDP, or SCTP.

[0018] The term “application interface” used hereinafter in the specification refers to a logical identifier or interface exposed by the destination node (southbound node) for receiving incoming connection requests or data from a source node.

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

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

[0021] In telecommunications, efficient handling of transport layer connections is critical for ensuring reliable and seamless communication between source and destination nodes. Network traffic, whether originating from applications, services, ordevices, often needs to be routed through multiple layers and managed effectively to avoid congestion, latency, and potential data loss. Conventionally, in the transport layer (the fourth layer of the Open Systems Interconnection (OSI) model), handling incoming and outgoing connections typically involves context switching and extensive lookup tables to map incoming connections to appropriate outgoing connections, which adds complexity and overhead.

[0022] In modern network systems and distributed architectures, configuring new source nodes and destination nodes at runtime may lead to service downtime, especially when these configurations involve changes to critical network components or services. When new nodes (representing interfaces between the network services, databases, or microservices) are introduced, several critical tasks must be performed, such as validating the endpoints, updating routing tables, and reallocating resources. These activities may disrupt ongoing service operations as the system adapts to the new configuration. For example, network routers, application layers, or load balancers may need reconfiguring to support the newly configured nodes, leading to brief service interruptions. Additionally, validating the integrity and security of the new nodes, provisioning resources, and updating service discovery mechanisms often require network traffic to be temporarily rerouted, causing downtime or inaccessibility.

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

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

[0025] An objective of the present disclosure is to provide a system and a method for efficiently managing transport layer (L4) connections in a network.

[0026] Another objective of the present disclosure is to provide a system and a method for seamlessly integrating a source node or a destination node into the network without interrupting existing services or requiring service disruptions.

[0027] Yet another objective of the present disclosure is to provide a system and a method for configuring a new destination endpoint, allowing it to be directly associated with a configured source endpoint as soon as a new incoming transport connection arrives. This ensures that the newly added destination endpoints are instantly operational and can handle traffic without waiting for manual mapping or causing delays in traffic processing.

[0028] Yet another objective of the present disclosure is to provide a system and method for efficiently managing L4 connections in the network, allowing for optimal resource allocation and better data routing between the source and destination nodes.

[0029] Yet another objective of the present disclosure is to provide a system and method for dynamically routing traffic based on source and destination information. This dynamic routing capability ensures that the traffic is routed to the most appropriate node (endpoint) based on real-time data about network conditions, resource availability, or predefined policies.

[0030] Another objective of the present disclosure is to provide a system and method for reducing network latency and improving overall network performance. By ensuring that new endpoints are quickly integrated into the network and that connections are established with minimal overhead, the system reduces delays and enhances the responsiveness of the network.

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

[0032] In an exemplary embodiment, the present disclosure provides a method for managing at least one transport layer connection between a source node and a destination node in a network. The method includes receiving, by a receiving unit, at least one request from an external system for configuring at least one of a new source node and a new destination node. The method further includes extracting, by a processing unit, one or more parameters from the received request. The extracted parameters include at least one source node parameter and at least one destination node parameter. Based on the one or more parameters, the method includes configuring, by the processing unit, at least one of the new source node and the new destination node. The method further includes establishing, by the processing unit, a transport layer connection between the newly configured source node and the newly configured destination node. The method further includes managing, by the processing unit, a data flow between the newly configured nodes over the established transport layer connection.

[0033] In an embodiment, configuring the new source node includes setting up, by the processing unit, a new listening port for the newly configured source node based on at least one transport protocol.

[0034] In an embodiment, the at least one transport protocol includes at least one of Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Stream Control Transmission Protocol (SCTP).

[0035] In an embodiment, the method further includes receiving, by the processing unit, an incoming connection request from the newly configured source node at the newly created listening port. The method further includes analyzing, by the processing unit, the incoming connection request to determine whether a requested destination node corresponds to the newly configured destination node or an existingdestination node. Based on the determination, the method includes establishing, by the processing unit, an outgoing connection with the appropriate destination node.

[0036] In an embodiment, configuring the newly configured destination node includes listing, by the processing unit, the new destination node corresponding to the new source node in a database.

[0037] In an embodiment, the source node is a northbound node, and the destination node is a southbound node.

[0038] In an embodiment, the method further includes configuring, by the processing unit, the new source node using an Application Programming Interface (API) based on the at least one source node parameter, and configuring the new destination node using the API based on the at least one destination node parameter.

[0039] In an embodiment, the at least one source node parameter includes at least one of a source node Internet Protocol (IP) address, a source node port number, a transport protocol type, an application protocol, and a transport layer listening point. The at least one destination node parameter includes a destination node IP address, a destination node port number, a transport protocol type, and an application interface.

[0040] In another exemplary embodiment, a system for managing at least one transport layer connection between a source node and a destination node is disclosed. The system includes a receiving unit configured to receive at least one request from an external system for configuring at least one of a new source node and a new destination node. The system includes a memory for storing the received request. The system further includes a processing unit coupled to the memory configured to extract one or more parameters from the received at least one request. The one or more extracted parameters comprise at least one source node parameter and at least one destination node parameter. The processing unit further configures at least one of the new source node and the new destination node based on the one or more extracted parameters,establishes a transport layer connection between the new configured source node and the new configured destination node, and manages data flow between the new configured source node and the new configured destination node over the established transport layer connection.

[0041] In yet another exemplary embodiment, the present disclosure provides a computer program product comprising a non-transitory computer-readable medium having instructions stored thereon. When executed by one or more processors, the instructions cause the one or more processors to execute a method for managing at least one transport layer connection between a source node and a destination node. The method includes receiving, by a receiving unit, at least one request from an external system for configuring at least one of a new source node and a new destination node. The method further includes extracting, by a processing unit, one or more parameters from the received request. The extracted parameters include at least one source node parameter and at least one destination node parameter. Based on the one or more parameters, the method includes configuring, by the processing unit, at least one of the new source node and the new destination node. The method further includes establishing, by the processing unit, a transport layer connection between the newly configured source node and the newly configured destination node. The method further includes managing, by the processing unit, a data flow between the newly configured nodes over the established transport layer connection.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

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

[0043] FIG. 1 illustrates an exemplary network architecture of a system for managing at least one transport layer connection between a source node and a destination node in a network, in accordance with an embodiment of the present disclosure.

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

[0045] FIG. 3 illustrates an exemplary system architecture for managing the at least one transport layer connection between the source node and the destination node in the network, in accordance with an embodiment of the present disclosure.

[0046] FIG. 4 illustrates an exemplary flow diagram of a method for configuring a new source node in the network, in accordance with an embodiment of the present disclosure.

[0047] FIG. 5 illustrates an exemplary flow diagram of a method for configuring a new destination node in the network, in accordance with an embodiment of the present disclosure.

[0048] FIG. 6 illustrates an exemplary flow diagram of a method for managing the at least one transport layer connection between the source node and the destination node in the network, in accordance with an embodiment of the present disclosure.

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

[0050] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture 102 - User(s)104 - User Equipment (UE)106 - Network108 - System200 - Block diagram 202 - Receiving unit204 - Memory206 - Interface(s)208 - Processing unit210 - Database 300 - System Architecture302-1 - Source 1302-2 - Source 2302 -N - Source N304 - Transport Load Balancer (TLB)306-1 - Destination 1306-2 - Destination 2306-N - Destination N400, 500, 600 - Flow Diagram700 - Computer system710 - External Storage Device720 - Bus730 - Main Memory740 - Read Only Memory750 - Mass Storage Device760 - Communication Port770 - ProcessorDETAILED DESCRIPTION

[0051] 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 ofthe 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.

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

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

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

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

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

[0057] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that theterms “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.

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

[0059] 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 many devices simultaneously. Further, 6G successor to 5G is expected to provide significantly high data speed with reduced latency, which may offer improvedconnectivity 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.

[0060] The rapid advancement of network technologies has led to a significant increase in data traffic and the growing complexity of network infrastructures. As businesses and organizations deploy increasingly sophisticated applications and services, the volume, diversity, and speed of data flowing through networks have expanded dramatically. Traditional network architectures, often designed with static traffic models in mind, are frequently unable to handle the escalating demands of modern network traffic efficiently. This results in performance bottlenecks, latency issues, and reduced network scalability. As a result, service providers and network administrators face increasing pressure to optimize network performance, reduce operational costs, and ensure a seamless user experience.

[0061] New client applications or services may need to connect to the system as business requirements evolve. For instance, if a company launches a new mobile application or website, new northbound endpoints are required to serve these applications. Similarly, as new backend systems or devices are added, new southbound endpoints are required to handle the interactions between the upper layers and these new services. For example, a company may expand its services to include a new type of device (e.g., a smart thermostat in an loT-based platform), requiring new southboundendpoints to facilitate communication with that device. In modern distributed systems, services are typically divided into multiple layers, each responsible for specific tasks. The northbound and southbound endpoints help establish a clear separation of concerns between these layers, enabling more manageable, scalable, and flexible architectures.

[0062] There is a need for dedicated mapping when integrating new northbound nodes (endpoint) and new southbound nodes (endpoint). The northbound endpoints typically connect to higher layers of the architecture, such as user-facing applications, external Application Programming Interfaces (APIs), or cloud services. The southbound endpoints often interface with lower layers, including devices, sensors, or backend systems. When configuring new endpoints in these layers, a dedicated mapping process becomes essential to ensure traffic can flow correctly between the two endpoints. This mapping ensures that requests originating from the northbound system are properly routed to the appropriate southbound service and that the data flow remains consistent, secure, and reliable. Configuring new source and destination endpoints is often necessary to scale or extend the network's capabilities. However, this introduces operational challenges that may impact service availability and system integration.

[0063] Hence, there is a need to provide a method and a system that can address the shortcomings of existing solutions.

[0064] The present disclosure relates to a method and system for managing a transport connection between a source node (northbound endpoint) and a destination node (southbound endpoint) in a network. The disclosed method automates the connection management and path formation between the dedicated source and destination nodes through an API-driven process. The disclosed method involves configuring new northbound and southbound endpoints via the API calls, with a Transport Load Balancer (TLB) facilitating the connection. When a new source endpoint is configured, a listening point is set up at the TLB, using the API details suchas Source IP, Source port, Transport Type, Application protocol, and L4 listening point. Similarly, a new destination endpoint is configured, with the API details including Destination IP, Destination Port, Transport Type, and Application interface. Upon receiving an incoming connection from a newly configured northbound endpoint, the TLB forms an outgoing connection to the relevant southbound endpoint. Additionally, if the incoming connection arrives from an already configured northbound endpoint, it may be routed to the newly configured southbound endpoint. This method ensures efficient connection management and dynamic routing between endpoints.

[0065] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1- 7.

[0066] FIG. 1 illustrates an exemplary network architecture (100) of a system (108) for managing at least one transport layer connection between a source node and a destination node in a network (106), in accordance with an embodiment of the present disclosure. In an aspect, the source node may refer to one or more devices or applications that initiate the connection. For example, the source may be a web server, a database server, or a client application. In an aspect, the destination node refers to one or more devices or applications that are the target of the connection. For example, the destination may be a web browser, a database client, or another server.

[0067] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102 -N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may be collectively referred to as the UE (104). Although only three UEs (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.

[0068] 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 is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, 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, multisensing, network- connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud- computing system or any other device that is network-connected.

[0069] Additionally, in some embodiments, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a tablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but is 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 or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from theuser (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.

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

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

[0072] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104).The network (106) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. Upon establishing the connection, the system (108) is configured to manage at least one transport layer connection between the source node and the destination node in the network (106).

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

[0074] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for managing the at least one connection between the at least one source node and the at least one destination node in the network (106), in accordance with an embodiment of the present disclosure. In an embodiment, the system (108) may be implemented in a Transport Load Balancer (TLB).

[0075] In an example, the source node may be a northbound node, and the destination node may be a southbound node. In one aspect, the northbound node typically represents an endpoint that provides services to higher layers of a system architecture or external systems, often handling client-facing or user-facing operations. The northbound node may be an application, Application Programming Interface (API), or interface exposed to the outside world for accessing data, initiating transactions, or interacting with other applications. The northbound node may be configured to initiate traffic that needs to be routed to a lower-level node or backend service. In another aspect, the southbound node is configured to be connected to the lower layers of the system architecture, managing communication with internalsystems, backend services, infrastructure, or devices. The southbound nodes are generally responsible for data processing, storage, or the actual execution of business logic. The southbound node receives requests, typically from the northbound node (the source node), and processes them accordingly.

[0076] In an embodiment, the system (108) may include a receiving unit (202) and a processing unit (208). The processing unit (208) 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 processing unit (208) 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.

[0077] In an embodiment, the system (108) may include an interface (206). The interface (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 (206) may facilitate communication through the system (108). The interface (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, the processing unit (208) and a database (210).

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

[0079] In an embodiment, the receiving unit (202) may be configured to receive at least one request from an external system for configuring at least one of a new source node (northbound node) and a new destination node (southbound node). In some embodiments, the external system may be any system capable of issuing a configuration request, such as, but not limited to, a network management system (NMS), an operations support system (OSS), an orchestrator, a provisioning gateway, or an automation script.

[0080] In an exemplary embodiment, the receiving unit (202) may expose an interface such as a Command line interface (CLI). The external system may be operated autonomously or under the supervision of a network administrator. For example, the external system may monitor network traffic and determine when new nodes are required (for instance, when scaling the network or integrating new services). The external system may send the at least one request (via CLI command) to the receiving unit (202) to ensure that new endpoints are provisioned in real time. The CLI offers a text-based interface that enables administrators and automated scripts to interact withthe system (108). Through the CLI, the external system can send requests that trigger specific actions within the network, such as configuring the new northbound node and the new southbound node. Using the CLI, the at least one request may be hit as per the requirement of the addition of the new northbound node or the new southbound node.

[0081] In an exemplary embodiment, the at least one request may be received through the network, such as, but not limited to, Ethernet, Wi-Fi, or internet. The at least one request may be encapsulated in a packet and transmitted over the network (106). Encapsulation refers to the process of wrapping configuration information within a protocol packet, which contains metadata such as the destination IP address, source IP address, port numbers, and protocol types. The encapsulated packet may then be transmitted over the network in a manner consistent with the OSI model, specifically focusing on the Transport Layer (Layer 4), which ensures that the data reaches its destination reliably. The transport connection facilitates the routing of data packets across the network (106).

[0082] In an embodiment, for configuring at least one of the new source node (northbound node) and the new destination node (southbound node), processing unit (208) may extract one or more parameters from the received at least one request. In particular, when configuring the new source node, the at least one incoming request may include one or more source node parameters, such as, but not limited to, a source IP address, a source port number, a transport protocol, an application protocol, and an L4 listening point. Similarly, when configuring the new southbound node, the at least one incoming request may include one or more destination node parameters, such as, but not limited to, a destination IP address, a destination port number, a Transport Type, and an application interface.

[0083] In an embodiment, the source IP address defines the network address assigned to the new northbound node and uniquely identifies it within the IP network. The source port number specifies the port on which the northbound node may listen forincoming connections, enabling multiple services to operate under the same IP address using distinct port values. The transport protocol type (such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP)) indicates the communication protocol to be used at the transport layer. The application protocol refers to the higher-layer protocol (for example, HTTP, Diameter, MAP, RADIUS, DNS, or any other protocol), which enables the receiving system to interpret incoming data appropriately. The L4 listening point refers to the specific combination of the source IP address and source port number at which the northbound node may receive incoming transport- layer connections.

[0084] In an embodiment, the destination IP address identifies the southbound node within the network and specifies the target endpoint to which outgoing connections may be directed. The destination port number corresponds to the particular application or service running on the southbound node that is intended to receive the forwarded traffic. The transport protocol type identifies the protocol (such as TCP, UDP, or SCTP) for establishing the outgoing transport-layer connection toward the destination node. The application interface refers to a logical identifier, service endpoint, or protocol-specific interface (such as a Diameter interface, MAP interface, RADIUS interface, HTTP endpoint, or microservice interface) exposed by the southbound node for receiving requests originating from the source node. These destination node parameters collectively facilitate the establishment and management of the outgoing connection between the TLB and the southbound node.

[0085] To extract the one or more parameters from the received at least one request, the processing unit (208) may perform a parsing operation on the received request. The parsing may include, for example, decoding the structure of the incoming request, identifying individual fields within the request payload, and interpreting the parameter values associated with each field. In one example, the processing unit (208) may decode the request payload to identify parameters such as the source IP address,source port number, transport protocol type, application protocol, destination IP address, destination port number, transport type, and application interface. Additionally, the processing unit (208) may validate the extracted one or more parameters to ensure that the received information is complete, syntactically correct, and compliant with the expected formats.

[0086] Once the one or more parameters are extracted, the processing unit (208) may configure at least one of the new source node and the new destination node based on the one or more extracted parameters. In an embodiment, the configuration of the new source node (northbound node) and the new destination node (southbound node) may be performed through an Application Programming Interface (API). The API may expose a dedicated configuration interface that allows an external system to create, modify, or update northbound or southbound endpoints without requiring any service interruption or system restart. The API may receive, validate, and process the at least one source node parameter and at least one destination node parameter, and may translate these parameters into internal configuration directives executed by the processing unit (208). In an embodiment, the API may support operations such as endpoint creation, endpoint activation, endpoint update, and endpoint association, thereby enabling real-time provisioning of transport- layer endpoints in a live network environment. The API may further include request-response mechanisms, authentication and authorization controls, and status reporting capabilities to ensure secure, consistent, and controlled configuration of new endpoints.

[0087] For example, when the processing unit (208) configures the new northbound node based on the extracted source node parameters received through the API, it prepares the northbound node to communicate properly within the network. This configuration process ensures that the newly added northbound node, typically an entry point for client-facing or external systems, is equipped with the necessary network attributes to facilitate seamless communication. In an aspect, the processingunit (208) may assign the source IP address to the newly configured northbound node, configure the source port number, and select the transport protocol type (e.g., TCP, UDP, or SCTP) specified in the request. The processing unit (208) may optionally configure the application protocol (e.g., HTTP, FTP, DNS, Diameter), enabling compatibility with upper-layer applications that interact with the northbound node.

[0088] In another embodiment, the processing unit (208) may similarly configure the new destination node (southbound node) through the same API mechanism, based on the extracted destination node parameters. The API may convey the destination node parameters to configure the southbound node by assigning the destination IP address, destination port number, and transport protocol type, and by enabling the appropriate application interface for receiving forwarded traffic. Optionally, the processing unit (208) may configure the application interface associated with the southbound node, such as a Diameter interface, MAP interface, RADIUS interface, HTTP endpoint, or a microservice-specific API interface, to enable proper reception and processing of traffic forwarded from the northbound node. The API thus provides a unified and standardized mechanism for dynamically configuring both northbound and southbound nodes, allowing the system to adapt quickly to new services, scale horizontally, and introduce new endpoints without downtime. This ensures that the destination node is prepared to receive, interpret, and process application-specific traffic.

[0089] In an embodiment, as part of configuring the new source node (northbound node), the processing unit (208) may further set up a new listening port for the newly configured source node based on the at least one transport protocol specified in the extracted parameters. In some embodiments, the processing unit (208) may allocate a dedicated transport-layer listening endpoint that combines the source IP address and the newly assigned port number, enabling the source node to receive incoming transport-layer connections. Optionally, the listening port may be configureddifferently depending on the transport protocol type. For example, when the transport protocol is TCP, the listening port is configured to accept connection-oriented sessions. When the transport protocol is UDP, the listening endpoint is configured to receive connectionless datagrams. Additionally, when the transport protocol is SCTP, the listening point is configured to support multi-stream associations.

[0090] In an embodiment, once the listening port for the source node is configured, the processing unit (208) may receive an incoming connection request from the newly configured source node at the newly established listening port. The incoming connection request may include information such as the destination identifier, transport protocol, and other connection attributes. In some embodiments, the processing unit (208) may perform validation of the received request, such as verifying the format of the request message, confirming the transport protocol type, or checking source-node authenticity.

[0091] After receiving the incoming connection request, the processing unit (208) may analyze the request to determine whether the destination node referenced in the incoming request corresponds to the newly configured destination node or to an existing destination node already maintained within the system (108). This determination may be based on parameters such as the destination IP address, destination port number, or application interface indicated in the incoming request. In some embodiments, the processing unit (208) may compare these values against entries stored in the database (210) associated with the TLB to determine whether a new destination node should be paired with the source node or whether the connection should be directed to an existing, previously configured destination node. Such analysis enables accurate routing of the incoming connection toward the appropriate destination endpoint.

[0092] Based on the determination of whether the requested destination node is newly configured or already existing, the processing unit (208) may establish anoutgoing connection with the appropriate destination node. When the destination node is the newly configured southbound node, the processing unit (208) may initiate a fresh outgoing transport-layer connection using the transport protocol indicated in the request. When the destination node corresponds to an existing southbound node, the processing unit may use the previously created configuration and database entry to initiate the outgoing connection. In either case, the outgoing connection creates a communication path that allows the system to pair the inbound connection from the source node with the outbound connection toward the destination node.

[0093] In an embodiment, configuring the new destination node (southbound node) may include listing the newly configured destination node in the database (210). In an embodiment, the database (210) may be associated with the TLB (304) and is configured to store configuration records associated with the newly configured destination node, including the destination IP address, destination port number, transport protocol type, and the corresponding application interface. The database (210) may also store associations between the source node and the destination node to facilitate future routing decisions. The listing may include storing the destination IP address, destination port number, transport protocol type, application interface, and an association with the corresponding source node. By maintaining this record, the system (108) ensures that subsequent incoming requests referencing the same destination parameters can be resolved efficiently.

[0094] To further elaborate, for configuring the new southbound node, the processing unit (208) may list a new southbound node corresponding to the newly configured northbound node. In an aspect, the southbound node may already exist or may be configured. In another embodiment, the processing unit (208) may be configured to identify the at least one destination node based on the destination IP address and the destination port number. This identification process is essential to routing the data packets to the correct endpoint, as it uniquely defines the target locationwithin the network. By specifying the destination, the TLB ensures that the connection path is configured to deliver data to the correct recipient. Further, the processing unit (208) may be configured to identify the at least one transport protocol associated with the transport connection request. The transport protocol may be one of several types, such as the TCP, the UDP, or the SCTP.

[0095] In an embodiment, the processing unit (208) may further select (list) the at least one destination node based on the type of traffic carried in the incoming connection request from the source node. For example, if the incoming request includes a Diameter message transported over TCP, the processing unit (208), in conjunction with the TLB, may route that traffic towards a destination node that is specifically configured to process Diameter signaling. This traffic-aware selection mechanism allows the system (108) to dynamically direct applications or protocols to their most appropriate processing nodes. In practice, this means that certain protocol types, such as Diameter for policy control in telecommunications, can be routed specifically to nodes optimized for handling the Diameter traffic.

[0096] After the new source node and the new destination node are configured, the processing unit (208) establishes a transport layer connection between the new configured source node and the new configured destination node. In particular, the processing unit (208) may establish a bidirectional transport layer connection between the newly configured source node and the selected destination node. In an embodiment, establishing the transport layer connection may include initiating an outgoing transport-layer session from the system (108) toward the selected destination node using the transport protocol specified in the extracted parameters (TCP, UDP or SCTP). The processing unit (208) sets up the transport layer connection (Layer 4), ensuring that traffic from the northbound node is properly routed to the southbound node. When the selected protocol is TCP, the processing unit (208) may perform the TCP three-way handshake to establish the outgoing connection. Once the connection is set up, theprocessing unit (208) configures routing rules or load balancing policies to ensure that when traffic arrives at the northbound node, it is forwarded to the correct southbound node for processing. In some environments, particularly in dynamic and distributed systems, the processing unit (208) in conjunction with TLB, may utilize API gateways to dynamically manage the mapping between northbound and southbound nodes. Once the mapping is established, the processing unit (208) may route the incoming traffic from the northbound node to the southbound node, based on the routing rules defined by the TLB. This ensures that data packets flow smoothly between the source and destination systems.

[0097] Once the transport layer connection between the newly configured source node and the newly configured destination node is established, the processing unit (208) may manage the data flow between the two nodes over the established transport layer connection. To manage the data flow, the processing unit (208) may forward data packets received from the source node to the destination node and may forward data packets received from the destination node to the source node. Further, the processing unit (208) may maintain session state information to ensure that data packets belonging to the same session follow the correct path. Further, the processing unit (208) may apply flow-control or congestion-control mechanisms that are appropriate for the transport protocol used for the connection. Further, the processing unit (208) may buffer data packets, may reorder data packets when out-of-order delivery occurs, and may apply policies to prioritize specific traffic. The processing unit (208) may also enforce routing or forwarding rules to direct the traffic toward the correct destination node. Additionally, the processing unit (208) may monitor the status of the transport connection, may detect failures or performance degradation, and may switch the data flow to an alternative destination node when required.

[0098] In an overall aspect, to manage the transport layer connection between the source node and the destination nodes, the TLB sets up a new listening point assoon as a new northbound endpoint is configured. For configuring the new northbound endpoint, the API may require details such as the Source IP address, the Source port number, the Transport Type, the Application protocol, and the L4 listening point. In a similar manner, a new southbound endpoint is listed at the TLB as soon as the new southbound endpoint is configured. For configuring the new southbound endpoint, the API may require details such as the Destination IP address, the Destination port number, the Transport Type, and the Application interface. Once an incoming connection arrives at the TLB from the newly configured northbound endpoint, the TLB forms the corresponding outgoing connection with the configured southbound endpoint. Additionally, when an incoming connection arrives from an already configured northbound endpoint, the TLB forms the corresponding outgoing connection with the newly configured southbound endpoint.

[0099] The disclosed system (108) enables automated configuration of source nodes and destination nodes through well-defined APIs, which reduces manual intervention and minimizes configuration errors. The system (108) further provides the capability to dynamically set up new listening points for newly configured northbound endpoints, thereby supporting rapid onboarding of new services and applications. The system (108) also enables seamless formation of corresponding outgoing connections upon receiving incoming connections from either newly configured or already configured northbound endpoints, ensuring consistent and reliable transport-layer communication. By maintaining destination-node information in a database, the system (108) supports efficient lookup, routing, and reuse of existing endpoint configurations. Additionally, the ability to analyze incoming connection requests and determine the appropriate destination node enhances routing intelligence and operational flexibility. The system (108) also improves overall data-flow management by enabling controlled forwarding, flow regulation, and monitoring over established transport-layer connections.

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

[0101] FIG. 3 illustrates an exemplary system architecture (300) for managing the at least one transport layer (L4) connection between the source node and the destination node in the network ( 106), in accordance with an embodiment of the present disclosure.

[0102] In an embodiment, the system architecture (300) may include one or more sources (source 1 302-1, source 2 302-2, source N 302-N), the TLB (304) and one or more destinations (destination 1 306-1, destination 2 306-2, destination N 306- N). The one or more sources (302-1, 302-2, 302-N) may collectively be referred to as a source node (302) (also known as a northbound node). The one or more destination nodes (306-1, 306-2, 306-N) may collectively be referred to as a destination node (306) (also known as a southbound node). The system architecture (300) demonstrates how incoming connections from the source node (302) are handled by the TLB (304) and subsequently routed to the destination node (306), based on specific connection protocols and traffic types. The system architecture (300) optimizes data flow and resource allocation while ensuring efficient connection management between nodes.

[0103] In an embodiment, the TLB (304) is a central component responsible for managing transport connections. The TLB (304) is connected to the at least one source node (302) and the at least one destination node (306), allowing it to monitor and control traffic between them. The TLB (304) plays a crucial role in handling incoming transport connection requests by identifying the source, destination, and transport protocol associated with each request. Upon receiving an incomingconnection request from the source node, the TLB (304) first examines the details of the source and destination nodes, including IP addresses and port numbers, as well as the type of transport protocol used, which may include TCP, UDP, or SCTP. This identification enables the TLB (304) to establish an appropriate outgoing connection to the destination based on the identified attributes.

[0104] In an embodiment, the TLB (304) is configured to segregate incoming connection requests based on the type of traffic associated with each connection. The system (108) distinguishes connections based on the application layer protocol (e.g., Diameter, MAP, or RADIUS) that may be transmitted over Layer 4 (L4) protocols such as TCP, UDP, or SCTP.

[0105] In an embodiment, the TLB (304) has multiple endpoints, each configured to handle specific sources and traffic types. Each endpoint is exposed to a specific source node (302), meaning that any connection request received on that endpoint is expected to originate from the associated source. When a connection request arrives at this endpoint, the TLB (304) verifies that the connection originates from the expected source node and validates the traffic type.

[0106] In an embodiment, once the TLB (304) verifies and authenticates the incoming connection (between the source node and the TLB), the TLB (304) initiates an outgoing connection to the appropriate destination node (306). The TLB (304) couples the incoming and outgoing connections by creating a logical construct that maintains both connections’ critical identifiers. This logical construct, or “connection pair,” includes the source IP address, source port, destination IP address, and destination port for both the incoming and outgoing connections. By establishing and maintaining this construct within the TLB (304), the system (108) can seamlessly forward data packets between the source and destination without requiring repeated lookup or mapping of connection attributes.

[0107] In an embodiment, the logical coupling of connections within the TLB (304) allows for efficient, real-time routing of data packets. With both the source and destination connections maintained as part of a shared construct, the TLB (304) may directly forward packets from one connection to the other without additional processing. This setup avoids delays associated with database or cache lookups and minimizes overhead. As a result, when the TLB (304) receives data packets on one side of the connection pair, it can instantly route them to the corresponding side, ensuring low-latency data flow and efficient network utilization. When an unexpected or unauthorized traffic type is detected, the TLB (304) also handles error responses. If the traffic type associated with an incoming connection does not match the expected application-layer protocol (e.g., if non-Diameter traffic is received on an endpoint configured for Diameter-over-TCP), the TLB (304) may reject the connection. In such cases, a negative response is sent from the destination node (306) to the TLB (304), which then relays the rejection back to the source node (302). This feedback loop ensures that only authorized traffic types are routed through the system (108), enhancing security and maintaining network integrity.

[0108] In an embodiment, the TLB (304) establishes two-way communication between the source node (302) and the destination node (306), which may depend on the transport protocol specified in the incoming connection request. For example, when the source node (302) initiates a request using TCP, the TLB (304) may accept the incoming TCP connection by completing a TCP three-way handshake on the configured listening port. Once the handshake is complete, the TLB (304) may initiate a corresponding outgoing TCP connection toward the selected destination node (306), thereby forming a bidirectional TCP communication path. This two-way TCP connection allows reliable, ordered, and congestion-controlled data transfer between the nodes.

[0109] In cases where the source node (302) uses UDP, the TLB (304) mayreceive UDP datagrams on a designated UDP listening endpoint. Because UDP is connectionless, the TLB (304) may identify the source IP address, source port, and UDP pay load attributes to determine the correct destination node. The TLB (304) may then generate corresponding UDP datagrams toward the destination node (306), thereby enabling a two-way exchange of stateless datagram traffic. This mechanism is suitable for applications requiring low latency or applications that do not require the overhead of connection establishment.

[0110] When the source node (302) uses SCTP, the TLB (304) may receive an SCTP association request on the SCTP-configured listening point. The TLB (304) may optionally perform SCTP-specific procedures, such as verification tag validation and association parameter negotiation. Once the incoming SCTP association is recognized, the TLB (304) may establish a corresponding SCTP association toward the selected destination node (306). As SCTP supports multi-streaming and multihoming, the TLB (304) may maintain multiple independent logical streams within the same association, enabling parallel, ordered, or unordered delivery based on application requirements. This setup allows efficient forwarding of multi-stream data between the source and destination nodes.

[0111] In an exemplary embodiment, consider a scenario in which the external system detects the need to onboard a new application server that may act as a northbound node for handling Diameter-over-TCP traffic. The external system transmits an API request to the TLB (304) containing the source node parameters, for example, a source IP address of 192.168.10.15, a source port of 3869, a transport protocol type of TCP, an application protocol of Diameter, and an L4 listening point associated with the new service. Upon receiving this request, the TLB (304) extracts and validates these parameters and configures the new northbound node accordingly. In the same operational cycle, the external system may also configure a new southbound node that serves as a Diameter backend server, for example, with1 destination IP address 10.20.5.25, destination port 3868, transport type TCP, and an application interface for policy control. The TLB (304) stores the destination node information in the database (210) and associates it with the newly configured source node. When an incoming TCP connection subsequently arrives at the TLB (304) from the configured northbound node on port 3869, the TLB (304) identifies the appropriate destination node based on the stored configuration and immediately establishes an outgoing TCP connection toward the backend server at 10.20.5.25:3868. Once both connections are active, the TLB (304) forms a logical connection pair and begins forwarding Diameter messages between the source node and the destination node in real time. Throughout the session, the TLB (304) manages data flow by maintaining TCP state, preserving message ordering, applying flow-control mechanisms, and ensuring uninterrupted bidirectional exchange between the two endpoints. This example demonstrates how the system architecture (300) dynamically configures transport-layer endpoints and manages end-to-end communication without service downtime or manual intervention.

[0112] FIG. 4 illustrates an exemplary flow diagram of a method (400) for configuring the new source node (northbound endpoint) in the network (106), in accordance with an embodiment of the present disclosure.

[0113] At step (402), the TLB receives an API call (at least one request) from the external system to configure the new source node. The API call may be initiated using the API. The API call contains source node parameters that define the characteristics of the new source node (northbound node), such as the source IP, source port, transport type, application protocol, and L4 listening point. The TLB may be configured to configure the new source node based on these source node parameters.

[0114] At step (404), the TLB may be configured to set up a new L4 listening point (listening socket) for the newly configured source node. The new L4 listening point refers to the specific combination of a source IP address and a source port numberat which the newly configured source node listens for incoming connection requests. The L4 listening point manages the transport-level communication (e.g., TCP or UDP) for the source node. The TLB may listen for incoming data packets on the configured L4 listening point. The listening socket may be set to accept incoming connections based on the specified source IP and source port. The TLB validates that the source port is open and available to accept connections. It also ensures that the transport protocol (e.g., TCP or UDP) is supported and correctly configured. Once the L4 listening point is set up and validated, the TLB (304) updates a routing table to reflect the new source node and its listening point.

[0115] At step (406), the TLB (304) may be configured to receive at least one transport connection (incoming connection) from the newly configured source. In an example, the request may include connection-specific parameters such as the IP address of the source node, the intended destination, and the transport protocol under which the incoming transport connection is made. The TLB (304) is equipped with multiple listening endpoints, each associated with specific source nodes and traffic types. Upon receiving the transport connection at this endpoint, the TLB (304) verifies the source of the connection, ensuring it aligns with the designated source for this endpoint. This step ensures that incoming traffic is appropriately identified and directed to the TLB (304) for further processing. The TLB may be configured to identify the at least one source node (302), the at least one destination node (306), and the at least one transport protocol for each incoming transport connection. In this step, the TLB (304) examines the details associated with the received transport connection to distinguish the at least one source node (302), the type of traffic being sent, and the protocol in use. The at least one transport protocol may include Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), or the Stream Control Transmission Protocol (SCTP), and the type of application layer protocol could be Diameter, Mobile Application Part (MAP), or Remote Authentication Dial-In User Service (RADIUS). For example, if the incoming connection request is for Diameter traffic over TCP, theTLB (304) identifies this protocol combination and prepares to direct it to the appropriate destination node based on its protocol requirements.

[0116] At step (408), the TLB may be configured to initiate an outbound connection (outgoing connection) towards the dedicated destination node. By initiating the outbound connection, the TLB ensures seamless data transmission between the source node and the destination node. When a client sends traffic to the source node, the TLB may route the incoming data to the appropriate outbound destination node over the newly established connection. Once the connection is established, the TLB can reliably route traffic between the nodes, ensuring high throughput and low latency.

[0117] FIG. 5 illustrates an exemplary method (500) for configuring a new destination node (southbound node) in the network (106), in accordance with an embodiment of the present disclosure.

[0118] At step (502), the TLB receives an API call (at least one request) from the external system for configuring the new destination node. The API call may be initiated using the API. The API call contains destination node parameters that define the characteristics of the new destination node, such as destination IP, destination port, transport type and application interface. Based on these destination node parameters, the TLB may be configured to configure the new destination node.

[0119] At step (504), the TLB lists the newly configured destination node. In an aspect, a new southbound endpoint is listed at the TLB as soon as a new southbound endpoint is configured. The TLB updates the routing table by listing the newly configured destination node. The destination node may be a new service, server, or system connected to the network. The TLB maintains a list of active destination nodes and their corresponding configurations, enabling efficient routing decisions.

[0120] At step (506), the TLB receives a transport connection (incoming connection) from the already configured source node. The TLB listens for incomingtransport connections from the already configured source nodes. These source nodes are endpoints that have already been set up and listed within the network. The source node may be any system, device, or service that initiates communication by sending data to the destination node.

[0121] At step (508), the TLB initiates an outbound connection towards the newly configured destination. Once the TLB has received the incoming connection from an already configured source node (Step 506) and identified the appropriate destination node (Step 504), the TLB proceeds to initiate the outbound connection. This means that the TLB establishes a path or session towards the newly configured destination node (often a southbound node) to forward the incoming traffic.

[0122] The TLB is configured to create a logical construct that maintains both the incoming request and outbound connection as a single, cohesive unit. This logical construct, often referred to as a “connection pair,” includes critical identifiers such as the source IP, source port, destination IP, and destination port for both the incoming and outgoing connections. For example, if the source TCP connection is identified by a source IP and port, the TLB (304) maintains this information alongside the destination’s IP and port. This coupling allows the TLB (304) to handle the two connections as a unified entity, enabling efficient data forwarding without additional lookups. The logical construct provides a direct association between the source and destination connections, ensuring that data packets can be relayed from one connection to the other without delay.

[0123] The TLB (304) may be configured to route data packets between the at least one source node (302) and the at least one destination node (306) through the coupling. Once the logical connection pairing is established, the TLB (304) may seamlessly forward data packets from the at least one source node (302) to the at least one destination node (306) and vice versa.

[0124] FIG. 6 illustrates an exemplary flow diagram of a method (600) for managing the at least one transport layer connection between the source node and the destination node in the network ( 106), in accordance with an embodiment of the present disclosure.

[0125] At step (602), the receiving unit (202) receives the at least one request from the external system. The at least one request is for configuring at least one of a new source node and a new destination node. The external system may be, for example, a network management system (NMS), an operations support system (OSS), an orchestration platform, a provisioning server, an automation framework, or any other system capable of issuing configuration commands to the TLB (304). In some embodiments, the external system may operate autonomously based on predefined policies, traffic conditions, or scaling requirements, or it may operate under the supervision of a network administrator. The request may be delivered to the receiving unit (202) through an Application Programming Interface (API), a command-line interface (CLI), or any other communication interface supported by the system. The request may contain one or more parameters required to configure the new source node or the new destination node.

[0126] At step (604), the processing unit (208), in conjunction with the TLB, extracts the one or more parameters from the received request. The extracted one or more parameters include at least one source node parameter and at least one destination node parameter. For configuring the new source node, the at least one incoming request may include the at least one source node parameter, such as a source IP address, a source port number, a transport protocol, an application protocol, and an L4 listening point. For configuring the new destination node, the at least one incoming request may include the at least one destination node parameter, such as a destination IP address, a destination port number, a Transport Type, and an application interface.

[0127] At step (606), the processing unit (208) configures at least one of thenew source node and the new destination node based on the one or more extracted parameters. In an embodiment, the new source node is configured through an API based on the at least one source node parameter, and the new destination node is configured through the API based on the at least one destination node parameter of the one or more extracted parameters. Once the one or more extracted parameters are applied, the processing unit (208) integrates the new source node into the network topology. This typically means that the node is added to the routing table or service discovery systems, so other nodes can be aware of its existence and interact with it.

[0128] In an embodiment, to configure the new source node, the processing unit (208) is further configured to set up a new listening port for the new configured source node based on at least one transport protocol. The at least one transport protocol includes at least one of TCP, UDP, and SCTP. The processing unit (208) is further configured to receive an incoming connection request from the new configured source node at the new listening port, analyse the incoming connection request to determine whether a destination node requested in the received incoming connection request is the new configured destination node or an existing destination node, and based on the determination, establish an outgoing connection with the requested destination node.

[0129] In an embodiment, to configure the new destination node, the processing unit (208) is further configured to list the new configured destination node corresponding to the new configured source node in a database. In such an embodiment, the processing unit (208) lists or registers the new destination node corresponding to the newly configured northbound node. The listing is crucial for establishing effective communication paths between nodes, ensuring that the transport connection is properly formed between the source node and the destination node.

[0130] At step (608), the processing unit (208) further establishes a transport layer connection between the new configured source node and the new configured destination node. In an embodiment, establishing the transport layer connection mayinclude initiating an outgoing connection toward the destination node based on the transport protocol associated with the request. For example, the processing unit (208) may perform protocol-specific procedures, such as a TCP three-way handshake when the connection is TCP-based, initiating a UDP exchange when the connection is UDP- based, or forming an SCTP association when the request specifies SCTP. The processing unit (208) may further create a logical mapping or coupling between the inbound connection received from the source node and the outbound connection initiated toward the destination node. This coupling enables the system (108) to maintain all relevant parameters, such as IP addresses, port numbers, protocol identifiers, and session metadata, allowing traffic to be forwarded efficiently between the two endpoints throughout the entire session.

[0131] At step (610), the processing unit (208), in conjunction with the TLB, manages the data flow between the new configured source node and the new configured destination node over the established transport layer connection. The TLB may serve as a gateway, router, or service mesh that manages network traffic and connections. Managing the data flow may include forwarding data packets received from the source node to the destination node and vice versa, maintaining session state information, and ensuring that packets belonging to a particular session are routed through the corresponding connection pair. This step ensures that the data flow between these nodes is established, maintained, and optimized for reliability, security, and performance.

[0132] In an operative aspect, once an incoming connection is established on the TLB from the newly configured northbound endpoint (node), its corresponding outgoing connection may be formed with a configured southbound endpoint.

[0133] Also, if an incoming connection from an already configured northbound endpoint arrives, its corresponding outgoing connection may be formed with a newly configured southbound endpoint.

[0134] In an aspect, the configuration of new northbound and southbound endpoints is fully API-driven, enabling seamless integration and setup through automated processes. This approach eliminates the need for manual intervention during endpoint configuration, allowing for greater flexibility, scalability, and efficiency in the network. Once a new northbound endpoint (source node) and a new southbound endpoint (destination node) are configured, the system automatically establishes a dedicated transport layer path between them. This transport path is created based on the parameters provided through the API, such as IP addresses, ports, transport protocols, and application interfaces, ensuring that communication between the two endpoints is routed correctly. The automation of this process ensures that the transport connection is formed without human oversight, reducing the likelihood of errors, increasing operational efficiency, and allowing the network to adapt quickly to changing requirements or new configurations. This API-driven approach not only simplifies the configuration process but also enhances the ability to scale and modify the network architecture dynamically.

[0135] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be implemented.

[0136] As shown in FIG. 7, the computer system (700) may include an external storage device (710), a bus (720), a main memory (730), a read-only memory (740), a mass storage device (750), a communication port (760), and a processor (770). A person skilled in the art will appreciate that the computer system (700) may include more than one processor (770) and communication ports (760). The processor (770) may include various modules associated with embodiments of the present disclosure.

[0137] In an embodiment, the communication port (760) 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 (760) may be chosen depending onthe network (106), such as a Local Area Network (LAN), a Wide Area Network (WAN), or any network to which the computer system (700) connects.

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

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

[0140] In an embodiment, the bus (720) communicatively couples the processor(s) (770) with the other memory, storage, and communication blocks. The bus (720) may be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCLX) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (770) to the computer system (700).

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

[0142] The present disclosure offers significant technical enhancements in enabling dynamic, scalable, and efficient management of transport-layer (L4) connections between northbound and southbound nodes within modem IP-based, cloud-native, and service-oriented network environments. Existing systems typically require manual configuration, service downtime, or static routing rules to introduce new endpoints, making it difficult to scale services, onboard new applications, or modify network paths without operational disruption. The present disclosure addresses these limitations by introducing a TLB equipped with standardized APIs that enable the real-time configuration of new source nodes and destination nodes without interrupting ongoing traffic flows. By enabling the TLB to extract source node and destination node parameters, such as IP addresses, port numbers, transport protocol types, and application-layer attributes, directly from API-driven requests, the system supports the seamless creation, activation, and mapping of newly configured endpoints. A key technical enhancement lies in the ability of the TLB to automatically establish corresponding outgoing connections when an incoming connection is received from either a newly configured or an existing northbound node, ensuring protocol- appropriate routing over TCP, UDP, or SCTP. The logical coupling of inbound and outbound connections within the TLB further enables low-latency, two-way data flow management without repeated lookups or manual configuration. By providing this dynamic and automated connection lifecycle management framework, the disclosure enhances routing precision, reduces operational overhead, eliminates downtime associated with endpoint provisioning, and enables rapid scaling of application workloads and backend services across distributed network architectures.

[0143] While the foregoing describes various embodiments of the invention,other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.ADVANTAGES OF THE PRESENT DISCLOSURE

[0144] The present disclosure, as described above, offers several significant technical advantages that enhance the functionality and efficiency of the network, including, but not limited to:• streamlines the process of establishing and managing transport connections by eliminating the need for complex mapping structures and lookup operations, leading to reduced latency and improved network performance;• enables a Transport Load Balancer (TLB) to handle a large number of concurrent connections without compromising performance, making the system scalable to accommodate growing network traffic;• provide zero downtime while exposing a new listening point for a newly configured northbound endpoint;• offering zero downtime while configuring a new southbound endpoint, and the new southbound endpoint may directly be associated with a configured northbound endpoint as soon as a new incoming transport connection arrives; and• provides a centralized point of control for managing network connections and traffic flows, therefore simplifying network management and reducing operational overhead.

Claims

CLAIMS1. A method (600) for managing at least one transport layer connection between a source node (302) and a destination node (306) in a network (106), the method (600) comprising: receiving (602), by a receiving unit (202), at least one request from an external system for configuring at least one of a new source node and a new destination node; extracting (604), by a processing unit (208), one or more parameters from the received at least one request, wherein the one or more extracted parameters comprise at least one source node parameter and at least one destination node parameter; configuring (606), by the processing unit (208), at least one of the new source node and the new destination node based on the one or more extracted parameters; establishing (608), by the processing unit (208), a transport layer connection between the new configured source node and the new configured destination node; and managing (610), by the processing unit (208), data flow between the new configured source node and the new configured destination node over the established transport layer connection.

2. The method (600) as claimed in claim 1, wherein configuring the new source node further comprises: setting up, by the processing unit (208), a new listening port for the new configured source node based on at least one transport protocol.

3. The method (600) as claimed in claim 2, wherein the at least one transport protocol comprises at least one of a Transmission Control Protocol (TCP), a User Datagram Protocol (UDP), and a Stream Control Transmission Protocol (SCTP).

4. The method (600) as claimed in claim 2, further comprising:receiving, by the processing unit (208), an incoming connection request from the new configured source node at the new listening port; analysing, by the processing unit (208), the incoming connection request to determine whether a destination node requested in the received incoming connection request is the new configured destination node or an existing destination node; and based on the determination, establishing, by the processing unit (208), an outgoing connection with the requested destination node.

5. The method (600) as claimed in claim 1, wherein configuring the new destination node further comprises: listing, by the processing unit (208), the new configured destination node corresponding to the new configured source node in a database (210).

6. The method (600) as claimed in claim 1, wherein the source node is a northbound node.

7. The method (600) as claimed in claim 1, wherein the destination node is a southbound node.

8. The method (600) as claimed in claim 1, further comprising: configuring, by the processing unit (208), the new source node through an Application Programming Interface (API) based on the at least one source node parameter; and configuring, by the processing unit (208), the new destination node through the API based on the at least one destination node parameter of the one or more extracted parameters.

9. The method (600) as claimed in claim 1, wherein the at least one source node parameter comprises at least one of a source node Internet Protocol (IP) address, a source node port number, a transport protocol type, an application protocol, and a transport layer listening point.

10. The method (600) as claimed in claim 1, wherein the at least one destination node parameter comprises a destination node Internet Protocol (IP) address, a destination node port number, a transport protocol type, and an application interface.

11. A system (108) for managing at least one transport layer connection between a source node (302) and a destination node (306) in a network (106), the system (108) comprising: a receiving unit (202) configured to receive at least one request from an external system for configuring at least one of a new source node and a new destination node; a memory (204) configured to store the at least one received request; and a processing unit (208) coupled to the memory (204), wherein the processing unit (208) is configured to receive the at least one request from the memory and execute instructions stored in the memory to: extract one or more parameters from the received at least one request, wherein the one or more extracted parameters comprise at least one source node parameter and at least one destination node parameter; configure at least one of the new source node and the new destination node based on the one or more extracted parameters; establish a transport layer connection between the new configured source node and the new configured destination node; and manage data flow between the new configured source node and the new configured destination node over the established transport layer connection.

12. The system (108) as claimed in claim 11, wherein to configure the new source node, the processing unit (208) is further configured to: set up a new listening port for the new configured source node based on at least one transport protocol.

13. The system (108) as claimed in claim 12, wherein the at least one transport protocol comprises at least one of a Transmission Control Protocol (TCP), a User Datagram Protocol (UDP), and a Stream Control Transmission Protocol (SCTP).

14. The system (108) as claimed in claim 12, wherein the processing unit (208) is further configured to: receive an incoming connection request from the new configured source node at the new listening port; analyse the incoming connection request to determine whether a destination node requested in the received incoming connection request is the new configured destination node or an existing destination node; and based on the determination, establish an outgoing connection with the requested destination node.

15. The system (108) as claimed in claim 11 , wherein to configure the new destination node, the processing unit (208) is further configured to: list the new configured destination node corresponding to the new configured source node in a database (210).

16. The system (108) as claimed in claim 11, wherein the source node is a northbound node, and the destination node is a southbound node.

17. The system (108) as claimed in claim 11, wherein the new source node is configured through an Application Programming Interface (API) based on the at least one source node parameter, and wherein the new destination node is configured through the API based on the at least one destination node parameter of the one or more extracted parameters.

18. The system (108) as claimed in claim 11, wherein the at least one source node parameter comprises at least one of a source node Internet Protocol (IP) address, a source node port number, a transport protocol type, an application protocol, and a transport layer listening point, and wherein the at least one destination node parameter comprises a destination node IP address, a destination node port number, a transport protocol type, and an application interface.

19. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method (600) for managing at least one transport layer connection between a source node (302) and a destination node (306) in a network (106), the method (600) comprising: receiving, by a receiving unit (202), at least one request from an external system for configuring at least one of a new source node and a new destination node; extracting, by a processing unit (208), one or more parameters from the received at least one request, wherein the one or more extracted parameters comprise at least one source node parameter and at least one destination node parameter; configuring, by the processing unit (208), at least one of the new source node and the new destination node based on the one or more extracted parameters; establishing a transport layer connection between the new configured source node and the new configured destination node; andmanaging data flow between the new configured source node and the new configured destination node over the established transport layer connection.

Images