UNIVERSIDADE PRESBITERIANA MACKENZIE ENGENHARIA ELÉTRICA. Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP FIXAS E VARIÁVEIS

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE PRESBITERIANA MACKENZIE ENGENHARIA ELÉTRICA. Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP FIXAS E VARIÁVEIS"

Transcrição

1 UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH): CONCEITOS E REPRODUÇÃO EM BANDAS FIXAS E VARIÁVEIS São Paulo 2013

2 UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH): CONCEITOS E REPRODUÇÃO EM BANDAS FIXAS E VARIÁVEIS Dissertação submetida ao Programa de Pós-Graduação em Engenharia Elétrica da Universidade Presbiteriana Mackenzie como parte dos requisitos para obtenção do título em Mestre em Engenharia Elétrica. Orientador: Professor Doutor Gunnar Bedicks Junior São Paulo 2013

3 B277d Barros, Uirá Moreno Rosário e Dynamic Adaptive Streaming Over Http (DASH): conceitos e reprodução em bandas fixas e variáveis. / Uirá Moreno Rosário e Barros São Paulo, f.: il.; 30 cm. Dissertação (Programa de Pós-Graduação (Stricto Sensu) em Engenharia Elétrica) - Universidade Presbiteriana Mackenzie - São Paulo, Orientador: Prof. Dr. Gunnar Bedicks Junior Bibliografia: f DASH. 2. Streaming. 3. IP. 4. Redes de computadores. 5. Android. 6. ISDB-Tb. I. Título. CDD

4 Ao Professor Fujio Yamada (in memoriam).

5 AGRADECIMENTOS Primeiramente agradeço a Deus, pela vida, pelo discernimento e pela oportunidade de estudo, assim como Sua presença em minha caminhada. Ao meu orientador, Professor Doutor Gunnar Bedicks, por ter acreditado e suportado minha pesquisa, pelo diálogo e suporte durante o mestrado. Também por ter me envolvido em atividades do laboratório relacionadas ao meu estudo, trazendo equipamentos e casos reais para que eu pudesse estudá-los. Fato esse que aproximou a realidade do mercado em meu trabalho e foi muito importante para o conhecimento adquirido, balanceado entre pesquisa e aplicação. Ao professor Daniel Arndt Alves que deu todo o apoio relacionado à computação, que foi essencial para a realização dos testes e resolução das dúvidas sobre redes. Ao professor Cristiano Akamine, pelas ótimas conversas, amizade e suporte nesse período. Aos meus colegas do Laboratório de TV Digital do Mackenzie: aos mestrandos pesquisadores pelo compartilhamento da vivência na elaboração de uma dissertação e grande ajuda na realização dos testes; à toda a equipe de professores, engenheiros, pesquisadores e administradores que ajudaram a sanar minhas dúvidas e foram muito importantes na construção do conhecimento sobre TV adquirido nos últimos anos. Essa convivência trouxe um significativo complemento na rotina e conhecimento durante o mestrado. Aos docentes do Programa de Pós Graduação em Engenharia Elétrica da Universidade Presbiteriana Mackenzie, pelas disciplinas lecionadas, que ajudaram no desenvolvimento da pesquisa, e pela disponibilidade em momentos de dúvidas. À minha namorada, Nathália Cunha, pela compreensão, apoio, carinho e companheirismo, mesmo em momentos de ausência. À minha família, que sempre suportou meus estudos, me incentivando e fazendo todo o possível para que eu conseguisse realizar a pesquisa. Ao Laboratório de TV Digital da Universidade Presbiteriana Mackenzie, pela bolsa de pesquisa e por disponibilizar todos os materiais utilizados, que viabilizaram a elaboração desta dissertação. Aos aportes do Programa CAPES RH-TVD, FINEP, CNPq e MACKPesquisa que foram importantes para a disponibilidade dos equipamentos presentes no Laboratório. iv

6 Have you heard - Pat Metheny

7 RESUMO Esta dissertação apresenta os conceitos, etapas e testes para o streaming IP de conteúdos de vídeo no sistema Dynamic Adaptive Streaming over HTTP (DASH). Toma-se essa tecnologia pois ela traz uma padronização do streaming HTTP, proposta pelo Moving Picture Experts Group (MPEG) e pelo International Organization for Standardization (ISO), com a ISO/IEC :2012. Primeiramente, é esclarecido o novo cenário de distribuição de conteúdos multimídia e seus desafios. Depois é apresentada a tecnologia DASH, com seu histórico e estruturação técnica. Também são explicados e exemplificados os conceitos de redes com base nos protocolos utilizados pelo DASH. Por fim, apresenta-se os testes práticos do DASH aplicado na distribuição de conteúdos televisivos em redes IP e sua reprodução em um dispositivo Mini-PC Android. O ensaio realizado em laboratório analisa a demanda de banda para reprodução do DASH codificado em constant bit rate (CBR) e adaptive bit rate (ABR) para limitações de banda de tráfego fixas e variáveis. Com os testes foi possível encontrar padrões de comportamento do DASH para as situações descritas. Palavras-chave: DASH, streaming, IP, rede de computadores, Android, ISDB-T B. vi

8 ABSTRACT This master thesis presents the concepts, steps and tests to stream a video content in a system called Dynamic Adaptive Streaming over HTTP (DASH). This technology is taken because it is a standardization of HTTP streaming, proposed by the Moving Picture Experts Group (MPEG) and International Organization for Standardization (ISO), with the ISO/IEC :2012 publication. Firstly, the new scenario of distributing multimedia content and his challenges are discussed. After this, the DASH technology is introduced with an historical and technical approach. Also, the network theory is explained following the protocols used by DASH. Lastly, the DASH practical tests are presented, focusing on the television contents distribution inside IP networks and it reproduction in an Mini-PC Android device. The tests analyses the network bandwidth demand for DASH reproduction coded for constant bit rate (CBR) and adaptive bit rate (ABR) with fixed and variable limitations on network bandwidth traffic. It was possible, with the tests, to find DASH behavior patterns to the situations described. Keywords: DASH, streaming, IP, computer networks, Android, ISDB-T B. vii

9 Lista de figuras Figura 1 Fluxo do sistema ISDB-T B Figura 2 Os quatro estágios do streaming Figura 3 Sistema de Comunicação de Shannon Figura 4 Transmissão simultânea de dois arquivos Figura 5 Assinaturas de Banda Larga Fixa (%) em relação ao desenvolvimento do país, Figura 6 Tempo de navegação de Internet por Velocidade de Conexão Figura 7 Comparativo da quantidade de assinaturas de Internet em banda larga fixa entre 2003 e Figura 8 Audiência de Internet por Velocidade de Conexão Figura 9 Composição do tráfego de Internet no período de pico para a América Latina e em acessos fixos Figura 10 Empacotamento ES no PES Figura 11 Método de inserção do PES no TS Figura 12 Método de multiplexação do TS Figura 13 Sistema de multiplexação do MPEG-2 Systems Figura 14 Estrutura do box MP Figura 15 Diagrama de estrutura do pacote mp Figura 16 Escopo da norma ISO/IEC : Figura 17 Hierarquia da MPD pela ISO/IEC : Figura 18 Diagrama de blocos do DASH Figura 19 Comparativo dos blocos ISDB-T B com o streaming Figura 20 Camadas do modelo OSI Figura 21 Comparação entre camadas do modelo OSI e TCP/IP Figura 22 Atribuição dos bits para classes de endereçamento IP Figura 23 Roteamento entre duas redes IP Figura 24 Distribuição dos bits do cabeçalho do datagrama IP Figura 25 Estrutura do datagrama IP Figura 26 Distribuição dos bits do cabeçalho do segmento UDP Figura 27 Distribuição dos bits do cabeçalho do segmento TCP Figura 28 Número de sequência do TCP Figura 29 Dinâmica da janela do TCP Figura 30 Abertura da conexão TCP

10 Figura 31 Exemplo de distribuição dos bits do cabeçalho do segmento TCP Figura 32 Fechamento da conexão TCP Figura 33 Estrutura pacote TCP/IP Figura 34 Conexão não persistente Figura 35 Conexão persistente com solicitações sequenciais Figura 36 Conexão persistente com solicitações em pipeline Figura 37 Formato da mensagem de requisição HTTP Figura 38 Formato da mensagem de resposta HTTP Figura 39 Distribuição dos bits do cabeçalho RTP Figura 40 Exemplo de distribuição dos bits do cabeçalho RTP Figura 41 Operação RTSP com RTP/RTCP e HTTP Figura 42 ZP1-20,02 ciclos/rad Figura 43 ZP2-160,18 ciclos/rad Figura 44 Setup de testes Figura 45 Quadro da sequência V Eighth Ave 1920x1088p30-8ave Figura 46 GK Figura 47 Variação da banda disponível - Padrão Decrescente Figura 48 Variação da banda disponível - Padrão Crescente Figura 49 Variação da banda disponível - Padrão Limites Alternados - início 8 Mbps Figura 50 Variação da banda disponível - Padrão Limites Alternados - início 256 kbps Figura 51 Variação da banda disponível - Padrão Alternado entre 8 Mbps e 4 Mbps. 96 Figura 52 Variação da banda disponível - Padrão Alternado entre 4 Mbps e 2 Mbps. 96 Figura 53 Variação da banda disponível - Padrão Alternado entre 2 Mbps e 1 Mbps. 97 Figura 54 Variação da banda disponível - Padrão Alternado entre 1 Mbps e 256 kbps Figura 55 Zone plate 1, após codificação H.264 em 1,438 Mbps pelo DASHEncoder. 98 Figura 56 Zone plate 1, após codificação H.264 em 1,845 Mbps pelo DASHEncoder. 99 Figura 57 Zone plate 1, após codificação H.264 em 2,205 Mbps pelo DASHEncoder. 99 Figura 58 Zone plate 2, após codificação H.264 em 1,438 Mbps pelo DASHEncoder.100 Figura 59 Zone plate 2, após codificação H.264 em 1,845 Mbps pelo DASHEncoder.100 Figura 60 Zone plate 2, após codificação H.264 em 2,205 Mbps pelo DASHEncoder.100 Figura 61 Eighth Ave, após codificação H.264 em 1,438 Mbps pelo DASHEncoder. 101 Figura 62 Eighth Ave, após codificação H.264 em 1,845 Mbps pelo DASHEncoder. 101 Figura 63 Eighth Ave, após codificação H.264 em 2,205 Mbps pelo DASHEncoder. 102 Figura 64 Exemplo de artefatos no vídeo Figura 65 Variação da taxa do zone plate 1 para banda ilimitada ix

11 Figura 66 Variação da taxa do zone plate 1 para banda limitada a 8 Mbps Figura 67 Variação da taxa do zone plate 1 para banda limitada a 4 Mbps Figura 68 Variação da taxa do zone plate 1 para banda limitada a 2 Mbps Figura 69 Variação da taxa do zone plate 1 para banda limitada a 1 Mbps Figura 70 Variação da taxa do zone plate 1 para banda limitada a 256 kbps Figura 71 Variação da taxa do zone plate 2 para banda ilimitada Figura 72 Variação da taxa do zone plate 2 para banda limitada a 8 Mbps Figura 73 Variação da taxa do zone plate 2 para banda limitada a 4 Mbps Figura 74 Variação da taxa do zone plate 2 para banda limitada a 2 Mbps Figura 75 Variação da taxa do zone plate 2 para banda limitada a 1 Mbps Figura 76 Variação da taxa do zone plate 2 para banda limitada a 256 kbps Figura 77 Variação da taxa demandada pela 8ave codificado em 1,438 Mbps Figura 78 Variação da taxa demandada pela 8ave codificado em 1,845 Mbps Figura 79 Variação da taxa demandada pela 8ave codificado em 2,205 Mbps Figura 80 Variação da taxa demandada por ZP1, codificado para ABR, em banda ilimitada Figura 81 Variação da taxa demandada por ZP2, codificado para ABR, em banda ilimitada Figura 82 Variação da taxa demandada por 8ave, codificado para ABR, em banda ilimitada Figura 83 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão decrescente Figura 84 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão decrescente Figura 85 Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão decrescente Figura 86 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão crescente Figura 87 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão crescente Figura 88 Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão crescente Figura 89 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps. 125 Figura 90 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps. 126 Figura 91 Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps. 127 x

12 Figura 92 Figura 93 Figura 94 Figura 95 Figura 96 Figura 97 Figura 98 Figura 99 Figura 100 Figura 101 Figura 102 Figura 103 Figura 104 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps xi

13 Figura 105 Figura 106 Figura 107 Figura 108 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps Área que representa a quantidade de kbits carregada no reprodutor até o instante de ZeroWindow Quantidade de pedaços de vídeo reproduzidos até o instante de ZeroWindow xii

14 Lista de tabelas Tabela 1 Tempo Mensal de Navegação por pessoa (hh:mm) - Dez/ Tabela 2 Lista dos países com maior quantidade de assinaturas de Internet fixa em Tabela 3 Limites mínimos de velocidade da banda larga ficam mais rigorosos.. 15 Tabela 4 Aplicações Top 10 de consumo da Internet no horário de pico na América do Norte em acessos fixos (Upstream e Downstream) Tabela 5 Capacidade mínima de backhaul em relação aos habitantes por município. 18 Tabela 6 Program Specific Information (PSI) Tabela 7 MPD gerada nos testes do DASH Tabela 8 Requisições HTTP do cliente para o servidor DASH Tabela 9 Classes de endereços IP Tabela 10 Máscara de sub-rede: divisão pela operação AND Tabela 11 Divisão de sub-redes Tabela 12 Quantidade de sub-redes em relação ao empréstimo de bits Tabela 13 Agrupamento em words Tabela 14 Somatória das words Tabela 15 Cabeçalho IP final Tabela 16 Cabeçalho IP no receptor Tabela 17 Cálculo da somatória no receptor Tabela 18 Caso de erro na transmissão Tabela 19 Mensagem requisição do Mini-PC Android Tabela 20 Alguns tipos de métodos de requisições HTTP Tabela 21 Resposta HTTP do reprodutor DASH Tabela 22 Alguns códigos de estados em respostas HTTP Tabela 23 Alguns tipos de métodos RTSP Tabela 24 Exemplo de troca de mensagens RTSP para SETUP Tabela 25 Exemplo de troca de mensagens RTSP para PLAY Tabela 26 Exemplo de troca de mensagens RTSP para PAUSE Tabela 27 Exemplo de troca de mensagens RTSP para TEARDOWN Tabela 28 Resumo da reprodução DASH - Sem erros ( ) ou com erros (X) Tabela 29 Tempo entre solicitação e reprodução para as sequências ZP1 e ZP

15 Tabela 30 Comparação das taxas de reprodução com as taxas de manutenção do streaming em DASH Tabela 31 Trecho do log da reprodução DASH Tabela 32 Resumo da reprodução para as sequências DASH, para ABR, em banda ilimitada Tabela 33 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão decrescente Tabela 34 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão crescente Tabela 35 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps.125 Tabela 36 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Tabela 37 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Tabela 38 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Tabela 39 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Tabela 40 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps Tabela 41 Resultado para quantidade de bits carregados para o reprodutor DASH até ZeroWindow Tabela 42 Resultado para quantidade de bits reproduzidos pelo reprodutor DASH até ZeroWindow Tabela 43 Tamanho do buffer do reprodutor DASH, em KBytes Tabela 44 Tamanho do buffer do reprodutor DASH, em segundos Tabela 45 Relação entre o momento de ZeroWindow (buffer completo) e fim do pico com a transição para a estabilidade xiv

16 Lista de siglas 3GPP AAC ABNT ABR ACK AHS ANATEL APP ASC ASI ATSC AVC BTS CAT CBQ CBR CDN CETIC CNAME CPU CR CSRC CWR DASH DCT DMB DQPSK DTS 3rd Generation Partnership Project Advanced Audio Coding Associação Brasileira de Normas Técnicas Adaptive Bit Rate Acknowledgment Adaptive HTTP Streaming Agência Nacional de Telecomunicações Application-specific Functions American Standard Code for Information Interchange Asynchronous Serial Interface Advanced Television Systems Committee Advanced Video Coding Broadcast Transport Stream Conditional Access Table Class Based Queuing Constant Bit Rate Content Delivery Network Centro de Estudos sobre as Tecnologias da Informação e da Comunicação Canonical Name Central Processing Unit Carriage Return Contributing Source Congestion Window Reduced Dynamic Adaptive Streaming over HTTP Discrete Cosine Transform Digital Multimedia Broadcasting Differential Quadrature Phase Shift Keying Decoding Time Stamp xv

17 DVB-T DVD DWT ECE ECN ES FDCT FIN FM GOP GSMA HAS HD HDTV HE HLS HTML HTTP IBOPE ICC IDCT IEC IETF IFFT IHL IID IIP IP IPD ISO ITU ISDB-T Digital Video Broadcasting - Terrestrial Digital Versatile Disc Discrete Wavelet Transform Explicit Congestion Notification Echo Explicit Congestion Notification Elementary Stream Forward Discrete Wavelet Transform Fim Frequência Modulada Groups of Pictures Global System for Mobile Communications Association HTTP Adaptive Streaming High Definition High Definition Television High Efficiency HTTP Live Streaming HyperText Markup Language Hypertext Transfer Protocol Instituto Brasileiro de Opinião Pública e Estatística Inter-channel Cross-Correlation Inverse Discrete Cosine Transform International Electrotechnical Commission Internet Engineering Task Force Inverse Fast Fourier Transform Internet Header Length Inter-channel Intensity Difference ISDB-T Information Packets Internet Protocol Interchannel Phase Difference International Organization for Standardization International Telecommunication Union Integrated System Digital Broadcasting - Terrestrial xvi

18 JVT LAN LF MIME MPD MPEG MTU MVD NIT NPT NTSC OFDM OSI OTT PAL PAT PC PCR PES PGMU PID PMT PNBL PNS PS PSH PSI PTS QAM QMF QPSK RAM Joint Video Team Local Area Network Line Feed Multipurpose Internet Mail Extensions Media Presentation Description Moving Picture Experts Group Maximum Transmission Unit Motion Vector Diference Network Information Table Normal Play Time National Television System Committee Orthogonal Frequency Division Multiplexing Open Systems Interconnection Over-the-top Phase Alternating Line Program Association Table Personal Computer Program Clock Reference Packetized Elementary Stream Plano Geral de Metas de Universalização do Serviço Telefônico Fixo Comutado Packet Identification Program Map Table Plano Nacional de Banda Larga Perceptual Noise Substitution Parametric Stereo Push Program Specific Information Presentation Time Stamp Quadrature Amplitude Modulation Quadrature Mirror Filter Quadrature phase-shift keying Random Access Memory xvii

19 RF RFC RR RST RTP RTCP RTMP RTSP SBR SD SDES SDI SMPTE SP SPI SR SSRC SYN TCP TS TNS TTL TV UDP UHF URG URL UTP VBR VCR VHF VLC Rádio Frequência Request For Comments Receiver Report Reset Real-time Transport Protocol Real-Time Transport Control Protocol Real Time Messaging Protocol Real-Time Streaming Protocol Spectral Band Replication Standard Definition Source Description Serial Digital Interface Society of Motion Picture and Television Engineers Space Serial Peripheral Interface Sender Report Synchronization Source Synchronize Sequence Numbers Transmission Control Protocol Transport Stream Temporal Noise Shaping Time To Live Televisão User Datagram Protocol Ultra High Frequency Urgente Uniform Resource Locator Unshielded Twisted Pair Variable Bit Rate Video Recorder Very High Frequency Variable Length Coding xviii

20 WAN XML ZP Wide Area Network extensible Markup Language Zone Plate xix

21 Sumário Lista de figuras Lista de tabelas Lista de siglas Sumário viii xiii xv xx 1 INTRODUÇÃO OBJETIVO ORGANIZAÇÃO DA DISSERTAÇÃO TV DIGITAL E SEUS NOVOS MODELOS NOVOS MODELOS DE DISTRIBUIÇÃO DE ÁUDIO E VÍDEO DI- GITAIS DESAFIOS DA BANDA LARGA BRASILEIRA Plano Nacional de banda larga (PNBL) DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH) AS TRÊS PRINCIPAIS FORMAS DE STREAMING Streaming Download progressivo Streaming adaptativo Início do streaming adaptativo ao surgimento DASH DASH - Abordagem técnica Codificação fonte: MPEG-2 Systems, compressão e empacotador DASH MPEG-2 systems Compressão do áudio: MPEG-4 HE-AAC Compressão do vídeo: H Empacotamento MP4Box

22 3.3.2 Estruturação do conteúdo e funcionamento do DASH CONCEITOS DE REDES IP APLICADOS AO STREAMING MODELOS OSI E TCP/IP Modelo OSI Camada de aplicação Camada de apresentação Camada de sessão Camada de transporte Camada de rede Camada de enlace de dados Camada física Modelo TCP/IP Camada de enlace Camada de Internet Camada de transporte Camada de aplicação CAMADA DE REDE: ENCAPSULAMENTO IP Endereçamento IP Cabeçalho IP Versão Internet header length (IHL) Tipo de serviço Tamanho Total Identificação Flags Offset do segmento Time to live (TTL) Protocolo Checksum do cabeçalho IP de Origem e Destino Opções e Padding Fragmentação IP xxi

23 4.2.4 Exemplo de aplicação IP no DASH CAMADA DE TRANSPORTE: UDP e TCP UDP Porta de origem e destino Tamanho total Checksum TCP Porta de origem e destino Número de sequência Número de confirmação Comprimento do cabeçalho Flags Tamanho da janela Checksum Ponteiro de urgência Opções Processo de abertura de conexão Processo de fechamento de conexão Exemplo de aplicação TCP no DASH CAMADA DE APLICAÇÃO: HTTP, RTP/RTCP e RTSP HTTP Estrutura da requisição Estrutura da resposta Sintaxe das mensagens HTTP RTP e RTCP RTP Exemplo de cabeçalho RTP possível nos testes RTCP RTSP Sintaxe das mensagens RTSP DASH: TESTES PRÁTICOS MATERIAL E METODOLOGIA xxii

24 5.2 RESULTADOS E DISCUSSÃO DO COMPORTAMENTO DA REDE PARA A REPRODUÇÃO DASH Reprodução do DASH, codificado em constant bit rate (CBR), com limitação de banda fixa Reprodução do DASH e a sua relação com as taxas de codificação Reprodução do DASH, codificado em adaptive bit rate (ABR), com limitação de banda variável Sequências em banda ilimitada Sequências em limitação no padrão decrescente Sequências em limitação no padrão crescente Sequências em limitação no padrão de limites alternados com início em 8 Mbps Sequências em limitação no padrão de limites alternados com início em 256 kbps Sequências em limitação no padrão de limites alternados entre 8 Mbps e 4 Mbps Sequências em limitação no padrão de limites alternados entre 4 Mbps e 2 Mbps Sequências em limitação no padrão de limites alternados entre 2 Mbps e 1 Mbps Sequências em limitação no padrão de limites alternados entre 1 Mbps e 256 kbps MEDIÇÃO DO BUFFER DO REPRODUTOR DASH (VLC) Procedimentos para o cálculo do buffer Resultados e discussão sobre o buffer do VLC (reprodutor DASH) CONCLUSÃO 148 Referências 150 xxiii

25 1 INTRODUÇÃO Atualmente se observa um forte crescimento do uso de dispositivos conectados em rede, tais como smartphones, tablets e set-top-boxes. Dados da International Telecommunication Union (2011) evidenciam que de 2006 a 2011 a quantidade de aparelhos celulares saltou de um número próximo de três bilhões, para aproximadamente seis bilhões. O mesmo documento traz a informação de que, no mesmo período, as assinaturas de banda larga móvel aumentaram 45% ao ano. Esse aumento fez com que, em 2011, o acesso à banda larga móvel chegasse, praticamente, ao dobro do número de assinaturas em relação ao mercado de Internet por cabo. Além do aumento na quantidade de aparelhos, o consumo de dados para cada dispositivo também está em forte crescimento. Na projeção da CISCO (2012) sobre o futuro do consumo de dados em aparelhos móveis mediu-se que em 2011 este estava em 0,6 Exabytes por mês e espera-se chegar a 10,8 Exabytes por mês em Desses dados, 48,3% serão consumidos por smartphones, 24,2% por laptops e notebooks e 10% por tablets. Em relação ao tipo de dado consumido, o mesmo white paper revela que o percentual do consumo de dados móveis para assistir vídeos em 2016 será de 70,5% do total. Assim, juntando as informações da International Telecommunication Union (2011) e da CISCO (2012), pode-se fazer uma projeção que em 2016 se estará consumindo algo em torno de 7,6 Exabytes por mês somente na visualização de vídeos em dispositivos móveis. Percebe-se, portanto, a tendência de fortalecimento de outros tipos de mídia para visualização de conteúdos multimídia, descentralizando o papel da televisão tradicional, pulverizando o conteúdo por meio de dispositivos móveis, convergentes e interconectados. Para possibilitar essa mudança midiática têm sido desenvolvidas diversas tecnologias para o streaming. Dentre os padrões criados, os mais conhecidos são o HTTP Dynamic Streaming da Adobe, o HTTP Live Streaming (HLS) da Apple e o Smooth Streaming Silverlight da Microsoft, todos com tecnologias proprietárias. Para atender a uma necessidade de convergência na utilização do streaming, foi desen- 1

26 volvido o Dynamic Adaptive Streaming over HTTP (DASH). Com a utilização do DASH ocorre uma interoperabilidade de sistemas, possibilitando a entrega, em plataformas diferentes, de um vídeo com streaming a uma taxa que se adapta com a taxa de download e processamento do dispositivo de visualização. Inclusive, por ser uma tecnologia nova, esta deve ser desenvolvida através da pesquisa, de forma a identificar seus nichos de possibilidades de implementação, e de promover constantes melhorias no sistema, que irão amadurecê-lo. 1.1 OBJETIVO É justamente no contexto dessas novas possibilidades que foi proposta a pesquisa ora relatada, que se volta ao estudo dessa nova tecnologia e à compreensão de suas características, com o objetivo de inserir as emissoras televisivas nessa nova realidade de consumo. A partir do entendimento da estrutura básica de streaming foca-se no estudo do DASH como uma possibilidade de complemento da distribuição dos conteúdos televisivos. Para tanto, busca-se verificar quais são os processos necessários para preparar o conteúdo que vai ao ar, via ISDB-T B, para que ele seja transmitido via streaming. Também é estudado, com os testes realizados, o comportamento do DASH, em constant bit rate (CBR) e adaptive bit rate (ABR), para diversas condições de disponibilidade de banda, que podem ser fixas ou flutuantes. 1.2 ORGANIZAÇÃO DA DISSERTAÇÃO Este trabalho apresenta no capítulo 2 um panorama histórico e os desafios no consumo de conteúdos multimídia, que parte da TV para novos modelos, com o advento das plataformas e sistemas para acesso a esse conteúdo via Internet. O capítulo 3 apresenta conceitos sobre o streaming e como o DASH se estrutura e funciona. No capítulo 4 são apresentados os principais conceitos de redes IP, com a teoria focada para a aplicação do streaming de áudio e vídeo. O capítulo 5 aborda os testes práticos realizados com o DASH, para diferentes configurações de taxa e limitações de banda. Nele é apresentada a metodologia utilizada e os resultados, que caracterizam o comportamento da demanda de banda para tecnologia DASH em diferentes situações. Por fim, o capítulo 6 apresenta as conclusões da dissertação e sugestões para trabalhos futuros. 2

27 2 TV DIGITAL E SEUS NOVOS MODELOS Atualmente o mundo presencia uma consolidação dos modelos de equipamentos digitais, em substituição aos analógicos. Tal mudança se faz presente pois a implementação digital tem assumido custos de fabricação cada vez menores e com qualidade e confiabilidade cada vez maiores, se comparadas às soluções analógicas (NVISION, 1996). Além das melhorias já relacionadas, a digitalização do sistema televisivo trouxe uma nova gama de ferramentas que vão desde o controle da processo da captação e produção, até a transmissão do sinal, com a flexibilização de configurações como formatos de áudio e vídeo, codificação e modulação (NVISION, 1999). Antes das transmissões digitais terrestres, desde meados da década de 90, já era possível obter uma programação digital televisiva por um sinal de satélite (ASAMI, 2005). Comercialmente, o início das transmissões digitais terrestres ocorrem em 1998, com o Advanced Television Systems Committee (ATSC), nos Estados Unidos e com o Digital Video Broadcasting - Terrestrial (DVB-T), na Europa (AKAMINE, 2004). Depois, em 2003, o Japão inicia a operação comercial do Integrated System Digital Broadcasting - Terrestrial (ISDB-T), mesmo ano no qual o Brasil criou um convênio para decisão do sistema de TV digital a ser adotado (YAMADA et al., 2004). É abordada nesta pesquisa a versão brasileira do padrão japonês, inaugurada no início de dezembro de 2007, em São Paulo (FÓRUM SBTVD, 2012). As principais diferenças entre o padrão japonês e o brasileiro estão na codificação da fonte, middleware e banda de operação. No sistema japonês é utilizado o H.264 para o codificação de vídeo one-seg 1, o padrão do Moving Picture Experts Group (MPEG), chamado MPEG-2, para a codificação do vídeo para os outros serviços e MPEG-2 Advanced Audio Coding (AAC) para a compressão do áudio (DIBEG, 2007). De acordo com o whitepaper do ministro japonês das telecomunicações, Asami (2005), a faixa espectral 1 Transmissão 1seg é utilizada para dispositivos móveis, caracterizada por utilizar um único segmento da modulação BST-OFDM (BEDICKS JUNIOR, 2008) 3

28 destinada para a radiodifusão 2 da televisão digital japonesa é a Ultra High Frequency (UHF). Vale ressaltar que a canalização do espectro japonês é diferente da estipulada no brasileiro (BEDICKS JUNIOR, 2008). A versão brasileira do ISDB-T se difere da japonesa pois o codec utilizado é o H.264 para vídeo e o MPEG-4 HE AAC para o áudio. Para o middleware desenvolveu-se uma plataforma brasileira, conhecida como Ginga, que permite a interatividade do telespectador com conteúdos fornecidos pela emissora. Outra diferença é que o ISDB-T B pode trabalhar tanto na faixa dos canais de 7 a 13, em Very High Frequency (VHF), como utilizar os canais 14 a 69, em UHF (AKAMINE et al., 2009). Para uma compreensão global do ISDB-T B, a ABNT (2007) apresenta um fluxo básico do sistema de transmissão, separando-o em codificador, multiplexador, modulador e amplificador, conforme a figura 1. O tipo de entrada neste sistema será o áudio, vídeo ou dados em um fluxo Transport Stream (TS), em acordo com o MPEG-2 system. Estes serão remultiplexados para criar um único TS que irá para o modulador, que modulará o sinal, preparando-o para ser transmitido, a partir de uma estrutura Orthogonal Frequency Division Multiplexing (OFDM) com 13 segmentos sucessivos, cada um com 1/14 da largura do canal de televisão (que podem variar entre 5,572MHz, 5,573MHz ou 5,575MHz, de acordo com o modo utilizado). Depois desse processo, o sinal de Rádio Frequência (RF) será amplificado para ser irradiado pela antena em determinada área de cobertura (ABNT 15601, 2007). Figura 1: Fluxo do sistema ISDB-T B. Fonte: ABNT (2007, p. 4). Além dos modelos de radiodifusão, existe um outro modelo de consumo de conteúdo de áudio e vídeo que vem angariando muitos espectadores: o streaming 3 de vídeo pela 2 Anatel (2012) define radiodifusão como serviço de radiodifusão a TV analógica e digital, além do rádio em frequência modulada (operando na faixa de FM) ou amplitude modulada (operando nas na faixa de ondas médias, curtas e tropicais) 3 Austerberry (2005a) define o streaming, no que se diz respeito ao audiovisual, como consumir um 4

29 Internet. A CISCO (2012) projeta que em 2016 dois terços do tráfego de dados mundial será por conta do vídeo, indicando esse expressivo aumento. Austerberry (2005b) traz o fluxo desse tipo de sistema de transmissão multimídia por uma rede Internet Protocol (IP), dividindo-o em quatro macro-blocos. O primeiro é a captura do som e da imagem que serão codificados, resultando em arquivos comprimidos. O segundo bloco é do servidor que armazenará esses arquivos e controlará o streaming. Já a terceira etapa será a distribuição do conteúdo multimídia a partir do uso de uma rede de internet, que leva à última etapa do processo: a visualização do conteúdo em um tocador de mídia. Esse reprodutor, que pode ser um software adicionado como plug-in em um navegador de internet, receberá o stream e o descomprimirá, possibilitando que se veja e ouça o conteúdo transmitido (AUSTERBERRY, 2005b). Pode-se observar o referido sistema na figura 2, apresentada a seguir. Figura 2: Os quatro estágios do streaming. Fonte: Austerberry (2005b, p. 139). Percebe-se que ambos os diagramas são bem similares, pois obedecem os princípios descritos por Shannon (1948), que definiu que um sistema de comunicação consiste em essencialmente cinco partes, conforme a figura 3. A primeira delas é a fonte de informação, conteúdo na medida que ele chega diretamente de algum emissor. 5

30 que produz as mensagens que serão enviadas ao receptor. A segunda é o transmissor, que tem como característica modificar a mensagem para possibilitar a sua transmissão no canal. Esse se configura na terceira parte do sistema, que é o meio pelo qual a mensagem se propagará entre o transmissor e o receptor. É importante ressaltar que o meio pode ser ruidoso, introduzindo erros na mensagem original. O próximo bloco é o receptor, que realiza exatamente o processo inverso do transmissor, buscando reconstituir a mensagem original a partir de um processo de decodificação. Por fim, tem-se o destinatário, para quem a mensagem foi designada (SHANNON, 1948). Figura 3: Sistema de Comunicação de Shannon. Fonte: Shannon (1948, p. 2). 2.1 NOVOS MODELOS DE DISTRIBUIÇÃO DE ÁUDIO E VÍDEO DIGITAIS A Forrester Research realizou uma pesquisa publicada no portal AdAge em março de 2012, que evidencia uma nova realidade no uso das horas livres dos brasileiros. Para tanto, foram entrevistados 2006 brasileiros maiores que 16 anos, e estes afirmaram passar, em uma média semanal, 6,2 horas de seu tempo livre assistindo televisão, enquanto no mesmo período os entrevistados alegaram tomar 23,8 horas semanais na Internet. Dessas pessoas, 86% reportam assistir vídeos na web (DELO, 2012). Estes dados evidenciam um novo paradigma de consumo de conteúdos audiovisuais, pois a maioria das pessoas entrevistadas realizam tal consumo a partir do uso da internet. Assim, a televisão deixa de ser o único meio de se assistir um vídeo, que agora compete com outras mídias interconectadas, 6

31 como o computador, celular e tablets. Dessa forma, as referidas mudanças conduzem ao desenvolvimento de novas tecnologias para atender a uma nova demanda. Uma dessas tecnologias, que surgiu na década de 1990, trata-se de umas das principais técnicas de visualização de vídeos na Internet: o streaming de mídia. Este se dá com o lançamento do RealPlayer da RealNetworks, que possibilitava visualizar streaming de conteúdos multimídia em seu aplicativo (OZER, 2011a). Porém o Windows Media foi o formato que, por volta de 2005, conseguiu a maioria do mercado de distribuição de vídeos streaming, já que a RealNetworks passava por períodos de dificuldades financeiras (OZER, 2011a). Também em 2005, a Macromedia Flash adicionou a tecnologia de codificação On2 Technologies VP6 aos seus produtos, o que o tornou competitivo em relação ao Windows Media, tanto que Ozer (2011a) afirma que em 2009 a maioria dos sites estava estruturado em Flash. A fim de continuar seu desenvolvimento no mercado de visualização de streaming a Microsoft lança em 2007 o Silverlight, sua nova plataforma, muito similar ao Flash. Em 2010 existe um novo cenário, com a decisão da Apple de não lançar o ipad compatível com o Flash e sim com o HTML5, uma atualização do código HyperText Markup Language (HTML). Essa nova versão da linguagem de marcação utiliza uma video tag, possibilitando o carregamento do vídeo pelo navegador (browser), a partir da utilização de um comando do código fonte HTML, não necessitando de plug-ins de aplicativos proprietários para visualizar o vídeo (OZER, 2011a). Juntamente a este cenário, o mundo já enfrentava um crescente consumo de banda nos dispositivos móveis em meio a uma diversidade de plataformas para se assistir vídeos, sendo muitas delas não compatíveis entre si e proprietárias. Tal situação é comprovada pela CISCO (2012), que relata que só no período entre 2011 e 2016 é previsto um aumento de 78% no tráfego de dados em dispositivos móveis. Como agravante para se assistir vídeos em redes móveis ainda se enfrenta uma variação na banda disponível para downloads e uploads, devido às sobrecargas em determinados horários e oscilação da intensidade do sinal. Assim, em 2009, o 3rd Generation Partnership Project (3GPP) decide realizar um padrão para distribuição de mídia em redes com taxas variáveis, com a intenção de suprir essas futuras demandas de consumo multimídia. Além dos diferentes formatos de distribuição streaming, outro motivo para se desenvolver um novo modelo se dá no fato de que 7

32 o padrão de pacotes da 3GPP, utilizado para o streaming multimídia em redes móveis, era o Real-Time Streaming Protocol (RTSP). Tal protocolo é normalmente utilizado para controle do vídeo, na camada de aplicação do modelo OSI, e requer uma infraestrutura exclusiva, além de ter problemas ao passar por firewalls. Já o novo padrão seria baseado no Hypertext Transfer Protocol (HTTP), totalmente convergente com as redes de Internet, além de uniformizar o modo de se distribuir os conteúdos tanto para a Internet, como para os dispositivos móveis (LOHMAR et al., 2011). O nome desse novo modelo ficou conhecido como Dynamic Adaptive Streaming over HTTP (DASH). Posteriormente, o MPEG utilizou como guia o documento 3GP-DASH para realizar sua contribuição no desenvolvimento do sistema, elaborando o padrão MPEG-DASH (LOHMAR et al., 2011). 2.2 DESAFIOS DA BANDA LARGA BRASILEIRA Até aqui foram apresentadas tecnologias que possibilitam a recepção de conteúdos de áudio e vídeo pela Internet, com destaque para o streaming utilizando a nova solução, chamada DASH. Porém para que esta nova forma de consumo de conteúdo audiovisual se torne uma realidade é preciso que haja uma infraestrutura que suporte essa demanda, que aumenta o tráfego pelas redes de Internet. É importante compreender que cada usuário que entra na rede irá aumentar a partilha da banda máxima disponível. Isso acontece pois uma rede de tráfego de dados tem como característica intercalar vários pacotes de dados de usuários diferentes transmitindo-os em um único canal, conforme explica Torres (2001). Na figura 4 é exemplificado esse tipo de transmissão de pacotes de dados, no caso dos computadores A e C para o terminal B. Por esse motivo o autor afirma que a velocidade de transmissão em uma rede de dados é altamente dependente do número de transmissões simultâneas e da demanda de cada usuário. Assim, para que se possa aumentar a capacidade da rede, possibilitando o aumento no número de usuários e da banda disponível para cada um, é preciso investir em uma grande infraestrutura, que envolve novas tecnologias de equipamentos, conexões e protocolos. O Brasil, assim como todo o mundo, enfrenta uma forte demanda para o crescimento da banda disponível da Internet, principalmente quando o fluxo de informação envolve dispositivos móveis. Ricardo Tavares, o vice-presidente de políticas públicas da Global 8

33 Figura 4: Transmissão simultânea de dois arquivos. Fonte: Torres (2001, p. 37). System for Mobile Communications Association (GSMA), organização que representa as operadoras de telefonia móvel, afirmou para revista Info Exame, da Editora Abril, que apesar do aumento da quantidade de celulares ele não vê a possibilidade de acontecer um problema de apagão das ligações de telefones móveis, mas afirma que há um risco desse colapso acontecer na disponibilidade de banda larga utilizada por esses aparelhos. Para Tavares, esse problema tem como causador a falta de investimentos em backhaul, que são as redes de fibra óptica responsáveis por carregar as informações da rede de telefonia móvel (EXAME INFO, 2009). De fato, o crescimento acelerado na quantidade de dados trafegados via web, com o uso de dispositivos móveis conectados, projeta um crescimento exponencial da demanda de banda. A International Telecommunication Union (2013) traz dados que evidenciam o problema do acesso à Internet em banda larga fixa, mostrando a grande disparidade desse tipo de acesso, entre países desenvolvidos e em países em desenvolvimento, conforme observa-se na figura 5. Vale ressaltar que a International Telecommunication Union (2013) considera como banda larga acessos à Internet com velocidades superiores a 256 kbps. Trazendo a realidade brasileira, o IBOPE Nielsen Online (2013) apresenta dados, expostos na tabela 1, que apontam que o Brasil está em primeiro lugar na lista mundial do tempo mensal de navegação na Internet por pessoa, superando países como França e 9

34 Porcentual dos habitantes Desenvolvidos Mundo Em Desenvolvimento * 2013* Ano 27,2 Figura 5: Assinaturas de Banda Larga Fixa (%) em relação ao desenvolvimento do país, Fonte: International Telecommunication Union (2013, p. 4). *Nota: Dados Estimados. 9,8 6,1 Alemanha. Desta forma fica evidente que existe demanda brasileira por crescimento do acesso à Internet. Tabela 1: Tempo Mensal de Navegação por pessoa (hh:mm) - Dez/2012 Posição País Navegação em Páginas 1 o Brasil 43:57 2 o França 39:23 3 o Alemanha 37:23 Fonte: Adaptado de IBOPE Nielsen Online (2013). Tais tempos de navegação podem ser interpretados como espera no download e upload, o que infere que seria possível uma redução no tempo de uso caso a velocidade de acesso fosse maior. Porém, a figura 6 evidencia que, independente da velocidade de acesso à Internet, o Brasil ainda está em primeiro lugar nesse requisito, entre os países comparados. Não é somente no tempo de navegação que o Brasil está na frente de países considerados desenvolvidos, mas também na quantidade de assinaturas de Internet fixa. A figura 7 mostra que em 2007 o Brasil superou a Espanha, em 2008 o Canadá, no ano de 2010 a Itália e em 2012 estava muito próximo à Coréia do Sul. Com esse crescimento o Brasil, em 2012, figura como o nono país da lista mundial desse tipo de conexão, conforme é mostrado na tabela 2 (INTERNATIONAL TELECOMMUNICATION UNION, 2013). 10

35 Brasil Itália Espanha França Reino Unido Austrália Alemanha EUA Suíça 10:00:53 30:59:15 31:54:42 31:57:18 30:53:42 24:49:13 24:20:36 22:15:38 21:57:51 25:57:01 28:05:41 24:52:04 22:28:58 26:48:23 28:43:32 25:58:04 28:30:36 22:40:30 24:17:33 22:07:13 23:08:07 22:40:30 24:17:33 22:07:13 20:49:52 28:24:53 28:29:23 26:52:39 27:25:20 25:48:11 27:22:21 26:23:37 25:33:04 21:19:58 20:14:46 17:38:18 0:00:00 4:48:00 9:36:00 14:24:00 19:12:00 24:00:00 28:48:00 33:36:00 Acima de 8Mb 2Mb - 8Mb 512kb - 2Mb Abaixo de 512kb Figura 6: Tempo de navegação de Internet por Velocidade de Conexão. Fonte: Adaptado de Nielsen (2011, p. 2). Tabela 2: Lista dos países com maior quantidade de assinaturas de Internet fixa em Posição País Assinaturas de Internet Banda Larga Fixa 1 o China o Estados Unidos o Japão o Alemanha o França o Reino Unido o Rússia o Korea do Sul o Brasil o Índia Fonte: Adaptado de International Telecommunication Union (2013). 11

36 Milhões de Acessos Fixos Rússia Coréia do Sul Brasil Itália Canadá Espanha Supera Espanha Próximo à Coréia Supera Canadá Supera Itália Ano Figura 7: Comparativo da quantidade de assinaturas de Internet em banda larga fixa entre 2003 e Fonte: Adaptado de International Telecommunication Union (2013). O crescimento dos dados relacionados ao tempo de navegação e de número de usuários demonstram que a demanda por Internet está sendo atendida de certa forma, pois ao contrário não haveria crescimento. Porém, é importante refletir quanto a qualidade da Internet entregue ao consumidor, principalmente no que se diz respeito à velocidade de acesso. Também em relação à taxa de transferência, a figura 8 mostra a distribuição da audiência de Internet por velocidade de conexão em diferentes países. Os dados apresentados revelam que os países que nas comparações anteriores estiveram atrás do Brasil fornecem uma velocidade média do serviço de banda larga bem superior ao brasileiro. O percentual de acessos com velocidades maiores que 2 Mbps dos oito países que são comparados ao Brasil estão entre os valores de 88% na Suíça e de 64% na Austrália e Itália, enquanto no Brasil esta realidade está em somente 21% da audiência conectada. O cenário brasileiro tem quase metade de acessos realizados a uma taxa de 512 kbps a 2 Mbps, sendo que 79% da população internauta navega com velocidades abaixo de 2 Mbps. O impacto da baixa média de velocidade de Internet brasileira se dá em serviços como 12

37 Figura 8: Audiência de Internet por Velocidade de Conexão. Fonte: Adaptado de Nielsen (2011, p. 1). armazenamento e utilização de dados em nuvem 4 e visualização de vídeos na web, já que a velocidade de conexão é um fator muito importante para que se consiga utilizar serviços. Atualmente o serviço de streaming de vídeo é altamente impactado pelo perfil da velocidade de Internet brasileira. É preciso considerar também que as maiores operadoras de banda larga residenciais trabalham em um modelo de negócio no qual a banda fornecida ao cliente é compartilhada entre vários usuários, não sendo um link dedicado, conforme contrato da Vivo (2012) e da NET (2011). Desta forma, ao analisar o contrato dessas empresas está claramente explicitado que as velocidades contratadas são nominais máximas e sujeitas a variações decorrentes, entre outros motivos, da quantidade de pessoas conectadas ao mesmo tempo ao provedor (VIVO, 2012). Inclusive, o contrato da NET (2011), além de explicitar que a velocidade contratada é a máxima, existe uma cláusula que garante ao cliente somente 10% da velocidade nominal contratada. Juntando essas condições com os dados apresentados na figura 8, pode-se chegar a estabelecer um cenário no qual 79% dos clientes brasileiros terão como garantia velocidades abaixo de 200 kbps (10% de 2 Mbps). Para se ter uma idéia de quão baixa é essa taxa 4 No documento do National Institute of Standards and Technology Badger et al. (2011, p. 2-1) definem Cloud Computing como um modelo que possibilita um acesso, por conveniência e demanda, a uma rede que compartilha um banco de recursos computacionais (por exemplo, armazenamento, aplicativos e serviços) que podem ser rapidamente fornecidos e liberados com mínimo gerenciamento e interação com o provedor. 13

38 basta verificar algumas recomendações mínimas de perfis de streaming. Por exemplo, para se utilizar o HTTP Live Streaming (HLS) da Apple são estabelecidos, pela empresa, alguns perfis que relacionam resolução e qualidade à taxas de transmissão. O perfil com a menor taxa de bits com som e imagem é com o vídeo em 480x320, transmitido por uma rede de celular com a taxa total de 150 kbps (APPLE INC., 2011). No caso da Adobe, utilizando o HTTP Dynamic Streaming, a menor taxa recomendada é para uma imagem 512x288, que se configura em 400 kbps (LEVKOV, 2010). Assim, em ambos os casos a maioria dos brasileiros, no cenário exemplificado neste parágrafo, estariam no limiar das recomendações, existindo a possibilidade de talvez nem conseguirem visualizar o vídeo no perfil mais simples possível. Portanto, se forem comparados os dados de tempo de acesso, aspecto no qual o Brasil lidera o ranking, com a posição do país em velocidade de Internet, fica claro que novos investimentos no setor são extremamente necessários e urgentes. Sobre esses tipos de aplicações em nuvem, Rafique et al. (2011) defendem que para que exista um desenvolvimento na área de comunicação é necessário que existam redes confiáveis de alta velocidade de transmissão. Somente com um investimento nas redes de transmissão, visando melhorias em sua capacidade e confiabilidade, será economicamente viável o uso de serviços em nuvem (RAFIQUE et al., 2011). A demanda por tais investimentos é tão grande que ela deixou de ser interesse unicamente das empresas fornecedoras de serviços em nuvem, mas também do Governo Federal brasileiro, que criou, em 2010, um plano para acesso a banda larga no Brasil, conhecido como PNBL. No documento base do programa é dito que um fator limitante à ampliação do acesso à internet em banda larga por meio de diferentes plataformas tecnológicas é a carência de infraestrutura (BRASIL, 2010). Vale ressaltar que a ANATEL tem estabelecido novos limites para melhoria da velocidade entregue ao usuário, com um plano de metas entre 2012 e 2014, conforme tabela 3. A partir de novembro de 2013, definiu-se que o valor médio mensal da velocidade deve ser pelo menos 70% da contratada e que a velocidade instantânea mínima deve ser 30% da contratada (ANATEL, 2013). Dados do relatório semestral da Sandvine (2013) trazem que a realidade da alta demanda de tráfego da rede para consumo de conteúdos multimídia via streaming. No fechamento do ano de 2013 confirma-se essa realidade pois, conforme confronta-se na tabela 4, as duas aplicações que mais consomem banda de Internet para download na 14

39 Tabela 3: Limites mínimos de velocidade da banda larga ficam mais rigorosos Data Taxa Média Taxa Instantânea Mudança (download e upload) (download e upload) Novembro de % da máxima contratada 20% da máxima contratada Novembro de % da máxima contratada 30% da máxima contratada Novembro de % da máxima contratada 40% da máxima contratada Fonte: Adaptado de ANATEL (2013). América do Norte, durante o período de pico, Netflix e Youtube, são de streaming de áudio e vídeo. Se somados seus porcentuais chega-se a 50,31% do tráfego de downloads da Internet no período de maior acesso. Apesar do consumo de vídeo demandar uma taxa maior de download do que upload a tabela traz que essas duas empresas também ocupam de relevância em Upstream, com o Netflix em 4 o e YouTube em 5 o lugar. Tabela 4: Aplicações Top 10 de consumo da Internet no horário de pico na América do Norte em acessos fixos (Upstream e Downstream). Upstream Downstream Posição Aplicação Porcentual Aplicação Porcentual 1 BitTorrent 36,35% Netflix 31,62% 2 HTTP 6,03% YouTube 18,69% 3 SSL 5,87% HTTP 9,74% 4 Netflix 4,44% BitTorrent 4,05% 5 YouTube 3,63% itunes 3,27% 6 Skype 2,76% MPEG 2,60% 7 QVoD 2,55% SSL 2,05% 8 Facebook 1,54% Amazon Video 1,61% 9 FaceTime 1,44% Facebook 1,31% 10 Dropbox 1,39% Hulu 1,29% Fonte: Adaptado de Sandvine (2013). O cenário para a América Latina também não diverge dos resultados obtidos para a América do Norte, conforme observa-se na figura 9. Destaca-se na figura 9 o porcentual para a categoria de Entretenimento em Tempo Real, que ocupa a maior porcentagem em todas as comparações, com valores próximos à metade dos downloads e mais do que o dobro consumido na navegação web. O relatório da Sandvine (2013) define a categoria de Entretenimento em Tempo Real como streaming de áudio e vídeo. Portanto, conclui-se que também na América Latina o porcentual de demanda para esse tipo de consumo de conteúdo é bem elevado. 15

40 100% 90% 80% 70% 10,45% 8,19% 8,65% 3,04% 3,19% 10,99% 8,13% 8,59% 9,28% 14,41% Outros Tunneling 60% 50% 41,46% 22,23% 20,39% Redes Sociais 40% ComparGlhamento de Arquivos 30% 20% 10% 10,64% 21,81% 49,13% 44,78% Navegação Web Entretenimento em Tempo Real 0% Upstream Downstream Valor Agregado Figura 9: Composição do tráfego de Internet no período de pico para a América Latina e em acessos fixos. Fonte: Adaptado de Sandvine (2013, p. 23). O relatório da Sandvine (2013) também traz dados comparativos relacionado à um novo produto do Netflix, que já é um alto consumidor de tráfego, e com sua novidade tenderá a aumentar ainda mais seu consumo. A empresa realizou o lançamento do Streaming em Super HD 1080p. Os dados apresentados mostram que a taxa máxima para visualização de conteúdos HD 1080p pelo Netflix chega a 3850 kbps. Mas com seu novo produto ela chegará a 5800 kbps, ou seja, uma diferença de 50,6%. Dessa forma, pode-se inferir que futuramente os números da demanda do Netflix tendem a aumentar ainda mais. Em suma, os dados apresentados mostram que o streaming de áudio e vídeo traz uma elevada demanda por banda de Internet, tanto para o mercado da América do Norte quanto a Latina. A análise do relatório também mostra que essa é uma realidade mundial, já que para os outros continentes apresenta-se um cenário muito similar. 16

41 2.2.1 Plano Nacional de banda larga (PNBL) Em 15 de setembro de 2009 o então presidente da República, Luiz Inácio Lula da Silva, convocou uma reunião com os Ministérios envolvidos com a inclusão digital no intuito de que todos eles elaborassem um programa em comum, que visasse a ampliação do número de usuários com acesso à Internet em banda larga em todo o Brasil. Especialistas em infraestrutura, regulação e serviços foram convidados para elaborar o programa, apresentando a proposta final ao presidente da República em reunião no dia 8 de abril de Depois, em 13 de maio de 2010 foi publicado no Diário Oficial da União o Decreto n o 7175, instituindo o Programa Nacional de Banda Larga (BRASIL, 2010). A referida política pública é de importante atenção ao desenvolvimento do uso de serviços de streaming multimídia no Brasil, já que o próprio conceito de banda larga adotado no programa envolve o áudio e vídeo, conforme trecho extraído do documento base do PNBL: O acesso em banda larga é caracterizado pela disponibilização de infraestrutura de telecomunicações que possibilite tráfego de informações contínua, ininterrupto e com capacidade suficiente para aplicações de dados, voz e vídeo mais comuns ou socialmente relevantes (BRASIL, 2010, p. 18). Tal programa tem como fator motivacional que o acesso a banda larga está intimamente ligado ao desenvolvimento econômico e social de um país. Isso porque quanto maior o ingresso de usuários com internet de alta velocidade maior será o mercado potencial para serviços pela rede, que demandará mais investimento no setor, tornando-se um ciclo virtuoso de desenvolvimento tecnológico e econômico (BRASIL, 2010). Quanto ao social, o aumento do acesso inclui o cidadão, pois ele poderá utilizar serviços públicos digitais, como governo eletrônico, educação à distância e bancos, além do acesso à cultura, informação e entretenimento (como vídeos, música e redes sociais) (BRASIL, 2010). Para aumento do acesso a banda larga o PNBL propõe o foco, inicialmente, no desenvolvimento de uma infraestrutura de rede com capacidade de suportar o aumento da banda requerida pelo desenvolvimento do programa. Essa estrutura também deverá ser o mais abrangente possível de tal forma a disponibilizar o serviço para toda a população, seja ela urbana ou rural, central ou periférica, rica ou pobre. O segundo foco inicial está 17

42 em políticas produtivas e tecnológicas, visando melhorar o sistema regulatório do setor (BRASIL, 2010). Os pilares do PNBL são três: redução de preço, aumento de cobertura e aumento da velocidade. Assim, o primeiro irá facilitar as condições para se ter o serviço, o segundo procura não restringir o acesso ao local de moradia do usuário e o terceiro visa a igualdade do país com a realidade do resto do mundo (BRASIL, 2010). Para tal, as ações do PNBL abordam algumas áreas específicas. Uma delas é a regulação e normas de infraestrutura, para aumentar a competitividade no setor e a oferta do serviço. Outras ações envolvem incentivos fiscais, para reduzir os custos repassados aos cidadãos. Também existem medidas que incentivam uma política produtiva e tecnológica, investindo na indústria nacional. Outros esforços estarão na criação de uma rede nacional de fibras ópticas, sob domínio da União, operada pela Telebrás, que pretende atingir municípios até 2014 (BRASIL, 2010). Quanto à capacidade de backhaul, o Decreto n. o 6424/2008 estabelece uma relação entre número de habitantes em cada cidade e a velocidade mínima de conexão nelas, conforme a tabela 5 (BRASIL, 2010). O decreto está dentro do Plano Geral de Metas de Universalização do Serviço Telefônico Fixo Comutado (PGMU), que foi revisado em junho de 2011, mantendo as metas do decreto de 2008 para o quinquênio (Computer World, 2011). Tabela 5: Capacidade mínima de backhaul em relação aos habitantes por município. Quantidade de habitantes Capacidade mínima de backhaul até 20 mil 8 Mbps entre 20 e 40 mil 16 Mbps entre 40 e 60 mil 32 Mbps acima de 60 mil 64 Mbps Fonte: Adaptado de Brasil (2010). Dessa forma, caso o PNBL consiga ter suas metas atingidas, a situação da Internet brasileira terá grandes avanços, melhorando o mercado de serviços que a utiliza como meio de atendimento de seus clientes. Trazendo este fato para o escopo deste trabalho, existe um modelo de distribuição de conteúdos multimídia, chamado over-the-top (OTT), que se beneficiará com as medidas do PNBL. Os serviços de vídeo OTT têm como característica o fornecimento do conteúdo audiovisual utilizando uma rede não gerenciada pelas empresas 18

43 fornecedoras deste conteúdo (ROSENBLATT, 2011). Desta forma elas só disponibilizam seus serviços, ficando a cargo do seu cliente a contratação de uma outra empresa para fornecer o meio de transmissão deste conteúdo até o usuário. Este modelo se diferencia em relação aos emissores broadcast, que utilizam como meio de entrega do conteúdo uma rede gerenciada por eles mesmos, não terceirizando-a (ROSENBLATT, 2011). 19

44 3 DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH) Conforme apresentado no capítulo 2, atualmente existe uma forte demanda no consumo de áudio e vídeo pela Internet, que é realizado por diversas tecnologias de streaming. Justamente sobre essas técnicas que este capítulo aborda, com o foco na sua nova versão, o DASH. Primeiramente são abordados os três principais procedimentos para distribuição e visualização multimídia na Internet. Depois é apresentado o panorama para surgimento do DASH e, posteriormente, como se estrutura e funciona essa nova tecnologia. 3.1 AS TRÊS PRINCIPAIS FORMAS DE STREAMING Nesta seção são explicados alguns conceitos principais das formas de distribuição e visualização multimídia na internet: streaming, download progressivo e o streaming adaptativo. Após essa exposição será possível explicar o DASH e seu caráter híbrido Streaming Austerberry (2005a) define que para existir um streaming de vídeo o receptor deve visualizar o conteúdo em tempo real imediatamente no momento de chegada deste conteúdo, em um processo contínuo. Tal característica de recepção tem uma forma similar ao início da televisão, há por volta de 70 anos, em que o sinal das câmeras e microfones dos estúdios eram enviados continuamente aos televisores, que exibiam a programação na medida que esta era capturada (AUSTERBERRY, 2005a). Em uma abordagem técnica, Ozer (2011a) defende que um stream deve ser entregue via um servidor streaming, que difere de um servidor web, que é mais utilizado para websites, textos em HyperText Markup Language (HTML), imagens e arquivos. Um aspecto a ser considerado em relação ao streaming é a disponibilidade de conteúdos a uma taxa de bit fixa. Para que o cliente possa assistir um vídeo com uma determinada 20

45 taxa de bits ele terá que ter um link com uma taxa igual ou superior à do conteúdo para possibilitar uma fluência na visualização. Caso contrário, o consumidor teria que esperar um trecho do vídeo ser armazenado na máquina (processo conhecido como buffer) para depois continuar a reprodução, gerando uma interrupção na visualização. O que pode acontecer no streaming com taxas não compatíveis é que o vídeo irá começar a ser reproduzido e depois irá parar, sendo essa uma das principais reclamações relacionadas a esta forma de distribuição de conteúdo (AUSTERBERRY, 2005c). Esta é uma situação análoga a uma empresa que deve ter uma taxa de entrega de um produto igual à sua produção para que a velocidade de fabricação seja repassada ao cliente, caso contrário o produto ficará estocado na espera de ser entregue. Um outro fator a se considerar em relação à taxa de bit é que a conexão entre o servidor e o cliente normalmente está exposta a diferentes interferências (eletromagnéticas, atenuações atmosféricas, espalhamento óptico etc.) e a congestionamentos da rede em horários de pico. Tais intervenções ocasionarão uma variação da taxa de bits disponível durante o tempo de conexão. Desta forma, as interrupções na visualização do vídeo acontecerão todas as vezes que a taxa do link variar para um valor menor que a taxa do vídeo Download progressivo Em relação ao método download progressivo, Ozer (2011a) caracteriza-o pela entrega do conteúdo utilizando um servidor web de Hypertext Transfer Protocol (HTTP). O uso desta estrutura traz um vantagem em relação a utilização de servidores exclusivos streaming, pois os servidores web estão implementados em todo mundo, já que eles são, em sua maioria, os responsáveis pela navegação em sites na web. No download progressivo, o cliente faz um download do áudio e vídeo e estes são armazenados no Hard Disk (HD) do dispositivo e a partir do disco rígido o conteúdo é exibido. Justamente pelo vídeo ficar armazenado com o cliente este poderá copiá-lo e distribuí-lo, o que preocupa alguns produtores de conteúdo detentores de direitos autorais. Por esse motivo muitos preferem utilizar o streaming, que não armazena o vídeo de forma completa no HD do cliente (OZER, 2011a). O download progressivo também possibilita a distribuição de conteúdos audiovisuais codificados em altas taxas, pois caso o cliente tenha uma conexão a uma baixa taxa ele trocará um período de espera de download por uma melhor qualidade de imagem e som. Esta situação se assemelha ao streaming, porém uma vez que o vídeo estiver no HD 21

46 do cliente este poderá visualizá-lo novamente de seu dispositivo, enquanto no streaming o conteúdo que chega é diretamente visualizado e descartado (AUSTERBERRY, 2005b) Streaming adaptativo Além da questão dos direitos autorais, com a finalidade de evitar o problema de pausas na visualização do vídeo foi criado o streaming adaptativo. Por meio dessa técnica, o servidor disponibiliza para o usuário um mesmo conteúdo codificado em diferentes taxas. Desta forma o cliente poderá adaptar dinamicamente a taxa de transmissão do streaming (dentre as taxas disponíveis) de acordo com uma análise da banda disponível, situação do buffer, do processamento da Central Processing Unit (CPU) e o tamanho da tela de visualização (OZER, 2011b). Assim, com o streaming adaptativo o usuário terá a melhor experiência de qualidade de som e imagem possível, permitindo tanto uma televisão fullhd, como um celular de baixa resolução, exibirem o mesmo conteúdo, adaptado para cada situação. 3.2 Início do streaming adaptativo ao surgimento DASH Ozer (2011b) traz as principais alternativas de streaming adaptativo existentes, iniciando pela Move Networks, que foi a primeira a popularizar esta tecnologia em 2007 (MO- VENETWORKS, 2010). A Move chegou a ter em sua carteira de clientes a ABC.com e FOX.com, sendo uma referência de desenvolvimento da tecnologia. Porém alguns movimentos de mercado fizeram com que a Move deixasse de ser um dos players do mercado do streaming adaptativo. Lawler (2010), no portal da GigaOM, relata os principais motivos que levaram a Move Networks para esta situação. Um deles foi o fato de que os usuários deveriam ter um plug-in em suas máquinas para visualizar o conteúdo. Enquanto os computadores não tivesse este aplicativo a empresa não poderia abranger o mercado, porém enquanto a Move não abrangesse-o as pessoas não iriam instalar o plug-in, o que impediu todo o desenvolvimento. Outro fator foram os custos para implementar e ter acesso ao serviço exclusivo. O fato dos reprodutores da Move não terem compatibilidade com propagandas, preparadas para o Adobe Flash, contribuiu também para a queda da companhia. Ao tomarem conta das possibilidades do streaming adaptativo outras empresas, como a Adobe e a Microsoft, começaram a investir na tecnologia e em 2008 lançaram 22

47 suas plataformas de streaming adaptativo retirando definitivamente a Move do mercado das empresas de streaming (LAWLER, 2010). No ano de 2008, conforme citado no parágrafo anterior, a Adobe criou o Dynamic Streaming RTMP (Real Time Messaging Protocol), que requeria pelo menos um servidor Flash Media 3.5 (ou compatível) e utilizava o protocolo de distribuição RTMP. Tal solução possibilitou também o uso de codecs como VP6 e H.264 (OZER, 2011b). O sistema conseguiu ter uma ampla abrangência já que o Flash, no final de 2008, tinha uma penetração de 99% os computadores conectados à Internet (FLASH, 2008). No final do mesmo ano a Microsoft também lançou seu produto, o Smooth Streaming, que funcionava com o plug-in Silverlight e introduziu o uso do protocolo HTTP, em contraste ao RTMP (OZER, 2011b). O portal InternetNews.com trouxe a matéria em que Patrizio (2008) diz que no ano do lançamento do Silverlight um em cada quatro consumidores tinham acesso ao sistema da Microsoft. Em meados de 2009 a Apple lançou sua própria tecnologia, também utilizando HTTP, chamada HTTP Live Streaming (HLS) que é o único sistema que permite visualizar streaming em dispositivos com o ios da Apple, como o iphone e ipad (OZER, 2011b). Desta forma, tanto a Apple quanto a Microsoft, estavam apostando no uso do HTTP e não no RTMP (proprietário da Adobe) como protocolo de distribuição. Frente a essa realidade, a Akamai lança a sua HD Network, que utilizava uma Content Delivery Network (CDN) rede de servidores em lugares diferentes com informações replicadas, que aproximam a informação do consumidor. Esta rede conseguia converter arquivos RTMP para HTTP e disponibilizá-los para reprodutores Silverlight e dispositivos ios (OZER, 2011b). Percebendo que os concorrentes estavam investindo em sistemas HTTP, a Adobe lança, em 2010, o HTTP Dynamic Streaming, que compatibilizou o Flash Player ao HTTP, permitindo este receber conteúdos não advindos de servidores Flash Media (OZER, 2011b). Com esse breve panorama é possível perceber que as diversas formas de distribuição do conteúdo para streaming estão convergindo para a utilização do HTTP, por poder utilizar toda uma infraestrutura já presente na rede de Internet. Apesar de aparentar uma convergência entre os sistemas apresentados, na realidade esta se dá somente no uso do HTTP e na estrutura macro relacionada ao uso deste protocolo. Sodagar (2011), em seu paper na revista IEEE Multimedia, apresenta a realidade 23

48 entre cada uma das plataformas apresentadas. No artigo é evidenciado que para cada solução existem formatos próprios de arquivos, seja ele do tipo Manifest a ser explicado ainda neste tópico como nos segmentos do conteúdo. A incompatibilidade também se dá ao receber este conteúdo, que para cada tecnologia existem seus dispositivos e aplicativos específicos. Sodagar (2011) defende que um padrão para o HTTP Streaming iria possibilitar uma interoperabilidade entre diferentes tipos de servidores e clientes, diminuindo os problemas relacionados a compatibilidade. É neste cenário que surge o DASH (Dynamic Adaptive Streaming over HTTP), que tem como objetivo estabelecer um padrão para o streaming dinamicamente adaptativo sobre HTTP. O DASH tem sido desenvolvido em várias frentes, que se baseam uma nas outras, e de forma colaborativa amadurecem a tecnologia. O começo do desenvolvimento do DASH se deu em abril de 2009 com um grupo no 3GPP que iniciou um trabalho com o streaming HTTP, já que além da padronização, conforme citado por Lohmar et al. (2011), este grupo tinha interesse na convergência da rede de Internet com a de dispositivos móveis. Primeiramente foi lançado o Release 9, em março de 2010, contendo o 3GPP Adaptive HTTP Streaming (AHS). Após esse primeiro documento o Open IPTV Forum elaborou um documento com requerimentos para seu HTTP Adaptive Streaming (HAS), baseado no AHS da 3GPP. Baseado nessas duas especificações o Moving Picture Experts Group (MPEG) lançou seu documento, com o MPEG-DASH. Após todas essas contribuições espera-se o lançamento do Release 10 da 3GPP (STOCKHAMMER, 2011). 3.3 DASH - Abordagem técnica No início do capítulo foram discutidas as qualidades e deficiências entre as três principais formas de distribuição desses conteúdos. Como forma de unir esses três tipos, potencializando as qualidades de cada um, começou-se a ser utilizado o HTTP, como protocolo da camada de aplicação, para se transmitir o conteúdo de áudio e vídeo. Isso porque o HTTP possibilita o streaming adaptativo ao mesmo tempo que utiliza a grande rede de servidores web para distribuir seu conteúdo. Na seção anterior foi apresentado o panorama que convergiu os modelos de streaming também para a utilização do HTTP, que culmina com a padronização dessa forma de distribuição com o DASH. Essa seção trará, primeiramente, como que realiza-se a codificação fonte do conteúdo que será trans- 24

49 mitido em DASH. Por fim, serão abordadas as dinâmicas de funcionamento do DASH assim como a sua estruturação Codificação fonte: MPEG-2 Systems, compressão e empacotador DASH Para a codificação do DASH é possível utilizar diversos tipos de codificações de fonte. No caso dos testes realizados com o DASH nessa dissertação, o conteúdo estrutura-se de acordo com procedimentos do MPEG-2 Systems. O áudio foi codificado em MPEG-4 High Efficiency AAC v2 (HE-AAC v2) e os vídeos em MPEG-4 parte 10 /Advanced Video Coding (AVC) - H MPEG-2 systems Para que seja possível unir os fluxos de diferentes codificações fonte de áudio e vídeo em um único fluxo, juntamente com dados, existe uma padronização que descreve seu procedimento, conhecida como MPEG-2 systems. Essa especificação define um tipo de multiplexação que resultará em um Transport Stream (TS), que é a utilizada no ISDB-T B. Como início de análise do MPEG-2 systems toma-se o resultado da codificação fonte de um conteúdo de áudio e vídeo, chamado Elementary Stream (ES). O ES se caracteriza por ser um fluxo contínuo de bits, resultantes da compressão, compostos por access units, que são os trechos do conteúdo comprimido (SARGINSON, 1995). Na sequência, o ES será dividido em blocos chamados Packetized Elementary Stream (PES), com vistas a facilitar as próximas etapas, já que trata-se de um fluxo empacotado, não mais contínuo. Esses pacotes podem conter um ou mais access units, e terão tamanho variável, com payload máximo de 64 KBytes (SARGINSON, 1995). Assim, no caso de uma única programação contendo áudio e vídeo, haverá uma separação desses elementos, destinando-os para os seus respectivos processos de compressão, o que resulta em ES diferentes e separados, e por consequência, PES também distintos. Durante o processo de codificação haverá diferentes atrasos para cada codificação fonte, o que gera um problema de sincronismo. Como o áudio e o vídeo serão unidos novamente em um único fluxo, será necessário estampas para sincronismo no tempo, chamadas time stamps. Esses marcadores permitirão a manutenção da reprodução simultânea do áudio e vídeo, já que o decodificador poderá reproduzir ao mesmo tempo cada um dos PES 25

50 baseando-se nessas estampas. Assim, cada um dos PES conterá um payload de dados do ES fracionados sequencialmente, e um cabeçalho que incluirá estampas de tempo, para manter os pacotes PES de diferentes fontes sincronizados. Ressalta-se que para tal existirá um clock comum entre os codificadores. As estampas do tempo, para o PES, terão um número com 33 bits, baseado em um clock de 90 khz, que é a divisão do clock de 27 MHz por 300 (TEKTRONIX, 2011). A figura 10 traz como que se dá o encapsulamento do ES no PES. Figura 10: Empacotamento ES no PES. Fonte: Adaptado de Sarginson (1995, p. 4/4). As estampas de tempo do PES estarão no cabeçalho, sendo uma a Decoding Time Stamp (DTS) e outra a Presentation Time Stamp (PTS). A diferença entre essas duas estampas pode ser compreendida ao analisar as técnicas de compressão de vídeo, que podem ser bidirecionais, ou seja, consideram informações passadas e futuras para uma codificação de um dado presente. Assim, para que possa ser realizada a decodificação é necessário que na saída do compressor os dados sejam enviados fora da ordem temporal, para que todas as informações necessárias para decodificar uma informação estejam presentes no seu momento da decodificação. Por esse motivo existe uma estampa, chamada DTS, que indicará a ordem que deverá ser decodificado cada PES. Porém, a ordem de decodificação dos PES não serão as mesmas de reprodução do conteúdo. Assim, faz-se necessária a estampa PTS, que ordenará a reprodução dos PES. Ressalta-se que no caso do áudio não ocorre a transmissão do resultado da compressão fora da sequência, ou seja, não precisam da DTS (TEKTRONIX, 2011). 26

51 Uma vez estruturados os PES eles serão multiplexados em um fluxo chamado Transport Stream (TS). O tamanho dos pacotes desse fluxo (188 bytes, sendo 4 de cabeçalho e 184 de payload) normalmente serão menores do que os do PES, o que resulta em uma divisão de um pacote PES em diversos pacotes TS. Ao analisar a divisão de um fluxo PES em diversos pacotes TS obtêm-se a estrutura apresentada na figura 11, que mostra que no primeiro pacote TS existirá o cabeçalho do PES e parte de seu payload. No próximo pacote Transport Stream seguirão os demais trechos da parte de dados do PES, até que todas as partes completem um pacote PES inteiro, o que possibilitará o encapsulamento TS do próximo pacote PES. Porém, pode acontecer de esses trechos da divisão do pacote PES não resultem em um múltiplo de 184 bytes, ou seja, no último pacote TS existirá um espaço de seu payload sem dados do pacote PES, que será preenchido com um campo de adaptação, que incluirá valores nulos, chamados de stuffing bytes (SARGINSON, 1995). 4 Bytes (Cabeçalho TS) Cabeçalho PES Stuffing Figura 11: Método de inserção do PES no TS. Fonte: Adaptado de Takahashi (2007, p. 16). Porém, na realidade existe mais do que um único fluxo a ser multiplexado, portanto, os pacotes TS intercalarão os diferentes PES de entrada. Essa divisão no tempo será feita de forma coerente com as taxas de cada PES, ou seja, a divisão dos fluxos de entrada com maior taxa de bits serão presentes em maior frequência no payload do TS, do que os de menor taxa com menor frequência (NHK, 2002). A figura 12 ilustra um exemplo de como é feita a multiplexação de dois PES diferentes. Como no MPEG-2 Systems existem várias estampas de tempo para sincronismo há a 27

52 184 Bytes Cabeçalho PES 1 PES1 Cabeçalho PES 1 Cabeçalho PES Bytes TS 4 Bytes (Cabeçalho TS) Cabeçalho PES 2 PES2 184 Bytes Figura 12: Método de multiplexação do TS. Fonte: Adaptado de Takahashi (2007, p. 13). necessidade de um clock de referência, que derivará outros pulsos. Porém, é preciso que essa base esteja sincronizada no codificador e decodificador, para que trabalhem de forma síncrona. Para tal, existe um campo no cabeçalho do TS com um valor binário chamado Program Clock Reference (PCR). Esse valor, com 42 bits (com 33 bits de base em 90 khz e 9 bits de extensão em 27 MHz) traz amostras do clock do codificador fonte e será enviado periodicamente para o decodificador fonte, para que este verifique se sua base de trabalho local está igual a do codificador fonte. Caso exista um desvio, chamado jitter, o decoder irá ajustar o oscilador de referência local para que haja sincronismo correto (SARGINSON, 1995). Na prática também existe, no cabeçalho do TS um campo de identificação do tipo de conteúdo que está no payload, chamado Packet Identification (PID). Esse valor, de 13 bits, ajudará na identificação dos diversos dados que chegam ao demultiplexador no decodificador fonte. Assim, também é facilitada a separação dos diferentes PES pois eles conterão o mesmo PID (TEKTRONIX, 2011). Mas para que o decodificador fonte consiga relacionar os dados com seus respectivos PIDs é necessário que ele verifique essa 28

53 informação com o uso de tabelas, que são transmitidas regularmente no payload dos pacotes do TS (SARGINSON, 1995). Essas tabelas são chamadas de Program Specific Information (PSI) e algumas tem seu PID padronizado, o que permite que o decodificador já a encontre sem qualquer informação adicional. A partir dessas tabelas padronizadas é possível encontrar os valores de outros PIDs dos demais serviços dentro do TS. A tabela 6 traz um resumo das tabelas PSI, seus PIDs e funções (AKAMINE, 2012). Tabela 6: Program Specific Information (PSI) Nome da tabela PID Alocado Descrição Program Association Table (PAT) 0x00 Indica o PID da Program Map Table (PMT) Program Map Table (PMT) Indicado na PAT Especifica os PIDs dos serviços disponíveis Network Information Table (NIT) Indicado na PAT Traz parâmetros de rede como a frequência FDM Conditional Access Table (CAT) 0x01 Indica PIDs de dados encriptados Fonte: Adaptado de NHK (2002). Em resumo, um codificador fonte que tem como entrada um conteúdo de áudio e vídeo não comprimidos e como saída um TS seguirá todos os processos e características descritos, conforme o diagrama exposto na figura 13. MPEG2 Áudio ISO/IEC Áudio Codificador ES Empacotador de áudio MPEG2 Systems ISO/IEC PES MPEG2 Vídeo ISO/IEC Vídeo Codificador ES PES Empacotador de vídeo Multiplexador MPEG-2 TS TS Figura 13: Sistema de multiplexação do MPEG-2 Systems. Fonte: Adaptado de Takahashi (2007, p. 9). 29

54 Compressão do áudio: MPEG-4 HE-AAC A técnica utilizada no áudio, assim como o MPEG-4 parte 10, assume o conceito de fazer uma codificação baseada em objetos, tomando, por exemplo, cada canal de áudio como um objeto e estabelecendo relações entre eles, ao invés de analisar somente sua envoltória espectral (STOLFI, 2008). As principais melhorias do MPEG-4, em relação ao MPEG-2, estão no uso do Perceptual Noise Substitution (PNS) e na quantização vetorial. O primeiro fator citado basea-se na característica do ser humano não ter grande sensibilidade para diferenciar um ruído original de outro que foi sinteticamente produzido a partir das informações do contorno da envoltória do espectro do sinal original. Assim, ao se codificar um sinal utilizando PNS somente são enviadas as informações do contorno o espectro, cabendo ao decodificador criar um ruído que se adeque ao contorno recebido (AUSTERBERRY, 2005d). Outra técnica utilizada é a quantização vetorial que tem como objetivo representar uma distribuição de dados por meio de um novo conjunto, que se assemelha estatisticamente do original, porém com menor número de dados (VIO- LATO, 2010). Para Meltzer e Moser (2006) o MPEG-4 HE-AAC v2 tem como principal característica o uso de três técnicas para redução do número de bits. A primeira é o Advanced Audio Coding (AAC), que filtra o áudio em bandas, gera coeficientes espectrais e utiliza um preditor espectral que codifica as diferenças do espectro do sinal ao decorrer do tempo. Por fim, aplica-se a codificação de Huffmman com os coeficientes (STOLFI, 2008). A segunda técnica chama-se Spectral Band Replication (SBR) que baseia-se em enviar somente a banda de baixas frequências e informações sobre o envelope espectral da banda de altas frequências, que servirá para recompô-la no decodificador (MELTZER; MOSER, 2006). A terceira é o Parametric Stereo (PS), que diferencia o HE-AAC v2 do HE-AAC v1, que tem como princípio parametrizar a relação de diferenças de tempo e fase entre o canal esquerdo e o direito e enviar um sinal mono, que será a união de dois canais. Com essas informações, será viável para o receptor, depois de decodificar esse sinal, reconstruir o estéreo com os parâmetros coletados na técnica do PS (MELTZER; MOSER, 2006). 30

55 Compressão do vídeo: H.264 Para o vídeo foi utilizado o H.264 Advanced Video Coding (AVC) que trata-se de uma técnica de codificação de vídeo elaborada por um grupo chamado Joint Video Team (JVT). Esta equipe une o grupo da International Telecommunication Union (ITU), chamado Video Coding Experts Group (VCEG), com o grupo MPEG. Em 2003 publicou-se o padrão como ISO/IEC MPEG-4 parte 10 e ITU-T Recomendação H.264. Esse padrão apresentou uma vantagem em relação aos anteriores devido a sua alta capacidade de compressão. A qualidade de imagem obtida utilizando H.264 foi superior ao MPEG-2 utilizando a mesma taxa de bits. Sikora (1997) ressalta que outra característica do H.264 foi seu desenvolvimento, em 1994, para futuras aplicações multimídias, em ambientes heterogênios e para dispositivos móveis. Basicamente o H.264 tem três etapas principais: modelo temporal, modelo espacial e codificador entrópico, que serão sucintamente explicadas a seguir. O modelo temporal tem como tarefa reduzir a redundância temporal entre os quadros (VIANELLO, 2007). Esse fenômeno ocorre pois normalmente existe uma alta correlação entre os quadros subsequentes, pois parte deles se repete no seguinte, já que a câmera tende a ficar no mesmo enquadramento por mais do que um quadro. Assim, diversos elementos se repetirão, mantendo sua posição ou se movendo. O modelo temporal atuará justamente com essa caraterística do vídeo, aliando um preditor em seu processo (STOLFI, 2010). Ao detectar o deslocamento de objetos entre quadros o codificador irá enviar essa informação para o preditor na forma de vetores de movimento e com base neles o preditor fará a estimativa do quadro seguinte. Stolfi (2010) também nomeia a compensação de movimento como compensação por translação de blocos semelhantes, já que esses objetos da imagem são na realidade os blocos resultantes da divisão da imagem, que acontecem na entrada do sistema, conforme Schäfer, Wiegand e Schwarz (2003). O modelo espacial irá diminuir a redundância de informação na imagem, considerando as semelhanças entre pixels vizinhos (VIANELLO, 2007). Richardson (2003) explica que para tal, uma técnica utilizada no H.264 é aplicar uma transformada nas amostras do quadro residual. Assim, essas amostras estarão em outro domínio, representadas por coeficientes, que serão quantizados a fim de reduzí-los, desprezando alguns valores. A saída deste bloco serão coeficientes quantizados da transformada. Desta forma a quan- 31

56 tidade de informação será reduzida, pois alguns desses coeficientes já serão suficientes para caracterizar a imagem (RICHARDSON, 2003). Portanto, esse processo divide-se em transformação, que diminuirá a correlação dos dados, quantização, que reduzirá a precisão da transformada, e, por fim, reorganização dos dados em grupos. Por fim, a codificação entrópica será responsável pelo tratamento da informação do vídeo, para que ele seja armazenado ocupando menor espaço possível, assim como seja transmitido a uma menor taxa de bits viável (SIKORA, 1997). Para conquistar essa propriedade, esse processo explorará as redundâncias estatísticas dos dados vindos dos modelos explicados anteriormente para codificá-los utilizando o mínimo de informação. As amostras quantizadas dos coeficientes da transformada realizada no modelo espacial, juntamente com os dados dos vetores de movimento vindos do modelo temporal e metadados serão unidos para resultarem em um único fluxo de bits na saída. Antes dos dados irem para o codificador entrópico, o fluxo de entrada primeiramente será pré-codificado com um preditor. Depois serão aplicadas duas técnicas de codificação entrópica: Huffman modificada e codificação aritimética (RICHARDSON, 2003) Empacotamento MP4Box Na estruturação do DASH, após a codificação da fonte, os conteúdos de áudio e vídeo serão empacotados pelo MP4Box, com base no ISO base media file format da ISO/IEC (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2012a). Uma das habilidades desse tipo de pacote é conseguir dividir o conteúdo em diversos arquivos (CON- COLATO, 2005). Essa propriedade é interessante na codificação DASH pois permite a fragmentação do vídeo em pedaços, que serão solicitados na reprodução. O MP4 formatase em orientação por objetos, que são chamados box. Dentro de um arquivo MP4 existem boxes, que são estruturados de forma hierárquica e não existirá nenhum dado fora de algum box. Cada uma dessas caixas é estruturada em três partes: indicador do tamanho total (4 bytes), tipo do box (4 bytes) e dados (tamanho variável), conforme estrutura da figura 14 (ZHAO; GUAN, 2010). Os três principais tipos do MP4 são o ftpy, que é obrigatório e inserido sempre no início do arquivo MP4, o moov, que indica que o box em questão contém metadados, e o mdat, que marca o box que contém os dados de mídia (CHEN; WU, 2012). 32

57 Tamanho (4 Bytes) Tipo (4 Bytes) Dados Figura 14: Estrutura do box MP4. Fonte: Adaptado de Zhao e Guan (2010, p. 984). O arquivo criado trará separadamente os boxes com metadados e outros com a mídia. Os metadados indicarão o tipo do conteúdo (em um código de 4 bytes) e timestamples (CONCOLATO, 2005). Ressalta-se que os metadados e a mídia se correlacionam por estarem em um mesmo box, além das estampas de tempo. A figura 15 mostra como se estrutura esse tipo de arquivo. Arquivo mp4 moov trak trak Metadados - Filme Trilha de Vídeo Trilha de Áudio Mídia - Filme mdat Áudio Vídeo Áudio Vídeo Áudio Figura 15: Diagrama de estrutura do pacote mp4. Fonte: Adaptado de Concolato (2005, p. 10). Na figura 15 observa-se que a mídia e seus metadados estão em boxes diferentes. O cabeçalho dos metadados, moov, indica que este é um box de metadados da mídia. Nota-se que dentro desse box encontram-se separadamente os dados da trilha de vídeo e da trilha 33

58 de áudio, ambas com o cabeçalho indicando trak, que evidencia que o box traz informações de um único stream. No outro box encontra-se a mídia, indicada no cabeçalho por mdat, que indica que internamente ao box existirão os dados de mídia (CONCOLATO, 2005). Assim, de forma hierárquica um box é inserido dentro do outro, e identificados por seus cabeçalhos Estruturação do conteúdo e funcionamento do DASH O DASH foi normatizado com a ISO/IEC :2012. A norma tem o escopo de padronizar a estrutura do media presentation description (MPD), dos segmentos e as análises desses componentes pelo cliente (INTERNATIONAL ORGANIZATION FOR STAN- DARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2012b). A estrutura de abordagem do DASH está destacada pelos blocos mais claros da figura 16. Media Presentation no Servidor HTTP Media Presentation Description (MPD) Programa A Segmento Segmento Segmento Segmento Segmento Segmento Programa B Segmento Segmento Segmento Segmento Segmento Segmento Entrega MPD Entrega Segmentos Cliente DASH Controle Analisador MPD Analisador Segmento Cliente HTTP Media Player Figura 16: Escopo da norma ISO/IEC :2012. Fonte: Adaptado de Sodagar (2011, p. 64). O Dynamic Adaptive Streaming over HTTP é constituído de duas partes principais: o MPD e a media presentation, que são os segmentos do conteúdo. O arquivo MPD é chamado de arquivo manifest, caracterizado por dar a localização dos arquivos do conteúdo a ser visto e ouvido pelo streaming. Este arquivo, escrito em extensible markup language (XML), contém o endereço URL de cada trecho do áudio e vídeo disponibilizado no 34

59 servidor. Ao iniciar a sessão o cliente prontamente já faz a requisição deste arquivo, indispensável para o streaming no DASH. A manifest file pode ser considerada como uma lista telefônica, em que os nomes são os arquivos de mídia, e os números de telefone são as URLs de cada arquivo. O MPD deve ser organizado de forma hierárquica em relação ao conteúdo multimídia, de acordo com o estabelecido pela ISO/IEC :2012. A media presentation, que é o conteúdo a ser transmitido, é primeiramente dividida em períodos, que podem ser comparados a blocos. Como uma função prática, essa divisão em períodos pode ser utilizada para dividir um programa de TV para entrada de intervalos comerciais. O próximo degrau da hierarquia é a divisão desses períodos em grupos, que congregam tipos de mídia comuns, devido ao codec utilizado ou linguagem de áudio, por exemplo. Assim, um grupo pode conter um áudio em português e outro grupo conter uma audiodescrição. A próxima divisão hierárquica será a separação de cada grupo em representações. Elas se diferenciam por conter o mesmo conteúdo codificados em taxas diferentes. No exemplo dado, seria como ter uma representação com o áudio em português a 128 kbps e outra com o mesmo conteúdo a 192 kbps. Por fim, a última partição da hierarquia se dá ao dividir cada representação em segmentos, que são propriamente os pedaços dos arquivos de áudio e vídeo. Para cada pedaço desse, chamado segmento, haverá uma URL associada. São esses endereços que irão para a MPD. A figura 17 mostra a hierarquia do MPD. Toma-se, na tabela 7, um exemplo real de uma MPD gerada nos testes do DASH, a serem apresentados no penúltimo capítulo dessa dissertação. O arquivo será interrompido em alguns pontos para identificação dos blocos. 35

60 MPD Período 1 Início = 0s Período 2 Início = 30s Período 3 Início = 60s Período 4 Início = 90s Período 3 Início = 60s Grupo 1 Grupo 2 Grupo 3 Grupo 1 Representação 2Mbps Representação 3Mbps Representação 6Mbps Representação 9Mbps Representação 3Mbps Segmento Inicial Segmento Mídia início = 0s Segmento Mídia início = 10s Segmento Mídia início = 20s Figura 17: Hierarquia da MPD pela ISO/IEC :2012. Fonte: Adaptado de Sodagar (2011, p. 65). 36

61 Tabela 7: MPD gerada nos testes do DASH. Cabeçalho: <?xml version="1.0"encoding="utf-8"?> <MPD xmlns:xsi="http://www.w3.org/2001/xmlschema" xmlns="urn:mpeg:mpegb:schema:dash:mpd:dis2011" xsi:schemalocation="urn:mpeg:mpegb:schema:dash:mpd:dis2011" profiles= "urn:mpeg:mpegb:profile:dash:isoff-basic-on-demand:cm" type="ondemand" mediapresentationduration="pt5m0.08s" minbuffertime="pt10.00s <Period> Identificação do tipo de mídia: <Group segmentalignmentflag="true"mimetype="video/mp4 <Representation mimetype="video/mp4"width="1280"height="720" startwithrap="true"bandwidth= "317880"minBufferTime="2000 Identificação da duração dos pedaços da mídia: <SegmentInfo duration="pt2.00s Identificação do arquivo inteiro do vídeo, para a primeira taxa: <InitialisationSegmentURL sourceurl="http:// /arquivos DASH/ zp1 t1t2t3/zp1 t1t2t3 1438kbit/ZonePlate 10M 20ponto02 24fps 720p/ new 1438kbit dash.mp4"/> Identificação sequencial dos pedaços do vídeo para a primeira taxa: <Url sourceurl="http:// /arquivos DASH/PosBanca/ zp1 t1t2t3/ zp1 t1t2t3 1438kbit/zp1 t1t2t31.m4s"/> [...] <Url sourceurl="http:// /arquivos DASH/PosBanca/ zp1 t1t2t3/ zp1 t1t2t3 1438kbit/zp1 t1t2t391.m4s"/> Início do bloco de identificação do vídeo na segunda taxa: </SegmentInfo> </Representation> <Representation mimetype="video/mp4"width="1280"height="720" startwithrap="true"bandwidth= "318061"minBufferTime="2000 <SegmentInfo duration="pt2.00s Identificação do arquivo inteiro do vídeo, para a segunda taxa: <InitialisationSegmentURL sourceurl="http:// /arquivos DASH/ PosBanca/ zp1 t1t2t3/zp1 t1t2t3 1845kbit/ ZonePlate 10M 20ponto02 24fps 720p new 1845kbit dash.mp4"/> Identificação sequencial dos pedaços do vídeo para a segunda taxa: <Url sourceurl="http:// /arquivos DASH /PosBanca/zp1 t1t2t3/zp1 t1t2t3 1845kbit/zp1 t1t2t31.m4s"/> [...] <Url sourceurl="http:// /arquivos DASH /PosBanca/zp1 t1t2t3/zp1 t1t2t3 1845kbit/zp1 t1t2t391.m4s"/> </SegmentInfo> </Representation> </Group> </Period> </MPD> 37

62 Ao realizar uma transmissão baseada em DASH utiliza-se a estrutura de servidor e cliente. Para realizar o streaming, o conteúdo a ser disponibilizado será separado em pequenos trechos e codificado em diferentes taxas, para viabilizar o streaming adaptativo. Cada pequeno trecho será armazenado no servidor, sendo a ele associado uma URL. Uma vez que o cliente tem o arquivo MPD o usuário poderá solicitar, através do método HTTP GET, cada segmento desejado. Ressalta-se que o primeiro segmento dentro de cada representação conterá metadados sobre a codificação dos próximos segmentos, que trarão o conteúdo de áudio e vídeo propriamente dito (MÜLLER; TIMMERER, 2011). Desta forma, o controle do streaming será, de forma completa, uma tarefa do usuário, que fará o acompanhamento da qualidade de processamento e da rede. Assim, de acordo com a análise realizada, o cliente poderá pedir uma outra representação, com segmentos codificados em uma taxa maior ou menor, uma resolução diferente ou até mesmo outra proporção da tela de visualização (STOCKHAMMER, 2011). Na tabela 8 é apresentado um exemplo, acontecido nos testes, das requisições HTTP do reprodutor para o servidor, solicitando pedaços do conteúdo DASH. Tabela 8: Requisições HTTP do cliente para o servidor DASH [04/Dec/2013:19:55: ] GET /Arquivos DASH/ 8ave t1t2t3/8ave t1t2t3 1438kbit/8ave t1t2t328.m4s HTTP/1.1" [04/Dec/2013:19:55: ] GET /Arquivos DASH /8ave t1t2t3/8ave t1t2t3 1438kbit/8ave t1t2t329.m4s HTTP/1.1" [04/Dec/2013:19:55: ] GET /Arquivos DASH /8ave t1t2t3/8ave t1t2t3 1438kbit/8ave t1t2t330.m4s HTTP/1.1" [04/Dec/2013:19:55: ] GET /Arquivos DASH /8ave t1t2t3/8ave t1t2t3 1845kbit/8ave t1t2t331.m4s HTTP/1.1" Para que um conteúdo seja codificado e estruturado em DASH é preciso que ele passe por todas as etapas do diagrama de blocos representado na figura 18. Portanto, a primeira etapa será tomar o media presentation, que é o conteúdo a ser disponibilizado em DASH, e dividí-lo em pedaços de um tamanho fixo, como por exemplo dois segundos. Linearmente esse processo é realizado até o final da mídia. Depois dessa etapa cada pedaço será codificado em taxas pré-estabelecidas, o que resulta em várias cópias dos pedaços da mesma mídia, porém com taxas diferentes. Ressalta-se que nessa 38

63 C B A Divisão Pedaços fixos Codificação Pedaços Organização URL e MPD E D C A B Servidor MPD Figura 18: Diagrama de blocos do DASH. etapa poderá ser escolhido diversos tipos de técnicas de codificação, como, por exemplo, o H.264. A última etapa será organizar todos os trechos e gerar uma lista de seus endereços, chamada MPD. Todo esse conteúdo será, por fim, disponibilizado no servidor. Ao se aplicar os conceitos básicos descritos no início deste capítulo surge um conflito na nomenclatura DASH relacionado ao uso da palavra streaming juntamente com HTTP. Stockhammer (2011) explica que no streaming tradicional normalmente os protocolos da camada de aplicação, do modelo OSI, são orientados ao estabelecimento de sessão, como o RTSP e RTP/RTCP. Nesta situação, o cliente se conecta ao servidor e uma sessão é mantida em aberta para toda a troca do conteúdo, até que o cliente solicite o fim da sessão. Porém o HTTP é considerado sem status, pois para cada dado trocado uma sessão é estabelecida e finalizada, não guardando um histórico das trocas de mensagem entre cliente e servidor. Desta forma pode-se dizer que o DASH não se trata de um streaming tradicional, já que seu protocolo não é orientado por sessões. Inclusive o protocolo HTTP está ligado ao uso de servidores web, que por sua vez estão relacionados ao streaming progressivo. O DASH é um streaming baseado em HTTP, que será muito similar ao download progressivo, porém levando em consideração as deficiências deste tipo de tecnologia. Dentre os principais pontos de melhoria em relação ao download progressivo estão o uso desnecessário da banda que acontecerá no caso de alguém requisitar vídeo, iniciar seu download integral 39

64 e decidir não vê-lo mais. Esta forma de entrega também não permite uma adaptação da taxa, assim como não suporta a transmissão de eventos ao vivo, já que o arquivo deverá estar pronto integralmente para sua transmissão (STOCKHAMMER, 2011). Estes foram os principais pontos que os desenvolvedores do DASH procuraram trabalhar, criando um download progressivo com as vantagens do streaming adaptativo. Begen (2011) afirma que o DASH é um sistema híbrido, pois imita o streaming através de pequenos downloads. 40

65 4 CONCEITOS DE REDES IP APLICADOS AO STREAMING Este capítulo traz os conceitos necessários para compreender como se dá a inserção dos dados, já comprimidos, no ambiente do internet protocol (IP), assim como as dinâmicas desse ambiente ao abordar as camadas de sua estrutura, com foco nos protocolos voltados para a realização do streaming. Basicamente os dados digitalizados e comprimidos serão gerenciados por uma aplicação que realizará o streaming do conteúdo. Essas informações serão passadas para uma camada chamada transporte que fará o controle da transmissão desses dados, como garantia de entrega e multiplexação e demultiplexação dos dados de diversas aplicações. Depois, todos esses dados serão passados para a camada de rede, que fará o encapsulamento IP para que eles sejam reconhecidos em uma rede de Internet, que distribuirá, pela camada de enlace, esses dados para vários terminais. Nesses receptores será feito o processo inverso, até que os dados cheguem na aplicação de streaming, na reprodução do conteúdo. Esse processo de streaming pode ter como paralelo o sistema ISDB-T B, apresentado na figura 1. A etapa de codificação em comum já foi abordada no terceiro capítulo deste trabalho, e estará na camada de aplicação. O próximo bloco, multiplexador, será a camada de transporte, com os protocolos UDP e TCP. O modulador será responsável por adequar esses dados a um ambiente de transmissão, portanto o paralelo com o streaming se dá no bloco do encapsulamento IP. Por fim, o amplificador e a antena, estão na camada física das redes IP, que são os cabos UTP, fibras ópticas, ou até mesmo amplificadores e antenas específicas para transmissão IP. Esse comparativo é mostrado na figura 19. A estrutura e processos de cada etapa serão explicados com maiores detalhes nas próximas sessões. Porém antes de abordar esses assuntos é necessário compreender como se estruturam os processos entre protocolos e camadas de arquiteturas de rede, baseadas nos modelos Open Systems Interconnection (OSI) e Transmission Control Protocol/IP (TCP/IP), explicados na primeira sessão. Depois as sessões do capítulo farão uma abor- 41

66 Figura 19: Comparativo dos blocos ISDB-T B com o streaming. Fonte: Adaptado de ABNT (2007, p. 4). dagem da camada mais baixa até chegar na aplicação streaming. Vale ressaltar, somente, que não se abordará a camada de enlace, pois ela se trata de uma camada mais próxima da física e seu estudo voltaria essa monografia a uma análise técnica de camadas físicas de rede, o que não faz parte do escopo deste trabalho. Pretende-se aqui abordar as especificidades da rede relacionadas ao streaming, que são diferentes em relação a transmissão de outros tipos de dados, como e transferência de arquivos. Assim as sessões, após a apresentação dos modelos, serão sobre a camada de rede, com o encapsulamento IP, a camada de transporte, com seus principais protocolos e, por fim, a camada de aplicação, com a exposição dos protocolos utilizados para o streaming. 4.1 MODELOS OSI E TCP/IP Ao realizar uma análise em arquiteturas de rede existem dois modelos muito utilizados como referência: o modelo OSI e o TCP/IP. O primeiro, desenvolvido pela International Standards Organization (ISO), evidencia em seu nome que a intenção em elaborá-lo foi em padronizar uma interconexão de sistemas diferentes. Assim, esse modelo tem como foco os conceitos da divisão de suas camadas e não os protocolos inseridos nelas. De forma diferente foi criado o modelo TCP/IP, que se baseia em um grupo de protocolos já existentes antes de sua elaboração, adequando sua divisão de camadas a esses protocolos (TANENBAUM; WETHERALL, 2010). Dada tal realidade, o modelo OSI pode ser con- 42

67 siderado como referência genérica de uma arquitetura de rede, pois ele traz conceitos de cada etapa do processo. Mas ao tentar definir alguns protocolos dentro de suas divisões foram percebidas incompatibilidades (TANENBAUM; WETHERALL, 2010). Nesse ponto que o modelo TCP/IP traz uma grande relevância em seu uso no estudo de arquiteturas de rede para Internet, pois ele foca e engloba os principais protocolos utilizados nesse tipo de estrutura. A seguir são explicadas as funções de cada camada dos dois modelos, para que a partir do OSI se compreenda o TCP/IP, pois baseando-se em suas camadas será explicado o processo para se realizar um streaming Modelo OSI O modelo OSI é subdivido em sete camadas, que podem ser divididas em três grupos: aplicação, transporte e rede (TORRES, 2001), conforme se pode observar na figura 20. No primeiro grupo estão as camadas que lidam com o uso dos dados por determinado programa. Esses dados terão garantia de transmissão e recepção pelo último grupo e o transporte será responsável pela conexão entre os grupos de aplicação e de rede. O grupo de aplicação, juntamente com o de transporte englobam as camadas que fazem uma conexão entre as duas pontas da comunicação, já que o grupo de rede se atém à comunicação entre equipamentos adjacentes durante o caminho da informação (TA- NENBAUM; WETHERALL, 2010). Cada camada presente nesses grupos é brevemente explicada a seguir. 7 Aplicação 6 Apresentação 5 Sessão 4 Transporte 3 Rede 2 Enlace de dados 1 Física } Grupo de Aplicação } } Grupo de Transporte Grupo de Rede Figura 20: Camadas do modelo OSI. Fonte: Adaptado de Torres (2001, p. 42). 43

68 Camada de aplicação Esta é a camada mais próxima da interação do usuário. Ela é responsável por suportar os processos que envolvem os dados dos aplicativos em execução como transferência e gerenciamento da demanda de recursos (BARRETT; KING, 2010) Camada de apresentação Esta tem a função de capturar os dados da camada de aplicação e organizá-los para transmití-los em algum padrão, por isso também é chamada de camada de tradução. Esse formato poderá ser uma compactação com ou sem criptografia, o que pode reduzir a quantidade de informação a ser transmitida pelas camadas abaixo (TORRES, 2001) Camada de sessão Trata-se da camada responsável por manter a comunicação entre as aplicações. Ela faz a mediação da sessão, com o monitoramento do diálogo entre as aplicações, gerenciando a entrada de novos componentes, troca de informações e finalização da conversa (BARRETT; KING, 2010) Camada de transporte Esta camada toma os dados da camada acima (sessão) e os divide em pacotes para que eles possam ser enviados pela camada de rede. A camada de transporte atenta para que a entrega dos pacotes para a camada de sessão seja feita na ordem correta e sem erros. Outra característica presente na camada de transporte é o estabelecimento de um serviço orientado a uma conexão ou não, que varia de acordo com o protocolo utilizado. No primeiro caso haverá uma abertura de conexão para depois haver a troca de dados e finalmente se encerrar a conexão. Protocolos orientados à conexão oferecem garantias de entrega dos pacotes, porém com uma maior troca de informações entre as pontas, o que gera um maior tráfego. Em compensação o outro tipo de orientação não terá o trabalho de abrir e fechar conexões, mas nem sempre garante recibo de entrega dos dados (BARRETT; KING, 2010). 44

69 Camada de rede A principal tarefa desta camada é o roteamento dos pacotes nas redes, da origem até o destino. Para que isso seja possível são criadas rotas entre os nós da rede até que se alcance o destinatário. O controle desse tráfego, que pode ficar congestionado em alguns trechos do caminho,também é realizado pela camada de rede (TANENBAUM; WETHERALL, 2010) Camada de enlace de dados O enlace organiza os dados para serem transmitidos por uma rede. As informações são dispostas em quadros, que são conjuntos de dados agrupados e rotulados de acordo com endereço físico real da placa de destino correspondentes ao IP destinatário (TORRES, 2001) Camada física Esta é a camada que fisicamente levará o sinal elétrico (ou mesmo óptico) de um ponto ao outro. Ela é responsável por formatar, por exemplo, o período, amplitude e frequência do sinal que representará os bits 0 e 1, para que eles sejam transmitidos por um meio de comunicação. Também são padronizados os tipos de conectores e função de cada pino (TANENBAUM; WETHERALL, 2010) Modelo TCP/IP O modelo TCP/IP é dividido em quatro camadas: enlace, Internet, transporte e aplicação. Tal arquitetura surgiu com a antecessora da Internet, chamada ARPANET. Esse foi um projeto do Departamento de Defesa dos Estados Unidos e tinha que operar em diferentes tipos de redes (satélite, linha telefônica, rádio etc.) e manter a comunicação entre origem e destino mesmo que algumas conexões fossem perdidas (TANENBAUM; WETHERALL, 2010). Para que isso fosse possível foi necessário criar um modelo que ficou conhecido por TCP/IP. A figura 21 demonstra uma comparação das camadas dos modelos OSI e TCP/IP. 45

70 Modelo OSI 7 Aplicação 6 Apresentação 5 Sessão 4 Transporte 3 Rede 2 Enlace de dados 1 Física Modelo TCP/IP Aplicação Ausente Ausente Transporte Internet Enlace de dados Ausente Figura 21: Comparação entre camadas do modelo OSI e TCP/IP. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 28) Camada de enlace Tem como responsabilidade manter a interligação da comunicação independente da conexão. Um dos requisitos é que exista uma interoperabilidade entre topologias e tecnologias de rede diferentes (TANENBAUM; WETHERALL, 2010) Camada de Internet Correlaciona-se com a camada de rede do modelo OSI, responsável por fazer o roteamento dos pacotes no destino. Para que isso seja possível foi padronizado um protocolo chamado IP juntamente com o Internet control message protocol (ICMP) (TANENBAUM; WETHERALL, 2010) Camada de transporte Tem a mesma função da camada que traz este mesmo nome no modelo OSI. No modelo TCP/IP foram definidos dois tipos principais de protocolos desta camada: o TCP e o user datagram protocol (UDP). O primeiro tem garantia de entrega dos pacotes, pois devolve um recibo de recebimento do dado, é orientado a conexão e administra o fluxo entre as pontas da conexão. Já o UDP não se orienta à conexão e não traz garantia de entrega dos pacotes bem como sua ordem de chegada. Ele é utilizado quando a garantia de entrega de todos os pacotes tem menos importância do que entregá-los o mais rápido possível, como a transmissão de áudio e vídeo (TANENBAUM; WETHERALL, 2010). 46

71 Camada de aplicação Esta camada engloba a camada de sessão, apresentação e aplicação do modelo OSI. Entre os protocolos presentes na camada de aplicação está o HTTP, que é responsável pelo streaming de soluções como o DASH, que se configura o estudo de caso desta dissertação (TANENBAUM; WETHERALL, 2010). 4.2 CAMADA DE REDE: ENCAPSULAMENTO IP Uma vez abordados os modelos OSI e TCP/IP, é possível versar sobre o encapsulamento IP. Nessa etapa são organizados os datagramas, pacotes compostos pelos dados a serem transmitidos juntamente com um cabeçalho. No caso do streaming, o áudio e vídeo já comprimidos serão parte dos dados úteis que terão como anexo o cabeçalho IP em sua sequência de bits, ou seja, eles serão encapsulados no ambiente IP. Essa adição feita aos dados visa que esses pacotes trafeguem em uma rede para seu destino por um trajeto conhecido com roteamento (INTERNET ENGINEERING TASK FORCE, 1981a). O roteamento se baseia em um endereçamento lógico padronizado pelo protocolo IP, chamado endereço IP, que terá sua estrutura explicada a seguir. Porém, o cabeçalho IP adicionado aos dados úteis não se resume ao endereço IP, mas inclui também outras informações, que serão explicadas na sequência do endereçamento Endereçamento IP A estrutura em uso é a versão 4 (IPv4), composta por endereços com 32 bits, porém devido ao crescente número de usuários da Internet está em implantação a versão 6 (IPv6) com 128 bits (TORRES, 2001). O endereço IPv4 é representado por quatro números, em base decimal, que representam cada um dos quatro bytes dos 32 bits do endereço, separados por.. Assim, existe a possibilidade de endereços de até Subdividiu-se todos esses endereços em cinco classes, caracterizadas pelo seu primeiro byte, conforme a tabela 9. Barrett e King (2010) ressaltam que para a classe A o primeiro byte tem o endereço 0 como inválido e o 127 é reservado, o que diminui os endereços de 1 até 126. Os autores também explicam que a classe D foi reservada para uso futuro, porém tem seu uso atual para transmissões em multicast e a classe E é reservada para fins experimentais. 47

72 Tabela 9: Classes de endereços IP. Classe Faixa inicial Faixa final Padrão binário do primeiro byte A 0.x.x.x 127.x.x.x a B 128.x.x.x 191.x.x.x a C 192.x.x.x 223.x.x.x a D 224.x.x.x 239.x.x.x a E 240.x.x.x 255.x.x.x a Fonte: Barrett e King (2010). Pode-se afirmar que essa divisão de classes trata-se também de uma divisão de redes. Isso porque o endereço IP pode ser dividido em duas partes: uma que identifica a rede e outra um dispositivo na respectiva rede. A determinação prática dessa divisão é realizada pela máscara de sub-rede, que é uma sequência de quatro bytes representados identicamente a forma de representação do endereço IP. Para que seja identificada em um endereço IP a porção do endereço da rede e do dispositivo é realizada a operação AND 1. Pode ser aplicado esse conceito nas classes A, B e C definindo-se as máscaras para a classe A, para a classe B e para a classe C (TORRES, 2001). Dois exemplos de resultados obtidos são apresentados na tabela 10, que representa em negrito a parte do endereço IP que define a rede. O resto do endereço IP (que não está em negrito) será a parte que endereça os dispositivos dessa rede. Tabela 10: Máscara de sub-rede: divisão pela operação AND. Classe A Endereço de origem Máscara de sub-rede Resultado AND 170.x.x.x Classe C Endereço de origem Máscara de sub-rede Resultado AND x Fonte: Barrett e King (2010). Nota-se que a classe A possibilita a definição de um maior número de terminais conectados dentro de uma única rede ( dispositivos = 2 24 ) já que são atribuídos 8 bits para a rede e 24 para endereços de terminais, enquanto a classe C pode definir endereço para um menor número (256 dispositivos = 2 8 ) atribuindo a rede e terminais o número 1 Na álgebra booleana AND sempre que houver um bit 0 envolvido o resultado será 0, caso exista a operação entre dois bits 1 o resultado será o bit 1. 48

73 de bits inverso aos da classe A (BARRETT; KING, 2010). A figura 22 traz a atribuição dos bits para todas as classes. Classe A ID Rede Classe B ID Rede Classe C ID Rede Classe D Endereçamento Multicast Classe E ID Terminais ID Terminais Reservado uso futuro ID Terminais Figura 22: Atribuição dos bits para classes de endereçamento IP. Fonte: Adaptado de Torres (2001, p. 71). A máscara de sub-rede também é utilizada no roteamento entre redes diferentes, conectadas por um, ou mais, roteadores, que é um elemento de rede responsável por gerenciar o tráfego de pacotes IP em uma rede local e entre redes. Isso ocorre quando um pacote, por exemplo, de uma rede A (170.5.x.x) é enviado para uma rede B (160.3.x.x). Nessa situação quando o cliente A enviar um pacote de origem do terminal (máscara ) com destino ao (mesma máscara) ele irá comparar o resultado da porção de rede utilizando a operação AND de cada IP e a sua máscara de sub-rede. Caso o resultado seja diferente, significará que o destino está em outra rede e o pacote será enviado ao roteador, que fará a ponte para a outra rede. Caso as máscaras de sub-rede sejam diferentes, o pacote será enviado diretamente para o roteador, pois trata-se de redes diferentes (BARRETT; KING, 2010). A estrutura do exemplo, acima descrito, é representada pela figura 23. Além da divisão da porção de rede e de terminais apresentada, também é possível subdividir a rede em sub-redes, o que criará a possibilidade de tráfego entre terminais 49

74 Terminal A IP Máscara Terminal B IP Máscara Roteador Figura 23: Roteamento entre duas redes IP. Fonte: Adaptado de Barrett e King (2010, p. 204). dentro de uma rede menor, sem a necessidade de passagem desses dados por toda uma rede maior. Com essa divisão o remetente conseguirá saber se o destinatário está próximo a qual roteador, ou se ele está fisicamente próximo. Assim, ele pode julgar se é necessário, ou não, trafegar por um link entre sub-redes para chegar no destino. Isso porque muitas vezes essa divisão em sub-redes pode identificar as filiais de uma rede de uma empresa. Além da localização geográfica de unidades os pacotes poderão ter um encaminhamento mais eficiente com a informação de sub-rede, já que pelo endereço mais restrito não haverá necessidade de um pacote ir para um rede mais ampla para ser roteado para um terminal que está próximo ao remetente. A configuração de sub-redes pode ser feita a partir uma alteração na máscara de sub-rede, ao emprestar um bit (ou mais) da porção do endereço destinado aos terminais. Desta forma o endereço IP terá uma porção de identificação da rede, outra da sub-rede e o resto dos terminais. Pode-se esclarecer melhor essa técnica com a análise do código binário do endereço de dois terminais, no qual o primeiro caso traz a máscara sem a subdivisão, onde ambos terminais estão na mesma rede. Depois, com a alteração da máscara de sub-rede, o mesmo endereço IP dos terminais configurarão sub-redes diferentes. Essas duas situações são apresentadas pela tabela 11. Na tabela 11 percebe-se que a quantidade de bits 1 da máscara de sub-rede não tem a necessidade de englobar bytes inteiros. Justamente essa extrapolação é que dividirá a rede em pedaços, com o empréstimo de bits da porção dos terminais. Assim, a primeira sub-rede irá do endereço até e a segunda sub-rede do endereço até , dividindo a rede em duas sub-redes ao emprestar um bit. 50

75 Tabela 11: Divisão de sub-redes. Sem sub-rede Máquina 1 Endereço IP Máscara Resultado AND x.x Máquina 2 Endereço IP Máscara Resultado AND x.x Com sub-rede Máquina 1 Endereço IP Máscara Resultado AND x Máquina 2 Endereço IP Máscara Resultado AND x Fonte: Barrett e King (2010). Caso sejam emprestados mais bits a quantidade de sub-redes irá se alterar, conforme a tabela 12. Tabela 12: Quantidade de sub-redes em relação ao empréstimo de bits. Bits emprestados na máscara Redes criadas Fonte: Barrett e King (2010). Visto como se dá a estrutura do endereçamento IP, é possível apresentar como é realizado o roteamento de um pacote IP entre origem e destino. Esse serviço é realizado não somente devido à presença dos endereços, mas também outros dados presentes no cabeçalho, que serão explicados a seguir Cabeçalho IP Juntamente com o endereço IP de origem e destino, são adicionadas outras informações ao payload (dados úteis a serem transmitidos, como áudio e vídeo) com o intuito de facilitar o roteamento. Todos esses dados adicionados estarão em um cabeçalho, que no datagrama IP terá de 20 a 24 bytes, enquanto o payload pode conter até ou bytes. A 51

76 estrutura do cabeçalho do datagrama IP é padronizada pela Internet Engineering Task Force (1981a) e será explicada baseando-se na request for comments (RFC) 791, conforme a estrutura apresentada na figura 24, que mostra a distribuição das funções dos bits do cabeçalho. Figura 24: Distribuição dos bits do cabeçalho do datagrama IP. Fonte: Adaptado de Internet Engineering Task Force (1981a, p. 11) Versão Nos quatro primeiros bits será indicada a versão do IP. Caso o datagrama esteja na versão 4 esse campo mostrará o número quatro em binário (0100) e caso seja a versão 6 o campo trará o número seis (0110) Internet header length (IHL) Em seguida quatro bits indicarão o tamanho do cabeçalho, representando-o a quantidade words de 32 bits presentes. Esse campo recebe o nome de IHL Tipo de serviço O próximo byte apresenta nos três primeiros bits se a procedência é de controle de rede e nos restantes pode-se inserir fatores de qualidade de serviço, como indicação da relevância de atraso, taxa de transferência e confiabilidade Tamanho Total Na sequência, é identificado, em 16 bits, o tamanho total do datagrama, computando-o em número de bytes. 52

77 Identificação Em continuidade, 16 bits serão responsáveis por identificar um rótulo dado ao remetente no ato da transmissão, para facilitar na identificação dos datagramas que serão fragmentados na transmissão Flags A fragmentação também usará os próximos três bits, conhecidos como flags, em que o primeiro sempre será 0, e os seguintes indicarão se o datagrama foi ou não fragmentado e se existem outros fragmentos após o atual ou se ele é o último Offset do segmento Também para o controle da fragmentação, os próximos 13 bits indicarão a ordem de cada fragmento do datagrama, com o primeiro fragmento rotulado como zero e os próximos medidos em bytes Time to live (TTL) Em continuidade, um byte indicará o tempo de vida do datagrama. No momento que este valor chegar a zero o datagrama será descartado. O tempo é medido em segundos e pode ser decrescido após a passagem em cada módulo de rede. Esse byte de TTL é importante para que dados perdidos não continuem por muito tempo na rede, o que poderia causar um congestionamento Protocolo O byte seguinte do TTL identifica, com números tabelados, para qual protocolo de transporte os dados serão entregues Checksum do cabeçalho Para a verificação se os datagramas foram corrompidos na transmissão os próximos 16 bits realizarão a operação de checksum, que é somar os valores somente do cabeçalho e gravar esse resultado nestes 16 bits. O algoritmo utilizado é guardar o valor desse campo e depois atribuir 0 aos seus 16 bits. Depois são agrupados todos os bits em palavras 53

78 (16 bits) e somados os valores binários de todas elas. Por fim, toma-se o resultado e realiza-se o complemento de um (invertendo bits 0 por 1 e vice-versa) e compara ao valor gravado antes de zerar o campo. Caso ele seja igual à conta realizada, o pacote não está corrompido. Como existe uma dinamicidade em alguns valores do header, essa soma é recalculada constantemente. Como exemplo do cálculo do checksum, para envio do datagrama, será considerado um cabeçalho IP com 24 bytes. Primeiramente é necessário agrupá-los em words de 16 bits, atribuindo (0x0000) no campo do checksum, conforme explicitado na tabela 13: Tabela 13: Agrupamento em words. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x0000) 0xc0a8 0x010b 0xc0a8 0x0172 0xf8f1 0xf300 O próximo passo é realizar a somatória de todas as words, contando com o checksum, que foi zerado. No caso do exemplo o resultado da somatória é 6d304. Para que o resultado continue sendo uma word de 16 bits soma-se o carryover ao resultado, conforme tabela 14. Tabela 14: Somatória das words. 0x d x x d 3 0 a Por fim toma-se o resultado do passo anterior, 0xd30a, e aplica-se o complemento de 1 tomando como resultado os últimos 16 bits. Esse procedimento resulta no valor final de 0x2cf5, que substituirá o 0x0000 inserido no campo no início do algoritmo. Assim o cabeçalho IP que irá para a camada inferior será o expresso na tabela 15. Tabela 15: Cabeçalho IP final. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x2cf5) 0xc0a8 0x010b 0xc0a8 0x0172 0xf8f1 0xf300 No receptor do datagrama será feito exatamente o mesmo procedimento e o resultado final a ser obtido será 0x0000 caso todos os bits sejam recebidos corretamente, conforme demonstrado na tabela 16: 54

79 Tabela 16: Cabeçalho IP no receptor. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x2cf5) 0xc0a8 0x010b 0xc0a8 0x0172 0xf8f1 0xf300 O resultado da somatória será 0x6fff9. O próximo passo será manter o resultado em uma word de 16 bits, somando-se o carryover, conforme tabela 17. Tabela 17: Cálculo da somatória no receptor. 0x f f f 9 0x x f f f f Ao resultado 0xffff aplica-se o complemento de 1, o que resulta em 0x0000, portanto, os bits recebidos estão corretos. Pode ser que ocorra um erro na transmissão e, por exemplo, os dois últimos bytes do IP do destino sejam alterados, fazendo com que o datagrama flua para o terminal com IP (0xc0a8 0x0101), ao invés do (0xc0a8 0x0172). Nesse caso, o terminal receptor detectará que o pacote não foi destinado à ele pois o valor do checksum não terá como resultado, após o algoritimo de verificação, o valor hexadecimal de 0x0000, conforme demonstrado na tabela 18, com a nova sequência, porém com o erro citado. Tabela 18: Caso de erro na transmissão. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x2cf5) 0xc0a8 0x010b 0xc0a8 0x0101 0xf8f1 0xf300 O resultado da somatória de todos esses valores será 0x6ff88. Esse valor transformado em 16 bits, conforme algoritmo, será 0xff8e e seu complemento de 1 resultará em 0x0071, que é justamente a diferença, em hexadecimal, em relação ao valor correto e o erro ocorrido. Apesar dessa informação o receptor não poderá corrigir o erro, pois ele não tem a informação de em qual das words ocorreu o erro nos últimos dois bits. Assim, o receptor somente saberá que o pacote que chegou foi endereçado erroneamente à ele, já que não resultou em 0x0000, o que permite que o terminal ignore o conteúdo do datagrama recebido. 55

80 IP de Origem e Destino Os 32 bits seguintes ao checksum indicarão o endereço IP de origem e os próximos 32 bits o endereço IP do destino Opções e Padding Os últimos 32 bits são opcionais, e para cada aplicação esse campo poderá ter uma quantidade de alocação de bits. Porém, caso exista o campo opções, ele sempre será completado com zeros 2 para atingir 32 bits (TORRES, 2001). Entre as possibilidades de uso desses últimos bits existe a opção de realizar gravação da rota do datagrama e aplicações de segurança (INTERNET ENGINEERING TASK FORCE, 1981a) Fragmentação IP Conforme observado no descritivo do cabeçalho do datagrama IP, existem alguns campos relacionados a fragmentação. A existência dessa divisão fica clara ao analisar a relação entre as camadas de enlace, rede e transporte do modelo OSI, explicada anteriormente. O tamanho dos quadros do enlace poderão variar de acordo com a tecnologia empregada, que limita uma máxima quantidade de bits por quadro, chamada maximum transmission unit (MTU). Assim, o tamanho do datagrama IP pode ser estruturado para obter uma quantidade compatível de bytes ao MTU da camada de enlace. Porém, os dados poderão ser trafegados em tecnologias diferentes, com valores heterogêneos de MTU, que podem impedir que um datagrama IP completo seja disposto em um quadro (KUROSE; ROSS, 2011). O valor de 576 bytes é um valor interessante a ser utilizado, já que ele é compatível com todos os hosts (INTERNET ENGINEERING TASK FORCE, 1981a). Para resolver esse problema, foram adicionados alguns campos no cabeçalho IP para que a carga útil de um datagrama pudesse ser fragmentada em datagramas menores e coubessem em um quadro. Assim, os campos identificação, flags e offset de segmento têm como objetivo auxiliar na fragmentação e desfragmentação do datagrama IP. A camada que fará esse processo é a de rede (no modelo OSI), já entregando os dados não fragmentados para a camada de transporte (KUROSE; ROSS, 2011). 2 Torres (2001) explica que esses zeros adicionais também são conhecidos como pad ou padding 56

81 Como exemplo de uso dos campos no processo de fragmentação, pode-se considerar um datagrama com bytes para ser transmitido em um enlace com MTU igual a 1700 bytes. Os dados úteis do datagrama original serão 9980 bytes, considerando um cabeçalho com 20 bytes. Esse payload terá que ser dividido em um múltiplo de oito bytes, já que esta é a base para a contagem utilizada no offset do segmento. O menor número múltiplo de oito e menor do que o MTU será = Assim, os 9980 bytes serão fragmentados em blocos de 1696 bytes que resultará em 5 fragmentos completos e um fragmento com os restantes 1500 bytes 3. Portanto, serão no total 6 fragmentos em diferentes datagramas IP, que representam um original, que será remontado no destino, com auxílio de informações do cabeçalho. No campo identificação será inserido um valor que rotulará o datagrama a ser fragmentado e este valor estará presente também em todos seus fragmentos. A flag trará o bit 1 para indicar ao destinatário que existem outros fragmentos a chegar e o bit 0 indica o último fragmento. Outro campo do cabeçalho utilizado no processo de fragmentação e desfragmentação é o offset de segmento. Ele indicará a ordem de montagem dos fragmentos, para gerar um único datagrama. Neste campo atribui-se o valor 0 para indicar que os dados precisam ser inseridos a partir do byte 0. Assim, no exemplo dado, o segundo pacote conterá o valor 212 pois = 1696, o que indica que os dados do segundo pacote deverão ser inseridos a partir do byte de número 1696 (recorda-se que o primeiro byte é considerado como 0 ). Os dados do terceiro fragmento terão no campo offset de segmento o valor 424 que representa que os dados devem ser alocados a partir do byte 3392, ou seja, após o primeiro e segundo fragmento. Assim ocorrerá sucessivamente até o último fragmento (KUROSE; ROSS, 2011) Exemplo de aplicação IP no DASH No caso do DASH os conteúdos de áudio e vídeo não são encapsulados diretamente no payload do datagrama IP. Com o DASH, as solicitações dos recursos estarão no protocolo HTTP, dentro dos pacotes TCP. Já para a transferência dos pedaços dos vídeos, o conteúdo estará diretamente dentro dos pacotes TCP. Aplicando-se o exemplo para o DASH, esses pacotes TCP estarão dentro do payload representado pela figura 25. Com a (5 1696) =

82 evolução para as próximas seções o conteúdo de dentro de cada payload será desmembrado e discutido, para a aplicação DASH. Cabeçalho IP (20 Bytes) Payload IP (até Bytes) Figura 25: Estrutura do datagrama IP. Fonte: Adaptado de Torres (2001, p. 81). 4.3 CAMADA DE TRANSPORTE: UDP e TCP Conforme abordou-se na sessão anterior, o DASH não trabalha com a inserção do conteúdo de áudio e vídeo diretamente dentro do payload IP, somente com o acréscimo do cabeçalho IP. Esse fato traz uma vantagem pois o IP não garante por si só que os datagramas cheguem ao destino, pois essa garantia é de responsabilidade da camada de transporte, que é explicada nesta sessão. Na realidade, os dados multimídia primeiramente passarão pelo tratamento da camada de transporte, com a adição do cabeçalho UDP ou TCP, para depois serem enviados para o encapsulamento IP pela razão supracitada. Conforme explicado ao descrever modelo TCP/IP, existem dois principais protocolos para transportar e garantir a integridade dos dados: o TCP e o UDP. Uma das funções desses protocolos é gerenciar as portas, que são complementos dos endereços IP e indicam uma aplicação específica para qual os dados devem ser enviados. Existem portas, que são indicadas no cabeçalho do pacote de transporte (BARRETT; KING, 2010). Podese estabelecer uma analogia entre as portas e o número de uma casa em uma vila. O endereço IP seria como a cidade, rua, número e bairro do condomínio; porém, dentro dele existem diversos moradores (aplicações), cada um com um número de casa (porta). Essa camada também fará o processo de multiplexação e demultiplexação dos dados. Isso porque diversas aplicações podem enviar dados para um único destino e a camada de transporte irá rotular os segmentos, entre outras informações, com a porta da aplicação destinatária e esses serão unidos no datagrama IP (encapsulamento da camada de rede), o que caracteriza o processo de multiplexação. No destino, os diversos pacotes IP terão seus dados transferidos para a camada de transporte, que irá demultiplexar os dados, pois enviará para a aplicação correta cada informação, ao analisar as portas de destino 58

83 (KUROSE; ROSS, 2011). As diferenças entre a multiplexação TCP e a UDP, assim como cada estrutura de seus segmentos, serão explicados a seguir UDP Este protocolo é caracterizado por não ser orientado à conexão, já que não estabelece uma sessão que se abre no início da comunicação entre dois terminais e se finaliza com a transmissão da última mensagem. Esse processo pode ser compreendido com a análise da multiplexação e demultiplexação dos segmentos UDP. No cabeçalho desse protocolo haverá um endereço de porta de destino e da fonte para cada segmento. Em cada aplicação pode-se relacionar um número de porta a um socket 4. Quando esse pacote é recebido, o terminal destinatário irá, na camada de transporte, analisar a porta de destino do segmento e verificar o socket associado à ela, que é atrelado a alguma aplicação. Vale ressaltar que cada terminal terá diversas aplicações em atividade e a cada uma delas será associado uma porta para cada um de seus sockets. Isso permite que a camada de transporte faça a demultiplexação dos dados recebidos pela camada de rede, com base no número da porta, que levará a um socket específico de uma aplicação (KUROSE; ROSS, 2011). Portanto, esse processo trata individualmente cada novo segmento, associando-o a um socket pré estabelecido pela aplicação. Algumas das vantagens em utilizar o UDP se dão pelo fato de que ele, por não ser orientado à conexão, não necessita uma troca inicial de mensagens entre origem e destino para abrir uma conexão. O protocolo UDP também não utiliza mecanismos de controle de tráfego, recebimento e retransmissões de pacotes perdidos. Essas características citadas provém ao UDP a propriedade de ter baixo atraso na transmissão, já que não tomará tempo em retransmissões, abertura de conexões e controles de tráfego. Essa propriedade também é reforçada devido à estrutura do protocolo, que é simples, o que exige menor processamento computacional para realizá-la, acarretando em menor tempo de processamento e possibilidade de gerenciar um número de conexões. Esses fatores se tornam interessantes quando se pensa em distribuição de conteúdos multimídia, que são robustos a pequenas perdas de pacotes, porém sensíveis ao atraso. Porém, o TCP tem sido uti- 4 Kurose e Ross (2011) definem socket como uma interface de software, que recebe e envia mensagens entre a rede e a aplicação. O socket é o conector de saída e entrada de informações da aplicação com todo o processo de transmissão de suas informações por uma rede. 59

84 lizado também para transmissão multimídia, devido à redução da perda de pacotes em redes e também bloqueio de firewalls para pacotes UDP (KUROSE; ROSS, 2011). A RFC 768 da Internet Engineering Task Force (1980) trata da estrutura do segmento UDP e diz que ele foi desenvolvido para ser um protocolo simples e que aplicações que exijam confiabilidade de entrega usem o TCP, que será explicado no próximo tópico. A estrutura tem apenas quatro campos, explicados de acordo com a RFC 768 e atribuídos aos bits do cabeçalho conforme a figura 26 (INTERNET ENGINEERING TASK FORCE, 1980). Figura 26: Distribuição dos bits do cabeçalho do segmento UDP. Fonte: Adaptado de Internet Engineering Task Force (1980, p. 2) Porta de origem e destino Cada campo de indicação de porta é composto por dois bytes (16 bits) e informam qual é o número da porta associada ao socket de origem e destino, respectivamente. Caso não seja exista um número de porta, é atribuído o valor zero Tamanho total Esse campo é composto por um byte. Traz a quantidade de bytes do segmento, contando com o cabeçalho e dados úteis. O mínimo valor é oito: dois bytes para cada porta, um para tamanho total e outro para checksum Checksum É composto pelo último byte do cabeçalho e tem seu algoritmo igual ao apresentado no cabeçalho IP. A diferença é que ele considera para a somatória do pseudocabeçalho IP, o cabeçalho UDP e dados úteis. Esse pseudocabeçalho, anexado antes do segmento UDP, conterá os IPs da origem, destino, protocolo utilizado e o tamanho do cabeçalho UDP. A vantagem do uso dos IPs no checksum é que a entrega do segmento para um 60

85 IP errado será detectada (STALLINGS, 2005). Vale frisar que essa característica de detecção já foi exemplificada na apresentação do cabeçalho IP dessa dissertação. Naquele exemplo utilizou-se como IP de origem o (0xc0a8 0x010b) e de destino o (0xc0a8 0x0172). No mesmo exemplo também foi demonstrada a detecção do erro, ao alterar os dois últimos bits do IP de destino. Ressalta-se que caso os dados não estejam em um múltiplo de oito bits, devem ser acrescentados zeros para satisfazer essa condição, para que o último grupo da somatória tenha 16 bits. Caso o segmento chegue no destino com o checksum preenchido de zeros, quer dizer que a origem não quis gerar esse algoritmo de verificação de erros TCP Diferente do UDP, esse protocolo é orientado à conexão. Essa característica também está ligada ao processo de multiplexação e demultiplexação dos dados entre a camada de rede e transporte. Ao se orientar a conexão, o TCP irá se diferenciar do processo do UDP pois o socket TCP é criado com a base de quatro elementos: IP da fonte, número da porta da fonte, IP do destino e número da porta do destino (KUROSE; ROSS, 2011). Assim é estabelecida uma conexão entre sockets únicos, gerados pelos dados de ambas as pontas. Ao receber os dados da camada de rede o destinatário analisará, na camada de transporte, esses quatro elementos, para assim enviar as informações para a aplicação correta. Outra diferença entre o UDP e TCP é que, para o processo não orientado à conexão, dados procedentes de IPs diferentes, mas com a mesma porta de destino, irão para o mesmo socket. Porém, para o TCP é criado um socket para cada par de IP remetente e porta de destino. A única exceção é para o momento de abertura de uma conexão, pois o TCP espera, por exemplo na porta 6789, alguma requisição de começo de conexão, independente do IP de origem. Para a abertura de uma conexão, o terminal enviará um pedido de início de conexão para uma porta preestabelecida. O terminal remetente receberá o pedido e verificará qual aplicação deseja abrir uma conexão, e com base nos quatro elementos (IP e porta fonte, IP e porta destino) irá criar um socket específico para que todos os dados que chegarem com as quatro informações serão destinados para a mesma aplicação, ou seja, está aberta uma conexão entre duas aplicações de dois terminais diferentes (KUROSE; ROSS, 2011). 61

86 O TCP também tem ferramentas de controle de congestionamento de tráfego de rede, que possibilitam o envio de quantidade de dados de acordo com a capacidade de leitura do cliente, assim como características da rede. O protocolo em questão também consegue organizar a ordem dos pacotes recebidos e requisitar somente os perdidos. Outra tarefa do TCP é receber o fluxo de dados da camada de rede e dividí-lo em pedaços de 1460 bytes para compatibilizar com o tamanho do quadro ethernet (1500 bytes), já que serão adicionados os cabeçalhos TCP (20 bytes) e IP (20 bytes) (TANENBAUM; WETHE- RALL, 2010). O cabeçalho TCP, assim como a função de cada campo, são definidos pela RFC 793 da Internet Engineering Task Force (1981b) e apresentados a seguir. A estrutura desse cabeçalho é representada pela figura 27, em que os bits destacados em cor mais escura representam o campo reservado, originalmente com oito bits. Porém, com o tempo, utilizaram-se dois bits para flags, explicadas posteriormente. Um exemplo de um cabeçalho com dados numéricos também será apresentado futuramente. Figura 27: Distribuição dos bits do cabeçalho do segmento TCP. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 350) Porta de origem e destino No primeiro e segundo campos, compostos por dois bytes cada, são mostrados os números da porta de origem e destino, respectivamente, da mesma forma apresentada no cabeçalho UDP (INTERNET ENGINEERING TASK FORCE, 1981b). 62

87 Número de sequência Esse campo, com 32 bits, traz o número da etiqueta do primeiro byte dos dados. Essa etiqueta rotula linearmente cada byte do fluxo de dados, iniciando com um valor aleatório, combinado entre a origem e o destino (KUROSE; ROSS, 2011). Um exemplo seria a transmissão de um dos trechos de vídeo em DASH, que resultou em uma quantidade de dados composta por bytes, que serão divididos em 1460 bytes por cada segmento TCP, o que resulta em 21 segmentos necessários para transmitir o trecho do vídeo por completo. Toma-se como valor combinado de etiqueta inicial o número 48. Assim, o primeiro byte será rotulado com esse número, acrescendo uma unidade a cada byte até o último, que terá a etiqueta de número Após cada byte de dados devidamente rotulado é possível enviar no campo número de sequência o valor da etiqueta do primeiro byte dos dados. No exemplo, o valor será 48 no primeiro segmento, 1508 no segundo segmento, 2968 no terceiro segmento, e assim consecutivamente até o último segmento, conforme representa a figura 28. Figura 28: Número de sequência do TCP. Fonte: Adaptado de Kurose e Ross (2011, p. 178). O número de sequência é utilizado para controle da reconstrução dos dados no destinatário, pois os dados podem ser organizados na forma correta, já que existe um rótulo linear de cada byte do arquivo completo. Por esse motivo, a falta de pedaços do arquivo também será facilmente notada, com base no número de sequência que será validado no pelo número de confirmação, conforme explicado no próximo tópico Número de confirmação O número de confirmação está relacionado ao procedimento de etiquetagem explicado na elaboração do número de sequência. Isso porque esse campo, que ocupa 32 bits, traz 63

88 o número do rótulo do próximo byte esperado, com base no que já foi recebido. Esse número só será mudado ao se verificar que os bytes já recebidos podem ser organizados sequencialmente sem trechos faltantes (KUROSE; ROSS, 2011). No exemplo da figura 28, após receber o primeiro segmento, o destinatário responderá ao remetente com o valor 1508 no campo do número de confirmação; ou seja, o próximo segmento esperado é ter os dados a partir desse valor, pois já recebeu os bytes rotulados de 48 a 1507 e espera continuar o recebimento dos próximos dados da sequência. Pode acontecer que, após a transmissão de vários segmentos subsequentes, não haja mudança no número de confirmação. Isso indica que o segmento com o número de sequência 1508 não teve confirmação de chegada por parte do cliente, ou seja, pode ter sido corrompido ou perdido na transmissão. Assim, o servidor, ciente do problema, retransmitirá o segmento após o timeout Comprimento do cabeçalho Traz a quantidade de grupos de 32 bits no cabeçalho TCP, representada em um código de quatro bits (INTERNET ENGINEERING TASK FORCE, 1981b) Flags O cabeçalho tem oito flags, compostas por um bit cada, que indicam estado ativado quando o bit está em um e desativado quando o bit está em zero. Eles são explicados, um a um, na sequência. CWR Esta flag é chamada Congestion Window Reduced e, se ativada, sinaliza que o transmissor reduziu o tamanho da janela, que será explicada em breve. Essa ação leva a uma diminuição da quantidade de arquivos transmitidos sem a chegada de uma confirmação de recebimento do dado, chamado recibo (Acknowledgment) (TANENBAUM; WETHERALL, 2010). ECE É uma sigla para explicit congestion notification (ECN) echo. Essa flag juntamente com a CWR é responsável por sinalizar um congestionamento (ECN). O receptor envia ECN-echo para o transmissor como pedido de redução na transmissão, ou seja, realize 5 Tempo que começa a ser contado a partir do envio do segmento, zerado com a confirmação da chegada dele no cliente. Caso ultrapassado valor estipulado, o segmento será retransmitido. 64

89 uma redução no tamanho da janela. O receptor deixará de informar ECE quando o transmissor devolver CWR (TANENBAUM; WETHERALL, 2010). URG Esta flag ativa a verificação do ponteiro de urgência, que indicará que os próximos bytes serão urgentes. Em breve será explicada mais detalhadamente essa situação. ACK A flag Acknowledgment é utilizada para indicar que o número de confirmação é válido. Ou seja, espera-se novos dados (indicados no número de confirmação), o que confirma que os anteriores foram recebidos (INTERNET ENGINEERING TASK FORCE, 1981b). Essa flag é o recibo de recebimento de pacotes e caso o bit seja zero quer dizer que o segmento não traz confirmações. PSH Esta flag é chamada de PUSH que solicita ao receptor que todas as informações com essa flag ativada sejam entregue imediatamente à aplicação destinatária, sem que se realize um buffer dessa informação (TANENBAUM; WETHERALL, 2010). RST Indica RESET, isto é, reinício da sessão. Essa flag será ativada caso ocorra algum erro ou também para recusar uma conexão (TANENBAUM; WETHERALL, 2010). SYN Sigla para Synchronize sequence numbers, para que seja acordado o número de sequência inicial de uma sessão. Portanto responsável por iniciar uma conexão, processo explicado em breve (INTERNET ENGINEERING TASK FORCE, 1981b). FIN Flag indicadora de que não há mais dados para serem enviados, assim encerrando uma conexão, que também terá seu processo explicado oportunamente Tamanho da janela Este campo ocupa 16 bits do cabeçalho e define quantos bytes terá o tamanho da janela. O janelamento TCP é uma técnica utilizada para permitir o envio de novos dados, mesmo sem ter recebido a confirmação da entrega dos anteriores. Essa possibilidade causa um melhor aproveitamento do tempo, já que o sistema não esperará a confirmação da chegada de cada pacote para enviar um novo, e sim aproveitará esse tempo enviando mais dados enquanto espera. Porém, deve haver um limite para envio de novos dados sem receber as confirmação dos anteriores. Essa demarcação é definida pelo tamanho da 65

90 janela, nesse campo de dois bytes. No caso do TCP a janela tem tamanho variável, avança de acordo com o recebimento das confirmações e trabalha byte a byte, ao invés de a cada pacote (TORRES, 2001). A figura 29 demonstra como se dá essa dinâmica. t Janela (tamanho fixo) t +1 Aguardando ACK Próximos envios Ponteiro 1 Ponteiro 2 Ponteiro 3 ACK t +2 Ponteiro 1 Ponteiro 2 Ponteiro 3 ACK ACKACK Bytes Bytes Bytes Ponteiro 1 Ponteiro 2 Ponteiro 3 Figura 29: Dinâmica da janela do TCP. Fonte: Adaptado de Torres (2001, p. 107). Na figura 29 é possível observar um fluxo de bytes que foram numerados em sequência. No caso apresentado, foi utilizada uma janela fixa para facilitar a compreensão da dinâmica do algoritmo. O ponteiro 1 aponta entre o último byte que houve confirmação (ACK) e o que ainda não teve tal validação. O ponteiro 2 divide os bytes já enviados e os próximos a serem transmitidos. Ressalta-se que este ponteiro se desloca em uma velocidade constante, no caso apresentado, dois bytes por unidade de tempo. Por fim, o último ponteiro aponta o último byte da janela. Os ponteiros 1 e 3 se moverão quando ocorrer o recebimento de confirmação de recebimento dos bytes anteriores à janela, enquanto o ponteiro 2 se move constantemente, conforme ilustrado nos tempos t + 1 e t + 2. Caso o ponteiro 2 chegue ao final da janela, o envio será pausado. Na prática, o tamanho dessa janela é variável, conforme informação da escala da janela, presente em opções e explicado no tópico dedicado a esse campo. Ao inserir o valor zero neste campo, o cliente diz ao servidor que já recebeu todos os pacotes até o número de confirmação 1 e necessita de uma pausa na transmissão. A retomada pode ser feita ao enviar um segmento com o número 66

91 de confirmação corrente e o campo tamanho da janela com um valor diferente de zero (TANENBAUM; WETHERALL, 2010) Checksum Este campo de dois bytes trará o mesmo algoritmo apresentado no UDP conforme a estabelece a RFC 768 (INTERNET ENGINEERING TASK FORCE, 1980) Ponteiro de urgência Este campo, com 4 bytes, aponta a quantidade de bytes com caráter de urgência, contado a partir do número de sequência vigente. Dessa forma nenhum processo deve ser interrompido até que todos os bytes de urgência tenham chegado ao destinatário. Essa função somente será ativada com o bit da flag URG setado no número um (TANENBAUM; WETHERALL, 2010) Opções Este campo pode ocupar até 40 bytes e sua quantidade deve ser múltipla de oito bits. Ele foi criado para adicionar funcionalidades no cabeçalho TCP. Neste campo haverá uma sequência de oito bits zero para indicar seu fim. Entre cada recurso dentro do campo opções haverá uma sequência de sete zeros e por último o bit um. Dentre as funcionalidades possíveis, está o tamanho máximo de segmento e será enviado juntamente com o bit SYN igual a um, ou seja, na abertura da sessão (INTERNET ENGINEERING TASK FORCE, 1981b). Outra função está ligada à variação do tamanho da janela TCP. Com o window scale o tamanho da janela poderá ser maior, já que com os 16 bits do campo é possível chegar no máximo a uma janela de 64 KB. Essa função permite deslocar o valor do tamanho da janela 14 bits para a esquerda o que resulta em janelas de até = 30 bits, ou seja, por volta de 1 GB de janela (TANENBAUM; WETHERALL, 2010) Processo de abertura de conexão Para abertura de uma conexão, o cliente pode enviar ao servidor um número de sequência escolhido e o pedido de SYN, o que pede uma sincronização desse número com a outra ponta da futura conexão. O servidor irá responder com esse número de sequência 67

92 juntamente com o SYN e ACK ativados. Por fim, o cliente retornará um ACK para o servidor com uma solicitação, o que inicia a conexão entre as duas pontas. Esse processo é conhecido por three-way handshake, pois firma um acordo de conexão em três passos e é representado pela figura 30 (TORRES, 2001). Cliente Servidor Número de Sequência + SYN Número de Sequência + SYN + ACK Solicitação + ACK Tempo Figura 30: Abertura da conexão TCP. A figura 31 traz um exemplo, com um cenário do DASH, do terceiro passo da abertura de conexão, na qual o reprodutor do vídeo DASH, com IP , responde ao servidor do conteúdo (IP ), com a flag ACK ativada (igual ao bit 1). No cabeçalho também pode-se inferir que o cliente já recebeu todos os bytes anteriores corretamente, já que o campo de número de confirmação autentica o recebimento dos bytes até a sequência 1507 e o primeiro byte do datagrama em questão traz o número de sequência seguinte, O exemplo também esclarece o uso do campo do comprimento do cabeçalho, que traz o número 5, que é a quantidade de grupos de 32 bits no cabeçalho enviado. No caso do campo do tamanho da janela o valor 0, pausará a transmissão temporariamente. Tal campo zerado indica que apesar de todos os bytes até a sequência 1507 tenham sido recebidos, o cliente não deseja novos datagramas. Esse cenário pode acontecer no caso do cliente não ter conseguido tomar todas as providências com os dados, como, por exemplo, a situação do reprodutor DASH estar com o buffer cheio. O estudo desse caso será abordado nos testes realizados. O campo seguinte traz o checksum do cabeçalho, com o algoritmo já apresentado anteriormente, e, por fim, o campo de ponteiro de urgência 68

93 aparece com o valor 0 pois não está sendo utilizado. Figura 31: Exemplo de distribuição dos bits do cabeçalho do segmento TCP. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 350) Processo de fechamento de conexão Para fechamento da conexão estabelecida, uma das partes informa que não existe mais dados a serem transmitidos, ao setar a flag FIN. No processo ocorrerá essa finalização por ambas as partes, da seguinte forma: um terminal A envia o pedido de finalização da conexão (mensagem com FIN ativado), o terminal B responde um ACK, com o FIN inativo, o que confirma o entendimento do pedido de finalização da conexão. Depois, o terminal B envia o pedido de finalização, com o FIN ativado, e o terminal A retorna um ACK, conforme figura 32 (TORRES, 2001) Exemplo de aplicação TCP no DASH No caso do DASH o protocolo de transporte utilizado é o TCP. Assim, quando é solicitado o início da reprodução no Mini-PC Android, o primeiro passo a ser feito é estabelecer uma conexão TCP, realizada conforme já explicado. Da mesma forma, quando o vídeo é finalizado existirá uma solicitação, por parte da caixa Android, para encerramento da conexão. Depois desse estabelecimento a aplicação VLC enviará uma mensagem HTTP solicitando o recurso para o servidor. Esta mensagem, assim como os pedaços do vídeo, codificados em H.264 e inseridos em um container mp4, estarão dentro do payload TCP, conforme a figura

94 Terminal A Terminal B FIN ACK FIN ACK Tempo Figura 32: Fechamento da conexão TCP. Cabeçalho IP (20 Bytes) Payload IP (1480 Bytes) Cabeçalho TCP (20 Bytes) Payload TCP 1460 Bytes Figura 33: Estrutura pacote TCP/IP. 4.4 CAMADA DE APLICAÇÃO: HTTP, RTP/RTCP e RTSP Nessa camada estarão as aplicações que tratarão os dados de forma mais próxima ao usuário. Os processos de estruturação e codificação DASH, já apresentados no terceiro capítulo estão nessas camadas, em aplicativos dedicados à essas tarefas. Na cadeia de transmissão de dados em redes IP, voltadas ao streaming, existem protocolos que fazem a administração das informações, repassando-as para a camada de transporte. Entre eles, são destacados em sessões dedicadas, o HTTP, RTP, RTCP e o RTSP HTTP O HTTP é o protocolo utilizado na Internet que padroniza a comunicação entre um servidor e um cliente, e é normatizado pela RFC 2616 da Internet Engineering Task Force (1999). O HTTP é aplicado sobre a camada de transporte TCP, com o uso de um socket, 70

95 que utiliza a rede IP. Entre as possíveis trocas de mensagens entre servidor e cliente está a solicitação de conteúdos, localizados pelo Uniform Resource Locator (URL) 6. O HTTP é rotulado como um protocolo sem estado, pois nativamente ele trata cada solicitação de recurso de forma separada, sem levar em consideração os pedidos realizados anteriormente, ao conectar e desconectar conexões TCP entre o servidor e o cliente a cada troca de informação. Esse processo, sem persistência, implica em haver múltiplos three-way handshakes para abertura de cada conexão, o que dispende tempo e recursos computacionais. Porém, a partir da versão HTTP 1.1 surge a possibilidade de criar conexões TCP persistentes, que agrupam diversas solicitações e respostas em uma única conexão (BARRETT; KING, 2010). Nessa configuração, após a resposta do servidor (no segundo passo da abertura), será mantida aberta a conexão para que sejam trocadas solicitações e reconhecimentos (ACK) entre cliente e servidor sem a solicitação de finalização. O fim só será requisitado caso o tempo de recebimento entre cada solicitação ultrapasse um valor estipulado na conexão, que pode indicar fim das requisições (KUROSE; ROSS, 2011). Como exemplo prático de conexão não persistente é possível considerar que em um servidor existe um filme que foi particionado em vários pedaços com dois segundos cada, conforme aplica-se no DASH. No reprodutor serão feitas requisições HTTP de cada trecho de dois segundos, uma de cada vez. O pedido do recurso implicará no seguinte processo: abertura de uma conexão TCP, com o three-way handshake, transferência de todos os pacotes do arquivo pedido e, por fim, o fechamento da conexão, conforme já explicado anteriormente. Para o próximo trecho do vídeo ser carregado no reprodutor é preciso que novamente seja feito todo o processo, com a abertura da conexão, transferência de todo o arquivo seguinte, e fechamento da conexão. A figura 34 ilustra esse processo. Um outro tipo de conexão é a persistente, que pode ser com requests sequenciais ou em pipeline. No caso das solicitações em sequência para se transferir os trechos do vídeo haverá somente uma abertura de conexão TCP. Isso porque após a transferência completa de todos os pacotes do primeiro pedaço do vídeo não haverá o fechamento da conexão e, na sequência, um novo trecho será solicitado, o que já dará início a transferência dos 6 URLs são endereços utilizados para localizar recursos em uma rede, e para o HTTP ele é padronizado, na RFC 2396, na seguinte forma: http URL = http: // servidor [ : porta ] [caminho do recurso [? pergunta da aplicação]] (INTERNET ENGINEERING TASK FORCE, 1998b). 71

96 Cliente { Abertura Conexão Transferência Trecho 1 { Fechamento{ Conexão { Abertura Conexão Transferência Trecho 2 { Seq + SYN+ACK ACK FIN Seq + SYN+ACK Seq + SYN FIN ACK Seq + SYN Figura 34: Conexão não persistente. Servidor Solicitação + ACK Solicitação + ACK Tempo Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 685). pacotes, sem abertura de nova conexão. Esse processo ocorrerá sucessivamente para todos os trechos do vídeo, conforme ilustra a figura 35. Cliente { Abertura Conexão Transferência Trecho 1 { Transferência Trecho 2 { Transferência Trecho 3 { Tempo Seq + SYN+ACK Seq + SYN Servidor Solicitação + ACK Solicitação + ACK Solicitação + ACK Figura 35: Conexão persistente com solicitações sequenciais. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 685). Outra possibilidade de conexão persistente é realizar os requests em pipeline, ou seja, pedir em paralelo os trechos do vídeo, não esperando terminar a transferência de um para começar o outro. A figura 36 ilustra o exemplo da conexão em pipeline. 72

97 Cliente { Abertura Conexão Transferência Trecho 1 { Transferência Trecho 2 { Transferência Trecho 3 { Transferência Trecho 4 { Seq + SYN+ACK Seq + SYN Servidor Solicitação + ACK Solicitação + ACK Solicitação + ACK Solicitação + ACK Tempo Figura 36: Conexão persistente com solicitações em pipeline. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 685). Portanto, a dinâmica da comunicação HTTP se dá com requisições, que são solicitações e ações que o cliente pede para o servidor, e respostas, que são as consequências de cada requisição. Ambas etapas são explicadas nas próximas sessões Estrutura da requisição O pacote de requisição HTTP é estruturado em três partes. A primeira é a linha de requisição, dividida em nome do método, endereço URL relacionado à requisição e indicação da versão do protocolo, por exemplo: GET /diretorio/imagens HTTP/1.1. A segunda parte contém os cabeçalhos, que trazem campos de informações também associados à requisição e têm a estrutura de nome do campo:valor do campo, como exemplo: Host: (que mostra o endereço do servidor) ou Connection: close (indica que a sessão deve ser fechada após requisição). A última parte do pacote HTTP é o corpo da entidade, que pode existir no caso de envio de dados ligados à requisição (KUROSE; ROSS, 2011). Um exemplo de uma mensagem de requisição, pelo Mini-PC Android ( ), do pedaço da sequência ZP1, durante a reprodução DASH, conforme tabela 19. Existem diversos tipos de requisições, relacionados ao método utilizado, alguns são mostrados na tabela

98 Tabela 19: Mensagem requisição do Mini-PC Android. GET /Arquivos DASH/PosBanca/zp1 t1/zp1 t1 1438kbit/zp1 t12.m4s HTTP/1.1 Host: Tabela 20: Alguns tipos de métodos de requisições HTTP. Método Ação relacionada GET Requisita um objeto na URL indicada HEAD Semelhante ao GET, porém a resposta não vem com o objeto requisitado PUT Escreve os dados da entidade na URL indicada POST Anexa os dados da entidade em subordinação à URL indicada DELETE Apaga os dados da URL referenciada Fonte: Adaptado de Internet Engineering Task Force (1999) Estrutura da resposta O servidor, após receber uma requisição, irá enviar uma resposta de acordo com o método explicado na sessão anterior. A estrutura da resposta HTTP é idêntica à requisição, só alterando-se a primeira parte, de linha de requisição para a linha de estado. Essa estrutura-se em versão do protocolo, código de estado e o significado do código, conforme o exemplo: HTTP/ Accepted. Da mesma forma que existem diversos tipos de métodos na requisição encontram-se vários códigos de estados de respostas, compostos por três dígitos, na qual o primeiro indica a classe da resposta. Essa pode ser de informação (código 1xx), sucesso (código 2xx), redirecionamento (código 3xx), erro de cliente (código 4xx) e erro de servidor (código 5xx). Nos cabeçalhos podem ser descritos qual o servidor utilizado, data de envio do pacote, data da última modificação, tamanho do payload em bytes, e tipo de conteúdo (INTERNET ENGINEERING TASK FORCE, 1999). A tabela 21 traz o exemplo para a resposta do reprodutor DASH, acusando o recebimento completo do arquivo solicitado no exemplo anterior. Tabela 21: Resposta HTTP do reprodutor DASH. HTTP/ OK Date: Thu, 28 Nov :20:01 GMT Last-Modified: Wed, 27 Nov :58:15 GMT Content-Length: Na linha de estado existe o código de estado, alguns mais típicos são descritos na tabela

99 Tabela 22: Alguns códigos de estados em respostas HTTP. Código Significado 1xx: Indica uma mensagem apenas informativa 2xx: Indica sucesso de algum tipo 200 OK 201 Created (Criada) 202 Accepted (Aceita) 3xx: Redireciona o cliente para outra URL 301 Moved Permanently (Mudou permanentemente) 302 Moved Temporarily (Mudou temporariamente) 304 Not Modified (Não modificada) 4xx: Indica um erro na parte do cliente 400 Bad request (Requisição malformada) 401 Unauthorized (Não autorizado) 403 Forbidden (Proibido) 5xx: Indica um erro na parte do servidor 500 Internal Server Error (Erro interno do servidor) 502 Bad Gateway (Gateway errado) 503 Service Unavailable (Serviço indisponível) Fonte: Adaptado de Barrett e King (2010) Sintaxe das mensagens HTTP A sintaxe das mensagens HTTP é baseada em duas RFCs. Uma delas é a RFC 822 da Internet Engineering Task Force (1982), que especificou como seriam os cabeçalhos das trocas de mensagens entre dois elementos e padronizou como código o American Standard Code for Information Interchange (ASCII). A outra referência é a RFC 2045 da Internet Engineering Task Force (1996) e trata-se de um complemento da primeira. Chamada de Multipurpose Internet Mail Extensions (MIME), a RFC 2045 e suas partes permitiram que elementos como figuras, vídeo e áudio, não presentes no código ASCII, pudessem ser compatibilizados na troca de mensagens pela Internet. Para tal são adicionados cabeçalhos do MIME ao cabeçalho da Internet Mail (RFC 822), que dão informações sobre o código binário dos dados úteis do corpo da mensagem. Essas referências rotulam o payload com o seu tipo de codificação e tamanho em bytes, para que o destinatário possa compreender como decodificar esses dados binários. Já os cabeçalhos da Internet Mail e MIME são textos codificados em ASCII, conforme suas respectivas RFCs. Assim, ao tomar o exemplo do código apresentado na sessão da estrutura da resposta pode-se afirmar que esse código será direcionado para a camada de transporte conforme a tabela ASCII, que gera um 75

100 fluxo de bits. Após o fluxo da linha de estado e dos cabeçalhos virá o código binário do arquivo de vídeo, codificado no padrão MPEG. Dessa forma, o cliente que receber esse pacote saberá separar a linha, cabeçalhos e dados úteis pois eles estão padronizados, e também saberá encaminhar o vídeo para a aplicação que consiga realizar a decodificação. O formato das mensagens segue conforme demonstrado nas figuras 37 e 38, para uma mensagem de requisição e de resposta, respectivamente. Linha de requisição Linhas de cabeçalho Linha em branco Corpo da entidade { { { { Método SP URL SP Versão CR LF Nome do campo de cabeçalho SP Valor CR LF... Nome do campo de cabeçalho SP Valor CR LF CR LF Legenda: SP = Espaço CR = Carriage Return LF = Line Feed Figura 37: Formato da mensagem de requisição HTTP. Fonte: Adaptado de Kurose e Ross (2011, p. 77). Nas figuras 37 e 38 o código SP identifica espaço, CR quer dizer carriage return que significa que o ponteiro de leitura deve voltar ao início e o LF é de line feed, que solicita a mudança para a próxima linha. Assim CR juntamente com LF faz o ponteiro de leitura ir para o início da próxima linha. A RFC 2616 deixa claro que sua sintaxe de mensagens não é totalmente compatível com o MIME, se diferenciando por alguns aspectos. Entre eles está que o campo do cabeçalho MIME-Version é opcional para o HTTP, e caso ele exista indicará que o cabeçalho HTTP está somente com os campos totalmente compatíveis com a estrutura MIME. Também a estrutura do formato das datas é diferente para o HTTP. Outros pontos de diferença se relacionam com os campos do MIME e do HTTP, que por vezes existem 76

101 Linha de estado Linhas de cabeçalho Linha em branco Corpo da entidade { { { { Versão SP Código de Estado SP Frase CR LF Nome do campo de cabeçalho SP Valor CR LF... Nome do campo de cabeçalho SP Valor CR LF CR LF Legenda: SP = Espaço CR = Carriage Return LF = Line Feed Figura 38: Formato da mensagem de resposta HTTP. Fonte: Adaptado de Kurose e Ross (2011, p. 78). em um formato e não no outro, principalmente os que envolvem codificação. Isso ocorre, por exemplo, no campo Content-Transfer-Encoding do MIME, que não existe no HTTP, o que exige que equipamentos de rede que fazem a conversão entre MIME e HTTP retirem esse campo (INTERNET ENGINEERING TASK FORCE, 1999) RTP e RTCP Esse protocolo de transporte em tempo real, chamado real-time transport protocol (RTP) normalmente utiliza o protocolo UDP para transporte de seu conteúdo. O RTP propriamente é utilizado para carregar dados com característica de tempo real, como áudio e vídeo. Juntamente com o RTP é utilizado um outro protocolo, chamado RTP control protocol (RTCP), que conferirá características de controle ao RTP. O RTCP não carrega dados de áudio e vídeo e sim dados para controlar a qualidade do serviço e informações sobre os participantes da sessão. Porém ambos não garantem a entrega do pacote ou que eles cheguem em ordem (INTERNET ENGINEERING TASK FORCE, 2003a). 77

102 RTP A principal função do RTP é multiplexar diferentes fluxos de áudio, vídeo e texto, em um único fluxo para o UDP. Para a demultiplexação são adicionados dados que identificam cada fluxo e para reprodução síncrona deles existe a adição de marcas de tempo (TANENBAUM; WETHERALL, 2010). Por exemplo, para transmissão de um conteúdo de áudio a 96 kbps o RTP pode coletar esse fluxo em grupos de 40 milissegundos. Assim, cada grupo será composto por , 04 = 3840 bits, ou seja, 480 bytes. Esses 480 bytes terão um cabeçalho RTP anexado para ser disponibilizado em um socket para o UDP. O cabeçalho RTP demonstra com mais detalhes essas e outras características para transmissão de áudio e vídeo. A RFC 3550 da Internet Engineering Task Force (2003a) padroniza o RTP e com base nela apresenta-se o cabeçalho RTP. Ele tem obrigatoriamente os 12 primeiros bytes em todos os pacotes, e os seguintes dependerão do número de fontes que contribuem no fluxo, tornando assim o tamanho do cabeçalho variável. A distribuição dos bits é representada na figura 39. Figura 39: Distribuição dos bits do cabeçalho RTP. Fonte: Adaptado de Internet Engineering Task Force (2003a, p. 13). Versão (V) Esse campo, composto de dois bits, indica a versão do RTP utilizada. A RFC 3550 apresenta a versão número 2. Padding (P) Caso o campo, de um bit, esteja ativado quer dizer que foi realizado padding na parte dos dados, para que completasse um múltiplo de quatro bytes. O último byte dos dados indica quantos bytes de padding foram adicionados. 78

3 Qualidade de serviço na Internet

3 Qualidade de serviço na Internet 3 Qualidade de serviço na Internet 25 3 Qualidade de serviço na Internet Além do aumento do tráfego gerado nos ambientes corporativos e na Internet, está havendo uma mudança nas características das aplicações

Leia mais

Jornalismo Multiplataforma. Tecnologias Redes e Convergência. eduardo.barrere@ice.ufjf.br

Jornalismo Multiplataforma. Tecnologias Redes e Convergência. eduardo.barrere@ice.ufjf.br Jornalismo Multiplataforma Tecnologias Redes e Convergência eduardo.barrere@ice.ufjf.br Panorama Em 2011, a TV atingiu 96,9% (http://www.teleco.com.br/nrtv.asp) TV Digital Uma novidade???? TV Digital Resolve

Leia mais

Prof. Manuel A Rendón M

Prof. Manuel A Rendón M Prof. Manuel A Rendón M Tanenbaum Redes de Computadores Cap. 1 e 2 5ª. Edição Pearson Padronização de sistemas abertos à comunicação Modelo de Referência para Interconexão de Sistemas Abertos RM OSI Uma

Leia mais

1. PRINCIPAIS PROTOCOLOS TCP/IP

1. PRINCIPAIS PROTOCOLOS TCP/IP 1. PRINCIPAIS PROTOCOLOS TCP/IP 1.1 IP - Internet Protocol RFC 791 Esse protocolo foi introduzido na ARPANET no início dos anos 80, e tem sido utilizado juntamente com o TCP desde então. A principal característica

Leia mais

Redes Mul)mídia. Tópicos. Streaming de Áudio e Vídeo. Aplicações de Rede Mul:mídia Introdução Classes de Aplicações Mul:mídia

Redes Mul)mídia. Tópicos. Streaming de Áudio e Vídeo. Aplicações de Rede Mul:mídia Introdução Classes de Aplicações Mul:mídia Redes Mul)mídia Streaming de Áudio e Vídeo Mário Meireles Teixeira Departamento de Informá:ca UFMA 2012 Tópicos Aplicações de Rede Mul:mídia Introdução Classes de Aplicações Mul:mídia Áudio e Vídeo de

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES REDES DE COMPUTADORES MEMÓRIAS DE AULA AULA 1 APRESENTAÇÃO DO CURSO, HISTÓRIA, EQUIPAMENTOS E TIPOS DE REDES Prof. José Wagner Bungart CONTEÚDO PROGRAMÁTICO Definição de Redes de Computadores e Conceitos

Leia mais

ESCOLA SECUNDÁRIA DO MONTE DA CAPARICA Curso de Educação e Formação de Adultos NS Trabalho Individual Área / UFCD

ESCOLA SECUNDÁRIA DO MONTE DA CAPARICA Curso de Educação e Formação de Adultos NS Trabalho Individual Área / UFCD 1 de 9 Desde o nascimento do telemóvel e o seu primeiro modelo vários se seguiram e as transformações tecnológicas que estes sofreram ditaram o nascimento de várias gerações. O Motorola DynaTac 8000X é

Leia mais

Exercícios Rede de Computadores I (27/05/2006)

Exercícios Rede de Computadores I (27/05/2006) UNIVERSIDADE FEDERAL DE VIÇOSA CENTRO DE CIÊNCIAS EXATAS E TECNOLOGICAS DEPARTAMENTO DE INFORMÁTICA Exercícios Rede de Computadores I (27/05/2006) Marcelo Santos Daibert Juiz de Fora Minas Gerais Brasil

Leia mais

Teste de Qualidade Web based para Banda Larga FAQs

Teste de Qualidade Web based para Banda Larga FAQs Teste de Qualidade Web based para Banda Larga FAQs Pergunta O que é o teste de velocidade? Quem é o público alvo? O que oferece? Como funciona? Por onde é o acesso? Resposta Um teste de qualidade de banda

Leia mais

Desenvolvimento de Aplicações Interativas. GINGA NCL e LUA. Projeto TV Digital Social

Desenvolvimento de Aplicações Interativas. GINGA NCL e LUA. Projeto TV Digital Social Desenvolvimento de Aplicações Interativas GINGA NCL e LUA Projeto TV Digital Social Marco Antonio Munhoz da Silva DATAPREV Gestor do Proejeto TV Digital Social AGENDA Divisão dos assuntos em quatro partes

Leia mais

Redes de Computadores e Teleinformática. Zacariotto 4-1

Redes de Computadores e Teleinformática. Zacariotto 4-1 Redes de Computadores e Teleinformática Zacariotto 4-1 Agenda da aula Introdução Redes de computadores Redes locais de computadores Redes de alto desempenho Redes públicas de comunicação de dados Computação

Leia mais

1. Introdução 1.1 Os sistemas de 4 a geração Quando falamos em redes de quarta geração (4G), dois nomes vem imediatamente à nossa cabeça: LTE (Long

1. Introdução 1.1 Os sistemas de 4 a geração Quando falamos em redes de quarta geração (4G), dois nomes vem imediatamente à nossa cabeça: LTE (Long 16 1. Introdução 1.1 Os sistemas de 4 a geração Quando falamos em redes de quarta geração (4G), dois nomes vem imediatamente à nossa cabeça: LTE (Long Term Evolution) e WiMAX [11]. A tecnologia LTE é um

Leia mais

Sistema GloVE. Solução de distribuição em grande escala de vídeos digitais sob demanda

Sistema GloVE. Solução de distribuição em grande escala de vídeos digitais sob demanda Sistema GloVE Sistema GloVE Solução de distribuição em grande escala de vídeos digitais sob demanda Introdução Diversas tendências estão mudando a maneira de se usar a Internet. Primeira, o número dos

Leia mais

Entenda os formatos mais populares de vídeo

Entenda os formatos mais populares de vídeo Entenda os formatos mais populares de vídeo Com o grande crescimento da internet banda larga no país muitos internautas estão cada vez mais tendo contato com arquivos de vídeo, tanto na visualização online

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

Streaming na pratica Shoutcast Flumotion

Streaming na pratica Shoutcast Flumotion Streaming na pratica Shoutcast Flumotion Felipe Santos dos Santos 1 1 Faculdade de Tecnologia Senac Pelotas(FATEC) Rua Gonçalves Chaves, 602 Centro CEP: 96.015-560 Pelotas RS Brasil Curso Superior de Tecnologia

Leia mais

UM PASSEIO PELA NAB 2011. Geraldo Cesar de Oliveira Star One

UM PASSEIO PELA NAB 2011. Geraldo Cesar de Oliveira Star One UM PASSEIO PELA NAB 2011 Geraldo Cesar de Oliveira Star One NAB 2011 em Números Mais de 1500 Expositores 151 países representados 92.708 visitantes cadastrados 25.601 visitantes internacionais Brasil uma

Leia mais

PAPEL BRANCO. Padrão de compactação de vídeo H.264. Novas possibilidades em vigilância por vídeo.

PAPEL BRANCO. Padrão de compactação de vídeo H.264. Novas possibilidades em vigilância por vídeo. PAPEL BRANCO Padrão de compactação de vídeo H.264. Novas possibilidades em vigilância por vídeo. Índice 1. Introdução 3 2. Desenvolvimento do H.264 3 3. Como funciona a compactação de vídeo 4 4. Perfis

Leia mais

Redes de Computadores e a Internet

Redes de Computadores e a Internet Redes de Computadores e a Internet Magnos Martinello Universidade Federal do Espírito Santo - UFES Departamento de Informática - DI Laboratório de Pesquisas em Redes Multimidia - LPRM 2010 Introdução Redes

Leia mais

26. O sistema brasileiro de televisão digital adota os seguintes parâmetros para HDTV:

26. O sistema brasileiro de televisão digital adota os seguintes parâmetros para HDTV: IFPB Concurso Público/Professor de Ensino Básico, Técnico e Tecnológico (Edital 24/2009) CONHECIMENTOS ESPECÍFICOS CÓDIGO 06 UCs de Comunicações Móveis e/ou de Processamento de Sinais de Áudio e Vídeo

Leia mais

TV Digital. Cristiano Akamine

TV Digital. Cristiano Akamine TV Digital O objetivo deste tutorial é fornecer ao leitor os subsídios básicos necessários para entender o princípio de funcionamento dos três sistemas de TV digital existentes no mundo: sistema americano,

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Capítulo 1 Gustavo Reis gustavo.reis@ifsudestemg.edu.br - O que é a Internet? - Milhões de elementos de computação interligados: hospedeiros = sistemas finais - Executando aplicações

Leia mais

Universidade Federal de Juiz de Fora Faculdade de Comunicação Social

Universidade Federal de Juiz de Fora Faculdade de Comunicação Social Universidade Federal de Juiz de Fora Faculdade de Comunicação Social O SISTEMA DE RÁDIO DIGITAL: A MODERNIZAÇÃO DO M.C.M. MAIS POPULAR DO PLANETA Texto redigido para embasar apresentação de seminário na

Leia mais

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação 1 Introdução à Camada de Transporte Camada de Transporte: transporta e regula o fluxo de informações da origem até o destino, de forma confiável.

Leia mais

2- Conceitos Básicos de Telecomunicações

2- Conceitos Básicos de Telecomunicações Introdução às Telecomunicações 2- Conceitos Básicos de Telecomunicações Elementos de um Sistemas de Telecomunicações Capítulo 2 - Conceitos Básicos de Telecomunicações 2 1 A Fonte Equipamento que origina

Leia mais

Universidade Federal Fluminense Mestrado em Engenharia de Telecomunicações

Universidade Federal Fluminense Mestrado em Engenharia de Telecomunicações Universidade Federal Fluminense Mestrado em Engenharia de Telecomunicações Fundamentos de Sistemas Multimídia Padrões de Rádio Digital Agosto/2006 Jailton Neves Padrões de Rádio Digital Agenda - IBOC In

Leia mais

Vídeo Sob Demanda. Elaine Calvet Mestrado Redes Telecom, UFF Disciplina: Sistemas Multimídia Prof.ª Debora

Vídeo Sob Demanda. Elaine Calvet Mestrado Redes Telecom, UFF Disciplina: Sistemas Multimídia Prof.ª Debora Vídeo Sob Demanda Elaine Calvet Mestrado Redes Telecom, UFF Disciplina: Sistemas Multimídia Prof.ª Debora Agenda Introdução Definição do Serviço VoD Desafios do Serviço Tecnologia Necessária Estudo de

Leia mais

SISTEMAS DE INFORMAÇÕES GERENCIAIS. Aula 09

SISTEMAS DE INFORMAÇÕES GERENCIAIS. Aula 09 FACULDADE CAMÕES PORTARIA 4.059 PROGRAMA DE ADAPTAÇÃO DE DISCIPLINAS AO AMBIENTE ON-LINE SISTEMAS DE INFORMAÇÃO GERENCIAL DOCENTE: ANTONIO SIEMSEN MUNHOZ, MSC. ÚLTIMA ATUALIZAÇÃO: FEVEREIRO DE 2007. Internet,

Leia mais

PROF.: PAULO GOMES MATÉRIA: STRS 2 MOURA LACERDA

PROF.: PAULO GOMES MATÉRIA: STRS 2 MOURA LACERDA PROF.: PAULO GOMES MATÉRIA: STRS 2 MOURA LACERDA A TV digital O surgimento da TV digital se deu em função do desenvolvimento da TV de alta definição (HDTV) no Japão e na Europa, há mais de duas décadas,

Leia mais

UNIVERSIDADE PRESBITERIANA MACKENZIE GUSTAVO DE MELO VALEIRA TRANSMISSÃO MPE NO SISTEMA DE TELEVISÃO DIGITAL ISDB-T

UNIVERSIDADE PRESBITERIANA MACKENZIE GUSTAVO DE MELO VALEIRA TRANSMISSÃO MPE NO SISTEMA DE TELEVISÃO DIGITAL ISDB-T 0 UNIVERSIDADE PRESBITERIANA MACKENZIE GUSTAVO DE MELO VALEIRA TRANSMISSÃO MPE NO SISTEMA DE TELEVISÃO DIGITAL ISDB-T São Paulo 2010 1 GUSTAVO DE MELO VALEIRA Transmissão MPE no sistema de televisão digital

Leia mais

Entenda o resultado da medição

Entenda o resultado da medição Entenda o resultado da medição Lembre-se que fatores externos podem influenciar na medição. As velocidades contratadas são velocidades nominais máximas de acesso, sendo que estão sujeitas a variações decorrentes

Leia mais

Avaliação de Desempenho e Consumo Energético de Streaming de Vídeo Auto Adaptativo em Dispositivos Móveis

Avaliação de Desempenho e Consumo Energético de Streaming de Vídeo Auto Adaptativo em Dispositivos Móveis Avaliação de Desempenho e Consumo Energético de Streaming de Vídeo Auto Adaptativo em Dispositivos Móveis Charles Bezerra Moreira cbm3@cin.ufpe.br Orientador: Eduardo Tavares eagt@cin.ufpe.br Agenda Introdução

Leia mais

Introdução ao protocolo SIP*

Introdução ao protocolo SIP* Introdução ao protocolo SIP* 1. SIP (Session Initiation Protocol) Pode se dizer que SIP trata se de um protocolo de controle referente à camada de aplicações do Modelo de Referência OSI (Open System Interconnection),

Leia mais

Padrões de Middleware para TV Digital

Padrões de Middleware para TV Digital Padrões de Middleware para TV Digital Alexsandro Paes, Renato Antoniazzi UFF Universidade Federal Fluminense Centro Tecnológico Departamento de Engenharia de Telecomunicações Mestrado em Telecomunicações

Leia mais

UNIVERSIDADE DA BEIRA INTERIOR Faculdade de Engenharia Departamento de Informática

UNIVERSIDADE DA BEIRA INTERIOR Faculdade de Engenharia Departamento de Informática 1 Este é o seu teste de avaliação de frequência. Leia as perguntas com atenção antes de responder. Escreva as suas respostas nesta folha de teste, marcando um círculo em volta da opção ou opções que considere

Leia mais

Radiodifusão Sonora Digital

Radiodifusão Sonora Digital 1 Radiodifusão Sonora Digital Lúcio Martins da Silva AUDIÊNCIA PÚBLICA COMISSÃO DE CIÊNCIA, TECNOLOGIA, INOVAÇÃO, COMUNICAÇÃO E INFORMÁTICA SENADO FEDERAL ASSUNTO: A ADOÇÃO DE UMA NOVA TECNOLOGIA PARA

Leia mais

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Prof. Luís Rodolfo Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Redes de computadores e telecomunicação Objetivos da Unidade III Apresentar as camadas de Transporte (Nível 4) e Rede (Nível 3) do

Leia mais

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet

Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Alternativas de aplicação do serviço GPRS da rede celular GSM em telemetria pela Internet Marcos R. Dillenburg Gerente de P&D da Novus Produtos Eletrônicos Ltda. (dillen@novus.com.br) As aplicações de

Leia mais

Fundamentos de Rede. Aula 01 - Introdução e Redes

Fundamentos de Rede. Aula 01 - Introdução e Redes Fundamentos de Rede Aula 01 - Introdução e Redes Contextualização Séculos XVIII e XIX - Revolução Industrial máquinas mecânicas, taylorismo, fábricas hierarquia, centralização da decisão, mainframes Séculos

Leia mais

Sistemas de Informação. Profª Ana Lúcia Rodrigues Wiggers Instrutora Cisco Networking Academy - UNISUL 2013

Sistemas de Informação. Profª Ana Lúcia Rodrigues Wiggers Instrutora Cisco Networking Academy - UNISUL 2013 Sistemas de Informação Profª Ana Lúcia Rodrigues Wiggers Instrutora Cisco Networking Academy - UNISUL 2013 Conjunto de Módulos Processadores (MP) capazes de trocar informações e compartilhar recursos,

Leia mais

IPTV em rede Multicast

IPTV em rede Multicast IPTV em rede Multicast Flávio Gomes Figueira Camacho Apresentação Flavio Gomes Figueira Camacho Diretor de TI da Vipnet Baixada Telecomunicações e, Operadora de STFC e SCM. Mestrando em Engenharia de Telecomunicações

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES REDES DE COMPUTADORES 09/2013 Cap.3 Protocolo TCP e a Camada de Transporte 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura da bibliografia básica. Os professores

Leia mais

1 Introduc ao 1.1 Hist orico

1 Introduc ao 1.1 Hist orico 1 Introdução 1.1 Histórico Nos últimos 100 anos, o setor de telecomunicações vem passando por diversas transformações. Até os anos 80, cada novo serviço demandava a instalação de uma nova rede. Foi assim

Leia mais

PADRÕES DE MIDDLEWARE PARA TV DIGITAL

PADRÕES DE MIDDLEWARE PARA TV DIGITAL PADRÕES DE MIDDLEWARE PARA TV DIGITAL Rafael V. Coelho Fundação Universidade Federal do Rio Grande (FURG) Rio Grande - RS rafaelvc2@gmail.com Resumo. Este trabalho discute os tipos de Middleware usados

Leia mais

HSPA: Conceitos Básicos

HSPA: Conceitos Básicos HSPA: Conceitos Básicos Este tutorial apresenta a tecnologia contida no padrão HSPA (High Speed Packet Access) para as redes celulares de 3ª geração (3G) baseada no conjunto de padrões WCDMA (Wideband

Leia mais

Bateria REDES MPU Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/

Bateria REDES MPU Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ Bateria REDES MPU Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ STJ 2008 Com relação a transmissão de dados, julgue os itens

Leia mais

VoIP. Redes de Longa Distância Prof. Walter Cunha

VoIP. Redes de Longa Distância Prof. Walter Cunha Redes de Longa Distância Prof. Walter Cunha As principais tecnologias de Voz sobre Rede de dados: Voz sobre Frame Relay Voz sobre ATM Voz sobre IP VoIP sobre MPLS VoIP consiste no uso das redes de dados

Leia mais

Aula 6 Modelo de Divisão em Camadas TCP/IP

Aula 6 Modelo de Divisão em Camadas TCP/IP Aula 6 Modelo de Divisão em Camadas TCP/IP Camada Conceitual APLICATIVO TRANSPORTE INTER-REDE INTERFACE DE REDE FÍSICA Unidade de Dados do Protocolo - PDU Mensagem Segmento Datagrama /Pacote Quadro 01010101010100000011110

Leia mais

11. VOZ SOBRE IP. VoIP. 25 Capitulo 11

11. VOZ SOBRE IP. VoIP. 25 Capitulo 11 11. VOZ SOBRE IP 11.1 INTRODUÇÃO Voz com qualidade de operador (carrier-grade voice) significa o seguinte: - Elevada disponibilidade. Um operador tem a rede disponível 99.999% do tempo (down-time< 5min.

Leia mais

TV DIGITAL APLICADA NA EDUCAÇÃO. Email: fujio.yamada@mackenzie.br

TV DIGITAL APLICADA NA EDUCAÇÃO. Email: fujio.yamada@mackenzie.br II SIMPOSIO INTERNACIONAL SOBRE NOVAS COMPETENCIAS EM TECNOLOGIA DIGITAL INTERATIVAS NA EDUCAÇÃO LABORATÓRIO DE TV DIGITAL DR. PROF. FUJIO YAMADA UNIVERSIDADE PRESBITERIANA MACKENZIE Email: fujio.yamada@mackenzie.br

Leia mais

NOVAS TECNOLOGIAS DE INFORMAÇÃO

NOVAS TECNOLOGIAS DE INFORMAÇÃO NOVAS TECNOLOGIAS DE INFORMAÇÃO Profª. Kelly Hannel Novas tecnologias de informação 2 HDTV WiMAX Wi-Fi GPS 3G VoIP Bluetooth 1 HDTV 3 High-definition television (também conhecido por sua abreviação HDTV):

Leia mais

Claudivan C. Lopes claudivan@ifpb.edu.br

Claudivan C. Lopes claudivan@ifpb.edu.br Claudivan C. Lopes claudivan@ifpb.edu.br Motivação Camadas do modelo OSI Exemplos de protocolos IFPB/Patos - Prof. Claudivan 2 Para que dois ou mais computadores possam se comunicar, é necessário que eles

Leia mais

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins

Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Curso: Sistemas de Informação Disciplina: Redes de Computadores Prof. Sergio Estrela Martins Material de apoio 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura

Leia mais

Redes de Computadores. Camada de Transporte

Redes de Computadores. Camada de Transporte Redes de Computadores Camada de Transporte Objetivo! Apresentar as características da camada de transporte da arquitetura TCP/IP! Apresentar os serviços fornecidos pela camada de transporte! Estudar os

Leia mais

Sistemas Multimédia. Arquitectura Protocolar Simples Modelo OSI TCP/IP. Francisco Maia famaia@gmail.com. Redes e Comunicações

Sistemas Multimédia. Arquitectura Protocolar Simples Modelo OSI TCP/IP. Francisco Maia famaia@gmail.com. Redes e Comunicações Sistemas Multimédia Arquitectura Protocolar Simples Modelo OSI TCP/IP Redes e Comunicações Francisco Maia famaia@gmail.com Já estudado... Motivação Breve História Conceitos Básicos Tipos de Redes Componentes

Leia mais

O Panorama da TV Digital no Brasil. Leandro Miller Leonardo Jardim

O Panorama da TV Digital no Brasil. Leandro Miller Leonardo Jardim O Panorama da TV Digital no Brasil Leandro Miller Leonardo Jardim Tópicos Abordados TV Aberta no Brasil Vantagens da TV Digital Padrões de TV Digital Sistema Brasileiro de TV Digital Oportunidades na TV

Leia mais

milenaresende@fimes.edu.br

milenaresende@fimes.edu.br Fundação Integrada Municipal de Ensino Superior Sistemas de Informação A Internet, Intranets e Extranets milenaresende@fimes.edu.br Uso e funcionamento da Internet Os dados da pesquisa de TIC reforçam

Leia mais

III.2. CABLE MODEMS CARACTERÍSTICAS BÁSICAS UNIDADE III SISTEMAS HÍBRIDOS

III.2. CABLE MODEMS CARACTERÍSTICAS BÁSICAS UNIDADE III SISTEMAS HÍBRIDOS 1 III.2. CABLE MODEMS III.2.1. DEFINIÇÃO Cable modems são dispositivos que permitem o acesso em alta velocidade à Internet, através de um cabo de distribuição de sinais de TV, num sistema de TV a cabo.

Leia mais

Documento de Requisitos de Rede (DRP)

Documento de Requisitos de Rede (DRP) Documento de Requisitos de Rede (DRP) Versão 1.2 SysTrack - Grupo 1 1 Histórico de revisões do modelo Versão Data Autor Descrição 1.0 30/04/2011 João Ricardo Versão inicial 1.1 1/05/2011 André Ricardo

Leia mais

Impacto da TV Digital no Futuro dos Negócios

Impacto da TV Digital no Futuro dos Negócios Impacto da TV Digital no Futuro dos Negócios Congresso SUCESU-SP 2007 Integrando Tecnologia aos Negócios 29/11/07 Juliano Castilho Dall'Antonia Diretor de TV Digital w w w. c p q d. c o m. b r 1 Sumário

Leia mais

Técnico em Informática. Redes de Computadores 2ºE1/2ºE2

Técnico em Informática. Redes de Computadores 2ºE1/2ºE2 Técnico em Informática Redes de omputadores 2ºE1/2ºE2 SUMÁRIO 2.1 Introdução 2.2 Vantagens do Modelo de amadas 2.3 Modelo de inco amadas 2.4 Funções das amadas 2.5 Protocolos de Rede 2.6 Arquitetura de

Leia mais

Administração de Sistemas de Informação I

Administração de Sistemas de Informação I Administração de Sistemas de Informação I Prof. Farinha Aula 03 Telecomunicações Sistemas de Telecomunicações 1 Sistemas de Telecomunicações Consiste de Hardware e Software transmitindo informação (texto,

Leia mais

Internet. Edy Hayashida E-mail: edy.hayashida@uol.com.br

Internet. Edy Hayashida E-mail: edy.hayashida@uol.com.br Internet Edy Hayashida E-mail: edy.hayashida@uol.com.br Internet A Internet não é de modo algum uma rede, mas sim um vasto conjunto de redes diferentes que utilizam certos protocolos comuns e fornecem

Leia mais

Modelo de Camadas OSI

Modelo de Camadas OSI Modelo de Camadas OSI 1 Histórico Antes da década de 80 -> Surgimento das primeiras rede de dados e problemas de incompatibilidade de comunicação. Década de 80, ISO, juntamente com representantes de diversos

Leia mais

Wireshark. Captura de Protocolos da camada de aplicação. Maicon de Vargas Pereira

Wireshark. Captura de Protocolos da camada de aplicação. Maicon de Vargas Pereira Wireshark Captura de Protocolos da camada de aplicação Maicon de Vargas Pereira Camada de Aplicação Introdução HTTP (Hypertext Transfer Protocol) 2 Introdução Camada de Aplicação Suporta os protocolos

Leia mais

Guia Técnico Inatel Guia das Cidades Digitais

Guia Técnico Inatel Guia das Cidades Digitais Guia Técnico Inatel Guia das Cidades Digitais Módulo 3: VoIP INATEL Competence Center treinamento@inatel.br Tel: (35) 3471-9330 As telecomunicações vêm passando por uma grande revolução, resultante do

Leia mais

Aula 1 Fundamentos. Prof. Dr. S. Motoyama

Aula 1 Fundamentos. Prof. Dr. S. Motoyama Aula 1 Fundamentos Prof. Dr. S. Motoyama 1 O que é uma Rede de Computadores? Vários tipos de redes: Redes Telefônicas Redes de Satélites Redes Celulares Redes de TV a cabo Internet e intranets Rede Privada

Leia mais

Prof. Othon M. N. Batista Mestre em Informática. Página 1 de 25

Prof. Othon M. N. Batista Mestre em Informática. Página 1 de 25 Mestre em Informática Página 1 de 25 Roteiro Introdução Definição História Requerimentos IMT-Advanced Padrões 4G LTE Advanced Padrões 4G WirelessMAN Advanced 4G no Brasil Perguntas Página 2 de 25 Introdução

Leia mais

Fundamentos. Prof. Dr. S. Motoyama

Fundamentos. Prof. Dr. S. Motoyama Fundamentos Prof. Dr. S. Motoyama 1 Tipos de Comunicação - Difusão: Rádio e TV - Pessoa-a-Pessoa: Telefonia - Máquina-a-Máquina: Computadores Difusão: Rádio e TV Receptor Receptor Receptor Transmissor

Leia mais

TV Dig ital - S ocial

TV Dig ital - S ocial Edson Luiz Castilhos Gerente Célula Software Livre - RS Marco Antonio Munhoz da Silva Gestor Projeto TV Digital Social 1 AGENDA O que é TV Digital? Histórico TV Analógica x TV Digital Sistema de TV Digital

Leia mais

2 Perspectivas de Consumo de Banda no Acesso

2 Perspectivas de Consumo de Banda no Acesso 2 Perspectivas de Consumo de Banda no Acesso Esse capítulo apresenta os novos serviços disponíveis aos usuários e a tendência de oferta futura, indicando as previsões de bandas associadas necessárias a

Leia mais

PROTOCOLO PPP. Luciano de Oliveira Mendes 1 Ricardo dos Santos 2

PROTOCOLO PPP. Luciano de Oliveira Mendes 1 Ricardo dos Santos 2 PROTOCOLO PPP Luciano de Oliveira Mendes 1 Ricardo dos Santos 2 RESUMO Neste trabalho é apresentado o Protocolo PPP, Suas principais características e seu funcionamento. Suas variações também são enfocadas

Leia mais

Guia de Consulta Rápida HTTP. Décio Jr. Novatec Editora. www.novateceditora.com.br

Guia de Consulta Rápida HTTP. Décio Jr. Novatec Editora. www.novateceditora.com.br Guia de Consulta Rápida HTTP Décio Jr. Novatec Editora www.novateceditora.com.br Guia de Consulta Rápida HTTP de Décio Jr. Copyright 2001 da Novatec Editora Ltda. Todos os direitos reservados. É proibida

Leia mais

IPTV. Anexo ao Manual de Operação do TSW800TP+

IPTV. Anexo ao Manual de Operação do TSW800TP+ Manual de Operação IPTV Anexo ao Manual de Operação do TSW800TP+ Versão: 2 Revisão: 4 Setembro/2010 Direitos de edição Este manual foi elaborado pela equipe da Wise Indústria de Telecomunicações. Nenhuma

Leia mais

Tecnologias da Internet (T) Avaliação de Frequência (v1) 60 minutos * 09.05.2012

Tecnologias da Internet (T) Avaliação de Frequência (v1) 60 minutos * 09.05.2012 1 Este é o seu teste de avaliação de frequência. Leia as perguntas com atenção antes de responder e tenha atenção que algumas perguntas podem ter alíneas de resposta em páginas diferentes. Escreva as suas

Leia mais

Estrutura de um Rede de Comunicações. Redes e Sistemas Distribuídos. Tarefas realizadas pelo sistema de comunicação. Redes de comunicação de dados

Estrutura de um Rede de Comunicações. Redes e Sistemas Distribuídos. Tarefas realizadas pelo sistema de comunicação. Redes de comunicação de dados Estrutura de um Rede de Comunicações Profa.. Cristina Moreira Nunes Tarefas realizadas pelo sistema de comunicação Utilização do sistema de transmissão Geração de sinal Sincronização Formatação das mensagens

Leia mais

Multimédia, Qualidade de Serviço (QoS): O que são?

Multimédia, Qualidade de Serviço (QoS): O que são? Multimédia, Qualidade de Serviço (QoS): O que são? Aplicações Multimédia: áudio e vídeo pela rede ( meios contínuos ) QoS a rede oferece às aplicações o nível de desempenho necessário para funcionarem.

Leia mais

1 INTRODUÇÃO 1 2 CONSIDERAÇÕES INICIAIS 1 2.1 ARQUITETURA DO SISTEMA 4 3 CONFIGURAÇÃO DO PROCESSADOR BTS 4 3.1 COMPRESSOR 5 3.

1 INTRODUÇÃO 1 2 CONSIDERAÇÕES INICIAIS 1 2.1 ARQUITETURA DO SISTEMA 4 3 CONFIGURAÇÃO DO PROCESSADOR BTS 4 3.1 COMPRESSOR 5 3. COMPRESSOR / DECOMPRESSOR TS9600 BTS i SUMÁRIO 1 INTRODUÇÃO 1 2 CONSIDERAÇÕES INICIAIS 1 2.1 ARQUITETURA DO SISTEMA 4 3 CONFIGURAÇÃO DO PROCESSADOR BTS 4 3.1 COMPRESSOR 5 3.2 DECOMPRESSOR 6 4. CARACTERÍSTICAS

Leia mais

NOVAS APLICAÇÕES DO ISDB-T

NOVAS APLICAÇÕES DO ISDB-T ANEXO 5 NOVAS APLICAÇÕES DO ISDB-T Uma das vantagens mais marcantes do ISDB-T é a sua flexibilidade para acomodar uma grande variedade de aplicações. Aproveitando esta característica única do ISDB-T, vários

Leia mais

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT. Fatores Tecnológicos, Estratégicos e Organizacionais

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT. Fatores Tecnológicos, Estratégicos e Organizacionais MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT 15.565 Integração de Sistemas de Informação: Fatores Tecnológicos, Estratégicos e Organizacionais 15.578 Sistemas de Informação Global:

Leia mais

Me Engº Leonardo Ortolan. Me Engº Thiago L. S. Santos

Me Engº Leonardo Ortolan. Me Engº Thiago L. S. Santos TV Digital Me Engº Leonardo Ortolan Me Engº Thiago L. S. Santos Sumário Introdução Desenvolvimento TV Digital: O que é? Padrões de TV Digital TV Digital Brasileira Participação da PUCRS no SBTVD Conclusão

Leia mais

Rádio WAP: Você já ouviu?

Rádio WAP: Você já ouviu? Rádio WAP: Você já ouviu? Este tutorial apresenta os conceitos e características da aplicação Rádio WAP, serviço que pode ser oferecido pelas operadoras de Telefonia Celular para seus assinantes. Ricardo

Leia mais

1 Sistemas de telefonia celular no Brasil

1 Sistemas de telefonia celular no Brasil 1 Sistemas de telefonia celular no Brasil Em 1984, deu-se início à análise de sistemas de tecnologia celular sendo definido o padrão americano, analógico, AMPS Advanced Mobile Phone System, como modelo

Leia mais

Avaliação de Desempenho e Consumo Energético de Streaming de Vídeo Auto Adaptativo em Dispositivos Móveis

Avaliação de Desempenho e Consumo Energético de Streaming de Vídeo Auto Adaptativo em Dispositivos Móveis Avaliação de Desempenho e Consumo Energético de Streaming de Vídeo Auto Adaptativo em Dispositivos Móveis Charles Bezerra Moreira cbm3@cin.ufpe.br Orientador: Eduardo Tavares eagt@cin.ufpe.br Agenda Introdução

Leia mais

CCNA 1 Conceitos Básicos de Redes. Módulo 11 Camada de Transporte TCP/IP Camada de Aplicação

CCNA 1 Conceitos Básicos de Redes. Módulo 11 Camada de Transporte TCP/IP Camada de Aplicação CCNA 1 Conceitos Básicos de Redes Módulo 11 Camada de Transporte TCP/IP Camada de Aplicação Camada de Transporte TCP/IP 2 Introdução à Camada de Transporte As responsabilidades principais da camada de

Leia mais

Software de rede e Modelo OSI André Proto UNESP - São José do Rio Preto andre.proto@sjrp.unesp.br O que será abordado Hierarquias de protocolos (camadas) Questões de projeto relacionadas às camadas Serviços

Leia mais

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural Arquitetura e Protocolos de Rede TCP/IP Modelo Arquitetural Motivação Realidade Atual Ampla adoção das diversas tecnologias de redes de computadores Evolução das tecnologias de comunicação Redução dos

Leia mais

Introdução à Computação: Sistemas de Computação

Introdução à Computação: Sistemas de Computação Introdução à Computação: Sistemas de Computação Beatriz F. M. Souza (bfmartins@inf.ufes.br) http://inf.ufes.br/~bfmartins/ Computer Science Department Federal University of Espírito Santo (Ufes), Vitória,

Leia mais

Taitell Telecom. Equipamentos e Soluções

Taitell Telecom. Equipamentos e Soluções Taitell Telecom Equipamentos e Soluções Solução de Vídeo MultiPortal Sobre a VoipSwitch VoipSwitch Inc. (www.voipswitch.com) é uma das líderes no mercado de VoIP, oferecendo plataforma completa para empresas

Leia mais

UMTS. www.teleco.com.br 1

UMTS. www.teleco.com.br 1 UMTS Este tutorial apresenta os conceitos básicos do Universal Mobile Telecommunications System (UMTS) padrão de 3ª Geração de sistemas celulares para evolução de redes GSM. Autor: Eduardo Tude Engenheiro

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Multimédia Prof. António Casimiro / José Rufino Email: docentes rcp@listas.di.ciencias.ulisboa.pt 2015/2016 Multimédia e Qualidade de Serviço Aplicações multimédia: Áudio e vídeo

Leia mais

TECNOLOGIA WEB INTERNET PROTOCOLOS

TECNOLOGIA WEB INTERNET PROTOCOLOS INTERNET PROTOCOLOS 1 INTERNET Rede mundial de computadores. Também conhecida por Nuvem ou Teia. Uma rede que permite a comunicação de redes distintas entre os computadores conectados. Rede WAN Sistema

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 2 - MODELO DE REFERÊNCIA TCP (RM TCP) 1. INTRODUÇÃO O modelo de referência TCP, foi muito usado pela rede ARPANET, e atualmente usado pela sua sucessora, a Internet Mundial. A ARPANET é de grande

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Ementa Introdução a Redes de

Leia mais

GfK Audience Measurements & Insights MEDIÇÃO DE AUDIÊNCIA DE TV E VÍDEO

GfK Audience Measurements & Insights MEDIÇÃO DE AUDIÊNCIA DE TV E VÍDEO MEDIÇÃO DE AUDIÊNCIA DE TV E VÍDEO Em nenhum momento de toda a história dos meios de comunicação modernos houve tantas mudanças fundamentais na distribuição e mensuração da mídia. Com o surgimento da transmissão

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br O que é a Internet? Milhões de elementos de computação interligados: hospedeiros = sistemas finais Executando aplicações Enlaces de comunicação: fibra, cobre, rádio,

Leia mais

Fabio Golmia - CEO EnterPlay 11 8139-1100 11 7806-3061 ID 7*22748 fabiogolmia@enterplay.com.br www.enterplay.com.br. Apresentação da Empresa

Fabio Golmia - CEO EnterPlay 11 8139-1100 11 7806-3061 ID 7*22748 fabiogolmia@enterplay.com.br www.enterplay.com.br. Apresentação da Empresa Fabio Golmia - CEO EnterPlay 11 8139-1100 11 7806-3061 ID 7*22748 fabiogolmia@enterplay.com.br www.enterplay.com.br Apresentação da Empresa Estrutura desta Apresentação Tema: Posicionamento da EnterPlay

Leia mais

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural

Arquitetura e Protocolos de Rede TCP/IP. Modelo Arquitetural Arquitetura e Protocolos de Rede TCP/IP Modelo Arquitetural Agenda Motivação Objetivos Histórico Família de protocolos TCP/IP Modelo de Interconexão Arquitetura em camadas Arquitetura TCP/IP Encapsulamento

Leia mais

Público Alvo: Critérios de admissão para o curso:

Público Alvo: Critérios de admissão para o curso: Fundado em 1965, o Instituto Nacional de Telecomunicações - Inatel - é um centro de excelência em ensino e pesquisa na área de Engenharia, e tem se consolidado cada vez mais, no Brasil e no exterior, como

Leia mais

Redes. Pablo Rodriguez de Almeida Gross

Redes. Pablo Rodriguez de Almeida Gross Redes Pablo Rodriguez de Almeida Gross Conceitos A seguir serão vistos conceitos básicos relacionados a redes de computadores. O que é uma rede? Uma rede é um conjunto de computadores interligados permitindo

Leia mais