Solução de QoS para Serviços Triple-Play

Carlos Eduardo Terra Barroso

Departamento de Telecomunicações – Universidade Federal Fluminense (UFF)

Rua Passo da Pátria, 156 – São Domingos – CEP 24.210-240 – Rio de Janeiro – RJ –
Brasil
carlos_terra@midiacom.uff.br

Resumo. Este artigo apresenta uma solução de QoS para serviços triple-play, sendo
descrito o modelo de rede de acesso e na seqüência apresentados os requisitos de
Qualidade de Serviço para as aplicações que compõem o serviço Triple-Play (vídeo,
voz e dados), os requisitos das operadoras para operação e manutenção da rede, a
visão do usuário sobre a prestação do serviço e a solução de QoS para a prestação do
serviço.

1. Introdução

A demanda por serviços de telefonia, TV por assinatura e acesso a Internet

exige, atualmente, dos provedores de serviços de telecomunicações a busca por soluções
de rede que permitam a prestação de serviços Triple-Play.

Redes de acesso específicas para cada um dos serviços (telefonia. TV e Internet)

permitem o tratame nto individual dos requisitos de Qualidade de Serviço (QoS –
Quality of Service) das aplicações (voz, vídeo e dados) aumentando, todavia, a
quantidade de redes em operação e a complexidade para prestação de serviços com alto
valor agregado.

Este trabalho apresenta uma solução que permite a oferta de serviços multimídia
convergentes [1]. A solução é baseada na arquitetura NGN (Next Generation Networks),
com uma única rede de acesso para todos os serviços. A infra-estrutura da rede utiliza
um backbone IP/MPLS, com tratamento individual dos requisitos de QoS por aplicação
em toda a estrutura, compondo o serviço Triple-Play em rede convergente, ou Triple-
Play convergente, conforme mostrado na Figura 1.
 TV

Figura 1 – Arquitetura NGN

Inicialmente será descrito o modelo de rede de acesso, sendo na seqüência

apresentados os requisitos de Qualidade de Serviço para as aplicações que compõem o
serviço Triple-Play (vídeo, voz e dados), os requisitos das operadoras para operação e
manutenção da rede, a visão do usuário sobre a prestação do serviço e, finalmente, a
solução de QoS para a prestação do serviço.

2 . Modelagem da Rede de Acesso

As redes de acesso compõem a estrutura responsável pelo transporte e entrega

dos serviços, do ponto de concentração da prestadora até o usuário final.

A estrutura de rede escolhida neste trabalho para a abordagem direta ou

agregação de acessos é a de Redes Ethernet Metropolitanas (MEN – Metro Ethernet
Networks), proposta pelo MEF (Metro Ethernet Forum)1 com a complementação de
uma rede de serviços NGN baseada e núcleo IP/MPLS.

As MENs possibilitam a prestação de serviços com alta velocidade e

ganularidade de acesso (10, 100, 1000, 10000 Mbps), alto grau de compartilhamento de
recursos físicos e lógicos, aderência a diversos modelos de QoS, ferramentas de
Operação e Manutenção (OAM) de fácil integração com as redes de camadas superiores
e, principalmente, possuem o framework ideal para operação com tecnologias de acesso
complementares.

A Figura 2 descreve o framework (estrutura) genérico, proposto pelo MEF para

as Redes Ethernet Metropolitanas.

1
Consórcio internacional responsável pela consolidação de normas técnicas e certificação de
redes e serviços baseados em Ethernet
 Other L2/L2+
Services Networks Subscriber
(e.g., ATM, FR, IP)
Service UNI
Interworking
NNI
MEN
UNI
Metro Service Provider Z1
Ethernet Network External
Subscriber (MEN) NNI External
NNI
Service Provider X Ethernet
Wide Area Network MEN
Network (E-WAN )
Interworking Service Provider Z2
Service Provider Y
NNI
Other L1
Transport Networks UNI
(e.g., SONET, SDH, OTN)

Subscriber
Network
Interworking
NNI
MEN
Service Provider X

Figura 2 – Arquitetura MEN: Framework Genérico

O MEF define [2] que o único requisito para a abordagem ao usuário final, a
partir de um elemento da MEN é a capacidade de transporte transparente de quadros
ethernet.

Tecnologias de acesso como WIMAX, G-PON e DSL são aderentes ao modelo,

desde que atendam ao requisito de transporte transparente de quadros Ethernet. Os
estudos detalhados dos mecanismos utilizados por outras tecnologias de acesso para
transporte dos quadros Ethernet são temas para outros trabalhos.

A MEN tem o comprometimento de isolamento, multiplexação e manutenção da

Qualidade de Serviço dos diversos fluxos de aplicações que são transportados por sua
estrutura.

Os serviços fornecidos pela MEN podem variar de acordo com a aplicação e a

característica da aplicação utilizada.

Para aplicações com característica de transmissão unicast, como aplicações de

telefonia e a maior parte das aplicações na Internet são utilizados serviços do tipo ponto-
a-ponto, ilustrados na Figura 3, definidos pelo MEF como E- LINE [3], [4], com
multiplexação de interface.
 Figura 3 – Serviço E-LINE com multiplexação na interface central

As aplicações com características de difusão irrestrita (broadcast), como

aplicações de TV, ou com características de difusão restrita para grupos (multicast),
como aplicações de jogos e Vídeo sob Demanda (VoD), são serviços que usam de
transmissão ponto- multiponto (TV e VoD) ou multiponto- multiponto (jogos), ilustrados
na Figura 4 e definidos pelo MEF como E- LANs [3], [4].

Figura 4 – Serviço E-LAN

3. Caracterização do tráfego e requisitos de QoS

As aplicações do serviço Triple-Play podem ser entendidas a partir da análise de

suas características e de seus requisitos (de forma absoluta ou relativa) considerando as
seguintes métricas [5], [6]:
 ? Throughput (banda/vazão): Consumo de banda da aplicação (médio e
valor de pico). Pode variar em função dos codificadores de camadas
superiores utilizados ou em função da ação do usuário. Para cálculos de
QoS é utilizado o valor de pico.

? Delay (retardo): Tempo máximo de entrega (origem => destino)

suportado por uma determinada aplicação sem comprometimento do seu
funcionamento. Devem ser levados em consideração o retardo de
enfileiramento na origem e no destino, o retardo de
codificação/decodificação (se houver) e o retardo de propagação pela
rede, conforme ilustrado na Figura 5.

Figura 5 – Cálculo do retardo

? Jitter (variação de retardo): Variação no retardo, normalmente causada

pela concorrência entre tráfegos em um mesmo canal de saída, e que
pode comprometer o retardo máximo.

? Perda de Pacotes: Perda de pacotes é tolerável até comprometer a

aplicação.

Um bom entendimento do comportamento das aplicações quando variamos

uma ou mais métricas é essencial para a modelagem de QoS da rede.

A percepção do usuário em relação ao serviço prestado (QoE – Quality of

Experience) deve ser no mínimo igual à de um serviço prestado em uma rede de
acesso dedicada.

3.1 Voz (Telefonia)

Os requisitos para a prestação do serviço de telefonia são:

Vazão: Varia em função do codificador utilizado. Com G.711 e a pilha TCP/IP

(RTP, UDP, IP, Ethernet), a vazão é de aproximadamente 90Kbps por canal.
 Retardo: Fim-a-Fim (Origem => Destino) não deve ser superior a 150ms para a
mídia voz (ITU-T G.114). A sinalização da chamada telefônica pode variar acima desse
valor.

Jitter: É tolerado desde que, somado ao calculo do Delay, não ultrapasse o valor
máximo de 150ms.

Perda de Pacotes: Valor máximo para implementações práticas de 0,25%

(utilizando G.711)

A Figura 6 [5] traz um exemplo do impacto do retardo em uma aplicação de Voz

sobre IP (VoIP) com diferentes codificadores de voz. A parametrização para definição
do nível de satisfação do usuário é dada pela norma G.107 (R-value) do ITU-T. Um dos
motivos para o maior impacto do retardo nos codificadores de menor consumo de
banda, como o G.729A e o G.723.1 é a complexidade da decodificação em comparação
com codificadores mais simples, porém com maior consumo de banda, como o G.711.

Figura 6 – Impacto do retardo na qualidade da chamada

3.2 Vídeo (IPTV)

Vazão: Varia em função do codificador utilizado. Com MPEG-2

aproximadamente 4Mbps por canal SDTV e com MPEG-4 2Mbps por canal SDTV.

Retardo: Fim-a-Fim (Origem => Destino) entre 3 e 5 segundos, não deve

comprometer a interação do usuário com a aplicação.

Variação do retardo: Até 30 ms em função do sincronismo entre o vídeo e áudio

apresentados (TV).

Perda de Pacotes: Deve ser abaixo de 0,5%.

3.3 Vídeoconferência

Vazão: Varia em função do codificador utilizado. Aplicações utilizando H.264

variam de 64kbps até 8Mbps.

Retardo: Fim-a-Fim (Origem => Destino) não deve ser superior a 150ms, para
manutenção da interação entre usuários.

Variação do retardo: Até 30 ms em função do sincronismo entre o vídeo e áudio

apresentados (TV).

Perda de Pacotes: Deve ser abaixo de 0,5%.

3.4 Video Streaming (VoD)

Vazão: Varia em função do codificador utilizado na origem. Aplicações típicas

variam entre 384Kbps até 1,5Mbps.

Retardo: Fim-a-Fim (Origem => Destino) entre 4 e 5 segundos.

Variação do retardo: Sem requisitos significativos (tolerante).

Perda de Pacotes: Sem requisitos significativos (tolerante).

A aplicação de streaming de vídeo, por não ser uma aplicação de tempo real, é
mais tolerante a atrasos e perdas que as demais aplicações de vídeo.

3.5 Aplicações de Internet e Jogos

Vazão: Aplicações de transferência e compartilhamento de arquivos (FTP e P2P)

tendem a ocupar toda a banda disponível, com valor médio próximo ao valor de pico.
Jogos tendem a limitar a banda em perfis pré-definidos. Navegação na web, com uso do
protocolo HTTP e chats tendem a ocupar a banda disponíve l pontualmente (durante a
interação do usuário), tendo alto valor de pico e baixo valor médio.

Retardo: Com exceção da aplicação de jogos, não tende a ser crítico.

Variação do retardo: Sem requisitos significativos (tolerante).

Perda de Pacotes: Sem requisitos significativos (tolerante).

Não existem valores exatos para variação de retardo e perda de pacotes para
aplicações de jogos.
4. Visão da Operadora e do Cliente

Podemos analisar os serviços Triple-Play sob duas perspectivas, visão da

operadora e visão do cliente. As seções a seguir tratam de cada uma dessas vertentes.

4.1 Visão da Operadora

A visão da operadora em relação aos serviços Triple-Play deve ser analisada sob
o ponto de vista do framework de operação e a operação da camada de rede.

Aspectos de operação como segurança e disponibilidade envolvendo a camada

de rede não são detalhados neste trabalho. Da mesma forma, tomamos as redes
IP/MPLS e NGN como estruturas elementares para a prestação do serviço Triple-Play
convergente.

A seguir é proposto um framework para a operação da rede e são apresentadas

algumas funcionalidades de operação da MEN.

4.1.1 Framework de Operação

A prestação de serviços Triple-Play convergentes exige a unificação das

camadas de acesso, rede e serviços nas operadoras de telecomunicações.

Para possibilitar essa unificação/convergência entre as camadas, é necessária

uma camada intermediária de mediação, que seja capaz de coletar informações
específicas de cada rede, atuando diretamente em cada elemento, ou interagindo com o
EMS (Element Management System ) respectivo de cada rede, consolidando a visão
integrada do serviço.

A interação entre a camada de mediação (CIL – Camada de Inventário Lógico) e

os EMS é feita através de APIs (Aplication Programming Interfaces) usando linguagem
XML, por exemplo, onde a CIL é capaz de tratar as informações coletadas antes de
repassá- las ao Sistema de OAM (Operation and Maintenence) da Camada de Operação.

No modelo onde cada serviço corresponde a uma rede de acesso/serviço, mesmo

com o núcleo de rede compartilhado, a visão consolidada do serviço Triple-Play exigiria
ainda um segundo passo de integração, tornando bastante complexa, mas não inviável, a
sua implementação.

A unificação dessas três camadas permite o aprovisionamento e configuração do

serviço Triple-Play de forma centralizada, evitando que a ativação de um único usuário
exija ação individual em três diferentes plataformas de acesso, rede e serviço, em
comparação com o modelo de prestação de serviços em redes especializadas.
 A camada de provisionamento é capaz de interagir com a CIL permitindo a
visualização dos recursos disponíveis e a geração das rotinas de configuração dos
serviços nas camadas inferiores.

Em escala similar estão os ganhos na operação do serviço, uma vez que através
da camada de operação, é possível a visualização do serviço como um todo.

As funções de cada EMS, muitas vezes proprietárias, são mantidas nesse

modelo, uma vez que a CIL não altera a sua estrutura, apenas estabelece uma interação
padronizada no contexto da prestação do serviço, dessa forma a gerência de
rede/elemento é mantida.

O faturamento dos serviços é feito através da consolidação das informações do

sistema de provisionamento. Como o sistema de provisionamento tem a visão orientada
para o serviço e não para a rede, através das facilidades da camada de mediação, além
do faturamento automático após a ativação, qualquer interrupção ou falha no serviço
pode ser automaticamente relatada pelo sistema de OAM ao sistema de faturamento, o
que implica na possibilidade de relatório, também automático, do nível de prestação do
serviço ao usuário final.

A Figura 7 apresenta um diagrama em blocos do modelo com a camada de

mediação.

Figura 7 – Modelo de operação convergente

4.1.2 Operação da MEN

Originalmente os protocolos Ethernet/IEEE 802.3 não ofereciam maiores

funcionalidades para gerenciamento de status, verificação de conectividade e medição
de níveis de Qualidade de Serviço, conhecidas como funcionalidades de OAM
(Operation and Maintenence).

Com a sua crescente utilização em redes de acesso metropolitanas (MEN),

algumas funções de OAM foram adicionadas protocolo através de extensões
padronizadas, como a 802.3ah [7] (Ethernet in First Mile - Physical Link Layer OAM) e
802.1ag [8] (Connectivity Fault Management - Per Service OAM).

A principal preocupação das novas extensões é prover a MEN com, no mínimo,

as mesmas funcionalidades de OAM encontradas em outras redes de acesso, como as
redes SDH e Frame-Relay, por exemplo.

Cabe ao EFM (padrão IEEE 802.3ah) o gerenciamento de cada enlace Ethernet

componente da solução (não necessariamente restrito a MEN ou ao last-mile).

É necessária a definição de um elemento lógico ativo em umas das interfaces

Ethernet que compõe o enlace, que será responsável pelo envio das PDUs de controle
(OAMPDU – com endereço MAC de destino padronizado), para a outra interface do
enlace (passiva), que será responsável pela resposta das informações solicitadas no
campo de dados da OAMPDU. O formato da OAMPDU é mostrado na Figura 8. Essas
interfaces não precisam estar diretamente conectadas, sendo permitida a passagem das
OAMPDUs por elementos (switchs e bridges) que não implementam a facilidade.

Figura 8 – 802.3ah, formato da OAMPDU

Diversas informações são controladas, permitindo uma enorme variedade de

informações sobre o estado do enlace que podem ser usadas pelo EMS para ações de
manutenção na rede, como por exemplo, desabilitar determinada interface caso o
número de erros encontrados seja superior a um determinado patamar.

Cabe ao CFM (padrão IEEE 802.1ag) a função mais importante do

gerenciamento nas MENs, visto que ele é o responsável pela gerência do serviço
ethernet (E-LINE ou E-LAN) fim-a- fim.

Essa funcionalidade traz a possibilidade do conhecimento do caminho lógico

percorrido na MEN, sendo possível a medição dos níveis de QoS do serviço globais e
por aplicação, a definição de caminhos alternativos (backup) e a vizualição dos pontos
de falha para entrega adequada do serviço.

Diferentemente de outros protocolos as funcionalidades de OAM trazidas pelo

CFM são específicas da camada de enlace (ethernet).

Dessa forma é possível a realização, por exemplo, de testes de conectividade

(como o Echo Reply / Request), sem a necessidade de conhecimento do endereço IP,
sendo o pacote de controle endereçado a um endereço MAC.

Além de conectividade, verificações e medições de níveis de QoS nas diferentes

aplicações/serviços são realizadas através do envio de mensagens de controle nas
respectivas classes de serviço.

A Figura 9 ilustra de forma geral a aplicação do EFM e do CFM em uma rede de

acesso de maneira integrada.

Figura 9 – Uso em conjunto dos padrões 802.3ah e 802.1ag

Uma abordagem mais detalhada sobre o IEEE 802.3ah e o IEEE 802.1ag

compõe tema para um trabalho específico, dada a variedade de informações tratadas.

4.2 Visão do cliente

A visão do cliente em relação ao serviço prestado é em geral bastante subjetiva,

sendo fator determinante para a satisfação com o serviço prestado às experiências
anteriores do usuário com as aplicações (QoE).

Usuários tradicionais dos serviços de TV atuais (aberta e paga) e telefonia

tradicional (TDM) costumam possuir certa resistência às aplicações de streaming de
vídeo e comunicação de vo z via Internet, pois estão adaptados a um nível de serviço
mais elevado.

O entendimento das prioridades dos usuários para cada tipo de serviço e

aplicação é certamente um campo de estudo de total interesse das operadoras e dos
provedores de conteúdo e serviço.
 A agregação de valor e funcionalidades aos serviços prestados tem sido um dos
grandes objetivos das operadoras de telecomunicações.

Uma funcionalidade, ligada às camadas de rede e provisionamento, que se

propõe a atender uma das maiores necessidades dos usuários, o aumento da banda
disponível para uma determinada aplicação, é o auto-provisionamento.

Com o auto-provisionamento o usuário é capaz de solicitar a operadora o

aumento ou diminuição da largura de banda disponibilizada para o serviço ou até
mesmo uma aplicação de acordo com a sua necessidade momentânea.

Como exemplo, o usuário pode solicitar o aumento do seu circuito de acesso à

rede, enquanto utiliza serviços de um portal de vídeo sob demanda através de streaming
de vídeo ou transferência de arquivos. Como terá maior banda disponibilizada, pode
solicitar que o streaming ou o arquivo para transferência tenha qualidade HDTV ao
invés de SDTV.

Em outro exemplo, para a mesma situação, o usuário pode solicitar que a banda
até então alocada para o seu serviço de TV seja integralmente repassada para a
aplicação de VoD enquanto essa estiver ativa.

A solicitação pode ser feita em portal de auto-atendimento acessado utilizando-

se recursos da própria rede.

O modelo apresentado na Figura 7 permite a interação do usuário com o sistema

de provisionamento.

Cabe ao sistema de provisionamento verificar com as camadas inferiores a

disponibilidade de recursos, adicionais ou não, para o atendimento da solicitação,
realizando as alterações necessárias nos elementos da camada de rede caso os recursos
estejam disponíveis, e informar ao sistema de faturamento as alterações efetuadas no
serviço prestado ao usuário.

5. Solução de Qos para diferentes tecnologias de acesso

Conforme descrito na Seção 2, o único requisito para a abordagem ao usuário

final, a partir de um elemento da MEN é a capacidade de transporte transparente de
quadros Ethernet.

Dessa forma, a definição de um modelo a partir da entrega direta em Ethernet é

aderente a qualquer outra tecnologia de acesso complementar que atenda a esse
requisito.
5.1 Classificação do tráfego na origem

A partir da classificação do tráfego (pacote a pacote) conforme a aplicação é

possível o tratamento individualizado da aplicação e a utilização de métodos que
permitam a manutenção ou garantia dos seus requisitos, conforme apresentado na Seção
3.

A classificação do tráfego na origem pode ser realizada baseando-se nos SAPs

de origem e destino (mais comum) de camada 3 (endereço IP) ou camada 4 (endereço
IP + Porta TCP ou UDP). Implementações mais recentes permitem também a
classificação baseada em endereços de camada 2 (MAC, por exemplo).

Por exemplo, podemos classificar todo o tráfego TCP nas portas 20, 21 e 80
(FTP, Controle FTP e HTTP), para o endereço IP de destino 200.255.67.132 (Locadora
Virtual - Servidor de transferência de arquivos) como tráfego de aplicação de Vídeo sob
Demanda e todo tráfego HTTP (TCP porta 80) para a URL http://www.bb.com.br como
tráfego de aplicação crítica. Demais pacotes com portas TCP (portas 20, 21 e 80) e
endereços IP de destino diferentes podem ser classificados como aplicação default. O
tráfego de controle, como as OAMPDUs do IEEE 802.3ah, pode ser classificado como
de controle/gerência, baseando-se no endereço MAC de destino (padronizado).

A classificação do tráfego deve ser realizada nos dois sentidos da comunicação.

Para aplicações controladas pela operadora (telefonia, TV e VoD) a classificação
bidirecional é facilitada em função da centralização da operação. Aplicações com
pontos remotos fora de sua administração (servidores de compartilhamento de arquivo
P2P e servidores de jogos distribuídos, por exemplo) e que não utilizam portas
padronizadas ou previamente informadas dificultam a classificação do tráfego.

Uma alternativa para a resolução dessa questão pode ser a utilização do portal de
auto-provisionamento para que o usuário informe, pelo menos em um dos sentidos da
comunicação, qual classificação que esse tráfego deve receber. Nada impede, também,
acordo entre diferentes operadoras para padronização da classificação do tráfego entre
suas redes, o que pode ser bastante útil nas aplicações de jogos distribuídos e
videoconferência.

A classificação do tráfego é extremament e relacionada à expectativa individual

do usuário em relação a uma determinada aplicação. Aplicações com maior tempo de
mercado, como telefonia (TDM x VoIP) e TV (IPTV e TV aberta), têm melhor
definidos os seus requisitos e as respectivas metodologias de verificação do nível de
satisfação do usuário (como ilustrado na Figura 6).

Aplicações oriundas do ambiente web ou amplamente utilizadas após a

popularização da Internet, como serviços de e-mail, chat e transferências de arquivos,
não possuem metodologias de auditoria da satisfação dos usuários tão bem definidas
como as aplicações de telefonia e TV. A classificação empregada pelas prestadoras de
serviços, para essas aplicações, é normalmente genérica e essencialmente técnica,
podendo causar insatisfação em usuários mais exigentes. A adaptação da classificação
em função do critério do usuário é extremamente comum nas implementações práticas.
 Uma das opções da operadora é flexibilizar totalmente a classificação pelo
usuário, o que pode causar um colapso nos sistemas de provisionamento, ou definir
alguns perfis/pacotes que o usuário possa optar de acordo com os seus próprios
critérios. Do escopo da flexibilização e dos perfis/pacotes, devem ser retirados o tráfego
de controle e operação.

5.2 Utilizando a arquitetura Diffserv como base para a garantia de QoS

No modelo Diffserv [9], [10] cada nó realiza a classificação do tráfego para que
ele receba o tratamento diferenciado.

O Diffserv não necessita controle de admissão, sinalização de QoS e nem

reserva de banda fim-a- fim.

A arquitetura Diffserv contém 6 mecanismos básicos de QoS:

• Classificação: Detalhada na Seção 5.1

• Marcação: Após a primeira classificação o tráfego é marcado de forma

padronizada facilitando a identificação das classes nos demais elementos.

• Policiamento (Policing): Responsável pela definição do throughput reservado

para cada classe de serviço.

• Mecanismo de Filas (Queuing): Responsável pelo isolamento do tráfego de

cada classe de serviço em filas, priorização e manutenção do throughput entre as
filas. Pacotes de maior prioridade são alocados em filas expressas.

• Descarte (Dropping): Responsável pela política de descarte. Tráfego excedente

de maior prioridade pode ser reclassificado como não prioritário antes de ser
descartado.

• Moldagem (Shaping): Aplicado ao final de todo o processo, tem

comprometimento com a eficiência de uso do enlace. Tráfego de pico, acima do
valor permitido pode ser conforme no tempo, aproveitando-se de intervalos de baixa
utilização.

A Figura 10 traz uma ilustração em blocos funcionais da implementação da

arquitetura Diffserv.
 Figura 10 – Diffserv apresentado em blocos funcionais

Os protocolos de camada 2 e 3 têm campos definidos para as marcações. Estas

têm formatos definidos nas seguintes recomendações ou padrões:

? Camada 3 (ToS – IP): IP Precedence (RFC 791)

DSCP (RFC 2474)

? Camada 2 (CoS – Ethernet): IEEE 802.1p

? Camada 2 (EXP Bits – MPLS): MPLS EXP (RFC 2547)

Na arquitetura Diffserv não importa se a marcação é feita no cabeçalho de

camada 2 (CoS - Ethernet ou EXP Bits - MPLS) ou no cabeçalho de camada 3 (ToS –
IP), pois é possível o mapeamento no protocolo de camada superior ou inferior baseada
na marcação original.

A Tabela 1 traz um exemplo do mapeamento de classes entre os protocolos de

camada 2 e 3.

Camada 3 Camada 2
802.1p ou
IP Precedence PHB DSCP MPLS
Decimal
EXP
0 0 0 0

1 CS1 8 1

1 AF11 10 1

2 CS2 16 2

2 AF21 18 2

3 CS3 24 3
 3 AF31 26 3

4 CS4 32 4

4 AF41 34 4

5 EF 46 5

6 CS6 48 6

Tabela 1 – Mapeamento de marcações

A escolha da arquitetura de QoS Diffserv [11] como base para o modelo de QoS
para prestação de serviços Triple-Play convergentes se dá pela sua simplicidade de
implementação e pela sua transparência em relação aos protocolos implementados na
camada de rede apresentada na Figura 7.

A camada de mediação, apresentada na seção 4.1.1, é capaz de coletar todo o

mapeamento de QoS aplicado na camada de rede (inventário lógico) e as estatísticas de
utilização das classes de serviços internas às estruturas de rede.

A disponibilização das estatísticas de utilização do serviço como um todo, de

cada rede ou segmento, para o sistema de OAM provê para a operadora as informações
necessárias para o planejamento de capacidade do sistema.

5.3 Mapeamento genérico de ToS (DSCP) para MPLS EXP Bits e 802.1p

A Tabela 2 traz um exemplo do mapeamento entre marcações, dadas as

respectivas classes de serviço.

Camada 3 Camada 2
Classe de Serviço 802.1q ou
PHB / DSCP MPLS
EXP
Sem Prioridade / Sem
0 0 0
Classificação
Baixa Prioridade CS1 8 1

Trafego Volume AF11 10 1

Gerência de Enlace CS7 16 7

Cliente-Servidor AF21 18 2

Sinalização CS3 24 3

Missão Critica AF31 26 3

Vídeo
CS4 32 4
Streaming/VoD
 IPTV AF41 34 4

Telefonia EF 46 5

Gerência de Rede CS6 48 6

Tabela 2 – Mapeamento classes de serviço

Das 7 classes de serviço possíveis nos protocolos de camada 2, além da classe

Sem Prioridade / Sem Classificação, devem ser reservadas ao menos 2 níveis para o
tráfego de gerenciamento.

Caso o protocolo de gerenciamento do enlace seja classificado como sem

prioridade ocorre que, nos momentos de sobrecarga de informações no enlace, a taxa de
perda dos pacotes de controle pode chegar a um nível acima do tolerado provocando a
interpretação nos receptores de falha no enlace e conseqüente interrupção dos
transmissores.

De maneira semelhante, tabelas de roteamento não recebidas dentro do tempo

limite esperado, podem provocar no receptor a interpretação de retirada de elementos da
tabela de encaminhamento, alterando a topologia conhecida da rede.

Dessa forma, torna-se recomendável que o tráfego de gerenciamento do enlace e

o tráfego de gerência de rede recebam classificações e conseqüentemente ocupem filas
específicas.

Aplicações de rede como videoconferência sobre IP normalmente realizam a

transmissão das mídias de tempo real (vídeo e áudio) utilizando pacotes UDP com o
tráfego de controle da conexão lógica utilizando TCP.

Se os protocolos TCP e UDP utilizarem uma mesma classe de serviço, nos

momentos de congestionamento da classe por alto interesse de tráfego, por exemplo, a
ação do TCP ao longo do tempo será a diminuição da taxa de transmissão, enquanto o
UDP manterá a sua taxa de transmissão original. Assim, cada vez que o TCP diminui
sua taxa de transmissão a banda disponibilizada é automaticamente ocupada pela
aplicação baseada em UDP, provocando um colapso na aplicação de controle baseada
no transporte via TCP, que tem seu tempo de vida ultrapassado.

A utilização de uma classe de serviço específica ou compartilhada com

aplicações baseadas em TCP, para o transporte dos tráfegos de sinalização das
aplicações que tenham essa característica torna-se recomendável.

5.4 Solução de QoS para serviços Triple-Play convergentes

A solução de QoS para serviços Triple-Play convergentes pode ser resumido

através da Tabela 3, levando-se em consideração uma banda disponível para cada
usuário de 10Mbps, dois canais de telefonia, com codificador G.711 e dois canais de TV
SDTV com MPEG-4.

Camada 3 Camada 2
Banda Banda
Classe de Serviço Reservada 802.1q ou Reservada
PHB (Mbps) MPLS (Mbps)
EXP
Internet 0 2,5 0 2,5

Jogos AF11 1,5 1 1,5

Gerência de Enlace CS2 0,11 2

Portal de Auto- 0,21
AF21 0,1 2
Provisionamento
Sinalização
CS3 0,1 3 0,1
(Telefonia e IPTV)
Vídeo Streaming /
CS4 1,4 4
VoD
5,4
TV (IPTV) AF41 4 4

Telefonia EF 0,18 5 0,18

Gerência de Rede CS6 0,11 6 0,11

Banda Total (Mbps) 10 10

Tabela 3 – Solução de QoS para serviços Triple-Play convergentes

A arquitetura Diffserv, usada como base para esse modelo, trabalha com os
conceitos de compartilhamento de banda, permitindo que fatias de banda não utilizadas
por uma determinada classe de serviço sejam realocadas para outras classes, otimizando
o uso da banda total disponível.

Para viabilizar a realocação dinâmica de banda é necessário que cada classe de

serviço possua, além do seu valor de banda reservada, um valor de banda de pico.

Aplicações cujas características e requisitos, conforme apresentados na Seção 3,

são restritos, como para Voz sobre IP e IPTV, além do tráfego das classes de
gerenciamento de rede e enlace, os valores de banda reservada serão sempre iguais aos
valores de banda de pico. Para as demais aplicações, como nem sempre as
características e requisitos são conhecidos, é permitido que a banda de pico seja
correspondente a banda total do enlace.

A classe de serviço reservada para a tráfego com o portal de Auto-

Provisionamento não necessita de banda de pico com valor acima da banda reservada,
uma vez que a taxa proposta é suficiente para a interação do usuário com o portal.

A Tabela 4 traz os valores de banda reservada e de pico tendo como base as

classes de serviços da Tabela 3.
 Banda Banda de
Classe de Serviço Reservada Pico
(Mbps) (Mbps)

Internet 2,5 10

Jogos 1,5 10

Gerência de Enlace 0,11 0,11

Portal de Auto-
0,1 0,1
Provisionamento
Sinalização
0,1 0,1
(Telefonia e IPTV)
Vídeo Streaming /
1,4 10
VoD
TV (IPTV) 4 4

Telefonia 0,18 0,18

Gerência de Rede 0,11 0,11

Banda Total (Mbps) 10

Tabela 4 – Bandas reservada e de pico, por classe de serviço

Além dos valores de reserva de banda os requisitos delay, jitter e perda de

pacotes por pacotes devem ser permanentemente auditados pelo sistema de OAM (seção
4.1.1), sempre do ponto de origem da aplicação ao ponto de destino, tendo como base a
Tabela 5.

Perda de
Delay Jitter
Requisito Pacotes
(ms) (ms)
(%)

Internet 5000 500 1

Jogos 4000 até 400 1

Gerência de Enlace 150 150 0,5

Portal de Auto-
500 500 1
Provisionamento
Sinalização (Telefonia
150 30 0,25
e IPTV)
Vídeo Streaming /
3000 até 300 1
VoD
TV (IPTV) 3000 30 0,5

Telefonia 150 até 150 0,25

Gerencia de Rede 150 150 0,5

Tabela 5 – Requisitos de Delay, Jitter e Perda de Pacotes

6. Conclusão

Uma proposta de solução de QoS para serviços Triple-Play exige o

entendimento primário das suas aplicações, de suas formas de prestação e as
arquiteturas de rede possíveis.

A busca pela solução de rede convergente remete a tentativa de diminuição do

número de redes em operação, o que provoca a diminuição de custos pela operadora e
principalmente a capacidade de operação unificada do sistema.

A operação unificada, por sua vez, traz o desafio da integração entre diferentes
EMS e do compartilhamento de um único meio de acesso para entrega dos serviços
exigindo o entendimento dos requisitos específicos de cada aplicação e consumindo
recursos financeiros para desenvolvimento de sistemas.

Uma vez desenvolvidos os sistemas, entretanto, a operadora prestadora do

serviço Triple-Play passa a possuir uma plataforma que lhe permitirá a operação
simplificada do sistema, a auditoria on-line de todos os recursos físicos e lógicos
disponíveis ou em uso, a rápida adequação às necessidades do usuário, a introdução
simplificada de outras tecnologias de acesso e a implementação de modelos de QoS
específicos para cada segmento da sua rede.
7. Referências

[1] Triple Play - The future of media convergence. Disponível em: < http://www.praxis-
profiline.de/bestellung-e.htm>. Acesso em 14 de nov. 2007.

[2] Metro Ethernet Network Architecture Framework Part 1 (MEF4): Generic

Framework. Disponível em: < http://metroethernetforum.org/techspec.htm>. Acesso em
12 de nov. 2007

[3] Metro Ethernet Services Definitions Phase I (MEF6). Disponível em: <
http://metroethernetforum.org/techspec.htm>. Acesso em 12 de nov. 2007

[4] Ethernet Services Attributes Phase 2 (MEF 10.1). Disponível em: <
http://metroethernetforum.org/techspec.htm>. Acesso em 12 de nov. 2007

[5] BUILDING the carrier - class IP next- generation network. Disponível em:
<http://www.cisco.com/en/US/partner/netsol/ns548/networking_solutions_white_paper
0900aecd802e2a52.shtml>. Acesso em 17 de ago. 2006.

[6] Service Provider Quality of Service Design Guide. Disponível em

http://www.cisco.com/en/US/partner/netsol/ns590/networking_solutions_white_paper0
9186a00801b1c5a.shtml>. Acesso em 10 de out. 2007

[7] IEEE 802.3ah-2004, “Ethernet in the First Mile Task Force”

[8] IEEE 802.1ag Draft8, “Connectivity Fault Management”

[9] [DiffServ_2474] K.Nichols, S. Blake, F. Baker, D. Black, Definition of the

Differentiated Services Field (DS Fiel) in the IPv4 and IPv6 Headers, RFC 2474, dez.
1998.

[10] [DiffServ_2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss,

An Architetcture for Differentiated Services, RFC 2475, dez. 1998.

[11] SRIVINAS, Vegesna. IP Quality of Service. S.l: Macmillan Technical Pub, 2001,
343 p.