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
§ 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
§ 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
§ An optional way is to use the
§ Under the condition that the files are received in the order, they were sent and the FullFDT flag in FDT instances are set to
§ For bandwidth saving purpose, ESG containers can be compressed with GZIP at transport level. This is signalled in the FDT by setting the
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)
沒有留言:
張貼留言