CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS DE TELECOMUNICAES

QUALIDADE DE SERVIO EM IPTV

MAURICIO RONEI MARQUES

Porto Alegre, 2010. Mauricio Ronei Marques

QUALIDADE DE SERVIO EM IPTV

Trabalho de concluso de curso apresentado ao Curso de Tecnologia em Sistemas de Telecomunicaes para obteno do ttulo acadmico de Tecnlogo em Telecomunicaes.

Orientador: Professor Antonio Carlos de Oliveira Pedra

Porto Alegre, 2010

Mauricio Ronei Marques

QUALIDADE DE SERVIO EM IPTV

Este trabalho de concluso de curso foi julgado adequado como parte dos requisitos para obteno do ttulo acadmico de Tecnlogo em rea de Atuao, Faculdade SENAI de Tecnologia. Porto Alegre, 03 de Dezembro de 2010.

Avaliadores ______________________________________________________ Prof.(a) <Maior Titulao > <Nome do(a) Professor(a)> <Nome da Universidade onde obteve a maior titulao> ______________________________________________________ Prof.(a) <Maior Titulao > <Nome do(a) Professor(a)> <Nome da Universidade onde obteve a maior titulao>
[S2] Comentrio: Colocar dados do professor avaliador designado [S1] Comentrio: Colocar dados do professor orientador

Coordenador do Curo: _______________________________ Prof. Msc. Leandro Cassol

Aos Mestres, colegas e funcionrios da Faculdade de Tecnologia do SENAI RS, minha filha Letcia e aos meus pais por nunca desistirem.

AGRADECIMENTOS

Agradeo primeiramente a Deus, pois percebo que foi feito por Ele o caminho que trilhei at chegar faculdade. Um especial agradecimento minha famlia que, mesmo de longe, nunca deixou de me apoiar. Aos colegas da GVT que muito contriburam para que esse trabalho se concretizasse e aos colegas de faculdade Fernando, Tarcsio e Gilnei. Aos Mestres Pedra, Jaqueline, Caruso, Sandro, Cassol e Ulbrich minha admirao e meus sinceros agradecimentos pelo apoio incondicional durante a execuo desse trabalho e durante todo o curso.

Aquele que busca prolas precisa mergulhar mais fundo Carl Jung

RESUMO

Neste trabalho busca-se propor solues para as dificuldades tcnicas relacionadas implementao de Qualidade de Servio em uma rede capaz de prover o servio de TV sobre IP (Internet Protocol Television). Nele so analisadas as tcnicas e os protocolos necessrios para um melhor funcionamento do servio. A oferta do servio de IPTV no Brasil depende da aprovao do PL 29/07, que trata da convergncia digital em TV por Assinatura, unificando regras, fomentando a produo audiovisual nacional e permitindo o ingresso das operadoras de telecomunicaes nesse mercado. A transmisso de contedo televisivo atravs da rede das operadoras de telecomunicaes h de provocar alteraes na arquitetura da rede para que fatores determinantes para a qualidade do servio sejam alcanados. Atualmente a Internet prov um nvel aceitvel de tolerncia a falhas e escalabilidade aos usurios. Porm novas aplicaes, como o IPTV, criam novas expectativas quanto qualidade dos servios oferecidos e alteram a maneira como as redes so projetadas e implementadas. A descentralizao dos head-ends, utilizao dos protocolos UDP e RTP, tcnicas de QoS em MPLS, diferenciao de servios com DiffServ e grupos multicast atravs do IGMP so apresentadas como alternativas para maximizar a utilizao da banda e minimizar os fatores que podem prejudicar a qualidade do servio. Entre os principais desafios esto a reduo do tempo de atraso, ou latncia, e da variao do atraso, ou Jitter, fatores aos quais o servio apresenta grande sensibilidade.

Palavras-chave: IPTV, PL29, MPLS, RSVP, DiffServ e QoS

ABSTRACT

In this paper seeks to propose solutions to technical difficulties related to implementing Quality of Service in a network capable of providing TV service over IP (Internet Protocol Television). In it is analyzed the techniques and protocols necessary for a better functioning of the service. The provision of IPTV service in Brazil depends on the approval of the PL 29/07, which deals with convergence in digital pay TV, unifying rules, fostering national audiovisual production and allowing the entry of telecom operators in this market. The transmission of television content through the network of telecom operators for the changes in the network architecture so that factors determining the quality of service are achieved. Currently the Internet provides an acceptable level of fault tolerance and scalability to users. But new applications such as IPTV, create new expectations about the quality of services offered and alter the way networks are designed and implemented. The decentralization of head-ends, use of UDP and RTP, QoS techniques in MPLS, differentiated services with DiffServ and multicast groups by IGMP are presented as alternatives to maximize bandwidth utilization and minimize the factors that can affect the quality service. Major challenges are to reduce the time delay, or latency, and jitter factors to which the service is highly sensitive.

Keywords: IPTV, PL29, MPLS, RSVP, DiffServ and QoS

LISTA DE SIGLAS

ADSL AF ANATEL ASM ATM BE BSR CAS CCNA CLP CO CODEC CoS DRM DSCP DTH DWDM FDM FEC FTP

Assimetric Digital Subscriber Line Assured Forwarding Agncia Nacional de Telecomunicaes Any Source Multicast Assincronous Transfer Mode Best Effort Broadband Services Router Conditional Access System Cisco Certified Network Associate Cell Loss Priority Central Office Coder/Decoder Class of Service Digital Rights Management Differentiated Services Code Point Direct to Home Dense Wavelength Division Multiplexing Frequency Division Multiplexing Forwardind Equivalence Class File Transfer Protocol

FTTx GVT HD HDTV HFC IETF IGMP IP IPTV ITU LSP LSR LTE MIMO MMDS MPEG MPLS MTU OFDM OSI PCM

Fiber to the X Global Village Telecom High Definition High Definition Television Hibrid Fiber Coax Internet Engineering Task Force Internet Group Management Protocol Internet Protocol Internet Protocol Television International Telecommunication Union Label Switched Path Label-Switching Routers) Long Term Evolution Multiple In Multiple Out Multichannel Multipoint Distribution Service Moving Picture Experts Group Multi Protocol Label Switching Maximum Transmission Unit Ortogonal Frequency Division Multiplexing International Standards Organization Pulse Code Modulation

PHB PL PNBL PON QoE QoS RFC RFP RSVP RTCP RTP SD SSM STB TCP TDM TOS UDP VLAN VoD VoIP

Per Hop Behavior Projeto de Lei Plano Nacional de Banda Larga Passive Optical Network Quality of Experience Quality of Service Request for Comments Request for Proposal Resource Reservation Protocol Real Time Control Protocol Real Time Protocol Standard Definition Single Source Multicast Set Top Box Transmission Control Protocol Time Division Multiplexing Type of Service User Datagram Protocol Virtual Local Area Network Vdeo on Demand Voice over IP

LISTA DE FIGURAS

Figura 1 Comparativo do servio de IPTV com e sem QoS........................................20 Figura 2 Modelos OSI e TCP/IP.......................................................................................25 Figura 3 Funes das camadas do modelo TCP/IP.....................................................27 Figura 4 6 bits do campo ToS do cabealho IP formam o campo DSCP .................31 Figura 5 Filas de servios diferenciados com DiffServ. ...............................................32 Figura 6 Ilustrao de uma comunicao Multicast......................................................34 Figura 7 Cabealho MPLS ................................................................................................37 Figura 8 Componentes de uma arquitetura FTTx.........................................................38 Figura 9 - Esquema de soluo IPTV sobre ADSL ..........................................................40 Figura 10 Componentes genricos de uma rede IPTV ................................................45 Figura 11 Distribuio de vdeo centralizada.................................................................46 Figura 12 Distribuio de vdeo descentralizada ..........................................................47 Figura 13 Exemplo de arquitetura IPTV com headends nacional e regional. .......................48 Figura 14 Sistema MMDS. ................................................................................................52 Figura 15 Sistema HFC .....................................................................................................53 Figura 16 Pacote capturado com o software Wireshark onde se observa a utilizao de TCP...........................................................................................................54 Figura 17 - Pacote capturado com o software Wireshark onde se observa o campo DSCP sem marcao....................................................................................................55 Figura 18 3way-handshake...............................................................................................59 Figura 19 Troca de mensagens RSVP ...........................................................................66

LISTA DE TABELAS

Tabela 1 - Fatores de compresso e taxa de transferncia aproximados ...................57 Tabela 2 - Comparativo entre E-LSPs e L-LSPs ............................................................67 Tabela 3 - Dificuldades encontradas e solues propostas ...........................................71

14

SUMRIO

INTRODUO......................................................................................................................................... 16 COMENTRIOS INICIAIS ...................................................................................................................... 16 TEMA E OBJETIVOS ............................................................................................................................. 17 JUSTIFICATIVA..................................................................................................................................... 20 MTODO DO TRABALHO ...................................................................................................................... 22 LIMITAES DO TRABALHO ................................................................................................................. 22 ESTRUTURA DO TRABALHO................................................................................................................. 23 2 MODELOS DE REFERNCIA OSI E TCP/IP ................................................................................................... 24 2.1 INTRODUO ................................................................................................................................. 24 2.2 MODELO TCP/IP............................................................................................................................. 26 1.1 1.2 1.3 1.4 1.5 1.6

RESUMO .......................................................................................................................................... 40 QUALIDADE DE SERVIO............................................................................................................................ 41 3.1 INTRODUO ...................................................................................................................................... 41 3.2 NECESSIDADE DE QOS ........................................................................................................................ 42 3.3 TCNICAS DE QOS .............................................................................................................................. 42 3.4 PARMETROS DE QOS........................................................................................................................ 44 4 COMPONENTES DE UMA REDE IPTV............................................................................................... 44 4.1 INTRODUO ................................................................................................................................. 44 4.2 HEADEND ........................................................................................................................................ 45 4.3 CORE IP............................................................................................................................................ 48 4.4 REDES DE ACESSO ...................................................................................................................... 49 4.5 SET-TOP-BOX................................................................................................................................. 49 4.6 RESUMO .......................................................................................................................................... 50 5 COMPARATIVO DO IPTV COM OUTRAS TECNOLOGIAS DE ENTREGA DO SERVIO DE TV........................... 50 5.1 DTH DIRECT TO HOME ................................................................................................................... 50 5.2 MMDS SERVIO DE DISTRIBUIO MULTIPONTO MULTICANAL .................................... 51 5.3 HFC HIBRID FIBER COAX .................................................................................................................. 52 5.4 RESUMO .......................................................................................................................................... 53 6 SOLUES PROPOSTAS PARA APERFEIOAMENTO DO SISTEMA IPTV ................................................. 54 6.1 INTRODUO ................................................................................................................................. 54 6.2 BANDA ELEVADA PARA TRANSPORTE DE UDIO E VDEO ................................................................... 56 3

2.3

2.2.1 2.2.2 2.2.3 2.2.4

CAMADA DE APLICAO ..........................................................................28 CAMADA TRANSPORTE.............................................................................29 CAMADA INTERNET ....................................................................................30 CAMADA DE ACESSO REDE.................................................................35

6.2.1 6.2.2 6.2.3

MPEG-4...........................................................................................................56 TCP x UDP .....................................................................................................57 IGMP ................................................................................................................60

6.3

6.4

6.3.1 6.3.2 6.3.3 6.3.4

GARANTIA DE ENTREGA E PRIORIZAO DE PACOTES ....................................................................... 61

ATRASOS E VARIAES NOS ATRASOS........................................................................................... 68

RTP ..................................................................................................................62 DIFFSERV e INTSERV.................................................................................62 RSVP ...............................................................................................................64 INTEGRAO MPLS E DIFFSERV ...........................................................66 ATRASO DE PROCESSAMENTO .............................................................68 ATRASO DE TRANSMISSO.....................................................................69 ATRASO DE FILA .........................................................................................69

6.4.1 6.4.2 6.4.3

6.5 7

RESUMO .......................................................................................................................................... 70 PROCEDIMENTO METODOLGICO ................................................................................................. 72

15
8 9 APLICAO E RESULTADOS ............................................................................................................ 74 COMENTRIOS FINAIS ........................................................................................................................ 75 9.1 INTRODUAO ................................................................................................................................. 75 9.2 CONCLUSES ................................................................................................................................ 75 9.3 SUGESTES PARA TRABALHOS FUTUROS SOBRE O TEMA IPTV............................................. 77 REFERNCIAS ........................................................................................................................................................ 78 ANEXO A TTULO DO ANEXO A......................................................................... ERRO! INDICADOR NO DEFINIDO. APNDICE A TESTES MPLS COM JPERF................................................................................................ 80 APNDICE B WINDOWS MEDIA ENCODER ......................................................................................... 82

16

INTRODUO

1.1

COMENTRIOS INICIAIS

O Brasil atualmente o 5 pas com o maior nmero de conexes Internet. Segundo o Ibope/Nielsen, h mais de 66 milhes de internautas, dos quais 27,5 milhes acessam regularmente a Internet em casa. Entretanto a receita das operadoras vem caindo e dentre os principais motivos para que isso ocorra esto o aumento da concorrncia na prestao de servios telefnicos com operadoras de telefonia mvel e o crescimento de operadoras e empresas que oferecem solues baseadas na tecnologia de Voz sobre IP (VoIP). Nesse contexto, oferecer mais servios ao consumidor utilizando a infra-estrutura existente tem sido a alternativa mais vivel, na qual se insere a oferta de IPTV, para recuperar e fidelizar clientes. O PL 29/2007, de autoria do deputado Paulo Bornhausen, a primeira tentativa de regular o servio de TV Paga no Brasil. A lei atual, de 1995, aborda como nico meio de transmisso o cabo, deixando de lado tecnologias como satlite e Internet. O servio de IPTV pode ser definido como a transmisso e recepo de sinais de TV utilizando a infraestrutura de rede banda larga IP. Nele ocorre a transmisso de canais em aberto (difuso para todos os usurios) e sob demanda (VoD), bem como servios interativos que integram Internet e televiso. Parece ser iminente a oferta desse servio no Brasil, pois vrias operadoras preparam-se para entrar no mercado de IPTV. Segundo um relatrio da Informa Telecoms e Media, em 2009 o nmero de lares com servios IPTV era de 26 milhes e poder chegar a 70 milhes em todo o mundo no final de 2014.

17 Como exemplo, tem-se o lanamento do servio pela GVT, previsto para 2011, com soluo tecnolgica hbrida que combina IPTV e TV paga via satlite (DTH). Ainda a respeito, o desafio a ser enfrentado ser grande, pois garantir a Qualidade de Experincia (QoE Quality of Expereience) exigida pelos espectadores, sobretudo na era da TV Digital, deve ser o objetivo. Isso porque o padro de qualidade requerido para transporte de udio e vdeo, muitas vezes em tempo real, mostra-se muito superior ao exigido para aplicaes como transferncias de arquivos, e-mail ou at mesmo aplicaes VoIP (UNEN, 2006). Nesse contexto, protocolos que se destinam a reservas de recursos como o Reservation Protocol (RSVP), protocolos que rotulam os pacotes da rede com o intuito de priorizao de informaes preferenciais como o DiffServ associados a arquiteturas de redes baseada em MPLS e grupos multicast podem ser de grande utilidade para o melhor aproveitamento da largura de banda. Assim consoante a atualidade e importncia do padro IPTV, este trabalho apresenta os elementos de uma arquitetura de rede IPTV, os padres de qualidade requeridos pela rede e os protocolos UDP, RTP/RTCP, RSVP, MPLS, IntServ e DiffServ. Tambm se prope a analisar, apresentar e discutir solues envolvendo as tcnicas usuais de aperfeioamento das transmisses multimdias.

1.2

TEMA E OBJETIVOS

O tema abordado nesse trabalho, o servio de TV sobre o protocolo IP, um tema atual que j realidade em muitas localidades do mundo. A oferta desse servio no Brasil est condicionada aprovao do PL 29/2007 pelo Senado Federal; porm, j h grande movimentao por parte das operadoras de telecomunicaes no sentido de adequao da infraestrutura atual e

18 escolha de fornecedores de equipamentos. Dentre os fabricantes aptos a oferecer uma soluo IPTV pode-se destacar a Ericsson, KPN, Nokia Siemens e Cisco. A aquisio da operadora GVT pelo grupo francs Vivendi deixa-a em situao muito favorvel, uma vez que o grupo conta com tecnologia e contedo. O grupo proprietrio do Canal+ Group, que atua no setor de TV paga na Frana e tambm na produo e distribuio de filmes, com 10,6 milhes de assinantes e, ainda, detentor de 20% da empresa de mdia norte-americana NBC Universal. Outros contedos multimdia, cada vez mais procurados por usurios de banda larga, integram o portflio da empresa, que controla a Activision Blizzard, do segmento de videogames, e a Universal Music Group, do segmento de msica. A operadora promete para 2011 o incio da comercializao de um servio de TV com a adoo de uma tecnologia hbrida combinando IPTV e DTH (Direct to Home). DTH a oferta do servio televisivo atravs de uma antena receptora instalada no cliente, recebendo o sinal diretamente de um satlite. IPTV a oferta desse contedo atravs da infra-estrutura da operadora de telecomunicaes, utilizando conexo de banda larga. Por outro lado a Oi j anunciou parceria com importantes fabricantes para fornecimento de infraestrutura para IPTV e a espanhola Telefonica est na eminncia de lanar um servio, em parceria com as Livrarias Saraiva, onde, atravs de um conversor ligado entre o modem de banda larga e a TV, o assinante pode passar a alugar filmes, efetuar a transferncia via Internet e visualiz-los em seu televisor. Algumas dificuldades tcnicas para a oferta do servio de IPTV motivaram o desenvolvimento deste TCC, dentre as quais podemos citar: a banda para a transmisso de udio e vdeo elevada e a arquitetura da rede no est apta a fornecer a largura de banda necessria para que o servio se apresente com qualidade aceitvel; o protocolo IP no foi originalmente desenvolvido para garantir a entrega de pacotes ou, sequer, garantir uma qualidade de servio.

19 O objetivo na poca foi criar um protocolo capaz de possibilitar que uma rede continue funcionando mesmo que parte dela esteja indisponvel, ou seja, em caso de falhas em enlaces da rede os pacotes possam tomar rotas alternativas para alcanar o destino. A principal vantagem do protocolo IP sempre foi sua simplicidade. Mesmo na nova verso do protocolo IP, IPv6, o objetivo foi manter a simplicidade do protocolo e, dessa forma, as fragilidades se mantiveram. a transmisso de dados como, por exemplo, no acesso websites, transferncia de arquivos, envio de e-mail e mensagens instantneas, utiliza o protocolo IP que se mostra eficiente utilizando a mxima do melhor esforo (Best-effort), na qual a largura de banda compartilhada por todos os fluxos de dados inseridos na rede e todo o trfego tratado da mesma maneira. Isto resulta, em caso de congestionamento, que pacotes sejam descartados sem quaisquer critrios de distino, o que no seria eficaz em um sistema IPTV; o atraso ao qual um pacote est sujeito dentro de uma rede um fator importante a ser analisado para transmisses em tempo real. Os atrasos podem ser classificados em atrasos de processamento, fila, transmisso e propagao que, somados, podem ocasionar uma latncia superior tolervel para a transmisso IPTV em tempo real. a latncia tolervel em uma transmisso, sobretudo de eventos ao vivo, muito inferior tolervel em outras aplicaes. O protocolo TCP devido ao triple handshake, executado antes do incio da transmisso de dados contribui para o aumento da latncia; a variao da latncia (jitter) muito impactante em aplicaes de tempo real uma vez que, caso o tempo gasto no trajeto emissorreceptor fosse sempre o mesmo seria possvel calcular quanto de

20 informao precisaria ser armazenada em buffer, para que assim a exibio do contedo no sofresse cortes aps ter sido iniciada. O objetivo principal deste trabalho analisar as causas dos problemas acima listados e propor, quando possvel, solues para san-los com o intuito de fornecer subsdios para a implantao de um sistema de IPTV puro e de qualidade, o que ser feito no captulo 6. A figura 1 demonstra o efeito causado pelo no estabelecimento de QoS adequada em um servio de IPTV.

Figura 1 Comparativo do servio de IPTV com e sem QoS.

Fonte: Cisco Academy

1.3

JUSTIFICATIVA

O crescimento da oferta de televiso em redes IP ao redor do mundo e a possibilidade das operadoras brasileiras, atravs da aprovao do PL 29, explorar esse mercado justificam o estudo do tema. Ao ensejo do lanamento do Plano Nacional de Banda Larga (PNBL) pelo governo federal, Jorge Bittar, deputado federal e membro do conselho consultivo do Instituto Telecom, falou sobre o IPTV e sua consonncia com o Plano Nacional de Banda Larga (PNBL):
Este projeto somado ao PNBL nos permite levar contedos audiovisuais pela TV por assinatura e da IPTV a brasileiros que no tinham acesso as estes bens culturais importantes para a valorizao da

21
cultura. E tambm pode trazer oportunidades de empregos mercado. porque vai apresentar investimentos considerveis em mo de obra qualificada para o

Outro aspecto a destacar, agora vinculado ao desenvolvimento e inovao, que o servio IPTV requer a renovao da arquitetura de rede para atender elevadas exigncias do servio em largura de banda e qualidade de servio, em associao com sistema de gesto sofisticado, capaz de lidar com a complexidade da rede e suas aplicaes. Devido a fato de o servio ser provido atravs de um canal bidirecional, a interatividade com o espectador ser facilitada e as mesmas possibilidades de comrcio e entretenimento antes exclusivos plataforma PC e Internet chegaro TV. Alm de permitir a oferta de mltiplos canais em alta definio (HDTV) o servio de IPTV pode, ainda, oferecer jogos, vdeos sob demanda, vdeo chamadas, e outros servios adicionais. Justifica-se o estudo proposto para que seja buscada uma maneira pela qual a utilizao de protocolos e tcnicas atuais de arquiteturas de redes contribua para minimizar as dificuldades tcnicas relacionadas anteriormente, propiciando o desenvolvimento desse servio no Brasil onde a largura de banda oferecida ainda est muito aqum do ideal e a infraestrutura de rede das operadoras ainda , basicamente, constituda por pares metlicos e com tecnologias distintas desde ATM, Frame-Relay at ETHERNET. Finalizando, relacionado a ofertas de trabalho e comrcio, a IPTV dever representar para os provedores de servios banda-larga uma nova era, a oportunidade de entrar no mercado de publicidade televisiva e construir novos negcios antes exclusivos das operadoras de televiso aberta ou por assinatura.

22 1.4 MTODO DO TRABALHO

A metodologia a ser aplicada neste trabalho ser a pesquisa bibliogrfica baseada em livros, artigos, teses e publicaes em mdia eletrnica, aliada a pequenos experimentos atravs da aplicao de tcnicas de QoS em pacotes trafegando em uma rede MPLS que, por no terem sido executados em ambiente controlado, compe o apndice do presente trabalho. Por ser um assunto novo no Brasil, h dificuldade de encontrar material sobre o tema. No entanto, muitas das tcnicas e dos protocolos estudados so aplicados tambm no servio de voz sobre IP (VoIP), bibliografia. Ser elaborado em conjunto com o professor orientador um cronograma para a execuo do trabalho e este dever ser rigorosamente atendido para o sucesso do projeto. Sero realizadas reunies com o orientador para avaliao do andamento do projeto e esclarecimento de dvidas. Em paralelo, os captulos sero redigidos, avaliados e corrigidos. onde j h extensa

1.5

LIMITAES DO TRABALHO

O propsito deste trabalho analisar como o servio de IPTV pode ser implementado utilizando a infraestrutura atual das operadoras de telecomunicaes brasileiras e propor tcnicas que permitam o melhor aproveitamento da largura de banda disponvel. Este trabalho tem a finalidade de exemplificar tcnicas que associadas podem contribuir para o melhor funcionamento de um sistema de IPTV. Os componentes do sistema sero citados, mas no sero frutos de estudo aprofundado. Optou-se por concentrar os estudos em protocolos e tcnicas de QoS que possam contribuir para a minimizao do atraso (delay) e jitter nas

23 transmisses entre headends e entre os headends e os ponto terminais da rede (Set-top-Box). Outros tpicos fundamentais, no menos importantes que os

apresentados neste trabalho, no so abordados neste TCC. Como exemplo, tem-se o estudo de sistemas relacionados segurana de rede, tais como Conditional Access System (CAS), responsvel pela deciso de permitir ou no a transmisso ao consumidor, e o DRM (Digital Rights Management), em que um conjunto de diversas tecnologias possibilita ou no o uso de produtos digitais de udio, vdeo ou imagem.

1.6

ESTRUTURA DO TRABALHO

O trabalho ser estruturado de forma a permitir que o entendimento de um sistema IPTV seja disponibilizado nos itens do captulo 1. Os captulos 2 e 3 destinam-se a apresentar a fundamentao terica sobre o tema. O captulo 2 trar a definio dos modelos de referncia TCP/IP e OSI e, ao descrever as camadas do modelo TCP/IP, sero relacionados os protocolos que atuaro em cada camada do modelo em uma aplicao IPTV. No captulo 3, tcnicas e parmetros de QoS sero tratados. A arquitetura de uma soluo IPTV ser descrita no captulo 4, onde so destacados os seus componentes, descrevendo as funes por eles exercidas. No captulo 5, o servio de IPTV ser comparado com outras tecnologias de entrega de contedos multimdia como, por exemplo, DTH e MMDS e nele sero expostos os problemas que podem ocorrer caso um sistema de IPTV no apresente os requisitos de QoS necessrios. O captulo 6 ter o objetivo de propor solues que permitam minimizar os efeitos do atraso, do jitter, da pequena largura de banda disponvel, da no garantia de entrega e perda de pacotes IP. As solues apresentadas para esses problemas so a combinao de protocolos de rede com tcnicas de QoS e adequaes na arquitetura da rede

24 2 MODELOS DE REFERNCIA OSI E TCP/IP

2.1

INTRODUO

Um meio que facilita o entendimento do funcionamento de um sistema de IPTV a compreenso de dois modelos de referncia criados para padronizar a interconexo de diferentes produtos de diferentes fabricantes: modelos OSI e TCP/IP (BAKER, 2009; CHOWDHURY, 2002). Na dcada de 80, a ISO (Organizao Nacional de Padronizao) em conjunto com representantes de diversos fabricantes criou um grupo de trabalho com objetivo de apresentar uma soluo para a incompatibilidade entre sistemas de diferentes fabricantes. Essa incompatibilidade gerava insatisfao por parte dos consumidores (BAKER, 2009; CHOWDHURY, 2002). O Modelo OSI foi o primeiro resultado apresentado pelo grupo em 1984 e divide as tarefas inerentes comunicao entre equipamentos em sete grupos ou camadas com o objetivo de, atravs da criao de grupos menores, facilitar a implantao e o gerenciamento de redes de computadores. Cada camada praticamente independente e tem a ela servios especficos associados, permitindo dessa forma que tarefas associadas determinada camada possam ser implementadas ou alteradas sem que as demais necessitem de quaisquer alteraes. A funo de cada camada fornecer servios camada imediatamente inferior (BAKER, 2009; CHOWDHURY, 2002). No modelo OSI as camadas em ordem decrescente so: Aplicao, Apresentao, Sesso, Transporte, Rede, Enlace e Fsica (BAKER, 2009; CHOWDHURY, 2002). As sete camadas do Modelo OSI, podem ser subdividida em dois grupos maiores: superior e inferior. O grupo superior composto pelas 3 primeiras camadas do modelo: Aplicao, Apresentao e Sesso, so normalmente implementadas em software e lidam com assuntos relacionados aplicao. Nas camadas inferiores, Transporte, Rede, Enlace e Fsica esto contemplados os servios que possibilitam a comunicao entre equipamentos (BAKER, 2009; CHOWDHURY, 2002).

25 O modelo TCP/IP foi desenvolvido para atender uma Request for Proposal (RFP) lanada pelo governo norte americano que buscava um modo confivel e eficiente de transportar dados em uma rede de computadores mesmo que parte dela se tornasse indisponvel (RTI, 2009). As camadas propostas pelo modelo TCP/IP so Aplicao, Transporte, Internet e Camada de Acesso ao meio (RTI, 2009; CHOWDHURY, 2002). A figura a seguir compara os modelos OSI e TCP/IP.

Figura 2 Modelos OSI e TCP/IP

Fonte: Cisco Academy Cabe ressaltar que ambos os modelos so referenciais, ou seja, possuem a finalidade de facilitar o entendimento do funcionamento de uma rede e fornecer um padro para que desenvolvedores de softwares e hardwares alcancem a interoperabilidade com outros fabricantes sem, no entanto, implicar na obrigatoriedade da adoo integral de um ou outro modelo (RTI, 2009; CHOWDHURY, 2002). Outro tpico a destacar que ambos os modelos apresentam uma arquitetura para a comunicao entre computadores, mas no so eles que efetivamente fazem a comunicao ocorrer. O que torna possvel essa comunicao

26 so os protocolos definidos em cada uma das camadas dos modelos (RTI, 2009; CHOWDHURY, 2002). Neste trabalho utilizou-se o modelo TCP/IP para definio dos protocolos que atuaro em cada camada.

2.2

MODELO TCP/IP

A pilha de protocolos TCP/IP recebeu esse nome em virtude de dois protocolos que a compe que so o TCP, protocolo da camada de transporte com a caracterstica de orientao conexo e transporte confivel de dados, e o protocolo IP, que definido na camada de rede e responsvel por segmentar uma mensagem e rote-la at o seu destino. O IP um protocolo no orientado conexo e no confivel, isto , no implementa nenhum mecanismo de deteco ou correo de erros (RTI, 2009; CHOWDHURY, 2002). O sucesso e a popularidade dos protocolos TCP/IP se deve ao fato der ter sido o primeiro protocolo a atingir a importante meta da comunicao de dados com abrangncia mundial. Isto somente foi possvel graas a algumas de suas caractersticas, entre elas (RTI, 2009): TCP/IP um protocolo aberto, pblico e completamente

independente de equipamentos e de sistemas operacionais; TCP/IP no define protocolos para o nvel fsico, possibilitando sua implementao sobre uma grande variedade de protocolos j existentes, tais como: Ethernet, Frame-relay e X.25; o esquema de endereamento do TCP/IP permite designar de maneira inequvoca qualquer mquina, mesmo em redes globais como a Internet; TCP/IP inclui protocolos do nvel de aplicao que atendem muito bem demanda de servios imposta pelos usurios.

27 A padronizao do TCP/IP feita atravs de Requests For Comments (RFC) e inclui a especificao formal dos protocolos e informaes sobre seu funcionamento (RTI, 2009). Em um sistema de IPTV podemos, utilizando o modelo referencial TCP/IP, definir os protocolos utilizados em cada uma das camadas explicando de que forma cada protocolo atuar permitindo uma melhor compreenso do sistema como um todo. A Figura 3 lista as funes exercidas pelas camadas da pilha de protocolos TCP/IP.

Figura 3 Funes das camadas do modelo TCP/IP.

Fonte: Cisco Academy

A seguir sero listadas cada uma das quatro camadas do modelo TCP/IP e descritas suas caractersticas e protocolos associados a elas dentro de uma rede que tenha entre seus servios a distribuio de contedo televisivo.

28 2.2.1 CAMADA DE APLICAO

A camada de Aplicao tem a responsabilidade de definir os protocolos necessrios para tornar possvel a comunicao fim-a-fim entre as aplicaes e tambm por controlar e determinar a interface com o usurio (RTI, 2009; CHOWDHURY, 2002). na camada denominada Aplicao que ocorre a interao entre o computador e o usurio. Em um sistema IPTV a camada de aplicao ser responsvel por identificar e estabelecer a disponibilidade do contedo no servidor e disponibilizar os recursos para que essa comunicao ocorra (RTI, 2009; 3). Nessa camada encontrar-se-o os protocolos responsveis por preparar os dados de forma a tornar possvel seu encaminhamento dentro de uma rede, nela atuam tambm os CODECs ou codificadores-decodificadores que tm a funo de compresso de sinais digitais de udio e vdeo reduzindo o tamanho do arquivo mantendo sua qualidade original (CHOWDHURY, 2002; 5; 8).

2.2.1.1 CODEC MPEG-4

O termo CODEC significa Coder/Decoder ou Codificador/Decodificador e basicamente um algoritmo que define como deve ser processado um determinado conjunto de informaes, com a funo de comprimir e descomprimir dados. O intuito justamente reduzir o tamanho do arquivo sem que haja, teoricamente, perda de qualidade perceptvel (8). Em termos de compresso de vdeo um CODEC deve atuar em duas frentes bsicas: O primeiro foco que o vdeo representa uma seqncia de imagens que possui repeties desnecessrias (redundncias), ou seja, informaes na imagem que podem ser suprimidas. A segunda abordagem indica que dentro de cada imagem (quadro) existem conjuntos de pixels prximos que so similares ou muito parecidos o que representa tambm redundncia de informaes que podem

29 ser reduzidas com a ao dos CODECS. Estes dois conceitos so chamados respectivamente de compresso temporal e compresso espacial (8). Em uma aplicao IPTV, com o objetivo de reduzir o fluxo de dados, CODECs devem ser aplicados e atuaro na camada de aplicao do modelo TCP/IP. A partir de 1988, o Moving Picture Experts Group (MPEG) e a International Telecommunication Union (ITU-T) se uniram para desenvolver pesquisas com um grupo de trabalho da International Standards Organization (ISO) com o objetivo de definir padres para compresso digital de sinais de udio e vdeo. Em 1998 foi apresentado o codec MPEG-4 que deve ser o codec utilizado em aplicaes IPTV (8).

2.2.2 CAMADA TRANSPORTE

A camada de Transporte responsvel por criar uma conexo ponto a ponto confivel alm de efetuar a segmentao e seqenciamento dos pacotes. Os dois principais protocolos adotados nessa camada so: UDP e TCP (FILIPPETTI, 2008).

2.2.2.1 Protocolo UDP

UDP um protocolo da camada de transporte, descrito na RFC 768. O protocolo UDP no fornece qualquer tipo de garantia de entrega, sendo, portanto, um protocolo no confivel. O UDP tambm fornece os servios de broadcast e multicast, permitindo que um nico cliente envie pacotes para vrios destinatrios na rede (CHOWDHURY, 2002).

30 2.2.2.2 Protocolo TCP

TCP um protocolo que garante transporte confivel dos dados e orientado a conexo, ou seja, para que uma transmisso TCP se inicie faz-se necessrio o estabelecimento prvio de uma conexo entre o transmissor e o receptor. O TCP est definido nas RFCs 793, 1122, 1323, 2018 e 2581 (CHOWDHURY, 2002; FILIPPETTI, 2008). Uma conexo TCP no um circuito TDM ou FDM fim-a-fim e nem tampouco um circuito virtual, uma vez que o estado da conexo invisvel aos ns intermedirios tais como roteadores ou switches, sendo localizadas apenas nos sistemas finais envolvidos na transmisso KUROSE, 2006 Em virtude dessas caractersticas o protocolo TCP no permite o trfego multicast (CHOWDHURY, 2002).

2.2.3 CAMADA INTERNET

A camada Internet responsvel pelo endereamento lgico dos hosts (endereo IP), pelo roteamento dos pacotes dentro da rede e pelo estabelecimento de controle de fluxo de dados durante uma comunicao (CHOWDHURY, 2002). Na camada Internet, alm do protocolo IP, os protocolos DiffServ, RSVP e IGMP podero ser adotados em uma rede IPTV.

2.2.3.1 DiffServ

Como mencionado anteriormente, o protocolo IP fornece servios de entrega de pacotes pelo atravs do modelo de melhor esforo ou best-effort que no oferece garantias nem quanto entrega dos pacotes de dados ao destino nem quanto ao atraso ou a variao do atraso (jitter) na entrega. Alm disso, neste

31 modelo, todos os fluxos de dados so tratados de uma mesma forma e, portanto, com uma mesma prioridade. O modelo Diferencial Services (DiffServ), proposto pelo IETF, tem o intuito de propiciar diferentes nveis de QoS ao protocolo IP (CHOWDHURY, 2002). O DiffServ agrupa os fluxos IP em classes de servios (CoS Class of Service), e fornece tratamento diferenciado aos fluxos baseado na classe a qual eles pertencem. Como o DiffServ possui poucas classes, a informao de qual classe pertence um pacote pode ser inserida no cabealho IP e, para isso, utiliza seis bits do campo TOS - Type of Service do cabealho IP para codificar a informao da classe, criando o campo Differentiated Services Code Point (DSCP; CHOWDHURY, 2002).

Figura 4 6 bits do campo ToS do cabealho IP formam o campo DSCP

Fonte: Lancope (http://www.lancope.com) Esta codificao permite criar at 64 classes distintas que representam o tratamento que deve ser dispensado cada pacote no encaminhamento dentro de uma rede. O tratamento diferenciado dar-se- no momento de encaminhamento dos pacotes e por isso denomina-se comportamento passo a passo ou Per Hop Behavior PHB (SILVA NETO, 2006). Apenas alguns PHBs padres foram definidos e so eles (SILVA NETO, 2006): Padro ou melhor esforo (BE-Best Effort).

32 EF ou Expedited Forwarding. Pacotes desta classe devem ter atraso e perdas mnimos. AF ou Assured Forwarding. Esta classe define uma srie de PHBs, na forma AFxy, sendo que x representa a classe AF e y representa a prioridade. Pacotes de classe AF diferentes so encaminhados em filas diferentes, e a prioridade determina a freqncia em que os pacotes so descartados em caso de congestionamento. A marcao do campo DSCP pode ficar a cargo dos hosts, baseado em conhecimento dos requisitos de cada aplicao; ou pode ficar a cargo dos roteadores de borda de uma rede DiffServ. Quando um pacote sem marcao chega a um destes roteadores, o roteador pode marc-lo de acordo com polticas previamente configuradas. Quando um roteador recebe um pacote j marcado, ele trata o pacote baseado somente no campo DSCP (SILVA NETO, 2006). Este tratamento se refere poltica de enfileiramento e descarte de pacotes e cada roteador pode manter diversas filas, com prioridades de atendimento e descarte diferentes. A Figura 5 ilustra as filas geradas com o uso do protocolo DiffServ.

Figura 5 Filas de servios diferenciados com DiffServ.

33 Fonte: Cisco Academy

2.2.3.2 RESERVATION PROTOCOL RSVP

RSVP foi desenvolvido para permitir que as aplicaes possam requisitar diferentes nveis de QoS para seus fluxos de dados. Em se tratando de reserva de recursos em uma rede IP, normalmente, trata-se de reserva de largura de banda e memria (buffer) em roteadores. necessrio que a reserva de recursos seja efetuada em todos os roteadores da rede por onde estes fluxos trafegaro KUROSE, 2006. O RSVP utiliza como base a tabela de roteamento local para conhecer possveis rotas para alcanar o destino, porm no o RSVP responsvel pelo estabelecimento de rotas (5; 8). Para que o RSVP seja implementado todos os equipamentos no trajeto cliente-servidor devem suport-lo (CARBONARO, 2004; 5). James F. Kurose destaca em (KUROSE, 2006) que o padro RSVP no especifica a maneira pela qual a rede fornece largura de banda reservada a determinado fluxo de dados, ficando a tarefa sob responsabilidade dos roteadores. Uma das caractersticas do RSVP que o torna vivel em aplicaes IPTV o fato de poder ser aplicado tanto em transmisses unicast quanto multicast (CARBONARO, 2004).

2.2.3.3 IGMP

Apesar do uso tradicional da Internet envolver a comunicao entre dois computadores, h casos especficos como a IPTV em que uma fonte de origem pode ter a necessidade de enviar um fluxo de dados a vrios destinos simultaneamente.

34 Esse tipo de comunicao (um para vrios) conhecida como multicast (CARBONARO, 2004). A Figura 6 ilustra uma transmisso multicast.

Figura 6 Ilustrao de uma comunicao Multicast

Fonte: Cisco Academy A comunicao entre dois hosts pode ser considerado um caso especfico de trfego multicast onde o grupo de destinos composto por apenas um elemento. Para criar e manter grupos multicast foi desenvolvido o protocolo IGMP (CARBONARO, 2004). O IGMP faz parte da pilha de protocolos TCP/IP, devendo ser implementado em todos os hosts que desejam receber trfego multicast e usado para fazer dinamicamente o registro de um host em um grupo multicast em uma rede local. A fim de se tornarem membros de um determinado grupo multicast, os hosts enviam uma mensagem IGMP para o roteador multicast de sua sub-rede. Os roteadores executando o IGMP, alm de receberem requisies IGMP, verificam quais grupos esto ativos ou inativos em uma determinada sub-rede. Isto feito por meio do envio peridico de consultas s sub-redes (CARBONARO, 2004). O funcionamento bsico do IGMP pode ser resumido segundo os procedimentos descritos abaixo (CARBONARO, 2004): um host envia uma mensagem IGMP ao roteador multicast de sua sub-rede indicando o desejo de tornar-se membro de determinado

35 grupo multicast. Esta mensagem indica ao roteador multicast que h um receptor para aquele grupo multicast naquela subrede. o host programa o seu dispositivo de rede para receber trfego do grupo multicast. o roteador registra que a sub-rede possui um membro de um determinado grupo multicast e prepara-se para repassar todo o trfego destinado ao grupo para a sub-rede. algum tempo depois, o roteador comea periodicamente a enviar mensagens IGMP de consulta para verificar se ainda h membros do grupo multicast na sub-rede. Se o host ainda deseja receber trfego do grupo, ele ir enviar ao roteador uma mensagem IGMP informando que ele ainda membro daquele grupo. Quando o host no deseja mais receber trfego do grupo multicast, ele reprograma o seu dispositivo de rede para tal. aps trs envios consecutivos de mensagens sem resposta, o roteador considera o grupo inativo e pra de repassar trfego para este grupo na sub-rede. Um roteador multicast mantm uma tabela de suas interfaces que possuem pelo menos um host em um grupo multicast. Quando o roteador recebe um pacote multicast de um determinado grupo, ele envia o pacote somente para as suas interfaces que possuem membros para aquele grupo multicast. O protocolo IGMP no determina a maneira como os pacotes so enviados nos roteadores. Isto feito de acordo com as regras do protocolo de roteamento multicast que est sendo executado no roteador (CARBONARO, 2004).

2.2.4 CAMADA DE ACESSO REDE

Equivalente s camadas Fsica e de Enlace do modelo OSI, a camada responsvel por monitorar o trfego de dados entre dispositivos alm de estabelecer

36 caractersticas da comunicao atravs do meio fsico utilizado e analisar os endereos de hardware (MAC-ADDRESS; FILIPPETTI, 2008). O MPLS no definido nessa camada, porm, para efeitos didticos uma vez que o mesmo atua entre as camadas de Acesso Rede e Internet, optou-se por descreva-lo associado camada de Acesso Rede. A camada de Acesso Rede contempla, tambm, o meio fsico utilizado no enlace e, por esse motivo, ser descrita associada a ela trs meios fsicos comuns para a ltima milha de acesso rede provedora do servio de IPTV: fibra ptica, wireless e par metlico.

2.2.4.1 MULTIPROTOCOL LABEL SWITCHING - MPLS

O MPLS uma tecnologia de encaminhamento de pacotes IP, baseada em etiquetas, padronizado pelo IETF. Dentre suas principais caractersticas, pode-se citar (OSBORNE, 2002; CHOWDHURY, 2002). agilidade de encaminhamento de pacotes, proporcionada pela inspeo de etiquetas no roteamento explcito, onde os pacotes so examinados apenas nas bordas de um domnio MPLS; implementao de orientao conexo em redes IP, propiciando engenharia de trfego; suporte a arquiteturas de qualidade de servio como DiffServ e IntServ; independncia da tecnologia da camada de ligao de redes e protocolos da camada de rede, proporcionando interoperabilidade em ambientes heterogneos; simplificao da interoperabilidade entre redes IP sobre ATM e IP no ATM;

suporte implementao de redes privadas virtuais (VPN) em ambientes de larga escala, com simplificao de gerenciamento, incremento de desempenho e suporte a QoS.

37

Figura 7 Cabealho MPLS

Fonte: Winkipedia

2.2.4.2 Meio Fsico ptico - FTTx

FTTx um termo genrico para designar arquiteturas de redes de transmisso de alto desempenho, baseadas em fibra ptica. Geralmente so redes passivas denominadas Passive Optical Network - PON. O termo FTTx, traduzido literalmente, siginfica Fiber to the x, onde x o local onde ser entregue a fibra como, por exemplo: FTTH Fiber to the Home, FTTO Fiber to the Office e FTTB Fiber to the Building (RTI, 2009). Com o barateamento da fibra ptica e surgimento de cabos mais leves e mais flexveis, auto-sustentveis em vos de at 80 metros (cabos DROP), a entrega de servios utilizando essa tecnologia foi facilitada. De maneira geral, a fibra ptica que antes s era utilizada na construo de backbones hoje chega at o ltimo ponto de responsabilidade da operadora. Muitas vezes so utilizados splitters para que um cabo com poucas fibras possa ser subdividido e, assim, atender vrios clientes em uma mesma regio (RTI, 2009).

38

Figura 8 Componentes de uma arquitetura FTTx.

Fone: www.furukawa.com.br

O atendimento de ltima milha com fibra ptica pode ser excelente opo, sobretudo, para atendimento de clientes distantes dos headends e tambm para atendimento a condomnios e edifcios.

2.2.4.3 Meio fsico Wireless

Muitas vezes a rea de cobertura das operadoras de telecomunicaes restringida pelo alto custo do cabeamento. Cidades com poucos habitantes e regies menos povoadas poderiam ser alcanadas com a utilizao do espao livre como meio de acesso. Tecnologias como Wi-max e LTE, com a adoo de tcnicas de modulao com mltiplas portadoras e espalhamento espectral, utilizao de mltiplas antenas para transmisso e recepo (MIMO Multiple In Multiple Out), podem fornecer taxas elevadas e confiabilidade, alm de que, tambm em transmisses wireless existe a possibilidade de utilizao de tcnicas de QoS (RTI, 2009).

39 2.2.4.4 Meio fsico par metlico - xDSL

O predomnio da tecnologia ADSL como meio de acesso banda larga Internet no Brasil faz com que a tecnologia seja o principal meio de acesso IPTV. Nesse contexto cabe destacar algumas de suas principais caractersticas KUROSE, 2006. ADSL foi uma soluo desenvolvida para transmitir dados em altas velocidades e a grandes distncias atravs de linhas telefnicas comuns. O desenvolvimento dessa tecnologia teve o desafio de utilizar a infraestrutura disponvel da operadora utilizada para atender clientes com o servio de linha telefnica analgica e, enfrentando a baixa qualidade do cabeamento, disponibilizar conexo de banda larga em um nico par de cabos metlicos. Para isso utiliza freqncias mais altas, entre 26 kHz e 1100 kHz, de forma a no interferir com o sinal de voz que opera entre 300 Hz a 3.4 KHz. A faixa entre 26 kHz e 138 kHz usada para downstream e a faixa de 138 kHz em diante, usada para upstream. Isso resulta em uma das principais caractersticas do ADSL, que a comunicao assimtrica, com taxas melhores para download do que para upload. Para que se possa mensurar o nvel de QoE em uma implementao IPTV sobre ADSL no deve-se ter como base apenas a largura da banda da rede uma vez que, at que os dados cheguem ao STB ele trafegar por enlaces com grande variedade de tecnologias aplicadas como, por exemplo, a camada fsica do ADSL e rede ATM, e a interao desses nveis e a soma dos efeitos das influncias externas que determinaro a QoE oferecida pelo servio. Em uma topologia de rede IPTV com rede de acesso baseada em ADSL, como exemplificada na Figura 9, o fluxo de vdeo distribudo utilizando ADSL 2+ desde o DSLAM at o modem router localizado nas dependncias do contratante. O modem encaminha o contedo para o STB para que seja decodificado, ou seja, prepara os sinais para que sejam compatveis com a TV do usurio.

40 Devido s restries de banda em um acesso ADSL existir restrio quanto ao nmero de aparelhos que podero receber sinais diferentes. Estima-se, atravs de clculos de ocupao de banda, que um acesso ADSL 2+ permitir que um assinante consiga, de maneira satisfatria, assistir a trs canais diferentes simultaneamente.

Figura 9 - Esquema de soluo IPTV sobre ADSL

Outra considerao a ser feita em relao ao acesso via rede metlica a possibilidade de adoo de VDSL2. Essa recente tecnologia DSL permite que sejam alcanadas taxas de at 100 Mbits/s em distncias curtas e, entre 1 e 2 KM, taxas entre 50 e 75 Mbits/s.

2.3

RESUMO

Nesse captulo foram apresentados os modelos de referncia OSI e TCP/IP e, utilizando o modelo TCP/IP, os protocolos que atuam em cada camada foram citados. Ambos os modelos estudados dividem as tarefas inerentes transmisso/recepo de dados em uma rede em camadas com o principal objetivo de facilitar o entendimento dos processos, etapas e protocolos utilizados na

41 arquitetura de uma rede IPTV. Fazendo uso dessa idia, optou-se por dividir o sistema IPTV em pores menores com base no modelo TCP/IP e, individualmente, estudar cada camada. A respeito da camada de Aplicao foi analisado o CODEC MPEG4 que tem a funo de compactar os dados. Relativo camada Transporte, os protocolos TCP e UDP foram comparados e os protocolos RTP e RTCP apresentados. Na camada Internet deu-se destaque ao protocolo IP e aos protocolos IGMP e RSVP. O MPLS foi associado, didaticamente, camada de acesso ao meio e nessa camada os meios ptico, metlico e espao livre tambm foram estudados.

QUALIDADE DE SERVIO

3.1

INTRODUO

Com a convergncia das redes comum que diferentes servios sejam oferecidos pela mesma infraestrutura de rede, porm, comumente diferentes aplicaes exigiro diferentes parmetros de Qualidade de Servio. Um atraso na ordem de 1 segundo em uma aplicao como vdeo ou teleconferncia poder tornla invivel, porm em uma aplicao do tipo chat ou transferncia de arquivos esse atraso pode ser muito bem tolervel em alguns casos (CHOWDHURY, 2002). Na recomendao do ITU, QoS definida como o efeito conjunto do desempenho do servio que determina o grau de satisfao de um usurio desse servio.

42 3.2 NECESSIDADE DE QOS

A manuteno de redes especficas para diferentes servios no , hoje em dia, uma soluo vivel. Hoje as redes so convergentes, ou seja, uma mesma estrutura de rede ser utilizada para provimento de diferentes servios (8). Diferentes aplicaes exigem das redes caractersticas distintas. Muitas aplicaes, mesmo aplicaes multimdias, podem exigir da rede apenas uma determinada banda. Ao pensarmos, por exemplo, em um link de 64 Kbps utilizado exclusivamente para trfego de voz, no haveria necessidade de implementar tcnicas adicionais de QoS para obteno de boa qualidade. Muitas vezes a vazo do link suficiente para a obteno da qualidade esperada. Dimensionar uma rede ao conhecer o trfego que a mesma ter que suportar uma soluo simples e deve ser aplicada j na fase do seu projeto (8). Superdimensionamento apenas uma das tcnicas de QoS explicadas nesse captulo, a qualidade de servio em redes IP no necessariamente resolvida com um nico protocolo ou algoritmo, na maioria dos casos e dependendo da necessidade das aplicaes, um conjunto de tcnicas devem ser adotadas.

3.3

TCNICAS DE QOS

As tcnicas mais difundidas para obteno de QoS em redes so (8; CHOWDHURY, 2002): superdimensionamento - superdimensionar uma rede sempre ser a soluo mais fcil, prtica e eficiente para a obteno de QoS, porm nem sempre faz-lo possvel pois, alm das restries de equipamentos e meio fsico, existe o fator custo que pode inviabilizar essa soluo.

43 poltica de filas - separar fluxos distintos em filas distintas e assim priorizar determinados contedos , tambm, uma forma eficaz e de baixo custo.

armazenamento em buffer - armazenar parte do contedo em buffer uma tcnica muito til em aplicaes que exigem baixo Jitter como, por exemplo, VoD. Nesse tipo de aplicao o receptor armazena em buffer de memria pacotes recebidos e inicia a execuo do vdeo com alguns segundos de atraso para que, caso seja necessrio a retransmisso de pacotes ou ocorra um aumento momentneo na latncia, o vdeo continue sendo exibido e o receptor no perceba a ocorrncia da falha.

modelagem de trfego trfego em rajadas comum em uma rede e desafiador para a implementao de QoS. Modelar o trfego de forma a manter taxas de transferncias constantes o objetivo da utilizao dessa tcnica.

reserva de recursos reservar recursos em um determinado enlace pode trazer aplicao a qualidade de servio almejada. Para reservar recursos no trajeto entre transmissor e receptor o administrador da rede deve conhecer previamente a rota entre ambos e, necessrio ainda, que todos os ativos de rede do trajeto possuam essa facilidade e que o recurso a ser reservado esteja disponvel.

balanceamento de carga sempre que exista mais de um caminho possvel entre emissor e receptor pode ser possvel dividir o trfego entre eles e, assim, no sobrecarregar ou subutilizar nenhum dos possveis caminhos.

44 3.4 PARMETROS DE QOS

O objetivo ao aplicar essas ou outras tcnicas para obteno de QoS atingir parmetros de qualidade especficos para determinada aplicao. Entre os parmetros mais significativos pode-se citar (8):

reduo da latncia pacotes oriundos de aplicaes sensveis a atrasos devem ser priorizados dentro da rede.

reduo de Jitter a variao do atraso pode ser impactante em aplicaes sob demanda.

aumento da confiabilidade garantir a entrega de pacotes essenciais determinada aplicao.

aumento da disponibilidade a disponibilidade de um link determinante para a manuteno de um nvel de qualidade aceitvel.

reduo da taxa de erros congestionamento e colises afetam o desempenho da rede e devem ser combatidos atravs da utilizao de tcnicas de QoS.

COMPONENTES DE UMA REDE IPTV

4.1

INTRODUO

Nesse captulo so descritos os componentes de uma rede IPTV. Na figura a seguir apresentado um exemplo de arquitetura genrica de uma rede IPTV demonstrando seus componentes principais (UNEN, 2006; TELECO 2010):

45

Figura 10 Componentes genricos de uma rede IPTV

Fonte: Teleco

4.2

HEADEND

O headend a rea primria onde o contedo adquirido e tratado para alimentar a rede IPTV. Assim como nas solues de TV a Cabo ou por Satlite, um servio de IPTV requer um head-end (UNEN, 2006; TELECO 2010). Headend o ponto da rede onde os canais de transmisso broadcast e os contedos sobre demanda so recebidos, comprimidos, tratados e formatados sendo, depois, entregue ao backbone IP, no qual todo sinal encapsulado por meio do protocolo IP e distribudo aos usurios (UNEN, 2006; TELECO 2010). O headend deve possuir, tambm, conexes com operadoras de TV convencionais para exibio do contedo ao vivo. A localizao do headend pode ser centralizada ou distribuda. Numa arquitetura centralizada, o vdeo enviado do headend central at o set-top-box do usurio. Todo o trfego de vdeo vai fluir a partir de um link conectado ao headend; esse link deve ser capaz de suportar picos elevados de trfego. Essa arquitetura apresenta um problema em relao ao tempo de resposta do usurio, pois o transporte vai fluir desde a rea de centralizao at a ponta final do cliente, aumentado o delay entre o headend e o usurio final.

46 O backbone de transporte nesse tipo de distribuio deve ser projetado para suportar uma grande quantidade de requisies de todas as reas de atuao da operadora de telecomunicaes. A Figura 11, abaixo, ilustra a distribuio de vdeo em uma arquitetura centralizada.

Figura 11 Distribuio de vdeo centralizada

Fonte: Teleco Um headend descentralizado reduz o tempo de acesso do usurio e a operadora pode implantar instncias intermedirias numa estrutura distribuda hierarquicamente. Os servidores armazenam o contedo, que popular em sua rea de atuao, e os segmentos iniciais dos programas mais acessados. Nessa distribuio de arquitetura, h um servidor que responsvel pela localizao dos programas disponveis em todo o sistema, como ilustrado na figura abaixo (TELECO 2010).

47

Figura 12 Distribuio de vdeo descentralizada

Fonte: Teleco

Em um sistema de IPTV a utilizao de headends distribudos pode trazer larga vantagem, sobretudo minimizando a latncia. Os armrios pticos de algumas operadoras de telecomunicaes poderiam ser utilizados como headends descentralizados. Na soluo proposta por Tara Van Unen em (UNEN, 2006), ilustrada na figura 13, observa-se um headend responsvel pelo contedo nacional e outro pelo contedo regional. Essa soluo mostrada a seguir.

48

Figura 13 Exemplo de arquitetura IPTV com headends nacional e regional.

4.3

CORE IP

Agrupa os canais de vdeo codificados, transportando sobre a rede IP do fornecedor de servio (backbone IP da operadora). So redes preparadas para a transmisso de vdeo, garantido uma QoS (Quality of Service) que reflita uma QoE (Quality of Experience) aceitvel pelo usurio, sendo sua qualidade comparada ou superior das TV a cabo ou via satlite. O core IP ainda contempla os protocolos de transporte em modos unicast e multicast e a sinalizao. O core IP uma rede, cuja estrutura fsica de transporte baseada em fibras pticas ou em outras redes de transporte como o DWDM. O core deve ser dotado de implementaes de QoS (TELECO, 2010). O core poder transportar simultaneamente centenas de canais de TV que podero ser visualizados pelos vrios assinantes. O nmero de canais aos quais o assinante poder ter acesso simultneo estar diretamente ligado capacidade de banda da rede de acesso. Em um acesso de ltima milha baseado em fibra ptica essa limitao deixa de ser significativa como no caso de acesso via ADSL.

49 4.4 REDES DE ACESSO

A rede de acesso faz parte da arquitetura de uma rede IPTV, e representa a ligao do fornecedor do servio de IPTV, a operadora de telecomunicaes e a casa do usurio. Esse acesso denominado ltima milha. A conexo do usurio pode ser realizada com a utilizao de vrias tecnologias de rede de acesso. O meio de acesso predominante atualmente a tecnologia DSL (linha digital de assinante), porm observa-se um grande crescimento na adoo de fibra ptica em redes PON (Passive Optical Network) e Metro Ethernet, permitindo estender distncias e aumentar velocidade (TELECO, 2010).

4.5

SET-TOP-BOX

O set-top-box (STB) o ponto terminal da rede, normalmente instalado dentro da residncia ou empresa para onde o servio de IPTV ser disponibiizado e tem a funo de permitir a comunicao entre o expectador e o provedor do servio alm de fornecer uma interface amigvel para que o usurio selecione o contedo que deseja assistir e tambm permitir a seleo de servios adicionais (UNEN, 2006; TELECO 2010). Os STB so equipamentos simples com uma interface amigvel. Devem possuir grande capacidade de armazenamento para que nele sejam gravados contedos de interesse dos clientes. Os STB apenas decodificam o sinal recebido da operadora e, por isso, no tm qualquer trabalho em nvel de processamento extra. O nico problema que um decodificador pode ter quando o mesmo se depara com erros de transmisso e dever decidir como proceder. Essa deciso pode tornar melhor ou pior a qualidade do vdeo e poder ser fator determinante para a diferenciao entre STBs.

50 4.6 RESUMO

Basicamente uma rede IPTV composta por headends que possuem a funo de receber e armazenar o contedo a ser disponibilizado, Core ou Ncleo composto por enlaces de alta velocidade com a funo de transportar o contedo entre os headends, as redes de acesso que com a funo de entregar o contedo nas dependncias do assinante do servio e onde observa-se o predomnio da tecnologia ADSL O STB ponto terminal da rede. Instalado nas dependncias do cliente responsvel por enviar para o aparelho de TV as imagens recebidas.

COMPARATIVO DO IPTV COM OUTRAS TECNOLOGIAS DE ENTREGA DO SERVIO DE TV

Nos captulos iniciais foram apresentadas razes que motivaram as operadoras a oferecer novos servios a seus clientes. Operadoras de TV a Cabo j oferecem TV, telefone e Internet a seus clientes. Esse tipo de servio que combina voz, dados e multimdia utilizando a mesma infraestrutura e, assim, permite o aproveitamento mximo das sinergias de rede foi denominado como triple play A seguir so apresentadas trs tecnologias de acesso a redes triple play para utilizar como parmetro de comparao com IPTV.

5.1

DTH DIRECT TO HOME

O site Wikipdia define DTH como modalidade de transmisso de contedo televisivo oriundo de satlite e recebido pelo cliente atravs da utilizao de antena receptora (WIKIPEDIA, 2010). De maneira geral o funcionamento do DTH d-se atravs de trs componentes do sistema: fonte de programao, central de transmisso e antena.

51 Basicamente a fonte de programao composta pelos canais que fornecem a programao, enquanto a central de transmisso, centro do sistema, a entidade que recebe a programao das fontes de transmisso e emite o sinal de transmisso para os satlites que repetiro o sinal que, enfim, ser coletado pela antena e passado para o receptor nas dependncias do usurio do servio. (WIKIPEDIA, 2010) Um dos fatores positivos tecnologia DTH sua alcanabilidade. O investimento de cabeamento de determinadas regies poderia no ser financeiramente vantajoso para as operadoras e, nesse caso, a utilizao de tecnologias wireless poderia ser a soluo. Os avanos da tecnologia para transmisses sem fio, como a transmisso e recepo com mltiplas antenas (MIMO) e modulao OFDM, permitem que requisitos de QoS sejam atendidos. Entre as principais tecnologias aptas a serem utilizadas em transmisses IPTV podemos citar o Wi-Max, o LTE e o Wi-Fi. Isto posto, o IPTV poderia atingir maior alcance, mesmo em regies no cabeadas, atravs da utilizao de tecnologias sem fio.

5.2

MMDS SERVIO DE DISTRIBUIO MULTIPONTO MULTICANAL

O servio de distribuio multiponto multicanal MMDS, adotado ainda por algumas operadoras de TV a cabo brasileiras , segundo a ANATEL, uma modalidade de servio especial, que se utiliza de faixa de microondas para transmitir sinais a serem recebidos em pontos determinados dentro de uma rea de prestao. O funcionamento do MMDS resumido na figura a seguir:

52

Figura 14 Sistema MMDS. Fonte: Portal Anatel.

A entrega de contedo televisivo via MMDS uma alternativa utilizada pelas operadoras de TV a cabo para alcanar regies onde ainda no dispe de cabos. Esse tipo de arquitetura apresenta desvantagens quanto vulnerabilidade a interferncias alm de possurem uma taxa de upstream baixa o que dificulta a interatividade. Ainda, em relao ao MMDS, a faixa de freqncia utilizada pelo sistema no Brasil, 2.5 GHz, disputada com as operadoras de telecomunicaes que pretendem utiliz-la com a tecnologia LTE (RTI, 2009).

5.3

HFC HIBRID FIBER COAX

Uma popular arquitetura de rede, conforme ilustra a Figura 15, criada com a combinao de fibras pticas e cabo coaxial. Denominada HFC essas redes so utilizadas por operadoras de TV a cabo para provimento de servios Triple Play aos seus assinantes. Uma rede HFC tem grandes vantagens como, por exemplo, menor custo de implantao e possibilidade de elevadas taxas de transmisso. Porm algumas desvantagens existem. Uma das desvantagens de uma arquitetura de rede baseada em HFC sua sensibilidade s descargas eltricas. O cabo funciona como um praraios e, numa tempestade, a chance de danos a equipamentos como fontes e amplificadores grande. Outro fator negativo a destacar que existe sempre a

53 possibilidade interferncia de sinais externos que podem criar rudos na rede e prejudicar a qualidade do sinal de radiofreqncia.

Figura 15 Sistema HFC

5.4

RESUMO

Uma soluo hbrida traria ao consumidor a necessidade de instalao de uma antena externa e utilizao de um equipamento para converter o sinal recebido do satlite e envi-lo ao aparelho de TV e pelo da operadora o investimento em hardwares e softwares destinados ao DTH, alm da licena necessria para uso do satlite o que, de certa forma, vai contramo da tendncia de redes convergentes na qual todos os servios esto baseados na mesma infraestrutura. A convergncia em uma rede IP , em tese, a melhor opo para a entrega de TV pelas operadoras de telecomunicaes, uma vez que as mesmas j dispem de grande experincia com redes de dados, alm de possurem anis pticos, redundncia e uma infraestrutura quase pronta para o servio de IPTV.

54 A proposta desse captulo foi comparar o IPTV com dois outros sistemas de transmisso de contedo televisivo, MMDS, DTH e HFC, com o objetivo de apresentar vantagens de um sistema IPTV.

SOLUES PROPOSTAS PARA APERFEIOAMENTO DO SISTEMA IPTV

6.1

INTRODUO

Sites como MegaTV e SuperCanais oferecem a possibilidade de assistirmos via Internet canais abertos como Rede Globo e por assinatura como SporTV com qualidade razovel. Em experincia realizada, utilizando conexo de 1Mbps e um Notebook Dell Latitude 510 com 512 MB de memria RAM e placa de vdeo Intel 915GM, observou-se que o delay entre a recepo do contedo via Internet e a via rede HFC da NET variando entre 30 at cerca de 90 segundos. Um delay de 90 segundos no pode ser considerado normal ou ideal, mas capturando com o software Wireshark os pacotes recebidos durante a recepo do contedo, conforme ilustra a Figura 16, observa-se que possvel sua reduo.

Figura 16 Pacote capturado com o software Wireshark onde se observa a utilizao de TCP.

Como visto na figura anterior, o protocolo utilizado na camada de transporte o TCP. O protocolo TCP possui em relao ao UDP um overhead de 20

55 bytes por implementar tcnicas de controle de fluxo e garantia de entrega. Em aplicaes multimdia um pacote no entregue no convm ser retransmitido, pois o mesmo no ter mais importncia dentro do contexto. A perda de um pacote em uma transmisso multimdia pode gerar o picotamento do som ou a falha em alguma imagem na tela e sua retransmisso de maneira nenhuma viria a corrigir a falha a tempo. A opo pelo protocolo UDP na camada 4 por si s j faria com que o delay fosse reduzido. Outro aspecto a se destacar a utilizao de QoS. Ao acessar o contedo disponibilizado por esses sites o contedo normalmente precisa atravessar redes de distintas operadoras e, portanto, a marcao de pacotes visando QoS pode no ser eficiente, pois um pacote classificado com prioridade mxima EF, em um determinado ponto da rede pode no receber essa priorizao em outros pontos da rede como ao ingressar na rede de outra operadora (KUROSE, 2006). Na arquitetura proposta o contedo ao vivo seria recebido diretamente, via satlite, por exemplo, pela operadora do servio e enviado aos assinantes atravs de rede prpria facilitando a eficincia da priorizao de pacotes e melhorando muito a Qualidade de Servio (QoS). Na Figura 17 possvel verificar que no h marcao no campo DSCP do cabealho IP no mesmo pacote capturado via Wireshark .

Figura 17 - Pacote capturado com o software Wireshark onde se observa o campo DSCP sem marcao.

A seguir so apresentadas solues para os problemas listados no item 1.2 Temas e Objetivos. O primeiro item a ser analisado diz respeito camada de transporte onde se prope uma comparao entre os protocolos da camada de transporte UDP e TCP. O segundo aspecto a ser considerado diz respeito camada de rede e a formao de grupos multicast atravs do IGMP.

56 6.2 BANDA ELEVADA PARA TRANSPORTE DE UDIO E VDEO

As propostas para reduzir a banda necessria para transmisso IPTV incluem a utilizao do CODEC MPEG-4, utilizao do protocolo UDP em substituio ao TCP na camada de transporte e criao de grupos multicast atravs do protocolo IGMP.

6.2.1 MPEG-4

Visando a minimizar a banda utilizada para a transmisso de udio e vdeo, que elevada e a arquitetura atual da rede no est apta a atender, proposta a utilizao de CODECs, que permitem a compactao dos dados mantendo a qualidade original dos mesmos.

6.2.1.1 Caractersticas do codec MPEG-4

O vdeo um dos contedos de mdia mais pesados, ou seja, que exigem mais das redes devido quantidade de informaes que cada segundo de vdeo contm. Quando no realizado nenhum tipo de compresso, estima-se que, para o transporte de vdeo utilizando PCM com amostra de 8 bits, seria necessria uma banda de 166 Mbps ou 369 Mbps para vdeos com alta definio (HD). Buscase, atravs da utilizao de CODECs, conseguir boa qualidade de vdeo com mnima ocupao de banda. O padro MPEG-4 tem um fator de compresso na ordem de 80 vezes, o que significa que a transmisso de vdeo a uma resoluo igual PCM necessitaria de, aproximadamente, uma taxa de transferncia de 2 Mbits/s.

57
Tabela 1 - Fatores de compresso e taxa de transferncia aproximados

Formato PCM MPEG-2 MPEG-4

Fator de compresso 1x 40x 80x

Taxa necessria para canal SD*1 (Mbit/s) 166 4,2 2,1

Taxa necessria para canal HD*2 (Mbit/s) 369 9,2 4,6

6.2.2 TCP x UDP

Os protocolos mais adotados na camada de transporte so o UDP e o TCP. Ambos apresentam caractersticas distintas que se adquam a diferentes aplicaes (FILIPPETTI, 2008).

6.2.2.1 Overhead TCP

O cabealho TCP possui 20 bytes (32 bits x 5 camadas) e formado pelos seguintes campos: Source Port Destination Port Sequence Number Acknowledgement Number Header Lenght Reserved; Code Bits Window CheckSum Urgent Point Option

58 Data

J o cabealho do protocolo UDP (RFC 768) possui 8 bytes e contm apenas os campos: Source Port Destination Port Lenght CheckSum Data

Observa-se, assim, que os pacotes enviados pela camada de Aplicao do modelo TCP/IP ao serem encapsulados utilizando TCP possuem um overhead de 12 bytes em comparao ao encapsulamento na camada de Transporte atravs do UDP. Ao supormos uma transmisso de dados com taxa efetiva de 100 Mbits/s e utilizando na camada de Transporte o encapsulamento TCP e MTU de 1500 bytes, teremos aproximadamente, 6.65 Mbytes de informaes dispensveis por minuto. Supondo a durao de um determinado contedo em 120 minutos teramos, nesse caso, 798 Mbytes de overhead adicional em relao ao UDP. Segundo James F. Kurose e Keith W. Ross, o protocolo UDP faz apenas quase to pouco quanto um protocolo de transporte pode fazer. A maioria dos campos suprimidos do cabealho do protocolo TCP tem a funo de garantir a entrega dos pacotes ao destinatrio, solicitar a retransmisso caso um pacote seja perdido e numerar os pacotes de forma que os mesmos possam ser reordenados no destino. Esse procedimento vlido para aplicaes que envolvam transferncia de dados como, por exemplo, FTP e Telnet, onde a correta entrega dos dados mais importante que o tempo gasto nesta entrega. Em uma aplicao de vdeo em tempo real ou sobre demanda, a retransmisso de um pacote que, por ventura, no tenha alcanado seu destino pode prejudicar a qualidade da imagem, pois a visualizao do fragmento retransmitido muito provavelmente ocorrer sobreposta outra imagem.

59 Em uma aplicao IPTV o protocolo UDP atuar em conjunto com o protocolo RTP e RTCP. Os protocolos RTP/RTCP so definidos pela RFC 3550 do Internet Engineering Task Force (IETF).

6.2.2.2 Estabelecimento da conexo

Diz-se do protocolo TCP que um protocolo orientado conexo, ou seja, para que se inicie uma transferncia de dados faz-se necessrio o estabelecimento de uma conexo entre emissor e receptor. O estabelecimento da conexo feito atravs da troca de informaes entre emissor e receptor e denominado triple handshake ou 3-way handshake. O tempo demandado para que a conexo seja estabelecida contribuir para o aumento da latncia e, portanto, contribui para a no eficincia do protocolo TCP em aplicaes IPTV. O estabelecimento de uma conexo atravs do 3-Way Handshake ilustrado na Figura 18.

Figura 18 3way-handshake

Fonte: Cisco Academy

O UDP um protocolo no orientado conexo e, devido a essa caracterstica, no necessita de nenhum tipo de comunicao prvia entre emissor e receptor para que a transmisso de dados se inicie. Essa caracterstica do protocolo UDP se apresenta como mais uma justificativa para sua adoo em sistemas IPTV.

60 6.2.3 IGMP

A criao de grupos Multicast contribui tambm para a otimizao do uso da banda disponvel uma vez que pode transformar o envio de um pacote para vrios destinos em uma nica operao de envio, como define Carbonaro em (CARBONARO, 2004):
Dentre outras aplicaes do Multicast temos a transferncia de dados em grandes volumes como a recepo de aplicaes de taxa constante como transferncia de udio, vdeo e texto de uma palestra ao vivo para um conjunto de participantes distribudos, as aplicaes de dados compartilhados como, por exemplo, uma videoconferncia compartilhada por muitos participantes distribudos, jogos interativos, tais como ambientes virtuais interativos distribudos ou jogos multiusurios como o Quake. Para cada uma dessas aplicaes, uma abstrao muito til a idia de multicast: o envio de um pacote de um remetente para mltiplos destinatrios em uma nica operao de envio.

Um grupo multicast definido como um conjunto de usurios para o qual possvel a transmisso de mensagens e so identificados por nome e endereos nicos endereos multicast (CARBONARO, 2004). Em um sistema IPTV faz-se necessrio a criao e manuteno de grupos Multicast. Os membros de um grupo Multicast seriam todos os usurios que, em determinado momento, assistem mesma programao.

O IGMP tende a ser o protocolo utilizado para a gesto de grupos em um sistema IPTV. Existem duas verses do protocolo IGMP a verso 3 e a verso 2. Apesar de as mensagens serem diferentes nas duas verses, as funes so as mesmas.

61 As diferenas existentes resumem-se pela possibilidade de agrupar as mensagens. A verso 3 utiliza uma rede Single Source Multicast (SSM), na qual s os aparelhos especficos podem enviar dados, ao contrrio da verso 2, que utiliza uma rede Any Source Multicast (ASM), onde qualquer dispositivo pode enviar dados para a rede, podendo causar problemas. As mensagens, na verso 3, podem ser agrupadas de forma a eliminar o overhead existente nas mensagens da verso 2, de maneira que o envio de um leave seguido de um join, envia-se apenas uma mensagem. (CARBONARO, 2004) No IGMP, o Set-Top Box (STB) seria um cliente do IGMP e o Broadband Services Router (BSR) o roteador IGMP. Ambos interagem, na troca das mensagens: JOIN o cliente indica que contedo deseja receber, tornando-se membro de um grupo; LEAVE o cliente faz um pedido para deixar o grupo; QUERY o roteador pergunta ao cliente quais so os grupos aos quais ele pertence. Este um mtodo para verificar condies de erros. Por exemplo, uma STB desligada da rede, logo no envia a mensagem LEAVE.

6.3

GARANTIA DE ENTREGA E PRIORIZAO DE PACOTES

Com o intuito de solucionar os problemas decorrentes das caractersticas do protocolo IP e da utilizao do protocolo UDP na camada de transporte, que geram problema devido retransmisso gerada pela no confirmao na entrega de um pacote, sugerida a utilizao do protocolo RTP. Para contribuir para a melhora da QoS, sobretudo no que tange priorizao e garantia de entrega de pacotes os protocolos DiffServ, IntServ, RSVP e MPLS podem ser utilizados

62 6.3.1 RTP

O protocolo RTP um protocolo de utilizado em aplicaes de tempo real como, como voz e vdeo sobre IP. o RTP que definir a forma com que um determinado fluxo de dados ser fragmentado, adicionando a cada fragmento informao de sequncia e de tempo de entrega, identificao dos contedos para descrever o tipo de codificao usada, identificao da fonte (em sesses multicast) e timestamping para compensao do jitter em pacotes pertencentes ao mesmo fluxo de dados. O protocolo RTP far uso do protocolo RTCP. O protocolo RTCP fornece ao RTP a funcionalidade de controle, contribuindo para o monitoramento da QoS (CHOWDHURY, 2002)..

6.3.2 DIFFSERV e INTSERV

Como visto anteriormente o protocolo IP um servio de entrega de melhor esforo, ou seja, no oferece nenhuma garantia de entrega de segmentos e to pouco a integridade dos dados e, por esse motivo, o modelo padro de encaminhamento padro de uma rede IP denominado Best-Effort, ou Melhor Esforo (FILIPPETTI, 2008). Nesse modelo de encaminhamento todo o fluxo de dados, independente do tipo de informao que o mesmo carrega, sero tratados da mesma maneira dentro da rede ocasionando que, dados de uma transmisso em tempo real em IPTV, que exigem baixa latncia e diminuto jitter, recebam a mesma prioridade de encaminhamento que pacotes provenientes de uma aplicao de correio eletrnico onde, normalmente, pequenos atrasos so bem tolerveis. Para solucionar essa deficincia prope-se a utilizao dos protocolos DiffServ e IntServ (SOARES, 2002). O protocolo DiffServ, RFC 2998, permite a distino de diferentes fluxos de dados dentro de uma rede. Parte do campo ToS (Type of Service) do cabealho

63 IP (6 bits) passa a ser utilizado para a marcao dos pacotes e classificao dos mesmos em diferentes classes de servio. Esse novo campo passa a se chamar DSCP (DS CodePoint) ou campo DS (Differencial Service). Como critrio de classificao pode-se utilizar, por exemplo, a interface de entrada ou sada do pacote, o protocolo (ou porta) utilizado na camada de transporte, entre outros e, aps essa classificao pode-se, por exemplo, determinar a reserva de um percentual de largura de banda ou determinar uma poltica de filas pela quais os pacotes pertencentes determinada categoria estaro sujeitos KUROSE, 2006. . Segundo o site Wikipedia, Estes acordos especificam que classes de trfego sero servidas, que garantias so necessrias para cada classe, e qual o volume de dados para cada classe. A classificao permite a distino entre pacotes pertencentes a diferentes classes de trfego e possibilita um tratamento diferenciado para cada pacote, entretanto, simplesmente classificar os pacotes no garante que eles recebam um servio com a QoS desejada. A classificao apenas um mecanismo para distingui-los, a diferenciao no tratamento destes pacotes uma deciso do policiamento utilizado. IntServ por sua vez, trabalha em conjunto com o protocolo de sinalizao RSVP que tem a funo de promover a reserva de recursos em determinado enlace (CHOWDHURY, 2002; 8). Os protocolos IntServ e DiffServ podem ser adotados como solues complementares (8). Uma alternativa de uso conjunto das duas solues seria a utilizao do DiffServ no Core IP na medida em que uma soluo mais leve e o IntServ / RSVP nas redes de acesso, na medida em que prov um bom controle dos requisitos de QoS das aplicaes e, ainda, pelo fato de ser possvel antecipadamente definir o trajeto a ser percorrido pelo fluxo de dados ao receber uma solicitao de determinado STB.

64 6.3.3 RSVP

O protocolo RSVP utilizado pelos hosts para informar e solicitar rede suas necessidades de QoS. Ele permite que os equipamentos de rede possam trocar informaes no sentido de cooperarem entre si, visando garantir a QoS aceita pela rede KUROSE, 2006. Associados aos protocolos de sinalizao encontram-se, em geral, os processos de controle de admisso e controle de policiamento. O controle de admisso verifica se o equipamento da rede tem condies de suportar um novo fluxo que demanda servio, de acordo com as exigncias de QoS especificadas no pedido de servio. Caso os recursos sejam insuficientes, o pedido deve ser rejeitado e a transmisso do fluxo bloqueada KUROSE, 2006. O controle de policiamento verifica se o usurio tem permisso administrativa para fazer um pedido de reserva de recursos da rede KUROSE, 2006. O RSVP comumente associado ao protocolo IntServ, utilizado para requisitar recursos da rede e trabalhar com a aceitao ou negao do mesmo (KUROSE, 2006). Uma importante caracterstica do RSVP em comunicao de grandes grupos multicast que a reserva de recursos parte do destinatrio, ou seja, em uma aplicao IPTV o STB efetuaria a solicitao de acordo com as suas necessidades (CARBONARO, 2004; KUROSE, 2006). A solicitao ser repassada a todos os ns da rede por onde o fluxo de dados ir transitar atravs do controle de admisso e do controle de poltica, e a solicitao de reserva poder ou no ser atendida. Com a utilizao de headends descentralizados o contedo estaria armazenado em um local prximo ao usurio final e, dessa forma, esse trajeto poderia ser facilmente pr-estabelecido. O protocolo RSVP negocia a reserva de recursos de forma simplex, ou seja, em um nico sentido, sempre do receptor para o emissor. Essa uma caracterstica importante a ressaltar sobre o protocolo RSVP, pois, em um mecanismo de entrega

65 ponto a ponto tradicional o emissor responsvel por requisitar reservas de recursos da rede, o que pode acarretar problemas, pois cada vez que um membro entra ou sai da aplicao, responsabilidade do emissor refazer todas as reservas da conexo, ao passo em que, quando a responsabilidade da solicitao de reserva passa a ser do STB surge a possibilidade de diferentes STBs efetuarem diferentes requisies de reservas (KUROSE, 2006) Alguns conceitos relacionados ao protocolo RSVP (KUROSE, 2006)

Sesso o nome dados ao processo de troca de mensagens de sinalizao e de dados do protocolo RSVP. atravs dessas mensagens que so relacionadas as camadas de transporte dos participantes da comunicao (unicast ou multicast). Cada sesso independente e pode ser estabelecida em valores de QoS diferentes dos requisitados pelo receptor inicialmente.

Soft-state estado que um determinado elemento emissor-receptor se encontra quando uma reserva estabelecida. Este estado dever ser periodicamente atualizado pelos STBs. Ao invs de entregar rede a responsabilidade em detectar e responder a falhas, o RSVP delega aos receptores o trabalho de reenviar periodicamente as solicitaes de reservas necessrias. As mensagens RSVP fundamentais so RESV e PATH. Mediante a troca destas mensagens, o protocolo toma uma srie de decises, como por exemplo, aceitar ou no o novo fluxo de dados, criando um ambiente para que os recursos sejam reservados, efetuar ou no a reserva de recursos. Cada parmetro utilizado para requisitar o QoS est representado nas mensagens do RSVP. A troca de mensagens exemplificada na Figura 19.

66

Figura 19 Troca de mensagens RSVP

6.3.4 INTEGRAO MPLS E DIFFSERV

Uma caracterstica comum aos protocolos MPLS e DiffServ o fato de que ambos so baseados em marcaes realizadas nos pacotes. Com a utilizao de MPLS e DiffServ nos enlaces de alta velocidade entre os headends e, at mesmo, nas redes de acesso surge a necessidade de realizar algumas adaptaes uma vez que com o roteamento baseado em labels proposto pelo MPLS o campo DS do cabealho IP no seria levado em conta e, consequentemente, ocorreriam. Para integrar MPLS e DiffServ necessrio transpor a informao do PHB nos pacotes MPLS. H duas maneiras de fazer isso: mapear o campo DSCP dos pacotes IP no campo EXP do MPLS e codificar o PHB no rtulo. Como o campo EXP tem apenas trs bits e o DSCP tem seis, no possvel mapear todos os PHBs possveis no campo EXP. LSPs criados dessa maneira so denominados E-LSPs. A outra forma de mapear PHBs no MPLS codificar o PHB de um pacote no seu rtulo. Soluo til quando h necessidade de estabelecimento de mais que tratamentos diferenciados propostos pelo DiffServ no

67 8 PHBs, ou quando se est usando um link que no use o cabealho MPLS, como ATM. LSPs criados desta forma so chamados L-LSPs. Em enlaces de tecnologia como ATM, que no utilizam o cabealho MPLS, a nica maneira de transpor a informao da classe de servio (CoS) utilizando L-LSPs uma vez que os roteadores necessitaro consultar o campo EXP para definir o tratamento que o pacote dever receber. A tabela a seguir resume as principais diferenas entre L-LSPs e ELSPs:
Tabela 2 - Comparativo entre E-LSPs e L-LSPs

E-LSP PHB determinado pelos bits EXP At 8 PHBs em um mesmo LSP

L-LSP PHB determinado pelo label ou pelo label + bits EXP Um PHB por LSP ou mltiplos PBHs com mesmo escalonamento e nveis de descarte distintos

Uso de conservador de labels. Uso intensivo de labels, pois eles Labels so criados apenas pelas tambm afetam os PHBs necessidades de roteamento A atribuio de PHBs no dependem Os PHBs so definidos juntos com a da sinalizao MPLS sinalizao MPLS At 8 PHBs na rede como um todo Nmero ilimitado de PHBs na rede

Em um sistema de IPTV no haveria a necessidade de um grande nmero de PHBs sendo necessria apenas a diferenciao de pacotes de transmisses ao vivo e sob demanda (VoD) e, sendo assim, mapear o contedo do campo DSCP do cabealho IP no campo EXP do cabealho MPLS seria a soluo mais fcil de implementar. Porm a extensa rede ATM que a maioria das operadoras ainda utiliza para prover acesso de banda larga, sobretudo atravs da tecnologia ADSL necessita ser aproveitada e, nesse contexto, faz-se necessria a utilizao de L-LSPs. O critrio para a diferenciao desses trfegos no poderia ser o protocolo da camada de transporte, pois ambas as aplicaes usariam UDP e a distino pelo nmero de porta no seria a ideal. Nesse caso o IP de origem, ou

68 seja, o IP do servidor que fornece o contedo poderia ser utilizado como critrio de classificao.

6.4

ATRASOS E VARIAES NOS ATRASOS

Em transmisses em tempo real um fator importante a ser analisado so os atrasos aos quais um pacote est sujeito dentro de uma rede. Os atrasos so classificados em: atraso de processamento, atraso de fila, atraso de transmisso e atraso de propagao.

6.4.1 ATRASO DE PROCESSAMENTO

O atraso de processamento engloba, tambm, o tempo gasto para que um roteador determine o caminho pelo qual o pacote deve seguir e para isso o cabealho da camada de rede precisa ser analisado. Isso demanda tempo. A variedade de tecnologias empregadas nas redes de acesso como, por exemplo, ADSL, Wi-Fi e Ethernet propicia o emprego do protocolo MPLS como uma soluo para agilizar o roteamento de pacotes ao mesmo tempo em que permite maior eficincia na interligao de redes de tecnologias distintas.. O MPLS, definido pelo IETF, atua em uma camada intermediria s camadas 3 Rede e 2 Enlace por isso as vezes denominada camada 2.5 e trata de um chaveamento (switching) baseado em rtulos e, dessa forma, para tomar a deciso do prximo salto a encaminhar o fluxo independe do desencapsulamento do cabealho da camada Internet.

69 6.4.2 ATRASO DE TRANSMISSO

O atraso de transmisso, por sua vez, estar diretamente relacionado distncia pela qual o pacote dever trafegar at que alcance seu destino. No caso em questo prope-se a descentralizao dos headends, ou seja, trazer para pontos mais prximos do usurio final o contedo de imagens a ser acessado.

6.4.3 ATRASO DE FILA

6.4.3.1 DiffServ

O atraso de fila minimizado, tambm, com a utilizao do protocolo DiffServ uma vez que os dados so separados e enfileirados de maneira organizada segundo a marcao feita no campo DSCP.

6.4.3.2 Armazenamento em Buffer

Buffer o nome dado a uma regio de memria temporria utilizada para escrita e leitura de dados. Os buffers podem ser implementados em software ou em hardware. A opo pela utilizao da tcnica de armazenamento em buffer devido existncia de uma diferena entre a taxa em que os dados so recebidos e a taxa em que eles podem ser processados ou apenas pelo fato de que a taxa de transferncia normalmente varivel (Variable Bit Rate - VBR). O jitter introduz distoro no processamento da informao na recepo e, por isso, a rede necessita de mecanismos especficos de compensao e controle. A tcnica de armazenamento em buffer pode contribuir significativamente para a reduo do jitter.

70 Buffers devem ser implementados nos roteadores de ncleo e de borda da rede e, nos STB podem ser utilizados, tambm, para armazenamento de alguns segundos de contedo de canais diferentes do canal em execuo para que seja alcanada uma troca de canal com menor latncia. Outra opo para a utilizao da tcnica de armazenamento em buffer a possibilidade de o espectador escolher com antecedncia a programao qual deseja ter acesso e o STB possuir inteligncia para efetuar a transferncia dos dados aproveitando os perodos de baixa utilizao da rede.

6.5

RESUMO

A busca por uma melhor qualidade de servio passa por vrias etapas como, por exemplo, a descentralizao dos headends e utilizao de tcnicas de QoS e protocolos como o RTP e RSVP. A criao de grupos multicast, atravs da utilizao do protocolo IGMP, evita que o mesmo contedo seja transmitido vrias vezes. A opo do espectador de escolher com antecedncia o que deseja assistir permitir que o contedo selecionado seja baixado em horrios de pouco trfego e armazenado em seu STB assim podendo ser assistido a qualquer horrio, minimizando a ocupao de banda em horrios de pico. Compactar os dados com a utilizao de codecs e utilizar o protocolo UDP em detrimento ao TCP so algumas sugestes apresentadas nesse captulo. A tabela que segue relaciona as principais dificuldades encontradas e as devidas solues propostas.

71
Tabela 3 - Dificuldades encontradas e solues propostas

DIFICULDADE ENCONTRADA Necessidade de banda elevada para trfego multimdia

SOLUES PROPOSTAS A utilizao do CODEC MPEG4/H.264 faz com que o trfego seja reduzido graas compresso do fluxo com a utilizao de algoritmos. A utilizao do protocolo UDP em substituio ao TCP na camada de transporte prov a reduo do trfego uma vez que o protocolo TCP possui grande overhead em relao ao UDP. As caractersticas que possibilitam a simplicidade do protocolo IP por outro lado fazem com que o mesmo no contemple nenhuma garantia de entrega, porm, a utilizao do RTP e RTCP associados ao UDP na camada de transporte possibilita um melhor controle da entrega e seqenciamento de pacotes. Fluxos de dados provenientes de aplicaes distintas muitas vezes exigem da rede diferentes tratamentos. Como o protocolo IP no prov nenhum tipo de priorizao de pacotes, pode-se, com a utilizao do DiffServ efetuar marcaes nos pacotes e, atravs dessas marcaes oferecer tratamento diferenciado a pacotes da aplicao IPTV. A utilizao do protocolo MPLS combinado com DiffServ e RSVP permitem, tambm com a utilizao de armazenamento em buffer, minimizar a variao do atraso ou jitter. A latncia gerada pelo estabelecimento de uma conexo com a utilizao do TCP tambm varivel e, com

No confiabilidade do protocolo IP no que tange a garantia de entrega

Priorizao do trfego

Variao do atraso

72 a utilizao do UDP a mesma no ocorre. Utilizao da tcnica de armazenamento em buffer. A utilizao de ativos de rede como roteadores e switches mais robustos e a utilizao do roteamento baseado em label MPLS resultam na diminuio do atraso de processamento. A diferenciao de pacotes permitida atravs da marcao de pacotes no campo DS cria filas especficas para trfegos especficos e, assim, o atraso de fila reduzido, sobretudo para os pacotes com DSCP marcado como EF. Priorizao de pacotes, utilizao de fibras pticas tanto no ncleo da rede como em enlaces de ltima milha e reserva de recursos contribuem para a reduo do atraso de propagao. O fato de que o UDP no realiza o 3-Way Handshake antes de iniciar o envio de dados contribui, tambm, para diminuir o atraso de propagao.

Atraso de processamento

Atraso de fila

Atraso de propagao

PROCEDIMENTO METODOLGICO

O desenvolvimento do presente trabalho deu-se, sobretudo, atravs do estudo em livros e teses. O captulo 2 trouxe a fundamentao terica sobre o tema e nele buscou-se o estudo do modelo de camadas TCP/IP e dos protocolos que podero atuar em cada um das camadas do modelo. O objetivo foi, em parte, alcanado, porm algumas implementaes prticas realizadas no foram includas, pois no se poderia considerar o ambiente

73 em que as mesmas ocorreram como sendo um ambiente controlado e, por isso, tais experimentos esto citados no apndice A. O captulo 4 trouxe os componentes bsicos da topologia de uma rede de IPTV. Os componentes foram citados e a eles uma breve descrio foi associada. No captulo 5 trs mtodos de transmisso de TV foram descritos: DTH, HFC e MMDS. O objetivo foi apresentar algumas de suas caractersticas para que seja possvel o estabelecimento de um comparativo com IPTV. O captulo 6 trouxe propostas de solues para as dificuldades inerentes transmisso de vdeo sobre o protocolo IP.

74

APLICAO E RESULTADOS

Para a otimizao da utilizao da infraestrutura disponvel s operadoras de telecomunicaes com o objetivo de oferecer o servio de IPTV aos seus clientes surge a necessidade de utilizao de tcnicas de QoS e, tambm, a adoo de protocolos especficos como RSVP e MPLS. A opo de utilizar o protocolo UDP na camada de transporte contribui para a diminuio do atraso de transmisso graas a no existncia do 3wayhandshake que se d antes do incio da transferncia de pacotes, permite a reduo do overhead nas transmisses e evita problemas causados por retransmisses associadas ao protocolo TCP. O protocolo RTP com a funo de gerenciar o seqenciamento dos pacotes e reduzir o jitter pode reduzir a latncia total do sistema complementando o protocolo UDP. A utilizao da tcnica de comutao baseada em etiquetas, oferecida pelo MPLS e, atravs do DiffServ, utilizando tambm etiquetas nos pacotes para identificao de diferentes classes de trfego possibilita que fluxos de dados diferentes recebam diferentes tratamentos. O RSVP, protocolo de sinalizao responsvel por efetuar solicitaes de reserva de recursos em determinado enlace e IGMP, para que uma transmisso destinada a vrios destinos seja resumida em uma nica transmisso e, a utilizao desses protocolos e tcnicas de QoS, se somam proposta de descentralizao dos headends para a minimizao da latncia.

75

COMENTRIOS FINAIS

9.1

INTRODUAO

O servio de IPTV j realidade em muitos pases e deve, em breve, se tornar popular no Brasil. Para que o servio apresente uma boa qualidade algumas aes devem ser tomadas no sentido de conseguir um melhor aproveitamento da banda disponvel e, por conseguinte, aproveitar a infraestrutura legada.

9.2

CONCLUSES

O servio de IPTV apresenta-se como uma excelente alternativa para as operadoras de telecomunicaes fidelizarem seus clientes e aumentar a lucratividade com oferta de novos servios.

As operadoras de telecomunicaes j oferecem telefonia e Internet e almejam oferecer triple play a seus clientes. De certa forma, j disponibilizam disso, uma vez que o acesso Internet promove acesso a vdeos ao vivo e sob demanda, por exemplo. Porm o variado entretenimento disponibilizado pela Internet ainda est preso s pequenas telas dos computadores, enquanto as enormes telas de TV restringem-se a exibir contedo transmitido via broadcast e, poucas excees, transmisses unicast com o sistema pay-per-view (pague para ver).

A interatividade ainda uma questo a ser melhorada, uma vez que, de maneira geral, o trfego unidirecional, ou seja, apenas o provedor envia informaes no recebendo do espectador nenhum retorno. O fato de a rede IP das operadoras ser, por padro,

76 bidirecional, facilitar o crescimento da interatividade e o surgimento de novas aplicaes e servios. A transmisso de contedo vdeo ser eficiente por meio da aplicao de tcnicas de QoS associadas a protocolos como MPLS, DiffServ e RSVP. O comparativo dos protocolos da camada de transporte UDP e TCP demonstra o overhead do TCP e, por essa caracterstica e, tambm por no permitir trfego multicast sugere-se a utilizao do protocolo UDP. Os parmetros de QoS podem ser obtidos com a utilizao de uma combinao de protocolos, melhor engenharia de trfego e melhorias nas redes de acesso. A aposta na convergncia all-IP, j que cada vez mais a indstria eletrnica investe em equipamentos com diversas funcionalidades, que permitem o acesso Internet e, consequentemente, ao IPTV.

77

9.3 SUGESTES PARA TRABALHOS FUTUROS SOBRE O TEMA IPTV

As chances de ter todos os servios indisponveis ao mesmo tempo, com o triple play, passam a ser muito maior; uma vez que todos os servios so providos pela mesma operadora e, possivelmente, por um nico meio de acesso. A exigncia por disponibilidade do sistema aumenta. Para minimiz-las, aes preventivas e corretivas devem ser eficientes. Com um ncleo de rede full-mesh adotando protocolos de roteamento IP ou MPLS, rotas alternativas poderiam ser automaticamente utilizadas. A sugesto no sentido de realizar novos estudos com solues de redundncia via Wi-Fi, Wi-MAX ou LTE, que poderia ser adotada de maneira simples : colocar o transmissor no armrio ptico da operadora e receptor na sala de equipamentos do condomnio, edifcio ou cliente corporativo, para atendimento de, ao menos, parte dos servios contratados.

O tempo demandado para que uma troca de canal seja concluda (canal zapping), tambm motiva estudos mais aprofundados. Segundo Tara em (UNEN, 2006), um valor considervel aceitvel algo em torno de 1 segundo e, para que o consumidor a considere instantnea e no deve superar 200 ms.

O fato de ter mais de um servio atendidos por uma nica conexo banda larga, faz-se necessrio o estabelecimento de regras que, de alguma forma, realizem o balanceamento de trfego de forma a no permitir que o uso excessivo de um servio venha a impedir o funcionamento de outros. Uma forma de se fazer isso poderia ser atravs do estabelecimento de VLANS especficas para cada servio e sub-interfaces nos roteadores de borda com regras de controle de banda nessas sub-interfaces.

Muito se tm a discutir sobre o tema IPTV e convergncias de maneira geral. Assuntos interessantes para trabalhos futuros.

78 REFERNCIAS

(1) 57, ago. 2009.

BAKER, Joe; CAGENIUS, Torbjrn; HATAS, Martin (Org.).

Redes de fibra ptica. Rti - Redes, Telecom e Instalaes, So Paulo, n. 111, p.48-

(2) CARBONARO, Karine Barbosa. Um estudo sobre a Qualidade de Vdeo em Redes Multicast com Servios Diferenciados Baseados na Tcnica DSMCast. 2004. 137 f. Monografia (Mestrado em Engenharia Eltrica) Faculdade de Engenharia Eltrica, Universidade Federal de Uberlndia (UFU), Uberlndia, 2004. (3) 2002. 380 p. (4) FILIPPETTI, Marco Aurlio. CCNA 4.1 (Exame 640-802): Guia CHOWDHURY, Dhiman D. Projetos Avanados de Redes IP:

Roteamento, Qualidade de Servio e Voz sobre IP. Rio de Janeiro: Editora Campus,

Completo de Estudo. Florianpolis: Editora Visual Books, 2008. 478 p. (5) KUROSE, James F.; ROSS, Keith W.. Redes de

computadores e a Internet: Uma abordagem top-down. So Paulo: Editora Pearson Addison Wesley, 2006. 634 p. (6) OSBORNE, Eric; SIMHA, Ajay. Engenharia de trfego com

MPLS: Projeto, configurao e gerenciamento do MPLS TE para otimizao do desempenho de rede. Rio de Janeiro: Editora Campus, 2002. 614 p. (7) SILVA NETO, Edson Moreira. ESPECIFICAO DE UMA

REDE MPLS FIM-A-FIM. 2006. 189 f. Tese (Doutorado em Cincias em Engenharia Eltrica), Universidade Federal do Rio Grande do Norte, Natal, 2006. (8) SOARES, Lilian C.; FREIRE, Victor A.. Redes Convergentes:

Estratgia para transmisso de voz sobre Frame Relay, ATM e IP. Rio de Janeiro: Editora Alta Books, 2002. 634 p. (9) TELECO (Comp.). TUTORIAL IPTV. Disponvel em:

<http://www.teleco.com.br/tutoriais/tutorialiptv/pagina_1.asp>. Acessado em: 27 de

79 novembro 2010. (10) UNEN, Tara Van. Validating IPTV service quality under realistic triple play network conditions (White Paper). Palo Alto - Canad, 2006. Disponvel em: http://www.compactpci-systems.com/pdfs/Agilent.Sep06.pdf. Acessado em: 03 de Outubro de 2010. (11) WIKIPEDIA (Comp.). DTH. Disponvel em:

<http://pt.wikipedia.org/wiki/DTH>. Acessado em: 04 de novembro 2010.

80 APNDICE A TESTES EM MPLS COM JPERF

Como forma de avaliar a eficcia da utilizao do roteamento baseado em labels do MPLS e do modelo de servios diferenciados DiffServ, foram realizados alguns experimentos onde observou-se a drstica reduo do jitter e melhora significativa na latncia do sistema. Abaixo seguem algumas imagens dos testes realizados.

O teste foi realizado com a ferramenta JPerf entre sites da empresa Mundial S/A localizados em So Paulo e Porto Alegre.

81

82 APNDICE B WINDOWS MEDIA ENCODER

Uma maneira simples de implementer um servidor de IPTV atravs da utilizao do software Windows Media Encoder. Um exemplo de experincia que, se realizada em ambiente controlado, pode trazer informaes importantes quanto eficcia do servio em determinada rede , utilizando um receptor de TV Digital USB instalado em um servidor, disponibilizar o contedo recebido para acesso remoto. Durante o desenvolvimento desse trabalho, realizei um pequeno experimento implementando um servidor IPTV utilizando um receptor de TV Digital USB. Utilizei o Dynamic DNS para acessar remotamente e o resultado foi, a meu ver, satisfatrio uma vez que o delay foi inferior 60 segundos e a imagem estava muito boa, mesmo no contando com placa de vdeo e processador robustos. As figuras que seguem mostram passo a passo a instalao do Windows Media Encoder:

83

84