1). User Requirements and Expectation of ESG:
§ The content of the service package should include existing channels and other popular content. The short form of content tailored as less than 10 min is highly demanded by the end users.
§ Highly personalized ESG is required since mobile TV is mostly considered as personal viewing.
§ Suitable content should be delivered for different mobile viewing conditions, requiring the ESG to be tailored based on the user preferences along with the current contexts. By providing the content that is personalized, end users will be given what they really want.
§ ESG should be simple and intuitive. There is a requirement that the delivery of personalized content mentioned above should minimize the end user’s manipulation, reducing the complexity from the user’s side.
2). Terminal Behaviour and Functions:
2.1). Bootstrap:
§ ESG bootstrap is the operation through which the terminal discovers which ESGs are available and how to acquire them.
§ Before the actual ESG bootstrap operation can take place, the terminal has to connect to a DVB-H transport stream and select a particular IP platform.
§ From the PSI/SI tables, the terminal receives the location (PID) where the IP stream with the well-known IP address for the ESG bootstrap information of that IP platform is located.
§ First time a terminal connects to the ESG Bootstrap FLUTE session, it discovers the available ESG providers in the ESGProviderDiscovery descriptor.
§ Next time the terminal connects to a particular IP Platform, in a reasonable amount of time, it can assume that previous stored information of the ESGProviderDiscovery descriptor is still valid.
2.2). Joining an ESG session
§ After the user selects an ESG provider, the associated ESGEntry contains the MultipleStreamTransport field that indicates which (single or multiple) transport mode is used.
§ Session Partitioning: The terminal can identify for which time period a particular session is relevant by checking “start_field_value” or “end_field_value”.
§ The presence of the start_field_value depends on the value of the
§ If the terminal just wants to consume a specific part of the ESG data relevant for a certain time period (e.g. next 2 hours, next week), the terminal may select the appropriate ESG FLUTE session to tune to, from the ESG session partition declaration and acquire the set of ESG fragments.
§ Overlapping Partitions: The ESG multiple stream transport allows that partitions of the ESG transported in separate sessions can overlap with respect to a particular partition criterion.
2.3). Announcement of available ESG containers
§ ESG containers that are available: The ESG containers are signalled by the presence of a
§ All ESG containers currently scheduled for transmission signalled in the FDT instance if the
§ When signalled FDT instance with FullFDT set to
§ Which ESG containers have been removed: from this session, if the
§ Which ESG containers have been added: This is signalled for each ESG container by the presence of a
§ Which ESG containers have been updated: This is signalled by a change to the TOI value, defined within the file element used to signal the delivery of an ESG container.
2.4). Caching of Transport Objects (TO)
§ Possible caching mechanism for ESG data without having to parse the ESG data.
§ The described caching mechanism is generally applicable to both, single or multiple stream ESG delivery
2.5). Processing and caching of ESG fragments
§ Typically the fragment management information will be the first structure instantiated in the ESG container (for processing efficiency reasons), however the terminal should not assume this, and should use the structure_type and strcture_ptr fields in the ESG container header to identify the location of the fragment management information structure within the ESG container.
§ Upon acquisition of an ESG container, the terminal should first look for the fragment management information.
§ Per TS 102 471, there shall be only one fragment management information structure per ESG container.
§ The type of the ESG XML fragment can be determined from the encapsulation.
§ The terminal then has the opportunity to extract the ESG XML fragment from the ESG container and cache it in a local repository.
§ This allows fast access to ESG XML information with limited processing effort for caching.
§ The terminal then has the opportunity to extract the auxiliary data from the ESG container and cache it in the terminal. This allows faster access to an auxiliary data once it is needed.
§ The auxiliary data is identified by a URI located in the data repository. This URI is used by the ESG to reference the auxiliary data.
§ The terminal can base its auxiliary data cache maintenance on the same method that is used to maintain its ESG XML fragment repository.
§ When the terminal detects that a given ESG container has been updated, it can track the changes in fragment management information and check whether a particular ESG auxiliary data fragment has been updated.
§ The following describes how the terminal should resolve a reference to an ESG auxiliary data.
§ 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.
§ In the case where the URI defines one of the following schemes: RTSP.
§ Terminals with an interactive channel are expected to implement the following protocols: HTTP1.1 (RFC 2616), RTSP (RFC 2326), RTP (RFC 3550).
§ The use of RTSP and RTP are envisaged in the case where ESG auxiliary data is content streamed over a point to point communication.
2.6). Processing of indexes
§ Indexes may be used to optimize access to the set of fragments forming the ESG.
§ In addition they may be used to:
- Infer the set of ESG fragments that constitute the ESG at a given time.
- Monitor for changes to the set of ESG fragments forming the ESG.
§ The availability of indexes is announced to the terminal by setting the
§ This ESG init message is carried within the ESG init container which has a container_ID of
2.7). Terminal behaviour on errors in the transmission of ESG
§ The ESG application is assuming that the ESG containers received at the application layer are error free.
§ In case of transmission errors, the loss of information may be avoided/reduced by the use of FECs which can be applied at the MPE layer or at the application layer within the ALC/LCT protocol.
2.8). Processing of ESG data model instance
§ A guideline is given on how to process an ESG data model instance.
§ Two possible entry points into the data model instance are foreseen:
- the service table - to navigate the announced services;
- the schedule event table to browse the available content and/or services.
2.9). Initialisation information for service consuming application
沒有留言:
張貼留言