Managing traffic differentiation for non-3GPP devices in a communication network

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present invention discloses a method and a network apparatus for managing traffic differentiation for non-3GPP devices connected behind 5G-RG / UE in a communication network. The method involves the first network apparatus receiving a protocol data unit (PDU) session request message including non-3GPP device identifiers from UE / 5G-RG. Further, the method includes sending by the first network apparatus the non-3GPP device identifiers to a second network apparatus to retrieve a Quality of Service (QoS) policy and determining the availability of the QoS policy in the Unified Data Repository (UDR) through the second network apparatus for corresponding non-3GPP device identifiers. Furthermore, the method includes rejecting by the first network apparatus the PDU session request in response to receiving a reject indication with reason from the second network apparatus.

Description

MANAGING TRAFFIC DIFFERENTIATION FOR NON-3GPP DEVICES IN A COMMUNICATION NETWORK

[0001] The present application pertains to the field of wireless communication, and more specifically, it relates to the management of traffic differentiation for non-3rd Generation Partnership Project (3GPP) devices connected behind a fifth-generation (5G) residential gateway (RG) or User Equipment (UE) within a communication network.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] The principal object of the invention herein is to provide a method and a network apparatus for managing traffic differentiation for non-3GPP devices connected behind 5G-RG or UE in a communication network.

[0009] Another object of the invention herein is to provide an SMF that receives the PDU session request with a non-3GPP device identifier and provides the device identifiers to PCF to get the updated policy rules.

[0010] Yet another object of the invention herein is to provide a PCF that contacts a UDR by providing the device identifier to receive the device profile details.

[0011] Yet another object of the invention herein is to provide a UDR that informs that the profiles are not present for the device identifier.

[0012] Yet another object of the invention herein is to provide a PCF that indicates to SMF that profiles are not present for the device identifier.

[0013] Yet another object of the invention herein is to provide an SMF that rejects the PDU session and provides an appropriate cause.

[0014] Yet another object of the invention herein is to provide a UE that does not trigger PDU Session using the same non-3GPP device identifier unless it gets updated information from AF.

[0015] In an aspect, the objects are achieved by providing a method for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE in a communication network. The method includes receiving by a first network apparatus a protocol data unit (PDU) session request message from the UE or 5G-RG. The PDU session request message includes non-3GPP device identifiers. Further, the method includes sending by the first network apparatus the non-3GPP device identifiers to a second network apparatus to determine a Quality of Service (QoS) policy and determining by the first network apparatus the availability of the QoS policy in the UDR through the second network apparatus for the corresponding non-3GPP device identifiers. Furthermore, the method includes rejecting by the first network apparatus the PDU session request in response to receiving a reject indication with reason from the second network apparatus where the reject indication with reason indicates that the QoS policy is not present for the non-3GPP device identifier in the UDR.

[0016] In another aspect, the objects are achieved by providing a method for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE in a communication network. The method includes receiving by a second network apparatus a non-3GPP device identifier from a first network apparatus and determining by the second network apparatus the availability of the QoS policy in the UDR for the corresponding non-3GPP device identifiers. Further, the method includes performing by the second network apparatus one of responding by sending a reject indication with reason to the first network apparatus where the QoS policy is not present for the non-3GPP device identifier in the UDR or proceeding with the PDU session with a default QoS without providing the traffic differentiation.

[0017] In yet another aspect, the objects are achieved by providing a first network apparatus for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE in a communication network. The first network apparatus includes a first processor, a first memory, and a first service controller connected to the first processor and the first memory. The first service controller receives a PDU session request message from the UE or 5G-RG. The PDU session request message includes non-3GPP device identifiers. The first service controller further sends the non-3GPP device identifiers to a second network apparatus to determine a QoS policy and determines the availability of the QoS policy in the UDR through the second network apparatus for the corresponding non-3GPP device identifiers. Furthermore, the first service controller rejects the PDU session request in response to receiving a reject indication with reason from the second network apparatus where the reject indication with reason indicates that the QoS policy is not present for the non-3GPP device identifier in the UDR.

[0018] In yet another aspect, the objects are achieved by providing a second network apparatus for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE in a communication network. The second network apparatus includes a second processor, a second memory, and a second service controller connected to the second processor and the second memory. The second service controller receives non-3GPP device identifiers from a first network apparatus and determines the availability of the QoS policy in the UDR for the corresponding device identifiers. Further, the second service controller performs one of responding by sending a reject indication with reason to the first network apparatus where the QoS policy is not present for the non-3GPP device identifier or proceeding with the PDU session with a default QoS without providing the traffic differentiation.

[0019] These and other aspects of the embodiments will be better understood with the following description and accompanying drawings. The descriptions, while indicating preferred embodiments and specific details, are for illustration and not limitation. Many changes and modifications can be made within the scope of the embodiments, which include all such modifications.

[0020] According to the present disclosure, unnecessary signaling traffic can be reduced and network resources can be managed efficiently, by having the SMF reject a PDU session request with an appropriate cause and a back-off timer when device profiles for a corresponding non-3GPP device identifier are not present in the UDR.

[0021] The invention is illustrated in the accompanying drawings, where like reference letters indicate corresponding parts. The embodiments will be better understood from the following description with reference to the drawings.

[0022] FIG. 1 is a block diagram that illustrates the hardware components associated with the first network apparatus according to the embodiments as disclosed herein.

[0023] FIG. 2 is a block diagram that illustrates the hardware components associated with the second network apparatus according to the embodiments as disclosed herein.

[0024] FIG. 3 is a flow diagram that illustrates a proposed method for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE in a communication network by a first network apparatus according to the embodiments as disclosed herein.

[0025] FIG. 4 is a flow diagram that illustrates a proposed method for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE in a communication network by a second network apparatus according to the embodiments as disclosed herein.

[0026] FIG. 5 is a sequence diagram that illustrates a method of provisioning of device identifier to 5GC and UE or 5G-RG according to the embodiments as disclosed herein.

[0027] FIG. 6 is a sequence diagram that illustrates a method of PDU session handling when device identifier policy is not present in the network according to the embodiments as disclosed herein.

[0028] The Fifth Generation System (5GS) represents a significant advancement in mobile communication technology, offering enhanced user experiences, optimized performance, and the ability to provide services to devices and users outside of the operator's 3GPP network. One of the key features proposed for the 5GS is the creation and utilization of user-specific identities, which can enable operators to tailor network settings and services to individual users' needs. This approach diverges from traditional methods where the subscription identifier is primarily used to establish connections.

[0029] In the context of 5GS, the user-specific identities can refer to various entities such as individual human users utilizing User Equipment (UE) with specific subscriptions, applications running on or connecting via a UE, or devices like Personal Internet of Things Network Elements (PINE) behind a gateway UE, such as a PIN Element with a Gateway Capability (PEGC). These use cases have been explored extensively, and solutions have been proposed, particularly in Technical Report (TR) 23700-32, which outlines how device identifiers are communicated by the UE / 5G Residential Gateway (5G-RG) to the network when non-3GPP devices are connected and require traffic differentiation.

[0030] Currently, device identifiers play a crucial role in traffic differentiation. When non-3GPP devices connect via UE / 5G-RG, the UE / 5G-RG assigns a device identifier to each device for traffic differentiation purposes. The UE / 5G-RG, based on the UE Route Selection Policy (URSP) rule that includes the device identifier, sends this identifier during Protocol Data Unit (PDU) session establishment or modification. Subsequently, the Session Management Function (SMF) and Policy Control Function (PCF) use these device identifiers to retrieve Quality of Service (QoS) policies from the Unified Data Repository (UDR) and provide traffic differentiation for each device.

[0031] However, several challenges persist with the existing methods. One notable issue arises when the SMF or PCF provides the device identifier to the UDR, but no QoS policy is available for those device identifiers. Additionally, while the binding of device identifiers to each device by the UE / 5G-RG is left to implementation, there is a need for defined solutions to ensure the PCF can add the device identifier in the URSP and make the device identifier available at the UE / 5G-RG.

[0032] Thus, it is desired to address the above-mentioned disadvantages or other shortcomings or at least provide a useful alternative.

[0033] The embodiments and their features are detailed with reference to the non-limiting examples shown in the drawings and described below. Well-known components and techniques are omitted to avoid unnecessary detail. The described embodiments are not mutually exclusive and can be combined to form new embodiments. The term "or" is used in a non-exclusive sense unless stated otherwise. The examples provided are for illustrative purposes to aid understanding and should not be seen as limiting the scope of the embodiments.

[0034] As is existing in the field, embodiments can be described and illustrated in terms of blocks which carry out a described function or functions.　These blocks, which can be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and can optionally be driven by firmware and software. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block can be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block.　Each block of the embodiments can be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.　Likewise, the blocks of the embodiments can be physically combined into more complex blocks without departing from the scope of the disclosure.

[0035] The drawings help illustrate the technical features but do not limit the embodiments. The disclosure includes any modifications, equivalents, and substitutes beyond those shown. Terms like first, second, etc., are used for distinction and do not limit the elements.

[0036] A requirement exists in 3GPP where multiple non-3GPP devices connected behind a UE / 5G-RG need traffic differentiation based on their needs. To address this requirement, some device profile details will be configured in the 5GC. In scenarios where the UE has already triggered a PDU session on behalf of non-3GPP devices to achieve traffic differentiation, but the corresponding profiles are missing, the handling is addressed in this proposed solution.

[0037] Embodiments disclosed herein provide a network apparatus and a method for providing services based on device identifiers. The method includes identifying a non-3GPP device connected behind a UE / 5G-RG and providing services based on the device identifier. A PCF adds the device identifier in a URSP and makes the device identifier available at the UE / 5G-RG.

[0038] In an embodiment, the terms PCF and Session Management Policy Control Function (SM-PCF) means the same and can be used interchangeably, if not specified otherwise (i.e. in the case of AMF, it is AM-PCF), otherwise it is SM-PCF or PCF.

[0039] Consider a scenario where non-3GPP devices are connected via a UE / 5G-RG, which needs traffic differentiation. To address this, the UE / 5G-RG binds these devices with unique device identifiers. Whenever these devices send traffic, the UE / 5G-RG adds the corresponding device identifier for the devices and sends it to the network. The list of device identifiers can be provisioned by the operator or Application Function (AF) to the 5GC, or such as UDM, PCF, or another Network Function (NF). Additionally, the UE / 5G-RG can be pre-configured with a list of device identifiers. During registration, the UE / 5G-RG may indicate support for traffic differentiation in the 5GMM capability indication to the Access Management Function (AMF). The AMF then provides an updated list of device identifiers to the UE / 5G-RG, which the AMF receives from the UDM. The AMF updates this list during the UE configuration update procedure to the UE / 5G-RG, and the UE / 5G-RG updates the received list.

[0040] The present invention provides a method and a network apparatus for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or UE in a communication network. In the proposed invention, the SMF, after receiving the PDU session request from the UE / 5G-RG with a non-3GPP device identifier to provide traffic differentiation, contacts the PCF. Upon notification from the PCF that device profiles are not present in the UDR, the SMF rejects the session and provides the appropriate cause to the UE.

[0041] The SMF receives the PDU session request with the non-3GPP device identifier and provides the device identifiers to the PCF to get the updated policy rules. The PCF contacts the UDR by providing the device identifier to receive the device profile details. The UDR informs that the profiles are not present for the device identifier.

[0042] The PCF indicates to the SMF that profiles are not present for the device identifier. Further, the SMF rejects the PDU session and provides an appropriate cause. The UE does not trigger using the same non-3GPP device identifier until it gets updated information from the AF.

[0043] Referring now to the drawings, and more particularly to FIGS. 1 through 6 where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

[0044] FIG. 1 is a block diagram illustrating the hardware components associated with the first network apparatus (100) according to the embodiments disclosed herein. The first network apparatus (100) corresponds to a Session Management Function (SMF) (604).

[0045] Examples of the first network apparatus (100) include, but are not limited to, Base Stations (such as macro cells, small cells, femtocells, picocells, etc.) for wireless communication, Antennas and RF Units (e.g., MIMO, beamforming) to enhance signal coverage and data throughput, Core Network Equipment (e.g., MMEs, S-GWs, P-GWs in 4G, AMFs, UPFs in 5G) for data routing, mobility, and session control, Network Function Virtualization (NFV) and Software-Defined Networking (SDN) for dynamic resource allocation and scalability, Edge Computing Nodes (e.g., MEC servers) for low-latency processing, Backhaul and Transport Equipment (e.g., fiber-optic links, microwave relays, Ethernet switches) to connect base stations to the core network, Network Management Systems (NMS) and Operation Support Systems (OSS) for network configuration, fault management, and optimization, Radio Network Controllers (RNCs) in 3G, Distributed Units (DUs) and Centralized Units (CUs) in 5G, Network Slicing Components for virtualized resource allocation, and Security elements (e.g., Firewalls, IDS, AAA Servers) for secure communication.

[0046] Examples of the UE (602) can include, but are not limited to, Consumer Electronics (such as Mobile Phones and Smartphones), Tablets, Wearable Devices, Computing Devices (such as Laptops, Notebooks, Desktops, Workstations, etc.), IoT Devices, Automotive Systems (such as connected cars, Autonomous Vehicles, Vehicle-to-Everything (V2X) communication devices, etc.), Enterprise Devices such as robotics, Specialized Equipment (such as Medical Devices, Public Safety Devices, etc.), and Media Devices (such as Gaming Consoles, Streaming Devices, etc.). Examples of the 5G-RG (602) include modem-router combos, standalone gateways, fiber optic gateways, 5G or long term evolution (LTE) gateways, digital subscriber line (DSL) gateways, IoT gateways, and the like.

[0047] In an embodiment illustrated in FIG. 1, the first network apparatus (100) includes a first processor (101), a first memory (102), a first communicator (103), and a first service controller (104). The first processor (101) manages traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network. Communication between the first processor (101), the first memory (102), the first communicator (103), and the first service controller (104) is facilitated by the first processor (101). The first processor (101) executes instructions stored in the first memory (102) and manages traffic differentiation for non-3GPP devices. The first processor (101) may include one or a plurality of processors, such as a Central Processing Unit (CPU), an Application Processor (AP), a Graphics Processing Unit (GPU), a Visual Processing Unit (VPU), and / or a Neural Processing Unit (NPU).

[0048] The first memory (102) stores the operating system, application software, and temporary data used by the first processor (101). Instructions to be executed by the first processor (101) are stored in the first memory (102). The first memory (102) is not limited to volatile memory and / or non-volatile memory and may include a plurality of computer-readable storage media. Non-volatile storage elements, such as magnetic hard disks, optical disks, floppy disks, flash memories, EPROM, or EEPROM memories, may be included in the first memory (102). In some examples, the first memory (102) may be considered a non-transitory storage medium, indicating that it is not embodied in a carrier wave or a propagated signal, but not necessarily non-movable. The first memory (102) stores the PDU session request message received from the UE or 5G-RG (602), which includes non-3GPP device identifiers.

[0049] The first communicator (103) facilitates communication between the UE or 5G-RG (602) and the first network apparatus (100), supporting various communication protocols such as Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), and second generation Digital Video Broadcasting by Satellite (DVB-S2). Internal communication between hardware components via one or more networks is also facilitated by the first communicator (103). An electronic circuit specific to a standard that enables wired or wireless communication is included in the first communicator (103). The first communicator (103) receives a PDU session request message, including the non-3GPP device identifiers from the UE or 5G-RG (602), and sends the non-3GPP device identifiers to a second network apparatus (200) to retrieve a QoS policy.

[0050] In an embodiment, the first service controller (104) is a hardware component to manage traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network. This hardware implementation ensures efficient and reliable execution of processes integral to managing traffic differentiation for non-3GPP devices.

[0051] The first service controller (104) features an innovative integrated circuit structure with a multi-core architecture tailored to optimize managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network. Each core within the architecture is specifically designed to execute distinct functions.

[0052] In an embodiment, the first service controller (104) receives a PDU session request message from the UE or 5G-RG (602). The PDU session request message includes non-3GPP device identifiers. Non-3GPP devices refer to devices that do not operate on traditional 3GPP standards. For example, non-3GPP devices include, but are not limited to, Internet of Things (IoT) sensors, smart home appliances, or other types of networked equipment.

[0053] In an embodiment, the first service controller (104) sends the non-3GPP device identifiers to a second network apparatus (200) to determine a QoS policy and determines the availability of the QoS policy in the UDR (608) through the second network apparatus (200) for the corresponding non-3GPP device identifiers.

[0054] In another embodiment, the first service controller (104) rejects the PDU session request in response to receiving a reject indication with reason from the second network apparatus (200) where the reject indication with reason indicates that the QoS policy is not present for the non-3GPP device identifier in the UDR (608). Further, the first service controller (104) proceeds with the PDU session request upon receiving a default QoS policy without providing the traffic differentiation. When the PDU session request is rejected, the first service controller (104) initiates a back-off timer to the UE or 5G-RG (602) and prevents the UE or 5G-RG (602) from initiating another PDU session with the same non-3GPP device identifier until the back-off timer expires.

[0055] FIG. 2 is a block diagram illustrating the hardware components associated with the second network apparatus (200) according to the disclosed embodiments. The second network apparatus (200) corresponds to a Session Management Policy Control Function (SM-PCF) (606).

[0056] Examples of the second network apparatus (200) include, but are not limited to, Base Stations (such as macro cells, small cells, femtocells, picocells, etc.) for wireless communication, Antennas and RF Units (e.g., MIMO, beamforming) to enhance signal coverage and data throughput, Core Network Equipment (e.g., MMEs, S-GWs, P-GWs in 4G, AMFs, UPFs in 5G) for data routing, mobility, and session control, Network Function Virtualization (NFV) and Software-Defined Networking (SDN) for dynamic resource allocation and scalability, Edge Computing Nodes (e.g., MEC servers) for low-latency processing, Backhaul and Transport Equipment (e.g., fiber-optic links, microwave relays, Ethernet switches) to connect base stations to the core network, Network Management Systems (NMS) and Operation Support Systems (OSS) for network configuration, fault management, and optimization, Radio Network Controllers (RNCs) in 3G, Distributed Units (DUs) and Centralized Units (CUs) in 5G, Network Slicing Components for virtualized resource allocation, and Security elements (e.g., Firewalls, IDS, AAA Servers) for secure communication.

[0057] In an embodiment illustrated in FIG. 2, the second network apparatus (200) includes a second processor (201), a second memory (202), a second communicator (203), and a second service controller (204).

[0058] The second processor (201) manages traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network. It communicates with the second memory (202), the second communicator (203), and the second service controller (204). Configured to execute instructions stored in the second memory (202), the second processor (201) may include one or a plurality of processors, such as a general-purpose processor (e.g., CPU, AP), a graphics-only processing unit (e.g., GPU, VPU), and / or an AI dedicated processor (e.g., NPU).

[0059] The second memory (202) stores the operating system, application software, and temporary data used by the second processor (201). It also stores instructions to be executed by the second processor (201). The second memory (202) is not limited to volatile memory and / or non-volatile memory and may include a plurality of computer-readable storage media. Non-volatile storage elements, such as magnetic hard disks, optical disks, floppy disks, flash memories, or forms of EPROM or EEPROM memories, may be included. Additionally, the second memory (202) may be considered a non-transitory storage medium, indicating it is not embodied in a carrier wave or a propagated signal, but not necessarily non-movable. The second memory (202) stores the non-3GPP device identifiers received from the first network apparatus (100).

[0060] The second communicator (203) facilitates communication between the first network apparatus (100) and the second network apparatus (200), supporting various communication protocols such as TCP / IP, UDP, and DVB-S2. It is configured for internal communication between hardware components via one or more networks. The second communicator (203) includes an electronic circuit specific to a standard that enables wired or wireless communication and facilitates receiving non-3GPP device identifiers from the first network apparatus (100).

[0061] In an embodiment, the second service controller (204) is a hardware component engineered to manage traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network. This hardware implementation ensures efficient and reliable execution of processes integral to managing traffic differentiation for non-3GPP devices.

[0062] Featuring an innovative integrated circuit structure with a multi-core architecture, the second service controller (204) is tailored to optimize managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network. Each core within the architecture is specifically designed to execute distinct functions.

[0063] In an embodiment, the second service controller (204) receives non-3GPP device identifiers from the first network apparatus (100). This process includes one or more of a session management (SM) policy association establishment message and an SM policy association modification message.

[0064] The second service controller (204) determines the availability of the QoS policy in the UDR (608) for the corresponding device identifiers. If the QoS policy is not present for the non-3GPP device identifier, the second service controller (204) either proceeds with the PDU session with a default QoS without providing traffic differentiation, or it responds by sending a reject indication with a reason to the first network apparatus (100).

[0065] FIG. 3 is a flow diagram that illustrates a proposed method for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network by a first network apparatus (100) according to the embodiments as disclosed herein. At step 301, the method includes receiving by the first network apparatus (100) a PDU session request message from the UE or 5G-RG (602). The PDU session request message includes non-3GPP device identifiers. Further, the PDU session request message includes one or more of a PDU session establishment request message and a PDU session modification request message. For example, the PDU session request message can also include additional parameters such as the requested QoS characteristics, session type, and priority level, which are essential for determining the appropriate handling of the session. At step 302, the method includes sending by the first network apparatus (100) the non-3GPP device identifiers to a second network apparatus (200) to retrieve a QoS policy. For example, the transmission of non-3GPP device identifiers can be accompanied by metadata that specifies the context of the request, such as the current network conditions and the device's capabilities. At step 303, the method includes determining by the first network apparatus (100) the availability of the QoS policy in the UDR (608) through the second network apparatus (200) for the corresponding non-3GPP device identifiers. At step 304, the method includes rejecting the PDU session request in response to receiving a reject indication with reason from the second network apparatus (200) when the reject indication with reason indicates that the QoS policy is not present for the non-3GPP device identifier in the UDR (608). Further, the method includes proceeding by the first network apparatus (100) with the PDU session request upon receiving a default QoS policy without providing the traffic differentiation. Furthermore, the method includes the first network apparatus (100) initiating a back off timer to the UE or 5G-RG (602) when the PDU session request is rejected with appropriate cause and refraining the UE or 5G-RG (608) to not initiate another PDU session with the same non-3GPP device identifier for which PDU session is rejected by the first network apparatus (100) until the back off timer is expired. The back off timer mechanism may be dynamically adjusted based on network load and historical data to optimize network performance and reduce congestion.

[0066] FIG. 4 is a flow diagram that illustrates a proposed method for managing traffic differentiation for non-3GPP devices connected behind a 5G-RG or a UE (602) in a communication network by a second network apparatus (200) according to the embodiments as disclosed herein. At step 401, the method includes receiving by the second network apparatus (200) non-3GPP device identifiers from the first network apparatus (100) including one or more of SM policy association establishment message and a SM policy association modification message. The received identifiers are processed to verify their authenticity and integrity before further actions are taken. At step 402, the method includes determining by the second network apparatus (200) the availability of the QoS policy in the UDR (608) for the corresponding non-3GPP device identifiers. At step 403, the method includes performing by the second network apparatus (200) one of responding by sending a reject indication with reason to the first network apparatus (100) when the QoS policy is not present for the non-3GPP device identifier in the UDR (or) proceeding the PDU session with a default QoS without providing the traffic differentiation.

[0067] In an embodiment, the first network apparatus (100) includes a SMF and the second network apparatus (200) includes a SM-PCF. The SMF is responsible for managing the PDU sessions, including their establishment, modification, and release, while the SM-PCF handles the policy control aspects, ensuring that the sessions adhere to the predefined QoS policies and other regulatory requirements.

[0068] FIG. 5 is a sequence diagram that illustrates a method of provisioning of the device identifier to the 5GC and the UE / 5G-RG (502) according to the embodiments as disclosed herein. At step 1, the UE / 5G-RG (502) is pre-configured with a list of the device identifiers. This pre-configuration can be achieved through a secure bootstrapping process where the device identifiers are embedded into the firmware of the UE / 5G-RG (502). At step 2a, the AF (510) provisions the list of device identifiers for the UE / 5G-RG to the UDM. This provisioning can be done using a secure API call that ensures the integrity and confidentiality of the device identifiers during transmission. At step 2b, the AF (510) provisions the list of device identifiers for the UE / 5G-RG (502) to the PCF (506) via NEF. The NEF acts as a mediator that translates the application-level provisioning requests into network-level configurations. At step 3, the UE / 5G-RG (502) sends a registration request to the AMF (504). This registration request includes the device identifiers and other necessary authentication credentials. At step 4, the AMF (504) downloads the subscription profile for the UE / 5G-RG (502), which includes the list of device identifiers. The subscription profile is retrieved from the UDM and contains all the necessary policies and configurations for the UE / 5G-RG (502). At step 5, the PCF (506) is pre-configured with a list of device identifiers for the UE / 5G-RG (502). This pre-configuration can be done through an OAM system that allows network operators to manage device identifiers centrally. At step 6, the AMF (504) creates an AMF policy and provides the device identifiers for the UE / 5G-RG (502). This policy is used to enforce network-level rules and QoS parameters for the UE / 5G-RG (502). At step 7, the AMF (504) sends a registration accept to the UE / 5G-RG (502) with an updated list of device identifiers. This acceptance message confirms the successful registration and provisioning of the device identifiers. At step 8, the PCF (506) uses the available device identifier info from step 2b or step 5 or step 6 to construct the URSP and add the device identifiers while sending the URSP to the PCF (506). The URSP is a policy rule set that dictates how the network should handle traffic from the UE / 5G-RG (502) based on the device identifiers.

[0069] In an embodiment, the AF (510) can provision the list of the device identifiers per UE / 5G-RG (502) to the PCF (506) for the UE (502). This can be done through a secure API that ensures the integrity and confidentiality of the device identifiers during transmission. Also, the PCF (506) for the UE (502) can be locally configured or provisioned using Operations Administration and Maintenance (OAM) about the device identifiers. The OAM system allows network operators to manage and update device identifiers centrally, ensuring that the PCF (506) always has the latest information. The PCF (506) uses this information for constructing the URSP by adding the device identifiers while sending the URSP to the UE / 5G-RG (502). The URSP is a policy rule set that dictates how the network should handle traffic from the UE / 5G-RG (502) based on the device identifiers.

[0070] FIG. 6 is a sequence diagram that illustrates a method of PDU session handling when the device identifier policy is not present in the network according to the embodiments as disclosed herein. At step 1, the AF (610) provisions QoS policies for the device identifiers. This provisioning can be done through a secure API that ensures the integrity and confidentiality of the QoS policies during transmission. At step 2, the UE / 5G-RG (602) sends a PDU session request to the SMF (604) by adding the device identifier when one of the non-3GPP devices sends some traffic which needs traffic differentiation. The PDU session request includes the device identifier and other necessary parameters for establishing the session. At step 3a, the SMF (604) downloads the QoS policy using the device identifier and provides the traffic differentiation directly from UDR (608) (i.e. by passing SM-PCF (606)). The QoS policy is retrieved from the UDR (608) and contains all the necessary parameters for traffic differentiation. At step 3b, the SMF (604) may reject the PDU or proceed with the PDU with default QoS when the UDR (608) informs that there is no QoS for the device identifier. The decision to reject or proceed with default QoS is based on operator policy. At step 4, the SMF (604) creates / modifies the SM policy by providing the device identifier. This policy is used to enforce network-level rules and QoS parameters for the PDU session. At step 5a, the PCF (606) downloads the QoS policy using the device identifier and provides the traffic differentiation when this (i.e. SM-PCF (606) receives the device identifiers from SMF (604)). The QoS policy is retrieved from the UDR (608) and contains all the necessary parameters for traffic differentiation. At step 5b, the PCF (606) may provide a reject indication to the SMF (604) or proceed with the PDU with default QoS when the UDR (608) informs that there is no QoS for the device identifier. The decision to reject or proceed with default QoS is based on operator policy. At step 6, the SMF (604) sends the PDU session to the UE / 5G-RG (602) when rejected based on step 3b or 5b. The SMF (604) may send a reject reason with a Back of Timer (BOT). At step 7, the SMF (604) may inform the AF (610) that the QoS policy is not present for the device identifier and the whole PDU got rejected. This notification allows the AF (610) to take corrective actions, such as provisioning the missing QoS policy. At step 8, the PCF (606) may inform the AF (610) that the QoS policy is not present for the device identifier and the whole PDU got rejected. This notification allows the AF (610) to take corrective actions, such as provisioning the missing QoS policy. At step 9, the AF (610) provisions QoS policies for the new device identifiers. This provisioning can be done through a secure API that ensures the integrity and confidentiality of the QoS policies during transmission.

[0071] In an embodiment, when the SMF (604) receives the device identifier during the PDU session establishment or PDU session modification and contacts the UDR (608) to retrieve the QoS policy for the corresponding non-3GPP device, when the UDR (608) does not send the policy mentioning that the policy is not configured for the device identifier, the SMF (604) may reject the PDU session. The rejection is based on the absence of a valid QoS policy for the device identifier. Also, based on operator policy, the SMF (604) may decide to proceed with the PDU session with default QoS or without providing traffic differentiation. The decision to proceed with default QoS is based on predefined operator policies that dictate how to handle such scenarios.

[0072] In an embodiment, when the SMF (604) receives the device identifier during the PDU session establishment or PDU session modification, the SMF (604) provides the device identifiers to the SM-PCF (606). The SM-PCF (606) contacts the UDR (608) to retrieve the QoS Policy for the corresponding non-3GPP device. When the UDR (608) does not send the policy mentioning that the policy is not configured for the device identifier, the PCF (606) indicates the reason to the SMF (604). The indication includes a specific cause code that explains why the policy is not available. Also, based on operator policy, the PCF (606) may decide to proceed with the PDU session with default QoS or without providing traffic differentiation. The decision to proceed with default QoS is based on predefined operator policies that dictate how to handle such scenarios. Also, the SMF (604), after receiving the indication from the PCF (606) with the reason that the policy is not present for the device identifier, may reject the PDU session. The rejection is based on the absence of a valid QoS policy for the device identifier. Also, based on the operator policy, the SMF (604) may decide to proceed with the PDU session with default QoS or without providing traffic differentiation. The decision to proceed with default QoS is based on predefined operator policies that dictate how to handle such scenarios.

[0073] In an embodiment, as AF (610) configures or provisions the QoS policy for the device identifiers to the UDR (608), either the SMF (604) or PCF (606) or any other NF informs the AF (610) that the UE / 5G-RG (602) is trying the PDU session with the device identifier for which the policy is not provisioned by the AF (610) yet. This notification allows the AF (610) to take corrective actions, such as provisioning the missing QoS policy. The AF (610) can then update the UDR (608) with the new QoS policy, ensuring that future PDU sessions can be handled correctly.

[0074] In an embodiment, when the SMF (604) or PCF (606) rejects the PDU session with some appropriate cause and a back-off timer is given to the UE / 5G-RG (602), the UE / 5G-RG (602) shall not try another PDU session with the same device identifier for which the PDU session is rejected until the back-off timer is expired. The back-off timer is a mechanism to prevent the UE / 5G-RG (602) from repeatedly attempting to establish a PDU session with an invalid or unprovisioned device identifier. This helps to reduce unnecessary signaling traffic and allows time for the AF (610) to provision the necessary QoS policies.

[0075] In an embodiment, the SMF (604), after receiving the PDU session request from UE / 5G-RG (602) with a non-3GPP device identifier to provide traffic differentiation, contacts the PCF (606) and, upon notifying from PCF (606) that device profiles are not present in UDR (608), the SMF (604) rejects the session and provides the appropriate cause to the UE (602). The rejection is based on the absence of a valid device profile for the device identifier. The appropriate cause code is included in the rejection message to inform the UE (602) of the reason for the rejection.

[0076] In an embodiment, the SMF (604) receives the PDU session request with a non-3GPP device identifier and provides the device identifiers to the PCF (606) to get the updated policy rules. The PCF (606) contacts the UDR (608) by providing the device identifier to receive the device profile details. The UDR (608) informs that the profiles are not present for the device identifier. The PCF (606) indicates to the SMF (604) that profiles are not present for the device identifier. The SMF (604) rejects the PDU session and provides an appropriate cause. The UE (602) does not trigger using the same non-3GPP device identifier until it gets updated information from AF (610). This ensures that the UE (602) does not repeatedly attempt to establish a PDU session with an invalid or unprovisioned device identifier.

[0077] In an embodiment, at present, a single user gets service from the network using the policy created for the same user, but when multiple users share the same device to get differentiated service, then there will be a vertical industry that will use this extensively, and the operator makes money by deploying this feature. It is a very crucial use case for enterprise scenarios.

[0078] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. While the preferred embodiments have been described, those skilled in the art will recognize that modifications can be made within the scope of the described embodiments.

Claims

1.A method performed by a policy control function (PCF) entity, the method comprising:receiving, from a session management function (SMF) entity, a non-3GPP device identifier;determining whether information associated with the non-3GPP device identifier is present in a unified data repository (UDR) entity; andin case that the information associated with the non-3GPP device identifier is not present in the UDR entity, transmitting, to the SMF entity, a message for indicating that the non-3GPP device identifier is not available for a user equipment (UE).2.The method of claim 1, wherein the non-3GPP device identifier is obtained via a protocol data unit (PDU) session modification procedure.3.The method of claim 2, wherein the PDU session modification procedure is rejected with a cause code notifying the UE that the non-3GPP device identifier is not available for the UE, in case that the message for indicating that the non-3GPP device identifier is not available for the UE is transmitted to the SMF entity.4.The method of claim 1, wherein the information associated with the non-3GPP device identifier is retrieved from the UDR entity.5.A method performed by a session management function (SMF) entity, the method comprising:receiving, from a user equipment (UE), a non-3GPP device identifier;transmitting, to a policy control function (PCF) entity, the non-3GPP device identifier; andin case that information associated with the non-3GPP device identifier is not present in a unified data repository (UDR) entity, receiving, from the PCF entity, a message for indicating that the non-3GPP device identifier is not available for the UE.6.The method of claim 5, wherein the non-3GPP device identifier is obtained via a protocol data unit (PDU) session modification procedure.7.The method of claim 6, wherein the PDU session modification procedure is rejected with a cause code notifying the UE that the non-3GPP device identifier is not available for the UE, in case that the message for indicating that the non-3GPP device identifier is not available for the UE is transmitted to the SMF entity.8.The method of claim 5, wherein the information associated with the non-3GPP device identifier is retrieved from the UDR entity.9.A policy control function (PCF) entity, the PCF entity comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andmemory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the PCF entity to:receive, from a session management function (SMF) entity, a non-3GPP device identifier,determine whether information associated with the non-3GPP device identifier is present in a unified data repository (UDR) entity, andin case that the information associated with the non-3GPP device identifier is not present in the UDR entity, transmit, to the SMF entity, a message for indicating that the non-3GPP device identifier is not available for a user equipment (UE).10.The PCF entity of claim 9, wherein the non-3GPP device identifier is obtained via a protocol data unit (PDU) session modification procedure.11.The PCF entity of claim 10, wherein the PDU session modification procedure is rejected with a cause code notifying the UE that the non-3GPP device identifier is not available for the UE, in case that the message for indicating that the non-3GPP device identifier is not available for the UE is transmitted to the SMF entity.12.The PCF entity of claim 9, wherein the information associated with the non-3GPP device identifier is retrieved from the UDR entity.13.A session management function (SMF) entity, the SMF entity comprising:at least one transceiver;at least one processor communicatively coupled to the at least one transceiver; andmemory, communicatively coupled to the at least one processor, storing instructions executable by the at least one processor individually or in any combination to cause the SMF entity to:receive, from a user equipment (UE), a non-3GPP device identifier,transmit, to a policy control function (PCF) entity, the non-3GPP device identifier, andin case that information associated with the non-3GPP device identifier is not present in a unified data repository (UDR) entity, receive, from the PCF entity, a message for indicating that the non-3GPP device identifier is not available for the UE.14.The SMF entity of claim 13, wherein the non-3GPP device identifier is obtained via a protocol data unit (PDU) session modification procedure.15.The SMF entity of claim 14, wherein the PDU session modification procedure is rejected with a cause code notifying the UE that the non-3GPP device identifier is not available for the UE, in case that the message for indicating that the non-3GPP device identifier is not available for the UE is transmitted to the SMF entity.

Images