Modelo dinâmico de busca de serviços convergentes em um cenário de TV digital móvel

Transcrição

1 Modelo dinâmico de busca de serviços convergentes em um cenário de TV digital móvel Leonardo S. Cunha 1, Carlos A. G. Ferraz 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) {lsc,cagf}@cin.ufpe.br Abstract. The convergence between Digital TV and wireless technologies, such as cellular networks, created a dynamic environment of services. This article describes a middleware for mobile devices that enables search, access and execution of pervasive services, independent from the network technology. The architecture of the middleware is detailed and a case of study of convergent applications in a mobile TV scenario is presented, Resumo. A convergência entre TV digital e tecnologias sem fio, como a rede celular, criou um ambiente dinâmico de serviços. Este artigo apresenta um middleware para dispositivos móveis que possibilita a busca, o acesso e a execução de serviços pervasivos, independente da tecnologia de rede. A arquitetura do middleware é detalhada e, por fim, é demonstrado um estudo de caso com aplicações convergentes em um cenário de TV digital móvel. 1. Introdução A atual revolução tecnológica já está acontecendo e é um fenômeno denominado convergência digital. Impulsionado pelo desenvolvimento da computação pervasiva, conceito introduzido por Mark Weiser [Weiser 91], dos dispositivos móveis e da comunicação multimídia, este processo está mudando a forma como cada um de nós interage com o ambiente através da tecnologia, criando uma nova perspectiva de quando, como e onde as informações são disponibilizadas e acessadas. Cada vez mais os usuários estão recebendo informações, sob a forma de dados e aplicações, de diversas fontes. Os dispositivos móveis atuais têm acesso simultâneo a diversas redes, como por exemplo, Wi-Fi (802.11), Bluetooth, a rede celular (GPRS/UMTS) e, mais recentemente, a rede de TV digital móvel, ex. Digital Vídeo Broadcasting - Handheld (DVB-H) [DVB]. Os diferentes protocolos de comunicação nas diferentes redes dificultam o desenvolvimento de aplicações e, consequentemente, também a experiência do usuário que precisa ter ciência das tecnologias envolvidas nas conexões dessas redes. Falta, portanto, um mecanismo para auxiliar a implantação e a busca de serviços convergentes ativos, independente do meio físico de comunicação utilizado. Visando suprir estas dificuldades, este trabalho apresenta um middleware para facilitar a criação de aplicações neste cenário convergente. Este middleware, através de uma API, provê mecanismos para facilitar a descoberta e o acesso aos serviços ativos nas diversas redes (DVB-H, GPRS/UMTS, Wi-Fi) do dispositivo, facilitando o desenvolvimento de aplicações que acessam serviços disponibilizados em diversas redes

2 no mesmo instante. Portanto, o foco desta proposta está em antecipar os requisitos desta nova classe de aplicações, explorando o uso das várias redes para aumentar a diversidade, a integração e a disponibilidade de serviços neste ambiente convergente. O cenário motivador para o trabalho proposto é a rede híbrida do sistema de TV digital móvel, pois, esta inclui, além da rede de TV, a rede de telefonia celular e possivelmente acesso a intranets e hotspots, através de conexões sem fio, como Wi-Fi. Além disto, o sistema de TV digital é inerentemente baseado em redes colaborativas, pois o conteúdo de TV é transmitido através de um canal broadcast e existe pelo menos uma outra rede unicast para o canal de interatividade [Arjona 05], no qual ocorre a comunicação do receptor com o provedor de serviços. É interessante enfatizar que a tecnologia de TV digital móvel não irá substituir as outras formas de comunicação de dados (unicast), mas, sim, complementá-las. A vantagem de utilizar a rede de TV digital é o mecanismo de broadcast, que permite uma alta taxa transmissão para um número ilimitado de dispositivos, com custo reduzido para os usuários finais, ao contrário do que acontece com as tecnologias atuais de transmissão unicast (GPRS, Wi-Fi), que, por outro lado, são redes bidirecionais que possibilitam interatividade e conteúdo personalizado. Entretanto, a rede broadcast não deve se limitar ao formato tradicional, transmitindo apenas áudio e vídeo (A/V), mas, sim, como uma rede capaz de transmitir dados e serviços em uma alta taxa de transmissão para um grande número de usuários. Este artigo está organizado da seguinte forma: a seção 2 descreve os trabalhos relacionados. A seção 3 apresenta a proposta geral deste trabalho. A seção 4 detalha a arquitetura do middleware, focando nos mecanismos de busca de serviços. Para estudo de caso, o cenário motivador utilizando o middleware é apresentado na seção 5. Por fim, na seção 6 são apresentados os resultados e as futuras direções deste trabalho. 2. Trabalhos Relacionados A convergência digital focada neste artigo abrange dispositivos móveis multifuncionais com acesso simultâneo à rede broadcast de TV digital móvel, à rede de transmissão celular (GPRS e UMTS) e a redes Wi-Fi (802.11). Este desenvolvimento tecnológico criou as condições necessárias para a realização da visão de [Weiser 91] em nosso dia a dia, como argumenta [Yam 04]. As aplicações interativas deste novo contexto podem se beneficiar destas múltiplas conexões para melhorar a robustez, a disponibilidade e para criar uma nova classe de aplicações que não seriam possíveis acessando cada rede isoladamente. Este cenário convergente esta exemplificado na Figura 1, que tem um dispositivo móvel com acesso a três redes distintas: a rede de TV digital móvel, a rede celular e redes hotspot. Em cada uma dessas redes é possível acessar serviços disponíveis nas intranets ou, através de um gateway, na Internet. Os provedores de serviço precisam de mecanismos para divulgar e transmitir os serviços, enquanto os usuários querem uma forma simples de achar e executar estas funcionalidades disponibilizadas nas diferentes redes.

3 Figura 1. Cenário convergente Por causa do dinamismo dos sistemas pervasivos, o conjunto de serviços ativos muda constantemente no ambiente de execução, gerando a necessidade de mecanismos transparentes de localização e acesso das aplicações distribuídas. Várias arquiteturas têm sido propostas para o problema de descoberta de serviços em ambientes pervasivos, dentre as quais se pode citar: Service Location Protocol [SLP], Jini [JINI] e Universal Plug and Play [UPnP]. O protocolo que uniformiza o transporte destes serviços entre redes de camadas físicas diferentes é o IP (Internet Protocol), que tem se tornado padrão desde o surgimento da Internet. Os padrões de TV digital móvel, através do IP Datacasting [IPDC][Staffans 04], e o futuro das redes celulares (4G) já adotaram o IP como protocolo para transmissão de dados. De acordo com [Krishna], esta convergência em serviços baseados em IP irá substituir toda tecnologia central atual por uma única tecnologia de rede universal baseada em IP. A seguinte declaração, exposta no site do DVB [DVB], anuncia o interesse desta entidade na convergência entre a TV digital e a Internet: O escopo do DVB se estendeu para criar um ambiente de conteúdos que combinem a estabilidade e a interoperabilidade do mundo de mídia com o vigor, inovação e multiplicidade do mundo da Internet.. Arquiteturas e ferramentas foram desenvolvidas para dar suporte a esse cenário convergente em INSTINCT [Dosch and Owens, 2004] baseado em trabalhos anteriores, como CISMUNDOS e CONFLUENT [Berge et. al., 2003]. O INSTINCT tem por objetivo fornecer blocos estruturais a fim de propiciar a integração das tecnologias sem fio com a TV digital nos dispositivos móveis. A rede celular é usada com canal auxiliar a fim de prover interatividade para os serviços de TV digital. Este artigo pretende estender o trabalho realizado pelo INSTINCT, melhorando a integração das tecnologias sem fio com a TV digital nos dispositivos móveis, e possibilitando acesso uniforme aos serviços providos pela plataforma convergente, independente dos protocolos de transmissão e da tecnologia de rede (unicast ou broadcast). Os padrões de TV digital móvel, Digital Vídeo Broadcasting (DVB-H), Digital Multimedia Broadcasting (DMB), Integrated Services Digital Broadcasting (ISDB-T) estão em fase de padronização em todo o mundo e têm diferenças significantes com relação à TV digital terrestre. A qualidade da recepção do sinal, a economia de energia da bateria, a pouca capacidade de processamento e a menor resolução da tela estão entre

4 os fatores específicos que afetam a transmissão de conteúdo broadcast para dispositivos móveis. Para poder usar a TV digital, o usuário precisa saber que serviços estão disponíveis no momento e como acessá-los. Isto pode ser feito através de uma aplicação, semelhante a um guia de programação de TV, conhecida como ESG (Electronic Service Guide) que contém descrições sobre os serviços disponíveis e como acessá-los. O ESG é uma aplicação central para TV digital, através da qual o usuário pode selecionar, além dos programas tradicionais de TV, os serviços que estão disponíveis, como uma aplicação de jogo ou uma página HTML da Internet, por exemplo. Existem diversos órgãos padronizando diferentes formatos de descrição e transmissão de ESG. Esta variedade de padrões dificulta a interoperabilidade entre sistemas e aplicações. Dentre os padrões abertos existentes, pode-se citar: Open Air Interface (OAI), DVB-H e TV Anytime (TVA). Como mostrado na Figura 2, o padrão DVB-H separa as operações do ESG em três grupos [DVB-H]: ESG bootstrap: operações do terminal para descobrir os ESG disponíveis na rede e como acessá-los. ESG acquisition: operações do terminal para acessar e processar as informações dos ESG disponíveis, após um longo período sem conexão. ESG update: operações do terminal para atualizar o ESG gravado no terminal com as últimas versões disponíveis. Esta atualização pode ser feita através de fragmentos, não sendo necessário atualizar o ESG completo. Figura 2. Operações de ESG O projeto TV Anytime (TVA) especificou os requisitos de um sistema de Personal Vídeo Recorder (PVR) e sob este ponto de vista desenvolveu as especificações para a descoberta e o acesso a serviços multimídias. Nas especificações do TVA já existem mecanismos para transmitir meta dados por redes unidirecionais e bidirecionais, portanto, é possível acessar o ESG de diferentes redes, inclusive através da Internet, como proposto por [Leban 03].

5 Figura 3. Arquitetura TVA O principal diferencial do TV Anytime para os outros padrões é o seu mecanismo de referência de conteúdo: o Content Referencing Identification (CRID). O CRID separa a referência ao conteúdo das informações de acesso ao conteúdo. O formato do CRID é CRID://<authority>/<data>, onde authority é uma entidade certificada a prover conteúdo e data é o endereço de acesso do conteúdo, por exemplo, CRID://company.com/foobar (foobar é o conteúdo e company.com é a autoridade provedora do conteúdo). O mecanismo de busca de conteúdo multimídia do TVA (Content selection) retorna o resultado com os CRIDs que satisfazem a consulta, como mostra a Figura 3, Com a referência do conteudo, CRID, é possível, através do Location resolving, recuperar o endereço de acesso, no formato de locator. O padrão locator, que está definido no TVA, tem formato: protocolo://ip@hora, por exemplo, dvb://123.5ac.3be;3e45@ t12:00: p02:10. Outros possíveis protocolos são: http, ftp, etc. Os conteúdos disponíveis podem ser de dois tipos: sob demanda, que podem ser acessados a qualquer instante, ou agendados, que tem um horário pré-determinado para ser acessado.. O mecanismo de busca deste trabalho está baseado no padrão do TV Anytime e propõe extensões a este formato para tratar a descrição, o acesso e a execução de serviços. As extensões propostas neste trabalho vão manter a compatibilidade com as versões anteriores dos padrões de ESG de modo a funcionar corretamente com dispositivos que não tenham suporte ao middleware proposto. 3. Proposta de Middleware Este trabalho define um middleware para facilitar a descoberta dinâmica de serviços IP convergentes, oferecendo mecanismos de busca e resolução de nomes. A principal motivação desta especificação consiste em mecanismos para desenvolvimento de serviços que não dependam da rede de onde serão executados, separando a descrição e a busca do serviço da implementação e execução do mesmo.

6 A arquitetura completa do middleware está detalhada nas próximas seções, pois além dos mecanismos de descoberta e acesso a serviços, que serão o foco neste artigo, o middleware proposto também possui um componente de monitoramento de rede, de adaptação e um gerenciador de serviços ativos Arquitetura baseada em serviços Nesta proposta foi adotada a abstração de serviço por causa do amadurecimento das ferramentas e dos modelos de desenvolvimento baseado em serviços, conhecido como SOA (Service Oriented Architecture) [Papa et al 03], que tem vantagens como transparência de localização de serviço e padronização de acesso. A abstração de serviço é genérica e flexível o suficiente para cobrir não somente funcionalidades multimídia, como também, acesso a informações e aplicações no PC ou na Internet, como por exemplo, um serviço de download de arquivo ou de streaming de A/V. É importante ressaltar a diferença do acesso de serviços das redes broadcast e unicast. No caso das redes unicast, os serviços são acessados remotamente de um servidor, o qual é um provedor de serviços. Estes são os serviços pull. Por outro lado, no caso das redes broadcast, os serviços estão sendo transmitidos a todo o momento, através de um carrossel de dados, para o dispositivo e são acessados localmente sem que haja necessidade do cliente requisitar o serviço desejado, o que caracteriza os serviços push. Além dos serviços push e pull, há também os serviços local, que são disponibilizados somente para acesso na máquina local. Os serviços local podem ser úteis para fazer o download de um serviço remoto e executá-lo localmente, por exemplo. Portanto, propõe-se a seguinte diferenciação entre os serviços: Serviços local: estão disponíveis localmente na máquina e têm prioridade por estarem implantados no mesmo domínio de execução do cliente; Serviços pull: têm a vantagem de estarem sendo transmitidos a taxas altas na rede broadcast; Serviços push: são os serviços que têm a menor preferência, por serem acessados remotamente, mas, por outro lado, existem mais alternativas de serviços disponíveis, tanto nas intranets quanto na Internet. Para um serviço ser implantado em um servidor, é preciso definir o nível de visibilidade do serviço para o mecanismo de busca: Indisponível: não pode ser descoberto por ninguém. Esta indisponível; Privado: pode ser visto somente na máquina local onde o serviço está implantado; Intranet: pode ser descoberto por pessoas com acesso à intranet (casa, trabalho). Possui um mecanismo mais específico de descoberta; Público: pode ser visto e acessado por qualquer entidade. Um bom mecanismo de busca para esta classificação seria um mecanismo de páginas amarelas, como o serviço de Trader de CORBA ou Universal, Description, Discovery and Integration (UDDI).

7 As redes que provêem serviços podem ser constituídas de várias subnets e provedores de conteúdo. A Internet tem todas estas propriedades, mas existem algumas desvantagens de utilizar a Internet como uma rede provedora de serviços. Os requisitos de largura de banda e Quality of Service (QoS) não podem ser controlados para satisfazer a demanda dos clientes. Por isso, ao invés de utilizar a Internet, utilizaremos intranets por oferecerem melhor capacidade e controle para serem usadas como rede provedora de serviços Arquitetura do middleware A arquitetura do middleware desenvolvido, Figura 1, está baseada em Task Computing [Song et al 2004], um framework orientado a usuário baseado em camadas: A camada de aplicações representa os dispositivos e as aplicações clientes que executam no dispositivo. A camada de middleware provê componentes para a descoberta, execução, monitoramento, gerenciamento e publicação de serviços. A camada de serviços contém descrições dos serviços e referências para suas implementações. Figura 4. Arquitetura do Middleware O Middleware é composto de seis serviços que executam no cliente (Service Manager, Service Discovery, Service Execution, Adaptation Engine e Network Monitor), além de um serviço do lado servidor, Service Provider. O Network Monitor monitora as interfaces de redes do dispositivo (DVB-H, Wi- Fi, Bluetooth, 3G) verificando quais estão com conexões ativas a fim de identificar todos os serviços disponíveis em um determinado instante. Quando uma conexão degrada, o sistema é notificado através do mecanismo de monitoramento, possibilitando a adaptação de determinado serviço por não propiciar a qualidade de serviço (QoS) desejada.

8 Além de monitorar a rede, o middleware também provê uma API de acesso a um mecanismo uniforme de descoberta, descrição e execução dos serviços disponíveis. Os serviços encontrados podem ser provenientes de qualquer rede, ou podem simplesmente estar armazenados no sistema de arquivos local do dispositivo móvel, sendo acessados através de uma API pelas aplicações cliente, como a aplicação de ESG (Electronic Service Guide), por exemplo. A camada de Serviços agrega funcionalidades como as descrições dos serviços e são a interface para acessar a implementação desejada do serviço. A descrição dos serviços contém informações de alto nível, como nome do serviço, ícone, descrição textual e parâmetros de entrada e saída. Além dessas informações, a descrição do serviço tem uma ou mais referências para implementações do serviço, no formato locator do TVA. Para executar os serviços, o middleware contém um gerenciador de serviços que é responsável por iniciar, gerenciar o ciclo de vida, e finalizar o serviço. Funções semelhantes de um gerenciador de aplicações do middleware de TV digital, como especificado por [MHP] e [JSR272]. Executar o serviço pode ser iniciar uma aplicação, abrir um HTML, fazer download de um arquivo ou tocar um áudio/vídeo (A/V). O mecanismo de descoberta de serviços do middleware é realizado por dois componentes: Service Discovery e Service Provider. Como mostrado na Figura 5, cada rede tem seu provedor de ESG que registra os serviços que estão ativos no momento. O Service Discovery faz consultas ao provedor de serviços (Service Provider), o qual retorna como resultado uma lista de descrições de servíços (Service Description) compatíveis com o formato do padrão TV Anytime. Figura 5. Middleware distribuído nas diferentes redes Com a descrição do serviço, podem-se acessar os respectivos locators. A partir do locator é possível executar o serviço acessando o mecanismo de execução do middleware. É possível que haja mais de um locator para uma mesma descrição de serviço, como também, um mesmo locator pode estar presente em mais de uma descrição. Desta forma, há uma clara separação entre descrições e implementações de serviços.

9 Caso haja mais de um locator para o mesmo serviço, é preciso escolher um para executar. Isto pode ser feito diretamente pelo usuário ou através do mecanismo adaptação do middleware (Adpatation Engine), levando em consideração o contexto, as preferências do usuário e a classificação de serviços (local, push e pull) proposta acima. Neste middleware há uma completa separação entre a descrição do serviço e sua implementação, enquanto que a busca e o acesso aos serviços é uniforme. Esta separação dá flexibilidade a cenários pervasivos, como por exemplo: para salvar um serviço que está sendo transmitido pela rede broadcast localmente na máquina é preciso somente adicionar o locator para o sistema de arquivos local na descrição do serviço e pode-se continuar usando a mesma descrição, ficando transparente para o usuário a fonte provedora do serviço. 4. Estudo de caso: MediaPort Como prova de conceito do trabalho proposto, foi desenvolvido um portal de serviços multimídia: o MediaPort, que disponibiliza os serviços encontrados em todas as redes para o usuário. Esta aplicação utiliza o serviço de monitoramento do middleware para manter a lista de serviços atualizada sempre que ocorre uma conexão ou desconexão de rede. Através do MediaPort é possível acessar serviços multimídias em diferentes formas (aplicações, A/V, HTML) e de maneira uniforme, independente da rede provedora. A fim de disponibilizar um serviço no MediaPort, é preciso implantar o serviço em um servidor ou no carrossel de dados, no caso de TV digital, e registrar o serviço como público no Service Provider da respectiva rede MediaPort usando o middleware Nesta seção será apresentado o personagem João da Silva, jovem profissional que gosta e tem acesso às novidades tecnológicas. As funcionalidades providas pelo middleware e aplicações-usuário, conforme ilustrado na Figura 4 na Camada de Aplicações, irão ajudá-lo a concretizar um cenário motivador da convergência digital: João da Silva acorda e no ônibus, a caminho do trabalho, acessa o MediaPort e lê as noticias do dia no seu dispositivo móvel. o O serviço de noticias tem canais de TV com o noticiário do dia e link para acesso a conteúdo personalizado para os interesses de João (esta aplicação de notícias mistura conteúdo vindo da rede celular e da rede de TV); Ao chegar no trabalho o ESG do dispositivo se atualiza automaticamente com as aplicações da intranet do trabalho, disponibilizando serviços de agenda de ramais e Voice Over IP (VoIP). o O MediaPort detecta automaticamente a presença de uma rede local conhecida e descobre os serviços disponíveis atualizando sua interface gráfica; Durante a tarde, João utiliza o dispositivo móvel para ouvir os canais de rádio transmitidos pela rede de TV digital e vê videoclipes, votando nas suas músicas favoritas favorito.

10 o O serviço de rádio oferecido proporciona interatividade para o usuário, através do canal de interatividade, usando as redes de TV digital e telecomunicações simultaneamente; À noite, João vai para o aeroporto embarcar rumo a uma viagem para visitar os parentes. Na espera para o embarque, ele pode acompanhar a copa do mundo, assistindo aos jogos, com acesso a estatísticas e tabelas. o Neste exemplo todos os dados acessados foram transmitidos via rede de TV digital móvel Ao chegar no destino, João percebe que os canais de TV do seu celular estão atualizados com a programação local e através da rede Wi-Fi do aeroporto aparecem serviços novos no MediaPort, como mapa e sugestões de locais para ir. o A aplicação MediaPort é notificado da presença de uma nova rede de TV digital e descobre os novos canais transmitidos. Os serviços da rede Wi- Fi são descobertos dinamicamente e disponibilizados para o usuário. A concretização deste cenário é facilitada pelo uso dos serviços de middleware apresentados neste trabalho. No diagrama de seqüência mostrado na Figura 6 está detalhado o fluxo de execução sob o ponto de vista do middleware a cada vez que uma rede nova é encontrada no cenário. Figura 6. Diagrama de Seqüência do Cenário Ao ser iniciada pelo usuário, a aplicação, MediaPort, se cadastra como listener para ser notificada de mudanças nas conexões das interfaces de rede através do Network Monitor. Ao identificar uma nova conexão de rede, o Network Monitor notifica todos os listeners, inclusive o Media Portal. Caso haja um provedor de serviços na rede recém conectada, é realizada a operação getservices no Service Discovery para descobrir todos os serviços ativos registrados. A partir desse momento, o terminal já contém as descrições para os serviços da nova rede e, portanto, atualiza e adapta as referências dos serviços disponíveis. A operação getservices do Service Discovery retorna uma lista de Service Description, XML no formato do TVA, através da qual a aplicação MediaPort mostra

11 uma descrição dos serviços descobertos para o usuário. Quando o usuário seleciona um dos serviços disponíveis, o mecanismo de Service Execution é acionado e o serviço se torna ativo, sendo gerenciado através do Service Manager. A fim de executar um serviço descoberto, é preciso especificar o locator do serviço, que define a rede e o IP de acesso para o serviço. A partir do protocolo de transporte especific ado no locator (dvb://, ou ou crid://), o gerenciador de serviços verifica se há suporte no dispositivo e, caso positivo, o conteúdo IP é desencapsulado. Este conteúdo IP é repassado pelo gerenciador de serviços, de acordo com a categorização do serviço consumido, para a aplicação que tenha requisitado a execução do serviço. 5. Conclusões e trabalhos futuros Foram apresentadas as direções do trabalho em andamento no CIn-UFPE para o desenvolvimento de um middleware para suporte a serviços convergentes. A arquitetura deste middleware foi detalhada com foco na descoberta dinâmica de serviços em ambientes convergentes e um cenário de uso foi demonstrado. Com os resultados deste trabalho, as futuras aplicações desenvolvidas para TV digital móvel podem se beneficiar dos serviços disponíveis no mundo da Internet e, ao mesmo tempo, os serviços IP da Internet podem se complementar com os dados providos pela rede broadcast, sob a forma de aplicações, serviços e conteúdo. Esta cooperação, entre diferentes plataformas, com protocolos e serviços comuns, trará oportunidades para criar um ambiente pervasivo para o usuário final, que não seria possível utilizando cada rede separadamente. Possibilitar suporte a outros padrões de ESG, além do TVA, e mecanismos de tradução e conversão entre diferentes padrões da indústria é uma área de interesse deste trabalho. Além disto, estender o cenário do ambiente convergente de tv digital para incluir redes peer-to-peer também é uma das direções de pesquisa da área [Gatis 06]. Por fim, espera-se implantar a aplicação desenvolvida no estudo de caso (MediaPort), utilizando os componentes do middleware desenvolvido, em um ambiente real, através de um laboratório de transmissão de TV digital móvel e um dispositivo com acesso simultâneo a redes Wi-Fi e DVB-H. 6. Referências [Arjona 05] Arjona, A. Internet Protocol Datacasting Transparent Interactivity Using Different Communication Channels. Master Thesis from the Telecommunications Software and Multimedia Laboratory, Helsinki University of Technology, [Berge et al 03] Berg, M., Butterfield, S., Cosmas, J., Casagranda, P., Garrec, D., Guiraudou, M., Martinez, G., Launay, E., Mazieres, B., Milanesio, D. "CISMUNDUS: convergence of digital broadcast and mobile telecommunications", In: Proceedings of the IBC 2003 Conference, Amsterdam, September [Dosch and Owens 04] Dosch, C. and Owens, T. "The Pan European Integrated INSTINCT Project - Making the Convergence of Digital Broadcasting and Mobile Communication a Reality". In: DVB World 2004 International Conference. Dublin, Ireland, March 2004.

12 [DVB] Digital Video Broadcasting. Acessado em Fevereiro de [DVB-H] DVB-H Online, Technical Specifications / IP Datacast DVB-H. Acessado em Março de [Faria et al 06] Faria, G., Henriksson, J. A., Stare, E. and Talmola, P. "DVB-H: Digital Broadcast Services to Handheld Devices". In: Proc. IEEE, vol. 94, no. 1, pp , Jan [Gatis 06] Gatis, I. Um Middleware para Construção de Aplicações de TV Digital Distribuídas baseadas no Modelo P2P. MSc thesis, Centro de Informática da Universidade Federal de Pernambuco, Janeiro [IPDC] IP Datacasting Fórum. Acessado em Fevereiro de [JINI] Jini Specification. Acessado em Dezembro [Krishna] Krishnakumar, G. Challenges in 4G Wireless Communication. [Leban 03] M. Leban. Internet Search for TV Content based on TV Anytime. IEEE EUROCON, [Papa et al 03] Papazoglou, M., and Georgakopoulos, D Service oriented computing. Communications of the ACM 46(10): [SLP] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service location protocol IETF request for comments 2165, June [Song et al 04] Song, Z., Labrou, Y., and Masuoka, R., "Dynamic Service Discovery and Management in Task Computing," pp , MobiQuitous 2004, August 22-26, 2004, Boston, USA. [Staffans 2004] Staffans, L. Internet Protocol Datacasting A Technology Overview. Master Thesis from the Telecommunications Software and Multimedia Laboratory, Helsinki University of Technology, [TVA] TV-Anytime. Página web do forum TV-Anytime. Acessado em Março de [UPnP] UPNP Forum. Acessado em Janeiro [Weiser 91] Weiser, M, Computer for the 21st century. In: Scientific American, 265(3) 1991, [Yam 04] Adenauer Corrêa Yamin. Arquitetura para um Ambiente de Grade Computacional Direcionado às Aplicações Distribuídas, Móveis e Conscientes do Contexto da Computação Pervasiva. PhD thesis, Universidade Federal do Rio Grande do Sul, Junho [MHP] DVB. TS : Multimedia Home Platform (MHP) Specification ETSI Standard, [JSR272] Java Specification Request in Progress: JSR 272: Mobile Broadcast Service API for Handheld Terminals