Você está na página 1de 7

Soluo de QoS Para Servios Triple-Play

Lazie Dimer Scheffer, Lucas Coitinho


Centro Universitrio La Salle (UNILASALLE)
Av. Victor Barreto, 2288 - Canoas - RS - Brasil
laziedimer@hotmail.com, lucascoitinho@gmail.com

Abstract:This article aims to demonstrate the use of Triple Play and mechanisms used to
provide Quality of Service (QoS) from the ISP to the end user. To generate QoS is
necessary use more than one mechanism to delivery QoS to end-user.
Resumo: Este artigo tem como objetivo demonstrar o uso do triple play e dos mecanismos
utilizados para fornecer Qualidade de Servio (QoS) da operadora para o usurio final.
Nele possvel notar a necessidade de uso de mais de um mecanismo no caminho
operadora-usurio para que no fim servio de tripleplay seja entregue com qualidade.

1. Introduo
Atualmente grande parte das residncias no Brasil e no mundo possuem algum dispositivo com
acesso internet, sendo a maioria computadores. Alm disto, nos ltimos anos aumentou
consideravelmente o nmero de pessoas com acesso a internet e com TV cabo em suas casas,
diante deste aumento brusco surge a tecnologia Triple-Play que busca unir servios de dados, voz
e multimdia em um nico canal. Juntamente com os servios de Triple-Play nasce a necessidade
de entregar um servio de qualidade para o usurio final.

2. Servio Triple Play


O Triple-Play uma tecnologia muito recente, que busca unificar servios que at ento eram
totalmente independentes para um exclusivo canal de comunicao, so estes servios voz, dados
e multimdia. Com o servio de Triple-Play a partir do servio de banda larga so entregues
telefonia fixa, internet e vdeo, esta ltima normalmente sendo a TV a cabo.
Hoje no Rio Grande do Sul, temos a GVT que fornece atravs do sinal de ADSL
(Asymmetric Digital Subscriber Line) os servios de TV a cabo, internet banda larga e telefonia,
alm da NET que fornece os mesmos servios atravs de cabo.

3. Caractersticas do Trfego e Requisitos de QoS


Considerando as mtricas a seguir, as aplicaes de servio Triple Play podem ser entendidas a
partir da anlise de seus requisitos e suas caractersticas:
Throughput: referente a banda/vazo da rede, e leva em considerao o consumo de banda
da aplicao (utilizao mdia e valor de pico). Valor pode variar de acordo com ao do
usurio, ou em funo dos codificadores de camadas superiores utilizados. O valor de pico
utilizado nos clculos de QoS.

Jitter: a variao do atraso na rede. Essa variao de retardo normalmente causada pela
concorrncia de trfego em um mesmo canal de dados, e que pode comprometer o
funcionamento adequado de uma aplicao.
Perda de Pacote: A perda de pacotes tolerada at certo nvel, pois se houver uma baixa
taxa de perdas no compromete o sistema.
Delay: mtrica que mede o retardo. Leva em considerao o tempo mximo de entrega, da
origem at o destino, suportada por uma determinada aplicao sem o comprometimento
do seu funcionamento. O retardo de enfileiramento no destino e na origem deve ser levado
em considerao, assim como o retardo de codificao e decodificao, e o retardo de
propagao na rede. A imagem da figura 1 ilustra esse delay na rede.

Figura 1 - Diferentes tipos de atrasos na rede.

Uma boa compreenso do comportamento das aplicaes de Triple-Play essencial para a


modelagem de QoS na rede, quando variamos uma ou mais mtricas.
3.1 Trfego de Voz
Para uma excelente QoE (Quality of Experience) so necessrio alguns requisitos bsicos no
servio de telefonia: vazo, baixo atraso, evitar jitter, e reduzir perda de pacotes.
A vazo varia de acordo com o codec utilizado. Utilizando G711 e a pilha TCP/IP (RTP,
UDP, IP, Ethernet), a vazo de 90 Kbps aproximadamente.
O atraso fim a fim, da origem at o destino, no deve ultrapassar a 150 ms para o contedo
de voz (ITU-T G114). A exceo a sinalizao da chamada telefnica, podendo ultrapassar a
uma taxa acima desse valor.
O jitter pode ser tolerado, desde que no ultrapasse a taxa de 150 ms, somado ao clculo
de delay.
A perda de pacotes no pode ultrapassar o valor acima de 0,25% para implementaes
prticas, quando se utiliza G711.

3.2 Trfego de Vdeo


A vazo varia de acordo com o codificador utilizado. Utilizando o codec MPEG-2 so necessrios
aproximadamente 4 Mbps por canal SDTV e com MPEG-4 2 Mbps em cada canal SDTV.
O atraso entre origem e destino pode ficar entre 3 a 5 segundos. No deve comprometer a
interao do usurio com a aplicao.
A variao do atraso deve ser de at 30 ms, em detrimento do sincronismo entre udio e
vdeo apresentados na TV.
Em relao a perda de pacotes, a taxa no deve ser superior a 0,5% para que o usurio tenha
uma QoE satisfatria.
3.3 Trfego de Dados.
As aplicaes de compartilhamento e transferncia de arquivos (FTP e P2P) tendem a ocupar toda
a banda disponvel, com o valor mdio de ocupao muito prximo ao valor de pico. Por outro
lado, a navegao web, usando protocolo HTTP, tendem apenas a ocupar a banda em momentos
pontuais, somente durante a interao do usurio com pginas, tendo um alto valor de pico, mas
um baixo valor mdio de utilizao.
O atraso no costuma ser um problema, exceto com aplicao de jogos online. Este quesito
no tende a ser crtico.
A variao do atraso (jitter), assim como perda de pacotes, no h um requisito
significativo e costuma ser tolervel em trfego de dados, em comparao a trfego de voz e vdeo.
No h um valor exato para a variao do atraso e perda de pacotes para aplicaes de jogos.

4. O QoS
4.1 Classificao do Trfego na Origem
A partir de uma classificao inicial de cada pacote (pacote a pacote) possvel separarmos cada
um conforme sua aplicao e a partir disto, realizar um tratamento individualizado para cada
aplicao.
Normalmente essa classificao na origem do pacote baseada nos SAPs de origem e
destino como o IP (camada 3) ou endereo IP + Porta TCP ou UDP (camada 4). Algumas
implementaes ainda utilizam o MAC Address. Nestes casos, o QoS realizado de acordo com
o trfego, por exemplo os acessos nas portas tcp/80 e tcp/443 para youtube.com.br a princpio
seriam de streaming de vdeo e por isto teriam mais banda do que os acessos ao clicrbs.com.br na
porta tcp/80, pois este ltimo acesso seria apenas uma navegao em um site.
No caso das operadoras a classificao dos pacotes ocorre fullduplex, ou seja, em ambos
os sentidos da comunicao. Essa classificao facilitada devido a centralizao na operadora de
todos os servios, mas ao mesmo tempo, quando surgem aplicaes como servidores de

hospedagem de arquivos, p2p ou outras aplicaes remotas a classificao se torna difcil devido
a utilizao de portas no padronizadas, por exemplo.
Uma das alternativas criadas pelas operadoras para driblar o problema acima fornecer
uma espcie de portal que possibilita que o prprio usurio final classifique seu pacote conforme
desejar. Alm disto diferentes operadoras podem compartilhar suas classificaes o que ajudaria
bastante quando h necessidade de trafegar dados entre duas operadoras.
4.2 Utilizao da arquitetura DIffServ
Utilizando Diffserv, cada n realiza a classificao do pacote, para que ele receba um tratamento
diferenciado. No necessrio controle de admisso, sinalizao e nem reserva fim a fim.
Mecanismos bsicos do Diffserv:
Classificao: Classificao dos pacotes, j detalhada acima.
Marcao: Aps a classificao o trfego marcado de forma padronizada, facilitando a
identificao da classe nos demais elementos. Na arquitetura Diffserv no importa se a
marcao feita no cabealho de camada 2 (CoS - Ethernet ou EXP Bits - MPLS) ou no
cabealho de camada 3 (ToS IP), pois possvel o mapeamento no protocolo de camada
superior ou inferior baseada na marcao original.
Policiamento: Define o throughput para cada classe de servio.
Mecanismo de Filas: Responsvel por separar o trfego de cada classe em filas, priorizao
e manuteno do throughput entre as filas. Pacotes de maior prioridade so separados para
filas expressas.
Descarte: Responsvel pela poltica de descarte. Pacotes excedentes com maior prioridade
podem ser reclassificados como menor prioridade para que no sejam descartados.
Moldagem: Utilizado no final do processo, comprometido com a eficincia do uso do
enlace.

Figura 2 - Exemplo de uso de DiffServ.

A arquitetura Diffserv tem implementao considerada simples e transparente em relao


aos protocolos implementados na camada de rede.
4.3 Mapeamento genrico de ToS (DSCP) para MPLS EXP
Nos protocolos de camada 2, h 7 classes de servio disponveis, alm da classe Sem prioridade
/ Sem classificao, devem ser reservadas duas classes para gerenciamento.
Sem classificao de gerenciamento, nos momentos de sobrecarga do enlace, a taxa de
perda pode se tornar intolervel, podendo at gerar falha de enlace e tambm nos transmissores.
Alm de atraso no recebimento de tabelas de roteamento o que alteraria a topologia conhecida da
rede. O recomendvel que alm de classificaes de gerenciamento, estes pacotes tambm
tenham filas especficas.
Outro problema que podem ocorrer uso da mesma fila para TCP e UDP. Por exemplo,
uma videoconferncia utiliza UDP para enviar/receber dados de voz e vdeo e TCP para controle
de conexo. No caso de criarmos uma classe/fila para ambos os pacotes ao TCP baixar o trfego
pois apenas para controle, o UDP assumiria cada vez mais banda, tornando esse controle de
conexo cada vez mais raro. Neste caso aconselhado termos Classes TCP e UDP separadas.
Tabela 1. Exemplo de Classificao

4.4 Soluo QoS para servios Triple Play convergentes:


Especialistas afirmam que a soluo para servios triple play um link de 10Mbps, dois canais de
telefonia (codificador G.711), e dois canais de TV (SDTV com MPEG-4).
utilizado como base a arquitetura Diffserv, j explicada acima. Com isto temos o
compartilhamento de banda e reutilizao de banda no utilizada por outra classe otimizando o

uso de banda total. Desta forma cada classe tem seu valor de banda reservada e tambm o seu valor
de banda de pico.
As aplicaes que utilizam uma largura maior de banda como Voz sobre IP e IPTV, por
exemplo, alm das classes de gerenciamento tem sempre a banda de pico reservada. Para as demais
aplicaes permitido inclusive que a banda pico seja equivalente a banda total do enlace.
Alm da reserva de banda, delay, jitter e perda de pacotes devem ser sempre auditados pelo
sistema OAM (Operation and Maintenance na camada de operao) da origem ao destino.

5. Concluso:
Quando falamos de QoS em servios Triple-Play, tudo depende da aplicao que queremos inserir
este QoS, por isso devemos ter um entendimento primrio desta aplicao, bem como a forma de
como ser prestado este servio.
Todo o pacote pertencente ao servio Triple-Play passa por uma classificao inicial, onde
definido uma prioridade visando assim o melhor aproveitamento da rede. Isto essencial para
que um servio no afete o outro durante a transmisso simultnea no mesmo canal de dados.
Conclumos que para as aplicaes em Triple-Play funcionarem adequadamente,
necessrio que sejam adotadas boas prticas de QoS nos trs diferentes tipos de trfego, podendo
assim o usurio ter uma excelente experincia em ambos os servios contratados.

6. Referncias:
BARROSO,
Carlos Eduado Terra. Soluo de QoS para Servios Triple-Play.
<http://www.midiacom.uff.br/~debora/fsmm/trab-2007-2/qostripleplay.pdf>. Acesso em: 03/09/2014.
ALANEN, Olli. QoS for Triple Play Services in Heterogeneous Network
<https://jyx.jyu.fi/dspace/bitstream/handle/123456789/13257/9789513930448.pdf?sequence=1>. Acesso
em: 03/09/2014.
ZOTOS, Nikolaos. PALLIS, Evangelos. KOURTIS Anastasios. Performance Evaluation of Triple Play
Services Delivery with E2E QoS Provisioning. <http://www.hindawi.com/journals/ijdmb/2010/836501/>.
Acesso em: 04/09/2014.
ADAMS,
Bruce.
End
to
End
QoS
and
Triple
Play.
<https://www.itu.int/ITUT/worksem/qos/200606/presentations/s8p4-adams.pdf>. Acesso em: 05/09/2014.
RODRIGUES, Sandy Carmo Relva. ENCAMINHAMENTO PTIMO DO TRFEGO EM REDES
TRIPLE
PLAY
<http://repositorio.uma.pt/bitstream/10400.13/92/1/MestradoSandyRodrigues.pdf>.
Acesso em: 07/09/2014.
GUERREIRO, Pedro. VIEIRA Hlder. BRAVO, Joo. O Triple Play Rumo Conquista do Mercado
<http://www.img.lx.it.pt/~fp/cav/ano2006_2007/MERC/Trab_2/cav/documentos/artigo_tripleplay.pdf>.
Acesso em: 07/09/2014.
WANDERLEY, Bruno Lima. ECHENIQUE, William David Mercado. VoIP
<http://www.teleco.com.br/tutoriais/tutorialvoipqos/pagina_1.asp>. Acessado em: 07/09/2014.

QoS

Você também pode gostar