4 Nu reference point

29.2503GPPNu reference point between SCEF and PFDF for sponsored data connectivityRelease 16TS

4.1 Overview

The Nu reference point is located between the Packet Flow Description Function (PFDF) and the Service Capability Exposure Function (SCEF). The Nu reference point is used for provisioning of PFDs from the SCEF to the PFDF and reporting the result of the PFD Management from the PFDF to the SCEF.

The stage 2 level requirements for the Nu reference point are defined in 3GPP TS 23.682 [2].

4.2 Nu reference model

The Nu reference point is defined between the SCEF and the PFDF. The relationships between the different functional entities involved are depicted in figure 4.2.1. The overall PCC architecture is depicted in subclause 3a of 3GPP TS 29.213 [4].

Figure 4.2.1: Nu reference model

4.3 Functional elements

4.3.1 PFDF

The PFDF (Packet Flow Description Function) is a functional element which receives and manages the PFDs associated to application identifier (s) from the SCEF via the Nu reference point.

The PFDF provisions PFDs for the corresponding application identifier (s) to the PCEF/TDF as defined in 3GPP TS 23.203 [3] and 3GPP TS 29.251 [9].

4.3.2 SCEF

The SCEF (Service Capability Exposure Function) is a functional element which provides means to securely expose the services and capabilities provided by the 3GPP network interfaces.

The SCEF shall support the management of PFDs provided by the 3rd party SCS/AS. The SCEF may provision the PFDs to the PFDF via the Nu reference point.

4.4 Procedures over Nu reference point

4.4.1 Management of PFD

The PFDs associated with application identifier (s) may be created, updated or removed in the PFDF by the third party SCS/AS via the SCEF as defined in 3GPP TS 23.682 [2].

If the SCEF receives one or more sets of PFDs for external application identifier (s) provisioned by the third party SCS/AS, which is authorized to perform the management of PFDs based on operator policies, the SCEF shall:

– If the external application identifier(s) is different from the application identifier(s) known at the PFDF, translate the external application identifier(s) to the application identifier(s) known at the PFDF; and

– may check if the allowed delay satisfies the required SLA against the minimum allowed delay as defined in 3GPP TS 23.682 [2]; and

– send an HTTP POST message to the PFDF including the provisioned PFD changes for the the application identifier (s) within the body of the HTTP POST as described in subclause 5.3.5.2.

NOTE 1: It is up to operator configuration whether to use different external application identifiers that require a mapping to application identifiers known at the PFDF. The external application identifier can be the same as the application identifier known at the PFDF.

Upon receipt of the HTTP request for the provisioning operation from the SCEF, the PFDF shall perform the following steps:

– If an allowed delay is received for an application identifier, for Pull mode as defined in 3GPP TS 29.251 [9], the PFDF shall compare the allowed delay with the configured caching time which is:

– a caching time value configured for that application identifier; or

– the default caching time value if no caching time value is configured for that application identifier.

– Then if the PFDF cannot ensure the PCEF/TDF will pull the PFDs in time (i.e. allowed delay is shorter than the caching time), the PFDF shall within the HTTP response send a failure reason and that caching time value used in the comparison and may still store (create/update/remove) the PFDs for this application identifier.

NOTE 2: In the Combination mode as defined in 3GPP TS 29.251 [9], the PFDF can check the received allowed delay against the caching time but will always store (create/update/remove) the PFDs.

– In the Pull mode as defined in 3GPP TS 29.251 [9], for the application identifier(s) without the need to send failure reason; or in the Push or Combination mode as defined in 3GPP TS 29.251 [9], for received application identifier(s), the PFDF shall:

– delete all the PFD(s) for the application identifier(s) where the removal-flag is also provided and set to true;

– update the existing PFD(s) if a new PFD(s) with the same PFD identifier(s) is received , add new PFD(s) if the new PFD(s) with a new PFD identifier(s) is received, and/or delete an existing PFD(s) if the same PFD identifier(s) without any content is received, where the partial-flag is also provided and set to true;

– remove existing PFD(s) (if available) and install the new PFD(s) for the corresponding PFD identifier(s) whereno flag is provided;

– acknowledge the HTTP POST message by sending a corresponding HTTP response with the appropriate status code as defined in subclause 5.3.2. If the POST operation was successful for at least one application identifier, the PFDF shall respond with an HTTP 200 OK status code.

4.4.2 PFD management notification

In the Push mode or Combination mode as defined in 3GPP TS 29.251 [9], if the PFDs are provisioned to at least one of the known PCEFs/TDFs (but not all) within the allowed delay (i.e. the provisioned PFDs can not be enforced successfully in some PCEF/TDFs known on the PFDF), the PFDF may notify the SCEF about the failed PFD provisioning with the HTTP POST message using the failure reason "PARTIAL_FAILURE" as defined in Table 5.4.7.1-1. In this case, the PFDF may include location area(s) of the PCEF/TDF(s) which can not enforce the provisioned PFD(s) within the field "user-plane-location-area" of the corresponding instance of the PFD report(s). If the PFDs are provisioned to none of the known PCEFs/TDFs within the allowed delay, the PFDF shall notify the SCEF about the failed PFD provisioning with the HTTP POST message using appropriate failure reason as defined in subclause 6.4.6.3 of 3GPP TS 29.251 [9].

When receiving the HTTP POST message, the SCEF shall respond with an HTTP response message.