7 Download Delivery Method

26.3463GPPMultimedia Broadcast/Multicast Service (MBMS)Protocols and codecsRelease 17TS

7.1 Introduction

MBMS download delivery method uses the FLUTE protocol (RFC 3926 [9]) when delivering content over MBMS bearers. MBMS download delivery method may use OMA PUSH [79] when delivering content over other UMTS/EPS bearers. Usage of FLUTE protocol is described in clause 7.2. The Usage of OMA Push is described in clause 7.4. The FLUTE session set-up with RTSP is defined in clause 7.5.

FLUTE is built on top of the Asynchronous Layered Coding (ALC) protocol instantiation (RFC 3450 [10]). ALC combines the Layered Coding Transport (LCT) building block [11], a congestion control building block and the Forward Error Correction (FEC) building block ([12]) to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. As mentioned in (RFC 3450 [10]), congestion control is not appropriate in the type of environment that MBMS download delivery is provided, and thus congestion control is not used for MBMS download delivery. See figure 10 for an illustration of FLUTE building block structure. FLUTE is carried over UDP/IP, and is independent of the IP version and the underlying link layers used.

Figure 10: Building block structure of FLUTE

ALC uses the LCT building block to provide in-band session management functionality. The LCT building block has several specified and under-specified fields that are inherited and further specified by ALC. ALC uses the FEC building block to provide reliability. The FEC building block allows the choice of an appropriate FEC code to be used within ALC, including using the no-code FEC code that simply sends the original data using no FEC coding. ALC is under-specified and generally transports binary objects of finite or indeterminate length. FLUTE is a fully-specified protocol to transport files (any kind of discrete binary object), and uses special purpose objects – the File Description Table (FDT) Instances – to provide a running index of files and their essential reception parameters in-band of a FLUTE session.

NOTE: One way of supporting the delivery of a subset of the nominally requested content by the DASH client which indicates explicit willingness to accept such incomplete content, and based on a specific UE implementation architecture, is described in clause 7.2.3 in TR 26.946 [110].

7.2 FLUTE usage for MBMS download

7.2.0 General

The purpose of download is to deliver content in files. In the context of MBMS download, a file contains any type of MBMS data (e.g. 3GPP file (Audio/Video), Binary data, Still images, Text, Service Announcement metadata).

In the present document the term "file" is used for all objects carried by FLUTE (with the exception of the FDT Instances).

UE applications for MBMS user services built upon the download delivery method have three general approaches to getting files from the FLUTE receiver for a joined session:

– Promiscuous: Instruct FLUTE to promiscuously receive all files available. Promiscuous reception can be suitable for single purpose sessions (generally with limited number and/or size of files) although uncertainty over the quality and content of files makes this approach generally undesirable.

– One-copy: Instruct FLUTE to receive a copy of one or more specific files (identified by the fileURI) – and potentially leaving the session following reception of one copy of all the specified files. Specifying the download file ensures that the UE has an upper bound to the quantity of files downloaded. One-copy reception requires prior knowledge of the file identifiers (fileURIs).

– Keep-updated: Instruct FLUTE to receive one or more specific files and continue to receive any updates to those files. As with one-copy, the keep-updated approach bounds the quantity of files downloaded and requires prior knowledge of the file identifiers. In order to realise an efficient keep-updated service, where file updates are unpredictable and maybe far apart in time, a registration and notification service is defined in sub-clause 7.7.

NOTE: The keep updated service is optional for the UE. In the absence of content filtering tools, the service is typically offered to a restricted set of applications.

NOTE: The present document does not prevent or endorse changing download reception approach, and any related file list, during the life of the download session. Discovery of session content lists (including file lists) out-of-band of the delivery method sessions is beyond the scope of the present document.

The interaction of these file download modes and the caching directives is defined in sub-clause 7.2.13.

MBMS clients and servers supporting MBMS download shall implement the FLUTE specification (RFC 3926 [9]), as well as ALC (RFC 3450 [10]) and LCT (RFC 3451 [11]) features that FLUTE inherits. In addition, several optional and extended aspects of FLUTE ,as described in the following clauses, shall be supported.

One FDT instance is typically bound to one MBMS transmission session. It is therefore recommended, that each MBMS transmission session should contain one or more repetitions of the same FDT instance.

7.2.1 Fragmentation of Files

Fragmentation of files shall be provided by a blocking algorithm (which calculates source blocks from source files) and a symbol encoding algorithm (which calculates encoding symbols from source blocks).

7.2.2 Symbol Encoding Algorithm

The "Compact No-Code FEC scheme" – [12] (FEC Encoding ID 0, also known as "Null-FEC") shall be supported.

The Raptor FEC scheme is described in sub-clause 7.2.12.

A UE that supports MBMS User Services shall support a decoder for the Raptor FEC scheme.

If a UE that supports MBMS User Services receives a mathematically sufficient set of encoding symbols generated according to the encoder specification in [91] for reconstruction of a source block then the decoder shall recover the entire source block. Note that the example decoder described in [91] clause 5.5 fulfils this requirement.

7.2.3 Blocking Algorithm

In the case of the Compact No-Code FEC scheme [12] (FEC Encoding ID 0), then the "Algorithm for Computing Source Block Structure" described within the FLUTE specification (RFC 3926 [9]) shall be used.

In the case of Raptor forward error correction, then the algorithm defined in [91] shall be used.

The values of N, Z, T and A shall be set such that the sub-block size is less than 256KB.

7.2.4 Congestion Control

For simplicity of congestion control, FLUTE channelization shall be provided by a single FLUTE channel with single rate transport.

7.2.5 Content Encoding of Files for Transport

Files may be content encoded for transport, as described in [9], in the Download delivery method using the generic GZip algorithm as specified in RFC 1952 [42]. UEs shall support GZip content decoding of FLUTE files (GZIP RFC 1952 [42], clause 9).

7.2.6 Transport File Grouping

Files downloaded as part of a multiple-file delivery are generally related to one another. Examples include web pages, software packages, and the referencing metadata envelopes and their metadata fragments. FLUTE clients analyse the XML-encoded FDT Instances as they are received, identify each requested file, associate it with FLUTE packets (using the TOI) and discover the relevant in-band download configuration parameters of each file.

An additional "group" field in the FLUTE FDT instance and file elements enables logical grouping of related files. A FLUTE receiver should download all the files belonging to all groups where one or more of the files of those groups have been requested. However, a UE may instruct its FLUTE receiver to ignore grouping to deal with special circumstances, such as low storage availability.

The group names are allocated by the FLUTE sender and each specific group name shall group the corresponding files together as one group, including files describes in the same and other FDT Instances, for a session.

Group field usage in FDT Instances is shown in the FDT XML schema (clause 7.2.10). Each file element of an FDT Instance may be labelled with zero, one or more group names. Each FDT Instance element may be labelled with zero, one or more group names which are inherited by all files described in that FDT Instance.

7.2.7 Signalling of Parameters with Basic ALC/FLUTE Headers

FLUTE and ALC mandatory header fields shall be as specified in [9, 10] with the following additional specializations:

– The length of the CCI (Congestion Control Identifier) field shall be 32 bits and it is assigned a value of zero (C=0).

– The Transmission Session Identifier (TSI) field shall be of length 16 bits (S=0, H=1, 16 bits).

– The Transport Object Identifier (TOI) field should be of length 16 bits (O=0, H=1).

– Only Transport Object Identifier (TOI) 0 (zero) shall be used for FDT Instances.

– The following features may be used for signalling the end of session and end of object transmission to the receiver:

– The Close Session flag (A) for indicating the end of a session.

– The Close Object flag (B) for indicating the end of an object.

In FLUTE the following applies:

– The Sender Current Time present flag (T) shall be set to zero.

– The Expected Residual Time present flag (R) shall be set to zero.

– The LCT header length (HDR_LEN) shall be set to the total length of the LCT header in units of 32-bit words.

– For "Compact No-Code FEC scheme" [12], the FEC Payload ID shall be set according to RFC 3695 [13] such that a 16 bit SBN (Source Block Number) and then the 16 bit ESI (Encoding Symbol ID) are given.

– For "MBMS FEC scheme", the FEC Payload ID shall be set according to Clause 7.2.12.1.

– For "EXT_TIME" LCT Header [119], the sender may include it in all or some of the LCT packets for a file transmission. If EXT_TIME is included, it shall contain the ERT time value set according to [119].

7.2.8 Signalling of Parameters with FLUTE Extension Headers

The FLUTE sender shall use FLUTE extension header fields EXT_FDT, EXT_FTI , EXT_CENC [9] as follows:

– EXT_FTI shall be included in every FLUTE packet carrying symbols belonging to any FDT Instance.

– FLUTE packets carrying symbols of files (not FDT Instances) shall not include an EXT_FTI.

– FDT Instances shall not be content encoded and therefore EXT_CENC shall not be used.

According to FLUTE [9] the following rules apply for a FLUTE sender:

– EXT_FDT is in every FLUTE packet carrying symbols belonging to any FDT Instance.

– FLUTE packets carrying symbols of files (not FDT instances) do not include the EXT_FDT.

Note: As an MBMS client conforms to a FLUTE receiver the receiver side treatment of LCT extension headers is covered by RFC3451 and RFC3926. The actions when receiving EXT_FDT and EXT_FTI are defined in RFC3926. The default action for unrecognized header extensions is to ignore them.

7.2.9 Signalling of Parameters with FDT Instances

The extended FLUTE FDT instance schema defined in clause 7.2.10.1 (based on the one in RFC 3926 [9]) shall be used. In addition, the following applies to both the session level information and all files of a FLUTE session.

The inclusion of these FDT Instance data elements is mandatory according to the FLUTE specification:

– Content-Location (URI of a file).

– TOI (Transport Object Identifier of a file instance).

– Expires (expiry data for the FDT Instance).

For MBMS operation, the UE shall not use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance.

NOTE 1: This requirement is strengthened for MBMS compared to RFC 3926 [9], where it is mentioned that "the receiver SHOULD NOT use a received FDT Instance to interpret packets received beyond the expiration time of the FDT Instance."

NOTE 2: It is expected that a TOI value may be reused after the highest expiry time of the FDT instances containing that TOI value.

NOTE 3: Since the expiry time corresponds to the end of transmission, A UE can either clean up its memory in case not sufficient symbols are received, or perform file repair if enabled in the system, or make partial file delivery available to the application (e.g. see clause 7.2.3 in TR 26.946 [110]).

Additionally, the inclusion of these FDT Instance data elements is mandatory. Note the following elements are optional in the FDT schema to stay aligned with the IETF RFC defined schema:

– Content-Length (source file length in bytes).

– Content-Type (content MIME type).

– FEC Encoding ID.

Other FEC Object Transmission Information specified by the FEC scheme in use:

NOTE 4: The FEC Object Transmission Information elements used are dependent on the FEC scheme, as indicated by the FEC Encoding ID.

– FEC-OTI-Maximum-Source-Block-Length.

– FEC-OTI-Encoding-Symbol-Length.

– FEC-OTI-Max-Number-of-Encoding-Symbols.

– FEC-OTI-Scheme-Specific-Info.

NOTE 5: RFC 3926 [9] describes which part or parts of an FDT Instance may be used to provide these data elements.

These optional FDT Instance data elements may or may not be included for FLUTE in MBMS:

– Complete (the signalling that an FDT Instance provides a complete, and subsequently unmodifiable, set of file parameters for a FLUTE session may or may not be performed according to this method).

– Content-Encoding.

– Content-MD5: represents a digest of the transport object. The file server should indicate the MD5 hash value whenever multiple versions of the file are anticipated for the download session.

– IndependentUnitPositions: represents a list of byte position in the file, at which the handler assigned to the Content-Type for the file may access the file.

– File-ETag: represents the value of the ETag, or entity-tag as defined in RFC 2616 [18] which mays also serve as the version identifier of the file object described by the FDT Instance.

NOTE 6: The values for each of the above data elements are calculated or discovered by the FLUTE sender.

The FEC-OTI-Scheme-Specific-Info FDT Instance data element contains information specific to the FEC scheme indicated by the FEC Encoding ID encoded using base64.

7.2.10 FDT Schema

7.2.10.1 Extended FLUTE FDT Schema

The below XML Schema shall be use for the FDT Instance.

This schema extends the schema defined in clause 7.2.10.3 by importing the 3GPP extensions specified in clauses 7.2.10.2, 7.2.10.5, 7.2.14 and 7.2.15. The various schema file names are as follows:

– Schema in clause 7.2.10.1: FLUTE-FDT-3GPP-Main.xsd

– Schema in clause 7.2.10.2: FLUTE-FDT-3GPP-2005-Extensions.xsd

– Schema in clause 7.2.10.5: FLUTE-FDT-3GPP-2007-Extensions.xsd

– Schema in clause 7.2.14: FLUTE-FDT-3GPP-2008-Extensions.xsd

– Schema in clause 7.2.15: FLUTE-FDT-3GPP-2009-Extensions.xsd

– Schema in clause 7.2.10.2: FLUTE-FDT-3GPP-2012-Extensions.xsd

– Schema in clause 7.2.10.2: FLUTE-FDT-3GPP-2015-Extensions.xsd

– Schema in clause J.2: schema-version.xsd

In this version of the specification the network shall set the schemaVersion element, defined as a child of FDT-Instance element, to 4.

The schema version attribute (part of the schema instruction) shall be included in the UE schema and the network schema.

Note: The value of the schemaVersion element and version attribute is intended to be increased by 1 in every future releases where new element(s) or attribute(s) are added.

When a UE receives an instantiation of an FDT compliant to this schema, it shall determine the schema version required to parse the instantiation as follows:

– If the UE supports one or more versions of the FDT schema with the schema version attribute, then the UE shall use the schema that has the highest schema version attribute value that is equal to or less than the value in the received schemaVersion element;

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

xmlns="urn:IETF:metadata:2005:FLUTE:FDT"

xmlns:fl="urn:IETF:metadata:2005:FLUTE:FDT"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:mbms2005="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"

xmlns:mbms2007="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"

xmlns:mbms2008="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"

xmlns:mbms2009="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"

xmlns:mbms2012="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"

xmlns:mbms2015="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"

xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"

targetNamespace="urn:IETF:metadata:2005:FLUTE:FDT"

elementFormDefault="qualified"

version="3">

<xs:import namespace="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"

schemaLocation="FLUTE-FDT-3GPP-2005-Extensions.xsd"/>

<xs:import namespace="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"

schemaLocation="FLUTE-FDT-3GPP-2007-Extensions.xsd"/>

<xs:import namespace="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"

schemaLocation="FLUTE-FDT-3GPP-2008-Extensions.xsd"/>

<xs:import namespace="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"

schemaLocation="FLUTE-FDT-3GPP-2009-Extensions.xsd"/>

<xs:import namespace="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"

schemaLocation="FLUTE-FDT-3GPP-2012-Extensions.xsd"/>

<xs:import namespace="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"

schemaLocation="FLUTE-FDT-3GPP-2015-Extensions.xsd"/>

<xs:import namespace="urn:3gpp:metadata:2009:MBMS:schemaVersion"

schemaLocation="schema-version.xsd"/>

<xs:element name="FDT-Instance" type="FDT-InstanceType"/>

<xs:complexType name="FDT-InstanceType">

<xs:sequence>

<xs:element name="File" type="FileType" maxOccurs="unbounded"/>

<xs:element ref="sv:schemaVersion"/>

<xs:element ref="mbms2012:Base-URL-1" minOccurs="0" maxOccurs="unbounded"/>

<xs:element ref="mbms2012:Base-URL-2" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="sv:delimiter"/>

<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="Group" type="mbms2005:groupIdType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="MBMS-Session-Identity-Expiry" type="mbms2005:MBMS-Session-Identity-Expiry-Type" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="Expires" type="xs:string" use="required"/>

<xs:attribute name="Complete" type="xs:boolean" use="optional"/>

<xs:attribute name="Content-Type" type="xs:string" use="optional"/>

<xs:attribute name="Content-Encoding" type="xs:string" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Encoding-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Instance-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Encoding-Symbol-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Scheme-Specific-Info" type="xs:base64Binary" use="optional"/>

<xs:attribute ref="mbms2008:FullFDT" use="optional" default="false"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="FileType">

<xs:sequence>

<xs:element ref="mbms2007:Cache-Control" minOccurs="0"/>

<xs:element ref="sv:delimiter"/>

<xs:element ref="mbms2012:Alternate-Content-Location-1" minOccurs="0" maxOccurs="unbounded"/>

<xs:element ref="mbms2012:Alternate-Content-Location-2" minOccurs="0" maxOccurs="unbounded"/>

<xs:element ref="sv:delimiter"/>

<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="Group" type="mbms2005:groupIdType" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="MBMS-Session-Identity" type="mbms2005:MBMS-Session-Identity-Type" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="Content-Location" type="xs:anyURI" use="required"/>

<xs:attribute name="TOI" type="xs:positiveInteger" use="required"/>

<xs:attribute name="Content-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="Transfer-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="Content-Type" type="xs:string" use="optional"/>

<xs:attribute name="Content-Encoding" type="xs:string" use="optional"/>

<xs:attribute name="Content-MD5" type="xs:base64Binary" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Encoding-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Instance-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Encoding-Symbol-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Scheme-Specific-Info" type="xs:base64Binary" use="optional"/>

<xs:attribute ref="mbms2009:Decryption-KEY-URI" use="optional"/>

<xs:attribute ref="mbms2012:FEC-Redundancy-Level" use="optional"/>

<xs:attribute ref="mbms2012:File-ETag" use="optional"/>

<xs:attribute ref="mbms2015:IndependentUnitPositions" use="optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:schema>

7.2.10.2 3GPP FDT Extension Type Schema

The extension of the IETF FLUTE FDT schema is done using the following schema definition:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

xmlns="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"

elementFormDefault="qualified">

<xs:complexType name="MBMS-Session-Identity-Expiry-Type">

<xs:simpleContent>

<xs:extension base="MBMS-Session-Identity-Type">

<xs:attribute name="value" type="xs:unsignedInt" use="required"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:simpleType name="MBMS-Session-Identity-Type">

<xs:restriction base="xs:unsignedByte"/>

</xs:simpleType>

<xs:simpleType name="groupIdType">

<xs:restriction base="xs:string"></xs:restriction>

</xs:simpleType>

</xs:schema>

The Release 11 extension of the FLUTE FDT schema is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

xmlns="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:ns1="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"

targetNamespace="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"

elementFormDefault="qualified">

<xs:element name="Alternate-Content-Location-1" type="Alternative-Content-LocationType"/>

<xs:element name="Alternate-Content-Location-2" type="Alternative-Content-LocationType"/>

<xs:complexType name="Alternative-Content-LocationType">

<xs:sequence>

<xs:element name="Alternate-Content-Location" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="Availability-Time" type="xs:dateTime"/>

</xs:complexType>

<xs:element name="Base-URL-1" type="xs:anyURI"/>

<xs:element name="Base-URL-2" type="xs:anyURI"/>

<xs:attribute name="FEC-Redundancy-Level" type="xs:unsignedInt"/>

<xs:attribute name="File-ETag" type="xs:string"/>

</xs:schema>

The Release 13 extension of the FLUTE FDT schema is as follows:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

xmlns="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"

elementFormDefault="qualified">

<xs:attribute name="IndependentUnitPositions" type="IndependentUnitPositionsType"/>

<xs:simpleType name="IndependentUnitPositionsType">

<xs:list itemType="xs:unsignedLong"/>

</xs:simpleType>

</xs:schema>

7.2.10.3 IETF FDT Schema

Below is the IETF based FDT XML schema that has been extended to define the main FDT schema in sub-clause 7.2.10.1.

NOTE 1: As the schema in RFC 3926 is not valid there exist no stable reference, thus this specification will include this schema until IETF has published an updated version of the schema.

NOTE 2: The schema in this sub-clause is provided for information, since the extended schema of sub-clause 7.2.10.1 is copying all the schema of this sub-clause and adds 3GPP specific extensions to it.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

xmlns="urn:IETF:metadata:2005:FLUTE:FDT"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:IETF:metadata:2005:FLUTE:FDT"

elementFormDefault="qualified">

<xs:element name="FDT-Instance" type="FDT-InstanceType"/>

<xs:complexType name="FDT-InstanceType">

<xs:sequence>

<xs:element name="File" type="FileType" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="Expires" type="xs:string" use="required"/>

<xs:attribute name="Complete" type="xs:boolean" use="optional"/>

<xs:attribute name="Content-Type" type="xs:string" use="optional"/>

<xs:attribute name="Content-Encoding" type="xs:string" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Encoding-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Instance-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length" type="xs:unsignedLong"

use="optional"/>

<xs:attribute name="FEC-OTI-Encoding-Symbol-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols" type="xs:unsignedLong"

use="optional"/>

<xs:attribute name="FEC-OTI-Scheme-Specific-Info" type="xs:base64Binary" use="optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="FileType">

<xs:sequence>

<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="Content-Location" type="xs:anyURI" use="required"/>

<xs:attribute name="TOI" type="xs:positiveInteger" use="required"/>

<xs:attribute name="Content-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="Transfer-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="Content-Type" type="xs:string" use="optional"/>

<xs:attribute name="Content-Encoding" type="xs:string" use="optional"/>

<xs:attribute name="Content-MD5" type="xs:base64Binary" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Encoding-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-FEC-Instance-ID" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Maximum-Source-Block-Length" type="xs:unsignedLong"

use="optional"/>

<xs:attribute name="FEC-OTI-Encoding-Symbol-Length" type="xs:unsignedLong" use="optional"/>

<xs:attribute name="FEC-OTI-Max-Number-of-Encoding-Symbols" type="xs:unsignedLong"

use="optional"/>

<xs:attribute name="FEC-OTI-Scheme-Specific-Info" type="xs:base64Binary" use="optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:schema>

7.2.10.4 Example of FDT

<?xml version="1.0" encoding="UTF-8"?>

<FDT-Instance

xmlns="urn:IETF:metadata:2005:FLUTE:FDT"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:mbms2007="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"

xmlns:mbms2008="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"

xmlns:mbms2009="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext" xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"

xsi:schemaLocation="urn:IETF:metadata:2005:FLUTE:FDT FLUTE-FDT-3GPP-Main.xsd"

FEC-OTI-FEC-Encoding-ID="1"

Complete="true"

Content-Encoding="gzip"

FEC-OTI-Encoding-Symbol-Length="512"

Expires="331129600"

mbms2008:FullFDT="true">

<File

Content-Type="application/sdp"

Content-Length="7543"

Transfer-Length="4294"

TOI="2"

FEC-OTI-Encoding-Symbol-Length="16"

FEC-OTI-Scheme-Specific-Info="AAEBBA=="

Content-Location="http://www.example.com/fancy-session/main.sdp"

mbms2009:Decryption-KEY-URI="http://www.example.com/key-uri">

<mbms2007:Cache-Control>

<mbms2007:Expires>331129630</mbms2007:Expires>

</mbms2007:Cache-Control>

<sv:delimiter>0</sv:delimiter>

<sv:delimiter>0</sv:delimiter> <MBMS-Session-Identity>93</MBMS-Session-Identity>

</File>

<File

Content-Type="String"

Content-Length="161934"

Transfer-Length="157821"

TOI="3"

FEC-OTI-Encoding-Symbol-Length="512"

Content-Location="http://www.example.com/fancy-session/trailer.3gp">

<sv:delimiter>0</sv:delimiter>

<sv:delimiter>0</sv:delimiter>

<MBMS-Session-Identity>93</MBMS-Session-Identity>

</File>

<sv:schemaVersion>2</sv:schemaVersion>

<sv:delimiter>0</sv:delimiter>

<MBMS-Session-Identity-Expiry value="3311288760">93</MBMS-Session-Identity-Expiry>

</FDT-Instance>

7.2.10.5 3GPP FDT Extensions

The following schema defines the new elements

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

xmlns="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"

elementFormDefault="qualified">

<xs:element name="Cache-Control">

<xs:complexType>

<xs:choice>

<xs:element name="no-cache" type="xs:boolean" fixed="true"/>

<xs:element name="max-stale" type="xs:boolean" fixed="true"/>

<xs:element name="Expires" type="xs:unsignedInt"/>

</xs:choice>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

</xs:element>

</xs:schema>

7.2.10.6 FEC Redundancy Level Extension

A MBMS download service may indicate FEC redundancy level in FLUTE FDT instance. The attribute " FEC-Redundancy-Level" is included within element "file" of the FDT to indicate the FEC redundancy level for the file. For example,if the FEC-Redundancy-Level is set to 20, it means BM-SC will add 20% extra redunancy for this file during MBMS delivery.

The FEC redundancy level information may be used by the MBMS client to e.g. stop decoding a particular DASH segment when MBMS client detects that the packet loss rate already exceeds the FEC redundancy level for that segment.

The XML syntax of the " FEC-Redundancy-Level" attribute within the FLUTE FDT is specified in clause 7.2.10.2, and the attribute is further refered to by the main FDT schema of clause 7.2.10.1.

7.2.11 MBMS Session Identity

The MBMS-Session-Identity element associates the file to the identity of the MBMS session. If the file will be part of several MBMS transmission sessions, then a list of MBMS session identities is defined.

The MBMS-Session-Identity-Expiry element associates an expiration time with a MBMS session identity value. Similar to the FLUTE FDT expiration time, the MBMS session identity expiration time (value attribute) is expressed within the FDT Instance payload as a 32 bit data field. The value of the data field represents the 32 most significant bits of a 64 bit Network Time Protocol (NTP) [78] time value. These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900.

7.2.12 FEC Scheme definition

7.2.12.1 General

This clause defines an FEC encoding scheme for the MBMS forward error correction code defined in [91] for the download delivery method. This scheme is identified by FEC Encoding ID 1. The FEC Payload ID format and FEC Object Transmission Information format are as defined in [91], sub-clauses 3.1 and 3.2 respectively.

7.2.13 Caching Directives

A file download service may indicate the caching recommendations for a specific file or set of files that are delivered using FLUTE. The caching directives are to be used with the file download modes as follows:

– Promiscuous mode: it is recommended to use the caching directives with the promiscuous mode as it enables improved management of the storage at the UE. Applications make use of available copies of files as long as their respective caching time is still valid. In case one or several files have expired and the download session is still available, the UE should join the FLUTE session and download the expired files. Alternatively, the UE may attempt to retrieve the file using HTTP and the file URL.

– One-Copy mode: Caching directives may be used with the one-copy mode to indicate the validity of a certain file. Applications requesting the file will receive the cached file as long as it is still valid. A file that is not expected to be static may indicate a long expiry time or permanent validity.

– Keep-Updated mode: it is recommended to use the caching directives with the keep-updated mode to indicate the validity of a certain file. Applications requesting the file will receive the cached file as long as it is still valid.

The caching functionality defines three different caching directives:

– no-cache: this directive is used to indicate to the receiver not to cache a specific file (or set of files). This is probably useful in the case where the file is expected to be highly dynamic (changes to the file occur quite often) or if the file will be used only once by the receiver application.

– max-stale: this directive indicates to the FLUTE receiver that a specific file (or set of files) should be cached for an indefinite period of time, if possible. The file has no expiry date.

– Expires: this directive is used by the server to indicate the expected expiry time of a specific file (or set of files). It indicates a date and time value expressed as the 32 most significant bits of the NTP [78] 64-bit timestamp format. These 32 bits provide an unsigned integer representing the time in seconds relative to 0 hours 1 January 1900.

The syntax of the caching directives is described in section 7.2.10.5.

7.2.14 Indicating a full FDT snapshot

If the server wants to inform the client about the current FDT snapshot, the server shall set the "FullFDT" attribute in the FLUTE FDT instance file. If the "FullFDT" attribute is set, the FDT instance shall be equivalent to the full File Delivery Table. Note FDT instances with a higher FDT instance ID may again extend the File Delivery Table.

A new attribute "FullFDT" is created within the element "FDT-Instance" of the FDT to indicate to the receivers that the FDT Instance contains the exact set of Transport Objects that are currently scheduled for transmission by the sender, in the actual FLUTE session.

The XML syntax of the "FullFDT" attribute within the FLUTE FDT is the following.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"
xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"

elementFormDefault="qualified">

<xs:attribute name="FullFDT" type="xs:boolean"

/>

</xs:schema>

This attribute differs from the existing "Complete" attribute in that the "Complete" attribute indicates that no new objects description will be provided in future FDT Instances within this session.

No assumption shall be made about the fact that a given FDT instance for which the attribute "FullFDT" is absent or set to FALSE, contains the exact set of Transport Objects that are currently scheduled for transmission by the sender, in the actual FLUTE session.

When two FDT instances with attribute "FullFDT" is equal to TRUE are received by a receiver and valid in a given time (that is to say they have not expired), the FDT instance with the highest FDT Instance ID shall be used by the terminal.

7.2.15 Decryption key indicating of protected download data

A MBMS download service may indicate relevant decryption key file for protected download file in FLUTE FDT instance. A new attribute "Decryption-KEY-URI" is created within element "file" of the FDT to indicate the association between protected download file and relevant decryption key file. The value of "Decryption-KEY-URI" in "file" element shall be equal to the content-location of the MIKEY file that contains the decryption key file.

When the server delivers a protected download file, the server should set a "Decryption-KEY-URI" field in the corresponding file element in the FLUTE FDT instance. When a UE receives a protected file, the UE may instruct its FLUTE receiver to download the relevant decryption key file according to "Decryption-KEY-URI" field in file element of FDT instance.

The XML syntax of the "Decryption-KEY-URI" attribute within the FLUTE FDT is the following.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"

elementFormDefault="qualified">

<xs:attribute name="Decryption-KEY-URI" type="xs:anyURI"/>

</xs:schema>

7.3 SDP for Download Delivery Method

7.3.1 Introduction

RFC 3926 [9] describes required and optional parameters for FLUTE session and media descriptors. This clause specifies SDP for FLUTE session that is used for the MBMS download and service announcement sessions. The formal specification of the parameters is given in ABNF ([23]).

7.3.2 SDP Parameters for MBMS download session

7.3.2.0 General

The semantics of a Session Description of an MBMS download session includes the following parameters:

– The sender IP address.

– The number of channels in the session.

– The destination IP address and port number for each channel in the session per media.

– The Transport Session Identifier (TSI) of the session.

– The start time and end time of the session.

– The protocol ID (i.e. FLUTE/UDP).

– Media type(s) and fmt-list.

– Data rate using existing SDP bandwidth modifiers.

– Mode of MBMS bearer per media.

– FEC capabilities and related parameters.

– Service-language(s) per media.

– QoE Metrics (as defined in sub-clauses 8.3.2.1 and 8.4).

– Alternative TMGI

This list includes the parameters required by FLUTE – RFC 3926 [9]

These shall be expressed in SDP ( [14] and [15]) syntax according to the following clauses.

7.3.2.1 Sender IP address

There shall be exactly one IP sender address per MBMS download session, and thus there shall be exactly one IP source address per complete MBMS download session SDP description. The IP source address shall be defined according to the source-filter attribute ("a=source-filter:") ( [14] and [15]) for both IPv4 and IPv6 sources, with the following exceptions:

1. Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and inclusive-mode shall use exactly one source address in the <src-list>.

2. There shall be exactly one source-filter attribute per complete MBMS download session SDP description, and this shall be in the session part of the session description (i.e. not per media).

3. The * value shall be used for the <dest-address> subfield, even when the MBMS download session employs only a single LCT (multicast) channel.

7.3.2.2 Number of channels

Only one FLUTE channel is allowed per FLUTE session in the present document and thus there is no further need for a descriptor of the number of channels.

7.3.2.3 Destination IP address and port number for channels

The FLUTE channel shall be described by the media-level channel descriptor. These channel parameters shall be per channel:

– IP destination address.

– Destination port number.

The IP destination address shall be defined according to the "connection data" field ("c=") of SDP ( [14]). The destination port number shall be defined according to the <port> sub-field of the media announcement field ("m=") of SDP ( [14]).

The presence of a FLUTE session on a certain channel shall be indicated by using the "m-line" in the SDP description as shown in the following example:

– m=application 12345 FLUTE/UDP 0

– c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1

In the above SDP attributes, the m-line indicates the media used and the c-line indicates the corresponding channel. Thus, in the above example, the m-line indicates that the media is transported on a channel that uses FLUTE over UDP. Further, the c-line indicates the channel address, which, in this case, is an IPv6 address.

7.3.2.4 Transport Session Identifier (TSI) of the session

The combination of the TSI and the IP source address identifies the FLUTE session. Each TSI shall uniquely identify a FLUTE session for a given IP source address during the time that the session is active, and also for a large time before and after the active session time (this is also an LCT requirement – RFC 3451 [11]).

The TSI shall be defined according the SDP descriptor given below. There shall be exactly one occurrence of this descriptor in a complete FLUTE SDP session description and it shall appear at session level.

The syntax in ABNF is given below:

– flute-tsi-line = "a=flute-tsi:" tsi CRLF

– tsi = 1*15DIGIT

7.3.2.5 Multiple objects transport indication

RFC 3626 [9] requires the use of the Transport Object Identifier (TOI) header field (with one exception for packets with no payload when the A flag is used). The transport of a single FLUTE file requires that multiple TOIs are used (TOI 0 for FDT Instances). Thus, there is no further need to indicate to receivers that the session carries packets for more than one object and no SDP attribute (or other FLUTE out of band information) is needed for this.

7.3.2.6 Session Timing Parameters

A MBMS download session start and end times shall be defined according to the SDP timing field ("t=") ( [14]).

7.3.2.7 Mode of MBMS bearer per media

A new MBMS bearer mode declaration attribute is defined which results in, e.g.:

– a=mbms-mode:broadcast 123869108302929 1

– OR

– a=mbms-mode:broadcast-mbsfn 123869108302929

The MBMS bearer mode declaration attribute shall be used in session descriptions using one or more MBMS broadcast mode media or broadcast-mbsfn mode media. If all media declarations use MBMS broadcast mode or broadcast-mbsfn mode, then the SDP attribute may be declared at session level. In that case the session level attribute applies to all media without a media level occurrence of the "mbms-mode" attribute. If one or more media using MBMS multicast mode is present in the same declaration as media using MBMS broadcast mode, then only media using the MBMS broadcast mode or broadcast-mbsfn mode will contain the "mbms-mode" attribute.

– mbms-bearer-mode-declaration-line = "a=mbms-mode:" ("broadcast" SP tmgi SP mbms-counting-information) / ("broadcast-mbsfn" SP tmgi) CRLF

– tmgi = 1*15DIGIT

– mbms-counting-information = 1 * DIGIT

Note: Please find below an example of the building of the TMGI:

UK MCC = 234 (MCC Digit 1 = 2; MCC Digit 2 = 3 and MCC Digit 3 = 4)

Vodafone UK MNC = 15

Therefore, with padding, Vodafone UK MNC = 15F (MNC Digit 1 = 1; MNC Digit 2 = 5 and MNC Digit 3 = F)

MBMS Service ID = 70A886

Therefore, TMGI = 70A886 32F451 (Hex)

Therefore, TMGI = 123869108302929 (Decimal)

The Temporary Mobile Group Identity (tmgi) information element is defined in TS 24.008 [40] including the coding of the fields. Octets 3 to 8 (MBMS Service ID, MCC and MNC) shall be placed in the tmgi attribute of the MBMS bearer mode declaration line, and are encoded as a decimal number. Octet 3 is the most significant octet. As this is encoded as a decimal number, leading zeros of the MBMS Service ID field may be omitted.

The MBMS Counting Information (mbms-counting-information) information element is defined in TS 25.413 [87] and indicates whether the RAN level counting procedures are applicable or not for the MBMS broadcast mode. The value 0 corresponds to the information element value of "not counting" and the value 1 corresponds to the information element value "counting".

If the MBMS bearer mode declaration attribute is applied at the session level, there shall be exacly one instance of MBMS bearer mode declaration attribute in the Session Description.

7.3.2.8 FEC capabilities and related parameters

A new FEC-declaration attribute is defined which results in, e.g.:

– a=FEC-declaration:0 encoding-id=1

This attribute may be used on both session-level and media-level. Multiple instances are allowed to specify several different FEC declarations. The attribute is used on session level to define FEC declarations used by multiple media components. On media level it is used to define FEC declarations which are only valid for a single media component. If FEC declarations on both session and media level use the same reference number (fec-ref) then the media level declaration takes precedence for that media component. Each media component references one FEC declaration using the "a=FEC" attribute.

This attribute is optional to use for the download delivery method as the information will be available elsewhere (e.g. FLUTE FDT Instances). If this attribute is not used, and no other FEC-OTI information is signalled to the UE by other means, the UE may assume that support for FEC id 0 is sufficient capability to enter the session.

A new FEC-declaration reference attribute is defined which results in, e.g.:

– a=FEC:0

This is a media-level only attribute, used as a short hand to reference one of one or more FEC-declarations.

The syntax for the attributes in ABNF [23] is:

– fec-declaration-line = "a=FEC-declaration:" fec-ref SP fec-enc-id [";" SP fec-inst-id] CRLF

– fec-ref = 1*3DIGIT ; value is the SDP-internal identifier for FEC-declaration.

– fec-enc-id = "encoding-id=" enc-id

– enc-id = 1*DIGIT ; value is the FEC encoding ID used

– fec-inst-id = "instance-id=" inst-id

– inst-id = 1*DIGIT ; value is the FEC Instance ID used.

– fec-line = "a=FEC:" fec-ref CRLF

7.3.2.9 Service-language(s) per media

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken from [73] which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3166 [75] (e.g. "a=lang:EN-US"). These are the same tags used in the User Service Description XML.

7.3.2.10 Bandwidth Specification

The maximum bit-rate required by this FLUTE session shall be specified using the "AS" bandwidth modifier [14] on media level. The Application Specific (AS) bandwidth for a FLUTE session shall be the largest sum of the sizes of all packets transmitted during any one second long period of the session, expressed as kilobits. The size of the packet shall be the complete packet, i.e. IP, UDP and FLUTE headers, and the data payload.

7.3.2.11 FEC Redundancy Level

The "FEC-redundancy-level" declaration attribute is defined in the form:

– a=FEC-redundancy-level:<fec-ref> <fec-redun-lev>,

This attribute is associated with the FEC-declaration attribute defined in sub-clause 7.3.2.8, with the same <fec-ref> field value. It may be used at the session or media level, and declares the redundant level of FEC protection, as a percentage, applied to the media component(s) carried on the associated MBMS download session. For example, a FEC redundancy level of 40% means that for an FEC-encoded block of K symbols, 1.4*K symbols are broadcast over the air. The applicability of the FEC redundancy level parameter, at the session or media level, mirrors the session- or media-level use of the corresponding FEC-declaration attribute with the same <fec-ref> value. The FEC-redundancy-level attribute is optional to use as a FEC declaration.

The syntax for this attribute, in ABNF [23], is as follows:

– <fec-ref> is as defined in sub-clause 7.3.2.8,

– <fec-redun-lev> = "redundancy level=" <redun-lev>, and

– <redun-lev> = 1*3DIGIT; represents the redundant amount of FEC protection applied to the file object, expressed as an integer percentage value.

In the event that both the FDT extension attribute "FEC-Redundancy-Level" as defined in sub-clause 7.2.10.6, and the SDP FEC redundancy level indication are present, the declaration in the FDT shall take precedence from the UE processing perspective.

7.3.2.12 Alternative TMGI

An alternative tmgi declaration attribute is defined at the session level with the following ABNF [23] syntax:

– "a=alternative-tmgi:" tmgi-list CRLF

– tmgi-list = tmgi *("," tmgi)

– tmgi = 1*15DIGIT

The content(s) of an MBMS User Service may be delivered simultaneously in multiple PLMN areas, over different MBMS bearer service instances (each identified by a unique TMGI). In this case, the alternative-tmgi attribute shall be present at the session level and lists all alternative values to the TMGI contained in the session-level MBMS bearer mode declaration attribute, used for the broadcast of the FLUTE session data.

When this attribute is present, the UE shall determine that the service is available at its current location, upon detecting a match between the TMGI derived from the PLMN-ID representing its current location, with one of the TMGIs from the following list:

– The set of TMGI values comprising the default TMGI in the MBMS bearer mode declaration attribute and

– the TMGIs contained in the alternative-tmgi attribute.

Absence of a match shall be an indication to the UE that the service not available at its current location.

The alternative tmgi declaration attribute is optional. It is not a replacement for the MBMS mode declaration attribute as defined in clause 7.3.2.7. In addition to the MBMS mode declaration attribute (which is the default TMGI), at most a single instance of the alternative tmgi declaration attribute shall be present in the Session Description. The same definition of the Temporary Mobile Group Identity (tmgi) as used in clause 7.3.2.7 shall be applied.

7.3.2.13 Transport protocol identification

For the MBMS download delivery method, the <proto> field of the media descriptions ("m=") line of the SDP shall be set to ‘FLUTE/UDP’.

7.3.2.14 Media type and fmt-list

For the MBMS download delivery method, the media type and format list information shall be set in the "m=" line of the SDP as follows. The <media> field shall be set to ‘application’ and the <fmt> field shall be set to ‘0’.

7.3.3 SDP Examples for FLUTE Session

Here is a full example of SDP description describing a FLUTE session:

v=0

o=user123 2890844526 2890842807 IN IP6 2201:056D::112E:144A:1E24

s=File delivery session example

i=More information

t=2873397496 2873404696

a=mbms-mode:broadcast 123869108302929 1

a=FEC-declaration:0 encoding-id=1

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

a=flute-tsi:3

m=application 12345 FLUTE/UDP 0

c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1

b=64

a=lang:EN

a=FEC:0

Below is a second example of an SDP description describing a FLUTE session and which indicates that 25% redundant FEC protection is applied to the FEC encoding of the video Segments of the associated DASH-formatted content:

v=0

o=user123 2890844526 2890842807 IN IP6 2201:056D::112E:144A:1E24

s=Download session carrying 2-hour DASH-encoded program

i=More information

t=3615124600 3615131800

a=mbms-mode:broadcast 123869108302929 1

a=FEC-declaration:0 encoding-id=1

a=FEC-redundancy-level:0 redundancy-level=25

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

a=flute-tsi:5

m=video 10111 FLUTE/UDP 0

c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1

b=512

a=lang:EN

Below is a third example of an SDP description describing a FLUTE session with three TMGIs: one associated with the MBMS bearer mode declaration attribute, and two others that are carried in the "alternative-tmgi" attribute:

v=0

o=user123 2890844526 2890842807 IN IP6 2201:056D::112E:144A:1E24

s=Download session carrying 2-hour DASH-encoded program

i=More information

t=3615124600 3615131800

a=mbms-mode:broadcast-mbsfn 123869108302929

a=FEC-declaration:0 encoding-id=1

a=FEC-redundancy-level:0 redundancy-level=25

a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9

a=flute-tsi:5

a=alternative-tmgi:123869108302899,123869108302915

m=video 10111 FLUTE/UDP 0

c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1

b=512

a=lang:EN

7.4 OMA Push usage for MBMS Download

7.4.1 Introduction

OMA Push may be used for MBMS download reception when MBMS Bearers are not available. The MBMS UE registers its MSISDN with the BM-SC to receive the Download Sessions using OMA Push. The BM-SC distributes FLUTE FDT instance which allows the MBMS UE to fetch files of interest.

If the MBMS UE is out of its home network and if at least one unicastAccessURI element is available in the deliver method description, the MBMS UE should register its MBMS Download Services with the BM-SC.

7.4.2 HTTP registration and deregistration procedure

The MBMS UE may register and deregister for unicast service delivery, if the MBMS User Service Description for this service includes at least one unicastAccessURI element in the deliveryMethod element.

The HTTP (RFC 2616 [18]) GET method is used for this purpose. If more than one unicastAccessURI is provided in the deliveryMethod element, the UE shall randomly select one.

In the following, we give the details of the syntax used for the above request method in ABNF [23].

– unicast_access_request_http_URL = unicast_access_URI "?" query

– unicast_access_URI = <unicastAccessURI from the User Service Description; URI-reference is as defined in [19].>

– query = action "&" serviceId "&" msisdn

– action = "action=" ("register" / "Register" / "deregister" / "Deregister")

– serviceId = "serviceId=" <value of the serviceId attribute of the User Service Description>

– msisdn = "msisdn=" 1*DIGIT <format as defined in [77]

The BM-SC responds with an "200 OK" status code in case of successful registration or deregistration. With the response to a successful registration request, an associated delivery procedure fragment as defined in clause 9.5 shall be delivered to the MBMS UE. The MBMS UE uses the File Repair procedure as described in the received associated delivery procedure description fragment. The file repair procedure is defined in clause 9.3. Note, the file repair procedure allows also to fetch complete files.

An HTTP GET request with "action" value set to "register" or "Register" shall be sent to register the MBMS UE for unicast file delivery service. The request shall also include the serviceId and the MSISDN of the MBMS UE. The format for the MSISDN is defined in [77]. The following is an exmaple for a registration request:

GET /unicasDelivery?action=Register&serviceId=urn:3gpp:0010120123hotdog&MSISDN=436642012345 HTTP/1.1

Host: bmsc.example.com

An HTTP GET request with "action" value set to "deregister" or "Deregister" shall be sent to deregister the MBMS UE from the unicast file delivery service. The request also includes the service ID and the MSISDN number of the MBMS UE as shown in the following example:

GET /unicasDelivery?action=Deregister&serviceId=urn:3gpp:0010120123hotdog&MSISDN=436642012345 HTTP/1.1

Host: bmsc.example.com

7.4.3 MBMS Download Delivery Method over OMA push bearers

MBMS Download over OMA Push bearers are formatted according to the OMA Push OTA specification [79].

OTA-WSP shall be used over unicast bearers. Application port addressing shall be used as specified in [79]. The application ID to be used is 0x9045 as allocated by OMNA [85].

OTA-HTTP may be used over the HTTP push bearer. Application port addressing shall be used as specified in [79]. The application ID to be used is 0x9045 as allocated by OMNA [85].

The Content-Encoding header shall be included if GZip is used.

The MBMS UE receives the FLUTE FDT instance and the Download Header instance via OMA Push OTA protocol [79]. Both documents are encapsulated in a multipart MIME document. Optionally an associated delivery description fragment as defined in clause 9.5 is part of the pushed document. The FLUTE FDT instance is identified by the MIME type "application/fdt+xml" and the associated delivery description fragment by the mimetype as defined in Annex C.7. The download header instance should use a default mime type "application/xml".

The XML schema for the download header fragment is defined below. The serviceId element contains the unique identifier of the MBMS service. The MBMS UE uses the Service Id to select the target application and has received the serviceId with the User Service Annoucement fragment. The format of the serviceId element is defined in clasue 11.2.1.1.

The fdtInstanceId element shall contain the FDT instance Identifier for the sent FDT instance. Note, the FDT instance id is transferred using the FDT Instance Header as defined in clause 3.4.1 of [9]

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns="urn:3GPP:metadata:2007:MBMS:downloadHeader"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:3GPP:metadata:2007:MBMS:downloadHeader"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<xs:element name="mbmsDownloadHeader">
<xs:complexType>
<xs:sequence>
<xs:element name="serviceId" type="xs:anyURI"/>
<xs:element name="fdtInstanceId" type="xs:unsignedInt"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

The UE will then have necessary information about all files in the FLUTE session including their fileURIs, content encodings, content lengths etc.

7.5 FLUTE session setup and control with RTSP

7.5.1 Introduction

In case the MBMS User Service contains MBMS streaming and MBMS download sessions, it may be beneficial to control all flows with RTSP. The prime use case of FLUTE session set-up and control with RTSP is for sending MBMS streaming associated presentation data.

7.5.2 SDP handling

The FLUTE specific SDP extensions are defined in clause 7. For the FLUTE session establishment using RTSP, a control URI as defined in [88] shall be present for the FLUTE media description. Note, a control URI is defined by the "a=control:" SDP field according to [88].

7.5.3 RTSP SETUP Method

The control URI as defined in [88] shall be present for each FLUTE media description in the SDP. The control URI is used within the RTSP SETUP method to establish the described FLUTE sessions.

The RTSP transport protocol specifier for FLUTE as defined in [88] shall be "FLUTE/UDP". One and only one UDP port is allocated for each FLUTE channel.

The following RTP specific parameters shall be used in the transport request and responds header for FLUTE sessions:

– client_port: This parameter provides the unicast FLUTE port(s) on which the client has chosen to receive FLUTE data.

– server_port: This parameter provides the unicast FLUTE port(s) on which the server has chosen to send data.

7.5.4 RTSP PLAY Method

The PLAY method tells the server to start sending data including FLUTE session data as defined in [88]. The RTSP server forwards the FLUTE packets as according by the RTSP range header in the RTSP PLAY.

Only ntp and clock range units may be used with the "Range" headers. Normal Play Time (NPT) indicates the stream absolute position relative to the beginning of the presentation. The NPT consists of a decimal fraction. The clock range header describe the absolute time expressed as ISO 8601 timestamps, using UTC (GMT).

7.5.5 RTSP PAUSE Method

The PAUSE request causes the stream delivery including all FLUTE sessions to be interrupted (halted) as defined in [88].

7.5.6 RTSP TEARDOWN Method

The TEARDOWN client to server request stops the stream delivery including all FLUTE data delivery for the given URI, freeing the resources associated with it. Details for the TEARDOWN method are defined in [88].

7.6 Hybrid Service Offerings for DASH-over-MBMS User Service and Generic Application Service

7.6.1 Introduction

As conveyed by the application service document (e.g. a unified MPD in case of DASH), an Application Service belonging to a MBMS User Service and carried by the MBMS download delivery method may be made available such that the resources are partly available on broadcast and are partly available in unicast.

This clause uses the generic term "resources". However, in case of DASH-over-MBMS, the term "resources" is expected to refer to Segments associated to Representations.

Two main use cases are considered in this context:

1) unicast fallback reception should the UE move outside the MBMS coverage area of the corresponding User Service. Subsequently, should the UE move back into MBMS coverage, it may be required by network operator policy that only broadcast reception of the Service is permitted (network policy and the means for its delivery and execution is outside the scope of this specification). It may also be desired by the MBMS service provider that reception of individual broadcast resources are restricted by MBMS service areas.

2) unicast-supplemented service offerings, for which certain resources are only available on unicast and these resources provide an additional user experience and therefore should be accessible by the application, regardless whether the MBMS client is in the coverage for broadcast reception or not.

In this specification, the MBMS User Service Bundle Description fragment is extended to support these capabilities. The extensions comprise two parts:

1) Parameters are added to the deliveryMethod child element of the userServiceDescription element, which identify whether content requested by the client application of the MBMS client, e.g., a DASH client, is carried over unicast or broadcast transport (or both), and if the information is redundant or supplementary to the user experience. In addition, for application service content delivered via broadcast, the MBMS service areas in which it is restricted for reception can be specified.

2) A new child element is added to the userServiceDescription element for providing the identities of identical and alternative versions of an application service content item which can be substituted for one another, in accordance to coverage conditions (i.e., inside or outside of MBMS coverage), or policy requirements (e.g., "only broadcast reception of content is allowed when the UE is within MBMS coverage"). In addition, a reference is provided to an Application Service Description document, that describes both broadcast and unicast resources, to enable the MBMS client to acquire this metadata fragment and subsequently passing it to the corresponding application. In the case that the application service is DASH content delivered over MBMS, the unified MPD is passed to the DASH client. For details on a proper communication between the DASH client and the MBMS client, refer to TS26.347 [136], clause 7.

Note: For DASH-over-MBMS, the MPD can contain resources (not only Segments of Representations) for which the availability on unicast is not signalled in the userServiceDescription element. In this case the service provider need to be aware that the MBMS client does not have any control over requests associated to these resources and this can for example result in unwanted unicast traffic even if the UE is the coverage for broadcast reception.

7.6.2 Extension of the deliveryMethod element

7.6.2.1 Broadcast Resource Specific Metadata

As a child element of deliveryMethod, each instance of r12:broadcastAppService denotes all resources that are available over broadcast, i.e. the resources are carried over the MBMS bearer. Each entry of basePattern under all r12:broadcastAppService element(s) is for use by the MBMS client to match against a portion of the entire resource URL used by the application to request files. A match implies that the corresponding requested resource is carried over an MBMS bearer. For example in DASH over MBMS, should the URL associated with a Segment request contain the BaseURL "http://example.com/per-3/rep-512", and the same BaseURL value were to appear in an instance of r12:broadcastAppService.basePattern, it means that the Representation with Representation@id = ‘512’ is available over broadcast. The basePattern value may, but is not required to, be identical to that of the Representation.BaseURL if present in the MPD.

In addition, each r12:broadcastAppService element may contain one or more serviceArea child elements which specify the service area(s) in which the associated broadcast resources (as identified by basePattern) is delivered/accessible. The semantics of serviceArea complies to the MBMS Service Area Identity as defined in [77], [104]. A given broadcast resource may be available in a set of service area(s) in common with, or different from, the service area(s) of any other broadcast resources. Absence of the serviceArea element implies that the availability of the broadcast resources is not restricted by service area. The serviceArea element(s) that may be present in one instance of r12:broadcastAppService element must be a subset of the MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId. When one or more serviceArea element(s) are included under one or more r12:broadcastAppService, the union of all the MBMS Service Area Identities identified by the serviceArea elements under all the r12:broadcastAppService must match the list of MBMS Service Area Identities included in the userServiceDescription.availabilityInfo.infoBinding.serviceArea elements for the same serviceId.

7.6.2.2 Redundant Unicast Resource Specific Metadata

The deliveryMethod element may also include one instance of the r12:unicastAppService element that denotes unicast resources that are redundant to resources available as broadcast resources. Similar to r12:broadcastAppService, each entry of basePattern element under the r12:unicastAppService element is for use by the MBMS client to match against a portion of the entire file URL used by the application to request files provided in the application service document. A match implies that the associated file is available over unicast delivery, but if broadcast resources are available to the application service, then these resources are of no additional benefit for the user experience. Typically, such resources are particularly relevant in case broadcast resources are not available and the MBMS client may provide these resources for unicast fallback and service continuity.

NOTE: In the absence of externally defined policies, the MBMS client can offer such resources to the application also in other circumstances. For example when the service is initially accessed, such resources may be offered to the application to support faster service access.

For example for DASH over MBMS, should the URL associated with a Segment request contain the BaseURL "http://example.com/per-3/rep-256", and the same BaseURL value were to appear in an instance of r12: unicastAppService.basePattern, it means that the Representation with Representation@id = ‘256’ is available over unicast. The basePattern value may, but is not required to, be identical to that of the Representation.BaseURL if present in the MPD.

7.6.2.2A Supplementary Unicast Resource Specific Metadata

The deliveryMethod element may also include one or more instances of the r15:supplementaryUnicastAppService element to denote one or more available unicast resources which are supplemental to resources provided on broadcast, i.e. they provide an additional user experience. Similar to r12:unicastAppService, each entry of the basePattern element child of the r15:supplementaryUnicastAppService element typically represents a media component delivered over unicast, but with the difference that the information is not redundant and therefore is expected to also be of benefit for the application service when in broadcast coverage.

7.6.2.3 Additional Points

A given resource may be delivered/available over one or both transport modes. The broadcast version might be deemed as preferable or even required for reception, for example, in accordance to service provider policy pertaining to location of the UE with respect to MBMS coverage. Based on user preference, and when the UE is in broadcast coverage, the UE may receive media resources delivered over broadcast, as well as additional resources delivered over unicast under r15:supplementaryUnicastAppService.

The presence of the r12:broadcastAppService and/or r12:unicastAppService element under deliveryMethod signifies that the parent MBMS User Service is an application service which contains resources delivered via broadcast and/or unicast modes. One or both of these child elements of deliveryMethod must be present when its parent userServiceDescription element contains the r12:appService element (see clause 7.6.3).

7.6.3 Extension of the userServiceDescription element

7.6.3.0 General

Presence of the r12:appService child element of userServiceDescription indicates that the associated MBMS User Service is an application service explicitly linked to the r12:broadcastAppService and r12:unicastAppService elements under deliveryMethod. The r12:appService element may contain either or both the child elements identicalContent and alternativeContent. r12:appService also has the attributes appServiceDescriptionURI and mimeType.

7.6.3.1 Identical Content

Each identicalContent element under userServiceDescription contains two or more interchangeable URLs, as indicated by the basePattern values, for the same resources. The implication is that the resource could be interchanged in accordance to coverage condition, policy requirements, etc.

7.6.3.2 Alternative Content

Each alternativeContent element under userServiceDescription contains two or more interchangeable URLs, as indicated by the basePattern values, corresponding to different resources available over broadcast and unicast transport but which could be substituted for one another in accordance to coverage condition, policy requirements, etc. In practical deployment of a DASH-over-MBMS service, eligibility for such switching may additionally require the following conditions to be met:

a) the employed media codecs and configuration information must be identical between the requested and substituted Representations,

b) the request does not contain a byte range, and

c) Segments of the alternative Representations must be time-aligned.

The UE may support the processing of the alternativeContent element.

identicalContent and/or alternativeContent may be present under the r12:appService element because Representations listed in the MPD may be encoded differently, or associated with different configurations for a given encoding scheme, as defined by their Initialization Segments (represented by Initialization Segment Description fragments). Therefore, the mere presence of basePattern entries under r12:broadcastAppService and r12:unicastAppService does not imply that the associated Representations are automatically eligible for interchange between broadcast and unicast reception.

The alternativeContent element shall not be present if the application service is not DASH-over-MBMS.

7.6.3.3 Reference to Unified MPD and other Application Service Documents

The attribute appServiceDescriptionURI of r12:appService references an Application Service Deescription which may be a Media Presentation Description fragment corresponding to a unified MPD. In this case, the attribute mimeType of r12:appService specifies the MIME type of the MPD, which may include the optional ‘profiles’ parameter. The latter parameter declares the interoperability and signals the use of features associated with the DASH Media Presentation described by this MPD. An example value of mimeType is the string "application/dash+xml;profiles=urn:3GPP:PSS:profile:DASH10", which denotes an MPD conforming to the 3GP-DASH Release-10 profile.

Other types of Application Service Description fragments may be supported.

A UE compliant with this specification shall ignore the r12:appService element whose mimeType attribute value is not supported by the UE.

7.7 Keep-Updated Service

7.7.1 Registration Procedure

The MBMS UE may register and deregister for the keep-updated service, if the MBMS User Service Description for this eMBMS service includes one KeepUpdatedService element.

The HTTP (RFC 2616 [18]) POST method is used for this purpose. A keep-updated registration XML fragment is sent to the BM-SC as the body of the POST request. The keep-updated XML fragment shall conform to the following XML schema.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="KeepUpdated" type="KeepUpdatedType"/> <xs:complexType name="KeepUpdatedType"> <xs:sequence> <xs:element name="fileURL" type="xs:anyURI" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="request" type="RequestType" use="optional" default="Register"/> <xs:attribute name="MSISDN" type="xs:string" use="optional"/> </xs:complexType> <xs:simpleType name="RequestType"> <xs:restriction base="xs:string"> <xs:enumeration value="Register"/> <xs:enumeration value="Deregister"/> </xs:restriction> </xs:simpleType> </xs:schema>

The keep-updated XML fragment shall have the following MIME type: "application/vnd.3gpp.keep-updated+xml".

An MBMS UE shall de-register when it no longer requires to receive the service. The HTTP POST method is used for de-registration. The set of files that the receiver wishes to de-register may be provided in the de-registration message as the body of the HTTP request. The MBMS UE may de-register all files that it has earlier registered for by sending an empty list.

As part of the request for registration or de-registration, the MBMS UE shall provide its MSISDN number, that may be used by the BM-SC to identify the client.

The BM-SC shall respond with an "200 OK" status code in case of a successful registration or deregistration. The body of the reply shall contain the keep-updated XML fragment that contains all files for which the BM-SC is willing to provide update notifications.

In case the BM-SC is not able to provide the service or if the request fails for any other reason, the BM-SC server shall reply with an HTTP 4xx or a 5xx error code.

7.7.2 Client Notification about Updates

When the BM-SC detects an update on a file or set of files that at least one user has registered for, it shall determine if delivery over MBMS is beneficial or not. The BM-SC should inform all MBMS UEs that have registered for that particular file about the existing file update(s).

The BM-SC informs the UEs about the forthcoming delivery of the file updates using eMBMS by sending an update of the Schedule Description metadata fragment of the keep-updated service USD using the MBMS service announcement procedures over unicast as defined in 5.2.5. For updated files that the BM-SC does not intend to broadcast, the file should be marked as unicast only using the r12:unicastOnly attribute in the Schedule Description metadata fragment. The file shall then be accessible using the same URI as provided by the fileURI element.

7.8 Location-specific deliveryMethod

An MBMS User Service may be distributed using different delivery methods (i.e., multiple instances of the deliveryMethod child element of the userServiceDescription element), each of which is available only in certain areas. These delivery methods may be carrying exactly the same content but over different MBMS bearers (e.g. over different PLMNs).

For the case that the FLUTE session parameters are exactly the same but are distributed over different MBMS bearers with different TMGIs, the alternative-tmgi attribute as defined in clause 7.3.2.12 shall be used.

For the case that the FLUTE session parameters are different (e.g. different destination IP address, port number, or TSI), the userServiceDescription element shall signal one of the following options:

– One or more deliveryMethod elements each of which declares the geographical area where the deliveryMethod instance is applicable, and an indication that this deliveryMethod belongs to a group of alternative deliveryMethod elements. The UE shall only use the deliveryMethod whose applicable area matches the current UE location

– Deliver the session description file (SDP) over unicast, where the UE will receive the SDP file applicable to the UE’s location

7.9 Partial File handling

7.9.1 General

Files may be lost entirely or partially during the transmission and the MBMS Client may not be able to recover the lost files. This clause provides recommended procedures for handling partial files in the MBMS client.

A partial file is defined as follows:

– an FDT Instance is received that contains a File entry with a specific TOI.

– the object associated to the TOI was not recovered by any recovery procedure (FEC, file repair, etc.). The MBMS client determines that a file will not be recovered. A file is not recovered if the starting time of the ADPD as defined in 9.3.2 is reached for that file and if present, the file repair for that file has not succeeded,

The partial file is the collection of all FDT Instance data that is assigned to the file, i.e.

– Content-Location (URI of a file).

– Content-Length (source file length in bytes)

– Content-Type (content MIME type)

as well as all received bytes including their position in the original file. In addition, the mbms2015:IndependentUnitPositions attribute may be present.

If the application supports the handling of partial files, then the MBMS client should provide the partial file to the application including the position of all received bytes. The partial file handling capability information from the application to the MBMS client as well as the handing of the partial file data is generally out of scope of this specification.

However, if the application communicates with the MBMS client using HTTP methods then

– – the MBMS client may signal the availability of a partial file to a request according to the Response format as defined in clause 7.9.2.2.

– The application may signal the capability to handle partial files for using a partial-file-accept request as defined in clause 7.9.2.1. If a partial-file-accept request is sent,

– the MBMS client should respond. If it responds it shall use the HTTP Response format as defined in clause 7.9.2.2 and shall include all received bytes in the response.

– Appropriate examples in the context of DASH over MBMS is provided in clause 7.9.2.3.

Independent units are defined in clause 7.9.3. The MBMS client may also support handling of independent units. If an MBMS client supports handling of independent units, it shall also support partial file handling.

7.9.2 Partial File Handling with HTTP GET Method

7.9.2.1 Partial-File-Accept Request

An application using HTTP GET requests to retrieve files may include in the GET request, the ‘Accept’ request header as defined in RFC 7231 [4], along with a new 3GPP-defined media type ‘application/3gpp-partial’.

By providing this header and issueing such a partial-file-accept request, the application signals that is capable to receive partial file responses as defined in clause 7.9.2.2.

An example of the use of such Accept header is:

Accept: */*, application/3gpp-partial

In this example, the application indicates that it will accept all media types in the response, as well as the specific "incomplete" type designated by application/3gpp-partial.

7.9.2.2 HTTP Response Format for Partial Files

If the MBMS client receives a regular HTTP GET request that includes the ‘Accept’ header but which does not contain media type ‘application/3gpp-partial’, and the MBMS client has received a partial file with at least one byte, it should respond with HTTP/1.1 404 Not Found, and include in the response the ‘Content-Type’ header set to ‘application/3gpp-partial’.

– The response code shall be set to 200 OK

– The Content-Type header shall be set to application/3gpp-partial.

– The message body is a multipart message body shall be exactly the same format as the multipart/byteranges media type as described in RFC 7233 [5], Annex A. The multipart/byteranges media type includes one or more body parts, each with its own Content-Type and Content-Range fields as the means to convey the byte range(s) of the partial file being returned. Each Content-Type header shall be set to the value of the Content-Type provided in the FDT Instance for this file. An extension header may be added 3gpp-access-position providing a byte position at which the handler of assigned to the Content-Type of the file may access the file. The value may be created from the mbms2015: IndependentUnitPositions, if present.

– A cache directive should be included in the response to prevent any intermediate proxies from storing an incomplete file and serving it to another application. Example for such cache directive are "Cache-Control: max-age=0" or "Cache-Control: no-cache"

If the MBMS client receives a partial-file-accept request, and the MBMS client has received a partial file with no bytes (i.e. only the FDT Instance describing the file metadata is received), then the MBMS client may respond with a partial file response defined as follows:

– The response code shall be set to 416 Requested Range Not Satisfiable

– The Content-Type header shall be set to the value of the Content-Type provided in the FDT Instance for this file.

– The Content-Range shall be set to bytes */Content-Length with Content-Length the value of the attribute Content-Length provided in the FDT Instance for this file.

7.9.2.3 Example Client and Server Implementation for DASH-over-MBMS

As an example, assume the Media Segment of interest is identified by the URL: "http://www.example.com/Period-2012-08-04T08-45-00/rep-xyz12345/seg-777.3gp". In addition, the Client is willing to receive the incomplete portion of the Segment (777) available at the Server when the request is received. The DASH Client sends the partial-accept request as follows:

GET /Period-2015-08-04T08-45-00/rep-xyz12345/seg-777.3gp HTTP/1.1

Host: www.example.com

…

Accept: */*, application/3gpp-partial

Assume that the server receives the above GET request for Segment 777, and it has the following sets of byte ranges of the requested Segment of size 256000 bytes at the time it receives the request: 0-19999, 50000-85000, 105500-199888, and 201515-229566. Due to the presence of the specific Accept header in the request, the server will return the partial Segment via the 200 response, by indicating the same content type for the message body as indicated in the request (i.e., application/3gpp-partial), but whereby the message body is constructed identically to the multipart/byteranges format. In addition, the response header Cache-Control: no-cache may be included in the response to prevent downstream caching of the message. The server’s response in this case is shown below:

HTTP/1.1 200 OK

Date: Tue, 04 Aug 2015 08:45:05 GMT

…

Content-Length: 172441

Content-Type: application/3gpp-partial; boundary=SEPARATION_STRING

Cache-Control: no-cache

–SEPARATION_STRING

Content-Type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-Range: bytes 0-19999

…<the first range>…

— SEPARATION_STRING

Content-type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-range: bytes 50000-79999

…<the second range>…

— SEPARATION_STRING

Content-type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-range: bytes 105500-199888

…<the third range>…

— SEPARATION_STRING

Content-type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-range: bytes 201515-229566

…<the fourth range>…

— SEPARATION_STRING

As an extension to the example, assume that the first byte range is lost as well and FDT Instance contains an mbms2015:IndependentUnitPositions attribute with value "0 60000 80000 110000":

The server’s response in this case is shown below:

HTTP/1.1 200 OK

Date: Tue, 04 Aug 2015 08:45:05 GMT

…

Content-Length: 172441

Content-Type: application/3gpp-partial; boundary=SEPARATION_STRING

Cache-Control: no-cache

— SEPARATION_STRING

Content-type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-range: bytes 55000-79999

3gpp-access-position: 60000

…<the second range>…

— SEPARATION_STRING

Content-type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-range: bytes 105500-199888

3gpp-access-position: 110000

…<the third range>…

— SEPARATION_STRING

Content-type: video.3gpp; codecs=avc1.64001E, mp4a.40.2

Content-range: bytes 201515-229566

…<the fourth range>…

— SEPARATION_STRING

7.9.3 Signaling Independent Units

7.9.3.1 Introduction

Independent Units may be signalled in the File entry of an FDT Instance using the attribute mbms2015: IndependentUnitPositions. The FDT Instance signaling is defined in clause 7.9.3.2.

MBMS clients that support partial file handling may also support the handling of independent units. The details of handling independent units are provided in clause 7.9.2.

7.9.3.2 FDT Instance Signaling

Independent units represent a non-empty list of byte locations, each of which is the location of the first byte of an independent unit.

An independent unit is the chunk of bytes between 2 consecutive entries in the IndependentUnitPositions list, except for the last independent unit which ranges from the last entry in the list to the end of the file.

The position of an independent Unit is the byte position in the file, at which the handler assigned to the Content-Type for the file may access the file.

If independent units are signaled in the FDT Instance, the following restrictrions apply:

– The attribute mbms2015: IndependentUnitPositions shall not be used in combination with the use of the Content-Encoding.

– The generation of the IndependentUnitPositions values is out of the scope this specification.

7.10 File Delivery Manifest

The File Delivery Manifest that is used within the xMB interface is defined in the xMB reference point specification TS 26.348 [143].