13.10 SAND for Multi-Network Access Mode

26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

13.10.1 Introduction

The primary use case for SAND for Multi-Network Access results from the distribution of the DASH content over MBMS, for which the MBMS client acts as a DASH server or DANE in order to provide DASH formats in a manner compatible to this specification to the DASH client. The client architecture follows TS26.347 [60], Figure 5.2. In this case, DASH Server functionalities are resident on an MBMS client, that provides selected DASH functionalities. In a simplified version, the MBMS client may not provide full DASH Server functionalities but acts as a DASH Aware Network Element (DANE). This function is also particularly relevant, if the MBMS service is setup to support MBMS-operation-on-Demand (MooD) and or MBMS Service continuity. The DANE functionality in the MBMS client permits dynamic steering of the DASH client between different resources, for example broadcast distributed resources and those being provided over unicast. Clause 7.4 in TS26.347 [60] provides different options for DASH-specific interfaces between the MBMS client and the DASH client. The use of SAND in this context is also documented in clause 7.4.3 of TS26.347 [60].

In addition to this, the second major use case is that the user may join the DASH-over-MBMS service while the service is already happening. This requires that the DASH server/DANE is able to express what Segments are cached and which ones are not cached as the user was not in broadcast coverage at earlier time. This also includes signalling of Segments that may have been lost or any of those that have been removed from the local cache.

This clause provides required and recommended functions for DANE and DASH client. Despite the requirements of this mode have been designed to fulfill the SAND for MBMS functionalities, it is not restricted for this use case and this mode may also be used in other context, in particular when using multiple networks for distribution and a dynamic steering across the network. Specifically, the following cases are considered:

– Networks go down dynamically and may re-appear

– Not all resources as announced in MPD are always accessible on all networks, e.g. broadcast resource is unavailable when device is outside broadcast coverage

– Networks may have different availability times

– Not all resources are available an all networks all the time

– The DANE may issue preferences for one network

– The information may be established by inband channels and out of band.

13.10.2 DANE Functionalities for SAND4M

To address the use cases, a DANE supporting SAND4M mode shall support the following SAND messages:

– ResourceStatus, as defined in clause 6.5.1 of ISO/IEC 23009-5 [54]

– DaneResourceStatus, as defined in clause 6.5.2 of ISO/IEC 23009-5 [54]

The DANE shall support offering the SAND messages using the assistance message channels defined in clause 13.10.4.2. The DANE may support offering the SAND messages using the enforcement and/or error message channels defined in clause 13.10.4.3 and clause 13.10.4.4, respectively.

When a SAND message is offered on a DANE, this message is expected to document the current status.

13.10.3 DASH Client Functionalities for SAND4M

3GP-DASH clients supporting SAND4M mode shall support the following SAND messages:

– ResourceStatus, as defined in clause 6.5.1 of ISO/IEC 23009-5 [54]

– DaneResourceStatus, as defined in clause 6.5.2 of ISO/IEC 23009-5 [54]

The DASH Client shall support the regular SAND inband message channels defined in clause 13.10.4. The DASH client should support receiving the SAND messages using the enforcement and/or error message channels defined in clause 13.10.5.3 and clause 13.10.5.4, respectively.

The DASH Client when receiving a SAND message from the DANE is expected to use the information in the message such that it expresses the current status of the announced networks.

As long the DASH client consumes the media, it should reqularly re-request the SAND message from the same URL as provided in the message channel defined in clause 13.10.4.2. If doing so, it should use a conditional HTTP GET in order to be informed if the SAND message has been updated.

13.10.4 Message Channel

13.10.4.1 General

The following scenarios are considered for exchange between the DANE and the DASH client in the SAND4M mode.

– Client assistance: A scenario for which the message is provided as auxiliary information for the client, but the service will be continued even if the client ignores the message. This is for example the case when the service provider provides information on the availability of additional networks that may be accessed by the DASH client to request the content. For protocols and methods, see clause 13.10.4.2.

– Client Enforcement: A scenario for which the client requires to act, the network provides suitable alternatives for future requests. The DANE cannot or is not willing to respond to the request with a valid resource, but provides suitable alternatives. For protocols and methods, see clause 13.10.4.3.

– Error Cases: A scenario for which the client is informed that the request is not valid and the network provides the reason and possible resolutions for the problem. The DANE cannot respond to the request with a valid resource. For protocols and methods, see clause 13.10.4.4.

13.10.4.2 Assistance

For assistance, a dedicated HTTP header field into the response for a segment request that indicates a notification that the DANE has SAND messages to send to the DASH client shall be used. Upon receiving an HTTP entity that contains the SAND header field in its entity head, the DASH client should issue an HTTP GET request to the indicated element to receive the SAND message.

The following ABNF syntax applies for the header field:

– SAND-header-field = "MPEG-DASH-SAND" ":" element-address

– element-address = absolute-URI

The field absolute-URI takes the syntax from RFC3986 [17]. The SAND header field provides the URI to the SAND message that is to be fetched by the DASH client using an HTTP GET method.

The message channel may be offered with segment requests or MPD requests and MPD update requests.

13.10.4.3 Enforcement

For enforcement, the DANE shall use a 300 Multiple Choices response with the following details:

– the response includes an entity containing a SAND message. The entity format is specified by the media type given in the Content-Type and shall be set to sand+xml, as defined in Annex C of ISO/IEC 23009-5 [54].

– The response should not include the Location field to avoid the use of the Location field value by the user agent for automatic redirection.

This response is cacheable unless indicated otherwise.

13.10.4.4 Error Case

For error cases, the DANE shall use of a suitable 4xx error code. The response may include a SAND message from which the client can deduce the reason for the error code and potential resolution of the problem.