Content for TS 26.346 Word version: 19.1.0

0… 4… 5… 5.3… 6 7… 7.3… 8… 8A… 8B… 9… 9.4… 10… 11… 12… A B… C… D… G… H… J… K… L… M…

7 Download Delivery Method p. 51

7.1 Introduction p. 51

MBMS download delivery method uses the FLUTE protocol (RFC 3926) 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). ALC combines the Layered Coding Transport (LCT) building block (RFC 3451), a congestion control building block and the Forward Error Correction (FEC) building block (RFC 5052) 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), 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.

Copy of original 3GPP image for 3GPP TS 26.346, Fig. 10: Building block structure of FLUTE

Figure 10: Building block structure of FLUTE
(⇒ copy of original 3GPP image)

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.

7.2 FLUTE usage for MBMS download p. 51

7.2.0 General |R12| p. 51

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 clause 7.7.

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

MBMS Clients and servers supporting MBMS download shall implement the FLUTE specification (RFC 3926), as well as ALC (RFC 3450) and LCT (RFC 3451) 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 p. 52

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

The "Compact No-Code FEC scheme" per RFC 3695 (FEC Encoding ID 0, also known as "Null-FEC") shall be supported.

The Raptor FEC scheme is described in 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 RFC 5053 for reconstruction of a source block then the decoder shall recover the entire source block. Note that the example decoder described in Section 5.5 of RFC 5053 fulfils this requirement.

7.2.3 Blocking algorithm p. 52

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

In the case of Raptor forward error correction, then the algorithm defined in RFC 5053 shall be used.

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

7.2.4 Congestion control p. 52

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

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

7.2.6 Transport file grouping p. 53

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

FLUTE and ALC mandatory header fields shall be as specified in RFC 3926 and RFC 3450 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", the FEC Payload ID shall be set according to RFC 3695 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 (RFC 5651), 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 RFC 5651.

7.2.8 Signalling of parameters with FLUTE extension headers p. 53

The FLUTE sender shall use FLUTE extension header fields EXT_FDT, EXT_FTI, EXT_CENC (RFC 3926) 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 RFC 3926 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.

7.2.9 Signalling of parameters with FDT instances p. 54

The extended FLUTE FDT instance schema defined in clause 7.2.10.1 (based on the one in RFC 3926) 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.

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:

FEC-OTI-Maximum-Source-Block-Length. When the FEC Encoding ID indicates the "Compact No-Code FEC scheme", the value of this data element shall not exceed 65535, consistent with the 16-bit constraint on the Encoding Symbol ID specified in Section 3 of RFC 3695 and in Section 3.3 of RFC 3926.
FEC-OTI-Encoding-Symbol-Length.
FEC-OTI-Max-Number-of-Encoding-Symbols.
FEC-OTI-Scheme-Specific-Info.

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 entity tag as defined in RFC 9110 which may also serve as the version identifier of the file object described by the FDT Instance.

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 Base 64.

7.2.10 FDT schema p. 55

7.2.10.1 Extended FLUTE FDT syntax p. 55

The XML schema specified in Listing 7.2.10.1-1 below shall be use for the FDT Instance. The filename of this schema is "TS26346_FLUTE-FDT.xsd". This schema extends the baseline IETF schema reproduced in clause 7.2.10.3 by importing the 3GPP extensions specified in clauses 7.2.10.2 and J.2.

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

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

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;

Listing 7.2.10.1-1: Extended FLUTE FDT schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:IETF:metadata:2005:FLUTE:FDT" version="4"
 xmlns="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"
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>Extended MBMS FLUTE File Delivery Table schema</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.10.1</xs:documentation>
  <xs:documentation>Copyright © 2005,
   3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
   All rights reserved.</xs:documentation>
 </xs:annotation>
 <xs:import namespace="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"
  schemaLocation="TS26346_FLUTE-FDT_Extensions_Rel-6.xsd"/>
 <xs:import namespace="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"
  schemaLocation="TS26346_FLUTE-FDT_Extensions_Rel-7.xsd"/>
 <xs:import namespace="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"
  schemaLocation="TS26346_FLUTE-FDT_Extensions_Rel-8.xsd"/>
 <xs:import namespace="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"
  schemaLocation="TS26346_FLUTE-FDT_Extensions_Rel-9.xsd"/>
 <xs:import namespace="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"
  schemaLocation="TS26346_FLUTE-FDT_Extensions_Rel-11.xsd"/>
 <xs:import namespace="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"
  schemaLocation="TS26346_FLUTE-FDT_Extensions_Rel-13.xsd"/>
 <xs:import namespace="urn:3gpp:metadata:2009:MBMS:schemaVersion"
  schemaLocation="TS26346_SchemaVersion.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: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: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: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: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: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: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 FLUTE FDT schema extensions p. 57

The Release 6 extensions to the 3GPP FLUTE FDT schema are specified in Listing 7.2.10.2-1 below. The filename of this schema is "TS26346_FLUTE-FDT_Extensions_Rel-6.xsd".

Listing 7.2.10.2-1: 3GPP FLUTE FDT schema extensions (Release 6)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"xmlns="urn:3GPP:metadata:2005:MBMS:FLUTE:FDT"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>MBMS FLUTE FDT schema extensions (Release 6)</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.10.2</xs:documentation>
  <xs:documentation>Copyright © 2005, 3GPP Organizational Partners
  (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved.</xs:documentation>
 </xs:annotation>
 <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:simpleType>
</xs:schema>

The Release 7 extensions to the 3GPP FLUTE FDT schema are specified in Listing 7.2.10.2-2 below. The filename of this schema is "TS26346_FLUTE-FDT_Extensions_Rel-7.xsd".

Listing 7.2.10.2-2: 3GPP FLUTE FDT schema extensions (Release 7)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"
 xmlns="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>MBMS FLUTE FDT schema extensions (Release 7)</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.10.2</xs:documentation>
  <xs:documentation>Copyright © 2007, 3GPP Organizational Partners
  (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved.</xs:documentation>
 </xs:annotation>
 <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>

The Release 8 extensions to the 3GPP FLUTE FDT schema are specified in Listing 7.2.10.2-3 below. The filename of this schema is "TS26346_FLUTE-FDT_Extensions_Rel-8.xsd".

Listing 7.2.10.2-3: 3GPP FLUTE FDT schema extensions (Release 8)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"
 xmlns="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>MBMS FLUTE FDT schema extensions (Release 8)</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.14</xs:documentation>
  <xs:documentation>Copyright © 2008, 3GPP Organizational Partners
  (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved.</xs:documentation>
 </xs:annotation>
 <xs:attribute name="FullFDT" type="xs:boolean"/>
</xs:schema>

The Release 9 extensions to the 3GPP FLUTE FDT schema are specified in Listing 7.2.10.2-4 below. The filename of this XML schema is "TS26346_FLUTE-FDT_Extensions_Rel-9.xsd".

Listing 7.2.10.2-4: 3GPP FLUTE FDT schema extensions (Release 9)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"
 xmlns="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>MBMS FLUTE FDT schema extensions (Release 9)</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.15</xs:documentation>
  <xs:documentation>Copyright © 2009, 3GPP Organizational Partners
  (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved.</xs:documentation>
 </xs:annotation>
 <xs:attribute name="Decryption-KEY-URI" type="xs:anyURI"/>
</xs:schema>

The Release 11 extensions to the 3GPP FLUTE FDT schema are specified in Listing 7.2.10.2-5 below. The filename of this schema is "TS26346_FLUTE-FDT_Extensions_Rel-11.xsd".

Listing 7.2.10.2-5: 3GPP FLUTE FDT schema extensions (Release 11)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"
 xmlns="urn:3GPP:metadata:2012:MBMS:FLUTE:FDT"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>MBMS FLUTE FDT schema extensions (Release 11)</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.10.2</xs:documentation>
  <xs:documentation>Copyright © 2012, 3GPP Organizational Partners
  (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved.</xs:documentation>
 </xs:annotation>
 <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 extensions to the 3GPP FLUTE FDT schema are specified in Listing 7.2.10.2-6 below. The filename of this schema is "TS26346_FLUTE-FDT_Extensions_Rel-13.xsd".

Listing 7.2.10.2-6: 3GPP FLUTE FDT schema extensions (Release 13)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"
 xmlns="urn:3GPP:metadata:2015:MBMS:FLUTE:FDT"
 xmlns:xs="http://www.w3.org/2001/XMLSchema" 
 elementFormDefault="qualified">
 <xs:annotation>
  <xs:documentation>MBMS FLUTE FDT schema extensions (Release 13)</xs:documentation>
  <xs:documentation>3GPP TS 26.346 clause 7.2.10.2</xs:documentation>
  <xs:documentation>Copyright © 2015, 3GPP Organizational Partners
  (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved.</xs:documentation>
 </xs:annotation>
 <xs:attribute name="IndependentUnitPositions" type="IndependentUnitPositionsType"/>
 <xs:simpleType name="IndependentUnitPositionsType">
  <xs:list itemType="xs:unsignedLong"/>
 </xs:simpleType>
</xs:schema>

7.2.10.3 Baseline IETF FLUTE FDT schema (informative) p. 59

The baseline FDT XML schema specified by the IETF in RFC 3926 is reproduced in Listing 7.2.10.3-1 below. This schema is not included as an attachment to the present document.

Listing 7.2.10.3-1: Baseline IETF FLUTE FDT schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:IETF:metadata:2005:FLUTE:FDT"
 xmlns="urn:IETF:metadata:2005:FLUTE:FDT"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 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 3GPP FLUTE FDT p. 61

Listing 7.2.10.4-1: Example 3GPP FLUTE 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:r7="urn:3GPP:metadata:2007:MBMS:FLUTE:FDT"
 xmlns:r8="urn:3GPP:metadata:2008:MBMS:FLUTE:FDT_ext"
 xmlns:r9="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext"
 xmlns:sv="urn:3gpp:metadata:2009:MBMS:schemaVersion"
 xsi:schemaLocation="urn:IETF:metadata:2005:FLUTE:FDT TS26346_FLUTE-FDT.xsd"
 FEC-OTI-FEC-Encoding-ID="1"
 Complete="true"
 Content-Encoding="gzip"
 FEC-OTI-Encoding-Symbol-Length="512"
 Expires="331129600"
 r8:FullFDT="true">
 <File TOI="2"
  Content-Type="application/sdp"
  Content-Length="7543"
  Transfer-Length="4294"
  FEC-OTI-Encoding-Symbol-Length="16"
  FEC-OTI-Scheme-Specific-Info="AAEBBA=="
  Content-Location="http://www.example.com/fancy-session/main.sdp"
  r9:Decryption-KEY-URI="http://www.example.com/key-uri">
  <r7:Cache-Control>
   <r7:Expires>331129630</r7:Expires>
  </r7:Cache-Control>
  <sv:delimiter>0</sv:delimiter>
  <sv:delimiter>0</sv:delimiter>
  <MBMS-Session-Identity>93</MBMS-Session-Identity>
 </File>
 <File TOI="3"
  Content-Type="String"
  Content-Length="161934"
  Transfer-Length="157821"
  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>4</sv:schemaVersion>
 <sv:delimiter>0</sv:delimiter>
 <MBMS-Session-Identity-Expiry value="3311288760">93</MBMS-Session-Identity-Expiry>
</FDT-Instance>

7.2.10.5 Caching directives extension |R7| p. 61

See clause 7.2.13.

7.2.10.6 FEC redundancy level extension |R11| p. 61

See clause 7.2.16.

7.2.11 MBMS Session identity p. 61

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 an 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 conveys the 32-bit Era Offset value from the 128-bit NTP Date Format data type specified in Section 6 of RFC 5905. These 32 bits provide an unsigned integer representing the Network Time Protocol (NTP) time in seconds relative to the current NTP era signalled in the Era Number field of the NTP Date Format data type. For era 0, the base date is midnight UTC (0 hours) on 1 January 1900.

7.2.12 FEC Scheme definition p. 62

7.2.12.1 General p. 62

This clause defines an FEC encoding scheme for the MBMS forward error correction code defined in RFC 5053 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 Section 3.1 of RFC 5053 and Section 3.2 of RFC 5053, respectively.

7.2.13 Caching directives signalling |R19| p. 62

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 conveys the 32-bit Era Offset value from the 128-bit NTP Date Format data type specified in Section 6 of RFC 5905. These 32 bits provide an unsigned integer representing the Network Time Protocol (NTP) time in seconds relative to the current NTP era signalled in the Era Number field of the NTP Date Format data type. For era 0, the base date is midnight UTC (0 hours) on 1 January 1900.

The syntax of the caching directives is specified in Listing 7.2.10.2-2, and the "Cache-Control" element is further referred to by the main FDT schema of clause 7.2.10.1.

7.2.14 Indicating a full FDT snapshot |R8| p. 62

If the server wants to inform the MBMS 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 specified in Listing 7.2.10.2-3, and the attribute is further referred to by the main FDT schema of clause 7.2.10.1.

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 |R9| p. 63

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

When the BM-SC delivers a protected download file, it should populate the "Decryption-KEY-URI" attribute 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 present in the "File" element of the FDT instance.

The XML syntax of the "Decryption-KEY-URI" attribute within the FLUTE FDT is specified in Listing 7.2.10.2-4, and the attribute is further referred to by the main FDT schema of clause 7.2.10.1.

7.2.16 FEC redundancy level signalling |R17| p. 63

An MBMS download service may indicate FEC redundancy level for individual FLUTE Transport Objects in a FLUTE FDT Instance. The attribute "FEC-Redundancy-Level" is included within the "File" element of the FDT Instance 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 redundancy 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 Listing 7.2.10.2-5, and the attribute is further referred to by the main FDT schema of clause 7.2.10.1.