ETSICENELEC joint Specialist Task Force 255 draft TR 101 282

1
ETSI/CENELECjoint Specialist Task Force
255draft TR 101 282

• A presentation of the initial analysis and
  conclusions underlying the definition of a
  standardization Work Program in the field of
  digital interactive TV
• Open Meeting on the development of a
  standardization Work Program supporting
  interoperability in digital interactive TV
  services,
• Brussels, 7 November 2003

2
Market development aspects relevant to an iTV
standardization Work Program

• Strong regional differences
• some markets reached service penetration gt40
  others struggle to pass a 5 threshold, causing
  differences in legacy environments
• Growing market acceptance of enhanced broadcast
• Simple broadcast related applications have been
  successful, which to some extent has directed
  stakeholders iTV investment policies
• Recognized market potential sophisticated
  services
• There is consent in more advanced markets, users
  are differentiating between linear and
  enhanced/interactive content
• Interoperability necessary to support market
  growth
• iTV market growth will be supported by the
  portability of services across markets, either
  organized in a vertical or in a horizontal way
• Available standardization
• SI and API specifications available from
  industry consortium (DVB)

3
Digital penetration in different markets
early 2003 estimates based on various individual
industry sources
Digital terrestrial
Digital satellite
Digital cable
Analogue cable
Analogue terrestrial
Analogue satellite
Note Overall digital penetration in the US
38,1 (19,1 satellite, 18,5 cable and 0,5
terrestrial source European Commission from
digital switchover to analogue switch-off, 2003)
4
Regulatory aspects relevant to to an iTV
standardization Work Program
Article 18 Dir. 2002/21/EC
Article 17 Dir. 2002/21/EC

• The Commission shall draw up a List of standards
  to serve as a basis for the harmonized provision
  of electronic services
• Member States shall encourage the use of these
  standards
• If necessary, the Commission may request
  additional standardisation

• In order to promote the free flow of information,
  media pluralism cultural diversity,
• Providers of digital interactive television
  services shall be encourage to use an open API
• Providers of enhanced receivers shall comply with
  an open API in accordance with mini-mum
  requirements of the relevant standards and
  specifications
• The effects of these provisions shall be examined
  before June 2004 by the Commission

5
General recommendations and conclusions from the
CENELEC Report

• Five possible areas for additional
  standardization
• Functional receiver specifications Service
  Information APIs presentation engines content
  authoring formats
• Include or incorporate ongoing processes
• Globalisation of the MHP specification
  (GEM-process) E-Book process MHEG-5
  standardization SI fine-tuning recent
  industry initiatives
• A single point of coordination
• the ETSI/CENELEC/EBU Joint Technical Committee
  Broadcast is recommended to oversee the process
  of further standardization
• Timelines
• in view of the upcoming EU evaluation of
  interoperability, the timely delivery of
  standards is specifically important to the market

6
General assumptionsunderlying the Work Program

• Tool-box approach
• a range of complementary solutions is likely
  have a more direct overall impact on
  interoperability than a single technical solution
• Bottom-up and top-down
• stakeholders should be able to improve
  interoperability at the receiver end as well as
  at the broadcast or content end of the chain,
  depending on the relevant market requirements
• Internal coherence
• A set of proposed standardization work items
  should be coherent in such a way that solution A
  does not prevent to implementation and usage of
  solution B in the same market
• External compliance
• Solutions, compliant with established markets
  should be available for both a bottom-up as
  well as a top-down approach to increased
  interoperability

7
Interoperability issues work in different
sections and layers in the broadcast chain
8
Functional Receiver Specification

• Functional Receiver Specification
• specification of an interactive digital
  television device, usually including hardware
  performance and software behaviour definitions
  and requirements, in order to be able to properly
  work in given scenarios to support the provision
  of interactive digital television services with a
  given quality level

9
Relevant facts developments with respect to
terrestrial delivery

• EICTA E-Book
• Based on inputs from DigiTag, UK DTG, NorDig,
  ANIEL. Includes FTA and Pay-TV scenarios through
  CI. Used in Germany, Spain, Italy mainly
• Does not address primarily iDTV, but provides for
  PSTN modem.
• Subtitling and Teletext considered as components
  of TV services.
• Further on-going work to specify updated E-Book
  version to cover interactive services, based on
  standardized API as an optional element.
• NorDig (Scandinavian countries)
• Unified specification covering 4 profiles
• basic, enhanced (no interactivity)
• Enhanced interactive, Internet access (based on
  MHP API)
• D-Book (UK)
• Specification for DTT
• DTG Testing test suites
• Marketing branding
• Includes Required and Optional features
• Under development I-DTG to address IP TV

10
Relevant facts developments with respect to
cable delivery

• EICTA-C
• Under elaboration
• Based on E-Book
• NorDig Cable (Finnish)
• Set up additional requirements in 2002 for the
  cable market.
• Specifically nationally oriented provides for
  the use of a specific CA system compulsory
• Common API
• ECCA
• Collecting commercial requirements to discuss
  with industrial manufacturers of STB expected
  for January 2004
• Development of specifications by mid 2004

11
Relevant facts developments with respect to
satellite delivery

• Original efforts made by Satellite Operators
• Generic requirements from satellite operators
  (broadcast element)
• Vertical satellite platforms (usually pay-TV)
  have defined their own specifications
• No reference available for satellite interactive
  services Free-To-Air.
• Interfaces for DVB-IRDs
• Physical Layers
• DVB interfaces for IRDs, which does not only
  cover satellite, but also terrestrial, cable and
  SMATV interfaces
• Not meant for interactive services, although
  provisions for return channel physical layers, as
  optional

12
Preliminary conclusions

• IEC/CENELEC
• to lead standardization work for development of
  a set of specifications for the several
  interactive infrastructures
• Specific items for the Work Program
• Baseline specification for interactive
  terrestrial STB. Contributions EICTA, DVB,
  DigiTAG, UK DTG, NorDig, ANIEL,
• Baseline specification for interactive cable STB.
  Contributions EICTA, DVB, ECCA, NorDig Cable, UK
  DTG,
• Baseline specification for interactive satellite
  STB. Contributions EICTA, Satellite Operators,
  ESOA, DVB, NorDig, Specially, address FTA
  services. Cooperation with vertical driven
  business operators.
• Adress additions to DVB-spec. to cover RC via
  Ethernet ports
• Address requirements from consumer associations
  and, in particular, cope with needs of people
  with disabilities

13
Roadmap functional receiver specifications
Roadmap

14
Service Information

• Service Information (SI)
• specified by DVB, which forms a part of DVB
  bitstreams, is used in order that the user can be
  provided with information to assist in selection
  of services and/or events within the bitstream,
  and so that the IRD can automatically configure
  itself for the selected service. Some SI data for
  automatic configuration is also specified by
  ISO/IEC as PSI

15
Relevant facts findings with respect to Service
Information (1)

• DVB-SI Specification
• Aid for automatic tuning of IRDs
• Presentation information left to choice of IRD
  Manufacturers
• Survey conducted by EICTA/DIGITAG
• Basic functionality of SI is generally optional
• Some interoperability issues remain, although
  solved if followed DVB guidelines
• Requirement to make interpretation by
  implementers
• Need to follow common implementation practices.
• Issues identified are mainly applicable to the
  broadcast component
• DVB-SI Guidelines
• Implementation guidelines, semantics and minimum
  profile
• Guidelines do not cover user-interface details or
  advanced EPG.
• Guidelines complemented by other recommendations
  developed by EICTA, NorDig, UK DTG
• Some lack of details on the use of private data
  codes.
• General stakeholders demand for transmissions to
  use mandatory SI codes

16
Relevant facts findings with respect to Service
Information (2)

• DVB-SI Allocation of Codes
• Permanent updates of Allocation of Codes by ETSI
  JTC through DVB Office.
• No clear mechanism put in place to check/ensure
  the updates of the tables.
• Confusion from other national SI codes registries
  set up by National Authorities or National
  stakeholders
• DVB-SI Maintenance Process
• DVB-GBS already commits to maintain DVB-SI spec.
  and DVB-SI guidelines.
• Issues raised only on a voluntary contribution
  from DVB Members.
• DVB Office maintaining the table for SI codes
  allocation

17
Preliminary conclusions

• DVB
• to lead the work program to maintain and update
  the DVB-SI spec., the DVB-SI Guidelines and DVB
  SI table of allocation of codes
• To act pro-active in finding DVB-SI actual
  implementation practices in the market
• Maintaining DVB-SI
• Sharing experiences on the implementation issues
• Ensuring fully comprehensive SI allocation tables
• Stakeholders
• to conclude on suitability of voluntary set up
• Testing environment
• Certification scheme
• National SI registries
• to harmonize at a European level their practices
  and share information on their resolutions
• Possible involvement of European Bodies, like the
  IRG

18
Roadmap Service Information
19
Execution engines or APIsand presentation engines

• APIs or execution engines
• Constitute the interface between resources in a
  digital receiver and broadcasted applications,
  i.e. they enable applications to execute a
  command, entered by the user through an interface
  by applying the receivers resources (e.g. return
  channel, storage, etc.)
• Presentation engines
• Can be applied to present interactive content on
  screen, without having to rely on the presence of
  an execution engine they provide a simpler
  paradigm at the expense of the detailed control
  and programmability provided by a typical
  execution engine
• In addition non-stand-alone versions (a.k.a.
  browsers) that do need an execution engine, are
  applied in the market as well
• Most digital receivers in Europe are equipped
  with an existing execution or presentation
  engine, either standardized (MHP) or
  non-standardized (e.g. OpenTV, Liberate or
  MediaHighway)

20
Recent developments signal the need for
additional activity related to APIs

• Globalization of MHP
• The GEM guideline specification enables MHP into
  to develop into a global API standard, however
  complex IPR issues remain
• Increased commercial interest in MHP deployment
• More broadcasters as well as content developers
  are planning development of MHP content and
  services
• Coexistence of MHP and legacy platforms
• The requirement to enable stakeholders in
  choosing a receiver-based approach when aiming to
  improve interoperability, generates the
  requirement to enable coexistence of standardized
  and legacy platforms in the same market. MHP can
  do this through plug-ins

21
Both MHP specifications enable coexistence but
consequences differ
MHP 1.1 interoperable plug-in mechanism
MHP 1.0.3 application based plug-in mechanism

• Upside
• Mechanism requires relatively simple static dual
  signaling of both MHP and legacy applications
• Downside
• Application based mechanism, not allowing legacy
  applications to get full access to the MHPs
  resources

• Downside
• Mechanism requires relatively complicated
  non-static dual signaling of both MHP and legacy
  applications
• Upside
• Legacy applications can get access to a
  receivers resources (e.g. Return channel) making
  it suitable for migration purposes

Note Several aspects of MHP 1.1 are still under
consideration preventing it from being deployed
on a commercial scale
22
Additional work on and around the MHP 1.1
specification is necessary

• Legacy systems and standardized APIs
• Feedback from stakeholders indicate that
  available standardized and non-standardized APIs
  meet current market requirements
• Coexistence migration
• As far as interoperability on the receiver side
  is concerned both versions of the MHP
  specification offer possibilities
• Interoperability on the content side between
  legacy systems and MHP may be addressed via a
  portable content format
• In order to facilitate migration, the
  interoperable plug-in mechanism embedded in MHP
  1.1 can be used

Conclusion The continuation of the work on and
around the MHP 1.1 specification should be
integrate time-critical item into the Work
Program
23
Developments in some markets created the need for
alternatives to an execution engine

• Enhanced broadcast
• The commercial success of applications requiring
  only local interactivity have triggered and
  endorsed stakeholders interest in solutions
  simply enabling the enhanced broadcast mode
• Presentation engines
• These provide an alternative means to present
  content on screen without relying on the presence
  of an API, but also at the expense of a number of
  features of an API
• Risk of non-standardization
• A standardized presentation engine may help
  bridging between zapper-boxes and full
  interactive receivers, preventing increasing
  non-interactive capability turning into a default
  standard

24
Presentation engines are currently deployed in
two different modes
Non-stand-alone
Stand-alone

• Engine, capable of giving users access to
  interactive content without the presence of an
  API
• Has access to a receivers resources within the
  limitations of its own technical capabilities
• Work is necessary in order to allow coexistence
  with MHP in the same market
• Market requirement to define at least one
  standardized solution

• Application or browser sitting on top of an API,
  not capable of functioning without the presence
  of an API
• Does not have access to a receivers resources
  other than through the API
• Does not establish a direct interoperability
  issue, as it is not necessarily resident in a
  receiver

25
Additional considerations with respect to
standardizing presentation engines

• O, 1 or many
• Including one presentation engine for both
  stand-alone and non-stand-alone modes is closest
  to market regulatory requirements
• Existing or new standardization initiatives
• No useful results can be expected in time from
  processes that have yet to be started up in
  standardisation bodies or industry groups
• Relevant aspects of coexistence
• For a stand-alone presentation engines
  coexistence with MHP should be ensured while a
  non-stand-alone presentation engine should take
  the shape of an MHP-application or module
• Additional browsers or presentation engines
• Coexistence with presentation engines, other
  than those covered by the Work Program can be
  dealt with either through the MHP (interoperable)
  plug-in mechanism or as an application (browser)

26
Ongoing work is available for considering
integration into the Work Program
Non-stand-alone
Stand-alone

• Standardization MHEG-5 broadcast profile ongoing
  in ETSI
• Requirements for MHEG-5/ MHP coexistence and
  migration defined
• Implementation of requirements (either in MHP
  1.0.3 or in MHP 1.1) under review

• DVB-HTML available in combination with MHP 1.1
• OCAP and DASE harmonized into ACAP
• ACAP intended to be made available by ATSC to DVB
  replacing DVB-HTML
• Discussion on global harmonization ongoing in ITU

• Conclusion
• It is proposed to integrate the activities
  related to
• MHEG-5 as a time-critical item into the Work
  Program
• ACAP as a non-time-critical item into the Work
  Program

27
Portability of Services

• Differences in iTV platforms can impede
  portability
• platform STB capabilities networks
  broadcast, return path
• and information infrastructure
• CENELEC Report cites Content Authoring issue
• Authoring for multi-platform delivery
• Need for a mechanism to support co-existence and
  enable migration where desired.
• Need to facilitate adaptation of existing
  services to new platforms
• Improving the ability to support a mixed
  environment
• in the context of STFs work, we have
  specifically focused on multi-platform delivery
  of enhanced and interactive TV services

28
Portable Content Formats (PCFs)

• Platform-independent service description
• Based on service providers point of view,
  providing the means to of describe the intended
  user experience
• Adaptation at the network/platform level
• Upon delivery to a given network, the portable
  content format is transformed into a local format
  suitable for delivery to the target platform
• PCFs do not replace the need for an engine in the
  STB
• Once a PCF is transcoded, it still needs an
  underlying engine in the box to work

29
PCF Applicability

• PCFs are based on best effort
• Cross platform result is comparable
  experience, much like web browsers
• But PCFs (and APIs) cant compensate for large
  differences in receiver capabilities (video
  scaling, graphics overlays, etc)
• PCFs can provide wide, but not perfect coverage
• Comments from one working group indicate that
  some high performance applications (e.g. action
  games) may not work well with PCFs
• PCFs should work on emerging and existing
  platforms
• An outside the box approach, but network
  operators need to implement one transcoder for
  each platform they support

30
PCF Conclusions

• The PCF approach has support
• DVB has an active PCF group, which includes a
  range
• of interests.
• SMPTE has completed a PCF standard
• Other players consider standardizing PCFs
  already deployed

Conclusion The DVB is encouraged to complete
their work DVB-PCF commercial requirements are
likely to be done by Q1 2004, with detailed
technical work to follow The DVB is asked to
take note of other developments during the course
of their standards efforts
31
General conclusions underlyingthe definition of
the Work Program

• Need for additional complementary standards
• In different sections layers within the
  broadcast chain, additional standardization will
  support increased interoperability, in addition
  to the currently available standards
• Toolbox approach
• A toolbox approach avoids conflicting standards
  and enables stakeholders to choose a solution
  tailored to their specific market environment
• Timing
• A distinction between time-critical,
  non-time-critical and regulatory work items
  ensures an effective use of resources while at
  the same time addressing regulatory market
  requirements nevertheless, not all work items
  will be completed by June 2004

32
but many issues remain outsidethe scope of the
Work Program

• Regulatory issues
• In addition to the standardization work items,
  some issues (e.g. SI coordination) have to be
  resolved at a regulatory level and will have to
  be indicated in the Work Program as well
• Interoperability issues will remain
• Not all interoperability issues in all markets
  can be resolved by standardization or even by
  regulation
• Regular backward compatibility issues remain
• For example, many installed IRDs will not be
  compatible with future services, regardless of
  the API theyre equipped with
• Possibility of phased development
• Interoperability and freedom of choice for users
  on a regional level will most likely precede
  interoperability and freedom of choice for users
  on a European level

33
Preliminary definition of work items to be
included in the Work Program
34
Continuation of the process

• 2nd draft TR 101 282
• Evaluation inclusion input 1st Open Meeting
• Evaluation inclusion additional stakeholder
  input (by Nov. 27, 2003)
• Evaluation of impact of competing standards
• Interfacing with the work of STF 254 on Mandate
  M/328
• Definition actual Work Program with timelines,
  deliverables and organizations involved and
  discuss Presentation at 2nd Open Meeting,
  16/12/03, Brussels
• Contributions
• The STF strongly invites contributions from
  individual stakeholders as well as industry
  groups stakeholder organizations

35
Specific additional stakeholder input is required
in the next areas

• Functional receiver specifications
• How to coordinate the different specification
  activities (e.g. multiple terrestrial and cable
  processes)
• Broadband iTV services
• Clarification from stakeholders is required to
  determine what, if any, additional
  standardization activity is needed with respect
  to interactive TV services using broadband for
  the delivery or the return channels
• PVR
• Is standardization in this area relevant to the
  improved interoperability of interactive
  television services within the next few years

36
Many thanksfor your kind attentionand
contributions

• ETSI/CENELECjoint Specialist Task Force 255
• Bart Brusse (bart_at_contestconsultancy.com)
• Dr. Julián Seseña (jsesena_at_iies.es)
• John Tinsman (jtinsman_at_opentv.com)