System and method for network policy configuration

Abstract

The disclosure relates to a method (500) and system (108) for configuring a network policy for a network device (114) in a network (106). The method (500) involves receiving (502), by a policy control function (PCF) (110), a policy control create request from a session management function (SMF) (112), wherein the policy control create request comprises a parameter field. The PCF (110) analyzes (504) the parameter field to identify a device type and a virtual local area network (VLAN) identifier (ID). The PCF (110) verifies (506) whether the device type and the VLAN ID are not null. Upon successful verification, the PCF (110) sends (508) a success response to the SMF (112), wherein the success response comprises the VLAN ID in a header and the device type, thereby configuring a network policy for the network device (114) in the network (106).

Description

SYSTEM AND METHOD FOR NETWORK POLICY CONFIGURATIONRESERVATION 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 CLIENT or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of communication systems. More particularly, the present disclosure relates to systems and methods for network policy configuration.DEFINITION

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

[0004] The term “Multi-Dwelling Unit (MDU) devices” refers to devices providing high-speed internet access to residents in multi-tenant buildings in the network. The MDU devices include network equipment that extend 5G coverage and capacity to densely populated areas.

[0005] The term “Customer Premises Equipment (CPE)” refers to a device installed in outdoor (referred to as outdoor CPE) or indoor locations (referred to as indoor CPE) close to end-users, such as on rooftops, walls, streetlights, office spaces, rooms, or utility poles. The CPE ensures optimal coverage and signal strength for the 5G services. The CPE serves as a gateway or access point for the 5G network, facilitating communication between the user's device and the core network infrastructure.

[0006] The term “Custom field” refers to a user-defined field that is not included by default in a standard system, application, or database schema. A custom field allows users to extend the system's functionality by adding additional data specific to their needs or use cases.

[0007] The term “CustomField2” refers to a customizable field or parameter used to store additional configuration details that are not part of the standard set of parameters. For example, a network administrator might use “CustomField2” to record specific settings or identifiers unique to the network.

[0008] The term “CustomField3” refers to an additional customizable field used for capturing or managing extra data beyond the standard parameters. This field is part of a flexible system designed to accommodate specific needs or attributes that are not covered by default fields.

[0009] The term “Policy control function (PCF)” refers to a network function in the network that provides policy control and decision-making capabilities. It is responsible for defining and enforcing policies related to quality of service (QoS), network slicing, and other network management aspects.

[0010] The term “Virtual Local Area Network (VLAN) refers to a network configuration that allows for the creation of logically segmented networks within a physical network infrastructure. The VLANs are used to group together devices thatare on the same network, regardless of their physical location, effectively creating multiple isolated networks within a single physical network.

[0011] The term “Global VLAN” refers to a virtual local area network (VLAN) configuration that is designed to be applicable across multiple network devices, segments, or geographic locations within an organization. The global VLAN extends its reach across various parts of the network, providing a unified network segment that spans a broader area.

[0012] The term “Virtual Local Area Network Identifier (VLAN ID)” refers to a unique number assigned to a VLAN to differentiate it from other VLANs within the network.

[0013] The term “Customized configuration” refers to the process of tailoring the settings and parameters of a system, application, or device to meet specific needs or preferences that differ from the default or standard settings.

[0014] The term “Network policies” refers to a set of rules, guidelines, and configurations applied to a network to manage its behavior, security, performance, and accessibility. These policies help ensure that the network operates efficiently, remains secure, and meets organizational or operational requirements.

[0015] The term “Resource allocation” refers to the process of efficiently assigning network resources such as bandwidth, power, and time slots to users and services to ensure effective communication, maximize throughput, and maintain quality of service (QoS).

[0016] The term “Policy Control Create Request” refers to a request or a message sent by a Session Management Function (SMF) to a PCF. The policy control creates request initiates the process of creating and applying policy rules for a network session.

[0017] The term “Session Management (SM) Policy Create Request” refers to a request for creating a new policy for a specific session or service in the network.

[0018] The term “Success response” refers to a response send from the PCF to the SMF to indicate that the policy control create request has been successfully processed.

[0019] The term “SM Create Success Response” refers to a response indicating that the policy creation was successful and provides any additional details as necessary.

[0020] The term “Device type” refers to the classification or specification of devices based on their hardware capabilities, functionalities, and the roles they play within the network. The device types help network operators manage and optimize their network services by understanding the different requirements and characteristics of various devices.

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

[0022] 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 is provided only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0023] Wireless telecommunications networks, including Fifth Generation (5G) networks, are increasingly being deployed to provide high-capacity, low-latency communication services to end users. These networks support a variety of user equipment (UE) types and configurations, including smartphones, fixed wireless terminals, and various forms of customer premises equipment (CPE). In denselypopulated environments such as multi-tenant buildings, apartment complexes, or campus settings, network operators often utilize Multi-Dwelling Unit (MDU) devices to extend and aggregate wireless access for multiple end users through a shared infrastructure.

[0024] A Multi-Dwelling Unit (MDU) typically interfaces with the access network through Customer Premises Equipment (CPE). The CPE serves as a relay point to extend last-mile connectivity between subscriber endpoints and the network core and may be provided at indoor or outdoor locations. MDUs and CPEs differ in form, function, and deployment environment, with MDUs often requiring dedicated policy control due to their shared access nature and localized subscriber density.

[0025] Within a 5G core network, functions such as the Session Management Function (SMF) and the Policy Control Function (PCF) are responsible for establishing session contexts and enforcing policy rules based on subscription profiles, QoS parameters, and access network information. In many known approaches, the SMF provides the PCF with session-specific parameters during policy establishment. However, conventional systems do not include mechanisms to differentiate among device types — such as distinguishing an MDU from an CPE or other gateway device — within the policy signaling procedures.

[0026] Some existing methods describe session management techniques that incorporate VLAN identifiers to enable differentiated network slice provisioning, mobility-aware session updates, or dynamic VLAN bridging. However, such techniques typically rely on preconfigured network parameters and do not dynamically infer or utilize device-type-specific metadata for tailored policy handling. These solutions operate under uniform assumptions about device roles and fail to reflect variations in access characteristics or deployment-specific configurations.

[0027] Furthermore, current systems lack provisions for identifying devicetypes from the incoming session request payload, particularly when custom or nonstandard fields are used to encode such metadata. As a result, there is often no means for dynamically distinguishing MDU devices from general-purpose CPEs or broadband gateways. This limitation complicates policy enforcement, VLAN assignment, and resource allocation strategies, particularly in mixed device environments with varying performance requirements and traffic patterns.

[0028] The absence of explicit device identification mechanisms and conditional response logic hinders the ability to apply differentiated network treatment based on device roles. In high-density or multi-tenant deployment scenarios, this results in suboptimal resource distribution, inability to isolate service domains, and challenges in implementing device-specific policy enforcement. Consequently, there exists a need for enhanced mechanisms that support accurate device classification and dynamic network policy control in heterogeneous network environments.OBJECTIVES OF THE DISCLOSURE

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

[0030] An objective of the present disclosure is to provide a system and a method for configuring network policies for network devices.

[0031] Another objective of the present disclosure is to differentiate multidwelling unit (MDU) devices from other devices by extracting information from customField2 and / or customField3 included in a policy control create request.

[0032] Another objective of the present disclosure is to dynamically adapt and configure network policies and parameters based on characteristics of MDU devices indicated by the customField2 and / or the customField3.

[0033] Yet another objective of the present disclosure is to improve network performance and resource allocation while ensuring that the MDU devices receive the configurations tailored to their requirements.

[0034] Yet another objective of the present disclosure is to manage traffic for the MDU devices to appropriate virtual local area networks (VLANs) using the device type and VLAN Identifier (ID).

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

[0036] The present disclosure relates to systems and methods for network policy configuration for a network device, particularly within a communication network supporting policy-based VLAN and device-type-specific session control. The disclosure enables the dynamic inclusion of device-related parameters in policy creation responses, thereby facilitating context-aware configuration.

[0037] In an embodiment, a system is disclosed for network policy configuration for a network device. The system comprises a policy control function (PCF) including a receiving unit configured to receive a policy creation request from a session management function (SMF). The policy creation request comprises a parameter field. The system further comprises an analyzing unit configured to analyze the parameter field within the policy creation request to identify information associated with the parameter field, wherein the information comprises a device type and a virtual local area network (VLAN) identifier (ID). The system further comprises a verification unit configured to verify that the device type and the VLAN ID associated with the parameter field are not null, and a sending unit configured to, upon successful verification that the device type and the VLAN ID are not null, send a success responseto the SMF. The success response comprises the VLAN ID and the device type for configuration of a network policy for the network device.

[0038] In one embodiment, the success response comprises the VLAN ID in a header. In another embodiment, the network device is a multi-dwelling unit (MDU). In another embodiment, the SMF is configured to assign the network device to a defined VLAN based on the VLAN ID. In another embodiment, in response to verification that the device type and the VLAN ID are null, the sending unit is configured to send a response to the SMF, wherein the response does not comprise the VLAN ID and the device type.

[0039] In an embodiment, a method is disclosed for network policy configuration for a network device by a policy control function (PCF). The method comprises receiving a policy control create request from a session management function (SMF), wherein the policy creation request comprises a parameter field. The method further comprises analyzing the parameter field within the policy creation request to identify information associated with the parameter field, wherein the information comprises a device type and a VLAN ID. The method further comprises verifying that the device type and the VLAN ID associated with the parameter field are not null, and upon successful verification, sending a success response to the SMF. The success response comprises the VLAN ID and the device type for configuration of a network policy for the network device.

[0040] In one embodiment, the success response comprises the VLAN ID in a header. In another embodiment, the network device is a multi-dwelling unit (MDU). In another embodiment, the method further comprises assigning, by the SMF, the network device to a defined VLAN based on the VLAN ID. In another embodiment, the method further comprises, in response to verification that the device type and the VLAN ID are null, sending a response to the SMF, wherein the response does not comprise the VLAN ID and the device type.

[0041] In an implementation, a network device is disclosed that is communicatively coupled with a network. The coupling comprises receiving, by the network, a connection request, sending, by the network, an acknowledgment of the connection request to the network device, and transmitting a policy creation request in response to the connection. Upon receiving the policy creation request, network policy configuration of the network device is performed by the method as described above.

[0042] In another embodiment, a computer program product is disclosed comprising 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 network policy configuration. The method comprises receiving a policy control create request from a session management function (SMF), wherein the policy creation request comprises a parameter field, analyzing the parameter field to identify information comprising a device type and a VLAN ID, verifying that the device type and the VLAN ID are not null, and upon successful verification, sending a success response to the SMF. The success response comprises the VLAN ID and the device type for configuration of a network policy for the network device.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

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

[0044] FIG. 1 illustrates an exemplary network architecture for implementing a system for configuring a plurality of network policies for a network device, in accordance with an embodiment of the present disclosure.

[0045] FIG. 2A illustrates an exemplary system architecture of the system for configuring the plurality of network policies for the network device, in accordance with an embodiment of the present disclosure.

[0046] FIG. 2B illustrates an exemplary block diagram of the system for configuring the plurality of network policies for the network device, in accordance with an embodiment of the present disclosure.

[0047] FIG. 3 illustrates an exemplary flow diagram for configuring the plurality of network policies for the network device, in accordance with an embodiment of the present disclosure.

[0048] FIG. 4 illustrates an exemplary flow diagram for configuring the plurality of network policies for the network device, in accordance with an embodiment of the present disclosure.

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

[0050] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 Network Architecture102 User104 User Equipment106 Network108 System110 Policy Control Function (PCF)112 Session Management Function (SMF)114 Network Device116 Customer Premises Equipment (CPE)200A System Architecture200B Block Diagram202 Processor204 Memory206 Interface(s)208 Receiving Unit210 Extraction Unit212 Processing Unit214 Sending Unit216 Database300 Flow Diagram for configuring a plurality of network policies for a network device400 Flow Diagram for configuring a plurality of network policies for a network device500 Computer System510 External Storage Device520 Bus530 Main Memory540 Read-Only Memory550 Mass Storage Device560 Communication Ports570 ProcessorDETAILED DESCRIPTION

[0051] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any 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.

[0052] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in theart with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

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

[0054] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0055] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,”and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0056] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

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

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

[0059] Currently, multi-dwelling unit (MDU) devices in 5G networks provides high-speed internet access to residents in multi-tenant buildings. These devices include network equipment designed to extend 5G coverage and capacity to densely populated areas. A customer premises equipment (CPE) is installed in outdoor or indoor locations close to end-users. These strategic placements of the CPE ensure optimal coverage and signal strength for 5G services. The CPE serves as a gateway or access point for the 5G network and facilitates communication between the user's device and the core network infrastructure. The MDU devices have specific requirements and configurations compared to other types of devices. The MDU devices have specific requirements and configurations compared to other types of devices (e.g., CPEs, network units, routers, servers, gateways, etc.).

[0060] Therefore, there is a need for systems and methods to differentiate the MDU devices from other devices and handle them appropriately.

[0061] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by providing a system and a method for configuring network policies for a network device based on characteristics of the network device. The network device is a multi-dwelling unit (MDU). The system forconfiguring a plurality of policies for a network device is described. The system comprises a policy control function (PCF). The PCF may receive a policy control create request from a session management function (SMF). The PCF may check whether a custom field is present in the received request. In responsive to detection of the custom field in the received request, the PCF may extract information from the custom field of the received request. The information comprises a device type and a virtual local area network (VLAN) identifier (ID). The PCF may check whether fields corresponding to the extracted device type and the VLAN ID are null. In response to detecting that the fields corresponding to the extracted device type and VLAN ID are not null, the PCF may send a successful response comprising the VLAN ID in a header and the device type.

[0062] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings FIGs 1 to 4.

[0063] FIG. 1 illustrates an example of a network architecture (100) for implementing a system (108) for configuring a plurality of network policies for a network device (114), in accordance with an embodiment of the present disclosure.

[0064] As illustrated in FIG. 1, one or more user equipments (UEs) (104-1, 104- 2... 104-N) may be connected to the network (106). A person of ordinary skill in the art will understand that the one or more UEs may be collectively referred to as UEs (104) and individually referred to as a UE (104). One or more users (102-1, 102- 2... 102-N) may provide one or more requests to the end server through the network (106). A person of ordinary skill in the art will understand that the one or more users may be collectively referred to as users (102) and individually referred as a user (102).

[0065] In an embodiment, the UE (104) may include, but not be limited to, a mobile, a laptop, etc. 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 asa camera, audio aid, microphone, or keyboard. Furthermore, the UE (104) may include a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, and a mainframe computer. Additionally, input devices for receiving input from the user (102) such as a touchpad, touch-enabled screen, electronic pen, and the like may be used. 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.

[0066] The UE (104) is configured to communicate with the network (106). In an embodiment, the network (106) may include at least one of a Third Generation (3G) Network, Fourth Generation (4G) network, Fifth Generation (5G) network, 6G network, WiFi Network, Fiber to the Home (FTTx) network, or the like which provides internet service to individual or to the subscriber home. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0067] 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, one or more messages, packets, signals, waves, voltage or current levels, or the like. 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, anad hoc network, an infrastructure network, a Public Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0068] The network architecture (100) further includes a system (108). The system (108) comprises a policy control function (PCF) (110). The network architecture (100) further comprises a session management function (SMF) (112), a plurality of network devices (114), and a plurality of customer premises equipment (CPEs) (116) provided indoors or outdoors. A person of ordinary skill in the art will understand that the plurality of network devices may be collectively referred to as network devices (114) and individually referred to as a network device (114). A person of ordinary skill in the art will understand that the plurality of CPEs (116) may be collectively referred to as CPEs (116) and individually referred to as a CPE (116). In example, each of the plurality of network devices (114) may comprise a multi-dwelling unit (MDU) device. The plurality of network devices (114) and the plurality of CPEs (116) may communicate with the system (108) over the network (106).

[0069] In an aspect, the PCF (110) may receive a policy control create request (e.g., session management control create request) from the SMF (112). The policy control create request is used to initiate the creation of a policy control session (e.g., request for creation of a corresponding SM policy association with the PCF (110)) for a network device (114). The policy control create request may be a request for configuring network policies for one of the network devices (114). The PCF (110) includes a receiving unit (208) that is configured to receive the policy control create request from the SMF (112), wherein the policy control create request comprises a parameter field.

[0070] The PCF (110) comprises an analyzing unit (210) that is configured to analyze the parameter field within the policy control create request to identify information associated with the parameter field. The information comprises a devicetype and a virtual local area network (VLAN) identifier (ID). In an example, the parameter field may be represented as customField2 in the request and may include values such as “MDU-1005” where “MDU” represents the device type and “1005” represents the VLAN ID. The PCF (110) further includes a verification unit (212) that is configured to verify that the device type and the VLAN ID associated with the parameter field are not null. This verification ensures that both parameters are explicitly provided in the request for downstream policy decisions.

[0071] Upon successful verification that the device type and the VLAN ID associated with the parameter field are not null, the PCF (110) includes a sending unit (214) configured to send a success response (e.g., SM create success response) to the SMF (112). The success response comprises the device type and the VLAN ID for configuration of a network policy for the network device (114). In an embodiment, the VLAN ID is included in the header of the success response, for example, using a custom header such as “x-YYY-vlan-id.” This approach ensures that the SMF (112) is aware of the VLAN context and can assign the network device (114) to a defined VLAN accordingly.

[0072] In response to detecting that the device type and VLAN ID are null in the parameter field, the sending unit (214) of the PCF (110) is configured to send a response to the SMF (112) without including the VLAN ID and the device type. This prevents unnecessary or incorrect policy configuration when such information is unavailable. In such cases, the network device (114) may be treated as a generic device or directed to a global VLAN.

[0073] The PCF (110) may also check whether the device type corresponds to a multi-dwelling unit (MDU). Upon identifying the device type as MDU, the PCF (110) includes the MDU device type and the extracted VLAN ID in the success response to the SMF (112). This ensures that MDU devices are accurately distinguished and placed into appropriate VLAN segments. The VLAN assignment is particularly important toprevent MDU traffic from being routed through default global VLANs, which could otherwise lead to network congestion or misrouted traffic. For instance, an MDU identified with VLAN ID “1005” can be assigned to a specific tenant’s VLAN to optimize bandwidth and enforce tenant-specific QoS policies.

[0074] In an embodiment, as shown in the figure, the network device (114) is communicatively coupled with the network (106) and the network (106) may receive a connection request therefrom. Upon receipt of the connection request, the network (106) is configured to send an acknowledgment of the connection request to the network device (114). Following the acknowledgment, the network (106) transmits a policy creation request to a policy control function (PCF) (110) in response to the established connection. Upon transmitting the policy creation request, the network (106), via coordination with a session management function (SMF) (112) and the PCF (110), performs a network policy configuration of the network device (114). The network policy configuration may include parsing of embedded parameters within the policy creation request, such as a device type and a virtual local area network (VLAN) identifier (ID), determining whether these parameters are present and non-null, and selectively applying configuration logic using processing components of the PCF (110). By performing the network policy configuration after transmitting the policy creation request, the network (106) ensures that appropriate policies are dynamically applied based on contextual attributes of the network device (114), including VLAN assignment and differentiated policy treatment. For example, where the network device (114) is identified as a multi-dwelling unit (MDU), the configuration may include assigning the device to a tenant-specific VLAN and enabling quality of service (QoS) rules aligned with fixed access deployments.

[0075] By enabling the dynamic extraction, verification, and conditional transmission of the device type and VLAN ID, the system enhances the precision of policy configuration for network devices, particularly MDUs, within a 5G networkinfrastructure. These capabilities improve segmentation, traffic routing, and overall policy enforcement based on device characteristics.

[0076] FIG. 2A illustrates an example of a system architecture (200A) for configuring the plurality of network policies for the network device (114), in accordance with an embodiment of the present disclosure.

[0077] The system architecture (200 A) comprises the PCF (110) and the SMF (112). The PCF (110) may communicate with the SMF (112) via a N7 interface. The N7 interface is used for communication between the PCF (110) and the SMF (112). The N7 interface facilitates the exchange of policy and session management information to ensure that network policies are applied correctly to the user sessions.

[0078] In an aspect, the PCF (110) may receive a policy control create request for configuring the network policies for the network device (114) from the SMF (112) over the N7 interface. The policy control create request comprises a parameter field which may include custom business-specific data embedded in fields such as customField2. The PCF (110) includes a receiving unit configured to receive such a request. Upon receipt, the PCF (110) may perform an initial check to determine whether the parameter field is present and populated.

[0079] Upon detection of the parameter field, the PCF (110) may employ an analyzing unit to parse the contents of the parameter field. The parameter field comprises at least a device type and a virtual local area network (VLAN) identifier (ID). In an implementation, the device type may correspond to a multi-dwelling unit (MDU), and the VLAN ID may be used to assign the device to a service-specific or tenant-specific VLAN. For instance, the parameter field may include the value <MDU, 3012>, where “MDU” identifies the device type and 3012 is the VLAN ID allocated to the corresponding MDU.

[0080] The PCF (110) comprises a verification unit that verifies whether theextracted device type and VLAN ID are not null. This verification step ensures that both parameters are explicitly provided and valid. For example, a check is performed to confirm that the device type string is not empty and that the VLAN ID is a valid numeric value.

[0081] If the device type and VLAN ID are verified as non-null, the PCF (110) utilizes a sending unit to generate and transmit a success response to the SMF (112) over the N7 interface. The success response includes the VLAN ID embedded in a header (e.g., a custom HTTP header such as “x-YYY-vlan-id”) and the device type in the response body or metadata. This enables the SMF (112) to assign the network device (114) to the correct VLAN and apply device-specific policy rules. For instance, if the PCF (110) receives a customField2 value of <MDU, 3012>, the success response includes “x-YYY-vlan-id: 3012” and “deviceType: MDU.”

[0082] Conversely, if the parameter field is absent or if the device type and VLAN ID are null, the PCF (110) is configured to send a success response to the SMF (112) without including the VLAN ID or device type. By performing conditional inclusion based on nullity, the PCF (110) avoids unnecessary policy enrichment for devices that do not require it or where information is incomplete.

[0083] By performing the steps of extraction, validation, and selective response generation, the PCF (110) enables accurate and efficient configuration of network policies for specialized devices such as MDUs without impacting standard policy workflows for other device types.

[0084] FIG. 2B illustrates an exemplary block diagram of the system (108) for configuring the plurality of network policies for the network device (114), in accordance with an embodiment of the present disclosure.

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

[0086] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108).

[0087] The system (108) may include the PCF (110) and a database (216). The PCF (110) may include a receiving unit (208), an extraction unit (210), a processing unit (212), and a sending unit (214).

[0088] The receiving unit (208) is configured to receive a policy creation request from a session management function (SMF) (112), wherein the policy creation request comprises a parameter field. In an aspect, the policy control create request is a request that the SMF (112) sends to the PCF (110) to establish or update policy rules for a particular session or service. Further, when a new session is being set up or when there is a need to modify existing session policies, the SMF (112) may generate the policy control create request. The request is part of the signaling between the SMF(112) and the PCF (110). The parameter field may include information that helps in device-specific policy application. For example, the SMF (112) may send a policy control create request with a parameter field such as customField2 containing the value "MDU, 96".

[0089] The processing unit (212) may check whether the parameter field is present in the received policy creation request. In an aspect, the system (108) may use custom fields (e.g., customField2 and customField3) for customizing configuration and handling of the network devices (114), such as MDU devices.

[0090] The extraction unit (210) is configured to analyze the parameter field within the policy creation request to identify information associated with the parameter field, wherein the information comprises a device type and a virtual local area network (VLAN) identifier (ID). For example, customField2 may include the value \<deviceType, VLAN ID> (e.g., MDU, 96), from which the device type "MDU" and VLAN ID "96" are identified and extracted.

[0091] The processing unit (212) or the extraction unit (210) functions as a verification unit that is configured to verify that the device type and the VLAN ID associated with the parameter field are not null. The verification step ensures that these values are valid and actionable for policy enforcement. If both values are non-null and valid, the subsequent policy configuration steps are executed.

[0092] The sending unit (214) is configured to, upon successful verification that the device type and the VLAN ID associated with the parameter field are not null, send a success response to the SMF (112), wherein the success response comprises the VLAN ID and the device type for configuration of a network policy for the network device (114). For example, the VLAN ID may be included in the header of the response, and the device type (e.g., MDU) included in the body of the response.

[0093] In an implementation, the success response comprises the VLAN ID ina header. For instance, the success response may include a header field "VLAN-ID: 96" and a body field "Device-Type: MDU".

[0094] In an aspect, the network device (114) may be a multi-dwelling unit (MDU), which is deployed in multi-tenant environments to provide wireless access aggregation.

[0095] The SMF (112) is configured to assign the network device (114) to a defined VLAN based on the VLAN ID included in the success response. Upon receiving the VLAN ID = 96 in the response, the SMF (112) maps the MDU device to the VLAN segment identified by ID 96.

[0096] In response to verification that the device type and the VLAN ID are null, the sending unit (214) is configured to send a response to the SMF (112), wherein the response does not comprise the VLAN ID and the device type. This ensures that in absence of valid information, the policy remains generic and does not misclassify the device.

[0097] In an aspect, the PCF (110) may differentiate MDU devices from other network devices using the custom fields and handle MDU-specific requirements appropriately without impacting other types of network devices.

[0098] In an aspect, the database (216) is configured to store program instructions. The database (216) is configured to store the data received from the receiving unit (208), extraction unit (210), the processing unit (212), and the sending unit (214). The program instructions include a program that implements the system (108) for configuring the plurality of policies for the network device (114). The database (216) may be configured to store the policy control create request, the extracted device type and VLAN ID, and the success response. The database (216) may include any computer-readable medium known in the art including, for example, volatile memory such as Static Random Access Memory (SRAM) and DynamicRandom Access Memory (DRAM), and / or nonvolatile memory such as Read Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an aspect, the database (216) may be implemented inside the PCF (110).

[0099] Although FIG. 2B shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2B. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0100] FIG. 3 illustrates an example of a flow diagram for configuring the plurality of network policies for the network device (114), in accordance with an embodiment of the present disclosure.

[0101] At step 302, the SMF (112) may send a policy control create request (e.g., session management (SM) policy control create request) to the PCF (110). The policy control create request comprises customField2. In an aspect, the policy control create request is a request sent by the SMF (112) to the PCF (110) to create or update policy rules for a specific session of the network device (114). The policy control create request comprises customField2 with a device type and VLAN ID. The VLAN ID is added in a header. In an example, the customField2 may contain a tuple such as <MDU, 96>, wherein “MDU” refers to the device type and “96” is the VLAN identifier allocated for a tenant-specific MDU. By including these parameters, the SMF (112) provides the PCF (110) with contextual metadata necessary for differentiated policy enforcement. The customField2 enables flexible device-level classification in multitenant or high-density deployments.

[0102] At step 304, the PCF (110) may check whether the customField2 valueis present in the request. In an aspect, the PCF (110) checks whether the request comprises the customField2. The presence of customField2 is used to differentiate the MDU devices from other devices. If the request comprises customField2, then the PCF (110) may invoke policy handling logic specifically tailored for the MDU use case. For example, when the device type in customField2 is identified as MDU, the PCF (110) may select a policy template with pre-defined bandwidth guarantees, VLAN segmentation rules, and low-latency QoS indicators. By performing this differentiation, the PCF (110) ensures that only the MDU-specific policies are applied to eligible devices.

[0103] At step 306, on detecting that the customField2 is null or empty, the PCF (110) may generate a default success response (e.g., SM create success response) without including any VLAN ID or device type. The absence of these fields indicates that the network device (114) does not fall under a special handling category. Therefore, the PCF (110) may refrain from sending VLAN configuration headers, resulting in the device being handled through default policy routing. The success response is sent to the SMF (112) with no value in the header.

[0104] At step 308, on detecting that customField2 is present in the policy control create request, the PCF (110) may extract a device type and a virtual local area network (VLAN) identifier (ID) from customField2. The extraction is performed by an internal extraction unit that parses the structure of the customField2 parameter. For example, if the field contains the value <MDU, 96>, then the extracted device type is “MDU” and the VLAN ID is “96.” By performing the parsing and extraction operation, the PCF (110) prepares the request for further validation and response generation.

[0105] At step 310, the PCF (110) may check whether one or more fields corresponding to the device type and VLAN ID are null or empty. If either of the fields is found to be null, the PCF (110) may skip the enrichment process and generate a standard response without embedding the VLAN ID or device type in the message.This check ensures data completeness before applying configuration logic.

[0106] At step 312, upon detecting that both the device type and VLAN ID are valid (i.e., not null), the PCF (110) may add the device type in the success response body and the VLAN ID in a designated header field. For example, if the customField2 contains the value <MDU, 96>, then the success response may include a body field “deviceType: MDU” and a header “x-YYY-vlan-id: 96.” This allows downstream entities, including the SMF (112) and potentially other network functions, to apply VLAN-specific routing rules and session-specific enforcement policies. The SMF (112) may then assign the MDU device to VLAN 96, which may correspond to a specific multi-tenant service profile or bandwidth class.

[0107] Furthermore, upon detecting that the one or more fields corresponding to the device type and VLAN ID are null or empty, the PCF (110) may generate the success response without including the VLAN ID in the header or the device type in the response. This ensures that only qualified devices receive policy customization, and devices without appropriate attributes are not misclassified.

[0108] In an aspect, with the help of customField2 containing device type = MDU and a valid VLAN ID, the PCF (110) and the SMF (112) may dynamically adapt and configure network policies and parameters based on the specific characteristics of MDU devices. The characteristics of MDU devices may include coverage constraints, susceptibility to signal interference, high user density in shared infrastructure environments, or requirements for fixed wireless access (FWA). In particular, MDUs may serve as aggregation nodes for multiple tenant UEs, requiring consistent VLAN assignment to support per-tenant isolation and application-layer traffic engineering.

[0109] By configuring VLAN identifiers based on the received policy control create request, the SMF (112) may assign the network device (114) to a defined VLAN as described in claim 9. This ensures that traffic originating from the MDU device isrouted through a designated Layer 2 or Layer 3 segment, aligned with tenant-specific service-level agreements or bandwidth partitions.

[0110] Moreover, in cases where the customField2 is absent or where the fields within it are null, the PCF (110) may send a response to the SMF (112) without including the device type or VLAN ID, as described in claim 10. By doing so, the PCF (110) prevents the accidental application of MDU-specific policies to devices not classified as MDUs.

[0111] By incorporating validation, selective enrichment, and conditional response logic at each decision point, the flow illustrated in FIG. 3 enables robust and adaptive network policy configuration aligned with heterogeneous device roles. The overall configuration flow enables a network to maintain performance differentiation, efficient segmentation, and scalable policy enforcement across MDU and non-MDU device populations.

[0112] FIG. 4 illustrates an example of a flow diagram (400) for performing a method for configuring a network policy for a network device (114), in accordance with an embodiment of the present disclosure.

[0113] At step 402, a policy control create request is received from a session management function (SMF) (112) by a policy control function (PCF) (110), wherein the policy control create request comprises a parameter field. The parameter field may include a device-specific and session-specific data structure, such as a custom field (e.g., customField2) embedded within the request. The custom field is structured to include at least two key elements: a device type and a virtual local area network (VLAN) identifier (ID). In some implementations, the custom field may be encoded as a delimited string, JSON object, or vendor- defined IE (Information Element) embedded in a standard NAS or N7 message. For example, the parameter field may carry the value “deviceType=MDU;vlanId=96” or a JSON object {"deviceType":"MDU", "vlanld": "96"}. The reception of the policy control create request triggers the evaluation process for configuring differentiated network policies based on device context.

[0114] At step 404, the parameter field within the policy control create request is analyzed to identify the information associated with the parameter field. The information comprises a device type and a VLAN ID. The device type may indicate, for example, a multi-dwelling unit (MDU), and the VLAN ID may specify the VLAN to which the network device (114) is to be logically assigned. The PCF (110) uses an extraction unit (210) to parse the parameter field. For instance, when the custom field includes the value “MDU, 96”, the extraction operation separates the string based on a delimiter (e.g., comma) and interprets the first token as “MDU” and the second token as the VLAN ID “96”. In another example, if the custom field contains a nested structure like “type=MDU;vlan=201;zone=EastWing”, the system (108) may extract “MDU” as the device type and “201” as the VLAN ID, while other non-essential attributes are ignored during policy determination. This parsing step enables the system (108) to handle diverse device types and assign VLANs dynamically for session management and QoS enforcement.

[0115] At step 406, the extracted device type and the VLAN ID are verified to ensure that neither of the values is null. This verification step is performed by a processing unit (212) to ensure that both fields are valid and can be used to proceed with policy configuration. A null or empty device type or VLAN ID indicates either an improperly formed request or a generic device not requiring differentiated handling. In such cases, the PCF (110) may default to generic policy application logic. For example, if the parameter field received is “vlanId=103” but the device type is missing, the PCF (110) may proceed without triggering MDU-specific configurations and return a basic SM policy response omitting the VLAN header enrichment.

[0116] At step 408, upon successful verification that the device type and theVLAN ID associated with the parameter field are not null, a success response is sent to the SMF (112). The success response comprises the VLAN ID embedded in a header and the device type included in the message body or metadata. For example, if the extracted values are “MDU” and “96”, the success response includes a header “x-YYY- vlan-id: 96” and a body field “deviceType: MDU”. In another implementation, the success response may be encoded in an N7 SMPolicyControlCreateResponse message where custom parameters are mapped to standardized AVPs (Attribute Value Pairs) or vendor-specific extensions. The SMF (112) uses this information to assign the network device (114) to the appropriate VLAN and apply device-specific policies, such as quality of service parameters, bandwidth slicing, or access control rules. For instance, a device tagged as MDU may be assigned to VLAN 96, which is pre-configured with elevated bandwidth guarantees and latency thresholds suitable for multi-user aggregation nodes. By including the VLAN ID and device type in the success response, the system (108) ensures accurate enforcement of configuration policies aligned with the operational role of the network device (114).

[0117] The flow diagram (400) enables dynamic and context-aware network policy configuration for specialized device types such as MDUs. The method enhances network performance by allowing granular control based on device classification and VLAN segmentation. For example, in a building with multiple access points, identifying the device as MDU ensures that it is grouped with similarly provisioned devices in VLAN 96, while standard residential gateways may be grouped under VLAN 10 with standard policies. By performing conditional parsing, validation, and enrichment of policy responses based on device-type metadata, the system (108) improves policy accuracy, traffic engineering flexibility, and operational scalability.

[0118] FIG. 5 illustrates an exemplary computer system (500) in which or with which embodiments of the present disclosure may be implemented.

[0119] As shown in FIG. 5, the computer system (500) may include an externalstorage device (510), a bus (520), a main memory (530), a read-only memory (540), a mass storage device (550), communication port(s) (560), and a processor (570). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. The processor (570) may include various modules associated with embodiments of the present disclosure. The communication port(s) (560) 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) (560) 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 connects.

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

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

[0122] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (520) 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) (560). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.

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

[0124] The present disclosure provides a method and a system for configuring network policies for multi-dwelling unit (MDU) devices in a communication network based on device-specific attributes such as device type and VLAN identifier. By incorporating custom parameter fields, such as customField2 and customField3, within the policy control create request, the system enables dynamic identification and classification of MDU devices. The extracted parameters are used to tailor network policy responses that reflect the operational requirements of the MDU device type, thereby enabling precise traffic management and differentiated policy enforcement.

[0125] The present disclosure provides a method and a system for assigning VLANs dynamically to MDU devices during session establishment by embeddingVLAN identifiers in both the policy control create request and the success response. This allows the session management function (SMF) to map the network device to a defined VLAN based on instructions from the policy control function (PCF), ensuring optimal allocation of logical network segments. As a result, network traffic associated with the MDU devices is routed appropriately, avoiding default VLAN congestion and enabling isolated and manageable service delivery.

[0126] The present disclosure provides a method and a system for achieving efficient resource utilization and network segmentation by incorporating VLAN ID information in structured policy signaling. By using structured custom fields to convey VLAN assignments and device classification, the system ensures that MDU devices are grouped according to their access and performance characteristics, facilitating quality-of-service (QoS) enforcement and capacity planning within high-density or tenant-segregated environments.

[0127] The present disclosure provides a method and a system for enabling customized handling of specialized network devices, such as MDUs, without requiring changes to existing network infrastructure for other device types. The solution ensures that policy customization is selectively applied based on the presence and validity of device type and VLAN identifiers, thereby isolating MDU-specific logic from the default policy path. This minimizes the overhead on general-purpose devices and maintains architectural compatibility with standard session management workflows.

[0128] The present disclosure provides a method and a system for supporting scalable network deployments in multi-tenant and high-user-density scenarios, by enabling the policy control function to infer, parse, validate, and apply context-aware configurations at the time of policy session creation. This adaptive configuration framework enhances network agility, reduces static provisioning effort, and supports advanced use cases such as fixed wireless access (FWA) through intelligent classification and response logic tailored to device roles like MDUs.

Claims

CLAIMS1. A system (108) for network policy configuration for a network device (114), the system comprising a policy control function (PCF) (110), the PCF (110) comprising: a receiving unit (208) configured to receive a policy creation request from a session management function (SMF) (112), wherein the policy creation request comprises a parameter field; an analyzing unit (210) configured to analyze the parameter field within the policy creation request to identify information associated with the parameter field, wherein the information comprises a device type and a virtual local area network (VLAN) identifier (ID); a verification unit (212) configured to verify that the device type and the VLAN ID associated with the parameter field are not null; and a sending unit (214) configured to, upon successful verification that the device type and the VLAN ID associated with the parameter field are not null, send a success response to the SMF (112), wherein the success response comprises the VLAN ID and the device type for configuration of a network policy for the network device (114).

2. The system (108) as claimed in claim 1, wherein the success response comprises the VLAN ID in a header.

3. The system (108) as claimed in claim 1, wherein the network device (114) is a multi-dwelling unit (MDU).

4. The system (108) as claimed in claim 1, wherein the SMF (112) is configured to assign the network device (114) to a defined VLAN based on the VLAN ID.

5. The system (108) as claimed in claim 1, wherein in response to verification that the device type and the VLAN ID are null, the sending unit (214) is configured to send a response to the SMF (112), wherein the response does not comprise the VLAN ID and the device type.

6. A method (400) for network policy configuration for a network device (114) by a policy control function (PCF) (110), the method comprising: receiving (402) a policy control create request from a session management function (SMF) (112), wherein the policy creation request comprises a parameter field; analyzing (404) the parameter field within the policy creation request to identify information associated with the parameter field, wherein the information comprises a device type and a virtual local area network (VLAN) identifier (ID); verifying (406) that the device type and the VLAN ID associated with the parameter field are not null; and upon successful verification that the device type and the VLAN ID associated with the parameter field are not null, sending (408) a success response to the SMF (112), wherein the success response comprises the VLAN ID and the device type for configuration of a network policy for the network device (114).

7. The method (400) as claimed in claim 6, wherein the success response comprises the VLAN ID in a header.

8. The method (400) as claimed in claim 6, wherein the network device (114) is a multi-dwelling unit (MDU).

9. The method (400) as claimed in claim 6, further comprising: assigning, by the SMF (112), the network device (114) to a defined VLAN based on the VLAN ID.

10. The method (400) as claimed in claim 6, further comprising: in response to verification that the device type and the VLAN ID are null, sending a response to the SMF (112), wherein the response does not comprise the VLAN ID and the device type.

11. A network device (114) communicatively coupled with a network (106), the coupling comprising: receiving, by the network (106), a connection request; sending, by the network (106), an acknowledgment of the connection request to the network device (114); and transmitting a policy creation request in response to the connection, wherein upon receiving the policy creation request, performing network policy configuration of the network device (114) by a method (400) as claimed in claim 6.

12. A computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method for network policy configuration for a network device by a policy control function (PCF), the method comprising: receiving a policy control create request from a session management function (SMF), wherein the policy creation request comprises a parameter field;analyzing the parameter field within the policy creation request to identify information associated with the parameter field, wherein the information comprises a device type and a virtual local area network (VLAN) identifier (ID); verifying that the device type and the VLAN ID associated with the parameter field are not null; and upon successful verification that the device type and the VLAN ID associated with the parameter field are not null, sending a success response to the SMF, wherein the success response comprises the VLAN ID and the device type for configuration of a network policy for the network device.

Images