1). ESG Overview:
§ A terminal can access an ESG once it has synchronized with a DVB-H-IPDC transport stream.
§ It can show the available services, status of some download and could offer an interface for other programs.
§ The ESG can be seen as a central directory of information about the services that are available in a DVB-IPDC system.
§ The provided information includes both detailed service description information (possibly presented in the form of rich content such as pictures, video extracts, links to other services, etc.) and information that is necessary for the terminal to access the service if selected.
§ It can know where to find the ESG data in the stream thanks to the PSI/SI tables.
§ The components of this schema (service, purchase, content, etc.) are encoded in fragments; a fragment is a chunk of XML data extensively describing the component it relates to.
§ The ESG is implemented through a layered model.
§ Many different kinds of features can be implemented in the ESG.
§ ESG serves the mobile terminal middleware with signaling data to enable service lookup from the DVB-H stream and playback with the correct client software and codecs.
2). ESG operations are broken down in three main operations:
§ EPG engine: The EPG engine is responsible for the aggregation of live channel EPG data.
§ It is also responsible for the generation of the EPG in the different formats associated to the different deployment models.
1. ESG bootstrap: the operation through which the terminal knows which ESGs are available and how to acquire them.
2. ESG acquisition: the operation through which the terminal gathers and processes the ESG information for the first time or after a long time without connecting.
3. ESG update: the operation through which the terminal refreshes the ESG information stored in the terminal with the latest versions.
§ NOTE: Even though in figure below, the steps are shown sequentially this does not mean that steps cannot be processed in parallel.
3). ESG operations - ESG Bootstrap:
§ From the ESG bootstrap information the terminal can determine the number of ESGs that are available on that IP platform, the identification thereof and the acquisition information to access a particular ESG. (The relevant ESG to consume and the required information to configure the selected ESG session.)
§ ESG bootstrap is the operation through which the terminal discovers which ESGs are available and how to acquire them.
Connect to a selected IP platform thru PID in PSI/SI table
§ 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, How the particular IP platform is selected is implementation dependant, it might be fixed in the implementation, selected by the user or selected by other means.
§ Once the terminal has connected to a valid DVB-H transport stream carrying IPDC services on 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 (TR 102 469).
§ From the ESG bootstrap information, the terminal can figure out how many ESGs are available on that IP Platform, what is the relevant ESG to consume and the required information to configure the selected ESG session.
§ Once the terminal located the IP stream of the selected ESG, it can initialize the file delivery session on the terminal and the ESG processing. Then the terminal can start to receive the ESG information.
§ Note: For starting on the selected ESG, the terminal needs to know the location of the related IP stream, through the PSI/SI tables.
§ Note: Service Information (SI) in Service Discovery provides supplementary information about services, both audio program and data.
3.1). ESG bootstrap
§ Several ESGs can be transported in parallel on an IP Platform.
§ To indicate to the receiving terminal, the availability of ESGs the specification consists of the following parts:
a) Bootstrap Descriptors provide information about the ESG Provider and the Acquisition of available ESGs.
b) Transport of the Bootstrap Descriptors and the ESGAccess Descriptor.
3.2). Two kinds of Bootstrap Descriptors are signaled in the bootstrap process:
§ ESGProviderDiscovery Descriptor
§ ESGAccess Descriptor.
§ The ESGProviderDiscovery descriptor specifies the ESG providers that deliver ESGs in a given IP Platform.
§ The ESGProviderDiscovery descriptor is represented as a textual XML file.
§ Based on the ESGProviderDiscovery descriptor, the user or the terminal may select the ESG to boot with.
§ Based on the ESGProviderID associated to each described ESGProvider, the terminal may parse the related ESGAccessDescriptor to boot the ESG.
§ The ESG Bootstrap Descriptors are transported on ALC/LCT as specified in TS 102 472 for FLUTE sessions.
§ Both descriptors are delivered through a FLUTE session with a well-known (registered) destination IP address and port (224.0.23.14 for IP Version 4 and FF0X:0:0:0:0:0:0:12D for IP Version 6 on port 9214 defined in TS 102 471).
§ Furthermore, this session is the only one sent to that address and port, so that the terminal does not require any additional information e.g. TSI of the session to start the bootstrap process.
4). ESG operations - ESG Acquisition:
§ One of the ESG delivery scenarios is the ESG delivery over Broadcast Channel.
§ In this scenario a whole ESG is delivered over DVB-H bearer utilizing one or several IP streams and using FLUTE protocol.
§ The interactive delivery methods can also be utilizing HTTP protocol
§ An ESG or parts of it can also be delivered over an interactive channel in three scenarios:
a) repair case: to repair the containers received over BroadCast channel (BC)
b) to complement the broadcast channel (delivered over different BC and IA channels)
c) as a standalone means for transporting a consistent ESG (over InterActive Channel - IA) channel)
1. For 1st scenario: In the repair case, the terminal can request for containers that are transmitted over the Broadcast Channel by using their Container IDs. The requests are to be sent to the interactive access point supporting ‘repair’ capability.
2. For 2nd scenario: It is possible to deliver parts of an ESG over different channels, i.e. over BC and IA Channels.
§ In this complementary case, a comprehensive list of the ESG Fragments are listed in the DeliveryList, i.e. at a given time the listed fragments form a consistent ESG. Update and versioning management is handled by tracking changes in the DeliveryList. The repair of the ESG can be performed to its BC delivered parts as in the BC-only delivery case.
3. The 3rd scenario: It is a standalone IA (Interactive Channel) delivery of an ESG. Also in this case the DeliveryList provides a list of consistent set of ESG Fragments. The repair, as specified for the BC delivery, does not apply.
5). ESG operations - ESG Update:
§ The operation through which the terminal refreshes the ESG information stored in the terminal with the latest versions.
5.1). For Update in ESG Transport:
§ ESG container updates (discussed in single stream or multiple streams of ESG transport)
§ Indexing and fragment updates (discussed in single stream or multiple streams of ESG transport)
§ Strategy for grouping fragments into ESG containers (discussed in single stream or multiple streams of ESG transport)
6). In Streaming Delivery - Session initiation using the ESG
§ The session initiation starting from the ESG with the necessary parameters that are extracted from the ESG and the session setup procedure.
6.1). Streaming Session parameters
§ The parameters of a session are provided in the Session Description of the ESG Acquisition fragment that either:
1. directly describes a session by:
(Case 1) an inlined SDP file of the ESG Acquisition fragment.
2. or indirectly describes a session by:
(Case 2) pointing to an SDP encapsulated in an ESG container
(Case 3) pointing to an SDP file transported within an ESG FLUTE session
(Case 4) pointing to an SDP transported in a separate FLUTE session that is announced by an inlined SDP
6.2). There are two methods of conveying the content referencing SDP file:
§
§
In indirect referencing (cases 2 to 4), the reference (SessionDescription) consists of:
§ an SDP description (SDPStream) that describes the FLUTE session that carries the SDP file of the service, and
§ the URI of that SDP file (SDPURI).
6.3). Detect updates of the SDP
Depending on the type of SDP delivery, terminal may detect updates of the SDP as follows:
§ Inlined SDP (case 1): an update of the SDP is detected by watching for updates to the ESG containers and consequently acquisition fragment that carries the SDP.
§ SDP as ESG auxiliary data (case 2): the terminal locates the SDP and registers its fragment_id and version. To detect updates to the SDP, the terminal checks the ESG Fragment Management Information for announcement of a new version of the fragment (identified through its fragment_id).
§ SDP file is carried as a single file in the FLUTE session (cases 3 and 4): the terminal checks the FDT to detect the announcement of a new version of the file, which is done by announcing a new mapping between the file URI and the TOI in a new FDT instance.
6.4). Timing synchronization
§ Terminal consuming a FLUTE session for dynamic session update concurrently to a streaming service, is supposed to download any new version of the SDP file.
§ As described in CDP specification, a new version is identified by a different TOI to URI mapping that appears in a newer FDT instance.
§ The URI of the SDP file is obtained from the SDPURI element contained in the SessionDescription element of the Acquisition fragment.
§ This SessionDescription element is of type
§ Upon detection of a new version of the SDP file of the streaming session, the terminal checks the start time in the SDP 't=' field.
§ The start time is given as NTP timestamp (UTC time).
§ The terminal should use the Sender Reports sent in the RTCP streams of the streaming service to establish the time synchronization and to schedule the update of the session with the new SDP file.
7). In File Delivery - Session discovery
§ A file delivery service is described in the ESG by a Service Fragment.
§ The contents of the file delivery service are described each by a Content Fragment.
§ The user selects the services he wants to consume and may perform a purchase step. Thereafter, the terminal locates the corresponding Acquisition Fragment by looking for the referring Schedule Event Fragments and/or Service Fragment.
§ The user should only see the timing published in the ESG and select content based on this timing.
§ The FLUTE receiver is expected to consume the sdp delivered along with the ESG.
§ The FLUTE sender should not expect that the terminal will override the sdp timing information based on the ESG information, therefore the sdp should have some relaxed session timing boundaries (i.e. larger than the timing boundaries in the ESG).
§ However, the FLUTE sender should not expect that terminals start reception before the start time published in the ScheduleEvent fragment.
8). Transport Protocol - ESG Retrieval over Interactive Channel
§ ESG Query Requests and ESG Query Responses shall be transmitted by HTTP over TCP/IP over interactive channel.
8.1). ESG Query Requests
§ The terminal shall originate requests. The network shall respond to requests.
§ The request shall be made using ‘POST’ method of HTTP/1.1.
§ The ‘Request-URI’ of HTTP POST request shall be set to the interactive AccessPoint URL signalled in the ESG Bootstrap AccessDescriptor.
8.2). ESG Query Responses
§ The ESG Query Response message is an HTTP Response message as specified in HTTP/1.1
§ The response payload will be delivered in the message body of the HTTP response message.
§ Optionally the response may be compressed with GZip. In that case the content-encoding entity header field is set to Content-Encoding: gzip
沒有留言:
張貼留言