8/8/2019 PID1479377_ieee

1/6

Interactive Service Provider Architecture for

Interactive Digital Television Systems

Gabriel Massote PradoComputer Science Department, Federal University of

So CarlosSo Carlos SP, Brazil

gabriel_prado@dc.ufscar.br

Srgio Donizetti ZorzoComputer Science Department, Federal University of

So CarlosSo Carlos SP, Brazil

zorzo@dc.ufscar.br

Abstract The Interactive Digital TV systems allow a new

range of services around broadcasted television content. Thus,

interactive programs can be broadcasted allowing user

interaction. The interaction implicates in a new way to produce

and think about television content. This paper aims at

presenting Interactive Service Provider architecture for

Interactive Digital TV systems, based on service-oriented

architecture, ensuring a standardized communication betweenclient applications and its interactive services. The diversity of

broadcasted applications and usage of an Interactive Channel

as external communication in Brazilian context, leads to a case-

study with the objective to consider the social inclusion

intention specified in Brazilian Presidential Decree No. 4901.

Keywords: Digital Television; Ginga; Interactive Service

Provider; Service-Oriented Architecture; Web Services

I. INTRODUCTIONDigital Television, like other media, is originating from

technological developments related to the form ofinformation dissemination. These developments, primarilyrelated to migration from the analogue systems to digitalsystems, allow television systems, now called DigitalTelevision (DTV) systems, to produce and broadcast programs with high quality audio and video. Furthermore,the digital signal enables the transmission of data togetherwith audio and video streams [3], which offers the ability toadd applications, with or without interactive character.

In this context, a new and exciting universe of activitiesinvolving production of audio/visual content to includeapplications that allow the user to interact in the programs iscreated. The possibility to offer applications to viewersoriginates the Interactive Digital Television System (iTV)[1], a new production chain involving the programs andapplications production of interactive character. In thissystem, service providers should be concerned with thediversity of applications and services that can be offered. Inthis case, the viewer becomes the user of televisionprograms.

Describing DTV and iTV systems, they both use largelythe same definitions and concepts. Their differences arerelated to the possibility of offering a richer user interaction by interactive systems. Therefor, an iTV system needs tooffer an interactive channel support and modify somefunctionality in production (service provider) and in

reception (user or Set-Top Box). These changes enable thefeatures of interactive systems and channel [12] used to sendthe results of interactive applications to service provider inorder to control the content of user interaction, remindingthat transmission occurs in the same way.

Changes in production and reception are related to the

data stream transmission together the audio/video stream andhow the data can be offered to user like interactiveapplications associated with a program. Thus, thecomponents in a system are represented by iTV service provider, transmission, reception (Set-Top Box) andinteractive channel, being responsible for quality ofaudio/video programs, with multiprogramming possibilitycaused by signal compression and the addition of digital datastreams along with audio/video.

Some iTV standards such as European (DVB), American(ATSC) and Japanese (ISDB-T), use iTV or DTV televisionsystems characteristics adjusting to the interests of eachcountry or region. The DVB (Digital Video Broadcasting)[7] focuses on the possibility of programs transmission,

offering higher quality audio/video since there is thepossibility to add interactive applications; ATSC (AdvancedTelevision System Committee) [8] focuses on thetransmission of television programs with the highest qualitydigital audio/video without concerning at interactivityoffering; ISDB-T (Integrated Services Digital Broadcasting -Terrestrial) [9], basis for the Brazilian System of DigitalTelevision (SBTVD/ISDB-TB standard), has the mainobjective: broadcasting programs focusing on diversity ofinteractive applications, offering support for portability andmobility for mobile devices.

In Brazil, the SBTVD is in implementation process fromthe large to the small urban centers. In the current scenario,the service providers have the capacity to produce

audio/visual content, broadcast digital programs and receivethe digital signal in the viewer. As quoted, in the small urbancenters some service providers broadcast their programs withinteractive applications for user interaction.

The motivation of this work is to propose architecture ininteractive channel to ensure data storage and informationrequest based on user interaction with interactive programs.Thus, service providers can produce programs with the possibility of adding interactive applications (interactiveprograms), promoting social inclusion and providing the user

8/8/2019 PID1479377_ieee

2/6

with new and updated information to produce televisioncontent. Another motivation is to add knowledge andresearch in the area of interactive channel, contributing to theadvance of implementations of Brazilian middleware Ginga[4] and SBTVD.

This paper presents a generic and extensible InteractiveService Provider architecture, using the Ginga-NCL

implementation of Brazilian middleware, which offers datastorage and information request facilities based on a ServiceOriented Architecture (Service Oriented Architecture)[2]. For treatment support of user interaction information, anInteractive Service Provider (ISP) and an extension tomiddleware will be added to an interactive channel to ensuresupport of interactive applications for communicating withthe external environment (PSI). This architecture enablesSBTVD to close the cycle of iTV system consisting atservice provider, broadcast communication, user (Set-TopBox) and interactive channel.

The paper is organized in four sections: Section 2 presents the possible behaviors of interactive applicationsand components necessary for communication with the

outside when needed; Section 3 presents the work related tochannel, offering interactive services; Section 4 describes thearchitecture of interactive channel proposal, highlighting itscharacteristics and its operation before the storage anddelivery of services and finally, Section 5 presents theconclusions of this work considering the Brazilian contextand the work of TVDI already developed at the national andinternational levels.

II. INTERACTIVE SERVICESAccording to Presidential Decree No. 4901 [5], the

assumptions of the Brazilian government arent restricted totransmission of digital content, but also to promote socialinclusion and democratization of information through thedevelopment of e-government, e-learning and e-commerceapplications, like on the Internet in the iTV context, beingclassified in t-government, t-learning and t-commerceapplications.

To promote social inclusion, SBTVD should enable theincorporation of interactive applications to televisioncontent, allowing the viewer (user) to interact withapplications, while iTV systems need to ensure thesesupports in Set- Top Box (STB), more specifically, in themiddleware. Moreover, it is necessary an interactive channelfor sending data to the service provider.

With the possibility of interactive applications broadcaster, the iTV systems start to worry not only aboutthe cycle of programs but also with the applications. Atelevision program without applications has a continuous lifecycle being generated, transmitted and received. Whenapplications are broadcasted, this continuous program cycleis the same but other life cycle is included in the program.This can be classified in pseudo-interactive or interactive [3]cycle, involving programs and applications.

A pseudo-interactive program limits the application lifecycle to exchange information to STB, that can write andread data using the middleware or deliver content to users,

but without any form of external communication using theinteractive channel .

The interactive programs have the same pseudo-interactive characteristics with the difference of applicationcommunication possibility through interactive channel. Thisfeature allows the service provider to add more functionality,allowing t-commerce, t-government and t-learning

applications to be broadcasted. New form of communication between service provider

and user becomes possible. The digital television systemsmust ensure the means to enable an interactive channelcommunication located between service providers and usersto send and receive information. [13]. For user interaction,information can be stored and offered in content form, forthe service provider an Interactive Service Provider (ISP)must be added in the interactive channel [1] [13]. In iTVsystems the ISP may be located at the network or at acompany contracted to provide such service.

The interactive channel is designed to ensure two-waycommunication between service providers and users, toguarantee that data resulting from user interaction can be

sent to ISP and service providers could request informationrelated to it, to produce and deliver new and updated contentto users through television programs or interactiveapplications.

The technologies used to ensure data transport throughthe interactive channel are influenced by several factors: physical and social. In Brazilian context, the technologychoice is influenced by socioeconomic differences, physicaland technological limitations present in every region of thecountry [1] [13]. According to the Brazilian standard No.15607-1 [6], the interactive channel architecture shouldnt berestricted to a single technology of access to internet, whatenables the use of different forms of internet access,considering lowest cost available in each region of the

country, due to the intent of social inclusion.With broadcast of interactive applications, the digital

television systems have a necessity of storing informationabout user interaction or other useful information aboutservice providers. Thus, programs with these features requirespecific forms (services) of data treatment to send andprovide information request in ISP. These specific forms canbe organized in an Interactive Service [12] based on a clientside and on a server side as shown in figure 1.

Figure 1. Interactive Service

8/8/2019 PID1479377_ieee

3/6

The client side is represented by interactive applicationsthat will be produced and broadcasted by service providersand the server side is represented by interactive services inISP responsible for data storage and information requestrelated to its application. An Interactive Service representsthe relationship and consequently the communicationbetween interactive applications and its application services.

This new form of production involving television,interactive applications and application services enables broadcasters to concentrate on the television production programs and Interactive Services [12]. Thus, there is the possibility to create a new production line, where thetelevision programs continue to display the audio/videoapplications and Interactive Services are produced andoffered to users.

III. INTERACTIVE SERVICE PROVIDERARCHITECTUREThe first purpose of Interactive Service Provider (ISP)

architecture is to offer a support of services publication,concerning an application service provider with the featureof concentrating common services in a unique localization.The second one is to offer a support to publish servicesresidents outside the ISP, such as a bank and somegovernmental services already developed. Other feature insecond purpose is the possibility to interconnect more thanone ISP to create a global communication.

This section is organized in 3 subsections: the firstdescribes the generic ISP architecture with all features about publication and service access; the second describes theClient API (CISP) that ensure a standardizedcommunication for clients; and finally, the third describesthe standard message used to communicate with ISP andtheir few parameters.

A.

Generic Interactive Service ProviderThe generic Interactive Service Provider (ISP) was

designed from a service-oriented architecture [2] with the principle to ensure to iTV systems a generic architecture,standardized and expandable with the guarantee of service publication and centralized database of commoninformation.

The architecture is based on a composition of Webservices (services) to enable the addition of new serviceswithout modifying the architecture and the way to access theservices. In order to meet these features, Web services wereadopted because they are independent of application andbecause they work with Web-based message requests [2].

In this service composition architecture, the services wererated to work with intermediaries or service providers roles[2]. The first category of services in this architecture islocated between the client applications and services rated asservice providers. Their feature is to receive requests fromclient applications and forwarding requests to service providers, as a router. The second category is related toapplication services responsible for the storage andinformation delivery related with interactive application.Thus, the architecture of the PSI, shown in figure 2, is

divided into two service layers: front-end and back-endlayers.

Figure 2. Generic ISP Architecture

The front-end layer is the only form that clients canaccess the PSI. This layer offers ways to publish and accessapplication services and the access management is donethrough an intermediary service (broker) who actsgenerically offering a standard interface (form ofcommunication) for the communication betweenapplications and services.

The broker (front-end service) is the standard service ofcommunication with ISP that provides three logicoperations (postService, listServices and Route) responsiblefor the service publication, request service and information.PostService operation is responsible for ensuring forms ofpublication of application services being available in PSI. Its

operation is based on the receipt of a file, which has theservice logic (classified how Local Services), storing the fileon the server and registering the service on a servicesregistry (UDDI - Universal Description, Discovery andIntegration) [2]. Other functionality enables that externalservice (classified how Remote Services) produced in otherISP, Web or Commerce Applications can be reached by ISPrequested. ListServices operation offers a list of servicesregistered in UDDI. When requested, the operation checksthe services on UDDI getting the corresponding filedescriptor of service (WSDL - Web Services DescriptionLanguage) [2] for service information. Finally, the Router provides a standard communication interface withinteractive application services and the routing feature to

forward requests to back-end layer. When a service requestis received, the router operation accesses the UDDI to verifyif service is available to process the request. Once it isavailable the request is redirected to a service that returnsthe response to be returned to the client.

Backend layer represents application services in ISPaimed at offering a fast way to deploy/publication and accessthe services. This layer was proposed to be used before thegreat possibility of Digital TV application producing and

8/8/2019 PID1479377_ieee

4/6

editing their services and applications. Thus, newdeveloped/updated applications only need to deploy theirservice using broker to offer the new features. Each servicein back-end layer has its own features independent of broker.This creates the possibility of using these services inarchitecture.

The general ISP behavior with front-end and back-end

layers, illustrated in figure 2, offers a standardcommunication interface with services published in the backend layer allowing different services to bedeployed/published, this way clients concern only aboutaccessing the ISP. This allows additional services to beadded in architecture without changing the access way used by clients to access application services. To use all thefeatures offered by ISP, consequently service broker,interactive services should be published using the ISP WebTool. On the user side, the Client ISP API helps user tocommunicate with ISP to send and receive information.

This architecture was developed using Java language toservices development and Axis2 Web Service engine [16] topublish services on Web. The API was developed to ensure

standard communication with ISP front-end layer (brokerservice) offering Java and Lua support. The ISP ManagerTool was developed using J2EE technology and Javaimplementation of Client ISP API to communicate withbroker operations.

B. Client ISP APITo facilitate the client access to the ISP frontend layer, an

API (Client ISP API - CISP) in Java, C++ and Lua wasproposed and aggregated to architecture. Their importance tothe architecture is related to simplify the clientcommunication, abstracting to the application developer theconfigure layer. With this API, the application developmentis concentrated only on logic of application and message

content.The CISP was developed using a dynamic way to createa SOAP message offered by Axis2 engine (AXIOM [17])and all abstracting from AXIOM is done by CISP.

C. Standard MessageIn order the communication between client applications

and ISP to occur in a standardized form, some configurationsneed to be added in a SOAP message [2], so that the brokercan understand the message and redirect to applicationservice. These messages, or SOAP envelop, is divided in aheader, in which application services information areconfigured, and a body containing the message content.

Some formatting or mandatory fields should compose the

message being sent. Through the header, the applicationmust specify which application services and operation of theservice you want to access, enabling the message to beinterpreted and routed through the broker. The data is sent inthe body to be stored by the service or request information.

This standard message is an essential component forunderstanding the requests by the ISP, more specifically bythe broker, allowing even applications to communicate withISP. Using CISP, the message doesnt need to be configured.

Reminding that de API abstracts all communicationconfiguration.

IV. DIGITAL TELEVISION ARCHITECTURE WITH ISPARCHITECTURE

The ISP architecture was planned to be used with iTVsystems, to offer support for interactive services composedby interactive applications and their application services. IniTV context, the usage of ISP architecture needs that someparts of architecture are added in iTV architecture to offerinteractive service support. These parts are covered foradditional ISP elements in service provider and user side.Figure 3 shows the iTV architecture with ISP.

Figure 3. Digital Television Architecture with ISP

On the user side, the interests are in the interactiveapplications communication with ISP to send and receivedata. To ensure this form of communication, developersneed to use Lua implementation of CISP to ensure correctcommunication with ISP together with interactiveapplications developed in NCL language. Luaimplementation needs to be used because Lua language ispart of implementation of Brazilian middleware Ginga.

Since the applications were developed using CISP, allinformation resulted from user interaction will be sent to the

ISP and the broker will receive the information and willredirect to the correct application service in the backendlayer.

On the service providers side, the interests are involved inhow to obtain information resulting from the userinteraction with interactive applications to producenew/updated content and new applications.

Therefor, the service providers need to organize theirenvironments with two main features: support forpublication of application services and a way to access these

8/8/2019 PID1479377_ieee

5/6

services to obtain information processed. The publication ofapplication services can be done through the ISP ManagerTool using the postService offered by broker. To obtaininformation about published services and operations theoperation listServices can be used. Finally, to requestinformation about result and data processed related in userinteraction, a request message can be done using the routeoperation that will be responsible for finding and redirectingthe message for an application service and return the answerabout message requested. The communication process canbe done by CISP.

With the ISP architecture the service providers can obtainby the interactive channel information that can be used forthe production of new content production, new interactiveapplications and real-time update.

V. CASE STUDYIn Brazilian context, in which SBTVD focus on

developing social inclusion programs, this work presents thedevelopment of an interactive application for people with

special needs in order to enable the visually impaired to participate in the process of technological development ofInteractive Digital Television in Brazil.

The technologies used in the development process are inagreement with Brazilian system and need to be tested. Acase study of a questionnaire interactive application forvisually impaired on client side and the ISP architecture areused to guarantee the access to the interactive applicationexternal communication.

The interactive application gives to user several questionson different topics with the narration aid to support visuallyimpaired people. Receiving the application, the user canselect the desired genre and browse the questions.Completing the interaction, the result of the answered

questions is forwarded to the ISP. The response processed bythe ISP has a set of information to display to the user asshowing true questions, the total score of true questions andwhat your ranking based on other users.

Client side of case study uses Ginga-NCLimplementation to offer interactive support of NCL [15]applications and Lua imperative language with CISP thatoffers standard communication with ISP. When applicationis received by middleware, the user needs to interact in orderto show something. Interacting with the application somequestion genres are able to be selected and start all questionsabout selected genre. Interactive options are showed using NCL and the sound used to ensure visually impaired arestarted through Lua. After user interaction, the information

about all questions answered are sent using ICSP Luaimplementation, providing all communication support withinteractive service and all answers are returned to be shownto user through application and sound support.

Figure 4. Interactive Application

To ensure external communication for questionnaireapplication, the ISP architecture is used. The first step todevelop the service was executed by a Java developergenerating logic of service and putting in action using theISP Manager Tool, offered by ISP to deploy and publish theservice on Web. With service deployed and published theclients can use all features offered by the service.

Figure 5. Architecture with case studyGeneral behavior, presented by figure 5 uses all

architecture modules presented in this paper. The generalbehavior can be described in some steps:

1. Indicates when the service provider developer publishes the application service after itsdevelopment using ISP Manager Tool;

2. The service is registered in UDDI in order to beverified by route operation to redirect incomingrequests;

3. After user interaction, a message containing userinteraction is sent to ISP (broker servicer) to beredirected to an application service and stored;

4.

When the request is received from broker, aconsultation is made in UDDI to verify serviceexistence;

5. If service is registered, the message is redirected toapplication service to be processed;

6. When application service receives the message, thecontent is processed and returned to broker with theinformation requested;

8/8/2019 PID1479377_ieee

6/6

7. The broker finishes the process redirecting theprocessed message to interactive application to showinformation.

In high level behavior, when user interacts with theapplication some sound notification is started,complementing text information shown on screen, describingmenus, alternative and answers. When interaction is

completed, the resulting data, containing the chosen genreand its answers are sent to the ISP. To obtain the informationresulting from the interaction, the service processes theinformation providing a final response to the user containingthe correct answers, your final score and you are ranking tobe compared with other users.

This case study is represented by interactive applicationdevelopment following by service development and publication. After development process, the interactiveapplication is able to be broadcasted and executed in themiddleware Ginga implementation Ginga-NCL.

VI. CONCLUSIONThe purpose of this work is to present architecture able to

offer a concentration of services related with ISP by serviceproviders. Other feature is ensuring the generality to use thearchitecture in several iTV.

The mainly motivation in the Brazilian context is basedon the governmental interest mentioned in the PresidentialDecree No. 4901, which highlights the intention of ISDB-TB to provide the social and cultural inclusion of thecountry. This work is characterized to afford interactivechannel architecture to support interactive applications thatuses Brazilian middleware Ginga.

As future work, the architecture has two interesting points to improve. The improvements are related with thecapacity to offer a deployment support for interactive

services, not only for application services. This would allowinteractive applications to be stored together with theirservices and when service providers want to broadcast them,they request the interactive applications. The otherimprovements are related to the capacity of supporting a lotof connections at the same time and if the architecture willsupport this. The studies need to be made in the clusteringarea to distribute the architecture in other nodes.

Thus, we conclude that this work offers an architecturethat presents the main contribution, offering a generic andexpandable ISP for the publication of application services,allowing multiple services to be added without thearchitecture and form of access to be altered.

REFERENCES

[1] MONTEZ, C.; BECKER, V.: TV Digital Interativa: Conceitos,Desafios e Perspectivas para o Brasil. 2 ed. Editora da UFSC. (2005)

[2] ERL, T.: Service-Oriented Architecture (SOA): Concepts,Technology, and Design. Editora Prentice Hall. (2005).

[3] FERNANDES, J.; LEMOS, G.; SILVEIRA, G.: Introduo Televiso Digital Interativa: Arquitetura, Protocolos, Padres ePrticas. JAI-SBC. (2004)

[4] SOARES, L. F. G.; RODRIGUES, R. F.; MORENO, M. F.: Ginga- NCL: the Declarative Environment of the Brazilian Digital TVSystem. JBCS. (2007)

[5] Brazilian Presidential Decree n 4901. 2003. Avaiable in:http://sbtvd.cpqd.com.br/downloads/decreto_4901_2003.pdf (2009)

[6] ABNT NBR 15607-1: Norma para Televiso Digital Terrestre -Canal de Interatividade - Parte 1: Protocolos, Interfaces Fsicas eInterfaces de Software. Avaiable in:

http://www.forumsbtvd.org.br/materias.asp?id=112 (2009)[7] DVB: European Digital Television Standard. Avaiable in:

http://www.dvb.org (2009)

[8] ATSC: American Digital Television Standard. Avaiable in:http://www.atsc.org/cms (2009)

[9] ISDB-T: Japanese Digital Television Standard. Avaiable in:http://www.dibeg.org (2009)

[10] SANTOS JUNIOR, J. B. A., I.C. ; MORSELLI JUNIOR, J. C. M. ;TEIXEIRA, F. C.; PRADO, G. M.; VILA, P. M.: Back Channel inInteractive Digital Television Systems: Strategies for PrototypingApplications Using an Interactive Service Provider. ICEIS, v. 1.(2009)

[11] SEOK, J. M.; CHOI, J. H.; CHOI, J. S.: The Design of Web-basedReturn Channel System in the Data Broadcast Services. ICACT, v.2. (2005)

[12] Milos, F.; Basic, H.; Zagar, M.: Model of Application Frameworkfor Resource Limited iTV Systems. Information TechnologyInterfaces, 2006. 28th International Conference p. 633 -638. (2006)

[13] MANHES, M. A. R.; P. J. Shieh.; et al.: Canal de Interatividadeem TV Digital. Caderno CPqD Tecnologia, v. 1. (2005)

[14] LUA. Avaiablein: . Accessed in: 05/06/10[15] NCL - Nested Context Language. Avaiable in:

. Accessed in 1/07/10.

[16] Axis2 - Web Service Engine. Avaiable in:. Accessed in 10/06/10.

[17] Axiom XML Object Model. Avaiable in:. Accessed in 10/06/10.