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:
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
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
§ An optional way is to use the
§ 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
§ 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
§ 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.
§ 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
§ In the context of textual representation, the gzip compression gives better results at transport (ESG container) level than at fragment level.