4 Packet Flow Description Management Service
29.5513GPP5G SystemPacket Flow Description Management ServiceRelease 18Stage 3TS
4.1 Service Description
4.1.1 Overview
The PFD Management Service, as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4], is provided by the Packet Flow Description Function (PFDF).
The only known NF service consumer is the SMF.
This service:
– allows a NF service consumer (e.g. SMF) to subscribe to and unsubscribe from PFD changes;
– notifies a NF service consumer (e.g.SMF) about changes of PFDs;
– notifies a NF service consumer (e.g.SMF) to retrieve the PFDs; and
– allows a NF service consumer (e.g. SMF) to retrieve PFDs.
4.1.2 Service Architecture
The 5G System Architecture is defined in 3GPP TS 23.501 [2]. The Policy and Charging related 5G architecture is also described in 3GPP TS 23.503 [4].
The PFD Management Service is provided by the PFDF to NF service consumers (e.g. SMF) and shown in the SBI representation model in Figure 4.1.2-1. The PFDF is a functionality within the NEF.
NEF
PFDF
SMF
Nnef_PFDmanagement
Figure 4.1.2-1: Reference Architecture for the Nnef_PFDmanagement Service; SBI representation
NEF
PFDF
SMF
N29
Figure 4.1.2-2: Reference Architecture for the Nnef_PFDmanagement Service; reference point representation
4.1.3 Network Functions
4.1.3.1 Packet Flow Description Function (PFDF)
The Packet Flow Description Function (PFDF):
– provides PFDs associated with one or more Application Identifiers;
– notifies a NF service consumer to retrieve the PFDs; and
– allows NF service consumers to subscribe to and unsubscribe from notifications on changes of PFDs for Application Identifier.
4.1.3.2 NF Service Consumers
The SMF shall support:
– requesting and receiving the PFD(s) for one or more Application Identifiers.
4.2 Service Operations
4.2.1 Introduction
Service operations defined for the Nnef_PFDmanagement Service are shown in table 4.2.1-1.
Table 4.2.1-1: Nnef_PFDmanagement Service Operations
|
Service Operation Name |
Description |
Initiated by |
|
Nnef_PFDmanagement_Fetch |
Provides the PFDs for application identifier(s) to the NF service consumer by the full pull or partial pull. |
NF service consumer (e.g. SMF) |
|
Nnef_PFDmanagement_Subscribe |
Allows NF service consumers to subscribe to notifications on events when the PFDs for application identifier(s) change. |
NF service consumer (e.g. SMF) |
|
Nnef_PFDmanagement_Notify |
Notifies NF service consumers to update and/or delete the PFDs for application identifier(s) or notifies NF service consumer to retrieve the PFDs for application identifier(s). |
PFDF |
|
Nnef_PFDmanagement_Unsubscribe |
Allows NF service consumers to unsubscribe from notifications on PFDs change events. |
NF service consumer (e.g. SMF) |
4.2.2 Nnef_PFDmanagement_Fetch Service Operation
4.2.2.1 General
The Nnef_PFDmanagement_Fetch service operation provides means for the NF service consumer to retrieve the PFDs for one or more application identifier(s). This service operation enables the NF service consumer to retrieve PFDs for an Application Identifier(s) from the PFDF when:
– a PCC rule with this application identifier is provided/activated by the PCF and the PFDs provided by the PFDF are not available at the NF service consumer; or
– the caching timer for an application identifier elapses and a PCC rule for this application identifier is still active.
When the NF service consumer removes the last PCC rule that refers to the corresponding application identifier, or when the caching timer expires and no PCC rule refers to the application identifier, the NF service consumer may remove the PFD(s) related with the application identifier.
The PFDs retrieved from PFDF take precedence over any PFDs pre-configured in the NF service consumer. If all PFDs retrieved from the PFDF are removed for an application identifier, the pre-configured PFDs shall be applied again for the application identifier.
The PFDF may provide caching time value via the "cachingTime" attribute or, if the feature CachingTimer is supported, via the "cachingTimer" attribute, together with the PFDs for an application identifier. The caching time value retrieved from the PFDF takes precedence over the default caching time value configured in the NF service consumer. If no caching time value is received from the PFDF, the configured default caching time value shall be applied.
NOTE x1: The NF service consumer(s) and the PFDF(s) within an operator network are configured with the same default caching time value to be applied for all application identifiers.
NOTE x2: The configuration of a caching time value per application identifier in the PFDF is based on the SLA between the operator and the ASP.
The following procedures using the Nnef_PFDmanagement_Fetch service operation are supported:
– Retrieval of PFDs by the full pull.
– Retrieval of PFDs by the partial pull.
4.2.2.2 Retrieval of PFDs by the full pull
This procedure, as shown in Figure 4.2.2.2-1, is used to retrieve PFDs from the PFDF by the full pull for requested application identifier(s).
Figure 4.2.2.2-1: Retrieval of PFDs by the full pull
1. The NF service consumer (e.g. SMF) shall send a GET request to the resource representing the PFDs for the requested application identifier(s):
– for PFDs of an individual application identifier, the request URI shall be set to "{apiRoot}/nnef‑pfdmanagement/v1/applications/{appId}" (as shown in figure 4.2.2.2-1, step 1a); and
– for PFD of a collection of application identifiers, the request URI shall be set to "{apiRoot}/nnef‑pfdmanagement/v1/applications" (as shown in figure 4.2.2.2-1, step 1b) with query parameters indicating the requested application identifier(s).
2. On success, an HTTP "200 OK" response shall be returned, with the payload body containing a representation of an "Individual application PFD" resource or a "PFD of applications" resource for the requested application identifier(s). The NF service consumer shall replace the stored PFD(s) retrieved from the PFDF with the new received PFD(s) for the requested application identifier(s). If the PFD(s) of one or more requested application identifier(s) are not provided in the response, the NF service consumer shall remove the PFD(s) of these requested application identifier(s) and re-apply the pre-configured PFDs.
If errors occur when processing the HTTP GET request, the PFDF shall send an HTTP error response as specified in clause 5.7. For "404 Not Found", the NF service consumer shall remove the PFD(s) of the requested application identifier(s) in the NF service consumer and re-apply the pre-configured PFDs.
If the feature "ES3XX" is supported, and the PFDF determines the received HTTP GET request needs to be redirected, the PFDF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].
4.2.2.3 Retrieval of PFDs by the partial pull
This procedure, as shown in Figure 4.2.2.3-1, is used to retrieve PFDs from the PFDF by the partial pull for requested application identifier(s) if the "PartialPull" feature defined in clause 5.8 is supported both by NF service consumer and PFDF.
Figure 4.2.2.3-1: Retrieval of PFDs by the partial pull
1. The NF service consumer (e.g. SMF) shall send an HTTP POST message to the resource "{apiRoot}/nnef‑pfdmanagement/v1/applications/partialpull". The NF service consumer shall include one or more ApplicationForPfdRequest data structure in the payload body of the HTTP POST. With the ApplicationForPfdRequest data structure, the NF service consumer shall include the application identifier within the "applicationId" attribute and the timestamp of the PFDs received in the last provisioning for the application identifier within the "pfdTimestamp" attribute. The NF service consumer may also request full set of PFD(s) of an application identifier without including the timestamp if it is not available.
2. If the PFDF accepted the HTTP POST request, the PFDF shall send to the NF service consumer:
– the HTTP "200 OK" response (as shown in figure 4.2.2.3-1, step 2a) including one or more PfdDataForApp data structure if the NF service consumer requests the PFD(s) for an application identifier(s) without the timestamp or if the NF service consumer requests PFD(s) for an application identifier(s) with timestamp and the PFDF determines that corresponding PFD(s) is changed since the last request based on the timestamp received in the request for the application identifier. Within the PfdDataForApp data type, the PFDF shall include the application identifier within the "applicationId" attribute, the new timestamp within the "pfdTimestamp" attirbute, the "partialFlag" attribute if applicable and create/update/remove the PFDs as follows:
– include the full list of the PFD(s) within the "pfds" attribute for the application identifier which is requested without the timestamp;
– include the full list of the PFD(s) within the "pfds" attribute for the application identifier if all the PFD(s) are changed for the application identifier since the last request based on the timestamp;
– for the application identifier whose PFD(s) are partially changed:
– include the new PFD(s) with new PFD identifier(s) within the "pfds" attribute if the new PFD(s) is added for the application identifier and the "partialFlag" attribute set to true;
– include the new PFD(s) with existing PFD identifier(s) within the "pfds" attribute if the existing PFD(s) is updated for the application identifier and the "partialFlag" attribute set to true;
– include the existing PFD identifier(s) without any content within the "pfds" attribute if the existing PFD(s) is removed for the application identifier and the "partialFlag" attribute set to true;
– not include the "pfds" attribute if the PFD(s) is removed for the application identifier.
NOTE 1: The PFDF does not include the PfdDataForApp data type for the application identifier whose PFD(s) is not updated since last request.
NOTE 2 If the PFDF determines that the PFDs are changed since the last request but cannot determine what changes have been applied to the individual PFD(s) for an application identifier, the PFDF can include the full list of the PFD(s) in the PfdDataForApp data type.
– the HTTP "204 No Content" response (as shown in figure 4.2.2.3-1, step 2b) if the PFD(s) for all the requested application identifier(s) are not changed since last request.
When the NF service consumer receives the response with "200 OK" status code, the NF service consumer shall
– remove the all existing PFD(s) (if available) and install all the new provided PDF(s) for an application identifier if full list of PFD(s) is received but "partialFlag" attribute is not received;
– delete the existing PFD(s) for an application identifier(s) where no PFD(s) is received;
– for an application identifier(s) where the PFD(s) is provided and "partialFlag" attribute is also provided and set to true:
– install a new PFD(s) if the new PFD(s) with a new PFD identifier(s) is received;
– update an existing PFD(s) if a new PFD(s) with the same PFD identifier(s) is received;
– delete an existing PFD(s) if the same PFD identifier(s) without any content is received;
– reserve an existing PFD(s) if the PFD identifier(s) is not received.
4.2.3 Nnef_PFDmanagement_Subscribe Service Operation
4.2.3.1 General
The Nnef_PFDmanagement_Subscribe service operation enables the NF service consumer to subscribe to notifications on events when the PFDs for application identifier(s) change.
The following procedures using the Nnef_PFDmanagement_Subscribe service operation are supported:
– Subscription for event notifications on PFDs change;
– Subscription update for event notifications on PFD change.
4.2.3.2 Subscription for event notifications on PFDs change
This procedure, as shown in Figure 4.2.3.2-1, is used to subscribe to notifications on events when the PFDs for application identifier(s) change.
Figure 4.2.3.2-1: Creation of a subscription for event notifications on PFDs change
1. The NF service consumer (e.g. SMF) shall send a POST request to the request URI representing the collection of PFD subscriptions resource "{apiRoot}/nnef‑pfdmanagement/v1/subscriptions". The NF service consumer shall include the PfdSubscription data type in the request payload body. Within the PfdSubscription data type, the NF service consumer shall include:
– an URI where to receive the requested notifications as "notifyUri" attribute;
and may include:
– subscribed application identifier(s) within the "applicationIds" attribute.
2. If the request is accepted, the PFDF shall:
– create a new subscription;
– assign a subscriptionId;
– store the subscription; and
– send an HTTP "201 Created" response, with the payload body containing a representation of the created subscription, and the Location header containing the resource URI of the created subscription "{apiRoot}/nnef-pfdmanagement/v1/subscriptions/{subscriptionId}".
Otherwise, one of the HTTP status codes listed in table 5.3.4.3.1-3 shall be returned.
NOTE: The PFDs that have been provisioned to the PFDF before the NF service consumer performs the subscription are not notified to the NF service consumer as a result of this subscription, but the NF service consumer can retrieve them before performing the subscription by invoking Nnef_PFDmanagement_Fetch Service Operation.
4.2.3.3 Subscription update for event notifications on PFDs change
This procedure, as shown in Figure 4.2.3.3-1, is used to update an existing subscription to notifications on events when the PFDs for application identifier(s) change.
Figure 4.2.3.3-1: Update of a subscription for event notifications on PFDs change
1. If the feature PfdChgSubsUpdate is supported, the NF service consumer (e.g. SMF) shall send a PUT request to the resource URI representing the targeted PFD subscription resource "{apiRoot}/nnef‑pfdmanagement/v1/subscriptions/{subscriptionId}". The NF service consumer shall include the PfdSubscription data type in the request payload body. Within the PfdSubscription data type, the NF service consumer shall include:
– an URI where to receive the requested notifications as "notifyUri" attribute;
and may include:
– subscribed application identifier(s) within the "applicationIds" attribute.
NOTE 1: The "notifUri" attribute within the PfdSubscription data structure can be modified to request that subsequent notifications are sent to a new NF service consumer.
2. If the feature PfdChgSubsUpdate is supported and the request is accepted, the PFDF shall:
– update the subscription; and
– send an HTTP "200 OK" response with the payload body containing a representation of the updated subscription.
Otherwise, if errors occur when processing the HTTP PUT request, the PFDF shall send an HTTP error response as specified in clause 5.7. If the feature "ES3XX" is supported, and the PFDF determines the received HTTP PUT request needs to be redirected, the PFDF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].
NOTE 2: The PFDs that have been provisioned to the PFDF before the NF service consumer performs the subscription are not notified to the NF service consumer as a result of this subscription, but the NF service consumer can retrieve them before performing the subscription by invoking Nnef_PFDmanagement_Fetch Service Operation.
4.2.4 Nnef_PFDmanagement_Notify Service Operation
4.2.4.1 General
The Nnef_PFDmanagement_Notify service operation notifies the NF service consumer to update, delete or retrieve the PFDs for application identifier(s).
The following procedures using the Nnef_PFDmanagement_Notify service operation are supported:
– Notification of PFD change.
– Notification PUSH
4.2.4.2 Notification of PFD change
Figure 4.2.4.2-1: Notification of PFD change
1. The PFDF shall send a POST request to the NF service consumer (e.g. SMF) targeting the URI "{notifyUri}, where {notifyUri} is the notification URI provided during the creation or modification of the subscription resource as specified in clause 4.2.3. The payload body of the POST request shall contain one or more PfdChangeNotification data structure(s).
2 If the notification is accepted, the NF service consumer shall reply with:
– "204 No Content" indicating the successful provisioning of all PFDs; or
– "200 OK" and the payload body of the response shall contain "PfdChangeReport" data structure with detailed information of failed application(s).
Otherwise, if errors occur when processing the HTTP POST request, the NF service consumer shall send an HTTP error response as specified in clause 5.7. If the feature "ES3XX" is supported, and the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].
4.2.4.3 Notification PUSH
Figure 4.2.4.3-1: Notification PUSH
1. If the NotificationPush feature defined in clause 5.8 is supported, and when the PFDF only notifies the NF service consumer to retrieve or remove the PFDs for application identifier(s), then the PFDF shall send a POST request to the NF service consumer (e.g. SMF) with "{notifyUri}/notifypush" as URI (where the "notifyUri" was previously supplied by the NF service consumer) and one or more NotificationPush data structure as request body. Each NotificationPush data structure shall include the application identifier(s) within the "appIds" attribute, the "pfdOp" attribute set to the applicable value and may include the "allowedDelay" attribute containing the allowed delay time if received when the "pfdOp" attribute is set to "RETRIEVE", "FULLPULL" or "PARTIALPULL".
2 If the NF service consumer accepts the received POST request, the NF service consumer shall send an HTTP "204 No Content" response.
After the successful processing of the HTTP POST request,
– if the PFDF requests the NF service consumer to retrieve the PFD(s) with the "pfdOp" attribute set to the value "RETRIEVE" or without the "pfdOp" attribute, the NF service consumer shall determine to invoke the full pull procedure defined in clause 4.2.2.2 or invoke the partial pull procedure defined in clause 4.2.2.3 if the "PartialPull" feature is supported to retrieve the PFD(s) for the application identifier(s).
– if the "PartialPull" feature is supported and if the PFDF requests the NF service consumer to retrieve the PFD(s) with the "pfdOp" attribute set to the value "FULLPULL", the NF service consumer shall invoke the full pull procedure defined in clause 4.2.2.2.
– if the "PartialPull" feature is supported and if the PFDF indicates the NF service consumer to retrieve the PFD(s) with the "pfdOp" attribute set to the value "PARTIALPULL", the NF service consumer may invoke the partial full procedure defined in clause 4.2.2.3.
– for all above cases, if the "allowedDelay" attribute is provided for one or more application(s), the NF service consumer shall retrieve the PFD within the allowed delay time.
– if the PFDF requests the NF service consumer to remove the PFD(s) with the "pfdOp" attribute set to the value "REMOVE", the NF service consumer shall remove the PFD(s) for the application identifier(s) and re-apply the pre-configured PFDs.
If errors occur when processing the HTTP POST request, the NF service consumer shall send an HTTP error response as specified in clause 5.7.
If the feature "ES3XX" is supported, and the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].
4.2.5 Nnef_PFDmanagement_Unsubscribe Service Operation
4.2.5.1 General
The Nnef_PFDmanagement_Unsubscribe service operation is used by the NF service consumer to unsubscribe from notifications on PFD change events.
The following procedures using the Nnef_PFDmanagement_Unsubscribe service operation are supported:
– Unsubscribe from event notifications on PFDs change.
4.2.5.2 Unsubscribe from event notifications on PFDs change
Figure 4.2.5.2-1: Unsubscribe from event notifications on PFDs change
1. The NF service consumer (e.g. SMF) shall send a DELETE request to the resource URI representing the individual PFD subscription. The request body shall be empty.
2. If the request is accepted, an HTTP "204 No Content" response shall be returned. The response body shall be empty.
Otherwise, if errors occur when processing the HTTP DELETE request, the PFDF consumer shall send an HTTP error response as specified in clause 5.7. If the feature "ES3XX" is supported, and the PFDF determines the received HTTP DELETE request needs to be redirected, the PFDF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].