The Multimedia Home Platform – an Overview

APPLICATION PROGRAMMING INTERFACE

The Multimedia Home Platform – an overview

J.-P. Evain EBU Technical Department

The Multimedia Home Platform (MHP) encompasses the peripherals and the inter- connection of multimedia equipment via the in-home digital network. The MHP solution covers the whole set of technologies that are necessary to implement digital interactive multimedia in the home – including protocols, common API languages, interfaces and recommendations.

This article offers an introduction to the design and harmonization of MHP receivers, starting with a reference model which has been derived from the DVB and UNITEL reference models.

Introduction ➩ A commercially-oriented group, compatibility in a multi-CA environ- DVB-MHP, to define the user and ment. At the beginning of 1996, the UNITEL – market requirements for enhanced universal set-top box project was and interactive broadcasting in the launched by the ISIS Programme of the local cluster (including Internet access). Reference model European Commission. The main aim of this project was to raise awareness of ➩ A technical group, DVB-TAM Different reference models have been the benefits of developing a common (Technical issues Associated with defined for each MHP system currently platform for user-transparent access to MHP), to work on the specification in use. UNITEL used object-modelling the widest range of multimedia serv- of the DVB Application Program- tools to define the application classes ices. Promising progress has since ming Interface (API). and functionalities that would ulti- been achieved towards the harmoniza- mately identify the hardware and soft- tion of what is now widely called the DVB-TAM is currently considering ware resources required by an MHP Multimedia Home Platform (MHP). several API candidates: system. With this system, users would ➩ MHEG-5/Java; be able to access: The MHP Launching Group was born from the UNITEL initiative in order to ➩ Mediahighway +; ➩ enhanced broadcasting services; open the project to external parties via ➩ JavaTV; ➩ interactive broadcasting services; joint meetings. Key representatives of the High Level Strategy Group took ➩ HTML/Java. ➩ Internet services. part in this group, and this collabora- tion eventually led to the transfer of The API chosen by DVB will have to be Fig. 1 shows just a part of the UNITEL these activities to the DVB Project. Two open, in order to suit the requirements reference model which was submitted DVB working groups were subse- of a horizontal market. It will have to to the DVB-TAM ad-hoc group that is quently set up: be CA-independent but will support working on the system modelling. Original language: English English language: Original 29/5/98. received: Manuscript

4 EBU Technical Review - Spring 1998 J.-P. Evain APPLICATION PROGRAMMING INTERFACE

DVB-TAM succeeded in defining a The reference model shown in Fig. 3 – both in terms of hardware and soft- common generic reference model, allows the development of high-level ware. Backward compatibility will be which is shown in Fig. 2. The reference APIs and applications, independent of supported to the largest possible extent, model shown in Fig. 3 is a combination the MHP system infrastructure. e.g. by using scalable applications. of the models shown in Figs. 1 and 2. This model offers system modularity Each application that is developed will through the use of key interfaces. These need to comply sufficienly with the ref- Abbreviations interfaces will be able to maintain the erence model to ensure cross-platform stability of MHP systems as they evolve interoperability in a competitive envi- API Application programming interface A/V Audio / video (visual) CA Conditional access CCETT (France Telecom’s) Cen- tre Commun d’Etudes de Télédiffusion et de Télécommunications CPU Central processing unit DAVIC Digital Audio-Visual Council DRAM Dynamic random access memory DSM-CC (ISO) Digital storage media - command control DSM-CC UU (DSM-CC, user-to-user DVB Digital Video Broad- casting DVB-SI DVB - Service Informa- tion EEPROM Electrically-erasable programmable read-only memory I/O Input/output ISO International Organiz- Basic OS ation for Standardiz- layer ation (Windows NT, Windows 95, JAVA Programming language Mac, OS9) for the WWW (developed by Sun Micro- systems) Figure 1 UNITEL: MHP hardware and software resources MHEG (ISO/IEC) Multi- and Hyper-media coding Experts Group MHP Multimedia home platform mips Million instructions per second MPEG (ISO) Moving Picture Experts Group NIU Network interface unit ROM Read-only memory RTE Run-time engine TAM (DVB) Technical issues Figure 2 Associated with MHP DVB-TAM reference model: system layers.

EBU Technical Review - Spring 1998 5 J.-P. Evain APPLICATION PROGRAMMING INTERFACE

Figure 3 Reference model: a possible API and middleware for pipes and streams. ronment. This should result in host ➩ security and access; Applications platforms where the integrity of the ➩ content loading; application is protected, and its behav- ➩ The predictable environment described iour is stable and predictable (thus navigation and selection; by the reference model will readily resulting in a high quality of service). ➩ declarative content and streams allow applications to be authored and The reference model must also define presentation control; tested. Compliance with the reference modes for data delivery, memory han- model will ensure that applications ➩ communication and I/O control; dling, object handling and instruction execute properly, independent of the execution. ➩ signalling, bit transport, driver and precise MHP implementation. The management functions. integrity of the look, feel and function- The reference model consists of five layers: ➩ application (content, script) and media (audio, video, subtitle) com- ponents; ➩ pipes and streams (see Fig. 4); ➩ the API and native navigation/ selection functions; ➩ platform/system software or middleware, including the interactive engine, the run-time engine (RTE) or virtual machine, the application manager, etc.; ➩ hardware and software resources, and associated software.

The main system functions are: ➩ application launch and control, ses- Figure 4 sion/event management; Reference model: application “pipes” and MPEG streams.

6 EBU Technical Review - Spring 1998 J.-P. Evain APPLICATION PROGRAMMING INTERFACE alities of each application will have to us to define a platform-independent been adopted by DVB. DSM-CC UU is be ensured; the design of the original reference model which can verify the interface that allows us to extract application provider must be pre- whether such applications comply in DSM-CC carousel objects from the served – irrespective of the platform terms of cross-platform compatibility broadcast stream, or via an interactive implementation. It should be possible and performance accuracy. access to a remote server. to design scalable applications that maintain compatibility across a range In reality, applications are neither fully DSM-CC carousel objects allow one or of receiver implementations. declarative nor fully procedural. As an more application objects to be carried example, declarative applications can in one module of the data carousel. DVB-TAM defines an application as a make use of procedural enhancements Objects can be arranged in modules, in functional implementation of an inter- to improve their performance. This order to optimize the performance and active service which is realized as soft- allows us to reduce the size of the appli- use of memory. DSM-CC also includes ware modules. An application can also cation and to reduce its execution time compression tools to format the appli- be seen as a set of organized functions by using routines written in executable cation objects and carousel modules, that request activation of MHP hard- code. Platform-independence is en- and mechanisms to ensure the secure ware and software resources (see Fig. 5). sured by relying on embedded RTEs, downloading of the carousel objects. virtual machines or other interactive An interactive application is basically engines. It is more difficult to achieve built around: compliance of the compiled code rou- Definition of the API ➩ tine libraries for different platforms, if application script (which can be they are not taken into account at the declarative and/or procedural) DVB-TAM has defined an API as a set time of the platform design. of high-level functions, data structures ➩ content/scenes (declarative interface and protocols which represent a stand- and media streams). Applications are identified and sig- ard interface for platform-independent nalled to indicate their availability, and application software. It uses object- The declarative interface is the repre- an appropriate mode of access is pre- oriented languages and it enhances the sentation of the man-machine inter- sented to the user. Applications are flexibility and re-usability of the plat- face. It can consist of graphics such as launched automatically or by request. form functionalities. a background design, selection but- The application presentation can be tons, still pictures, text etc. Each scene nominal or down-sized (if scalable), An application describes a set of can comprise a set of other scenes, thus maximizing the use of the availa- objects according to the definition of application objects and attributes. The ble resources. Application manage- high-level APIs. It defines the interface pipes implement the interconnections ment encompasses: interruptions, (via the interactive engine) between the between the scenes and concatenated failures, priority modes and dynamic applications, and the software and functions. resource allocation. The application hardware resources of the host. The must release the system resources it primitives that are embedded in the Procedural applications, based on low- has used, when quitting. application objects are interpreted, and level functions and primitives, are used the resources that are requested by the when very strong optimization is corresponding declarative and proce- required at the host level (e.g. to mini- Application delivery dural functions are activated. The mize the platform footprint and maxi- interpreter is an executable code. mize the use of the transmission mechanisms resources). Procedural applications are UNITEL identified the following API generally platform-dependent and, Application script and content are requirements: hence, each one must be verified on the grouped together in application objects different host platforms. which are converted into DSM-CC car- ➩ Openness: it should be specified in ousel objects. DSM-CC has been stand- such a way that it can be used in the Declarative applications use high-level ardized by MPEG for the retrieval and implementation of other interfaces. functions and primitives. This allows transport of MPEG streams, and has ➩ Abstraction: it should not expose its implementation. It should also hide all aspects of the underlying software and hardware.

➩ Evolution: it should be flexible and easily extendible.

➩ Scalability: it should be hardware- independent in order to take advan- tage of future improvements in hardware and of the characteristics of different hardware implementations. The API itself can be updated or complemented by, for example, Figure 5 adding new libraries (e.g. proce- DVB-TAM: relationship between hardware entities, resources dural extensions) by means of and functions. download mechanisms.

EBU Technical Review - Spring 1998 7 J.-P. Evain APPLICATION PROGRAMMING INTERFACE

According to the application format, (Fig. 3), the navigator has consequently compatibility between the signals low-level and/or high-level APIs will been placed at the same level as the API transmitted by the different broad- be used to deal, respectively, with pro- to enable boot access to pipes and casters and content providers. cedural and declarative functions: streams. ➩ The security model should include ➩ a description of the procedures and Low-level APIs are more procedural The basic navigator should: and tend to access low-level proce- entities that must be put into place dural functions. The API interprets ➩ list all the programmes available, to support the associated secret the application function or primi- without discrimination; management issues. It should be tive but also knows how to activate independent of CA systems. The ➩ allow user-friendly access to these the resources. MHP API should give access to CA programmes by offering appropri- functions, if and when required. ➩ High-level APIs are more declarative. ate shortcuts (e.g. specific remote- The higher the level of abstraction control buttons). Among the important security aspects declaration (i.e. the hiding of the to be addressed are (i) machine protec- system implementation), the Enhanced navigation can then be pro- tion against abusive requests for sys- stronger is the system independ- vided by means of electronic pro- tem resources (e.g. excessive demands ence. The API interprets the appli- gramme guides, possibly including on memory) and (ii) protection against cation function or primitive but such enhanced facilities as user profiles non-authorized access to data (e.g. pri- does not need to know how the cor- and bookmarks. vate data). responding resources will be activated. Application launch and The specification of an open API should Middleware lead to the embedding of this hard- control ware-independent facility within DVB The possibility of implementing the receivers. The application launch function, and API by means of middleware is directly the application and presentation con- related to the application format DVB-MHP has stated that the API trol functions, provide the facilities to (whether declarative or procedural) should: run an application. The application and the use of either low-level or code may be already resident in the high-level APIs. Each middleware ➩ support applications that are STU or it may be obtained via a session implementation will be tailored for locally stored as well as those that to a remote server. After loading, the optimum use by the host platform. are down-loaded in either real time application is launched and execution or non-real time; is transferred to the new code. There can be different ways of imple- ➩ preserve the “look and feel” of the menting the interactive or run-time application; It is the application manager’s respon- engine which, in general, is required to sibility to: ➩ enable access to databases (e.g. support the following: ➩ DVB-SI); check the code and data integrity; ➩ the script and content interpreters; ➩ ➩ synchronize the commands and allow room for competition among ➩ the libraries; implementers. information; ➩ ➩ adapt the presentation graphic for- the event manager (remote control An open and evolutionary (modular, and other devices, user actions, mat to suit the platform display; portable, flexible, extendible) API is markers, timers, the handling of vital for the implementation of plat- ➩ obtain and dispose of the system error conditions); forms in an unfragmented horizontal resources; ➩ the loader. market. This will allow different con- ➩ manage the error signalling and tent and service providers to share dif- exceptions; Depending on the API used, the RTE ferent implementations of compliant ➩ offers low-level interfacing with the platforms. initiate and terminate any new ses- sions; system hardware and software resources. The RTE may call up resi- ➩ allow the sharing of variables and dent programmes which can use a Navigation/selection contents; native platform-dependent interface to ➩ conclude in an orderly and clean improve the system performance and The API can also be used by resident fashion. to diminish the operational constraints programmes such as the embedded (e.g. the size of the downloaded appli- navigator function that allows a first cation objects) at the declarative appli- level of navigation when the receiver is Security functions cation level. The RTE is executable switched on. APIs can also be used to code, adapted to each platform and manipulate streams and to enable basic aligned with the reference model. functions such as channel/pro- DVB has defined the following security requirements (although the security gramme hopping or “zapping”. The virtual machine can be used to model itself has not yet been defined): emulate declarative interfaces but it is The navigator can also be implemented ➩ The API should be accompanied by generally used to run procedural func- in executable code, in which case it a system which incorporates a com- tions (e.g. complex calculations, infor- does not need to use the API and its mon security model for the applica- mation and text processing, data interpreter. In the DVB-TAM model tions and data. It should enable full extraction) or resident programmes

8 EBU Technical Review - Spring 1998 J.-P. Evain APPLICATION PROGRAMMING INTERFACE that enhance the declarative interface DVB has currently defined three pro- the API. According to DVB-MHP: “the of the application. files. These require a minimum of migration process will be initiated when 1 Mbyte of Flash-ROM and 1 Mbyte of service providers have begun to offer serv- The use of run-time engines and vir- DRAM, up to a maximum of 16 Mbytes ices in a format that is compatible with the tual machines allows the API to sup- of Flash-ROM and 32 Mbytes of DRAM, MHP solution”. port the platform independence of coupled with a CPU speed from applications. 20 mips to more than 100 mips. It is DVB receivers already make use of a sometimes specified that, for example, large number of common elements 70% of CPU time should be devoted to including the modulation and multi- Hardware and software run the applications, with the remain- plexing schemes, MPEG-2 audio and resources ing 30% being used for the system video, the DSM-CC UU interface and management. protocols, the Common Interface (for conditional access and other uses) and The Multimedia Home Platform must Stored in ROM are the following: the DVB-SI. be user-friendly. A minimum set of ➩ the API interpreter; peripherals includes a display, a point- Nevertheless, a number of elements ing device and, optionally, a keyboard ➩ the libraries; differ between implementations: and local internal/external permanent storage. The connection of these ➩ the run-time engine and/or virtual ➩ the mechanisms which combine peripherals should be on a “plug and machine; application script and code, data and contents into application play” basis. ➩ the loader, objects; Internal resources in the MHP receiver ➩ the system tools; ➩ compression tools; include the front-end, demux, decod- ➩ the file system; ers, filters, a common interface, a com- ➩ the format of procedural functions; ➩ munication interface, a CA system, the firmware; ➩ memory and associated drivers. libraries (e.g. procedural exten- ➩ the operating system (boot-up, sions, graphics); memory management, task sched- ➩ uler, resource identification, alarms data carousels or other cyclic data and timers, resource locking); delivery mechanisms; ➩ the drivers; ➩ down-loading procedures and tools; ➩ the navigator. ➩ memory allocation and manage- The use of Flash memory allows a lim- ment (e.g. application queues and ited number of revisions to be down- garbage collection); loaded. Flash memory can be ➩ interactivity; partitioned in order to reserve memory segments for different memory uses ➩ the formats of the variables; and, for example, to refresh selectively ➩ only part of this memory. security procedures.

Jean-Pierre Evain graduated from The applications delivered via the DVB has requested that, in a multi- ENSEA, Cergy-Pontoise (near Paris), in DSM-CC carousel are stored in RAM. provider / multi-application environ- 1983. His first employment was with RAM is also used for video/audio/ ment, the MHP solutions should be CCETT in Rennes and, in 1992, he data decoding and buffering, for based on the separation of data. This moved to Geneva to join the EBU Tech- will enable different authorized appli- nical Department as a Senior Engineer. dynamic platform management (e.g. process queues, stacks), for data, and cations to use this data (if in a common Currently, Mr Evain works in the EBU for persistent storage of data such as data format), particularly as different division called “New Systems and Serv- application variables. applications can be implemented to ices” and is a member of various BMC accomplish the same task. It will be project groups. He represents the EBU The basic system configuration and possible to reserve part of the data for in various international consortia and factory settings are usually stored on specific applications. in European collaborative projects. EEPROM (using less than 10 Kbytes of Concerning his MHP and API activities, memory). At the system level, migration should Jean-Pierre Evain is the project Man- be considered carefully in order to ager of the CEC DG3 UNITEL project. achieve the largest possible use of the He chaired the MHP Launching Group DVB-TAM API. This will help to main- that eventually led to the transfer of Migration and future tain receiver portability and mobility, MHP activities to DVB. He launched operational issues the ICT-SB project group on MHP har- particularly for digital terrestrial monization. He is now the Secretary broadcasting where the limited of the DVB-MHP requirement group Migration is primarily the process by number of programmes is another rea- and is actively following the DVB-TAM which a population of receivers based son to support solutions which favour and DAVIC activities on the API. He on proprietary software systems are all a horizontal retail market. The con- also represents the EBU and UNITEL in converted to a population of MHP sumer will probably not invest in sev- the ETSI-MTA (Multimedia Terminals and Applications) group. receivers which use the common eral receivers if the added content DVB-MHP system and, particularly, value is limited.

EBU Technical Review - Spring 1998 9 J.-P. Evain APPLICATION PROGRAMMING INTERFACE

Migration will not be “easy”. It will ➩ similar start-up and closing appli- [3] DVB document TAM 029 rev. 5: require substantial effort and collabo- cation procedures should be used; TAM Reference model. ration, e.g. to maintain backward com- ➩ the amount of re-inscriptible Flash [4] M. Echiffre et al. (CSELT): MHEG-5 patibility with currently-deployed plat- memory that is available should be – Aims, concepts, and imple- forms. defined. mentation issues IEEE 98. The wide use of a common API will MHP platforms will evolve and will be raise new operational issues. There [5] J. van der Meer and C.M. Huizer able to support more complex and, (Philips): Interoperability be- will be significant changes in the hopefully, scalable applications. These tween different interactive modes of operation of the service pro- may require further API extensions. engines for digital television, viders who, currently, target well- Future evolution should certainly aim problems and solutions defined and proven receiving plat- at increasing the degree of commonal- Philips, June 1997. forms. In order to accommodate differ- ity of these system elements and proce- ent implementations of platforms, all dures. This should contribute towards [6] DAVIC 1.4 specification – Part 9 using a common API, we will have to increasing the cost-effectiveness of the [7] An API and an Operating Sys- follow certain generic guidelines: system. It should also help to increase tem for Interactive Digital TV the lifetime of the equipment. Decoders ➩ applications will have to be OpenTV, January 1998. down-loadable and should not rely on persistent storage when the [8] N. Birch (S&T): The UK MHEG pro- application is not active; Acknowledgements file as a response to DVB TAM RSD1 ➩ common libraries (procedural The Author would like to thank the UK Digital Television Group, April extensions, graphics etc.) and resi- DVB-MHP and DVB-TAM members 1998. dent programmes should be who patiently agreed to describe their embedded in order to limit the size [9] UNITEL Deliverable 3.1: Charac- of the application; respective systems, and also Philippe terisation and specification of Bridel (France-Telecom/CCETT) who the architecture reference ➩ application, data and declarative developed the UNITEL architecture model interfaces should be organized in and reference model. CCETT on behalf of the UNITEL accordance with common generic Consortium, December 1997. schemes; ➩ the same data carousel object for- Bibliography mat should be used, and the same [1] G. Luetteke (Philips): The DVB And in this issue ... mechanisms should be applied for Multimedia Home Platform [10] A. Mornington-West: MHEG-5 the delivery of these objects over MUST’98, May 1998. the streams being broadcast; and Java – the basis for a com- [2] ITU-R document 11A/107-11: mon European API? ➩ common compression schemes Examples of API structure EBU Technical Review, No. 275, should be adopted; ITU/EBU, April 1997. Spring 1998.

10 EBU Technical Review - Spring 1998 J.-P. Evain