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…

5.7.8 Downlink Background Data Transfer using dynamic policy invocation
...

5.7.8 Downlink Background Data Transfer using dynamic policy invocation |R18| p. 114

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

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

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

Pre-requisites:

The 5GMSd 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 5GMSd 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 5GMSd Application Provider provisions a Policy Template in the 5GMSd AF at reference point M1d 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 5GMSd AF creates a corresponding new Background Data Transfer policy in the PCF based on them using the Npcf_BDTPolicyControl service (or, if the 5GMSd 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 5GMSd AF acknowledges successful creation of the Policy Template to the 5GMSd 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 5GMSd 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 5GMSd-Aware Application launches media session handling using an appropriate service launch mechanism at reference point M6d.

Step 6.

In response, the Media Session Handler fetches Service Access Information from the 5GMSd AF for the relevant Provisioning Session via reference point M5d. A client dynamic policy invocation configuration is provided that describes the Policy Templates applicable to the requesting 5GMSd 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 5GMSd AF.

Step 7.

The 5GMSd-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 M6d.

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 5GMSd-Aware Application subscriber(s) of the Background Data Transfer opportunity by sending a notification to each one via reference point M6d. 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 5GMSd-Aware Application that has received such a notification invokes a suitable client API on the Media Session Handler at reference point M6d. The invocation includes an estimate of the data volume the 5GMSd Client intends to transfer in the background.

Step 10.

The Media Session Handler instantiates a dynamic policy resource on the 5GMSd 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 5GMSd 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 5GMSd AF responds to the Media Session Handler to grant the Background Data Transfer request. The grant response includes a recommendation from the 5GMSd 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 5GMSd-Aware Application of the Background Data Transfer grant by sending a synchronous response or asynchronous notification to the latter at reference point M7d. This conveys the maximum time period recommendation and maximum data volume indicated by the 5GMSd AF in the previous step.

Step 14.

The 5GMSd-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 M6d.

Step 15.

As a consequence, the Media Session Handler subscribes to receive Background Data Transfer warning notifications from the 5GMSd AF by invoking a network API on the latter at reference point M5d. 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 5GMSd-Aware Application would like to download during the granted time period for Background Data Transfers:

Step 16.

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

Step 17.

The Media Player acquires the content item from the 5GMSd AS at reference point M4d using the content item URL supplied in the previous step.

Step 18.

The Media Player stores the acquired content item for later playback.

Step 19.

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

(Steps 20-28 are described below.)

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

Step 29.

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 5.7.8-2.

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

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

The steps are as follows:

Step 20.

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 5GMSd AF as defined in clause 4.16.7.3 of TS 23.502.

Step 21.

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

If the 5GMSd 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 22.

The 5GMSd 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 23.

Using an asynchronous notification mechanism at reference point M5d, the 5GMSd 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 24.

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

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

Step 25.

The 5GMSd 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 26.

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

Step 27.

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

Step 28.

As a consequence, the 5GMSd-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 M7d.