WO2025008981A1

WO2025008981A1 - Method and system of handling traffic request in a network

Info

Publication number: WO2025008981A1
Application number: PCT/IN2024/051000
Authority: WO
Inventors: Aayush Bhatnagar; Adityakar Jha; Anu Ranjan; Pankaj Malhotra; Swarup Sengupta; Ranjan Mamgain; Yog VASHISHTH
Original assignee: Jio Platforms Ltd
Current assignee: Jio Platforms Ltd
Priority date: 2023-07-05
Filing date: 2024-06-29
Publication date: 2025-01-09
Anticipated expiration: 2026-01-05

Abstract

The present disclosure relates to a system (108) and a method (400) of handling traffic request in a network (106). The system (108) includes a transceiver (210) to receive a traffic request including at least one data packet along with an Internet Protocol (IP) address from the network (106). Further, the system (108) includes a mapping module (214) to map the IP address from the received traffic request against a plurality of IP addresses stored in a database (208). Further, the system (108) includes a determination module (218) to determine an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit (310). Further, the system (108) includes a policy module (220) to handle the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request.

Description

METHOD AND SYSTEM OF HANDLING TRAFFIC REQUEST IN A

NETWORK

FIELD OF THE INVENTION

[0001] The present invention relates to the field of wireless communication networks and, more particularly, relates to a method and system of handling traffic request in the networks.

BACKGROUND OF THE INVENTION

[0002] In modern telecommunication networks, the User Plane Function (UPF) plays a crucial role in packet processing and traffic management. The UPF is a key component of the Core Network defined by the 3rd Generation Partnership Project (3GPP). The 3GPP is an international standards organization responsible for developing specifications for mobile communication systems. These specifications define the architecture, protocols, and functionalities of the mobile network infrastructure.

[0003] The UPF is responsible for processing user traffic in the Core Network based on signaling received over the N4 interface. The N4 interface facilitates communication between the UPF and other network elements, such as the Access Network (AN) and the Session Management Function (SMF). The UPF performs various functions, including traffic classification, forwarding, quality of service enforcement, and usage reporting.

[0004] To ensure proper handling of user traffic, the UPF employs traffic classification mechanisms. These mechanisms involve analyzing packet information at different layers of the network protocol stack. The protocol stack consists of multiple layers, each responsible for specific functions in data transmission. [0005] At the lower layers, such as Layer 3 (L3) and Layer 4 (L4), the UPF examines traffic flow information, including IP addresses, port numbers, and protocols. This information allows the UPF to differentiate between different types of traffic, such as voice calls, video streaming, or web browsing. The UPF can then apply appropriate forwarding actions and quality of service policies based on this classification.

[0006] Additionally, the UPF considers higher-layer characteristics for more granular traffic classification. These characteristics relate to the Layer 7 (L7) application layer, which represents the highest layer in the protocol stack and deals with application-specific data. Examples of L7 characteristics include URLs, domain names, or application-specific attributes.

[0007] To extract L7 characteristics, the UPF may employ deep packet inspection (DPI) techniques. DPI involves examining the content of packet payloads to identify specific application protocols or extract relevant information, such as URLs or domain names. This enables the UPF to gain deeper insights into the nature of user traffic and apply more specific processing rules.

[0008] Accurate traffic classification is crucial for implementing various policies and rules in the UPF. These include Forwarding Action rules, which determine how packets are routed or processed, Quality of Service (QoS) enforcement rules, which ensure that different types of traffic receive the appropriate level of service, and usage reporting rules, which track and monitor network resource utilization.

[0009] To prioritize traffic classification rules, the UPF assigns different levels of priority based on their selectivity. More specific rules, such as those defined by Application Detection Function (ADF) identifiers, have higher priority compared to more general rules. This prioritization ensures that the UPF applies the most appropriate processing rules and actions to each packet based on the specific application or service it belongs to. [0010] However, traditional methods of application detection, particularly at the L7 layer, have limitations. Performing DPI on each packet to extract L7 characteristics and match them against an application identification database can be computationally intensive and resource-consuming. This becomes a significant challenge, especially in high-traffic scenarios where UPF nodes need to handle a large volume of packets.

[0011] Therefore, there is a need for an optimization technique that improves the efficiency and performance of the Application Detection Function in the UPF. By leveraging IP matching at the L3 layer, the UPF can selectively process packets based on the IP address of the server hosting the application. This approach eliminates the need for costly DPI operations on all packets, leading to significant CPU savings and improved UPF performance.

SUMMARY OF THE INVENTION

[0012] One or more embodiments of the present disclosure provide a method and system of handling traffic request in a network.

[0013] In one aspect of the present invention, a system of handling traffic request in a network is disclosed. The system includes a transceiver configured to receive a traffic request from the network. The traffic request includes at least one data packet along with an Internet Protocol (IP) address. Further, the system includes a mapping module configured to map the IP address from the received traffic request against a plurality of IP addresses stored in a database. Further, the system includes a determination module configured to determine an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit. The application identifier pertains to a content of the least one data packet to identify at least one of an application or a service associated with the received traffic request. Further, the system includes a policy module configured to handle the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request. [0014] In an embodiment, the received traffic request is at least an uplink and a downlink traffic request. In an embodiment, the uplink traffic request includes the at least one data packet with a destination IP address and the downlink traffic request includes the at least one data packet with a source IP address.

[0015] In an embodiment, on receipt of the traffic request from the network, an identification module is configured to identify a traffic type of the received traffic request determined by applying a set of traffic identification and classification rules based on a predefined priority. In an embodiment, the application identifier enables the identification module to identify at least one of the application and service associated with the received traffic request.

[0016] In an embodiment, at least one of the application and service is preregistered in the network via a Domain Name System (DNS). In an embodiment, on determination of the application identifier, the mapping module is configured to perform mapping of the application ID to attributes associated with the plurality of applications and services including at least one IP address, domain name, and Uniform Resource Locator (URL). Further, the mapping aids the identification module to identify and classify the received traffic request.

[0017] In an embodiment, the mapping is performed at a network layer of the traffic request. In an embodiment, a building module of the system builds the database which stores the plurality of IP addresses by transmitting one or more Domain Name System (DNS) queries for each of the application domains extracted from Uniform Resource Locators (URLs), the URLs configured for the respective applications.

[0018] In another aspect of the present invention, a method of handling traffic request in a network is disclosed. The method includes the step of receiving a traffic request from the network, the traffic request includes at least one data packet along with an Internet Protocol (IP) address. The method further includes the step of mapping the IP address from the received traffic request against a plurality of IP addresses stored in a database. The method further includes the step of determining an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit. Further, the application identifier pertains to a content of the least one data packet to identify at least one of an application or a service associated with the received traffic request. The method further includes the step of handling the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request.

[0019] In another aspect of the invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The computer-readable instructions are executed by a processor. The processor is configured to receive a traffic request from the network, the traffic request includes at least one data packet with an Internet Protocol (IP) address. The processor is further configured to map the IP address from the received traffic request against a plurality of IP addresses stored in a database. The processor is further configured to determine an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit. The application identifier pertains to a content of the least one data packet to identify at least one of an application or a service associated with the received traffic request. The processor is further configured to handle the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request.

[0020] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all- inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] FIG. 1 is an exemplary block diagram of an environment for handling traffic request in a network, according to one or more embodiments of the present invention;

[0023] FIG. 2 is an exemplary block diagram of the system of handling traffic request in a network, according to one or more embodiments of the present invention;

[0024] FIG. 3 is an exemplary flow diagram of the system of FIG. 2 of handling traffic request in a network, according to one or more embodiments of the present invention; and

[0025] FIG. 4 is a schematic representation of a method of handling traffic request in a network, according to one or more embodiments of the present invention.

[0026] The foregoing shall be more apparent from the following detailed description of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0027] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.

[0028] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.

[0029] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.

[0030] As per various embodiments depicted, the present invention discloses the system and method of handling traffic request in a network.

[0031] FIG. 1 illustrates an exemplary block diagram of an environment 100 for handling traffic request in a network 106, according to one or more embodiments of the present disclosure. In this regard, the environment 100 includes a User Equipment (UE) 102, a server 104, the network 106 and a system 108 communicably coupled to each other for handling traffic request in the network 106. [0032] As per the illustrated embodiment and for the purpose of description and illustration, the UE 102 includes, but not limited to, a first UE 102a, a second UE 102b, and a third UE 102c, and should nowhere be construed as limiting the scope of the present disclosure. Accordingly, in alternate embodiments, the UE 102 may include a plurality of UEs as per the requirement. For ease of reference, each of the first UE 102a, the second UE 102b, and the third UE 102c, will hereinafter be collectively and individually referred to as the “User Equipment (UE) 102”.

[0033] In an embodiment, the UE 102 is not limited to, any electrical, electronic, electro-mechanical or an equipment and 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.

[0034] The environment 100 includes the server 104 accessible via the network 106. The server 104 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defense facility side, or any other facility that provides service.

[0035] The network 106 includes, 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. The network 106 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.

[0036] The network 106 may also 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, a V OIP or some combination thereof.

[0037] The environment 100 further includes the system 108 communicably coupled to the server 104 and the UE 102 via the network 106. The system 108 is configured to handle the traffic request in the network 106. As per one or more embodiments, the system 108 is adapted to be embedded within the server 104 or embedded as an individual entity. However, for the purpose of description, the system 108 is described as an integral part of the server 104, without deviating from the scope of the present disclosure.

[0038] Operational and construction features of the system 108 will be explained in detail with respect to the following figures.

[0039] FIG. 2 is an exemplary block diagram of the system 108 of handling the traffic request in the network 106, according to one or more embodiments of the present invention.

[0040] As per the illustrated embodiment, the system 108 includes one or more processors 202, a memory 204, a user interface 206, and a database 208. For the purpose of description and explanation, the description will be explained with respect to one processor 202 and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the system 108 may include more than one processors 202 as per the requirement of the network 106. The one or more processors 202, hereinafter referred to as the processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.

[0041] As per the illustrated embodiment, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204. 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 RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.

[0042] In an embodiment, the user interface 206 includes a variety of interfaces, for example, interfaces for a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The user interface 206 facilitates communication of the system 108. In one embodiment, the user interface 206 provides a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, the UE 102 and the database 208.

[0043] The database 208 is one of, but not limited to, a centralized database, a cloudbased database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 208 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open- source, etc.

[0044] In order for the system 108 to handle the traffic request in the network 106, the processor 202 includes one or more modules. In one embodiment, the one or more modules includes, but not limited to, a transceiver 210, an identification module 212, a mapping module 214, a building module 216, a determination module 218, and a policy module 220 communicably coupled to each other to handle traffic request in the network 106.

[0045] In one embodiment, the transceiver 210 of the system 108 receives the traffic request from the network 106. The traffic request typically refers to a request made by the UE 102 or application on the network 106 to transmit data to another UE 102 or application. This request could be for various purposes such as accessing a website, downloading a file, sending an email, or any other communication over the network 106. The traffic request includes, but is not limited to, Hyper Text Transfer Protocol (HTTP) request, email request, file transfer request, and Domain Name System (DNS) request. Further, the traffic request includes at least one data packet along with an Internet Protocol (IP) address. The at least one data packet is a fundamental unit of data transmission. It's a formatted unit of data that travels across the network 106 from one UE 102 to another. The Internet Protocol (IP) address is the unique identifying number assigned to every UE 102 connected to the network 106t.

[0046] On receipt of the traffic request received from the network 106, an identification module 212 identifies a traffic type of the received traffic request. The traffic type of the received traffic request is determined by applying a set of traffic identification and classification rules based on a predefined priority. The set of traffic identification and classification rules includes, but not limited to, Quality of Service (QoS) classification, protocol-based classification, port-based classification, IP address-based classification, user-based classification, time -based classification and so on. The set of traffic identification and classification rules has an associated priority. On the basis of associated priority, the incoming traffic is matched against the classification rules. For example, if 2 traffic classification rules are configured having same classifier which is “port is 53” but different priority then traffic with “port 53” will be matched with rule having higher priority.

[0047] In an embodiment, the traffic type of the received traffic request is at least one of an uplink and a downlink traffic request. The uplink traffic request is the traffic request transmitted from an internal network to an external network. The internal network includes, but is not limited to, local area networks (LANs). The external network includes, but is not limited to, Wide Area Networks (WANs), routers, or hubs. In an embodiment, the uplink traffic request includes the at least one data packet with a destination IP address and the downlink traffic request includes the at least one data packet with a source IP address.

[0048] Upon receiving the traffic request from the network 106 and identifying the traffic type of the received traffic request, the mapping module 214 maps the IP address of the received traffic request. The mapping of the IP address of the received traffic request is against a plurality of IP addresses which are stored in the database 208. In this regard, a building module 216 of the processor 202 is configured to build the database 208 which stores the plurality of IP addresses. More specifically, the database 208 is built by transmitting one or more Domain Name System (DNS) queries for each of the application domains extracted from Uniform Resource Locators (URLs). The URLs are configured for each of the respective applications. The DNS is a naming database in which internet domain names are located and translated into IP addresses . The URL is a unique identifier used to locate a resource on the internet. [0049] Upon mapping the IP address of the received traffic request, the determination module 218 determines an application identifier of the mapped IP address utilizing a Deep Packet Inspection (DPI) unit 310(as shown in FIG. 3). The application identifier pertains to information used to identify a specific application or service running on the network 106.

[0050] In an embodiment, the application identifier pertains to the content of the at least one data packet to identify at least one of the application or the service associated with the received traffic request. The application identifier enables the identification module 212 to identify at least one of the application and the service associated with the received traffic request. Further, at least one of the applications and service is preregistered in the network 106 via Domain Name System (DNS).

[0051] Upon determining the application identifier, the mapping module 214 is further configured to perform mapping of the application ID to attributes associated with the plurality of applications and services. The attributes associated with the plurality of applications and services includes at least one of IP address, domain name, and Uniform Resource Locator (URL). Further, mapping of the application ID to attributes associated with the plurality of applications and services aids the identification module 212 to identify and classify the received traffic request. The mapping is performed at a network layer of the traffic request. The network layer is the third layer of the Open Systems Interconnection (OSI) model. The network layer handles the routing and sending of data between different networks 106.

[0052] Upon identification and classification of the received traffic request, the policy module 220 is configured to handles the received traffic request. The received traffic request is handled by implementing a set of rules or policies based on the determined application identifier corresponding to the received traffic request. In one embodiment, policies are enforced for differential handling of packets in each PDU session. These policies are enforced by SMF over N4 interface or pre -configured at the UPF, for example, Packet detection rules along with action like QoS like rate, charging, forwarding are provided to UPF by SMF. [0053] FIG. 3 is an exemplary block diagram of an architecture 300 of the system 108 of handling traffic request in the network 106, according to one or more embodiments of the present invention.

[0054] According to the exemplary embodiment, the system 108 may include, but may not be limited to, a User Plane Function (UPF) 302, Radio Access Network (RAN) 304 communicatively coupled to the UPF 302, a Data Network 306 communicatively coupled to the UPF 302, and an Application Detection Function (ADF) 308 communicatively coupled to the UPF 302.

[0055] The UPF 302 is a key component of a 5G core network responsible for handling user plane traffic. Further, the UPF 302 is responsible for the routing and forwarding of user data packets in the user plane. It performs tasks such as packet inspection, forwarding, and applying quality of service (QoS) policies.

[0056] In one embodiment, the UPF 302 is configured for the packet processing and traffic management of user traffic flowing through the network 106. It ensures efficient handling of user data based on the signaling received over a communication interface. In one embodiment, the communication interface is a N4 interface. The UPF 302 operates on the principles outlined in 3rd Generation Partnership Project (3GPP) standards and is responsible for various functions related to traffic classification, forwarding actions, quality of service enforcement, and usage reporting. These functions are vital for maintaining network performance, security, and overall user experience.

[0057] The N4 is an interface with a Session Management Function/Packet data network Gateway- Control plane function (SMF/PGW-C) for policy enforcement in the UPF 302. Further, features of the UPF 302 can be controlled by the SMF over N4 interface either at the beginning of session establishment or during the lifetime of session through modification requests. [0058] The term “3GPP” is a 3rd Generation Partnership Project or 3GPP and is a collaborative project between a group of telecommunications associations with the initial goal of developing globally applicable specifications for Third Generation (3G) mobile systems. 3GPP specifications cover cellular telecommunications technologies, including radio access, core network, and service capabilities, which provide a complete system description for mobile telecommunications. The 3GPP specifications also provide hooks for non-radio access to the core network, and for networking with non-3GPP networks.

[0059] In the context of the UPF 302, after the packet processing and traffic management of user traffic flowing through the network 106, the identification module 212 is configured to identify a traffic type of the received traffic request. The traffic type of the received traffic request is determined by applying a set of traffic identification and classification rules based on a predefined priority. The traffic classification refers to the process of analyzing and categorizing user traffic based on specific criteria. This classification is performed at different layers of the network protocol stack, including Layer 3/Layer 4 (L3/L4) traffic flow information and higher- layer characteristics up to Layer 7 (L7), which represents the application layer. The Layer 3 of the network protocol stack is the network layer which works for the transmission of data from one host to the other located in different networks 106. The Layer 4 of the network protocol stack is the transport layer which provides services to the application layer (Layer 7) and takes services from the network layer (Layer 3). The Layer 7 of the network protocol stack is the application layer which is implemented by the network applications. These applications produce the data, which has to be transferred over the network 106. By examining these characteristics, the UPF 302 can gain insights into the nature of the traffic and make informed decisions about how to handle it.

[0060] The traffic classification information provided to the UPF 302 includes various elements. For L3/L4 traffic flow information, the UPF 302 receives Service Data Flow (SDF) filters or five-tuple information including source IP address, destination IP address, source port number, destination port number, and protocols (such as UDP, TCP, etc.) associated with the traffic. More specifically, the UPF 302 supports detection of individual flows based on service data information that comprises of source IP address, source port, destination IP address, destination Port and application. This feature helps in identifying individual service data flows and defining differential treatment if required. Additionally, the UPF 302 can utilize application IDs, , which can map to IP addresses, domains, or URLs accessed by users. These application IDs provide a more granular level of classification and allow for precise handling of different applications or services. The application ID is sent along with each rule by the SMF, and their definitions are configured statically at the UPF 302. When the application ID is determined, the application ID is used to apply the corresponding rule to the data packet.

[0061] In one implementation, the UPF 302 is communicatively coupled to the RAN 304 over N3 interface and User traffic transferred from gNodeB/eNodeB to the UPF 302 and vice a versa. The UPF 302 is communicatively coupled to the data network (DN) 306 over N6 interface and User traffic are sent to/received from DN 306. Further, the RAN 304 and the DN 306 are communicatively coupled with the UPF 302 via uplink and downlink network signaling. The UPF 302 receives an application service request from the RAN 304 and caters the request by communicating with the data network 306.

[0062] In one implementation of the embodiment, the ADF 308 is a part of the UPF 302 and configured for identifying and classifying user traffic based on specific application-related criteria, such as application IDs, IP addresses, domains, or URLs accessed by users. By leveraging the ADF 308, the UPF 302 is configured to gain insights into the nature of the traffic at a granular level and apply appropriate processing rules or policies. [0063] In one implementation, the ADF 308 may include, but may not be limited to, the database 208, the Deep Packet Inspection (DPI) unit 310, and a packet processing logic 312.

[0064] The ADF 308 is designed to enable accurate traffic classification by associating traffic flows with specific applications or services. This allows for differentiated treatment of different types of traffic, ensuring that the appropriate quality of service (QoS) enforcement rules, forwarding action rules, and usage reporting policies are applied.

[0065] In the context of the UPF 302, the ADF 308 receives application-related information in the form of application IDs. These application IDs serve as unique identifiers for different applications or services in the network 106. The ADF 308 can map these application IDs to various attributes associated with the applications, such as IP addresses, domains, or URLs. This mapping enables the UPF 302 to identify and classify user traffic based on the specific applications being accessed.

[0066] The ADF 308 operates by applying traffic detection and classification rules associated with the received application IDs. These rules are prioritized based on their selectivity, where more specific rules have higher priority compared to more general rules. The prioritization ensures that traffic matching both higher and lower priority rules is handled according to the higher priority rule and its associated processing rules.

[0067] In one implementation, the database 208 of the ADF 308 is configured as a repository of IP address mappings associated with specific applications or services accessed by users. The purpose of the database 208 is to provide a quick and efficient lookup mechanism for validating the destination IP addresses of user traffic in order to determine if the application detection is required. It helps optimize the processing of user traffic by bypassing computationally intensive operations, such as the deep packet inspection (DPI) 310, for traffic that is unlikely to match any ADF-related rules.

Y1 [0068] The database 208 is built and maintained by collecting and updating IP address mappings for relevant applications for which validation is required. These mappings are obtained through a series of operations performed by the UPF 302. Specifically, the UPF 302 sends Domain Name System (DNS) queries for each application domain extracted from the URLs configured for the application. The responses to these DNS queries provide the IP addresses associated with the respective applications.

[0069] The collected IP address mappings are then stored in the database 208 for subsequent reference during the destination IP address validation process. When user traffic arrives at the UPF 302, the traffic is directed to the ADF 308, where the destination IP address of the traffic is compared against the IP addresses stored in the database 208.

[0070] If the destination IP address matches any of the IP addresses in the database 208, it indicates that the user traffic is destined for an application that requires further application detection. In such cases, the traffic is forwarded to the subsequent stage, which may involve the DPI 310 and packet processing logic 312 for URL extraction and matching against the Application Identification Database. The DPI 310 process is responsible for analyzing the content of each packet to identify the applications or services associated with the user traffic. This information is used for traffic classification and applying the appropriate forwarding actions, quality of service (QoS) enforcement rules, and other policies in the UPF 302. Further, the packet processing logic 312 within the ADF 308 performs rule-based matching and processing of user packets. It applies traffic classification rules based on the received signaling information, including SDF filters, five-tuple information (IP address, port, protocol), and application IDs.

[0071] On the other hand, if the destination IP address does not match any IP addresses in the database, it suggests that the user traffic is unlikely to be associated with any application that requires ADF-related processing. This allows for bypassing the computationally intensive DPI 310 process, and the packet is transmitted to the packet processing logic 312 for further processing which leads to improved performance and resource utilization in the UPF 302.

[0072] For instance, the packets with destination IP addresses such as a.b.c.d, e.f.g.h, m.n.o.p, q.r.s.t are stored in the database 208. When user traffic with the data packet of destination IP address a.b.c.d arrives at the UPF 302, the traffic is directed to the ADF 308, where the destination IP address of the traffic is compared against the IP addresses stored in the database 208. If the destination IP address a.b.c.d matches with the IP addresses in the database 208, it indicates that the user traffic is destined for an application that requires further application detection. In such cases, the traffic is forwarded to the subsequent stage, which may involve the DPI 310 and packet processing logic 312 for URL extraction and matching against the Application Identification Database.

[0073] Alternatively, if the packet with destination IP address w.x.y.z arrives at the UPF 302, the traffic is directed to the ADF 308, where the destination IP address of the traffic is compared against the IP addresses stored in the database 208. The destination IP address w.x.y.z does not match with any IP addresses in the database 208. Therefore, the DPI 310 process is bypassed and the packet with destination IP address w.w.y.z is transmitted to the packet processing logic 312 for further processing which leads to improved performance and resource utilization in the UPF 302.

[0074] Uplink Traffic Processing: The UPF 302 receives uplink user traffic from the Radio Access Network (RAN) 304 over the network interface. The ADF 308 within the UPF 302 validates the destination IP address of the user traffic against the IP addresses stored in the database 208. If the destination IP address matches any of the configured application IP addresses, the packet is directed to undergo deep packet inspection (DPI) using the DPI unit 310 for further processing. If the destination IP address does not match any configured application IP addresses, the packet is identified as not matching the ADF 308 rules and is processed further based on other applicable rules.

[0075] Downlink Traffic Processing: The UPF 302 receives downlink user traffic from the data network 306 and performs the necessary traffic classification and forwarding actions based on the established rules. The ADF 308 within the UPF 302 can also be involved in downlink traffic processing, where traffic may be classified based on the source IP address, port number, protocol, or other criteria.

[0076] FIG. 4 is a flow diagram of a method 400 of handling traffic request in the network 106, according to one or more embodiments of the present invention. For the purpose of description, the method is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.

[0077] At step 402, the method 400 includes the step of receiving the traffic request from the network 106. The traffic request includes at least one data packet along with an Internet Protocol (IP) address. In one embodiment, the transceiver 210 is configured to receive the traffic request from the network 106, the traffic request includes at least one data packet along with an Internet Protocol (IP) address.

[0078] On receipt of the traffic request from the network 106, an identification module 212 identifies a traffic type of the received traffic request. The traffic type of the received traffic request is determined by applying a set of traffic identification and classification rules based on a predefined priority. In an embodiment, the traffic type of the received traffic request is at least one of an uplink and a downlink traffic request. In an embodiment, the uplink traffic request includes the at least one data packet with a destination IP address and the downlink traffic request includes the at least one data packet with a source IP address.

[0079] At step 404, the method 400 includes the step of mapping the IP address by mapping module 212 from the received traffic request against the plurality of IP addresses stored in the database 208. In this regard, a building module 216 of the processor 202 is configured to build the database 208 which stores the plurality of IP addresses. More specifically, the database 208 is built by transmitting one or more Domain Name System (DNS) queries for each of the application domains extracted from Uniform Resource Locators (URLs), the URLs configured for the respective applications.

[0080] At 406, the method 400 includes the step of determining the application identifier for the mapped IP address by the determination module 218 utilizing the Deep Packet Inspection (DPI) unit 310. The application identifier pertains to the content of the least one data packet to identify at least one of the application or the service associated with the received traffic request. To identify at least one of the application or the service associated with the received traffic request, the application identifier enables the identification module 212. Further, at least one of the applications and service is preregistered in the network 106 via Domain Name System (DNS).

[0081] Upon determining the application identifier, the mapping module 214 is configured to perform mapping of the application ID to attributes associated with the plurality of applications and services. The attributes associated with the plurality of applications and services includes at least one IP address, domain name, and Uniform Resource Locator (URL). Further, mapping aids the identification module 212 to identify and classify the received traffic request. The mapping is performed at the network layer of the traffic request.

[0082] At 408, the method 400 includes the step of handling the received traffic request by the policy module 220. The received request is handled by implementation of the set of rules or policies based on the determined application identifier corresponding to the received traffic request. [0083] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer- readable instructions are executed by the processor 202. The processor 202 is configured to receive the traffic request from the network, the traffic request includes at least one data packet with the Internet Protocol (IP) address. The processor 202 is further configured to map the IP address from the received traffic request against the plurality of IP addresses stored in the database 208. The processor 202 is further configured to determine the application identifier for the mapped IP address utilizing the Deep Packet Inspection (DPI) unit 310, wherein the application identifier pertains to the content of the least one data packet to identify at least one of the application or the service associated with the received traffic request. The processor 202 is further configured to handle the received traffic request by implementation of the set of rules or policies based on the determined application identifier corresponding to the received traffic request.

[0084] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-4) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.

[0085] The present disclosure incorporates technical advancement of reduction in CPU consumption. By avoiding processing for non-matching applications, the system significantly reduces CPU utilization, enabling efficient handling of high network traffic volumes. Further, the reduced CPU load translates to improved processing speed and responsiveness, ensuring an optimal user experience and minimizing packet processing latency. The present disclosure also eliminates the need for costly DPI operations on all packets, leading to significant CPU savings and improved system performance.

[0086] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[0087] Environment- 100

[0088] User Equipment (UE)- 102

[0089] Server- 104

[0090] Network- 106

[0091] System -108

[0092] Processor- 202

[0093] Memory- 204

[0094] User Interface- 206

[0095] Database- 208

[0096] Transceiver- 210

[0097] Identification module- 212

[0098] Mapping module - 214

[0099] Building module- 216

[00100] Determination module- 218

[00101] Policy module- 220

[00102] User Plane Function (UPF)- 302

[00103] Random Access Network (RAN)- 304

[00104] Data Network- 306

[00105] Application Detection Function (ADF)-308

[00106] Deep Packet Inspection (DPI)-310

[00107] Packet processing Logic- 312

Claims

We Claim:

1. A method (400) of handling traffic request in a network (106), the method (400) comprising the steps of: receiving, by one or more processors (202), a traffic request from the network (106), the traffic request includes at least one data packet along with an Internet Protocol (IP) address; mapping, by the one or more processors (202), the IP address from the received traffic request against a plurality of IP addresses stored in a database (208); determining, by the one or more processors (202), an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit (310), wherein the application identifier pertains to a content of at least one data packet to identify at least one of an application or a service associated with the received traffic request; and handling, by the one or more processors (202), the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request.

2. The method (400) as claimed in claim 1 , wherein the received traffic request is at least an uplink and a downlink traffic request.

3. The method (400) as claimed in claim 2, wherein the uplink traffic request includes the at least one data packet with a destination IP address and the downlink traffic request includes the at least one data packet with a source IP address.

4. The method (400) as claimed in claim 1 , wherein on receipt of the traffic request from the network (106), the one or more processors is configured to perform the step of: identifying, a traffic type of the received traffic request determined by applying a set of traffic identification and classification rules based on a predefined priority.

5. The method (400) as claimed in claim 1, wherein the application identifier enables the one or more processors (202) to identify at least one of the application and service associated with the received traffic request.

6. The method (400) as claimed in claim 1, wherein the at least one of the application and service is preregistered in the network via a Domain Name System (DNS).

7. The method (400) as claimed in claim 1, wherein on determination of the application identifier, the one or more processors (202), is configured to perform the step of mapping the application ID to attributes associated with the plurality of applications and services including at least one IP address, domain name, and Uniform Resource Locator (URL), wherein the step of mapping aids the one or more processors to one of, identify and classify the received traffic request.

8. The method (400) as claimed in claim 1, wherein the mapping is performed at a network layer of the traffic request.

9. The method (400) as claimed in claim 1, wherein the one or more processors (202), builds the database (208) which stores the plurality of IP addresses by transmitting one or more Domain Name System (DNS) queries for each of the application domains extracted from Uniform Resource Locators (URLs), the URLs configured for the respective applications.

10. A system (108) of handling traffic request in a network (106), the system (108) comprising: a transceiver (210), configured to receive, a traffic request from the network (106), the traffic request includes at least one data packet along with an Internet Protocol (IP) address; a mapping module (214), configured to map, the IP address from the received traffic request against a plurality of IP addresses stored in a database (208); a determination module (218), configured to determine, an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit (310), wherein the application identifier pertains to a content of the least one data packet to identify at least one of an application or a service associated with the received traffic request; and a policy module (220), configured to handle, the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request.

11. The system (108) as claimed in claim 10, wherein the received traffic request is at least an uplink and a downlink traffic request.

12. The system (108) as claimed in claim 11, wherein the uplink traffic request includes the at least one data packet with a destination IP address and the downlink traffic request includes the at least one data packet with a source IP address.

13. The system (108) as claimed in claim 10, wherein on receipt of the traffic request from the network, an identification module (212) is configured to identify, a traffic type of the received traffic request determined by applying a set of traffic identification and classification rules based on a predefined priority.

14. The system (108) as claimed in claim 10, wherein the application identifier enables the identification module (212) to identify at least one of the application and service associated with the received traffic request.

15. The system (108) as claimed in claim 10, wherein the at least one of the application and service is preregistered in the network (106) via a Domain Name System (DNS).

16. The system (108) as claimed in claim 10, wherein on determination of the application identifier, the mapping module (214) is configured to perform mapping of the application ID to attributes associated with the plurality of applications and services including at least one IP address, domain name, and Uniform Resource Locator (URL), wherein mapping aids the identification module to identify and classify the received traffic request.

17. The system (108) as claimed in claim 10, wherein the mapping is performed at a network layer of the traffic request.

18. The system (108) as claimed in claim 10, wherein a building module (216) of the system builds the database (208) which stores the plurality of IP addresses by transmitting one or more Domain Name System (DNS) queries for each of the application domains extracted from Uniform Resource Locators (URLs), the URLs configured for the respective applications.

19. A non-transitory computer-readable medium having stored thereon computer- readable instructions that, when executed by a processor (202), causes the processor (202) to: receive, a traffic request from the network (106), the traffic request includes at least one data packet with an Internet Protocol (IP) address; map, the IP address from the received traffic request against a plurality of IP addresses stored in a database (208); determine, an application identifier for the mapped IP address utilizing a Deep Packet Inspection (DPI) unit (310), wherein the application identifier pertains to a content of the least one data packet to identify at least one of an application or a service associated with the received traffic request; and handle, the received traffic request by implementation of a set of rules or policies based on the determined application identifier corresponding to the received traffic request.