ESG with SPP (Service Purchase and Protection) N/A yet
To be completed later
2009年10月1日
ESG/EPG (13) - Middleware and STB
ESG/EPG - Middleware and STB
1). EPG / ESG - Middleware and STB Overview
§ The content is selected by means of an Electronic Program Guide (EPG) that resides on a Set Top Box (STB) in IPTV, which also acts as the decoder for the video streams to permit display on conventional TVs with analog inputs.
§ Users request content to be viewed using an IPTV remote control and on-screen menus in the Electronic Program Guide (EPG).
§ Though completely different from the on-screen program scroll on the TV Guide Channel in the United States, the technology is based upon broadcasting data to an application usually residing within middleware in a set-top box which connects to the television set and enables the application to be displayed.
§ Middleware is the software system used for delivering an IPTV service to the consumer.
§ IPTV middleware is the software that manages the interaction of network elements from the headend through to the STB.
§ There may be a server portion to the middleware in the headend, or at a central network point, and a client portion that resides in the STB.
§ The middleware allows a customer to select from a list of available video programs.
§ Providers include Microsoft, Widevine, Myrio/Siemens, Minerva, and Orca, among others.
2). Middleware Functions include
§ Middleware Functions include subscriber control, service definition, content control, and system control.
§ IPTV middleware supports the basic operation of the IPTV system with functions such as subscriber authentication, channel selection, an electronic program guide, and VoD services.
§ The middleware is typically a client/server architecture where the client resides on the STB.
§ The middleware controls the user experience and, because of this, it defines how the consumer interacts with the service. For example, the user interface and services available to a consumer, such as electronic program guide (EPG), VoD, or pay-per-view (PPV) service, are all made available and controlled through the middleware.
3). Typical Middleware capabilities include
3.1). User Management:
§ The middleware provides the dynamic User Interface (UI) to the STB.
§ It also keeps track of the STB security ID, as well as maintaining the STB usage log for billing and security purposes.
§ It provides the Web-based STB remote control capability.
§ The STBs can also be remotely upgraded.
§ The UI of the STB may be customized and assigned to individual users or multiple user groups.
3.2). Content Management:
§ The software provides flexible control over that content.
§ For example, one can apply different costs to different content types, decide on the usage pattern, or create different packages for different content groups.
3.3). Infrastructure Management:
§ The middleware allows the administrator to configure server roles and functions and control input and output parameters.
§ The middleware provides manual and automated tools for load balancing.
§ It can monitor the availability of all servers and can activate a failover mechanism in the event of finding a component failure.
4). IPTV middleware solutions can be categorized into three parts:
1. Middleware that provides a broad range of features and interfaces into multiple network elements, multiple customer facing elements, provides customer management and monitoring as well as interfaces into back office systems. Middleware in this category can be deployed on a client/server basis and/or integrated into network components (including CPE) and the applications provide management and interface to both northbound SP provider network components and servers and southbound into set-top boxes and customer equipment. Additionally this category of middleware usually provides APIs into the SP’s OSS/BSS.
2. Middleware that is provided in conjunction with a specific network element and/ or functionality. This category of middleware is usually housed within the equipment itself such as a headend, content server, application server, STB etc.
3. Middleware that is focused on back-office functionalities and interfaces. This type of middleware is separate from OSS/BSS but has been developed specifically to provide interfaces between customer edge equipment and SP OSS/BSS.
5). A number of existing interactive IPTV middleware standards:
§ MHP - Multimedia Home Platform (MHP) to support IPTV it is first helpful to understand how MHP operates. The following sections give a brief overview of MHP when used in an end-to-end DVB digital TV system.
§ GEM - Globally Executable MHP (GEM) specification was developed. Thework involved in developing the standard was carried out by the DVB organization. From a technical perspective GEM is based on MHP middleware technology and defines a set of mandatory core features.
§ OCAP - OpenCable Applications Platform is the interactive TV middleware standard of choice for network service providers based in
§ ACAP - (Advanced Common Application Platform) is an open interactive TV middleware standard used by digital set-top boxes that receive signals from
§ ARIB B23 - the Japanese TV standards body, has also adopted GEM as a basis for Japanese iTV standards.
ESG/EPG (12) - ESG User Requirement and Terminal Behaviour
ESG - User Requirement and Terminal Behaviour
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
訂閱：
文章 (Atom)