ESG/EPG (7) - Layer for ESG Transport

ESG Layer for ESG Transport

1). ESG Transport OV

§ Transport: Transported by FLUTE to enable the optimal delivery of containers as files.

§ Over the broadcast channel, the ESG data (e.g. ESG XML fragments, auxiliary data) is delivered using ESG containers, with the possible exception of SDP files that can alternatively be transported as separate files,

§ In both modes ESG Containers are transported in FLUTE dynamic file delivery carousel sessions as described for file delivery in TS 102 472.

§ To enable a terminal to track changes to fragments without having to acquire all the ESG Containers within an ESG session

§ A fragment indexing structure can be used to enable a terminal to track changes to fragments without having to acquire all the ESG containers within an ESG delivery session.

§ A partitioning strategy determines the set of data to be carried in each transport flow.

§ The ESG session partition declaration tells the terminal, how the ESG is partitioned, and what the partitioning criteria for each session are.

§ ESG Query Requests and ESG Query Responses shall be transmitted by HTTP over TCP/IP.

2). The transport of ESG Containers supports two modes:

§ the "single stream mode", where ESG containers are transported as Transport Objects (TO) in a single FLUTE session

§ the "multiple stream mode", where ESG containers are transported in multiple FLUTE sessions which are distributed over several transport flows.

3). single stream mode

§ In the single stream mode the ESG Containers are transported as transport objects in a single FLUTE session.

§ The FLUTE Session for the transport of ESG Container is based on the file delivery specified in TS 102 472 in the mode.

3.1). ESG container updates

§ Container_ID and Versioning information, conveyed by the transport layer are used to enable a terminal to track changes to ESG containers.

§ The default and mandatory way to announce new versions of a ESG container is to provide an FDT instance with a new FDT instance ID as specified in TS 102 471.

§ The new FDT instance declares a new mapping of the ESG container's "Content-Location" field to a new TOI value.

§ An optional way is to use the Split TOI mechanism.

§ It conveys the ESG containers version_ID as part of the ESG containers associated TOI value.

§ This allows the terminal to keep track of changes in ESG container versions directly at the transport level, without the indirection of the FDT.

3.2). Indexing and fragment updates

§ The fragment indexing structure can be used to enable a terminal to track changes to fragments without having to acquire all the ESG containers within an ESG session.

§ This structure comprises an index list, index and in the single-stream case, one sub index.

§ In the single-stream case, these structures are carried on the same transport flow as the ESG fragment containers.

§ By monitoring the fragment_id and fragment_version fields in the Multi-field sub-index, the terminal can detect fragment updates.

3.3). Strategy for grouping fragments into ESG containers

§ As soon as a fragment is updated within an ESG container, the ESG container version is updated.

§ In this case the terminal might need to reload the ESG container to get the updated fragment.

§ It is reasonable to consider that separating static fragments and dynamic fragments can potentially reduce the number of ESG container updates by grouping potential fragment updates in the same ESG container(s).

§ Thus this could reduce the number of ESG containers a terminal must acquire to get the updated fragments.

4). multiple stream mode

§ In the multiple stream case, the ESG data are split into a number of separate transport flows.

§ In the multiple stream mode the ESG Containers are transported in multiple FLUTE sessions which are distributed over several IP streams.

§ The mode used is signalled by the MultipleStreamTransport field in the ESGAccess Descriptor.

4.1). Indexing Structure:

§ The optional indexing structure is carried in the announcement carousel, intended to be repeated at a rate high enough to be carried in each DVB-H Burst carrying ESG data.

§ It is recommended that an FDT instance holds a "FullFDT" attribute set to "true" in the ESG Announcement FLUTE session.

§ If an index is present in the ESG Announcement FLUTE Session, the terminal can assume that the set of ESG fragments listed by the index carried in the ESG Announcement FLUTE session, is consistent.

§ The sessions that are declared in the ESG session partition declaration can be carouselled at rates which depend on how important the set of ESG data they carry may seem to a typical user, and on the number of users expected to make use of these data.

§ Index Structue http://docs.google.com/View?id=ddh56dhg_237zjmwf4jd

4.2). Indexing Overview:

§ To enable a terminal to track changes to fragments without having to acquire all the fragment containers within an ESG session, a fragment indexing structure has been specified.

§ This structure consists of index list, index and one or more optional sub indices. This indexing allows a terminal to monitor for changes to ESG Fragments from one structure.

§ When a fragment index is transmitted in an ESG multi stream mode, the index shall be carried on the Announcement Carousel of the ESG.

§ In the case of the ESG delivered as a single stream mode, the index shall be carried on the same IP Flow as that of the ESG fragments.

§ The presence of the fragment index is announced using the Index_list structure

4.3). ESG container updates

§ The same rules apply as for the single stream case

4.4). Indexing and fragment updates

§ Considering the multi-stream mode ESG delivery, this division point is based on the transport flow and each SubIndex will have all entries for one transport flow.

§ The declaration of only one sub index per transport flow helps the terminal to monitor updates in this transport flow.

§ Moreover, a given ESG container should not contain sub indexes representing different transport flows.

§ If there are several sub indexes representing the same transport flow, they should be placed into the same ESG container taking the ESG container size and the update frequency of sub indexes under account.

4.5). Strategy for grouping fragments into ESG containers

§ The same as for the single stream case

4.6). Partitioning

§ The ESG data are split into a number of separate transport flows.

§ A partitioning strategy is used to decide on the set of data to be carried in each transport flow.

§ The particular partitioning strategy used and the set of transport flows that form this partitioned ESG are signalled within an ESG session partition declaration which is carried in the announcement carousel.

4.7). ESG session partition declaration may be keyed on a number of fields including:

§ The number of hours measured from now for which the fragments are relevant. This may be used to split the ESG into various time intervals.

§ The "serviceID" attribute of the target Service fragments. This may be used to carry all fragments relevant to a particular service.

§ User-defined keys.

4.8). The Usage of ESG Session Partition strategy:

§ The number of hours for which the fragments are relevant.

§ Using this rule, the ESG can be delivered according to various time schedules.

§ The split such as 0 to 2 hours, 2 hours to 4 hours, 4 hours to 6 hours gives the terminal the opportunity of decoding the specific ESG part it wants.

§ Each rule can apply in duplicate manner. Thus, an ESG having a schedule with a 6 hours scope can be delivered as follows: 0 to 2 hours, 0 to 4 hours, 0 to 6 hours.

§ The URI declared in the serviceID attribute of the Service fragment. Using this rule, the ESG can be split based on serviceIDs.

5). Compression in ESG Containers at transport layer

§ In both modes the single stream mode and the multiple stream mode ESG Containers are transported as files in Transport Objects in FLUTE sessions.

§ The ESG Containers may be compressed with GZIP (RFC 1952).

§ To signal that the ESG Container is compressed with GZIP the Content-Encoding attribute in the FDT shall be set to "gzip".

§ In the context of textual representation, the gzip compression gives better results at transport (ESG container) level than at fragment level.

ESG/EPG (6) - Layer for ESG Encapsulation and Container

ESG Layer for Encapsulation and Container

1). ESG Fragment Encapsulation

§ Fragmentation is the generic decomposition mechanism of the ESG into self-consistent units of data.

§ Encapsulation: Encapsulated ESG XML fragments (ESG metadata) into ESG containers

§ In order to support efficient delivery and processing of individual fragments, ESG fragments are encapsulated into ESG containers before being transported over a FLUTE session.

In this context self-consistency capability of an ESG Fragment means that:

§ ESG Fragments can be obtained in a random order.

§ Each ESG Fragment can be transmitted and updated independently.

2). Different types of fragments may exist:

§ ESG XML fragments.

§ ESG Auxiliary data.

§ Private Auxiliary data.

3). Encapsulation of ESG Fragments serves three purposes:

§ Aggregation: To reduce the overhead of fragment management information and to support the processing and transmission of ESG information of considerable size, ESG Fragments are aggregated into ESG Containers.

§ Fragment Management: To enable the management of fragment creation, deletion and updates over time the fragment management information is signalled for each fragment. This allows a terminal to identify new versions of a fragment without actually reading and comparing the content of the fragments.

§ Processing Support: To support a fast processing of ESG Fragments on the terminal redundant data is added into the ESG Container to support the fast random access to the content of ESG Fragments.

4). ESG Fragment Encapsulation is divided into these three parts:

§ ESG Containers - are transport objects delivered by the transport layer. They aggregate ESG Fragments to enable the efficient transport and processing of ESG data. Beside the specification of the syntax and the semantics of the data fields of an ESG Container also the notion of container identity is specified.

§ ESG Fragment Management Information - provides the encapsulation mechanism for a set of ESG fragments, by providing the ability to assign a unique identifier (fragment_id) for the lifetime of an ESG fragment and indicating the current version of an ESG fragment.

§ ESG Data Repository.

5). General Structure of an ESG fragment container

http://docs.google.com/View?id=ddh56dhg_235czzsrkfw

§ Header: which contains identification and pointers to the different high-level structures of the ESG fragment container.

§ Fragment management information structure: which holds identification information of the ESG fragments inside the ESG data repository, as well as pointers to them.

§ ESG data repository: which contains the ESG fragments (i.e. ESG XML fragments, ESG Auxiliary data or Private auxiliary data).

6). Fragment Management Information

§ The Fragment Management Information provides the encapsulation mechanism for a set of ESG fragments, by providing the ability to assign a unique identifier (fragment_id) for the lifetime of an ESG fragment and indicating the current version of an ESG fragment.

§ Each entry references a single ESG fragment carried within the same container.

§ Within the ESG container, the fragment management information declares the set of ESG fragments that can be found within the ESG container.

§ The fragment management information announcing for each ESG fragment, its type and its location within the ESG data repository.

7). ESG Data Repository

§ ESG Data Repository can hold any type of ESG Fragment. The type of the ESG Fragment and the position inside the ESG Data Repository is signalled by the Fragment Management Information

§ ESG Auxiliary data are resources which are referenced from an instance of the XML based data model e.g. an SDP file, an HTML page, an SVG file, a PNG file, etc.

§ A service provider may either make the ESG auxiliary data available:

• As part of the data forming the ESG fragment stream.
• Over the interactive channel.

8). ESG Container:

§ Each ESG container is assigned a unique ID (Container_ID) and version information, which are signalled by the underlying ALC/FLUTE layer.

§ ESG Containers are used to carry a number of different types of ESG data. This ranges from ESG initialization information (e.g. ESG Init Message, ESG Session Partition Declaration, Index data) to ESG fragments.

§ An ESG Container is identified by a 16bit integer value (Container_ID) that shall be unique within an ESG Fragment Stream. When containers are delivered in the multiple stream mode, the Container_ID shall be unique across all IP streams forming that ESG.

§ An ESG Container is delivered as a file within a FLUTE session. Since an ESG Container is identified using its Container_id value, this shall be used to form a unique URI, that is used for the "Content-Location" attribute of the "File" element within the ESGs FDT.

§ While using FLUTE as the transport protocol for the ESG, it is mandatory to signal ESG Container ID and Version changes in the FDT.

§ ESG Container ID and Version may be signalled by the mechanisms described in this clause, which define how the TOI field provides the required versioning information.

§ When a version identifier is assigned to a transported object through the LCT header, the TOI field is split into two parts:

• the first part (Most Significant Bits) is allocated to the actual object identification (e.g. a Container_ID),
• the second part (Less Significant Bits) is allocated to the version identifier (e.g. a container Version_ID).

§ The LCT TOI field is 32 × O + 16 × H bits in length where the Transport Object Identifier flag (O) length is 2 bits and the Half-word flag (H) length is 1 bit. The maximal length of the TOI is therefore 112 bits (i.e. 14 bytes).

§ It is recommended that each ESG container is announced in the FDT of the underlying FLUTE session with a URI

§ The default and mandatory way to announce new versions of a ESG container, is to provide an FDT with a higher FDT instance ID. The new FDT declares a new mapping of the ESG container's "Content-Location" field to a new TOI value.

§ An optional way is to use the Split TOI mechanism. It consists in conveying the ESG container's container_ID and version_ID in the ESG container's TOI value. This allows the terminal to keep track of changes in ESG containers directly at the transport level, without the indirection of the FDT.

§ Under the condition that the files are received in the order, they were sent and the FullFDT flag in FDT instances are set to "true". The wraparound problem can be assumed not to exist, because a received FDT instance with Full FDT attribute "true" that always declares the latest consistent and complete set of files.

§ For bandwidth saving purpose, ESG containers can be compressed with GZIP at transport level. This is signalled in the FDT by setting the "Content-Encoding" attribute to "gzip".

9). Three different types of ESG containers:

§ ESG init container: contains initialization information required by the client for setting up ESG reception and processing.

§ ESG fragment container: contains data related to the ESG (i.e. ESG XML fragments, ESG auxiliary data or private auxiliary data).

§ Optional ESG index container: contains indexing information for easily tracking changes to fragments without having to acquire all ESG fragment containers.

§ The signalling of the representation of ESG XML fragments (textual, fragment level gzip, BiM) is carried in an ESG init message which is encapsulated in a special ESG container, called the ESG init container.

§ The ESG init message holds all information necessary to set up the processing of ESG fragments at the client, in particular character encoding and DecoderInit.

The ESG init container gives:

§ The encoding method used for the ESG.

§ The indication if one or more indexes are carried within the stream.

§ The DecoderInit information.

§ An optional ESGMain element.

§ The ESG session partition declaration if the ESG multiple streams transport is used.

10). ESG containers and semantics:

§ An encapsulated ESG XML fragment structure contains one ESG XML fragment (content, acquisition, etc.) represented according to the following options:

§ Textual XML

§ Binary XML represented in the BiM format

§ For both representation options, the gzip compression at transport level is supported

§ In the context of textual representation, the gzip compression gives better results at transport (ESG container) level than at fragment level.

ESG Container Semantics: (N/A Here)

ESG Fragment Management Information Semantics: (N/A Here)

ESG Data Repository Semantics: (N/A Here)