EP4699279A1

EP4699279A1 - Traffic management in 5g networks based on traffic categories

Info

Publication number: EP4699279A1
Application number: EP24720087.6A
Authority: EP
Inventors: Antonio INIESTA GONZALEZ; Miguel Angel MUÑOZ DE LA TORRE ALONSO
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-04-17
Filing date: 2024-04-15
Publication date: 2026-02-25
Also published as: WO2024218041A1

Abstract

This disclosure provides a method for enabling traffic management on a per traffic category basis in a communications network. The method comprises receiving at a first network node from a second network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category; receiving at a third network node from the first network node the one or more PFDs associated with a traffic category; transmitting from the third network node to a fourth network node the one or more PFDs associated with a traffic category; and applying at the fourth network node differentiated traffic management actions to the traffic based on the traffic category. In some embodiments, the method further comprises transmitting from the third network node to the first network node a request for PFDs associated with a traffic category, and wherein the SMF receives from the NEF the PFDs associated with a traffic category in response to the request. In some embodiments, the method further comprises transmitting from the third network node to the first network node a subscription request for PFDs associated with a traffic category, and wherein the NEF notifies to the SMF the PFDs associated with a traffic category when the NEF receives the PFDs associated with a traffic category from the AF.

Description

TRAFFIC MANAGEMENT IN 5G NETWORKS BASED ON TRAFFIC CATEGORIES

TECHNICAL FIELD

The present invention generally relates to traffic management in 5G (Fifth Generation) networks, and more specifically, the invention relates to the provisioning of policy rules and the application of differentiated traffic management actions in deployments based on URSP rules with Traffic Descriptors on a per traffic category basis.

BACKGROUND

In 3GPP (Third Generation Partnership Project) Fifth Generation (5G) mobile networks the Application Function (AF) interacts with the 3GPP Core Network, enabling external parties to utilize the Exposure APIs provided by the network operator. The AF facilitates communication between applications and the 5G system. The Network Exposure Function (NEF) various functionalities, including offering different Exposure APIs. The NEF manages and provide access to these APIs. The 5G System architecture allows the User Data Management (UDM), Policy Control Function (PCF), and NEF to store data in the Unified Data Repository (UDR). The UDR stores subscription policy data. The Policy Control Function (PCF) supports a unified policy framework to govern the network behavior. The PCF is responsible for providing User Equipment (UE) Policies and Policy and Charging Control (PCC) rules to the Session Management Function (SMF), thus regulating network behavior according to operator policies and subscription terms. The Session Management Function (SMF) is responsible for various functionalities, such as receiving PCC rules from the PCF and configuring the User Plane Function (UPF) accordingly. This allows for efficient management of user sessions and network resources. The User Plane Function (UPF) handles user plane traffic based on the rules received from the SMF. This includes packet inspection and the execution of different enforcement actions, such as Sponsored Data or Quality of Service (QoS) handling, ensuring optimized traffic management in the 5G network. User Equipment (UE) policies are defined by 3GPP to configure the UE with operator policies. These policies include Access Network Discovery and Selection Policy (ANDSP) for non-3GPP access and UE Route Selection Policy (URSP) related to applications and PDU sessions.

A problematic aspect in the context of network automation and traffic management in the 5G system is inadequate PCC Rule definition. The Policy Control Function (PCF) for the PDU session is required to provision Policy and Charging Control (PCC) rules to the Session Management Function (SMF) with an aligned Service Data Flow (SDF) template and Traffic Descriptor (TD) of the URSP rules. However, this alignment is primarily restricted to cases where the TD in the URSP rule is defined as an application identifier or a flow description, which are the identifiers that can be currently used in the PCC rules. When the TD in the URSP rule is defined differently, for instance, including a Connection Capability, it is undefined how to appropriately define the corresponding PCC rule.

A further problematic aspect is limited traffic differentiation. Network operators require traffic differentiation to apply differentiated traffic management actions, such as charging, Quality of Service (QoS), and more, according to operator policies and subscription terms. The existing technology does not allow for the application of differentiated traffic management actions for various traffic types in deployments based on URSP rules with Traffic Descriptors. As a result, there is a need for a more flexible and efficient method to handle traffic differentiation in the 5G system.

SUMMARY

The invention is set out in the appended set of claims.

An object of the invention is to allow for the application of different traffic management actions on a per traffic category basis within an application session, thus enabling more granular control over the enforcement of policies for different types of traffic.

An aspect of the invention relates to a method performed by a first network node for enabling traffic management on a per traffic category basis in a communications network. The method comprises receiving at a first network node from a second network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category; and transmitting from the first network node to a third network node the one or more PFDs associated with a traffic category. In some embodiments, the method further comprises receiving at the first network node from the third network node a request for PFDs associated with a traffic category, and wherein the SMF receives from the NEF the PFDs associated with a traffic category in response to the request. In some embodiments, the method further comprises receiving at the first network node from the third network node a subscription request for PFDs associated with a traffic category, and wherein the NEF notifies to the SMF the PFDs associated with a traffic category when the NEF receives the PFDs associated with a traffic category from the AF. In some embodiments, the method further comprises transmitting from the first network node to a User Data Repository (UDR) the one or more PFDs associated with a traffic category; receiving at the first network node from the UDR one or more PFDs associated with a traffic category, in response to a request for PFDs associated with a traffic category from the fifth network node; and transmitting from the first network node to the third network node the received PFDs associated with a traffic category. In some embodiments, the one or more PFDs associated with a traffic category are further associated with an application identifier. In some embodiments, the first network node receives from the second network node the PFDs through an Nnef Northbound API for PFD Management. In some embodiments, the transmitting of the PFDs to the UDR includes storing the PFDs and their associated traffic category in the UDR. In some embodiments, the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink. In some embodiments, the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink. In some embodiments, the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging. In some embodiments, the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images. In some embodiments, the one or more PFDs associated with a traffic category are received at the first network node from multiple second network nodes, and wherein the first network node aggregates the PFDs received from the multiple second network nodes. In some embodiments, the first network node is a Network Exposure Function (NEF), the second network node is an Application Function (AF), the third network node is a Session Management Function (SMF), the fourth network node is a User Plane Function (UPF), the fifth network node is a Policy Control Function (PCF).

An aspect of the invention relates to a method performed by a third network node for enabling traffic management on a per traffic category basis in a communications network. The method comprises receiving at a third network node from a first network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category; and transmitting from the third network node to a fourth network node the one or more PFDs associated with a traffic category. In some embodiments, the method further comprises transmitting from the third network node to the first network node a request for PFDs associated with a traffic category, and wherein the SMF receives from the NEF the PFDs associated with a traffic category in response to the request. In some embodiments, the method further comprises transmitting from the third network node to the first network node a subscription request for PFDs associated with a traffic category, and wherein the NEF notifies to the SMF the PFDs associated with a traffic category when the NEF receives the PFDs associated with a traffic category from the AF. In some embodiments, the method further comprises receiving at the third network node from a fifth network node one or more Policy and Charging Control (PCC) rules including a traffic descriptor comprising a traffic category, wherein the PCC rules are based on Traffic Categories included in a user's subscription; and transmitting from the third network node to the fourth network node one or more Packet Detection Rules (PDRs) including the traffic descriptor comprising a traffic category. In some embodiments, the method further comprises receiving at the third network node from the first network node one or more PFDs associated with a traffic category. In some embodiments, the one or more PFDs associated with a traffic category are further associated with an application identifier. In some embodiments, the method further comprises the third network node checking for previously stored PFD rules associated with the traffic category, and initiating a PFD Management pull procedure if the PFD rules are not found. In some embodiments, the PFD Management pull procedure comprises the third network node transmitting a Nnef_PFDmanagement_Fetch message to the first network node to retrieve PFDs by a full pull or a partial pull service operation. In some embodiments, the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink. In some embodiments, the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink. In some embodiments, the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging. In some embodiments, the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images. In some embodiments, the first network node is a Network Exposure Function (NEF), the second network node is an Application Function (AF), the third network node is a Session Management Function (SMF), the fourth network node is a User Plane Function (UPF), the fifth network node is a Policy Control Function (PCF).

An aspect of the invention relates to a method performed by a fourth network node for enabling traffic management on a per traffic category basis in a communications network. The method comprises receiving at a fourth network node from a third network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category; and applying at the fourth network node differentiated traffic management actions to the traffic based on the traffic category. In some embodiments, the method further comprises receiving at the fourth network node from the third network node one or more Packet Detection Rules (PDRs) including the traffic descriptor comprising a traffic category. In some embodiments, the one or more PFDs associated with a traffic category are further associated with an application identifier. In some embodiments, the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink. In some embodiments, the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink. In some embodiments, the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging. In some embodiments, the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images. In some embodiments, the differentiated traffic management actions include charging and Quality of Service (QoS) actions. In some embodiments, the fourth network node detects the traffic category within an application session traffic by matching incoming packets with the PDR with a Packet Detection Indicator (PDI) of the type of traffic category based on the provisioned PFDs. In some embodiments, the first network node is a Network Exposure Function (NEF), the second network node is an Application Function (AF), the third network node is a Session Management Function (SMF), the fourth network node is a User Plane Function (UPF), the fifth network node is a Policy Control Function (PCF).

Other aspects of the invention relate to mobile network nodes, particularly a fourth network node (103, 800), a third network node (107, 700), a first network node (109, 600), a fifth network node (111), a second network node (113) configured to perform the respective methods as described herein. Other aspects of the invention relate to computer program and computer program products.

In some embodiments, the fourth network node is a User Plane Function (UPF). In some embodiments, the third network node is a Session Management Function (SMF). In some embodiments, the first network node is a Network Exposure Function (NEF). In some embodiments, the fifth network node is a Policy Control Function (PCF). In some embodiments, the second network node is an Application Function (AF).

Advantageously, the proposed solution enables MNOs to apply differentiated traffic management actions based on URSP rules with Traffic Descriptors that include Traffic Categories. This is especially useful when an application client requests different traffic categories for distinct flows within the application session.

Further advantageously, the solution allows MNOs to verify that applications are accurately mapped to the appropriate Traffic Categories, ensuring efficient use of network resources.

Further advantageously, the proposed solution enables that an application client can indicate a separate traffic category (TC) for each flow within the application session in their request to the operating system (OS) such as iOS. The OS then directs each flow within the application session into a PDU Session based on MNO-provisioned URSPs with Traffic Descriptors corresponding to the requested traffic category (TC).

Further advantageously, the solution aligns PCC rules and URSP rules when the Traffic Descriptor (TD) in the URSP rule contains a traffic category, further enhancing the network's efficiency and performance.

Additional objectives, features and advantages of the concepts disclosed herein will be apparent from the following description, claims and drawings, or may be learned by practice of the described technologies and concepts as set forth herein.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to best describe the manner in which the disclosed concepts may be implemented, as well as define other objects, advantages and features of the disclosure, a more particular description is provided below and is illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the invention and are not therefore to be considered to be limiting in scope, the examples will be described and explained with additional specificity and detail through the use of the accompanying drawings.

Figure 1 illustrates an example networked system in accordance with particular embodiments of the solution described herein.

Figures 2A-2C illustrate an example signaling diagram showing a procedure according to particular embodiments of the solution described herein.

Figure 3 illustrates an example flowchart showing a method performed by a mobile network node according to particular embodiments of the solution described herein.

Figure 4 illustrates an example flowchart showing a method performed by a mobile network node according to particular embodiments of the solution described herein.

Figure 5 illustrates an example flowchart showing a method performed by a mobile network node according to particular embodiments of the solution described herein.

Figure 6 illustrates an example block diagram of a mobile network node configured in accordance with particular embodiments of the solution described herein.

Figure 7 illustrates an example block diagram of a mobile network node configured in accordance with particular embodiments of the solution described herein.

Figure 8 illustrates an example block diagram of a mobile network node configured in accordance with particular embodiments of the solution described herein.

DETAILED DESCRIPTION

The invention will now be described in detail hereinafter with reference to the accompanying drawings, in which examples of embodiments or implementations of the invention are shown. The invention may, however, be embodied or implemented in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present invention to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment. These embodiments of the disclosed subject matter are presented as teaching examples and are not to be construed as limiting the scope of the disclosed subject matter. For example, certain details of the described embodiments may be modified, omitted, or expanded upon without departing from the scope of the described subject matter.

The example embodiments described herein arise in the context of a telecommunications network, including but not limited to a telecommunications network that conforms to and/or otherwise incorporates aspects of a fifth generation (5G) architecture. Figure 1 is an example networked system 100 in accordance with example embodiments of the present disclosure. Figure 1 specifically illustrates User Equipment (UE) 101 , which may be in communication with a (Radio) Access Network (RAN) 102 and Access and Mobility Management Function (AMF) 106 and User Plane Function (UPF) 103. The AMF 106 may, in turn, be in communication with core network services including Session Management Function (SMF) 107 and Policy Control Function (PCF) 111. The core network services may also be in communication with an Application Server/ Application Function (AS/AF) 113. Other networked services also include Network Slice Selection Function (NSSF) 108, Authentication Server Function (AUSF) 105, User Data Management (UDM) 112, Network Exposure Function (NEF) 109, Network Repository Function (NRF) 110, Unified Repository Function (UDR) 114, Network Data Analytics Function (NWDAF) 115 and Data Network (DN) 104. In some example implementations of embodiments of the present disclosure, each one of the entities in the networked system 100 are considered to be a Network Function (NF). One or more additional instances of the NFs may be incorporated into the networked system.

This disclosure provides a method for enabling traffic management on a per traffic category basis in a communications network. The method comprises receiving at a first network node from a second network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category; receiving at a third network node from the first network node the one or more PFDs associated with a traffic category; transmitting from the third network node to a fourth network node the one or more PFDs associated with a traffic category; and applying at the fourth network node differentiated traffic management actions to the traffic based on the traffic category. In some embodiments, the method further comprises transmitting from the third network node to the first network node a request for PFDs associated with a traffic category, and wherein the SMF receives from the NEF the PFDs associated with a traffic category in response to the request. In some embodiments, the method further comprises transmitting from the third network node to the first network node a subscription request for PFDs associated with a traffic category, and wherein the NEF notifies to the SMF the PFDs associated with a traffic category when the NEF receives the PFDs associated with a traffic category from the AF. In some embodiments, the method further comprises transmitting from a fifth network node to the third network node one or more Policy and Charging Control (PCC) rules including a traffic descriptor comprising a traffic category, wherein the PCC rules are based on Traffic Categories included in a user's subscription; and transmitting from the third network node to the fourth network node one or more Packet Detection Rules (PDRs) including the traffic descriptor comprising a traffic category. In some embodiments, the method further comprises transmitting from the first network node to a User Data Repository (UDR) the one or more PFDs associated with a traffic category; receiving at the first network node from the UDR one or more PFDs associated with a traffic category, in response to a request for PFDs associated with a traffic category from the fifth network node; and transmitting from the first network node to the third network node the received PFDs associated with a traffic category. In some embodiments, the one or more PFDs associated with a traffic category are further associated with an application identifier. In some embodiments, the first network node receives from the second network node the PFDs through an Nnef Northbound API for PFD Management. In some embodiments, the transmitting of the PFDs to the UDR includes storing the PFDs and their associated traffic category in the UDR. In some embodiments, the method further comprises the third network node checking for previously stored PFD rules associated with the traffic category, and initiating a PFD Management pull procedure if the PFD rules are not found. In some embodiments, the PFD Management pull procedure comprises the third network node transmitting a Nnef_PFDmanagement_Fetch message to the first network node to retrieve PFDs by a full pull or a partial pull service operation. In some embodiments, the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow (SDF) filter. In some embodiments, the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink. In some embodiments, the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink. In some embodiments, the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging. In some embodiments, the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images. In some embodiments, the differentiated traffic management actions include charging and Quality of Service (QoS) actions. In some embodiments, the fourth network node detects the traffic category within an application session traffic by matching incoming packets with the PDR with a Packet Detection Indicator (PDI) of the type of traffic category based on the provisioned PFDs. In some embodiments, the one or more PFDs associated with a traffic category are received at the first network node from multiple second network nodes, and wherein the first network node aggregates the PFDs received from the multiple second network nodes. In some embodiments, the first network node is a Network Exposure Function (NEF), the second network node is an Application Function (AF), the third network node is a Session Management Function (SMF), the fourth network node is a User Plane Function (UPF), the fifth network node is a Policy Control Function (PCF).

This disclosure also provides mobile network nodes, particularly a fourth network node (103, 800), a third network node (107, 700), a first network node (109, 600), a fifth network node (111), configured to perform the respective methods as described herein. In some embodiments, the fourth network node is a User Plane Function (UPF) 103. In some embodiments, the third network node is a Session Management Function (SMF) 107. In some embodiments, the first network node is a Network Exposure Function (NEF) 109. In some embodiments, the fifth network node is a Policy Control Function (PCF) 111. In some embodiments, the second network node is an Application Function (AF) 113.

This disclosure also provides the corresponding computer program and computer program products comprising code, for example in the form of a computer program, that when run on processing circuitry of the mobile network nodes causes the mobile network nodes to perform the disclosed methods.

The solution and the features comprised therein are further described in what follows.

The proposed solution enables traffic management on a per traffic category basis by introducing extensions to existing procedures and rules. These extensions involve the following: 1 ) AF transmitting the Packet Flow Description (PFD) including the associated traffic category to NEF for an application, via an extension of the Nnef PFD Management API; 2) transmitting PCC rules from PCF to SMF, by means of an extension of the PCC rules (and PDRs) including a traffic descriptor type incorporating the traffic category; 3) transmitting the PFDs with the traffic category from NEF/PFDF to UPF (through SMF) using the PFD Management provisioning procedure. The core essence of the solution lies in extending the PFD Management procedure and the PCC rules (and PDRs) to enable mobile network operators (MNOs) to support classification of user plane traffic based on Traffic Categories for deployments using URSP rules with Traffic Descriptors.

Hereinafter, drawings showing examples of embodiments of the solution are described in detail.

Figures 2A-2C show a signaling diagram illustrating a procedure for enabling traffic management on a per traffic category basis in a communications network, particularly following the PFD Management Pull procedure.

As a precondition, there is a deployment based on URSP rules with Traffic Descriptors including Traffic Categories.

The steps of the procedure are detailed below:

Step 1) the AF provisions for a certain application (e.g., example.com) the PFD rules including their associated Traffic Category (this Traffic Category is the one provided by the application client in the UE), through Nnef Northbound API for PFD Management by triggering an HTTP POST request message including the following parameters:

• Afld. Identifies the AF

• service=PFDManagement. Identifies the requested service, in this case the NEF PFD Management service

• appld=example.com. Identifies the application.

• list of (PFDs, trafficcategory). This is a list of PFDs and their associated traffic category. The traffic category might be based on the 3GPP standardized traffic categories in URSP.

Each set of PFDs within the same application (appld) might have a different traffic category. For example, for appld=App1 , some PFDs might correspond to trafficCategory=”On demand downlink Streaming” while some other PFDs might correspond to trafficCategory-’Internet”.

Step 2) the NEF (PFD Management service) acknowledges the request with a Nnef 200 OK message.

Steps 3, 4 and 5) the NEF (PFD Management service) requests UDR to store the application identifier and the PFDs with their associated traffic category. UDR stores the PFDs and their associated traffic category and acknowledges the request (indicating successful operation). This requires an extension of the Application Data structure in UDR.

Steps 6 and 7) UE triggers PDU session establishment, by means of sending a PDU Session Establishment Request to AMF. AMF selects an SMF to manage the PDU session and triggers Nsmf PDU Session Create.

Step 8) SMF triggers Npcf_SMPolicyControl_Create Request message to retrieve SM policies for the user PDU session.

Step 9) PCF triggers Nudr Query Request message to retrieve the policy data for this use PDU session.

Step 10) UDR answers with Nudr Query Response message including the Subscriber Policy Data, including the traffic category/ies included in the user's subscription.

Step 11 ) PCF generates PCC rules based on the Traffic Categories included in the user's subscription.

Step 12) Based on the above, PCF triggers Npcf_SMPolicyControl_Create Response message including the PCC rules to be applied for this user PDU session. In this case, it is proposed to extend the PCC rule with a type of traffic descriptor (separate from appld and sdf Filter) based on the traffic category, so the generated PCC rule(s) will include a trafficcategory and the associated traffic enforcement actions (e.g., Charging and QoS). The extension proposed, specifically to Service Data Flow Template is shown below:

PCC rule information elements: Step 13) SMF triggers PFCP Session Establishment Request message including the corresponding PDRs/FARs/QERs/URRs. In this case, it is proposed to extend the PDR with a type of traffic descriptor (separate from appld and sdf Filter) based on the traffic category, so the generated PDR(s) will include a PDI of type trafficcategory and the associated FAR, QER and URR to apply the corresponding traffic enforcement actions (e.g., Charging and QoS). The extension proposed, specifically to PDI IE is shown below:

PDI IE within PFCP Session Establishment Request:

Step 14) LIPF stores the PDRs/FARs/QERs/URRs and answers back to SMF with a PFCP Session Establishment Response message.

Steps 15 and 16) Based on the PCC rules received in Step 12 above, in this case PCC rule(s) with trafficcategory, SMF checks if it has previously stored PFD rules for the traffic category/ies in the PCC rules. If this example, SMF has not any stored the PFD rules for the requested traffic category/ies and SMF triggers the PFD Management pull procedure by requesting to NEF PFD Management service for the requested traffic category/ies.

Specifically, in the case of the pull procedure, it is proposed to extend the Nnef_PFDmanagement_Fetch service and specifically the following service operations:

• Retrieval of PFDs by the full pull.

• Retrieval of PFDs by the partial pull.

As an example, for the full pull service operation, the proposed extensions are shown below (retrieval of the PFDs by the full pull): • The NF service consumer (e.g. SMF) shall send a GET request to the resource representing the PFDs for the requested traffic category(ies):

- for PFDs of an individual traffic category, the request URI shall be set to "{apiRoot}/nnef pfdmanagement/v1/trafficCategories/{trafficCategory; and

- for PFD of a collection of traffic categories, the request URI shall be set to "{apiRoot}/nnef pfdmanagement/v1 /trafficcategories" with query parameters indicating the requested traffic category(ies).

The above shows the example of the (full) pull procedure, but the same extensions are proposed for the (partial) pull procedure and for the push procedure.

Step 17) NEF (PFD Management service) triggers Nudr Query Request message to UDR to retrieve the PFDs for the requested traffic category/ies.

Steps 18 and 19) UDR retrieves all the PFDs for the requested traffic category/ies.

Step 20) After receiving the message in previous step, the NEF responds back to SMF the with a Nnef 200 OK successful response, including the PFDs for the requested traffic category/ies.

Step 21 ) SMF provisions UPF with the PFDs for the requested traffic category/ies by triggering a PFCP PFD Management request message, which is proposed to be extended to include the trafficCategory/ies and the corresponding PFDs.

Steps 22 and 23) UPF stores the PFDs for the Traffic Category/ies and answers SMF by triggering a PFCP PFD Management response message.

Steps 24 and 25) User opens example.com application. UPF detects the Traffic Category/ies within example.com application session traffic by matching the incoming packets with the PDR with PDI of type trafficcategory (based on the provisioned PFDs in Step 21 above) and applies the corresponding enforcement actions indicated in FAR, QER and URR (e.g. Charging, QoS). For example, assuming example.com application has two different traffic categories (e.g. trafficCategory=”On demand downlink Streaming” and trafficCategory-’Internet”), the mechanism proposed allows to apply different traffic management actions to each traffic category for the traffic of the application session. The mechanism proposed allows to apply different traffic management actions to each traffic category for the traffic of any application session.

Step 26) UPF forwards the traffic to the Application Server according to the FAR. Hereinafter, flowcharts showing examples of embodiments of the solution are described in detail.

The embodiments correspond to methods performed by and involving a fourth network node (103, 800), a third network node (107, 700), a first network node (109, 600), a fifth network node (111), a second network node (113).

Figure 3 is a flowchart illustrating a method performed by the first network node for enabling traffic management on a per traffic category basis in a communications network.

In step S-301 , the first network node receives from a second network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category.

In step S-302, the first network node receives from the third network node a request for PFDs associated with a traffic category, and wherein the SMF receives from the NEF the PFDs associated with a traffic category in response to the request.

In step S-303, the first network node receives from the third network node a subscription request for PFDs associated with a traffic category, and wherein the NEF notifies to the SMF the PFDs associated with a traffic category when the NEF receives the PFDs associated with a traffic category from the AF.

In step S-304, the first network node transmits to a User Data Repository (UDR) the one or more PFDs associated with a traffic category.

In step S-305, the first network node receives from the UDR one or more PFDs associated with a traffic category, in response to a request for PFDs associated with a traffic category from the fifth network node.

In step S-306, the first network node transmits to the third network node the received PFDs associated with a traffic category.

In step S-307, the first network node transmits to a third network node the one or more PFDs associated with a traffic category.

In some embodiments, the one or more PFDs associated with a traffic category are further associated with an application identifier.

In some embodiments, the first network node receives from the second network node the PFDs through an Nnef Northbound API for PFD Management. In some embodiments, the transmitting of the PFDs to the UDR includes storing the PFDs and their associated traffic category in the UDR.

In some embodiments, the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow (SDF) filter.

In some embodiments, the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow (SDF) filter.

In some embodiments, the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink.

In some embodiments, the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink.

In some embodiments, the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging.

In some embodiments, the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images.

In some embodiments, the one or more PFDs associated with a traffic category are received at the first network node from multiple second network nodes, and wherein the first network node aggregates the PFDs received from the multiple second network nodes.

In some embodiments, the first network node is a Network Exposure Function (NEF), the second network node is an Application Function (AF), the third network node is a Session Management Function (SMF), the fourth network node is a User Plane Function (UPF), the fifth network node is a Policy Control Function (PCF).

Figure 4 is a flowchart illustrating a method performed by the third network node for enabling traffic management on a per traffic category basis in a communications network.

In step S-401 , the third network node receives from a first network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category.

In step S-402, the third network node transmits to the first network node a request for PFDs associated with a traffic category, and wherein the SMF receives from the NEF the PFDs associated with a traffic category in response to the request. In step S-403, the third network node transmits to the first network node a subscription request for PFDs associated with a traffic category, and wherein the NEF notifies to the SMF the PFDs associated with a traffic category when the NEF receives the PFDs associated with a traffic category from the AF.

In step S-404, the third network node receives from a fifth network node one or more Policy and Charging Control (PCC) rules including a traffic descriptor comprising a traffic category, wherein the PCC rules are based on Traffic Categories included in a user's subscription.

In step S-405, the third network node transmits to the fourth network node one or more Packet Detection Rules (PDRs) including the traffic descriptor comprising a traffic category.

In step S-406, the third network node receives from the first network node one or more PFDs associated with a traffic category.

In step S-407, the third network node transmits to a fourth network node the one or more PFDs associated with a traffic category.

In some embodiments, the method further comprises the third network node checking for previously stored PFD rules associated with the traffic category, and initiating a PFD Management pull procedure if the PFD rules are not found.

In some embodiments, the PFD Management pull procedure comprises the third network node transmitting a Nnef_PFDmanagement_Fetch message to the first network node to retrieve PFDs by a full pull or a partial pull service operation.

In some embodiments, the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink. In some embodiments, the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging.

Figure 5 is a flowchart illustrating a method performed by the fourth network node for enabling traffic management on a per traffic category basis in a communications network.

In step S-501 , the fourth network node receives from a third network node one or more Packet Flow Descriptions (PFDs) associated with a traffic category.

In step S-502, the fourth network node receives from the third network node one or more Packet Detection Rules (PDRs) including the traffic descriptor comprising a traffic category.

In step S-503, the fourth network node applies differentiated traffic management actions to the traffic based on the traffic category.

In some embodiments, the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images. In some embodiments, the differentiated traffic management actions include charging and Quality of Service (QoS) actions.

In some embodiments, the fourth network node detects the traffic category within an application session traffic by matching incoming packets with the PDR with a Packet Detection Indicator (PDI) of the type of traffic category based on the provisioned PFDs.

Figure 6 is a block diagram illustrating elements of a mobile network node 600 of a mobile communications network. In some embodiments, the mobile network node 600 is a NEF 109. As shown, the mobile network node may include network interface circuitry 601 (also referred to as a network interface) configured to provide communications with other nodes of the core network and/or the network. The mobile network node may also include a processing circuitry 602 (also referred to as a processor) coupled to the network interface circuitry, and memory circuitry 603 (also referred to as memory) coupled to the processing circuitry. The memory circuitry 603 may include computer readable program code that when executed by the processing circuitry 602 causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry 602 may be defined to include memory so that a separate memory circuitry is not required. As discussed herein, operations of the mobile network node may be performed by processing circuitry 602 and/or network interface circuitry 601 . For example, processing circuitry 602 may control network interface circuitry 601 to transmit communications through network interface circuitry 601 to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory 603, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry 602, processing circuitry 602 performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to core network nodes).

Figure 7 is a block diagram illustrating elements of a mobile network node 700 of a mobile communications network. In some embodiments, the mobile network node 700 is an SMF 107. As shown, the mobile network node may include network interface circuitry 701 (also referred to as a network interface) configured to provide communications with other nodes of the core network and/or the network. The mobile network node may also include a processing circuitry 702 (also referred to as a processor) coupled to the network interface circuitry, and memory circuitry 703 (also referred to as memory) coupled to the processing circuitry. The memory circuitry 703 may include computer readable program code that when executed by the processing circuitry 702 causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry 702 may be defined to include memory so that a separate memory circuitry is not required. As discussed herein, operations of the mobile network node may be performed by processing circuitry 702 and/or network interface circuitry 701 . For example, processing circuitry 702 may control network interface circuitry 701 to transmit communications through network interface circuitry 701 to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory 703, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry 702, processing circuitry 702 performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to core network nodes).

Figure 8 is a block diagram illustrating elements of a mobile network node 800 of a mobile communications network. In some embodiments, the mobile network node 800 is a UPF 103. As shown, the mobile network node may include network interface circuitry 801 (also referred to as a network interface) configured to provide communications with other nodes of the core network and/or the network. The mobile network node may also include a processing circuitry 802 (also referred to as a processor) coupled to the network interface circuitry, and memory circuitry 803 (also referred to as memory) coupled to the processing circuitry. The memory circuitry 803 may include computer readable program code that when executed by the processing circuitry 802 causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry 802 may be defined to include memory so that a separate memory circuitry is not required. As discussed herein, operations of the mobile network node may be performed by processing circuitry 802 and/or network interface circuitry 801 . For example, processing circuitry 802 may control network interface circuitry 801 to transmit communications through network interface circuitry 801 to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory 803, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry 802, processing circuitry 802 performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to core network nodes). Figure 9 is a block diagram illustrating a virtualization environment 900 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 900 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 900 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

Applications 902 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 904 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 906 may present a virtual operating platform that appears like networking hardware to the VMs 908.

The VMs 908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 906. Different embodiments of the instance of a virtual appliance 902 may be implemented on one or more of VMs 908, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM 908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 908, and that part of hardware 904 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 908 on top of the hardware 904 and corresponds to the application 902.

Hardware 904 may be implemented in a standalone network node with generic or specific components. Hardware 904 may implement some functions via virtualization. Alternatively, hardware 904 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 910, which, among others, oversees lifecycle management of applications 902. In some embodiments, hardware 904 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 912 which may alternatively be used for communication between hardware nodes and radio units.

Embodiments within the scope of the present invention may also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such tangible computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or combination thereof) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer- readable medium. Combinations of the above should also be included within the scope of the tangible computer-readable media.

Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in standalone or network environments. Generally, program modules include routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Computer executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.

Those of skill in the art will appreciate that other embodiments of the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Communication at various stages of the described system can be performed through a local area network, a token ring network, the Internet, a corporate intranet, 802.11 series wireless signals, fiber-optic network, radio or microwave transmission, etc. Although the underlying communication technology may change, the fundamental principles described herein are still applicable.

The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. For example, the principles herein may be applied to any remotely controlled device. Further, those of skill in the art will recognize that communication between the remote the remotely controlled device need not be limited to communication over a local area network but can include communication over infrared channels, Bluetooth or any other suitable communication interface. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without following the example embodiments and applications illustrated and described herein, and without departing from the scope of the present disclosure.

The terminology used herein is for the purpose of describing various embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "includes," "including," "comprises," and "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, or components, and combinations thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, or components, and combinations thereof. Further, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to ""a/an/the element, apparatus, component, means, module, step, etc."" are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

Claims

1 . A method for enabling traffic management on a per traffic category basis in a communications network, the method comprising: receiving at a first network node (109, 600) from a second network node (113) one or more Packet Flow Descriptions, PFDs, associated with a traffic category; receiving at a third network node (107, 700) from the first network node (109, 600) the one or more PFDs associated with a traffic category; transmitting from the third network node (107, 700) to a fourth network node (103, 800) the one or more PFDs associated with a traffic category; and applying at the fourth network node (103, 800) differentiated traffic management actions to the traffic based on the traffic category.

2. The method of claim 1 , further comprising: transmitting from the third network node (107, 700) to the first network node (109, 600) a request for PFDs associated with a traffic category, and wherein the third network node (107, 700) receives from the first network node (109, 600) the PFDs associated with a traffic category in response to the request.

3. The method of any one of claims from claim 1 to claim 2, further comprising: transmitting from the third network node (107, 700) to the first network node (109, 600) a subscription request for PFDs associated with a traffic category, and wherein the first network node (109, 600) notifies to the third network node (107, 700) the PFDs associated with a traffic category when the first network node (109, 600) receives the PFDs associated with a traffic category from the second network node (113).

4. The method of any one of claims from claim 1 to claim 3, further comprising: transmitting from a fifth network node (111 ) to the third network node (107, 700) one or more Policy and Charging Control, PCC, rules including a traffic descriptor comprising a traffic category, wherein the PCC rules are based on Traffic Categories included in a user's subscription; and transmitting from the third network node (107, 700) to the fourth network node (103, 800) one or more Packet Detection Rules, PDRs, including the traffic descriptor comprising a traffic category.

5. The method of any one of claims from claim 1 to claim 4, further comprising: transmitting from the first network node (109, 600) to a User Data Repository, UDR, the one or more PFDs associated with a traffic category; receiving at the first network node (109, 600) from the UDR one or more PFDs associated with a traffic category, in response to a request for PFDs associated with a traffic category from the fifth network node (111 ); and transmitting from the first network node (109, 600) to the third network node (107, 700) the received PFDs associated with a traffic category.

6. The method of any one of claims from claim 1 to claim 5, wherein the one or more PFDs associated with a traffic category are further associated with an application identifier.

7. The method of any one of claims from claim 1 to claim 6, wherein the first network node (109, 600) receives from the second network node (113) the PFDs through an Nnef Northbound API for PFD Management.

8. The method of any one of claims from claim 1 to claim 7, wherein the transmitting of the PFDs to the UDR includes storing the PFDs and their associated traffic category in the UDR.

9. The method of any one of claims from claim 1 to claim 8, wherein the method further comprises the third network node (107, 700) checking for previously stored PFD rules associated with the traffic category, and initiating a PFD Management pull procedure if the PFD rules are not found.

10. The method of any one of claims from claim 1 to claim 9, wherein the PFD Management pull procedure comprises the third network node (107, 700) transmitting a Nnef_PFDmanagement_Fetch message to the first network node (109, 600) to retrieve PFDs by a full pull or a partial pull service operation.

11 . The method of any one of claims from claim 1 to claim 10, wherein the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow, SDF, filter. - T1 -

12. The method of any one of claims from claim 1 to claim 11 , wherein the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow, SDF, filter.

13. The method of any one of claims from claim 1 to claim 12, wherein the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink.

14. The method of any one of claims from claim 1 to claim 13, wherein the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink.

15. The method of any one of claims from claim 1 to claim 14, wherein the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging.

16. The method of any one of claims from claim 1 to claim 15, wherein the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images.

17. The method of any one of claims from claim 1 to claim 16, wherein the differentiated traffic management actions include charging and Quality of Service, QoS, actions.

18. The method of any one of claims from claim 1 to claim 17, wherein the fourth network node (103, 800) detects the traffic category within an application session traffic by matching incoming packets with the PDR with a Packet Detection Indicator, PDI, of the type of traffic category based on the provisioned PFDs.

19. The method of any one of claims from claim 1 to claim 18, wherein the one or more PFDs associated with a traffic category are received at the first network node (109, 600) from multiple second network node (113)s, and wherein the first network node (109, 600) aggregates the PFDs received from the multiple second network node (113)s.

20. The method of any one of claims from claim 1 to claim 19, wherein the first network node (109, 600) is a Network Exposure Function, NEF, the second network node (113) is an Application Function, AF, the third network node (107, 700) is a Session Management Function, SMF, the fourth network node (103, 800) is a User Plane Function, UPF, the fifth network node (111) is a Policy Control Function, PCF.

21 . A method performed by a first network node (109, 600) for enabling traffic management on a per traffic category basis in a communications network, the method comprising: receiving at a first network node (109, 600) from a second network node (113) one or more Packet Flow Descriptions, PFDs, associated with a traffic category; and transmitting from the first network node (109, 600) to a third network node (107, 700) the one or more PFDs associated with a traffic category.

22. The method of claim 21 , further comprising: receiving at the first network node (109, 600) from the third network node (107, 700) a request for PFDs associated with a traffic category, and wherein the third network node (107, 700) receives from the first network node (109, 600) the PFDs associated with a traffic category in response to the request.

23. The method of any one of claims from claim 21 to claim 22, further comprising: receiving at the first network node (109, 600) from the third network node (107, 700) a subscription request for PFDs associated with a traffic category, and wherein the first network node (109, 600) notifies to the third network node (107, 700) the PFDs associated with a traffic category when the first network node (109, 600) receives the PFDs associated with a traffic category from the second network node (113).

24. The method of any one of claims from claim 21 to claim 23, further comprising: transmitting from the first network node (109, 600) to a User Data Repository, UDR, the one or more PFDs associated with a traffic category; receiving at the first network node (109, 600) from the UDR one or more PFDs associated with a traffic category, in response to a request for PFDs associated with a traffic category from the fifth network node (111 ); and transmitting from the first network node (109, 600) to the third network node (107, 700) the received PFDs associated with a traffic category.

25. The method of any one of claims from claim 21 to claim 24, wherein the one or more PFDs associated with a traffic category are further associated with an application identifier.

26. The method of any one of claims from claim 21 to claim 25, wherein the first network node (109, 600) receives from the second network node (113) the PFDs through an Nnef Northbound API for PFD Management.

27. The method of any one of claims from claim 21 to claim 26, wherein the transmitting of the PFDs to the UDR includes storing the PFDs and their associated traffic category in the UDR.

28. The method of any one of claims from claim 21 to claim 27, wherein the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow, SDF, filter.

29. The method of any one of claims from claim 21 to claim 28, wherein the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow, SDF, filter.

30. The method of any one of claims from claim 21 to claim 29, wherein the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink.

31 . The method of any one of claims from claim 21 to claim 30, wherein the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink.

32. The method of any one of claims from claim 21 to claim 31 , wherein the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging.

33. The method of any one of claims from claim 21 to claim 32, wherein the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images.

34. The method of any one of claims from claim 21 to claim 33, wherein the one or more PFDs associated with a traffic category are received at the first network node (109, 600) from multiple second network node (113)s, and wherein the first network node (109, 600) aggregates the PFDs received from the multiple second network node (113)s.

35. The method of any one of claims from claim 21 to claim 34, wherein the first network node (109, 600) is a Network Exposure Function, NEF, the second network node (113) is an Application Function, AF, the third network node (107, 700) is a Session Management Function, SMF, the fourth network node (103, 800) is a User Plane Function, UPF, the fifth network node (111) is a Policy Control Function, PCF.

36. A method performed by a third network node (107, 700) for enabling traffic management on a per traffic category basis in a communications network, the method comprising: receiving at a third network node (107, 700) from a first network node (109, 600) one or more Packet Flow Descriptions, PFDs, associated with a traffic category; and transmitting from the third network node (107, 700) to a fourth network node (103, 800) the one or more PFDs associated with a traffic category.

37. The method of claim 36, further comprising: transmitting from the third network node (107, 700) to the first network node (109, 600) a request for PFDs associated with a traffic category, and wherein the third network node (107, 700) receives from the first network node (109, 600) the PFDs associated with a traffic category in response to the request.

38. The method of any one of claims from claim 36 to claim 37, further comprising: transmitting from the third network node (107, 700) to the first network node (109, 600) a subscription request for PFDs associated with a traffic category, and wherein the first network node (109, 600) notifies to the third network node (107, 700) the PFDs associated with a traffic category when the first network node (109, 600) receives the PFDs associated with a traffic category from the second network node (113).

39. The method of any one of claims from claim 36 to claim 38, further comprising: receiving at the third network node (107, 700) from a fifth network node (111) one or more Policy and Charging Control, PCC, rules including a traffic descriptor comprising a traffic category, wherein the PCC rules are based on Traffic Categories included in a user's subscription; and transmitting from the third network node (107, 700) to the fourth network node (103, 800) one or more Packet Detection Rules, PDRs, including the traffic descriptor comprising a traffic category.

40. The method of any one of claims from claim 36 to claim 39, further comprising: receiving at the third network node (107, 700) from the first network node (109, 600) one or more PFDs associated with a traffic category.

41 . The method of any one of claims from claim 36 to claim 40, wherein the one or more PFDs associated with a traffic category are further associated with an application identifier.

42. The method of any one of claims from claim 36 to claim 41 , wherein the method further comprises the third network node (107, 700) checking for previously stored PFD rules associated with the traffic category, and initiating a PFD Management pull procedure if the PFD rules are not found.

43. The method of any one of claims from claim 36 to claim 42, wherein the PFD Management pull procedure comprises the third network node (107, 700) transmitting a Nnef_PFDmanagement_Fetch message to the first network node (109, 600) to retrieve PFDs by a full pull or a partial pull service operation.

44. The method of any one of claims from claim 36 to claim 43, wherein the traffic descriptor in the PCC rules is separate from an application identifier and a Service Data Flow, SDF, filter.

45. The method of any one of claims from claim 36 to claim 44, wherein the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow, SDF, filter.

46. The method of any one of claims from claim 36 to claim 45, wherein the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink.

47. The method of any one of claims from claim 36 to claim 46, wherein the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink.

48. The method of any one of claims from claim 36 to claim 47, wherein the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging.

49. The method of any one of claims from claim 36 to claim 48, wherein the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images.

50. The method of any one of claims from claim 36 to claim 49, wherein the first network node (109, 600) is a Network Exposure Function, NEF, the second network node (113) is an Application Function, AF, the third network node (107, 700) is a Session Management Function, SMF, the fourth network node (103, 800) is a User Plane Function, UPF, the fifth network node (111) is a Policy Control Function, PCF.

51 . A method performed by a fourth network node (103, 800) for enabling traffic management on a per traffic category basis in a communications network, the method comprising: receiving at a fourth network node (103, 800) from a third network node (107, 700) one or more Packet Flow Descriptions, PFDs, associated with a traffic category; and applying at the fourth network node (103, 800) differentiated traffic management actions to the traffic based on the traffic category.

52. The method of claim 51 , further comprising: receiving at the fourth network node (103, 800) from the third network node (107, 700) one or more Packet Detection Rules, PDRs, including the traffic descriptor comprising a traffic category.

53. The method of any one of claims from claim 51 to claim 52, wherein the one or more PFDs associated with a traffic category are further associated with an application identifier.

54. The method of any one of claims from claim 51 to claim 53, wherein the traffic descriptor in the PDRs is separate from an application identifier and a Service Data Flow, SDF, filter.

55. The method of any one of claims from claim 51 to claim 54, wherein the traffic category indicates on demand downlink streaming, particularly indicating traffic pertaining to video content to be streamed in downlink.

56. The method of any one of claims from claim 51 to claim 55, wherein the traffic category indicates on demand uplink streaming, particularly indicating traffic pertaining to video content streamed by users in uplink.

57. The method of any one of claims from claim 51 to claim 56, wherein the traffic category indicates real time interactive traffic, particularly indicating traffic pertaining to instant messaging.

58. The method of any one of claims from claim 51 to claim 57, wherein the traffic category indicates internet traffic, particularly indicating traffic pertaining to content that is not video and not instant messaging, for example text and/or images.

59. The method of any one of claims from claim 51 to claim 58, wherein the differentiated traffic management actions include charging and Quality of Service, QoS, actions.

60. The method of any one of claims from claim 51 to claim 59, wherein the fourth network node (103, 800) detects the traffic category within an application session traffic by matching incoming packets with the PDR with a Packet Detection Indicator, PDI, of the type of traffic category based on the provisioned PFDs.

61 . The method of any one of claims from claim 51 to claim 60, wherein the first network node (109, 600) is a Network Exposure Function, NEF, the second network node (113) is an Application Function, AF, the third network node (107, 700) is a Session Management Function, SMF, the fourth network node (103, 800) is a User Plane Function, UPF, the fifth network node (111) is a Policy Control Function, PCF.

62. Apparatus for enabling traffic management on a per traffic category basis in a communications network, the apparatus comprising a processor and a memory, the memory containing instructions executable by the processor such that the apparatus is operable to perform the method of any one of claims from claim 21 to claim 35.

63. Apparatus for enabling traffic management on a per traffic category basis in a communications network, the apparatus comprising a processor and a memory, the memory containing instructions executable by the processor such that the apparatus is operable to perform the method of any one of claims from claim 36 to claim 50.

64. Apparatus for enabling traffic management on a per traffic category basis in a communications network, the apparatus comprising a processor and a memory, the memory containing instructions executable by the processor such that the apparatus is operable to perform the method of any one of claims from claim 51 to claim 61 .

65. A system comprising an apparatus as claimed in claim 62, an apparatus as claimed in claim 63, and an apparatus as claimed in claim 64.

66. A computer-implemented system comprising one or more processors and one or more computer storage media storing computer-usable instructions that, when used by the one or more processors, cause the one or more processors to perform a method according to any one of claims from claim 21 to claim 61 .

67. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform a method according to any of claims from claim 21 to claim 61 .

68. A computer program product, embodied on a non-transitory machine-readable medium, comprising instructions which are executable by a processor, causing the processor to perform the method according to any of claims from claim 21 to claim 61 .