Content for TS 26.501 Word version: 18.6.0

1… 4… 4.0.6… 4.1… 4.2… 4.2.2… 4.3… 4.4 4.5… 4.6… 4.7… 4.7.4… 4.8 4.9… 4.10… 5… 5.2… 5.2.4 5.2.5… 5.3… 5.3.2… 5.4… 5.5… 5.6… 5.7… 5.7.4… 5.7.8 5.8… 5.10… 5.10.5… 5.10.6… 5.11… 5.12… 5.12.4… 5.12.5… 6… 6.2… 6.2.2.2… 6.2.3… 6.3… 6.4… 6.8… 6.9… 6.9.5… 6.9.7 7… 8… 9… A… A.4… A.8 A.9 A.10 A.11 A.12 A.13 A.14 A.15… A.15.3… B… B.3 C… C.3 C.4 C.5 D… E…

6.9.7 Uplink Background Data Transfer using dynamic policy invocation
...

6.9.7 Uplink Background Data Transfer using dynamic policy invocation p. 180

Figure 6.9.7-1 shows a high-level call flow for the configuration and usage of a Background Data Transfer session in uplink 5G Media Streaming:

Copy of original 3GPP image for 3GPP TS 26.501, Fig. 6.9.7-1: Call flow for uplink Background Data Transfer session configuration and establishment

Figure 6.9.7-1: Call flow for uplink Background Data Transfer session configuration and establishment
(⇒ copy of original 3GPP image)

Pre-requisites:

The 5GMSu Application Provider has negotiated a Service Level Agreement with the 5GMS System operator that includes all or some of the following:
1. Time window(s) when Background Data Transfers are available. These may recur on a regular pattern (e.g., daily, weekly, monthly, etc.).
2. A quota for the maximum number of 5GMS Clients that may avail themselves of a Background Data Transfer during each such time window.
3. A quota for the maximum aggregate volume of data that may be transferred by all 5GMS Clients during each Background Data Transfer window.
The 5GMS System operator may have provisioned a Background Data Transfer Policy in the PCF based on the Service Level Agreement, in which case it may share the corresponding Background Data Transfer reference identifier directly with the 5GMSu Application Provider.

The steps in the call flow sequence are as follows with differences from the baseline call flow highlighted in bold:

Step 1.

The 5GMSu Application Provider provisions a Policy Template in the 5GMSu AF at reference point M1u including network QoS parameters that either references an existing Background Data Transfer policy already provisioned in the PCF that embodies the aforementioned Service Level Agreement or else directly specifies Background Data Transfer parameters in line with the aforementioned Service Level Agreement.

Step 2.

If the supplied Policy Template explicitly declares new Background Data Transfer parameters, the 5GMSu AF creates a corresponding new Background Data Transfer policy in the PCF based on them using the Npcf_BDTPolicyControl service (or, if the 5GMSu AF is deployed outside the Trusted DN, the Nnef_BDTPNegotiation service (see clause 4.16.7.2 of TS 23.502). The PCF may interact with the UDR as a consequence. The procedure yields a Background Data Transfer reference identifier.

Step 3.

The 5GMSu AF acknowledges successful creation of the Policy Template to the 5GMSu Application Provider. This confirms that the parameters of the Policy Template (including the Background Data Transfer parameters) are acceptable to the 5GMS System.

Step 4.

If it has not already done so, the 5GMSu AF subscribes to receive Background Data Transfer warning notifications from the PCF as defined in clause 4.16.7 of TS 23.502.

At some later point in time:

Step 5.

The 5GMSu-Aware Application launches media session handling using an appropriate service launch mechanism at reference point M6u.

Step 6.

In response, the Media Session Handler fetches Service Access Information from the 5GMSu AF for the relevant Provisioning Session via reference point M5u. A client dynamic policy invocation configuration is provided that describes the Policy Templates applicable to the requesting 5GMSu Client, including information about Background Data Transfer windows and endpoint(s) that the Media Session Handler may subscribe to in order to receive Background Data Transfer warning notifications from the 5GMSu AF.

Step 7.

The 5GMSu-Aware Application also subscribes to receive notifications of Background Data Transfer opportunities from the Media Session Handler by invoking a client API on the latter at reference point M6u.

At the start of the next Background Data Transfer window:

Step 8.

According to its list of current subscriptions (see step 7), the Media Session Handler notifies its 5GMSu-Aware Application subscriber(s) of the Background Data Transfer opportunity by sending a notification to each one via reference point M6u. The notification indicates the time window of the Background Data Transfer opportunity.

Step 9.

If it wishes to avail itself of the Background Data Transfer opportunity (immediately or at some later point during the time window indicated in the previous step) a 5GMSu-Aware Application that has received such a notification invokes a suitable client API on the Media Session Handler at reference point M6u. The invocation includes an estimate of the data volume the 5GMSu Client intends to transfer in the background.

Step 10.

The Media Session Handler instantiates a dynamic policy resource on the 5GMSu AF based on one of the Policy Templates advertised in the Service Access Information that includes Background Data Transfer parameters. The request includes an estimate of the data volume the 5GMSu Client intends to transfer in the background.

Step 11.

If the request falls within a time window for Background Data Transfers advertised in the Service Access Information and if the quota for the number of Background Data Transfers within the current time window has not been exceeded, the Media Session Handler requests a change to the network QoS of the appropriate PDU Session by invoking the Npcf_PolicyAuthorization_Create operation (either directly or via the NEF) according to clause 4.16.7.1 of TS 23.502 based on the Background Data Transfer parameters described in the appropriate Policy Template and citing the reference identifier of the Background Data Transfer referenced in step 1 or created in step 2.

Step 12.

The 5GMSu AF responds to the Media Session Handler to grant the Background Data Transfer request. The grant response includes a recommendation from the 5GMSu AF of the maximum time period for which the Background Data Transfer is available and the maximum Background Data Transfer volume granted for the media streaming session during this grant period (which may be smaller than that requested in step 10).

Step 13.

The Media Session Handler informs the 5GMSu-Aware Application of the Background Data Transfer grant by sending a synchronous response or asynchronous notification to the latter at reference point M7u. This conveys the maximum time period recommendation and maximum data volume indicated by the 5GMSu AF in the previous step.

Step 14.

The 5GMSu-Aware Application subscribes to receive Background Data Transfer warning notifications from the Media Session Handler by invoking a client API on the latter at reference point M6u.

Step 15.

As a consequence, the Media Session Handler subscribes to receive Background Data Transfer warning notifications from the 5GMSu AF by invoking a network API on the latter at reference point M5u. The subscription endpoint(s) are indicated in the Service Access Information obtained in step 6.

The following steps are repeated for each content item the 5GMSu-Aware Application would like to download during the granted time period for Background Data Transfers:

Step 16.

The 5GMSu-Aware Application initiates upload of a content item in the background by invoking a suitable client API on the Media Streamer at reference point M7u. The content is identified by a URL that is available on a 5GMSu AS.

Step 17.

The Media Streamer uploads the content item from the 5GMSu AS at reference point M4d using the content item URL supplied in the previous step.

Step 18.

The Media Player confirms that the content item has been successfully uploaded by sending a notification to the 5GMSu-Aware Application at reference point M7u.

(Steps 19-27 are described below.)

When the granted time period for Background Data Transfers subsequently expires:

Step 28.

The PCF automatically reverts the network QoS of the media streaming session to its state prior to the Background Data Transfer grant without intervention from the 5GMS System.

At any time during a Background Data Transfer window the PCF may detect that the network cannot satisfy the requirements of the Background Data Transfer policy at the UE's current location (as defined in clause 6.1.2.4 of TS 23.503) or that the volume of data transferred by all UEs in the current Background Data Transfer window has exceeded the quota provisioned in the Background Data Transfer policy. The procedures in this case are summarised in Figure 6.9.7-2.

Copy of original 3GPP image for 3GPP TS 26.501, Fig. 6.9.7-2: Call flow for uplink Background Data Transfer session renegotiation/cancellation

Figure 6.9.7-2: Call flow for uplink Background Data Transfer session renegotiation/cancellation
(⇒ copy of original 3GPP image)

The steps are as follows:

Step 19.

If it is able to identify alternative Background Data Transfer policies, the PCF sends a Background Data Transfer warning notification with these candidates to the 5GMSu AF as defined in clause 4.16.7.3 of TS 23.502.

Step 20.

The 5GMSu AF evaluates the candidate alternative Background Data Transfer policies for suitability.

If the 5GMSu AF determines that one of the candidate alternative Background Data Transfer policies suggested by the PCF is suitable for the media streaming session in question:

Step 21.

The 5GMSu AF requests that its chosen alternative Background Data Transfer policy is applied, according to step 12 in clause 4.16.7.3 of TS 23.502. As defined in clause 6.1.2.4 of TS 23.503, in this case the current Background Data Transfer policy remains in force until its natural end (see step 29 above).

Step 22.

Using an asynchronous notification mechanism at reference point M5u, the 5GMSu AF notifies the Media Session Handler of the modified Background Data Transfer grant, including the new maximum time period for which the Background Data Transfer is available, and the new maximum Background Data Transfer volume granted for the media streaming session during this grant period (which may be smaller than that requested in step 10).

Step 23.

The Media Session Handler informs the 5GMSu-Aware Application of the Background Data Transfer grant by sending an asynchronous notification to the latter at reference point M6u. This conveys the maximum time period recommendation and maximum data volume indicated by the 5GMSu AF in the previous step.

Otherwise, if none of the candidate Background Data Transfer policies suggested by the PCF deemed suitable by the 5GMSu AF:

Step 24.

The 5GMSu AF informs the PCF that none of the candidate Background Data Transfer policies is suitable, according to step 13 in clause 4.16.7.3 of TS 23.502.

Step 25.

Using an asynchronous notification mechanism at reference point M5u, the 5GMSu AF notifies the Media Session Handler that the Background Data Transfer window has ended prematurely.

Step 26.

Using an asynchronous notification mechanism at reference point M6u, the Media Session Handler notifies the 5GMSu-Aware Application that the Background Data Transfer window has ended prematurely.

Step 27.

As a consequence, the 5GMSu-Aware Application may choose to cancel an in-progress Background Data Transfer by invoking a suitable client API method on the Media Player at reference point M7u.