Content for TS 26.501 Word version: 19.2.0

1… 4… 4.1… 4.2… 4.3… 4.4 4.5… 4.6… 4.7… 4.8 4.9… 4.10… 4.11… 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.7.9… 5.8… 5.10… 5.10.3 5.10.4 5.10.5… 5.10.6… 5.10.7 5.11… 5.12… 5.12.3 5.12.4… 5.12.5… 5.13… 5.14… 6… 6.2… 6.2.2.2… 6.2.3… 6.3… 6.4… 6.8… 6.9… 6.9.5… 6.9.7 6.9.8… 7… 8… 8.2 9… A… A.4… A.8… A.11… A.13… A.15… A.16… B… C… D… E… F… G… G.2… G.3… H…

5.2.5 Procedures for downlink media streaming with per-application authorisation of media session handling operations 5.2.5.1 Overview 5.2.5.2 Authorisation of media session handling at M5d based on access token 5.2.5.3 Authorisation of media session handling at M5d based on redirection 5.2.6 Procedures for downlink streaming from multiple service locations
...

5.2.5 Procedures for downlink media streaming with per-application authorisation of media session handling operations |R18| p. 92

5.2.5.1 Overview p. 92

This clause defines procedures by which a 5GMSd Application Provider authorises a 5GMSd-Aware Application to invoke media session handling operations on the 5GMSd AF at reference point M5d.

5.2.5.2 Authorisation of media session handling at M5d based on access token p. 93

The 5GMSd Application Provider provides a different access token (e.g. a random string) via M8 to each 5GMSd-Aware Application, so that each application instance can identify itself uniquely to the 5GMSd AF. The access token is provided, for example, during the login procedure or is requested at a later stage. The validity of access tokens is often limited in time. The 5GMSd-Aware Application may need to refresh the access token depending on the token validity.

The 5GMSd-Aware Application passes the access token (via an M6 API call) to the Media Session Handler. When the Media Session Handler invokes a media session handling operation at reference point M5, it presents the access token to the 5GMSd AF. Upon receipt of such an access token, the 5GMSd AF verifies whether the access token is valid. If the token is valid, the 5GMSd-Aware Application is authorised to invoke the operation.

When the OAuth 2.0 architecture RFC 6749 is used, the 5GMSd Application Provider acts as authorization server, the 5GMSd-Aware Application acts as client and the 5GMSd AF acts as resource server.

The call flow is depicted below.

Copy of original 3GPP image for 3GPP TS 26.501, Fig. 5.2.5.2-1: Call flow for authorisation based on access token

Figure 5.2.5.2-1: Call flow for authorisation based on access token
(⇒ copy of original 3GPP image)

The steps are as follows:

Step 1.

When the user wants to use the 5GMSd-Aware Application to consume e.g. video content, the user needs to authenticate with the application and the 5GMSd Application Provider at reference point M8. (In some cases, this authorisation may be cached/stored by the application, so that the user is not always challenged to provide the login credentials.)

Step 2.

Based on the login credentials supplied in the previous step, the 5GMSd Application Provider determines the policy rights to which this application service subscription is entitled (e.g. the user may have subscribed to an SD quality video service or a 4K quality video service). According to the subscription entitlement level, the 5GMSd Application Provider creates an access token and passes this token back to the application with the login response.

Step 3.

When the 5GMSd-Aware Application (immediately or later) invokes the Media Session Handler to activate media session handling for a media delivery session, the application passes the access token to the Media Session Handler. The access token may embed a user identifier, or the user identifier may be passed as separate (anonymised) parameter.

Step 4.

When the Media Session Handler invokes a media session handling operation on the 5GMSd AF at reference point M5, it provides the access token, e.g. as an HTTP request header.

Step 5.

The 5GMSd AF verifies the access token with the 5GMSd Application Provider.

Step 6.

If the 5GMSd AF has verified that the 5GMSd-Aware Application is authorised to invoke the media session handling operation (based on the token), the 5GMSd AF carries out the requested operation. (This may involve further interaction with the PCF or NEF.)

5.2.5.3 Authorisation of media session handling at M5d based on redirection p. 94

When the OAuth 2.0 RFC 6749 Authorization Code grant type is used, either the 5GMSd Application Provider or the 5GMSd AF acts as authorization server, as shown in Figure 5.2.5.3-1. The Media Session Handler acts as client and the 5GMSd AF acts as resource server.

Copy of original 3GPP image for 3GPP TS 26.501, Fig. 5.2.5.3-1: Alternative deployments of authorization server

Figure 5.2.5.3-1: Alternative deployments of authorization server
(⇒ copy of original 3GPP image)

The call flow is depicted below.

Copy of original 3GPP image for 3GPP TS 26.501, Fig. 5.2.5.3-2: Call flow for authorisation based on access token

Figure 5.2.5.3-2: Call flow for authorisation based on access token
(⇒ copy of original 3GPP image)

Step 1.

Step 2.

When the Media Session Handler invokes a media session handling operation on the 5GMSd AF (M5 Service) at reference point M5...

Step 3.

...the 5GMSd AF identifies that authorisation is required for accessing the requested service. The 5GMSd AF sends a redirect to the Media Session Handler, which is forwarded to the 5GMSd-Aware Application.

Step 4.

The 5GMSd-Aware Application requests an access token from the authorization server, which is realised either by the 5GMSd Application Provider (at reference point M8u) or by the 5GMSd AF (at reference point M5u).

Step 5.

After determining the policy rights of the requesting 5GMSd-Aware Application, the Authorization Service creates an access token and provides it to the 5GMSd-Aware Application.

Step 6.

The 5GMSd-Aware Application attempts to activate the media session handling operation again, this time providing the access token obtained in the previous step as an additional input paramrter.

Step 7.

The Media Session Handler invokes the media session handling operation again, this time providing the obtained access token.

Step 8.

The 5GMSd AF verifies the access token with the 5GMSd Application Provider.

Step 9.

If the 5GMSd AF is satisfied that the 5GMSd-Aware Application is authorised to invoke the media session handling operation (based on the presented access token), the 5GMSd AF carries out the requested operation. (This may involve further interaction with the PCF or NEF.)

5.2.6 Procedures for downlink streaming from multiple service locations |R19| p. 96

Figure 5.2.6-1 illustrates a variant of the high-level procedure for DASH streaming defined in clause 5.2.3 that permits downlink streaming from multiple service locations. Differences from the baseline procedure in clause 5.2.3 are highlighted in boldface.

The procedure makes the following assumptions:

The Media Player has the necessary functionality to stream media content from multiple service locations. This may include the functionality needed to switch between service locations, for example by client decision, or based on steering information from the network, or the use of multiple service locations concurrently, etc.
Multiple service location configuration information required to access content across multiple service locations is available within the Media Player Entry (or available alongside the Media Player Entry such as within a document referenced by the Media Player Entry). This configuration information may be:
- Embedded in a Media Player Entry document (e.g., MPD),
- Provided alongside the Media Player Entry document, such as in a separate document referenced by a Media Player Entry document (e.g., MPD), or
- Provided as the Media Player Entry document with a reference to a document containing the media streaming presentation information (e.g., MPD).
Content is hosted at two or more service locations. These service locations may be located inside the 5GMS System (i.e., hosted by the 5GMSd AS) or outside (i.e., hosted by the 5GMSd Application Provider).

Copy of original 3GPP image for 3GPP TS 26.501, Fig. 5.2.6-1: High-level procedure for downlink streaming from multiple service locations within the 5GMS System

Figure 5.2.6-1: High-level procedure for downlink streaming from multiple service locations within the 5GMS System
(⇒ copy of original 3GPP image)

Steps:

Step 1.

The 5GMSd Application Provider provisions the 5G Media Streaming System, including content hosting and ingest, such that content is available from two or more service locations (labelled Service Location 1 and Service Location 2). Upon successful provisioning and content ingest (see clause 5.4.4), either the 5GMSd Application Provider or the 5GMSd AS may create or update Media Player Entry documents (or documents pointed to by each Media Player Entry document) to include any necessary multiple service location configuration information required by the 5GMSd Client to access media content from multiple service locations.

Step 2.

The 5GMSd-Aware Application triggers the Service Announcement and Service and Content Discovery procedure. The Service and Content Discovery procedure only involves the 5GMSd-Aware Application and the 5GMSd Application Provider. The Service Announcement includes either the whole Service Access Information (i.e. details for Media Session Handling at reference point M5d and for Media Streaming access at reference point M4d) or a reference to the whole Service Access Information.

Step 3.

A media content item is selected.

Step 4.

The 5GMSd-Aware Application triggers the 5GMSd Client to initiate the 5G Media Streaming Service.

When the 5GMS-Aware Application has received only a reference to the Service Access Information (see step 1):

Step 5.

The Media Session Handler interacts with the 5GMSd AF to acquire the whole Service Access Information. The Service Access Information may include Media Player Entry URLs.

Step 6.

The Media Session Handler provides the Media Player Entries to the 5GMS-Aware Application. The information may indicate a precedence order for these Media Player Entries.

Then:

Step 7.

The Media Player is invoked with the selected Media Player Entry to start media access and playback.

Step 8.

The Media Player establishes the transport session for acquiring the Media Player Entry.

Step 9.

The Media Player requests the Media Player Entry.

Step 10.

The Media Player receives the Media Player Entry.

Step 11.

The Media Player processes the Media Player Entry. From the Media Player Entry, the Media Player determines the multiple service location configuration, including the locations of the available service locations where content can be accessed and the method in which it should access this content (e.g., switch between service locations, use of a content steering to guide access to service locations, simultaneous use of service locations, etc.). It further determines, for example, the number of needed transport sessions for media acquisition to each service location. The Media Player should be able to use the Media Player Entry information to initialize the media pipelines for each media stream. The Media Player Entry should also contain information to initialize the DRM client, when DRM is used.

Step 12.

The Media Player notifies the Media Session Handler about the Media Player Entry.

Step 13.

Optional: the Media Player acquires the necessary DRM information, for example a DRM License.

Step 14.

The Media Player configures the media playback pipeline.

Step 15.

The Media Player establishes the necessary transport sessions for the content according to the multiple service location strategy and configuration information indicated by the Media Player Entry. These transport sessions may be established between the Media Player and any one or more of the available service locations. For example, the Media Player may establish one transport session for each media component (audio, video, etc) and possibly additional transport sessions for other media representations to each service location.

Step 16.

The Media Player notifies the Media Session Handler that it is ready to commence playback and optionally provides transport session parameters for those transport sessions terminating at the 5GMSd AS.

Step 17.

The Media Player requests and obtains the initialization information according to the multiple service location strategy in use. This initialization information may be obtained from any one service location or a combination of service locations. The Media Player repeats this step for each required initialization segment.

Step 18.

The Media Player requests and obtains the media segments according to the multiple service location strategy in use. These media segments may be obtained from any one service location or a combination of service locations. The received information is put into the appropriate media rendering pipeline.

Step 19.

Previous steps are repeated according to the Media Player Entry information.