TVGrid: A Grid Architecture to use the idle resources on a Digital TV network

TVGrid: A Grid Architecture to use the idle resources on a Digital TV network Carlos Eduardo Coelho Freire Batista 1, Tiago Maritan Ugulino de Araújo 1, Derzu Omaia 1, Thiago Curvelo dos Anjos 1, Giuliano Maia Lins de Castro 1, Francisco Vilar Brasileiro 2, Guido Lemos de Souza Filho 1 1 Digital Video Applications Lab Federal University of Paraíba 2 Distributed Systems Lab Federal University of Campina Grande {bidu,maritan,derzu,curvelo,giuliano}@lavid.ufpb.br, fubica@dsc.ufcg.edu.br,guido@di.ufpb.br Abstract Systems such as SETI@home [8] have proven that it is possible to make good use of massive amounts of communication and computing power that would otherwise be wasted in the leaves of the Internet. In this paper we explore this idea in a different setting. We present the TVGrid architecture, which brings parallel application execution to the Digital TV domain, by using the idle communication and processing capacity of a digital TV network. In the proposed architecture, a TV station runs a scheduler that uses unused bandwidth in the digital TV broadcast channel to send tasks to digital TV receivers, which may run them using their unused capacity. Task s outputs are later sent back to the TV station through a return channel (a broadband Internet connection, for example). TV Grid architecture was developed during the studies of the Brazilian Digital TV project. 1. Introduction An important technological convergence is happening worldwide with the crescent adoption of Digital TV. The convergence between computational and telecommunication technologies is building up a new TV, a technological revolution of an enormous reach, given that an important fraction of the world population spends a considerable amount of their time watching TV. A set of technologies was developed or adapted to the TV context. The digital TV receiver has many characteristics of a personal computer (having a processor, memory, etc), and the viewer now has an active role, since the new TV brings interactivity along: the TV environment now includes the execution of applications. On Europe, digital TV is already a reality, with DVB (Digital Broadcasting Video) systems running, with millions of devices receiving digital TV signal [9]. In Italy, 4 million digital TV receivers were sold in the last two years [10], all conforming to DVB s digital TV definitions, which specifies interactivity. In most other countries digital TV initiatives are being developed. For instance, Brazilian government is leading researches on the adoption of the Brazilian digital TV system. According to the Communication Minister, digital TV adoption in Brazil will increase the number of receivers nationwide, from 65 million to 80 million [19]. In summary, worldwide there are now hundreds of millions of digital TV receivers processing digital TV signal, and many more are still to be available in the near future. Analog TV uses a transmission channel that is able to convey data at a rate of tens of Mbps depending on the system (for instance, Brazilian analog TV uses a 20Mbps channel) [4]. The transmission of a high definition video using the MPEG-2 codification (which, nowadays, is the most used standard on digital TV) demands a transmission rate between 10 to 18Mbps [2], and newer standards such as ITU H.264 [6] uses even lower rates [3]. This unused capacity, complemented by the introduction of extra processing power at the receivers, has been used to allow the execution of interactive applications in digital TV. Nevertheless, in many cases, the interactive applications only consume a tiny amount of the excess resources (broadcast channel and dedicated interactive processor). Due to the nature of certain programs broadcasted, it is likely that these resources will never be used at their full capacity. The TVGrid architecture (based on the model of utility patent MU8600875-7 [1]) proposed in this paper aims at filling this gap. 2. Digital TV ` The Interactive Digital TV can be defined as the fusion of the traditional TV with computer

technologies, allowing viewers to take an active part on the program watched, with the possibility of interaction with the content. Plus, digital TV improves some aspects of TV transmission and reception, eliminates the effects of signal interference, etc. The digital TV signal is composed basically by the analogical TV signal digitally encoded. However, due to the development of compression technologies, digital compressed video can be broadcasted with bit rates of 1/4 to 1/10 of the original raw (not compressed) video. Using those technologies, the channel commonly used for the transmission of analogical TV can be used to transmit a larger quantity of information. The encoding and data transport technologies on the digital TV context allows the multiplexing of data with the video. A video can carry, then multiple subtitles, additional information and also applications to be executed by the TV receiver [21][23]. 2.1 Digital TV Systems A digital TV system can be seen as a set of definitions, which makes possible the construction of devices for transmission and reception of digital TV. Based on such definitions, a TV station transmits the video signal, digitally encoded, using a determined modulation standard to the receptors (embedded or not on the TV device) that will decode these signals in order to display it. The transport mechanism for the transmission of digital video with aggregated data used on the majority of the Digital TV Systems is the standard MPEG-2 system [7]. This mechanism defines tables for inclusion of data, which can be information concerning the transmitted program, as well as interactive applications. Some of the differences found between Digital TV Systems resides exactly on the way those tables are used. Among the existing systems, we can highlight the European DVB (Digital Broadcasting Video) the American ATSC (Advanced Television Systems Committee), and the Japanese ISDB (Integrated Digital Services Broadcasting) [21][22][23]. The digital TV receiver is a device responsible for decoding the received video signal, and for manipulating the aggregated information, offering it to the viewer as an electronic program guide, for example. It also makes possible the execution of applications received together with the video. This receiver, known as set-top box, can be seen as a computer adapted for the needs of the television environment, having a processor, memory, operational system, etc. It also runs a middleware, which is responsible for abstracting specific characteristics of each receiver, allowing the same application to be executed on set-top boxes made by different manufactures. Applications for Digital TV should be, though, portable and independent of platform [23]. A digital TV System standard also defines the middleware to be used, and most of the defined middleware available nowadays, such as the DVB- MHP (Multimedia Home Platform) and the ATSC- ACAP (Advanced Common Application Platform), chooses Java as part of the solution for the execution of applications on the receivers. Sun released the Java TV API to offer specific resources for the television environment. Beyond Java and correlated API (of graphic elements, for example), those middleware may include support for declarative languages (such as XHTML) and to scripts (like ECMAScript). The Java applications executed on the receivers are called Xlets [24][23]. To allow the execution of MHP applications with other platforms of digital TV, the DVB proposed the development of an unified specification for digital TV middleware, called GEM (Globally Executable MHP), including MHP characteristics that were not linked to specific characteristics of DVB receivers. This specification is currently adopted by the Japanese middleware standard (ARIB B.23) and American (ATSC ACAP). Following the same trend of compatibility, ITU (International Telecommunication Union) published a set of ITU-T recommendations: J.200, J.201 and J.202. These recommendations aimed at harmonizing the systems of digital TV at different levels [23]. 2.1.1 Brazilian Digital TV System. On 2005, Brazilian government led the SBTVD (from the Portuguese Sistema Brasileiro de TV Digital Brazilian Digital TV System) Project, which engaged thousands of researchers from various Brazilian universities and research centers. SBTVD activities involved the studying of all parts that compose a Digital TV System and the development of some innovations to fit to the Brazilian social context (requirements defined by the Brazilian government). The objective of the project was to give the government the necessary information to conduct a decision on the Brazilian open terrestrial Digital TV System (known as ISDTV-T, International Standard for Digital Television - Terrestrial). The reference procedural middleware developed for the Brazilian digital TV system - FlexTV [22] - is GEM [21][22] compatible, and carries on many innovations that could also be applied to other countries on Latin America. The Brazilian government is now defining the ISDTV-T standard, and its middleware choice is Ginga, the combination of the

reference procedural and declarative middlewares: FlexTV [22] and MAESTRO [28] respectively. The requirements that guided the specification of the Brazilian Digital TV middleware were mostly based on some particularities of the country s social context, a context that most Latin American countries share. Only 32.1 million people have access to the internet, which represents 21% of the Brazilian population Brazilian government then defined that Digital TV should be a tool for digital inclusion, since that TV is present on 91% of the Brazilian households. Ginga s innovative functionalities allow the development of advanced applications, exploring the integration with other devices. Brazil will have, according to the Communications Minister, 80 million Digital TV receivers by 2017 (the deadline established by the government for the total transition to the Digital model). Brazilian government is also putting some effort on expanding Ginga s reach to all Latin American countries. 2.2 The Digital TV Transmission System MPEG-2 is the set of standards and definitions concerning the codification and compression of audio and video, published by ISO/IEC as the international standard 13818. It is currently the most commonly adopted standard for transmission of video and data in digital TV systems [7]. Among the components defined by the MPEG-2's transmission process, we can highlight the Elementary Stream (ES). The Elementary Stream can be found in many forms, such as: Digital Control Data, Digital Video, Digital Audio and Digital Data. When dealing with audio and video, these data can be organized to represent fundamental codification units. MPEG-2 Transport Stream (MPEG-2 TS) is a simple form of packetizing and multiplexing video, audio and application data to be transmitted over different kinds of networks (such as terrestrial, cable or satellite). A MPEG-2 TS packet has 188 bytes, having a 4 bytes header and a 184 bytes payload for data. The header has a 13 bits field acting as the Packet Identifier (PID). The PID is used to identify elementary streams of a program in a MPEG-2 TS. The signaling tables found on MPEG-2 specifications contain the description of the elementary streams that will compose a TV program, and also the description of the program itself. 2.2.1 DSM-CC. The Digital Storage Media Command and Control (DSM-CC) specification [13] is a set of protocols supplying control operations and functions to the management of bit streams discussed on standards ISO/IEC 11172 (MPEG-1) and ISO/IEC 13818 (MPEG-2) [13]. The DSM-CC supports data transmission using MPEG-2, time codes for MPEG-2 video and broadcast file systems. 2.2.2 Data Carousel. Data carousel is a DSM-CC transport mechanism [15], allowing a server to transmit a large volume of data to a set of receivers, cyclically repeating the transmission of its content. The data contained on the carousel are logically divided onto modules, which are divided on blocks with the same size (the last block can be smaller than the rest). The division by modules eases the process of broadcast transmission [15]. If an application on the receiver wishes to access a certain module of the data carousel, it has to wait until the next data retransmission. The quantity of blocks in a module depends on the size of the module and on the maximum size of each block's payload [15]. It is possible to dynamically update the carousel that is being transmitted, adding, removing or altering its files, only by creating a new version of the module carrying the files to be updated. 2.2.3 Object Carousel. An object carousel belongs to the DSM-CC class and allows the transmission of a structured group of objects on a DSM-CC data carousel, since that, data transmitted on data carousel have no specific meaning. To transmit data in a structured form, the object carousel uses the BIOP (Broadcast Inter-ORB Protocol) protocol, defined by the CORBA model [15]. The object carousel uses objects with the following types: file, directory and stream. Using those types, a carousel can transmit a file system. 2.3 Application Information Table To signal a receiver that applications are available, GEM [23][21][22] defines a service information table named Application Information Table (AIT) [11][7]. The AIT contains all the information the receiver needs to run the application, such as the name, the identifier and the control of the application lifecycle. The control of application life cycle, signaled by the field application_control_code (of AIT), allows the broadcaster to signal the receiver what to do with the application with regard to its life cycle. The application_control_code values for Ginga are "autostart", "present", "destroy", "prefetch", "kill", "remote" and unbound. Applications with "autostart" control code are started automatically when the receiver changes to that TV channel. The applications with "present" control

code are not started automatically, but will be added to the receiver's list of available applications. The user can then choose to start this application by choosing it from that list. Any applications with a "kill" or "destroy" control code will be automatically killed by the receiver. For instance, at the end of a TV program an application associated with this TV program should be killed. The difference between these two control codes is that an application with a "kill" control code will be granted the option to keep running if the application chooses to. Applications with "destroy" control code will always be killed. The "prefetch" control code is only valid for DVB- HTML applications, and indicates that the application should be loaded but not actually started. The "remote" control code indicates that the receiver must switch to a different program in order to start the application. The unbound control defines that the application is not attached to the service (a particular channel, a TV program) and therefore can be run outside a service s context. 3. TVGrid Architecture The following components integrate the TVGrid architecture: a TV station, equipped with a Task Server, a TV Broadcast network (cable, satellite or terrestrial), an interaction channel (an Internet connection, for instance) and finally the Digital TV receivers (set-top boxes). Due to the particular characteristics of the communication channels that link the digital TV system components, and the fact that the receivers are not able to directly communicate with each other, the TVGrid architecture is more suitable to execute applications with a lose communication pattern among the tasks that comprises it or, ideally, applications whose tasks do not communicate at all. These applications are referred in the literature as embarrassingly parallel applications, or bag-of-tasks (BoT) applications. A digital TV network implementing the TVGrid architecture will have a BoT application as input and each task will have to be sent to the receivers, in order to be processed. Figure 1. TVGrid Architecture Overview A proper mechanism is necessary, though, for the task delivery and for the processed result devolution. The mechanism has to be adapted to the characteristics commonly found on digital TV networks. TVGrid architecture is proposed to be used on Digital TV Systems using a GEM [11] compliant middleware. The TVGrid's Task Server has to be incorporated to the transmission schema on the TV Station, in a way that the tasks can be multiplexed to the video stream sent to the receivers. Since the task transmission is done through broadcast, somehow each receptor has to choose a task among all available to process. On the TVGrid architecture, the task server gives each task to be broadcasted a unique id (an index), and the set of ids is used to compose the file system to be multiplexed with the video. Each task will be represented by a file on an object carrousel. An autostart application, which is called on the TVGrid architecture a trigger application, will be sent in a different object carousel with the AIT application_control_code field value set to "autostart". The trigger application will carry all available indexes of the broadcasted tasks, so the trigger application can choose one of the available tasks randomly. After the random index is chosen, the task data download is requested to the proper data carrousel. The data request is done through methods and definitions that compose the GEM [23][21][22] core. Having the task, the digital TV receiver processes it, and when it is done, sends the result to the TV Station. The operation can be repeated in all receivers that are turned on a particular channel, as long as the TV Station continues sending new tasks in the carousel.

Figure 2. Task delivery to the Digital TV receivers. The TV Station sends the video stream with multiplexed tasks. Receiver runs the trigger ( autostart ) application Xlet (1) and generates a random index from the list with all available tasks on the transmitted object carrousel. The receiver gets the chosen task in order to process it (3). A Digital TV network may combine different types of receivers, by different manufacturers, with different hardware. Also, as previously mentioned, the TV Station has no control over the receiver: the viewer may change the channel (causing the end of the application execution if the application_control_code field value from the AIT is not set for unbound ) or turn off the receiver at any time. To solve all tasks, on such an environment, redundancy is necessary and important, but TVGrid's can have a better performance if the task scheduling is optimized. To distribute the tasks the Object Carousel is used multiplexed with the video. The data transmission rate may vary based on the video being streamed, so, transmitting all tasks in a single carousel is not the best choice, since depending on the size of each task and the number of tasks, it may take too long for the carousel to be transmitted and since the environment provides no control over the state of each processor, we cannot rely only on redundancy to state that each task will have an equal probability of being processed. The carousel will then have a fixed number of slots, to be filled with tasks that are stored at a bag in the TV Station. The number of slots will depend on the average size of the tasks on the redundancy required and on the average time a viewer stays tuned to the particular channel or to the particular program being transmitted (that roughly defines how many tasks a viewer processes in average). Each time a carousel is being mounted to be transmitted, the slots are filled with random tasks taken from the bag of tasks. The trigger application carries the indexes of the slots, choosing a random slot to pick a task and process it. The slots may carry different tasks for each carousel transmission. When the TV Station receives the result of the processing of a particular task, then that task is removed from the bag of tasks, and is never transmitted again. To improve performance, particularly when the output of tasks is large, the results can be communicated in two steps. In the first step it is send simply a signal that informs that the task has been processed, therefore allowing the immediate removal of the task from the bag of tasks; then, the actual result is transmitted to the TV Station. The application execution finishes when the bag of tasks is empty. Notice that when there are more slots than tasks remaining to be executed the same task may appear several times in the carousel, increasing the redundancy level and the probability of completing that task. In the above discussion we considered that the application is broadcasted in a particular channel. In some cases a TV Station may transmit the same application in several channels at the same time. Having multiple channels to distribute tasks obviously improves the data transmission rate, but we can explore this even more, optimizing what is being transmitted on each channel. Since we are dealing with channels with different programs, the average time a viewer stays tuned to it also changes. So, we can have Object Carousels mounted with different slots numbers, having the slots being fed with tasks by the same bag of tasks. Each channel's carousel will have a particular trigger application with the indexes of the slots of tasks that are coming along. 6. Conclusion The greatest known computational grid [27] possesses approximately 20,000 available CPUs for processing. Other globally spread grids, like OurGrid [18], still possesses less CPU in labs around the world, whose idle capacity varies over time. The use of digital TV infrastructure can scale this value to millions of CPUs. In events or programs of great audience [26] it is easy to get millions of TV receivers tuned in the same channel with idle processing. The existent approaches which brings distributed computing to Digital TV domain, like GridCast [16] and Share it! [17] do not take advantage of the receivers idle cycles, limiting their scope to content sharing. To fill this gap, we proposed an architecture for opportunistic computing on Digital TV Networks, showing how to build a grid by using the existent technologies employed in the TV standards.

This model should be generalized on future works, in order to better reflect all parameters found on digital TV networks. 7. References [1] BATISTA, C.E.C.F., SOUZA FILHO, G. L. de, Sistema para Execução de Aplicações Paralelizadas utilizando uma Grade de Aparelhos Receptores de Redes de Televisão (System for the Execution of Parallelized Applications using a Grid formed by a Network of TV Receivers). Brazilian Utility Model Patent MMU8600875-7, 2006. [2] FOX, B.. Digital TV Rollout IEEE Spectrum, Vol. 38, No. 2, Feb. 2002, pp. 65-67. [3] Apple Computer Inc. Apple - QuickTime - Tehnologies - H.264. Available at http://www.apple.com/quicktime/technologies/h264/. Access on November, 2006. [4] YAMADA, F. et al, Sistema de TV Digital (Digital TV System). In Revista Mackenzie de Engenharia e Computação No. 5. Editora Mackenzie, São Paulo, 2004. [5] DUARTE, Alexandre, et al. GridUnit: Software Testing on the Grid. Proceedings of the 28th International Conference on Software Engineering (ICSE 2006). May, 2006. [6] WIEGAND, T., et al. Overview of the H.264/AVC Video Coding Standard. In IEEE Transactions on Circuits and Systems for Video Technology, Vol. 13, No. 7, July 2003. [7] MORRIS, S., SMITH-CHAIGNEAU, A. Interactive TV Standards A Guide to MHP, OCAP and JavaTV. ISBN-13 978-0-240-80666-2. Elsevier, Focal Press, 2005. [8] SETI@HOME Seti@Home. Available at http://setiathome.ssl.berkeley.edu/. Access on October, 2006. [9] FREEMAN, J., LESSITER, J. Using Attitude Based Segmentation to Better Understand Viewers Usability Issues with Digital and Interactive TV. Proceedings of the 1st European Conference on Interactive Television: from Viewers to Actors? pp.19--27. January, 2004. [10] DVB. Digital Video Broadcasting Italy. Available at http://www.dvb.org/about_dvb/dvb_worldwide/italy/index.x ml. Access on October, 2006. [11] ETSI. ETSI. TS 102 819: Globally Executable MHP (GEM). ETSI Standard, May, 2004. Available at http://webapp.etsi.org/workprogram/report_workitem.asp? WKI_ID=19737. Access on July, 2006. [12] ISO/IEC 13818-1. Information technology Generic coding of moving pictures and associated audio information: Part 1: Systems, 2000. [13] ISO/IEC TR 13818-6. Information technology Generic coding of moving pictures and associated audio information Part 6: Extensions for DSM-CC, 1998. [14] ISO/IEC 13818-10. Information technology Generic coding of moving pictures and associated audio information Part 10: Conformance extensions for Digital Storage Media Command and Control (DSM-CC), 1999. [15] ETSI TR 101 202 V1.2.1. Digital Video Broadcasting (DVB), Implementation guidelines for Data Broadcasting. 01-2003. Technical Report. [16] HARMER T. J. et al Gridcast A Grid and Web Service Broadcast Infrastructure, Proceedings of IEEE International Conference on Services Computing, 2005. [17] TURCAN, E., STROMBACK, L., MORRIS, J., "Share it! by bringing P2P into the TV-domain". In Peer-to- Peer Computing, 2003. (P2P 2003). In Third International Conference on P2P Proceedings. 2003. [18] CIRNE FILHO, W. et al, "Labs of the World, Unite!!!". Journal Of Grid Computing, Holland, p. 1-17, 2006. [19] Agência Brasil. "TV digital deve aumentar em 80 milhões número de aparelhos no país, diz ministro (Digital TV shall increase number of TV sets to 80 millions on the country (Brazil), says minister)". Available at http://www.agenciabrasil.gov.br/noticias/2006/07/06/materia. 2006-07-06.4998754189/view. Access on October, 2006. [20] MAIOR, M. S., TV interativa e seus caminhos (Interactive TV and its trends). Msc. Thesis, UNICAMP, Campinas, 2002. [21] LEITE, L. E. C., SOUZA FILHO, G. L. de. Recomendações para o Modelo de Referência: MIDDLEWARE (RFP 04/2004) FlexTV (Recommendations for the reference model: Middleware FlexTV. Available at http://www.mc.gov.br/sbtvd/pdf/middleware/recomendac oes_minicom.pdf. Access on June, 2006. [22] LEITE, L. E. C., et al. "FlexTV Uma Proposta de Arquitetura de Middleware para o Sistema Brasileiro de TV Digital (FlexTV a Middleware Architecture Proposal for the Brazilian Digital TV System)". In Revista de Engenharia de Computação e Sistemas Digitais, v. 2, pp 29-50, 2005. [23] BATISTA, C. E. C. F., "TV Digital - Java na sala de estar (Digital TV Java on your living room)". In Revista MundoJava, No. 17. 2006. [24] Sun JavaTV. Java Technology in Digital TV. Available at: http://java.sun.com/products/javatv/. Access on June, 2006. [25] Sunflow. "Sunflow, Global Illumination Rendering System". Available at http://sunflow.sourceforge.net/. Access in May, 2006. [26] Rede Globo. Cobras & Lagartos- Compra Isolada Mercado Nacional - Direção Geral de Comercialização (Cobras & Lagartos Isolated Buy National Market Commercialization General Direction). Available at http://comercial.redeglobo.com.br/programacao_novela/cobr as_nacional.php. Access on June 2006. [27] EGEE Enabling Grids for E-sciencE Available at http://www.eu-egee.org/. Access on January, 2007. [28] SOARES, L. F. G.. MAESTRO: The Declarative Middleware Proposal for the SBTVD. In: 4th European Interactive TV Conference, 2006, Athens. Proceedings of the 4th European Interactive TV Conference, 2006.