Method and system for managing traffic in a network

Abstract

The disclosure provides a method (500) and system (100) for managing traffic in a network (106). The method (500) includes receiving a message from a device. Further, the method (500) includes extracting at least one parameter associated with the device from the received message. The method (500) further includes transmitting a request including the at least one extracted parameter towards a third NF (214). The method (500) further includes adding Information Element (IE) corresponding to device type and Virtual Local Area Network Identifier (VLAN ID) to the request. Further, the method (500) includes transmitting a response corresponding to the request including IE and VLAN ID to the second NF (212). The method (500) further includes customer tag to received response based on IE. The method (500) includes assigning VLAN ID to downlink data packets of device based on customer tag.

Description

METHOD AND SYSTEM FOR MANAGING TRAFFIC IN A NETWORKRESERVATION OF RIGHTS

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

[0002] The present disclosure relates to a field of telecommunications network. In particular, the present disclosure relates to a method and a system for managing traffic in a network.DEFINITIONS

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

[0004] The term “network function” as used herein in the specification refers to a modular software component that performs a specific task within a network infrastructure. The network functions are critical for enabling and managing various network services and features. The concept is central to the Service-Based Architecture (SBA), where network functions are no longer tied to specific hardware but are virtualized and are deployed flexibly on cloud-native platforms.

[0005] The term ‘Residential Multiple Dwelling Unit (RMDU)’ as used herein in the specification refers to a type of network deployment used in residential complexes or buildings where multiple households or units share networkresources. The RMDU devices include equipment such as routers, access points, or modems that facilitate network connectivity within the shared environments.

[0006] The term “Home Gateway (HGW)” as used herein in the specification refers to device that provides connectivity and networking services to a residential environment. The HGW acts as an intermediary between the user's home network and the internet, or a wider network provided by the telecom operator.

[0007] The term “Virtual Local Area Network (VLAN)” as used herein in the specification refers to a technology used in computer networking to segment and isolate network traffic within a larger physical network. By creating VLANs, network administrators can improve performance, enhance security, and manage traffic efficiently.

[0008] The term “Policy Control Function (PCF)” as used herein in the specification refers to a network function in the Fifth Generation (5G) network architecture responsible for managing policies and rules for network operation and service delivery. The PCF defines and enforces policies for managing user sessions, such as quality of service (QoS), charging rules, and access control.

[0009] The term “Session Management Function (SMF)” as used herein in the specification refers to a network function in the 5G network architecture responsible for managing user sessions and the associated network resources for data transfer. The SMF handles establishment, modification, and release of Packet Data Unit (PDU) sessions that enable user equipment (UE) to access data networks.

[0010] The term “User Plane Function (UPF)” as used herein in the specification refers to a network function in the 5G network architecture responsible for handling data traffic between the UE and external data networks. The UPF routes user data traffic between the Radio Access Network (RAN) and external Packet Data Networks (PDNs), such as the internet, private networks, or cloud services. Further, the UPF applies traffic filtering rules based on the policies defined by the SMF, ensuring that only authorized traffic flows are allowed.

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

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

[0013] In modem broadband and 5G core networks, Residential Multiple Dwelling Units (RMDUs) such as apartment complexes, housing societies, and commercial buildings are typically served through shared aggregation and access infrastructures. A Home Gateway (HGW) or a Customer Premises Equipment (CPE) often acts as the termination point for user broadband sessions while also providing connectivity to RMDU management devices, such as building controllers, IP cameras, access control systems, and utility meters. On the transport side, technologies like Ethernet over GRE (EoGRE) and VLAN tagging are widely used to multiplex multiple customers and services over the same physical and logical network paths. In such deployments, traffic from end users, building management systems, and other devices is often carried over the same tunnels and VLAN constructs between the access network and the 5G core.

[0014] However, the RMDU management traffic has characteristics and security requirements that are fundamentally different from regular subscriber broadband traffic. Management traffic is typically intended only for operator-controlled management systems and must not have direct Internet reachability. In contrast, user broadband traffic requires Internet access with appropriate policy control, QoS, and charging. When both classes of traffic are aggregated through the same HGW and share common tunnels and VLANs towards the core, the network may be unable to distinguish between RMDU-originated flows and normal subscriber traffic. The lack of differentiation complicates enforcement of security policies,routing decisions, and QoS treatment for the respective traffic types which may also expose RMDU devices to unintended external connectivity, increasing the risk surface for attacks or misuse.

[0015] Conventional solutions for traffic separation in such environments primarily rely on static configuration at the access or aggregation layers. For example, operators may configure separate VLANs or logical interfaces on aggregation switches or Broadband Network Gateways (BNGs) to carry management traffic and subscriber traffic. In some deployments, dedicated physical ports or separate CPEs may be used to terminate RMDU management traffic, while subscriber traffic uses a different interface. In other cases, the HGW or RMDU devices may be manually configured with specific VLAN tags or IP subnets, and downstream firewalls or routers may use static ACLs and routing rules to steer management flows towards private management networks while routing subscriber traffic towards the public internet.

[0016] However, the conventional approaches suffer from several limitations. Static VLAN and interface configurations at access and aggregation devices require per-site or per-building provisioning, which is operationally complex and error- prone in large-scale deployments with thousands of RMDUs. Any change in traffic segregation policy often demands manual reconfiguration across multiple network elements, leading to long rollout times and inconsistent enforcement. Relying on separate CPEs or physical interfaces increases hardware costs and complicates installation and maintenance at customer premises. Furthermore, when traffic reaches the 5G core encapsulated over common EoGRE tunnels or shared VLANs, the core network functions may still see all flows as belonging to the same subscriber context, preventing fine-grained, policy-based differentiation between RMDU management flows and regular broadband sessions. As a result, the RMDU devices may inadvertently gain or retain Internet reachability, and the operator has limited flexibility to apply differentiated QoS, charging, or routing policies based on device type within a shared HGW-RMDU access environment.

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

[0018] In an exemplary embodiment, a method for managing traffic in a network is described. The method includes receiving a message from a device. The method includes extracting at least one parameter associated with the device from the received message. The method includes transmitting a request including the at least one extracted parameter towards a third Network Function (NF) using a second Network Function (NF). The method further include adding an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further, the method includes transmitting a response corresponding to the request including the added IE and the VLAN ID to the second NF. The method includes adding a customer tag to the received response based on the added IE. Further, the method includes assigning the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

[0019] In an embodiment, the at least one parameter comprises a Media Access Control Identifier (MAC ID).

[0020] In another embodiment, the first NF includes a User Plane Function (UPF), the second NF includes a Session Management Function (SMF) and the third NF includes a Policy Control Function (PCF).

[0021] In another embodiment, the VLAN ID is added as a custom Hypertext Transfer Protocol (HTTP) header to the request.

[0022] In another embodiment, adding the customer tag to the received response, the method includes determining if the added IE corresponding to the device type is associated with a Residential Multiple Dwelling Unit (RMDU) device. Further,the method includes transmitting the received response along with the added IE towards the first NF inside an ethemet packet filter based on the determination.

[0023] In another embodiment, the method includes determining if the added IE corresponding to the device type is not associated with the RMDU device. Further, the method includes assigning a global VLAN ID to one or more downlink data packets of the device based on the determination.

[0024] In another exemplary embodiment, a system for managing traffic in a network is described. The system includes a first Network Function (NF) configured to receive a message from a device. The first NF is configured to extract at least one parameter associated with the device from the received message. Further, the first NF is configured to transmit a request including the at least one extracted parameter towards a third Network Function (NF) using a second Network Function (NF). The system may include the third NF configured to add an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further, the third NF is configured to transmit a response corresponding to the request comprising the added IE and the VLAN ID to the second NF. Finally, the second NF configured to add a customer tag to the received response based on the added IE, and the first NF is configured to assign the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

[0025] In yet another embodiment, a computer program product including a non- transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to execute a method for managing traffic in a network is described. The method includes receiving a message from a device. The method includes extracting at least one parameter associated with the device from the received message. The method includes transmitting a request including the at least one extracted parameter towards a third Network Function (NF) using a second Network Function (NF). The method further include adding an Information Element (IE) corresponding to a device type and aVirtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further, the method includes transmitting a response corresponding to the request including the added IE and the VLAN ID to the second NF. The method includes adding a customer tag to the received response based on the added IE. Further, the method includes assigning the VLAN ID to one or more downlink data packets of the device based on the added customer tag.OBJECTIVES OF THE DISCLOSURE

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

[0027] An objective of the present disclosure is to provide a method and a system to segregate traffic in a network (Fifth Generation (5G) core network) by tagging Residential Multiple Dwelling Unit (RMDU) devices and Home Gateway (HGW) devices with separate Virtual Local Area Network (VLAN) Identifiers (IDs).

[0028] Another objective of the present disclosure is to provide a method and a system to dynamically assign the VLAN IDs to traffic based on the device type, ensuring differentiated treatment of the RMDU and the HGW traffic.

[0029] Another objective of the present disclosure is to provide a method and a system that restrict internet access for the RMDU devices to ensure they are used exclusively for management purposes while maintaining connectivity.

[0030] Another objective of the present disclosure is to provide a method and a system that enhances traffic management efficiency and network security by segregating traffic based on VLAN tagging in a scalable and automated manner.

[0031] Another objective of the present disclosure is to provide a method and a system that segregate data packets on different VLAN IDs for different types of devices.

[0032] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

[0033] 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 the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0034] FIG. 1 illustrates an exemplary network architecture for managing traffic in a network, in accordance with an embodiment of the present disclosure.

[0035] FIG. 2 illustrates an exemplary block diagram of a system managing the traffic in the network, in accordance with an embodiment of the present disclosure.

[0036] FIG. 3 illustrates an exemplary system architecture for managing the traffic in the network, in accordance with an embodiment of the present disclosure.

[0037] FIG. 4 illustrates an exemplary process flow for managing the traffic in the network, in accordance with an embodiment of the present disclosure.

[0038] FIG. 5 illustrates an exemplary flow diagram of a method for managing the traffic in the network, in accordance with an embodiment of the present disclosure

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

[0040] The foregoing shall be more apparent from the following detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102 - User(s)104 -User Equipments (UEs)106 - Network108 - System200 - Block diagram202 - Processor(s)204 - Memory206 -Interface(s)208 - Processing engine210 - Database300 - System architecture302 - Radio Access Network (RAN) (gNodeB)304 - Access and Mobility Management Function (AMF)306 - User Plane Function (UPF)308 - Session Management Function (SMF)310 - Network Exposure Function (NEF)- Data Network (DN) - Unified Data Management (UDM) - Policy Control Function (PCF) - Authentication Server Function (AUSF) - Network Slice Selection Function (NSSF) - Charging Function-Policy Control (CHF-PC) - Diameter Routing Agent (DRA) - Signal Transfer Point (STP) - Binding Support Function (BSF) - Short Message Service Function (SMSF) - Network Data Analytics Function (NWDAF) - Gateway Mobile Location Centre (GMLC) - Location Management Function (LMF) - Location Services (LCS) Client - Equipment Identity Register (EIR) - Flow Diagram - Residential Multiple Dwelling Unit (RMDU) - Method - A computer system - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port670 - ProcessorDETAILED DESCRIPTION

[0041] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

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

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

[0044] Also, it is noted that individual embodiment 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.

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

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

[0047] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0048] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device is capable of receiving and / or transmitting one or parameters, performingfunction / s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and / or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to internet protocol (IP) enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0049] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signalling Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

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

[0051] 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. 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 to connect and interact with technology.

[0052] In the rapidly evolving domain of 5G networks, efficient traffic management and segregation have become paramount to ensure network performance, security, and scalability. Residential Multiple Dwelling Units (RMDUs) and Home Gateway (HGW) devices are two distinct device categories within the 5G core network. The RMDUs are primarily used for management purposes, and the HGWs provide comprehensive internet access to end-users. Given the different roles of the RMDU and the HGW, it is critical to segregate the traffic effectively to avoid unauthorized internet access by RMDU devices and to optimize resource utilization for HGWs.

[0053] However, conventional techniques fail to provide an efficient mechanism to segregate traffic for the RMDU devices and the HGW devices at a granular level, resulting in inefficiencies and security risks. The lack of segregation between thetraffic of the RMDU devices and the HGW devices creates multiple issues such as, the RMDU devices intended for management purposes may gain unintended internet access, resulting in excess resource utilization and risk of security breaches.

[0054] There is, therefore, a need for a method and a system for managing traffic in the network. The present disclosure provides a method for segregating traffic in the 5G core networks based on device types such as the RMDU devices and the HGW devices, leveraging Virtual Uocal Area Network (VUAN) Identifier (ID) tagging. The method includes provisioning the RMDU devices in a Policy Control Function (PCF) with a custom field indicating the device type as "RMDU" . During packet Data Unit (PDU) session establishment, the PCF includes a custom Information Element (IE) specifying the device type and the VLAN ID in Hypertext Transfer Protocol Version 2 (HTTP / 2) messages to a Session Management Function (SMF). The SMF embeds the VLAN ID in a "C-TAG" Information Element (IE) within an Ethernet Packet Filter in a Packet Detection Information (PDI) towards a User Plane Function (UPF). Further, the UPF tags downlink (DL) traffic for the RMDU devices with the VLAN ID provided by the SMF. For traffic, such as HGW traffic, where the C-TAG IE may not be available from the SMF, the UPF applies a global VLAN ID tag in the DL packets. In an exemplary embodiment, the PCF adds the IE corresponding to a device type and an IE corresponding to a VLAN ID. The device IE may include “IE Name: DeviceType”, “IE Identifier: e.g. 0x01”, “Length: e.g. 4 bytes”, and “Value: e.g. "RMDU" (indicating the device is the RMDU)”. Further, the VLAN ID IE may include “IE Name: Vlanldentifier”, “IE Identifier: e.g. 0x02”, “Length: e.g. 2 bytes”, and “Value: e.g. 200 (the VLAN ID assigned to that device type)”. In operation, the PCF constructs a policy response that includes the DeviceType IE with value “RMDU”, and Vlanldentifier IE with value “200”, and also places “200” in a custom HTTP header for convenient parsing.

[0055] In an embodiment, the present disclosure ensures secure isolation of RMDU devices traffic, restricting it to management purposes, efficient differentiation of the RMDU devices and the HGW devices traffic in the 5G core network, andscalability and adaptability through the VLAN ID tagging. Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings. The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1- FIG. 6.

[0056] FIG. 1 illustrates an exemplary network architecture 100 for managing traffic in a network 106, in accordance with an embodiment of the present disclosure. As illustrated in FIG. 1, the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2. . . 104-N associated with one or more users 102-1, 102-2. . . 102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2... 102-N may be collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2. . . 104-N may be collectively referred to as the UE 104 or the UEs 104. Although only three UE 104 are depicted in FIG. 1, however, any number of the UE 104 may be included without departing from the scope of the ongoing description.

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

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

[0059] In FIG. 1, the UE 104 may communicate with the system 108 through the network 106 for sending or receiving various types of data. In an embodiment, the network 106 may include at least one of the 5G network, the 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), Virtual Local Area Network (VLAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0060] 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, the PSTN, a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

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

[0062] In an embodiment, the system 108 may be configured to receive a message from a device. Further, the system 108 may extract at least one parameter associated with the device from the received message. The system 108 may transmit a request including the at least one extracted parameter towards a third Network Function (NF) using a second Network Function (NF). Further, the system 108 may add an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further the system 108 may transmit a response corresponding to the request including the added IE and the VLAN ID to the second NF. The system 108 may add a customer tag to the received response based on the added IE. Further, the system 108 may assign the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

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

[0064] FIG. 2 illustrates an exemplary block diagram 200 of a system 108 for managing the traffic in the network 106, in accordance with an embodiment of the disclosure. FIG. 2 is explained in conjunction with the FIG. 1.

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

[0066] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (RO), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, a processing engine 208 and a database 210.

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

[0068] In an embodiment, the system 108 is configured for managing traffic in the network 106. The first NF 208 may be configured to receive a message from a device such as the UE 104 including a RMDU device or a HGW device. The first NF 208 includes a User Plane Function (UPF). The message may be a solicit message. The solicit message establishes a connection for management traffic, ensuring that the UPF processes and forward the traffic based on predefined rules. The RMDU device may act as a requesting router and inserts one or more Identity Association for Prefix Delegation (IA PD) options into the solicit message sent from the device to the Session Management Function (SMF) via the UPF. The IA PD is an Identity Association through which a server delegates one or more IPv6 prefixes to a requesting router, allowing that router to further subnet and assign addresses within those prefixes to downstream networks or devices. The IA_PD isused when the client is actually a router (e.g., HGW / CPE). The DHCPv6 server assigns a prefix, such as 2001:db8:200: 1000:756, instead of a single address. Further, the router slices the prefix into smaller subnets (e.g., / 64), and assigns the subnets to internal LAN, Wi-Fi, RMDU segments. In an example, the HGW in a residential building sends a DHCPv6 Prefix Delegation request to the operator’s DHCPv6 server. The server returns an IA PD containing a delegated prefix, say 2001:db8:300:4000:: / 56.

[0069] Further, the first NF 208 is configured to extract at least one parameter associated with the device from the received message. The at least one parameter includes a Media Access Control Identifier (MAC ID). The MAC ID is globally unique, assigned by the manufacturer, and embedded in the device's hardware, when the device transmits any Ethernet frame or encapsulated packet toward the network 106, the MAC ID is present in the frame header. The first NF 208, upon receiving the message, parses the link-layer or encapsulation header to read the hardware-embedded MAC ID from the appropriate field (for example, the source MAC address field of the Ethernet header).

[0070] In an embodiment, the first NF 208 is configured to transmit a request including the at least one extracted parameter towards a third Network Function (NF) 214 using a second Network Function (NF) 212. The UPF transmit a session report request to the SMF. The session report request includes the MAC ID associated with the RMDU device. The UPF may send the session report request to inform the SMF about the detected events for the PDU session that are related to a Session Reporting Rules (SRR). The SRR contains information to request the UPF to detect and report events for the PDU session that are not related to specific Packet Detection Rules (PDRs) of the PDU session or that are not related to traffic usage measurement. Further, the SMF transmits a Session Management (SM) policy control request towards the PCF along with the MAC ID associated with the RMDU device. The Session Management (SM) policy control request is a npcf SMPolicyControl request. The npcf SMPolicyControl request provides session related policies to the SMF.

[0071] In an embodiment, the third NF 214 is configured to add an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. The third NF 214 includes a Policy Control Function (PCF). The third NF 214 is configured to add the VLAN ID as a custom Hypertext Transfer Protocol (HTTP) header to the request. When the PCF receives a policy request containing the at least one extracted parameter (for example, the MAC ID and / or other session identifiers), the PCF uses the parameter as a lookup key into an internal policy database or subscriber profile repository. Based on the lookup, the PCF determines the device type and the appropriate VLAN ID that should be applied to traffic associated with that device. The PCF then constructs a policy decision object, for instance in a structured format (such as JSON or an equivalent schema), and explicitly inserts an Information Element (IE) representing the device type into this policy object. The IE may be encoded as a specific field within a rule block (for example, deviceType = "RMDU"), which may later be interpreted by the SMF for configuring user-plane rules. The rule block may be a logical container that includes one or more fields describing when a rule applies and what should be done . To convey the VLAN ID, the PCF leverages the HTTP -based control interface (for example, an HTTP / 2 or HTTP / 1.1 REST API used on the PCF-SMF reference point). Instead of embedding the VLAN ID only in the message body, the PCF programmatically sets a custom HTTP header in an outgoing response.

[0072] Further, the third NF 214 may be configured to transmit a response corresponding to the request including the added IE and the VLAN ID to the second NF 212. The PCF may transmit a Session Management (SM) policy control response towards the SMF including the “x-VLAN-ID=X” and device type=“RMDU”. In an embodiment, the SMF may transmit a session report response towards the UPF. The session report response confirms that the SMF has received and processed the session report request sent by the UPF. The session report response indicates the actions performed by the SMF (such as modifying the PDU session) based on the reported events related to the PDU session.

[0073] In an embodiment, the second NF 212 is configured to add a customer tag to the received response based on the added IE. The second NF 212 includes a Session Management Function (SMF). The second NF is configured to determine if the added IE corresponding to the device type is associated with a Residential Multiple Dwelling Unit (RMDU) device. Further, the second NF 212 is configured to transmit the received response along with the added IE towards the first NF inside an ethemet packet filter based on the determination. The SMF may transmit a session modification request towards the UPF based on the SM policy control response. The SMF may include a customer tag (C-TAG) IE (VLAN ID=X) in the session modification request. The customer tag IE may be a VLAN ID associated with the RMDU device. The VLAN ID enables the UPF to enforce specific traffic segregation and management policies for the RMDU device traffic. The VLAN ID acts as a unique identifier for tagging the RMDU device traffic to segregate the RMDU device traffic from the HGW device traffic. Further, the UPF may transmit a session modification response towards the SMF. The session modification response acknowledges the receipt and implementation of the session modification request sent by the SMF. The session modification response may confirm that the UPF has successfully applied the requested updates to the handling of the PDU session, such as implementing VLAN tagging, Quality of Service (QoS) adjustments, or traffic filtering rules.

[0074] Further, the first NF 208 is configured to assign the VLAN ID to one or more downlink data packets of the device based on the added customer tag. The first NF 208 maintains an internal mapping table where each customer tag is associated with a corresponding VLAN ID (for example, RMDU_200 to VLAN 200, GLOBAL to VLAN 100). When a downlink packet for the device arrives at the first NF 208, the packet classifier matches it against the configured rule, retrieves the associated customer tag, and consults the mapping table to obtain the VLAN ID. Before the packet is transmitted toward the access or aggregation network, the first NF 208 invokes a header-rewrite operation in the user-plane processing pipeline. The operation adds or updates the 802. IQ tag field in the outerEthernet header with the selected VLAN ID. The resulting frame now carries the VLAN ID corresponding to the customer tag and is forwarded over the relevant tunnel or interface.

[0075] In some embodiments, the second NE 212 is configured to determine if the added IE corresponding to the device type is not associated with the RMDU device, and the first NF is configured to assign a global VLAN ID to one or more downlink data packets of the device based on the determination. When the SMF receives the policy response from the third NF 214, the response includes an Information Element (IE) indicating the device type (for example, “RMDU”, “Residential broadband CPE”, “loT device”, or similar). The SMF is configured with a rule set or mapping table that defines which device types are treated as RMDU devices and which are treated as non-RMDU devices. The SMF parses the IE, compares the indicated device type against this mapping, and determines that the device is not associated with an RMDU when the device type does not match any of the preconfigured RMDU categories. Based on the determination, the SMF selects a global VLAN profile forthat device or session instead of an RMDU-specific VLAN profile. The global VLAN profile may be defined in SMF configuration or provided as part of the policy rules from the PCF and typically contains a global VLAN ID (for example, VLAN 100) used for general broadband traffic. During downlink processing, when packets for that device are classified and matched to the configured rule, the first NF 208 identifies that the device is associated with the non-RMDU customer tag and inserts or sets the global VLAN ID in the header of the outgoing Ethernet frames.

[0076] FIG. 3 illustrates an exemplary system architecture 300 for managing the traffic in the network 106, in accordance with an embodiment of the present disclosure. The system architecture 300 is analogous to the 5G network architecture.

[0077] In FIG. 3, a communication flow between various network functions and interfaces of the 5G network architecture is depicted. In an embodiment, the UE104 may be connected to the 5G network architecture. The UE 104 may be the enduser device such as smartphone, loT device that accesses the 5G network for data, voice, or other services. The UE 104 may be connected to an Access and Mobility Management Function (AMF) 304 via N1 interface. The AMF 304 may manage signalling related to connection setup, mobility, and authentication. The N1 interface a transparent interface in the 5G networks that transfers information from the UE 104 to the AMF 304.

[0078] In an embodiment, the AMF 304 is further connected to a Radio Access Network (RAN) (gNodeB) 302 via N2 interface. The RAN 302 provides wireless connectivity between the UE 104 and the 5G network. The N2 interface supports mobility management, session management, and radio resource control between the AMF 304 and the RAN gNB 302, ensuring seamless connectivity and user experience as the UE 104 moves across the network 106. The RAN 302 is further connected to a User Plane Function (UPF) 306 viaN3 interface. The UPF 306 may route user traffic between the RAN 302 and external data networks (DN) 312. The UPF 306 may enforces traffic rules, the QoS, and performs packet inspection. The N3 interface is responsible for handling the data traffic (user plane traffic) between the UE 104 and the network 106. Further, the UPF 306 is connected to the DN 312 via N6 interface. The DN 312 provides internet or private network access for user data traffic through the UPF 306. The N6 interface facilitates the transfer of user data between the network 106 and external data networks (e.g., the internet, private servers, or application networks). The UPF 306 is further connected to a Session Management Function (SMF) 308 via N4 Interface. The SMF 308 may handle session establishment, modification, and release for the PDU session. The SMF 308 Allocates Internet Protocol (IP) addresses and manages traffic steering via the UPF 306. The N4 Interface may be used for managing user sessions and handling user plane data for optimal user experience in traffic routing, session management, and quality of service (QoS) enforcement.

[0079] Further, the SMF 308 is connected to the AMF 304 via the Ni l interface. The N11 interface is responsible for managing session establishment, modification,and termination, as well as handling mobility management and user authentication across the network 106. The SMF 308 is further connected to a Network Exposure Function (NEF) 310 that exposes network capabilities and services to external applications or networks via the N29 interface. The N29 interface is responsible for providing session-related information and policy decisions from the SMF 308 to external network entities and third-party applications via the NEF 310. The NEF is further connected to the AMF 304 via N51 interface. The N51 interface enables the AMF 304 to expose mobility management and authentication data to external applications or services via the NEF 310. The SMF 308 is further connected to a Policy control function (PCF) 316 via N7 interface. The PCF 316 provides policy rules and enforces Quality of Service (QoS) for traffic management. The N7 interface enables communication between the SMF 308 and the PCF 316 for the management and enforcement of policies related to Quality of Service (QoS), charging, and other session-specific rules. The PCF 316 is further connected to the AMF 304 via a N15 interface. The N15 interface is responsible for enabling the AMF 304 to interact with the PCF 316 for policy control and decision-making related to mobility management and session management for the UE 104. The PCF 316 is further connected to a Binding Support Function (BSF) 328 via a Rx interface. The BSF 328 may manage binding between user sessions and the network functions serving the sessions. The Rx interface is responsible for managing policy control and binding information related to user data sessions and mobility management.

[0080] Further, the BSF 328 is further connected to the NEF 310. The BSF is further connected to a Diameter Routing Agent (DRA) 324 via the Rx interface. The DRA 324 is a protocol used for authentication, authorization, and accounting (AAA) in the network 106. The DRA 324 acts as an intelligent intermediary for routing Diameter messages between network nodes. The Rx interface ensures that charging rules and quality of service (QoS) policies are applied consistently and accurately to user sessions by enabling the necessary information exchange between the DRA 324 and BSF 328. The DRA 324 is further connected to the PCFvia a Sd interface. The Sd interface is responsible for ensuring that policy decisions made by the PCF 316 are properly enforced and charging information is accurately routed and exchanged between various network components.

[0081] Further, the PCF 316 is connected to a Charging Function-Policy Control- Policy Control (CHF-PC) 322 via a N28 interface. The CHF-PC 322 may handle charging and billing policies for user sessions. The N28 interface is facilitates the exchange of charging and policy control information, ensuring that policy decisions made by the PCF 316 are aligned with charging rules managed by the CHF-PC 322. The CHF-PC 322 is further connected to the SMF 308 viaN40 interface and to the DRA 324 via Gy, Sy interface. The N40 interface is responsible for enabling accurate charging and policy enforcement in the network 106. The N40 allows for the real-time exchange of charging data, policy control decisions, and service usage reports. The Gy interface refers to a standardized online charging reference point between a Policy and Charging Enforcement Function (PCEF) or packet core gateway (for example, a GGSN / PGW / UPF acting as the charging enforcement point) and an Online Charging System (OCS). The Sy interface refers to a standardized reference point between a Policy and Charging Rules Function (PCRF) (or policy control function) and an Online Charging System (OCS), used to exchange subscriber spending, quota, and usage-related information that may influence policy decisions. Further, the Gy, Sy interface is responsible for managing charging and policy control operations related to user sessions and data flows. The Gy, Sy interface ensures that Diameter signalling for charging, policy enforcement, and QoS is efficiently routed between the CHF-PC 322 and other network components. Further, the PCF 316 is connected to a Network Data Analytics Function (NWDAF) 332 viaN23 interface. The NWDAF 332 Collects and analyses data from network functions to optimize performance. The N23 interface is responsible for enabling the PCF 316 to incorporate real-time network data and analytics into its policy control decisions.

[0082] The NWDAF 332 is further connected to a Network Slice Selection Function (NSSF) 320 via N34 interface. The NSSF 320 allows multiple logicalnetworks (slices) to run on a shared physical network infrastructure. Each slice is tailored to specific services, use cases, or customer requirements. The N34 interface facilitates the exchange of data related to network slicing and network performance analytics. The NSSF 320 is further connected to the AMF 304 via a N22 interface. The N22 interface enables the AMF 304 to interact with the NSSF 320 to obtain information about network slice selection for a particular UE 104 or session.

[0083] Further, the AMF 304 is connected to a Unified Data Management (UDM) 314 via a N8 interface. The UDM 314 stores and manages subscriber data, authentication credentials, and policies. The N8 interface is used for subscriber data retrieval from the AMF 304. Further, the UDM 314 is connected to an Authentication Server Function (AUSF) 318 via a N 13 interface . The N 13 interface is used for the authentication process of the UE 104 and ensures that the UE 104 trying to connect to the network 106 is legitimate and authorized to access services. The UDM 314 is connected to a Short Message Service Function (SMSF) 330 via N21 interface. The AUSF 318 may perform authentication of the UE 104 using credentials stored in the UDM 314. The SMSF 330 may handle Short Message Service (SMS) services in the 5G network. The N21 interface enables the SMSF 330 to interact with the UDM 314 to manage SMS functionality, particularly for storing, retrieving, and processing subscriber-related data and settings related to the SMS services. The SMSF 330 is further connected to a Signal Transfer Point (STP) 326 via SIGTRAN interface. The STP 326 serves as a signalling message router, ensuring that signalling messages reach the correct destination node, such as a Mobile Switching Center (MSC), Home Location Register (HLR), or Short Message Service Center (SMSC). The SIGTRAN interface facilitates signalling related to the SMS within the network 106 and for routing and transferring SMS- related signalling messages across different parts of the network 106 and the SS7 networks. The SMSF 330 is further connected to the DRA 324 via SGd interface. The SGd interface supports SMS routing, message delivery, and policy enforcement within the network 106.

[0084] Further, the SMSF 330 is connected to the AMF 304 via a N20 interface. The N20 interface facilitates the exchange of information related to SMS delivery, mobility management, and session management. The AMF 304 is further connected to the AUSF 318 via a N12 interface. The N12 interface is used for the authentication and security procedures during the initial registration and mobility management of the UE 104 in the network 106. The AMF 304 is further connected to a 5G an Equipment Identity Register (EIR) 340 via aN17 interface. The EIR 340 is responsible for managing and validating mobile device identities such as the UE 104. The N17 interface facilitates the exchange of information about the equipment identity of the UE 104 for authentication and validation purpose.

[0085] The AMF 304 is further connected to a Gateway Mobile Location Centre (GMLC) 334 via a NL2 interface. The GMLC 334 manages location-based services, supporting interfaces for external applications and Location Management Function (LMF) 336. The NL2 interface is a communication interface between the GMLC 334 and the AMF 304 in the network to support a location-based services (LBS) to provide location information for emergency services, tracking, and other location-dependent services. The LMF 336 is connected to the AMF 304 via a NL1 interface. The NL1 interface manages user mobility and authentication during the registration and handover processes. The LMF 336 may provide location services for UEs 104. The NL1 interface allows the LMF 336 and the AMF 304 to handle location and mobility management and ensures a smooth user experience as the UE 104 moves through the network and maintains its active session. Further, the GMLC 334 is connected to a Location Services (LCS) client 338 via Le interface. The LCS Client 338 requests location-related information from the network to support applications and services that rely on positioning data. The Le interface facilitates communication between the GMLC 334 and the LCS Client 338, enabling the LCS Client 338 to request and retrieve location information about the UE 104 or devices.

[0086] Further, the GMLC 334 is connected to the UDM 314 via NL6 interface.The NL6 interface communicate the location data when location-based services orsubscriber-related information is required for delivering accurate location data. When a location request is made (e.g., an emergency call or a location-based service query), the GMLC 334 may need to authenticate and authorize the UE 104. Further, the UDM 314 is connected to the NEF 310 via N52 interface. The N52 interface enables the UDM 314 to expose relevant subscriber data and authentication information to other network functions or external applications via the NEF 310. Further, the NEF 310 is connected to the GMLC 334 via a NL5 interface. The NL5 interface enables the exchange of location information and facilitates locationbased services by exposing location-related capabilities of the network to external applications or clients.

[0087] An NL7 interface is an interface that enables the communication between the LMF 336 and other location-related functions for location services in an Internet protocol (IP) Multimedia Subsystem (IMS). In an aspect, the IMS is an architecture for delivering multimedia services over the IP networks. The IMS is a framework that enables the integration and delivery of services such as voice, video, messaging, and data through the Internet Protocol (IP).

[0088] A N14 interface is an interface used by the AMF 304 for coordinating session management and mobility management, enabling these two core network functions to work together in supporting the user's 102 session, particularly during handovers or mobility events. The N14 interface facilitates the exchange of information required for session management, mobility management, and bearer resource management. The N14 ensures that user sessions are maintained without interruption, even as the user 102 moves across different areas of the network 106. Additionally, the N 14 interface supports the enforcement of QoS and policy rules, ensuring seamless session continuity and high-quality service delivery.

[0089] A N16 interface is an interface used by the SMF 308 for service data flow (SDF) management. The N16 interface is responsible for the interaction between the SMF 308 and the application functions (AFs), such as service platforms or applications that require session management and data flow control. The N16interface enables the SMF 308 to enforce application-specific policies, manage QoS requirements, and dynamically adjust session parameters based on the service or application the user is accessing. By allowing the AF to provide policy information, the N16 interface ensures that user sessions are optimized for the specific needs of each service, leading to a more tailored and efficient user experience.

[0090] FIG. 4 illustrates an exemplary process flow 400 for managing the traffic in the network 106, in accordance with an embodiment of the present disclosure. The process flow 400 may be implemented by network functions such as the PCF 316, UPF 306, and the SMF 308. FIG. 4 is explained in conjunction with the FIGs. 1, 2 and 3.

[0091] At step 404, the RMDU device 402 may transmit the solicit message to the UPF 306. The solicit message establishes a connection for management traffic, ensuring that the UPF 306 may process and forward the traffic based on predefined rules. The solicit message may also include the MAC ID associated with the RMDU device 402.

[0092] At step 406, the UPF 306 transmit a session report request to the SMF 308. The session report request includes the MAC ID associated with the RMDU device 402. The UPF 306 sends the session report request to inform the SMF 308 about the detected events for the PDU session. The detected events may include session updates, thresholds being crossed, anomalies, or status changes. Further, the MAC ID uniquely identifies the RMDU device 402 involved in the PDU session.

[0093] At step 408, the SMF 308 transmits a Session Management (SM) policy control request towards the PCF 316 along with the MAC ID associated with the RMDU device 402. The Session Management (SM) policy control request is a npcf_ SMPolicyControl request. The npcf SMPolicyControl request provides session related policies to the SMF 308. The PCF 316 uses the MAC ID to identify the RMDU device 402 and apply the correct policies such as traffic restrictions or VUAN tagging for the PDU session. In an embodiment, the RMDU device 402 is provisioned at the PCF 316. The PCF 316 compares the MAC ID received with theSM policy control request with the provisioned RMDU device 402, to identify the RMDU device 402.

[0094] At step 410, the PCF 316 transmits a SM policy control response towards the SMF 308. The SM policy control response may include the x-VLAN-ID=X and the custom IE devicetype= “RMDU”. The custom IE ensures that the SMF 308 may differentiate the session as being associated with an RMDU 402, applying policies specifically designed for such devices. The VLAN ID provided in the SM policy control response ensures proper tagging of traffic for isolation and management purposes, separating RMDU device 402 traffic from other type such as the HGW.

[0095] At step 412, the SMF 308 may transmit a session report response towards the UPF 306. The session report response confirms that the SMF 308 has received and processed the session report request sent by the UPF 306. The session report response indicates the actions performed by the SMF 308 (such as modifying PDU session) based on the reported events related to the PDU session.

[0096] At step 414, the SMF 308 transmits a session modification request towards the UPF 306 based on the SM policy control response. The SMF 308 may include a customer tag (C-TAG) IE (VLAN ID=X) in the session modification request. The customer tag IE may be a VLAN ID associated with the RMDU 402. The VLAN ID enables the UPF 306 to enforce specific traffic segregation and management policies for the RMDU 402 traffic. The VLAN ID acts as a unique identifier for tagging the RMDU 402 traffic to segregate the RMDU device traffic from the HGW traffic.

[0097] At step 416, the UPF 306 transmits a session modification response towards the SMF 308. The session modification response acknowledges the receipt and implementation of the session modification request sent by the SMF 308. The session modification response may confirm that the UPF 306 has successfully applied the requested updates to the handling of the PDU session, such as implementing VLAN tagging, QoS adjustments, or traffic filtering rules.

[0098] At step 418, the UPF 306 transmits an advertise message towards the RMDU device 402. The RMDU device 402 may construct a full Internet Protocol Version 6 (IPv6) address via IPv6 Stateless address autoconfiguration to ensure that the link-local address generated by the RMDU device 402 does not collide with the link-local address of the UPF 306 and the SMF 308.

[0099] At step 420, the RMDU device 402 may transmit a request towards the UPF 306. The request may correspond to retrieving timer values (T1 and T2) at which RMDU 402 reports for live session. T1 may represents the interval at which the RMDU 402 is required to send periodic updates or reports about the ongoing live session to the UPF 306. T2 may indicates a threshold or timeout value for events such as idle session detection or triggering additional session-specific actions.

[0100] At step 422, the UPF 306 may transmit a reply corresponding to the request towards the RMDU device 402. The reply may include values of the Timer T1 and T2 for the RMDU device 402.

[0101] At step 424, the UPF 306 may tag the downlink (DU) traffic (DU data packets) directed towards the RMDU device 402 with the VUAN ID associated with the RMDU device 402. The RMDU device 402 traffic is tagged with the VUAN ID in such a way that all the traffic directed to RMDU device 402 is transmitted via the VUAN ID associated with the RMDU device 402, ensuring segregation of the traffic data.

[0102] FIG. 5 illustrates an exemplary flow diagram of a method (500) for monitoring the one or more counters in the network (106), in accordance with an embodiment of the present disclosure. The method 500 may be implemented by the first NF 208, the second NF 212 and the third NF 214 of the system 100. FIG. 5 is explained in conjunction with FIGs. 1, 2, 3 and 4.

[0103] At step 502, a message is received from a device. The message may be an initial data packet, a control message, or any uplink traffic that uniquely identifies the device on the link layer. In an example, a RMDU controller in the buildingpowers up and sends a DHCP Discover or other initial packet toward the network. The packet travels through the Home Gateway (HGW), the aggregation network, and reaches the first NF (UPF 208) encapsulated in the usual access tunnel (e.g., Ethernet over Generic Routing Encapsulation (EoGRE) or General Packet Radio Service (GPRSO Tunnelling Protocol - User Plane (GTP-U)).

[0104] At step 504, at least one parameter associated with the device is extracted from the received message. The at least one parameter include a Media Access Control Identifier (MAC ID). In an example, from the incoming DHCP packet, the UPF inspects the Ethernet header and reads the MAC ID “AA:BB:CC:DD:EE:01”. The UPF may flag this MAC ID as a key parameter to be forwarded upstream with a policy request so that the PCF may decide if this MAC corresponds to an RMDU controller.

[0105] At step 506, a request including the at least one extracted parameter is transmitted towards a third Network Function (NF) using a second Network Function (NF). The first NF include a User Plane Function (UPF), the second NF include a Session Management Function (SMF) and the third NF include a Policy Control Function (PCF). In an example, the UPF sends a usage report or session establishment message to the SMF including the MAC ID “AA:BB:CC:DD:EE:01”. The SMF then triggers a policy request to the PCF.

[0106] At step 508, an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) is added to the request based on the at least one extracted parameter. The VLAN ID is added as a custom Hypertext Transfer Protocol (HTTP) header to the request. In an example, the PCF checks an internal mapping such as “AA:BB:CC:DD:EE:01” corresponds to a DeviceType = RMDU and VLAN ID = 200. Further, the PCF prepares a response that includes IE such as DeviceType = RMDU and a Custom HTTP header “X- RMDU-VLAN-ID” such as 200.

[0107] At step 510, a response corresponding to the request including the added IE and the VLAN ID is transmitted to the second NF. In an example, the PCF sendsan HTTP / 2 response to the SMF which may include payload including policy rules referencing DeviceType = RMDU and the custom header “X-RMDU-VLAN-ID: 200”. The SMF then parses the response and now knows that MAC is an RMDU device and all downlink traffic must be tagged with VLAN 200.

[0108] At step 512, a customer tag is added to the received response based on the added IE. If the added IE corresponding to the device type is associated with a Residential Multiple Dwelling Unit (RMDU) device, the received response along with the added IE is transmitted towards the first NF inside an ethemet packet filter. In an example, the SMF adds a customer tag like C-Tag = RMDU_200 tied to the session. Further, the SMF sends an N4 Session Modification message to the UPF containing an Ethemet packet filter that matches downlink packets for MAC AA:BB:CC:DD:EE:01 and an instruction such as “Forthis packet filter, use C-TAG corresponding to VLAN ID 200. The message embeds the device-type IE and instructs the UPF to treat the device as an RMDU endpoint.

[0109] At step 514, the VLAN ID is assigned to one or more downlink data packets of the device based on the added customer tag. In an example, When an application server in the operator’s private management network sends a control packet to the RMDU controller, the packet reaches the UPF as downlink traffic for the session associated with MAC AA:BB:CC:DD:EE:01. The UPF matches this packet to the configured filter and tags the outgoing Ethemet frame with VLAN 200 before forwarding it over the EoGRE tunnel toward the building. As a result, aggregation switches may treat this traffic as management-only RMDU traffic.

[0110] In an embodiment, if the added IE corresponding to the device type is not associated with the RMDU device, a global VLAN ID is assigned to one or more downlink data packets of the device. In an example, Consider another device with MAC ID “AA:BB:CC:DD:EE:02” connected to the same HGW but classified by the PCF as a “Residential broadband device” rather than RMDU. The PCF returns DeviceType = Residential and VLAN ID = 100 (global VLAN). The SMF configures the UPF accordingly. For all downlink packets destined to the MAC ID,the UPF tags the Ethernet frames with VLAN 100, which represents the general internet access VLAN.[oni] FIG. 6 illustrates an exemplary computer system 600 in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 6, the computer system 600 may include an external storage device 610, a bus 620, a main memory 630, a read-only memory 640, a mass storage device 650, communication port(s) 660, and a processor 670. A person skilled in the art will appreciate that the computer system 600 may include more than one processor and communication ports. The processor 670 may include various modules associated with embodiments of the present disclosure. The communication port(s) 660 may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 660 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 600 connects.

[0112] The main memory 630 may be a Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 640 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 670. The mass storage device 650 may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device 650 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.

[0113] The bus 620 communicatively couples the processor 670 with the other memory, storage, and communication blocks. The bus 620 may be, e.g. a PeripheralComponent Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 670 to the computer system 600.

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

[0115] In an embodiment, the Residential Multiple Dwelling Unit (RMDU) is provisioned at the Policy Control Function (PCF) along with a custom field DeviceType= “RMDU”. During Home Gateway (HGW) packet data unit (PDU) session establishment, the PCF includes custom IE deviceType: "RMDU" based on the custom field at the PCF. Further, the PCF includes a “x-vlan-id=<VLAN ID> as custom Hypertext Transfer Protocol Version 2 (HTTP2) header towards the Session Management Function (SMF) during PDU session establishment of HGW. Based on the customized HTTP2 header and deviceType: "RMDU”, the SMF includes a customer tag ‘C-TAG’ IE (VLAN ID) towards the User Plane Function (UPF) inside Ethernet Packet Filter in a Packet Detection Information (PDI). Further, the UPF tag all the Downlink (DL) traffic with the Virtual Local Area Network Identifier (VLAN ID) provided by the SMF for RMDU traffic (‘C-TAG’ IE (VLAN ID) is present), for HGW traffic, where C-TAG IE is not present, the UPF may tag the global VLAN in downlink (DL) packets towards the HGW device.

[0116] In an embodiment, a method for managing traffic in a network is described. The method includes receiving a message from a device. The method includes extracting at least one parameter associated with the device from the received message. The method includes transmitting a request including the at least oneextracted parameter towards a third Network Function (NF) using a second Network Function (NF). The method further include adding an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further, the method includes transmitting a response corresponding to the request including the added IE and the VLAN ID to the second NF. The method includes adding a customer tag to the received response based on the added IE. Further, the method includes assigning the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

[0117] In another embodiment, a system for managing traffic in a network is described. The system includes a first Network Function (NF) configured to receive a message from a device . The first NF is configured to extract at least one parameter associated with the device from the received message. Further, the first NF is configured to transmit a request including the at least one extracted parameter towards a third Network Function (NF) using a second Network Function (NF). The system may include the third NF configured to add an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further, the third NF is configured to transmit a response corresponding to the request comprising the added IE and the VLAN ID to the second NF. Finally, the second NF configured to add a customer tag to the received response based on the added IE, and the first NF is configured to assign the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

[0118] In yet another embodiment, a computer program product including a non- transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to execute a method for managing traffic in a network is described. The method includes receiving a message from a device. The method includes extracting at least one parameter associated with the device from the received message. The method includes transmitting a request including the at least one extracted parameter towards a thirdNetwork Function (NF) using a second Network Function (NF). The method further include adding an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter. Further, the method includes transmitting a response corresponding to the request including the added IE and the VLAN ID to the second NF. The method includes adding a customer tag to the received response based on the added IE. Further, the method includes assigning the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

[0119] While the foregoing description 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.

[0120] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0121] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing fromthe principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.

[0122] The present disclosure provides significant technical advancements in segregating Residential Multiple Dwelling Unit (RMDU) management traffic from Home Gateway (HGW) subscriber traffic in a 5G core network, including Ethernet over the EoGRE based access. Conventional approaches treat all HGW-anchored sessions uniformly at the core, relying on common VLANs or static configuration at aggregation devices, which makes it difficult for the core to distinguish RMDU management flows from normal broadband traffic. This leads to security exposure where RMDU devices may inadvertently reach the public internet, complicate policy enforcement, and reduces flexibility in applying differentiated QoS or routing. To overcome the limitations, the present disclosure introduces a device- type-aware VLAN tagging mechanism wherein the Policy Control Function (PCF) provisions RMDU devices with a custom field Device Type = “RMDU”, inserts a corresponding custom information element into HGW establishment signalling, and conveys a dedicated VLAN identifier via a custom HTTP / 2 header towards the Session Management Function (SMF). The SMF, in turn, includes a C-TAG information element carrying the VLAN ID within an ethemet packet filter in the Packet Detection Information (PDI) towards the User Plane Function (UPF), enabling the UPF to deterministically tag downlink traffic for RMDU devices with an RMDU-specific VLAN while other traffic continues to use a global VLAN.

[0123] By incorporating policy-driven device typing at the PCF, VLAN ID signalling over HTTP / 2 towards the SMF, and automatic C-TAG insertion at the UPF, the present disclosure achieves multiple technical benefits. First, the present disclosure enables precise separation of RMDU management traffic from HGW broadband traffic at the 5G core, allowing the network to completely block Internet access for RMDU devices while still maintaining secure management connectivity.Second, the present disclosure centralizes the VLAN selection logic in the control plane instead of relying on manual per-node configuration, reducing configuration errors and simplifying rollout across large deployments. Third, the present disclosure preserves transparency at the RMDU and HGW side, since no special encapsulation logic or VLAN awareness is required in the customer premises equipment, all differentiation is achieved by core-network intelligence. Fourth, the present disclosure improves scalability and operational agility, as introducing a new VLAN or modifying the segregation policy only requires updates to PCF / SMF configuration rather than field re-provisioning of access devices. Fifth, by allowing the UPF to tag only RMDU-classified traffic with the dedicated VLAN and to apply a global VLAN for all remaining flows, the present disclosure ensures backward compatibility with existing transport and EoGRE infrastructures while delivering secure, policy-driven traffic segregation for mixed RMDU / HGW environments.TECHNICAL ADVANTAGES

[0124] Efficient Traffic Segregation: The present disclosure provides a method and a system that enables Fifth Generation (5G) core network to segregate traffic for Residential Multiple Dwelling Unit (RMDU) devices and Home Gateway (HGW) devices using Virtual Local Area Network (VLAN) tagging, ensuring precise and efficient traffic management.

[0125] Enhanced Network Security: By restricting internet access for RMDU devices and isolating the traffic for management purposes, the present disclosure reduces the risk of unauthorized access and enhances overall network security.

[0126] Dynamic VLAN Assignment: The present disclosure leverages custom fields in a Policy Control Function (PCF) and a Session Management Function (SMF) to dynamically assign VLAN Identifiers (IDs), enabling automated and scalable traffic classification.

[0127] Improved Quality of Service (QoS): By isolating the RMDU and the HGW traffic, the present disclosure ensures better QoS by applying tailored policies for each type of traffic, optimizing resource utilization.

[0128] Reduced Network Complexity: The present disclosure perform automation of VLAN ID tagging based on device type, eliminating need for manual configuration, reducing complexity in traffic management and policy enforcement.

[0129] Adaptability to Device Types: The present disclosure distinguishes between different device types such as the RMDU and the HGW using custom identifiers, allowing flexible and precise application of network policies

[0130] Enhanced Management Capabilities: By tagging the RMDU traffic separately, the present disclosure ensures that the RMDU devices can be effectively monitored and managed without impacting other network operations.

[0131] Minimized Packet Eoss and Conflicts: The VLAN-based traffic segregation ensures that traffic from different device types does not interfere with each other, minimizing packet loss and reducing conflicts.

Claims

Claims1. A method (500) for managing traffic in a network (106), the method (500) comprising: receiving (502), by a first network function (NF) (208), a message from a device; extracting (504), by the first NF (208), at least one parameter associated with the device from the received message; transmitting (506), by the first NF (208), a request comprising the at least one extracted parameter towards a third Network Function (NF) (214) using a second Network Function (NF) (212); adding (508), by the third NF (214), an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter; transmitting (510), by the third NF (214), a response corresponding to the request comprising the added IE and the VLAN ID to the second NF (212); adding (512), by the second NF (212), a customer tag to the received response based on the added IE; and assigning (514), by the first NF (208), the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

2. The method (500) as claimed in claim 1, wherein the at least one parameter comprises a Media Access Control Identifier (MAC ID).

3. The method (500) as claimed in claim 1, wherein the first NF (208) comprises a User Plane Function (UPF) (306), the second NF (212) comprises a Session Management Function (SMF) (308) and the third NF (214) comprises a Policy Control Function (PCF) (316).

4. The method (500) as claimed in claim 1, wherein the VLAN ID is added as a custom Hypertext Transfer Protocol (HTTP) header to the request.

5. The method (500) as claimed in claim 1, wherein adding the customer tag to the received response, further comprising: determining, by the second NF (212), if the added IE corresponding to the device type is associated with a Residential Multiple Dwelling Unit (RMDU) device (402); and transmitting, by the second NF (212), the received response along with the added IE towards the first NF (208) inside an ethemet packet filter based on the determination.

6. The method (500) as claimed in claim 1, further comprising: determining, by the second NF (212), if the added IE corresponding to the device type is not associated with the RMDU device (402); and assigning, by the first NF (208), a global VLAN ID to one or more downlink data packets of the device based on the determination.

7. A system (108) for managing traffic in a network (106), the system (108) comprising: a first Network Function (NF) (208) configured to: receive a message from a device; extract at least one parameter associated with the device from the received message; and transmit a request comprising the at least one extracted parameter towards a third Network Function (NF) (214) using a second Network Function (NF) (212);the third NF (214) configured to: add an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter; and transmit a response corresponding to the request comprising the added IE and the VLAN ID to the second NF (212); and the second NF (212) configured to add a customer tag to the received response based on the added IE, and wherein the first NF (208) is configured to assign the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

8. The system (108) as claimed in claim 7, wherein the at least one parameter comprises a Media Access Control Identifier (MAC ID).

9. The system (108) as claimed in claim 7, wherein the first NF (208) comprises a User Plane Function (UPF) (306), the second NF (212) comprises a Session Management Function (SMF) (308) and the third NF (214) comprises a Policy Control Function (PCF) (316).

10. The system (108) as claimed in claim 7, wherein the third NF (214) is configured to add the VLAN ID as a custom Hypertext Transfer Protocol (HTTP) header to the request.

11. The system (108) as claimed in claim 7, wherein the second NF (212) is configured to: determine if the added IE corresponding to the device type is associated with a Residential Multiple Dwelling Unit (RMDU) device (402); and transmit the received response along with the added IE towards the first NF (208) inside an ethemet packet filter based on the determination.

12. The system (108) as claimed in claim 7, wherein the second NF (212) is configured to determine if the added IE corresponding to the device type is not associated with the RMDU device (402), and the first NF (208) is configured to assign a global VLAN ID to one or more downlink data packets of the device based on the determination.

13. A computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors (202), cause the one or more processors (202) to execute a method for managing traffic in a network (106), the method (500) comprising: receiving (502), by a first network function (NF) (208), a message from a device; extracting (504), by the first NF (208), at least one parameter associated with the device from the received message; transmitting (506), by the first NF (208), a request comprising the at least one extracted parameter towards a third Network Function (NF) (214) using a second Network Function (NF) (212); adding (508), by the third NF (214), an Information Element (IE) corresponding to a device type and a Virtual Local Area Network Identifier (VLAN ID) to the request based on the at least one extracted parameter; transmitting (510), by the third NF (214), a response corresponding to the request comprising the added IE and the VLAN ID to the second NF (212); adding (512), by the second NF (212), a customer tag to the received response based on the added IE; and assigning (514), by the first NF (208), the VLAN ID to one or more downlink data packets of the device based on the added customer tag.

Images