MHP Guide

The MHP-Guide
A comprehensive Guide to the Multimedia Home Platform,

the underlying technology and possible uses
Document / Version number: D16 / 1.0
Date: 30.03.2006
Issued by: The MHP Knowledge Project (MHP-KDB)
This document is available at: http://www.mhpkdb.org
Visit the MHP Knowledge Database: www.mhpkdb.org

Document Information:
Document Type: Deliverable

Document No.: D16
Title: The MHP Guide
Version No.: 1.0
Related to work package: WP4
Type of the Deliverable: Report
Dissemination level: Public
Author: The MHP Knowledge Project
Due date: January 2006

Delivery date (Ver. 0.9): 13th February 2006 (Stable Draft)
Delivery date (Ver. 1.0): 30th March 2006
Copyright notice
© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP Knowledge Project
This work may be reproduced and redistributed, in whole or in part, without alteration and without
prior written permission, provided all copies contain the following statement:
© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP Knowledge Project. This
work is reproduced and distributed with the permission of the Institut für Rundfunktechnik
GmbH. No other use is permitted without the express prior written permission. For
permission, contact info@mhpkdb.org.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
As we are interested to continuously improve the quality of our documents, we kindly ask you to
report back any error you find in our documents or any improvement you are able to suggest. This
can be done via writing comments into the database or by an email to feedback@mhpkdb.org.
30th March 2006
The MHP-Guide Version: 1.0
Table of Content
Table of Content.......................................................................................................................3
List of Tables ..........................................................................................................................11
List of Figures.........................................................................................................................12
1 Purpose of the MHP-Guide .............................................................................................14
1.1 General ...................................................................................................................14
1.2 Target Groups ........................................................................................................14
2 What is interactive television?.........................................................................................19
2.1 Types of applications ..............................................................................................19
2.1.1 Available Interactive Applications .......................................................................19
2.1.2 Information Services ...........................................................................................20
2.1.3 Communication Services ....................................................................................22
2.1.4 Entertainment Services.......................................................................................23
2.1.5 T-Commerce.......................................................................................................25
2.1.6 T-Government.....................................................................................................26
2.1.7 T-Learning ..........................................................................................................27
2.1.8 T-Health/T-Care..................................................................................................28
2.1.9 Business TV........................................................................................................28
2.2 Levels of interactivity ..............................................................................................29
3 Introduction to MHP ........................................................................................................31
3.1 The DVB Project .....................................................................................................31
3.2 The need for MHP as an open API standard..........................................................31
3.2.1 Market developments and DVB activities ...........................................................31
3.2.2 EU policy.............................................................................................................32
3.3 MHP activities in DVB.............................................................................................33
3.4 MHP: Current status and new developments .........................................................33
3.5 Ensuring the interoperability of MHP ......................................................................34
3.5.1 The MHP Test Suite ...........................................................................................35
3.5.2 The MHP Knowledge Project..............................................................................36
3.6 MHP in the markets ................................................................................................37
3.6.1 Austria.................................................................................................................37
3.6.2 Denmark .............................................................................................................38
3.6.3 Finland ................................................................................................................38
Page 3 of 215
30th March 2006
3.6.4 France.................................................................................................................39
3.6.5 Flandern..............................................................................................................39
3.6.6 Germany .............................................................................................................40
3.6.7 Italy .....................................................................................................................41
3.6.8 Norway................................................................................................................42
3.6.9 Spain...................................................................................................................43
3.6.10 Sweden...........................................................................................................44
3.6.11 United Kingdom ..............................................................................................45
3.6.12 Switzerland .....................................................................................................45
4 MHP iTV Applications .....................................................................................................46
4.1 MHP application .....................................................................................................46
4.1.1 Why Java? ..........................................................................................................46
4.1.2 Extensions added from other standards .............................................................46
4.1.3 New TV Specific functionality .............................................................................47
4.2 MHP applications and the broadcast chain ............................................................51
5 MHP end-to-end architecture ..........................................................................................53
5.1 Introduction.............................................................................................................53
5.2 MHP end-to-end reference model ..........................................................................53
5.2.1 Program Content Playout ...................................................................................54
5.2.2 MHP Application Authoring & Production Tools .................................................54
5.2.3 Content Management System (CMS).................................................................54
5.2.4 Download server & firmware upgrade ................................................................54
5.2.5 Public Key Infrastructure MHP PKI.....................................................................55
5.2.6 PSI/SI..................................................................................................................55
5.2.7 DSM-CC .............................................................................................................56
5.2.8 Conditional Access System ................................................................................57
5.2.9 Network Equipment ............................................................................................58
5.2.10 MHP terminal ..................................................................................................58
5.2.11 Return Channel...............................................................................................58
5.2.12 Application specific backend servers..............................................................59
5.3 Actors of the MHP end-to-end system and their roles ............................................59
5.3.1 MHP authoring tool vendor .................................................................................61
5.3.2 MHP application developer.................................................................................61
5.3.3 MHP service provider .........................................................................................61
5.3.4 Broadcaster ........................................................................................................61
Page 4 of 215
30th March 2006
5.3.5 Network operator ................................................................................................62

5.3.6 MHP playout vendor ...........................................................................................62
5.3.7 CAS provider ......................................................................................................62
5.3.8 ISP ......................................................................................................................62
5.3.9 MHP Backend operator ......................................................................................63
5.3.10 MHP terminal vendor ......................................................................................63
5.3.11 DVB Services SARL .......................................................................................63
5.3.12 MHP Certification Authority.............................................................................64
5.3.13 End-user .........................................................................................................64
5.3.14 MHP SW stack provider..................................................................................64
6 Organization of the MHP knowledge...............................................................................65
7 Basic Architecture ...........................................................................................................67
7.1 Introduction.............................................................................................................67
7.2 DVB-J .....................................................................................................................67
7.2.1 Introduction .........................................................................................................67
7.2.2 DVB-J Constraints ..............................................................................................67
7.3 DVB-HTML .............................................................................................................68
7.4 Principle of scarce resources .................................................................................69
7.4.1 Memory...............................................................................................................69
7.4.2 Persistent storage...............................................................................................69
7.4.3 Tuning Interface..................................................................................................73
7.4.4 Return Channel...................................................................................................74
7.5 Migration .................................................................................................................75
7.5.1 Migration from previous legacy middleware to MHP ..........................................75
7.5.2 Migration from older to more recent MHP versions ............................................76
8 Broadcast Protocols ........................................................................................................79
8.1 Introduction.............................................................................................................79
8.2 Transport Stream Elements....................................................................................79
8.2.1 A note on naming................................................................................................79
8.2.2 MPEG-2 Transport Stream .................................................................................79
8.2.3 DVB Transport Stream .......................................................................................82
8.2.4 MHP....................................................................................................................82
8.3 DSM-CC .................................................................................................................82
8.3.1 DSM-CC Object Carousel...................................................................................83
8.3.2 Object carousel optimization...............................................................................84
Page 5 of 215
30th March 2006
8.4 Synchronization ......................................................................................................85

8.4.1 Do-It-Now stream events ....................................................................................85
8.4.2 Scheduled stream events ...................................................................................86
8.4.3 Creating stream events.......................................................................................86
8.5 Section Filtering ......................................................................................................87
8.5.1 What is a section? ..............................................................................................87
8.5.2 MHP....................................................................................................................88
8.5.3 Capacity and performance..................................................................................88
8.5.4 Examples ............................................................................................................89
8.6 Tuning and service selection ..................................................................................89
8.7 Principles of conditional access (smart card, CI content protection) ......................90
9 MHP Applications and Application Lifecycle ...................................................................92
9.1 Applets and Xlets....................................................................................................92
9.2 Xlet Application.......................................................................................................92
9.3 Resident applications .............................................................................................94
9.4 Stored applications .................................................................................................94
9.4.1 Restrictions of stored applications ......................................................................95
9.4.2 Extensions to MHP 1.0 APIs...............................................................................95
9.4.3 Signaling of stored application............................................................................96
10 Service Signaling........................................................................................................97
10.1 Introduction.............................................................................................................97
10.2 Introduction to SI / PSI............................................................................................97
10.2.1 Information independent from transport stream..............................................98
10.2.2 Optional “other” tables ....................................................................................98
10.2.3 Tuning to other streams..................................................................................99
10.2.4 Accessing Service Information .......................................................................99
10.2.5 Usage of the SI overview tables .....................................................................99
10.3 Introduction to AIT and application change ..........................................................100
10.4 Application Loading over Return Channel ............................................................101
11 Security.....................................................................................................................102
11.1 Security in interactive television environments .....................................................102
11.1.1 Integrity .........................................................................................................102
11.1.2 Confidentiality ...............................................................................................103
11.1.3 Availability.....................................................................................................103
11.2 Signing MHP Applications ....................................................................................104
Page 6 of 215
30th March 2006
11.2.1 Hash files (dvb.hashfile) ...............................................................................104

11.2.2 Signature files (dvb.signature.*)....................................................................104
11.2.3 Certificate files (dvb.certificates.*) ................................................................105
11.2.4 Example of a signed MHP application ..........................................................106
11.3 DVB MHP Public Key Infrastructure (PKI) ............................................................107
11.3.1 Actors in the MHP PKI ..................................................................................107
11.3.2 DVB Services Hierarchy ...............................................................................107
11.3.3 DVB MHP PKI for MHP terminal Manufacturers...........................................109
11.3.4 DVB MHP PKI for Application Developers....................................................109
11.3.5 DVB MHP PKI for Broadcasters ...................................................................109
11.3.6 Certificate Management................................................................................110
11.4 Authenticating applications in the MHP Terminal .................................................110
11.5 Application Rights Model ......................................................................................111
11.6 Other aspects .......................................................................................................111
12 Graphics, Text Presentation, Audio, Video...............................................................113
12.1 Introduction...........................................................................................................113
12.2 Layers and composition concept ..........................................................................113
12.3 Playable media .....................................................................................................114
12.3.1 Java Media Framework 1.0 .........................................................................114
12.3.2 Java Media Framework 2.0 .........................................................................114
12.3.3 Java Media Framework on MHP terminals ..................................................115
12.3.4 Media flow....................................................................................................115
12.3.5 Media player and available controls ............................................................115
12.3.6 Obtaining a player and controls ...................................................................118
12.3.7 Selection of audio components with AudioLanguageControl .......................119
12.3.8 Selection of subtitles with SubtitlingLanguageControl .................................120
12.3.9 Selection of media with MediaSelectControl ...............................................122
12.4 UI components overview/main HAVI components................................................123
12.4.1 Main HAVI components ................................................................................123
12.4.2 HComponent and HContainer ......................................................................123
12.4.3 HVisible and HLook ......................................................................................125
12.4.4 Other considerations using HAVI..................................................................126
12.4.5 Input events and exclusive registrations on input event ...............................126
12.5 Displayable graphics formats and restriction ........................................................127
12.5.1 PNG ..............................................................................................................128
Page 7 of 215
30th March 2006
12.5.2 JPEG ............................................................................................................128

12.5.3 GIF................................................................................................................128
12.6 Color Table ...........................................................................................................129
12.7 Differences between TV and computer screens...................................................130
12.7.1 Calculation (PAL).........................................................................................132
12.7.2 Loss of sharpness.........................................................................................132
12.7.3 Calculation (NTSC) .......................................................................................133
12.7.4 Overview of scale factors.............................................................................133
12.8 Color conversion...................................................................................................133
12.9 Double buffering ...................................................................................................134
12.10 Fonts.....................................................................................................................135
12.10.1 Generating fonts ...........................................................................................135
12.10.2 Generating the font index file........................................................................136
12.10.3 Using external fonts ......................................................................................137
13 Return Channel ........................................................................................................138
13.1 Introduction...........................................................................................................138
13.2 Types of return channels ......................................................................................138
13.2.1 Always-on return channels ...........................................................................138
13.2.2 Connection-based return channels...............................................................139
13.2.3 Detailed example ..........................................................................................139
13.3 Protocol overview .................................................................................................139
13.3.1 UDP ..............................................................................................................139
13.3.2 TCP...............................................................................................................139
13.3.3 HTTP ............................................................................................................140
13.3.4 DNS ..............................................................................................................140
13.3.5 Protocol support............................................................................................140
13.4 MHP as client for Internet services & Integration of contents received via return
channel .............................................................................................................................141
13.5 Security on the Return Channel ...........................................................................142
14 Equipment ................................................................................................................143
14.1 Playout systems ...................................................................................................143
14.2 MHP Terminal architecture ...................................................................................144
14.2.1 Hardware requirements ................................................................................146
14.2.2 Conceptual view for Software architecture ...................................................147
14.3 Test equipment.....................................................................................................148
Page 8 of 215
30th March 2006
14.3.1 IRT MHP Application analyzer ......................................................................148

14.3.2 Return Channel analysis tool........................................................................149
14.3.3 AIT / DSM-CC Analyzer and Compliance Tool.............................................150
14.3.4 Loading Time Analyzer .................................................................................151
15 Usability ....................................................................................................................152
15.1 Layout and Design................................................................................................153
15.1.1 As much as necessary, as little as possible .................................................154
15.1.2 Consistency ..................................................................................................154
15.1.3 Screen Layout...............................................................................................154
15.2 Navigation.............................................................................................................156
15.2.1 Remote Control Units ...................................................................................156
15.2.2 Interaction Design.........................................................................................158
15.3 Legibility of Text....................................................................................................159
15.3.1 Legibility Examples .......................................................................................159
15.4 Recommendations for Using Colors .....................................................................162
15.5 Usability Studies and User-Centered Design .......................................................163
16 MHP Outlook ............................................................................................................166
16.1 Technical aspects .................................................................................................166
16.1.1 DVB over IP / IP tuner ..................................................................................166
16.1.2 IP over DVB ..................................................................................................167
16.1.3 Personal Digital Recorder (PDR) ..................................................................168
16.1.4 HDTV ............................................................................................................169
16.1.5 MPEG4 / H.264.............................................................................................169
16.1.6 DVB-S2.........................................................................................................170
16.1.7 Object Tracking.............................................................................................170
16.2 Commercial aspects .............................................................................................171
16.2.1 DVB-MHP in Europe.....................................................................................171
16.2.2 DVB-MHP in the rest of the world .................................................................173
17 Glossary and abbreviations ......................................................................................175
18 Literature ..................................................................................................................191
18.1 General DVB ........................................................................................................191
18.2 General TV ...........................................................................................................191
18.3 General User Interaction ......................................................................................191
18.4 Other.....................................................................................................................192
19 Annex A - How to use the MHP KDB .......................................................................193
Page 9 of 215
30th March 2006
19.1 Organization of the Database Content .................................................................193

19.1.1 Rights and Roles ..........................................................................................194
19.1.2 Reviewing Process .......................................................................................194
19.2 Using the KDB ......................................................................................................195
19.3 Licensing conditions .............................................................................................198
19.3.1 Licensing conditions for documents in the static part of KDB .......................199
19.3.2 Licensing conditions for Java source code ...................................................199
20 Annex B – Develop your first Xlet with MHP-KDB....................................................201
20.1 Build an application ..............................................................................................201
20.2 Download an application: .....................................................................................202
20.3 Debug an application:...........................................................................................202
20.4 Source code of basic application: .........................................................................203
21 Annex C - Presentation of the MHP APIs.................................................................206
21.1 “Core” APIs ...........................................................................................................206
21.2 JMF APIs ..............................................................................................................207
21.3 JavaTV APIs .........................................................................................................207
21.4 DAVIC APIs ..........................................................................................................208
21.5 HAVi (Home Audio Video Interoperability) APIs ...................................................209
21.6 DVB APIs..............................................................................................................209
22 Annex D – Migration .................................................................................................212
Page 10 of 215
30th March 2006
List of Tables
Table 1-1: Chapters and their potential target group relevance............................................................ 18
Table 2-1: Levels of interactivity in relation to types of applications ..................................................... 30
Table 5-1: Elucidation of actors in the MHP end-to-end reference model ............................................ 60
Table 11-1: Actors in the MHP Public Key Infrastructure.................................................................... 107
Table 12-1: Palette construction rules................................................................................................. 130
Table 13-1: MHP 1.0.x Protocol Support............................................................................................. 141
Table 13-2: MHP 1.1.1 Protocol support ............................................................................................. 141
Table 14-1: Hardware resource requirements..................................................................................... 146
Table 15-1: Mandatory keys in MHP ................................................................................................... 158
Table 19-1: Rights and Roles Model of the MHP-KDB ....................................................................... 194
Table 20-1: Authoring Tools vendors .................................................................................................. 202
Table 21-1: Java Core APIs ................................................................................................................ 207
Table 21-2: JavaTV APIs..................................................................................................................... 208
Page 11 of 215
30th March 2006
List of Figures
Figure 2-1: EPG of the ARD Portal ....................................................................................................... 20
Figure 2-2: Simple STB-EPG (TechniSat)............................................................................................. 20
Figure 2-3: News Service with ¼ scaled video (Mediaset, Italy)........................................................... 21
Figure 2-4: Weather Service (RTL TV interaktiv, Germany) ................................................................. 21
Figure 2-5: Traffic Service (Prototype, rbb, Germany) .......................................................................... 22
Figure 2-6: Interactive multimedia teletext (Pro7, Germany) ................................................................ 22
Figure 2-7: TV mail client (Alticast) ....................................................................................................... 22
Figure 2-8: Arcade Game on TV screen (sofia digital) .......................................................................... 23
Figure 2-9: Interactive TV Game (ZDF, Germany)................................................................................ 23
Figure 2-10: Video on Demand Selection (gist) .................................................................................... 24
Figure 2-11: Tracking ebay auctions on the TV screen (Nionex).......................................................... 25
Figure 2-12: Sofa Shopping with OTTO’s interactive MHP Shop ......................................................... 25
Figure 2-13: Regional Information Portal for the city of Tampere (Finland).......................................... 26
Figure 2-14: Voting application related to News Show (SkyTV, UK) .................................................... 27
Figure 2-15: Kids’ Edutainment: Goosebumps (FoxKids, Germany) .................................................... 27
Figure 2-16: Customer Information at Housing Society “ewt” (GIST,
Germany) ....................................................................................................................................... 28
Figure 3-1: Profiles of the MHP standard .............................................................................................. 34
Figure 3-2: The MHP Logo .................................................................................................................... 35
Figure 3-3: DGTVi Logo ........................................................................................................................ 42
Figure 4-1: HScene in the UI model ...................................................................................................... 50
Figure 4-2: Display structure ................................................................................................................. 51
Figure 4-3 MHP applications in broadcast chain................................................................................... 52
Figure 5-1: MHP E2E Reference Model................................................................................................ 53
Figure 5-2: Detailed view of Conditional Access System...................................................................... 57
Figure 6-1: Mapping of the MHP-KDB Categories in the MHP End-to-End
Reference Model ............................................................................................................................ 66
Figure 7-1 Plug-in implementation options............................................................................................ 75
Figure 8-1 Transport Stream ................................................................................................................. 80
Figure 8-2 Example building blocks of an MPEG-2 encoder ................................................................ 80
Figure 8-3 MPEG-2 Packet Header ...................................................................................................... 81
Figure 8-4 Example of object carousel in DVB service ......................................................................... 83
Figure 8-5: DSM-CC Object Carousel Layering .................................................................................... 84
Figure 8-6: Encrypting and decrypting content...................................................................................... 90
Figure 8-7: Encryption and decryption process..................................................................................... 91
Figure 9-1: Xlet lifecycle state machine diagram................................................................................... 92
Page 12 of 215
30th March 2006
Figure 11-1: Example of a signed application [Hetzer 2001] .............................................................. 106

Figure 11-2: The DVB Services Hierarchy .......................................................................................... 108
Figure 12-1: Graphic Planes in MHP................................................................................................... 113
Figure 12-2: Porter-Duff Alpha Composition Rules ............................................................................. 114
Figure 12-3: HComponent and HContainer (a) ................................................................................... 123
Figure 12-4: HComponent and HContainer (b) ................................................................................... 124
Figure 12-5: HVisible and HLook ........................................................................................................ 125
Figure 12-6: Example of a color table ................................................................................................. 129
Figure 12-7: Opaque CLUT ................................................................................................................. 130
Figure 12-8: Comparison of pixel aspect ratios................................................................................... 131
Figure 14-1: Typical MHP playout server interfaces ........................................................................... 143
Figure 14-2: The MHP Logo ................................................................................................................ 144
Figure 14-3: MHP terminal hardware architecture ............................................................................. 145
Figure 14-4: MHP terminal software architecture............................................................................... 147
Figure 15-1: Typical Screen Structure of an MHP Application............................................................ 153
Figure 15-2: Basic Formal Structure of a Screen Surface .................................................................. 153
Figure 15-3: Layout of a TV Screen .................................................................................................... 154
Figure 15-4: Screen Organization ....................................................................................................... 155
Figure 15-5: Remote Controls of MHP Terminals ............................................................................... 156
Figure 15-6: Functions of a Remote Control ....................................................................................... 158
Figure 15-7: Legibility Example 1 ........................................................................................................ 160
Figure 15-10: Legibility Example 4 ...................................................................................................... 162
Figure 15-11: Examples of color combinations with poor legibility...................................................... 163
Figure 16-1: Example of an IP STB..................................................................................................... 167
Figure 16-2: HD Ready logo defined by EICTA for HD equipment..................................................... 169
Figure 16-3: Example for object tracking............................................................................................. 170
Figure 16-4: MHP situation in the world in August 2005 [MHP_ORG]................................................ 171
Figure 19-1: Simplified Data Model of the KDB .................................................................................. 193
Figure 19-2: Searching an Issue in the KDB ....................................................................................... 195
Figure 19-3: Adding an Issue to the KDB............................................................................................ 196
Figure 19-4: Editing a Document......................................................................................................... 198
Figure 20-1: Developing application steps .......................................................................................... 201
Page 13 of 215
30th March 2006
1 Purpose of the MHP-Guide
1.1 General
DVB MHP, the DVB Multimedia Home Platform, is a major standard for
interactive TV today. This document is a free guidebook that offers MHP-KDB Project:
comprehensive knowledge on all fundamental aspects of MHP for all those The MHP-KDB project
involved along the end-to-end chain of interactive TV: those who are simply is co-funded by the
EU as an "IST project.
interested in MHP and want a quick overview and those who want to dig Its main aim is to
deeper into the subtleties of the standard, those who plan to enter the world improve the
of MHP practically and those who already work with MHP and need specific interoperability of
information on certain issues. MHP implementations
and MHP applications.
The MHP-Guide is generated from practical experience of European actors
in broadcasting, IT manufacturing and technology research who are familiar
with MHP in their every day work and who joined forces in the MHP
knowledge project mainly to improve interoperability of MHP
implementations and applications. As one major result of this project, the
online MHP-Knowledge Database was established. This database offers a
continuously growing number of solutions including MHP reference
application modules as "Open Source" code available for free usage.
Additionally a virtual online test center for testing interoperability on
standard hardware MHP terminals.
The MHP-Guide complements the resources offered by the MHP-
Knowledge Database. While the MHP-Guide provides a comprehensive yet
concise overview of the basic applications and technologies of the MHP
End-to-End chain, the online database leads on to deeper levels of
knowledge and to the practical dimension, be it for offering your own
solution, retrieving a solution or testing your applications.
The document layout features a broad text column with an extensive
margin. This margin highlights special information such as the depth of
information (NOVICE/EXPERT LEVEL), brief definitions of relevant terms and
references to related entries in the database for more specific knowledge
and practical solutions.
1.2 Target Groups

The MHP-Guide supports fundamental research needs of all sorts of
interest groups. The following table will help readers to see which chapters
and sections are particularly interesting for them. It lists all document
chapters and their potential target groups.
Page 14 of 215
30th March 2006
Application Programmers
Authoring Tool Providers

Decoder Manufacturers
Broadcast Equipment
Expert/ Novice Level

Manufacturers
Broadcasters
Chapter
Chapter 2: What is interactive television?
2.1 Types of applications N
2.2 Levels of interactivity N
Chapter 3: Introduction to MHP
3.1 The DVB Project N
3.2 The need for MHP as an open standard N
3.3 MHP activities in DVB N
3.4 MHP: Current status and new

N
developments
3.5 Ensuring the interoperability of MHP N
3.6 MHP in the markets N
Chapter 4: MHP iTV Applications
4.1 MHP application N
4.2 MHP applications and the broadcast

N
chain
Chapter 5: MHP End-to-End Architecture
5.1 Introduction N
5.2 MHP end-to-end reference model N
5.3 Actors of the MHP end-to-end system

N
and their roles
Chapter 6: Organization of the MHP knowledge
6 Organization of the MHP knowledge N
Chapter 7: Basic Architecture
7.1 Introduction N
7.2 DVB-J N
7.3 DVB-HTML N
7.4 Principle of scarce resources N/E
7.5 Migration E
Page 15 of 215
30th March 2006

Broadcast Equipment

Manufacturers
Broadcasters
Chapter
Chapter 8: Broadcast Protocols
8.1 Introduction N
8.2 Transport Stream Elements N
8.3 DSM-CC N/E
8.4 Synchronization N/E
8.5 Section Filtering N
8.6 Tuning and service selection N
8.7 Principles of conditional access (smart

N
card, CI content protection
Chapter 9: MHP Applications and Application Lifecycle
9.1 Applets and Xlets N
9.2 Xlet Application N
9.3 Resident Applications N
9.4 Stored Applications N/E
Chapter 10: Service Signaling
10.1 Introduction N
10.2 Introduction to SI /PSI N/E
10.3 Introduction to AIT and application

E
change
10.4 Application Loading over Return

N
Channel
Chapter 11: Security
11.1 Security in interactive television

N
environments
11.2 Signing MHP applications E
11.3 DVB MHP Public Key Infrastructure

E
(PKI)
11.4 Authenticating applications in the MHP

E
terminal
Page 16 of 215
30th March 2006

Broadcast Equipment

Manufacturers
Broadcasters
Chapter
11.5 Application Rights Model N
11.5 Other Aspects E
Chapter 12: Graphics, Text Presentation, Audio, Video
12.1 Introduction N
12.2 Layers and composition concept N
12.3 Playable media N/E
12.4 UI components overview/main HAVI

N
components
12.5 Displayable graphics formats and

N
restriction
12.6 Color Table N
12.7 Differences between TV and computer

N/E
screens
12.8 Color conversion E
12.9 Double buffering E
12.10 Fonts N
Chapter 13: Return Channel
13.1 Introduction N
13.2 Types of return channels N
13.3 Protocol overview N
13.4 MHP as client for internet services &

integration of content received via return N
channel
13.5 Security on the return channel N
Chapter 14: Equipment
14.1 Playout systems N
14.2 MHP terminal architecture E
14.3 Test equipment N/E
Chapter 15: Usability
Page 17 of 215
30th March 2006

Broadcast Equipment

Manufacturers
Broadcasters
Chapter
15.1 Layout and Design N
15.2 Navigation N
15.3 Legibility of Text N
15.4 Recommendations for using colors N
15.5 Usability studies and user-centered

N
design
Chapter 16: MHP Outlook
16.1 Technical aspects N/E
16.2 Commercial aspects N
Chapter 17: Glossary and abbreviations
17. Glossary and abbreviations N
Chapter 18: Literature
18. Literature N
Annex A
19. How to use the MHP KDB N
Annex B
20. Develop your first Xlet with MHP KDB N
Annex C
21. Presentation of the MHP APIs N
Annex D
22. Migration E
Table 1-1: Chapters and their potential target group relevance
Page 18 of 215
30th March 2006
2 What is interactive television? NOVICE LEVEL

With the dawn of digital television a whole new spectrum of opportunities
has arrived. We were used to the introduction of new technical elements in
television during the years of analogue television, but they were all the
results of long-term processes. In those days, new functionalities were
realized by introducing new hardware in the television set (e.g. teletext and
stereo chips). Today enhancements are incomparably more rapid and far-
reaching in their impact because they are software-based: the digital TV
contains an “engine” for running applications, like we have become
accustomed to in the context of PCs. This technological basis of interactive
TV should lead to the introduction of new applications for many years to
come. It can significantly reduce the time to market for new applications.
Similar applications coming from different broadcasters will potentially have
a different look and feel. It will be possible to bring new applications into
use for just a limited time and scrap them afterwards since they do not
cause additional costs for the consumer. Interactive television (iTV)
applications will have an impact beyond the traditional broadcasting world.
There will be extended commercial potential for these applications and, as
a consequence, applications will also be developed by non-broadcasters.
The great advantage of interactive TV is that all services are running in a
controlled environment (unlike on the internet). Via DVB-T/S/C broadcast
large audiences may be addressed without the need of scaling the server
capacity or network connection.
But what is it that interactive TV can bring? The following paragraphs will
give an overview of the types of applications and the types of interactivity
that iTV can actually provide. While chapter 2.1 describes various types of
already available interactive applications, chapter 2.2 aims at a broader
classification of interactivity.
2.1 Types of applications
2.1.1 Available Interactive Applications

Interactive TV-Applications lead the way out of pure “lean-back”
consumption of TV. The first group of applications consists of so-called
program related applications that accompany the actual TV broadcast of
certain programs. These can be classified as follows:
Ahead of a certain program they can be instrumental in attracting
viewers by offering applications in advance promoting this program;
During a broadcast, they allow for the consumers’ active involvement
like participation in quizzes or voting, and/or provide additional
information that in its depth cannot be covered by the TV program
itself, as for example on the occasion of large TV events like the
Olympics or Elections, as well as on service programs, science
magazines, or entertainment programs;
After a program, additional services might offer yet more related
information and service or interaction offers that can be dealt with by
the consumer independent of the original program time slot.
The second large group of applications consists of program-independent
applications offering general information services, communication,
Page 19 of 215
30th March 2006
entertainment, video-on-demand, or T-commerce services, and, finally, TV-

based front-ends for e-Government, e-Learning or e-Health.
The following sections offer a classification of these listed types of services.
They do not refer specifically to the different types of program related
services as outlined above. However, elements of the described services
often form part of program enhancement. Furthermore, all the application
types described may be combinations of various subsets, e.g. digitext
encompassing extensive news service or T-Learning combined with T-
Chat, etc. Thus, the explanations and classifications merely serve to
describe types of applications and their general concepts.
2.1.2 Information Services

EPG
The Electronic Program Guide is a common application that should be
available in all countries and on all STBs. In many cases there are even
individual EPGs for different services on offer. The EPG lists available TV
channels and the TV programs that run on these channels. Frequently, the
EPG is a 7-day program guide. The program data is usually obtained by
reading Service Information (SI) data from the broadcast services. Thus it
can inform the user on what is currently on air, what will be broadcast next,
etc. While STBs usually offer this information in their individual look and
feel (defined by the STB manufacturer), most broadcasters offer their
specific, more extensive EPGs. This is especially interesting if they operate
more than one channel, because an attractive EPG may draw users to
certain programs on additional channels.
Figure 2-1: EPG of the ARD Portal
Figure 2-2: Simple STB-EPG (TechniSat)
Page 20 of 215
30th March 2006
News Service / Event Service

There are various kinds of News Services; most of them are portal-like
listings of current affairs, some with sophisticated categorization, and
others with very simple structures. News Applications range from simple
Live-Tickers provided via a small overlay band (in most cases at the bottom
part of the screen) to extensive (program related) information portals on big
events such as championships, Olympic Games or the Grand Prix
1
Eurovision de la Chanson .
Figure 2-3: News Service with ¼ scaled video (Mediaset, Italy)
Weather Forecast
Weather Forecast Services are usually of the type “broadcast only”.
Interactivity lies mainly in the fact that users can choose detailed views of
certain regions for a certain day. Various services throughout Europe offer
a selection of regional, national and international forecasts and current
information.
Figure 2-4: Weather Service (RTL TV interaktiv, Germany)
Traffic Service
Similarly, Traffic Services can offer users a choice of detailed information
on a certain region at a certain time. rbb’s prototype of an interactive traffic
service highlights construction sites, traffic jams and other road blocks for
any selected region in Berlin and Brandenburg. Traffic information may also
include information and schedules of public transport services, train
stations and airports. 2
1
Examples can, among others, be found at http://www.mediaset.it/digitaleterrestre/ or
http://www.ard-digital.de/index.php?id=282&languageid=1.
2
For a video presenting the user scenario visit
http://www.rbb-online.de/_/unternehmen/beitrag_jsp/activeid=254/key=teaser_300427.html
Page 21 of 215
30th March 2006
Figure 2-5: Traffic Service (Prototype, rbb, Germany)
Digitext / teletext
iTV offers the opportunity to deliver all sorts of extra information related to
the TV program much in the way it is done on the Internet. In addition to
regular, i.e. the currently usual, text-based pages, broadcasters or service
providers can offer pictures, audio and video in interactive portals, mostly
relying on bi-directional interactivity especially for video delivery.
Figure 2-6: Interactive multimedia teletext (Pro7, Germany)
2.1.3 Communication Services

T-Mail / T-Chat
Various companies on the MHP market offer MHP-based mail clients.
These can be integrated in special community services by broadcasters,
i.e. in program enhancement, but they can as well be implemented in the
STB directly, just like an EPG (see section 2.1.2). Mail and Chat
applications are clearly of the bi-directional type as they involve actual
communication among end-users. It goes without saying that these
applications require the use of the return channel to connect to a mail
server on the Internet and a keyboard, physical or virtual on screen.
Figure 2-7: TV mail client (Alticast)
Page 22 of 215
30th March 2006
2.1.4 Entertainment Services

T-Games
Interactive Games for the TV screen may range from “broadcast only” to T-Games
“bi-directional”. “Broadcast only” style would include so-called Arcade
Interactive Games to
Games like Tetris, Black Jack and the like. These games are mostly TV play on the TV screen.
compatible as interaction here only requires very few keys on the remote
control and can be handled very easily. Applications are relatively small
and quite well-received by customers. As they usually are not related to
specific TV programs they are provided by middleware or STB developers
3
rather than broadcasters , so that, similar to the mobile phone market,
these applications would be delivered with the STB or downloaded from a
website of a software provider directly to the iTV Terminal.
Figure 2-8: Arcade Game on TV screen (sofia digital)
Beyond basic Arcade gambling, some providers also offer traditional board
games transferred to iTV applications, e.g. Sky’s version of Cluedo, Soccer
(penalty) games or even more program related offers like BBCi’s CBeebies
(amongst others an interactive Big Brother game). 4
Figure 2-9: Interactive TV Game (ZDF, Germany)
Broadcasters have also built quiz games applications related to specific

shows and enabling users to participate in these shows. Multiple choice
games are especially applicable as there is a finite number of selectable
options, so that users can even use the color-, arrow- or number keys on
the remote control to select the correct answer. Figure 2-9 5 shows a kids’
quiz which has been broadcast in Germany since the 1970s; kids in the
3
See, for example, http://www.broadbandbananas.com/, SofiaDigital at
http://www.digitv.fi/sivu.asp?path=9;1239;3392;3928, or http://www.digeo.com/prodserv/digeoitv.jsp.
4
All applications listed in this paragraph can be found at www.broadbandbananas.com/ with screenshots,
scenario videos and background information.
5
For a use scenario of this iTV game see
http://www.zdf.de/ZDFmediathek/inhalt/16/0,4070,2173552-6-wm_dsl,00.html
Page 23 of 215
30th March 2006
studio see a short video and hear a question. After that they get some 30
seconds to choose the right answer by jumping back and forth between the
possible statements. With the new interactive version, kids at home can
also make a choice. Via the color keys (blue, green, yellow) they can select
one out of three cartoon figures jumping between the three available
choices. They score a point if the figure ends up on the correct spot. (For
more edutainment examples, cf. 2.1.7 T-Learning). The same is, of course,
possible with quiz shows for grown-ups like the two ARD Quiz Shows 6
(Germany) or “Who Wants To Be a Millionaire?” (France, Germany, Italy
and the UK) 7 .
For more and other ways of interactive TV Games the reader is also
recommended to take a look at BBC’s Channel 4 Games:
http://www.broadbandbananas.com/
Video on Demand Services

iTV can also function as a distribution interface for Video on Demand (VoD)
Services. Via such a portal customers select films from a range of available
VoD / Video on
movies. In hotel rooms of the world this portal will be more a transaction
Demand:
interface where a time slot is ordered that will later be charged on the hotel
Films can be ordered
room bill – the movies are transmitted or delivered by a fixed schedule and and started
the customers’ actions on the portal will merely allow access. As the individually by request
schedule would be kept even without interaction by a single user this way of the customer,
of selling access rights is also called Near-VoD. “True” VoD, e.g. at home independent of
would offer the possibility to choose a film that would actually be delivered broadcast program
schedules.
because of this transaction. The TV program is available “on demand”,
whenever the end-user chooses. Usually, the STB would have broadband
access and the selected movie would be delivered via ADSL or a similar
8
connection.
Figure 2-10: Video on Demand Selection (gist)
6
For the Edutainment program “Kopfball” see http://www.ard-digital.de/index.php?id=2670&languageid=1,
for “Das Quiz mit Jörg Pilawa” see http://www.ard-digital.de/index.php?id=280&languageid=1
7
There may be more iTV applications on this quiz format in other countries. For France and UK see
http://www.broadbandbananas.com/, for Germany http://www.rtl.de/tv/743540.php,
for Italy: http://www.mediaset.it/news/scheda/9109.shtml
8
The screenshot shows a VoD Service by German developer company GIST (http://www.gist.de/). See also
http://www.digeo.com/prodserv/moxi_ondemand.jsp for a concrete VoD service.
Page 24 of 215
30th March 2006
2.1.5 T-Commerce
T-Commerce
Interactive TV offers a number of possibilities for T-Commerce, from Analogue to the term
interactive advertising to triggering actual purchase transactions via the TV e-Commerce T-
set (also called “transactive TV”). Commerce covers all
sorts of “commercial “
Tele-Shopping applications and
A number of T-Commerce applications have been developed/ proto-typed transactions that are
delivered and
already. performed on the TV
With an extra feature of the pontegra browser (www.nionex.de) users can screen.
track current eBay auctions and be informed as soon as the auction status
changes. 9
Figure 2-11: Tracking ebay auctions on the TV screen (Nionex)
There are also a number of iTV Shopping portals using different iTV
standards: Nionex offers a “pontegra T-Commerce shopping solution 10
which appears to be transactive and bi-directional. German Mail-Order
company OTTO also created an interactive shopping portal where
customers can see, select and order all sorts of goods from the TV screen-
adapted catalogue just like they would on the Internet.
Figure 2-12: Sofa Shopping with OTTO’s interactive MHP Shop
Interactive Advertising
There have also been a number of prototypes for interactive advertising,
e.g. an MHP-based ad for Daimler-Chrysler in 2002 11 . Beyond merely
attaching further information that is made available through interactive
navigation menus, optimum impact is expected from an emotional
contextualization of the product [DUREAU 2004]. There have been various
prototypical applications that connected certain products to TV programs
9
Brochure available at the site of the application developer, Nionex:
http://www.nionex.de/downloads/Images/29_3463.pdf/download_pontegra_eBay_tracking.pdf
10
http://www.nionex.de/downloads/Images/29_3462.pdf/download_T-commerce.pdf
11
For more information see http://www.mhp-forum.de/content/applikat/daimler.htm
Page 25 of 215
30th March 2006
through object tracking and interactive menus for background

information. 12
2.1.6 T-Government
T-Government
Regional Information Portals Analogue to the term
Despite strong efforts - e.g. in Italy - to push iTV as a prime medium for e- e-Government
Government there are not yet many relevant T-Government Services.
T-Government covers
Especially regarding interactivity the available services seem rather meager all sorts of information
to date. Some network providers and especially STB developers have services and (ideally)
made first tests on the use of chip cards in STBs to enable maximum data communication and
security. Currently, a number of regional information portals in Finland and actions with the
relevant authority,
Italy are on offer as “T-Government” services; however, they often merely delivered and
combine tourist information with local news and announcements. performed on the TV
screen.
Figure 2-13: Regional Information Portal for the city of Tampere (Finland)
The ‘Italia Utile’ (‘Useful Italy’, also called “Utile T-Gov”) DTV portal is
planned to make available public information and services currently on offer
via the web based e-government portal Italia.gov.it also via terrestrial
digital TV. Its interface will be similar to that of classic teletext information
services, however, it will be faster and offer two-way interaction. 13
Availability is forecast for autumn 2006 or later. 14 Piemont already has a
basic portal with regional information, apparently broadcast only. T-
Government is said not to be as useful for bi-directional services, mainly
due to the fact that consumers are not used to writing with a Remote
Control device. However, this might change with the current generation of
SMS writing youths who will easily adopt to writing with such a device
which is even slightly bigger than a mobile phone. Currently, according to
rumors and vague forecasts authorities test technical and legal
preconditions to transfer actual transactions from the Internet to the iTV
platform(s), like submitting tax calculation forms or even voting.
12
See for example www.fun-tv.de/content/dokumente/ditv_anga_2005e.ppt#295 or
http://www.joanneum.at/en/informatik/bibliothek_detail.php?p_iid=IIS&p_typ=PUB&p_id=2193.
13
Taken from http://europa.eu.int/idabc/en/document/3648/5718
14
Find out more about the current status of fat http://www.raiutile.rai.it/articolo.jsp?id=437
Page 26 of 215
30th March 2006
Voting
As an interactive instrument for the democratic society iTV already can be

used for opinion polls 15 . Voting applications, of course, can be used for all
sorts of entertainment programs as well. 16 .
Figure 2-14: Voting application related to News Show (SkyTV, UK)
2.1.7 T-Learning T-Learning

An example for the potential of iTV for T-Learning in a program related Analogue to the term
context is a kids’ edutainment format of German Pay TV channel FoxKids. e-Learning
In this case the MHP application is not only used to offer extra information T-Learning covers all
on the program, but involves the kids in what they see and hear, giving sorts of educational
them an interactive learning experience. Learning and teaching experts say applications that are
delivered and
that learners remember 30% of what they see, 20% of what they hear, 50% performed on the TV
17
of what they read and hear and up to 90% of what they do themselves . screen. In various
18
Some others also stress the power of narrative teaching . This example publications this
complies with both ideas, telling stories in English and asking questions in ranges from providing
program related
German to check understanding. Examples like Goosebumps and “1-2 (educational)
oder 3” (ZDF, Germany, see section 2.1.4 Entertainment) may give an idea background material
of how iTV can be used for T-Learning, not only for children but also for to interactive learning
grown-ups in Business TV (cf. section 2.1.5 T-Commerce) as well as T- applications which
Health (cf. the following section) or “pure” T-Learning environments. check and track
learners’ progress.
Figure 2-15: Kids’ Edutainment: Goosebumps (FoxKids, Germany)
15
Example from SkyTV; see http://www.broadbandbananas.com/
16
For entertainment-motivated voting applications visit http://www.mediaset.it/news/scheda/14888.shtml .
17
Common understanding in Learning Theory, quoted in Margit Hertlein. Mind Mapping – Die kreative
Arbeitstechnik. Spielerisch Lernen und Organisieren, Hamburg 2001
18
For a comprehensive overview and bibliography see Rossiter, Marsha: Narrative and Stories in Adult Teaching
and Learning, available at http://www.ericdigests.org/2003-4/adult-teaching.html
Page 27 of 215
30th March 2006
2.1.8 T-Health/T-Care
The term T-Health covers basically every kind of TV based information on T-Health
health, wellness and medical topics. A special variant of health applications Analogue to the term
is “T-Care”: T-Care is a truly interactive and bi-directional way of e-Health
connecting patients and care persons or health institutions via iTV. T-Health covers all
Basically, this sort of information exchange is based on T-Mail and T-Chat sorts of information
facilities (cf. 2.1.3 Communication). In some cases 19 , however, this services related to
involves dedicated applications for exchanging current data on blood health and well-being
that are delivered and
pressure (Patient enters figures with the Remote Control after taking the performed on the TV
blood pressure) or other medical data. The application also stores patients’ screen.
information on the correct medication for patients and care personnel to
see and check. An example for such a TV-based interactive healthcare
platform is a system called Philips Motiva that was implemented and tested
in the US in 2005. Chronically ill patients are connected directly to their T-Care
care providers in order to motivate them to modify their behavior – to follow Analogue to the term
their doctor’s guidelines, eat right and exercise more. They receive a e-Care
combination of tailored educational content, timely reminders and positive T- Care covers all
reinforcement around personal goals. In addition, patients are able to track sorts of
their own vital signs – such as weight, heart rate, heart rhythm, and blood communication
20 services that connect
pressure.
patients and health
care personnel in (bi-
2.1.9 Business TV directional) TV-based
communication
Business TV is more a use case scenario than a type of application of its applications.
own. However, the idea of combining Information Services, (Internal)
Communication, T-Commerce, T-Government-like applications (to
communicate with the Human Resources Department) and T-Learning for
Further Education is worth considering especially for application developers
and network providers. Organizations may use these types of interactive
applications to provide all sorts of information and communication facilities
to their employees (Intranet-style) and, to a smaller extent, to business
partners and customers. A German housing society, for instance, offers all
sorts of information to its tenants and potentially interested persons.
Figure 2-16: Customer Information at Housing Society “ewt” (GIST, Germany)
19
Unfortunately, there were no screenshots available. For more information on one possible application scenario
and the respective success story contact www.ortikon.com (Finnland).
20
For details see: http://www.medical.philips.com/us/news/content/file_804.html
Page 28 of 215
30th March 2006
2.2 Levels of interactivity

Roughly speaking, ”interactivity” in iTV may be categorized along three
basic levels:
Broadcast only: Broadcast only applications, such as digital teletext
and personal video recording (PVR), obtain required data from the
broadcast stream. They only support “local interactivity” where the
consumer may interact locally with data stored on the end device.
Unidirectional Interactivity: Unidirectional interactive applications,
such as online voting and advertisement response, allow users to
provide response data in a single direction, with no direct reply from a
return path server.
Bi-Directional Interactivity: Bi-directional interactive applications, such
as email, web browsing, and online gaming, allow users to acquire
data from sources outside of the broadcast stream, such as a return-
path server.
The table below shows how these technical levels of interactivity relate to
certain types of applications.
Type Application Level of interactivity
Broadcast Unidirectional Bi-Directional

only Interactive Interactive
Information EPG ∗
News ∗
Weather Forecast ∗
Traffic Service ∗
Teletext/digitext ∗
Communication T-Mail ∗
T-Chat ∗
Entertainment T-Games ∗ ∗ ∗
Video On Demand
∗
(VOD)
Betting ∗
T-Commerce T-Banking ∗
Promotion
∗
application
Interactive
∗
Advertising
Page 29 of 215
30th March 2006
T-Government Information Portals ∗ ∗ ∗

T-Learning Edutainment
∗
games
Professional
∗ ∗ ∗
Further Education
T-Health Information portals ∗

T-Care ∗
Table 2-1: Levels of interactivity in relation to types of applications
Page 30 of 215
30th March 2006
3 Introduction to MHP
This chapter gives an overview of the background of MHP development as
seen from the perspective of the relevant market players and also provides
a look into the aspect of EU wide regulation.
It lines out the current state of MHP as well as planned new developments
(which are discussed in more detail in chapter 16.
Additionally it presents an overview of the MHP activities in some European
countries.
3.1 The DVB Project

Around 1990, the technologies of video coding, channel modulation and
chip integration had - after decades of research - reached a status which
indicated that digital TV broadcasting could be commercially realized in the
nearer future. In 1991, a "European Launching Group" was established
which started to coordinate with all interested players the basic technology
issues required for the introduction of digital TV. Since the official
foundation of the DVB project emerging from this group in 1993, this
initiative has successfully bundled all relevant technical developments in
the area of digital television. It has developed specifications for digital
television systems, which are fed into international standards bodies such
as ETSI. These DVB/ETSI standards are world-wide adopted and they
provide the basis for hundreds of cable, satellite and terrestrial networks
and the markets related to these networks.
Within Europe, the success of DVB has brought a degree of interoperability
that is much wider than ever before in history. Today, this has hindered an
open and community-wide TV distribution and TV market.
DVB currently has some 250 member companies from all over the world
covering all technical and service aspects related to digital TV.
3.2 The need for MHP as an open API standard
3.2.1 Market developments and DVB activities

In the first phase of standardization, DVB concentrated on the
fundamentals like channel coding for cable, satellite and terrestrial
transmission, service information, teletext transmission and the basic
encryption mechanisms. This was very helpful to achieve a successful
early start of the digital TV market in around 1995.
Soon, however, discussions in some markets came up concerning API
systems. It became clear that the potential of digital TV could considerably
be enhanced by interactivity but at the same time different API solutions
appeared in the market which were proprietary and incompatible. Both
aspects of these solutions, being proprietary as well as being incompatible
caused many worries to most market partners and only in some vertically
oriented markets different APIs were introduced. In these markets usually
one Pay TV operator decided which API to use and subsidized
corresponding decoders. Other service providers were blocked from
making their content visible on these decoders. Consequently, no broad
market development took place.
Page 31 of 215
30th March 2006
Therefore, in 1997, the DVB project started to extend the scope of its
successful work from pure digital TV to interactive digital TV and to develop
a single API standard.
3.2.2 EU policy
"Interoperability of digital interactive television services and enhanced
digital television equipment, at the level of the consumer, should be
encouraged in order to ensure the free flow of information, media pluralism
and cultural diversity. It is desirable for consumers to have the capability of
receiving, regardless of the transmission mode, all digital interactive
television services, having regard to technological neutrality, future
technological progress, the need to promote the take-up of digital
television, and the state of competition in the markets for digital television
services. Digital interactive television platform operators should strive to
implement an open application program interface (API) which conforms to
standards or specifications adopted by a European standards
organization." (Recital 13 of the Directive 2002/21/EC)
This quotation from the EU regulatory framework for electronic
communications networks and services clearly shows the political desire for
open markets and standardized APIs in the area of digital interactive
television.
This framework requires Member States to recommend service providers
and equipment providers to use an open API. Competition in digital
interactive TV is seen in the context of interoperability: if interoperability
and freedom of choice for users have not been adequately achieved in one
or more Member States, the Commission is allowed under the framework
to take action in the area of digital interactive TV and even mandate a
standard (Article 18 of Directive 2002/21/EC).
Consequently, the EU Commission welcomes the introduction of MHP as
European iTV standard. EU commissioner Erkki Liikanen stated at the 4th
EBU conference (March 2001) in Brussels:
“The Commission welcomes in particular the development of the
Multimedia Home Platform (MHP) standardized by the Digital Video
Broadcasting Group (DVB). The MHP platform has been developed by the
industry, for the benefit of the industry. The Commission considers that this
voluntary, industry led standardization is the best process to reach
interoperability, and to guarantee widespread implementation of the
standard.“
In their latest “Communication ... on reviewing the interoperability of digital
interactive television services” dated 02.02.2006 (COM(2006) 37 final) the
EU Commission states:
“The demand for interactive TV applications has proved to be less than
many forecast some years ago, and the commercial success of interactive
television remains limited. The most successful applications have been in
the area of quiz shows, sport, gambling and reality television; governments
have yet to find ways to exploit the technology successfully as a means of
communicating with citizens.”
“Developments in the market, particularly in Italy, have shown that
interoperability can be achieved when stakeholders act together with a
common aim to implement a technical standard like MHP, but that this in
Page 32 of 215
30th March 2006
itself is not sufficient to ensure the emergence and growth of interactive

digital television services; further business and technical developments are
needed.”
The resulting conclusions of the Commission in this communication contain
the following statements:
“The Commission’s priorities are now to work with Member States to
ensure the successful switchover to digital TV, which is a pre-requisite for
having interactive digital services, and to support open standards and the
ongoing cooperation on interoperability and exchange of best practice
between Member States and between stakeholders.”
“The Commission considers ... that mandating EU-wide standards under
Article 18(3) of the Framework Directive would not contribute significantly to
the growth of interactive digital television in Europe, and could have
significant negative effects.”
“The Commission ... considers that the market is best served at the present
time by continuing to rely on industry-led voluntary standardisation
initiatives.”
By this communication the Commission plays back the main responsibility
to successfully introduce an open interoperable API system to the market.
3.3 MHP activities in DVB

Very soon after the take-up of the API standardization efforts in DVB in
1997, it became clear that, technologically, the new standard could not be
based on any of the proprietary APIs as they existed in the market by then.
Subsequently, and with far-sightedness, the decision was made to use
Java technology as a basis for new common APIs. Every MHP compliant
product manufacturer will target a broader market without depending on a
particular broadcaster, and multiple service providers will be able to
develop interactive applications without depending on a particular
manufacturer, the only requirement they have to fulfill is to be MHP
compliant. The strength of this standardization is its open approach.
Also this standard relies on existing and proven standards that have
already been deployed (e.g. DAVIC). A first ETSI version of the standard
(DVB-MHP 1.0) became available in July 2000. Already in August 1999, a
public "over-the-air" demonstration of MHP applications and MHP decoders
took place at the Internationale Funkausstellung IFA (International
Broadcasting Exhibition) in Berlin. This first version of the MHP standard
had a number of shortcomings, e.g. certain technical aspects had not been
covered precisely enough. Consequently, the next version of the standard
(MHP 1.0.1) was created. It was published by ETSI in October 2001 and
was published by the Commission as European Standard on 31st
December 2002 (OJ 2002/C 331/04). In June 2002, MHP 1.0.2 was
introduced. This, in turn, was followed by MHP version 1.0.3.
3.4 MHP: Current status and new developments

While the work outlined above primarily improved the basic profile of the
standard, a new profile with additional features like HTML, extended back-
channel usability or smart card API was published by ETSI (MHP 1.1).
MHP 1.1, was published by ETSI in November 2001 as TS 102 812 v1.1.1
One major change with regard to MHP 1.0 is the inclusion of DVB–HTML,
Page 33 of 215
30th March 2006
based on the W3C specification. DVB-HTML is optional within the

Enhanced Broadcasting Profile and the Interactive Broadcast Profile, but is
an integral part of the Internet Access Profile. MHP 1.1 also provides a
lifecycle model for plug-ins and includes support for application downloads
via the return channel.
All valid DVB-MHP standards can be obtained from the ETSI website.
From a service and application point of view currently three profiles and
one option called DVB-HTML have been defined allowing manufacturers to
develop a range of products that provide different functionalities. Each
profile can co-exist with others offered on the market.
Enhanced broadcast profile combines digital broadcast of audio/video
services with download applications, which enable local interactivity. This
profile does not support an interaction channel.
Interactive broadcast profile enables a range of interactive services
associated or independent from broadcast services. This profile requires an
interaction channel.
Internet access profile is intended for the provisioning of Internet
services. It also includes links between those Internet services and
broadcast services.
Internet access profile DVB-HTML

+
Profiles
Interactive broadcast profile DVB-HTML

+
Enhanced broadcast profile
Options
Figure 3-1: Profiles of the MHP standard
There are a number of new technological developments beyond the

internet access profile. They cover technologies like PDRs, IP delivery, HD
and new video coding standards. All of them are in one or another aspect
related to MHP as MHP can be seen a central control instance for DVB
decoders. More insight in these developments is given in chapter 16.
3.5 Ensuring the interoperability of MHP

Since first practical experiences with MHP were gained it has become
evident that the interoperability of applications and decoders at a technical
detail level would be a challenging issue for this complex standard.
Enabling interoperability is enabling several systems (the components of
the MHP end-to-end value chain) to interact with one another and to
exchange data according to a prescribed method in order to achieve
predictable results. In order to deal with these interoperability issues, a lot
of testing has already been performed, basically checking all available
applications on the emerging decoder implementations. IRT’s
Page 34 of 215
30th March 2006
interoperability workshops provided the organizational framework and

technical basis for many of these tests. Today, there are still unresolved
issues. In addition, the findings of the tests have not been systematically
and completely documented. Interoperability, performance and ease of use
are the responsibility of the actors of the complete MHP value chain.
Solving the described problems is the prerequisite for MHP’s large-scale
market success, which will be dependent on stable interactive services with
a good performance.
Both, creation of the MHP Test Suite and the MHP Knowledge Database
are initiatives to cope with the question of interoperability.
3.5.1 The MHP Test Suite

DVB has taken into account the interoperability issue by releasing an
official MHP Test Suite for Conformance Testing of receivers. Every MHP
device on the market which aims at carrying the official MHP logo (see
below) must have passed this Test Suite in a self-certification process
applied by the manufacturer.
Figure 3-2: The MHP Logo
The strength and quality of the official Test Suite directly influences
interoperability of systems in the market and is an ideal means to ensure
that MHP support all features as defined in the MHP specification.
The MHP Test Suite is made available to decoder manufacturers via ETSI.
It consists of thousands of test cases written as Java Xlets which can be
run in an automated testing environment (ATE).
Test Suite versions 1.0.2a and 1.0.2b have been made available in
September 2002 (1.0.2.a) and January 2003 (1.0.2b). Both versions of the
Test Suite are related to the MHP standard version 1.0.2. Early March 2003
the DVB Technical Module approved version 1.0.3 of the MHP specification
and is further working on advanced versions of MHP, such as the internet
access profile (MHP 1.1.2 and PVR extensions). As a result, additional
work is required to update the Test Suite to comply with these recent
versions of the MHP standard.
Huge effort both financially and in manpower has already been invested by
several companies, amongst them the partners who have in 2004 joined in
the EC funded MHP-CONFIDENCE project.
Main activities of MHP-CONFIDENCE are to identify areas where MHP
interoperability can be strengthened by additional Conformance Tests, to
setup specifications for programming related tests, to implement these
tests and to verify them in a quality acceptance process to such an extent
that they match the quality criteria imposed for DVB’s Official MHP Test
Suite.
Page 35 of 215
30th March 2006
3.5.2 The MHP Knowledge Project

In order to actively support and accelerate MHP take-up throughout
Europe, the MHP KNOWLEDGE PROJECT has been launched. Initiated
by core members of the MHP Alliance, the EC co-funded research project
combines the competence of some of the Alliance’s key players with that of
notable partners from technology research.
By establishing the MHP Knowledge Database (MHP-KDB), a dynamically
updated single "point of call" for all MHP related issues, the project sets out
to tackle exactly the issue of interoperability of MHP implementations and
applications. The knowledge database is designed to store all questions
and issues that arise during the process of implementing MHP decoders
and MHP applications.
MHP-KDB does not only rely on internal expertise but encourages the
whole MHP community to contribute to the project by sharing practical
experience on interoperability issues. This guarantees that the most
pressing problems are addressed. The project ensures that useful
information is available on all components within the entire value chain. It
provides know-how and best practice solutions to all companies and
organizations active in this field.
By July 2005 the MHP Knowledge Project made their MHP Knowledge
Database available for online access to the whole MHP community.
The database is accessible via the project website http://www.mhpkdb.org.
All interested users from companies and organizations active in the field of
MHP are invited to benefit from the offered MHP knowledge and to actively
make use of this new platform for information exchange. For the relevant
MHP issues, the database presents a continuously growing number of
solutions including reference application modules as "Open Source" code
which is available for free usage by any MHP-developer. The know-how in
the database addresses all components within the entire value chain of
MHP-based applications. Annex A provides detailed information on how the
MHP Knowledgebase works.
The project website also gives access to a "virtual test centre" which
presents the unique possibility to test MHP applications online on standard
hardware MHP decoders, without the need for physical access to a testing
laboratory. More information on the online test centre can be found on the
project’s website http//www.mhpkdb.org.
The MHP-KDB partners are in detail:

Institut für Rundfunktechnik GmbH, München, Germany (Co-ordinator)
Bayerische Medien Technik, München, Germany
Danish Broadcasting Corporation, Søborg, Denmark
Deutsche Welle, Bonn, Germany
Instituto Tecnológico de Aragón, Zaragoza, Spain
Rundfunk Berlin-Brandenburg/ARD Digital Play Out Center, Potsdam,
Germany
Panasonic AVC Networks Germany GmbH, Peine, Germany
Philips CE/STB, Suresnes, France
Telenor, Fornebu, Norway
Page 36 of 215
30th March 2006
tComLabs, Ghent, Belgium

Universität Duisburg-Essen, ICB, Essen, Germany
3.6 MHP in the markets

This section describes in short the current status of the MHP deployment in
some European countries. More in-depth information on MHP in various
markets can be found in the document “Analysis of the Current Situation” at
http://www.mhpkdb.org/publ/mhp-kdb_d1-ver-2.pdf.
As many of the described activities still are in experimental stage, some of
the information given may be outdated soon. Nevertheless it provides a
short documentation of the efforts made.
3.6.1 Austria
In the Austrian city of Graz a DVB-T test, including the broadcast of MHP
based interactive content, ran for 3 months starting in June 2004. This test
run was provided by a number of public and private broadcasters.
In addition to the three regular TV services ORF 1, ORF 2 and ATV+ an
interactive service called „!TV4GRAZ“ was distributed via DVB-T. 150
MHP-enabled DVB-T set top boxes, including a return channel, were
provided to households for using the broadcast interactive service. The
interactive content was accessible to the consumers via an MHP-Portal. It
contained enhanced applications, like EPG or news ticker as well as
interactive applications using the return channel, like a quiz and an
interactive advertisement that included the possibility of requesting further
information.
Also Austrian cable network operators are testing MHP via DVB-C and
cable-based return channel. The cable network operator Salzburg AG ran
test applications, including news ticker, SMS/email applications, games and
ticket ordering, until February 2005.
On Feb. 23 2006 the Austrian regulator granted a license to operate two
nation wide DVB-T multiplexes to the “Österreichische Rundfunksender
GmbH&Co KG” (ORS). The ORS will serve as a platform operator for these
two multiplexes.
Part of this license is the obligation to use MHP for interactive applications.
This license explicitly refers to Art. 18 of the framework directive and the
obligation of the EU member states to encourage open API standards in its
MHP argumentation.
The ORS has published a receiver specification (to be found at www.ors.at)
which requires the implementation of MHP 1.1.2 for compliant receivers.
This specification is also valid for the satellite market as the relevant
services are also distributed via DVB-S – including the MHP applications.
It is planned to add on the first multiplex a MHP bitrate of 600 kbit/s to each
service. Besides an MHP EPG also commercial MHP applications are
foreseen.
Page 37 of 215
30th March 2006
3.6.2 Denmark
Denmark currently has digital cable (TDC) and satellite (Canal Digital and
Viasat) networks. At present, there is not too much interactivity on air.
Existing offers are either based on OpenTV (TDC and Viasat) or
MediaHighway (Canal Digital). The construction of a DTT network has just
started in 2004. This network will be based on MHP.
DR has been supporting MHP from the very beginning – through
participation in MHP Alliance, MHP Action Group, and through NorDig. In
June 2001, DR initiated an analysis project with the purpose of preparing
DR technically to develop and broadcast MHP applications. It is the result
of this work that we now see being used in the development of the DR
Portal application and its supporting infrastructure.
As DR launches the DR Portal, it will be made available in the satellite
networks in proprietary APIs as well as in MHP. This, however, refers only
to the migration period. After that it will be MHP only. The MHP-portal will
also be made available in the DTT network, and, most probably, also in the
cable network as part of the 'must carry legislation'.
The DTT network is currently under construction and will be put into
operation by in early 2006. The channels that will be available initially in the
DTT network will be DR and TV2-DK channels and a common EPG service
is also planned. The market for set top boxes will be horizontal with no
subsidizations. The DR interactive 24/7 information service was launched
in the fall of 2004 and is broadcast on satellite and later also on DTT.
3.6.3 Finland
A total of 16 television broadcasting stations and ten television sub-
transmitters in northern Finland will be digitalized during the third phase of
the extension of the digital television network.
Digital television will make numerous new channels available to the
consumers. Until now, three television channels have been broadcast via
the terrestrial television network in these areas. The extension of the
network will increase the number of channels to ten. The channels
available in the digital television are the channels TV1, TV2, YLE24, YLE
Teema (YLE Theme) and YLE FST of the Finnish Broadcasting Company.
In addition, the selection includes MTV3, MTV3+, Subtv, Channel Four
Finland and Channel Four Plus.
In addition to new channels, the digital television offers several additional
services, such as a television program guide, digital text television and
channel-specific additional services. The services are available using MHP
(Multimedia Home Platform) compatible receivers.
Digita DTT has defined some network rules of operation including special
requirements for MHP terminals in Finland. 21
Current MHP applications on air as a regular service in the DTT networks
are:
21
These rules can be found at
http://www.digita.fi/digita_dokumentti.asp?path=1841;2081;3640;2113
http://www.digitv.fi/digiProEtusivu.asp?path=9;1826
Page 38 of 215
30th March 2006
YLE offer: Supervideotext, Memory game, NE-spelet, News ticker,

Government facts
MTV offer: Real estate finder, TV-bank (and Hockey score ticker,
Weakest Link and Formula 1 as prototypes).
Digita, the Finnish Broadcasting Company, MTV3 and Channel Four
Finland have agreed on extending the broadcasting network of digital
television to cover the whole of Finland during 2005.
3.6.4 France
DTT was launched officially on 31st March 2005. The coverage concerned
35% of population at start and was extended to 50% until 1st of September
2005, date of the Pay TV services launch, which have the particularity to be
mandatory MPEG-4 video codec compliant. The assumption was that
interactive TV services are closely linked to pay TV offers.
No consensus could be found between the different players concerning
interactivity: whereas the public broadcasters support MHP, commercial
broadcasters are generally in favor of proprietary solutions.
No clear choice on interactivity can be made until the commercial
distribution has taken up.
A regulatory text called “Paquet Telecom” (including standard
recommendations from the European Commission toward MHP) has been
adopted in France in July 2004.
According to two technical arrests, describing the signal content
compliance as well as the legal obligation for DTT receivers, were
promulgated by the Ministry of Industry:
Receiver: the receiver must be compliant with IEC/CENELEC 62216-
1 norm.
Signal: signaling and securing information must be compliant with TS
102 812 (MHP 1.1). If any broadcaster uses another standard, it has
to be a non-proprietary open standard and it must be made known to
the CSA (French regulatory board).
3.6.5 Flandern
In Belgium, media (TV, Radio) is within the power of the communities
(Flemish speaking, French speaking and German speaking). In the
Flemish community, about 97.5% of the homes can be connected to the
cable network and more than 90% of these homes are actually connected
to the cable network to receive analogue cable television. In September
2003, the public Flemish broadcaster VRT, the commercial broadcasters
VMMa, VT4 and afterwards MTV and the owners of the cable network
Interkabel and Telenet signed a cooperation treaty called “Vlaanderen
Interactief” (Flanders Interactive). Within this cooperation, they will do
research on the technological and the social scientific side of iDTV. This
cooperation will also prepare the introduction of iDTV in Flanders. The
project is supported and funded for 12.4 million euros by the Flemish
government. “Vlaanderen Interactief” has chosen one standard: MHP.
In September 2005 Telenet started its commercial deployment of
interactive digital television. In addition to a number of digital television
channels, Telenet offers different types of applications: a TV portal, an
EPG, interactive applications like voting, VOD, shopping and will launch a
Page 39 of 215
30th March 2006
PVR with MHP middleware in March 2006. The government is also

interested in offering access to different e-government services and in the
near future everyone will be able to authenticate himself by putting his
electronic identity card in the smart card reader of the set-top box.
Belgacom, the incumbent national telephony operator and a competitor of
Telenet, offers since the summer of 2005 also digital TV, but over xDSL.
Besides digital TV, video on demand, web access and Interactive TV will
be offered. The middleware is produced by Myrio, which was recently taken
over by Siemens (the system integrator for the Belgacom TV project). For
strategic reasons, not much technical information is made public.
In the meantime Flanders is fully covered by DVB-T. Only the TV (2) and
Radio (9) channels from the public broadcaster VRT are available. No
interactive services are offered and the VRT doesn’t make any promotion
for that network.
On the cable networks from Interkabel, people are now also able to receive
digital TV (DVB-C) without any interactive services.
3.6.6 Germany
The major German market players have considered the introduction of
digital television including interactivity via APIs since 1995. Due to the lack
of standards, original planning had been based on proprietary systems. It
became clear soon, however, that these systems were not suitable for
open, horizontal mass markets. German partners have consequently
contributed very actively to the development and deployment of MHP.
MHP was first demonstrated publicly in Germany at IFA 1999, the first
regular services were started in mid 2002.
Meanwhile several broadcasters (all of them free TV) offer a number of
regular MHP services.
In addition to the MHP activities of established TV broadcasters, some new
players have entered the stage: The big German mail order company
"Otto" has started to offer its products via TV, using an interactive MHP
application. Furthermore, "Hörzu", a well established TV print magazine,
now broadcasts an MHP version via TV.
Even though in 2003 more digital satellite receivers than analogue satellite
receivers were sold in Germany for the first time, MHP has not yet
developed into a market success.
The start of DTT and the analogue switch-off on 4. August 2003 in the
region Berlin/Brandenburg was accompanied by the introduction of
enhanced TV services based on MHP. Since then a number of regions
followed and some are already preparing DVB-T. Due to the fact that
terrestrial analogue TV will be switched off by 2010, it can be assumed that
the purchase of DVB-T boxes will increase continuously in the next years in
Germany. Since the beginning of 2005, three DVB-T boxes enabling MHP
are available on the German market (see also section 2.4.3). The sales
prices of the MHP DVB-T boxes range from 225 € to 800 €, while prices for
DVB-T boxes not supporting MHP start at 70 €.
The higher costs and the lacking of a good promotion of MHP terminals
might constrain their powerful impact on the German TV market. If these
Page 40 of 215
30th March 2006
problems will be overcome and the broadcasters will offer more interactive
services, MHP will have a bright future in Germany.
In January 2005 some German cable operators decided to support MHP in
their networks; no regular services, however, have been implemented up to
now. The majority of the cable operators, however, is not interested in
MHP.
T-Online intended to introduce an MHP set-top-box with hard disc at IFA in
September 2005. This terminal integrates DSL which guarantees a high-
speed return channel suited for MHP applications. Value-added services
such as Video on Demand (VoD), games, ring tones, video clips are
offered and can be invoiced via T-Online.
3.6.7 Italy
On December 1st 2003, Mediaset and RAI have started digital terrestrial TV
broadcast aiming at coverage of 50 % of the population with a plan to have
a fast extension to the entire country.
By end of 2004 the coverage already exceeded the 50% threshold.
The Italian national broadcasters (RAI, Mediaset, La 7) have adopted DVB
MHP as the standard for interactive applications for the Italian DTT.
The Telecommunication authority defines the broadcast licenses for
network operators and authorizations for the TV content suppliers for an
antitrust system. As a component of the regulation, the Italian government
has allocated a budget for a contribution of initially 150 euros per
interactive DTT receiver for 900,000 receivers.
Italy is now by far, thanks to Government subsidies for interactive
receivers, the country with the highest number of MHP set-top boxes
actually deployed in consumers' houses. In 2003 and 2004 actually
730,000 MHP terminals have been deployed into the households.
In 2005 the subsidies have been lowered to 70 Euros per MHP decoder,
but an additional deployment of more than 1,000,000 MHP terminals is
expected.
In Italy there are already 15 to 30 analogue programs available. In fact,
DTT contents rely on interactivity more than quantity and in the Italian DTT
networks interactive MHP applications play a very important role.
The overall interactive offering per DTT provider is:
Mediaset 26 applications
LA7/MTV 10 applications
LA7 6 applications
RAI 8 applications
According to the deployments encouraged by the subsidies there is a quite
huge number of MHP terminals available in the Italian market.
To allow an optimum interoperability between the various networks carrying
MHP applications and the available decoders the DGTVi has generated a
"D-Book" (http://www.dgtvi.it/stat/Industry/D-Book/Page1.html).
DGTVi is an association (composed of RAI, Mediaset, La7, MTv, and the
Fondazione Ugo Bordoni) working to enable the deployment of digital TV.
Page 41 of 215
30th March 2006
On its web site, one can find the coverage of the operators for DTT
(www.dgtvi.it).
DGTVi proposes to the manufacturers to conform their products to D-Book
on a voluntary basis. A DGTVi logo (cf. Figure 3-3) has been created and
will be released for certified receivers that will pass a test procedure. These
tests are performed in a self certification process by the vendor itself.
Figure 3-3: DGTVi Logo
3.6.8 Norway
On 26th February 2004 the Parliament approved that a DTT network can
be established in Norway. When the transmission will start is not published,
and is dependent on who is going to be implementer of the infrastructure.
Some conditions are the most important part of the approval:
The network shall have coverage of at least 95 % of the population.
All households in Norway shall, after the analogue switch-off, have a
digital TV offer with all the programs from NRK and TV2, and
hopefully the other Norwegian channels. This is related to total
coverage, independent of the distribution platform.
The most popular Nordic and other foreign channels are to be
included in the offer.
The analogue switch-off will be implemented region by region, and
expected to be finalized by the end of 2008. There will be no funding
from the Government.
The cost for the set-top box is expected to be NOK 1300 –1500 (EUR
165-190).
There is one company ”Norges Televisjon AS” (NTV), which is owned 50 %
by NRK and 50 % by TV 2, that has got an advanced commitment for the
license to be responsible for the DTT transmissions. They will also be
responsible for the selection of programs, establishing and running the
multiplexes and they will possibly pay for the distribution.
The government has reopened the possibility to apply for license on DTT
due to new license period. Telenor by Telenor Broadcast has signalized
that they will be one of the appliers for license in addition to Norges
Television. The Telenor owned company Norkring AS will then build the
network. They own most of the infrastructure that is expected to be used.
NTV has planned to distribute two multiplexes from the start; one with
public service broadcasters’ programs and one with some Pay TV
channels, the program package has, however, not been finally decided
upon. A third multiplex is planned for a later stage. Ahead of the analogue
switch-off there are currently only frequencies for three multiplexes.
The set-top box offer to the consumers will be based on re-tail, with some
kind of support from NTV to a few set-top box vendors. A specification for
Page 42 of 215
30th March 2006
the set-top box, mainly based on the NorDig (cf. below) spec., has been the
basis for discussions with some vendors, and the set-top boxes shall be
prepared for MHP services. (NorDig All transmissions will be encrypted.
The set-top box shall have one embedded CA solution, but the CA vendor
is still not decided.
Telenor Broadcast, including Satellite Broadcasting, Norkring and Canal
Digital, have promoted MHP since 2000. In 2000, Satellite Broadcasting
started developing an MHP 1.0 platform (play out) which was presented at
IBC2000. The reason for starting this development was that at the time no
playout platform with the wanted functionality was available. As a satellite
network operator Telenor wanted a multi-user playout to be also used for
cable and terrestrial. Several customers were to use the playout/ object
carousel while the broadcaster was to control its own applications. A web
interface was developed where the pilot customers could upload their
applications, and the Thor II satellite was used for distribution. The pilot
service started with seven customers, on satellite in 2001 and had MHP 1.0
(enhanced broadcast) on air until October 2003. The main aim was to
collect experience, to promote the use of an open API on interactive digital
TV and to stimulate the horizontal market and third party application
development. Telenor also started an MHP Forum in the Nordic countries
in 2002 together with broadcasters and application developers. The forum
had meetings where all the partners could discuss the use of MHP and how
to launch MHP in the TV market.
In 1998, broadcasters and network operators in the Nordic countries
started NorDig to specify a common standard IRD for the Nordic countries.
In 2000 NordigII was specified with MHP Interactive Broadcast profile, and
the Nordic broadcasters all promote MHP in DTH when the market is ready
both with set-top boxes and applications. All the broadcasters want to use
MHP in DTT when it is launched.
In late 2004 NRK started an MHP service on satellite and in spring 2005
they started a forum for development and usage of MHP together with the
other public Nordic broadcasters.
3.6.9 Spain
The current situation of digital television in Spain shows a panorama
broadly dominated by the satellite platform. In the case of the cable
platform estimations say that 60% of the TV cable clients received digital
television in 2004.
In the year 2004 the number of homes having a terrestrial digital decoder
begins to be of some importance, there is an estimation of about 130,000
homes with terrestrial digital decoders (mainly from the disappeared
QuieroTV). After the crash of the platform Quiero TV, the DTT was
restricted to the transmissions in digital of the operators that transmit free,
and to the very limited offer of the other two operators that obtained also
licenses (VeoTV and NetTV). During 2005 the Government has initiated a
set of actions in order to get ready for the analogue switch-off before 2010.
Thus, since November 2005, more than 20 free DTT channels are
available, some of them including MHP interactive services (EPG,
enhanced teletext, etc.)
The satellite technology is more extended and it has adopted faster the
digitalization process due to its lower update cost. But the growing
Page 43 of 215
30th March 2006
competition of the cable sector and a business model based on maintaining

a high entrance price, have caused a continuous descent of the clients of
this platform from the year 2001.
Although initially the cable platform deployed in Spain was analogue, the
different operators are involved in the digitalization process of their
networks to be able to transmit a greater number of channels and to
introduce other services. The big Spanish cable operators, ONO and
AUNA, concluded the year 2004 almost reaching 100% the digitalization
process. All the new clients receive digital television.
Television broadcast through a broadband connection is the latest option
incorporated in the market of digital TV. Telefónica has launched its
television service Imagenio, using ADSL technology, having at the end of
2004 about 5000 clients.
Some field trials and deployment tests (projects which include MHP
services) have been carried out; among these initiatives we can find the
projects ACTUA TV and MICROMARKETS.
ACTUA TV project (performed during 2003/04) consisted of a series of
demonstrations, carried out in diverse commercial centers, dedicated to
show to the public the technological capacities of DTT and of the MHP
interactive applications. The demonstrations were carried out in stands with
STB and iDTV. The base of the demonstrations was the programming of
TELEMADRID and laOtra, acting as an interactive portal and enhanced TV.
The project MICROMARKETS consisted of a group of tests of the
operation of DTT, framed in a project based on adding a channel to the
digital emissions of Televisió de Catalunya. This project was developed
during 2003 and 2004. The interactive contents were based on MHP
applications (including the possibility to use the return channel) offering
news tickers, weather forecast, chat, text messaging and interactive
advertisements.
The continuation of the project MICROMARKETS will be “Maresme digital”
which involves the deployment of the required infrastructure of DTT in the
area of the Maresme. This area was chosen as a first sample territory (to
be extended to other cities in the future) because of the poor signal
reception due to the complicated geography. The project has been
developed along the year 2005.
RTVE, the Spanish public broadcaster, launched initially some MHP
applications on a trial basis in November 2004, and nowadays offers on its
5 channels in DTT a set of basic MHP applications such as enhanced
teletext and an EPG.
3.6.10 Sweden
The public service broadcaster (SVT) initiated broadcasting of MHP
services on all digital platforms in 2004. These services consist of
advanced text information services. A 500 user trial will soon begin in
Gävle using the DVB-T platform to trial a MHP-based community
information service.
Page 44 of 215
30th March 2006
3.6.11 United Kingdom

Broadcasters in the United Kingdom are providing a lot of interactive
content, starting with simple enhanced applications displaying additional
information up to interactive applications which are using a return channel.
However, all these applications aren’t based on MHP but on OpenTV (Sky
Digital, BBC), MHEG-5 (terrestrial digital TV) or other platforms. The
interactive content is quite successful and the consumers are used to press
the red button for activating interactivity, e.g. in a sports bidding application.
MHP is currently only a topic for the BBC, which is doing some research
projects answering questions like, which possibilities are provided by MHP
1.0 and MHP 1.1 or how can MHEG-5 content be migrated to MHP?
However, it is most likely that the success of the available interactive
content, implemented with MHEG-5/OpenTV, and the number of devices in
the market will avoid a short term introduction of MHP services and devices
in the United Kingdom.
This legacy situation including the usage of different APIs causes a
problem for broadcasters like the BBC which deliver their services in
parallel via networks using OpenTV and networks using MHEG-5.
Interactive content therefore has to be adopted for both systems which
either means giving up optimum usage of any of the systems by using meta
formats covering both systems or having additional effort for individually
optimizing the content for each system.
3.6.12 Switzerland
In January 2006 the SRG (the swiss public broadcaster) has announced to
launch interactive services using MHP by 2007. MHP will then be used via
DVB-S and DVB-T. The SRG intends to use MHP also via DVB-C; the
swiss cable operators, however, have partly introduced OpenTV and would
like to keep this system.
One specific aspect of SRGs service concept for MHP is the support of
disabled people by the optional transmission of additional information.
Starting in March 2006 the terrestrial transmission will be migrated to DVB-
T. This process will be completed in 2009. Via satellite, SRG will open in
May 2006 a second DVB-S transponder to broadcast their programs.
HDTV is announced by SRG in 2010.
Page 45 of 215
30th March 2006
4 MHP iTV Applications NOVICE LEVEL

This chapter presents the concept of the MHP iTV applications. It also
analyses the choice of the Java programming language and the specificity
of Java in the TV context. It also gives an overview of the link between
MHP applications and the various components in the broadcast chain. iTV (Interactive
Television)
4.1 MHP application A capability in digital

TV offering interactive
An MHP application is an interactive application written in the Java- services (e.g.
programming language. The Java MHP applications are called “Xlets”; they information,
run on top of the MHP middleware. The Xlets have a specific lifecycle and communication,
transaction, etc.) often
are controlled by the broadcaster or user via the middleware. The Xlets can directly related and
be started, stopped, paused and resumed. synchronized with the
broadcast content.
4.1.1 Why Java?

Xlet
DVB has adopted the Java programming language for MHP interactive Xlet is the interface
applications and has created a lightweight version suitable for broadcast used for execution
applications called DVB-J or DVB-Java. Consensus was reached by all engine application
partners involved in DVB to adopt Java as language for MHP interactive lifecycle control in
MHP.
applications due to its maturity, quality of tools and development skills
available.
Whereas MHP is based on a subset of Personal Java 1.2, several major
elements were removed; some to save space, others because their
functionality is not needed in the TV context. Below the main changes in API (Application
MHP are listed: Programming
Interface)
Several major parts have been added in MHP, such as additional
APIs for STB-specific functions (DVB MHP API). The publicly
accessible surface of
Where the functionality needed was too different from standard Java software classes
the code was modified through which
applications operate
The UI model reflects the consumer, TV-centric model rather than the upon the specific
PC/workstation model, functions contained
within the MHP.
Changes in the core Java classes were made to save memory
space.
4.1.2 Extensions added from other standards 1

The following extensions were added from other standards:
DAVIC (Digital Audio
JavaTV API Video Council)
Contained in package javax.tv. * This API comprises: A worldwide
Xlet classes and infrastructure association of bodies
concerned to promote
Service selection interoperability in
audio visual
SI/PSI access equipment of all kinds
concentrating on
This API was standardized by Sun Microsystems:
standardized
http://java.sun.com/products/javatv/ interfaces.
1
For more details and description of each API see Annex C.
Page 46 of 215
30th March 2006
DAVIC API
Contained in package org.davic.* This API comprises:
Basic MPEG concepts
Tuning between transport streams
MPEG-2 section filtering
Resource management
Access to CA information
This API was standardized by DAVIC: http://www.davic.org
HAVi API
Contained in package org.havi.* This API comprises:
Video/graphics integration
UI widgets for consumer systems and TV screens HAVi (Home Audio
Video
Solutions forhardware restrictions related to video and graphics Interoperability)
integration on TV screen.
A vendor-neutral
This API was standardized by HAVi: http://www.havi.org/ audio-video standard
aimed specifically at
the home
entertainment
environment. HAVi
4.1.3 New TV Specific functionality allows different home
entertainment and
MHP iTV applications in a TV context needed new functionalities that had communication
to be specified in the MHP standard or to be re-used from other standards. devices to be
The section below gives a brief overview of all these functionalities. networked together
and controlled from
Service Information Access one primary device,
There are two different APIs that enable the MHP application to access the such as a PC or
television.
SI:
org.dvb.si.* a DVB specific API that provides access to all DVB-
defined tables (except the AIT).
javax.tv.service.* an API independent from the underlying
technology. It supports access to most SI data, but accessing the MPEG-2
DVB tables is harder. A digital video and
audio compression
Media Control (encoding) technique
MHP applications sometimes need to control media (video, audio, subtitles, defined by the Moving
etc.); to do that MHP has defined different APIs. Pictures Expert Group
(MPEG).
Media control can be carried out via the Java Media Framework (JMF) that
allows control over MPEG-2 media and audio media presentation
(play/pause/change content).
Additional controls for broadcast-specific functions are split across several
packages: org.davic.media.* + org.dvb.media.* + javax.tv.media.*;
TV-specific functions have been added in JMF:
Subtitles,
Scaling/positioning,
Decoder format conversion,
New content referencing method in URL format to reference DVB
services and streams (locator).
Page 47 of 215
30th March 2006
Service selection
The MHP applications can control what service is being presented on the
TV screen. For that MHP has defined two APIs:
A JavaTV service selection API (javax.tv.service.selection); this
enables the application to change the current service.
A DAVIC tuning API (org.davic.net.tuning); this supports the access
by the application to data, also on TS different from the one the
current service is in.
File System Access

To enable MHP applications to access the file system in the terminal MHP
uses the following packages:
java.io, used to access a file system; this includes DSM-CC access
and persistent file system access.
org.dvb.dsmcc, added to support DSM-CC functionalities that don’t
exist in a normal PC file system:
Stream events, Normal Play Time,
Asynchronous loading of files,
Caching hints,
Notification of object changes.
MHP has some restrictions in the file system access:
No absolute paths, these may vary between implementations.
No write access possible to a DSM-CC object carousel.
User Input
A STB usually has no keyboard: the inputs are sent to the STB via a
remote control.
The supported key codes from a remote control are defined by MHP and
HAVI; other codes may be used, but are not interoperable. A standard set
of keys is defined (e.g. arrow keys, OK, exit, digits…). MHP also defines a
separate user input event API to support exclusive key access in
org.dvb.event package (used for entering PINs, etc).
The Graphics Model

Big changes compared to Java 1.2 have been introduced to the UI library
and graphics model.
Standard AWT widgets are not available in MHP (Button…); only
lightweight components are available. As the AWT windowing model gets
changed a lot, the HAVi widgets can be used instead.
MHP applications can build their own widgets; this seems to be the most
popular choice amongst implementers and allows a more TV-centric UI
experience.
The org.dvb.ui package adds functionalities missing from other UI
extensions:
TV-specific text layout support,
Alpha compositing between planes,
Font loading for downloaded fonts.
The HAVi widget set

Page 48 of 215
30th March 2006
The org.havi.ui package includes some basic widgets:

Buttons, check-boxes and radio buttons,
Text entry fields,
Static text,
Icons,
Dialog boxes,
Animations.
It also contains higher-level concepts (like HContainer, HComponent and
others and also enables resource management for graphics-related
components).
Window management issues

There are several reasons for STBs not to have a full window manager like
a PC:
MHP has no need for all functionalities,
An MHP application cannot use an AWT frame as the top-level
component,
The HW may impose limitations not found in a PC environment.
Instead, MHP uses HScene (a HAVi replacement for frames).
HScene
An HScene solves the problems with frames the from org.havi.ui package
and implements the java.awt.container package.
HScene controls:
Which application has input focus,
How applications are laid out on screen,
Which applications currently are visible.
HScene acts as the top-level GUI component for any MHP application:
Only one HScene is allowed for every application (actually one
HScene per display device).
The application cannot see higher in AWT hierarchy than its own
HScene.
HScenes from other applications are not visible to this application.
Applications canot interfere with one another.
Page 49 of 215
30th March 2006
Frame
HScene HScene
Component HContainer Component
Component
Figure 4-1: HScene in the UI model
Display devices
A TV has different display characteristics than a PC monitor; this needed to
be included this in the display model. The HScreen class represents a
physical display device; it ties together all MPEG decoding, graphics and
backgrounds; it models the use of graphics planes in the STB hardware.
Each HScreen consists of several lower-level devices; an example
therefore is given in Figure 4-1.
Modeling graphics hardware

In MHP the interactive TV display is split into three independent layers: the
background layer, the video layer and the graphic layer, see Figure 4-2.
HAVi defines a physical device for each layer:
HbackgroundDevice used to display either a still image or a plain
color;
HvideoDevice used to present video from MPEG decoder;
HgraphicDevice used for application graphics and cursors.
All of these objects are subclasses of HscreenDevice.
Page 50 of 215
30th March 2006
HScreen
HBackgroundDevice
HVideoDevice
HGraphicDevice
Figure 4-2: Display structure
Being familiar with Java is not sufficient to develop MHP applications;

developers have to assimilate the differences in the TV environment and
the HW constraints set by STBs.
Which API for which application?

To implement information applications such as a news application or a
weather forecast application one needs to present this information in a
user-friendly way. All the graphics APIs are important in that case (HAVI,
AWT, DVB UI).
To implement an EPG the SI data must be accessed. The Service
Information contains metadata necessary to locate, tune to and display
services on a terminal. An EPG relies mainly on information displayed in
the EIT (Event Information Table), the SDT (Service Description Table) and
the BAT (Bouquet Allocation Table). Thus, to implement an EPG mainly the
APIs are needed that enable the terminal to access the SI and to tune on a
specific service. MHP has defined two APIs for that purpose:
JavaTV
Org.dvb.si
On the other hand also graphic presentation APIs are needed such as
HAVI that enable the presentation of graphics and text on the screen.
T-commerce applications need the return channel functionality. Hence, all
APIs that control the return channel are needed (org.dvb.net.rc) in addition
to all other basic ones (graphic and UI).
Generally, every type of application has its specific API requirements,
based on the functionalities needed. It is therefore important that
application developers define all specific functionalities before starting the
actual implementation.
4.2 MHP applications and the broadcast chain

To play out an application, it has to be included into the transmitted
transport stream and some additional signaling in the PSI/SI signals (cf.
chapter 10) needs to take place (AIT table). The inclusion in the transport
stream is done via an DSM-CC object carousel, which is input to a
Page 51 of 215
30th March 2006
multiplexer, where it is combined with other components in the broadcast

stream to form the final transport stream to be transmitted, see Figure 4-3.
MHP applications need the addition of AIT tables in the SI that defines the
broadcast interactive applications (specific to MHP applications) and the
behavior of the application once downloaded in the terminal. The content
and the source code of the application are broadcast using the DSM-CC
object carousel that represents a specific kind of MPEG private sections.
Once the MHP application has been received by the terminal, the
application manager (specific part of the MHP middleware) will control the
lifecycle of the application according application signaling provided by
broadcaster, or by user requests. It also handles requests from other
applications. Only the middleware can directly control the application state;
other parts of the system (other applications, user and broadcasters) can
request application state change only via the application manager.
Program Content
Playout
(Audio/Video/subtitle)
MUX
PSI/SI tables
PSI/SI
AIT
MHP Authoring &
Production tools
DSM-CC
Application
Object Network
carousel equipment
Network
Application Return channel MHP Terminal

specific
backend server
Figure 4-3 MHP applications in broadcast chain
The MHP applications can be transmitted by an external provider to

broadcaster; also the application can be signed to avoid non-signed
applications to access critical resource of the terminal. The next chapter will
present all the end-to-end broadcast chain elements.
Page 52 of 215
30th March 2006
5 MHP end-to-end architecture NOVICE LEVEL
5.1 Introduction
This chapter presents the typical architecture and infrastructure of the MHP
end-to-end chain. It also list the actors of the MHP end-to-end value chain
and their roles in this chain and presents guidelines/ recommendations for
all actors.
5.2 MHP end-to-end reference model

This section presents the MHP end-to-end system. It defines and describes
the components that contribute to the architecture and infrastructure of the
MHP end-to-end chain. The reference model is depicted in Figure 5-1; the
components are elaborated in the following sections.
Program Clock
Program A/V Data

Content Playout CA System
(1) Subtitle/Teletext (9)
PSI/SI (6)
AIT Network
MHP Authoring & Equipment
Production Tools (10)
(2) DSM-CC (7)
(Signed) Application
Object
Stream Events
Application data
(8)
Content
New firmware
Management
System (3)
Broadcast
Content
Download server Network

(4)
Application
specific backend Return Channel (12) MHP Terminal (11)
server (13)
New Root
OSD
firmware certificates
Billing Information Graphics
download (5)
Return
Smartcard Mass
Channel
Billing System (9) Storage
(12)
(14)
Keys
MHP Specific Non MHP Specific
Figure 5-1: MHP E2E Reference Model
Page 53 of 215
30th March 2006
5.2.1 Program Content Playout

Program Content Playout (1) is not specific to MHP systems.
Program Content Playout is a function needed in most broadcast networks
regardless of MHP. Program content is sent from a content provider to the
broadcast system; here it enters the Program Content Playout that feeds it
to the Network Equipment (10). The actual implementation of this
component is dependent on the format of the Program Content when it
enters a particular system. Typically the Program Content Playout is
implemented as video servers that store and play out content streams or as
encoders that convert uncompressed source material into a DVB compliant
transport stream.
The main issue in this context is that the component can extract the
program clock reference from the Program Content and that the content
playout can be synchronized to the rest of the broadcast system.
5.2.2 MHP Application Authoring & Production Tools

Creation and broadcasting of an MHP application (2) can be divided in 2
steps:
Authoring/Developing of MHP application
Signing and creation of broadcast data
Systems deployed to realize these steps, could be linked to a Content
Management System (CMS) that manages the content handled by MHP
applications (cf. next section).
5.2.3 Content Management System (CMS)

A CMS (3) is a system that separates the content from the framework
(layout, design, logic). It is a system that supports the creation,
management, publishing and distribution of combined information. A CMS
provides the possibility to create or pre-process (improve) existing data.
Within the MHP E2E architecture, the CMS (3) would be responsible for
content generation and content delivery.
Firmware
5.2.4 Download server & firmware upgrade The software that is

embedded onto a
Download server (4) & firmware upgrade process are not specific to MHP piece of hardware in
systems. order to control that
A download server provides necessary software utilities to prepare a hardware device.
system software binary image file for any target digital broadcast receiving
device.
Receiver manufacturers who want to upgrade firmware of their already
deployed receivers provide software binary image files to the appropriate
broadcaster or network operator who allocates specific bandwidth for this DVB-SSU
purpose.
DVB System
Each time a new firmware update is broadcasted, the MHP terminal is able Software Update
to move in a special operational mode in order to receive and upgrade its
firmware.
Page 54 of 215
30th March 2006
Broadcast format of a new firmware update depends on both MHP terminal

manufacturers and broadcasters but generally the DVB-SSU specification
is followed [MHP 1.0.2; MHP 1.0.3].
5.2.5 Public Key Infrastructure MHP PKI

The DVB MHP PKI relies on the integrity of certificates that verify the
identity of the entity that has signed an application’s file tree. The highest-
level certificate, known as the “root certificate” is embedded into each MHP
receiver by its manufacturer, and this is used to authenticate a certificate at PKI
the next level in the hierarchy. This authentication process is repeated A system that enables
users of a public
through each level of the certificate hierarchy until a leaf (or end-entity)
network to exchange
certificate is encountered and authenticated. Thus users can be sure that data securely and
application has not been modified and is only using the intended resources. privately through the
use of a public and
private cryptographic
5.2.6 PSI/SI key pair that is
obtained and shared
PSI/SI (6) are not specific to MHP systems, but an additional table (AIT) is through a trusted
defined for MHP systems. authority.
Video, audio and other data are all interleaved (multiplexed) when
transmitted on a single Transport Stream (TS). Within the DVB standards
of distributions these separate sources of data are identified with a unique
packet identifier (PID). In order to navigate between all PIDs received by a Transport Stream
client, the PSI/SI set of tables is used as a table of contents. Further, the A multiplex of
tables provide descriptions of the content available. Because of the several program
broadcast nature of the TS, tables have pre-defined minimum repetition streams that are
intervals during broadcast to ensure a maximum access time. carried in packets.
Program Specific Information (PSI) is defined as part of the MPEG-2
standard. PSI defines four different tables, including Private tables. The
remaining three table definitions are:
Program Allocation Table (PAT), which can be considered the root of
a hierarchical structure of television programs;
Program Map Table (PMT), defines the individual components of a
single program and
Conditional Access Table (CAT), indicating conditional access (CA)
properties for any CA system utilized by programs within this TS.
The PAT and CAT table have fixed positions within the TS, while all PMTs
are referenced in the PAT.
Service Information (SI) is an addition to the PSI specification. Defined by
the DVB, it is also referred to as DVB-SI. It defines a series of mandatory
and optional tables, providing both extra information about the data in the
TS and information relating to external data and properties of the TS. The
mandatory tables are
Network Information Table (NIT), containing physical properties of
this and possibly other TS
Service Description Table (SDT), giving extra information on DVB-
services, comparable to MPEG-2 programs
Event Information Table (EIT), distributing event information for DVB-
services, comparable to program information for television channels.
Updates of the EIT should be synchronized to the actual content
Page 55 of 215
30th March 2006
being played out in the program content playout (1) component, but
in many operational systems this may not be the case at all times.
Time and Date Table (TDT), broadcasting time to the MHP Terminal
The optional tables are

Bouquet Association Table (BAT), provides logical grouping of
services across TS;
Running Status Table (RST), sent only once to update the client of a
status change;
Time Offset Table (TOT) and
Stuffing Tables (ST).
There are optional variations of all the mandatory tables. All tables except
ST are anchored at fixed positions in the TS and can be accessed without
parsing other tables first.
Part of the DVB-MHP specification is the Application Information Table
(AIT). Although not part of the PSI/SI set of tables, the table is referenced
from one or more PMTs. The AIT contains information about the available
applications within a given service.
5.2.7 DSM-CC
MHP applications, data and events are broadcasted using a DSM-CC
playout system (7). The application and data are sent on an object DSM-CC (Digital
carousel, while events are sent as stream events. Storage Media
Command and
22 Control)
5.2.7.1 DSM-CC Files and Directories
A format for
DSM-CC offers, among other things, a mechanism to broadcast objects transmission of data
(like files and directories) in a carousel-like fashion. and control
information in an
A DSM-CC object carousel consists of three layers. At the top layer (called MPEG-2 private
the object carousel layer), the DSM-CC User-to-User objects (like files and section.
directories) are visible. These objects are transported in so-called modules.
These modules represent the middle layer and this layer is called the data
carousel layer. At this layer, the modules are just a container for data. The
User-to-User objects are not interpreted here; this is done at the top layer.
The modules are broadcast as a sequence of DownloadDataBlocks, which
are MPEG-2 private sections with added semantics. These
DownloadDataBlocks form the lowest layer.
DAVIC has specified how to refer to DSM-CC UU objects using java.io: it is
the same way MHEG refers to those objects. The MHP specification has
included this part of DAVIC and thus also uses java.io to access files and
directories in a DSM-CC object carousel.
5.2.7.2 DSM-CC Stream Events

Interactive applications sometimes require synchronization with TV
programs. A quiz show is a good example. During this show, the
22
This section is a slightly adapted copy of chapter 12 from: Report on ongoing standardization efforts,
Deliverable #15, SMASH, by Ivar Miljeteig and Ronald M. Tol.
http://www.extra.research.philips.com/euprojects/smash/deliver/del15/del15.pdf
Page 56 of 215
30th March 2006
quizmaster asks a lot of questions. Certainly, the interactive application has

to be synchronized with the running program, to ensure that the display and
the duration of the question is the same as for the live viewer. This requires
an MHP trigger at the precise time to make the applications react.
Stream Events (SE) (8) are markers embedded in the Transport stream
(TS) as private section. The TS must also contain an object carousel (OC)
which contains at least one stream event object. This object identifies the
matching event.
Within a stream event information (text, digits) can be transmitted. It
provides for a real time data transmission.
There are two types of Stream Events (SE). Those are:
“Do it now” event – the event is triggered immediately (as soon as
possible) without time preferences
“Scheduled events” – is depending on a time reference (NPT), when
the time is reached the event is triggered. The NPT is a frame
accurate media time defined by DSM-CC and reconstructed from
PCR information present in the MPEG-2 stream.
Scheduled events offer more precision at the cost of increased complexity.
The link between Program Content Playout (1) and DSM-CC (7) is only
needed if scheduled events (8) are implemented.
In MHP KDB Project, this topic is investigated by the Signal Focus group.
5.2.8 Conditional Access System

The Conditional Access System (9) is not specific to MHP systems.
CAS
CW SAS
generator EMM
generator
DVB SMS
scrambler ECM EMM
generator injector
Figure 5-2: Detailed view of Conditional Access System

VOD (Video On
It is an optional part. MHP broadcast may be clear and free-to-air. Demand)
The viewer pays a
A Conditional Access System (CAS) is used to control the access to small fee to the
program content on most platforms including MHP. The CA systems are television service
proprietary, but the basic components are the same. A Control Word (CW) provider in order to
watch particular
generator generates a CW, which is used to scramble the program content.
movies listed on the
The CW is also used to generate an Entitlement Control Message (ECM) in on-screen television
an ECM generator, which is located in the Subscriber Management System menu. Similar to pay-
(SMS) server. The ECM is related to the program content and holds the per-view.
access criteria. The ECM is used for recovering the CW in the MHP
Terminal. On request from the SMS the Entitlement Management Message
(EMM) generator in the Subscriber Authorization System (SAS) server
Page 57 of 215
30th March 2006
generates an EMM. The EMM holds information about the access

status/entitlements of the user. The EMM is usually broadcasted in the
transport stream, but could also be sent to the MHP Terminal over the
return channel for instance when buying VOD movies. When the EMM is
sent over the return channel an (MHP) application have to feed the EMM to
the CA subsystem (Smart Card) in the MHP Terminal.
5.2.9 Network Equipment

The network equipment (10) is not specific to MHP systems.
The network equipment consists of the multiplexers and network adapters
needed for the particular network type that is used (terrestrial, cable and
satellite). In a real system some of the functions described in the preceding
sections may actually be performed in this box, e.g. some of the PSI/SI (6)
is often generated by the multiplexer.
From a high-level perspective this component should be irrelevant when
implementing MHP applications.
5.2.10 MHP terminal

The MHP terminal (11) (e.g. a set top box) is the actual device that
executes the MHP applications. It is the MHP terminal that presents the
applications to the user, and it is through the MHP terminal that the user
interacts with the system.
The MHP terminal can interact with third party devices, usually smartcards
(11.1), through a common interface slot. The MHP terminal can also use
what is commonly referred to as the return channel (11.2) to interact with
external systems.
Mass storage devices (11.3) such as hard drives and DVD writers will most
likely be more and more common. This storage can be utilized to store both
content and applications.
The on-screen graphic display (11.4) is maybe the most basic component
of a MHP terminal. The OSD graphic is the part of the MHP terminal that
generates the visual representation of an application. The OSD graphic is xDSL
either placed on top of the video, it may be blended with the video creating Refers collectively to
a transparent look or it may cover the entire screen. Most applications will all types of digital
subscriber lines, the
use the OSD. two main categories
being ADSL and
SDSL. Two other
5.2.11 Return Channel types of xDSL
An important component in the E2E architecture is the return channel (12). technologies are High-
data-rate DSL (HDSL)
It adds the real interactivity to the whole system. The return channel can be and Very high DSL
classified with regard to the available technologies and with regard to the (VDSL).
way how applications use the return channel.
An MHP application typically uses a return channel for having a bi-
directional IP link between the MHP receiver and application servers. DVB-RCS
These servers are application specific and can have an interface to the DVB return channel
billing system (14), which is operator specific. by satellite.
With a PSTN modem it is also possible to make drop calls. This can be
used by very basic applications, like voting, where only one-way
interactivity is needed. In that situation, the MHP receiver just calls a
number. The semantics of the user’s response is bind on the dialed phone
Page 58 of 215
30th March 2006
number itself. On the server side in order to collect users’ responses, it is

sufficient to answer the phone call and immediately after drop it without
setting up an IP connection.
From technical point of view the return channels can be divided in wired
interaction channels and mobile interaction channels. For each category,
there are connections that are temporary and connections that are “always
on”. Euro-DOCSIS
Currently, most MHP terminals with a return channel use a built-in PSTN Adaptation of DOCSIS
modem. An advantage of this return channel type is that PSTN is widely to European cable
available. Some disadvantages are that a time-consuming connection set networks. DOCSIS is
a standard for
up phase is needed; the phone line is busy; in most European countries delivering data over
one has to pay per time unit so connection time should be kept as small as cable TV systems,
possible. More advanced wired interaction channels use broadband return typically for subscriber
channels standards as Euro-DOCSIS, xDSL or FTTH, which are always on. Internet access
services.
The special modem needed for these broadband channels can be installed
in the receiver or the receiver can be connected with a home gateway by
Ethernet (wired or wireless (WiFi)) or by USB.
FTTH (Fiber-To-The-
Mobile interaction channels are less common at the moment. The main Home):
technologies in this area are the GSM modem, which is in use comparable The installation of
with a PSTN modem and a GPRS connection, which is in use comparable Optical fiber from a
with ADSL and 3G technology (UMTS). telephone switch
directly into the
Another option is using the satellite as return channel. A common standard subscriber’s home.
here is DVB-RCS.
5.2.12 Application specific backend servers

The application specific backend servers (13) are probably the least
standardized area of the E2E architecture. This follows naturally from the
fact that they are application specific. This also makes it more complicated
to give a general description of what they are since they are application
dependent.
Some applications need to access or store information in a central
repository; this storage may be implemented as an application specific
backend server (13). The MHP terminal (11) communicates with the
backend servers using the return channel (12). The backend server may
respond either through the return channel or through the broadcast stream.
As the backend server has much more resources than the MHP terminal it
is often a good design choice to put as much as possible of the application
logic into the backend server. The backend server may access other
systems to perform the requested operations on behalf of the MHP
terminal.
5.3 Actors of the MHP end-to-end system and their

roles
This section presents the main roles that actors of the end-to-end chain can
play and it highlights their scope and concerns. Table 5-1: Elucidation of
actors in the MHP end-to-end reference model
Table 5-1 gives an overview of how the actors relate to the various
components in the chain as presented in section 5.2. The identifiers in the
table refer to Figure 5-1.
Page 59 of 215
30th March 2006
Identifier End-to-end system Main actors involved

component
1 Program Content Playout Service provider

Broadcaster
2 MHP Application Application developer

Authoring & Production Authoring tool vendor
Tools
3 Content Management Application developer

System Service provider
4 Download Server Broadcaster MHP

terminal vendor
5 Public Key Infrastructure Application developer

MHP PKI Broadcaster
MHP terminal vendor
DVB Services SARL
6 SI/PSI Service provider

Broadcaster
7 DSM-CC Broadcaster MHP

Playout vendor
8 Stream Events Broadcaster

Service provider
Application developer
9 Conditional Access CAS provider

System (CAS) Broadcaster
MHP terminal vendor
10 Network Equipment Broadcaster

Network operator
11 MHP Terminal MHP terminal vendor

End-User
12 Return Channel ISP

Backend operator
MHP terminal vendor
13 Application Specific Application developer

Backend Server Broadcaster
Backend operator
14 Billing System Application developer

Broadcaster
Backend operator
Table 5-1: Elucidation of actors in the MHP end-to-end reference model
Page 60 of 215
30th March 2006
It shall be noted that, in the broadcasting environment, many actors play

more than one role in the end-to-end system. The actors are addressed in
more detail in the following sections.
5.3.1 MHP authoring tool vendor

The MHP authoring tool vendor provides tools aimed at application
developers to ease the creation and development of MHP interactive TV
applications. Some tools allow analyzing and testing applications; some
also enable to sign applications.
5.3.2 MHP application developer

MHP application developers are the creators and providers of the code of
MHP interactive TV applications. The application developers may use MHP
authoring tools or may develop directly in java code, with standard java
development tools.
The MHP Knowledge Project provides a number of open source code
samples that the MHP application developers can re-use.
It is interesting to see that anybody could write MHP applications because
MHP is a standard and its APIs are public.
5.3.3 MHP service provider

It is currently a bit tricky to define the exact role of an MHP service provider
in the iTV production chain. There is no accurate definition analogue to
ISPs in the Internet world mostly due to the fact that MHP services are not
as established as web services are. At the moment broadcasters are often
also the service providers.
The most appropriate description probably is that MHP service providers
are delivering a service to the iTV user. They might do the MHP
programming and maintain the interactive services, they might host a back-
end system, they may have a play-out system and they have often a billing
system.
As stated before it is difficult to draw the line between application
developers on the one side and to the broadcasters on the other side.
5.3.4 Broadcaster
To define the role of the broadcaster in the end-to-end chain is not an easy
task, mainly because the term is commonly used for entities that cover
many different roles in the chain. Some, for instance, are at the same time
content provider, application developer, service provider and actual
broadcasters.
Though the word is often used metonymically for all these roles, in this
chapter it will stand for those actors responsible for the act of transmitting
media, including the management and maintenance of the DSMCC object
carousel and multiplexing.
Most MHP based services in Europe are provided by Public Service
Broadcasters.
Page 61 of 215
30th March 2006
For more detailed information on the European market, cf. MHP-KDB

deliverable D1 “Analysis of the Current Situation” under
http://www.mhpkdb.org/publ/mhp-kdb_d1-ver-2.pdf.
5.3.5 Network operator

The network operator may have the role of a pure infrastructure operator
starting with multiplexers, adding access rights in a CA-system, modulating
the TS and sending the RF signal on air either in a DTT network or on
satellite. A cable operator will start with a headend for remultiplexing of the
received programs and then distribute to their customers.
In some cases the network operator also will offer playout of applications
using a multi-user playout platform, where the broadcasters, T-commerce
actors, information and betting companies may upload their applications.
5.3.6 MHP playout vendor

A playout vendor will support the E2E system with Application server,
PSI/SI generator, DSM-CC Object carousel and it may include Authoring
and Production tools.
5.3.7 CAS provider

The CAS providers are actors of the iTV broadcasting end-to-end chain not
specific to MHP. They provide the Conditional Access System that is used
by the service providers and broadcasters to securely deploy pay-TV ISP (Internet Service
services and protect the TV content with secure technologies, most often Provider)
by involving smart cards. A company that sells
Internet services to
See section 8.7 for a description of the CAS. the public.
5.3.8 ISP NAT (Network

In the current system, the role of the Internet Service Provider (ISP) is Address Translation)
limited to providing the IP-connectivity between the MHP-terminal and the An Internet standard
IP-network. If applications use the return channel, the ISP manages and that enables a local-
controls this return channel. Multiple models exist for return channel area network (LAN) to
use one set of IP-
connectivity (bridging, PPPoX, etc.). For some systems, the MHP-terminal
addresses for internal
will need to implement the matching protocol to establish this IP- traffic and a second
connectivity. set of addresses for
external traffic.
The use of Network Address Translation (NAT) and firewalls might also
pose problems when using the return channel. NATs and firewalls are not
necessarily under control of the ISP, as also the customer uses these types
of devices. It is recommended to write MHP-applications in such a way that
they are NAT and firewall traversal friendly.
In alternative architectures, the broadcast channel is also transported over
this IP-network. This means that also the MHP-application itself is
transported over this IP network. This introduces new problems as the ISP
is now involved in the broadcasting side as well. Tight security mechanisms
need to be put in place to control access to the MHP-terminals.
Page 62 of 215
30th March 2006
5.3.9 MHP Backend operator

The MHP Backend operator is involved in different aspects of the E2E
system. The backend operator needs to connect to the IP-network, as this
is the point where information originating from the MHP-receiver is received
back by the operator. As this is an interface towards the public IP-network,
care must be taken for the security and scalability of this interface and
servers. Especially for applications in which financial gains or confidential
data is exchanged, this interface and the servers are a very critical
component of the system.
The exact functionality of the backend server depends on the applications.
It can be assumed that there will be one backend server (or server
functionality) for each (interactive) application in the network. Depending on
the functionality the backend server needs to interface to the content
management system to dynamically update content on the broadcast
system.
As a third role, the backend server needs to interface to the billing system.
Typically this is a proprietary interface. The exact functionality depends on
the applications and the business model behind the application. E.g. for
betting games, the backend server needs to make sure the payment
information is correctly transferred to the billing system. Note that it might
also be necessary to have information flowing from the billing system to the
backend server. In the case of betting, it will be the billing system that
verifies the payment information.
5.3.10 MHP terminal vendor

The MHP terminal vendors are the providers of MHP terminals (iDTV, STB
and PC) compliant with DVB MHP specification and hence carrying the
MHP logo, proof that the DVB MHP test suite has been successfully
passed.
The MHP terminal vendors may use their own MHP software stack or may
integrate software from external MHP stack providers.
In the iTV context, MHP terminal vendors are often referred to as
manufacturers.
5.3.11 DVB Services SARL

DVB Services Sàrl is a limited liability company governed by the Swiss Civil
Code and by its Statutes established with the aim of providing certification
authority and all other related services to broadcasters, manufacturers, and
entities. The main associate of DVB Services Sàrl is the DVB Project. The
registered office of DVB Services Sàrl is the registered office of the
European Broadcasting Union in Geneva, Switzerland
The DVB Services SARL plays a key role in the security of MHP iTV
applications.
See http://www.dvbservices.org/.
Page 63 of 215
30th March 2006
5.3.12 MHP Certification Authority

The MHP Certification Authority provides a Public Key Infrastructure for
MHP, called MHP PKI. The Infrastructure provides the backbone for
authenticating applications and files that are broadcast to an MHP receiver.
This authentication process is designed to ensure that application code has
not been modified from that originally developed by its author, is permitted
to execute on devices connected to the broadcast network, and that the
application only accesses the set of restricted resources that it has been
authorized to access.
5.3.13 End-user
The end-user is the owner of an MHP terminal, installed in its home
PSTN (Public
environment, usually the living room. It has to be taken into account that
Switched Telephone
potential users of interactive TV do not necessarily have PC knowledge Network)
and the user interface is limited to the remote control buttons and the low
The international
resolution of the TV screen. telephone system
Return channel can only be used if the MHP terminal is connected to a based on copper
wires carrying analog
PSTN or Internet. As this has to be done by the end-user and is thus not voice data.
guaranteed, every application has to ensure proper function in case the
return channel is not available.
Among the main concerns of the end-user are the ease of use, loading
time, reactivity, speed, graphics, video and audio performance of the
interactive applications.
5.3.14 MHP SW stack provider

The MHP SW stack provider is a software vendor who licenses an MHP
stack implementation to an MHP terminal vendor.
Page 64 of 215
30th March 2006
6 Organization of the MHP knowledge

The MHP-KDB project tackles one of the most pressing issues in the field
MHP-KDB
of digital interactive television: the harmonized usage and implementation
(Multimedia Home
of DVB-MHP by establishing a single “point of call” for all MHP-related Platform –
technical issues: the MHP Knowledge Database. In short the so called Knowledge
MHP-KDB contains the know-how and best practice solutions for all DataBase)
companies and organizations active in this field. EU co-funded IST
The prime focus of MHP-KDB is to improve the interoperability of MHP project (lifetime:
December 2003 –
implementations and MHP applications. March 2006) that
The MHP-KDB project has identified more than one hundred issues to be established a public
database for all
published in the database that are regarded as being crucial for MHP relevant MHP issues
application development. These issues deal with important topics all along and a virtual test
the MHP end-to-end architecture (cf. chapter 5). These issues can be centre for checking
allocated to following categories: MHP applications.
www.mhpkdb.org
1. Basic Architecture
2. Broadcast Protocols
3. Application Lifecycle
4. Application Signaling
5. Security
6. Graphics, Audio and Video
7. Text Presentation
8. Return Channel
9. Equipment
10. Usability
11. Other aspects
Beside some general Basic Architecture (Chapter 7) issues, this chapter

handles scarce resources of MHP terminals and the two kinds of MHP
applications, DVB-J and DVB-HTML.
The category Broadcast Protocols (Chapter 8) looks at DSM-CC stream
events related issues, both, from the play-out side and the terminal side. It
also addresses topics such as section filtering, SI and service selection.
The Application Lifecycle focus area (Chapter 9) deals with a range of
aspects and issues that are essential for the optimum deployment of MHP
applications.
The Application Signaling area (Chapter 10) takes a look at signaling and
lifecycle control of broadcast applications with the AIT table.
The focus area on Security (Chapter 11) covers issues regarding
certification, signing and MHP Security in general.
Displaying Graphics, Audio and Video (Chapter 12) comes along with
several problems that are tackled in this category. The concept of layers
and composition is explained. Additionally, Text Presentation issues such
as using and generating fonts as well as the use of external fonts are
addressed.
Page 65 of 215
30th March 2006
The focus area on Return Channel (Chapter 13) covers issues regarding
the communication based on the return channel offered in the interactive
broadcast and Internet access profiles,.
The Equipment focus (Chapter 14) mainly addresses aspects of authoring
tools and play-out systems.
The Usability focus (Chapter 0) area deals with all aspects regarding man-
machine-interaction in MHP. It gives an outlook what an MHP designer has
to consider with regard to layout, navigation and the presentation of text
and images.
Other aspects deal with any other issue that cannot be allocated to one of
the before mentioned focus groups.
The following figure shows where in the end-to-end MHP architecture the
categories can be located.
Figure 6-1: Mapping of the MHP-KDB Categories in the MHP End-to-End Reference Model
Page 66 of 215
30th March 2006
7 Basic Architecture
7.1 Introduction
MHP applications can be classified into two types:
DVB-J: DVB-J (DVB-Java) applications are written in Java using the
MHP API. Basic Architecture
DVB-HTML: applications which depend on an implemented
conformant browser.
However, the latter variant is to date not used or deployed.
Applications have to be designed to meet the specific constraints of the
terminal (and playout) architecture. Only a fixed subset of JAVA / HTML is
available, many functions for advanced data processing and storage have
been cut down to a minimum. Usually only one application at a time will be
visible on the screen. It may have to share the user’s attention with the
running TV program, but not with another application. Scarce resources
play a vital role in application development, as in an MHP terminal virtually
any resource is scarce, restricting access to one application at a time. The
installation and start procedure for applications is designed to work fully
automatically, without user interference. MHP applications must not crash.
This chapter will outline the basic principles and constraints of DVB-J,
general issues about dealing with scarce resources and about migrating to
higher versions of the MHP standard, which may result in changes to the
DVB-J definition.
7.2 DVB-J NOVICE LEVEL
7.2.1 Introduction
DVB-J (DVB-Java) applications are written in Java using the MHP API set
DVB-J (DVB-Java)
and consist of a set of class files that are broadcast with a service. DVB-
Java applications are known as "Xlets". This is a concept similar to applets DVB-J applications
are written in Java
for Web pages that have been introduced by Sun in the JavaTV using the MHP API
specification. Like applets, the Xlet (cf. 9.2 Xlet Application) interface set and consist of a
requires an external source (the application manager in the case of an set of class files that
MHP receiver) to start and stop an application. are broadcast with a
service.
7.2.2 DVB-J Constraints

MHP 1.0.x is based on the PersonalJAE specification 23 . PersonalJAE is
short for PersonalJava Application Environment Version and in the
Xlet
following section referred to as PersonalJava. PersonalJava is a Java
software development platform for mobile and embedded systems. It has DVB-Java
applications are
been superseded by the J2ME CDC and CLDC, but still exists in many known as "Xlets".
products.
PersonalJava is closely equivalent to Java 1.1.8 regarding the libraries and
features it contains. This means that application developers are not allowed
23
Part of ISBN: 1-892488-25-6. The OEM PersonalJava Application Environment
Version 1.2a specification - http://java.sun.com/products/specformhp
Page 67 of 215
30th March 2006
to use java classes and methods form later Java Software Development
Kits (SDKs). CDC (Connected
Device
Modern development tools such as Eclipse (http://www.eclipse.org/) have
Configuration)
features for method auto completion and real-time syntax check. These
features use the code libraries to operate. So by specifying correct MHP A Java profile for
mobile Devices that
class libraries and API documentation in such tools, developers are forced aims towards J2SE
to use correct methods and objects. compliance with
moderate resource
The MHP Knowledge database provides APIs and stub libraries developers requirements. For low
can use for this purpose. Further information can be found in Annex B. performance devices
the Connected Limited
DVB-J is an environment different from desktop PCs and this different Device Configuration
environment causes deviations in the Java environment when compared to (CLDC) is available as
PersonalJava. One example: the MHP specification Version 1.0.3 24 chapter a subset of CDC.
11.2.1 states “Each DVB-J application instance is considered to logically
run in its own virtual machine instance”. This fact has consequences for the
usage of finalizers. Chapter 11 of the MHP specification Version 1.0.3
specified in details deviations from PersonalJava including classes not
required and deviations in functionality and methods.
MHP 1.1.x continues to refer to PersonalJava and not the subsequent
specification Connected Device Configuration (CDC).
The classes used for MHP must be delivered in the Java 1.1.x compatible
format 25 . Compilers provided by SUN in subsequent Java SDKs are
capable of outputting class files that are Java 1.1.x compatible. This is
done by using the compiler parameters source and target. E.g.:
javac -source 1.2 -target 1.1 <source files>
It is important to remove the standard java API from projects to prevent that
objects that are not part of the MHP Specification are referenced and later
failing when executed in an MHP environment. DVB-HTML
DVB-HTML
applications are a set
7.3 DVB-HTML of HTML pages that
are broadcast as part
DVB-HTML is not very popular now, partly because the specification for of a service. The
DVB-HTML was only completed with MHP 1.1 and partly because many specification is based
broadcasters, terminal manufacturers and content developers find it too around a modularized
complex and difficult to implement. DVB-HTML applications are a set of version of XHTML 1.1,
and also includes
HTML pages that are broadcast as part of a service. The spec is based CSS 2.0, DOM 2.0,
around a modularized version of XHTML 1.1 and also includes CSS 2.0, and ECMAScript.
DOM 2.0 and ECMAScript. Up to date there is no test suite available for
DVB-HTML, so the DVB-HTML support in MHP terminals cannot be
certified.
24
ETSI ES 201 812 V1.1.1 - http://pda.etsi.org/pda/home.asp?wki_id=NQi7pkU'e9@_22@@TK7My
25
The Java VM Specification section 4.1 states that the version numbers encoded in the class files are defined by
Sun, and that 1.0.2 supports class file format versions 45.0 through 45.3 inclusive; 1.1.X can support class file
formats of versions in the range 45.0 through 45.65535 inclusive; and 1.2 of the Java 2 platform can support
class file formats of versions in the range 45.0 through 46.0 inclusive.
There are several tools available for presenting information about java class files including version number.
One example is Class editor http://sourceforge.net/projects/classeditor/
Page 68 of 215
30th March 2006
7.4 Principle of scarce resources

Generally, MHP terminals offer only limited resources for applications.
Thus, these resources must be shared in a very efficient way between the
terminal middleware and concurrent MHP applications. Accordingly,
effective resource management is a crucial aspect for decoder developers
and MHP application programmers who tackle this issue frequently in the
MHP APIs.
7.4.1 Memory
It is mainly to save costs why many MHP terminals tend to have rather little
memory. The MHP standard does not directly mandate a minimum memory
size, but names a number of short test procedures the terminal has to
pass. From these procedures a minimum memory requirement of estimated
4 megabytes can be derived. Luckily most terminals on the market have
more memory, still it can be considered as a scarce resource. Unlike other
scarce resources the memory cannot be blocked by just one application,
but the amount and size of concurrently running applications influences the
overall box performance.
Managing Memory as a scarce resource

There are three major rules for efficient memory use on MHP terminals:
Adhere to the Xlet application lifecycle model and send temporary
inactive applications into the “paused” mode to free memory.
Avoid very large files such as large images and long audio files.
Mark applications as “service bound” and ensure that not too many
applications are allowed to run concurrently on the same service.
In general, MHP terminals are not built for real multitasking. Only one
application should be active and visible on the screen at any given time.
Further applications, like a general portal application, may run in paused
mode in the background to get restarted when the user decides to leave
the current application. The paused mode was introduced to keep
applications running in the background in a kind of hibernate mode with
very little resource usage. When an application is sent to pause mode, all
memory consuming objects, like images, should be destroyed, whereas
they will be built up again when the application is restarted. This way,
applications that are used frequently have to be loaded from the object
carousel only once while the user is viewing the current service.
It may happen that there is not enough memory available to start further
applications. In this case the MHP terminal may reject any try to do so.
However the way the terminal reacts is implementation specific.
The valid applications for a service are listed the Application Information
Table (AIT). It is important to make sure that these applications could run
simultaneously on the minimum MHP terminal configuration that is going to
be used to consume this service.
7.4.2 Persistent storage NOVICE LEVEL

The MHP environment allows authorized applications to use an area of the
local file system for persistent storage. Such signed applications that have
Page 69 of 215
30th March 2006
been granted file access permission are able to read, write and delete files
on a persistent area of the device memory.
To signal a signed application the application id value must be in the range Range of app_ID
of 0x4000 to 0x7FFF. Otherwise, the permissions for file access cannot be
More details about the
granted. By default, signed applications have access to the same values range for
resources as unsigned applications. Signed applications can request application_id can be
additional permissions through the use of a signed "Permission Request found in section
File". The permission request file is an XML file conforming to the DTD 10.5.1 Encoding [MHP
1.0.3].
described in section 12.6.2 Permission request file [MHP 1.0.3]. This file
must reside in the same folder as the main class of your application, and is
named with the following format: dvb.<application name>.perm where
“application name” is the fully qualified class name of the initial class for the
application. (e.g. “org.mhpkdb.app.MainClass”)
Each element in the permission request file corresponds to a specific
resource requested for the application. From an application standpoint,
permissions are represented by subclasses of
java.security.Permission. Each subclass represents a different
resource that an application must gain permission to access. The
permission class representing the persistent storage is
java.io.FilePermission.
The file access request in the permission file would look like <file
EXPERT LEVEL
value=”true”></file>. Below is an example of requesting access to use
the persistent storage. The permission file would contain the following
contents:
<?xml version="1.0"?>
<!DOCTYPE permissionrequestfile PUBLIC "-//DVB//DTD Permission Request File
1.0//EN" "http://www.dvb.org/mhp/dtd/permissionrequestfile-1-0.dtd">
<permissionrequestfile orgid=0x00499602d3 appid="0x4002">
<file value=”true”>
</file>
</permissionrequestfile>
If permission is granted, the application is able to use the java.io package

to interact with the local file system. Buffered in- and output has to be
preferred during file access.
As long as there is no standardized signing procedure, MHP terminals may
behave differently when an application tries to access the persistent
storage. Tests in the laboratory show highest interoperability under
following conditions:
Application id must be in the range of 0x4000 to 0x7FFF.
Access persistent storage without permission check.
Page 70 of 215
30th March 2006
The root of the persistent storage area can be retrieved from the
dvb.persistent.root system property. Applications are constrained to
this directory and its subdirectories. Trying to access its parent directory will
result in a java.lang.SecurityException being thrown. Applications
have read-only access to this directory.
The MHP implementation will automatically create the following
subdirectories for each application under the persistent root directory:
<organization_id>
<organization_id>+<file.seperator>+<application_id>
The organization_id and application_id values are hexadecimal text

encoding (without leading zeros) of the values specified in the AIT. These
can be retrieved from the XletContext using the getXletProperty
method with parameters of dvb.org.id and dvb.app.id respectively.
The persistent root directory is not the root of the file system on the STB,
but the directory the STB reserved for persistent storage.
The file separator value can be retrieved from the system properties.
According to section 11.3.1.1 [MHP 1.0.3] the following properties are
required to be supported for java.lang.System.getProperty():
file.separator
path.separator
line.separator
dvb.persistent.root
StringBuffer sBuffer = new StringBuffer();
// Create a new file name (including complete path).
sBuffer.append(System.getProperty("dvb.persistent.root"));
sBuffer.append(System.getProperty("file.separator"));
sBuffer.append(xletContext.getXletProperty("dvb.org.id"));
sBuffer.append(xletContext.getXletProperty("dvb.app.id"));
sBuffer.append("testFile.txt");
// Creating a new file object.
java.io.File testFile = new java.io.File(sBuffer.toString());
Page 71 of 215
30th March 2006
The organization directory is owned by the platform and shall have

organization read / write access and world read access. The application
directory is owned by the application and has application read / write
access, but no access for other applications unless explicitly granted by the
owning application. Below is an example of referencing a file in the
application directory. This example assumes that the application is signed
and has been granted access to persistent storage.
Applications can specify attributes (expiration date, priority, and
permissions) for a particular file using the org.dvb.io.persistent.
FileAttributes class. These attributes are used to control access to a file
and control the lifecycle of a file.
The following listing shows how to set permissions and how to check them.
Here the file obtains the read and write permission. The permissions “read”,
“write”, “delete” and “execute” for a file are the standard permissions given
by the Java API. The parameter is always a comma-separated string
containing no white spaces.
java.io.FilePermission testPermission =
new java.io.FilePermission(sBuffer.toString(), "read,write");
try{
java.security.AccessController.checkPermission(testPermission);
}catch(AccessControlException ace){
System.out.println("checkPermission throws: " + ace);
Although checkPermission() appeared with Java 1.2 the first time, it is

already part of the MHP API. The file access itself works like described for
Java 1.1.8.
The persistent storage is actually not persistent. Some rules are defined in
the MHP specification when files in the persistent storage will be removed:
There is not enough free persistent storage available to satisfy the
persistent storage needs of a running application.
The file stored in persistent storage expires.
The file is cleared (i.e. deleted) by the creating application or an
application with appropriate permissions.
The file is cleared as a result of an explicit request by the end user.
The persistent storage used by MHP applications exceeds 75% of its
overall size.
One last thing the application developer has to be aware of; The MHP
specification defines the minimum size of the complete persistent storage
with 4096 bytes. Attempts to store data above this size may fail.
Page 72 of 215
30th March 2006
7.4.3 Tuning Interface

One terrestrial or cable channel or satellite transponder carries one MPEG2
transport stream. Each transport stream carries a couple of services.
Tuning means adjusting the terminal’s network interface so that it can
provide all information necessary to consume a certain service. If a target
service to tune to is part of the same transport stream as the current
service, tuning consists only in filtering different packets out of the stream.
If a target service is part of another transport stream, tuning does include
adjusting the network interface to a different frequency, which requires a
certain effort of terminal resources.
Tuning should not be mixed up with service selection, because tuning does
not include the update of the application information table (AIT).
The network interface is a scarce resource as obviously only one
application at a time can be allowed to perform tuning operations.
Furthermore tuning to another transport stream may cause the
disconnection of an application’s object carousel. This is why all
applications possibly running in parallel on the same service with an
application that performs tuning operations should be built robust enough to
withstand tuning. The terminal middleware has always priority on accessing
the network interface. Applications that rely on the tuning interface should
be able to deal with user events such as channel switching by remote
control.
Issue #106 in the MHP-KDB provides an example on how to perform tuning
in contrast to service selection.
Network Interface Controller

The network interface controller represents a controller that is used for
tuning a network interface. Applications may create a
NetworkInterfaceController object and use it to attempt to reserve a
network interface for exclusive access. The network interface controller
acts as a resource proxy for this resource.
Objects of the public class NetworkInterface represent physical network
interfaces that can be used for receiving broadcast transport streams.
Normally only one network interface is available in an MHP terminal. Twin-
receivers and other advanced terminals may offer more than one network
interface, e.g. to record one programme while displaying another one.
Classes and important methods
NetworkInterfaceManager
The network interface manager keeps track of broadcast network interfaces
that are connected to the receiver. There is only one instance of the
network interface manager in a receiver and here the tuner is selected.
static NetworkInterfaceManager getInstance(): The method
returns the singleton instance of the NetworkInterfaceManager.
NetworkInterface[] getNetworkInterfaces(): This returns an array
of available network interfaces.
Page 73 of 215
30th March 2006
NetworkInterface
This class offers information about a particular network interface.
int getDeliverySystemType(): The method returns an integer value
that identifies the type of network that this interface accesses.
TransportStream getCurrentTransportStream(): This returns the
transport stream to which the network interface is currently tuned.
Returns null if the network interface is not currently tuned to a
transport stream, e.g. because it is performing a tune action.
Locator getLocator(): Returns the locator of the transport stream to
which the network interface is currently connected. Returns null if the
network interface is not currently tuned to a transport stream.
boolean isLocal(): This method was intended to allow a unified
interface to tuners both in the receiver and in other devices, i.e.
whether the respective network interface is built into the terminal or
connected externally.
boolean isReserved(): This method tells the applications whether
the network interface has been reserved by an application for tuning.
NetworkInterfaceController
This class provides a mechanism for applications to actually control a
network interface and to use it to tune to a new transport stream. Once a
NetworkInterfaceController has been successfully bound to a network
interface, an application can actually start tuning.
reserve(NetworkInterface ni, Object requestData): Tries to
reserve the given network interface for exclusive access by the
calling instance of NetworkInterfaceController.
release(): After the tuning operation the network interface has to be
released again by calling this method.
tune(Locator locator): Tunes to the given locator.
7.4.4 Return Channel

The return channel provides the IP-connectivity for the MHP terminal. To
use the return channel, the interactive broadcast and internet access profile
need to be supported by the terminal. The quality (speed) of the return
channel depends on the type of return channel offered by the terminal and
potentially also on the type of subscription for internet access a user has
(e.g. with xDSL or cable bandwidth up to 40 MBit/s can be offered, but this
is typically not the speed offered to the residential user).
xDSL or cable modems provide an always-on connection and as such
there are no specific needs to first establish the IP-connectivity, as they are
not considered as a scarce resource. These types of modems are not likely
to be integrated into the MHP terminal, which will rather have an Ethernet
interface for connection with a home network or external modem.
When using PSTN (dial-up) connectivity, the MHP-receiver first has to
establish the telephony connection (dial-in) and then the IP-path using
PPP-protocols, as it has to be considered as a scarce resource. For
establishing this IP-connectivity the application has to provide the
telephony number used for the dial-in process. Also, only one connection
can be active at a time. A PSTN return channel is a scarce resource that an
application should not use unless it is really necessary. As using the dial-up
Page 74 of 215
30th March 2006
modem also involves extra costs, only signed applications are allowed to
access the dial-up modem. An MHP-receiver will also ask for a users’
permission ahead of the attempt to establish this dial-up connection; the
allowed numbers might also be stored in a “white list” so the user is not
always being interrupted when a dial-up connection needs to be made.
In general, return-channel interfaces are described in the class
RCInterface; for connection-based (e.g. PSTN) the class
ConnectionRCInterface defines the different procedures for getting
access and releasing the return channel.
Access to the return channel is managed by the class
RCInterfaceManager.
7.5 Migration
This sub-section provides an overview of all MHP-migration aspects. Part
one covers migration from legacy applications to MHP applications. Part
two deals with migrating to an updated version of MHP (e.g. from MHP
1.0.2 to MHP 1.0.3).
7.5.1 Migration from previous legacy middleware to

MHP
The main goal of DVB-MHP is to reach a horizontal market by providing an Plug-in
open standard. For the moment, however, many interactive applications A "plug-in" is a set of
deployed around the world only work on proprietary systems and are based functionality that can
on legacy middleware. Migration to the MHP platform is a crucial issue for be added to a generic
platform in order to
all broadcasters changing from proprietary middleware solutions to MHP.
provide interpretation
Importantly, migration costs should be kept as low as possible by making of application and
use of existing proved solutions. There are two basic options for migrating content formats not
existing applications: specified by MHP
specification to be
Re-authoring all existing applications; included in MHP
terminals.
Using a plug-in to enable older applications to run on the new MHP
middleware. The figure below illustrates the position of the two types
of plug-ins defined by the MHP architecture.
Legacy app.
Type A
MHP Applications
Plug-in A Legacy app.

Type B
MHP API
Application
System Software Manager
Plug-in B
Ressources
Figure 7-1 Plug-in implementation options
Page 75 of 215
30th March 2006
They are two possible types of plug-in implementations:

In native code provided for MHP implementation (Plug-in B).
As an MHP application (Plug-in A).
The plug-in solutions require to have implemented the respective plug-in for
the legacy middleware. This is efficient if we have a lot of legacy
applications to migrate. On the other hand, the plug-ins demand additional
implementation effort and, for type A, also higher processing power in the
decoders.
Re-authoring, on the other hand, can require more effort if we have a lot of
applications to migrate but it results in truly portable applications which are
better designed. If the proprietary decoder populations have to be
supported as well for a certain time, re-authoring also requires simulcasting
of applications in both API versions.
Alternative migration approaches are described in more detail in the
document “Guidelines on Migration” [MHPKDB-1MHPKDB] which can be
found on the MHP-KDB website.
7.5.2 Migration from older to more recent MHP versions

In order to correct bugs or bad behavior and to enrich the standard with
novelties, new versions are introduced putting a focus on backward
compatibility.
Sometimes, however, backward compatibility is not granted, and, as a
result, an MHP application compliant with an earlier version of the standard
(e.g. MHP 1.0.2) will have to be reworked to be compliant with the
subsequent versions of MHP (such as MHP 1.0.3 errata 2).
Generally they are five types of changes, each with a different impact:
Editorial: A change concerning the formal aspect of the specification
but not the definition (typo in description, specific formatting...). Such
a modification should not have an impact on the backward
compatibility;
Clarification: A change that clarifies, gives more precision,
rephrases a specific specification item in order to improve reader
understanding. Such modification should not raise backward
compatibly issues but rather interoperability issues;
System: A change concerning the signaling part, system behavior.
Such modification may raise interoperability issues if not hidden by
playout system or MHP terminal;
API Behavior: A change in the behavior of the MHP API. Such
modification will raise backward compatibility issues;
API Definition: A change concerning the java definition of MHP API.
Such modification will also raise backward compatibility issues.
Some modifications affect the backward compatibility so that applications

based on an older version cannot run on a more recent version.
In order to help application developers to migrate from an older MHP
version to a new one, we have analyzed the evolution from MHP 1.0.2 to
Page 76 of 215
30th March 2006
MHP 1.0.3 specifications. The graphs below represent overviews of the

modifications that have been added in the new version. Also DVB-MHP has
been working on some modifications in version 1.0.3 that are defined in
errata (the last is number 3).
Change type
8%
21%
5%
44%
22%
Editorial API Behaviour API change Clarification System
Figure 7-1 Different type of changes
Most of the changes between the two versions are due to clarifications.
Modification type
3%
Change
42%
Add
55% Delete
Figure 7-2 Different type of modifications
Among all modifications the most important type are changes and
additions, very little from previous version was deleted.
Page 77 of 215
30th March 2006
Changes per domain
4%
8% 16% Application
DVB-J API
9% Media
0% DSMCC-IO
9% Graphics
2%
1% Security
Event
5%
Havi
11%
Mpeg
SI
Return Channel
18%
Other
17%
Figure 7-3 Changes per domain
As we see in this graph a lot of changes concern several domains of MHP.

The most concerned domains are DSMCC-IO, Graphics and Application.
Backward compatibilty
12
Change
Add
Delete
28
Figure 7-4 Number of backward compatibility issues
Lots of problems of backward compatibility are due to changes and to

additions from the previous version to the new one.
For more details concerning migration issues see Annex D – Migration.
Page 78 of 215
30th March 2006
8 Broadcast Protocols
NOVICE LEVEL
8.1 Introduction
There are several different protocols that can be used for broadcasting data
and applications. This chapter will go through these, from the most basic
overview through to detailed technical descriptions on some subjects. In
most cases you will find the information you need here, but in some cases
you may be directed to external sources to perform further studies.
Broadcast Protocols
8.2 Transport Stream Elements
A good understanding of the transport stream concept is a great advantage
when developing or broadcasting MHP applications. This section will give
an introduction to the relevant standards and building blocks that form a
transport stream.
8.2.1 A note on naming

Channel = Service = Program
Ordinary people, DVB and ISO have different names for the same concept.
Most people refer to a service provided by a broadcaster as a channel.
That is a service that usually consists of a sequence of audio/visual
content. The service can be accompanied by additional components such
as applications and data.
In DVB a “channel” is named a “service” while the “channel” was named
“program” by ISO.
Program = Event
To confuse things further, DVB has also renamed the concept that ordinary
people refer to as programs. In DVB terms a service consists of a
sequence of events. An event corresponds to what usually is referred to as
a program; i.e. a piece of audio-visual content that has a defined start and
duration. Typically the 9 o’clock news could be an example of an event.
The following text will interchangeably use program or service when
referring to “channel”.
8.2.2 MPEG-2 Transport Stream

MPEG-2 is a standard issued by the International Organization for
Standardization (ISO). The systems [mpeg2systems] part is the most
interesting part from an MHP applications viewpoint. This document
describes how audio, video and data from different services are combined
into a transport stream.
A transport stream is a sequential stream of 188 bytes packets.
Conceptually you could also say that a transport stream is a collection of
one or more services.
Each service is a collection of one or more elementary streams.
An elementary stream is a sequence of packets containing video, audio or
some other type of data.
Page 79 of 215
30th March 2006
Transport Stream 1
Service 1
Elementary Video 1
Streams
Audio 1
Audio 2
Application 1
Data 1
ECM
Service 2
Service n
Figure 8-1 Transport Stream
The MPEG-2 packets of the elementary streams consist of 4 bytes header

and 184 bytes payload. Before broadcasting, the different elementary
streams are merged into a single stream of packets in a process called
multiplexing. The unit that performs this process is called a multiplexer.
This unit may very well be an integrated part of other devices, which is in
fact very often the case for devices that do the compression of the service
content, i.e. encoders.
Video
Video Compression
Program
Clock Mux
Audio Audio
Compression
Figure 8-2 Example building blocks of an MPEG-2 encoder
Typically, a device called MPEG-2 encoder will have a video input and a
number of audio inputs. The video and audio is uncompressed before it is
fed to the encoder. The encoder will then compress the video and audio
Page 80 of 215
30th March 2006
and multiplex the streams into a transport stream that contains all the
elementary streams of a service.
The use made of the “Program Clock” is explained in section 8.2.2.4.
The resulting transport stream will contain packets of all the underlying
elementary streams.
8.2.2.1 MPEG-2 Packets

Each 188 bytes MPEG-2 packet belongs to exactly one elementary stream.
The elementary stream is identified by a packet identifier (PID). The PID is
a 13 bits number located in the MPEG-2 packet header (the first 4 bytes of
the packet). The PID can in principle have any value between 0 and 8191
but some of the PID values are reserved for special uses. Values below 32
are reserved for metadata (see next section and chapter 10 for details) and
8191 is reserved for a special type of packets called null packets.
Null packets are commonly used to pad a transport stream with empty
packets to keep a constant bit rate.
188 bytes
header payload header payload header payload
sync transport payload transport PID transport adaptation continuity

byte error unit start priority scrambling field counter
indicator indicator control control
8 1 1 1 13 2 2 4
Figure 8-3 MPEG-2 Packet Header
The figure above shows the fields of the MPEG-2 packet. The first byte is a
sync byte that is used to identify the beginning of a packet in a continuous
stream of bytes. It always has the value of 0x47.
The transport scrambling control field indicates if the packet is scrambled
(see section on scrambling for more information on scrambling). The last
field is a counter to field that is primarily used to detect packet loss. The
continuity counter is incremented for each packet sent for each elementary
stream. This way it is very easy to detect that a packet is missing at the
receiver if the continuity counter skips a number. See the MPEG-2 Systems
specification for a detailed explanation of the remaining fields.
8.2.2.2 MPEG-2 packet payload

MPEG-2 packets can be divided into two main types: Packetized
Elementary Stream packets (PES Packets) and Data packets (usually
MPEG2 sections). PES packets are packets containing compressed audio
or video data. They include timing information. The data packets are
packets containing data that is not critical in timing, often metadata that
provides information on what information can be found in the transport
stream.
PSI, SI, EMM and ECM data all use a table format defined in the MPEG-2
systems specification as MPEG2 sections.
Page 81 of 215
30th March 2006
8.2.2.3 Program Specific Information (PSI)

In addition to the audio and video packet that we discussed in the previous
section, there will also be packets that contain metadata about the
elementary streams. MPEG-2 defines a set of tables that provides
information about what is sent on the different streams. This meta-data is
called PSI/SI (chapter 10 gives more details about PSI/SI).
8.2.2.4 Synchronization
The encoder will puts time codes, called Presentation Time Stamp (PTS) in
all the audio and video packets that will be used by the decoder to correctly
synchronize the audio and video. The PTS is relative to the Program Clock
Reference (PCR). The PCR is derived from a clock that is either internal to
encoder or external, this depends on the make and model of the encoder,
but in any case it is a clock that is used to enable the decoder to correctly
present synchronized audio and video. The PCR is used as a reference for
all program content of a given service; also MHP applications can be
synchronized to the PCR. This is done using a mechanism called ‘normal
play time’ (NPT), which in turn is synchronized to the PCR.
The PCR is sent in a separate elementary stream or as part of one the
other elementary streams embedded in the packets. Again this depends on
setup, make and model of the encoder.
8.2.3 DVB Transport Stream

A DVB transport stream is an MPEG-2 transport stream that is constrained
by some more rules in addition to the MPEG-2 specification. Most
important in this setting is that the DVB has defined some more tables that
are termed Service Information (SI). The SI tables extend and add to the
information found in PSI. See chapter 10 for details.
8.2.4 MHP
MHP makes use of the standard DVB transport stream protocols and DVB
service specifications. There is a new table added to the services if they
carry an MHP application. This is the Application Information Table (AIT).
See chapter 10 for details. The application is then broadcasted using the
DSM-CC format, which is described in detail in a following section of this
chapter.
8.3 DSM-CC NOVICE LEVEL

DSM-CC is part of the MPEG-2 specification [mpeg2DSM-CC] and covers
network session and resource management, configuring of clients,
downloading to a client, video management, service interactive applications
and service, data and user-to-user (U-U) object carousel for broadcast
applications.
DSM-CC transport is based on MPEG2 sections as defined in the MPEG2
systems layer [mpeg2systems].
In MHP DSM-CC is used to broadcast MHP applications and data as well
as stream events (covered in chapter 8.4). As broadcast systems are one-
way, the client has no way of telling the broadcast system which data it
wants. Thus the data is organized in carousels, i.e. one file is broadcasted
after the other and then the first is broadcasted again and the second etc.
Page 82 of 215
30th March 2006
This means that the client may have to wait a full lap to access a specific
file unless the file is repeated several times during one lap. The longest
access time for a file is defined by the bandwidth of the carousel and the
size of the data on the carousel.
MHP applications and data are broadcasted in object carousels. DSM-CC
also supports data carousels that are the simplest form of carousel.
8.3.1 DSM-CC Object Carousel 26 EXPERT LEVEL

DSC-CC object carousels extend the data carousel and add the concept of
files, directories and streams providing functionality close to a standard file
system. Object carousels are also based on the Object Request Broker
(ORB) framework defined by CORBA. I.e. all objects in the object carousel
are broadcasted as BIOP (Broadcast Inter-ORB Protocol) messages as
defined by CORBA and these messages are contained within a DSM-CC
data carousel.
The following message types can be carried in an object carousel:
DSM::File: representing files.
DSM::Directory: representing logic containers for a set of file
messages/reference to files in a directory
DSM::Stream: reference to MPEG-2 stream; to a single program, or
to one or more elementary streams.
DSM::ServiceGateway: identifies the root directory of the object
carousel, thus there is only one present in every object carousel.
BIOP::StreamEvent: describes a set of synchronization points
(stream events) in the stream.
Figure 8-4 Example of object carousel in DVB service
26
Part of this section is a slightly adapted copy of chapter 12 from: Report on ongoing standardization efforts,
Deliverable #15, SMASH, by Ivar Miljeteig and Ronald M. Tol.
http://www.extra.research.philips.com/euprojects/smash/deliver/del15/del15.pdf
Page 83 of 215
30th March 2006
A DSM-CC object carousel consists of three layers. At the top layer (called
the object carousel layer), the DSM-CC User-to-User objects (like files and
directories) are visible. These objects are transported in so-called modules.
These modules represent the middle layer and this layer is called the data
carousel layer. At this layer, the modules are just a container for data. The
User-to-User objects are not interpreted here; this is done at the top layer.
The modules are broadcasted as a sequence of DownloadDataBlocks,
which are MPEG-2 private sections with added semantics. These
DownloadDataBlocks form the lowest layer.
Figure 8-5: DSM-CC Object Carousel Layering
Each module cannot be larger than 64 Kbytes, but a single file cannot be
divided into several modules. Thus files that are larger than 64 Kbytes 27
have to be contained as the only file within one module.
DAVIC has specified how to refer to DSM-CC UU objects using java.io: it is
the same as how MHEG refers to those objects. The MHP specification has
included this part of DAVIC and thus also uses java.io to access files and
directories in a DSM-CC object carousel (cf. Annex C - Presentation of the
MHP APIs)
For more information on DSM-CC see [GuidelinesDataBroadcasting].
NOVICE LEVEL
8.3.2 Object carousel optimization
When you write MHP applications you probably want the application to be
perceived as fast and smooth as possible. This might be achieved by
optimizing the object carousel.
There are two basic ways of optimizing the object carousel; either by
organizing and grouping the files wisely in the modules or by repeating
critical files several times in the object carousel. The first method is quite
difficult and requires detailed knowledge about how the application is
designed.
The latter is probably easier, but has its disadvantages as well. When you
start to repeat files in the object carousel this will affect the size of the
object carousel. When the size of the object carousel is increased, the
access time of other files (those that aren’t repeated) increases, potentially
27
The broadcaster/developer should be aware that broadcasting too large files may cause the application to not
function correctly on all MHP terminals as they often have limited resources and may not be able to handle a
file if it is too large.
Page 84 of 215
30th March 2006
slowing down other parts of the application. A bigger object carousel also
increases the cost of deploying an application as the required bandwidth
increases. This is a trade off that has to be taken into consideration when
optimizing the object carousel.
NOVICE LEVEL
8.4 Synchronization
For MHP applications it is often necessary to be synchronized with media
content like audio or video. To enable MHP applications to run
synchronized to the media content, the so-called stream events are used
by MHP. A stream event is a small data-packet that will be sent by the
broadcaster to the MHP terminal to hand it over to the MHP application.
These stream events can contain a limited amount of application specific
content, which can be used to provide additional information like the text of
a question for a quiz show application.
Stream events are sent along the content to the MHP terminal and will be
handed over to the Xlet by the middleware. The Xlet itself only needs to
register a listener for a specific stream event and will be informed by the
MHP terminal, if the according stream event was received. All necessary
actions like filtering the transport stream as well as extracting and parsing
the data will be done by the MHP terminal. If a stream event is available for
the MHP application, then the middleware will create a StreamEvent object
which it provides to the registered Xlet’s StreamEventListener object.
There are two kinds of stream events defined in MHP: Do-It-Now as well as
scheduled stream events. While Do-It-Now stream events will be provided
to the Xlet’s listener right after the MHP terminal receives the event, the
scheduled stream events are delayed by the MHP terminal until the time of
the event matches the normal play time of the service.
The difference of these two kinds of stream events has no impact to the
MHP application. The subscription of a stream event is independent of the
stream event type.
8.4.1 Do-It-Now stream events

A Do-It-Now stream event can be used to provide a signal as fast as
possible from the headend to the MHP application. If an MHP terminal
receives a Do-It-Now stream event, then it will hand over the stream event
and its payload immediately to the MHP application.
Do-It-Now stream events are single shot events which won’t be repeated if
an MHP terminal missed it – therefore the MHP terminal has to make
special efforts to ensure a high probability that they can be reliably
received.
The benefit of Do-It-Now stream events is that they can be easily used to
synchronize an MHP application with a live program. If something happens
in the live program that needs to be signaled to the MHP application
shortly, a Do-It-Now stream event can be created and sent to the MHP
application. It is defined that such a stream event must be transmitted from
the headend to the MHP application as fast as possible.
A problem of Do-It-Now stream events is that the runtime from headend to
the MHP application isn’t known and therefore it isn’t reliable that it is
constant. If problems introduced by this unknown delay and jitter should be
avoided, then scheduled stream events will be the better choice.
Page 85 of 215
30th March 2006
Do-It-Now stream event must have an event identifier in the range 0x0001
to 0x3fff.
8.4.2 Scheduled stream events

Scheduled stream events are created prior to the time the event is to occur
and are handed over once or several times to the MHP terminal in a bunch.
The MHP terminal takes these scheduled stream events and stores them
until the normal playtime reaches the scheduled time of an event. If a
scheduled event for the current normal playtime is found, this event will be
provided to the MHP application’s registered StreamEventListener
object.
The benefit of scheduled stream events is that they can be created and
also be provided to the MHP terminal in a bunch. Especially the
transmission of the scheduled stream events prior to their planned
signaling to the MHP application can be used to avoid delays and jitter
introduced by the broadcast chain.
Scheduled stream events can only be used for pre-recorded content,
because the correct time of the media content must be known for creating
the timestamps for the stream event scheduling. For live events the exact
time of the planed events isn’t known and therefore the timestamp of the
event can’t be given.
The early transmission of the scheduled stream event is problematic for
MHP application which wants to provide the payload just in time. If, for
example, an MHP application for a quiz show provides the information
about the correct answer by a scheduled stream event, then it is possible to
catch the payload of the stream event even before the question occurred in
the game and extract the information about the correct answer. A player
who can get access to the information has an advantage in answering the
question correctly and can win the game more easy. To avoid such
problems, Do-It-Now stream events should be used in such a case.
Scheduled stream event must have an event identifier in the range 0x8000
to 0xbfff.
8.4.3 Creating stream events

A stream event must be signaled in the object carousel as well as a normal EXPERT LEVEL
playtime signal for scheduled stream events or the broadcast of
StreamEventDescriptors for Do-It-Now stream events. It is not
possible to provide a detailed “how to” for configuring the playout, because
every playout equipment is different to use. The following steps are
necessary on the headend side for broadcast stream events:
Configure the MHP playout software to contain a stream event object in the
DSM-CC.
Add at least one event name and identifier to the stream event object in the
DSM-CC. For Do-It-Now stream events the identifier must be in range
0x0001 to 0x3fff, for scheduled stream events the identifier must be in
range 0x8000 to 0xbfff. An event identifier 0x0000 isn’t allowed.
Use the API of the MHP playout software to create a stream event with the
previously added event name and/or identifier as well as the optional
payload. If the stream events are of type Do-It-Now, it is necessary to
Page 86 of 215
30th March 2006
invoke the stream event creation on the API at the time the event should be
received by the Xlet (please take into account the little delay, which the
stream event needs from the headend to the MHP terminal).
For scheduled stream events also the normal play time must be provided.
In the Xlet a listener must subscribe to a defined stream event. This is done
by creating a DSMCCStreamEvent object, which points to the stream
event object contained in the DSM-CC. With the DSMCCStreamEvent all
available event names/identifier can be retrieved as well as one or more
listeners registered for an event.
For further information see also issue KDB issue identifier 9 “Stream events
in MHP” in the KDB.
8.5 Section Filtering

NOVICE LEVEL
8.5.1 What is a section?

Sections are logical data containers transmitted over TS packets. They are
defined in the MPEG2 systems specification [MPEG2Systems]. A section is
usually used to transmit metadata for already existent audio and video
elementary streams in the TS, but their use is not limited to this. A section
has an upper size limit of 4 Kbytes. Since data easily can exceed this limit,
section tables are used to divide data into manageable section sizes. The
practical limit to a table’s size lies in the capabilities of the STB receiving it,
i.e. its caching capability.
A few standardized tables are defined through MPEG and DVB.
Broadcasters are also able to distribute their own proprietary tables using
private sections.
Sections will in most cases contain static data; i.e. the data can change at
any time, but there should only be one instance of it. This data should
ideally be available to any STB at all times. Since STBs have limited
resources for caching of data and users can enter a broadcast stream at
any time, sections need to be repeated to ensure their availability. There
are of course endless possibilities of doing this, but the simplest and most
frequently used method is to just start transmitting a table from the
beginning once it has reached its end on the TS. I.e. use a data carousel.
Both MPEG and DVB have defined specifications for special tables
transmitted in sections. These are specified as PSI and SI, respectively,
and are described in more detail in chapter 10. Sections for these tables
are limited to a maximum size of 1 Kbyte, not 4 Kbytes as other private
sections. The MPEG specific tables are elementary to the navigation of a
TS, i.e. how to find available content in the stream. These give information
about Services in a stream and what elements these consist of. The DVB
specific tables extend this information to include descriptive information of
both programs and events and information of other TS in a broadcasters
network.
The section header is either of standard or free format type, where the
latter is a subset of the former. The free format header is 3 bytes long and
includes an 8-bit table id and a 12-bit section length. The extended
standard header adds a 16-bit user defined table id extension, a 5-bit
Page 87 of 215
30th March 2006
version number and 8-bits section and last section number. Whenever the
standard header is used a 32-bit CRC is expected at the end of the section.
Section filters are used to extract a specific section or a series of sections
from the TS. The filter specifies a table id and a specific bit pattern for the
section to be identified with. The first section matching the filter in the TS is
copied and returned. There are also special versions of filters for getting
complete tables or other series of sections.
8.5.2 MHP
Section filters in MHP are 8 bytes long and consist of both values and
mask. The mask will determine which bits to include in the filter while the
values will dictate a possible match. The filter can start between the 3rd and
31st byte of the section, excluding the header. Both positive and negative
filters are available; positive filters will trigger when the bit pattern defined
match a section, while negative filters do the opposite. The latter is useful
when monitoring changes in a section, e.g. a version number different than
the current.
8.5.2.1 API
In MHP the section filtering is contained within the
org.davic.mpeg.sections package. A filter is defined through the
startFiltering method of the SectionFilter class.
startFiltering(java.lang.Object appData, int pid, int table_id, int offset, byte[]
posFilterDef, byte[] posFilterMask, byte[] negFilterDef, byte[] negFilterMask)
In summary, this method is asynchronous and will notify an already

registered listener object. The event will be identified with the appData
object reference. There are several versions of the startFiltering
method and the simplest one will only require a PID to be defined.
There are three types of filtering operations defined in MHP, all extending
SectionFilter. First, SimpleSectionFilter returns a single section, the
first match found. Second, TableSectionFilter retrieves the complete
table of which the first matched section belongs to. Third,
RingSectionFilter will continuously store matched sections in an array
of predefined size, terminating when an existing section is found in the next
step of the array. E.g. if sections are set to empty as they are retrieved this
function will indefinitely cycle through the array on a FIFO basis.
Handling several section filters is made easier through the
SectionFilterGroup class. Several filters can be created and turned on
and off in a single operation. This helps manage the scarce resource
section filters, across multiple independent applications.
8.5.3 Capacity and performance

Section filtering is a scarce resource in a STB, and MHP has defined that a
minimum of 2 section filters for each TS will be available for MHP
applications. There are not any performance requirements for MHP section
filtering.
A section filter can be performed in both hardware and software, and in
many cases as a combination of the two. Software filtering is more
processing power consuming and can slow down other applications on the
Page 88 of 215
30th March 2006
STB while running. Hardware filtering will usually not affect any other
operation.
There are few implementations that do all filtering in software. In the
simplest form this will only include PID hardware filtering. In those cases
where some of the filtering is performed in software, this is most likely to be
the bit-masks, and then maybe just a subset of these. E.g. it is possible that
only the positive mask will be filtered in hardware or otherwise only the very
first bytes in a section.
Any hardware filtering will always be performed first and only after this will
a software check verify a match or not. For implementers it can therefore
be useful to filter on as many early bits in a section, and leave out later bits
and possibly negative filters if not absolutely necessary.
8.5.4 Examples
For further information see entries below in the MHP KDB database:
“Private section for up-to-date text data?”
http://mhp-kdb.s3.uni-essen.de/nukes/?module=issue_view&op=FillData&id=20
“What is the fastest way to download files? MPEG or DSMCC?”
(http://mhp-kdb.s3.uni-essen.de/nukes/?module=issue_view&op=FillData&id=26)
“Read private sections from transport stream”
(http://mhp-kdb.s3.uni-essen.de/nukes/?module=issue_view&op=FillData&id=27)
8.6 Tuning and service selection

The MHP terminal provides the viewer with a simple, intuitive user interface
NOVICE LEVEL
for all basic tuning and service selection functions. Simultaneous decoding
of several services (video, audio and data at different protection levels) and
service selection which is based on the service information are made
possible.
Applications must allow for tuning happening (javax.tv.service.selection) in
parallel with the execution of their destroy Xlet method. Hence,
implementations of that method should not rely on being able to load
classes while executing, because the old carousel which the application
was using may not be available any longer.
If you are receiving a not tuned application, your implementation is not
tuned to the right transport stream for playing the media. Even if you are
playing it from a file, the MHP implementation will treat this as tuning to a
new transport stream, simply because it is the easiest and most accurate
way to simulate a real input.
The middleware of the MHP-Box will not automatically tune to a different
transport stream in order to play a piece of media - this is a deliberate
decision in MHP. So you cannot have access to A/V content of other
services without using the service selection or tuning APIs.
All channel decoder output data is available on the MHP interface. This
makes a superb platform for experimenting with data broadcast
applications. Nevertheless, the applications also run without using the
service selection API or Tuning API.
Page 89 of 215
30th March 2006
8.7 Principles of conditional access (smart card, CI

content protection) NOVICE LEVEL
Conditional Access - or CA - is as the wording implies a way of controlling
who can watch, listen to or otherwise use the distributed content. The
means to do this is by encrypting the content in the transmitting end in a
way that can only decrypted in the receiving end if the user is entitled to do
so.
The need to encrypt content

All pay-TV operators rely on the existence of a CA system for their
business models and with the dawn of satellite distributed television also
public service broadcasters may need to encrypt their programming if they
have not acquired rights to distribute in a large geographic area (e.g.
Northern Europe) that the satellite footprint permits.
Reason for including conditional access

CA systems have been used also in the analogue world with the main
functionality of being the central component in pay TV systems. With the
dawn of digital television the encryption of the services was a commercial
requirement in the specification process. It is being used in many networks.
In the simplest interpretation, this looks like:
Figure 8-6: Encrypting and decrypting content
This is of course more complicated in the real world, where protection

against hacking is a big (and for many broadcasters/gatekeepers also an
economical) issue.
To be able to control who can access what content, the CA system is
closely related to a customer registration system called SMS (Subscriber
Management System). The SMS database keeps the customer related
information together with information on what permissions the individual
customers have.
On the consumer side the users possess a unique smartcard, which is
addressed over air with the correct entitlement data, and which in
cooperation with the CA system provides the decrypting of the services. In
the set top box end, there are 2 possible ways, which are both DVB
compatible:
1) The CA system can be present in an external unit called CA module,
which fits into an interface specified by DVB called Common Interface (or in
short CI) - the smart card can be fitted into this module.
2) The CA system can be build into the set top box with a smart card
reader as the interface for the customer to use.
Encryption and decryption process

The actual scrambling algorithm used is not public and is only revealed to
authorized license holders on a need-to-know basis only. The terms of the
Page 90 of 215
30th March 2006
license makes requires that the algorithm can only be implemented in

hardware. However, the real security of conditional access lies not within
the semi-secret scrambling algorithm (source code software
implementations have been and most likely still are available for download
from the internet).
The scrambling algorithm uses a key called control word (CW). The
security of the scheme lies in a secure transfer of the key to the authorized
receiver. The keys are encrypted and sent in special elementary streams
called entitlement control message (ECM) streams. The systems used to
encrypt the CW and package it into an ECM is not standardized. These
systems are called conditional access (CA) systems.
The encrypting algorithm of the ECM and its content format is CA system
specific and secret. To decrypt the ECM and extract the CW in the MHP
terminal a smartcard from the appropriate CA system vendor for the
services is needed. The PSI tables should not be scrambled, but except for
these most elementary streams can be scrambled if the broadcaster
chooses to do so.
In addition to ECM streams the transport stream will also contain
Entitlement Management Message (EMM) streams if there are scrambled
services in the stream. The EMM’s are used to send messages to the
smartcard itself. These messages usually control different settings on the
smartcards such as updating of subscription information like
adding/removing access to scrambled services.
This is illustrated in Figure 8-7.
Figure 8-7: Encryption and decryption process
Page 91 of 215
30th March 2006
9 MHP Applications and Application

Lifecycle
Application Lifecycle
This chapter deals with the application lifecycle management of an MHP
terminal. Both the MHP application states and the state transition model will
be considered. Furthermore the relationship between resident applications
and broadcasted MHP applications, and, finally, an outlook on stored
applications, to be introduced by MHP 1.1, will be provided.
9.1 Applets and Xlets NOVICE LEVEL
Applets were designed for use with Internet browsers and a full set of Java
classes as included in standard Java Runtime Environments. Applet:
An Applet is a partial
Xlets are geared towards consumer device applications, such as a
Java application
television-broadcasting environment. They use a well-defined lifecycle of program designed to
Loaded, Paused, Active, and Destroyed states, particularly tailored to run inside the womb
environments like television. of a web browser, with
help from some
Applets are significantly linked to a mouse controlled GUI, but most predefined support
consumer electronics devices are operated by a remote control. Applets classes.
are typically linked to HTML pages and AWT. An application that allows
keyboard navigation and operation can be suitably run as an Xlet, when the HTML (Hypertext
used AWT components will be replaced by HAVi controls. Markup Language):
Due to the fact that an Xlet might originate from an unknown or not Language to describe
trustworthy system and the security restraints safeguards the system content for the world
wide web. It is
resources, applets and Xlets use a similar security model. Xlets should not possible to create
be able to access system-critical resources or interfere destructively with links between HTML
the operation of other Xlets. content and to
integrate in addition to
texts and graphics
9.2 Xlet Application also interactive
content.
Xlets have a well-defined lifecycle with Loaded, Paused, Active, and
Destroyed states.
initXlet startXlet
(not loaded) Loaded Paused Active
pauseXlet
NOVICE LEVEL
destroyXlet destroyXlet destroyXlet

AWT (Abstract
Windowing Toolkit):
Destroyed
The basic
programming interface
for graphical user
Figure 9-1: Xlet lifecycle state machine diagram interfaces in Java. All
other graphical user
Loaded: the DVB-J application instance is loaded but not initialized. interfaces available in
Java (like Swing) are
Paused: the application instance minimizes its usage of resource. based on AWT.
Active: the application instance is working and providing service.
Destroyed: the application instance has released all its resource and
terminated.
The reason of having these different application states can be found in two
MHP inherent restrictions:
Page 92 of 215
30th March 2006
• Applications have to run in low performance environments: On an

average MHP Terminal system resources might be used by one
application up to a level where no further application may be
started. Instead of continuously destroying the first application it is
possible to just release scarce resources and have it running in a
paused mode. Thus, basic multitasking is possible while using
terminal resources efficiently.
• Applications must not crash: In order to keep the terminal system
clean it is necessary that the applications clean up after being
terminated. This is done by introducing a destroyed mode before
changing into the not loaded state again. This also allows for
introducing a superior management instance to control all
applications through a well-defined interface. Each of the states
has typical tasks that are performed when the application enters
the state.
Multiple Xlets are allowed per Xlet Manager, which is a resident application. VM (Virtual Machine)
The Inter-Xlet Communication mechanism allows Xlets to communicate Software used to
and cooperate with each other. A single application is allowed per its own isolate the application
VM instance. to run from the real
hardware and
The initial class of the MHP application must implement the interface operating system.
javax.xlet.Xlet and all of the defined methods, which will be used by Applications
developed for a virtual
the Xlet manager to signal the applications state changes like they are machine are hardware
shown in Figure 9-1. When the application manager of an MHP terminal is independent and can
asked to launch an application, it will first call initXlet(XletContext run without changes
ctx) and then startXlet(). The method pauseXlet() will send the Xlet on any hardware as
long as the virtual
into background and startXlet() may be used again to resume the Xlet. machine for that
hardware is available.
To finally terminate MHP application, destroyXlet(boolean
unconditional) is called by the Xlet manager, returning the Xlet into not
loaded state. The boolean switch is used to tell the Xlet if it is obliged to
terminate or if it has the choice to deny the request for termination.
If an Xlet want to change the current application lifecycle state by itself, it
must inform the Xlet manager about the change. The signaling of the state
change to the Xlet manager is done by invoking the according methods on
the XletContext, which the Xlet was provided by the
initXlet(XletContext ctx) invocation. There are three methods for
inform the Xlet manager about the change:
• void resumeRequest(): If the Xlet want to change its state
from paused to active, it has to invoke the resumeRequest()
method of its XletContext object. But note that the Xlet manager
need not set the Xlets state to active.
• void notifyPaused(): As soon as the Xlet enters the paused
state by itself, it must use this method to signal the paused state to
the Xlet manager. This is not necessary, if the Xlet manager
invoked the pauseXlet() method.
• void notifyDestroyed(): When the Xlet enters the

destroyed state by itself without the initiation of the Xlet manager
(invocation of destroyXlet(boolean unconditional)), then the
Xlet manager is informed about this self-destruction of the MHP
Page 93 of 215
30th March 2006
application by invoking the notifyDestroyed() method of the

XletContext.
The XletContext object provides access to environment settings of the Xlet
with the method getXletProperty(java.lang.String key). Similarly to
the getProperty(java.lang.String key) method of the javas System
object, a predefined string is used to access the settings. Currently there
are the following properties are accessible (see also chapter 11.7.1.1 of
MHP 1.0 specification) :
• dvb.org.id“: The organization identifier of the Xlet this
XletContext belongs to, like it is signaled in the broadcast. Value
is returned as organization identifier encoded as String (defined in
chapter 14.5 of MHP 1.0 specification).
• dvb.app.id“: The signaled application identifier of the Xlet.
Value is returned as application identifier encoded as String
(defined in chapter 14.5 of MHP 1.0 specification).
• dvb.caller.parameters“: Provided Parameters when the
Xlet was started by an AppProxy. Parameters are returned as
String[]. If no parameters are available, then the String[] has
zero length.
• XletContext.ARGS: Parameters as signaled in the broadcast.
Parameters are returned as String[]. If no parameters are
signaled, then the String[] has zero length.
9.3 Resident applications NOVICE LEVEL
Unlike broadcast MHP applications, a resident application is stored in a

non-volatile storage memory of the MHP terminal on part of the
manufacturer. Consequently, a resident application does not have to be
implemented as an MHP application. Examples are the navigator, tools for
configuration of the MHP terminal, games or the Xlet manager.
As such resident applications are manufacturer specific additions it is not
defined which have to be included in an MHP terminal. Broadcasted MHP
applications are not capable of interacting with resident applications.
Indirect communication may happen when broadcast applications access
MHP functions like service selection, which is also observed by the
navigator application of the MHP terminal and thus could influence the
behavior of the navigator.
NOVICE LEVEL
9.4 Stored applications
MHP 1.1 introduces “stored applications” as a third application type in
addition to the currently existing broadcast and resident applications. A AIT (Application
Information Table)
stored application is a broadcast MHP application that can be stored on the
MHP terminal for later usage. This can be useful if the application is Service bound DVB-
Table describing all
reloaded from the faster local storage instead of the broadcasted data available MHP
carousel. A stored application associated with a broadcast service can only applications of that
be started when it is currently signaled in the AIT of a broadcast service, service. Used to
even if it is already stored on the MHP terminal. signal and control the
MHP applications of a
In addition to stored applications related to a specific service, also stand- service.
alone stored applications can be developed, like, for example, a game.
Page 94 of 215
30th March 2006
The lifecycle of a stored application is not any different to the lifecycle of a

broadcast application. It can only be started if the application is signaled in
the AIT of the currently selected service. This is also valid for stand-alone
stored applications, because they are bound to a stored service which
contains an AIT with the signaling.
The AIT is described in more detail in section 10.3.
9.4.1 Restrictions of stored applications

Stored applications related to a broadcast service are behaving like any
other broadcast application. There are no differences despite of the fact,
that stored applications can be loaded faster than broadcast applications
on the data carousel.
EXPERT LEVEL
A stand-alone stored application is not associated to a broadcast service
and therefore its ServiceContext has no access to a
ServiceContentHandler which deals with audio or video, like a
Player object. Despite of a related ServiceContentHandler, the
application can create its own Player that receives a higher priority for
resources than any previously existing presentations.
Furthermore, the behavior of the SIDatabase is undefined for stand-alone
stored applications. Either no service information objects are returned at all,
or SIDatabase returns service information of the last tuned service.
Therefore stand-alone stored applications should not deal with service
information that is related to the actual service.
A stored application consists of objects downloaded from the broadcast
data carousel. These stored objects can be of the type directory or file (see
also chapter 9.4.3 - Signaling of stored application). Therefore all other
object types in the data carousel cannot be stored on the MHP terminal, so
that for instance DSMCCStreamEvent objects of the data carousel are not
available in the storage of a stored application. A stored application
needing access to stream events has to mount a currently broadcasted
data carousel that contains an assigned DSMCCStreamEvent to listen to.
9.4.2 Extensions to MHP 1.0 APIs EXPERT LEVEL

The service filter is extended to support the filtering of stored applications.
If such a filter is used, the returned ServiceList object contains a list of
all currently installed stored applications as Service objects of type
StoredApplicationService. Depending on the implementation of the
MHP middleware also manufacturer specific resident applications may be
included in the filtered ServiceList. An MHP application cannot rely on
the possibility of retrieving manufacturer specific resident applications.
With ServiceContext.select(Service) it is also possible to select a
StoredApplicationService object. According to the AIT associated to
the service the signaled stored applications are available and if an autostart
stored application is available, it will be started.
All files of a stored application are accessible as if they were actually
broadcast. The only differences are, that asynchronous loading can be
expected to complete immediately and that no ObjectChangeEvents are
generated. An ObjectChangeEvent cannot occur as the stored files are
not connected to any broadcast and can therefore not be updated. It is also
Page 95 of 215
30th March 2006
not possible for the MHP application to selectively remove files from the
storage of the stored application like it is not possible to delete files in the
data carousel.
Despite the MHP 1.0 definition of filename restrictions for persistent
storage (see chapter 14.6.1 of MHP 1.0 specification), the MHP 1.1 defines
an exception for the filenames of a stored application. Stored applications
can therefore contain files in the storage of the MHP terminal, the names of
which exceed the restriction of MHP 1.0. This exception is only valid for the
files downloaded from the data carousel to the MHP terminal’s storage.
Files that are created by the stored application in the persistent storage are
still limited to the filename restriction of MHP 1.0.
9.4.3 Signaling of stored application EXPERT LEVEL
A stored application is signaled in the AIT like any other broadcast MHP
application. In addition to the signaling of normal MHP applications, stored
applications contain an Application Storage Descriptor in the common
descriptors loop or application descriptors loop of the AIT. This descriptor
contains information about the kind of storable applications (broadcast
related or stand-alone) and the versions of the application. If any file of the
stored application changes, the version number must be increased by one.
The version numbering should be unique and if no version number was
available anymore, a new application identifier should be used.
To enable the MHP terminal to store the necessary files of the MHP
application, an Application Description File must be supplied in the data
carousel of the application. The Application Description File has an XML
structure and is described in the MHP 1.1 specification, chapter 10.14.3
Application description file. In chapter 9.1.9.1 Version management, some
more information about the versioning and updating of a stored application
will be given. If an application updates too often, the MHP terminal can
refuse to perform these updates. A good advice is to avoid the storage of
frequently updated files by not listing such files in the Application Descriptor
File.
Last but not least, the permission request file is related to stored
applications. With the element application storage in the permission
request file the right for controlling stored applications can be obtained.
Page 96 of 215
30th March 2006
10 Service Signaling
10.1 Introduction
Applications often require aligning with other instances or timings. After
applications have been developed, there are some additional steps that
need to be taken. They need to be transmitted - i.e. included in the
Application Signalling
transport stream, and their presence and nature needs to be signaled. The
signaling serves different purposes:
to give notice to the receiver that an application is available
to give notice to the receiver what the application contents
to provide eventual signaling from the broadcaster to the application
This chapter provides information on how the signaling is happening as
defined in the MHP standard.
10.2 Introduction to SI / PSI

Service Information contains metadata necessary to locate, tune to and NOVICE LEVEL
display services on a terminal. Some is fairly network-oriented, like the
mapping of streams to a certain service; other is even human-readable in-
formation, e.g. the program service information.
Service Information is divided into tables structuring information related to
different aspects of DVB transmission. These tables have entries called
Descriptors, which is the smallest unit in Service Information data.
Strictly speaking there is “Program-Specific Information” (PSI) as de-fined
by MPEG-2 as well as additional “Service Information” (SI) as defined by
the DVB-Project and the resulting ETSI standards [ETSI EN 300 468].
In the following the available SI/PSI tables are described in brief:
Program Allocation Table (PAT)

This table contains information on where to find the Program Mapping
Tables (PMT) for each program (service) available on the current MPEG-2
stream. This is a table that would not normally be accessed from an Xlet.
Program Mapping Table (PMT)

The Program Mapping Table contains information about which elementary
streams belong to a certain service. Each service has allocated one PMT,
where the PID (Packet Identifier) numbers of the respective audio, video
and data streams are listed, as well as a reference to the Program Clock
Reference (PCR).
Conditional Access Table (CAT)

This table contains private data with information on conditional access
restrictions. The main purpose of the CAT is to tell the terminal where to
find the EMM stream, i.e. the PID of the EMM stream (cf. section 2.4.4.6 of
the MPEG-2 systems specification): “The Conditional Access (CA) Table
provides the association between one or more CA systems, their EMM
streams, and any special parameters associated with them.
Page 97 of 215
30th March 2006
The following additional tables were defined by the DVB-Project:
Bouquet Association Table (BAT)

The BAT contains a list of services that form a bouquet. It offers information
on the provider and the name of the bouquet. This information can be used
for displaying an EPG sorted by different bouquet providers.
Service Description Table (SDT)

The service description table describes all services available on the current
transport stream and may contain information on services on other streams
as well. It contains the names and provider of the services.
Network Information Table (NIT)

This table contains information on the network the current transport stream
is running on, like network name, orbit position and transponder number
whereas the latter two are only applicable for satellite networks.
Event Information Table (EIT)

The EIT is a large table with a lot of different descriptors. It contains
information on the program events within the services. As a minimum, the
name of the currently running and the upcoming program is listed for each
service. But some providers also give information on the program schedule
for a day or week in advance. When building an EPG application, this is the
core table to look at.
Running Status Table (RST)

Any event has a running status, i.e. it is either currently running or not. The
concurrently updated information on the RST allows to automatically
switching to a certain event as soon as it starts.
Time and Date Table (TDT)

This table contains the current UTC time and is concurrently updated.
Time Offset Table (TOT)

This table contains the local time as UTC time plus the local time offset.
Furthermore the Stuffing Table (ST), the Selection Information Table (SIT)
and the Discontinuity Information Table (DIT) are defined, but they are less
relevant for MHP application programming at the moment.
10.2.1 Information independent from transport stream NOVICE LEVEL

Obviously it should make no difference from which transport stream the
Time and Date Table (TDT) and the Time Offset Table (TOT) are read.
The Network Information Table (NIT) from the actual network is also
identical on all transport streams that belong to this network.
The Bouquet Allocation Table (BAT) may as well group services of different
transport streams and even networks, though on different networks there
probably will be different BATs.
10.2.2 Optional “other” tables

NOVICE LEVEL
Some transport streams, e.g. such that belong to a broadcaster or provider
that offers multiple programs on different transport streams, may include
information on all of their programs on all their streams. There may be NITs
Page 98 of 215
30th March 2006
of other networks, SDTs of other transport streams and pre-sent/following

EITs of other transport streams signaled on the current stream.
10.2.3 Tuning to other streams

If a specific piece of information is not broadcast in any way on the current NOVICE LEVEL
transport stream, there is no way to avoid tuning. On terminals with one
network interface this could mean losing the TV stream, so it is not always
applicable. Tuning can be done with the org.davic.net.tuning API. Details
and examples are available in the MHP Knowledgebase.
10.2.4 Accessing Service Information

Service Information can only be accessed through asynchronous method
calls to the org.dvb.si or javax.tv.service APIs. This is because the MHP
terminal is not required to cache all available information on the terminal,
but much of the information has to be read directly from the transport-
stream. Depending on the kind of information requested it may take several
seconds till the desired information is received from the stream. To avoid
blocking the application during this time, SI request methods have been
designed to be asynchronous.
The first request is always to an org.dvb.si.SIDatabase or
javax.tv.service.SIManager object. By adding a listener the application
receives the desired SI-table object. That object then offers own methods
to request more detailed information (single descriptors) from the
respective table. Basically any kind of information may be requested
through both mentioned APIs. The advantage of org.dvb.si is that its
objects mirror exactly the Service Information available on a DVB-S/C/T
stream, whereas javax.tv.service is more generic and might need to
address certain Service Information Descriptors by filtering for its id
number. On the other hand the generic approach of javax.tv.service offers
a more comfortable access on EPG related information. Both APIs are
identical regarding the performance aspect, because the MHP stack will
most likely use the same underlying implementation.
10.2.5 Usage of the SI overview tables

In order to explore the vast amount of available SI data accessible via the EXPERT LEVEL
two APIs, we provide two tables that give an overview which steps to follow
in order to retrieve a certain piece of information. The documents are called
“DVB SI API overview.pdf” and “JavaTV SI API overview.pdf”.
The first column lists the retrieval methods that can be issued on the base
object, such as SIDatabase or SIManager. The second column lists the
type of object that will be returned with methods that can be invoked on
those objects in the third column.
In order to obtain a specific piece of information, locate it at the table of the
desired API and track the way back to the base object. The tables are
extensive, but may simplify in some cases. Thus, if any information cannot
be found in the tables, please refer to the API documentation.
Page 99 of 215
30th March 2006
10.3 Introduction to AIT and application change

Unlike other Service Information tables, the AIT cannot be accessed via
any of the SI-APIs. It is managed by the terminal and represented by the EXPERT LEVEL
AppsDatabase class. This database holds information on all the
applications available on a service and gets quickly updated in the case of
a ser-vice change.
In the AIT each application is unambiguously identified within a certain
service by a combination of an organization ID and an application ID. In
Java these are combined in a class called AppID. Each service has its own
AIT. The applicationID and the organisationID have to be configured in the
carousel playout server. For each application there are attributes to
influence the lifecycle behavior:
service bound: Applications that are service bound can only run
when the service they are bound to is running
Visibility: The visibility flag determines whether the application can
be seen by other applications in the AIT.
Autostart: Autostart applications start automatically when the service
they are signaled on is started.
According to the MHP-standard service selection seriously affects running
applications. Depending on the application attributes the following does
happen on service selection:
All applications that are marked as “service bound” on the old service will
be terminated instantly.
Applications that are service unbound will be killed as soon as the
AppsDatabase has been updated with the applications available on the
new service. This takes place about some seconds after the service
change itself.
Only applications that are service-unbound AND signaled on the new
service as well continue to run.
Autostart services are launched. If the service was already launched on the
old service, it will be relaunched.
Applications that are not running in a ServiceContext are not affected, like
terminal resident applications (Navigator).
Applications can be used to launch and control other applications, e.g. to
build a portal application for a service bouquet (cf. chapter 9). It is also
possible to launch applications that are signaled on other services. The
new service with the target application has to be selected, with all
consequences mentioned above. Mere tuning is not sufficient, because
tuning does not affect the AppsDatabase, as it does not search the stream
EXPERT LEVEL
for a new AIT. I.e. when tuning the AppsDatabase content remains the
same with the result that all running applications keep running, but new
applications can only be launched if they are by chance also available on
the new stream we tuned to. Also the DSM-CC object carousel will get
disconnected, so a running application might not have access to its data
anymore. This should always be considered before tuning. The conclusion
is also, that portal applications have to be signaled on all services where
there are applications available that should be startable from the portal.
Page 100 of 215

30th March 2006
10.4 Application Loading over Return Channel

With the advent of a return channel, which by nature is point-to-point, new
possibilities arise. The return channel can be used bi-directionally and may HTTP (Hyper Text
therefore be of advantage to use under certain circumstances - e.g. on- Transfer Protocol)
demand data, individually adapted data/applications. The standard protocol
MHP 1.1 has support for loading data and applications over the return used for browsing the
internet.
channel using HTTP. As such this is only applicable when the Interactive
Broadcast and Internet Access Profile are used. Firewalls are typically
configured to transparently allow HTTP-traffic, so problems related to the
IP-transport are avoided.
A receiver will attempt to download a data file or application if it is signaled
in the AIT by using the transport protocol descriptor that it has to attempt to
use the interaction channel. This is described in details in 10.8.1 of the
MHP 1.1 specification [MHPKDB-1].
The receiver has to search for the required file in the directories and zip
files signaled in the AIT tables.
In the case that the MHP-terminal detects that the server uses https (the
secure version of http) the terminal shall use https.
The advantages of loading applications over the return channel could be
that an application is loaded faster. The load on the broadcast carousel can
be reduced by having receiver load applications using the return channel.
E.g. this could be used for those applications that are used by a limited
number of people, by loading them over the return channel, they do not
take up bandwidth in the carousel, freeing up space for other more used
applications, or to increase general loading time.
Page 101 of 215

30th March 2006
11 Security
This section gives a brief theoretical background of the security problem,
the identified security goals and the nature of possible security threats. In
the following, the MHP security framework and the application rights model
are described.
Security
11.1 Security in interactive television environments

In theory, the security problem is often separated into different aspects also
called security goals. The security goals that are seen as relevant in the
context of interactive television are Integrity, Confidentiality and Availability
[Hetzer 2001]. These are shortly described in this section and lead over
into security requirements for iTV systems.
11.1.1 Integrity
Integrity is given when a certain piece of information is not tampered in an
unauthorized manner. In general it can be said that any modification that
happens against the intention of the owner of the information violates its
integrity.
When looking closer at an execution environment for interactive
applications, two kinds of information can be identified: data and code, or in
more detail: data, application code and system code. Hence, integrity
comprehends integrity of those three parts.
System code (MHP implementation on a MHP terminal) can be considered
as static and its integrity (in particular of its security relevant parts) has to
be permanently ensured by the manufacturer. If this is not the case any
security model collapses. The integrity of the system code therefore has to
be presumed by broadcasters and developers.
Application code is transmitted together with according data to the user
terminals via the broadcast channel. Because the source of the application NOVICE LEVEL
is firstly not known, the integrity of a received application code can not be
assumed. The MHP-terminal has therefore to be provided with possibilities
to check, if the source of an application is trustworthy,
to recognize if code has been tampered before receiving it and
to ensure that already received code cannot be tampered within the
terminal by other applications.
Integrity of data is the actual goal behind the integrity aspect. However, in
every computer system data is processed and modified by code. Therefore
the integrity of code (as described above) is one of the necessary
conditions for the integrity of data.
Data are either received via the broadcast channel together with the
appropriate code or created and stored on the user terminal by
applications. In this respect, further conditions for data integrity are
therefore
the prevention (or at least the recognition) of unauthorized
modification of data before or during broadcast and
the prevention of unauthorized modification of data within the
terminal by other than the native code.
Page 102 of 215
30th March 2006
11.1.2 Confidentiality
Confidentiality is given, if a piece of private information cannot be accessed
by third party without authorization of the owner. Relating to iTV systems
the security aspect of confidentiality covers two issues.
The first case concerns private information (data and code), that a
broadcaster (owner) distributes via the broadcast channel and that
therefore can be received by all user terminals. However, normally due to
their business models (e.g. pay-TV), broadcasters might want to restrict
access to their content for example to certain users who have subscribed
and paid for a certain service TV service. Confidentiality can here be
achieved by conditional access systems (CA) through content encryption
by the broadcaster and the appropriate distribution of keys for decryption to
authorized users. Since MHP provides the usage of CA systems, the
confidentiality condition can be fulfilled also for MHP applications by
encrypting object carousels. Hence, this possibility is not further elaborated
here in the context of security.
The second case concerns private information of the user (e.g. credit card
information, passwords, etc.) generated by user interactions and then NOVICE LEVEL
stored on the user terminal by an application. The confidentiality of user
information is only endangered if the user terminal is connected to a return
channel; otherwise the private information cannot be transferred or viewed
by another party than the user. However, if the return channel exists, also
the possibility is given that an application (either accidentally or
deliberately) transmits private information from the user terminal to
unauthorized thirds. Therefore the MHP-terminal has to ensure
that only trustworthy applications are granted access to user
information stored on the terminal.
11.1.3 Availability
Availability is given, if it is possible to use the different services of a system.
On the MHP-terminal, the applications and the system code itself have to
share the available resources of the system. If one application manages to
consume a certain resource to a disproportional extent, the availability of
other applications or even of the system is endangered.
Application code that was willfully written to destroy the balanced resource
distribution within a system is called “denial of service attack”. But also
code that simply contains bugs can accidentally lead to a denial of service.
A problem in this context are Deadlocks that occur when at least two
processes within a system block each other by awkward allocation and
request of resources. The system therefore needs a possibility to dissolve
deadlocks if they occur. In every case, the MHP system has to control the
access to system resources and it has to control the consumption of
resources after it has granted an application access to them.
However, loss of service availability of is not the only danger that occurs
NOVICE LEVEL
when applications from an unknown source get access to the resources of
a MHP terminal. Thinking to the abusive use of the modem by dialing a
premium rate phone number makes clear that access to certain system
resources can only be given to trustworthy applications.
Therefore, it can be stated as a security requirement for an MHP-terminal,
Page 103 of 215
30th March 2006
that applications only can make use of system resources they are
allowed to use and
that certain resources can only be used by trustworthy applications.
11.2 Signing MHP Applications

The MHP standard provides a signature procedure that can be used to EXPERT LEVEL
digitally sign files in a directory, complete directory trees or even whole
object carousels. The aim of such procedure is, to provide the MHP
terminal with a possibility to verify if an application was signed by a
trustworthy entity and, to check if a received application has been modified
after signing.
This process uses three different authentication messages (hash codes,
signatures and certificates) and works as follows:
11.2.1 Hash files (dvb.hashfile)

On the broadcaster side, the integrity of the application files is verified and
hash values are created and stored in hash files that always have the name
“dvb.hashfile”. Each directory in the tree to be signed has finally to contain
one hash file. The hash file itself contains one or more sections that are
structured as follows:
Hash algorithm identifier
List of filenames
Hash value
For creation of the Hash values MHP allows the algorithms MD5 (128 bit)
and SHA-1 (160 bit), whereas the SHA-1 algorithm has to be considered
safer due to its significantly longer hash word. The hash values are created
by hashing all files in the directory as well as the hash files of the
subdirectories (if available). This hierarchical creation of hash codes allows
for processing large directory trees with comparable little effort since the
“dvb.hashfile” contained in the root directory contains the checksum (hash
total) for the complete directory tree. This hash however does not provide
security against unauthorized modification on its own, but it allows
detecting if anything (filenames, file content) in the underlying file structure
has been changed – preconditioned the hash file itself has not lost its
integrity.
11.2.2 Signature files (dvb.signature.*)

The signature files are stored in the root directory and have two functions: RSA (Rivest-Shamir-
Adelman-algorithm)
To protect the highest hash file (contained in the root directory)
Secure asymmetric
To specify the originator of the application encryption algorithm
using a key pair of
By signing, the signing entity assures that the signed application will not private and public key.
cause any damage and is therefore safe to run on the user terminals.
In MHP all signature files have the name “dvb.signature.*”, whereas “*”
stands for consecutive id-numbers in case of more than one signature files
in the directory. The digital signatures contained in the signature files are
created by hashing the “dvb.hashfile” in the root directory and then
encrypting this hash value by using the RSA method: The broadcaster uses
Page 104 of 215

30th March 2006
its private key for encryption and stores the public key (necessary to verify
the signature) in the corresponding certificate file.
11.2.3 Certificate files (dvb.certificates.*)

For every entity that signs an application (directory tree) two files have to
be provided in the root directory: the signature file and the certificate file.
The “*” in both filenames represent the id-number of the entity, so that it is
clear which certificate file corresponds to which signature file.
As already mentioned, the certificate file contains the certificate whose
public key allows for confirming the signature of the corresponding
signature file.
The MHP-standard uses X.509-certificates and for this reason defines a
new profile thereof.
The certificate that a broadcaster uses for signing is usually a leaf
certificate standing at the end of a chain of trust. MHP defines, that all
certificate files have to contain all certificates that are necessary to
authenticate the leaf certificate used for signing: The complete chain from
the leaf certificate up to the root certificate.
The root certificate authority has to be well known to the receiver i.e. the
root certificate has to be stored on the MHP terminal. For more information
on root certificates please refer to the KDB entry ”DVB Root Certificates,
costs and rights” (solution 85).
Page 105 of 215

30th March 2006
11.2.4 Example of a signed MHP application

Figure 11-1 shows an example of a signed directory tree that contains a
MHP application realizing a new sticker. The application itself consists of
Java class files and data files.
The example shows that all directories in the tree contain the hash file
whereas the hash file in the root directory checksums the complete
directory tree. As explained in the sections above, the signature file
secures the root hash file and specifies the originator of the application.
The corresponding certificate file provides the chain of trust that connects
the signing entity with the root certificate known to the MHP terminal. In this
case only one entity has signed the application.
Figure 11-1: Example of a signed application [Hetzer 2001]

PKI
A system that enables
In practice, signing of an application respectively a certain directory tree users of a public
network to exchange
within an object carousel is accomplished by software tools. data securely and
The signing entity, usually the broadcaster, has to take this into account privately through the
use of a public and
when considering additional costs for signing. However, the major costs private cryptographic
that arise in the context of application signing are related to subscribing at key pair that is
an appropriate certificate authority. Further information can be found in the obtained and shared
next sections. through a trusted
authority.
Page 106 of 215

30th March 2006
11.3 DVB MHP Public Key Infrastructure (PKI)
11.3.1 Actors in the MHP PKI

This table provides a summary of the actors in the MHP security part and EXPERT-LEVEL
the roles they play in the PKI.
Actor Role
DVB Services It implements the DVB-MHP PKI:

SARL (cf. 5.3.11)
It issues certificates and keys in particular root
certificates
It provides the CRL and RCMM management
messages.
Certification = CA
Authority (cf. 5.3.12)
It creates, issues and manages the certificates.
Root CAs are part of the DVB-MHP PKI.
Application = DVB-MHP PKI subscriber

developer
Application developers can sign their applications
(cf. 5.3.2) using the key and certificates obtained at DVB
Services.
Broadcaster = DVB-MHP PKI subscriber

(cf. 5.3.4) A broadcaster can sign the applications delivered
over its network using the key and certificates
obtained with DVB Services.
It broadcasts management messages (CRL and
RCMM) provided by DVB Services.
MHP terminal = DVB-MHP PKI Root Embedding

vendor
The vendor embeds the set of root certificates,
provided by DVB Services, in the MHP terminal.
The vendor processes the management messages.
Table 11-1: Actors in the MHP Public Key Infrastructure
11.3.2 DVB Services Hierarchy

Figure 11-2: The DVB Services Hierarchy gives a good overview on how
the Public Key Infrastructure (PKI) that was developed for MHP is intended
to work. Certificate Authorities (CA) have been defined for the issuance of
the Root Certificates and of Certificates linked to MHP applications.
MHP Terminal manufacturer have to embed Root Certificates in their MHP
Terminals. Application Developers and Broadcasters will receive
Subscriber Certificates entitling them to digitally sign MHP applications and
attach Certificates to such applications for delivery to Terminals.
Page 107 of 215

30th March 2006
The DVB MHP PKI hierarchy is resilient because at each level the
Certification Services Provider operates two signing Certification
Authorities, each of which issues Certificates. A recipient receives one from
each Signing CA, an Active and a Substitute. In the case of Manufacturers,
the Root Certificates for the DVB MHP PKI hierarchy are embedded in the
MHP Terminals they manufacture. If one is compromised or otherwise
revoked, the Application Developer would be provided with the necessary
authorization to make use of the Substitute Root Certificate, which would
activate the Substitute hierarchy. The revoked Root Certificate is replaced
by a delivery of a new Root Certificate authenticated by one DVB MHP
Root CA and by the RCMM Signing CA which only uses its Certificate for
this purpose.
The DVB Services Infrastructure describes those entities under the direct
responsibility of DVB Services Sarl. These include the DVB MHP Root
CAs, the RCMM Signing CA and the DVB MHP Signing CAs. The DVB
MHP Signing CAs issue Certificates to entities outside the infrastructure,
Certificate Subscribers and Subordinate Signing CAs. These Subordinate
Signing CAs operate under their own Certification Practice Statements,
which must be however consistent with this CPS. The DVB Services
Infrastructure, together with these extensions, comprises the DVB MHP
PKI.
DVB MHP DVB MHP DVB MHP

Root CA #1 Root CA #2 Root CA #3
Signing CA Signing CA RCMM signing CA
Additional level Root

Certificates DVB MHP Signing CA certificates
& keys
Certificate Subscribers
MHP Terminal
Vendors
Application Developers Broadcasters
CRL,
RCMM MHP E2E
Signed applications MHP
Broadcast
Terminal
Chain
Figure 11-2: The DVB Services Hierarchy
CA: Certificate Authority

CRL: Certificate Revocation List (cf. 11.3.6)
RCMM: Root Certificate Management Messages (cf. 11.3.5)
Page 108 of 215

30th March 2006
11.3.3 DVB MHP PKI for MHP terminal Manufacturers

Manufacturers need to install a set of root certificates into their terminals in
order provide them with the possibility to authenticate the certificate
hierarchy files that are delivered with applications. Without these root
certificates the receiver is unable to run signed applications.
Currently there are three certificates that need to be installed, namely:
An active root certificate currently used to authenticate certificates.
A substitute root certificate that could be used to authenticate
certificates at a future date.
A special root certificate used to authenticate changes to the set of
root certificates stored in the receiver.
The process of updating these root certificates is triggered by information
delivered in a broadcast stream and the manufacturer should not need to
be involved in the update process.
Manufacturers need to obtain the set of root certificates from DVB Services
SARL by entering into the DVB MHP PKI Root Embedding Agreement.
11.3.4 DVB MHP PKI for Application Developers

Application developers need to sign applications that access restricted
resources in MHP terminals or which need to verify the integrity of the
application file tree for any other reason. The signing process for an
application requires the use of an asymmetric key pair (also known as a
public/private key pair) where the private key is securely managed under
the control of the authenticating end-entity. The DVB MHP PKI uses
cryptographic hardware tokens (usually a USB device or a SmartCard) to
protect the private key and these keys are normally generated by DVB
Services SARL as part of the certificate subscription process. This
certificate subscription process also associates the identity of the private
key owner with a certificate that contains the corresponding public key part.
Once application developers have received their private key token and
associated certificate, they can use these in conjunction with an
appropriate application-signing tool to create the additional security files
that authenticate their application on the receiver.
Application developers who need to sign applications need to obtain keys
and certificates from DVB Services SARL by entering into the DVB MHP
PKI Certificate Subscriber Agreement. As part of this subscription process,
the application developers need to provide proof of their identity and of their
right to broadcast applications over their chosen network(s). The
subscription agreement also requires the key owner to take appropriate
precautions to ensure the security of their keys and to inform DVB Services
SARL if the key is lost, stolen or otherwise compromised.
Note that only organizations that have been assigned MHP Organization
IDs may apply for subscription to DVB MHP PKI.
11.3.5 DVB MHP PKI for Broadcasters

Broadcasters take responsibility for the content that they deliver over their
network and, as such, may decide to take responsibility for signing
applications that they broadcast. In this case a broadcaster may need a key
Page 109 of 215

30th March 2006
pair and associated certificate of their own to sign applications in the same
manner as described for an application developer.
Broadcasters also have a responsibility to include management messages
to MHP receivers with each application that is delivered. These
management messages include lists of certificates that are considered
invalid (Certificate Revocation Lists) and changes to the root certificates
stored in receivers (Root Certificate Management Messages). The files that
contain these messages are available to broadcasters from DVB Services
SARL.
CRL (Certificate
11.3.6 Certificate Management Revocation List)
X.509 certificates may be revoked by the issuing certificate authority prior Contains a list of
to their regular expiration date. Possible reasons for that are that a certificates that have
broadcaster’s private key has been compromised or a broadcaster stops been revoked prior to
using a certificate authority. Each certificate authority publishes a list of their date of
expiration.
revoked certificates, called a Certificate Revocation List (CRL).
The CRLs are transmitted to the MHP terminals usually within the object
carousel. The possibility of using the interaction channel for the distribution
of the CRL files is also given but is in most cases not favorable due to the
limited availability of return channels in the user terminals.
When authenticating an application, MHP-terminals have to inspect the set
of CRL files periodically and cache the revocation information for future
use. During the validation process of a certificate chain, the CRL of each
certificate authority on the certification path is checked.
11.4 Authenticating applications in the MHP EXPERT LEVEL

Terminal
In order to authenticate an application, the MHP terminal has to carry out
the following steps:
Verification that the files contained in a directory are listed in the hash
file (located in the same directory)
Verification that the file contents and corresponding hash values in
the directory are consistent
Verification of all directories in the tree (ascending in the directory
structure), up to the directory that contains one or more signature
files
Verification of the signature provided in the signature file by using the
public key provided in the corresponding certificate file
Following the certificate chain contained in the certificate each
certificate in the chain has to be verified until the link to the root
certificate is found
If the certificate chain could be verified by using the root certificate stored
on the MHP terminal and none of the provided certificates were found to be
revoked, the application can be accepted as authenticated.
After going through this process, the MHP terminal has verified that the
application comes from a trusted entity and has not been modified after
signing.
Page 110 of 215

30th March 2006
It has to be noted that it is not necessary and also not desirable to sign all
files in a directory tree. This however means that the MHP-terminal has to
take care that in particular the class files whose code contains security
relevant instructions, are authenticated before execution.
11.5 Application Rights Model

As shown above, the rights that broadcast applications need to access
different resources in the MHP terminal have to be restricted in order to NOVICE LEVEL
protect the users and the MHP terminal against unauthorized behavior.
Based on the application policy model defined in PersonalJava and J2SE
[Morris 2005], MHP defines a number of new permissions that applications
need to use many features and resources of the receiver.
The MHP specification rules that the MHP terminal shall assign
permissions to applications by taking into account two sources of
information (compare chapter 12.6 of the standard [MHP 1.0.3]:
Permissions granted by the user in the preferences in the MHP
terminal
Permissions explicitly requested by the broadcaster within the
permission request file (PRF)
This principle distributes the power among the broadcaster and the user
and hence reduces the danger that an application carries out unauthorized
actions. The application is only permitted to carry out actions that fulfill both
conditions.
The third factor that influences the permissions an application is given is
the fact, if an application is signed or not. Only if an application is properly
signed – i.e. the permission request file can be authenticated by the
terminal – the permissions requested in the permission request file will be
assigned the application.
Unsigned applications or signed applications that cannot be authenticated
(e.g. because one of the certificates in the chain has been revoked) are
only given the default rights. The MHP-specification defines in section
11.10.1 [MHP 1.0.3] some default permission and restrictions.
In addition to permissions, the permission request file may also request
credentials. A credential is a right owned by a third entity and therefore has
to be certified by this entity. Credentials are therefore necessary e.g. if an
application wants to access data stored in the persistent storage that is
owned by another application.
The MHP terminal must decide if an application can be given a particular
permission in the moment the application queries the presence of this
permission for the first time or when the an application invokes an action
that requires the permission for the first time.
11.6 Other aspects

Since authentication of whole applications within the MHP terminal may be
time and resource intensive, it should be considered which parts of an
application have to be signed to ensure the desired level of security. As a
general rule it can be stated that media files should not be signed.
Page 111 of 215

30th March 2006
Handling of signed applications may get complicated in the case of content

updates. A news-ticker application like the example in Section 11.2.4 has to
be provided with regularly updated data files. But if one component of the
signed directory structure is modified, the overall checksum provided in the
“root-hash file” is not valid any more. The MHP terminal is no longer able to
authenticate the application when this is required (e.g. for a certain method
call). For further considerations on this problem please refer to the following
KDB entry: Solution 86 - “How to update content without resigning?”
Page 112 of 215

30th March 2006
12 Graphics, Text Presentation, Audio,

Video
Graphics, Audio, Video
12.1 Introduction
The provision of graphics, text audio and video is a substantial addition to
the traditional video/audio components. It provides various possibilities but
also adds complexity. In this chapter several of these possibilities are
examined with respect to MHP. Initially the concept of layers and Text Presentation
composition is introduced to give a better understanding of the abstraction
methods used in MHP.
12.2 Layers and composition concept

MHP terminals are hybrids between desktop computers and traditional TV-
receivers. Each screen on MHP compliant hardware provides three graphic
planes. These are from back to front, background plane, video plane and
graphic plane.
TV Viewer
Background plane Graphic plane

Video plane
Figure 12-1: Graphic Planes in MHP
The MHP platform allows these planes to be blended using some of the
Porter-Duff alpha composition rules. Figure 12-2 illustrates the Porter-Duff
alpha composition rules.
Page 113 of 215

30th March 2006
Figure 12-2: Porter-Duff Alpha Composition Rules 28
In addition to alpha composition MHP has optional support for HAVi mattes.
As briefly explained, the MHP Platform provides a good foundation for
building applications with advanced graphic layout, look and functionality.
12.3 Playable media
NOVICE LEVEL
12.3.1 Java Media Framework 1.0
The Java Media Framework 1.0 was published 1998 by Sun, Silicon
Graphics and Intel for enabled Java applications to manage time-based
media content. It provides interfaces and classes to access media content
in a standardised and platform independent way.
It provides classes for providing the content (DataSources), for rendering
(Player) and for controlling the playback of the media (Controls). The
Player is also responsible for fetching the data from the source,
synchronising the media (audio and video) by a clock and provides a visual
component which contains the decoded video.
An application has only to create a Player object by specifying the URL of
the media source, add a ControllerListener and start the playback.
The ControllerListener is necessary, because the JMF itself is
working asynchronous and sends events if a state change (e.g. player is
ready for rendering) occurs.
12.3.2 Java Media Framework 2.0 NOVICE LEVEL

In 1999 the Java Media Framework [SUNJMF] was extended by Sun and
IBM to provide also features like manipulating media content in a Java
application. Therefore also the rendering of the content is encapsulated into
a DataSink as well as the access to the media stream in a Processor.
Even if the media content playback is as easy as in JMF 1.0, the new
technique enables the application developer to connect a DataSource
28
http://en.wikipedia.org/wiki/Alpha_compositing
Page 114 of 215

30th March 2006
with an own Processor for changing a part of the content and providing
that to a DataSink.
To access the media data by Java it is necessary to decode, stream and
rendering the complete media information in Java. This slows down the
processing speed of media content on small devices. For Java applications
that playback time-based media content completely with in Java, a powerful
device like a PC is currently necessary.
NOVICE LEVEL
12.3.3 Java Media Framework on MHP terminals
MHP implements only Java Media Framework 1.0, because the DataSink
PVR (Personal Video
and Processor concept of JMF 2.0 is too heavy for today’s MHP Recorder):
terminals. Normally the main source of media is the media content in the
A PVR is a receiver
DVB stream. The media cannot be rewind or fast-forward – except the equipped with storage
MHP terminal implements the special PVR extension. Also the media can for recording digital
be delivered by files in the DSM-CC. media and an
appropriate user
On MHP terminals the implementations of the Control interface need not interface that also
to return a Component for the graphical user interface. Also the visual allows scheduling
automatic recordings.
component of a Player may return null if no such component is available
on the MHP terminal. But if a MHP terminal returns a Player, then it must
support it completely. In addition, the Player must not return a
GainControl, which is used to change the audio volume.
In addition to the standard JMF there are some extensions like controls for
accessing MHP specific features (e.g. selecting another language for the
subtitling) or special events for signaling the Player’s state of a
DripFeedDataSource.
12.3.4 Media flow NOVICE LEVEL

The media processed by JMF on a MHP terminal will be provided from a
DataSource and processed as well rendered by a Player. Normally the
necessary source and player objects for the selected service are created
automatically.
If the creation of an own DataSource is necessary, the Manager class
can be used by specifying a MediaLocator or an URL. The
MediaLocator or URL describes the requested source and the Manager
tries to return a DataSource object that can handle the referenced media.
To create a Player object for a DataSource constructed by a
MediaLocator/URL, the Manager provides a method that returns a
Player depending on the specified DataSource or MediaLocator/URL,
if a MediaLocator/URL is specified instead of a DataSource.
If a Player is available, then it can be started, stopped and closed. For
Player created by the MHP terminal itself, these methods shouldn’t be
invoked, because they can result in undefined behavior of the displayed
video content.
12.3.5 Media player and available controls NOVICE LEVEL

The Player object is a MHP terminal specific implementation of the
Player interface. It provides possibility to add listeners to the Player but
Page 115 of 215

30th March 2006
the access to all Control objects available for the currently selected
media is most important function. With the method for getting the
Controls of the Player, the media content can be accessed and
modified, for example the size of the displayed video can be altered or the
selected language of the audio can be changed.
The Control classes which are supported or introduced by MHP are
listed in the sections below. But all instances of Player support all
Control classes. If a Player only supports a subset of the Control
classes available by MHP, then the Player only returns the Control
classes it supports itself.
12.3.5.1 LanguageControl
This is the base interface for all Control classes dealing with language
related content. It allows retrieving the available languages for the content
as well as the selection of a specific language content or the default
language content. A Control doesn’t implement this interface directly, but
one of its sub-interfaces: AudioLanguageControl or
SubtitlingLanguageControl.
For selecting a language, the ISO 639 code must be used. If the service
contains more than one component with the same ISO 639 language
identifier, then the first signaled component with the requested identifier will
be selected. To select another component with the multiple used ISO 639
identifier the MediaSelectControl must be used.
12.3.5.2 AudioLanguageControl
The AudioLanguageControl is responsible for select the audio
language. If a service contains more than one audio component with
different languages, then the audio can be changed through this Control
by using the language ISO 639 specification.
12.3.5.3 SubtitlingLanguageControl
To control the language of the service’s subtitling, this Control can be
used like the other LanguageControl classes. In addition to the selection
of the language to display, the SubtitlingLanguageControl also
allows the retrieval of the subtitling state as well as a method to switch the
subtitling on or off.
12.3.5.4 SubtitlingEventControl
SubtitlingEventControl is a sub-interface of the
SubtitlingLanguageControl and therefore it inherits the functionality
of the SubtitlingLanguageControl. But it extends it by the possibility
to observe the state-changes of the subtitling. If the subtitling is switch on
or off, the subtitling status changed method of the listener is invoked which
itself has to check the current state of the subtitling by retrieving the
information from the Control’s isSubtitlingOn() method.
12.3.5.5 VideoPresentationControl
The VideoPresentationControl is used for retrieving information
about the capability of the video positioning, scaling factors for video resize,
check for support of scaling and clipping as well as the possibility to modify
the clipping region. Changing the video’s size is possible with either
Page 116 of 215

30th March 2006
BackgroundVideoPresentationControl – which is a sub-interface of

VideoPresentationControl – or AWTVideoSizeControl.
12.3.5.6 BackgroundVideoPresentationControl
As a sub-class of VideoPresentationControl it inherits the retrieval as
well as the clipping functionality but extends it by the possibility to retrieve
and alter the video’s location and size. The new location and size of the
video is specified as a VideoTransformation, which itself uses float
values in the range 0.0 up to 1.0 for representation. So, the
VideoTransformation is independent of the TV’s real pixel-resolution.
A MHP terminal needn’t to support any location or size of the video. MHP
terminals are allowed to support only the video to location on even lines for
interlaced video or to only support as video sizes a quarter as well as full
size. For MHP applications it is possible to check how the video will be
changed for a specific VideoTransformation by using the method
getClosesMatch().
12.3.5.7 AWTVideoSizeControl
With AWTVideoSizeControl the location and size of the video can be
changed, like it is possible with the
BackgroundVideoPresentationControl. The only difference is, that
the AWTVideoSizeControl uses the screen's co-ordinate system instead
of the normalised co-ordinate system of the
BackgroundVideoPresentationControl. Also the
AWTVideoSizeControl has the possibility for retrieving the location and
size a video on the screen for the location and size the application want to
set. Like it is described for BackgroundVideoPresentationControl,
the MHP terminal needn’t to support any location and size but at least the
location on even lines as well as quarter and full size of the video.
12.3.5.8 VideoFormatControl
For video content different video formats are supported. The aspect ratio of
the MPEG-2 video can either be 4:3 or 16:9. To enable the MHP
application to retrieve the video format of the Player, the
VideoFormatControl can be used. This Control is only available for
retrieving information, the manipulation of the video format isn’t supported
by the Control.
12.3.5.9 MediaSelectControl
The MediaSelectControl used for selecting the components of the
service, like the video and audio, to be processed by the Player. It allows
the selection and deselection of service components as well as the retrieval
of the currently selected components. A listener can be registered to
observe the result of the selection process.
With the MediaSelectControl it is possible to select other than the
default video and audio components by the application.
12.3.5.10 DVBMediaSelectControl
To enable a MHP application to select a different kind of content into a
running Player, the MediaSelectControl is extended to the
DVBMediaSelectControl.
Page 117 of 215

30th March 2006
12.3.5.11 FreezeControl
With FreezeControl it is possible to stop the decoding of the media
content. After freezing the content the last decoded video frame is still
visible and the audio is stopped but the time base of the media isn’t
stopped. When the media playback is resumed, it isn’t defined at which
point of the video and audio transmission the presentation of the content
restarts. For broadcasted content on MHP terminals without a PVR
functionality most likely the currently received media content will be
presented. On MHP terminals with PVR functionality this could be different,
because the media content received while the Player was frozen can be
stored.
12.3.5.12 GainControl (optional)

The GainControl needn’t be supported by a MHP terminal, but if a MHP
implementation returns the GainControl for a Player, then it must be
supporting the control of the volume. It is possible to change the volume
between mute and, as maximum 1.0, the volume level when application
was started.
12.3.5.13 CachingControl (optional)

An MHP implementation needn’t to contain the CachingControl, but it is
allowed to support it. If an MHP terminal returns a CachingControl, then
it must support it as described in the JMF specification. The
CachingControl is available for media content, that is downloadable,
which for broadcasted content in a normal MHP terminal isn’t possible.
Therefore MHP application must be in aware of the fact, that this class
doesn’t exists on the MHP terminal.
12.3.5.14 MediaTimePositionControl (for audio clips only)

For playback of audio clips the MediaTimePositionControl is
supported to control the timeline of the audio clip. If the MHP application
sets another media time position, then the audio clip will as soon as
possible start the playback at the specified timeline position.
The MediaTimePositionControl is not supported for broadcasted
audio.
12.3.6 Obtaining a player and controls NOVICE LEVEL
Access to the Controls is only possible by getting the Player first. The
Player can be retrieved from the service context of the Xlet. As soon as
the Xlet has it’s service context, it can get an array of all
ServiceContentHandlers bound to the Player and check if one
ServiceContentHandler in that array is an instance of Player.
Player p = null;
try {
ServiceContextFactory scf = ServiceContextFactory.getInstance();
ServiceContext sc = scf.getServiceContext(xletContext);
Page 118 of 215
30th March 2006
if (sc != null) {
ServiceContentHandler[] sch = sc.getServiceContentHandlers();
for (int i=0;i<sch.length;i++) {
if (sch[i] instanceof Player) {
player = (Player) sch[i];
break;
catch (SecurityException e) {
e.printStackTrace();
After the Player is found in the ServiceContentHandler array of the

service context, the getControl(String) method must be used for
obtaining a specific Control from the Player. As parameter the fully
qualified class name of the requested Control must be specified. If the
Player doesn’t support the requested Control, null will be returned,
otherwise a reference to the Control will be returned.
if (player != null) {
AWTVideoSizeControl vsc = (AWTVideoSizeControl) play-

er.getControl(“javax.tv.media.AWTVideoSizeControl”);
if (vsc != null) {
...
12.3.7 Selection of audio components with

AudioLanguageControl
First action is to retrieve the AudioLanguageControl from the Player
like it is described in 12.3.6. When the Xlet has the NOVICE LEVEL
AudioLanguageControl object, then the list of available audio
languages can be acquired from the control. If no audio language is
available, then an array with length 0 is returned.
Page 119 of 215

30th March 2006
To select one audio language, the method selectLanguage(String) of

the AudioLanguageControl can be used. The parameter is the ISO 639
representation of the language to select, as it is included in the above
array.
If more than one audio language stream with the same ISO 639 identifier is
available, then the first signaled audio stream of the network is chosen. To
select an audio language stream which has the same identifier as another
audio stream and is therefore perhaps not selectable by the
AudioLanguageControl, the MediaSelectControl must be used.
AudioLanguageControl alc = (AudioLanguageControl) play-

er.getControl("org.davic.media.AudioLanguageControl");
if (alc != null) {
String[] availableLanguages = alc.listAvailableLanguages();
if (availableLanguages.length == 2) {
try {
alc.selectLanguage(availableLanguages[1]);
catch (LanguageNotAvailableException e) {
catch (NotAuthorizedException e) {
A more generic way of selecting audio streams – and therefore audio

languages – can be performed with the MediaSelectControl (see also
chapter 12.3.9).
NOVICE LEVEL
12.3.8 Selection of subtitles with
SubtitlingLanguageControl
To get access to the SubtitlingLanguageControl the according
Player object must be retrieved first (for further details see 12.3.6). The
SubtitlingLanguageControl can be used to get the list of available
subtitling languages as String array with ISO 639 identifier. Also the
Page 120 of 215

30th March 2006
wanted subtitling language can be selected, the status of the visibility of the
subtitles retrieved as well as the subtitles switch on or off.
The selection of a subtitling language won’t change the visibility state of the
subtitles. So if the subtitle is switched off, then the selection of a subtitling
language won’t switch it on. This must be performed additionally by using
the setSubtitling(boolean) method.
To select one subtitling language, the method
selectLanguage(String) of the SubtitlingLanguageControl can
be used. The parameter is the ISO 639 representation of the language to
select, as it is included in the array of available languages.
If more than one subtitling languages with the same ISO 639 identifier is
available, then the first signaled subtitling of the network is chosen. To
select a subtitling language which has the same identifier as another
subtitling and is therefore perhaps not selectable by the
SubtitlingLanguageControl, the MediaSelectControl must be
used.
SubtitlingLanguageControl slc = (SubtitlingLanguage-Control) play-

er.getControl("org.davic.media.SubtitlingLanguageControl");
if (slc != null) {
String[] availableLanguages = slc.listAvailableLanguages();
if (availableLanguages.length == 2) {
try {
slc.selectLanguage(availableLanguages[1]);
slc.setSubtitling(true);
catch (LanguageNotAvailableException e) {
catch (NotAuthorizedException e) {
A more generic way of selecting audio components – and therefore audio

languages – can be performed with the MediaSelectControl (see also
chapter 12.3.9).
Page 121 of 215

30th March 2006
12.3.9 Selection of media with MediaSelectControl

EXPERT LEVEL
To select specific media content –video, audio or subtitles – the
MediaSelectControl can be used. It can be used to select a bunch of
service components to a Player object. If a service contains more than
one component per media type (e.g. video or audio), then only the signaled
default component of the media type will be automatically selected by the
MHP terminal. When this control is used the combination of service
components to select can be different to the signaled default.
As first action the MediaSelectControl must be obtained from the
Player. The MediaSelectControl provides a method for retrieving the
current selection, which returns an array of Locators identifying the
selected service components. It is possible to remove, add or replace
components of the current selection.
MediaSelectControl msc = (MediaSelectControl) play-

er.getControl("javax.tv.media.MediaSelectControl");
if (msc != null) {
Locator[] selectedLocators = msc.getCurrentSelection();
if (selectedLocators.length > 1) {
msc.remove(selectedLocators[0]);
try {
synchronized (this) {
wait(10000);
catch (InterruptedException e) {
msc.add(selectedLocators[0]);
In the above example the first component of the current selection will be
removed so that the playback of the media – video, audio or any other
component which is at index 0 in the array – stops. The rest of the selected
Page 122 of 215
30th March 2006
components are still running and won’t be stopped. After 10 seconds the
removed component will be added to the current selection, so that the
removed content reappears.
12.4 UI components overview/main HAVI components

The scope for this section is the HAVi 29 Level 2 GUI API. The HAVi Level 2
GUI API is the section of the HAVi Specification that is adopted by the MHP
Specification. The HAVi Level 2 GUI API is only a part of the full HAVi
Specification that defines a full APIs for Home Audio-Video devices.
12.4.1 Main HAVI components

In a well designed and factored Java API it is important to understand the
base classes, abstract classes and interfaces. Most design patterns in Java
involve some or all of these abstractions. It is this abstraction that provides
the structure and flexibility that the API designers have chosen for the API.
This section will explain some of these abstractions and provide an
overview of the core components in the HAVi Level 2 GUI API. Some
concepts will be visualized using UML 30 class diagrams. Because the UML
notation might be unfamiliar to some readers, introduction notes are used
to explain the notation elements when first introduced in the diagrams. The
notation follows the guidelines from book “UML for Java™ Programmers” 31
chapter 3 “class diagrams”.
12.4.2 HComponent and HContainer
Figure 12-3: HComponent and HContainer (a)
29
HAVi - Home Audio-Video Interoperability. See http://www.havi.org
30
Unified Modeling Language. See http://en.wikipedia.org/wiki/Unified_Modeling_Language
31
ISBN: 0131428489
Page 123 of 215

30th March 2006
HComponent is the base class for all MHP classes that paints on the
screen. HComponent is an abstract class specializing the class
java.awt.Component. HComponent extends the java.awt.Component with
features for alpha compositing 32 trough the HMatteLayer interface. In
addition to this, HComponent implements the TestOpacity interface.
TestOpacity is a simple interface that allows all HComponents to be
queried for opacity.
Figure 12-4: HComponent and HContainer (b)
HComponent participates with HContainer in a composite design pattern 33 .

This means that HContainers can be composed by HComponents and
since HContainers are HComponents (see figure above) nested component
structures can be constructed. This composition mechanism is provided by
Java AWT because HComponent extends the AWT Component class and
similarly the HContainer extends the AWT Container class.
Because HComponent and HContainer are subclasses of the normal Java
Container and Component classes, they can be used anywhere the normal
Java Container or Component can be used. In fact any instances of
Container or Component returned by the MHP middleware will be instances
of HContainer and HComponent.
In addition to the interfaces HMatteLayer and TestOpacity, which the
HComponent also implements, HContainer implements the
HComponentOrdering interface. HComponentOrdering is an interface that
supports the manipulation of the z-ordering of the composed HComponents
and/or HContainers.
32
In computer graphics, alpha compositing is often useful to render image elements in separate passes, and then
combine the resulting multiple 2D images into a single, final image in a process called compositing. See
http://en.wikipedia.org/wiki/Alpha_compositing
33
http://en.wikipedia.org/wiki/Composite_pattern
Page 124 of 215

30th March 2006
12.4.3 HVisible and HLook
Figure 12-5: HVisible and HLook
The API states “The HVisible class is the base class for all non-interactive
components”.
As shown above the HVisible has an association that allows zero or one
reference a HLook object. The idea is that certain layout and presentation
logic can be delegated to a HLook object. The bright reader might have
noticed that HLook is an interface, and interfaced it is not allowed to
contain anything besides method definitions and static constants. So
HVisible will contain a reference to a class that implements the HVisible
interface and thereby meet the requirement by HVisible. HAVi comes with
several classes implementing the HLook interface, just ready to be plugged
into Hvisibles. Developers that need a specific customized Look can
implement their own classes that implements the HVisible interface. There
are two Interfaces that specializes the HLook interface by defining
additional methods. The two sub interfaces are HAdjustableLook and
HExtendedLook. For more information on these interfaces see the MHP
Specification. The concept presented here, where presentation logic can be
34
changed at runtime, is an example of the strategy design pattern .
Layout of HVisible can be controlled by LayoutManagers. If a layout
manager is associated with the Container into which a HVisible component
is placed, the size and location of the component will be controlled by the
layout manager. The HLook interface also plays a role when it comes to the
layout mechanism.
This is because the HLook interface specified the methods:
java.awt.Dimension getMinimumSize(HVisible hvisible)
34
http://en.wikipedia.org/wiki/Strategy_pattern
Page 125 of 215

30th March 2006
java.awt.Dimension getMaximumSize(HVisible hvisible)

java.awt.Dimension getPreferredSize(HVisible hvisible)
These methods are also implemented by the java.awt.Component class.
Exactly these methods are used by LayoutManagers when the component
layout computed. The reason for their presence in HLook is that a new look
may require other dimensions for proper presentation. E.g. a border may
be added to components requiring the HLook implementation to add the
extra with necessary to paint the border. In that case the HLook
implementation will implement methods listed above and return a
java.awt.Dimension object with the appropriate size. So these methods
participate in the strategy design pattern mentioned above.
The HState interface does not define any methods, but encapsulates
constants for component states which are used in the various HVisible
setContent and getContent methods to indicate which state the specified
content is to be set. HState is therefore not a usual interface in that it is
merely a utility container for static constants.
HVisibles can be in different states and component behaviour changes with
the state. For more information, see the HAVi [HAVI] and MHP
Specifications e.g. [MHP 1.0.3].
12.4.4 Other considerations using HAVI

In general it can be recommended using the GUI Widgets available on the
MHP Platform. The reason is that fewer classes need to be in the
broadcast stream providing faster start uptimes for applications. But since
the MHP middleware implementations are interpretations of the MHP
Standard, there can be deviances in the HAVI component default values
across different implementations. Solution 13 in the MHP KDB “Careful use
of HAVI widgets” explains this issue in greater detail, but the conclusion is
to explicitly specify default values in the code instead of relying on the
implicit values. A middle course to common behavior across set-top boxes
is to extend the HAVi base classes as explained in the previous sections.
12.4.5 Input events and exclusive registrations on input

event
The MHP GUI event model is based on the Java AWT event model. The
Java AWT event model has been designed to suit GUI environments where
a window manager 35 exists. This does not directly suit the MHP Platform
where no window manager exists. So the task managed by the window
manager needs to be managed by the MHP middleware. In Java AWT the
focused window has the input focus from the keyboard. In MHP the typical
user input device is a remote control. Therefore the MHP middleware
provides a mechanism allowing applications to request input events focus.
35
A window manager is software that controls the placement and appearance of applications on modern
computers with graphical user interfaces (GUI). See http://en.wikipedia.org/wiki/X_window_manager
Page 126 of 215

30th March 2006
12.5 Displayable graphics formats and restriction36

The picture formats JPEG and PNG can be represented in MHP by default.
The support of pictures in the GIF format is left to the equipment NOVICE LEVEL
manufacturer. The support of further formats isn't provided by the
specification. Depending on the used format mentioned above, the
representation possibilities are restricted.
All images transmitted shall be within the gamut encompassed by the
sRGB color space. Where possible this should be coded so that the
terminal does not have to translate. Where this is impractical, the sRGB
image may be transcoded into a different color space provided the gamut
assumption is not violated (q.v. JPEG).
Note: A picture is loaded asynchronously under MHP. This can have the
consequence that the picture and the picture information, such as the
picture measurements, aren’t confessed on time. The problem can be
avoided if the picture was already loaded before showing.
Below, a small code example is given for synchronous image loading:
public class LoadingImage extends Component{
//Produce instance of a picture.
Image image = this.getToolkit().getImage("image.png");
//Using the MediaTracker to check loading up process.
MediaTracker tracker = new MediaTracker(this);
//Registering the Image at the MediaTracker (ID=0)
tracker.addImage(image, 0);
try{
//Waiting until the image is loaded.
tracker.waitForID(0);
} catch (InterruptedException e){
//Image wasn't loaded completely.
…public void paint(Graphics g){
// The image can be immediately shown now.
g.drawImage(image,0,0,this);
36
ETSI TS 101 812 V1.3.1 (2003-06); Technical Specification, http://www.etsi.org (12/02/2005)
Wikipedia, http://www.wikipedia.de (12/02/2005)
Page 127 of 215

30th March 2006
12.5.1 PNG
PNG was designed as a free substitute for the older proprietary format GIF. NOVICE LEVEL
Unlike the JPEG format PNG uses a lossless compression. PNG can
process up to 256 colors from a color table (cf. 12.6). Furthermore, the
Alpha Channel
storage of grey level pictures is possible with 1, 2, 4, 8 or 16 bits and color
An alpha channel is
pictures (RGB) with 8 or 16 bits per channel (therefore 24 or 48 bits per additional information
pixel). PNG files can contain transparency information either in form of an in a picture file that
alpha channel or for every color of the color table. PNG supports alpha determines the
channels of 8 or 16 bits, what corresponds to 256 or 65536 graduations of transparency for every
pixel
the transparency strength.
The restrictions for the PNG format under MHP are described in section
15.1 of [MHP 1.0.2]. MHP terminals are required to support the entire PNG
color types define in PNG Specification Version 1.0. MHP terminals are
Chromaticity
responsible for mapping these colors to those used by the terminal's OSD.
Where PNG graphics use colors defined in the minimum color table these Contains hue and
color repletion
colors shall be reproduced correctly. Other colors shall be reproduced on a
"best effort" basis.
In addition, the MHP terminal will usually ignore gAMA (gamma) and cHRM
(chromaticity) chunks in PNG files. This may cause that the chrominance
and the brightness are not displayed correctly.
12.5.2 JPEG NOVICE LEVEL

JPEG is a method to the coding of digitized, colored images. Several
compression methods are in use whereas the following two are lossy:
Low-pass filtering of the color difference signal: The color difference Color Difference
signals are stored most in reduced dissolving. The signals are deep Signal
passport filtered and lower felt (in the simplest case by an averaging). Results of the coding
The fact, that the place dissolving of the human eye for colors is less of the RGB signal
sensitive compared to black-and-white transitions is also used for the from difference
data reduction. Through this, the amount of data can be usually formation between the
reduced by factor two. color signals red,
green and blue and
Quantization: The real data reduction is reached by the quantization. the signal of
This is the case at all lossy data reductions. By the quantization, a luminance. It doesn't
high information precision is changed by a reduced number of values contain information
into some less exact information. about the brightness
but only about the hue
These quality losses should be taken into account just like the following and the color.
one.
Color information lying in the RGB color space is transferred by the JPEG
compression into the YUV color space. This color conversion leads to color Low-Pass Filtering
purity errors if the origin color value does not have a comparable color This function enabling
value in the YUV color space. low frequencies to
pass through but
cutting out high
12.5.3 GIF frequencies.
GIF is a graphic format with a good lossless compression for pictures with
low color depth. This format supports animations in which per frame 256
colors can be used. The PNG format should be used instead of the GIF
format, because the support of this format is optional and GIF animations
are also not supported.
Page 128 of 215

30th March 2006
12.6 Color Table

It is the most natural way to encode the color information of a pixel to
indicate the values of the individual color channels directly in the data
structure of every pixel. This manner of the color addressing has, however,
a high storage requirement. There is a less memory-intensive method at
graphical data with 256 or less different colors which make use of a so-
called color table or color lookup table (CLUT).
All colors used in the picture are listed in the color table. Every entry de-
fines the values of the color channels of a color. The color table is saved
independent from the pixel data. The data of each pixel does not contain
the color itself, but it contains an index pointing to a entry in the color table.
The amount of the used storage for the index limits the maximum number
of usable table entries. For example: if the index storage is limited on two
bits, at most four colors can be indexed (cf. Figure 12-6).
0 0 1 2 3 Index Value
0 1 2 3 2
0
1 2 3 2 1
1
2 3 2 1 0
2
3 2 1 0 0 3
a) b) c)
a) This is the information of an indexed image.
b) This is the classification between the index and the color.
c) This is the image after the color assignment.
Figure 12-6: Example of a color table
The color depth of a grid graphic is often reduced to 256 or less colors in
order to save memory. The process of reducing the number of colors in a
picture by mapping them to a color table is called color quantization.
The color table used under MHP contains 139 opaque colors, 48 colors
with a transparency of 30% and 1 color with a transparency of 0% (see
figure below: Palette construction rules).
Page 129 of 215

30th March 2006
Transparency Alpha Additional Red Green Blue Number of colors

Grey Levels
(R=G=B)
0% 255 42, 85, 170, 0, 63, 0, 31, 63, 0, 127, 255 139
212 127, 95, 127,
191,
159, 191,
255
223, 255
30% 179 - 0, 85, 0, 51, 102, 0, 255 48

170, 153,
(*)
255
204, 255
100% 0 - - - - 1
Total 188
(*): Where the MHP terminal cannot implement this "ideal" value of semi-transparency it shall replace it with the
nearest value of semi-transparency it can implement. Note: semi-transparency shall not be approximated as either
0 % or 100 % transparency.
Table 12-1: Palette construction rules
Figure 12-7: Opaque CLUT
12.7 Differences between TV and computer screens NOVICE LEVEL

Interactive TV draws from both worlds – computer and television. This
results in a few problems, foremost about the pixel aspect ratio. Without
proper conversion the prepared images on a computer system are being
distorted on the TV screen. This is due to the different picture format used
by television, which employs rectangular pixels instead of square ones.
This applies for both NTSC and PAL systems, but in a different fashion.
PAL frames have a size of 720 by 576 Pixels which would equal a relation
of 4:3.2, not matching the TV screen aspect ratio of 4:3. NTSC frames are
720 by 486 in size, which comes out as 4:2.7. The resulting pixel aspect
ratios needed to compensate this effect are shown in Figure 12-8.
Page 130 of 215

30th March 2006
Figure 12-8: Comparison of pixel aspect ratios
Here are some examples on what happens when a computer image is

displayed on TV screens without prior conversion.
Computer screen (Original)
PAL 4:3
NTSC 4:3
PAL 16:9
Page 131 of 215

30th March 2006
EXPERT LEVEL
12.7.1 Calculation (PAL)
The widespread approach to convert computer images for interactive TV is
to squeeze the image by a factor of roughly 0.95:
A 4:3 aspect ratio image would equal 768x576 square pixels. To have 720
horizontal rectangular pixels covering the same width as the square ones,
they have to be 768/720 = 1.067 times wider than the square pixels. Thus
the pixel aspect ratio on the TV screen would be 1.067:1. This equals to the
amount that a square pixel gets stretched horizontally on a TV screen. To
compensate this stretching, we have to divide 1.067, equaling a scaling by
the factor 0.95.
The result is close, but it still is an approximation. This is due to the fact
that in digital video the active line width was increased meaning that we
have more pixels to the right and to the left which show actual image
content. A digital horizontal line has 720 pixels; an analogue line has only
702. The TV screen aspect ratio of 4:3 holds true only for 702x576 pixels.
When converting an analogue PAL video to PAL D1, the additional 18
pixels can be seen at the edges as black vertical stripes. True digital
equipment records full 720x576 pixel images, which equals a screen
aspect ratio of about 4.1:3.
So the final horizontal scaling factor is 702/768 = 0.914 for preparing
images for TV screens. Vice versa we have to use a factor of 768/702 =
1.094 for scaling TV images for computer editing (in case a correct aspect
ratio on the computer is needed).
12.7.1.1 Scaling for PAL 16:9 EXPERT LEVEL

PAL 16:9 is calculated likewise. The 702 x 576 image is stretched to this
aspect ratio. 16:9 in square pixels would be 1024 x 576. This results in a
scale factor of 1024 / 702 = 1.46. Or vice versa, to prepare computer
images for 16:9 TV they have to be horizontally squeezed by 702 / 1024 =
0.69.
Undoubtedly there is a loss of picture sharpness because of this procedure.
This is why the scaling should always be the last step of image preparation.
NOVICE LEVEL
12.7.2 Loss of sharpness
The following images show the loss of sharpness due to pixel aspect ratio
conversion. We assume that the image has the same vertical resolution
and a content image aspect ratio on all screens. Luckily the viewing
distance with TV sets is often large enough so that the human eye cannot
tell the difference; still this is a fact screen designers must be aware of.
Computer screen
Page 132 of 215

30th March 2006
PAL 4:3 screen
PAL 16:9 screen
12.7.3 Calculation (NTSC)

Calculations for NTSC are a little bit different. The format of a digital NTSC
D1 frame is 720 x 486, but the active area in 4:3 aspect ratio is 711 x 486
in size. With square pixels, the format would be 648 x 486, resulting in a
pixel width of 648/711 = 0.911.
We now know that square pixels will shrink on an NTSC TV Screen, so
they have to be stretched by 711/648 = 1.097.
EXPERT LEVEL
12.7.4 Overview of scale factors
This table shows the scale factors that have to be applied to convert
images for the TV screen and back while keeping the image’s aspect ratio.
Source Target Horizontal Vertical
Computer Screen 1:1 PAL 4:3 91.4 % 100 %
Computer Screen 1:1 PAL 16:9 69 % 100 %
Computer Screen 1:1 NTSC 4:3 109.7 % 100 %
Computer Screen 1:1 NTSC 4:3 100 % 91.1 %
PAL 4:3 Computer 1:1 109.4 % 100 %
PAL 16:9 Computer 1:1 146 % 100 %
NTSC 4:3 Computer 1:1 91.1 % 100 %
PAL 4:3 NTSC 4:3 101.3 % 84.4 %
12.8 Color conversion

Color conversion is done automatically by MHP terminals. Any image is
considered as being in the sRGB color space (the internet standard) and
correctly converted into the TV´s color space. The image’s color palette
Page 133 of 215

30th March 2006
gets mapped onto the minimum color set as described in the MHP
standard. However, the result varies greatly between terminals by different
manufacturers. Some boxes may implement full true-color support, while
others perform a dithering or just a nearest color match. Especially the
latter is very susceptible to color mismatch. This may still be acceptable
when the aim is to support also more advanced terminals. But if the
requirement is to play safe on all terminals, the color conversion should be
part of the production process already. An MHP compliant color palette can
be either downloaded or assembled by hand. The Color Lookup Table
(CLUT) for the minimum color support contains 139 opaque colors, 48
semi-transparent colors and one fully transparent color. Those colors are
not evenly spread over the full color spectrum, but there is an emphasis on
greenish colors, whereas red colors are weakly represented. Thus plants
can be displayed quite authentically, whereas skin colors may be very far
from the original tone after conversion. Quite often a mere nearest color
match will result in a color that has a close luminance value, but a totally
different tone. Original red values are often mapped on grey values that
spoil the image. Good photo editing tools generally allow for better
conversion than terminal built-in solutions.
The only solution to display near true color images on all devices is to use
MPEG-2 video drips. Those are images that are converted to I-frames. This
can be done with appropriate MPEG-2 encoding software and some image
manipulation programs. MPEG-2 does not use the whole 256 values a byte
offers in order to code the r, g and b values, but a range from 12 to 238. It
is important to make sure that the encoder matches the RGB black value of
0 to 12 in the MPEG-2 color space, likewise the 256 shall be mapped to
238 and all values in between accordingly. Note that most tools do this
conversion by default. This reduction also means a slight but inevitable loss
of contrast in the image. When TV footage is used as source for a drip-feed
it shall be considered that this is already converted to the MPEG-2 color
space, so the automatic conversion has to be turned off. Otherwise the
image will again lose contrast.
12.9 Double buffering

Double Buffer means that the screen storage of a graphics card is twice
available. Through this, the picture of an animation can be rendered in the
background which is at first invisible (back buffer). As soon as the picture is
requested, the ready picture as a whole is represented in the foreground
(frame buffer). Another picture can be rendered in the background and held
up for displaying next time. This technique is used to avoid a flickering and
a distorting effect on screens. This effect is being caused if the graphic is
displayed and will be written at the same time.
Some receivers support double buffering by default. Whether the receiver
supports double buffering can be found out with the following code lines at
run time:
//Creating of a standard HScene.
HScene hScene = HSceneFactory.getInstance().getDefaultHScene();
//Is the receiver supporting double buffering?
hScene.isDoubleBuffered();
Page 134 of 215

30th March 2006
If the receiver does not support double buffering, it is possible to try the
following resolution method, which creates a double buffering software
solution:
public void paint(Graphics g){
bufferDimension = this.getSize();
bufferImage = createImage(bufferDimension.width,
bufferDimension.height);
bufferGraphics = bufferImage.getGraphics();
//Rendering of the image in the back buffer.
bufferGraphics.drawImage(image,x,y,null);
// Showing the image which was already created in the back buffer.
g.drawImage(bufferImage,0,0,this);
12.10 Fonts
The MHP specification defines one common font for all MHP devices. The
font is called Tiresias Screenfont (see http://www.tiresias.org). It is
especially designed for the usage on television. No other fonts are
supported by default.
To keep the font in a compressed format the MHP member group decided
to use the portable font resource format. The format provides dynamic
usage. This enables application developers to upload and use own fonts on
the MHP device.
12.10.1 Generating fonts

In spring 1994 Bitstream announced a new font rendering system called
“truedoc”. This system records font shapes and stored them in a much
more compressed format. A very compact rasterizer makes the system
portable. It began to get very popular. One innovation was that the format
could be used to display any type of fonts in a web browser without using
images. Because of its portability the format got also famous in the Java
community. During the development of the MHP standard truedoc seems to
be the appropriate system for MHP terminals.
Bitstream provided a web-font toolset to create and save fonts in their new
format. The font format is called portable resource format (pfr). Soon further
companies like HexMac offered tools to edit and create fonts in the new
format too. Additional font converter, e.g. from the font format “true type” to
“truedoc” were available. This is now over 10 years ago.
Today the hype is over, HecMac disappeared from the market and
Bitstream doesn’t provide their web-fonts tools anymore. Currently it seems
to be nearly impossible to get any tool dealing with the portable resource
format, so the only possibility is to retrieve completed fonts directly at
Bitstream. However, only small number is offered for free.
Page 135 of 215

30th March 2006
If you want to create fonts by yourself, you have to develop your own font
creator or converter first. Therefore the specification of the portable
resource format version 1.0 (this version is used in the MHP terminals) is
available on the MHP Knowledge Database website related to the issue
“Creation of truedoc fonts”. Object carousel
The data structure
(containing
12.10.2 Generating the font index file applications, media
As mentioned it is possible to upload and use own fonts on an MHP files, etc.) that is
terminal. Therefore you have to include the fonts (stored in the truedoc broadcast within a
transport stream.
format) and a font index file in the object carousel. The index file has to be
placed in the root directory of the application (signaled in the regarding In the context of MHP
DSM-CC object
application information table).
carousels are used
The index file includes the description of the font like font name or location
of the font file. It provides the mapping between a font face name and the
file containing the font data. The file is called dvb.fontindex.. The XML
DTD defines the file syntax.
The XML index file contains a loop of all external fonts broadcast with the
application. Each font is defined by the following tags:
<name>: Contains the font face name of the font (e.g. "Helvetica")
<fontformat>: The file format of the font. For the PFR format used in the
MHP specification, this shall be "PFR".
<filename>: Relative path to the font file. This is relative to the directory
containing the font index file. The separator character for directories is "/".
As this is a relative path, it shall not begin with a "/" character.
<style>: The style elements contain the names of the styles of the font that
are contained in this font file. The possible values are "PLAIN", "BOLD",
"ITALIC" and "BOLD_ITALIC". There is one style element included per
style contained in the indicated font file, except when all the usable styles
of the font are in the same file in which case the style elements can be left
out. When different styles of the font are contained in separate files, these
are included in the directory as separate font entities with the same name
but different style and filename.
Just take a look at an example. It is very easy to generate a font index for
signaling own fonts.
<?xml version="1.0"?>
<!DOCTYPE fontdirectory PUBLIC "-//DVB//DTD Font Directory 1.0//EN"

"http://www.dvb.org/mhp/dtd/fontdirectory-1-0.dtd">

<fontdirectory>
<font>
Page 136 of 215

30th March 2006
<name>OzHandicraft BT</name>
<fontformat>PFR</fontformat>
<filename>org/mhpkdb/ui/OzHandicraft.pfr</filename>
<style>PLAIN</style>
</font>
<font>
<name>Zurich BT</name>
<fontformat>PFR</fontformat>
<filename>org/mhpkdb/ui/Zurich.pfr</filename>
12.10.3 Using external fonts

Using external fonts in a MHP application is quite simple. First of all you
have to put the font index file in the root directory of the applications. The
fonts, saved in the portable font resource format, have to be placed in the
directory given in the filename tag of the index file. The application can now
import this font with the FontFactory. The method createFont returns
the font object of the requested font. This could be used in the familiar way.
try {
/* load the file dvb.fontindex (mandatory filename) with the information about the
additional fonts by creating a FontFactory */
FontFactory fontbox;
fontbox = new FontFactory();
/* when the file dvb.fontindex was found and all entries were valid a FontFactory
was made above. Now Fonts can be created
Be aware of the following exception: If one font described in the font index
file is not in the object carousel the font factory will not work. It is only
possible to import fonts if the font index file is free of errors.
Page 137 of 215

30th March 2006
13 Return Channel
Return Channel
13.1 Introduction
The usage of the return channel allows improvement of the user NOVICE LEVEL
experience. By using the return channel it is possible to build truly
interactive applications in which the user signals information back to the
provider of the applications, this can be used e.g. for voting applications or
to control Video On Demand servers. With MHP 1.1 the return channel can
GSM (Global System
also be used to download applications; please consult chapter 9.4.3 for for Mobile
further information on this topic. Communications)
Most popular standard
for mobile phones in
13.2 Types of return channels the world.
There are basically two types of return channels: always on and connection GPRS (General
based. Depending on the type of return channel, an MHP terminal and/or Packet Radio
applications might have to implement different functionality to cope with the Service):
requirements set by the users. Mobile data service
available to users of
Each interface to a return channel is instantiated by an instance of the GSM mobile phones.
class RCInterface. Basic properties (type and speed) of the channel are
modeled in this class. UMTS (Universal
Mobile
Access to the return channel is managed by the RCInterfaceManager Telecommunications
class. System)
It is one of the third-
For the moment, a PSTN modem is integrated in most of the MHP
generation (3G)
terminals. Ethernet is also used when a high speed Internet connection is mobile phone
available. The mobile interaction channels are less common. The main technologies
technologies in this area are the GSM modem, which is in use comparable
with a PSTN modem and a GPRS connection, which is in use comparable ADSL (Asymmetric
with ADSL. Another option is the use of UMTS technology, which also Digital Subscriber
provides an always-on connection. Line)
Enables faster data
Using satellite technology as return channel is also a possibility. DVB-RCS transmission over
(DVB-Return channel satellite) offers a standardized solution however its copper telephone
use is not common yet. lines than a PSTN
modem, usually
several Mbit/s
13.2.1 Always-on return channels
PSTN (Public
Always-on return channels are that type of return channels for which the IP- Switched Telephone
connection is always present; examples include cable modem, xDSL or Network)
Ethernet. These technologies provide always-on connections and the user International
needs to have a subscription to the service from the ISP. An Ethernet telephone system
return channel will typically be used in combination with xDSL or cable based on copper
modem, the customer will connect the Ethernet port either using a hub or wires carrying
analogue voice data.
switch, or directly to the cable or xDSL modem. Typically these types of
return channels provide a high bandwidth pipe to the Internet and as such
IP (Internet Protocol)
can also be potentially used to stream audio/video. Note of course that the
The computer
speed depends also on the type of subscription with the ISP that is
networking protocol
providing the service. These always-on return channels do not use a dial used on the Internet
up modem.
Page 138 of 215

30th March 2006
13.2.2 Connection-based return channels

Connection-based return channels are that type of return channel for which NOVICE LEVEL
a connection needs to be established before the actual data-transfer can
happen. A typical example is a dial-up connection.
ISDN (Integrated
Applications need to have the proper right before a connection-based Services Digital
return channel can be used, this is to ensure only “trusty” applications Network)
make call attempt. It is a type of circuit
switched telephone
Only one application can control the dial up modem at a specific time. If an network system,
application tries to establish a connection while another application already designed to allow
uses one, the priority level of the application defines which application will digital transmission of
voice and data over
get the control.
ordinary telephone
If there is no activity on the return channel for a configurable amount of copper wires, resulting
in better quality and
time, the connection should be disconnected automatically.
higher speeds than
available with
analogue systems.
13.2.3 Detailed example
There are many possible network configurations covering the return
channel technologies such as PSTN, ISDN, cable, GSM, DECT and other DECT (Digital
interactive channel options. Enhanced Cordless
Telecommunications)
Issue 6 “How to use a connection based and/or permanently connected ETSI standard for
return channel?” in the MHP knowledgebase contains a fully worked out digital portable phones,
example (solution 75) that illustrates the different mechanisms that can be commonly used for
used to establish a connection and how to send data to a backend server domestic or corporate
purposes
using MHP.
13.3 Protocol overview

UDP (User Datagram
MHP defines the level of support for different IP-protocols. The level of
Protocol)
support depends on the profile and standard version.
It is one of the core
protocols of the
13.3.1 UDP Internet protocol suite.
UDP does not provide
MHP provides the usage of UDP based communication via the return the reliability and
channel. The communication established is bi-directional where information ordering guarantees
can be sent and received, this enables UDP based communications with
external UDP servers. This capability enables stateless connection oriented
communication, which are mainly adequate for example on multimedia TCP (Transmission
data, home control application and service discovery. UDP in itself does not Control Protocol)
have support for a reliable connection, (e.g. in case of packet loss). If
It is one of the core
reliability is important for the application, the application has to take care of protocols of the
this. (E.g. retransmission if needed) Internet protocol suite.
Using TCP,
Issue 29 “UDP communication” in the MHP knowledgebase provides applications on
example code on how to use UDP for sending and receiving data. networked hosts can
create connections to
one another, over
13.3.2 TCP which they can
exchange data. The
MHP provides the usage of TCP based communication via the return protocol guarantees
channel. The communication established is bi-directional where information reliable and in-order
can be sent and received, this enables TCP based communications with delivery of sender to
external TCP servers. This capability enables connection-oriented receiver data.
communication used by most of network application protocols such as
HTTP, SSL etc. It can also be used directly for data transmission. TCP
Page 139 of 215

30th March 2006
HTTP (Hypertext
provides for in-sequence reliable delivery. TCP is the main protocol that is Transfer Protocol)
used for transferring large chunks of data and is also used by other It is the primary
protocols like HTTP. method used to
transfer or convey
Issue 24 “TCP connection” in the MHP knowledgebase provides example information on the
code on how to use TCP for sending and receiving data. World Wide Web.
13.3.3 HTTP
MHP provides the usage of the Hypertext Transfer Protocol (HTTP) via the SSL (Secure Sockets
return channel. The communication chain is bi-directional. This facilitates Layer)
the user to get information from the World Wide Web and to send SSL and Transport
information to an HTTP Server. Layer Security (TLS),
its successor, are
Issue 64 “Possible use of HTTP” in the MHP-knowledgebase discusses cryptographic
how to establish an HTTP connection. protocols which
provide secure
communications on
13.3.4 DNS the Internet.
DNS (Domain Name System) is used to resolve Internet names (as

www.mhpkdb.org) to IP addresses (as 194.172.230.122). The other way
around is also possible, but is not used so often and not mandatory on an DNS (Domain Name
System)
MHP terminal. Using Internet names instead of IP addresses allows for
more flexibility and readability of server-identifiers. It can also be used to It is a system that
stores information
implement specific features (e.g. load balancing).
associated with
In order to be able to use DNS in an MHP environment a return channel domain names in a
distributed database
should be available and provide access to a DNS server. The IP address of on networks, such as
the DNS server can be configured automatically into an MHP terminal the Internet.
using DHCP or during PPP connection set-up. Manual configuration using
the build in menu system is also possible on most of the MHP terminals.
Issue 3 “DNS Look-Up” in the MHP Knowledgebase shows an example of PPP (Point to Point
how to use DNS lookup on an MHP terminal. Protocol)
Commonly used to
establish a direct
13.3.5 Protocol support connection between
In the MHP standard it is pointed out that the protocols defined provide two nodes.
support for IP over the interaction channel. Which protocols that are
supported, depends on the MHP version and the supported profiles. The
Enhanced broadcast profile does not provide any support for the IP
protocols. The tables below provide an overview of the support by the
Interactive Broadcast Profile and Internet Access Profile.
Page 140 of 215

30th March 2006
Protocol Interactive
O = optional Broadcast profile

M = mandatory
TCP M
UDP M
HTTP 1.1 O
DNS M
Table 13-1: MHP 1.0.x Protocol Support
Protocol Interactive Internet
O = optional Broadcast Profile Access Profile

M = mandatory
TCP M M
UDP M M
HTTP 1.1 O O
HTTP M M
(“MHP-HTTP 1.0”)
DNS M M
HTTPS M M
Table 13-2: MHP 1.1.1 Protocol support
13.4 MHP as client for Internet services & Integration

of contents received via return channel
MHP 1.0 does not define any Internet services that must be supported by
the MHP terminal itself. It is possible to develop MHP applications, that use
the return channel for sending and/or receiving data from the Internet by IP
and display the content by an own application. By developing an own
application, all Internet services based on IP can be brought to a MHP
terminal, but it has to be remembered, that such MHP applications can be
huge.
For MHP terminals implementing MHP 1.1 with Internet Access Profile 2
there are Internet services defined that must be supported directly by a
resident application of the MHP terminal. Such an MHP 1.1 terminal must
at least implement and provide an email client, a web browser as well as a
Usenet client. These clients must be also accessible and controllable by
MHP applications, so that a MHP application can use the email client to
Page 141 of 215
30th March 2006
create and send emails or embed the web browser to display HTML
content.
It is possible to integrate content received from a server via the return
channel. To display such content, an MHP application must be developed
and broadcasted to the MHP terminal. After the MHP application is started,
it can connect the return channel and receive data from a server. As soon
as the data has been received by the MHP terminal, the application can
render the data and display it on the TV screen.
13.5 Security on the Return Channel

The use of the return channel of a MHP terminal is restricted. Possible risks
are that an application deliberately or due to bugs in the code transmits Return Channel
private data unauthorized to a third party or dials up a premium rate Security
telephone number leading to high cost for the user.
The description of the return channel security in this section builds upon the
general security methods of MHP as treated in the Chapter 11.
Unsigned applications may not use the return channel at all. Signed
applications also may not access the return channel (by default) unless
otherwise specified by the permission request file. The syntax of the return
channel permission also provides the phone number that an application
may try to dial.
The return channel security in MHP goes one step further and requires
user interaction whenever an application – preconditioned it is properly
signed and equipped with permissions – builds up a return channel
connection: The terminal then has to ask the user to confirm or deny dialing
a certain phone number.
General purpose security for the return channel is provided by the
Transport Layer Security (TLS) protocol as described in [RFC 2246]. TLS (Transport
Layer Security)
An MHP application can establish a TLS session. This can be used for A cryptographic
sensitive transactions. In such a scenario, the application knows the server protocol, which
to connect to and can check that a given certificate chain contains the provides secure
expected certificate that it knows and trusts. communications on
the Internet. The
One or several TLS root certificates can be optionally broadcast along with successor of SSL 3.0
the application. The certificate files shall be authenticated members of the
same authenticated sub-tree as the application. Before a TLS connection
can be established, the MHP terminal has to ensure that the received
certificate list contains at least one trusted certificate. When there are no
TLS certificates sent with the application, the MHP terminal will
authenticate the above-mentioned signature and permissions and then
allow a connection to be established to any server.
For more information on return channel security confer to chapter 11 of
[MHP 1.0.3].
Page 142 of 215

30th March 2006
14 Equipment
Equipment
14.1 Playout systems
The Playout system is a vital part of any MHP enabled broadcasting
network. The role of the playout system is to convert MHP Xlets and data
into a DSM-CC carousel that can be received on MHP terminals.
NOVICE LEVEL
PSI
Management
Console
DSM-CC
MHP Playout Carousel
Remote API Server
Security
Figure 14-1: Typical MHP playout server interfaces
There are a multitude of different MHP Playout systems. A very

comprehensive list can be found in the MHP-KDB (issue 74 “What DSM-
CC Playout Systems are available?”, solution “Report on available DSM-
CC playout systems”).
The figure above is an attempt to show a typical MHP playout without being
vendor specific. The figure show common functions that may be included,
some are required.
The DSM-CC carousel is often a box with a DVB-ASI output and some
form of file and/or network based input interface. It can be a hardware
“black box” or an application running on a standard workstation architecture
utilizing a DVB-ASI PCI card to generate the final DVB-ASI signal.
The DSM-CC carousel is the most service critical part of the system and in
most cases it would be recommended to have some form of redundancy of
this module. Without the DSM-CC carousel all non-stored MHP application
will cease to function correctly. The DVB-ASI is usually connected to a
multiplexer to be multiplexed with other service content into the final
transport stream. There may be a matrix switch, distribution amplifier or
failover switch between the output of the DSM-CC carousel and the
multiplexer, this is dependant on the redundancy scheme used.
Some vendors provide a playout server separately from the DSM-CC
carousel. This server may provide additional functionality and interfaces in
addition to the pure DSM-CC functionality provided by the DSM-CC
carousel modules.
Page 143 of 215

30th March 2006
The role of the playout server will typically be to integrate the other
modules of the system. The server may have logic to create the required
AIT tables and ensure that the PSI subsystem is updated whenever the AIT
changes. It could also ensure that the security subsystem will sign and re-
sign applications whenever needed.
The security module is responsible for signing applications and could also
include functionality for certificate management. This is an area that seems
to be currently less mature than the core DSM-CC playout systems, and
the options are more limited in this area.
Most playouts have a configuration and management GUI that is used to
operate and supervise the playout.
A remote API (typically Java based) to control all relevant functions is also
fairly common.
14.2 MHP Terminal architecture

MHP terminal means all devices that fulfill the requirements of the MHP EXPERT LEVEL
specification. Indeed we can find STBs, but also PCs and IDTVs. Those
terminals are designed for reception and presentation of multimedia
STB (Set-top box)
content (audio/video, subtitles, etc.) and additionally to enable interactivity
(user can interact with an interactive applications). MHP Terminal to be
connected to a TV set.
This sub-section introduces the Hardware (HW) and Software (SW)
architectures of the MHP terminals, and presents each component.
To be MHP compliant the terminals have to pass the MHP test suite
provided by DVB group. All MHP compliant terminals have this MHP logo:
Figure 14-2: The MHP Logo
Page 144 of 215

30th March 2006
Figure 14-3 below represents an abstract view of the MHP Terminal

EXPERT LEVEL
hardware architecture:
Figure 14-3: MHP terminal hardware architecture
The MHP Terminal selects the appropriate broadcast TV information by

tuning to one of many input channels through the <TS selector>. The
signal is digitally modulated using Quadrature Phase Shift Key (QPSK) for
satellite applications, Quadrature Amplitude Modulation (QAM) for cable
and Orthogonal Frequency Division Multiplexing (OFDM) for terrestrial. The
information in the selected Radio Frequency (RF) channel is then
demodulated to produce a MPEG-2 Transport Stream (TS) containing the
audio, video and other information that relates to the selected TV program.
In general, digital TV information in the MPEG-2 Transport Stream may be
encrypted to prevent customers who have not paid for a particular service
from being able to view it.
The <Demux> filters audio, video and data contents in the MPEG-2 TS
according to the users selected service. When the MPEG2 TS is encrypted,
the <Demux> also decrypts the content according to special keys provided
by the <Conditional Access Unit> (e.g. SmartCard unit, common
interface module).
The <A/V Processor> then decompresses the audio and video information
and synchronizes them correctly.
Graphical content provided by the <Graphic Processor> and Audio/Video
content are then mixed and encoded in a specific displayable signal (e.g.
PAL/CVBS, PAL/RGB, HDMI 720p50 etc).
The <Remote Control> allows end users to control the behavior of the
MHP Terminal and interact with MHP applications.
MHP Terminals may also include a <Return Channel> access allowing to
send and to receive interactive data. Conventional telecommunications
modems are typically used in satellite and terrestrial MHP Terminals, while
cable ones generally have a cable modem.
Page 145 of 215

30th March 2006
The <CPU/RAM/ROM> controls the whole operation, performs specific

data manipulation functions and provide both volatile and non-volatile
memory access. It generally uses a real-time operating system (RTOS) on
top of a hardware abstraction layer for the management of the resources
and processes of the MHP Terminal.
14.2.1 Hardware requirements

This table below represents in function of each profile an approximation of INFORMATION
the hardware resource requirement.
Profile Used Processor Flash / RAM (MB) Other

(Mips) ROM (MB) Requirements
Enhanced 100-150 4-8 8-16

Broadcast
Interactive 100-150 ca. 8 16-32 Return Channel

Broadcast
Internet >150 8-16 >32 Return Channel

Access
Table 14-1: Hardware resource requirements
The MHP specifications [MHPKDB-1] define a minimum hardware

requirement for each version 1.0 / 1.1. In practice each manufacturer has a
specific implementation so that the value presented above gives a range
instead of precise values.
Page 146 of 215

30th March 2006
14.2.2 Conceptual view for Software architecture
EXPERT LEVEL
Figure 14-4: MHP terminal software architecture
In order to build the software architecture of a MHP Terminal, several

software components, possibly coming from different software suppliers,
are required.
Firstly, the <Hardware Abstraction Layer (HAL)>, the <Driver Layer>
and the <Operating System>, providing access to low level resources of
the MHP terminal, are generally coming from hardware vendors and/or
drivers suppliers.
In most cases MHP terminals include the CAS/DRM vendor specific
component <CAS/DRM> allowing to view non Free-To-Air content.
The biggest software part of the MHP terminal, often coming from a specific
middleware vendor, includes the <FW Loader>, the <Middleware
Implementation>, the <JVM>, the <MHP Implementation>, the <Native
Applications> and the <Porting API>.
The <FW Loader> is a crucial part of the MHP Terminal, wherewith the
MHP Terminal software can be upgraded later in the field. In particular, it
can be used to upgrade MHP 1.0.2 compliant terminals with MHP 1.0.3
upgrade.
The <Middleware Implementation> provides several digital TV services
allowing to support native applications (<Native Applications>) like EPGs
(i.e. Electronic Program Guide) and the MHP specific middleware (<MHP
Implementation>).
Although the <JVM> (i.e. Java Virtual Machine) is integrated with the
<MHP Implementation> and the <Middleware Implementation>, this
software component is generally coming from specific JVM vendors.
Page 147 of 215

30th March 2006
Middleware vendors define the <Porting API>. This part provides an

abstraction of low-level hardware dependent software parts and allows the
<Middleware Implementation> and others upper software components to
be portable.
<MHP Applications> represent all MHP applications software code that
can be downloaded and executed on the MHP Terminal. These
applications are generally designed by specific MHP Application suppliers
or directly by broadcast content providers.
You can find more details on the SW and HW requirements on the DVB-
MHP web site (http://www.mhp.org) and a list of available MHP terminals
on the KDB web site (http://www.mhpkdb.org).
14.3 Test equipment
14.3.1 IRT MHP Application analyzer

Scope
INFORMATION
The MHP Application Analyzer is a PC-based tool for performing
compliance checks and functional tests on MHP applications. It brings
broadcasters and software developers into the position of performing in-
depth analysis of their MHP applications.
After running the different Analyzing options, a detailed result protocol is
provided that enables to locate bugs or critical areas in the application.
Functionality
The Application Analyzer provides four different test analysis and test
functions:
Configure and Run: In this mode, the Application Analyzer executes the
application on the MHP without intervention. This function offers
comfortable configuration and handling options.
Static Checker: The Static Checker analyzes the bytecode by decompiling
it and evaluating all available information under the following aspects:
Java Bytecode Verification (Compliance with Java und VM
Specification)
Compliance with MHP Standard (used classes, methods, etc.)
Compliance with Security requirements
Evaluation of used resources
Dynamic Checker: The Dynamic Checker analyzes the behavior of the
MHP application under runtime conditions. The analysis comprises a
manual functional check, compliance check, resource monitoring, stress
test, profiling and others.
On Air Analysis: This provided the possibility to examine MHP Application

broadcast on a DVB network with regard to DVB SI Data and signaling.
Availability
The static checker of the MHP Application Analyzer is available for
registered users of the MHP-KDB as a part of the virtual test centre of IRT.
The Static Checker performs analysis of the java code with regard to
Page 148 of 215
30th March 2006
general errors as well as compliance checks against a particular MHP

Standard version.
After uploading their bytecode in form of .jar-archives to the MHP-KDB
server, users can choose between different MHP standard versions
(currently MHP 1.0.2, 1.0.3, and 1.1).
Once started, the static analyzer parses the bytecode and writes the
structure of the application (e.g. classes, methods, fields) in a temporary
file. After parsing the application, the static analyzer analyses the
temporary file for bytecode errors, warnings for unused fields/methods and
MHP compliance errors.
The user is then provided with a final result protocol. Details about handling
and operation of the Static Checker are given in the “IRT-Test Centre User
Guide”.
The full Version of the MHP Application Analyzer can be purchased at
Institut für Rundfunktechnik. For further information please visit their
website at http://www.irt.de and choose “products”.
14.3.2 Return Channel analysis tool

Scope
INFORMATION
The Return Channel Analysis Tool is distributed software integrated into
ITA’s Testing Environment. It offers MHP application developers reports of
the performance of their applications in the return channel.
Functionality Description
Once users have uploaded their application and configured the MHP
playout via the web, they will be able to configure different test scenarios by
selecting among the different alternatives that ITA’s Testing Environment
offer:
Broadcast chain: DVB-S, -T or -C (in the first implementation, only DVB-S
will be available)
Receivers: commercial STBs, PC based clients.
Return Channel: PSTN, xDSL, Cable or other access networks that may be
implemented or emulated. It will also be possible to configure in detail
some network parameters, such as downlink and uplink bit rates for xDSL
and Cable networks.
ISP & Backbone network: The behavior of the ISP and the backbone
network may be also configurable in order to emulate problems such as
packet loss, bottlenecks or connection failures, so that the performance of
MHP application in such situations can be evaluated.
After defining the test scenario, the user can select the measure points and
the parameters to be reported after test execution. Eligible measures will
be, among others, bandwidth usage, sent and lost packets.
During test execution, the tool collects the requested information at the
selected points of the return channel segment using SNMP, process this
information and report a detailed analysis, including graphics and statistics
of the application performance in terms of network aspects.
The return channel reports along with other useful information from the
testing environment (such as STB debug output) and a stream of the video
Page 149 of 215

30th March 2006
output of the selected MHP receiver is made available for the user via the
web.
Availability
The Return Channel Analysis Tool is integrated in the online test centre of
ITA and available for registered users of the MHP-KDB website. To obtain
return channel reports, users must run their interactive applications in this
test centre.
14.3.3 AIT / DSM-CC Analyzer and Compliance Tool

Scope INFORMATION
Panasonic provides an AIT and DSM-CC analyzer called Stream-Analyzer.
The Stream-Analyzer extracts certain streams and tables of a transport
stream and displays them in a tree on screen. The analyzer is able to:
Show the content of the tables PAT, PMT and AIT.
Show the content of the DSM-CC carousels.
Save the content of tables and DSM-CC carousels.
Check whether there are any inconsistencies in the signaling or in the
DSM-CC carousels.
The analyzer is written in Java to provide a platform independent tool.
Functionality
After program start the user can decide which transport stream he wants to
analyze. The transport stream should be compliant with the DVB–S or
DVB-T standard. Support of DVB-C is not guaranteed. After selecting the
transport stream packets will be loaded and all services including AITs or
DSM-CC carousels are shown with their application related tables and
elementary streams.
Now the user has two different options. On the one hand, he can select an
Application Information Table or a DSM-CC carousel from the list and
request the content. In the case of AIT he will get a table that lists all
information of the signaled applications like path, name, start modus, etc. In
the case of DSM-CC carousel he will get a tree that shows all directories
and files including in the carousel. Additional he has the possibility to save
the different contents
On the other hand the user can analyze an AIT or a DSM-CC carousel.
Among other things analyzing of an AIT will include the following:
Testing if the signaled DSM-CC carousel is available.
Testing if signaled class is available.
Check of the section layer.
Check if a class is auto start.
Check if only one class is auto start.
A DSM-CC carousel will be analyzed with respect to:
Availability of the gateway and all modules
Consistency of the directory structure
Other aspects.
Page 150 of 215

30th March 2006
Both analyzing an AIT and analyzing a DSM-CC carousel results in a test

report stored in a HTML file and shown on the screen.
The user can select again and again AITs or DSM-CC carousels to analyze
or to show them until he exits the application.
Availability
The Stream-Analyzer is available for download in the tools-section of the
MHP-KDB.
14.3.4 Loading Time Analyzer

Scope
This tool from tComLabs allows measuring the time to start an MHP INFORMATION
application. The start time is the time between the moment the application
is asked to run and the moment the application is in the active state.
Functionality
An Xlet is written to do these measurements. The Xlet is in fact a special
application launcher. It asks the application manager to load, initialize and
start an Xlet and measures the time that the receiver needs to execute
these tasks. The logger, written for the MHP-KDB code framework, is used
to report the test results.
Availability
The tool is accessible from the tools section of the MHP-KDB Portal. The
required class files have to be downloaded and put in an object carousel.
For detailed information please refer to the user manual that is provided
with the tool.
Page 151 of 215

30th March 2006
15 Usability
Usability deals with the relationship between services and tools and their
users. Usability
The broad acceptance of interactive TV services depends on a variety of
factors. A crucial one is that these services were tested with regard to their
usability. Usability is to ensure that users understand the created services
and users want to make use of them and know how to use them in the best
possible way. Usability
“Usability is a
When creating new interactive applications, the developer has to consider measure of the quality
that the viewer still focuses on TV and that television is a medium for of the user experience
entertainment, while interactive applications are regarded as additional in interacting with
services. Watching TV is a passive activity, while iTV services require something.”
(Jakob Nielsen)
some action from the user. The spectator is not used to interact with his TV
set except for switching TV channels and using the EPG and teletext. Usability is to ensure
user-friendliness and
In particular the MHP programmer must take into account legibility, layout –satisfaction,
and navigational aspects as well as the usage of colors in a well-advised efficiency of use, and
error prevention when
and moderate way. working with an
Aspect ratios are dealt with in detail in chapter 12 of this guide. interactive service.
The Usability and Style Guide in the KDB provides more comprehensive
information about these topics.
Page 152 of 215

30th March 2006
15.1 Layout and Design

The basic formal structure of a screen surface is defined by the layout. It
defines the different functional areas with respect to their position, size and
conciseness as well as the relationship of the areas to each other.
Moreover, it defines the arrangement and design of the single functional
areas themselves. The layout’s function is to provide a visual system
making it easier for the user to understand the application and to be able to
find his way through it. Thus the layout is specifically based on the laws of
design.
Figure 15-1: Typical Screen Structure of an MHP Application
Figure 15-2: Basic Formal Structure of a Screen Surface
Page 153 of 215

30th March 2006
15.1.1 As much as necessary, as little as possible

The extent of the functional area and the display area to be displayed by
the layout depends on the complexity of the application. The goal should
always be to use as few elements as possible and to develop a simple
layout. The fewer elements the user has to observe, process and learn, the
better.
15.1.2 Consistency
The developed layout scheme should be applied to all the pages of an
application or the bouquet if possible. This is the only way the user can find
his way quickly and easily. There can, of course, be an alternative layout in
some specific areas or a consciously created interruption of the layout at
specific pages. Interruptions of the individual layout scheme should be
consciously used as a stylistic device in order to irritate the user, to
misbalance him and to gain more attention to some specific pages. These
kinds of interruptions only work though if the user was made aware of a
stringent and consistent layout scheme until the disruption actually takes
place. If this is not the case, the whole page is entirely disruptive and the
visitor will sooner or later give up finding his way through the site [Noss
2003].
15.1.3 Screen Layout
Figure 15-3: Layout of a TV Screen
Research indicates that viewers scan television screens from the upper left
corner down to the lower right. This behavior is stronger with text heavy
interactive applications than with conventional broadcast because reading
habits come into play.
Because viewers exhibit the same eye movements in general, we know
that the upper left and lower right areas of the screen are privileged -
perfect for titles and logos, while the upper right and lower left are dead
spaces, in which objects and images are unlikely to be noticed. Combining
text, quarter-screen video and photographs can affect the viewer’s
interpretation of screen elements. In general, video and text content will be
perceived separately. Lengthy text content next to video will be ignored.
Titles and logos should go in the upper left corner for maximum impact.
Video sits most comfortably with text when placed in a dead area upper
right or lower left Navigation information related to the title (such as a
crumb trail) should ideally be positioned next to the title. Static information
such as time and date is least obtrusive in the dead areas of the page.
Page 154 of 215

30th March 2006
Universal navigational tools should be positioned at the bottom of the page

where the eye finishes reading [BBC, 2002].
15.1.3.1 Organize the Screen
Figure 15-4: Screen Organization
The left hand side is always privileged by European reading viewers. For
text services, stories should be positioned in the left side. For quarter
screen enhancements to video programming, the video should be on the
left hand side instead.
Use the top for navigational information about the current page content,
such as crumb trails.
Story title and content navigation must be physically part of the
content space
This area of the screen is high visibility and should not be used for
general or repetitive help instructions
Video tools and navigation can be located in an overlay over the
bottom of the video or in the space immediately underneath
Service wide instructions, color key prompts and helpful general tips
belong in the bottom of the screen
Instructions to turn the page or scroll through text content or a table
should always be placed at the bottom of the text/table, where the
eye finishes reading and looks for more
Every service is different and presents unique challenges and layout
requirements. The most important rule to remember is consistency.
Page 155 of 215

30th March 2006
15.2 Navigation
Good navigation means building a relationship between a visual interface
and the tools a viewer uses. The relationship is good if it supports the
viewers’ goals and desires in using a service, and not so good if it creates
additional obstacles to the viewer [BBC 2002].
To help the viewer, every navigational interface must aspire to several key
objectives:
Tell the viewer where they are, how they got there, and where they
can go next at any time
Provide feedback every time a viewer executes a command
Teach the viewer how to use the service in seconds
Relate to larger cultural mental models and metaphors
Present predictable and consistent navigational devices
Encourage freedom of movement rather than limited predetermined
paths, and provide quick escape in the form of an exit route, or near-
instant access to full screen video.
15.2.1 Remote Control Units
Figure 15-5: Remote Controls of MHP Terminals
Viewers use remote control units (in some cases extensive keyboards) to
make choices within interactive television services. Good navigation is
about providing a user interface that seems to instinctively teach the viewer
how to make the right choices by pressing the right buttons. In an ideal
world all viewers would have the same controls available to them and
interfaces could develop a standardized visual language. However, controls
differ enormously between - and often within - platforms. The layout and
Page 156 of 215
30th March 2006
labeling of keys on the remote can vary, or keys can be missing entirely
[BBC 2002]. Several functional groups of keys are, however, generally
available:
Traditional television controls
Number keys
Arrow keys and a select key
Color (Fastext) keys
Additional platform specific controls.
15.2.1.1 Traditional Television Remote Controls

Most set-top box remote controls incorporate keys to change television
channel, adjust the volume, and turn the power off and on. These keys are
not remapped to new functions within interactive applications. Once an
interactive application is launched, all of these functions should be
available to the viewer as usual. Several keys exist on remote controls for
both traditional and digital televisions, with slightly different uses. On
analogue televisions, the text key provides access to Ceefax, Teletext and
other analogue text services. On digital platforms it launches a digital
application which provides a similar but further customized service. Many
standard television remotes have an Info key which brings up an on screen
display. On digital televisions the Info key can be remapped to bring up
relevant additional information [BBC 2002].
15.2.1.2 Platform Specific Controls

Several remote controls have useful features that are not universally
available across all platforms. In some cases, for applications that are
specific to a particular platform and which have guaranteed access to these
extra features, the following keys can simplify the interface. Sometimes
keys can be remapped to application-specific functions, but generally they
can and should be used only as specified by the platform owners. For any
applications that are available across several platforms, interfaces must be
designed to take advantage of each, while ensuring all content is available
to viewers on all platforms. Although some of these keys are useful, user
testing indicates that viewers look for controls within the screen interface,
or for onscreen prompts. Viewers may not realize that special keys on the
remote can be used within an application [BBC 2002].
Common Examples are:
Back Up (Back): can be hierarchical or historical (taking users up a
level or back to the previous page), available on most platforms, but
not on terrestrial
Help: useful key that satellite viewers are accustomed to pressing for
help text across all services
Exit: a key that quits an application and returns the viewer to
standard broadcast on terrestrial
Page Up/Down: these keys scroll through content which is too long to
fit on a single page standard on cable and with systems for viewing
the web on TV
Previous/Skip: these keys move from one item to another and can be
used instead of the arrow keys available on cable and with systems
for viewing the web on TV
Page 157 of 215

30th March 2006
Full Keyboards: allow the user to enter text available on most

platforms as an option.
15.2.2 Interaction Design
Figure 15-6: Functions of a Remote Control
The MHP specification defines a minimum set of input events. These input
events define the MHP mandatory keys that have to be available on the
user input device of the MHP terminal (cp. Table 15-1).
Keys on the input device of

Input event
the MHP terminal
VK_0 to VK_9 10 number keys

VK_UP
VK_DOWN
4 arrow keys
VK_LEFT
+
VK_RIGHT
1 select key
VK_ENTER
VK_TELETEXT 1 key to access teletext

VK_COLORED_KEY_0
VK_COLORED_KEY_1
VK_COLORED_KEY_2 4 color keys
VK_COLORED_KEY_3
Table 15-1: Mandatory keys in MHP
Page 158 of 215

30th March 2006
Accordingly the MHP environment offers three possible ways of interaction:

by number keys [a]
by four color keys [b]
by four arrows keys and select keys [c]
With the aid of color and number keys, the direct selection of functions can
be performed. The navigation via arrow keys is suitable for the indirect
selection of functions via menu lists as well as for the skipping between
menus and paging. Be careful to apply as little as possible of the three LEGIBILITY vs.
methods on one screen at the same time [BBC 2002]. READABILITY
Legibility means that
writing can easily be
15.3 Legibility of Text deciphered and read.
Text poses difficult challenges on television screens, as viewers are not Readability refers to
accustomed to reading static blocks of text on screen and because the the comprehensibility
and the joy of reading
display quality of still images on television is poor [Noss 2003]. Careful
of a text.
attention also has to be paid to character shapes, to help distinguish similar
letters (such as upper case, lower case and the numbers) and to help with
the characters most commonly misread by the visually impaired (such as 6,
8 and 9).
Several rules can improve legibility on a TV screen:
Body text should generally not be smaller than 24 point
The text should under no circumstances be smaller than 18 point
Light text on a dark background is slightly easier to read on the TV
screen
Text on screen needs greater line spacing than in print
A full screen of text should contain a rough maximum of 90 words
A generally accepted practice is not to use more than three different
fonts
Be consistent in the use of fonts, e.g. use the same font for every
headline, the same font for text blocks, etc.
15.3.1 Legibility Examples

Here is a collection of positive and negative legibility examples:
Page 159 of 215

30th March 2006
Figure 15-7: Legibility Example 1
The font size in this sketch text is too small. The text field is very wide
which causes long lines. The line break, causing a change for the eye from
the end of one line to the next line, is favored by the large line spacing but it
is still difficult for the eye to perform. Thus this sketch text is difficult to read.
In order to improve legibility, the font size should first be enlarged. Then,
perhaps, line spacing and line length could be corrected.
Page 160 of 215

30th March 2006
In this script text the 18pt font size is well chosen. The text field is very wide
but due to the large font the line spacing is agreeable and the line break
from the end of one line to the beginning of the next line can be performed
very easily. The text is well legible.
In this script text the18pt font size is well chosen. The text field is very wide
but due to the large font the line lengths are agreeable. The line spacing is
too small though. This makes the text look quite packed and the line space
is difficult to perform. The text is only legible to a certain extent.
Page 161 of 215

30th March 2006
In this script text the 18pt font size is well chosen. The text field is narrow
but the line lengths are acceptable. The line spacing is relatively small but
due to the small lines the line skip can be performed easily. The text can be
read easily. The text uses almost two thirds of the surface. Thus on the left
side a piece of negative space is created meaning that surface is not used.
This is used in the upper part for the heading. A very calm and clear overall
picture is created. This is also due to the alignment of the text block and the
heading with the subtitle at the lower edge of the screen.
15.4 Recommendations for Using Colors

Use colors only as a supporting device for highlighting information and not
as the only device for coding because correct color reproduction or color
perception cannot always be guaranteed. Some people have problems
distinguishing between colors. Use little color as to not burden the user with
a visually overloaded surface on the one hand and to guarantee that the
colors used are sufficiently distinguishable on the other. The more colors
you use, the more information the user has to assimilate and the less
valuable and concise the single colors become. Certain combinations of
extreme colors should be strictly avoided. Television screens have a more
limited overall gamut than computer monitors and a much higher gamma
value, resulting in a high contrast, high saturation display. To achieve
similar intensity of color, images should be toned down and simplified when
taken from the computer to the television. Hot reds and oranges cause
particularly bad distortion and pure whites and blacks should never be
used. The strongest white for display on a television should be around 95
percent, or 240/240/240 in RGB terms. The darkest black conventionally
used is 5 percent, or 16/16/16. Strong color changes along scan-lines
cause a variety of distortions known as bleed or color shift. The change
from one strong color to another can cause overlap-ping strips to appear,
or a double exposure ghosting effect. With irregular shapes such as words
Page 162 of 215
30th March 2006
of text, color shift can cause spots or glows around bright objects. Because
these effects occur across the horizontal scan lines they are especially
pronounced at the vertical boundaries of objects. Intricate patterns should
be avoided as well. Moiré distortion is common on television sets when
regular patterns such as grids or dots are rotated away from true vertical.
Curves distort less than straight lines, and movement diminishes the impact
of all television display problems [SN HESS].
Figure 15-11: Examples of color combinations with poor legibility
15.5 Usability Studies and User-Centered Design

Successful services can sometimes be created by using usability rules of
thumb and trying to anticipate the user’s behavior. But experience shows
that users often do not accept what they are offered, because the user
needs were predicted wrongly. Much of the risk that lies in launching a new
service can be mitigated by using a user-centered design approach. It is
important to incorporate the feedback as well as the creative potential of
the later user as early as possible in the service design process.
It is often argued that the user cannot tell what he wants, because he does
not know what is possible with the new technology. This holds true only
partly. With the use of appropriate questionnaires the user can give us
hints:
What he does not want in a service
Which functionality he would add to the service
Which desires he has with respect to mobile communication
User-centered design is an iterative process, which involves several cycles
of conception and reworking of the service concept. In most cases, the final
result is a good deal away from the original scenario, which should be
consequently modified or even replaced according to the user comments.
The simplest way to incorporate user comments for every service launch is
to perform a usability study on a full-grown prototype and improve the user
interface accordingly. However user-centered design from scratch looks
different:
1. Invent a scenario
2. Have scenario commented by a user group
Page 163 of 215

30th March 2006
3. Rewrite or replace scenario

4. Repeat step 2 and three until a satisfying level of agreement is
reached
5. Design a clickable prototype
6. Evaluate the prototype with a professional user group not involved
in the project
7. Refine the prototype
8. Make usability study with target user group
9. Refine the prototype
10. Repeat step 8 and 9 if necessary
11. Implement service
12. Test service under real life conditions with target user group
13. Refine interface if necessary
14. Repeat 12 and 13 if necessary
15. Final service Launch
This guideline is only an example to emphasize that the user has to be

integrated in the process in every phase of the service development. The
key principles of User-Centered Design are listed by Gould and Lewis
[Gould 1995]:
Early Focus on Users and Tasks

First, designers must understand who the users will be. This understanding
is arrived at in part by directly studying their cognitive, behavioral,
anthropometric, and attitudinal characteristics, and in part by studying the
nature of the work expected to be accomplished.
Empirical Measurement
Second, early in the development process, intended users should actually
use simulations and prototypes to carry out real work, and their
performance and reactions should be observed, recorded, and analyzed.
Iterative Design
Third, when problems are found in user testing, as they will be, they must
be fixed. This means design must be iterative: There must be a cycle of
design, test and measure, and redesign, repeated as often as necessary.”
There are various methods to perform user validations, all varying in effort
and quality of the result, e.g.:
Thinking aloud method

A basic method of usability study where test users use a service prototype
or implementation and comment everything they think and do aloud. These
comments are recorded, compiled and compared in order to find relevant
weaknesses of the service.
Questionnaires and interviews
Page 164 of 215

30th March 2006
Test users use a service and fill in a prepared questionnaire afterwards. It

is important to have some open questions in the end in order to get hints on
hidden problem areas the editor of the questionnaire did not consider. This
kind of evaluation can also be performed as a guided interview.
Eye-tracking systems
Eye-tracking is a very effective method to discover discontinuities in the
user interface layout. It tracks eye movements and can reveal even short
subconscious irritations that the test user would not remember or find worth
mentioning.
Camera recording
The test user is given a number of tasks to fulfill while using the service.
The success and speed in solving these tasks is measured. The video
recording is also a good way to visualize usability problems to all groups
involved in the development process.
Heuristic analysis
This involves usability experts that examine services according to known
usability problems and give recommendations.
For good results especially on usability the user should be given a number
of pre-defined tasks. The results such as speed of execution are then used
as an empirical base which enhances the individual subjective judgments
by the users.
Further information on the topic and state-of-the-art methodology can be
found on the website of the Institute for Mobile Markets Research in Atlanta
(http://www.immr.org). Different usability guidelines can be found on Jakob
Nielsen’s Website http://www.useit.com.
Page 165 of 215

30th March 2006
16 MHP Outlook
This chapter provides an outlook on the future potential of MHP. Part one
focuses on technical aspects by describing the relevant current and
upcoming updates of the standard. Part two provides a short overview of
commercial aspects.
16.1 Technical aspects

From the start, MHP has proven that it is fit for the future: Since version 1
came into the market, the standard has been continuously updated with
additional functions such as a recording API, reading TV Anytime
metadata, or support for SmartCard reader interfaces, to name just a few. It
has shown its potential to adopt and integrate new technical components
accommodating both upcoming technological and market needs.
Combined with technical integration work, this MHP standardization
process has proven that MHP is ideally suited as a means to allow open
access to all kinds of new and upcoming decoder components like hard
disc, SmartCard reader or broadband Internet access.
By integrating further additional components and offering them to service
providers, MHP is currently broadening its service potential far beyond
“classical” interactive services like EPGs, news tickers or quiz shows. As
described below, this concerns quite a number of new and relevant
technical features like IP transmission networks or new coding formats.
The growing technical potential makes interoperability even more urgent
and hence increases the need for MHP as the universal interface.
16.1.1 DVB over IP / IP tuner

With the developing broadband technology and propelled by a fierce
competition in the telecom market, telecom operators have started to DVB-IPI
deploy TV over IP (Internet Protocol) services on a large scale. DVB standard for the
transport of DVB
DVB has consequently anticipated the definition of a standard for broad- services over IP
cast of DVB services over bi-directional IP networks, resulting in a first networks.
standard DVB-IPI available at ETSI. Its current version addresses transport First published in
of MPEG2 DVB services encoded with MPEG2 technology and March 2005 as ETSI
encapsulated in MPEG2 TS, to cover mainly the following services: TS 102 034
Live media broadcast

Content on demand (COD) such as music and video
DVB has already specified in the DVB-IPI standard a mechanism for
service discovery and selection (SD&S) for DVB MPEG2 based A/V
services over bi-directional IP net-works and is currently continuing work on
the broadband content guide (BCG) as and additional standard and on
extending the first version of the DVB IPI standard.
MHP has already supported all main broadcast protocols such as DVB-S,
DVB-T and DVB-C, but needed an extension to fully support the IP front-
end. Therefore commercial requirements were created within the scope of
DVB and currently, the DVB technical working groups develop the technical
standardization for the ‘MHP IP tuner’.
Page 166 of 215

30th March 2006
This MHP IP tuner specification will address both devices merely

containing a broadband IP interface and also hybrid devices containing a
broadband IP network interface as well as a classical DVB interface (cf.
Figure 16-1).
For hybrid IP STB:

Optional DVB-S,
DVB-T, DVB-C
Telecom IP network
0perator’s (e.g. ADSL)
network
TV over IP
Figure 16-1: Example of an IP STB
Key benefits for IPTV network operators will include:

The rise of a competitive market in middleware suppliers while
retaining compatibility for content and interactive applications.
The potential to deploy rich and complex applications while
minimizing the need to fall back on the original device manufacturer
for additional native code extensions.
Taking advantage of an "always on" interaction channel for advanced
technical and business potential
The IP tuner specification is expected to be available in the second half of
2006.
16.1.2 IP over DVB

INSTINCT Project
As IP broadcast emerges, MHP applications and content using this
technology are being developed. INSTINCT, an EU-project, offers a current EU funded research
project. Committed to
approach as described below (cf. http://www.ist-instinct.org). realising the
The underlying application retrieval mechanism had to be as transparent as commercial provision
of convergent services
possible to the application itself. Therefore the idea was to imitate the in mobility with a
carousel realized with DSM-CC over DVB-C/T/S. The IP broadcast protocol special focus on DVB-
of choice was FLUTE which can be used for iterative broadcast of files and T, DVB-H and DVB-
file sets. Similar to DSM-CC, it allows altering the frequency and data rate MHP.
(www.ist-instinct.org)
with which distinct files are being sent. In order to allow for “easy” access of
the files for the application, received files are just copied into the DSM-CC
carousel cache. As INSTINCT uses a Linux-PC platform running IRT’s
middleware for iTV, this translates into configuring the terminal’s FLUTE-
Client to use a destination directory below the DSM-CC root directory. FLUTE
Yet, unlike in the case of DSM-CC Object Carousel, here the contents are Protocol for File
not visible in the directory until downloading has been finalized. This delivery over
implies that for content access, the application needs to know from another unidirectional
Transport
source which files are to be downloaded. This information can be hard
coded into the service or rather be encoded in an electronic service guide
(ESG). Letting aside the matter of the service signaling itself, applications
can communicate with the FLUTE client on the terminal through an API,
Page 167 of 215

30th March 2006
which has to be implemented as an extension to an existing MHP stack.

The major difference between using DSM-CC or FLUTE is that the FLUTE
implementation needs the application to ask for download before accessing
any file on the carousel. A listener notifies the application of the completed
download. A solution that completely mimics the behavior of the DSM-CC
API, however, would also be feasible.
IP-broadcast enables new types of push services. The terminal FLUTE
client can be set to a constant listening mode, scanning the FLUTE channel
for alert notifications. These notifications are short XML messages in RSS
format (any other format would also be possible) that are filtered on the
terminal according to content description parameters. The application can
add a listener to the FLUTE client in order to get notified of received alerts,
which may then be displayed in the desired way. An example of a push
service prototype making use of this feature will shortly be available on the
37
website of RBB .
INSTINCT used a terminal-resident navigator application along with an
XML-ESG for signaling and starting services. In a system relying fully on
IP-broadcast, a common format of the ESG remains to be agreed upon.
16.1.3 Personal Digital Recorder (PDR)

There is an increasing demand for recording programs or parts thereof.
Personal Digital Recorders (PDR) based on hard disk video recording have
been available on the market for some time now. In order to open the full
potential of MHP for that market and to allow new service ideas based on TV-Anytime
combinations of interactivity and recorded programs such as personalized
Forum to develop
TV experiences, DVB has prepared a proposal for an extension of the MHP specifications
specification for the necessary extensions and interfaces. This proposal supporting local
takes into account the recording concepts developed by the TV-Anytime storage of A/V content
forum and it is available as DVB bluebook A087, not yet as an ETSI www.tv-anytime.org
standard.
The specified interfaces provide the following functions:
Scheduled recording (time, duration and channel)
Time shift recording (recording of current program with “pause” and
instant reviewing controlled by MHP “navigator”)
While the specification defines the basic requirements for the recording
engine, detailed functionalities will depend on what has been implemented
in the respective terminals.
The decoder internal recording application can identify the event to be
recorded by the specified TV-Anytime CRID combined with the DVB locator
as used in MHP. The application will then:
Search the list of recordings and recording requests
Track and manage the recording
Play complete recordings
It offers time-shift recording and allows interrupting live programs for instant
replay.
37
http://www.rbb-online.de/_/unternehmen/beitrag_jsp/activeid=254/key=teaser_300427.htm
Page 168 of 215

30th March 2006
It furthermore allows for switching the time-shift on/off, checking the size of
the time-shift buffer, and also enables random access within the disk buffer.
Application signaling was extended in order to cope with some aspects
critical for the recording of applications. This includes marking applications
as “critical to store”, “optional to store” or “not to be stored”. Another aspect
is how applications shall be dealt with in the case of trick mode playback.
Finally, the specification considers broadcaster security by specifying if and
how content may be used by other broadcasters.
16.1.4 HDTV
Digital TV user experience is greatly enhanced by High Definition (HD)
which is already being deployed: Offering up to five times the spatial
resolution of a classical Standard Definition (SD) program, HD content
provides the best video image quality ever seen in digital TV. This
obviously calls for enhancing rendering of MHP applications for
presentation on HD displays in order to keep MHP an attractive tool in the
HD market.
However, the design of adaptable MHP applications for different screen
resolutions and aspect ratios raises will be a challenge.
Currently deployed MHP 1.0.3 and MHP 1.1.2 applications are dedicated
for 720x575 screen size TV sets. HD TV sets support higher resolutions:
HD Ready TV sets, identified by the logo depicted in Figure 16-2 provide a
displayable area of 1280x720 or 1920x1080.
Figure 16-2: HD Ready logo defined by EICTA for HD equipment
MHP 1.1.2 includes support for HD video and HD graphics. The support for
HD graphics as included in the standard may be revisited depending on
market feedback, i.e. if the specification should prove too demanding or
expensive. It is expected that the MHP 1.1.2 test suite will include tests for
basic operation of MHP + HD receivers.
It will be important for HD deployment to limit interoperability issues
(applications – MHP terminals – TV sets). Guidelines for application writers
would therefore be helpful to have, DVB, however does not plan to provide
such guidelines.
16.1.5 MPEG4 / H.264

The new compression standard H.264 is used to reduce bandwidth - as
compared to MPEG2 - and is currently being implemented in a number of
markets. For standard SD transmission, H.264 is planned to be used in
DVB-T networks in France, furthermore H.264 is going to be used for many
Page 169 of 215

30th March 2006
IPTV networks (e.g. all known ones in Germany) and most HDTV
broadcasts. H.264 is also called MPEG4 part 10 / AVC.
In order to facilitate transition to this new codec for broadcast services,
DVB has defined new SI/PSI values. The existing MHP 1.1.2 standard
version already includes optional support for H.264.
Only MHP applications which intend to make use of the new SI/PSI
information in order to provide corresponding video control functions will
have to be updated.
Impact on MHP middleware is limited due to the fact that whatever the
codec is that is used for compression; a service will still be identified by its
DVB Locator.
16.1.6 DVB-S2
Similarly to the video codecs, the DVB-S modulation has been
DVB-S2
supplemented by DVB-S2 which offers more bandwidth and new degrees
of flexibility. Despite from the fact that more bandwidth means also more Advanced DVB
satellite modulation
data capacity that can be used for MHP applications, we expect that this
new standard will neither have impact on MHP specification itself nor on First published in
March 2005 as
already deployed MHP applications. However, new MHP terminals and
ETSI EN 302 307
broadcast equipment need to support this standard if they are to receive
DVB-S2 broadcasts.
16.1.7 Object Tracking

Object tracking is a feature which allows enhancing quite a number of
betting, shopping or gaming services. By tracking and marking one or more
objects on the TV screen, specific interaction options can be tied to these
objects (e.g. “select the tool you would like to buy”, “guess which player will
make the next goal”, etc.).
The objects can be tracked by software or specific hardware extensions in
the studio and the positioning data is transmitted via stream events or
private sections in near real time.
An example of a commercial implementation of such a system can be
found at the TeleClix website 38 . Figure 16-3 contains a screenshot with an
example for object tracking in a sports program.
Figure 16-3: Example for object tracking GMF4iTV

General Media
Framework for
interactive TV
38
http://www.teleclix.com/Products_&_Services/TeleClix_LiveLink_system/ENG EU funded research
project
Page 170 of 215
30th March 2006
The project GMF4iTV has developed advanced concepts for interaction

with moving objects in normal TV programs extending the existing features
of DVB-MHP. The interaction is based on tracking certain objects in an
MPEG-2 video and generating dynamic metadata in the MPEG-7 format,
describing the actual position and shape of the objects, and broadcasted in
sync with the MPEG-2 video. MHP is using these metadata to highlight the
objects by graphical rendering, which is done synchronized with the MPEG-
2 video. A normal remote control can be used to select the object by
pressing the color button, which matches the object. Alternatively a PDA PDA
can be used as an advanced remote control, where the object can be
Personal Digital
selected by touching the highlighted object. Then additional information can Assistent
be retrieved about this specific object, which may consist of MPEG-4 A/V-
clips, MHP-applications, pictures and HTML-pages. This additional content
can be presented to the viewer also in personalized form, based on
metadata and user profiles.
This example shows that there is still room for further technical
development and standardization effort as the market and the business
models develop over time.
16.2 Commercial aspects
Figure 16-4: MHP situation in the world in August 2005 [MHP_ORG]
16.2.1 DVB-MHP in Europe

While a small number of countries have already started to broadcast
regular services based on MHP, many countries are running trials or are
planning to do so.
DVB-MHP is today the only open standardized API and the implementation
of MHP is recommended by the European Commission (EC).
It is not likely that EC will mandate MHP as the only API to be implemented
in Europe, but it is the only full API that is noted in the official list of
recommended standards. A new EC document on the status on MHP is
Page 171 of 215
30th March 2006
expected until spring 2006. This will be mostly based on information gained
at the meetings in the EU MHP Implementation Group.
One problematic aspect of the implementation of MHP is that the license
costs are still not finally approved, and there are still some principle
discussions concerning the basis for these costs. Additionally, it is also an
issue how to cover the costs for development of the MHP Test Suites.
Both cost aspects have to be solved rather soon.
Another problem is that the full MHP specification is complex and offers
different ways to implement certain applications. This leads to the fact that
proper testing is required in order to achieve good interoperability between
all applications and all versions of MHP terminals. The dynamics of
development in the SW and HW domains make this interoperability difficult
to manage and maintain in a horizontal business context where content
providers / broadcasters and manufacturers policies are driven by interests
that may be in conflict and not focused on the business performance of the
system.
The main problem so far does not seem to be the technical platform for
interactive services itself, but how to get the public attracted to these
services so that they will buy the STBs at some higher price than the pure
“Zapper” versions, and start to use the services.
It will be an important issue to introduce interactive services and to get the
audiences acquainted to them in order to get the related business models
working.
Despite these remaining questions it is likely that most of the organizations
in Europe, that are going to start with interactive services, will do this based
on MHP. As outlined above, MHP is flexible to support many current and
future service (and business!) options.
Following the positive experiences made in Italy (cf. 3.6.7) Austria has
decided in 2005 to select a very similar business model: MHP shall be the
API to be used in the DVB-T market and decoders shall be subsidized. In
Germany, broadcasters will use the DVB-IPI standard and MHP to
distribute their broadcast services including interactivity via IP DSL
networks. Here the DVB system can prove its benefits also in non
broadcast IT networks.
Furthermore, the BluRay consortium has chosen MHP as interactivity tool
for their HD DVD system. Once more this shows how flexible MHP can be
used to open new fields of application and constitute a universal “key”
component in many markets still to grow and still to detect.
In order to support markets which still use proprietary APIs, DVB has
PCF
specified a Portable Content Format (PCF) for a common authoring for
different APIs. This standard can help to ease the migration process from Portable Content
Format
one of the other APIs to MHP. More information concerning such migration
processes can be found in [].
A lot of dedicated companies are now developing MHP based services and
these services can be bought for implementation in an open market.
Proprietary iTV platforms in Europe

In the early days of interactive TV in Europe a number of proprietary
platforms were deployed which are partly still competing with MHP:
Page 172 of 215

30th March 2006
Open TV is used by BskyB and several other operators in Europe

and is also implemented by many operators in the rest of the world. It
will therefore be in use for many years ahead.
MediaHighway was developed by Canal Plus Technology, and is now
one of the products from NDS. It is not so widely used and there
does not seem to be any further development of it.
Liberate is not much used in Europe anymore, mainly by Cable-TV
networks in UK. It is not expected to be a competitor to MHP. The
Liberate system is based on extensive communication via interaction
channel with servers in the network.
NDS has introduced a MHP based API with some proprietary other
elements in it. If MHP will be as widely used as expected, it is likely
that NDS will leave the old MediaHighway behind and go fully for the
MHP based version.
The terrestrial platform in UK is still running MHEG-5, which is open
and standardized, but a “Presentation Engine” and not a complete
API. Both the MHEG-5 and the MHP specifications are now modified
so that a MHP based STB can in the future execute MHEG-5 based
services.
16.2.2 DVB-MHP in the rest of the world

MHP originally is the standard for interactivity within the DVB system and in
several aspects linked to specifities of the DVB-S/-C/-T systems. In order to
make MHP more generally applicable, DVB has also produced another
version of the MHP standard named Global Executable Multimedia Home
Platform, GEM.
GEM
GEM was created to enable organizations (e.g. US CableLabs) to define Global Executable
specifications based on MHP together with DVB. It has the following goals: Multimedia Home
Platform
To maximize interoperability between GEM based specifications from
different organizations.
To maximize the presence of MHP components, enabling economies
of scale for the whole interactive broadcast chain.
To take into account local business and technical constraints.
GEM is not a stand alone specification that can be directly implemented,
but a framework to be used by those organizations that wish to define
specifications based on MHP. Additionally, the design rules of the GEM
specification enable content authors to write applications that can be
directly interoperable across different GEM based receivers.
The GEM specification lists those parts of the MHP specification that have
found to be DVB technology or market specific. It allows these to be
replaced where necessary as long as the replacement technology is
functionally equivalent to the original.
The set of technologies where functional equivalents are allowed is
negotiated as part of the technical dialogue between DVB and each of the
organizations wishing to use GEM.
Additionally, the GEM specification contains a list of those other
specifications with which it can be used.
Gem 1.0 was published in February 2003 and contains links to
“CableLabsOpenCable”.
Page 173 of 215

30th March 2006
DVB is currently working with ATSC in order to finalize the inclusion of the ATSC
GEM core into the US system environment of digital television:
Advanced Television
ACAP (Advanced Common Application Platform) the middleware Systems Committee.
Preparing US TV
specification based on GEM, was recently approved by the ATSC. With trial
standards.
services already on air in Korea, where the ATSC system is used for digital
terrestrial television, this approval clears the way for the growth of
interactive services in the USA, with harmonized standards across the ACAP
cable and terrestrial markets. OCAP developed by CableLabs for the Advanced Common
American cable market, is also based around the GEM core. Application Platform
ATSC previously published a companion Standard A/96, “Interaction
Channel Protocols”.
Used in combination with forward broadcast channels from terrestrial, cable
and satellite networks, these protocols provide a complete interactive
system.
Overall Conclusions
There is today no other open standardized API that can be
implemented in Europe. Even though DVB-MHP is not mandated by
EC, it is recommended as the API to be implemented in the member
countries.
Most of the European countries starting with digital TV and
Interactive services are implementing MHP.
In the rest of the world it seems that MHP based solutions will be
implemented by use of the GEM standard in many markets.
Page 174 of 215

30th March 2006
17 Glossary and abbreviations
24/7
Twenty-four-seven. Availability round the clock (Twenty-four hours a day, seven days a week).
3G
Third Generation. Mainly used in the context of mobile communication networks.
ACAP
Advanced Common Application Platform: It is a middleware specification based on GEM.
ADSL
Asymmetric Digital Subscriber Line. Enables faster data transmission over copper telephone lines
than a PSTN modem, usually several Mbit/s
AIT
Application Information Table. Table defined by MHP to provide basic information about MHP
applications.
Alpha Channel
An alpha channel is additional information in a picture file that determines the transparency for every
pixel.
API
Application Programming Interface. The publicly accessible surface of software classes through which
applications operate upon the specific functions contained within the MHP.
ATE
Automated Testing Environment. In the context of MHP meaning an environment to automatically run
all the many tests included in the official MHP Test Suite.
ATSC
Advanced Television Systems Committee. Preparing US television standards.
A/V
Audio/Video
AWT
Abstract Window Toolkit
Page 175 of 215

30th March 2006
BAT
Bouquet Association Table. Table defined by the DVB specification for Service Information. Providing
information which DVB services belong to a certain bouquet.
BIOP
Broadcast Inter-ORB Protocol
CA
Certification Authority (in DVB MHP PKI context) or Conditional Access
CAS
Conditional Access System
CAT
Conditional Access Table. MPEG2 defined table to provide information on the type of CA system used
in a broadcast stream.
CDC
Connected Device Configuration
CLDC
Connected Limited Device Configuration
CI
Common Interface. Interface based on PCMCIA which allows to connect external CA modules to DVB
decoders.
CLUT
Color Lookup Table. In the context of DVB a predefined table which maps the true color space of MHP
applications to the possibly limited color space of MHP terminals.
CMS
Content Management System
COD
Content On-Demand
CORBA
Common Object Request Broker Architecture
CRC
Page 176 of 215
30th March 2006
Cyclic redundancy check, a type of hash function used to produce a checksum, in order to detect
errors in transmission or storage
CRID
CRID is a concept from the standardization work done by the TV-Anytime forum. A CRID or a Content
Reference Identifier closely matches the concept of the Uniform Resource Locator or URL, made
famous by the stunning success of the World-Wide Web:
A unit of content, in a broadcast stream, can be referred to by its globally unique CRID in the same
way that a webpage can be referred to by its globally unique URL on the web.
Thus, it should come as no surprise that a CRID is specified much like URLs. Typically, the content
owner will use their DNS-names in a combination with a product-specific name to create globally
unique CRIDs. As an example, let's assume that BBC wants to make a CRID for the upcoming
Olympics in China. It may look something like this
crid://www.bbc.co.uk/olympics/2008/
Then, to refer to a specific event - such as the women's shotput finale - they can use the following
inside their metadata.
crid://www.bbc.co.uk/olympics/2008/finale/shotput/women
CRL
Certificate Revocation List: Contains a list of certificates that have been revoked prior to their date of
expiration.
CPS
Certification Practice Statement
CSS
Cascading Style Sheets
CW
Control Word. In the context of DVB CA systems the bit pattern controlling the scrambling and
descrambling algorithm.
DAVIC
Digital Audio Video Council: A worldwide association of bodies concerned to promote interoperability
in audio visual equipment of all kinds concentrating on standardized interfaces.
DECT
Digital Enhanced (former European) Cordless Telecommunications: It is an ETSI standard for digital
portable phones, commonly used for domestic or corporate purposes.
DFC
Decoder Format Conversion
DGTVi
Page 177 of 215
30th March 2006
Italian platform for interactive TV using MHP.
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System: It is a system that stores information associated with domain names in a
distributed database on networks, such as the Internet.
DOM
Document Object Model. A description of how a HTML or XML document is represented in an object-
oriented fashion. DOM provides an application programming interface to access and modify the
content, structure and style of the document.
DRM
Digital Rights Management
DSM-CC
Digital Storage Media Command and Control: A format for transmission of data and control
information in an MPEG-2 private section.
DTD
Document Type Definition
DTT
Digital Terrestrial Television
DTV
Digital Television
DVB-ASI
Digital Video Broadcast-Asynchronous Serial Interface: A standard for how to connect components
such as encoders, modulators, receivers, and multiplexers.
DVB-C
Digital Video Broadcasting - Cable
DVB-HTML
DVB-HTML applications are a set of HTML pages that are broadcast as part of a service. The
specification is based around a modularized version of XHTML 1.1, and also includes CSS 2.0, DOM
2.0, and ECMAScript.
Page 178 of 215

30th March 2006
DVB-IPI
DVB standard for the transport of DVB services over IP networks.
DVB-J
DVB-J (DVB-Java) applications are written in Java using the MHP API set and consist of a set of class
files that are broadcast with a service.
DVB-RCS
DVB return channel by satellite.
DVB-S
Digital Video Broadcasting – Satellite
DVB-S2
Advanced DVB satellite modulation
DVB-SSU
DVB System Software Update
DVB-T
Digital Video Broadcasting – Terrestrial
DVD
Digital Versatile Disc
E2E
End-to-End
EC
European Commission
ECM
Entitlement Control Message. In the context of DVB CA systems used to broadcast messages to the
CA system in the decoder containing information on the rights required for descrambling of a specific
service.
ECMAScript
ECMAScript is a scripting programming language, standardized by Ecma International in the ECMA-
262 specification. The language is widely used on the web, and is often referred to as JavaScript or
JScript, although those two terms have more specific meanings. To understand the relation between
ECMAScript, JavaScript, and JScript, knowing the history of ECMAScript is a helpful prerequisite.
Page 179 of 215

30th March 2006
EIT
Event Information Table. Table defined by the DVB specification for Service Information. Providing
detail information on the events of the broadcast schedule.
EMM
Entitlement Management Message. In the context of DVB CA systems used to broadcast messages to
the user smart card containing information on the rights of the individual users.
EPG
Electronic Program Guide
ESG
Electronic Service Guide
ETSI
European Telecommunications Standards Institute
EU
European Union
Euro-DOCSIS
Adaptation of DOCSIS to European cable networks: DOCSIS is a standard for delivering data over
cable TV systems, typically for subscriber Internet access services.
FIFO
FIFO is an acronym for First In, First Out. This expression describes the principle of a queue or first-
come, first-served behavior: what comes in first is handled first, what comes in next waits until the first
is finished, etc. Thus it is analogous to the behaviour of persons "standing in a line" (preferred in
American English) or "queueing" (preferred in Commonwealth English), where the persons leave the
queue in the order they arrive.
FLUTE
Protocol for File delivery over unidirectional transport mechanisms.
FTTH
Fiber-To-The-Home: The installation of Optical fiber from a telephone switch directly into the sub-
scriber’s home.
Gamma
Value of the brightness adaptation to the screen.
Page 180 of 215

30th March 2006
GEM
Global Executable Multimedia Home Platform.
GIF
Graphics Interchange Format. Very common graphics format, optionally supported by MHP terminals.
GPRS
General Packet Radio Service: It is a mobile data service available to users of GSM mobile phones. It
is often described as "2.5G"
GSM
Global System for Mobile Communications: It is the second generation for mobile phone technologies.
GUI
Graphical User Interface
H.264
Compression Standard. Also called MPEG4 part 10 / AVC.
HAVi
Home Audio Video Interoperability: A vendor-neutral audio-video standard aimed specifically at the
home entertainment environment. HAVi allows different home entertainment and communication
devices to be net-worked together and controlled from one primary device, such as a PC or television.
HDTV
High Definition Television
HTTP
Hyper Text Transfer Protocol: It is the primary method used to transfer or convey information on the
World Wide Web.
HW
Hardware
IFA
Internationale Funkausstellung: Annual International Broadcasting Fair in Berlin.
IP
Internet Protocol: The computer networking protocol used on the Internet.
Page 181 of 215

30th March 2006
IPTV
Internet Protocol Television. TV delivered via IP networks.
ISDN
Integrated Services Digital Network: It is a type of circuit switched telephone network system,
designed to allow digital transmission of voice and data over ordinary telephone copper wires,
resulting in better quality and higher speeds than available with analogue systems.
ISO
International Organization for Standardization
ISP
Internet Service Provider: A company that sells Internet services to the public.
ITV
Interactive Television. A capability in digital TV offering interactive services (e.g. information,
communication, transaction, etc.) often directly related and synchronized with the broadcast content.
J2ME
Java 2 Micro Edition
J2SE
Java 2 Platform Standard Edition
JavaTV
It is a Java-based API for iTV applications development.
JMF
Java Media Framework
JPEG
Joint Photographic Experts Group. Commonly used compressed graphics format. Mandatorily
supported by MHP terminals.
JVM
Java Virtual Machine
KDB
Knowledge Database: Public database of the MHP-KDB project.
Page 182 of 215

30th March 2006
Legibility
Legibility means that writing can easily be deciphered and read.
LGPL
Lesser General Public License. Open Source license used by the MHP-KDB project.
MHEG
Multimedia and Hypermedia information coding Expert Group. This Group developed a standard for a
presentation engine called MHEG-5 which is used for digital teletext services in the UK.
MHP
Multimedia Home Platform
MPEG-2
A digital video and audio compression (encoding) technique defined by the Moving Pictures Expert
Group (MPEG).
MUX
Multiplex
NAT
Network Address Translation: An Internet standard that enables a local-area network (LAN) to use one
set of IP-addresses for internal traffic and a second set of addresses for external traffic.
NIT
Network Information Table. Table defined by the DVB specification for Service Information. Providing
information on the transport streams/multiplexes available in a DVB network and their technical
parameters (frequency, modulation, ...).
NPT
Normal Playtime
NTSC
National Television System(s) Committee: It is the analogue television system in use in Korea, Japan,
United States, Canada and some South-American countries.
ORB
Object Request Broker
OC (Object Carousel)
The data structure (containing applications, media files, etc.) that is broadcast within a transport
stream. In the context of MHP DSM-CC object carousels are used.
Page 183 of 215

30th March 2006
OCAP
Open Cable Application Platform: It is a technical standard, which is used in the cable networks of
North America.
OFDM
Orthogonal frequency-division multiplexing
OSD
On-screen Display
OSI
Open Source Initiative
PAL
Phase Alternating Line: It is a color encoding system used in analoge broadcast television systems in
large parts of the world.
PAT
Program Allocation Table. Table defined by the MPEG2 systems specification. Providing a very basic
list of the services in a MPEG2 transport stream and linking to the corresponding PMTs.
PC
Personal Computer
PCF
Portable Content Format. Format specified by DVB to support authoring of interactive applications in
an API independent way.
PCI
Peripheral Component Interconnect: A computer bussing architecture that defines electrical and
physical standards for electronic interconnection.
PCR
Program Clock Reference. Master clock for each DVB service used to synchronize time critical
content (basically video and audio, but optionally also data).
PDR
Personal Digital Recorder
PersonalJAE
Personal Java Application Environment
Page 184 of 215

30th March 2006
PES
Packetized Elementary Stream. MPEG2 defined protocol layer used for transmission of streamss to
be decoded in real time (basically video and audio, but optionally also data).
PFR
Portable Resource Format
PID
Packet Identifier. Identifier for MPEG2 transport stream packets used for identifying different
elementary streams.
PIN
Personal Identification Number
PKI
Public Key Infrastructure: A system that enables users of a public net-work to exchange data securely
and privately through the use of a public and private cryptographic key pair that is obtained and
shared through a trusted authority.
PMT
Program Map Table. Table defined by the MPEG2 systems specification. Providing a basic list of
components (video, audio, teletext, data, ...) belonging to a specific and linking to these components.
PNG
Portable Network Graphics. Common graphics format, mandatorily supported by MHP terminals.
PRF
Permission Request File. Information needed in the context of the MHP security model.
PPPoX
PPP over some data link protocol such as Ethernet (PPPoE) or ATM (PPPoA). See also PPP.
PPP
In computing, the Point-to-Point Protocol, or PPP, is commonly used to establish a direct connection
between two nodes. It can connect computers using serial cable, phone line, trunk line, cellular
telephone, specialized radio links, or fiber optic links. Most internet service providers use PPP for dial-
up access to the Internet.
PPP is commonly used to act as a "layer 2" (the "Data Link" layer of the OSI model) protocol for
connection over synchronous and asynchronous circuits, where it has largely superseded an older
non-standard protocol (known as SLIP), and telephone company mandated standards (such as X.25).
PPP was designed to work with numerous "layer3" network layer protocols, including IP, IPX, and
AppleTalk.
Page 185 of 215

30th March 2006
PPP was designed much later than the original HDLC specifications. The creators of PPP included
many additional features that had been seen only in various proprietary WAN data-link protocols up to
that time.
PSI/SI
Program Specific Information/Service Information. Tables like PAT, PMT, SDT, NIT or BAT defined by
MPEG2 and DVB providing various types of metadata related to DVB networks and services.
PSTN
Public Switched Telephone Network: The international telephone system based on copper wires
carrying analogue voice data.
PTS
Presentation Time Stamp. Timing information for the presentation of content (video, audio, data)
transmitted via DVB streams.
PVR - Personal Video Recorder

A PVR is a receiver equipped with storage for recording digital media and an appropriate user
interface that also allows scheduling automatic recordings.
QAM - Quadrature Amplitude Modulation

Modulation scheme used in some DVB networks.
QPSK - Quadrature Phase Shift Keying

Modulation scheme used in some DVB networks.
RC
Return Channel
RF
Radio Frequency
RGB
Red, Green, Blue: Color Model.
RSA
Rivest-Shamir-Adelman (-Algorithm): Secure asymmetric encryption algorithm using a key pair of
private and public key.
RSS
Really Simple Syndication
Page 186 of 215

30th March 2006
RST
Running Status Table. Not commonly used DVB SI table to provide the running status of an event.
RTOS
Real Time Operating System
SARL
DVB Services Sàrl is a limited liability company governed by the Swiss Civil Code established with the
aim of providing certification authority and all other related services to broadcasters, manufacturers,
and entities.
SAS
Subscriber Authorization System
SDK
Software Development Kit
SDT
Service Description Table. Table defined by the DVB specification for Service Information. Providing
detail information on the services contained in the actual (and optionally also in other) DVB transport
stream.
SE
Stream Event. Defined as an option of the DSM-CC transmission protocol. Used to transmit time
critical information to the MHP terminal.
SMS
Subscriber Management System (broadcasting) or Short Messaging Service (mobile phones)
SNMP
Simple Network Management Protocol
sRGB
Standard RGB Color Space
SSL
Secure Sockets Layer: SSL and Transport Layer Security (TLS), its successor, are cryptographic
protocols which provide secure communications on the Internet.
ST
Stuffing Table. DVB table without useful data to be used for stuffing purposes.
Page 187 of 215

30th March 2006
STB
Set-top Box. MHP Terminal to be connected to a TV set.
SW
Software
T-Care
Analogue to the term e-Care. T- Care covers all sorts of communication services that connect patients
and health care personnel in (bi-directional) TV-based communication applications.
T-Commerce
Analogue to the term e-Commerce T-Commerce covers all sorts of “commercial“ applications and
transactions that are delivered and performed on the TV screen.
TCP
Transmission Control Protocol: It is one of the core protocols of the Internet protocol suite. Using TCP,
applications on networked hosts can create connections to one another, over which they can
exchange data. The protocol guarantees reliable and in-order delivery of sender to receiver data.
TDT
Time and Data Table. DVB defined table to carry time information in a DVB transport stream.
T-Games
Interactive Games to play on the TV screen.
T-Government
Analogue to the term e-Government. T-Government covers all sorts of information services and
(ideally) communication and actions with the relevant authority, delivered and per-formed on the TV
screen.
T-Health
Analogue to the term e-Health. T-Health covers all sorts of information services related to health and
well-being that are delivered and performed on the TV screen.
T-Learning
Analogue to the term e-Learning. T-Learning covers all sorts of educational applications that are
delivered and per-formed on the TV screen. In various publications this ranges from providing program
related (educational) back-ground material to interactive learning applications which check and track
learners’ progress.
TLS
Transport Layer Security: A cryptographic protocol, which provides secure communications on the
Internet. The successor of SSL 3.0
Page 188 of 215

30th March 2006
TOT
Time Offset Table. DVB defined table to carry time information containing information on local time in
a DVB transport stream.
TS
Transport stream: A multiplex of several program streams that are carried in packets.
UDP
User Datagram Protocol: It is one of the core protocols of the Internet protocol suite. UDP does not
provide the reliability and ordering guarantees.
UI
User Interface
UML
Unified Modelling Language
UMTS
Universal Mobile Telecommunications System: It is one of the third-generation (3G) mobile phone
technologies.
URL
Uniform Resource Locator
Usability
Usability is to ensure user-friendliness and –satisfaction, efficiency of use, and error prevention when
working with an interactive service.
USB
Universal Serial Bus
VM
Virtual Machine
VoD
Video On Demand: The viewer pays a small fee to the television service provider in order to watch
particular movies listed on the on-screen television menu. Similar to pay-per-view.
W3C
World Wide Web Consortium
Page 189 of 215

30th March 2006
WiFi
Wireless Fidelity
xDSL
It refers collectively to all types of digital subscriber lines, the two main categories being ADSL and
SDSL. Two other types of xDSL technologies are High-data-rate DSL (HDSL) and Very high DSL
(VDSL).
XHTML
Extensible Hypertext Markup Language
Xlet
Xlet is the interface used for execution engine application lifecycle control in MHP.
XML
Extensible Markup Language. Often used when authoring content for MHP applications.
YUV
A color format: Y contains the brightness signal (luminous intensity) and U and V contain the
combined color information (chroma).
Page 190 of 215

30th March 2006
18 Literature
[Gould 1995] J.D. Gould, and C. Lewis, “Designing for Usability: Key Principles and What Designers
Think,” Communications or the ACM, Vol. 28, No 3, March 1995, p. 300. Quoted
according to: Aftelak, Häyrynen, Kurvinen: User-Centered Design in the course of
large and distributed project. 15th Meeting of the World Wireless Research Forum.
Paris. December 9th, 2005.]
[Hetzer 2001] Hetzer, Hanno; Sicherheitsanforderungen in digitalen Broadcastmedien am Beispiel
der Multimedia Home Platform (MHP)
[MHP 1.0.0] MHP Standard Specification, Version 1.0.0
[MHP 1.0.2] MHP Standard Specification, Version 1.0.2.
http://www.mhp.org/documents/mhp_Ts101812.V1.2.1.pdf.zip
[MHP 1.0.3] MHP Standard Specification, Version 1.0.3.
http://www.mhp.org/documents/mhp_Ts101812.V1.3.1.pdf.zip
[MHP 1.0.3e] Errata of the MHP Standard Specification, Version 1.0.3.
http://www.mhp.org/documents/tm2971r1.tm-tam0801r6.MHP1.0.3.errata2.pdf
[MHP 1.1] MHP Standard Specification, Version 1.1.
http://www.mhp.org/documents/Ts102812.V1.2.1.zip
[MHPKDB-1] The MHP Knowledge Project, 2006, “Guidelines on Migration” (Deliverable D18)
http://www.mhpkdb.org/publications.html
[Morris 2005] Morris, Steven; Interactive TV Standards A Guide to MHP OCAP and JavaTV Focal
Press / Elsevier Inc.; 2005
[Morris 2005a] Steven Morris; “Interactive TV Web”;
http://www.interactivetvweb.org/tutorial/mhp/index.shtml (last visited on 05/01/2006)
[Newell 2005] J. C. Newell, “An introduction to MHP 1.0 and MHP 1.1”;
http://www.bbc.co.uk/rd/pubs/whp/whp030.shtml (last visited on 05/01/2006)
18.1 General DVB

[GuidelinesDataBroadcasting] ETSI TR 101 202 V1.2.1 (2003-01) ”Digital Video Broadcasting (DVB);
Implementation guidelines for Data Broadcasting”
[ETSI] European Telecommunications Standards Institute, http://www.etsi.org
[DVB_ORG] Digital Video Broadcasting, http://www.dvb.org
[MHP_ORG] The official MHP web site, http://www.mhp.org
[HAVI] Home Audio Video Interoperability specification,
http://havi.org/technical/specifications.asp
18.2 General TV
[Dureau 2004] Dureau, V.: ADDRESSABLE ADVERTISING ON DIGITAL TELEVISION.
(Amsterdam, 2004) In: Broadcast Papers – IBC Papers 2004, available at
http://www.broadcastpapers.com/ibc2004/ibc04OpenTVAdvertising.pdf (Last visited
on 19/12/2005)
18.3 General User Interaction

[BBC 2002] The BBC Styleguide
Page 191 of 215

30th March 2006
[Noss 2003] Noss, Christian: Lerneinheit, Studienbrief Screendesign für den Online-Studiengang
Educational Media der Universität Duisburg-Essen, 2003
18.4 Other
[SUNJMF] http://java.sun.com/products/java-media/jmf/index.jsp
[MHPKDB] The MHP Knowledge Project, http://www.mhpkdb.org
[MPEG2Systems] ISO/IEC 13818-1 Information technology - Generic coding of moving pictures and
associated audio information: Systems
[MPEG2DSMCC] ISO/IEC 13818-6 "Information technology - Generic coding of moving pictures and
associated audio information - Part 6: Extensions for DSM-CC".
[RFC 2246] http://www.ietf.org/rfc/rfc2246.txt?number=2246
[SN HESS] Sozialnetz Hessen, http://www.sozialnetz-hessen.de, 2005
Page 192 of 215

30th March 2006
19 Annex A - How to use the MHP KDB
19.1 Organization of the Database Content

The MHP Knowledge Database (KDB) was created and designed to offer
valuable material to all entities in the MHP production chain for free.
The project encourages broadcasters, decoder manufacturers, authoring
tool providers, broadcast equipment manufacturers and, in particular,
application programmers to make use of the reports, guidelines, best
practice recommendations and sample codes provided in the KDB. Special
emphasis was laid on a clear, intuitive structure of the contents in the KDB
in order to ensure ease of use.
The KDB consists of a static and a dynamic part. The static part contains
written documents like reports and guidelines that cover general know-how
on MHP and interactive television. The dynamic part offers detailed MHP-
related information (sample codes, benchmark applications, design and
testing tools, guidelines) that is cross-linked to facilitate the locating of
additional information on a certain topic in the KDB.
As the simplified data model shows (see sketch below), the so called Issue
is the central data type. An Issue can be any kind of MHP-related question,
interoperability problem, etc.
Once an Issue has been placed in the database, related Solutions can be
attached to it. Issues and Solutions can be further explained by adding
comments, sample code or any other kind of documents (Attachment).
The option to place comments to Issues and Solutions enables to open
discussions related to certain questions.
Figure 19-1: Simplified Data Model of the KDB
Page 193 of 215

30th March 2006
19.1.1 Rights and Roles

User roles and their corresponding rights are shown in the following table:
Role Rights
Author Read all documents

Add comments to documents
Publish his own documents
Modify all his documents
Test Centre User Author Role PLUS

Use Remote Testing Environments
Reviewer Test Centre User Role PLUS

Modify all documents
Admin Reviewer Role PLUS

Delete documents
Table 19-1: Rights and Roles Model of the MHP-KDB
After a regular registration you will be given the role of a Test Centre User.
Highly interested users can obtain additional rights.
19.1.2 Reviewing Process

Any contribution to the MHP-KDB will be initially published in the state of
Not Reviewed.
There is a set of persons who are assigned the role of reviewers. Initially, a
set of project members serve as reviewers.
A reviewer can access the pool of all contributions with status Not
Reviewed. There, the reviewer can pick and review any contribution. There
are no further mechanisms like check-in/check-out etc.
If a reviewer decides that a contribution is not fit for getting this quality
mark, the reviewer adds a comment to the contribution in order to record
his recommendations and remarks. The document is set to the state
Declined until its next modification, which changes the document status
back to Not Reviewed, allowing the reviewer to check it again. The author
is automatically notified by an email about this step.
The further proceedings in this case are resolved by mutual email
exchange between reviewer and author until the author withdraws his
contribution or the reviewer is confident and ready that the quality mark
Reviewed can be granted.
Only contributions that are clearly not related to MHP are deleted directly.
Any other contributions are deleted only if the author withdraws it.
Changes to a document that has already been reviewed will change its
status back to Not Reviewed. Reviewers are allowed to edit documents to
make them fit the KDB quality criteria.
Page 194 of 215

30th March 2006
19.2 Using the KDB

This chapter delineates how to use the KDB in an effective way, and gives
a brief explanation of the license agreements and their consequences for
using KDB content.
A more detailed introduction to the usage of the KDB is provided in the
“Help” section of the web site.
The database provides three basic functions: adding, modifying and
searching for entries.
Users are encouraged to always search for an issue before adding an
issue to the database. First of all, the user is required to choose the
document type to search for. The KDB provides two ways of searching for
issues: a keyword based search and a category based search, both of
which can be combined. The search results are displayed as a list of
hyperlinks within the search screen. After clicking on one of the links, the
Document View form for the chosen document type is displayed.
Figure 19-2: Searching an Issue in the KDB
Page 195 of 215

30th March 2006
Figure 19-3: Adding an Issue to the KDB
For adding a document the user has to choose Archive Document. A

selection of types of documents that can be added appears. Members of
the MHP-KDB project are permitted to enter all document types, registered
users which are not MHP-KDB members are allowed to enter issues,
solutions, comments, attachments and source code. The user has to
provide some information about the posted issue:
Page 196 of 215

30th March 2006
Title of the new issue

Description of the issue
Issue Type (Question, Exception, Performance, Other)
Probable Solution Type (Application Change, Decoder
Implementation Change, Recommendation, Standard Modification,
Test Suite Modification, Other)
Keywords
Category (one of the main and / or sub-categories in the KDB)
Tool if applicable
Application if applicable
MHP Terminal if applicable
MHP Standard (MHP 1.0.2, MHP 1.0.3, MHP 1.1) if applicable
Additionally, the user has the opportunity to upload appropriate
attachments and source code examples.
In order to modify a document, users need to click on the Edit Document
tab. This will display a hyperlink list of all the documents that this user has
entered into the database, ordered by document type (i.e. only the author
of a document is allowed to modify this document). It is displayed whether
the issues and solution provided by the author have been reviewed or not.
By clicking on the link of the desired document, the Edit Document screen,
which almost exactly resembles the Add Document screen, is displayed.
The user can then make the desired changes and commit the updated
version of the document into the database.
Editing a document does not mean that its former version is lost. Instead, a
versioning system is applied that keeps older versions in the database but
does not display them. If users then find out that a certain older version of a
document needs to be recovered, they can ask the administrator to do that.
Only the administrator is able to delete documents. Hence users need to
request deletion of documents.
Page 197 of 215

30th March 2006
Figure 19-4: Editing a Document
19.3 Licensing conditions

All documents in the static area of the database can be downloaded, used
and distributed as long as they remain unchanged. Parts or even entire
documents can be copied and used for other purposes. This offer is free of
charge, but the user is obliged to refer to the MHP-KDB project. The
wording of the licensing conditions for contents of the static database part
can be found in chapter 19.3.1. .
Regarding the usage of source code, one existing license agreement
offered by the Open Source Initiative (www.opensource.org) is used. Thus,
the source code provided by the MHP-KDB project can be claimed to be
"OSI Certified Open Source Software". This procedure allows for easy
dissemination of MHP and harmonization of its usage, two of the main
goals of the MHP-KDB project.
The project is using the LGPL (Lesser General Public License), because it
allows for free usage of the source code and requires
not to change the copyright notice
to inform about any changes of the source code
to make the used source code of the MHP-KDB project available
when distributing complete software works.
The LPGL contains also a disclaimer excluding warranty issues.
In addition to the LGPL rules a "code of conduct" is added. It requests for
reporting back any improvements of the code and when applications go on
Page 198 of 215

30th March 2006
air that make usage of our know-how. The wording of the licensing
conditions for Java source code is laid down in chapter 19.3.2 of this
document.
19.3.1 Licensing conditions for documents in the static

part of KDB
The PDF-documents in the static area will contain the project logo, a
reference to the project website and a copyright notice as follows:
"© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP
Knowledge Project. This work may be reproduced and redistributed, in
whole or in part, without alteration and without prior written permission,
provided all copies contain the following statement:
"© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP
Knowledge Project. This work is reproduced and distributed with the
permission of the Institut für Rundfunktechnik GmbH. No other use is
permitted without the express prior written permission. For
permission, contact info@mhpkdb.org.”
This document is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As we are interested to continuously improve the quality of our documents,
we kindly ask you to report back any error you find in our documents or any
improvement you are able to suggest. This can be done via writing
comments into the database or by an email to feedback@mhp-kdb.org.”
19.3.2 Licensing conditions for Java source code

The following notice will identify the software in our database as OSI
Certified:
"This software is OSI Certified Open Source Software. OSI Certified is a
certification mark of the Open Source Initiative."
The JAVA code in the database is marked as follows:

"[one line to give the library's name and an idea of what it does]
Copyright (C) 2006 by [contributing partner] on behalf of the MHP
Knowledge Project.
This library is free software; you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the
Free Software Foundation; either version 2.1 of the License, or (at your
option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software Foundation,
Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
Page 199 of 215

30th March 2006
[information on how to contact the author by electronic and paper mail]

www.mhpkdb.org"
As a non-binding code of conduct the following rules are added:

"We are interested to continuously improve the quality of our Knowledge
Database. Therefore we kindly ask you to report back any bug you find in
our software or any improvement you are able to suggest. This can be
done via writing comments into the database or by an email to
feedback@mhpkdb.org.
Furthermore we would appreciate if you could inform us (also via
feedback@mhpkdb.org) about any broadcast MHP application which was
developed using our Knowledge Database“.
Page 200 of 215

30th March 2006
20 Annex B – Develop your first Xlet with NOVICE LEVEL

MHP-KDB
A basic environment for developing MHP applications consist of three
parts:
A set of class libraries that will let you to compile the application. A
stub generator that generates MHP stub libraries from MHP javadoc
is available for free download in the tools section of the KDB
(www.mhpkdb.org). The javadoc files can be downloaded from MHP
and Sun web-sites.
A text editor with java compiler, or an MHP authoring tool to edit and
compile the application.
An MHP compliant platform to run the application. This may be a PC-
based emulator or a development STB. The emulator simulates the
behavior of an application on the PC but it is not suitable for
estimating the performance on a real STB. Also only commercial
emulators support all MHP features. Currently open source emulators
offer only subsets of the standard, but allow for decent simple
application development for beginners.
Once we have developed an application to be broadcast on a real network,
it is important to test it on different STBs with different middleware stacks to
check it for interoperability problems.
Build
Debug Download
Run
Figure 20-1: Developing application steps
20.1 Build an application

Authoring tools can be used to facilitate application building. Yet,
depending on the individual requirements they may be too limited. Custom-
made applications using text editor and java compiler may be the more
flexible approach. Some authoring tools offer additional features like
analyzing, testing and signing applications.
Below is an (incomplete) list of currently available authoring tools:
Vendors Tools
Actalis MHPSigner tool for signing MHP applications
Aircode The TVPlus I Station authoring tool
Alticast The Alticomposer authoring tool
Page 201 of 215

30th March 2006
Cardinal Information system “Cardinal Studio” authoring tool
Core Media Starter Kit for MHP
Digisoft “DigiHost” Content management system
Emuse “Modelstream® Pro” development tool
Ensequence “on-Q Create” authoring tool
Fraunhofer IMK “JAME Author” authoring tool
Icareus “iTV Suite” authoring tool / DVB-HTML browser
Institut für Rundfunktechnik Dynamic and static MHP-applications analyzer
Mindhouse Content management system and applications
MIT-Xperts iDesigner authoring tool
NDS Value@TV Solutions is a complete application authoring

tool
NPTV “iTV Factory suite" authoring tool
Ortikon Interactive Content provider tool and DVB-HTML browser emulator
Panasonic MHP development kit
Sony Professional Broadcast “Media Gateway” authoring tool
TeleIDEA “IdeaPublisher and TeleAuthor” a complete authoring and

testing tool.
Unisoft MHP Security File Generator
Zappware “EZTV” Customizable applications
Table 20-1: Authoring Tools vendors
20.2 Download an application:

Applications are either resident or downloaded; resident applications
enable navigation and configuration of the MHP terminal. Those
applications are deployed by manufacturers and can be upgraded by
broadcasters. Downloaded applications are broadcasted using the DSM-
CC object carousel. Developers who want to test such applications on an
MHP terminal can use a play out system to compose and broadcast the
DSM-CC object carousel that will include the application. An open source
playout server implementation is available from
http://krusty.cineca.it/vpweb/cgi-bin/blosxom.cgi
20.3 Debug an application:

Manufacturers usually provide developer STBs to ease debugging. These
specific STBs enable the output of application print messages via serial
port or Ethernet connection. They are more expensive than commercial
STBs but make development more efficient. All applications have to be
tested on different kinds of MHP terminals to avoid potential interoperability
difficulties. The MHP-KDB test center offers remote interoperability testing
on a number of common STBs (for more information MHP-KDB web site).
Page 202 of 215

30th March 2006
20.4 Source code of basic application:

The application below will display a text message “Hello MHP World” on
the screen.
/*Include all needed package*/
import java.awt.*;
import java.awt.event.*;
import javax.tv.xlet.*;
import org.havi.ui.*;
public class HelloWorld extends Component implements KeyListener, Xlet {
private XletContext context;
private HScene scene;
private String messageToDispalay = "Hello MHP World";
private HStaticText text;
/* Standard Xlet lifecycle methods and constructors */
public HelloWorld(){
super();
/* Initialize the Xlet. The context for this Xlet will get passed in to this
method, and a reference to it should be stored in case it's needed later. This is
the place where any initialisation should be done, unless it takes a lot of time
or resources.
*/
public void initXlet(XletContext ctx) throws XletStateChangeException {
setName(string);
this.context = ctx;
HSceneFactory factory = HSceneFactory.getInstance();
HSceneTemplate hst = new HSceneTemplate();
hst.setPreference (HSceneTemplate.SCENE_SCREEN_DIMENSION,
new org.havi.ui.HScreenDimension(1,
1), HSceneTemplate.REQUIRED);
hst.setPreference (HSceneTemplate.SCENE_SCREEN_LOCATION,
Page 203 of 215

30th March 2006
new org.havi.ui.HScreenPoint(0, 0),

HSceneTemplate.REQUIRED);
text = new HStaticText(messageToDispalay,70 ,120 ,580 ,40);
text.setBordersEnabled(false);
text.setForeground(Color.white);
text.setFont(new Font("Tiresias" ,Font.BOLD , 24));
scene = factory.getBestScene(hst);
scene.setBounds(0,0,720,576);
scene.setLayout(null);
scene.setBackgroundMode(HScene.BACKGROUND_FILL);
scene.add(this);
scene.add(text);
scene.addKeyListener((KeyListener)this);
this.setSize(scene.getSize());
public void startXlet()throws XletStateChangeException {
validate();
scene.setVisible(true);
scene.requestFocus();
/*
* Pause the Xlet. This method cannot throw any exceptions, since an Xlet MUST
* pause itself when asked. However, exactly what the Xlet should do to pause
* itself is not specified. Doing nothing is allowed, but is not a good idea.
*/
public void pauseXlet(){
scene.setVisible(false);
/*
* Destroy the Xlet. This should release all resources, finish all threads and then
* exit. If the argument is false, then this method can refuse to be destroyed by
* throwing an XletStateChangeException.
*/
Page 204 of 215

30th March 2006
public void destroyXlet(boolean unconditional)
throws javax.tv.xlet.XletStateChangeException{
if(unconditional){
if (scene!= null) {
removeKeyListener(this);
scene.remove(text);
scene.remove(this);
scene.setVisible(false);
HSceneFactory.getInstance().dispose(scene);
scene = null;
context.notifyDestroyed();
else
{/* We have had a polite request to die, so we can refuse
* this request if we want.
*/
throw new XletStateChangeException("Please don't let me die!");
/* Key action will be defined in these functions*/
public void keyPressed (KeyEvent key){}
public void keyTyped(KeyEvent ignored) {}
public void keyReleased(KeyEvent ignored){}
Page 205 of 215

30th March 2006
21 Annex C - Presentation of the MHP APIs NOVICE LEVEL

The APIs used to develop MHP applications are presented in this chapter.
MHP uses a number of already existing standards and also defines some
specific additional APIs. The main Java APIs used in MHP are described in
this Annex.
21.1 “Core” APIs
API Description
java.awt Build applications with graphical user interfaces.

It is separated into two parts:
creating the interface
and defining the behavior.
java.awt.event Provides interfaces and classes for dealing with

different types of events fired by AWT
components
The java.awt.image package contains classes

and interfaces that allow you to create new
java.awt.image
images from scratch rather than loading them
from a file and to modify images that already
exist.
java.beans Contains classes related to Java Beans

development
java.io Provides for system input and output through

data streams, serialization and the file system.
java.lang Provides classes that are fundamental to the

design of the Java programming language.
java.lang.reflect Provides classes and interfaces for obtaining

reflective information about classes and objects.
java.net Provides the classes for implementing

networking applications.
java.security Provides the classes and interfaces for the

security framework.
java.security.cert Provides classes and interfaces for parsing and

managing certificates.
Contains the collections framework, legacy

collection classes, event model, date and time
java.util
facilities, internationalization, and miscellaneous
utility classes (a string tokenizer, a random-
Page 206 of 215

30th March 2006
number generator, and a bit array).
java.util.zip Provides classes for reading and writing the

standard ZIP and GZIP file formats.
Table 21-1: Java Core APIs
21.2 JMF APIs

These APIs are used to control how audio and video content is decoded
and displayed, and are defined by Sun Microsystems. While this is mostly
used for controlling what broadcast video is presented (and how it is
presented), applications can also use JMF to play audio files or display a
special kind of image format.
JMF 1.0 was originally designed to control streaming video and audio from
a disk file either locally or from a “video” file server over a network. In order
to address the unique nature of broadcast streams, JMF was extended by
DAVIC with its org.davic.media package, discussed later. The JMF 1.0
used for iTV contains the following packages:
javax.media
javax.media.protocol
21.3 JavaTV APIs

Java TV (JAVATV) is a transport independent abstraction for access to the
MPEG-2 SI (as extended by the transport standards); with additional
support for the unique properties of broadcasting traditional data items
such as files. It is slightly more favorable to DVB’s SI over the other
systems, since that was its first supported model, however in general it is
99% abstract. It contains the following packages:
API Description
javax.tv.graphics Adds some support to AWT for TV-specific issues

such as video-graphics blending and discovering
the root container of the application
javax.tv.locator Provides the mechanism for URL-like references

to broadcast services and broadcast media clips
javax.tv.media Adds support for TV-specific functionality to JMF
javax.tv.media.protocol Adds support for broadcast streaming protocols

to JMF
javax.tv.net Provides a mechanism for accessing IP

datagrams contained in a broadcast stream
javax.tv.service High-level concepts for describing digital TV

services. This package is also provides the basic
mechanism for querying service information from
the broadcast service.
Page 207 of 215

30th March 2006
javax.tv.service.guide Support for EPG-type applications, including

concepts for describing individual events,
program schedules and parental rating
information
javax.tv.service.navigation Support for navigating services. This includes

support for concepts such as lists of favorite
services, components within services (i.e.
elementary streams) and service types
javax.tv.service.selection Concepts describing how services are presented

to the user, and how a new service can be
selected. This also describes the concepts for
presenting several services at once (e.g. picture-
in-picture)
javax.tv.service.transport Concepts describing the transport mechanism

used for a digital TV service, such as transport
streams, broadcast networks and bouquets
javax.tv.util Utility classes for JavaTV applications, including

management of timers and timer events
javax.tv.xlet Application lifecycle model and supporting

classes
Table 21-2: JavaTV APIs
21.4 DAVIC APIs

DAVIC, Digital Audio Visual Council was an organization set up to promote
audio-visual applications through open standards. It picked up on the issue
from MHEG and added a Java API offering better control of a receiver to an
application. Many participants in DAVIC later also joined DVB for their MHP
work, resulting in the latter incorporating the former.
In MHP today, there are several packages originating from the early DAVIC
work. These packages mainly give an application better control of both
selection and presentation of both audio and video. DAVIC also provides
the framework of scarce resource notification used in consistently in MHP.
org.davic.media includes Java Media Framework extensions relevant to
TV content. Most important is the language control for both audio and
subtitles.
org.davic.mpeg represents MPEG system concepts through Transport
Stream, Service and Elementary Stream classes. This information is partly
extracted from the MPEG PSI information carried in a transport stream.
The sub package org.davic.mpeg.dvb contains extended versions of
these classes with additional DVB specific information. Another sub
package, org.davic.mpeg.sections, provides the ability to filter specific
MPEG sections from a transport stream.
org.davic.net deals with content referencing through the Locator class. In
org.davic.net.dvb this class is extended to be more DVB specific. Explicit
tuning between transport streams is handled with the org.davic.net.tuning
package. However, this is not necessary when switching services. The last
Page 208 of 215

30th March 2006
sub package org.davic.net.ca deals with all conditional access system

issues.
org.davic.resources holds the framework for resource notification adopted
in MHP. Each scarce resource on a device will itself implement the
notification regime, but it should be based on the interfaces found in this
package.
21.5 HAVi (Home Audio Video Interoperability) APIs

The Home Audio Video Interoperability (HAVI) has defined an extensive set
of Java-based packages for consumer electronics devices. One part of
HAVi that has been adopted by the standards supporting Java includes the
user interface (UI) packages. This set of packages requires a subset of the
standard java.awt package as more fully defined in (HAVI). The HAVi User
Interface contains the following packages:
org.havi.ui
org.havi.ui.event
21.6 DVB APIs

The DVB API is custom made APIs for MHP made by DVB. The DVB API
is covered in chapter 11.3.2 and appendix H to U in the MHP specification
[MHP 1.0.3].
org.dvb.application provides access to lists of applications, which are
available in this context and the ability to launch those applications.
org.dvb.dsmcc provides extend access to files carried in the broadcast
stream. The API also provides access to objects like streams and stream
events, and stream event descriptors and NPT descriptors. One of the
most important classes is the DSMCCObject. Instances of this object
represents object in a DSM-CC carousel. DSMCCObjects can be used
directly or by using the java.io.File methods.
org.dvb.event provides access to user input events before they are
processed through the event mechanism of the java.awt package. A class
that implements the UserEventListener can receive input events even
though that application does not have user input focus.
org.dvb.io provides support for inter-application communication and an
extension to the java.io package for access to files held in persistent
storage. With the org.dvb.io.ixc.IxcRegistry class you can obtain a
reference to a remote object residing in another Xlet on the same MHP
terminal. The org.dvb.io.persistent provides access and attributes of files
stored in persistent storage.
org.dvb.lang provides those core platform related features not found in the
java.lang package. The DVBClassLoader is used to load classes and
resources from a search path of URLs referring to locations where Java
class files may be stored.
org.dvb.media provides DVB specific extensions to the Java Media
Framework. Players that are presenting video in an HVideoComponent to
control how the video is clipped use the
org.dvb.media.VideoPresentationControl interface. The
org.dvb.media.BackgroundVideoPresentationControl is only used with
Page 209 of 215

30th March 2006
video presented on the video plane. The interface can be used to set size,
position, and clipping region. The org.dvb.media.VideoFormatControl
provides a way to transform the incoming signal according to the format
defined in the decoder format conversion (DFC).
org.dvb.net provides general networking features not found in other
packages, extensions to the conditional access API from DAVIC, session
management for bi-directional IP connections which are session based
from the point of view of an application and extensions to the tuning API
from DAVIC. The org.dvb.net.ca package provides the CAPermission that
hold permissions for a range of CA system ids. MHP requires support for
HTTP. The org.dvb.net.rc package lets the applications set up a return
channel if needed for the HTTP/TCP/UDP connection. The
org.dvb.net.tuning package holds tuner permissions and associates each
SI database with a network interface.
org.dvb.si provides access to DVB service information. The API maps
more or less directly onto the underlying SI tables. The SIDatabase class
represents the entire database of SI the MHP terminal has access to on a
given tuner. When an application issues a request to the SIDatabase, a
SIRequest object is returned. Most of the calls to the SIDatabase are
asynchronous; when the information requested is available a
SISuccessfulRetrieveEvent is sent. This contains references to the
SIRequest object. By using the retrieveDescriptors method of the
SIInformation interface it is possible to get the descriptors associated with
an SI element. It is also possible to monitor changes to a specific SI
element using the SIMonitoringListener.
The DVBTest class of the org.dvb.test package allows test applications to
log messages during their execution and to indicate their termination
condition in a platform independent manner.
org.dvb.ui provides extended graphics functionality. The DVBGraphics
class is an adapter class to support alpha compositing in an MHP device.
The support for alpha composition allows for rules that say how
transparency is applied to that graphics context and how it is blended with
any components beneath it in the AWT hierarchy.
org.dvb.user provides access to settings and preferences configured by
the end-user.
As seen above several APIs can be used for the same feature. Below are
presented these main features and the available APIs for each.
Graphic control:
AWT,
HAVI,
DVB UI
SI access :
JavaTv,
DVB SI,
Service selection:
Javatv service selection
JMF
Page 210 of 215

30th March 2006
Return channel:
org.dvb.net.rc
Audio/video control:
JMF
DAVIC
Resource management by an application:

org.davic.resource
Tuner control API:

DAVIC
Page 211 of 215

30th March 2006
22 Annex D – Migration
EXPERT LEVEL
This annex presents a synthesis on the migration issues between the
versions 1.0.2 and 1.0.3. It gives an overview on the potential backward
compatibility problems in each domain.
DSMCC-IO
API definition change:
The methods below are not yet synchronized:
public synchronized int subscribe(java.lang.String eventName,
org.dvb.dsmcc.StreamEventListener l) throws
UnknownEventException, InsufficientResourcesException
public synchronized void unsubscribe(int eventId,
UnknownEventException
public synchronized void unsubscribe(java.lang.String eventName,
UnknownEventException
So developers must take care that if application access the same
streamevent object from different threads this can cause problems.
APPLICATION
This new method is added since version 1.0.3 a:
org.dvb.application.AppAttributes.isVisible():
Applications that have been launched are marked as visible and listed, this
method shall return true when application are listed false otherwise.
Developers must avoid using method
org.dvb.application.AppAttributes.isVisible(), which doesn't exist in MHP
1.0.2 terminal for backward compatibility reason.
Application Listing and launching changes:
org.dvb.application.AppsDatabase.getAppAttributes(AppID):
Returns the properties associated with the given ID. Returns null if no such
application is available. Properties of externally authorized applications will
be returned from MHP 1.0.3 onwards thru
org.dvb.application.AppsDatabase.getAppAttributes(AppID).
org.dvb.application,.AppsDatabase.getAppAttributes(AppsDatabaseFilter):
This method will return an empty Enumeration if there are no attributes.
Properties of externally authorized applications will be returned from MHP
1.0.3 onwards thru
org.dvb.application.AppsDatabase.getAppAttributes(AppsDatabaseFilter).
org.dvb.application.AppsDatabase.getAppIDs(AppsDatabaseFilter)
ID of externally authorized running applications will be returned from MHP
1.0.3 onwards thru
org.dvb.application.AppsDatabase.getAppIDs(AppsDatabaseFilter).
Page 212 of 215

30th March 2006
MEDIA
Method definition change:
public interface VideoFormatListener becomes
public interface VideoFormatListener extends java.util.EventListener
So avoid relying on MHP 1.0.2 to VideoFormatListener definition (use MHP
1.0.3 definition, it will work also on MHP 1.0.2 receiver).
RETURN CHANNEL
Method declaration changed:
public interface ConnectionListener becomes
public interface ConnectionListener extends java.util.EventListener
So to be backwards compatible, the developer must assume that an object
that implements the connectionListener interface does not implement the
EventListener interface.
The target for connection can include character “+” as the first character
only to indicate the phone number including international code.
That will affect the following objects:
org.dvb.net.rc.RCPermission;
org.dvb.net.rc.ConnectionRCInterface.
HAVI
Behavior change
If byte array don’t contain a valid image constructor
HBackgroundImage(byte[]) in version 1.03 “may” return an
IllegalImageException so developers that rely on this exception shall not
yet rely on it to be backward compatible.
The function getVideoController shall never throw
HpermissionDeniedException when an application does not currently have
the right to get the VideoPlayer object so that developers shall not yet rely
on such exception.
SI
Normative Clarification
org.dvb.si.Descriptor: the application don’t sub-class this object
Descriptor(). All 1.02 application must not sub-class Descriptor().
Function not supported
getTextualServiceIdentifiers no longer supported. Use getName,
getShortServiceName, getProviderName and getShortProviderName
instead.
Object moved to new package
ServiceComponent has moved to a new package. Avoid usage of this class
if application need to be compatible with both 1.0.2 and 1.03:
“javax.tv.service.navigation.ServiceComponent”
Page 213 of 215
30th March 2006
StreamType has moved to a new package.

Avoid usage of this class if application need to be compatible with both
1.0.2 and 1.03: “javax.tv.service.navigation.StreamType”
Recommendation
In the functions
org.dvb.si.SiNetwork.RetrieveSITransportStream(short, Object,
SIRetrievalListener, short[])
org.dvb.si.Descriptor.SIBouquet.retrieveSIBouquetTransportStreams(short,
Object, SIRetrievalListener, short[]) and
org.dvb.si.Descriptor.SIBouquet.retrieveDescriptors(short, Object,
SIRetrievalListener, short[])
the last argument “someDescriptorTags” shall not be null, because the
behavior is implementation dependent. So developers shall take care about
this case to guarantee the same comportment on each type of
implementations.
Most part of the changes define in Errata 2 are mainly clarifications or
editorial changes; an Errata 3 is coming soon to fix version 1.0.3.
Application
In org.dvb.application.AppProxy a new field is added:
Public static final int INVALID
Security
Changes in the minimum to be supported Certificate Revocation List.
(8 CRLs instead of 5 CRLs).
DSM-CC
In org.dvb.dsmcc the exception ServiceXFRException shall not be thrown if
the Service Domain that actually contains the DSMCCObject is already
mounted.
Behavior changes:
Delivery of carousel within multiple services delivered over multiple trans-
port stream is possible if:
Carousel_id in the carousel_id_descriptor is in the range of 0x100-0xffffffff.
The carousel_id__descriptor for the carousel are identical in both services
(so the carousel have the same carousel_id and boot parameters).
Any changes in DSI shall not provoke the unavailability of a carousel. In
org.dvb.dsmcc the exception ServiceXFRErrorEvent shall not be thrown if
the Service Domain that actually contains the DSMCCObject is already
mounted. Take care if you rely on this exception.
The receiver shall deactivate any event listeners dependant on a timebase
(and may free resources associated with those listeners) under the follow-
Page 214 of 215

30th March 2006
ing conditions If a timebase is deleted (reference to it is removed from the

set of NPTReferenceDescriptors)
but also If a discontinuity is detected (i.e. NPTDiscontinuityEvent
generated) in that timebase;
or If a service selection operation changes the current service, either
through the MHP API or through the service selection feature of the MHP
navigator ;
Page 215 of 215

MHP Guide

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MHP Guide

Hochgeladen von

Copyright:

Verfügbare Formate

The MHP-Guide

A comprehensive Guide to the Multimedia Home Platform,

Document / Version number: D16 / 1.0

Issued by: The MHP Knowledge Project (MHP-KDB)

This document is available at: http://www.mhpkdb.org

Visit the MHP Knowledge Database: www.mhpkdb.org

Document Type: Deliverable

Author: The MHP Knowledge Project

Due date: January 2006

5.3.5 Network operator ................................................................................................62

8.4 Synchronization ......................................................................................................85

11.2.1 Hash files (dvb.hashfile) ...............................................................................104

12.5.2 JPEG ............................................................................................................128

14.3.1 IRT MHP Application analyzer ......................................................................148

19.1 Organization of the Database Content .................................................................193

Figure 11-1: Example of a signed application [Hetzer 2001] .............................................................. 106

1 Purpose of the MHP-Guide

1.2 Target Groups

Authoring Tool Providers

Expert/ Novice Level

Chapter 2: What is interactive television?

2.1 Types of applications      N

2.2 Levels of interactivity      N

Chapter 3: Introduction to MHP

3.1 The DVB Project      N

3.2 The need for MHP as an open standard      N

3.3 MHP activities in DVB      N

3.4 MHP: Current status and new

3.5 Ensuring the interoperability of MHP      N

3.6 MHP in the markets      N

Chapter 4: MHP iTV Applications

4.1 MHP application  N

4.2 MHP applications and the broadcast

Chapter 5: MHP End-to-End Architecture

5.2 MHP end-to-end reference model      N

5.3 Actors of the MHP end-to-end system

Chapter 6: Organization of the MHP knowledge

6 Organization of the MHP knowledge      N

Chapter 7: Basic Architecture

7.4 Principle of scarce resources   N/E

Authoring Tool Providers

Expert/ Novice Level

Chapter 8: Broadcast Protocols

8.2 Transport Stream Elements     N

8.3 DSM-CC     N/E

8.4 Synchronization   N/E

8.5 Section Filtering    N

8.6 Tuning and service selection  N

8.7 Principles of conditional access (smart

Chapter 9: MHP Applications and Application Lifecycle

9.1 Applets and Xlets  N

9.2 Xlet Application    N

9.3 Resident Applications   N

9.4 Stored Applications    N/E

Chapter 10: Service Signaling

10.2 Introduction to SI /PSI     N/E

10.3 Introduction to AIT and application

10.4 Application Loading over Return

Chapter 11: Security

11.1 Security in interactive television

11.2 Signing MHP applications    E

11.3 DVB MHP Public Key Infrastructure

11.4 Authenticating applications in the MHP

2.1 Types of applications N

2.2 Levels of interactivity N

3.1 The DVB Project N

3.2 The need for MHP as an open standard N

3.3 MHP activities in DVB N

3.5 Ensuring the interoperability of MHP N

3.6 MHP in the markets N

4.1 MHP application N

5.2 MHP end-to-end reference model N

6 Organization of the MHP knowledge N

7.4 Principle of scarce resources N/E

8.2 Transport Stream Elements N

8.3 DSM-CC N/E

8.4 Synchronization N/E

8.5 Section Filtering N

8.6 Tuning and service selection N

9.1 Applets and Xlets N

9.2 Xlet Application N

9.3 Resident Applications N

9.4 Stored Applications N/E

10.2 Introduction to SI /PSI N/E

11.2 Signing MHP applications E

11.5 Application Rights Model N

11.5 Other Aspects E

12.2 Layers and composition concept N

12.3 Playable media N/E

12.6 Color Table N

12.8 Color conversion E

12.9 Double buffering E

13.2 Types of return channels N

13.3 Protocol overview N

13.5 Security on the return channel N

14.1 Playout systems N

14.2 MHP terminal architecture E

14.3 Test equipment N/E

15.1 Layout and Design N

15.3 Legibility of Text N

15.4 Recommendations for using colors N

16.1 Technical aspects N/E

16.2 Commercial aspects N

17. Glossary and abbreviations N

19. How to use the MHP KDB N

20. Develop your first Xlet with MHP KDB N

21. Presentation of the MHP APIs N