METAHEURÍSTICAS APLICADAS À GERAÇÃO DE CARROSSEL NO SISTEMA BRASILEIRO DE TV DIGITAL

Transcrição

1 UNIVERSIDADE FEDERAL DA PARAÍBA CENTRO DE CIÊNCIAS EXATAS E DA NATUREZA DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA METAHEURÍSTICAS APLICADAS À GERAÇÃO DE CARROSSEL NO SISTEMA BRASILEIRO DE TV DIGITAL BRUNO JEFFERSON DE SOUSA PESSOA JOÃO PESSOA-PB Julho-2008

2 UNIVERSIDADE FEDERAL DA PARAÍBA CENTRO DE CIÊNCIAS EXATAS E DA NATUREZA DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA METAHEURÍSTICAS APLICADAS À GERAÇÃO DE CARROSSEL NO SISTEMA BRASILEIRO DE TV DIGITAL BRUNO JEFFERSON DE SOUSA PESSOA JOÃO PESSOA-PB Julho-2008

3 BRUNO JEFFERSON DE SOUSA PESSOA METAHEURÍSTICAS APLICADAS À GERAÇÃO DE CARROSSEL NO SISTEMA BRASILEIRO DE TV DIGITAL DISSERTAÇÃO APRESENTADA AO CENTRO DE CIÊNCIAS EXATAS E DA NATUREZA DA UNIVERSIDADE FEDERAL DA PARAÍBA, COMO REQUISITO PARCIAL PARA OBTENÇÃO DO TÍTULO DE MESTRE EM INFORMÁTICA (SISTEMAS DE COMPUTAÇÃO). Orientador: Prof. Dr. Lucídio dos Anjos Formiga Cabral JOÃO PESSOA-PB Julho-2008

4 P475m Pessoa, Bruno Jefferson de Sousa. Metaheurísticas Aplicadas à Geração de Carrossel no Sistema Brasileiro de TV Digital / Bruno Jefferson de Sousa Pessoa. João Pessoa, p. Orientador: Lucídio dos Anjos Formiga Cabral Dissertação (mestrado) UFPB/CCEN 1. Comunicação Social. 2. TV digital. 3. TV Interativa. 4. Metaheurísticas. UFPB/BC CDU:316.77(043)

5

6 Dedico esta dissertação aos meus pais, Vladimy e Delma, à minha avó Darcira, minha segunda mãe, à minha tia Elza, que tanto lutou pela educação de seus irmãos e sobrinhos, e em especial, à minha namorada, Karinna, pelo carinho, compreensão, companheirismo e dedicação, empregados durante todo o mestrado.

7 Agradecimentos A Deus, por nunca me deixar desistir de lutar pelos meus sonhos, sempre me guiar nas decisões mais importantes da minha vida e ser minha fortaleza nos momentos mais difíceis. Aos meus pais, pela preocupação com a minha educação desde garoto. Aos meus irmãos, Bruna e Breno, pela compreensão e por suportarem conviver comigo durante os períodos mais estressantes do mestrado. À minha namorada, minha linda, meu amor, Karinna Ugulino, por simplesmente existir. Ao meu orientador, Professor Lucídio Cabral, exemplo de educador, de pessoa, de bom caráter. Se tornou muito mais que orientador, um amigo que pretendo conservar durante toda a vida. Ao Professor Guido Lemos, idealizador da minha dissertação e norteador de minha carreira profissional. Destemido e empreendedor, orgulho da Universidade Federal da Paraíba, me espelhei em suas características a fim de ser um profissional diferenciado. Aos amigos que ajudaram, junto comigo, a construir o Laboratório de Aplicações de Vídeo Digital, reconhecido nacionalmente como um centro de excelência em pesquisas sobre TV Digital. Aos amigos que estudaram comigo desde o CEFET-PB e que até hoje conservam um forte laço de amizade. À minha família. Em especial à minha mãe, Delma de Sousa Pessoa. Não existem palavras que possam descrever o que ela representa pra mim.

8 Resumo As aplicações de TV Digital, principais responsáveis pela interatividade em ambientes de TV Interativa, são transmitidas via broadcast juntamente com os fluxos de áudio e vídeo num mecanismo de transmissão cíclica que lembra o giro de um carrossel. Para serem executadas, cada aplicação terá que esperar o tratamento das aplicações em sua frente, com um atraso máximo para recepção igual ao período do carrossel, ou seja, o período de tempo necessário para a transmissão de todas as aplicações, respeitando-se a taxa reservada para a transmissão de dados. Hoje, atrasos como o elucidado, usuais em ambientes de TV Digital, representariam multas exorbitantes segundo o modelo de negócios atual. A fim de solucionar tal problema, foram utilizadas as metaheurísticas GRASP, VND e VNS, que, a partir de um modelo de negócio próprio, objetivaram minimizar o atraso na execução das aplicações em um tempo computacional razoável.

9 Abstract The Digital TV applications, primarily responsible for interactivity in Interactive TV environments, are transmitted via broadcast along with audio and video streams in a transmission mechanism that reminds the cyclical turning of a "carousel". To be executed, each application will have to wait for the processing of applications on its front, with a maximum delay of reception equal to the period of the carousel, that is, the time necessary for the transmission of all applications subject to the rate reserved for data transmission. Today, delays like this, common in Digital TV environments, would represent exorbitant fines according to the current business model. In order to solve this problem, it were used the GRASP, VND and VNS metaheuristics, which, from a own business model, aimed to minimize the delay in the execution of applications in a computational reasonable time.

10 Sumário: 1. Introdução Motivação Objetivos TV Digital Sistemas de TV Digital MPEG-2 Sistemas DSM-CC Aplicações de TV Digital API JavaTV API DAVIC API HAVi API DVB Os Xlets Sistema Brasileiro de TV Digital Apresentação do Problema Modelo de Negócio Proposto Metodologia Modelagem Matemática GVND GRASP VND GVNS Construção Busca Local VNS Resultados Descrição das instâncias Função de avaliação Tempo de Execução Considerações Finais Referências Bibliográficas APÊNDICE A Instância utilizadas no Cenário A... 73

11 APÊNDICE B Instância utilizadas no Cenário B... 77

12 Índice de Figuras Figura 1. Elementos básicos em um Sistema de TV Digital Figura 2. Arquitetura em camadas de um receptor Figura 3. Processo de identificação dos fluxos de áudio e vídeo [15] Figura 4. Arquitetura JavaTV Figura 5. Ciclo de vida de um Xlet Figura 6. Representação da forma de transmissão em carrossel Figura 7. Otimização do atraso no carrossel Figura 8. Contribuição de cada fase na construção das soluções no algoritmo GVND (Cenário A) Figura 9. Contribuição de cada fase na construção das soluções no algoritmo GVND (Cenário B) Figura 10. Contribuição de cada fase na construção das soluções no algoritmo GVNS (Cenário A) Figura 11. Contribuição de cada fase na construção das soluções no algoritmo GVNS (Cenário B) Figura 12. Contribuição, em termos percentuais, de cada fase do algoritmo GVNS quanto ao tempo de execução (Cenário A) Figura 13. Contribuição, em termos percentuais, de cada fase do algoritmo GVNS quanto ao tempo de execução (Cenário B) Figura 14. Gráfico comparativo dos tempos de execução dos algoritmos GVND e GVNS Figura 15. Gráfico comparativo dos tempos de execução dos algoritmos GVND e GVNS... 68

13 Índice de Tabelas Tabela 1. Sequência de execução de um Xlet Tabela 2. Função de avaliação para Solução Atual (Cenário A) Tabela 3. Função de avaliação para Solução Atual (Cenário B) Tabela 4. Detalhamento da contribuição de cada fase no algoritmo GVND (Cenário A) Tabela 5. Detalhamento da contribuição de cada fase no algoritmo GVND (Cenário B) Tabela 6. Detalhamento da contribuição de cada fase no algoritmo GVNS (Cenário A) Tabela 7. Detalhamento da contribuição de cada fase no algoritmo GVNS (Cenário A) Tabela 8. Comparação entre a média dos valores da função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário A) Tabela 9. Comparação entre a média dos valores da função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário B) Tabela 10. Comparação entre os valores das melhores soluções encontradas para a função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário A).. 60 Tabela 11. Comparação entre os valores das melhores soluções encontradas para função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário B) Tabela 12. Resultado do algoritmo GVNS para a instância 12 no Cenário A Tabela 13. Resultado do algoritmo GVNS para a instância 13 no Cenário B Tabela 14. Contribuição de cada fase do algoritmo GVND quanto ao tempo de execução Tabela 15. Contribuição de cada fase do algoritmo GVND quanto ao tempo de execução Tabela 16. Contribuição, em segundos, de cada fase do algoritmo GVNS quanto ao tempo de execução (Cenário A) Tabela 17. Contribuição, em segundos, de cada fase do algoritmo GVNS quanto ao tempo de execução (Cenário B) Tabela 18. Tempos de execução dos algoritmos GVND e GVNS (Cenário A) Tabela 19. Tempos de execução dos algoritmos GVND e GVNS (Cenário B)... 68

14 Tabela 20. Instâncias 1 e Tabela 21. Instâncias 3 e Tabela 22. Instâncias Tabela 23. Instâncias 6 e Tabela 24. Instâncias 8 e Tabela 25. Instâncias Tabela 26. Instâncias 11 e Tabela 27. Instâncias 13 e Tabela 28. Instâncias Tabela 29. Instância 1 e Tabela 30. Instância 3 e Tabela 31. Instância Tabela 32. Instância 6 e Tabela 33. Instância 8 e Tabela 34. Instância Tabela 35. Instância 11 e Tabela 36. Instância 13 e Tabela 37. Instância

15 Lista de Acrônimos e Siglas ACAP Advanced Common Application Platform AIT Application Information Table API Application programming interface ARIB Association of Radio Industries and Businesses ATSC Advanced Television Systems Committee A/V Áudio e Vídeo CAT Conditional Access Table DAVIC Digital Audio Video Council DSM-CC Digital Storage Media Command and Control DVB Digital Video Broadcasting ES Elementary Stream GEM Globally Executable MHP GRASP Greedy Randomized Adaptive Search Procedure HAVi Home Audio Video Interoperability IEC International Electrotechnical Commission ISDB Integrated Services Digital Broadcasting ISO International Organization for Standardization ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector MHP Multimedia Home Platform MPEG Moving Picture Experts Group MPEG2-TS MPEG-2 Transport Stream NIT Network Information Table OCAP OpenCable Application Platform PAT Program Association Table PES Packetised Elementary Stream PID Program Identification PMT Program Map Table SBTVD Sistema Brasileiro de TV Digital SI Service Information TS Transport Stream TVD TV Digital VND Variable Neighborhood Descent VNS Variable Neighborhood Search

16 14 1. Introdução Em meio à implantação da TV Digital no Brasil, muito se fala sobre esse assunto, no entanto muito se confunde também. O sistema de TV Digital não se restringe à transmissão e modulação de sinais digitais, aliás, o que fará mudar a forma como se assiste televisão não diz respeito a esse aspecto, e sim à interatividade. Por meio dela os telespectadores poderão interagir diretamente com a programação das emissoras de TV ao enviarem informações através de um canal de retorno, o qual pode ser a telefonia convencional ou mesmo a transmissão terrestre. Esse novo mecanismo, que promete revolucionar a forma de assistir televisão, tornando o telespectador cada vez menos passivo e com a capacidade de interferir não só na programação televisiva, como também na troca de informações com a emissora, se origina da possibilidade da transmissão de dados, oriunda do modelo digital de transmissão. Sendo assim, programas de computador poderão ser transmitidos juntamente com os fluxos de áudio e vídeo, recepcionados e executados pelos set-top boxes ou terminais de acesso computadores com desempenho limitado, que além de converterem para analógico o sinal digital transmitido, também são responsáveis pela execução das aplicações no ambiente de TV Digital. Então, da mesma forma que um usuário de computador interage com o mesmo, o telespectador poderá interagir com o set-top box e com a emissora que transmite as aplicações. Para dar suporte à interatividade, os padrões de TV Digital existentes desenvolveram uma camada de software capaz de abstrair os detalhes de hardware dos terminais de acesso, proporcionando aos programadores de aplicações de TV Digital ou aplicações interativas (como são chamadas as aplicações que serão executadas nos settop boxes) uma independência quanto as suas especificidades. Com isso, uma vez implementadas, as aplicações serão executadas em terminais de acesso de diferentes fabricantes sem necessidade de adaptação. A camada de software referida, denominada middleware, é responsável por todo o tratamento das aplicações citadas, desde sua recepção até o controle de seu ciclo de vida. Os principais middlewares de TV Digital existentes são o MHP (europeu), o DASE (americano), o ARIB (japonês) e o Ginga (brasileiro). O último surgiu a partir de uma iniciativa do governo federal, que, ao instituir o Sistema Brasileiro de TV Digital, conseguiu envolver o corpo acadêmico brasileiro,

17 15 além de empresas especializadas, em prol do desenvolvimento de um Sistema de TV Digital capaz de atender às demandas específicas do país. O Ginga foi desenvolvido com participação ativa do LAVID (Laboratório de Aplicações de Vídeo Digital), centro de pesquisa onde o presente trabalho nasceu e encontrou suas motivações. 1.1 Motivação As aplicações de TV Digital, também conhecidas como Xlets em um middleware procedural, são transmitidas via broadcast juntamente com os fluxos de áudio e vídeo, uma após a outra, de uma forma que lembra um "carrossel de dados", visto que há a retransmissão das aplicações logo após a transmissão da última aplicação no carrossel. A transmissão em carrossel é de todo imprescindível, uma vez que nada se pode garantir quanto à recepção das aplicações, isto é, o telespectador pode estar com o settop box desligado no momento da primeira transmissão de uma aplicação, fazendo-se indispensável o uso das retransmissões para que este tenha condições de recepcioná-la a posteriori. Embora indispensável, o modelo de transmissão mencionado apresenta problemas que conflitam com o modelo de negócios utilizado no sistema de televisão atual. Como as aplicações estão organizadas em forma de uma fila circular, isso significa que para serem executadas cada uma delas terá que esperar o tratamento da aplicação em sua frente, com um atraso máximo para recepção igual ao período do carrossel, ou seja, o período de tempo necessário para a transmissão de todas as aplicações, respeitando-se a taxa reservada para a transmissão de dados. Hoje, atrasos como o elucidado, usuais em ambientes de TV Digital, representariam multas exorbitantes segundo o modelo de negócios atual, e praticamente inviabilizariam a transmissão em carrossel. Com o propósito de minimizar o atraso na execução das aplicações em um tempo computacional razoável, e, consequentemente, reduzir as multas inerentes ao modelo transmissão empregado, foram utilizadas as metaheurísticas GRASP, VND e VNS [1] [2] [3] [4], tendo como base um modelo de negócio próprio, também proposto por este trabalho.

18 Objetivos Este trabalho tem como objetivo principal o desenvolvimento de um algoritmo que, baseado em metaheurísticas disponíveis na literatura e em um modelo de negócios próprio, seja capaz de minimizar o atraso na execução das aplicações interativas. Para isso, os seguintes objetivos específicos devem ser alcançados: elaboração de um modelo de negócio que promova e viabilize a publicidade em ambientes de TV Digital; desenvolvimento de um modelo matemático que reflita o modelo de negócios proposto e objetive a minimização dos atrasos; criação de algoritmos que, baseados em metaheurísticas, reduzam os atrasos em um tempo computacional razoável.

19 17 2. TV Digital Nesta seção são apresentados conhecimentos básicos sobre os Sistemas de TV Digital, que incluem algumas tecnologias, protocolos e estatísticas relevantes para o entendimento do contexto no qual está inserido o presente trabalho. 2.1 Sistemas de TV Digital Um sistema de TV Digital pode ser definido como um conjunto de especificações que visam a transmissão e recepção de sinais digitais específicos ao ambiente de TV Digital [5]. Basicamente, ele é composto de uma estação transmissora, um meio físico sobre o qual o sinal de vídeo é transmitido, e um receptor desses sinais, o qual é popularmente conhecido como set-top box ou terminal de acesso, conforme mencionado na seção anterior. A Figura 1 apresenta os elementos básicos presentes em um sistema de TV Digital. Figura 1. Elementos básicos em um Sistema de TV Digital.

20 18 São eles: Codificador: Converte os sinais analógicos de áudio e vídeo para o formato digital de acordo com padrões de compressão como MPEG-2, H.264, AAC (Audio Advanced Encoding). Gerador de Carrossel: Elemento responsável por preparar um conjunto de arquivos de dados para serem transmitidos, de maneira cíclica, conforme o padrão DSM-CC ( Seção 2.2 ). Antes de sua transmissão, os dados são multiplexados juntamente com os fluxos de áudio e vídeo digitalizados. Multiplexador: Equipamento responsável por fundir os fluxos de áudio, vídeo e dados a serem transmitidos. O padrão adotado pela maioria dos Sistemas de TV Digital é o MPEG-2 Sistemas. Fluxos Elementares: Os fluxos de áudio, vídeo e dados, multiplexados segundo o padrão MPEG-2 Sistemas. Modulador: Converte as informações digitais oriundas do multiplexador em sinais capazes de ser transmitidos via rádio ou voltagens elétricas em um cabo. Receptor: Decodifica os sinais de áudio e vídeo, gerencia e executa as aplicações interativas. É, na verdade, um computador com recursos limitados, controlado por um middleware que atua em uma camada superior a do sistema operacional. A disposição das principais camadas que compõem um receptor é ilustrada abaixo: Figura 2. Arquitetura em camadas de um receptor. Com o objetivo de assegurar a interoperabilidade entre esses elementos, foram criados padrões, cujas especificações regulamentam todo o processo de captura,

21 19 compressão, modulação e transmissão dos sinais de vídeo, bem como todas as interfaces físicas entre os equipamentos envolvidos no processo. Dentre os existentes podem-se destacar o Europeu (DVB Digital Vídeo Broadcasting), o Americano (ATSC Advanced Television Systems Committee), e o Japonês (ISDB Integrated Services Digital Broadcasting) [6][7]. Uma das interseções que mais se destaca entre as propostas de padronização referidas é o padrão MPEG-2, o qual é utilizado como principal tecnologia nos processos de codificação do sinal fonte, multiplexação e transporte de dados. Seu mecanismo de transporte permite a transmissão de dados agregados por meio do uso de tabelas que podem carregar informações acerca da programação transmitida, como também as aplicações interativas propriamente ditas [8]. Algumas das diferenças encontradas entre os sistemas ou padrões de TV Digital se encontram justamente na forma da utilização dessas tabelas e nos metadados que descrevem as informações transportadas. Com a multiplexação dos dados agregados e dos codificados do sinal fonte, surge o conceito de fluxo elementar, através do qual um único fluxo de transporte permite que sejam codificados e transportados em paralelo um ou mais fluxos de vídeo, por exemplo, diferentes finais de um mesmo filme, selecionados pelo telespectador através de uma aplicação interativa, vários canais de áudio, além do transporte das aplicações que proporcionarão interatividade. O outro elemento que também passou pelo processo de padronização foi o middleware de TV Digital. Dessa maneira, os sistemas DVB, ATSC, ISDB e SBTVD definiram, respectivamente, o MHP [9], o ACAP [10], o ARIB e o Ginga [5] [6] [11]. Para abstrair as especificidades dos terminais de acesso de diferentes fabricantes e garantir que as aplicações desenvolvidas sejam executadas sem a necessidade de adaptação em cada um deles, esses middlewares são definidos por APIs (Application Programing Interface), com o a tecnologia Java da Sun Microsystems atuando como o componente central de sua parte procedural. Há também o suporte a linguagens declarativas. Com a finalidade de oferecer compatibilidade entre as aplicações dos diferentes sistemas de TV Digital, o grupo DVB propôs a unificação dos middlewares. Dessa iniciativa surgiu o GEM (Globally Executable MHP) [12], que inclui as características do MHP não específicas ao sistema DVB. Essa especificação é atualmente adotada

22 20 pelos padrões de middleware procedural Japonês (ARIB B.23), Americano (ATSC- ACAP) e Brasileiro (Ginga-J). Dando continuidade às iniciativas de compatibilização, a ITU (International Telecommunication Union) publicou um conjunto de recomendações ITU-T: J.200, J.201 e J.202, cujo objetivo é a harmonização dos sistemas de TV Digital em diferentes níveis. 2.2 MPEG-2 Sistemas O padrão MPEG-2 Sistemas define formatos e protocolos que especificam como os fluxos de áudio, vídeo e dados devem ser combinados para serem transmitidos adequadamente. Esses fluxos, como mencionado previamente, são denominados fluxos elementares (Elementary Streams) e são divididos em pacotes com a finalidade de facilitar processo de multiplexação, dada a dificuldade em manipular fluxos contínuos de informação. Cada pacote inclui um timestamp, um identificador do stream que informa o tipo do conteúdo e como ele foi codificado, e alguma informação de sincronização. Uma vez que os fluxos elementares são divididos em pacotes, o novo fluxo resultante é chamado de Packetized Elementary Stream (PES) [13]. Um conjunto de fluxos PES de áudio e vídeo que são apresentados como parte de um mesmo conteúdo formam um Program Stream (MPEG2-PS), que é o formato de multiplexação usado na maioria dos discos DVDs [14]. Nele podem existir diversos fluxos de vídeo (ex.: diferentes ângulos de um mesmo filme), bem como diferentes fluxos de áudio (vários idiomas, por exemplo), todavia, todos eles devem ser parte de uma mesma apresentação ou de um mesmo conteúdo. Esse grupo de fluxos relacionados é chamado de serviço no contexto da TV Digital. Para a transmissão de áudio e vídeo em um sistema de TV Digital é utilizado outro formato de multiplexação, o Transport Stream (MPEG2-TS). Diferentemente do Program Stream, ele é capaz de carregar vários serviços; é como se ele transmitisse vários Program Streams. Durante seu processo de multiplexação, os pacotes PES dos vários serviços são organizados um após o outro, de forma que eles façam parte de um único fluxo a ser transportado. Isso implica na inserção de informações que possibilitem ao receptor identificar quais pacotes PES pertencem a um determinado serviço. Antes de classificar os pacotes PES quanto ao serviço que fazem parte, é necessário determinar a qual fluxo PES cada pacote pertence. Sendo assim, cada pacote

23 21 PES possui um PID (Packet Identifier), que é um número que o identifica unicamente dentro do Transport Stream. Como os fluxos PES não possuem nenhuma indicação sobre o serviço ao qual pertencem, surge a necessidade de um mecanismo que demonstre como está organizado um Transport Stream específico, ou seja, quais serviços que o compõem e quais fluxos PES forma cada serviço. Para tal, o MPEG-2 Sistemas definiu o Service Information (SI) que nada mais é do que é um conjunto de tabelas ou metadados, transmitidos juntamente com os dados de áudio e vídeo. As tabelas definidas no MPEG-2 Sistemas são: PMT (Program Map Table): Para cada serviço no Transport Stream há uma tabela PMT correspondente que contém a lista de identificadores dos fluxos PES que o compõem. PAT (Program Associoation Table): Tabela fundamental para o Service Information. Ela contém os identificadores dos fluxos elementares das PMTs referentes a cada serviço. CAT (Conditional Access Table): Descreve o sistema de acesso condicional utilizado e provê informação de como decodificá-lo. Um exemplo de sua aplicabilidade está nos programas pay-per-view, em que só aqueles usuários que pagaram pelo serviço conseguem decodificar o sinal transmitido pela emissora. De posse do Transport Stream, o demultiplexador (componente do receptor responsável por separar os fluxos de áudio, vídeo e dados, multiplexados em um Transport Stream) inicia a procura pela PAT, a qual é transmitida a cada meio segundo e possui um identificador com valor fixo (0x001). A partir da PAT são identificados os fluxos elementares de cada PMT, onde, finalmente, estão localizados os identificadores dos fluxos de áudio e vídeo. A figura abaixo ilustra o processo de demultiplexação:

24 22 Figura 3. Processo de identificação dos fluxos de áudio e vídeo [15]. Com o intuito de sinalizar a presença de aplicações interativas em um Transport Stream, os middlewares compatíveis com o GEM definem uma tabela de serviço de informação extra, a saber, a AIT (Application Information Table). Ela descreve cada um das aplicações que serão executadas quando um determinado serviço está sendo exibido. As seguintes informações estão normalmente presentes em uma AIT: nome, versão, prioridade, identificador e tipo da aplicação, localização dos arquivos que a compõem, diretório base dentro do sistema de arquivos transmitido, organização associada à aplicação, seu status, entre outros. Duas partes principais são consideradas durante a identificação de uma aplicação. Uma se refere ao identificador da organização e outra ao identificador da própria aplicação. Ambos são valores que os identificam de forma única durante a transmissão. Além da identificação das aplicações, a AIT possui um mecanismo que permite controlar o seu ciclo de vida. O campo application_control_code é o responsável por sinalizar ao receptor de TV Digital que atitudes tomar quanto ao ciclo de referido. Os valores possíveis para o application_control_code definidos pelo GEM são:

25 23 autostart (0x01): A aplicação será iniciada automaticamente quando serviço for selecionado. present (0x02): Aplicação a ser iniciada pelo usuário, ficando disponível na lista de execução de aplicações. destroy (0x03): Quando o código de controle de uma aplicação é modificado de autostart ou present para destroy uma aplicação procedural é então condicionalmente finalizada (o método destroyxlet() será invocado com o valor false). kill (0x04): Quando o código de controle de uma aplicação é modificado de autostart ou present para kill uma aplicação procedural é então incondicionalmente finalizada (o método destroyxlet() será invocado com o valor true). prefetch (0x05): A máquina de execução das aplicações declarativas é carregada. Quando todos os elementos são inicializados, a aplicação espera por uma ação que a mova para o estado active. remote (0x06): A aplicação não está disponível no canal corrente, porém em um outro canal a ser selecionado. 2.3 DSM-CC O protocolo utilizado para a transmissão de dados multiplexados com conteúdo audiovisual na maioria dos padrões de TV Digital é o DSM-CC (Digital Storage Media - Command and Control), o qual é definido na parte 6 do padrão MPEG-2 (extensões para DSM-CC) [15]. Ele foi inicialmente desenvolvido para dispositivos gravadores de vídeo e estendido posteriormente para diversas funcionalidades, tais como o controle de servidores de vídeo MPEG, suporte para a transmissão de dados usando o MPEG-2, transmissão de sistemas de arquivos, dentre outros. A especificação do DSM-CC é dividida em várias partes, nem todas elas utilizadas pelos padrões de TV Digital. Há suporte a dois mecanismos de transmissão de dados no padrão DSM-CC, o carrossel de dados e o carrossel de objetos. O primeiro permite a um servidor transmitir um grande volume de dados para um conjunto de receptores, repetindo ciclicamente a transmissão do seu conteúdo. Tal transmissão é efetivada sem que haja uma descrição sobre a semântica e o formato dos dados, logo, toda responsabilidade de análise dos

26 24 mesmos se encontra no lado do receptor [16]. Esse tipo de carrossel é utilizado pelo ATSC (Advanced Television System Committee), padrão americano de TV Digital. Para situações mais complexas, o modelo de carrossel de objetos provê uma melhor solução ao oferecer uma semântica de dados semelhante a um sistema de arquivos. Dessa forma, uma estrutura de diretórios inteira pode ser transmitida e facilmente interpretada no lado do receptor. Esse tipo de carrossel é utilizado pelos padrões europeu e brasileiro de TV Digital, DVB e SBTVD, respectivamente. Os dados no carrossel de objetos são divididos em módulos, os quais podem conter um ou mais arquivos ou diretórios. Há um limite de 64 Kbytes para módulos com mais de um arquivo e a imposição de que arquivos com tamanhos maiores devem pertencer a um único módulo, nunca separado em módulos diferentes. A estruturação das aplicações em sistemas de arquivos, sua divisão em módulos, bem como todos os procedimentos necessários para o envio de Xlets de acordo com o padrão DSM-CC, estão sob a responsabilidade de uma ferramenta essencial nos sistemas de TV Digital o Gerador de Carrossel principal alvo dos resultados obtidos com o trabalho proposto. 2.4 Aplicações de TV Digital As aplicações de TV Digital ou aplicações interativas são classificadas em procedurais e declarativas, de acordo com a natureza do middleware onde são executadas. As aplicações declarativas são baseadas em um conteúdo declarativo, isto é, em uma linguagem que enfatiza a descrição declarativa do problema, ao invés da sua decomposição em uma implementação algorítmica [17]. As linguagens declarativas são linguagens de mais alto nível de abstração, que tem o foco na apresentação e sincronização de objetos de mídia (vídeo, áudio, gráficos, etc). Em linguagens procedurais, o programador possui um maior poder sobre o código, chegando ao ponto de ter a capacidade de traçar todo o fluxo de controle e execução de sua aplicação. Em relação às linguagens declarativas, as procedurais exigem mais do programador no tocante ao desenvolvimento de aplicações, porém oferecem mais recursos e robustez, o que permite a construção de aplicações para os mais diversos fins.

27 25 Diferentemente das linguagens declarativas dos midlewares de TV Digital, as linguagens procedurais dos mesmos possuem uma plataforma de desenvolvimento em comum, que de certa forma promove a compatibilidade entre elas. Tal base comum se refere ao ambiente computacional Java, o qual designa a API JavaTV como sua principal ferramenta para produção de conteúdo para televisão interativa. Além da JavaTV, também fazem parte das definições GEM as APIs DAVIC, HAVi e DVB. Todas elas utilizam a linguagem de programação Java para sua definição API JavaTV JavaTV é uma API de extensão vertical da plataforma Java projetada para produção de conteúdo interativo procedural para TV Digital baseado em Java [18]. De forma geral, a API JavaTV provê, para programas escritos em Java, alguns mecanismos de controle e acesso sobre receptores de TV Digital, abstraindo totalmente os aspectos do sistema operacional e detalhes da hardware. Dessa forma, o propósito chave da API JavaTV é prover um conjunto de métodos, classes e interfaces para facilitar a construção de aplicações para plataformas de recepção de TV Digital independentes de tecnologia de redes de difusão. A API JavaTV é simplificada e provê apenas as funcionalidades características dos receptores digitais. Algumas APIs que são específicas de dispositivos de eletrônica de consumo, como os mecanismos de armazenamento persistente, não estão inclusas na API JavaTV. Essas APIs são providas em novas definições para o ambiente de aplicações ou são desenvolvidas em conjunto com vários. As principais funcionalidades oferecidas pela JavaTV para aplicações são: acesso a serviços e informação de serviços; seleção de serviços; controle (alto nível) dos elementos de recepção do sinal de difusão (sintonizador, demultiplexador e decodificador); acesso dados de difusão (broadcast); gerência do ciclo de vida das aplicações; De forma geral, a API JavaTV, através de suas funcionalidades, dá suporte às aplicações que são executadas por uma JVM designada para terminais de acesso. Com a utilização da JVM e APIs, os detalhes do sistema operacional e hardware são abstraídos, deixando os desenvolvedores livres para se concentrar no desenvolvimento

28 26 do seu domínio de aplicação, o conteúdo interativo. Na Figura 4 temos um visão geral a API JavaTV e sua relação com as camadas inferiores do receptor e com as aplicações que utilizam a API API DAVIC Figura 4. Arquitetura JavaTV. O sistema Digital Audio Video Council (DAVIC) [19] é um conjunto de especificações e padrões que possuem como objetivo fornecer uma real interoperabilidade fim-a-fim de plataformas que executem serviços de áudio e vídeo transmitidos via broadcast. Deste modo, esses padrões podem ser utilizados em sistemas de TV digital para a entrega de conteúdo ao usuário final e também para possibilitar a interatividade com esse mesmo usuário. As principais funcionalidades da API DAVIC são as seguintes: extensão ao controle de exibição de áudio e vídeo provido pelo JMF (Java Media Framework); manipulação dos elementos de um Transport Stream; interfaces para as várias características de um sistema de acesso condicional; acesso ao sintonizador dos receptores; gerenciamento dos recursos escassos do set-top box; suporte ao armazenamento de aplicações; acesso às seções privadas do MPEG2-Sistemas;

29 API HAVi O HAVi (Home Audio Video Interoperability) [20] fornece um padrão de home networking para interoperabilidade entre dispositivos de áudio e vídeo. Seu principal objetivo é fazer com que os dispositivos que compõem uma rede HAVi possam interagir entre si e que haja funções disponíveis pelas quais um ou mais dispositivos sejam controlados por um outro dispositivo, independente de fabricante e de implementação do padrão. A arquitetura do HAVi é aberta, independente de plataforma e de linguagem de programação utilizada, podendo ser utilizada em qualquer sistema operacional de tempo real. Tais aspectos promovem o desenvolvimento de dispositivos interoperáveis por parte dos fabricantes, e facilita, por parte dos desenvolvedores de aplicações, a construção de aplicações em Java através de APIs disponibilizadas pelo HAVi. A API HAVi oferece vários recursos e soluções para controlar dispositivos de entrada de dados no ambiente televisivo e construir telas de apresentação. A seguir algumas dessas características serão listadas: possui um subconjunto de Java AWT 1.1; suporte para diferenças em Pixel Aspect Ratio, Screen Aspect Ratio e Screen Size; Alpha blending e video/image layering; suporte para controle remoto; conjunto próprio de componentes de GUI, podendo ser estendido. Além das funcionalidades apresentadas anteriormente, HAVi também apresenta o modelo de apresentação em camadas. O modelo de visualização é divido em três camadas: Background Layer, Video Layer, Graphic Layer. Essa separação torna-se importante quando é necessário que a alteração em uma camada não interfira em outra API DVB A especificação DVB/MHP [21] é construída a partir das APIs JavaTV, HAVi e DAVIC. Para completá-la são necessárias novas interfaces de programação e elas são definidas pela API DVB Core que estende algumas funcionalidades das APIs citadas. Como exemplo dos principais serviços adicionados, pode-se mencionar: gerenciamento da conexão do canal de retorno; armazenamento de informações;

30 28 manipulação de eventos; segurança e gerenciamento de aplicações; acesso estendido aos arquivos transmitidos via DSM-CC; extensões para o controle de exibição de áudio e vídeo; extensões às funcionalidades de acesso condicional do DAVIC. 2.5 Os Xlets Um Xlet é uma aplicação Java responsável pelo provimento de um determinado serviço e é criado para ser executado em um receptor de televisão digital. Os Xlets não precisam estar previamente armazenados no set-top box, pois podem ser enviados pelo canal de difusão quando necessários [22]. Um gerenciador de aplicações é necessário para controlar o ciclo de vida de um Xlet e sinalizar as suas mudanças de estado. Algumas características do gerenciador são: ele é capaz de destruir a qualquer momento os Xlets que estão sobre seu comando; é responsável por sinalizar um Xlet a respeito do seu estado corrente; e tem o poder de mudar o seu estado. Entretanto, um Xlet também pode mudar seu próprio estado, devendo assim sinalizar para o gerenciador de aplicações seu estado corrente. Cada Xlet possui um contexto associado a ele, o qual é usado para permitir que uma aplicação obtenha maiores informações sobre o ambiente de execução e facilite a comunicação de suas mudanças de estado. Assim como nos Applets, a interface Xlet permite que um agente externo (um gerenciador de aplicações) inicie e finalize a aplicação, bem como realize outros controles sobre a mesma. A interface Xlet é definida a seguir: public interface Xlet { public void initxlet(xletcontext ctx) throws XletStateChangeException; public void startxlet() throws XletStateChangeException; public void pausexlet(); public void destroyxlet(boolean unconditional) throws XletStateChangeException; }

31 29 Um Xlet pode se encontrar em quatro estados distintos em seu ciclo de vida: loaded, paused, active e destroyed. O ciclo de vida de um Xlet é mostrado na figura abaixo. Figura 5. Ciclo de vida de um Xlet. Um Xlet encontra-se no estado loaded quando ele foi carregado e não inicializado, ou seja, depois da sua instanciação. Caso uma exceção ocorra, o Xlet vai para o estado destroyed. Quando um Xlet encontra-se no estado paused, ele está inicializado, ocioso e sem utilizar recurso algum do ambiente. Esse estado pode ser alcançado das seguintes formas: a partir do estado loaded, após o método initxlet() retornar com sucesso; a partir do estado active, após o método pausexlet() e antes do método XletContext.notifyPaused() retornarem com sucesso para o Xlet. O estado active caracteriza uma execução normal, onde o Xlet está provendo algum serviço. O estado destroyed é alcançado uma única vez por ciclo. Com a execução do método destroyxlet(), o Xlet termina sua execução e libera os recursos alocados para ele. Esse método pode ser executado em duas situações distintas: quando o gerenciador de aplicações deseja a destruição de um Xlet em especial ou quando o próprio Xlet deseja destruir a si mesmo. Somente o Xlet pode determinar se ele é capaz de prover o serviço para o qual foi designado. Dessa forma, o gerenciador não pode obrigar um Xlet a prover determinado serviço. Uma típica seqüência de execução de um Xlet pode ser descrita abaixo:

32 30 Tabela 1. Sequência de execução de um Xlet. Gerenciador de aplicações Cria uma nova instância de um Xlet. Cria um objeto contexto para o Xlet, executa e inicializa-o. Xlet Um construtor sem argumentos é chamado; entra no estado carregado. O Xlet utiliza o contexto para a sua própria inicialização; entra no estado pausado. Sinaliza para o Xlet executar um serviço e entra no estado ativo. Sinaliza para o Xlet parar a execução do serviço. Sinaliza para o Xlet ser destruído. Adquire recursos necessários e inicia a execução do serviço. Pára a execução do serviço e libera recursos alocados. Salva preferências do usuário e libera os recursos utilizados. 2.6 Sistema Brasileiro de TV Digital No ano de 2005 o governo brasileiro instituiu o projeto SBTVD (Sistema Brasileiro de TV Digital), do qual participaram milhares de pesquisadores de várias universidades e centros de pesquisa. As atividades do SBTVD abordaram todas as partes que compõem um sistema de TV Digital, além do desenvolvimento de inovações que objetivaram ajustar a implantação da TV Digital ao contexto social brasileiro. O objetivo do projeto foi oferecer ao governo as informações necessárias para guiá-lo no sentido da criação de um sistema aberto de televisão digital terrestre, posteriormente batizado como ISDTV-T (International Standard for Digital Television Terrestrial). O middleware de referência, denominado Ginga, teve sua origem na junção do middleware procedural FlexTV [6], desenvolvido em compatibilidade com o GEM, e o middleware declarativo MAESTRO [11], ambos concebidos no projeto em questão. Os requisitos que conduziram a especificação do Ginga foram, em sua maioria, baseados em algumas particularidades do contexto social do país, as quais são compartilhadas pela maioria dos países latino-americanos. Assim, algumas inovações em relação aos outros middlewares se fizeram necessárias e foram implementadas preservando a compatibilidade com estes. No mesmo ano da instituição do SBTVD, o CPqD (Centro de Pesquisas e desenvolvimento de Telecomunicações) verificou [23] que havia por volta de 55

33 31 milhões de televisores presentes em 90% dos lares brasileiros; dessa porcentagem, 79% só recebiam via radiodifusão terrestre. Quanto aos equipamentos utilizados, 27% eram monitores de 14 polegadas, 37% de 20 polegadas, com 47% deles exclusivamente com antena interna. Estatísticas como essas, somadas ao fato de apenas 32,1 milhões de brasileiros terem acesso à Internet (21% da população), fizeram o governo determinar alguns requisitos básicos para o Sistema Brasileiro de TV Digital. Entre eles tem-se: baixo custo e robustez na recepção, flexibilidade e capacidade de evolução, interatividade e novos serviços. Este visa promover a inclusão digital e é tratado como um requisito fundamental. Algumas das pretensões do governo são que o Brasil tenha cerca de 80 milhões de terminais de acesso até 2017 (prazo estabelecido da transição completa para o modelo digital), e que o Ginga alcance outros países da América Latina. Percebe-se claramente que para alcançar suas pretensões e cumprir com os requisitos estabelecidos, o governo preconizará custos baixos no preço final dos terminais de acesso, a fim de que eles possam ser acessíveis à população desde a classe menos favorecida. Logo, os set-top boxes terão seus recursos computacionais limitados e um cenário propício à otimização de sistemas será estabelecido.

34 32 3. Apresentação do Problema Com a digitalização das informações transmitidas pelas emissoras de televisão, a largura de banda de 6 Mhz, concedida às TVs abertas pelo governo brasileiro, poderá transmitir 20 Mbps de áudio, vídeo e dados [24]. Dessa taxa, no mínimo 14 Mbps será reservado para a transmissão de vídeo no padrão H.264, também conhecido como MPEG-4 Parte 10 ou AVC (Advanced Video Coding) e adotado pelo SBTVD. Logo, a taxa máxima pra transmissão de dados será limitada a 6 Mbps. Tanto as aplicações procedurais (Xlets) quanto as aplicações declarativas possuem tamanho irrisório ao compará-las com a taxa limite mencionada acima. Entretanto, não apenas de código executável elas são formadas. Frequentemente, arquivos de áudio, vídeo, imagens e até mesmo de banco de dados são necessários a uma enorme gama de aplicações, fazendo com que o tamanho do carrossel aumente consideravelmente. Em conseqüência disso, torna-se comum um carrossel com tamanho dez, vinte ou trinta vezes maior que taxa reservada para a transmissão de dados. Outro aspecto importante a ser ressaltado diz respeito à capacidade de armazenamento dos set-top boxes. Um dos requisitos do governo brasileiro que vem guiando a digitalização de seu sistema televisivo é que o resultado dessa transformação sirva como ferramenta de inclusão digital. Essa preocupação se justifica pelo fato de apenas 32,1 milhões de brasileiros possuírem acesso à Internet, o que representa 21% da população, enquanto que 91% dos domicílios no Brasil possuem televisão [8]. Por conseguinte, quanto mais recursos que possam encarecer o preço final dos set-top boxes puderem ser removidos, mais pessoas terão condições de comprá-los e maior será o alcance da inclusão digital tão preconizada pelo governo. Conclui-se, então, que pelo menos durante a transição da TV analógica para a digital, não existirá espaço de armazenamento reservado para as aplicações oriundas do carrossel. Diante das limitações impostas, infere-se que essas aplicações terão um certo atraso para serem executadas, visto que terão que esperar o tratamento de todas as aplicações a sua frente, de acordo com a seqüência com a qual elas giram no carrossel, para que possam enfim ser recepcionadas. A ilustração abaixo mostra essa situação com maior clareza:

35 33 Figura 6. Representação da forma de transmissão em carrossel. A figura acima exibe uma foto de uma transmissão hipotética em carrossel no instante em que o usuário liga o set-top box. No cenário hipotético ilustrado, a taxa reservada para a transmissão de dados é de 750 KB/s, e o carrossel possui onze aplicações com 1,5 MB de tamanho cada uma. Repare que no instante em que o usuário liga o terminal de acesso, a aplicação na cor vermelha, pela qual o telespectador espera, já passou pelo momento da recepção e execução das aplicações. Agora, o usuário terá que esperar a passagem de todas as aplicações, até que chegue a vez da aplicação esperada. O tempo decorrido para tal seria o de 18 segundos, já que existem nove aplicações a sua frente, cada uma com tempo de transmissão de 2 segundos (tamanho / taxa). Atrasos como esses não são tolerados em hipótese alguma no contexto televisivo, independente do modelo de negócio adotado. Um segundo de publicidade nesse veículo de comunicação pode custar um fortuna, sendo assim, atrasos e quebras de contratos significam multas exorbitantes e perdas financeiras insuportáveis às emissoras. Contudo, elas não são as únicas que têm o interesse em reduzir os atrasos na execução das aplicações. É corriqueiro aos internautas esperarem vários minutos ou até mesmo horas para a conclusão de um download, pois eles convivem com esse tipo de situação desde o início do desenvolvimento da Internet. Todavia, esse não é um comportamento esperado dos telespectadores, que, historicamente, não costumam ter paciência e não suportam ficar de frente pra TV durante os intervalos comerciais. Semelhantes às propagandas de hoje, as aplicações de TV Interativa também tratarão de publicidade, anúncio,

36 34 merchandising e serão mais um incômodo para os telespectadores impacientes. Uma pequena espera para execução de uma determinada aplicação poderá significar uma mudança de canal (situação que aborta sua execução), o desligamento do terminal de acesso, ou até mesmo fazer com que os telespectadores criem aversão a determinadas aplicações num caso mais extremo. Em vista disso e diante da impossibilidade de eliminação dos atrasos, uma vez que é comum o tamanho de um carrossel ser muitas vezes maior que a taxa reservada para a transmissão de dados, surge a necessidade de minimizá-los em um tempo computacional razoável. Para tal, as seguintes macro propriedades devem ser compreendidas: i. todas as aplicações serão inicialmente candidatas e poderão estar presentes ou não no carrossel; ii. elas terão freqüências diferentes de acordo com seu benefício; iii. a distância entre aplicações idênticas dentro do carrossel será o otimizada de forma a reduzir seu atraso máximo; iv. a receita obtida pela emissora será resultado da subtração do valor recebido com a veiculação das aplicações e a multa paga por atraso de cada uma delas; Percebe-se das propriedades (i) e (ii) que o problema abordado é um tipo especial do problema clássico da Mochila 0-1, adicionada a possibilidade de inserção de um mesmo objeto mais de uma vez. Tal problema clássico é considerado pela literatura como um problema NP-HARD [25]. Uma vez adicionadas, as aplicações precisam ser organizadas dentro do carrossel de forma a minimizar a distância entre as aplicações replicadas e, consequentemente, minimizar o atraso e aumentar a receita da emissora (propriedades (iii) e (iv) ). Para isso, deve-se alterar a posição das aplicações até que uma configuração de carrossel com o mínimo de atraso seja encontrada. A Figura 8 mostra como um layout de carrossel organizado pode reduzir o atraso.

37 35 Figura 7. Otimização do atraso no carrossel. A primeira representação de carrossel da esquerda para a direita exibe a replicação das aplicações de acordo com seu benefício (problema clássico da mochila), sem a preocupação de organizar sua estrutura interna. Note que a aplicação na cor vermelha a de maior benefício terá que esperar a transmissão das oito aplicações no pior caso. Minimizando a distância máxima entre as aplicações idênticas, essa mesma aplicação terá que esperar apenas por outras duas, reduzindo bastante o tempo necessário para sua execução. O número de operações necessárias para encontrar a solução ótima é dado pela fórmula da permutação com repetição: p = n q! q n!!... q 1 2 n!, onde q 1, q 2 e q n representam a quantidade de aplicações de índice 1, 2 e n inseridas no carrossel. Um algoritmo que teste todas as configurações possíveis na procura da solução ótima teria uma complexidade θ(n!), e um número de operações próximo a n!, visto que no problema específico em questão o numerador tende a ser um valor absurdamente maior que denominador. Vale salientar que n não corresponde ao número de aplicações candidatas a serem inseridas no carrossel, e sim ao somatório das freqüências das aplicações selecionadas. O tamanho final do carrossel é variável e será obtido a partir do somatório citado anteriormente. Entretanto, ele terá um limite máximo que representa um valor que gera

38 36 um atraso obrigatoriamente menor que o tempo de veiculação contratado pelos anunciantes. Num futuro bem próximo, espera-se que no mínimo 20 aplicações diferentes disputem a banda reservada para a transmissão de dados. Hoje em dia já pode-se verificar que esse valor é quase alcançado pela televisão digital fechada, a SKY, por exemplo. Testes realizados, os quais serão apresentados com mais detalhes posteriormente, demonstram que com 20 aplicações candidatas há uma inserção por volta de 40 aplicações no carrossel, onde o número maior de repetições de uma mesma aplicação chega a seis. Com isso, a aplicação da fórmula anterior resultaria em um valor bem próximo a 40! operações, que representa uma eternidade seja qual for a plataforma utilizada para processamento. A complexidade do algoritmo demonstrada inviabiliza a busca pela solução ótima e torna necessário o uso de heurísticas que auxiliem na procura de um boa solução em um tempo computacional razoável. A partir delas que este trabalho se desenvolve e apresenta soluções para os problemas definidos.

39 37 4. Modelo de Negócio Proposto Espera-se muito da interatividade na TV Digital aberta brasileira, porém há muito a ser discutido e definido. Sabe-se que revolucionará a maneira da assistir televisão e que surgirá um nova forma de publicidade e marketing capaz de gerar receitas no grande negócio que é a televisão. Entretanto, não há nada definido no tocante às regras que serão impostas para transformar a interatividade em negócio. Um dos poucos consensos é que as aplicações serão veiculadas às programações das emissoras, assim como acontece hoje com as propagandas. Mas há mais dúvidas do que consensos. Por exemplo, tempo e horário de exibição são os principais parâmetros utilizados no modelo de negócio atual, os quais podem, com a digitalização da banda de transmissão, ser substituídos ou mesclados com a quantidade de bytes ocupados pela propaganda e pelas aplicações, isto é, a emissora tem agora a possibilidade de vender os bytes de sua banda de transmissão. Mas, será que a venda de banda será de todo livre, ou seja, será que a emissora poderá transmitir aplicações interativas no mesmo instante em que são exibidas as propagandas? Elas poderão anunciar produtos diferentes ou terão a obrigatoriedade de anunciar o mesmo produto da propaganda exibida simultaneamente? Outra dúvida bastante discutida diz respeito ao tempo de manipulação das aplicações ou o tempo no qual elas permanecerão ativas para o usuário. Caso haja a obrigatoriedade das aplicações anunciarem os mesmos produtos das propagandas, o tempo de manipulação referido seria de apenas 30 segundos, período de tempo reservado para a exibição das propagandas no modelo de negócios atual. Contudo, bem mais que 30 segundos não necessários para a manipulação da maioria das aplicações interativas. Para exemplificar, imagine um formulário, preenchido através do controle remoto, para cadastro de informações pessoais, requisitados por uma aplicação interativa que vende pizzas através da TV. O modelo de negócios proposto não tem a pretensão de responder a todas essas perguntas, até porque muitas delas fogem do escopo deste trabalho, que tem por objetivo o desenvolvimento de uma solução que minimize o atraso na execução das aplicações de TV Digital transmitidas em carrossel e, consequentemente, aumente a receita das emissoras. Logo, ele se destina a propor regras de negócio com o intuito de especificar valores e parâmetros para a veiculação de aplicações interativas, e

40 38 principalmente definir uma forma de calcular quanto se deve pagar por seus atrasos. Para isso foram criados dois cenários, A e B, que tratam de forma diferentes o valor a ser pago para a transmissão de tais aplicações. Além dos parâmetros tempo e horário de exibição, que atualmente dominam a negociação da veiculação de propagandas, há uma inclinação, por parte das emissoras, em também negociar banda de transmissão. Dessa forma, os anunciantes pagarão valores diferenciados de acordo com os formatos de áudio e vídeo escolhidos. Por exemplo, um vídeo de alta definição, que necessita de uma maior largura de banda para ser transmitido, custará bem mais aos anunciantes se comparado com os vídeos em definição padrão. Apesar de interessante para fluxos de áudio e vídeo, essa estratégia prejudica a negociação das aplicações interativas, pois limitam o tamanho máximo do carrossel à taxa reservada para transmissão de dados, que de acordo com a Seção 3 estará por volta de 6Mbps ou 750KB/s (transformando a unidade) no Sistema Brasileiro de TV Digital. Isso implica na rejeição de contratos com anunciantes, pois a soma das aplicações presentes em um carrossel nunca poderá ultrapassar 750KB, que é considerado um tamanho médio para um única aplicação de TV Digital. Para não fugir totalmente da tendência atual de vender Kbytes, foi definido o Cenário A, que embora não apresente a limitação citada no parágrafo anterior, exige que aplicações maiores paguem mais por sua veiculação. Além do tamanho, faixas de valores foram criadas como forma de replicar e minimizar o atraso das aplicações que pagam mais por sua veiculação. Exemplificando, nos testes realizados foram utilizadas faixas de valores que variam de R$ 0,10 a R$ 1,00 por KByte contratado. Sendo assim, uma aplicação com 1 MB de tamanho e que escolheu a faixa 5 para veiculação (faixa 1 = R$ 0,10/KB, faixa 2 = R$ 0,20/KB, etc), terá que pagar R$ 500,00 / s durante o período em que participará da transmissão em carrossel. Vale salientar que o período de manipulação da aplicação é diferente do período de participação no carrossel. Contratar um período de 60 segundos (500 * 60 = R$ a ser pago no exemplo anterior) não quer dizer que o usuário terá todo esse tempo para manipulá-la. Significa apenas que uma determinada aplicação será transmitida para os telespectadores, junto com outras aplicações inclusive, por esse período de tempo. O tempo de manipulação (t m ), nesse caso, seria a soma do instante (t 0 ) da execução da aplicação com seu atraso (at), subtraído do período contratado. Isto é:

41 39 t m = 60 ( t0 + at), com t 0 no intervalo [0, 60]. O valor da multa a ser paga pelo atraso seria calculado a partir do valor pago pela veiculação, levando em consideração um atraso máximo tolerado pelos anunciantes devido à natureza da transmissão em carrossel em ambientes de TV Digital, a qual difere do modelo de negócios atual como foi explicado anteriormente. Após tal atraso, visando evitar longos períodos de espera para a execução de aplicações interativas, a multa por segundo de atraso seria aumentada gradativamente de acordo com cláusulas contratuais acordadas entre as emissoras e os anunciantes. O cenário B compartilha todas as características do Cenário A, com exceção do valor a ser pago para veiculação de uma aplicação. No último há uma vinculação entre o tamanho da aplicação e o valor total pago, cujo cálculo se dá em função do preço do Kbyte. Em conseqüência disso, não existe a possibilidade de aplicações grandes pagarem pequenas quantias, mesmo que seus anunciantes queiram arcar com longos períodos de atraso. No cenário B também são definidas faixas de valores, porém estas não tem vinculação nenhuma com o tamanho das aplicações, permitindo uma maior flexibilidade na negociação entre emissoras e anunciantes.

42 40 5. Metodologia Com o objetivo de implementar algoritmos capazes de otimizar a geração de carrossel no Sistema Brasileiro de TV Digital, fez-se necessário a adoção de um procedimento metodológico composto pela elaboração das etapas descritas nos tópicos posteriores. 5.1 Modelagem Matemática O modelo matemático proposto baseia-se na idéia de reduzir o tempo máximo entre dois downloads subseqüentes de um mesmo Xlet (com finalidade didática, as aplicações interativas, procedurais ou declarativas, são todas denominadas de Xlets nesta seção). Em geral, a solução produzida tende a distribuir as possíveis cópias de cada Xlet de maneira uniforme ao longo da seqüência de Xlets do carrossel. Notação X: conjunto de aplicações interativas (Xlets). T: conjunto de posições ocupadas pelas aplicações. n: número total de aplicações. p i : valor pago para veiculação da aplicação i por segundo. t i : tamanho da aplicação i. R: taxa reservada para a transmissão de dados. TMAX: tamanho máximo para o carrossel. M: um número maior que TMAX. q: número máximo de aplicações no carrossel. AT: atraso tolerado pelas aplicações. TV: tempo de veiculação das aplicações. Variáveis de Decisão x ij = 1, se a aplicação i ocorrer na posição j. 0, caso contrário. z i = 1, se a aplicação i for selecionada a compor o carrossel 0, caso contrário.

43 41 y i : parcela do atraso da aplicação i multada com p i, com i = 1, 2, 3,..., n. w i : parcela do atraso da aplicação i multada com p i * 2, com i = 1, 2, 3,..., n. k d i j : soma em Kbytes das aplicações selecionadas entre as posições i e j da aplicação k. Di: maior distância (em Kbytes) entre duas ocorrências da aplicação i. Maximizar i X p z * TV i i i X w ( p i i *2) + y i * p i Sujeito a: j T i X t x i ij TMax, (1) n i= 1 x ij = 1, j [1...q ] (2) x ij = x (i+ n)j, i X, j [1...q ] (3) z y i i j T ( D x, i X i ij / R) [ AT + ( t / R) ], i i X (4) (5) w i ( D i / R) y, i X i (6) d i kj n j 1 s= 1 l= k t s x sl i X, k,j M (1 x [ 1,...,q ] ik ) M (1 x, k < j ij ) j 1 l= k + 1 M x il, (7) D i d i kj, k, j [ 1,..., q], k < j (8) y, w i i 0, i X (9) z, x i ij { 0,1} i X, j [1...q ] (10) D, d i i kj 0, i X, k, j [1...q ] (11)

44 42 O modelo em questão é formulado com base na abstração de uma matriz de q colunas (posição de cada Xlet no carrossel) e 2n linhas (cada uma representa um Xlet), em que o conjunto de Xlets é denotado por X e n = X. O carrossel é representado duas vezes na matriz (2n linhas) a fim de possibilitar o cálculo das distâncias entre aplicações idênticas e subsequentes, levando em conta o giro do carrossel.o número máximo de colunas q é calculado a partir da divisão de Tmax pela menor aplicação pertencente a X, onde TMax = TV*R. O tamanho máximo do carrossel é dado por Tmax, o qual é obtido ao multiplicar o tempo de exibição das aplicações pela taxa reservada para a transmissão de dados. O primeiro termo da função objetivo representa o lucro obtido com a adição de Xlets no carrossel (denota o lucro logrado com a contratação das aplicações) e o segundo as multas aplicadas devido aos atrasos em sua execução. A restrição (1) impõe um limite máximo ao tamanho do carrossel, enquanto que a (2) garante que apenas um único Xlet é alocado a cada posição do carrossel. A restrição (3) força a representação dupla do carrossel na matriz, e a (4) sinaliza quais Xlets serão selecionados a compor o carrossel. As restrições (5) e (6) calculam as parcelas do atraso das aplicações a serem multadas com as diferentes penalidades na função objetivo. Já as restrições (7) e (8) capturam o atraso máximo (em KBytes) D i para cada Xlet. Finalmente, as restrições de integralidade e não-negatividade são apresentadas em (9), (10) e (11). 5.2 GVND O algoritmo em questão é composto das metaheurísticas GRASP e VND, cuja integração é detalhada nas seções seguintes GRASP Nesta seção, é descrita a metaheurística GRASP Greedy Randomized Adaptive Search Procedure proposta para a otimização do Gerador de Carrossel de acordo com o modelo de negócios apresentado anteriormente. Um GRASP é um procedimento iterativo que combina várias propriedades favoráveis de outras heurísticas [1]. Mais especificamente, cada iteração do GRASP consiste de dois estágios: uma fase de construção da solução e uma fase de busca local. Em cada iteração, uma solução é encontrada. A melhor solução obtida dentre todas as

45 43 iterações é considerada a solução final. O pseudocódigo descrito pela Figura 9 ilustra uma metaheurística GRASP. Na fase de construção de uma solução, inicia-se um conjunto vazio, que iterativamente recebe um elemento, até formar uma solução viável. Em cada iteração da fase de construção, dois aspectos são analisados: a aleatoriedade e a adaptação. A aleatoriedade se deve ao fato de que o próximo elemento a ser escolhido para compor a solução não será necessariamente o melhor, segundo o critério guloso utilizado. Na verdade, a escolha é feita de forma aleatória, a partir de uma lista, denominada Lista Restrita de Candidatos (LRC), que contém os β melhores elementos candidatos segundo o critério guloso especificado. O valor de β é um parâmetro do algoritmo. Por outro lado, o aspecto da adaptação do processo se mostra evidente à medida que se escolhe um elemento que irá compor a solução inicial, já que os próximos elementos a serem inseridos em LRC dependerão daqueles naquela já incluídos. A seguir é descrito o algoritmo GRASP: Algoritmo GRASP ( f(.), GRASPmax, s ) 1. f * = ; 2. para Iter = 1 até GRASPmax faça 3. { 4. Fase-Construcao(s); 5. Fase-BuscaLocal( f(.), s); 6. se (f(s) < f * ) então { 7. s * = s; 8. f * = f(s); 9. } 10. } 11. Retorne s * ; Fim GRASP As soluções obtidas na fase de construção do GRASP não são garantidas como ótimos locais, considerando uma dada vizinhança (diz-se que uma solução s é localmente ótima, se não existe uma solução melhor na vizinhança de s). Portanto, o emprego da segunda fase do GRASP é feito com o intuito de se melhorar a solução obtida na fase de construção.

46 44 Um algoritmo de busca local é utilizado nesta segunda fase para, sucessivamente, substituir a solução atual por uma solução melhor, encontrada na vizinhança da solução atual. O algoritmo termina quando nenhuma solução melhor é encontrada na vizinhança da solução atual ou após algum outro critério de parada ter sido atingido Fase de construção A fase de construção tem seu início com uma solução S vazia, ou seja, nenhuma aplicação iterativa foi selecionada para compor o carrossel. A cada iteração uma aplicação é escolhida, de forma aleatória, a partir da lista restrita de candidatos (LRC). A lista LRC corresponde às aplicações que possuem um melhor benefício em analogia ao problema clássico da Mochila 0-1. Essa lista é obtida com o auxílio de uma função gulosa, denotada por g(x), que estima o benefício de seleção de cada aplicação x candidata a compor o carrossel. g(x) = vp(x)* tv(x) / [tam(x) + esp(x)], (2) onde: vp(x) corresponde ao valor pago pela veiculação da aplicação x; tv(x) corresponde ao tempo de veiculação da aplicação x; tam(x) corresponde ao tamanho da aplicação x; esp(x) corresponde ao espaço ocupado no carrossel pela aplicação x em cada iteração; As melhores aplicações candidatas a formar o carrossel serão aquelas que satisfizerem a condição abaixo: g(x) g max α(g max g min ), (3) onde g min = min{ g(x) x é uma aplicação candidata }, g max = max{ g(x) x é uma aplicação candidata} e α [0,1]. O parâmetro α, que determina o tamanho da lista de candidatos restrita, é basicamente o único parâmetro a ser ajustado na implementação de um procedimento GRASP. Valores de α que limitam a lista restrita de candidatos, isto é, valores que levam a uma escolha próxima da gulosa, implicam em soluções finais de qualidade muito próxima àquela obtida de forma puramente gulosa, com um baixo esforço

47 45 computacional. Por outro lado, deixam a desejar na diversidade das soluções construídas. Já uma escolha de α próxima da seleção puramente aleatória leva a uma grande diversidade de soluções construídas mas, por outro lado, muitas das soluções construídas são de qualidade inferior, tornando mais lento o processo de busca local [26]. O procedimento GRASP procura, portanto, associar bons aspectos dos algoritmos puramente gulosos, com aqueles dos procedimentos aleatórios de construção de soluções. Alguns procedimentos GRASP mais sofisticados ajustam o parâmetro α ao longo de suas iterações de acordo com os resultados obtidos em cada uma delas. No problema em questão, testes demonstraram que os melhores resultados foram encontrados com α próximo a 0,5. Após a obtenção de LRC e a escolha aleatória de uma aplicação x LRC, há a adição desta no carrossel, fazendo-se necessária a atualização das listas de aplicações selecionadas e não-selecionadas. Um pseudocódigo do algoritmo da fase de construção é apresentado abaixo: Algoritmo Fase-Construção (CAP_MAX, g(.), α, s) 1. s Ø; // todas as aplicações candidatas a compor o carrossel 2. Inicializar a função gulosa g; 3. TAM c = 0; // tamanho do carrossel 4. enquanto (TAM c < CAP_MAX) faça 5. { 6. LX = {aplicações em ordem crescente de acordo com a função g(x)}; 7. g min = min{ g(x) x LX }; 8. g max = max{ g(x) x LX}; 9. LRC = { x LX g(x) g max α(g max g min ) ; 10. Selecionar de forma aleatória um elemento v de LCR; 11. s = s {v}; 12. TAM c = TAM c + TAM(x); 13. Atualizar as listas das aplicações selecionadas e não-selecionadas. 14. } 15. Retorne s; Fim Fase-Construção;

48 46 A condição de parada para o algoritmo acima é alcançada quando o tamanho do carrossel atinge um valor limite, representado na ilustração por CAP_MAX. Esse é um parâmetro a ser ajustado, cujo valor deve ser um múltiplo da soma das aplicações candidatas. Valores próximos a duas ou três vezes a soma das aplicações candidatas alcançaram os melhores resultados nos testes realizados Busca Local A fase de Busca Local utilizou o VND como estratégia de refinamento da solução, o que a transformou no ponto de hibridização do algoritmo GVND VND No método VND (Variable Neighborhood Descent), proposto por Mladenovic e Hansen [4], explora-se o espaço de soluções através de trocas sistemáticas de estruturas de vizinhança. Uma nova solução é aceita somente quando for de melhora em relação à solução corrente e retorna-se à primeira estrutura quando isto acontece [27]. Quando não há mais melhora da solução, troca-se a estrutura de vizinhança e o algoritmo segue até que todas as vizinhanças sejam exploradas. Abaixo é ilustrado seu o pseudocódigo: Algoritmo VND( f(.), N(.), r, s) 1. Seja r o número de estruturas diferentes de vizinhança; 2. s s 0 ; // Solução corrente 3. k 1; // Tipo de estrutura de vizinhança corrente 4. enquanto (k r) faça { 5. Encontre o melhor vizinho s' N (k) (s); 6. se (f(s ) > f(s)) então { 7. s s"; 8. k 1; 9. } senão { 10. k k + 1; 11. } 12. } 13. Retorne s; Fim VND;

49 47 Foram definidas três estruturas de vizinhança, N 1, N 2 e N 3, definidas a partir dos seguintes movimentos, respectivamente: permutar a posição de dois elementos do carrossel um a um (complexidade: θ(n 2 ) ); excluir uma aplicação em uma posição específica do carrossel (complexidade: θ(1) ); inserir cada aplicação, presente ou não no carrossel, em todas as posições do mesmo (complexidade: θ (n 2 ) ); A estrutura de vizinhança N 1 foi escolhida como a primeira vizinhança a ser explorada por ser aquela que tem mais influência no melhoramento da solução corrente. A segunda estrutura de vizinhança tenta reduzir o carrossel ao seu tamanho mínimo como forma de encontrar uma boa solução. É nela que a geração de vizinhos se dá com uma menor complexidade, sendo, portanto, um fator importante na redução do custo computacional. Por último, temos N 3, que além de aumentar o carrossel como meio de encontrar uma boa solução, tenta reduzir a distância entre as aplicações idênticas ao realizar inserções em todas as posições do carrossel. Os movimentos utilizados foram todos determinísticos, adotando o Método Primeiro de Melhora (First Improvement Method), ou seja, a solução corrente s é atualizada com o primeiro vizinho capaz de melhorá-la. 5.3 GVNS A combinação GRASP e VND oferece uma ótima maneira de intensificar a busca por melhores soluções de vizinhanças previamente definidas. Em contrapartida, sua técnica de diversificação é um pouco limitada. A conseqüência disso é uma maior probabilidade do algoritmo não escapar de ótimos locais, o que direciona as soluções encontradas para um mesmo ponto. Para reverter este quadro, foi adicionada àquela combinação a metaheurística VNS (Variable Neighborhood Search), resultando no algoritmo denominado GVNS. O GRASP compõe sua espinha dorsal, onde os outros algoritmos irão apoiarse. O VND, mais uma vez, é responsável pelo refinamento da solução durante a fase de Busca Local. Já o VNS tem a atribuição de diversificar a solução refinada na etapa anterior, com o intuito de escapar dos ótimos locais resultantes de seu refinamento. O algoritmo GVNS é apresentado a seguir:

50 48 Algoritmo GVNS ( f(.), GRASPmax, s ) 1. f * = ; 2. para Iter = 1 até GRASPmax faça 3. { 4. Fase-Construcao(s); 5. Fase-BuscaLocal( f(.), s); 6. VNS( f(.), N(.), r, s); 7. se (f(s) < f * ) então { 8. s * = s; 9. f * = f(s); 10. } 11. } 12. Retorne s * ; Fim GRASP Construção A fase de construção do GVNS é idêntica a do algoritmo GVND Busca Local A fase de Busca Local também é constituída pelo algoritmo VND, o qual utiliza as vizinhanças N 1 e N 3 (definidas na seção 5.2.2) na busca por soluções. Diferentemente do algoritmo GVND, a exploração da vizinhança N 1 não se dá de forma exaustiva, visto que, aproximadamente, metade do número total de vizinhos são avaliados. A decisão de explorar um vizinho ou não é realizada a partir da geração aleatória de um número no intervalo [1, 10]; sendo ele menor ou igual a cinco ocorre a exploração, caso contrário o processo se repete com um outro vizinho. Outra diferença importante em relação ao GVND diz respeito a não inclusão de sua vizinhança N 2, justificada pela natureza das inserções e deleções de aplicações em um carrossel, discorrida nos parágrafos seguintes. O movimento de inserção aumenta a freqüência da aplicação inserida no carrossel, o que reduz, consequentemente, seu atraso em particular, e aumenta o atraso de todas as outras aplicações, já que estas terão que esperar por mais uma aplicação para serem executadas. Como resultado, a maioria das inserções geram maiores multas e

51 49 menores valores da função objetivo. Portanto, infere-se o quão caro é o movimento de inserção. Com o movimento de deleção ocorre o contrário: há um aumento no atraso da aplicação excluída e uma diminuição no atraso das outras aplicações. Como a última redução é, de forma absoluta, maior que o aumento no atraso da aplicação deletada, ocorre que o atraso global do carrossel diminui e valores maiores da função objetivo são encontrados. A natureza dos movimentos explanados anteriormente dá a falsa impressão de que o movimento de deleção traz sempre os melhores resultados. No entanto, embora esteja sempre auxiliando no melhoramento da solução corrente, é ele o responsável, na maioria das vezes, em fazer o algoritmo deparar-se com ótimos locais. Ao melhorar sucessiva e rapidamente as soluções, ele acaba se tornando um método de descida bastante íngreme que encontra vales de subidas muito custosas. Para sanar tal problema, o movimento de deleção foi retirado do VND e outras estruturas de vizinhança foram exploradas durante o VNS, detalhado a seguir VNS O Método de Pesquisa em Vizinhança Variável (Variable Neighborhood Search, VNS), é um método de busca local que consiste em explorar o espaço de soluções através de trocas sistemáticas de estruturas de vizinhança. Contrariamente a outras metaheurísticas baseadas em métodos de busca local, o método VNS não segue uma trajetória, mas sim explora vizinhanças gradativamente mais distantes da solução corrente e focaliza a busca em torno de uma nova solução, se e somente se, um movimento de melhora é realizado. O método inclui, também, um procedimento de busca local a ser aplicado sobre a solução corrente. Esta rotina de busca local também pode usar diferentes estruturas de vizinhança. Na sua versão original, o método VNS faz uso do método VND para fazer a busca local, e difere deste, principalmente, por gerar vizinhos da solução corrente de forma aleatória, prevenindo assim a ciclagem, situação que pode ocorrer se alguma regra determinística for usada Visando escapar dos ótimos locais com os quais se depara o movimento de deleção, e tornar mais eficaz a estratégia de inserção de elementos no carrossel, foram utilizadas estruturas de vizinhança, cuja exploração comporta movimentos consistindo na inserção aleatória de aplicações em um posição fixa do carrossel (complexidade: θ(1)). Para que essa inserção não comprometa a qualidade da solução construída na

52 50 Busca Local do GVNS, são inseridas apenas aquelas aplicações selecionadas a compor o carrossel durante essa fase. Dessa forma, há a escolha, de forma aleatória, de um subconjunto de com três, seis e nove aplicações subsequentes, presentes no carrossel construído na Busca Local do GVNS e sua posterior inserção ao final do carrossel. As quantidades de aplicações subsequentes foram escolhidas com base no número máximo de aplicações que usualmente são inseridas em um carrossel e em testes realizados. Para cada uma dessas quantidades, o algoritmo é executado três vezes, representando o critério de parada do laço principal do VNS. A ilustração de seu pseudocódigo encontrase a seguir: Algoritmo VNS(f(.), N(.), s) 1. Seja s 0 uma solução inicial; 2. Seja r o número de estruturas diferentes de vizinhança; 3. s s 0 ; // Solução corrente 4. enquanto (Critério de parada não for satisfeito) faça { 5. k 1; // Tipo de estrutura de vizinhança corrente 6. enquanto (k r) faça { 7. Gere um vizinho qualquer s' N (k) (s); 8. s" BuscaLocal(s'); 9. se (f(s") > f(s)) então { 11. s s"; 12. k 1; 13. } senão { 14. k k + 1; 15. } 16. } 17. } 18. Retorne s; Fim VNS; A Busca Local deste algoritmo utiliza o VND como método de refinamento de soluções, tendo como entrada o carrossel após cada uma das inserções mencionadas no parágrafo anterior. Os movimentos que definem as estruturas de vizinhança (N 4, N 5, N 1,

53 51 N 6 e N 7 ), estão descritos a seguir na ordem em que elas foram listadas, que propositalmente corresponde à seqüência de exploração de vizinhanças do VND. São eles: inserir 1 (uma) aplicação no carrossel, para cada uma das aplicações selecionadas (complexidade: θ(n) ); excluir 1 (uma) aplicação no carrossel, para cada uma das aplicações selecionadas (complexidade: θ(n) ); definido no algoritmo GVND, porém com uma redução no número de vizinhos explorados de acordo com o que foi explanado na Seção (complexidade: θ(n 2 ) ); inserir 2 (duas) aplicações no carrossel, para cada par de aplicações selecionadas e consecutivas (complexidade: θ(n) ); excluir 2 (duas) aplicações no carrossel, para cada par de aplicações selecionadas e consecutivas (complexidade: θ(n) ); Repare que é dada uma maior ênfase à inserção de elementos, pois além da primeira estrutura de vizinhança (a mais explorada no VND) ser gerada a partir de um movimento de inserção, não há deleções sem que haja prévias inserções. Com essa estratégia, tenta-se maximizar o tamanho do carrossel, e assim, evitar que os movimentos de deleção direcionem o algoritmo para ótimos locais. Apesar dos vários movimentos que definem as estruturas de vizinhança, todos eles têm uma complexidade de ordem θ(n), o que reduz o custo computacional do algoritmo. Apenas os movimentos que definem N 1 possuem uma complexidade maior θ(n 2 ) já que têm uma grande importância no melhoramento das soluções.

54 52 6. Resultados Como não foram encontrados problemas semelhantes na literatura, a base de comparação para os resultados obtidos foi definida de acordo com a solução adotada na implementação dos Geradores de Carrossel atuais, que apenas transmitem as aplicações uma após a outra sem a preocupação em reduzir atrasos. Essa solução foi avaliada de acordo com a modelagem matemática apresentada na Seção 4, definida a partir do modelo de negócios proposto. Além da comparação com a solução abraçada pelos Geradores de Carrossel atuais, foram confrontados os resultados dos algoritmos GVND e GVNS, tanto no que se refere aos valores da função de avaliação, quanto ao tempo de execução. Os resultados são apresentados para os dois cenários do modelo de negócio proposto. A implementação dos algoritmos propostos utilizou a linguagem C++, e os experimentos foram todos realizados em um computador com sistema operacional Linux 32bits, kernel , distribuição Ubuntu 8.04, processador Core 2 Duo T5250 de 1.5 Ghz e memória RAM de GB. As seções que seguem descrevem as instâncias escolhidas para a realização dos testes, apresentam os resultados quanto aos valores da função de avaliação e do tempo de execução, respectivamente. 6.1 Descrição das instâncias Uma instância é formada por um conjunto de aplicações inicialmente candidatas a fazerem parte do grupo seleto de aplicações que comporão o carrossel. Cada aplicação possui os seguintes atributos: identificador (ID); tamanho; faixa; valor pago por segundo de veiculação; tempo total de veiculação; atraso máximo tolerado.

55 53 Foram gerados três grupos de instâncias, um com dez aplicações e os outros com 15 e 20, respectivamente, para cada cenário. A produção de instâncias se deu de forma aleatória, com os atributos das aplicações obedecendo a limites especificados a seguir. O tamanho das aplicações foi gerado a partir de um levantamento prévio de aplicações reais desenvolvidas no LAVID. Em tal levantamento foi observado que as aplicações interativas variavam de 250 KB a 2,5 MB, que serviram de limiares para a geração aleatória das instâncias. Para o Cenário A as faixas de veiculação variaram de 1 a 10, com a mesma semântica apresentada na Seção 4. Modelo de Negócio Proposto (Faixa 1 = R$ 0.10, Faixa 2 = R$ 0.20, e assim sucessivamente); o valor pago por segundo de veiculação foi deduzido multiplicando-se o tamanho da aplicação pelo o valor referente a sua faixa de veiculação; o tempo total de veiculação foi fixado em 120 segundos para todas aplicações; para finalizar, o atraso máximo tolerado foi definido como 10% do tempo total de veiculação, ou seja, 12 segundos. Após isso as multas por segundo de atraso são cobradas em dobro com relação ao valor pago por segundo de veiculação. Já para o cenário B foram definidas dez faixas que representam as quantias a serem pagas por segundo para veiculação de aplicações independentemente de seus tamanhos. As quantias para cada faixa, do menor para o maior valor, são em reais (R$): 25, 50, 100, 200, 400, 800, 1200, 1600, 2000, 2500; o tempo total de veiculação foi fixado em 180 segundos para todas aplicações, simulando o período de um intervalo comercial; o atraso máximo tolerado continuou sendo os mesmos 12 segundos do cenário A, assim como o cálculo das multas. O único parâmetro relacionado ao modelo de negócios proposto que não faz parte do conjunto de propriedades de uma aplicação é a taxa reservada para transmissão de dados, a qual foi estabelecida como 6Mbps ou 750 KB/s, baseada na taxa real do Sistema Brasileiro de TV Digital, para ambos os cenários. Para um maior detalhamento sobre as instâncias vide Apêndices. 6.2 Função de avaliação Simplificadamente, o valor da função de avaliação é o resultado da diferença entre a receita obtida com a veiculação das aplicações e a multa sofrida pelo atraso em sua execução.

56 54 Por não levar em conta aspectos importantes como o tamanho, a prioridade (faixa) e o atraso máximo das aplicações, a solução atual implementada nos Geradores de Carrossel acaba sofrendo bastante com as multas, o que reduz consideravelmente a diferença receita-multa, representada como lucro nas ilustrações desta seção. As Tabelas 2 e 3 mostram, para os Cenários A e B, os valores da função de avaliação para a solução atual mencionada, que é citada ao longo da Seção apenas como Solução Atual. Tabela 2. Função de avaliação para Solução Atual (Cenário A). Instância Lucro (R$) , , , , , , , , , , , , , , ,17 Tabela 3. Função de avaliação para Solução Atual (Cenário B). Instância Lucro (R$) , , , , , , , , , , , , , , ,28 Devido ao fato das fases de busca local dos algoritmos GVND e GVNS alterarem de forma intensa as soluções produzidas na fase de construção, a variação do parâmetro α, que define o tamanho da LRC, não gerou soluções de boa qualidade, que estivessem próximas de ótimos locais. O valor de α foi fixado em 0.5, de forma a balancear o confronto entre gulosidade e aleatoriedade do GRASP. Outra situação da qual vale fazer menção diz respeito ao número de iterações escolhido para o GRASP. Por ter um método de refinamento com alto poder de intensificação, o que se deve, principalmente, aos movimentos utilizados no VND, o número de iterações não precisou ser alto para que boas soluções fossem encontradas. Isso fez com que este número fosse fixado em 25, resultando em bons resultados no tocante ao custo computacional. Outros números foram testados, porém aquele fixado foi o que melhor balanceou a qualidade das soluções e o custo computacional requerido.

57 55 Para cada instância foram realizadas 10 execuções, o que resultou em um total de 300 execuções, 150 para cada algoritmo (GVND e GVNS). Os valores utilizados nesta seção representam a média dos encontrados nas execuções mencionadas. Abaixo é ilustrado, em termos percentuais, a contribuição das fases de Construção e Busca Local no desenvolvimento das soluções. Observamos, a partir do gráfico abaixo, que na busca por uma boa solução para a Instância 1, a média dos valores encontrados para a função de avaliação, alcançados em todas as iterações das dez execuções do algoritmo GVND, durante a fase de Construção, representa aproximadamente 80% do valor final produzido pela fase de Busca Local. 100% 90% 80% 70% 60% 50% 40% Busca Local Construção 30% 20% 10% 0% Figura 8. Contribuição de cada fase na construção das soluções no algoritmo GVND (Cenário A). 100% 90% 80% 70% 60% 50% 40% Busca Local Construção 30% 20% 10% 0% Figura 9. Contribuição de cada fase na construção das soluções no algoritmo GVND (Cenário B).

58 56 A seguir, o detalhamento dos valores que originaram os gráficos em barra acima. Na segunda coluna, da esquerda pra direita, estão as médias dos valores encontrados para a função de avaliação das soluções produzidas pela fase de Construção, durante as iterações das execuções do GVND. A terceira coluna exibe tais valores em relação à fase de Busca Local. A quarta coluna, rotulada como Média, possui a média dos valores das melhores soluções oriundas da fase de Busca Local, entre as dez execuções do GVND para cada instância. A última coluna mostra o valor da melhor solução encontrada entre todas as iterações de todas execuções. Tabela 4. Detalhamento da contribuição de cada fase no algoritmo GVND (Cenário A). Instância Construção Busca Local Lucro (R$) (R$) (R$) Média Melhor , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,76 Tabela 5. Detalhamento da contribuição de cada fase no algoritmo GVND (Cenário B). Instância Construção Busca Local Lucro (R$) (R$) (R$) Média Melhor , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,00

59 57 Vale reforçar que os resultados das colunas 3 e 4 são diferentes, pois o primeiro reflete a média geral entre todas as iterações realizadas nas dez execuções de cada instância (25*10 = 250 iterações), enquanto que o segundo se refere à média das dez melhores soluções de cada conjunto de 25 iterações. Os resultados relacionados com o algoritmo GVNS são apresentados a seguir: 100% 90% 80% 70% 60% 50% 40% 30% VNS Busca Local Construção 20% 10% 0% Figura 10. Contribuição de cada fase na construção das soluções no algoritmo GVNS (Cenário A). 100% 90% 80% 70% 60% 50% 40% 30% VNS Busca Local Construção 20% 10% 0% Figura 11. Contribuição de cada fase na construção das soluções no algoritmo GVNS (Cenário B).

60 58 Tabela 6. Detalhamento da contribuição de cada fase no algoritmo GVNS (Cenário A). Instância Construção Busca Local VNS Lucro (R$) (R$) (R$) (R$) Média Melhor , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,19 Tabela 7. Detalhamento da contribuição de cada fase no algoritmo GVNS (Cenário A). Instância Construção Busca Local VNS Lucro (R$) (R$)) (R$) (R$) Média Melhor , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,39 Não obstante o GVND seja focado no refinamento das soluções, apoiando-se no método de descida VND, os movimentos utilizados, embora determinísticos, possuem intrinsecamente um mecanismo de diversificação. Isso o fez alcançar ótimos resultados em relação à solução atual adotada pelos Geradores de Carrossel e chegar bem próximo dos valores obtidos com o GVNS. Este, por sua vez, sofreu bastante na tentativa de aumentar o carrossel e escapar dos ótimos locais. Na maioria das instâncias o GVNS conseguiu superar os resultados do VND, aumentou o carrossel escapando dos ótimos

61 59 locais, entretanto, isso custou caro no que se refere ao tempo de execução. Mais detalhes sobre o custo computacional dos algoritmos são apresentando na próxima Seção. As Tabelas 8 e 9 confrontam as médias dos valores da função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual. Os valores das colunas Ganho 1 e Ganho 2 comparam os resultados dos algoritmos GVND e GVNS com a solução atual para os Geradores de Carrossel. A coluna Ganho 1 representa a diferença percentual entre as colunas GVND e Solução Atual, enquanto que a coluna Ganho 2 exibe a diferença percentual entre as colunas GVNS e Solução Atual. A coluna Ganho 3 apresenta o incremento obtido, em termos percentuais, com a solução GVNS em relação ao GVND. Tabela 8. Comparação entre a média dos valores da função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário A). Instância Solução Atual GVND GVNS Diferença Percentual (R$) (R$) (R$) (R$) Ganho 1 Ganho 2 Ganho , , ,66 3,81 4,77 0, , , ,15 1,00 1,17 0, , , ,63 0,00 0,09 0, , , ,16 1,33 1,37 0, , , ,55 4,97 5,50 0, , , ,95 2,70 2,78 0, , , ,16 14,32 14,32 0, , , ,61 9,88 9,88 0, , , ,86 6,10 6,19 0, , , ,87 8,28 8,27-0, , , ,89 11,49 11,49 0, , , ,58 21,56 21,56 0, , , ,46 32,74 32,96 0, , , ,24 34,37 34,29-0, , , ,67 31,49 31,47-0,02

62 60 Tabela 9. Comparação entre a média dos valores da função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário B). Instância Solução Atual GVND GVNS Diferença Percentual (R$) (R$) (R$) (R$) Ganho 1 Ganho 2 Ganho , , ,83 5,68 5,68 0, , , ,17 4,47 5,13 0, , , ,10 6,91 7,82 0, , , ,89 1,52 2,26 0, , , ,44 13,27 13,54 0, , , ,56 19,48 19,66 0, , , ,57 11,57 11,98 0, , , ,56 7,65 8,40 0, , , ,67 8,45 8,51 0, , , ,11 14,06 14,29 0, , , ,28 21,44 21,79 0, , , ,44 25,89 26,48 0, , , ,14 36,97 37,26 0, , , ,56 24,09 24,19 0, , , ,19 20,19 20,52 0,33 A seguir é apresentada a mesma comparação da tabela anterior, diferenciando-se desta por tratar dos melhores valores encontrados para a função de avaliação ao invés da média. Tabela 10. Comparação entre os valores das melhores soluções encontradas para a função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário A). GVNS Diferença Percentual (R$) Instância Solução Atual (R$) GVND (R$) (R$) Ganho 1 Ganho 2 Ganho , , ,43 4,41 5,01 0, , , ,56 1,00 1,70 0, , , ,09 0,00 0,38 0, , , ,43 1,41 1,41 0, , , ,41 5,30 5,65 0, , , ,53 2,70 3,16 0, , , ,16 14,32 14,32 0, , , ,61 9,88 9,88 0, , , ,60 6,14 6,45 0, , , ,26 8,28 8,28 0, , , ,89 11,49 11,49 0, , , ,58 21,56 21,56 0, , , ,48 33,09 33,09 0, , , ,52 34,37 34,37 0, , , ,19 31,49 31,89 0,40

63 61 Tabela 11. Comparação entre os valores das melhores soluções encontradas para função de avaliação dos algoritmos GVND e GVNS, e a Solução Atual (Cenário B). GVNS Diferença Percentual (R$) Instância Solução Atual (R$) GVND (R$) (R$) Ganho 1 Ganho 2 Ganho , , ,50 5,68 5,68 0, , , ,39 5,05 5,22 0, , , ,89 7,26 7,98 0, , , ,78 1,62 2,34 0, , , ,67 13,57 13,59 0, , , ,67 20,03 19,71-0, , , ,74 12,09 12,09 0, , , ,17 8,21 8,66 0, , , ,67 8,48 8,62 0, , , ,22 14,29 14,29 0, , , ,22 21,79 22,04 0, , , ,00 26,34 26,63 0, , , ,61 37,30 37,34 0, , , ,67 24,23 24,23 0, , , ,39 20,45 20,78 0,33 Aqui faz-se necessário uma reflexão sobre os Cenários A e B que destaque as diferenças nas atuações dos algoritmos GVND e GVNS em ambas situações. Como visto anteriormente, a principal diferença entre os Cenários A e B está na forma como os anunciantes pagarão pela veiculação de suas aplicações. No cenário A ocorre uma vinculação do valor a ser pago com o tamanho das aplicações, os quais são os principais parâmetros que definem a replicação e a prioridade das aplicação quanto à minimização de atrasos. Tal vinculação gera uma dependência entre eles de tal forma que os algoritmos GVND e GVNS encontram pouca diversidade entre as aplicações de uma instância, o que prejudica a busca por boas soluções. É como se um parâmetro anulasse o outro, fazendo com que as aplicações fossem relativamente iguais. Como é sabido, quanto mais as aplicações são semelhantes, menos necessidade há de replicá-las ou excluí-las, e assim menos trabalho é realizado pelos algoritmos. É importante lembrar que o tempo de veiculação no Cenário B é de 180 segundos enquanto que o do Cenário A é de apenas 120. Isso quer dizer que reduzir um segundo de atraso em 180 segundos de veiculação gera um ganho percentual bem menor que a redução do mesmo segundo em 120 segundos de veiculação. Caso fosse reduzido tal tempo de veiculação, os valores alcançados no Cenário B seriam bem superiores àqueles do outro cenário. Testes preliminares, não apresentados neste trabalho, comprovaram tal situação.

64 62 Com relação ao ganho do GVNS em relação ao GVND, perceba que com o Cenário B, o primeiro supera, considerando a média dos valores das soluções, o GVND praticamente em todas as instâncias, enquanto que no Cenário A esse número cai quase que pela metade. Isso tudo é fruto de uma maior diversidade gerada pela independência dos parâmetros que definem a prioridade das aplicações. As tabelas a seguir ilustram resultados do algoritmo GVNS para as instâncias com 20 elementos em que houve um maior ganho do GVNS em relação ao GVND em cada cenário: Tabela 12. Resultado do algoritmo GVNS para a instância 12 no Cenário A. Tabela 13. Resultado do algoritmo GVNS para a instância 13 no Cenário B. As sequências de aplicações correspondentes às soluções das Tabelas 12 e 13, respectivamente, são as seguintes: 1, 10,12, 20, 9, 19, 6, 2, 13, 20, 12, 16, 17, 19, 6, 20, 9, 14, 12, 2, 13, 20, 19, 6, 16.