# Interactive Digital Terrestrial Television:  The Interoperability Challenge in Brazil

Authors: Jordi Amatller Clarasó; David Baldo; Giuliano Benelli; Giovanni Luca Daino; Riccardo Zambon
Journal: International Journal of Digital Multimedia Broadcasting
 (2009)

---

## Abstract

This paper introduces different standards implemented in existing Digital Terrestrial Television Broadcasting systems to allow the fruition of interactive services and applications through digital Set Top Boxes.  It focuses on the interoperability issue between the Brazilian and the European architectures. In fact, despite in Brazil the GEM specification has been designed to foster wide content compatibility across a range of interactive platforms, it has never come to a final implementation and deployment. As a result the interoperability issue has been deeply explored in the BEACON project and an innovative system architecture has been  developed to deploy t-learning services across Europe and Brazil, providing integration of those systems that were not able to interoperate until nowadays. This work is an important step in the direction of standards' interoperability. As a result, MHP and Ginga NCL-Lua implementation appeared to be the very best choice to deliver interactive services in an interoperable mode between European and Brazilian digital television.


---

## Body

## 1. Introduction

In the past, several DTTB (Digital Television Terrestrial Broadcasting) systems have been designed and developed, differentiating upon how each modulation system meets specific conditions such as the use of the spectrum resource, coverage requirements and transmission network structure, reception conditions, type of service required, policy, cost to the consumers and broadcasters, and so forth.Those DTV (Digital Television) systems are now replacing  old analog TV systems all over the world with the introduction of several standards (European, Japanese, North-American, Korean, Brazilian, etc.) to supply innovative features and services.Moreover, a relevant added value for digital broadcasting comes from the chance to develop interactive applications through reference standards related to each DTV system implementations enumerated above.As a matter of fact,  the interactivity standardization has not been developed in an homogeneous way, because every DTV system needs its ownApplication Programming Interfaces (APIs) to communicate with the interactivity middleware and every implementation is grown basing on its country technologies, needs and laws; so those standards are generally not compatible.To allow broad content compatibility across a range of  new interactive platforms, the GEM (Globally Executable MHP) [1] specification has been created. It defines a subset of APIs removing the transmission-related elements and retaining the application’s ones. As a consequence, application developers can build applications that work on any GEM-compliant platform, and middleware developers can use GEM as the core of their products, by mean of some customization to provide different versions of middleware.Unfortunately, the use of GEM specification in Brazil is unavailable due to some legal and royalties issues. As a result, it is actually not possible to adopt the GEM specification solution to create interactive applications that can work on different DTV systems also including the Brazilian one.To solve this problem, going a step ahead in the interoperability between DTV standards, the BEACON project identified a different solution compliant with Brazilian middleware standards. Consequently, based on an innovative system for management and broadcasting, an integrated system architecture has been designed to deliver t-learning services across Europe and Brazil, providing integration of systems that until nowadays was not able to cooperate.This goal is achieved providing methodologies, process schemas, and pilot applications granting new opportunities for all the players involved in the value chain.A relevant improvement to the social inclusion is also provided because, as it will be explained in the next paragraphs,  the t-learning services delivered with the BEACON platform are addressing the need to cover the Brazilian social-gap permitting (through t-learning) a profitable training for entering the university.To help the reader going through the article, sections are organized as follows. Section2 gives an overview of DTTB standards involved in the project and in its overall architecture. Section 3 describes the interactivity standard developed for those DTV systems, introducing a brief GEM description and an exhaustive paragraph regarding the Brazilian interactivity standardization issues and problems. Then Section 4 describes the BEACON project focusing on its objectives and the methodologies involved in the design of the platform. A deeper analysis of the system architecture  implementation is provided in Section 5, where the whole architecture is described focusing on the t-learning service implementation, the technologies involved in  the applications’ deployment, and the needed upgrades to obtain the integration between the European and the Brazilian DTV frameworks. Finally, Section 6 present the project outcomes  and Section 7 opens a window on the future works concerning these system architectures and how they can strongly improve the benefits brought from our works.


## 2. DTTB Standard Overview

In the next paragraphs we provide a brief description of the DTTB European standard, the Japanese standard, and the Brazilian standard (that is directly derived from the previous ones).This overview is not exhaustive, because actually there are also a North-American terrestrial television implementation (namedAdvanced Television Systems Committee, ATSC) and a Korean one (Digital Multimedia Broadcasting-Terrestrial, DMB-T) with their related interactivity standards, but they are out of the scope of this work; so they are omitted.As a matter of fact, this brief overview just provides a basic knowledge of the lower layers supporting the system architecture that we have deployed and that will be illustrated in this article.


### 2.1. DVB-T

The DVB-T (Digital Video Broadcasting-Terrestrial) specification refers to terrestrial broadcasting. The system has been designed to operate within the existing UHF spectrum allocated to analogue television transmissions. The system was developed for 8 MHz channels but it can be scaled to any channel bandwidth (8, 7, or 6 MHz) with corresponding scaling in the data capacity. The net bit rate available in 8 MHz channel is in the  4.98–31.67 Mbps range, depending on the choice of channel coding parameters, modulation types, and guard interval duration.The system was essentially designed to be able to adapt to all types of channels. It is capable to cope not only with Gaussian channels, but also with Ricean and Rayleigh channels. It can withstand high-level (up to 0 dB) long delay static and dynamic multipath distortion.The system is robust to interference from delayed signals, either echoes resulting from terrain or building reflections or signals from distant transmitters in a single frequency network arrangement [2, 3].The system features a number of selectable parameters that accommodate a large range of carrier-to-noise ratios and channel behaviours. It supports fixed, portable, or mobile reception, with a consequential trade-off in the usable bit rate.This range of parameters allows the broadcasters to select a mode appropriate to the application foreseen. For instance, a pretty robust mode (with a correspondingly lower data rate) is needed to ensure reliable portable reception with a simple set-top antenna. A less robust mode with a higher data rate could be used where the service planning involves frequency-interleaved channels [3, 4].Less robust modes with the highest data rates can be used for fixed reception and for digital TV broadcasting.


### 2.2.ISDB-T

ISDB (Integrated Services Digital Broadcasting) is a new type of broadcasting intended to provide audio, video, and multimedia services. The system was developed for terrestrial (ISDB-T) and satellite (ISDB-S) broadcasting.For terrestrial broadcasting, the system has been designed to have enough flexibility to deliver digital television and sound programs and offer multimedia services in which different types of digital information such as video, audio, text, and computer programs will be integrated. It also aims to provide stable reception through compact, light and inexpensive mobile receivers in addition to integrated receivers typically used in homes.The system uses a modulation referred to asBand-Segmented Transmission (BST) OFDM, which consists of a set of common basic frequency blocks called BST-Segments. Each segment has a bandwidth corresponding to 1/14th of the terrestrial television channel spacing (6, 7, or 8 MHz depending on the region). For example, in a 6 MHz channel, one segment occupies 6/14 MHz = 428.6 kHz spectrum seven segments occupy 3 MHz.It also provides hierarchical transmission capabilities by using different carrier modulation schemes and coding rates of the inner code on different BST-segments. Each data segment can have its own error protection scheme (coding rates of inner code, depth of the time interleaving) and type of modulation (QPSK, DQPSK, 16-QAM, or 64 QAM). Each segment can then meet different service requirements. A number of segments may be combined flexibly to provide a wideband service (e.g., High Definition TV). By transmitting OFDM segment groups with different transmission parameters, hierarchical transmission is achieved. Up to three services can be provided in one terrestrial channel and partial reception of services contained in the transmission channel can be obtained using a narrow-band receiver that has a bandwidth as low as one OFDM segment.The system was developed and tested with 6 MHz channels, but it can be scaled to any channel bandwidth with corresponding variations of the data capacity. The net bit rate for one 428.6 kHz segment in a 6 MHz channel ranges 280.85–1787.28 kbps. The data throughput for a 5.57 MHz DTV channel ranges 3.65–23.23 Mbps [3, 5].


### 2.3.SBTVD-T

Brazil has chosen ISDB-T modulation for its Digital TV format, naming it SBTVD-T (Sistema Brasileiro de Televisão Digital-Terrestre).This new standard has been developed by an association including Brazilian government, Brazilian universities and communication companies.Basically, SBTVD-T differs from ISDB-T in that it uses the MPEG-4 Part 10  (H.264) video codec instead of ISDB-T’s MPEG-2 [6].As MPEG-4 video demands greater processing power, hardware designed for digital reception in Brazil has to include chips that are usually more expensive than those used in Japanese receivers, thus making compatibility between the two standards only through substantial software modification.


## 2.1. DVB-T

The DVB-T (Digital Video Broadcasting-Terrestrial) specification refers to terrestrial broadcasting. The system has been designed to operate within the existing UHF spectrum allocated to analogue television transmissions. The system was developed for 8 MHz channels but it can be scaled to any channel bandwidth (8, 7, or 6 MHz) with corresponding scaling in the data capacity. The net bit rate available in 8 MHz channel is in the  4.98–31.67 Mbps range, depending on the choice of channel coding parameters, modulation types, and guard interval duration.The system was essentially designed to be able to adapt to all types of channels. It is capable to cope not only with Gaussian channels, but also with Ricean and Rayleigh channels. It can withstand high-level (up to 0 dB) long delay static and dynamic multipath distortion.The system is robust to interference from delayed signals, either echoes resulting from terrain or building reflections or signals from distant transmitters in a single frequency network arrangement [2, 3].The system features a number of selectable parameters that accommodate a large range of carrier-to-noise ratios and channel behaviours. It supports fixed, portable, or mobile reception, with a consequential trade-off in the usable bit rate.This range of parameters allows the broadcasters to select a mode appropriate to the application foreseen. For instance, a pretty robust mode (with a correspondingly lower data rate) is needed to ensure reliable portable reception with a simple set-top antenna. A less robust mode with a higher data rate could be used where the service planning involves frequency-interleaved channels [3, 4].Less robust modes with the highest data rates can be used for fixed reception and for digital TV broadcasting.


## 2.2.ISDB-T

ISDB (Integrated Services Digital Broadcasting) is a new type of broadcasting intended to provide audio, video, and multimedia services. The system was developed for terrestrial (ISDB-T) and satellite (ISDB-S) broadcasting.For terrestrial broadcasting, the system has been designed to have enough flexibility to deliver digital television and sound programs and offer multimedia services in which different types of digital information such as video, audio, text, and computer programs will be integrated. It also aims to provide stable reception through compact, light and inexpensive mobile receivers in addition to integrated receivers typically used in homes.The system uses a modulation referred to asBand-Segmented Transmission (BST) OFDM, which consists of a set of common basic frequency blocks called BST-Segments. Each segment has a bandwidth corresponding to 1/14th of the terrestrial television channel spacing (6, 7, or 8 MHz depending on the region). For example, in a 6 MHz channel, one segment occupies 6/14 MHz = 428.6 kHz spectrum seven segments occupy 3 MHz.It also provides hierarchical transmission capabilities by using different carrier modulation schemes and coding rates of the inner code on different BST-segments. Each data segment can have its own error protection scheme (coding rates of inner code, depth of the time interleaving) and type of modulation (QPSK, DQPSK, 16-QAM, or 64 QAM). Each segment can then meet different service requirements. A number of segments may be combined flexibly to provide a wideband service (e.g., High Definition TV). By transmitting OFDM segment groups with different transmission parameters, hierarchical transmission is achieved. Up to three services can be provided in one terrestrial channel and partial reception of services contained in the transmission channel can be obtained using a narrow-band receiver that has a bandwidth as low as one OFDM segment.The system was developed and tested with 6 MHz channels, but it can be scaled to any channel bandwidth with corresponding variations of the data capacity. The net bit rate for one 428.6 kHz segment in a 6 MHz channel ranges 280.85–1787.28 kbps. The data throughput for a 5.57 MHz DTV channel ranges 3.65–23.23 Mbps [3, 5].


## 2.3.SBTVD-T

Brazil has chosen ISDB-T modulation for its Digital TV format, naming it SBTVD-T (Sistema Brasileiro de Televisão Digital-Terrestre).This new standard has been developed by an association including Brazilian government, Brazilian universities and communication companies.Basically, SBTVD-T differs from ISDB-T in that it uses the MPEG-4 Part 10  (H.264) video codec instead of ISDB-T’s MPEG-2 [6].As MPEG-4 video demands greater processing power, hardware designed for digital reception in Brazil has to include chips that are usually more expensive than those used in Japanese receivers, thus making compatibility between the two standards only through substantial software modification.


## 3. Interactivity Standards

In DTV broadcasting, a new interesting feature is the interactivity, that is the chance to deliver multimedia applications interacting with the user and giving a consistent added value to DTV services.To implement interactivity in a correct way, several standards are available, and in this article will be given a description of the ones that are designed for the DTTB systems introduced in the previous section. Those interactivity standards involve the middleware that have been modified in the BEACON project in order to implement the interoperability system architecture.


### 3.1. MHP

The DVB-MHP (Multimedia Home Platform) stack defines a transport system, an execution environment and a set of API for the developer to provide a platform independent interface between applications from different providers and the manufacturer-specific hardware and software implementation. It enables any digital content provider to address all types of terminals ranging from low-end to high-end set-top boxes, integrated digital TV sets, or multimedia PCs.Figure1 shows a simple view of the architecture of an MHP receiver.Figure 1
MHP Architecture.Implementations of the various Java APIs included in the MHP specification need an implementation of basic DVB functionality to build upon.Implementations of the network protocols are also needed which may not be part of a basic DVB receiver implementation. On top of these is the Java virtual machine that runs applications. The receiver manufacturer will include a resident application (“Navigator”) providing basic TV functionality. This may fit above the MHP APIs and be implemented in Java or may fit alongside the MHP APIs and be implemented in some other technology.The DVB system introduced the concept of profiles as a support to the implementation of standards. Every profile makes reference to a specific application area and defines the requirements of aSet Top Box (STB) necessary for its support. Three MHP profiles presently exist.(1)
Enhanced Broadcast Profile. It is defined in the specifications MHP 1.0 (BS 201 812). This profile requires a Set Top Box with no or limited capacity of management of the return channel.(2)
Interactive TV Profile. It is defined in the specifications MHP 1.0 [7]. It allows the use of the return channel (PSTN, ADSL, GPRS, Ethernet, etc.) for the implementation of interactive applications. This profile also supports the downloading of MHP applications through the return channel (only from the version 1.1), while in the previous profiles this is possible only through the broadcasting channel.(3)
Internet Access Profile. It is defined in the specifications MHP 1.1 [7]. This profile requires a more complex Set Top Box in terms of memory and computational power and allows complete interactivity and access to Internet content.Actually, interactivity currently implemented refers to the first two profiles of the MHP specifications: the enhanced broadcasting profile and the interactive broadcast profile, which adds to the first profile the interaction with a back-end Service Centre through a bidirectional IP return channel. It allows the personalization of service content through the features introduced by the second MHP profile that guarantees the chance to customize service contents for each user through the return channel by [8](1)
supporting HTTP protocol to get different types of data (text, images, and audio clip);(2)
supporting HTTPS protocol to grant security to the exchange of reserved personal data;(3)
using a Smart Card to support the storage of user related data and allow policies of strong authentication.A full customisation should be possible with the exploitation of the MHP 1.1 specifications that will allow the download of whole applications (layout, programming logic, and contents) through the return channel with a huge saving of resources on the broadcast channel, but the first release of Set Top Boxes implementing MHP 1.1 has still to come in EU countries.


### 3.2. GEM

To allow the use of MHP in non-DVB networks, the GEM specification has been created. It defines a subset of MHP which removes the transmission-related elements of the MHP specification but retains the application API’s, thus allowing broad content compatibility across a range of  new delivery platforms developments.The following platforms are defined, based on/extending GEM:(1)
Multimedia Home Platform (MHP), the open, multiplatform middleware specification developed by the DVB project;(2)
OpenCable Application Platform (OCAP), which is an ITV middleware software layer for US cable;(3)
ARIB B.23 specification from Japan’s ARIB (Association of Radio Industries and Businesses);(4)
Advanced Common Application Platform (ACAP), the North American ATSC middleware standard for terrestrial broadcast;(5)
BD-J the Java-platform for the Blu-ray disc;(6)
Ginga-J, one of the middleware solution in the Brazilian framework.Figure2 outlines the concept of GEM [1].Figure 2
GEM Concept.As all these platforms are based on the common GEM-core, it is possible to write Java-application with interoperable operation on all these systems. So, interactive services developed following GEM specifications can be utilized in European, North-American, Japanese, and Brazilian TV networks.


### 3.3. ARIB

ARIB is the main Japanese association of industries and business operating for the development of Japanese DTV. It conducts research and development, establishes standards, provides consultation services for radio spectrum coordination, also cooperating with other foreign international organizations, and provids frequency change support services for the digital terrestrial television broadcasting in Japan. These activities are conducted in cooperation by telecommunication operators, broadcasters, radio equipment manufacturers, and related organizations [9].As regards the interactivity in Japanese DTV, ARIB has publishedARIB B23   [10]. The Standard comprises two parts, one concerning monomedia coding systems and another concerning application execution engine platforms. The standard embodies a system that is based on the MHP method of DVB specifications and GEM, with additional provision of the necessary implementations to work in the ISDB.


### 3.4.Ginga

Ginga is the middleware specification for Brazilian Digital TV System. This specification is made up by a set of standardized technologies and Brazilian innovations that make it the most advanced middleware specification and the best solution for the Brazilian requirements.The Ginga Architecture can be divided into two major modules: Common Core and Specific Service.The last one is  also divided into two main integrated subsystems, which allow the development of applications following two different programming paradigms (as shown in Figure3).Figure 3
Ginga Architecture.Depending on the required functionalities of an application project, one paradigm will be more suitable than the other one. Those subsystems are calledGinga-J (for Java applications) and Ginga-NCL (for declarative NCL applications).Ginga-J is a logical subsystem of the Ginga System that processes Xlet object content. A key component of the procedural application environment is the procedural content execution engine, composed by a Java Virtual Machine.Ginga-NCL (NCL stands forNested Context Language) is a logical subsystem of the Ginga System that processes NCL documents. A key component of Ginga-NCL is the declarative content decoding engine (NCL formatter named Maestro). Other important modules are the XHTML-based user agent, which includes a stylesheet (CSS) and ECMAScript interpreters, and the Lua engine, which is responsible for interpreting Lua scripts.In fact, beside NCL declarative language, Brazilian DTV Forum has accepted Lua language as the scripting language for the platform, and it is the scripting language used to implement procedural objects embedded in NCL documents.At this moment only Ginga-NCL has been accepted by the Brazilian Forum for Digital TV, and it is the only middleware mandatory for interactive Brazilian TV.Ginga-NCL and Ginga-J are built over the services offered by the Ginga Common-Core module, whose organization is illustrated in Figure4.Figure 4
Ginga common core module.Common content decoders serve both procedural and declarative application needs for the decoding and presentation of common content types. The Ginga Common Core is composed of common content decoders and procedures to obtain contents, transported in MPEG-2 Transport Streams or via the return channel. The Ginga Common Core will also support the conceptual display model specified for the ISDTV-T [11].The architecture and facilities of Ginga are intended to apply to broadcast systems and receivers for terrestrial broadcast. However, the same architecture and facilities may be applied to other transport systems (such as satellite, cable TV, etc.).In general, Ginga is unaware of any native applications that also may choose to share the graphics plane. These include but are not limited to closed captioning, conditional access system messages, receiver menus, and native program guides.


### 3.5.NCL-Lua

A detailed explanation of NCL declarative language and then of Lua scripting language follows.Unlike HTML or XHTML, NCL has a stricter separation between content and structure and it provides noninvasive control of presentation linking and layout. As such, NCL does not define any media itself. Instead, it defines the glue that holds media together in multimedia presentations.NCL has been specified in a modular way since version 2.0, allowing the combination of its modules in language profiles. Each profile can group a subset of NCL modules, allowing the creation of languages according to the users’ needs. Moreover, NCL modules and profiles can be combined with other language modules, allowing the incorporation of NCL features into those languages and vice-versa.The current version of Ginga-NCL is 3.0, the version selected for the development of our work.The NCL document only defines how media objects are structured and related in time and space. As a glue language, it does not restrict or prescribe the mediaobject content types. In this sense, we can have image objects, video objects, audio objects, text objects, execution objects (e.g., Xlet, Lua, etc.), and so forth as NCL media objects. Which media objects are supported depends on the media players that are embedded in the NCL formatter. In the Brazilian DTV system, one of these players is the MPEG-4 decoder/player, implemented in hardware in the DTV receptor. In this way, note that the main MPEG-4 video and audio is treated like all other media objects that can be related using NCL.Another NCL media object required in ISDTV-T is the HTML-based media object. Therefore, NCL does not substitute but embeds HTML-based documents (or objects).As with other media objects, what HTML-based language will support in an NCL formatter is an implementation choice and, therefore, will depend on which HTML browser will act as a media player embedded in the NCL formatter.Although an XHTML-based browser must be supported, the use of XHTML elements to define relationships (including XHTML links and ECMAScripts) should be dissuaded when authoring NCL documents. Structure-based authoring should be emphasized.During the exhibition of media-object contents, several events are generated. Examples of events are the presentation of marked segments of a media-object content, the selection of a marked content segment, and so forth. Events may generate actions on other media objects, like to start, pause, or stop their presentations. Hence, events must be reported by media players to the NCL formatter that, in its turn, can generate actions to be applied to these or other players. Ginga-NCL defines an adapter API [12] to standardize the interface between the Ginga-NCL formatter and each specific player. Third part players, including XHTML-based browsers, usually need an adapter module to realize their integration.Finally, for live editing, Ginga-NCL has also defined NCL stream events (DSM-CC events) in order to support live generated events in stream media, in particular the main program stream video. Again, the use of XHTML elements to define relationships (stream event elements in this case) should be dissuaded in authoring NCL documents emphasizing  structure-based authoring.Lua is the NCL Script Language, and it provides a library that offers a set of functions to support NCL’s editing commands. All functions can receive a time reference as an optional parameter that can be used to specify the exact moment when the editing command should be executed. This parameter has the same scheduling function of the time reference present in stream events.If the time-reference optional parameter is not provided in the function call, the editing command should be executed immediately. When provided, it defines the amount of time, in seconds, for how long the command must be postponed. However, this parameter can also specify the exact moment to execute the command in terms of absolute values.NCL-Lua also provides an extended library that offers a set of functions to start, stop, pause or resume an interface defined in NCL for NCL-Lua media object executions. These function results can be used as conditions, evaluated by the NCL formatter, to trigger actions on other NCL objects of the same document. Besides commanding event state transitions, a procedural NCL-Lua code can also register itself as a listener of state transitions of any NCL event.Depending on the middleware configuration, it is possible to have access in Lua to the same API provided by the Ginga-J, the Ginga procedural environment, in order to have access to some set-top box resources and Ginga facilities [13].Finally, Lua has also a very particular set of characteristics that makes it unique in a DTV domain:(1)
it has a simple procedural syntax with powerful data description constructs;(2)
it is dynamically typed;(3)
it has automatic memory management with garbage collection, making it ideal for configuration, scripting, and rapid prototyping;(4)
it has also other features that make it a good option for embedded and soft real-time systems, as is the case of DTV systems: incremental garbage collection, weak references, and coroutines;(5)
it is interpreted from bytecodes;(6)
it is an “embeddable” language: the interpreter is a pure ANSI C library;(7)
it is small, and as consequence, easy to install, easy to adapt, and portable;(8)
it is efficient (faster than Perl and Python; much faster than JavaScript).All these features made Lua very well accepted as a scripting language in the DTV domain and a key feature for the development of our system.


### 3.6. Brazilian Standardization

In this section some important arguments about the Brazilian standardization choices regarding the DTV interactive part are discussed, because those choices have an important role on the determination of the effective availability of the interactive standard that better fits system needs.At the time of writing, for the implementation of interactive implementation, four alternatives have been taken into consideration for the Brazilian Forum for Digital TV.(1)
Ginga NCL and Lua. At the moment they are the only languages accepted by the Brazilian Forum for Digital TV, and this middleware is mandatory for interactive Brazilian TV.(2)
Ginga-J based on GEM. it is still not clear because the Brazilian Forum for Digital TV has concerns about MHP via licensing;(3)
Java DTV. is a specification developed recently by Sun Microsystems for interactive television, but at the moment it is only a specification, there is no set top box with this implementation (maybe in 1 or 2 years there will be set top boxes in the market but it is not approved for the Brazilian Forum and actually it remains only a specification);(4)
Web browser based on webkit and javascript. This is not a standard solution and it is not clear about this implementation due to hardware requirements.It is clear that the only option for the BEACON project is Ginga NCL and Lua, because it has been accepted for the Brazilian Forum for Digital TV, and it is the only implementation available in real set top boxes from Brazil.In fact, at the beginning of the project, it seemed that the set top boxes market was going in the Ginga-J direction (implementing Ginga-J as an exact map of GEM permits all interactive application GEM compliant to be interoperable with ISDTV and other standards, as noted before).Technically it seems to be the optimum, but there are some legal problems for implementing GEM into Brazilian set top boxes: in Europe every MHP compliant STB producer must pay $1,75 per device for royalty on the MHP standard. GEM is a derived standard of MHP, but Brazilian interactive STBs producers do not want to pay this royalty and decided to leave the GEM implementation of Ginga-J.Moreover, only Ginga-NCL implementation of Ginga Standard is mandatory at this moment, so the BEACON consortium decides to design the Ginga-NCL version of the player tool (developed in MHP for the European side). The Ginga-NCL choice guarantees the Consortium a real implementation of this standard.


## 3.1. MHP

The DVB-MHP (Multimedia Home Platform) stack defines a transport system, an execution environment and a set of API for the developer to provide a platform independent interface between applications from different providers and the manufacturer-specific hardware and software implementation. It enables any digital content provider to address all types of terminals ranging from low-end to high-end set-top boxes, integrated digital TV sets, or multimedia PCs.Figure1 shows a simple view of the architecture of an MHP receiver.Figure 1
MHP Architecture.Implementations of the various Java APIs included in the MHP specification need an implementation of basic DVB functionality to build upon.Implementations of the network protocols are also needed which may not be part of a basic DVB receiver implementation. On top of these is the Java virtual machine that runs applications. The receiver manufacturer will include a resident application (“Navigator”) providing basic TV functionality. This may fit above the MHP APIs and be implemented in Java or may fit alongside the MHP APIs and be implemented in some other technology.The DVB system introduced the concept of profiles as a support to the implementation of standards. Every profile makes reference to a specific application area and defines the requirements of aSet Top Box (STB) necessary for its support. Three MHP profiles presently exist.(1)
Enhanced Broadcast Profile. It is defined in the specifications MHP 1.0 (BS 201 812). This profile requires a Set Top Box with no or limited capacity of management of the return channel.(2)
Interactive TV Profile. It is defined in the specifications MHP 1.0 [7]. It allows the use of the return channel (PSTN, ADSL, GPRS, Ethernet, etc.) for the implementation of interactive applications. This profile also supports the downloading of MHP applications through the return channel (only from the version 1.1), while in the previous profiles this is possible only through the broadcasting channel.(3)
Internet Access Profile. It is defined in the specifications MHP 1.1 [7]. This profile requires a more complex Set Top Box in terms of memory and computational power and allows complete interactivity and access to Internet content.Actually, interactivity currently implemented refers to the first two profiles of the MHP specifications: the enhanced broadcasting profile and the interactive broadcast profile, which adds to the first profile the interaction with a back-end Service Centre through a bidirectional IP return channel. It allows the personalization of service content through the features introduced by the second MHP profile that guarantees the chance to customize service contents for each user through the return channel by [8](1)
supporting HTTP protocol to get different types of data (text, images, and audio clip);(2)
supporting HTTPS protocol to grant security to the exchange of reserved personal data;(3)
using a Smart Card to support the storage of user related data and allow policies of strong authentication.A full customisation should be possible with the exploitation of the MHP 1.1 specifications that will allow the download of whole applications (layout, programming logic, and contents) through the return channel with a huge saving of resources on the broadcast channel, but the first release of Set Top Boxes implementing MHP 1.1 has still to come in EU countries.


## 3.2. GEM

To allow the use of MHP in non-DVB networks, the GEM specification has been created. It defines a subset of MHP which removes the transmission-related elements of the MHP specification but retains the application API’s, thus allowing broad content compatibility across a range of  new delivery platforms developments.The following platforms are defined, based on/extending GEM:(1)
Multimedia Home Platform (MHP), the open, multiplatform middleware specification developed by the DVB project;(2)
OpenCable Application Platform (OCAP), which is an ITV middleware software layer for US cable;(3)
ARIB B.23 specification from Japan’s ARIB (Association of Radio Industries and Businesses);(4)
Advanced Common Application Platform (ACAP), the North American ATSC middleware standard for terrestrial broadcast;(5)
BD-J the Java-platform for the Blu-ray disc;(6)
Ginga-J, one of the middleware solution in the Brazilian framework.Figure2 outlines the concept of GEM [1].Figure 2
GEM Concept.As all these platforms are based on the common GEM-core, it is possible to write Java-application with interoperable operation on all these systems. So, interactive services developed following GEM specifications can be utilized in European, North-American, Japanese, and Brazilian TV networks.


## 3.3. ARIB

ARIB is the main Japanese association of industries and business operating for the development of Japanese DTV. It conducts research and development, establishes standards, provides consultation services for radio spectrum coordination, also cooperating with other foreign international organizations, and provids frequency change support services for the digital terrestrial television broadcasting in Japan. These activities are conducted in cooperation by telecommunication operators, broadcasters, radio equipment manufacturers, and related organizations [9].As regards the interactivity in Japanese DTV, ARIB has publishedARIB B23   [10]. The Standard comprises two parts, one concerning monomedia coding systems and another concerning application execution engine platforms. The standard embodies a system that is based on the MHP method of DVB specifications and GEM, with additional provision of the necessary implementations to work in the ISDB.


## 3.4.Ginga

Ginga is the middleware specification for Brazilian Digital TV System. This specification is made up by a set of standardized technologies and Brazilian innovations that make it the most advanced middleware specification and the best solution for the Brazilian requirements.The Ginga Architecture can be divided into two major modules: Common Core and Specific Service.The last one is  also divided into two main integrated subsystems, which allow the development of applications following two different programming paradigms (as shown in Figure3).Figure 3
Ginga Architecture.Depending on the required functionalities of an application project, one paradigm will be more suitable than the other one. Those subsystems are calledGinga-J (for Java applications) and Ginga-NCL (for declarative NCL applications).Ginga-J is a logical subsystem of the Ginga System that processes Xlet object content. A key component of the procedural application environment is the procedural content execution engine, composed by a Java Virtual Machine.Ginga-NCL (NCL stands forNested Context Language) is a logical subsystem of the Ginga System that processes NCL documents. A key component of Ginga-NCL is the declarative content decoding engine (NCL formatter named Maestro). Other important modules are the XHTML-based user agent, which includes a stylesheet (CSS) and ECMAScript interpreters, and the Lua engine, which is responsible for interpreting Lua scripts.In fact, beside NCL declarative language, Brazilian DTV Forum has accepted Lua language as the scripting language for the platform, and it is the scripting language used to implement procedural objects embedded in NCL documents.At this moment only Ginga-NCL has been accepted by the Brazilian Forum for Digital TV, and it is the only middleware mandatory for interactive Brazilian TV.Ginga-NCL and Ginga-J are built over the services offered by the Ginga Common-Core module, whose organization is illustrated in Figure4.Figure 4
Ginga common core module.Common content decoders serve both procedural and declarative application needs for the decoding and presentation of common content types. The Ginga Common Core is composed of common content decoders and procedures to obtain contents, transported in MPEG-2 Transport Streams or via the return channel. The Ginga Common Core will also support the conceptual display model specified for the ISDTV-T [11].The architecture and facilities of Ginga are intended to apply to broadcast systems and receivers for terrestrial broadcast. However, the same architecture and facilities may be applied to other transport systems (such as satellite, cable TV, etc.).In general, Ginga is unaware of any native applications that also may choose to share the graphics plane. These include but are not limited to closed captioning, conditional access system messages, receiver menus, and native program guides.


## 3.5.NCL-Lua

A detailed explanation of NCL declarative language and then of Lua scripting language follows.Unlike HTML or XHTML, NCL has a stricter separation between content and structure and it provides noninvasive control of presentation linking and layout. As such, NCL does not define any media itself. Instead, it defines the glue that holds media together in multimedia presentations.NCL has been specified in a modular way since version 2.0, allowing the combination of its modules in language profiles. Each profile can group a subset of NCL modules, allowing the creation of languages according to the users’ needs. Moreover, NCL modules and profiles can be combined with other language modules, allowing the incorporation of NCL features into those languages and vice-versa.The current version of Ginga-NCL is 3.0, the version selected for the development of our work.The NCL document only defines how media objects are structured and related in time and space. As a glue language, it does not restrict or prescribe the mediaobject content types. In this sense, we can have image objects, video objects, audio objects, text objects, execution objects (e.g., Xlet, Lua, etc.), and so forth as NCL media objects. Which media objects are supported depends on the media players that are embedded in the NCL formatter. In the Brazilian DTV system, one of these players is the MPEG-4 decoder/player, implemented in hardware in the DTV receptor. In this way, note that the main MPEG-4 video and audio is treated like all other media objects that can be related using NCL.Another NCL media object required in ISDTV-T is the HTML-based media object. Therefore, NCL does not substitute but embeds HTML-based documents (or objects).As with other media objects, what HTML-based language will support in an NCL formatter is an implementation choice and, therefore, will depend on which HTML browser will act as a media player embedded in the NCL formatter.Although an XHTML-based browser must be supported, the use of XHTML elements to define relationships (including XHTML links and ECMAScripts) should be dissuaded when authoring NCL documents. Structure-based authoring should be emphasized.During the exhibition of media-object contents, several events are generated. Examples of events are the presentation of marked segments of a media-object content, the selection of a marked content segment, and so forth. Events may generate actions on other media objects, like to start, pause, or stop their presentations. Hence, events must be reported by media players to the NCL formatter that, in its turn, can generate actions to be applied to these or other players. Ginga-NCL defines an adapter API [12] to standardize the interface between the Ginga-NCL formatter and each specific player. Third part players, including XHTML-based browsers, usually need an adapter module to realize their integration.Finally, for live editing, Ginga-NCL has also defined NCL stream events (DSM-CC events) in order to support live generated events in stream media, in particular the main program stream video. Again, the use of XHTML elements to define relationships (stream event elements in this case) should be dissuaded in authoring NCL documents emphasizing  structure-based authoring.Lua is the NCL Script Language, and it provides a library that offers a set of functions to support NCL’s editing commands. All functions can receive a time reference as an optional parameter that can be used to specify the exact moment when the editing command should be executed. This parameter has the same scheduling function of the time reference present in stream events.If the time-reference optional parameter is not provided in the function call, the editing command should be executed immediately. When provided, it defines the amount of time, in seconds, for how long the command must be postponed. However, this parameter can also specify the exact moment to execute the command in terms of absolute values.NCL-Lua also provides an extended library that offers a set of functions to start, stop, pause or resume an interface defined in NCL for NCL-Lua media object executions. These function results can be used as conditions, evaluated by the NCL formatter, to trigger actions on other NCL objects of the same document. Besides commanding event state transitions, a procedural NCL-Lua code can also register itself as a listener of state transitions of any NCL event.Depending on the middleware configuration, it is possible to have access in Lua to the same API provided by the Ginga-J, the Ginga procedural environment, in order to have access to some set-top box resources and Ginga facilities [13].Finally, Lua has also a very particular set of characteristics that makes it unique in a DTV domain:(1)
it has a simple procedural syntax with powerful data description constructs;(2)
it is dynamically typed;(3)
it has automatic memory management with garbage collection, making it ideal for configuration, scripting, and rapid prototyping;(4)
it has also other features that make it a good option for embedded and soft real-time systems, as is the case of DTV systems: incremental garbage collection, weak references, and coroutines;(5)
it is interpreted from bytecodes;(6)
it is an “embeddable” language: the interpreter is a pure ANSI C library;(7)
it is small, and as consequence, easy to install, easy to adapt, and portable;(8)
it is efficient (faster than Perl and Python; much faster than JavaScript).All these features made Lua very well accepted as a scripting language in the DTV domain and a key feature for the development of our system.


## 3.6. Brazilian Standardization

In this section some important arguments about the Brazilian standardization choices regarding the DTV interactive part are discussed, because those choices have an important role on the determination of the effective availability of the interactive standard that better fits system needs.At the time of writing, for the implementation of interactive implementation, four alternatives have been taken into consideration for the Brazilian Forum for Digital TV.(1)
Ginga NCL and Lua. At the moment they are the only languages accepted by the Brazilian Forum for Digital TV, and this middleware is mandatory for interactive Brazilian TV.(2)
Ginga-J based on GEM. it is still not clear because the Brazilian Forum for Digital TV has concerns about MHP via licensing;(3)
Java DTV. is a specification developed recently by Sun Microsystems for interactive television, but at the moment it is only a specification, there is no set top box with this implementation (maybe in 1 or 2 years there will be set top boxes in the market but it is not approved for the Brazilian Forum and actually it remains only a specification);(4)
Web browser based on webkit and javascript. This is not a standard solution and it is not clear about this implementation due to hardware requirements.It is clear that the only option for the BEACON project is Ginga NCL and Lua, because it has been accepted for the Brazilian Forum for Digital TV, and it is the only implementation available in real set top boxes from Brazil.In fact, at the beginning of the project, it seemed that the set top boxes market was going in the Ginga-J direction (implementing Ginga-J as an exact map of GEM permits all interactive application GEM compliant to be interoperable with ISDTV and other standards, as noted before).Technically it seems to be the optimum, but there are some legal problems for implementing GEM into Brazilian set top boxes: in Europe every MHP compliant STB producer must pay $1,75 per device for royalty on the MHP standard. GEM is a derived standard of MHP, but Brazilian interactive STBs producers do not want to pay this royalty and decided to leave the GEM implementation of Ginga-J.Moreover, only Ginga-NCL implementation of Ginga Standard is mandatory at this moment, so the BEACON consortium decides to design the Ginga-NCL version of the player tool (developed in MHP for the European side). The Ginga-NCL choice guarantees the Consortium a real implementation of this standard.


## 4. Beacon Project

BEACON (Brazilian-European Consortium for DTT Services) is a specific targeted research project on Digital Terrestrial Television.It will develop innovative t-learning pilot services related to social inclusion in the State of Sao Paulo (Brazil) on the basis of pioneering research on interoperability between the European (DVB) and the Brazilian (SBTVD) Digital Terrestrial Television standards and the definition of a pedagogically sound methodology for distance learning through digital television. Ultimately the project will result in the establishment of a Brazilian-European Consortium that will manage the exploitation of the assets and the services implemented by the project.As regards the technological state of the art inside of which the BEACON project is supplying another step of innovation, it is important to understand that if several other systems are already developed to deliver t-learning services (with more or less interactivity) around the world, our system  is the first one facing the challenge of t-learning interoperability between the well known DVB-MHP European stack and the Brazilian one.In fact, in Brazil SBTVD-T is now defined and implemented, but regarding the interactivity part there are some important issues that, at the time of writing, still have to be solved and/or defined (as described in Section3.6).So, the innovation opportunity given by this work includes the following:(1)
to analyze the technologies available to find one that fits the needs of Brazilian platform integration;(2)
to develop an application running on Brazilian STBs that can be easily interfaced with the t-learning system;(3)
to integrate the European t-learning application and services involved in the BEACON project with the one that will be developed in Brazil;(4)
to create an important starting point for the development of several interactive applications delivered by SBTVD-T defining specific guidelines.In this way, the project is addressed to build a concrete interaction between the European and Brazilian DTT interactive applications.


### 4.1. Objectives

BEACON aims to contribute for going a step ahead of the state of the art of Digital Terrestrial Television technology and services pursuing the following main objectives:(1)
to perform research on innovative and interoperable (between the European DVB and the Brazilian SBTVD standards) DTT applications and services addressed to the t-learning domain notably customized for the Brazilian specific needs related with social inclusion issues;(2)
to provide feedback data analysis of services pilot run to Brazilian Public Administrations in order to contribute to the relevant policy making processes regarding the DTT standard adopted and to its implementation;(3)
to establish a Brazilian-European Consortium which will manage the exploitation of the assets and the services implemented by the project activities.In order to achieve the above stated objectives, BEACON will jointly consider technological solutions, pedagogical issues and sustainable models. The project’s activities output the following:(1)
research on innovative DTT-based e-learning methodology and on the relevant technologies performed;(2)
t-learning definition availability;(3)
innovative interoperable (DVB, MHP-SBTVD, Ginga) t-learning DTT application development;From the technological point of view, BEACON envisages to achieve the previously mentioned objectives by research activities that will lead to:(1)
develop a micro-XML browser, aiming to foster convergence towards IP service infrastructures, to enable innovative t-learning services fruition and to enhance their user-friendliness (usability);(2)
develop an enhanced interoperable service framework able to broadcast applications on different DTV platforms (DVB-SBTVD) and to set up a Service Center in charge of services delivery;(3)
identify and promote standard solutions for the development of interoperable t-learning applications—that is, methodological and technological guidelines to design, implement and test t-learning applications on a DTT platform;(4)
identify and integrate authoring tools to grant full compliancy to both t-learning and DTV standards.Furthermore, BEACON will deal with pedagogical issues related to t-learning by mean of research activities aimed to:(1)
get a better understanding on how people learn in their home environments and how they may relate to learning through TV compared to other means, that is, when people have access and can take advantage of learning opportunities in their home;(2)
investigate sociological dynamics that operate in the home, how these relate to television and what impact this may make on creating learning opportunities in the home, that is, social barriers to preventing access to learning opportunities in the home;(3)
evaluate how informal learning, in the home, could draw people into formalised learning;(4)
define what aspects of interactivity are needed for home learning context and how it can motivate learners;(5)
investigate to what extent the current e-learning didactic strategies are heritable and achievable by mean of t-learning applications and services taking into account the innovative technological results of the project;(6)
deliver interoperable t-learning services aimed at fostering social inclusion in Brazil.Those objectives are achieved addressing a particular context. In fact, in Brazil the academic reality shows that public universities are usually better than private ones. For a long time, governments were the only entities willing to invest the massive amounts of money required to create and maintain good universities, thus the majority of Brazilian scientific researchers are found in the public universities (very little research is funded by private colleges).Also, public universities have no fees, differently from privates universities.Because the number of candidates is usually superior to the number of vacancies offered, vestibular is adopted by practically all public universities. It is a test open to all students who have completed high school and the students with the best scores qualify for enrollment.Obviously, a good preparation and a good training program can have a key role in the enrollment of students and in the improvement of the quality of their expectations (and then lives) given by studying in a good university.In this scenario, the specific t-learning services delivered with the BEACON platform are focused on how to cover the social-gap in this country fostering a profitable training to access the university to all those peoples (students) that can not be reached by e-learning courses or other training opportunities.Such a service has been chosen to deal with the inclusion matter described above, but every kind of interactive services (t-learning courses and so on) can be delivered through this platform between Europe and Brazil.


### 4.2. Methodologies

In this paragraph the methodologies used to realize the system will be discussed.As for the learning scenario to be implemented in the BEACON test pilot, it is the result of an iterative design process based on theUser Centred Design (UCD) approach. UCD approach will be used to define user needs and requirements and to analyse user activities. This methodology allows to design and to develop an artifact that effectively satisfy the user and supports him during the activity.The UCD proposes an iterative cycle of some steps of the process that are repeated many times in order to refine the requirements before the implementation.The methodology applied to the BEACON service model design is the result of an iterative process set of the following steps:(1)
User requirements analysis: user needs will be analyzed, along with service requirements (features, privacy, usability,…) coming from the e-Health Service Provider;(2)
Feasibility studies, aiming to identify the most valuable state of the art technology to develop the service, for achieving the project goals;(3)
Definition of service features and specifications, aiming to identify the system architecture and related hardware/software modules, in order to guarantee service expected functionalities;(4)
DTT application testing in an emulated environment: the DTT application is implemented through software authoring tools in emulated environment, which would be properly tested and debugged before deployment and broadcasting;(5)
Application deployment and testing with final users in a broadcasting environment: the DTT application is uploaded and managed by the Object Carousel Generator, multiplexed with audio/video contents, COFDM modulated and broadcasted to final users. The application is downloaded on the Set Top Box and users are involved in an iterative process of evaluation-redesign-testing (phases 3, 4 and 5) on the basis of “User Centred Design” approach.


## 4.1. Objectives

BEACON aims to contribute for going a step ahead of the state of the art of Digital Terrestrial Television technology and services pursuing the following main objectives:(1)
to perform research on innovative and interoperable (between the European DVB and the Brazilian SBTVD standards) DTT applications and services addressed to the t-learning domain notably customized for the Brazilian specific needs related with social inclusion issues;(2)
to provide feedback data analysis of services pilot run to Brazilian Public Administrations in order to contribute to the relevant policy making processes regarding the DTT standard adopted and to its implementation;(3)
to establish a Brazilian-European Consortium which will manage the exploitation of the assets and the services implemented by the project activities.In order to achieve the above stated objectives, BEACON will jointly consider technological solutions, pedagogical issues and sustainable models. The project’s activities output the following:(1)
research on innovative DTT-based e-learning methodology and on the relevant technologies performed;(2)
t-learning definition availability;(3)
innovative interoperable (DVB, MHP-SBTVD, Ginga) t-learning DTT application development;From the technological point of view, BEACON envisages to achieve the previously mentioned objectives by research activities that will lead to:(1)
develop a micro-XML browser, aiming to foster convergence towards IP service infrastructures, to enable innovative t-learning services fruition and to enhance their user-friendliness (usability);(2)
develop an enhanced interoperable service framework able to broadcast applications on different DTV platforms (DVB-SBTVD) and to set up a Service Center in charge of services delivery;(3)
identify and promote standard solutions for the development of interoperable t-learning applications—that is, methodological and technological guidelines to design, implement and test t-learning applications on a DTT platform;(4)
identify and integrate authoring tools to grant full compliancy to both t-learning and DTV standards.Furthermore, BEACON will deal with pedagogical issues related to t-learning by mean of research activities aimed to:(1)
get a better understanding on how people learn in their home environments and how they may relate to learning through TV compared to other means, that is, when people have access and can take advantage of learning opportunities in their home;(2)
investigate sociological dynamics that operate in the home, how these relate to television and what impact this may make on creating learning opportunities in the home, that is, social barriers to preventing access to learning opportunities in the home;(3)
evaluate how informal learning, in the home, could draw people into formalised learning;(4)
define what aspects of interactivity are needed for home learning context and how it can motivate learners;(5)
investigate to what extent the current e-learning didactic strategies are heritable and achievable by mean of t-learning applications and services taking into account the innovative technological results of the project;(6)
deliver interoperable t-learning services aimed at fostering social inclusion in Brazil.Those objectives are achieved addressing a particular context. In fact, in Brazil the academic reality shows that public universities are usually better than private ones. For a long time, governments were the only entities willing to invest the massive amounts of money required to create and maintain good universities, thus the majority of Brazilian scientific researchers are found in the public universities (very little research is funded by private colleges).Also, public universities have no fees, differently from privates universities.Because the number of candidates is usually superior to the number of vacancies offered, vestibular is adopted by practically all public universities. It is a test open to all students who have completed high school and the students with the best scores qualify for enrollment.Obviously, a good preparation and a good training program can have a key role in the enrollment of students and in the improvement of the quality of their expectations (and then lives) given by studying in a good university.In this scenario, the specific t-learning services delivered with the BEACON platform are focused on how to cover the social-gap in this country fostering a profitable training to access the university to all those peoples (students) that can not be reached by e-learning courses or other training opportunities.Such a service has been chosen to deal with the inclusion matter described above, but every kind of interactive services (t-learning courses and so on) can be delivered through this platform between Europe and Brazil.


## 4.2. Methodologies

In this paragraph the methodologies used to realize the system will be discussed.As for the learning scenario to be implemented in the BEACON test pilot, it is the result of an iterative design process based on theUser Centred Design (UCD) approach. UCD approach will be used to define user needs and requirements and to analyse user activities. This methodology allows to design and to develop an artifact that effectively satisfy the user and supports him during the activity.The UCD proposes an iterative cycle of some steps of the process that are repeated many times in order to refine the requirements before the implementation.The methodology applied to the BEACON service model design is the result of an iterative process set of the following steps:(1)
User requirements analysis: user needs will be analyzed, along with service requirements (features, privacy, usability,…) coming from the e-Health Service Provider;(2)
Feasibility studies, aiming to identify the most valuable state of the art technology to develop the service, for achieving the project goals;(3)
Definition of service features and specifications, aiming to identify the system architecture and related hardware/software modules, in order to guarantee service expected functionalities;(4)
DTT application testing in an emulated environment: the DTT application is implemented through software authoring tools in emulated environment, which would be properly tested and debugged before deployment and broadcasting;(5)
Application deployment and testing with final users in a broadcasting environment: the DTT application is uploaded and managed by the Object Carousel Generator, multiplexed with audio/video contents, COFDM modulated and broadcasted to final users. The application is downloaded on the Set Top Box and users are involved in an iterative process of evaluation-redesign-testing (phases 3, 4 and 5) on the basis of “User Centred Design” approach.


## 5. DTT System Design

In this section the system architecture is described, with a deeper analysis of the key elements and their roles in the broadcast and presentation phases.Then, the modification needed to the DVB-MHP-compliant system to become interoperable with SBTVD-T and Ginga NCL-Lua middleware are introduced, describing the involved technologies.


### 5.1. Architecture

The system architecture refers to the consolidated interactive DTV framework and comprises the following elements, as represented in Figure5:Figure 5
Interactive DTV Framework.(1)
Service and Content providers, providing content to be broadcasted on the communication channel;(2)
Broadcaster, in charge of multiplexing, modulating and broadcasting audio, video and applications over the air;(3)
Users, getting the DTT application (Java Xlet) over the air and downloading it on the STB through the interactive remote control;(4)
Service Centre, managing connectivity and user interaction through Internet protocols.The BEACON proposed architecture, as described in the following sections, will not restrict the inter-working with other service providers and network operators.Also, the adoption of a new framework, different from the European DVB-MHP platform formerly planned to be used, introduces the needs of facing the interoperability of different solutions as a key objective of the project.As seen before, in a technological perspective the decision of the Brazilian Government to establish the SBTVD-T standard leads to the adoption of the following subsystems:(1)
ISDB-T as broadcasting standard. ISDB-T is maintained by the Japanese organization ARIB and is based on MPEG-2 video and audio coding as well as the transport stream described by the MPEG-2 System standard. ATSC and DVB also adopted the same standard for their transport system. DVB and ISDB also provide for other video compression methods to be used, including JPEG and MPEG-4, although JPEG is only a required part of the MPEG standard. As for the modulation, ISDB-T supports COFDM with QPSK/QAM in the VHF and/or UHF band.(2)
H.264 (MPEG-4 Part 10) as the video and audio coding standard for supporting HDTV (High definition TV) 1080i video for fixed TV sets and LDTV (Low definition TV)  for mobile terminals.(3)
Ginga as the middleware standard, based on an execution engine (Ginga-J) integrated with a presentation engine (Ginga-NCL).As for the broadcasting, the interactive services that have been developed with this technology are only text (flat XML files) and resources (images, audios,…). During the emission, with the set of interactive services, is transmitted the tmPlayer product, a micro browser which is located in the Set Top Box and is able to analyse and parse XML information for converting to MHP code.Due to the Brazilian choice of SBTVD-T, the whole platform will be designed on the basis of a new architecture model.In order to realize this solution some necessary adaptations have been identified: Audio/Video encoder: changed to MPEG4-H.264; a data channel server for the Ginga middleware; a multiplexer equipment ISDB-T compliant; a modulator ISDB-T compliant; Set Top Boxes compliant with ISDB-T standard and Brazilian Middleware software and user interfaces (see Figure6 for European and Brazilian implementations).Figure 6
Interactive DTV Implementations in the Europe and Brazil.The hardware/software modules used in the test bed platform are(1)
anauthoring tool, with tmManager and tmPlayer (this two elements will be explained in the following paragraphs);(2)
anobject carousel generator and content multiplexing using a playout system  (tmCarousel, suitable for both DVB and ISDB);(3)
aDVB-T modulator and an ISDB-T modulator;(4)
anMHP compliant STB and Ginga compliant STB;(5)
a connection to PSTN as a return channel for interactive applications.


### 5.2. T-Learning Service

As regards t-learning, it is a subset of e-learning but the relevant access through a home-based TV could hugely enhance the learning opportunities in a way that Internet-based e-learning cannot currently do.For BEACON, a t-learning service is developed using aLearning Management System (LMS).This is the system that will be used in the project and will be correctly adapted to work on the system upgraded technology for interoperability on MHP and Ginga (NCL-Lua) standards.An LMS is a web application for managing computer-mediated distance learning (also known ase-learning) via Internet.An evolution of offlineComputer-Based Training (CBT) is called Web Based Training (WBT), delivered by internet. Those courses need a more structured way of delivering e-learning for a more detailed tracking in real time of the user interactions. This led to the creation of LMS software.In the DTT interactive domain, a t-learning session requires the following functionalities:(1)
authentication, to start the user session on the server;(2)
authorization, to receive a list of resources available to the user;(3)
delivery, to receive the course’s content;(4)
tracking, to track the duration and the results of the user session;(5)
communication, to exchange short mail messages with the tutor or the teachers.Apart from the delivery, that can take place using the broadcasted channel (i.e., the course contents can be included in the carousel), all the other functionalities require a connection to a service centre using the return channel.The service centre role can be played by an LMS customized with APIs created to exchange data with the t-learning application. Then can take place the authoring process that  can be streamlined according to the structure and layout of the courses, so that an automatic conversion of the content towards the format required for the DTT application could take place.An authoring tool consists of(1)
atext editor with an automatic check of the maximum number of characters allowed per page;(2)
animage selector to choose the illustration for the page and check its format and dimensions;(3)
aproperty selector to specify the page type: (i.e., tutorial, test, glossary, etc.);(4)
anautomatic ID generator for each page or entry;(5)
afunction to link an active word to an ID.The output will be an XML file and a folder of images. This output can be reopened with the authoring tool for further editing, copied to aSCORM WBT [14] engine to test it in a web browser environment, or finally passed to the transformation engine to be converted to the specific XML format required by the DTT application.In Figure7 there is a screenshot from the t-learning service developed in the BEACON project.Figure 7
t-learning service implemented.


### 5.3. System Technologies

In this section, an analysis of the existing technologies and upgrades needed to match the specifications given by the new libraries introduced (MHP and Ginga NCL-Lua) is shown, focusing on the architecture that will be the base for the provisioning of t-learning courses.A system calledtmBroadcast will be used. It is developed by tmira solutions, a Spanish partner of the BEACON project [15].tmBroadcast is an integral system for management and broadcasting ofElectronic Program Guides (EPG) and interactive MHP applications in DVB networks.  It is developed according to DVB and World Wide Web Consortium standards [16–18].The main features of the system are the following:(1)
user management: define users, assigning roles and services per user;(2)
broadcast configuration: all the options for configuring network parameters and modulation, maintenance services, generation of DVB/SI tables, bitrates configuration and selection of several outputs (ASI, RTP, UDP, modulator);(3)
EPG: the system has a complete tool fully integrated for management and emission of the Electronic Programming Guide and this part has all the functionality of the product tmEPG;(4)
maintenance of applications: management of interactive applications like creation, modifications, updates, editing contents, configuration of the return channel;(5)
scheduling: scheduling of applications at any time and for each service (Firing stream events);(6)
system configuration: Setting the parameters of the operating system (time, network);(7)
system backup: the system has the ability to perform backups with the configuration of the system, which may also include applications, EPG and log files;(8)
automatic updates tasks: includes the possibility of defining tasks for updating application contents in an automated manner according to a defined schedule.tmBroadcast is composed of three subsystems, as shown in Figure8Figure 8
tmBroadcast and its subsystems(1)
tmCarousel is a carousel playout of interactive TV applications and DVB signalling.  It works in DVB for cable, terrestrial and satellite networks.(2)
tmManager is a web platform that provides a web user interface and a set of tools to extract and transform contents in an automatic way, allowing to adapt any website or format for digital TV.(3)
tmPlayer is an application broadcasted that runs on STB and allows the viewer to browse the contents of an application. The browser is based in a custom XML language independent of the platform.These three subsystems are the core of the project implementation and need a more detailed explanation to point out the key features of each component, in order to define the upgrades needed to integrate the t-learning services in Europe and Brazil.


#### 5.3.1. tmCarousel

tmCarousel is a client server system that includes the following components:(1)
Configuration Manager System, in charge of  receiving, processing and distributing system configuration to other system modules. It assures that configuration is always consistent. This module includes a timer that allows the insertion and removal of applications according to the broadcast programming.(2)
DVB Service Information (PSI/SI) generator. It generates DVB tables according to  specific configurations. Tables generated are: PAT, PMT, NIT, SDT, DTT, TOT, AIT, EIT P/F, EIT S [16].(3)
Data encoder, responsible for encoding the interactive applications according to the standard identified for this purpose (DSM-CC) [19] and sending them to the multiplexer to be inserted  into the output signal.(4)
Software Multiplexer, responsible for generating the output signal with DVB tables and applications. The output is transmitted through DVB-ASI, UDP or RTP.tmCarousel works for DVB in cable, terrestrial and satellite (NIT configuration), and its development is based on the following standards:(1)
MPEG-2: TS construction (ISO/IEC DIS 13818-1), DSM-CC: (ISO/IEC IS 13818-6) [17];(2)
DVB Service Information (ETSI EN 300 468, ETSI ETR 211, ETSI ETR 162) [20];(3)
Data broadcast (ETSI EN 301 192, TR 101 202), MHP (ETSI TS 101 812 ver 1.3.1 (MHP 1.0.3), ETSI TS 101 812 ver. 1.2.1 (MHP 1.0.2), ETSI TS 102 812 ver. 1.2.1 (MHP 1.1.X), DVB BlueBook A068r3 (MHP 1.1.3), A107: DVB MHP Specification 1.2 (MHP 1.2)) [17, 20].The system is highly reliable and robust. Several ASI or UDP Unicast/Multicast outputs can be set up.


#### 5.3.2. tmManager

tmManager is the web platform for the secure control and management of tmBroadcast. It includes the definition of users and roles for the system. It also incorporates the functionality associated with the maintenance, scheduling and broadcasting of MHP applications, management and emission of EPG service and management of automatic updating tasks.tmManager has the functionality associated with the multiplex operator that allows a complete network configuration, including services, components, EPG, interactive applications, bitrate, output type (DVB-ASI or IP), operating system time, backups, network interfaces, and so forth.tmManager interface is multilingual, and it is currently available in English and Spanish, but can be easily translated to any other language like Portuguese.tmManager is based on the following standards:(1)
DVB: Service Information (ETSI EN 300 468) [20];(2)
World Wide Web Consortium: XML, XSL, XPL, XSD, XPATH, XQUERY, XFORMS, XHTML, CSS [18].One of the main advantages of tmManager is the ability to extract information from external data sources (web, database, content managers, RSS, Web services, etc.), and transform it into tmPlayer XML  format to represent it in an interactive MHP STB.tmManager has a core set of libraries to extract and transform contents to a desired format in an automatic way. This functionality is based on standard languages defined by World Wide Web Consortium [18]:(1)
XML (eXtensible Markup Language): for definition of contents;(2)
XSLT (XML Stylesheet Transformations): data transformation between formats  HTML, CSV, XLS, XML, PDF, XML;(3)
XPL (XML Processing Language): XML processing language;(4)
XPath (XML Path Language): language to access data into an XML (nodes and attributes);(5)
XQuery (XML Query Language): XML language to query databases;(6)
XForms: XML language to define web forms and interfaces.tmManager is able to transform any content in almost any format. In the system architecture developed for the BEACON project, tmManager will be in charge of transforming the course contents defined in SCORM language in tmPlayer XML for DVB and tmPlayer NCL for SBTVD.


#### 5.3.3. tmPlayer

Is the technology that enables adoption of a Web, Database, CMS, and so forth, to bring their content directly to the television. Therefore all services available on Internet such as sending e-mail, online banking, games, information, and so forth, can be automatically reused for interactive TV.tmPlayer is an XML-based micro-browser that is broadcasted permanently and is able to represent any type of interactive service starting from just a XML files. tmPlayer allows the definition, representation and navigation into a wide range of interactive services through XML files. The language of tmPlayer has been used in the MHP platform, but it can be easily adapted to other platforms such as GEM, IPTV, OpenTV, Ginga, and so forth.Among its functionalities tmPlayer includes sending email, plugins, return channel access, use of smartcards. It also provides a development environment that enables the implementation of MHP interactive services, with no need for any skill in Java programming, or MHP itself. It only requires some expertise in XML technologies, much more widespread in the Internet community.


### 5.4. System Upgrades

The tmBroadcast system had been originally designed for DVB broadcasting in cable, terrestrial and satellite networks, but all technology involved in this system has been developed basing on standards and in modular components in order to be flexible and adaptable. As a result,  it can be expanded to adopt any other standards of digital TV.In the architecture developed for the BEACON purposes,  tmBroadcast must be upgraded to be fully compatible with the Brazilian standard SBTVD. This upgrade is planned for each of the tmBroadcast components and it is described below.First of all we have defined the sequence of processes to bring the course contents to the students through interactive Digital TV with tmBroadcast. In Figures9 and 10 the steps of the whole process are shown, and steps that must be upgraded for SBTVD have been highlighted in orange colour. The other steps are the same for DVB and SBTVD and can be enumerated as:Figure 9
Upgrading Steps.Figure 10
DVB and SBTVD Transformation.(1)
Update application event: generated automatically or manually by the administrator user, this event produces the generation or update of an application, in our case a t-learning course;(2)
Content extraction: the contents in SCORM format are extracted from the Learning Management System;(3)
Content transformation: the contents are transformed using standard languages (XPL, XSL, XPath, etc.). Note that this process is different for DVB and SBTVD, because for the first one the result will be in tmPlayer (MHP) XML format and for the second one the result will be in tmPlayer NCL/Lua format;(4)
Application files generation: XML and image files are generated into the emission folder for each application or course;(5)
Send updated files: the new files are passed to  the tmCarousel system;(6)
Carousel generation: tmCarousel generates the carousel and the signalling according to DVB or SBTVD standards for the application generated;(7)
Broadcast: tmCarousel outputs through an ASI/IP PCI card and the output is connected to the multiplexer;(8)
Presentation of course contents: contents are presented to the student at home.tmPlayer is broadcasted with the contents, and it is the application in charge of representing the contents into the  student TV. In DVB tmPlayer is based on Java MHP whereas in SBTVD tmPlayer is defined by the Lua scripting language and the presentation is defined in NCL (XML format).In the following paragraphs the steps to be accomplished to bring the course contents to the students will be introduced. To perform all these operations both in DVB and SBTVD, several upgrades have been necessary to tmCarousel, tmManager and tmPlayer.


#### 5.4.1. tmCarousel Upgrade

DVB and SBTVD present several common features. As it can be seen, every table implemented in tmCarousel is included in the SBTVD standard, so tmCarousel is already implementing a subset of SBTVD which will be enough to generate interactive TV. It will not be necessary to make any modification to tmCarousel in order to generate interactivity in a SBTVD network.The main tasks for tmCarousel update are testing the system with Brazilian equipments, due to the fact that the standard specification usually differs from the hardware and software implementation of the providers. The testing also provides the proper broadcasting parameters on an SBTVD network.


#### 5.4.2. tmManager Upgrade

The tmManager role  in the system is to generate the contents in the right format for each Digital TV platform. The input contents will be defined in SCORM format and tmManager will transform it automatically to tmPlayer XML (DVB)  and tmPlayer NCL/Lua (SBTVD).As seen before, tmManager transformations are defined using standard languages. In each case (DVB or SBTVD) the correct transformation is defined and then performed to transform correctly the same course contents defined in SCORM format to the corresponding output format.The output files in both cases consist of XML files and images. In DVB these files are generated according to tmPlayer XML format, and for SBTVD the generation takes place according to the NCL/Lua format.In this scenario any content can be easily delivered in European and Brazilian Digital TV stations. Once the appropriate tmManager transformations have been defined, it is possible to generate automatically both contents for both platforms. Since SCORM is a standard to define learning contents, any type of learning content will be interoperable in both platforms.


#### 5.4.3. tmPlayer Upgrade

For the tmPlayer upgrade is necessary to distinguish between tmPlayer XML (for DVB-MHP STBs) and tmPlayer NCL/Lua (for SBTVD STBs).The tmPlayer XML for DVB-MHP is a commercial product of tmira solutions that is on air in several TV stations. This player has almost all the functionalities required for t-learning applications of the BEACON project. As seen before, tmPlayer based on DVB-MHP is a microbrowser that represents interactive applications defined in XML language.The mandatory middleware specified by the Sistema Brasileiro de TV Digital is based on the declarative language Ginga-NCL and scripting language Lua.Moreover, the declarative pages are generated by tmManager from the course contents in SCORM format. There are parts of the applications that cannot be defined using a declarative language and therefore must be implemented using Lua scripting language. Lua is needed to be used in forms, user interactions and return channel management, all these functionalities need to be included in a common tmPlayer NCL/Lua application in order to be reusable in the future.Briefly, the upgrades that have to be done in the system in order to assure the interoperability between European and Brazilian TV standards will follow the below steps:(1)
To develop a tmPlayer NCL/Lua prototype application with static content;(2)
To define structure and format of course contents (SCORM-BEACON format);(3)
To implement the transformation of SCORM-BEACON format to tmPlayer NCL/Lua, transformation processes defined in XPL and XSL language will be implemented in tmManager;(4)
To test courses created in the Ginga NCL/Lua Emulator;(5)
To test courses created in Ginga NCL/Lua real STBs, in European testbed at tmira solutions premises. To this extent, several Ginga STBs are available to test the applications created for the BEACON project, once they have been  loaded using its USB port;(6)
To implement the transformation of SCORM-BEACON format to tmPlayer XML for DVB-T using tmManager transformation engine;(7)
To create real course contents according to the SCORM-BEACON format;(8)
To test courses created in Ginga NCL/Lua STBs and DVB-MHP STBs.As seen before, the input format of the courses (BEACON-SCORM) is converted automatically to tmPlayer XML format using XSLT transformations. Then, the files generated are broadcast on a DVB-T/SBTVD-T network and tmPlayer is able to load, parse it and show the interactive content to TV students.


### 5.5. Alternative Approach

In this section, another approach is introduced to achieve interoperability between DVB standard (MHP or GEM) and ISDTV standard (Ginga) interactivity. This might be considered a new way to achieve interoperability, alternative to GEM, when a new implementation of the Brazilian television standard will be ready.Ginga Ready is a Ginga implementation powered by MOPA Embedded Systems. Over this layer Brazilian partners are implementing an XHTML browser that support also ECMA Script. The idea will be to implement the applications for the tmira solutions player that will act as a software abstraction layer.This solution will be optimal when implementations of standard MHP1.1 will run in European STBs: MHP1.1, with internet profile, has a full support of XHTML with ECMA scripts. So, any application that runs in a MHP1.1 STB can also run in others STBs that supports a XHTML (with ECMA scripts) browser, just with minimal modifications. Differences may be close to the ones experienced by users visiting a web site with two different web-browsers. Otherwise, web site developers need to optimize their sites to grant valuable navigation in different browsers. The same situation will take place once MHP1.1 will be implemented in European STBs.Actually, with MHP1.0.3, all applications  (included tmPlayer) are java ones. tmPlayer is an application that allows the reading of XML language: different applications running in tmira solutions player use the same player and different XML (an XML interpreter). Every application, for example different BEACON t-learning courses, can be presented by tmira solutions player, achieving interoperability.Looking at the same thing in a different perspective, in this scenario another interoperability solution has been studied into the BEACON project, but, instead of the previous problem(the failed Brazilian introduction of GEM in Ginga)  the core problem is the delay of real implementation on STBs of MHP1.1 in Europe.Obviously, once future implementation of MHP (1.1 and so on) will be available in Europe, this solution can be developed with success.As for the BEACON project, this way has been deeply explored and, although it is not the main implementation (focused on Ginga-NCL, as seen before), Brazilian partners of the project have yet implemented some modules of this solution to explore feasibility.


## 5.1. Architecture

The system architecture refers to the consolidated interactive DTV framework and comprises the following elements, as represented in Figure5:Figure 5
Interactive DTV Framework.(1)
Service and Content providers, providing content to be broadcasted on the communication channel;(2)
Broadcaster, in charge of multiplexing, modulating and broadcasting audio, video and applications over the air;(3)
Users, getting the DTT application (Java Xlet) over the air and downloading it on the STB through the interactive remote control;(4)
Service Centre, managing connectivity and user interaction through Internet protocols.The BEACON proposed architecture, as described in the following sections, will not restrict the inter-working with other service providers and network operators.Also, the adoption of a new framework, different from the European DVB-MHP platform formerly planned to be used, introduces the needs of facing the interoperability of different solutions as a key objective of the project.As seen before, in a technological perspective the decision of the Brazilian Government to establish the SBTVD-T standard leads to the adoption of the following subsystems:(1)
ISDB-T as broadcasting standard. ISDB-T is maintained by the Japanese organization ARIB and is based on MPEG-2 video and audio coding as well as the transport stream described by the MPEG-2 System standard. ATSC and DVB also adopted the same standard for their transport system. DVB and ISDB also provide for other video compression methods to be used, including JPEG and MPEG-4, although JPEG is only a required part of the MPEG standard. As for the modulation, ISDB-T supports COFDM with QPSK/QAM in the VHF and/or UHF band.(2)
H.264 (MPEG-4 Part 10) as the video and audio coding standard for supporting HDTV (High definition TV) 1080i video for fixed TV sets and LDTV (Low definition TV)  for mobile terminals.(3)
Ginga as the middleware standard, based on an execution engine (Ginga-J) integrated with a presentation engine (Ginga-NCL).As for the broadcasting, the interactive services that have been developed with this technology are only text (flat XML files) and resources (images, audios,…). During the emission, with the set of interactive services, is transmitted the tmPlayer product, a micro browser which is located in the Set Top Box and is able to analyse and parse XML information for converting to MHP code.Due to the Brazilian choice of SBTVD-T, the whole platform will be designed on the basis of a new architecture model.In order to realize this solution some necessary adaptations have been identified: Audio/Video encoder: changed to MPEG4-H.264; a data channel server for the Ginga middleware; a multiplexer equipment ISDB-T compliant; a modulator ISDB-T compliant; Set Top Boxes compliant with ISDB-T standard and Brazilian Middleware software and user interfaces (see Figure6 for European and Brazilian implementations).Figure 6
Interactive DTV Implementations in the Europe and Brazil.The hardware/software modules used in the test bed platform are(1)
anauthoring tool, with tmManager and tmPlayer (this two elements will be explained in the following paragraphs);(2)
anobject carousel generator and content multiplexing using a playout system  (tmCarousel, suitable for both DVB and ISDB);(3)
aDVB-T modulator and an ISDB-T modulator;(4)
anMHP compliant STB and Ginga compliant STB;(5)
a connection to PSTN as a return channel for interactive applications.


## 5.2. T-Learning Service

As regards t-learning, it is a subset of e-learning but the relevant access through a home-based TV could hugely enhance the learning opportunities in a way that Internet-based e-learning cannot currently do.For BEACON, a t-learning service is developed using aLearning Management System (LMS).This is the system that will be used in the project and will be correctly adapted to work on the system upgraded technology for interoperability on MHP and Ginga (NCL-Lua) standards.An LMS is a web application for managing computer-mediated distance learning (also known ase-learning) via Internet.An evolution of offlineComputer-Based Training (CBT) is called Web Based Training (WBT), delivered by internet. Those courses need a more structured way of delivering e-learning for a more detailed tracking in real time of the user interactions. This led to the creation of LMS software.In the DTT interactive domain, a t-learning session requires the following functionalities:(1)
authentication, to start the user session on the server;(2)
authorization, to receive a list of resources available to the user;(3)
delivery, to receive the course’s content;(4)
tracking, to track the duration and the results of the user session;(5)
communication, to exchange short mail messages with the tutor or the teachers.Apart from the delivery, that can take place using the broadcasted channel (i.e., the course contents can be included in the carousel), all the other functionalities require a connection to a service centre using the return channel.The service centre role can be played by an LMS customized with APIs created to exchange data with the t-learning application. Then can take place the authoring process that  can be streamlined according to the structure and layout of the courses, so that an automatic conversion of the content towards the format required for the DTT application could take place.An authoring tool consists of(1)
atext editor with an automatic check of the maximum number of characters allowed per page;(2)
animage selector to choose the illustration for the page and check its format and dimensions;(3)
aproperty selector to specify the page type: (i.e., tutorial, test, glossary, etc.);(4)
anautomatic ID generator for each page or entry;(5)
afunction to link an active word to an ID.The output will be an XML file and a folder of images. This output can be reopened with the authoring tool for further editing, copied to aSCORM WBT [14] engine to test it in a web browser environment, or finally passed to the transformation engine to be converted to the specific XML format required by the DTT application.In Figure7 there is a screenshot from the t-learning service developed in the BEACON project.Figure 7
t-learning service implemented.


## 5.3. System Technologies

In this section, an analysis of the existing technologies and upgrades needed to match the specifications given by the new libraries introduced (MHP and Ginga NCL-Lua) is shown, focusing on the architecture that will be the base for the provisioning of t-learning courses.A system calledtmBroadcast will be used. It is developed by tmira solutions, a Spanish partner of the BEACON project [15].tmBroadcast is an integral system for management and broadcasting ofElectronic Program Guides (EPG) and interactive MHP applications in DVB networks.  It is developed according to DVB and World Wide Web Consortium standards [16–18].The main features of the system are the following:(1)
user management: define users, assigning roles and services per user;(2)
broadcast configuration: all the options for configuring network parameters and modulation, maintenance services, generation of DVB/SI tables, bitrates configuration and selection of several outputs (ASI, RTP, UDP, modulator);(3)
EPG: the system has a complete tool fully integrated for management and emission of the Electronic Programming Guide and this part has all the functionality of the product tmEPG;(4)
maintenance of applications: management of interactive applications like creation, modifications, updates, editing contents, configuration of the return channel;(5)
scheduling: scheduling of applications at any time and for each service (Firing stream events);(6)
system configuration: Setting the parameters of the operating system (time, network);(7)
system backup: the system has the ability to perform backups with the configuration of the system, which may also include applications, EPG and log files;(8)
automatic updates tasks: includes the possibility of defining tasks for updating application contents in an automated manner according to a defined schedule.tmBroadcast is composed of three subsystems, as shown in Figure8Figure 8
tmBroadcast and its subsystems(1)
tmCarousel is a carousel playout of interactive TV applications and DVB signalling.  It works in DVB for cable, terrestrial and satellite networks.(2)
tmManager is a web platform that provides a web user interface and a set of tools to extract and transform contents in an automatic way, allowing to adapt any website or format for digital TV.(3)
tmPlayer is an application broadcasted that runs on STB and allows the viewer to browse the contents of an application. The browser is based in a custom XML language independent of the platform.These three subsystems are the core of the project implementation and need a more detailed explanation to point out the key features of each component, in order to define the upgrades needed to integrate the t-learning services in Europe and Brazil.


### 5.3.1. tmCarousel

tmCarousel is a client server system that includes the following components:(1)
Configuration Manager System, in charge of  receiving, processing and distributing system configuration to other system modules. It assures that configuration is always consistent. This module includes a timer that allows the insertion and removal of applications according to the broadcast programming.(2)
DVB Service Information (PSI/SI) generator. It generates DVB tables according to  specific configurations. Tables generated are: PAT, PMT, NIT, SDT, DTT, TOT, AIT, EIT P/F, EIT S [16].(3)
Data encoder, responsible for encoding the interactive applications according to the standard identified for this purpose (DSM-CC) [19] and sending them to the multiplexer to be inserted  into the output signal.(4)
Software Multiplexer, responsible for generating the output signal with DVB tables and applications. The output is transmitted through DVB-ASI, UDP or RTP.tmCarousel works for DVB in cable, terrestrial and satellite (NIT configuration), and its development is based on the following standards:(1)
MPEG-2: TS construction (ISO/IEC DIS 13818-1), DSM-CC: (ISO/IEC IS 13818-6) [17];(2)
DVB Service Information (ETSI EN 300 468, ETSI ETR 211, ETSI ETR 162) [20];(3)
Data broadcast (ETSI EN 301 192, TR 101 202), MHP (ETSI TS 101 812 ver 1.3.1 (MHP 1.0.3), ETSI TS 101 812 ver. 1.2.1 (MHP 1.0.2), ETSI TS 102 812 ver. 1.2.1 (MHP 1.1.X), DVB BlueBook A068r3 (MHP 1.1.3), A107: DVB MHP Specification 1.2 (MHP 1.2)) [17, 20].The system is highly reliable and robust. Several ASI or UDP Unicast/Multicast outputs can be set up.


### 5.3.2. tmManager

tmManager is the web platform for the secure control and management of tmBroadcast. It includes the definition of users and roles for the system. It also incorporates the functionality associated with the maintenance, scheduling and broadcasting of MHP applications, management and emission of EPG service and management of automatic updating tasks.tmManager has the functionality associated with the multiplex operator that allows a complete network configuration, including services, components, EPG, interactive applications, bitrate, output type (DVB-ASI or IP), operating system time, backups, network interfaces, and so forth.tmManager interface is multilingual, and it is currently available in English and Spanish, but can be easily translated to any other language like Portuguese.tmManager is based on the following standards:(1)
DVB: Service Information (ETSI EN 300 468) [20];(2)
World Wide Web Consortium: XML, XSL, XPL, XSD, XPATH, XQUERY, XFORMS, XHTML, CSS [18].One of the main advantages of tmManager is the ability to extract information from external data sources (web, database, content managers, RSS, Web services, etc.), and transform it into tmPlayer XML  format to represent it in an interactive MHP STB.tmManager has a core set of libraries to extract and transform contents to a desired format in an automatic way. This functionality is based on standard languages defined by World Wide Web Consortium [18]:(1)
XML (eXtensible Markup Language): for definition of contents;(2)
XSLT (XML Stylesheet Transformations): data transformation between formats  HTML, CSV, XLS, XML, PDF, XML;(3)
XPL (XML Processing Language): XML processing language;(4)
XPath (XML Path Language): language to access data into an XML (nodes and attributes);(5)
XQuery (XML Query Language): XML language to query databases;(6)
XForms: XML language to define web forms and interfaces.tmManager is able to transform any content in almost any format. In the system architecture developed for the BEACON project, tmManager will be in charge of transforming the course contents defined in SCORM language in tmPlayer XML for DVB and tmPlayer NCL for SBTVD.


### 5.3.3. tmPlayer

Is the technology that enables adoption of a Web, Database, CMS, and so forth, to bring their content directly to the television. Therefore all services available on Internet such as sending e-mail, online banking, games, information, and so forth, can be automatically reused for interactive TV.tmPlayer is an XML-based micro-browser that is broadcasted permanently and is able to represent any type of interactive service starting from just a XML files. tmPlayer allows the definition, representation and navigation into a wide range of interactive services through XML files. The language of tmPlayer has been used in the MHP platform, but it can be easily adapted to other platforms such as GEM, IPTV, OpenTV, Ginga, and so forth.Among its functionalities tmPlayer includes sending email, plugins, return channel access, use of smartcards. It also provides a development environment that enables the implementation of MHP interactive services, with no need for any skill in Java programming, or MHP itself. It only requires some expertise in XML technologies, much more widespread in the Internet community.


## 5.3.1. tmCarousel

tmCarousel is a client server system that includes the following components:(1)
Configuration Manager System, in charge of  receiving, processing and distributing system configuration to other system modules. It assures that configuration is always consistent. This module includes a timer that allows the insertion and removal of applications according to the broadcast programming.(2)
DVB Service Information (PSI/SI) generator. It generates DVB tables according to  specific configurations. Tables generated are: PAT, PMT, NIT, SDT, DTT, TOT, AIT, EIT P/F, EIT S [16].(3)
Data encoder, responsible for encoding the interactive applications according to the standard identified for this purpose (DSM-CC) [19] and sending them to the multiplexer to be inserted  into the output signal.(4)
Software Multiplexer, responsible for generating the output signal with DVB tables and applications. The output is transmitted through DVB-ASI, UDP or RTP.tmCarousel works for DVB in cable, terrestrial and satellite (NIT configuration), and its development is based on the following standards:(1)
MPEG-2: TS construction (ISO/IEC DIS 13818-1), DSM-CC: (ISO/IEC IS 13818-6) [17];(2)
DVB Service Information (ETSI EN 300 468, ETSI ETR 211, ETSI ETR 162) [20];(3)
Data broadcast (ETSI EN 301 192, TR 101 202), MHP (ETSI TS 101 812 ver 1.3.1 (MHP 1.0.3), ETSI TS 101 812 ver. 1.2.1 (MHP 1.0.2), ETSI TS 102 812 ver. 1.2.1 (MHP 1.1.X), DVB BlueBook A068r3 (MHP 1.1.3), A107: DVB MHP Specification 1.2 (MHP 1.2)) [17, 20].The system is highly reliable and robust. Several ASI or UDP Unicast/Multicast outputs can be set up.


## 5.3.2. tmManager

tmManager is the web platform for the secure control and management of tmBroadcast. It includes the definition of users and roles for the system. It also incorporates the functionality associated with the maintenance, scheduling and broadcasting of MHP applications, management and emission of EPG service and management of automatic updating tasks.tmManager has the functionality associated with the multiplex operator that allows a complete network configuration, including services, components, EPG, interactive applications, bitrate, output type (DVB-ASI or IP), operating system time, backups, network interfaces, and so forth.tmManager interface is multilingual, and it is currently available in English and Spanish, but can be easily translated to any other language like Portuguese.tmManager is based on the following standards:(1)
DVB: Service Information (ETSI EN 300 468) [20];(2)
World Wide Web Consortium: XML, XSL, XPL, XSD, XPATH, XQUERY, XFORMS, XHTML, CSS [18].One of the main advantages of tmManager is the ability to extract information from external data sources (web, database, content managers, RSS, Web services, etc.), and transform it into tmPlayer XML  format to represent it in an interactive MHP STB.tmManager has a core set of libraries to extract and transform contents to a desired format in an automatic way. This functionality is based on standard languages defined by World Wide Web Consortium [18]:(1)
XML (eXtensible Markup Language): for definition of contents;(2)
XSLT (XML Stylesheet Transformations): data transformation between formats  HTML, CSV, XLS, XML, PDF, XML;(3)
XPL (XML Processing Language): XML processing language;(4)
XPath (XML Path Language): language to access data into an XML (nodes and attributes);(5)
XQuery (XML Query Language): XML language to query databases;(6)
XForms: XML language to define web forms and interfaces.tmManager is able to transform any content in almost any format. In the system architecture developed for the BEACON project, tmManager will be in charge of transforming the course contents defined in SCORM language in tmPlayer XML for DVB and tmPlayer NCL for SBTVD.


## 5.3.3. tmPlayer

Is the technology that enables adoption of a Web, Database, CMS, and so forth, to bring their content directly to the television. Therefore all services available on Internet such as sending e-mail, online banking, games, information, and so forth, can be automatically reused for interactive TV.tmPlayer is an XML-based micro-browser that is broadcasted permanently and is able to represent any type of interactive service starting from just a XML files. tmPlayer allows the definition, representation and navigation into a wide range of interactive services through XML files. The language of tmPlayer has been used in the MHP platform, but it can be easily adapted to other platforms such as GEM, IPTV, OpenTV, Ginga, and so forth.Among its functionalities tmPlayer includes sending email, plugins, return channel access, use of smartcards. It also provides a development environment that enables the implementation of MHP interactive services, with no need for any skill in Java programming, or MHP itself. It only requires some expertise in XML technologies, much more widespread in the Internet community.


## 5.4. System Upgrades

The tmBroadcast system had been originally designed for DVB broadcasting in cable, terrestrial and satellite networks, but all technology involved in this system has been developed basing on standards and in modular components in order to be flexible and adaptable. As a result,  it can be expanded to adopt any other standards of digital TV.In the architecture developed for the BEACON purposes,  tmBroadcast must be upgraded to be fully compatible with the Brazilian standard SBTVD. This upgrade is planned for each of the tmBroadcast components and it is described below.First of all we have defined the sequence of processes to bring the course contents to the students through interactive Digital TV with tmBroadcast. In Figures9 and 10 the steps of the whole process are shown, and steps that must be upgraded for SBTVD have been highlighted in orange colour. The other steps are the same for DVB and SBTVD and can be enumerated as:Figure 9
Upgrading Steps.Figure 10
DVB and SBTVD Transformation.(1)
Update application event: generated automatically or manually by the administrator user, this event produces the generation or update of an application, in our case a t-learning course;(2)
Content extraction: the contents in SCORM format are extracted from the Learning Management System;(3)
Content transformation: the contents are transformed using standard languages (XPL, XSL, XPath, etc.). Note that this process is different for DVB and SBTVD, because for the first one the result will be in tmPlayer (MHP) XML format and for the second one the result will be in tmPlayer NCL/Lua format;(4)
Application files generation: XML and image files are generated into the emission folder for each application or course;(5)
Send updated files: the new files are passed to  the tmCarousel system;(6)
Carousel generation: tmCarousel generates the carousel and the signalling according to DVB or SBTVD standards for the application generated;(7)
Broadcast: tmCarousel outputs through an ASI/IP PCI card and the output is connected to the multiplexer;(8)
Presentation of course contents: contents are presented to the student at home.tmPlayer is broadcasted with the contents, and it is the application in charge of representing the contents into the  student TV. In DVB tmPlayer is based on Java MHP whereas in SBTVD tmPlayer is defined by the Lua scripting language and the presentation is defined in NCL (XML format).In the following paragraphs the steps to be accomplished to bring the course contents to the students will be introduced. To perform all these operations both in DVB and SBTVD, several upgrades have been necessary to tmCarousel, tmManager and tmPlayer.


### 5.4.1. tmCarousel Upgrade

DVB and SBTVD present several common features. As it can be seen, every table implemented in tmCarousel is included in the SBTVD standard, so tmCarousel is already implementing a subset of SBTVD which will be enough to generate interactive TV. It will not be necessary to make any modification to tmCarousel in order to generate interactivity in a SBTVD network.The main tasks for tmCarousel update are testing the system with Brazilian equipments, due to the fact that the standard specification usually differs from the hardware and software implementation of the providers. The testing also provides the proper broadcasting parameters on an SBTVD network.


### 5.4.2. tmManager Upgrade

The tmManager role  in the system is to generate the contents in the right format for each Digital TV platform. The input contents will be defined in SCORM format and tmManager will transform it automatically to tmPlayer XML (DVB)  and tmPlayer NCL/Lua (SBTVD).As seen before, tmManager transformations are defined using standard languages. In each case (DVB or SBTVD) the correct transformation is defined and then performed to transform correctly the same course contents defined in SCORM format to the corresponding output format.The output files in both cases consist of XML files and images. In DVB these files are generated according to tmPlayer XML format, and for SBTVD the generation takes place according to the NCL/Lua format.In this scenario any content can be easily delivered in European and Brazilian Digital TV stations. Once the appropriate tmManager transformations have been defined, it is possible to generate automatically both contents for both platforms. Since SCORM is a standard to define learning contents, any type of learning content will be interoperable in both platforms.


### 5.4.3. tmPlayer Upgrade

For the tmPlayer upgrade is necessary to distinguish between tmPlayer XML (for DVB-MHP STBs) and tmPlayer NCL/Lua (for SBTVD STBs).The tmPlayer XML for DVB-MHP is a commercial product of tmira solutions that is on air in several TV stations. This player has almost all the functionalities required for t-learning applications of the BEACON project. As seen before, tmPlayer based on DVB-MHP is a microbrowser that represents interactive applications defined in XML language.The mandatory middleware specified by the Sistema Brasileiro de TV Digital is based on the declarative language Ginga-NCL and scripting language Lua.Moreover, the declarative pages are generated by tmManager from the course contents in SCORM format. There are parts of the applications that cannot be defined using a declarative language and therefore must be implemented using Lua scripting language. Lua is needed to be used in forms, user interactions and return channel management, all these functionalities need to be included in a common tmPlayer NCL/Lua application in order to be reusable in the future.Briefly, the upgrades that have to be done in the system in order to assure the interoperability between European and Brazilian TV standards will follow the below steps:(1)
To develop a tmPlayer NCL/Lua prototype application with static content;(2)
To define structure and format of course contents (SCORM-BEACON format);(3)
To implement the transformation of SCORM-BEACON format to tmPlayer NCL/Lua, transformation processes defined in XPL and XSL language will be implemented in tmManager;(4)
To test courses created in the Ginga NCL/Lua Emulator;(5)
To test courses created in Ginga NCL/Lua real STBs, in European testbed at tmira solutions premises. To this extent, several Ginga STBs are available to test the applications created for the BEACON project, once they have been  loaded using its USB port;(6)
To implement the transformation of SCORM-BEACON format to tmPlayer XML for DVB-T using tmManager transformation engine;(7)
To create real course contents according to the SCORM-BEACON format;(8)
To test courses created in Ginga NCL/Lua STBs and DVB-MHP STBs.As seen before, the input format of the courses (BEACON-SCORM) is converted automatically to tmPlayer XML format using XSLT transformations. Then, the files generated are broadcast on a DVB-T/SBTVD-T network and tmPlayer is able to load, parse it and show the interactive content to TV students.


## 5.4.1. tmCarousel Upgrade

DVB and SBTVD present several common features. As it can be seen, every table implemented in tmCarousel is included in the SBTVD standard, so tmCarousel is already implementing a subset of SBTVD which will be enough to generate interactive TV. It will not be necessary to make any modification to tmCarousel in order to generate interactivity in a SBTVD network.The main tasks for tmCarousel update are testing the system with Brazilian equipments, due to the fact that the standard specification usually differs from the hardware and software implementation of the providers. The testing also provides the proper broadcasting parameters on an SBTVD network.


## 5.4.2. tmManager Upgrade

The tmManager role  in the system is to generate the contents in the right format for each Digital TV platform. The input contents will be defined in SCORM format and tmManager will transform it automatically to tmPlayer XML (DVB)  and tmPlayer NCL/Lua (SBTVD).As seen before, tmManager transformations are defined using standard languages. In each case (DVB or SBTVD) the correct transformation is defined and then performed to transform correctly the same course contents defined in SCORM format to the corresponding output format.The output files in both cases consist of XML files and images. In DVB these files are generated according to tmPlayer XML format, and for SBTVD the generation takes place according to the NCL/Lua format.In this scenario any content can be easily delivered in European and Brazilian Digital TV stations. Once the appropriate tmManager transformations have been defined, it is possible to generate automatically both contents for both platforms. Since SCORM is a standard to define learning contents, any type of learning content will be interoperable in both platforms.


## 5.4.3. tmPlayer Upgrade

For the tmPlayer upgrade is necessary to distinguish between tmPlayer XML (for DVB-MHP STBs) and tmPlayer NCL/Lua (for SBTVD STBs).The tmPlayer XML for DVB-MHP is a commercial product of tmira solutions that is on air in several TV stations. This player has almost all the functionalities required for t-learning applications of the BEACON project. As seen before, tmPlayer based on DVB-MHP is a microbrowser that represents interactive applications defined in XML language.The mandatory middleware specified by the Sistema Brasileiro de TV Digital is based on the declarative language Ginga-NCL and scripting language Lua.Moreover, the declarative pages are generated by tmManager from the course contents in SCORM format. There are parts of the applications that cannot be defined using a declarative language and therefore must be implemented using Lua scripting language. Lua is needed to be used in forms, user interactions and return channel management, all these functionalities need to be included in a common tmPlayer NCL/Lua application in order to be reusable in the future.Briefly, the upgrades that have to be done in the system in order to assure the interoperability between European and Brazilian TV standards will follow the below steps:(1)
To develop a tmPlayer NCL/Lua prototype application with static content;(2)
To define structure and format of course contents (SCORM-BEACON format);(3)
To implement the transformation of SCORM-BEACON format to tmPlayer NCL/Lua, transformation processes defined in XPL and XSL language will be implemented in tmManager;(4)
To test courses created in the Ginga NCL/Lua Emulator;(5)
To test courses created in Ginga NCL/Lua real STBs, in European testbed at tmira solutions premises. To this extent, several Ginga STBs are available to test the applications created for the BEACON project, once they have been  loaded using its USB port;(6)
To implement the transformation of SCORM-BEACON format to tmPlayer XML for DVB-T using tmManager transformation engine;(7)
To create real course contents according to the SCORM-BEACON format;(8)
To test courses created in Ginga NCL/Lua STBs and DVB-MHP STBs.As seen before, the input format of the courses (BEACON-SCORM) is converted automatically to tmPlayer XML format using XSLT transformations. Then, the files generated are broadcast on a DVB-T/SBTVD-T network and tmPlayer is able to load, parse it and show the interactive content to TV students.


## 5.5. Alternative Approach

In this section, another approach is introduced to achieve interoperability between DVB standard (MHP or GEM) and ISDTV standard (Ginga) interactivity. This might be considered a new way to achieve interoperability, alternative to GEM, when a new implementation of the Brazilian television standard will be ready.Ginga Ready is a Ginga implementation powered by MOPA Embedded Systems. Over this layer Brazilian partners are implementing an XHTML browser that support also ECMA Script. The idea will be to implement the applications for the tmira solutions player that will act as a software abstraction layer.This solution will be optimal when implementations of standard MHP1.1 will run in European STBs: MHP1.1, with internet profile, has a full support of XHTML with ECMA scripts. So, any application that runs in a MHP1.1 STB can also run in others STBs that supports a XHTML (with ECMA scripts) browser, just with minimal modifications. Differences may be close to the ones experienced by users visiting a web site with two different web-browsers. Otherwise, web site developers need to optimize their sites to grant valuable navigation in different browsers. The same situation will take place once MHP1.1 will be implemented in European STBs.Actually, with MHP1.0.3, all applications  (included tmPlayer) are java ones. tmPlayer is an application that allows the reading of XML language: different applications running in tmira solutions player use the same player and different XML (an XML interpreter). Every application, for example different BEACON t-learning courses, can be presented by tmira solutions player, achieving interoperability.Looking at the same thing in a different perspective, in this scenario another interoperability solution has been studied into the BEACON project, but, instead of the previous problem(the failed Brazilian introduction of GEM in Ginga)  the core problem is the delay of real implementation on STBs of MHP1.1 in Europe.Obviously, once future implementation of MHP (1.1 and so on) will be available in Europe, this solution can be developed with success.As for the BEACON project, this way has been deeply explored and, although it is not the main implementation (focused on Ginga-NCL, as seen before), Brazilian partners of the project have yet implemented some modules of this solution to explore feasibility.


## 6. Conclusion

This article describes an innovative system architecture to deliver t-learning services related to social inclusion in Brazil, on the basis of pioneering research on interoperability between the European and the Brazilian Digital Terrestrial Television Broadcasting standards. Before of this, an introduction to the interactivity standards is given, focusing on the key differences between different options:  an interoperability solution based on GEM implementation (at this moment not available in the Brazilian scenario but analyzed in this paper), the solution implemented in the BEACON project platform (involving Ginga NCL-Lua middleware for the Brazilian realization) and other choices based  on the advent of MHP 1.1 in Europe.This effort is the  first important step in the direction of SBTVD interoperability with the other DTTB standards. It creates the basis for a wide range of interactive applications development, designing a common architecture involving MHP and Ginga without neglecting some other possible alternatives, but finding in the NCL-Lua implementation the actual best choice to deliver interactive services in an interoperable mode between European and Brazilian digital television.


## 7. Future Works

Future enhancements are strongly dependent on political choices such as GEM implementation in Ginga, delays of MHP 1.1 in European STBs and so on. During the design and the realization of BEACON system architecture several technologies and standard have been taken into account, so different ways could be covered if something changes.Obviously, the solution that has been implemented faced the challenge of the creation of an interactive application that runs t-learning services on the SBTVD-T standard, but it permits interoperability only between Europe and Brazil.The introduction of GEM in Ginga, instead, would have allowed interoperability with other standards (e.g., Japanese, North-American). As for the system described in this paper, it would be possible to perform the upgrade to a GEM middleware just with the creation of a GEM-compliant tmPlayer and some small modifications, because in our effort the broadcasting issues about tmBroadcast in a Brazilian (SBTVD) scenario have been already solved.Another interesting evolution of the system regards the integration with HTML browsers. In fact, although it seems a step back from t-learning to e-learning services, it permits the fruition of the services on every HTML-enabled browser by only creating another one tmPlayer version able to translate the XML input in HTML pages (those pages will be adapted opportunely to be browsed easily as interactive DTV contents).In this way, expanding the range of networks and devices, it will be possible to overcome the borders of the DTV broadcasting model to reach every internet-embedded device using different internet access networks (xDSL, Wi-Fi, WiMAX, UMTS, IMT2000 etc.), or by plugging small media centres (e.g., mini-PCs, Play Station, Wii or X-BOX) to a TV screen.In this way, by yhe use of the familiar TV remote controller, it will be possible to draw benefits from new devices such as WiiMote and 3D mouse, making the  interaction so much easier and intuitive, especially for the elderly and many other “infomarginated” peoples.In this way it is possible to minimize the digital gap for those people and to increase the effective social inclusion and the digital inclusion.



---

*Source: 579569-2009-08-27.xml*