Modelo dinâmico de busca de serviços convergentes em um

Document Sample
Modelo dinâmico de busca de serviços convergentes em um Powered By Docstoc
					    Modelo dinâmico de busca de serviços convergentes em um
                cenário de TV digital móvel
                       Leonardo S. Cunha1, Carlos A. G. Ferraz1
        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
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.
                             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
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].
                              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@2001-12-07T12:00:00.00+01P02: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.
       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.

3.1. 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).
        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.

3.2. 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.
        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.
        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.

4.1. 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.
           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
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 especificado no locator (dvb://, ou http://, 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, 2005.
[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 2003.
[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.
[DVB] Digital Video Broadcasting. www.dvb.org. Acessado em Fevereiro de 2006.
[DVB-H] DVB-H Online, “Technical Specifications / IP Datacast DVB-H”. www.dvb-
  h-online.org. Acessado em Março de 2006.
[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. 194-
   209, Jan. 2006.
[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 2006.
[IPDC] IP Datacasting Fórum. www.ipdc-forum.org. Acessado em Fevereiro de 2006.
[JINI] Jini Specification. www.sun.com/software/jini/specs. Acessado em Dezembro
   2005.
[Krishna] Krishnakumar, G. “Challenges in 4G Wireless Communication”.
[Leban 03] M. Leban. “Internet Search for TV Content based on TV Anytime.” IEEE
   EUROCON, 2003.
[Papa et al 03] Papazoglou, M., and Georgakopoulos, D. 2003. “Service oriented
   computing”. Communications of the ACM 46(10):25–28.
[SLP] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service location protocol IETF
  request for comments 2165, June 1999.
[Song et al 04] Song, Z., Labrou, Y., and Masuoka, R., "Dynamic Service Discovery
   and Management in Task Computing," pp. 310 - 318, 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, 2004.
[TVA] TV-Anytime. Página web do forum TV-Anytime. www.tv-anytime.org.
  Acessado em Março de 2006.
[UPnP] UPNP Forum. www.upnp.org, Acessado em Janeiro 2006.
[Weiser 91] Weiser, M, “Computer for the 21st century”. In: Scientific American,
  265(3) 1991, 94-104.
[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 2004.
[MHP] DVB. TS 102 812: Multimedia Home Platform (MHP) Specification 1.1.1.
ETSI Standard, 2003. 4.7.1.2
[JSR272] Java Specification Request in Progress: “JSR 272: Mobile Broadcast Service
  API for Handheld Terminals”