Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 5: Server and network assisted DASH (SAND)

ISO/IEC 23009-5:2017 defines the following: - the functional SAND architecture which identifies the SAND network elements and the nature of SAND messages exchanged among them; - the semantics of SAND messages exchanged between the network elements present in the SAND architecture; - an encoding scheme for the SAND messages; - the SAND message delivery protocol.

Technologies de l'information — Diffusion en flux adaptatif dynamique sur HTTP (DASH) — Partie 5: DASH assisté par serveur et réseau (SAND)

General Information

Status
Published
Publication Date
23-Feb-2017
Current Stage
9060 - Close of review
Start Date
02-Sep-2027
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 23009-5:2017 - Information technology -- Dynamic adaptive streaming over HTTP (DASH)
English language
47 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 23009-5
First edition
2017-02
Information technology — Dynamic
adaptive streaming over HTTP
(DASH) —
Part 5:
Server and network assisted DASH
(SAND)
Technologies de l’information — Diffusion en flux adaptatif
dynamique sur HTTP (DASH) —
Partie 5: DASH assisté par serveur et réseau (SAND)
Reference number
ISO/IEC 23009-5:2017(E)
©
ISO/IEC 2017

---------------------- Page: 1 ----------------------
ISO/IEC 23009-5:2017(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 23009-5:2017(E)

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 2
3.3 Conventions . 2
4 Overview . 3
5 SAND reference architecture and interfaces . 3
6 SAND messages . 7
6.1 General . 7
6.2 Common Envelope for SAND messages . 7
6.3 Metrics messages . 9
6.3.1 General. 9
6.3.2 TCPConnections . . 9
6.3.3 HTTPRequestResponseTransactions . 9
6.3.4 RepresentationSwitchEvents . 9
6.3.5 BufferLevel .10
6.3.6 PlayList .10
6.4 Status Messages .11
6.4.1 AnticipatedRequests .11
6.4.2 SharedResourceAllocation .11
6.4.3 AcceptedAlternatives .12
6.4.4 AbsoluteDeadline .13
6.4.5 MaxRTT .14
6.4.6 NextAlternatives . .14
6.4.7 ClientCapabilities .15
6.5 PER Messages .16
6.5.1 ResourceStatus .16
6.5.2 DaneResourceStatus .17
6.5.3 SharedResourceAssignment .19
6.5.4 MPDValidityEndTime . .19
6.5.5 Throughput .20
6.5.6 AvailabilityTimeOffset.21
6.5.7 QoSInformation.22
6.5.8 DeliveredAlternative.23
6.5.9 DaneCapabilities .24
6.6 PED Messages .25
7 SAND message representation format .25
8 Transport Protocol to carry SAND messages .25
8.1 General .25
8.2 Protocol to carry metrics and status messages .25
8.2.1 General.25
8.2.2 Sending a message directly to Metrics server or DANE .26
8.2.3 Attaching a message to requests for media .26
8.3 Protocol to carry PER messages . .27
8.3.1 General.27
8.3.2 Assistance .28
8.3.3 Enforcement .28
8.3.4 Error case .28
© ISO/IEC 2017 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 23009-5:2017(E)

9 Signalling of SAND communication channel .28
9.1 General .28
9.2 XML schema for sand:Channel element .29
10 Optional transport protocols to carry SAND messages .30
10.1 General .30
10.2 WebSocket protocol .30
10.2.1 General.30
10.2.2 Signalling via the MPD .31
10.2.3 WebSocket messages . . .32
11 Reporting of metrics via SAND protocols .32
Annex A (normative) XML Schema for SAND messages .33
Annex B (normative) SharedResourceAllocation allocation strategies.41
Annex C (normative) MIME type registration for SAND message .45
Bibliography .47
iv © ISO/IEC 2017 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 23009-5:2017(E)

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: w w w . i s o .org/ iso/ foreword .html.
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO/IEC 23009 series can be found on the ISO website.
© ISO/IEC 2017 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 23009-5:2017(E)

Introduction
In order to enhance the delivery of DASH content, this document introduces messages between DASH
clients and network elements or between various network elements for the purpose of improving the
efficiency of streaming sessions by providing information about real-time operational characteristics
of networks, servers, proxies, caches, CDNs, as well as DASH client’s performance and status.
vi © ISO/IEC 2017 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 23009-5:2017(E)
Information technology — Dynamic adaptive streaming
over HTTP (DASH) —
Part 5:
Server and network assisted DASH (SAND)
1 Scope
This document defines the following:
— the functional SAND architecture which identifies the SAND network elements and the nature of
SAND messages exchanged among them;
— the semantics of SAND messages exchanged between the network elements present in the SAND
architecture;
— an encoding scheme for the SAND messages;
— the SAND message delivery protocol.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates
and times
ISO/IEC 23009-1:2014, Information technology — Dynamic adaptive streaming over HTTP (DASH) —
Part 1: Media presentation description and segment formats
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax
IETF RFC 6455, The WebSocket Protocol
IETF RFC 7233:2014, Hypertext Transfer Protocol (HTTP/1.1): Range Requests
3 Terms, definitions, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 23009-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http:// www.e lectropedia. org/
— ISO Online browsing platform: available at http:// www. iso. org/o bp
© ISO/IEC 2017 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC 23009-5:2017(E)

3.1.1
DASH Aware Network Element
DANE
network element which has at least minimum intelligence about DASH; for instance, it may be aware
that the delivered objects are DASH-formatted objects such as the MPD or DASH segments, and may
prioritize, parse or even modify such objects
3.1.2
SAND messages
messages exchanged between DASH clients, DASH aware Network Elements or Metrics Server in order
to either enhance reception (PER) or delivery (PED) of DASH service, or to report status or metrics from
the DASH client to DASH aware Network Elements or Metrics Server
3.2 Abbreviated terms
DANE DASH aware network element
DASH Dynamic Adaptive Streaming over HTTP
DM DASH Metrics
HTTP Hypertext Transfer Protocol
MPD Media Presentation Description
PED parameters enhancing delivery
PER parameters enhancing reception
RNE regular network element
SAND server and network assisted DASH
TLS transport layer security
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
UTC Coordinated Universal Time
UTF unicode transformation format
UUID universally unique identifier
XML Extensible Mark-Up Language
3.3 Conventions
The following naming conventions apply in this document.
— Elements in an XML document are identified by an upper-case first letter and in bold face as
Element. To express that an element Element1 is contained in another element Element2, we
may write Element2.Element1. If an element’s name consists of two or more combined words,
camel-casing is typically used, e.g. ImportantElement. Elements may be present either exactly
once, or the minimum and maximum occurrence is defined by . .
— Attributes in an XML document are identified by a lower-case first letter, as well as they are
preceded by a ‘@’-sign, e.g. @attribute. To point to a specific attribute @attribute contained
2 © ISO/IEC 2017 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 23009-5:2017(E)

in an element Element, one may write Element @ attribute. If an attribute’s name consists
of two or more combined words, camel-casing is typically used after the first word, e.g. @
veryImportantAttribute. Attributes may have assigned a status in the XML as mandatory (M),
optional (O), optional with default value (OD) and conditionally mandatory (CM).
— Namespace qualification of elements and attributes is used as per XML standards, in the form of
namespace: Element or @namespace: attribut e. The fully qualified namespace will be
provided in the schema fragment associated with the declaration. External specifications extending
the namespace of DASH are expected to document the element name in the semantic table with an
extension namespace prefix.
— Variables defined in the context of this document are specifically highlighted with italics, e.g.
InternalVariable.
— Structures that are defined as part of the hierarchical data model are identified by an upper-case
first letter, e.g. Period, Adaptation Set, Representation, Segment, etc.
— The term “this clause” refers to the entire clause included within the same first heading number.
The term “this subclause” refers to all text contained in the subclause with the lowest hierarchy
heading.
4 Overview
In recent years, the Internet has become an important channel for the delivery of multimedia using
HTTP as its primary protocol. In 2014, ISO/IEC published the second edition of MPEG Dynamic Adaptive
Streaming over HTTP (DASH) as an International Standard that specified formats for the media
presentation description (MPD), as well as ISO-BMFF and MPEG-2 TS based segments. DASH does not
define a system or protocol, but is considered as an enabler for efficient and high-quality delivery of
multimedia content over the Internet.
In order to enhance the delivery of DASH content, this document introduces messages between DASH
clients and network elements or between various network elements for the purpose of improving
efficiency of streaming sessions by providing information about real-time operational characteristics
of networks, servers, proxies, caches, CDNs as well as DASH client’s performance and status.
The Server and network assisted DASH (SAND) addresses the following:
— unidirectional/bidirectional, point-to-point/multipoint communication with and without session
(management) between servers/CDNs and DASH clients;
— mechanisms for providing content-awareness and service-awareness towards the underlying
protocol stack including server and/or network assistance;
— various impacts on elements of the existing Internet infrastructure such as servers, proxies, caches
and CDNs;
— QoS and QoE support for DASH-based services;
— scalability in general and specifically for logging interfaces;
— analytics and monitoring of DASH-based services.
5 SAND reference architecture and interfaces
The SAND reference architecture is based on the following four broad categories of elements.
a) DASH clients.
© ISO/IEC 2017 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC 23009-5:2017(E)

b) Regular network elements (RNE), which are DASH unaware and treat DASH delivery objects as any
other object, but are present on the path between origin server and DASH clients, e.g. transparent
caches. Note that such regular network elements are not in the scope of this document.
c) DASH aware network elements (DANE), which have at least minimum intelligence about DASH; for
instance, they may be aware that the delivered objects are DASH-formatted objects such as the
MPD or DASH segments, and may prioritize, parse or even modify such objects. More details on
typical DANE functionalities are provided.
d) Metrics server, which are DASH aware and are in charge of gathering metrics from DASH clients.
Based on these elements, the SAND reference architecture is defined as shown in Figure 2. Within this
architecture, the following four categories of messages, called SAND messages as shown in Figure 1, are
exchanged:
— Parameters Enhancing Delivery (PED) messages that are exchanged between DANEs;
— Parameters Enhancing Reception (PER) messages that are sent from DANEs to DASH clients;
— status messages that are sent from DASH clients to DANEs;
— metrics messages that are sent from DASH clients to Metrics servers.
PER messages ->
Metrics
DANE
server
<- Status messages
<- PED messages ->
PER messages ->
DASH
DANE
client
<- Status messages metrics messages ->
Figure 1 — SAND messages
4 © ISO/IEC 2017 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 23009-5:2017(E)

Figure 2 — SAND reference architecture
In this context, a media origin that serves DASH content may also receive status messages from the
clients, send PED parameters to other DANEs, and is therefore also considered as a DANE element.
Similarly, a third-party server that may receive SAND status messages from DASH clients or send SAND
PER messages to the clients is considered as a DANE element. Note that the third-party server may not
necessarily be on the media delivery path and it may not see the DASH segments. However, as it may
understand the SAND status messages or produce SAND PER messages to DASH clients, e.g to improve
delivery efficiency, it is nevertheless considered as a DANE element.
A DASH client may send two types of messages: metric messages carrying metric information and status
messages carrying operational information. The metrics and status messages have a similar structure;
however, it is important to distinguish them since these messages carry information of different nature.
Whereas status message provide real-time feedback from the client to DANEs in order to support real-
time operations, Metrics are provided as a summary of the session or at least longer time intervals of
the session and are not considered provided in real-time.
Based on this terminology, the following interfaces are considered:
— Client-to-Metrics-server Interface: Carries metrics messages;
— Client-to-DANE Interface: Carries status messages;
— DANE-to-DANE Interface: Carries PED messages;
— DANE-to-Client Interface: Carries PER messages.
The implementation of the SAND architecture is neither mandatory nor necessary for successful DASH-
based streaming operation. One may choose to implement a subset of the interfaces and messages
defined in the SAND reference architecture.
© ISO/IEC 2017 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO/IEC 23009-5:2017(E)

ISO/IEC 23009-1 gives also an overview of a possible deployment architecture for DASH. In light of the
SAND reference architecture above, Figure 3 suggests a possible extension to it for a SAND-augmented
DASH architecture.
Key
a
PER, metrics and status messages.
Figure 3 — SAND-augmented DASH architecture
In ISO/IEC 23009-1, the DASH client model consists of the DASH access engine, the Media engine and
the Application. The DASH access engine operates at the interface with the network when it comes to
receiving the MPD and the segments, even though the delivery of the MPD is out-of-scope of MPEG DASH
as stated in ISO/IEC 23009-1:2014, 5.2.1. To support the interfaces in the SAND reference architecture,
the DASH access engine becomes also responsible for the communication with the DANEs since the
DANEs are network elements providing DASH-related information. Figure 4 extends the original DASH
Client model from ISO/IEC 23009-1 with the addition of a SAND channel to communicate with DANEs.
6 © ISO/IEC 2017 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC 23009-5:2017(E)

MPD
Segment data
DASH access
Media engine
Media
  engine
output
MPEG format
SAND channel
media + timing
Event + timing
Figure 4 — SAND-augmented DASH Client model
6 SAND messages
6.1 General
This clause defines the SAND messages and their attributes. The format representation of SAND
messages is XML and is defined in Clause 7. SAND messages are XML documents for which the MIME
type is defined in Annex C.
SAND implementations may choose to support all or only a subset of the SAND messages defined here.
Additionally, implementations may create their own messages by using their own XML namespace.
SAND elements (DANEs and DASH clients) are expected to not send SAND messages when there is no
entity in the network for using them.
6.2 Common Envelope for SAND messages
All SAND messages shall use the common envelope of Table 1.
For better efficiency, the common envelope for SAND messages allows SAND messages aggregation
within the same envelope. The envelope is the unit of data that is provided to the transport layer for
sending SAND message.
All SAND messages have many parameters in common. Parameters which convey the same value for all
messages included in a same envelope are attached to this common envelope for SAND messages. All
messages also share common parameters that need to be assigned different values for each individual
message in an envelope. Table 1 defines these parameters and is implicitly included in all of the following
message definitions.
Within this document, the date-time type indicated in the tables shall be represented as specified by
ISO 8601.
Table 1 — SAND message common envelope
Parameter Type Cardinality Description
CommonEnvelope 1
token 0.1 If present, this is a unique identifier of the message sender. It
senderId
is up to the sender to provide such a unique identifier.
date- 0.1 If present, this indicates the UTC time (format as specified
generationTime
time by ISO 8601) at which the message was generated.
© ISO/IEC 2017 – All rights rese
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.