You are on page 1of 6

Set-Top Box Software Architectures for Digital Video Broadcast and Interactive Services

Rudolf Jaeger BetaResearch Betastrae 1 85774 Unterfoehring Germany rudi_jaeger@betaresearch.de

Abstract
Consumer and Business demand for Multi-Media services has led to a proliferation of solutions that provide a wide range of services such as Digital Television, Internet Connectivity and others. Set-Top Boxes (STB), the consumer device employed in Digital Video Broadcasting Networks, are mainly used for digital television reception and also for interactive services such as Internet Access or Homeshopping. This paper presents the software architecture of two generations of STBs called the d-box. The first generation of the d-box shows a monolithic software structure with a native Application Programming Interface. In particular we will discuss the application download mechanism in detail. With the introduction of the Java language and a layered software approach it is possible to reach both goals, namely writing system independent applications and adapting to new hardware platform without a significant change in the d-box software. The second part of the paper discusses the software architecture of the second generation of the d-box focusing upon the employed inter-process communication means. In addition an example of an User Interface dialog for the set-up will be presented taking into account that both novices as well as experts are every day users of the d-box.

applications which are platform independent and providing an user interface which allows an easy access to the various services are other requirements which affect the software architecture. The following chapter discusses the two service models for interactive services. In chapter 3 we describe the architecture and some implementation issues of the first generation of the d-box. The emphasis is put upon the application download functionality offering some degree of interactive services. Chapter 4 presents the software architecture and its implementation of the second generation of the d-box focusing on the intersubsystem communication means. This chapter concludes with an example of an User Interface (UI) dialog.

2. Service models Broadcasting

for

digital

video

2.1 Local Interactivity Service Model


In the early stage of digital video Broadcasting the primary function of STBs was to receive, select and display digital-quality videos. Broadcast video streams are characterised that they are not further accessible after the moment they have been broadcast (limited linear reception model). Within the video streams specific information in form of tables [1] [2] are multiplexed to provide the STB with signalling information required for synchronisation, tuning and program selection. This information must be available throughout the duration of the program. Due to the fact that anyone can enter the program at any time the signalling information is played out using the data carousel mechanism (enhanced reception model). Combining both models it is possible to provide the so-called local interactivity for the STB user. The Near

1. Introduction
Although the cost aspect is one of the most driving factor for deploying a Set-Top Box (STB) as a consumer device, the design and implementation of the software architecture becomes very important, because it must be flexible enough to adapt to new interactive services e.g. internet access. In addition adapting to the short life cycles of Hardware platforms, writing

Video on Demand (NVoD) service offering the same program at time shifted beginnings is a typical example of a local interactivity. For this scenario films are played out in an overlapped fashion. The necessary signalling information for selecting the film, obtaining further information of the film etc. is broadcast. Another example of local interactivity could be a simple data application e.g. a ticker, which is synchronised with the video stream. The application data and the actual ticker data are distributed via the data carousel mechanism. From the network point of view the digital broadcast network acts as a large serial disk for the storage of signalling information used for selection the video/audio streams, applications and actual data used by the applications. This communication model allows STBs with a very limited local caching capability to find the necessary data and code on the network at any time with a worst case access time equal to the carousel cycle duration. There are no connection and log-on latencies when using this kind of communication model.

2.2 Global Interactivity Service Model


The local interactive service model is enhanced by offering on demand services. Applying this model, the STB user is enabled to interact with a server system by means of a Return channel network. For example interactive advertisements let the user obtain more information about a product on demand by linking the video commercials with an associated interactive data service. An interactivity icon, usually customised for different user profiles will be displayed offering e.g. an interactive shopping option. The entire service model follows a two stage approach. The application loading and synchronisation with the video stream (first stage) is done by the data carousel mechanism as explained above. Performing the application (second stage) may be accomplished by an one-to-one client/server communication employing also WWW facilities.

number of Hardware devices for interfacing with the outside world. The various device driver modules were interfaced to the software modules of the middleware layer using driver specific interface definitions. There is no Hardware Abstraction Interface (HAI) which allows software components to be defined which are neither hardware-dependent nor middlewaredependent. The middleware layer contains modules to be used for - building the various service and program information needed for the video selection - performing conditional access related functions - performing the system software upgrade of the STB over air - providing the low level graphic functions. On top of the middleware layer the applicationdependent components are built. They consist of modules used to implement the specific details of an application e.g. an Electronic Program Guide (EPG). As the name implies, these modules are not reusable across different applications. In figure 1 such an architecture is shown. The first generation d-box also follows this approach. The device driver and subsystem modules written in C/C++ are highly dependent on each other because their interfaces were designed according to the other modules they interact with. For example the MPEG video decoding subsystem module written in C++ had many .h files of other modules #included. Thus this module becomes dependent on the interfaces of the other modules.

6\VWHP6RIWZDUH PRQROLWK

$SSOLFDWLRQ (3*
7LFNHU

$3,

3. Software architecture of first generation Set-Top Boxes


3.1 Implementation aspects
The capability of functionality of the first generation STB is limited by its processor power and its small memory footprint. The initial goal was to provide digital television reception functionality with the option to download and execute applications supporting local interactive services. The Hardware is usually composed of a CPU, FPROM/RAM and a
7DVN 0RGXO

2 S H U D W L Q J 6 \ V W H P

''



''

6RIWZDUH ''

LQWHUWDVNFRPPXQLFDWLRQ

'HYLFH
LQWHUPRGXO

'ULYHU

FRPPXQLFDWLRQ

Figure 1: Software architecture of the first generation d-box

Modules were assigned to tasks. The communication and the synchronisation among the tasks are accomplished by means of Operating System services. The outcome was a software architecture and an implementation characterised by a strong monolithic structure which consists of one single executable file (s. figure 1). The size of the entire system software (executable file) of the first generation d-box occupies less than 1 MByte FPROM thus fulfilling its stringent memory constraint.

blocks are received by the d-box, a CRC check is done to verify the correctness of that particular block. If the block is verified correctly, the block payload is stored and the block table is updated. If a data block reception fails due to transmission bit errors or the CRC is incorrect, the d-box waits for the next repetition of the file to be played out. After successful reception of the entire application image, the transition to the application linking state occurs automatically. 3. Application Linking The Dynamic Linker, which conforms to the IEEE-695 standard [4], and resident as a task in the d-box, links the system API function calls in the file image to the system software through the use of a linker symbol table. This table contains the string names and addresses of all the API functions available in the dbox. The current linker is able to support distributed linking, meaning that the copy of the object code used by the linker may be distributed over more than one memory area. An executable image is created and an automatic transition to the application start state occurs. 4. Application Start The application starts automatically and may be terminated in different application-specific ways but the primary way is to use the remote control by pressing the TV button. The executable remains in RAM until a new application is downloaded or the system software requires use of the memory.
79 YLHZLQJ
VKRZ DSSOLFDWLRQV

3.2 Application Download Mechanism


In order to support already local interactivity services exceeding the NVoD functionality, e.g. offering a ticker or simple games, the application download mechanism offering an Application Programming Interface (API) accompanied by a Software Development Kit was implemented in the first generation d-box. The functionality of the application download mechanism is controlled by a finite state machine and can be invoked from the TV viewing state using EPG commands. A successful application lounch comprises the following four states (s. figure 2). 1. Application Lister 2. Application Launching/Loading 3. Application Linking 4. Application Start 1. Application Lister Within this background task the application names will be searched and prepared for display on the EPG. The names and descriptions of applications available for downloading and selection are conveyed by using the Program Specific and Service Information tables. Within the Program Map Table, the stream_type parameter identifies the data delivery mechanism which is in this case the DSM-CC data carousel [3]. Within the Event Information Table, the short_event_descriptor parameter is used to transmit the textual description of the application (application name, description of the application etc.) that is displayed on the EPG. 2. Application Launching/Loading Using the remote control, a user may select one of the listed applications. After a selection has been made, a state transition from application lister to application launching/loading occurs. The DSM-CC based data carousel reception mechanism starts. As the data

UHWXUQ WR79

OHDYH

$SSOLFDWLRQ /LVWHU

$SSOLFDWLRQ /LQNLQJ

DSSOLFDWLRQ

VHOHFW DSSOLFDWLRQ

GHVHOHFW DSSOLFDWLRQ

$SSOLFDWLRQ /DXQFKLQJ /RDGLQJ

$SSOLFDWLRQ 6WDUW

Figure 2: States for implementing the Application download mechanism

4. Software architecture of the second generation d-box


4.1 Introduction
From an application provider point of view, the developed applications should be highly portable (write once run everywhere). Other constraints come from the software/hardware life cycle. The hardware life cycle is a magnitude smaller than the software life cycle. The software architecture and its implementation must ensure, that an introduction of a new Hardware platform requires minimal adaptation of the existing software. Driven by these requirements the software architecture of the second generation of the dbox was designed. It is characterised by its highly layered structure as depicted in figure 3. A clear separation of all hardware related functions are accomplished by the Hardware Abstraction Interface (HAI). It provides a generic interface to all Hardware dependent device drivers. Thus a change of the underlying hardware only affects the associated device driver, no changes within higher layers are necessary. On top of the HAI the DVB, graphic and communication subsystems are built which themselves are interfaced to the BetaResearchVM (Java VM) [5]. All platform functionality used by the Java applications is encapsulated by the VM. The application space comprises infrastructure modules which build the basis for the actual applications.

The details of the modules can be found in [6]. In the following subsections the functionality and implementation of the HAI is explained in detail.

4.2 Functionality of the Hardware Abstraction Interface


The foundation block for the second generation of the d-box 2 software system is a real time operating system. A UNIX-like system kernel was chosen for controlling an embedded consumer device. Its actor and threading mechanism provide the fundamental communication means used by all subsystems. For each device driver there exists a number of function calls performing operations such as read(), write(), ioctl() etc. As an example, the steps to be performed for a DEMUX read command are described. After initialisation two tables are built pointing to the actual function calls for each device driver ((1) in figure 4). In other words the device registers itself at the HAI. An upper layer device driver call is transferred to the HAI using operating system interthread communications ((2) in figure 4). The actual execution of a specific driver function call occurs within the HAI. In order to exploit the multithreading capability it must be ensured, that several upper layer modules are allowed to access the same device driver function even though the previous call may not yet have been completed. For example a second DEMUX read command for acquiring different Service Information tables might be issued from the upper layer modules before the first read command was completed. The multithreading capability of the operating system protects all local variables (each thread has its own stack) but the protection does not apply for global variables. For example the data of DEMUX queue (i.e. physical unit) are global and do not belong to the function calls. Therefore it must be protected by means of semaphores within the driver function call code. In figure 4 this is depicted with the insertion of the lock() and unlock() specifically for the read() function call.

Figure 3: Layered architecture of the generation d-box

second

VXEV\VWHPDFWRU

,QLW '')BWDEOH +$, '(08;

'HYLFH'ULYHU

IXQFWLRQBWDEOH

DEMUX read write ioctl


 UHDG'HPX[ IXQFWLRQV 'HPX[ JOREDO

of the Service Descriptor Table (SDT). The acquisition of the SDT table is done in conjunction with the HAI and the DEMUX device driver as outlined in the previous subsection. After completion of filtering, the table is stored in a shared memory area and a table complete message is returned to the calling Java thread ((2) in figure 5). The VM copies the tables into the Java environment where the channel search thread builds the actual data (channel name, bouquet name etc.) to be displayed by the UI subsystem ((3) in figure 5).
FKDQQH O VHDUFK -90 

03(*

6'7

03(* ZULWH LRFWO

90KHDS

UHDG  ORFN $FFHVV+:

WKUHDG

XQORFN $FWRU ''&RGH UHWXUQ

6'7 '9% 6,

Figure 4: Performing a DEMUX read command using the Hardware Abstraction Interface

WKUHDG VKDUHG PHPRU\

4.3 Interfacing the Java environment to the native software layers


Within this subsection we will discuss the implementation and communication issues of how Java software modules interact with native modules. Based upon a channel search the communication means will be explained in detail. In general, major functions of the applications are implemented as Java threads. Each Java thread is assigned to an operating system thread. In terms of the thread management, there are two possibilities. Either it is done within the BetaResearchVM or it is performed within the underlying Operating System. For our implementation we use the latter approach because the Operating System in use offers a synchronisation mechanism and a fixed priority pre-emptive scheduler. Both features are needed for handling multiple and distributed threads. A thread management within the VM would be more appropriate if the underlying Operating System does not provide such features. The channel search functionality runs as a separate thread. A channel search is initiated by issuing an inter thread call (OS call) from the channel search thread to the SI thread within the DVB actor ((1) in figure 5). A channel search requires among other tasks the building
DEMUX-DD

WKUHDG

DFWRU

Figure 5: Inter-subsystem communication for building the SDT

4.4 User interface assistant concept


In comparison to various other approaches the d-box provides more than one way for the user to access its features, thereby directly reflecting that both novices as well as experts are every-day users of the d-box as an every-day device. In order to offer appropriate support for the novice a number of specialised assistant applications (e.g. for configuring the device, for managing the channel list of the device etc.) are available. Since the primary directive of all assistants is to offer easy and guided access to the dbox, only a subset of relevant features can be accessed, employing a very literate UI dialog-style. In contrast to

this, the expert UI dialog allows a broader and more direct access to d-box features, employing a more terse dialog-style well suited for expert users. An example is shown in figures 6 and 7.

user configurable d-box settings as well as an expert UI dialog excerpt for the automatic channel search user task.

5. Summary
The software architecture of the first generation of the d-box fulfilled the stringent memory constraints while offering significant functionality including support of downloadable applications. The size of the entire system software (executable file) occupies less than 1 MByte FPROM. This download capability allowed the enhancement of the service space from purely digital video reception to interactive data services. The major advantage of the modular and layered-oriented architecture of the second generation d-box presented is that it is highly independent of any specific hardware and OS platform. This allows the hardware platform to be quickly upgraded to add new features without significant redesign of the system software.

Figure 6: Assistant UI dialog for the channel search The figures show two ways to execute the user task perform automatic channel search. In the Start Assistant (s. figure 6), the user cannot modify parameters that are used for the channel search (e.g. number of antennas connected, installation options etc.). Rather, reasonable defaults for the parameters stored in the configuration data store are used for the operation. The user is fully guided through the whole configuration task.

6. Acknowledgement
The STBs presented herein summarises the work of many people. Special thanks to Michael Brandt, Frank Lonczewski, Martin Mohring, Wolfram Proske, Hartmut Wolf and Juergen Zeller for their tremendous contribution in the architectural design and implementation work of the second generation d-box. Thank you to David Gillies and Sven-Olof Koopmann for their review improving the readability of the paper.

7. References
[1] ETR 300 468 Specification for Service Information in DVB Systems, January, 1997 [2] ETR 211 Guidelines On Implementation and Usage Of Service Information (SI), August, 1997 [3] ISO 13818-6 Extension For Digital Storage Media Command And Control, MPEG 96, July 1996 [4] IEEE Std.695-1990 Standard For Microprocessor Universal Format For Object Modules, July 24, 1990 [5] Arnold K. and Gosling J., The JavaTM Programming Language, Second Edition Addison-Wesley, Reading, MA, 1998 [6] Lonczewski F. and Jaeger R., An extensible Set-Top-Box Architecture for interactive and broadcast Services offering sophisticated User Guidance, Proc. In ICME 2000, New York [7] Pekowsky S. and Jaeger R., The Set-Top-Box as a MultiMedia-Terminal, IEEE Transactions on Consumer Electronics, August 1998, Vol. 44, Nr. 3

Figure 7: Expert UI dialog for the channel search All the user has to do (e.g. in the absence of any error situation) is to press repeatedly the Ok button on the remote control. In contrast to this, the expert settings offer direct access to all user configurable parameter settings of the d-box. In the UI dialog no user guidance is employed. Figure 7 shows a menu with some of the

You might also like