Optimization procedure for pfd management

Abstract

Embodiments herein relate to optimization procedures for packet flow description (PFD) management. In one embodiment, a method (800) for managing packet flow description (PFD) is proposed, comprising: receiving (S801), from a session management function (SFM) (201) or a user plane function (UPF) (302), a requirement message indicating a requirement for at least one PFD rule for an application; detecting (S802) the at least one PFD rule for the application; and notifying (S803) the SMF (201) or the UPF (302) of information about the at least one PFD rule. Embodiments herein can implement optimization procedures for PFD management that optimize the delivery of PFD rules by reducing the amount of signaling and by reducing the number of hops between producers (AFs) and consumers (UPFs).

Description

TECHNICAL FIELD

[0001] Embodiments herein generally relate to the field of wireless communication, and more particularly, embodiments herein relate to an optimization procedure for PFD management. BACKGROUND

[0002] Figure 1 is a schematic block diagram illustrating a 5G reference architecture as defined by 3GPP. As shown in Figure 1 the 5G reference architecture can comprise the following network nodes:

[0003] • AF (Application Function);

[0004] • NEF (Network Exposure Function);

[0005] • SMF (Session Management Function);

[0006] • UPF (User Plane Function).

[0007] AF (Application Function)

[0008] The Application Function (AF) interacts with the 3GPP core network in order to facilitate the provision of services, and in particular, in the context of the present disclosure, in order to facilitate the provision of PFD rules that will allow the network operator to classify the traffic of applications.

[0009] NEF (Network Exposure Function)

[0010] The Network Exposure Function (NEF) supports different functionalities, and in particular, in the context of the present disclosure, the NEF supports a PFD management service that allows the NEF to receive PFD rules from the AF, store them in the UDR and provide them to the SMF.

[0011] SMF (Session Management Function)

[0012] The Session Management Function (SMF) supports different functionalities, and in particular, in the context of the present disclosure, the SMF is able to fetch PFD rules for an application from the NEF (PFD management service). The SMF can also subscribe to the NEF on notifications of PFD data about different applications, either to a specific list or to all of them. The SMF also supports a PFCP PFD management procedure in order to provide PFD rules to the UPF.

[0013] UPF (User Plane Function)

[0014] The User Plane Function (UPF) supports different functionalities and, in particular, in the context of the present disclosure, the UPF supports the handling of user plane traffic, including packet inspection, where either the rules to detect the traffic of an application are provided locally in the UPF or the rules to detect the traffic of an application are received from the SMF through the PFCP PFD management procedure.

[0015] PFD management

[0016] As part of 3GPP Rel14, a mechanism has been standardized to exchange user traffic classification rules (in the form of PFDs) between a content provider / multiple content providers and an operator network / multiple operator networks. 3GPP TS 29.122 defines the T8 interface between a SCS / AS (content provider) and a Service Capability Exposure Function (SCEF) in the operator network's packet core and specifically defines the T8 APIs for PFD management in section "4.4.10 Procedures for PFD Management". In addition, a new entity called PFDF has been standardized for this purpose.

[0017] PFDs are provided from the content provider (SCS / AS) to the operator network packet core through the SCEF and stored in the PFDF. A PFD describes different types of traffic used by the content provider application and is exchanged with the network e.g. to implement a zero-rating or QoS use case (i.e. identify the content provider's traffic and not deduct from the user's quota or apply a better QoS than the default traffic).

[0018] Examples of PFDs include destination IPv4 or IPv6 addresses (all traffic matching to those addresses through the PFD) or HTTP URLs.

[0019] In 3GPP Rel15, as part of the 5G network architecture, as shown in Figure 2 Figure 1, the above mechanism has been ported and with the following modifications:

[0020] - AF (instead of SCS / AS)

[0021] - NEF (instead of SCEF)

[0022] - PFD management service in the NEF (instead of PFDF entity)

[0023] - UPF (instead of TDF-U or PGW-U)

[0024] - Storage of PFDs in the UDR (instead of storing them at the PFDF entity).

[0025] References:

[0026] 3GPP TS 29.551 V16.3.0 (March 2020) 5G System; Packet Flow Description Management Service; Stage 3. SUMMARY

[0027] The following issues are identified in the existing 5GC PFD management:

[0028] • PFD rules for most applications (e.g. Facebook) have a huge size (e.g. typically including thousands of server IP addresses).

[0029] • The existing mechanism to transfer PFD rules from a content provider to a network operator is not efficient in terms of signaling and in terms of the number of hops between producer (AF) and consumer (UPF).

[0030] In view of the above issues in the existing 5GC PFD management, the embodiments herein propose mechanisms to solve the above issues as follows:

[0031] • Support for UPF as consumer is added for the NEF PFD management service (through the Nnef Southbound API for PFD management). The current SMF is the only consumer.

[0032] • Optimized Nnef Southbound API for PFD management consists of:

[0033] • Optimized push procedure: by proposing a notification push where the UPF subscribes the NEF on PFD notifications for a list of appIds. And the NEF notifies the UPF accordingly but does not transfer the PFDs (so let the UPF to decide to retrieve them or not).

[0034] • Optimized pull procedure: by proposing the UPF to request the NEF for PFD rules for a list of appIds and indicate in the request either interest for partial update (according to a baseline) or for full update. In case of partial update, the UPF indicates the baseline so the NEF is able to return partial update on that baseline.

[0035] • Optimized combined push-pull procedure: by proposing the UPF to subscribe the NEF on PFD notifications for a list of appIds and to pull partial PFDs when needed (e.g. during O&M maintenance window or at PDU session establishment with PCC rules with a certain appId).

[0036] In one embodiment, a method for managing packet flow descriptions (PFDs) is proposed, comprising: receiving a demand message from a user plane node, the demand message indicating a demand for at least one PFD rule for an application; detecting the at least one PFD rule for the application; and informing the user plane node about the at least one PFD rule.

[0037] In one embodiment, the method further comprises: receiving one or more PFD rules for one or more applications from a content providing node; associating a baseline with the one or more PFD rules for the application.

[0038] In one embodiment, the method further comprises: requesting a PFD storage node to store the one or more PFD rules for the application and the associated baseline.

[0039] In one embodiment, the demand message indicates a subscription to a PFD management service, the demand message including a baseline or not including a baseline; the demand message further including a push notification demand.

[0040] In one embodiment, detecting the at least one PFD rule further comprises: detecting a changed PFD rule based on the baseline associated with the one or more PFD rules received from the content providing node and the baseline received in the demand message from the user plane node.

[0041] In one embodiment, the demand message indicates a request for a PFD management service, the demand message including a baseline or not including a baseline.

[0042] In one embodiment, detecting the at least one PFD rule further comprises: querying a PFD storage node for the at least one PFD rule based on the baseline received in the demand message from the user plane node; receiving a changed PFD rule from the PFD storage node.

[0043] In one embodiment, informing the user plane node about the at least one PFD rule further comprises: informing the changed PFD rule and the latest baseline.

[0044] In one embodiment, informing the user plane node about the at least one PFD rule further comprises: transmitting the changed PFD rule along with the notification; or notifying the existence of the changed PFD rule.

[0045] In one embodiment, the above method is performed at a network exposure function (NEF) or service capability exposure function (SCEF); wherein the user plane node is a user plane function (UPF), traffic detection function user plane function (TDF-U), or PDN gateway user plane function (PGW-U); wherein the PFD storage node is a unified data repository (UDR) or a packet flow description function (PFDF) entity; wherein the content providing node is an application function (AF) or service capability server (SCS) / application server (AS); and wherein the baseline is a version reference or a timestamp.

[0046] In another embodiment, a method for managing packet flow descriptions (PFDs) is proposed, comprising: transmitting a requirement message indicating a requirement for at least one PFD rule for an application to a network exposure node; receiving information about the at least one PFD rule from the network exposure node.

[0047] In one embodiment, the requirement message indicates a subscription for a PFD management service, the requirement message includes a baseline or does not include a baseline; the requirement message further includes a push notification requirement.

[0048] In one embodiment, the requirement message indicates a request for a PFD management service, the requirement message includes a baseline or does not include a baseline.

[0049] In one embodiment, receiving the information about the at least one PFD rule from the network exposure node further comprises: receiving a latest baseline and a changed PFD rule relative to a PFD rule associated with the baseline in the requirement message.

[0050] In one embodiment, receiving the information about the at least one PFD rule from the network exposure node further comprises: receiving a changed PFD rule; or receiving a notification about existence of a changed PFD rule.

[0051] In one embodiment, the method further comprises: retrieving the notified PFD rule during an operation and maintenance (O&M) maintenance window or at packet data unit (PDU) session establishment.

[0052] In one embodiment, the method is performed at a user plane function (UPF), traffic detection function user plane function (TDF-U), or PDN gateway user plane function (PGW-U); wherein the network exposure node is a network exposure function (NEF) or service capability exposure function (SCEF); and wherein the baseline is a version reference or a timestamp.

[0053] In yet another embodiment, a method for managing packet flow description (PFD) is proposed, comprising: receiving a storage request to store at least one PFD rule and an associated baseline for an application; storing the at least one PFD rule and the associated baseline.

[0054] In one embodiment, the method further comprises: receiving a query request with an associated baseline; comparing the baseline associated with the query request and the stored baseline; and providing a changed PFD rule based on the comparison and the stored baseline.

[0055] In one embodiment, the above method is performed at a unified data repository (UDR) or a packet flow description function (PFDF) entity; and wherein the baseline is a version reference or a timestamp.

[0056] In yet another embodiment, an apparatus for managing packet flow description (PFD) is proposed, comprising: at least one processor; and a non-transitory computer readable medium coupled to the at least one processor, the non-transitory computer readable medium containing instructions executable by the at least one processor, whereby the at least one processor is configured to: receive, from a user plane node, a requirement message indicating a requirement for at least one PFD rule for an application; detect the at least one PFD rule for the application; and inform the user plane node of information about the at least one PFD rule.

[0057] In one embodiment, the at least one processor is further configured to: receive, from a content providing node, one or more PFD rules for one or more applications; associate a baseline with the one or more PFD rules for the application.

[0058] In one embodiment, the at least one processor is further configured to: request a PFD storage node to store the one or more PFD rules for the application and the associated baseline.

[0059] In one embodiment, the requirement message indicates a subscription to a PFD management service, the requirement message includes the baseline or does not include the baseline; the requirement message further includes a push notification requirement.

[0060] In one embodiment, when the at least one PFD rule is detected, the at least one processor is further configured to: detect a changed PFD rule based on the baseline associated with the one or more PFD rules received from the content providing node and the baseline received in the requirement message from the user plane node.

[0061] In one embodiment, the requirement message indicates a request for a PFD management service, the requirement message includes the baseline or does not include the baseline.

[0062] In one embodiment, when at least one PFD rule is detected, at least one processor is further configured to: query a PFD storage node for at least one PFD rule based on a baseline received in a demand message from a user plane node; and receive the modified PFD rule from the PFD storage node.

[0063] In one embodiment, when information about at least one PFD rule is notified to a user plane node, at least one processor is further configured to: notify the changed PFD rule and the latest baseline.

[0064] In one embodiment, when notifying a user plane node of information about at least one PFD rule, at least one processor is further configured to: transmit the changed PFD rule along with the notification; or notify of the existence of the changed PFD rule.

[0065] In one embodiment, the above device is implemented in a Network Open Function (NEF) or Service Capability Open Function (SCEF); wherein the user plane node is a User Plane Function (UPF), a Service Detection Function User Plane Function (TDF-U), or a PDN Gateway User Plane Function (PGW-U); wherein the PFD storage node is a Unified Data Repository (UDR) or Packet Flow Description Function (PFDF) entity; wherein the content providing node is an Application Function (AF) or a Service Capability Server (SCS) / Application Server (AS); and wherein the baseline is a version reference or timestamp.

[0066] In another embodiment, an apparatus for managing packet flow descriptions (PFDs) is proposed, comprising: at least one processor; and a non-transitory computer-readable medium coupled to the at least one processor, the non-transitory computer-readable medium containing instructions executable by the at least one processor, wherein the at least one processor is configured to: transmit a request message indicating a need for at least one PFD rule for an application to a network open node; and receive information about the at least one PFD rule from the network open node.

[0067] In one embodiment, the demand message indicates a subscription to the PFD management service, and the demand message may or may not include a baseline; the demand message further includes push notification demands.

[0068] In one embodiment, the request message indicates a request for the PFD management service, and the request message may or may not include a baseline.

[0069] In one embodiment, when information about at least one PFD rule is received from a network open node, at least one processor is further configured to receive the latest baseline and the PFD rule that has changed relative to the baseline in the demand message.

[0070] In one embodiment, the at least one processor is further configured to, when receiving the information about the at least one PFD rule from the network exposure node: receive a changed PFD rule; or receive a notification about existence of a changed PFD rule.

[0071] In one embodiment, the at least one processor is further configured to retrieve the notified PFD rule during an operation and maintenance (O&M) maintenance window or at packet data unit (PDU) session establishment.

[0072] In one embodiment, the above apparatus is implemented in a user plane function (UPF) or PDN gateway user plane function (PGW-U); wherein the network exposure node is a network exposure function (NEF) or service capability exposure function (SCEF); and wherein the baseline is a version reference or a timestamp.

[0073] In yet another embodiment, an apparatus for managing packet flow descriptions (PFDs) is presented, comprising: at least one processor; and a non-transitory computer readable medium coupled to the at least one processor, the non-transitory computer readable medium containing instructions executable by the at least one processor, whereby the at least one processor is configured to: receive a storage request to store at least one PFD rule and an associated baseline for an application; store the at least one PFD rule and the associated baseline.

[0074] In one embodiment, the at least one processor is further configured to: receive a query request with an associated baseline; compare the baseline associated with the query request and the stored baseline; and provide a changed PFD rule based on the comparison and the stored baseline.

[0075] In one embodiment, the above apparatus is implemented in a unified data repository (UDR) or packet flow description function (PFDF) entity; and the baseline is a version reference or a timestamp.

[0076] In yet another embodiment, a computer readable medium comprising computer readable code which, when run on an apparatus, causes the apparatus to perform any of the above methods is presented.

[0077] With the embodiments herein, the following advantages can be achieved:

[0078] • The embodiments herein can allow network operators to support PFD management procedures in a very efficient way by optimizing the delivery of PFD rules, by reducing the amount of signaling, and by reducing the number of hops between producer (AF) and consumer (UPF).

[0079] • The embodiments herein can remove the signaling, processing and memory impact related to PFD management in the SMF, increasing its available capacity to handle PFCP management procedures.

[0080] • The embodiments herein can reduce the signaling requirements related to PFD management by half in an operator network.

[0081] • The embodiments herein can prevent overloading of the receiver of the PFD management information and the communication channel between the producer and the receiver. Thus, the impact on the NEF is also minimized. BRIEF DESCRIPTION OF DRAWINGS

[0082] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate various embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the relevant art to make and use the embodiments disclosed herein. In the drawings, like reference numerals indicate the same or functionally similar elements, and wherein:

[0083] Figure 1 is a schematic block diagram illustrating a 5G reference architecture as defined by 3GPP;

[0084] Figure 2 is a schematic block diagram illustrating 5GC PFD management;

[0085] Figure 3 is a schematic block diagram illustrating an example communication system in which the embodiments herein can be implemented;

[0086] Figures 4A-4B is a schematic sequence diagram illustrating a proposed push procedure according to embodiments herein;

[0087] Figure 5 is a schematic sequence diagram illustrating proposed PFD storage in the UDR according to embodiments herein;

[0088] Figures 6A-6B is a schematic sequence diagram illustrating a proposed pull procedure according to embodiments herein;

[0089] Figures 7A-7C is a schematic sequence diagram illustrating a proposed combined push-pull procedure according to embodiments herein;

[0090] Figure 8 is a schematic flow diagram illustrating an example PFD management method in the NEF according to embodiments herein;

[0091] Figure 9 is a schematic flow diagram illustrating an example PFD management method in the UDR according to embodiments herein;

[0092] Figure 10 is a schematic flow chart illustrating an example PFD management method in a UPF according to embodiments herein;

[0093] Figure 11 is a schematic block diagram illustrating an example PFD management device in a NEF according to embodiments herein;

[0094] Figure 12 is a schematic block diagram illustrating an example PFD management device in a UDR according to embodiments herein;

[0095] Figure 13 is a schematic block diagram illustrating an example PFD management device in a UPF according to embodiments herein;

[0096] Figure 14 is a schematic block diagram illustrating an example computer-implemented device according to embodiments herein. DETAILED DESCRIPTION

[0097] Embodiments herein will be described in the following description with reference to the drawings. However, the embodiments herein can be implemented in many different forms and should not be construed as limited to the embodiments set forth herein. The elements in the drawings are not necessarily to scale, relative to each other.

[0098] Reference to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

[0099] As used herein, the term “A, B, or C” means “A” or “B” or “C”; the term “A, B, and C” means “A” and “B” and “C”; and the term “A, B, and / or C” means “A”, “B”, “C”, “A and B”, “A and C”, “B and C”, or “A, B, and C”.

[0100] Embodiments herein propose an optimization procedure for PFD management that optimizes the delivery of PFD rules by reducing the amount of signaling and by reducing the number of hops between producer (AF) and consumer (UPF).

[0101] Figure 3 is a schematic block diagram illustrating an example communication system in which embodiments herein can be implemented.

[0102] In an example communication system of one embodiment, as Figure 3As illustrated in the middle, the proposed solution is based on different extensions of the Nnef Southbound API for PFD management, in particular:

[0103] • Added support for UPF as consumer for the NEF PFD management service (through the Nnef Southbound API for PFD management). The current SMF 201 is the only consumer.

[0104] • Optimized Nnef Southbound API for PFD management consists of:

[0105] • Optimized push procedure: by the proposed notification push, where the UPF subscribes the NEF on PFD notifications for a list of appIds. And the NEF accordingly notifies the UPF but does not deliver the PFDs (so let the UPF to decide to retrieve them or not). In addition, the UPF can subscribe the NEF on PFD deltas (regarding a certain baseline) for a list of appIds.

[0106] • Optimized pull procedure: by the proposed UPF requests the NEF for PFD rules for a list of appIds and indicates in the request either interest for partial updates or for full updates. In case of partial updates, the UPF indicates a baseline, so the NEF can return partial updates regarding that baseline.

[0107] • Optimized combined push-pull procedure: by the proposed UPF subscribes the NEF on PFD notifications for a list of appIds, and when needed (e.g. during O&M maintenance window or at PDU session establishment with PCC rules with a certain appId), the UPF pulls partial PFDs.

[0108] Optimized push procedure

[0109] Figures 4A-4B is a schematic sequence diagram illustrating the proposed push procedure according to embodiments herein. The steps are detailed below:

[0110] Step 1) The AF provides PFD rules for a set of applications (e.g. examplel.com, example2.com) through the Nnef Northbound API for PFD management by triggering an HTTP POST request including Afld, (appId = examplel.com, PFDs), (appId = example2.com, PFDs).

[0111] It is assumed that there is a NEF serving the AF (i.e. the AF provides PFDs for a certain application towards that NEF).

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

[0113] Steps 3, 4 and 5) The NEF (PFD Management service) requests the UDR to store the PFD received in step 1 for the application. The NEF establishes a baseline for the PFD on a per application basis (e.g. baseline 1 as this is the first version of the PFD from the AF). The baseline can be a version reference or a timestamp. The UDR stores the PFD and acknowledges the request (indicating a successful operation).

[0114] Steps 6 and 7) The UPF subscribes to the NEF PFD Management service in order to retrieve PFD rules for a certain set of applications. It is proposed that the UPF is configured with two different lists of appId:

[0115] • A list of appId corresponding to commonly used applications (e.g. Facebook, YouTube, Netflix, etc.).

[0116] • A list of appId corresponding to less commonly used applications.

[0117] Based on the above, it is proposed that the UPF subscribes to the two lists above as follows:

[0118] • For the first list above, the UPF subscribes in order to retrieve PFDs (in case the UPF has a previously stored version of the PFD for a certain appId, the UPF indicates the baseline in order to retrieve the delta, i.e. the updated PFD with respect to the baseline).

[0119] • For the second list above, the UPF only subscribes in order to receive an indication about the presence of PFDs (in case the UPF has a previously stored version of the PFD for a certain appId, the UPF indicates the baseline in order to receive an indication about the presence of updated PFDs with respect to that baseline).

[0120] In order to do this, it is proposed to extend the Nnef southbound API for PFD management (push procedure) as follows:

[0121] • On a per-appId basis and depending on the baseline, the UPF requests either the PFD or just an indication about the presence of an updated PFD.

[0122] In this example, the UPF triggers a HTTP POST message indicating a subscription operation to the PFD Management service (Nnef_PFDManagement_Subscribe) and including as parameters:

[0123] • appId = example1.com, baseline = no_baseline, push notification

[0124] • appId = example2.com, baseline = no_baseline

[0125] In this example, the UPF indicates no_baseline as it does not have a previously stored PFD for the appId.

[0126] It is assumed that there is a NEF serving the AF (i.e. the AF provides a PFD for a certain application towards that NEF) and that UPF discovers that NEF on a per application basis.

[0127] Step 8) After receiving the message in the previous step, the NEF replies to the UPF with a Nnef 200 OK success response.

[0128] Step 9) The NEF (PFD Management service) triggers a Nudr_Query request message towards the UDR to enquire whether there is an updated PFD (according to baseline) for appId = example1.com and to directly retrieve the updated PFD (according to baseline) for appId = example2.com.

[0129] Steps 10 and 11) The UDR checks whether there is an updated PFD (according to baseline) for appId = example1.com and appId = example2 and for the last one it directly retrieves the updated PFD (according to baseline) and indicates the latest baseline (baseline1): (appId = example1.com, PFD presence = YES), (appId = example2.com, PFDs, baseline = baseline1).

[0130] Steps 12 and 13) The NEF notifies the consumer (UPF) by triggering a Nnef_PFDManagement_Notify message indicating that there is an updated PFD rule (according to baseline) for appId = example1.com and delivering the updated PFD rule (according to baseline) for appId = example2.com and the latest baseline, the Nnef_PFDManagement_Notify message including: (appId = example1.com, PFD Presence = YES), (appId = example2.com, PFDs, baseline = baseline1).

[0131] Steps 14 and 15) The UPF stores the information received in the previous steps (e.g. it can later retrieve updated PFDs for appId = examplel.com during an O&M maintenance window) and replies to the NEF with a Nnef 200 OK success response.

[0132] Step 16) The AF provides the updated PFD rules for the set of applications (e.g. examplel.com, example2.com) by triggering an HTTP POST request including Afld, (appId = examplel.com, PFDs), (appId = example2.com, PFDs) through the Nnef Northbound API for PFD management.

[0133] Step 17) The NEF (PFD management service) acknowledges the request with a Nnef 200 OK message.

[0134] Steps 18, 19 and 20) The NEF (PFD management service) requests the UDR to store the PFDs for the applications received in step 14 above. The NEF establishes a new baseline for the PFDs on a per application basis (e.g. baseline2 as this is the second version of the PFDs from the AF). The baseline can be a version reference or a timestamp. The UDR stores the PFDs and acknowledges the request (indicating a successful operation).

[0135] Steps 21 and 22) The NEF notifies the consumers (UPF) as follows: a push notification for appId = examplel.com (indicating that there are delta PFD rules with respect to the previous baseline = baseline1) and a push including the latest baseline (baseline2) and delta PFDs (between baseline1 and baseline2) for appId = example2.com. To do this, the NEF triggers a Nnef PFDManagement Notify message towards the UPF including: (appId = examplel.com, PFD Presence = YES), (appId = example2.com, baseline = baseline2, Delta PFDs).

[0136] Note that, Figure 4A and 4B The AF, UDR, NEF, UPF in Figure 3 may be configured as the AF 304, UDR 303, NEF 301 and UPF 302 in

[0137] Optimized pull procedure

[0138] The proposed embodiment is based on PFD storage in UDR including a corresponding baseline. Figure 5 is a schematic sequence diagram illustrating the proposed PFD storage in UDR according to embodiments herein. The steps are detailed below:

[0139] Step 1) The AF provides PFD rules for a certain application (e.g. example1.com) through the Nnef northbound API for PFD management by triggering an HTTP POST request including Afld, (appId = example1.com, PFDs).

[0140] It is assumed that there is a NEF serving the AF (i.e. the AF provides PFDs for a certain application towards that NEF).

[0141] Step 2) The NEF (PFD management service) acknowledges the request with a Nnef 200 OK message.

[0142] Steps 3 and 4) The NEF sets a baseline (baseline 1) for the PFD received in step 1 above and requests the UDR to store the PFDs for the application (example.com) including the baseline (baseline 1). The baseline can be a version reference or a timestamp.

[0143] Steps 5 and 6) The UDR stores the PFDs together with the corresponding baseline (baseline 1) as application data (appId = example.com) and acknowledges the request (indicates successful operation).

[0144] Step 7) After some time (e.g. 1 week), the AF provides updated PFD rules for the application (e.g. example1.com) through the Nnef northbound API for PFD management by triggering an HTTP PUT request including Afld, (appId = example1.com, PFDs).

[0145] Step 8) The NEF (PFD management service) acknowledges the request with a Nnef 200 OK message.

[0146] Steps 9 and 10) The NEF sets a new baseline (baseline 2) for the PFD received in step 7 above and requests the UDR to store the PFDs for the application (example.com) including the baseline (baseline 2).

[0147] Steps 11 and 12) The UDR stores the PFDs together with the corresponding baseline (baseline 2) as application data (appId = example.com) and acknowledges the request (indicates successful operation).

[0148] It is noted that, Figure 5 The AF, UDR, NEF, UPF in Figure 3 The AF 304, UDR 303, NEF 301 and UPF 302 in

[0149] Figures 6A-6B is a schematic sequence diagram illustrating the proposed pull procedure according to embodiments herein. The steps are detailed below:

[0150] Precondition: According to Baseline 1, the UPF has a PFD stored for appId = example.com (see above Figure 5 ).

[0151] Steps 1 and 2) The UE triggers PDU session establishment by means of sending a PDU session establishment request to the AMF. The AMF selects a SMF to manage the PDU session (the SMF selection function in the AMF selects a SMF instance based on available SMF instances obtained from the NRF or based on configured SMF information in the AMF) and triggers Nsmf PDU Session Create. It is noted that, Figure 5 The sequence diagram in

[0152] Step 3) The SMF triggers a Npcf SMPolicyControl Create request message to retrieve the SM policy for the user PDU session.

[0153] Step 4) The PCF triggers a Nudr Query request message to retrieve the policy data for this user PDU session.

[0154] Step 5) The UDR answers with a Nudr Query response message including the subscriber policy data.

[0155] Step 6) The PCF generates the corresponding PCC rule(s) based on the subscriber policy data.

[0156] Step 7) Based on the above, the PCF triggers a Npcf SMPolicyControl Create response message including the PCC rule to be applied for this user PDU session. In this case, there will be a PCC rule for appId = example.com including some enforcement actions (charging and QoS).

[0157] Step 8) SMF selects UPF and triggers a PFCP Session Establishment Request message including the corresponding PDR / FAR / QER / URR. In this case, there will be a PDR with a PDI of type Application with appId = example.com and the corresponding FAR, QER and URR.

[0158] Step 9) UPF stores the PDR / FAR / QER / URR and answers to SMF with a PFCP Session Establishment Response message.

[0159] Steps 10 and 11) Based on the PDR received in step 8 above, in this case, PDR with appId = example.com, the UPF checks if it has previously stored a PFD rule for appId = example.com (from any previous request). In this example, the UPF has stored a PFD rule according to baseline 1 and proposes the UPF to trigger a request to the NEF PFD Management service for appId = example.com indicating a "partial get request" and including the baseline (baseline 1), i.e. the UPF requests only the delta between baseline 1 and the latest baseline (baseline 2 in this example) (new, updated, removed PFDs).

[0160] Assuming there is a NEF serving the AF (i.e. the AF provides PFDs for a certain application towards the NEF) and that UPF discovers that NEF on a per application basis.

[0161] Step 12) NEF (PFD Management service) triggers a Nudr_Query request message to the UDR including the baseline (baseline 1) to retrieve the delta PFDs for appId = example.com.

[0162] Steps 13 and 14) UDR retrieves the PFDs for the requested appId (example.com) but retrieves only the delta according to baseline 1 (i.e. the PFDs between the requested baseline (baseline 1) and the latest baseline (baseline 2)). UDR answers with a Nudr_Query response message including the delta PFDs and the latest baseline (baseline 2).

[0163] Step 15) After receiving the messages in previous steps, NEF replies to the UPF with a Nnef200 OK success response including the delta PFDs and the latest baseline (baseline 2).

[0164] Steps 16 and 17) The UPF merges the delta PFD with its stored PFD for the target application (example.com) and the latest baseline (baseline 2) for future requests. The UPF replies to the NEF with a Nnef 200 OK success response.

[0165] Steps 18 and 19) The user opens the example.com application. The UPF detects the example.com traffic by matching the incoming packets with a PDR having a type application with appId = example.com (with the latest PFD) and applies the corresponding enforcement actions (charging, QoS) indicated in the FAR, QER and URR.

[0166] Step 20) The UPF forwards the traffic to the application server according to the FAR.

[0167] Note that, Figure 6A and 6B The AF, UDR, NEF, UPF in Figure 3 The AF 304, UDR 303, NEF 301 and UPF 302 in

[0168] Optimized combined push-pull procedure

[0169] Figures 7A-7C is a schematic sequence diagram illustrating the proposed combined push-pull procedure according to embodiments herein. The steps are detailed below:

[0170] Step 1) The AF provides PFD rules for a set of applications (e.g. examplel.com, example2.com) through an HTTP POST request including Afld, (appId = examplel.com, PFDs), (appId = example2.com, PFDs) through the Nnef northbound API for PFD management.

[0171] It is assumed that there is a NEF serving the AF (i.e. the AF provides PFDs for a certain application towards that NEF).

[0172] Step 2) The NEF (PFD management service) acknowledges the request with a Nnef 200 OK message.

[0173] Steps 3 and 4) The NEF sets a baseline (baseline 1) for the PFDs received in step 1 above and requests the UDR to store the PFDs for the applications including the baseline (baseline 1). The baseline can be a version reference or a timestamp.

[0174] Steps 5 and 6) The UDR stores the PFD along with the corresponding baseline (baseline 1) as application data and acknowledges the request (operation indicating success).

[0175] Steps 7 and 8) The UPF subscribes to the NEF PFD Management service in order to retrieve PFD rules for a certain set of applications. It proposes that the UPF is configured with two different lists of appId:

[0176] • A list of appId corresponding to commonly used applications (e.g. Facebook, YouTube, Netflix, etc.).

[0177] • A list of appId corresponding to less commonly used applications.

[0178] Based on the above, the UPF subscribes to the two lists above as follows:

[0179] • For the first list above, the UPF subscribes in order to retrieve PFDs (in case the UPF has a previously stored version of the PFD for a certain appId, the UPF indicates the baseline in order to retrieve the delta, i.e. the updated PFD with respect to the baseline).

[0180] • For the second list above, the UPF only subscribes in order to receive an indication about the presence of an updated PFD (in case the UPF has a previously stored version of the PFD for a certain appId, the UPF indicates the baseline in order to receive an indication about the presence of an updated PFD with respect to that baseline).

[0181] To do this, it is proposed to extend the Nnef Southbound API for PFD Management (Push procedure) as follows:

[0182] • On a per-appId basis and depending on the baseline, the UPF requests either the PFD or just an indication about the presence of an updated PFD.

[0183] In this example, the UPF triggers a HTTP POST message indicating a subscription operation to the PFD Management service (Nnef_PFDManagement_Subscribe) and including as parameters:

[0184] • appId = example1.com, baseline = no_baseline, push notification

[0185] • appId = example2.com, baseline = no_baseline

[0186] In this example, as the UPF does not have a previously stored PFD for the appId, the UPF indicates no_baseline.

[0187] It is assumed that there is a NEF serving the AF (i.e. the AF provides a PFD for a certain application towards that NEF) and that UPF discovers that NEF on a per application basis.

[0188] Step 9) Upon reception of the message in the previous step, the NEF replies to the UPF with a Nnef 200 OK success response.

[0189] Step 10) The NEF (PFD Management service) triggers a Nudr_Query request message towards the UDR to enquire whether there is an updated PFD (according to baseline) for appId = examplel.com and to directly retrieve the updated PFD (according to baseline) for appId = example2.com.

[0190] Steps 11 and 12) The UDR checks whether there is an updated PFD (according to baseline) for appId = examplel.com and appId = example2 and for the last one, it directly retrieves the updated PFD (according to baseline) and indicates the latest baseline (baseline 1): (appId = examplel.com, PFD presence = YES), (appId = example2.com, PFDs, baseline = baseline 1).

[0191] Steps 13 and 14) The NEF notifies the consumer (UPF) by triggering a Nnef PFDManagement_Notify message indicating that there is an updated PFD rule (according to baseline) for appId = examplel.com and delivering the updated PFD rule (according to baseline) for appId = example2.com and the latest baseline, the Nnef PFDManagement_Notify message including: (appId = examplel.com, PFD Presence = YES), (appId = example2.com, PFDs, baseline = baseline 1).

[0192] Steps 15 and 16) The UPF stores the information received in the previous steps (e.g. it can later retrieve the updated PFD for appId = examplel.com during an O&M maintenance window) and replies to the NEF with a Nnef 200 OK success response.

[0193] Steps 17 and 18) The UE triggers PDU session establishment by means of sending a PDU session establishment request to the AMF. The AMF selects a SMF to manage the PDU session (the SMF selection function in the AMF selects a SMF instance based on available SMF instances obtained from the NRF or based on configured SMF information in the AMF) and triggers Nsmf PDU Session Create. Note that, Figures 7A-7C The sequence diagram in Figure 1 does not include all the signaling messages involved in the PDU session establishment procedure. The relevant signaling messages of the present disclosure are described in the following steps.

[0194] Step 19) The SMF triggers a Npcf_SMPolicyControl_Create request message to retrieve the SM policy for the user PDU session.

[0195] Step 20) The PCF triggers a Nudr_Query request message to retrieve the policy data for this user PDU session.

[0196] Step 21) The UDR answers with a Nudr_Query response message including the subscriber policy data.

[0197] Step 22) The PCF generates the corresponding PCC rule(s) based on the subscriber policy data.

[0198] Step 23) Based on the above, the PCF triggers a Npcf_SMPolicyControl_Create response message including the PCC rule(s) to be applied to this user PDU session. In this case, there will be a PCC rule for appId = examplel.com including some enforcement actions (charging and QoS) and another PCC rule for appId = example2.com including some enforcement actions (charging and QoS).

[0199] Step 24) The SMF selects a UPF and triggers a PFCP session establishment request message including the corresponding PDR / FAR / QER / URR. In this case, there will be a PDR with PDI for the type of application with appId = examplel.com and the corresponding FAR, QER and URR and another PDR with PDI for the type of application with appId = example2.com and the corresponding FAR, QER and URR.

[0200] Step 25) The UPF stores the PDR / FAR / QER / URR and answers to the SMF with a PFCP session establishment response message.

[0201] Steps 26 and 27) Based on the PDRs received in step 24 above, in this case, the PDR has appId = examplel.com and another PDR has appId = example2.com, the UPF checks if it has previously stored PFD rules for those applications (from any previous request). In this example, the UPF has stored PFD rules for appId = example2.com (and no PFD push notification, so they are updated). In addition, the UPF does not have stored PFD rules for appId = examplel.com (but knows that there are PFD rules to retrieve), so it triggers a request to the NEF PFD management service to retrieve them. Alternatively, the UPF can retrieve the PFD rules later, in order to avoid signaling overload.

[0202] Step 28) The NEF (PFD management service) triggers a Nudr_Query request message to the UDR by including the baseline (no_baseline) to retrieve the PFD for appId = examplel.com.

[0203] Steps 29 and 30) The UDR retrieves the PFD for the requested appId (examplel.com). The UDR answers with a Nudr_Query response message including the PFD and the latest baseline (baseline 1).

[0204] Step 31) After receiving the messages in previous steps, the NEF replies to the UPF with a Nnef200 OK success response including the PFD and the latest baseline (baseline 1).

[0205] Steps 32 and 33) The UPF stores the PFD for the application (examplel.com) and stores the new baseline (baseline 1) for future requests. The UPF replies to the NEF with a Nnef200 OK success response.

[0206] Steps 34 and 35) The user opens the examplel.com application. The UPF detects the examplel.com traffic by matching the incoming packets with the PDR having type application with appId = examplel.com (with the latest PFD) and applies the corresponding enforcement actions (charging, QoS) indicated in the FAR, QER and URR.

[0207] Step 36) The UPF forwards the traffic to the application server according to the FAR.

[0208] Steps 37 and 38) The user opens the example2.com application. The UPF detects the example2.com traffic by matching the incoming packets with a PDR having a PDI of type application with appId = example2.com (with the latest PFD) and applies the corresponding enforcement actions (charging, QoS) indicated in the FAR, QER and URR.

[0209] Step 39) The UPF forwards the traffic to the application server according to the FAR.

[0210] By the above embodiments, the following technical effects can be achieved:

[0211] • The embodiments herein can allow the network operator to support the PFD management procedure in a very efficient way by optimizing the delivery of the PFD rules, by reducing the amount of signaling and by reducing the number of hops between the producer (AF) and the consumer (UPF).

[0212] • The embodiments herein can remove the signaling, processing and memory impact related to the PFD management in the SMF, increasing its available capacity to handle the PFCP management procedure.

[0213] • The embodiments herein can reduce the signaling requirements related to the PFD management by half in the operator network.

[0214] • The embodiments herein can prevent overloading the receiver of the PFD management information and the communication channel between the producer and the receiver. Therefore, the impact on the NEF will also be minimized.

[0215] It is noted that, Figure 7A , 7B The AF, UDR, NEF, UPF in 7C can be configured as Figure 3 The AF 304, UDR 303, NEF 301 and UPF 302 in

[0216] Figure 8 is a schematic flowchart illustrating an example PFD management method in the NEF according to embodiments herein. In one embodiment, the flowchart in Figures 3-7C may be implemented in the NEF in Figure 8 .

[0217] The method 800 can start at step S801, where the NEF 301 can receive, from the UPF 302, a requirement message indicating a requirement for at least one PFD rule for an application.

[0218] In one embodiment, the requirement message can indicate a subscription of a PFD management service. That is, as Figures 4A-4B andFigures 7A-7C As shown in FIG. 6A, the UPF 302 can subscribe to the NEF PFD management service, such that whenever the NEF 301 receives a new version (new baseline) of the PFD from the AF 304, the NEF 301 can notify the UPF 302 about the new version (push).

[0219] In one embodiment, the requirement message (in this embodiment, the subscription) can include or not include the baseline. That is, if the UPF 302 has an older version (baseline) of the PFD for this application, the UPF 302 can indicate the baseline in the subscription; as a result, the NEF 301 can indicate to the UPF 302 only the changed (added, deleted, or updated) PFDs. Otherwise, if the UPF 302 does not have any version (baseline) of the PFD for this application, the UPF 302 can indicate no baseline.

[0220] In one embodiment, the requirement message (in this embodiment, the subscription) can include a push notification requirement, such that if any new version is received, the NEF 301 can only transmit the push notification to the UPF 302, and then the UPF 302 can download the PFD rules within an available time. For example, as shown in FIG. 6B, the UPF 302 can download the PFD rules within the operation and maintenance (O&M) maintenance window. Figures 4A-4B As shown in FIGs. 7A to 7C, the UPF 302 can retrieve the notified PFD rules during an operation and maintenance (O&M) maintenance window or at packet data unit (PDU) session establishment.

[0221] In one embodiment, the push notification requirement can only apply to infrequently used applications. For frequently used applications, the NEF 301 can push the PFD rule(s) such that the UPF 302 can immediately obtain the PFD rule(s).

[0222] In one embodiment, as shown in FIG. 6B, the requirement message (in this embodiment, the PFD request) can include or not include the baseline, similar to the push scenario. Figures 6A-6B As shown in FIGs. 7A to 7C, the requirement message can indicate a request for the PFD management service. That is, the UPF 302 can require (request) the NEF 301 to provide the PFD for the application (pull).

[0223] In one embodiment, the requirement message (in this embodiment, the PFD request) can include or not include the baseline, similar to the push scenario.

[0224] In one embodiment, as shown in FIG. 6B, the requirement message (in this embodiment, the PFD request) can include or not include the baseline, similar to the push scenario. Figures 7C-7C As shown in FIG. 6B, the UPF 302 can send the requirement message more than once. That is, even if the push subscription is successful, the UPF 302 can send the pull request. Furthermore, the UPF 302 can repeatedly send the pull request and / or the push subscription.

[0225] In one embodiment, although not shown in Figure 8 Method 800 can also include steps of receiving PFD rules from the AF 304 and storing them in the UDR 303, although not shown in Figure 8 These steps can be performed concurrently with the steps shown in Figure 8 These steps can be performed before or after the steps shown in

[0226] In one embodiment, the NEF 301 can receive one or more PFD rules for one or more applications from the AF 304. The NEF 301 can then associate a baseline with the one or more PFD rules for the same application. The baseline can be a version number or a timestamp.

[0227] In one embodiment, the NEF 301 can request the UDR 303 to store the one or more PFD rules for the application and the associated baseline.

[0228] Method 800 can then proceed to step S802, where in response to a received requirement message from the UPF 302, the NEF 301 can detect at least one PFD rule for an application.

[0229] In one embodiment, when receiving the requirement message (or subscription or request) from the UPF 302, the NEF 301 can detect at least one PFD rule for an application by checking the UDR 303. In one embodiment, the NEF 301 can query the UDR 303 for at least one PFD rule based on the baseline received in the requirement message (or subscription or request) from the UPF. In response to the query from the NEF 301, the UDR 303 can then compare the baseline associated with the query request and the baseline stored in the UDR 303 for this application and can determine whether there is a new baseline (e.g. new version) for this application. In particular, if the requirement message (or subscription or request) indicates no baseline and thus the query request accordingly indicates no baseline, then the UDR 303 can determine that the stored PFD rule(s) will be the new version. If a new baseline is found, the UDR 303 can provide the changed PFD rule(s). The UDR 303 can also provide the baseline (e.g. version number or timestamp).

[0230] In one embodiment, in response to successful subscription of the PFD management service of the UPF 302, the NEF 301 can detect whether any new version of the PFD rule(s) is received from the AF 304. For example, whenever the PFD rule(s) is received from the AF 304, the NEF 301 can establish a new baseline for the PFD rule(s), and at the same time, the NEF 301 can detect the updated PFD rule based on the new baseline associated with the one or more PFD rules received from the AF and the baseline received in the demand message from the UPF. In particular, the NEF 301 can compare the PFD rule(s) received from the AF 304 (associated with the new baseline) and the PFD rule(s) associated with the baseline indicated in the subscription message. If necessary, the NEF 301 can query the UDR 303 for the PFD rule(s) associated with the baseline indicated in the subscription message.

[0231] Then, the method 800 can proceed to step S803, where the NEF 301 can inform the UPF 302 about the information on the at least one PFD rule.

[0232] In one embodiment, depending on the demand message from the UPF 302, the NEF 302 can either inform the UPF 302 about the latest baseline and the existence of changed PFD rules (partial PFD rules) or transfer the changed PFD rules along with the notification.

[0233] The above steps are only examples, and the NEF 301 can perform any action described in relation to Figures 3-7C the management of the PFD rule(s).

[0234] Figure 9 is a schematic flow diagram illustrating an example PFD management method in the UDR according to embodiments herein. In one embodiment, the flow diagram in the UDR in Figures 3-7C may be implemented. Figure 9

[0235] The method 900 can start at step S901, where the UDR 303 can receive a storage request from the NEF 301 to store at least one PFD rule and an associated baseline for an application. The baseline is either a version reference or a timestamp. Then, at step S902, the UDR 303 can store the at least one PFD rule and the associated baseline.

[0236] ​The method 900 further comprises S903, wherein the UDR 303 can receive a query request with an associated baseline from the NEF 301. Then, in response to the query request from the NEF 301, at step S904, the UDR 303 can compare the baseline associated with the query request and the baseline for this application stored in the UDR 303 and can determine whether there is a new baseline (e.g. new version) for this application. In particular, if the query request indicates no baseline, then the UDR 303 can determine that the stored PFD rule(s) will be the new version. Then, at step S905, the UDR 303 can provide the changed PFD rule(s) if a new baseline is found. The UDR 303 can also provide the baseline (e.g. version number or timestamp).

[0237] It is noted that the above steps S901-S902 and S903-S905 can be performed in any manner, e.g. in any order, simultaneously or separately. Moreover, these steps can be performed repeatedly. The above steps are merely examples, and the UDR 303 can perform any action described in relation to Figures 3-7C to manage the PFD rule(s).

[0238] Figure 10 is a schematic flowchart illustrating an example PFD management method in a UPF according to embodiments herein. In one embodiment, the flowchart in Figures 3-7C may be implemented in a UPF in Figure 10 .

[0239] The method 1000 can start at step S1001, wherein the UPF 302 can transmit a requirement message indicating a requirement for at least one PFD rule for an application to the NEF 301.

[0240] In one embodiment, the requirement message can indicate a subscription of a PFD management service. That is, as shown in Figures 4A-4B and Figures 7A-7C , the UPF 302 can subscribe to the NEF PFD management service, such that whenever the NEF 301 receives a new version (new baseline) of a PFD from the AF 304, the NEF 301 can inform the UPF 302 about the new version (push).

[0241] In one embodiment, the requirement message (in this embodiment, the subscription) can include or not include a baseline. That is, if the UPF 302 has an older version (baseline) of the PFD for this application, the UPF 302 can indicate the baseline in the subscription; as a result, the NEF 301 can indicate to the UPF 302 only the changed (added, deleted, or updated) PFDs. Otherwise, if the UPF 302 does not have any version (baseline) of the PFD for this application, the UPF 302 can indicate no baseline. The baseline can be a version number or a timestamp.

[0242] In one embodiment, the requirement message (in this embodiment, the subscription) can include a push notification requirement, such that if any new version is received, the NEF 301 can only transmit a push notification to the UPF 302, and then the UPF 302 can download the PFD rules within an available time. For example, as shown in FIGS. 7A to 7C, the UPF 302 can retrieve the notified PFD rules during an operation and maintenance (O&M) maintenance window or at packet data unit (PDU) session establishment. Figures 4A-4B

[0243] In one embodiment, the push notification requirement can only apply to infrequently used applications. For frequently used applications, the NEF 301 can push the PFD rule(s) such that the UPF 302 can immediately obtain the PFD rule(s).

[0244] In one embodiment, as shown in FIGS. 7A to 7C, the requirement message can indicate a request for the PFD management service. That is, the UPF 302 can require (request) the NEF 301 to provide the PFD for the application (pull). Figures 6A-6B

[0245] In one embodiment, the requirement message (in this embodiment, the PFD request) can include or not include a baseline, similar to the push scenario.

[0246] Then, the method 1000 can proceed to step S1002, in which the UPF 302 can receive information about at least one PFD rule from the NEF 301.

[0247] In one embodiment, depending on the requirement message from the UPF 302, the NEF 302 can either notify the UPF 302 of the existence of the latest baseline and changed PFD rules (partial PFD rules) or transmit the changed PFD rules along with the notification.

[0248] ​​Then, at step S1003, the UPF 302 can retrieve the notified PFD rules during an operation and maintenance (O&M) maintenance window or at packet data unit (PDU) session establishment. Note that this step is not necessary for all applications in the application, as the NEF 302 can transmit the changed PFD rules along with the notification.

[0249] The above steps are merely examples, and the UPF 302 can perform any actions described in relation to Figures 3-7C the PFD rule(s) management.

[0250] Figure 11 is a schematic block diagram illustrating an example PFD management device in the NEF 301 according to embodiments herein.

[0251] In one embodiment, the example PFD management device in the NEF 301 can comprise at least one processor 1101 ; and a non-transitory computer-readable medium 1102 coupled to the at least one processor 1101. The non-transitory computer-readable medium 1102 contains instructions executable by the at least one processor 1101, whereby the at least one processor 1101 is configured to perform steps in the example method 800 illustrated in the schematic flowchart of Figure 8 hereinabove; the details of which are omitted here.

[0252] Note that the example PFD management device in the NEF 301 can be implemented as hardware, software, firmware, and any combination thereof. For example, the example PFD management device in the NEF 301 can comprise a plurality of units, circuits, modules, and the like, each of which can be used to perform one or more steps of the example method 800 or one or more steps illustrated in relation to the NEF 301 in Figures 3-7C hereinabove.

[0253] Figure 12 is a schematic block diagram illustrating an example PFD management device in the UDR 303 according to embodiments herein.

[0254] In one embodiment, the example PFD management device in the UDR 303 can comprise at least one processor 1201 ; and a non-transitory computer-readable medium 1202 coupled to the at least one processor 1201. The non-transitory computer-readable medium 1202 contains instructions executable by the at least one processor 1201, whereby the at least one processor 1201 is configured to perform steps in the example method 900 illustrated in the schematic flowchart of Figure 9 hereinabove; the details of which are omitted here.

[0255] It is noted that the example PFD management device in the UDR 303 can be implemented as hardware, software, firmware, and any combination thereof. For example, the example PFD management device in the UDR 303 can include a number of units, circuits, modules, and the like, each of which can be used to perform one or more steps of the example method 900 or one or more steps illustrated in FIG. 9 in relation to the UDR 303. Figures 3-7C

[0256] Figure 13 is a schematic block diagram illustrating an example PFD management device in the UPF 302 according to embodiments herein.

[0257] In one embodiment, the example PFD management device in the UPF 302 can include at least one processor 1301 and a non-transitory computer-readable medium 1302 coupled to the at least one processor 1301. The non-transitory computer-readable medium 1302 contains instructions executable by the at least one processor 1301, whereby the at least one processor 1301 is configured to perform steps in the example method 1000 as illustrated in the schematic flowchart of Figure 10 herein. Details thereof are omitted.

[0258] It is noted that the example PFD management device in the UPF 302 can be implemented as hardware, software, firmware, and any combination thereof. For example, the example PFD management device in the UPF 302 can include a number of units, circuits, modules, and the like, each of which can be used to perform one or more steps of the example method 1000 or one or more steps illustrated in FIG. 10 in relation to the UPF 302. Figures 3-7C

[0259] Figure 14 is a schematic block diagram illustrating an example computer-implemented device 1400 according to embodiments herein. In one embodiment, the device 1400 can be configured as the above-mentioned devices, such as the example PFD management device in the NEF 301, the example PFD management device in the UPF 302, and the example PFD management device in the UDR 303.

[0260] ​​In one embodiment, the device 1400 can comprise, but is not limited to, at least one processor, such as a central processing unit (CPU) 1401, a computer readable medium 1402, and a memory 1403. The memory 1403 can include volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as a hard disk or flash memory). In one embodiment, the computer readable medium 1402 can be configured to store a computer program and / or instructions that, when executed by the processor 1401, cause the processor 1401 to perform any of the above-mentioned methods.

[0261] In one embodiment, the computer readable medium 1402, such as a non-transitory computer readable medium, can be stored in the memory 1403. In another embodiment, the computer program can be stored in a remote location, for example, in a computer program product 1404 (which can also be embodied as a computer readable medium), and can be accessible by the processor 1401 via, for example, a carrier 1405.

[0262] The computer readable medium 1402 and / or the computer program product 1404 can be distributed and / or stored on a removable computer readable medium, for example, a diskette, a CD (compact disc), a DVD (digital video disc), a flash memory or similar removable memory medium (for example, a compact flash, a SD (secure digital), a memory stick, a mini SD card, an MMC multimedia card, a smart media), an HD-DVD (high definition DVD) or a Blu-ray DVD, a USB (universal serial bus) based removable memory medium, a tape medium, an optical storage medium, a magneto-optical medium, a bubble memory, or the computer readable medium 1402 and / or the computer program product 1404 can be distributed and / or stored over a network (for example, an Ethernet network, an ATM network, an ISDN network, a PSTN network, an X.25 network, the Internet, a local area network (LAN) or a similar network which is capable of transmitting data packets to infrastructure nodes) as a propagating signal.

[0263] In the above, example embodiments have been described with the use of a 5G architecture, however, the embodiments are equally applicable to a 4G LTE (Evolved Packet Core, EPC) or other communication systems.

[0264] For example, in one embodiment, the AF and its respective actions can be the SCS / AS and its respective actions, the NEF and its respective actions can be replaced by the SCEF and its respective actions, the PFD management service in the NEF and its respective actions can be replaced by the PFDF entity and its respective actions, the UPF and its respective actions can be replaced by the TDF-U or PGW-U and its respective actions, the storage of the PFD in the UDR and its respective actions can be replaced by the storage at the PFDF entity and its respective actions.

[0265] For example, the network exposure node is described above by using a network exposure function (NEF) 301 in the example embodiment, however, a service capability exposure function (SCEF) can also be used instead of the network exposure node.

[0266] For example, the user plane node is described above by using a user plane function (UPF) 302 in the example embodiment, however, a traffic detection function user plane function (TDF-U) or a PDN gateway user plane function (PGW-U) can also be used instead of the network exposure node.

[0267] For example, the PFD storage node is described above by using a unified data repository (UDR) 303 in the example embodiment, however, a packet flow description function (PFDF) entity can also be used instead of the network exposure node.

[0268] For example, the content provision node is described above by using an application function (AF) 304 in the example embodiment, however, a service capability server (SCS) / application server (AS) can also be used instead of the network exposure node.

[0269] Example embodiments are described herein with reference to block and / or flow diagrams of non-transitory computer program products and / or computer-implemented methods, apparatus (systems and / or devices). As such, it will be understood that each block of the block diagrams and / or flow diagrams, and / or combinations of blocks in the block diagrams and / or flow diagrams, can be implemented by computer program instructions that are tangibly embodied in a machine-readable medium (e.g., a non-transitory computer-readable medium) and / or computer- implemented. The machine-readable medium (e.g., the non-transitory computer- readable medium) can include, without limitation, memories (e.g., erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), read-only memories (ROMs), programmable read-only memories (PROMs), random access memories (RAMs), etc.) readable by a machine (e.g., a computer). The computer program instructions can be program code transmitted in a propagated signal, which can be any intangible medium of transmission, including without limitation, wireless, wired, optical, and the like. The computer program instructions can be part of, present in, or transmitted with a Data Stream (in whole or in part).

[0270] These computer program instructions can also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the function / act specified in the block(s) of the flowchart and / or diagram block(s) or a combination of flowchart and / or diagram block(s). As such, the instructions can be used to implement functionality corresponding to the flowchart and / or diagram block(s) or a combination of flowchart and / or diagram block(s) and can be executed by the computing system 1000. The computer program instructions can also be loaded onto a computer and / or other programmable instruction execution apparatus to cause a series of operations to be performed on the computer and / or other programmable apparatuses to produce a computer-implemented process such that the instructions which execute on the computer and / or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or diagram block(s) of the flowchart and / or diagram block(s) or a combination of flowchart and / or diagram block(s).

[0271] It should also be noted that in some alternative implementations, the functions / actions noted in the blocks can occur out of the order noted in the flowcharts. For example, two blocks shown in succession can in fact be executed substantially concurrently or can sometimes be executed in the reverse order, depending on the functionality / acts involved. Also, the functionality of a given block of the flowcharts and / or block diagrams can be separated into multiple blocks and / or integrated into fewer blocks and / or a combination of these. Finally, other blocks and / or functions can be added / inserted between the blocks and / or operations illustrated in the flowcharts and / or block diagrams without departing from the scope of the present concepts. Also, while some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication can occur in the opposite direction to the depicted arrows.

[0272] Many modifications and variations of the embodiments described herein can be made without departing from the underlying principles of the present concepts. All such modifications and variations are intended to be included herein within the scope of the present concepts. Thus, it is intended that the subject matter disclosed herein be considered in all its novel respects, including those specifically discussed above. Accordingly, the examples of the embodiments included herein are intended to be illustrative rather than restrictive, and it is contemplated that the present concepts include all such modifications, enhancements, and other embodiments that fall within the spirit and scope of the present concepts. Thus, the scope of the present concepts should be determined by the broadest permissible interpretation of the following claims and their equivalents, and the present concepts should not be restricted or limited to the above detailed description, unless the claims specifically and expressly recite otherwise.

[0273] Abbreviations

[0274] AF application function

[0275] AMF access and mobility function

[0276] AS application server

[0277] CP control plane

[0278] CUPS control plane user plane separation

[0279] DL downlink

[0280] DPI deep packet inspection

[0281] FAR forwarding action rule

[0282] IE information element

[0283] NEF network exposure function

[0284] PCF policy control function

[0285] PCRF policy and charging rules function

[0286] PDN packet data network

[0287] PDR packet detection rule

[0288] PDU packet data unit

[0289] PFCP packet flow control protocol

[0290] PFDF packet flow description function

[0291] PFD packet flow description

[0292] PGW packet gateway

[0293] PGW-U packet gateway user plane function

[0294] QoS quality of service

[0295] RAN radio access network

[0296] SCEF service capability exposure function

[0297] SCS service capability server

[0298] SDF service data flow

[0299] SMF session management function

[0300] SUPI subscription permanent identifier

[0301] TDF-U traffic detection function user plane function

[0302] UDR unified data repository

[0303] UE user equipment

[0304] UL uplink

[0305] UP user plane

[0306] UPF user plane function

[0307] URR usage reporting rule

[0308] WID work item identifier

Claims

1. A method (800) for managing packet flow descriptions, PFDs, performed at a network exposure node (301), comprising: - receiving, from a content providing node (304), one or more PFD rules for an application through a northbound API for PFD management of the network exposure node; - associating a baseline with the one or more PFD rules for the application; - receiving (S801) a demand message from a network node (201, 302) indicating a request for at least one PFD rule for an application, the demand message comprising a baseline; - detecting (S802) at least one updated PFD rule based on the baseline associated with the one or more PFD rules received from the content providing node (304) and the baseline received in the demand message from the network node (201, 302); and - informing (S803) the network node (201, 302) of the at least one updated PFD rule; wherein informing (S803) the network node (201, 302) of the at least one updated PFD rule further comprises: - informing the one or more updated PFD rules and the latest baseline; or - transmitting the one or more updated PFD rules along with the latest baseline; wherein the baseline is a version reference or a timestamp.

2. The method (800) of claim 1, further comprising: - requesting a PFD storage node (303) to store the one or more PFD rules for the application and the associated baseline.

3. The method (800) of claim 2, wherein, Detecting (S802) the at least one PFD rule further comprises: - querying the PFD storage node (303) for the at least one PFD rule based on the baseline received in the demand message from the network node (201, 302); - receiving a changed PFD rule from the PFD storage node (303).

4. The method (800) of any one of claims 1 to 3, wherein, The method (800) is performed at a network exposure function (NEF) (301) or a service capability exposure function, SCEF; wherein the network node is a session management function, SMF (201), a user plane function, UPF (302), a traffic detection function user plane function, TDF-U, or a PDN gateway user plane function, PGW-U; wherein the PFD storage node is a unified data repository, UDR (303), or a packet flow description function, PFDF, entity; and wherein the content providing node is an application function, AF (304), or a service capability server, SCS / application server, AS.

5. A method (1000) for managing packet flow descriptions, PFDs, performed at a network node (201, 302), comprising: - transmitting (S1001) a demand message to a network exposure node (301) indicating a request for at least one PFD rule for an application, the demand message comprising a baseline; - receiving (S1002) at least one updated PFD rule from the network exposure node (301) based on the baseline; wherein receiving (S1002) information about the at least one updated PFD rule from the network exposure node (301) further comprises: - receiving one or more updated PFD rules relative to the PFD rules in the requirement message and the baseline; or - receiving the one or more updated PFD rules; wherein the baseline is a version reference or a timestamp.

6. The method (1000) of claim 5, wherein, performing the method (1000) at a session management function, SMF (201), a user plane function, UPF (302), a traffic detection function, TDF-U, or a PDN gateway user plane function, PGW-U; and wherein the network exposure node is a network exposure function, NEF (301), or a service capability exposure function, SCEF.

7. A method (900) for managing packet flow descriptions, PFDs, performed at a PFD storage node (303), comprising: - receiving (S901) a storage request to store at least one PFD rule and an associated baseline for an application; - storing (S902) the at least one PFD rule and the associated baseline; - receiving (S903) a query request with an associated baseline; - comparing (S904) the baseline associated with the query request and a stored baseline; and - providing (S905) one or more updated PFD rules based on the baseline associated with the query request and the stored baseline; wherein the baseline is a version reference or a timestamp.

8. The method (900) of claim 7, wherein, performing the method (900) at a unified data repository, UDR (303), or a packet flow description function, PFDF, entity.

9. An apparatus (1100) for managing packet flow descriptions, PFDs, in a network exposure node, comprising: at least one processor (1101); and a non-transitory computer-readable medium (1102) coupled to the at least one processor (1101), the non-transitory computer-readable medium (1102) containing instructions executable by the at least one processor (1101), whereby the at least one processor (1101) is configured to: - receive one or more PFD rules for one or more applications from a content providing node (304) via a northbound API for PFD management of the network exposure node; - associate a baseline with the one or more PFD rules for the application; - receive (S801) a requirement message from a network node (201, 302) indicating a request for at least one PFD rule for an application, the requirement message comprising a baseline; - detect (S802) at least one updated PFD rule based on the baseline associated with the one or more PFD rules received from the content providing node (304) and the baseline received in the requirement message from the network node (201, 302); and - inform (S803) the network node (201, 302) of the at least one updated PFD rule; wherein, in order to notify (S803) the network node (201, 302) of the at least one updated PFD rule, the at least one processor (1101) is further configured to: - notify the one or more updated PFD rules and a latest baseline; or - transmit the one or more updated PFD rules together with the latest baseline; wherein the baseline is a version reference or a timestamp.

10. The apparatus (1100) of claim 9, wherein, The at least one processor (1101) is further configured to: - request a PFD storage node (303) to store the one or more PFD rules and associated baseline for the application.

11. The device (1100) of claim 9 or 10, when detecting (S802) the at least one PFD rule, the at least one processor (1101) is further configured to: - query the PFD storage node for the at least one PFD rule based on the baseline received in the demand message from the network node (201, 302); - receive the one or more updated PFD rules from the PFD storage node (303).

12. The device (1100) according to any one of claims 9 to 10, wherein, The device (1100) is implemented in a Network Exposure Function, NEF (301) or a Service Capability Exposure Function, SCEF; wherein the network node is a Session Management Function, SMF (201), a User Plane Function, UPF (302), a Traffic Detection Function - User Plane Function, TDF-U or a PDN Gateway - User Plane Function, PGW-U; wherein the PFD storage node is a Unified Data Repository, UDR (303) or a Packet Flow Description Function, PFDF entity; and wherein the content providing node is an Application Function, AF (304) or a Service Capability Server, SCS / Application Server, AS.

13. A device (1300) for managing Packet Flow Descriptions, PFDs, comprising: at least one processor (1301); and a non-transitory computer readable medium (1302) coupled to the at least one processor (1301), the non-transitory computer readable medium (1302) containing instructions executable by the at least one processor (1301), whereby the at least one processor (1301) is configured to: - transmit (S1001) a demand message indicating a request for at least one PFD rule for an application to a network exposure node (301), the demand message comprising a baseline; - receive (S1002) at least one updated PFD rule from the network exposure node (301) based on the baseline; wherein, in order to receive (S1002) information about the at least one updated PFD rule from the network exposure node (301), the at least one processor (1301) is further configured to: - receive a latest baseline relative to the PFD rule in the demand message and the baseline and the one or more updated PFD rules; or - receive the one or more updated PFD rules; wherein the baseline is a version reference or a timestamp.

14. The apparatus (1300) of claim 13, wherein, implementing the device (1300) in a Session Management Function, SMF (201), a User Plane Function, UPF (302), a Traffic Detection Function - User Plane Function, TDF-U, or a PDN Gateway - User Plane Function, PGW-U; and wherein the network exposure node is a Network Exposure Function, NEF (301), or a Service Capability Exposure Function, SCEF.

15. A device (1200) for managing Packet Flow Descriptions, PFDs, comprising: at least one processor (1201); and a non-transitory computer-readable medium (1202) coupled to the at least one processor (1201), the non-transitory computer-readable medium (1202) containing instructions executable by the at least one processor (1201), whereby the at least one processor (1201) is configured to: - receive (S901) a storage request to store at least one PFD rule and an associated baseline for an application; - store (S902) the at least one PFD rule and the associated baseline; - receive (S903) a query request with an associated baseline; - compare (S904) the baseline associated with the query request and a stored baseline; and - provide (S905) one or more updated PFD rules based on the baseline associated with the query request and the stored baseline; wherein the baseline is a version reference or a timestamp.

16. The apparatus (1200) of claim 15, wherein implementing the device (1200) in a Unified Data Repository, UDR (303), or a Packet Flow Description Function, PFDF, entity.

17. A computer readable medium (1402, 1404) comprising computer readable code, which when run on a device (1400) causes the device (1400) to perform the method (800, 900, 1000) according to any one of claims 1-8.

18. A computer program product comprising computer readable code, which when run on a processor causes the processor to perform the method according to any one of claims 1-8.

Images