Content for TS 26.247 Word version: 18.4.0

0f… 4 5… 6… 7… 8… 9… 10… 11… 12… 13… 14… 15 A… B… C… D… F… K… L… M…

13.1 Introduction 13.2 SAND modes for 3GP-DASH 13.3 DANE discovery 13.4 SAND messages and protocols for 3GP-DASH 13.5 SAND message handling behaviours for DANEs and DASH clients 13.6 Use of SAND for Network Assistance 13.7 Use of SAND for proxy caching 13.8 Use of SAND for consistent QoE/QoS 13.9 SAND extension messages XML schema 13.10 SAND for multi-network access mode
...

13 Server And Network-assisted DASH (SAND) support |R15| p. 76

13.1 Introduction p. 76

Server And Network-assisted DASH (SAND) functionality is specified in ISO/IEC 23009-5 [54]. SAND support in PSS is described in TS 26.233. An overview of SAND functionality in ISO/IEC 23009-5 [54], 3GPP-targeted architectural considerations for SAND support, and initial use cases for SAND in context of 3GPP are described in TR 26.957.

This clause describes the following:

SAND modes to use for 3GP-DASH described in clause 13.2.
DANE discovery procedures for SAND described in clause 13.3.
SAND messages and protocols to use for 3GP-DASH described in clause 13.4.
Normative behaviours on SAND message handling for DANE and 3GP-DASH client described in clause 13.5.
Use of SAND functionality for enabling network assistance, proxy caching and consistent QoE/QoS described in clauses 13.6, 13.7 and 13.8, respectively.
XML schema for SAND extension messages, described in clause 13.9.
Use of SAND functionality for enabling SAND for Multi-Network support (SAND4M) in clause 13.10.

13.2 SAND modes for 3GP-DASH p. 77

3GP-DASH clients supporting SAND functionality shall support at least one of the following modes:

'Network Assistance', as specified in clauses 13.4, 13.5 and 13.6
'Proxy Caching', as specified in clauses 13.4, 13.5 and 13.7
'Consistent QoE/QoS', as specified in clauses 13.4, 13.5 and 13.8
'SAND for Multi-Network Access' as specified in clause 13.10.

13.3 DANE discovery p. 77

The SAND specification [54] provides the sand:Channel element in the MPD to inform the client about the location and method to communicate with the DANE. That method of DANE discovery may be used for DANEs that are in-band with respect to the media delivery path, i.e. when the MPD server may be aware of SAND functionality in the network.

An in-band DANE may also be discovered by a SAND header field in the HTTP header of an HTTP response to a request for DASH resources as defined in ISO/IEC 23009-5 [54]. In this case, no session is created between the DANE and the DASH client.

When the DANE is out-of-band with respect to the media delivery path, as is the case with the Network Assistance DANE and the Consistent QoE/QoS DANE, a more generic method for DANE discovery may be used, namely using the DNS protocol as described in TS 23.003. Toward this purpose, the UE needs a DANE Fully Qualified Domain Name (FQDN) for the DANE. The procedures for addressing and identification for Bootstrapping MBMS Service Announcement as described in clause 15.5 of TS 23.003 shall be used for DANE discovery. Accordingly, the Fully Qualified Domain Name (FQDN) for the DANE shall be "dane.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org". The URL to establish the out-of-band connection with the DANE shall be:

http://dane.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org/

The DANE FQDN is composed of six labels. The last three labels shall be "pub.3gppnetwork.org". The second and third labels together shall uniquely identify the PLMN, as described in clause 15.5 of TS 23.003. The first label shall be "dane".

When receiving a DNS query on the DANE FQDN, the DNS server shall respond with the information, including IP address, of the DANE or DANEs that are available to the UE for SAND functionality, according to any of the defined SAND modes.

Specific modes of DANE may be identified with targeted DANE FQDNs, as follows:

A Proxy-Caching DANE, if provided, shall be located at the FQDN "pcdane.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" (first label is "pcdane").
A Network Assistance DANE, if provided, shall be located at the FQDN "nadane.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" (first label is "nadane");
A Consistent QoE/QoS DANE, if provided, shall be located at the FQDN "qoedane.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" (first label is "qoedane");

If a specific mode of DANE is queried, using the specific DANE FQDN, then the response informs of the IP address of that mode of DANE only.

13.4 SAND messages and protocols for 3GP-DASH p. 77

3GP-DASH clients supporting SAND functionality in the 'Proxy Caching' mode shall support the following SAND messages (as described further in clause 13.7):

ClientCapabilities, as defined in clause 6.4.7 of ISO/IEC 23009-5 [54]
DaneCapabilities, as defined in clause 6.5.9 of ISO/IEC 23009-5 [54]
AnticipatedRequests, as defined in clause 6.4.1 of ISO/IEC 23009-5 [54]
AcceptedAlternatives, as defined in clause 6.4.3 of ISO/IEC 23009-5 [54]
DeliveredAlternative, as defined in clause 6.5.8 of ISO/IEC 23009-5 [54]
ResourceStatus, as defined in clause 6.5.1 of ISO/IEC 23009-5 [54]
MPDValidityEndTime, as defined in clause 6.5.4 of ISO/IEC 23009-5 [54]

In a PSS service environment with SAND support, DANEs in the 'Proxy Caching' mode shall also support these messages.

3GP-DASH clients supporting SAND functionality in the 'Network Assistance' mode shall support the following SAND messages (as described further in clause 13.6):

ClientCapabilities, as defined in clause 6.4.7 of ISO/IEC 23009-5 [54]
DaneCapabilities, as defined in clause 6.5.9 of ISO/IEC 23009-5 [54]
SharedResourceAssignment, as defined in clause 6.5.3 of ISO/IEC 23009-5 [54]
SharedResourceAllocation, as defined in clause 6.4.2 of ISO/IEC 23009-5 [54]
NetworkAssistanceInitiationRequest, as defined in clause 13.6
NetworkAssistanceInitiationResponse, as defined in clause 13.6
NetworkAssistanceTermination, as defined in clause 13.6
SegmentDuration, as defined in clause 13.6
DeliveryBoostRequest, as defined in clause 13.6
DeliveryBoostResponse, as defined in clause 13.6

In a PSS service environment with SAND support, DANEs in the 'Network Assistance' modes shall also support these messages.

3GP-DASH clients supporting SAND functionality in the 'Consistent QoE/QoS' mode shall support the following SAND messages (as described further in clause 13.8):

ClientCapabilities, as defined in clause 6.4.7 of ISO/IEC 23009-5 [54]
DaneCapabilities, as defined in clause 6.5.9 of ISO/IEC 23009-5 [54]
SharedResourceAssignment, as defined in clause 6.5.3 of ISO/IEC 23009-5 [54]
SharedResourceAllocation, as defined in clause 6.4.2 of ISO/IEC 23009-5 [54]
QoSInformation, as defined in clause 6.5.7 of ISO/IEC 23009-5 [54]

In a PSS service environment with SAND support, DANEs in the 'Consistent QoE/QoS' modes shall also support these messages.

In case the DASH client connects to a DANE, the 3GP-DASH client shall send the status message ClientCapabilities in order to inform the DANE about the SAND mode(s) it supports. The 3GP-DASH client shall use the messageSetUri parameter to indicate which SAND mode(s) it supports based on the following URNs:

urn:3gpp:dash:sand:messageset:pc:2016 to indicate support for the 'Proxy Caching' mode
urn:3gpp:dash:sand:messageset:na:2016 to indicate support for the 'Network Assistance' mode
urn:3gpp:dash:sand:messageset:qoe:2016 to indicate support for the 'Consistent QoE/QoS' mode
urn:3gpp:dash:sand:messageset:sand4m:2018 to indicate support for the 'SAND for Multi-Network Access' mode

Depending on the SAND mode(s) supported by the 3GP-DASH client, one or more of these URNs may be included in the ClientCapabilities message.

In case the DANE connects to a 3GP-DASH client, the DANE shall send the PER message DaneCapabilities in order to inform the 3GP-DASH client about the SAND mode(s) it supports. The DANE shall use the messageSetUri parameter to indicate which SAND mode(s) it supports based on the following URNs:

urn:3gpp:dash:sand:messageset:pc:2016 to indicate support for the 'Proxy Caching' mode
urn:3gpp:dash:sand:messageset:na:2016 to indicate support for the 'Network Assistance' mode
urn:3gpp:dash:sand:messageset:qoe:2016 to indicate support for the 'Consistent QoE/QoS' mode
urn:3gpp:dash:sand:messageset:sand4m:2018 to indicate support for the 'SAND for Multi-Network Access' mode

Depending on the SAND mode(s) supported by the DANE, one or more of these URNs may be included in the DaneCapabilities message.

If the 3GP-DASH client has already discovered the DANE via the use of mode-specific FQDNs provided in clause 13.3 (i.e., with first labels 'nadane', 'qoedane' and 'pcdane' as defined in clause 13.3), the exchange of ClientCapabilities and DaneCapabilities messages shall not be performed on connection to a DANE.

If SAND is supported, HTTP shall be supported as the minimum transport protocol for carrying SAND messages. This does not preclude that other additional transport protocols could also be implemented. The mandatory use of HTTP as a minimum transport protocol for SAND messages shall be in accordance with Table 13-1 (bold font represents mandatory):

Table 13-1: Mandatory usages of HTTP for carrying SAND messages

Metrics messages	HTTP POST HTTP headers may be used for small metrics messages.
Status messages	HTTP headers HTTP POST
PER messages	HTTP GET

For SAND status messages, carriage in HTTP headers shall be used for communicating with in-band DANEs, while HTTP POST shall be used for communicating with out-of-band DANEs. This distinction between two kinds of DANE is introduced in the high-level architecture in clause 4.2.8 of TS 26.233.

3GP-DASH clients supporting SAND functionality as well as DANEs in the 'Network Assistance' or 'Consistent QoE/QoS' modes shall further support the WebSocket protocol specified in RFC 6455, provided that HTTP over TLS (HTTPS) is supported by the respective 3GP-DASH client or DANE. If HTTP over TLS (HTTPS) is not supported by a 3GP-DASH client, then that 3GP-DASH client should support the WebSocket protocol for the 'Consistent QoE/QoS' and 'Network Assistance' modes. Similarly, if HTTP over TLS (HTTPS) is not supported by a DANE, then that DANE should support the WebSocket protocol for the 'Consistent QoE/QoS' and 'Network Assistance' modes. When WebSockets is supported for the 'Consistent QoE/QoS' mode, as specified in ISO/IEC 23009-5 [54], the MPD shall contain a sand:Channel element whose @schemeIdUri is "urn:mpeg:dash:sand:channel:websocket:2016" and WebSocket URI in the @endpoint attribute.

13.5 SAND message handling behaviours for DANEs and DASH clients p. 80

13.5.1 DASH client behaviour p. 80

3GP-DASH clients supporting one or more of the following SAND modes: (i) 'Network Assistance', (ii) 'Proxy Caching', (iii) 'Consistent QoE/QoS', shall comply with the actions in Table 13-2 in handling of the corresponding SAND messages.

Table 13-2: Normative behaviours on SAND message handling for 3GP-DASH clients

SAND Message	Actions	Nature
On DaneCapabilities and SharedResourceAllocation supported	Send SharedResourceAllocation	Mandatory
On SharedResourceAssignment	Select Representations to fit in @bandwidth	Optional
On DaneCapabilities and AnticipatedRequests supported	Send AnticipatedRequests with ALL future segment requests.	Mandatory
On DaneCapabilities and AcceptedAlternatives supported	Send AcceptedAlternatives with ANY future segment requests.	Mandatory
On MPDValidityEndTime	If @mpdUrl present, fetch MPD before @validityEndTime.	Mandatory
On MPDValidityEndTime	Else (@mpd is present by SAND specification), use @mpd as new MPD version when @validityEndTime has passed.	Mandatory

13.5.2 DANE behaviour p. 80

In a PSS service environment with one or more of the following SAND modes: (i) 'Network Assistance', (ii) 'Proxy Caching', (iii) 'Consistent QoE/QoS', DANEs shall comply with the actions in Table 13-3 in handling of the corresponding SAND messages.

Table 13-3: Normative behaviours on SAND message handling for DANEs in a PSS environment

SAND Message	Actions	Nature
On SharedResourceAllocation	1. Add client to the sharing strategy	Optional
	2. Update allocation strategy	Optional
	3. Send SharedResourceAssignment to clients in the sharing strategy	Mandatory
On AnticipatedRequests	Cache resources indicated by AnticipatedRequests and send ResourceStatus to signal available resources	Mandatory
On AcceptedAlternatives	Send DeliveredAlternatives in case DANE delivers an alternative segment rather than the requested segment	Mandatory

13.6 Use of SAND for Network Assistance p. 80

13.6.1 General description p. 80

The Network Assistance function enables a 3GP-DASH client to improve the QoE of content streaming sessions, and is provided by the DANE. The DANE for this mode is out-of-band, i.e. it is not in the media delivery path. The Network Assistance communication is independent from the media server communication, hence the Network Assistance communication occurs in a separate path to the transfer of the MPD and the content segments. The media server does not need to be aware of the Network Assistance function.

Network Assistance may be made available to certain clients only, for example subject to subscription options. Client authentication may also be applied before granting access to Network Assistance. Clients are able to discover the availability and information about the Network Assistance DANE, and to establish a Network Assistance session with the DANE.

Network Assistance is based on the model of the client requesting network assistance and the DANE responding to the request. The Network Assistance functionality may be granted to a client supporting the delivery of 3GP-DASH content with either only the first or with both of the two functions below, in both cases based on the 3GP-DASH client having made a request to the DANE for Network Assistance:

The DANE indicates to the 3GP-DASH client the highest suitable media rate for the next segment download, based on the available Representations for the content item;
The DANE indicates to the 3GP-DASH client a temporary delivery boost for occasions when the content playback input buffer on the client risks suffering from under-run.

Once a Network Assistance session is active, the client may issue a Network Assistance call prior to fetching the next media segment from the server. The Network Assistance call consists of a single SAND signalling exchange. This exchange with the DANE activates either the first of the above functions or a sequence of both functions; the second only if the 3GP-DASH client was granted access to the function. If the client does not need a delivery boost, then the DANE omits the second function in the response to the 3GP-DASH client.

The Network Assistance functions depend on only a small part of the set of SAND capabilities.

Clause 13.6.2 specifies common functions.

Clauses 13.6.3 and 13.6.4 describe the two constituent functions of Network Assistance, namely rate recommendation and temporary delivery boost, respectively.

Clause 13.6.5 specifies the Network Assistance functions and their mapping to SAND messages.

Clause 13.6.6 specified how the Network Assistance request and response calls are constructed using the SAND message container that contains the appropriate Network Assistance messages.

Clause 13.6.7 describes an example workflow for Network Assistance.

13.6.2 Common functions p. 81

13.6.2.1 Introduction p. 81

Unless the DANE location is already known to the 3GP-DASH client, for example by pre-installing a commonly used DANE location for the operator to which the client is subscribed, the client needs to discover the DANE for Network Assistance, before being able to use Network Assistance functionality.

The DANE manages the population of clients that are eligible for Network Assistance by accepting Network Assistance session initiation calls from clients. In this way the DANE is able to provide a more reliable Network Assistance function by being aware of which clients might need relevant network resources allocated at any time.

13.6.2.2 DANE discovery p. 81

DANE discovery procedures relevant for the Network Assistance mode are described in clause 13.3.

13.6.2.3 Network Assistance session initiation p. 81

The facility of Network Assistance requires that the network is aware of its possible intended usage by every client in advance of first usage of the facility. Hence the client needs to register with the DANE, providing the location of the media server delivering the content item and the IP port at which it will be delivered, in advance of the playback starting. The network thus has the possibility to apply any authentication or policy procedure on that connection, as well as be prepared for Network Assistance usage by all clients that may register for it.

The 3GP-DASH client shall initiate a Network Assistance session with the Network Assistance DANE at a convenient stage in the process of preparing to receive PSS content. When this takes place may be dependent on the nature of the application that streams media content items, but in any case the scope of the Network Assistance session is intended such that it starts with the start of playback of an individual content item, and ends when the playback of that content item is stopped.

13.6.2.4 Network Assistance session termination p. 82

When the 3GP-DASH client no longer requires Network Assistance facilities, it shall terminate the Network Assistance session. This could be the case for example when the playback of a streamed media content item is stopped, or the converse operation to that which occurred when the session was initiated.

13.6.3 Rate recommendation function p. 82

The 3GP-DASH client uses this function of the DANE to obtain a recommendation of the highest suitable media rate for an upcoming media segment download.

The 3GP-DASH client provides the necessary information, such as available media versions with the required bit rates, and buffer level, to the DANE. The DANE provides the response with the recommendation of the highest suitable media rate. The recommended rate is based on network estimations or predictions of available link bandwidth for the ensuing period of time. The recommended rate is neither enforced by the network, nor does the network make any commitment that the recommended rate will be honoured. How the information is gathered and relayed to the Network Assistance function of the DANE is out of scope of the present specification.

At the Network Assistance logical level this function includes the option for the client to indicate that it would benefit from a delivery boost during the following media segment download. This is specified in clause 13.6.5.2.

13.6.4 Temporary delivery boost function p. 82

The 3GP-DASH client uses this function to indicate to the network that a temporary boost, i.e. a temporary increase of network throughput for this client, would be needed in order to avoid the risk of media playback stalling due to buffer under-run, which could otherwise occur during the next media segment or soon after.

Throughput boosting may be used also at the start of a playback session to shorten the time to playout, giving a better experience for the user.

The network informs the client when the network applies the delivery boost, in order to ensure that the client is not misled as to the available link throughput, since this could lead to the client making an erroneous media rate selection when the throughput is back to normal again, without boost, and select a higher media rate than suitable for the next segment download. During a delivery boost period the client shall not select a higher media rate than indicated with the rate recommendation function. The client may return to its own normal media rate selection method only when the delivery boost period has ended. After the delivery of a segment with network boost, the network reverts to normal delivery, i.e. without boost.

13.6.5 SAND messages usage and extensions p. 82

13.6.5.1 Introduction p. 82

This clause contains the specification of the Network Assistance functions firstly as generic function calls, and how they could be mapped to SAND messages.

The Network Assistance (NA) DANE is out-of-band, i.e. not located in the media path. The 3GP-DASH client shall send the NA SAND messages as the body of HTTP requests directly to the NA DANE, using the HTTP POST method to send a Network Assistance message to the DANE.

The Network Assistance transactions between the 3GP-DASH client and the DANE at the logical level consist of the Network Assistance initiation and termination, the Network Assistance request and the Network Assistance response.

A combination of existing SAND messages as defined in the SAND specification, with usage as defined in clause 13.6.5.2, and SAND extension messages as defined in clause 13.6.5.3, are used.

The XML schema for the SAND extension messages is provided in clause 13.9.

13.6.5.2 Use of existing SAND messages p. 83

13.6.5.2.1 Shared resource allocation p. 83

The SAND status message SharedResourceAllocation is used in the NA request from the 3GP-DASH client to the DANE, in order to provide information about the available media bitrates for the content item to be accessed.

The parameters operationPoints and bandwidth in the SAND message SharedResourceAllocation shall represent each of the available media bitrates, indicated as the sum of all media components in each case.

13.6.5.2.2 Buffer level p. 83

In the case that the 3GP-DASH client is requesting a network delivery boost during the following segment, the SAND metrics message BufferLevel is used to inform the DANE of the current buffer level for the content item being accessed.

13.6.5.2.3 Shared resource assignment p. 83

The SAND PER message SharedResourceAssignment is used in the NA response from the DANE to the 3GP-DASH client, in order to provide the recommended choice of bitrate version for the next segment of the content item being accessed.

13.6.5.3 SAND message extensions p. 83

13.6.5.3.1 Network Assistance session initiation p. 83

The 3GP-DASH client initiates a Network Assistance session by sending the NetworkAssistanceInitiation SAND extension message to the DANE within a SAND message envelope. The generic procedure for the Network Assistance session initiation request is shown in Table 13-4.

Table 13-4: Network Assistance session initiation generic procedure

Function call	Originator → destination	Parameters
Network Assistance session initiation request	UE → DANE	Media server IP address, Media delivery port number
Network Assistance session initiation response	DANE → UE	session id, port number, WebSocket requirement

In the Network Assistance session initiation request message, the following parameters shall be set by the UE:

MediaServerIPAddress - the IP address of the media server;
MediaDeliveryPortNumber - the port number used for the delivery of the media segments.

The Network Assistance session initiation request message syntax is shown in Table 13-5.

Table 13-5: Network Assistance session initiation request message syntax

Parameter		Type	Cardinality	Description
SandMessage = NetworkAssistanceInitiationRequest		Object	1
	MediaServerIPAddress	String	1	IP address of the media server delivering content segments in the present Network Assistance session.
	MediaDeliveryPortNumber	Integer	1	Port number for media server delivering content segments in the present Network Assistance session.

The NetworkAssistanceInitiationRequest message shall be carried in a SAND message envelope, as specified in ISO/IEC 23009-5 [54], with the following constraints:

The senderID element shall be included, in order to provide a reference by which the session initiation request can be authenticated or otherwise authorised at the DANE or elsewhere in the network, relayed by the DANE receiving the message;
The generationTime element may be omitted;
The messageId element may be omitted.

The NetworkAssistanceInitiationRequest message is defined in the schema whose @schemeIdUri is:

"urn:3gpp:dash: schema:sandmessageextension:2017"

In the Network Assistance session initiation response message, the following parameters are set by the DANE:

SessionID - this is used to identify the context of any future messages relating to this Network Assistance session;
PortNumber - the DANE sets the port number at which all further NA communications in this session shall occur;
WebSocketRequirement - the DANE indicates whether the UE shall set up a WebSocket connection to the DANE for all further NA communications in this session.

The Network Assistance session initiation response SAND extension message syntax is shown in Table 13-6.

Table 13-6: Network Assistance session initiation response message syntax

Parameter		Type	Cardinality	Description
SandMessage = NetworkAssistanceInitiationResponse		Object	1
	SessionID	Integer	1	Reference to the network assistance session, allocated by the DANE. A value of 0 is reserved to indicate failure, or refusal of the NA session initiation. In case of failure, no further parameters shall be added to this message.
	PortNumber	Integer	0..1	The DANE informs the 3GP-DASH client of the port number that shall be used for NA communications in the present session.
	WebSocketRequirement	Object	0..1	The DANE informs the 3GP-DASH client whether a WebSocket shall be set up for the present session.

The NetworkAssistanceInitiationResponse message shall be carried in a SAND message envelope, as specified in ISO/IEC 23009-5 [54], with the following constraints:

The senderID element shall be included, and shall be the same as that used in the corresponding session initiation request;
The generationTime element may be omitted;

The messageId element may be omitted. The NetworkAssistanceInitiationResponse message is defined in the schema whose @schemeIdUri is:

"urn:3gpp:dash: schema:sandmessageextension:2017"

13.6.5.3.2 Network Assistance session termination p. 85

The 3GP-DASH client terminates a Network Assistance session by sending the NetworkAssistanceTermination SAND extension message to the DANE within a SAND message envelope, with parameter SessionID as allocated by the DANE when the session was initiated. Table 13-7 shows the generic procedure of Network Assistance session termination.

Table 13-7: Network Assistance session termination generic procedure

Function call	Originator → destination	Parameters
Network Assistance session termination request	UE → DANE	Session id
Network Assistance session termination response	DANE → UE	Session id

The Network Assistance session termination message syntax is shown in Table 13-8. The same SAND message is used for both request and response, only with different semantics for the SessionID parameter.

Table 13-8: Network Assistance session termination message syntax

Parameter		Type	Cardinality	Description
SandMessage = NetworkAssistanceTermination		Object	1
	SessionID	Integer	1	Reference to the network assistance session that was allocated by the DANE after successful initiation.

The request message shall not use value 0 for SessionID, since it is an invalid setting.

A response message indicating SessionID = 0 means that an unknown SessionID was provided in the request, or some other failure.

The NetworkAssistanceTermination SAND extension message is defined in the schema whose @schemeIdUri is:

"urn:3gpp:dash: schema:sandmessageextension:2017"

The NetworkAssistanceTermination message shall be carried in a SAND message envelope, as specified in ISO/IEC 23009-5 [54], with the following constraints:

The senderID element shall be included, in order to provide the same reference by which the Network Assistance session had previously been initiated;
The generationTime element may be omitted;
The messageId element may be omitted.

13.6.5.3.3 Segment duration p. 85

The segment duration SAND extension status message is used to provide the nominal segment duration for the upcoming segment, as obtained from the MPD of the content item. The generic procedure is shown in Table 13-9.

Table 13-9: Segment duration provision generic procedure

Function call	Originator → destination	Parameters
Segment duration	UE → DANE	Segment duration

The segmentDuration message syntax is shown in Table 13-10.

Table 13-10: Segment duration message syntax

Parameter		Type	Cardinality	Description
SandMessage = SegmentDuration		Object	1
	segmentDuration	Integer	1	Segment duration in milliseconds

The SegmentDuration message is used within the compound NetworkAssistanceRequest SAND transaction specified in clause 13.6.6.2.

The SegmentDuration message is defined in the schema whose @schemeIdUri is:

"urn:3gpp:dash: schema:sandmessageextension:2017"

13.6.5.3.4 Delivery boost request p. 86

The 3GP-DASH client may include a request for delivery boost in the NA request, when there is a risk that buffer underflow is imminent. The request is valid for the time period of the upcoming media segment. The client may request delivery boost for the fetch of the first media segment, in order to accelerate the start of playback. If buffer under-run remains to be an imminent risk then the client may repeat the delivery boost request for the following segment. The client may request delivery boosts until it attains a sufficient media buffer fullness level. The decision to grant or decline any boost request lies entirely with the network or DANE policy.

The delivery boost request is actuated by including the DeliveryBoostRequest message in the Network Assistance request. It is classed as a SAND PED message extension. Table 13-11 shows the generic procedure.

Table 13-11: Delivery boost request generic procedure

Function call	Originator → destination	Parameters
Delivery boost request	UE → DANE	None

The syntax of the DeliveryBoostRequest message is shown in Table 13-12.

Table 13-12: Delivery boost request message syntax

Parameter	Type	Cardinality	Description
SandMessage = DeliveryBoostRequest	Object	1

The DeliveryBoostRequest message is used within the compound NetworkAssistanceRequest SAND transaction specified in clause 13.6.6.2.

The DeliveryBoostRequest message is defined in the schema whose @schemeIdUri is:

"urn:3gpp:dash: schema:sandmessageextension:2017"

13.6.5.3.6 Delivery boost response p. 87

The delivery boost response is actuated by including the DeliveryBoostResponse message in the Network Assistance response. It is classed as a SAND PED message extension. It indicates whether the DANE grants or declines the corresponding boost request. Table 13-13 shows the generic procedure.

Table 13-13: Delivery boost response generic procedure

Function call	Originator → destination	Parameters
Delivery boost response	DANE →UE	Request granted or not

The DeliveryBoostResponse message syntax is shown in Table 13-14.

Table 13-14: Delivery boost response message syntax

Parameter		Type	Cardinality	Description
SandMessage = DeliveryBoostResponse		Object	1
	Status	Enum	1	Status of requested delivery boost

The status semantics are shown in Table 13-15.

Table 13-15: Delivery boost response status values

Status	Semantics
boostGranted	Delivery boost granted
boostDeclined	Delivery boost declined

The DeliveryBoostResponse message is used within the compound NetworkAssistanceResponse SAND transaction specified in clause 13.6.6.3.

The DeliveryBoostResponse message is defined in the schema whose @schemeIdUri is:

"urn:3gpp:dash: schema:sandmessageextension:2017"

13.6.6 Network Assistance transactions p. 87

13.6.6.1 General p. 87

The Network Assistance transactions consist of the Network Assistance request and Network Assistance response compound messages. Each of these compound messages consists of several SAND messages and/or several SAND extension messages as defined in the present specification, contained in a single SAND envelope message.

13.6.6.2 Network Assistance request p. 87

The generic procedure for the Network Assistance request is shown in Table 13-16.

Table 13-16: Network Assistance request generic procedure

Function call	Originator → destination	Parameters
Network Assistance request	Client → DANE	Segment duration Available bit rates Delivery boost request Buffer level

The Network Assistance request is realised by using a single SAND message envelope containing the following SAND messages:

SegmentDuration SAND extension message;
SharedResourceAllocation SAND status message;
Optionally the DeliveryBoostRequest SAND extension message, if the client is requesting delivery boost during the upcoming media segment;
BufferLevel SAND metrics message, which shall be included if the DeliveryBoostRequest message is included in the Network Assistance request.

The SAND message envelope is used to carry the Network Assistance request compound message, with the following constraints:

The senderId element shall be used by the UE as a reference for the Network Assistance transaction;
The generationTime element is not required for Network Assistance, hence it shall be omitted;
The messageId element is not used and shall be omitted in all Network Assistance messages.

The segment duration and available media bit rates are derived by the client from the information contained in the MPD.

The media segment duration shall be provided using the MediaSegmentDuration message, as defined in clause 13.6.5.4. The validityTime element in the SharedResourceAllocation SAND message is not required to be included.

The parameters operationPoints and bandwidth in the SAND message SharedResourceAllocation shall represent each of the available media bitrates, indicated as the sum of all media components.

The delivery boost request is activated by the inclusion of the DeliveryBoostRequest message in the SAND message envelope. It has no additional parameters. If the message is present in the Network Assistance SAND message envelope then the delivery boost request is actuated. If it is not present, then the 3GP-DASH client is not making a delivery boost request for the respective segment.

The buffer level parameter may be omitted, but if the client is requesting a boost for this segment, then the buffer level shall be communicated.

An example of a complete Network Assistance request compound message structure is shown in Table 13-17. Depicted is a specific example with six operation points available to the client, and the client is asserting the delivery boost request. The syntax of each of the component messages is specified normatively in clause 13.6.5.

Table 13-17: Network assistance request compound message structure example

Parameter
CommonEnvelope
	senderId
	SandMessage = SegmentDuration
		segmentDuration
	SandMessage = SharedResourceAllocation
		operationPoints
			Bandwidth1
			Bandwidth2
			Bandwidth3
			Bandwidth4
			Bandwidth5
			Bandwidth6
	SandMessage = DeliveryBoostRequest
	SandMessage = BufferLevel
		T
		Level

13.6.6.3 Network Assistance response |R18| p. 88

The generic procedure for the Network Assistance request is shown in Table 13-18:

Table 13-18: Network Assistance response generic procedure

Function call	Originator → destination	Parameters
Network Assistance response	DANE → Client	Recommended bitrate Delivery boost response

The Network Assistance response is realised by using a single SAND message envelope containing the following SAND messages:

One SharedResourceAssignment SAND PER message;
Optionally, one DeliveryBoostResponse SAND extension message.
The DANE provides the recommended bitrate from those listed in the Network Assistance request using the Bandwidth element in the SharedResourceAssignment message.

The validityTime element is used to express the end time of validity of the recommendation. If it is omitted then the client shall assume the validity is for the whole media segment duration, i.e. for the duration indicated in the Network Assistance request.

The DeliveryBoostResponse message indicates whether the requested boost, if requested for the upcoming media segment, is granted or declined. If no boost request was made then the Network Assistance response shall not contain a DeliveryBoostResponse message.

The syntax of a complete Network Assistance response compound message example is shown in Table 13-19. In this example the DANE communicates the recommended bandwidth and includes the response to the delivery boost request that was received from the client in the preceding Network Assistance request compound message.

Table 13-19: Network assistance response compound message structure example

Parameter
CommonEnvelope
	SandMessage = SharedResourceAssignment
		validityTime
		Bandwidth
	SandMessage = DeliveryBoostResponse
		Status

13.6.7 Example workflow for Network Assistance p. 90

Figure 13.1 shows an example workflow for the Network Assistance use case. Here it is assumed that the Network Assistance DANE location is already known by the 3GP-DASH client, hence the discovery procedure of the out-of-band DANE is not shown. It is also assumed that the client is already aware of the location of the PSS server from which it will access the content item, about which the client informs the DANE. The individual workflow steps are described in Figure 13.1.

Copy of original 3GPP image for 3GPP TS 26.247, Fig. 13.1: Example SAND workflow for Network Assistance

Figure 13.1: Example SAND workflow for Network Assistance
(⇒ copy of original 3GPP image)

Step 0.

The client and DANE exchange SAND capabilities exchange messages, as described in clause 13.4.

Step 1.

The client registers its intention to make use of the Network Assistance functionality in the DANE by initiating the Network Assistance session, using the NetworkAssistanceInitiationRequest message, providing the IP address of the media server and port number used for delivery of media segments.

Step 2.

The DANE responds to the request in step 1 with the NetworkAssistanceInitiationResponse message. If the request is accepted by the DANE, the response contains the session id, the port number for all further Network Assistance messages, and the indication of whether a WebSocket connection shall be set up by the client for further Network Assistance communications in the present Network Assistance session.

Step 3.

The client sends the NetworkAssistanceRequest message to the DANE, indicating the media content item segment duration and the available versions in terms of total bitrate. If a network delivery boost is requested for the upcoming segment then the DeliveryBoostRequest and the BufferLevel messages are included in addition.

Step 4.

The DANE responds with the NetworkAssistanceResponse message, indicating the recommended version of the content item in terms of the recommended bitrate, and whether a delivery boost is foreseen during the upcoming media segment.

Step 5.

The client issues an HTTP GET to the media server in order to initiate delivery of the media segment.

Step 6.

The media server delivers the requested segment to the client. If a delivery boost was granted for the present segment, the DANE or network may deliver a part or parts of the segment at a significantly higher bitrate than the media playback bitrate, in order to facilitate filling of the media buffer in the client.

Steps 3-6 are repeated for as long as the content item playback continues.

Step 7.

The client has ended playback of the content item, so it sends the NetworkAssistanceTerminationRequest message to the DANE, indicating the session id of the Network Assistance session.

Step 8.

The DANE confirms the termination of the Network Assistance session, also confirming the corresponding session id.

13.7 Use of SAND for proxy caching p. 91

13.7.1 Introduction p. 91

To realize partial representation caching, SAND can be used to inform DASH clients about partially cached representations, e.g., via use of the PER messages ResourceStatus, DeliveredAlternative and MPDValidityEndTime, described in clause 13.7.3. Moreover, toward realizing next segment caching, SAND can be used by DASH clients to inform the network (i.e., DANE) anticipated DASH segments, acceptable alternative content, etc. leading to next segment caching, e.g., via use of the status messages AnticipatedRequests and AcceptedAlternatives, described in clause 13.7.2. An example workflow realizing next segment caching is presented in clause 13.7.4. Further details of the proxy caching use case are in TR 26.957.

DANE discovery procedures relevant for the Proxy Caching mode are described in clause 13.3. SAND messages and protocols for the Proxy Caching mode are described in clause 13.4. SAND message handling behaviours for DANEs and 3GP-DASH clients in the Proxy Caching mode are described in clause 13.5.

13.7.2 Status messages for proxy caching p. 91

13.7.2.1 AnticipatedRequests p. 91

This message allows a 3GP-DASH client to announce to a DANE its interest to a specific set of segments. The intent is to signal the set of segments in representations that the DASH client is likely to select and request soon.

3GP-DASH clients sending an AnticipatedRequests message shall follow the syntax and semantics in Table 3 of ISO/IEC 23009-5 [54], and shall include the sourceUrl parameter.

13.7.2.2 AcceptedAlternatives p. 91

This message allows 3GP-DASH clients to inform DANEs on the media delivery path (typically caching DANEs), that when they request a given DASH segment, they are willing to accept other DASH segment(s) as an alternative. A 3GP-DASH client shall not include alternative segments unless it is ready to receive them and be able to play them.

3GP-DASH clients sending an AcceptedAlternatives message shall follow the syntax and semantics in Table 5 of ISO/IEC 23009-5 [54], and shall the sourceUrl parameter.

13.7.3 PER messages for proxy caching p. 92

13.7.3.1 ResourceStatus p. 92

This message allows for a DANE to inform a 3GP-DASH client - typically in advance - about knowledge of segment availability including the caching status of the segment(s) in the DANE.

3GP-DASH clients receiving a ResourceStatus message shall follow the syntax and semantics in Tables 10-12 of ISO/IEC 23009-5 [54].

13.7.3.2 MPDValidityEndTime p. 92

This message provides the ability to signal to the client that a given MPD, whose @type is set to 'dynamic' and @minimumUpdatePeriod is present, can only be used up to at a certain wall-clock time.

3GP-DASH clients receiving an MPDValidityEndTime message shall follow the syntax and semantics in Table 17 of ISO/IEC 23009-5 [54].

13.7.3.3 DeliveredAlternative p. 92

As a response to an AcceptedAlternatives message sent by a 3GP-DASH client, a DANE may deliver an alternative segment rather than the requested segment. If so, the DANE shall send a DeliveredAlternative message to the 3GP-DASH client to inform that the response contains a segment alternative and not the requested segment.

3GP-DASH clients receiving a DeliveredAlternative message shall follow the syntax and semantics in Table 23 of ISO/IEC 23009-5 [54].

13.7.4 Example workflow on SAND use for proxy caching p. 93

An example workflow realizing next segment caching is depicted in Figure 13.2, where DANE (PSS Server) caches content based on SAND-based status messages received from the DASH client (PSS client). For the SAND messages depicted in Figure 13.2, the messageType codes in Table 2 of ISO/IEC 23009-5 [54] are used.

Copy of original 3GPP image for 3GPP TS 26.247, Fig. 13.2: Example SAND workflow for proxy caching

Figure 13.2: Example SAND workflow for proxy caching
(⇒ copy of original 3GPP image)

Step 1.

The SAND capability exchange between the DANE and client will negotiate the use of the related SAND messages for proxy caching (using the SAND messages ClientCapabilities and DaneCapabilities as described in clause 13.4). More specifically, the DANE and DASH client negotiate the use of the following SAND messages:

PER: ResourceStatus, DeliveredAlternative, MPDValidityEndTime, DaneCapabilities
Status Messages: AnticipatedRequests, AcceptedAlternatives, ClientCapabilities

Step 2a.

Client issues an HTTP GET and sends request for media to the DANE. In the header of the HTTP request (per the standardized formats in ISO/IEC 23009-5 [54], as described in clause 13.4), client includes the SAND header that contains the status messages on proxy caching, namely on anticipated requests, accepted alternatives and/or next alternatives. DANE receives these status messages, processes them and then forwards the SAND header that contains the status messages.

Step 2b.

The DANE forwards the HTTP request for the desired media to the content server, since the DANE does not have a cached version of the media. DANE forwards the HTTP headers carrying SAND messages to without any modification.

Step 3a.

Content server responds with HTTP 200 OK with body containing media.

Step 3b.

In the HTTP response, DANE includes SAND header to advertise availability of PER messages on proxy caching with the URI hosted at the DANE for the corresponding PER messages, namely on resource status, DANE resource status and/or delivered alternatives.

Step 4.

Client issues an HTTP GET request targeting the URI hosted at the DANE to fetch the PER messages on proxy caching, namely on resource status, DANE resource status and/or delivered alternatives. In the header of the HTTP request, client may include the SAND header that contains further status messages on proxy caching, namely on anticipated requests, accepted alternatives and/or next alternatives.

Step 5.

DANE responds with the HTTP OK with body containing the PER message on proxy caching, namely on resource status, DANE resource status and/or delivered alternatives.

steps 6,7:

Client requests and downloads cached media from DANE.

13.8 Use of SAND for consistent QoE/QoS p. 94

SAND can be an enabler for video-aware network resource management to provide consistent QoE/QoS for DASH clients. As such, DANE placed at the network core can allow the service provider to perform video-aware resource management. The DANE is also considered to contain a QoE reporting server to receive periodic feedback of media buffer levels from the DASH clients. This is done by establishing an application-level feedback connection between the DASH client and the DANE for each streaming flow, e.g., via an HTTP POST connection. Hence the DANE has a synthetic view of the buffer levels of all the connected streaming clients. It computes a maximum bit rate (MBR) MBRj for each flow j and communicates the MBRj of each flow j to the respective DASH client using SAND messages. Further details of the consistent QoE/QoS use case are in TR 26.957.

Thus the DANE indirectly manages the network resources at various parts of the network by setting the QoS parameters that influence the DASH client adaptation behaviour. The DANE controls the rate adaptation of the video clients by communicating the respective MBR parameters to each client.

The video-aware resource management can be realized at the DANE via the use of SAND, where DASH clients can indicate their desired bandwidth levels through the use of the SAND status message SharedResourceAllocation and also can report QoE metrics. In addition, when the DANE determines the resource allocation across the DASH clients, it can inform the DASH clients about their resource assignments and throughput / QoS, which can be achieved by the SAND PER messages SharedResourceAssignment, Throughput and QoSInformation, as specified in clauses 6.5.3, 6.5.5 and 6.5.7 of ISO/IEC 23009-5 [54], respectively.

DANE discovery procedures relevant for the Consistent QoE/QoS mode are described in clause 13.3. SAND messages and protocols for the Consistent QoE/QoS mode are described in clause 13.4. SAND message handling behaviours for DANEs and 3GP-DASH clients in the Consistent QoE/QoS mode are described in clause 13.5.

The SAND status message SharedResourceAllocation shall follow the syntax and semantics in Table 4 of ISO/IEC 23009-5 [54]. 3GP-DASH clients sending the SharedResourceAllocation message shall include the bandwidth parameter. In addition, the SAND message common envelope shall contain the senderId parameter.

The SAND PER message SharedResourceAssignment shall follow the syntax and semantics in Table 16 of ISO/IEC 23009-5 [54]. 3GP-DASH clients receiving the SharedResourceAssignment message shall recognize the clientId and bandwidth parameters.

The SAND PER message QoSInformation shall follow the syntax and semantics in Table 22 of ISO/IEC 23009-5 [54].

An example workflow realizing the consistent QoE/QoS is depicted in Figure 13.3, where the use of the WebSocket protocol RFC 6455 is considered and the DANE functionality is hosted at the PSS server and SAND-capable DASH client capabilities are hosted in the PSS client (consistent with the SAND support in PSS as described in TS 26.233). For the SAND messages depicted in Figure 13.3, the messageType codes in Table 2 of ISO/IEC 23009-5 [54] are used.

Copy of original 3GPP image for 3GPP TS 26.247, Fig. 13.3: Example SAND workflow for consistent QoE/QoS

Figure 13.3: Example SAND workflow for consistent QoE/QoS
(⇒ copy of original 3GPP image)

Step 1.

Client issues an HTTP GET and sends request for MPD to the content server. In the header of the HTTP request, client includes the SAND header that contains the status messages on client capabilities.

Step 2.

Content server responds with HTTP 200 OK with body containing the MPD. As specified in ISO/IEC 23009-5 [54], the MPD contains a sand:Channel element whose @schemeIdUri is "urn:mpeg:dash:sand:channel:websocket:2016" and WebSocket URI in the @endpoint attribute.

steps 3, 4:

The 3GP-DASH Client parses the MPD starts downloading the segments. In addition, the sand:Channel element is located in the MPD element. Using this information, the 3GP-DASH client initiates the WebSocket connection with the out-of-band DANE (e.g., located in the PSS server) as specified in RFC 6455.

It is noted here that WebSocket-based SAND channel announcement may also be accomplished by the use of OMA DM [22].

steps 5, 6, 7, 8:

Upon successful establishment of the WebSocket connection between a 3GP-DASH Client and DANE, the 3GP-DASH client starts listening for incoming PER messages and may send metrics and status messages when needed. Since the WebSocket Protocol establishes a full-duplex connection, the DANE and the 3GP-DASH client may exchange SAND messages travelling simultaneously in opposite directions over the channel.

The DANE sends the DANE capabilities message to the 3GP-DASH Client (Step 5). When received, the 3GP-DASH Client replies with a client capabilities message (Step 6). As specified by ISO/IEC 23009-5 [54], the messages are WebSocket messages sent in the text format and formatted in XML. More specifically, the DANE and 3GP-DASH client negotiate the use of the following SAND messages for consistent QoE/QoS:

PER: SharedResourceAssignment, DaneCapabilities
Status Messages: SharedResourceAllocation, ClientCapabilities
QoE Metrics: BufferLevel, PlayList

When the capabilities messages have been exchanged, the WebSocket connection stays open and further SAND messages relevant for consistent QoE/QoS may be exchanged, namely PER messages on shared resource assignment, QoS information and throughput, QoE metrics and status messages shared resource allocation.

13.9 SAND extension messages XML schema p. 96

The XML schema for the SAND extension messages is defined in Table 13-20.

Table 13-20: XML schema for SAND extension messages

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
  targetNamespace="urn:3gpp:dash:schema:sandmessageextension:2017"
  attributeFormDefault="unqualified"
  elementFormDefault="qualified"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns="urn:3gpp:dash:schema:sandmessageextension:2017">
  <xs:annotation>
    <xs:appinfo>SAND Messages Extension</xs:appinfo>
    <xs:documentation xml:lang="en">
      This Schema defines the Server And Network Assisted DASH (SAND) messages extension for 3GPP.
    </xs:documentation>
  </xs:annotation>
  <!-- SAND message: main element -->
  <xs:element name="SANDMessage" type="SANDEnvelopeType"/>
  <!-- SAND common envelope Type -->
  <xs:complexType name="SANDEnvelopeType">
    <xs:choice maxOccurs="unbounded">
      <xs:element name="NetworkAssistanceInitiationRequest" type="NetworkAssistanceInitiationRequestType"/>
      <xs:element name="NetworkAssistanceInitiationResponse" type="NetworkAssistanceInitiationResponseType"/>
      <xs:element name="NetworkAssistanceTermination" type="NetworkAssistanceTerminationType"/>
      <xs:element name="SegmentDuration" type="SegmentDurationType"/>
      <xs:element name="DeliveryBoostRequest" type="DeliveryBoostRequestType"/>
      <xs:element name="DeliveryBoostResponse" type="DeliveryBoostResponseType"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:choice>
    <xs:attribute name="senderId" type="xs:token"/>
    <xs:attribute name="generationTime" type="xs:dateTime"/>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>
  <!-- SAND message base Type -->
  <xs:complexType name="SANDMessageType">
    <xs:attribute name="messageId" type="xs:unsignedInt"/>
    <xs:attribute name="validityTime" type="xs:dateTime"/>
  </xs:complexType>
  <!-- NetworkAssistanceInitiationRequest Type -->
  <xs:complexType name="NetworkAssistanceInitiationRequestType">
    <xs:attribute name="MediaServerIPAddress" type="xs:string" use="required"/>
    <xs:attribute name="PortNumber" type="xs:unsignedInt" use="required"/>
  </xs:complexType>
  <!-- NetworkAssistanceInitiationResponse Type -->
  <xs:complexType name="NetworkAssistanceInitiationResponseType">
    <xs:attribute name="sessionId" type="xs:unsignedInt" minOccurs="1" maxOccurs="1"/>
    <xs:attribute name="PortNumber" type="xs:unsignedInt" minOccurs="0" maxOccurs="1"/>
    <xs:attribute name="WebSocketRequired" type="WebSocketRequiredType" minOccurs="0" maxOccurs="1"/>
  </xs:complexType>
  <!-- NetworkAssistanceTermination Type -->
  <xs:complexType name="NetworkAssistanceTerminationType">
    <xs:attribute name="sessionId" type="xs:unsignedInt" use="required"/>
  </xs:complexType>
  <!-- SegmentDuration Type -->
  <xs:complexType name="SegmentDurationType">
    <xs:attribute name="duration" type="xs:unsignedInt" use="required"/>
  </xs:complexType>
  <!-- DeliveryBoostRequest Type -->
  <xs:complexType name="DeliveryBoostRequestType">
    <xs:attribute name="DeliveryBoostRequest" type="xs:string" fixed="Affirmed"/>
  </xs:complexType>
  <!-- DeliveryBoostResponse Type -->
  <xs:complexType name="DeliveryBoostResponseType">
    <xs:attribute name="DeliveryBoostStatus" type="DeliveryBoostStatusType" use="required"/>
  </xs:complexType>
  <!-- DeliveryBoostStatus Type -->
  <xs:simpleType name="DeliveryBoostStatusType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="granted"/>
      <xs:enumeration value="declined"/>
    </xs:restriction>
  </xs:simpleType>
  <!-- WebSocketRequiredType Type -->
  <xs:complexType name="WebSocketRequiredType">
    <xs:attribute name="WebSocketRequired" type="xs:string" fixed="Affirmed"/>
  </xs:complexType>
</xs:schema>

13.10 SAND for multi-network access mode p. 97

13.10.1 Introduction p. 97

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 with the present document to the DASH client. The client architecture follows TS 26.347, 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 of TS 26.347 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 TS 26.347.

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 fulfil 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 in-band channels and out of band.

13.10.2 DANE functionalities for SAND4M p. 98

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 p. 98

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 in-band 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.4.3 and clause 13.10.4.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 regularly 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 p. 98

13.10.4.1 General p. 98

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 p. 99

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 RFC 3986. 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 p. 99

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 p. 99

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.