UNIVERSIDADE DE BRASLIA

FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELTRICA

USO DE TDMoIP COMO ALTERNATIVA

PARA BROADCASTING EM APLICAES IPTV

WILSON DUTRA SAMPAIO

ORIENTADOR: DOUTOR PAULO HENRIQUE PORTELA DE

CARVALHO

DISSERTAO DE MESTRADO EM ENGENHARIA ELTRICA

PUBLICAO PPGENE.DM 283 A/06

BRASLIA/DF: OUTUBRO /2006

UNIVERSIDADE DE BRASLIA
FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELTRICA

USO DE TDMoIP COMO ALTERNATIVA

PARA BROADCASTING EM APLICAES IPTV
WILSON DUTRA SAMPAIO
DISSERTAO
SUBMETIDA
AO
DEPARTAMENTO
DE
ENGENHARIA ELTRICA DA FACULDADE DE TECNOLOGIA DA
UNIVERSIDADE DE BRASLIA COMO PARTE DOS REQUISITOS
NECESSRIOS PARA A OBTENO DO GRAU DE MESTRE.
APROVADA POR:
____________________________________________________________
Profo Paulo Henrique Portela de Carvalho, Docteur, ENE/UnB
(Orientador)
____________________________________________________________
Rodrigo Pinto Lemos, Doutor, EEE, UFG
(Examinador Externo)
____________________________________________________________
Paulo Roberto de Lira Gondim, Doutor, ENE/UnB
(Examinador Interno)

BRASLIA, 30 DE OUTUBRO 2006.

ii

FICHA CATALOGRFICA
SAMPAIO, WILSON DUTRA
Uso de TDMoIP como alternativa para broadcasting em aplicaes IPTV [Distrito
Federal] 2006.
xxii, 253p.,297 mm (ENE/FT/UnB, Mestre, Engenharia Eltrica, 2006).
Dissertao de Mestrado Universidade de Braslia. Faculdade de Tecnologia.
Departamento de Engenharia Eltrica.
1. TDM sobre IP
2. Emulao de Circuitos
3. Convergncia de Redes
4. Transmisso Digital de Vdeo
5. IPTV
6. Vdeo on-demand
I. ENE/FT/UnB
II. Ttulo (srie)

REFERNCIA BIBLIOGRFICA
SAMPAIO, WILSON DUTRA (2006). Uso de TDMoIP como alternativa para
broadcasting em aplicaes IPTV, Dissertao de Mestrado. Publicao PPGENE.DM-283
A/06. Departamento de Engenharia Eltrica, Universidade de Braslia, Braslia, DF, 190 p.

CESSO DE DIREITOS
AUTOR: Wilson Dutra Sampaio
TTULO: Uso de TDMoIP como alternativa para broadcasting em aplicaes IPTV
GRAU: Mestre

ANO: 2006

concedida Universidade de Braslia permisso para reproduzir cpias desta dissertao

de mestrado e para emprestar ou vender tais cpias somente para propsitos acadmicos e
cientficos. O autor reserva outros direitos de publicao e nenhuma parte dessa dissertao
de mestrado pode ser reproduzida sem autorizao por escrito do autor.
___________________________________
Wilson Dutra Sampaio
QRSW4 BL A-3 - Apto 306, Setor Sudoeste
70.675-403 Braslia DF - Brasil

iii

AGRADECIMENTOS

Brasil Telecom e aos meus gerentes e diretores ao longo dos ltimos trs anos, pelo
apoio e flexibilizao no horrio de trabalho, que me proporcionaram essa grande
oportunidade de enriquecimento pessoal e profissional.
Ao meu orientador Paulo Henrique Portela de Carvalho, pelo apoio durante a execuo do
trabalho e pela grande pacincia, aceitando que o trabalho fosse conduzido dentro do ritmo
possvel em funo das atividades da Brasil Telecom.
Aos colegas do LabCom Roque, Georges, Priscila, Martin e Eduardo, pela ajuda com os
equipamentos,

configurao

das

redes

e utilizao das instalaes, alm do

companheirismo e da convivncia diria.

Aos graduandos Diego, Fabrcio, Mrcio, Srgio e Breno, pelo apoio na configurao dos
roteadores, desenvolvimento das classes e rotinas em Java e utilizao do Analisador.
RAD do Brasil, na pessoa do Sr. Oscar Caldern Prager, pela cesso dos equipamentos
IP-mux para demonstrao, bem como acesso documentao associada.

iv

Para Julhiana e Viviani, cada uma na sua poca, que se viram

privadas de mim por tanto tempo e de tantas formas
durante a realizao desse trabalho.

RESUMO

USO DE TDMoIP COMO ALTERNATIVA PARA BROADCASTING EM

APLICAES IPTV
Autor: Wilson Dutra Sampaio
Orientador: Paulo Henrique Portela de Carvalho
Programa de Ps-graduao em Engenharia Eltrica
Braslia, outubro de 2006

O presente trabalho estuda as tecnologias de emulao de circuitos TDM sobre redes de

pacotes, desenvolvidas como alternativa s aplicaes VoIP para preservar os
investimentos nas redes atuais. Com base nesse estudo, proposta a utilizao de circuitos
TDM emulados como alternativa de baixo custo para transmisso vdeo digital,
caracterizando uma aplicao IPTV com caractersticas diferentes das usuais.
Em seu desenvolvimento, so propostos novos mecanismos para o seqenciamento de
pacotes e a recuperao do relgio de transmisso no receptor, que so descritos e
validados

atravs de simulao no MatLab e Simulink, bem como parcialmente

implementados atravs de uma aplicao desenvolvida em Java, submetida avaliao

experimental na rede IP do LabCom/UnB.
O trabalho apresenta tambm os resultados experimentais obtidos com a utilizao de uma
aplicao comercial TDMoIP, desenvolvida pela RAD, utilizada para emular um circuito
E1 no entroncamento de uma central de comutao Trpico-RA, analisado sob diversas
condies, incluindo o ponto de vista da central em relao qualidade do enlace e o
estudo comparativo com a aplicao Java desenvolvida.

vi

ABSTRACT

TDMoIP AS AN
APPLICATIONS

ALTERNATIVE

FOR

BROADCASTING

IN

IPTV

Author: Wilson Dutra Sampaio

Supervisor: Paulo Henrique Portela de Carvalho
Programa de Ps-graduao em Engenharia Eltrica
Braslia, outubro de 2006

This work presents new technologies for TDM emulation over packet networks, as an
alternative to VoIP applications, saving network investments. After that, it proposes TDM
pseudo-wires as an option to reduce digital video transmission costs, introducing a new
kind of IPTV application.
The work proposes new algorithms to improve solutions to TDM over IP main challenges:
packet-sequence processing and clock-recovery at receiver. These algorithms are described
and implemented using simulation at MatLab and Simulink, and tested using a simple
Java-based application to deploy TDM over IP on a real network at LabCom/UnB.
Moreover, it also presents experimental results from a commercial solution for TDMoIP
technology, developed by RAD Data Communications, Inc. and used to deploy trunk E1
circuits for a Trpico-RA voice switch, in several conditions, analyzing pseudo-wire
behavior and link quality as viewed by that switch. Finally, this work provides a
comparison between that and proposed solution.

vii

SUMRIO

1 - INTRODUO E MOTIVAES.......................................................................

2 EMULAO DE CIRCUITOS TDM EM REDES IP....................................... 19

2.1 - A EMULAO DE CIRCUITOS EM REDES DE PACOTES................. 19
2.1.1 - O conceito de emulao de circuitos em redes de pacotes.................

20

2.1.2 - Modelo de referncia PWE3 para sincronizao de rede.................. 21

2.1.3 - As diversas propostas de emulao de circuitos TDM sobre PSN.... 26
2.2 - SERVIOS TDM SOBRE IP......................................................................... 31
2.2.1 - Diferenas essenciais entre as redes TDM e redes IP......................... 31
2.2.2 - Transporte de servios TDM atravs de redes IP............................... 32
2.2.3 Implementao de pseudo-circuitos TDM.......................................... 34
2.3 - PROPOSTA DE EVOLUO DA IMPLEMENTAO TDMOIP....... 41
2.3.1 - A Implementao TDMoIP da RAD................................................. 41
2.3.2 - O novo mecanismo proposto para seqenciamento de pacotes......... 47
2.3.3 - O mecanismo alternativo proposto para sincronizao TDM........... 53
2.4 - COMPARAO ENTRE AS TECNOLOGIAS TDMOIP E VOIP........ 59
2.4.1 - Semelhanas entre as tecnologias......................................................... 59
2.4.2 - Sensibilidade s perdas de pacotes....................................................... 60
2.4.3 - Eficincia de utilizao da largura de banda...................................... 62
2.4.4 Complexidade computacional.............................................................. 64
2.4.5 - Latncia e requisitos para transporte do trfego de voz.................... 67
2.5 - PRINCIPAIS APLICAES TDM SOBRE IP E ETHERNET................. 70
2.5.1 - Entroncamento de voz e extenso de circuitos.................................... 70
2.5.2 - Circuitos E1/T1 sobre redes de pacotes como rede de acesso local... 75
2.5.3 - Servios de linha dedicada E1/T1 sobre redes de pacotes................. 77
2.5.4 - Backbone para redes mveis sobre rede se pacotes............................ 79

viii

3 - ALTERNATIVA TDMoIP PARA BROADCASTING IPTV............................. 81

3.1 - A TRANSMISSO DE VDEO DIGITAL................................................... 81
3.2 - OS PADRES DE CODIFICAO DE VDEO......................................... 82
3.2.1 Os padres H.261 e MPEG-1............................................................... 83
3.2.2 O padro H.262 ou MPEG-2 Vdeo..................................................... 83
3.2.3 O padro H.263..................................................................................... 85
3.2.4 O padro H.264 ou MPEG-4 Vdeo..................................................... 85
3.3 - SERVIOS IPTV: CARACTERSTICAS E REQUISITOS...................... 86
3.4 - TECNOLOGIAS PARA TRANSMISSO IPTV E VoD............................ 88
3.5 - ADEQUAO TDMOIP PARA TRANSMISSO DE VDEO............... 91
3.5.1 - Fragmentao do fluxo de vdeo em pacotes....................................... 94
3.5.2 - Absoro de PDV na transmisso IPTV.............................................. 96
3.5.3 - Sincronizao dos receptores na transmisso IPTV........................... 97
4 - IMPLEMENTAO E RESULTADOS EXPERIMENTAIS............................ 103
4.1 - MODELAGEM TDMoIP UTILIZANDO MATLAB E SIMULINK..... 103
4.1.1 Modelagem TDMoIP no MatLab e Simulink................................. 103
4.1.2 Simulao MatLab do algoritmo de seqenciamento de pacotes... 104
4.1.3 Simulao Simulink do PLL para sincronizao do receptor.......... 111
4.2 - EXPERIMENTAO TDMoIP NA REDE LABCOM/UnB................... 132
4.2.1 Definio da topologia e configurao da rede LabCom.................. 133
4.2.2 Estudo e configurao dos equipamentos RAD IPmux-11............... 136
4.2.3 Estudo e configurao da central Trpico-RA................................... 141
4.2.4 Ensaios de desempenho TDMoIP...................................................... 143
4.3 - IMPLEMENTAO TDMOIP EM JAVA................................................ 151
4.3.1 Desenvolvimento das ferramentas de transmisso e recepo.......... 151
4.3.2 Ensaios de desempenho TDMoIP...................................................... 154
4.4 -ANLISE DOS RESULTADOS EXPERIMENTAIS.................................. 157
4.4.1 Desempenho do algoritmo de seqenciamento de pacotes................ 157
4.4.2 Desempenho do PLL para sincronizao do receptor....................... 158
4.4.3 Desempenho do IPMux-11 na emulao de um enlace TDM........... 159
4.4.4 Anlise comparativa ente IPmux-11 e aplicao Java....................... 161

ix

5 CONCLUSES E TRABALHOS FUTUROS..................................................... 165

REFERNCIAS BIBLIOGRFICAS........................................................................ 169
APNDICE A ARQUITETURA PWE3.................................................................. A1
A.1 - TERMINOLOGIA UTILIZADA NA ARQUITETURA PWE3..................... A1
A.2 - PROTOCOLOS UTILIZADOS NA ARQUITETURA PWE3....................... A9
A.3 - TIPOS DE FLUXOS DE DADOS NA ARQUITETURA PWE3.................... A10
A.4 - PILHA DE PROTOCOLOS NA ARQUITETURA PWE3............................. A13
A.5 - DETECO DE ERROS EM PWE3............................................................... A22
A.6 - CONGESTIONAMENTO EM PWE3............................................................... A23
A.7 - PLANO DE CONTROLE DA ARQUITETURA PWE3................................. A24
A.8 - IMPLEMENTAO DA ARQUITETURA PWE3 SOBRE IP..................... A25
APNDICE B REQUISITOS PWE3....................................................................... A29
B.1 - REQUISITOS GERAIS PARA PWE3.............................................................. A29
B.2 - REQUISITOS PARA PWE3 EMULANDO SERVIOS TDM...................... A35
APNDICE C ESPECIFICAES TDMoIP...................................................... A41
C.1 SUBCAMADA DE ENCAPSULAMENTO......................... A41
C.2 SUBCAMADA DE ADAPTAO....................................... A52
C.3 SERVIOS TDM EMULADOS........................................... A60
C.4 GERENCIAMENTO DE FALHAS...................................... A64
APNDICE D PROCESSAMENTO DO NMERO DE SEQENCIA.............. A69
APNDICE E LISTAGEM DE FUNES MATLAB....................................... A73
E.1 FUNO PARA SIMULAO DE PACOTES COM O
ALGORITMO IETF........................................................................ A73
E.2 FUNO PARA SIMULAO DE PACOTES COM O
NOVO ALGORITMO..................................................................... A75

LISTA DE TABELAS

Tabela 1.1 - Escala de notas da avaliao subjetiva MOS.............................................

Tabela 1.2 - Custos mensais dos produtos Brasil Telecom para voz e dados...............

14

Tabela 2.1 - Comparao entre as propostas para transporte TDM sobre PSN............. 31
Tabela 2.2 - Durao das amostras TDM para cada tamanho do pacote de dados........ 55
Tabela 2.3 - Amostras de voz por tecnologia e codificador utilizado.......................... 62
Tabela 2.4 - Overhead e taxa efetiva por tecnologia e codificador utilizado................ 63
Tabela 2.5 - Efeito do atraso na qualidade do sinal de voz........................................... 67
Tabela 2.6 - Especificaes de latncia mxima para redes pblicas e privadas.......... 68
Tabela 2.7 - Latncia fixa por tecnologia e codificador utilizado................................. 68
Tabela 2.8 - Comparao de requisitos PWE3 com relao a VoIP.............................. 69
Tabela 3.1 - Overhead na PSN x tamanho dos pacotes na tecnologia SAToP.............. 94
Tabela 3.2 - Overhead na PSN x tamanho dos pacotes na tecnologia TDMoIP......... 95
Tabela 4.1 - Matriz de simulao da transmisso de pacotes atravs da PSN............... 105
Tabela 4.2 - Equivalncia entre parmetros experimentais e os utilizados no PLL
Simulink.................................................................................................... 126
Tabela 4.3 - Regras de Zieger-Nichols em malha fechada para ajuste de
controladores PID...................................................................................... 129
Tabela 4.4 - Configurao de parmetros para os gateways IPmux-11......................... 139
Tabela 4.5 - Registro de eventos do IPmux-11, acesso HTTP...................................... 140
Tabela 4.6 - Regime de ocupao do trfego concorrente............................................. 145
Tabela 4.7 - Condies de alarme para enlaces PCM na Trpico-RA.......................... 148
Tabela 4.8 - Comparao perdas efetivas de pacote nos dois algoritmos simulados.... 157
Tabela 4.9 - Durao dos dados TDM e quantidade de pacotes para PDUs AAL1...... 162
Tabela 4.10 -Comparao do desempenho entre o IPmux-11 e a aplicao Java.......... 163

xi

LISTA DE FIGURAS

Figura 1.1 - Penetrao das tecnologias de comunicao na populao mundial (%)

Figura 1.2 - Penetrao das tecnologias de comunicao nos domiclios brasileiros...

Figura 1.3 - Broadcasting de TV utilizando uma rede IP.............................................

Figura 1.4 - Interconexo de PBXes e LANs, utilizando um backbone IP...................

Figura 1.5 - Modelo de referncia CES sobre PSN.......................................................

Figura 1.6 - Comunicao entre dois telefones convencionais usando VoIP................ 10

Figura 1.7 - Comunicao entre dois telefones convencionais usando TDMoIP.......... 11
Figura 2.1 - Modelo de referncia PWE3 para sincronizao de rede.......................... 22
Figura 2.2 - Cenrio de rede sincronizada pelo PE....................................................... 23
Figura 2.3 - Cenrio de rede sincronizada pelo CE....................................................... 24
Figura 2.4 - Cenrio de sincronizao relativa.............................................................. 25
Figura 2.5 - Cenrio de sincronizao adaptativa......................................................... 26
Figura 2.6 - Correntes da emulao TDM sobre redes de pacote................................. 27
Figura 2.7 - Acomodao da variao no atraso dos pacotes pelo jitter buffer............

34

Figura 2.8 - Recuperao do relgio no destino pelo mtodo sncrono........................ 36

Figura 2.9 - Recuperao do relgio no destino pelo mtodo relativo SRTS............... 37
Figura 2.10 - Recuperao do relgio no destino pelo mtodo adaptativo
utilizando timestamp atravs do protocolo RTP........................................ 38
Figura 2.11 - Recuperao do relgio no destino pelo mtodo adaptativo
utilizando a ocupao, no tempo, do jitter buffer...................................... 38
Figura 2.12 - Esquemas de sincronizao para gateways TDMoIP RAD..................... 46
Figura 2.13 - Ilustrao do mecanismo de seqenciamento proposto............................. 48
Figura 2.14 - Exemplo de reconfigurao dinmica do jitter buffer............................... 51
Figura 2.15 - Mecanismo de recuperao do relgio baseado em timestamp e PLL...... 57
Figura 2.16 - Recuperao do relgio no receptor pelo mtodo adaptativo proposto..... 58
Figura 2.17 - Entroncamento TDM convencional..........................................................

71

Figura 2.18 - Entroncamento de servios atravs de VoIP............................................. 73

Figura 2.19 - Entroncamento IP esttico utilizando TDMoIP....................................... 73

xii

Figura 2.20 - Entroncamento IP com comutao utilizando TDMoIP.......................... 74

Figura 2.21 - Entroncamento IP utilizando TDMoIP com interoperabilidade

75

VoIP.....
Figura 2.22 - Utilizao de metroethernet como rede de acesso multi-servios............. 76
Figura 2.23 - Servios de linha dedicada sobre redes de dados...................................... 77
Figura 2.24 - Backbone IP para uma rede mvel celular................................................ 79
Figura 3.1 - Acesso IPTV numa configurao triple play............................................. 89
Figura 3.2 - Modelo convencional ponto a ponto para transmisso IPTV.................... 90
Figura 3.3 - Alternativa de broadcasting IPTV usando TDMoIP e multicast............ 93
Figura 3.4 - Esquema usual para controle de qualidade em IPTV................................ 98
Figura 3.5 - Proposta de controle de qualidade baseado exclusivamente no receptor.. 99
Figura 4.1 - Histograma de freqncias na medio do RTT entre o LabCom/UnB e
os stios Internet das universidades federais e portais dos governos
estaduais brasileiros................................................................................... 106
Figura 4.2 - Grfico da simulao MatLab, apresentando os pacotes transmitidos
(azul) e recebidos (verde).......................................................................... 107
Figura 4.3 - Grfico da simulao MatLab, apresentando os instantes de
transmisso (azul) e recepo (verde) de cada pacote............................... 104
Figura 4.4 - Grfico da simulao MatLab utilizando o algoritmo proposto pelo
IETF para seqenciamento, apresentado no Apndice A.......................... 109
Figura 4.5 - Grfico da simulao MatLab utilizando o novo mecanismo proposto
de gravao no jitter buffer para seqenciamento..................................... 110
Figura 4.6 - Princpio de operao da sincronizao adaptativa usando PLL............... 111
Figura 4.7 - Diagrama de blocos do PLL em malha fechada........................................ 113
Figura 4.8 - Diagrama de blocos do filtro EWMA duplo............................................. 116
Figura 4.9 - Diagrama de blocos do controlador PID................................................... 119
Figura 4.10 - Diagrama de blocos do DCO..................................................................... 121
Figura 4.11 - Operao do PLL na recuperao do sincronismo no receptor................. 123
Figura 4.12 - Implementao do PLL com filtro EWMA no Simulink.......................... 124
Figura 4.13 - Evoluo do erro entre T(n) e R(n) para o filtro EWMA no Simulink...... 127
Figura 4.14 - Evoluo do erro T(n) - R(n) para o filtro EWMA c/desvio de 7,5Hz.... 128
Figura 4.15 - Sinal de controle para o filtro EWMA c/desvio de 7,5Hz....................... 129

xiii

Figura 4.16 - Implementao do PLL com o controlador PID proposto no Simulink.... 130
Figura 4.17 - Evoluo do erro T(n) - R(n) para o controlador PID c/desvio de 7,5Hz 131
Figura 4.18 - Sinal de controle para o controlador PID c/desvio de 7,5Hz................... 132
Figura 4.19 - Modelo conceitual do ambiente experimental .......................................... 133
Figura 4.20 - Topologia da plataforma de testes PWE3................................................. 134
Figura 4.21 - Tela principal da ferramenta Analisador, do LabCom/UnB.................. 135
Figura 4.22 - Gateway IPmux-11 da RAD utilizado nos testes...................................... 136
Figura 4.23 - Tela de configurao do gateway IPmux-11 utilizado nos testes.............. 137
Figura 4.24 - Central Trpico-RA utilizada nos testes para gerao de feixe E1........... 142
Figura 4.25 - Caminho utilizado pelos pacotes no pseudo-circuito TDM...................... 144
Figura 4.26 - Desempenho de um pseudo-circuito E1 para enlaces de 4Mbps............... 146
Figura 4.27 - Desempenho de um pseudo-circuito E1 para enlaces de 6Mbps............... 146
Figura 4.28 - Desempenho de um pseudo-circuito E1 para enlaces de 8Mbps............... 147
Figura 4.29 - Desempenho de um pseudo-circuito E1 para enlaces de 10Mbps............. 147
Figura 4.30 - Desempenho de um pseudo-circuito E1 para 48 octetos por pacote......... 149
Figura 4.31 - Desempenho de um pseudo-circuito E1 para 240 octetos por pacote....... 149
Figura 4.32 - Desempenho de um pseudo-circuito E1 para 720 octetos por pacote....... 150
Figura 4.33 - Desempenho de um pseudo-circuito E1 para 1440 octetos por pacote..... 150
Figura 4.34 - Diagrama de blocos do Mux-IP PC........................................................... 152
Figura 4.35 - Telas das aplicaes Mux-IP PC............................................................... 154
Figura 4.36 - Ensaio comparativo entre IPmux-11 e Mux-IP PC................................... 155
Figura 4.37 - Desempenho do IPmux-11 no teste comparativo...................................... 156
Figura 4.38 - Desempenho do Mux-IP PC no teste comparativo.................................... 156
Figura A.1 - Multi-quadro com 16 quadros e sinalizao CAS..................................... A6
Figura A.2 - Utilizao do canal 16 para sinalizao CCS de um feixe E1................... A7
Figura A.3 - Modelo lgico da pilha de protocolos PWE3............................................ A9
Figura A.4 - Modelo de referncia para a pilha de protocolos PWE3........................... A14
Figura A.5 - Detalhamento da camada de encapsulamento PWE3................................ A15
Figura A.6 - Arquitetura PWE3 sobre uma rede IP....................................................... A25
Figura A.7 - Arquitetura PWE3 sobre rede MPLS com palavra de controle................. A26
Figura B.1 - Modelo de referncia PWE3..................................................................... A30
Figura B.2 - Cenrio original: pseudo-circuito PE a PE................................................ A31

xiv

Figura B.3 - Cenrio alternativo: pseudo-circuito CE a CE.......................................... A32

Figura C.1 - Formato geral de um pacote TDMoIP .................................................... A41
Figura C.2- Palavra de controle TDMoIP de 32 bits................................................... A42
Figura C.3 - Formato de um pacote TDMoIP sobre UDP/IP....................................... A45
Figura C.4 - Formato de um pacote TDMoIP sobre MPLS......................................... A48
Figura C.5 - Formato de um pacote TDMoIP sobre Ethernet...................................... A50
Figura C.6 - Estrutura AAL1 de 48 octetos....................................................................A54
Figura C.7- Exemplo de alocao dos canais TDM nos octetos das PDUs AAL1
para emulao de circuitos estruturada...................................................... A55
Figura C.8 - Estrutura de uma P-format PDU AAL1
para emulao de circuitos estruturada...................................................... A56
Figura C.9 - Exemplo de alocao de canais nos octetos das PDUs AAL1.................. A57
Figura C.10- PDUs AAL1 dentro do s pacotes TDMoIP ............................................. A58
Figura C.11- Hierarquia digital plesicrona................................................................... A61
Figura C.12- Fluxo TDM estruturado com canalizao................................................. A62
Figura C.13- Hierarquia digital sncrona........................................................................ A63
Figura C.14- Configurao tpica de uma rede TDMoIP.............................................. A65

xv

LISTA DE NOMENCLATURAS E SIGLAS

3G

Terceira Gerao das Redes Mveis

AC

Attachment Circuit Circuito de Acesso

ADPCM

AIS

Adaptive Differential Pulse Code Modulation Modulao por Cdigo de

Pulsos Diferencial Adaptativa
Asyimmetric Digital Subscriber Line Linha Digital de Assinante
Assimtrica
Alarm Indication Signal - Sinal de Indicao de Alarme

ANATEL

Agncia Nacional de Telecomunicaes

ANSI
ATM

American National Standards Institute Instituto Nacional de Padres dos

Estados Unidos da Amrica
Assyncronous Transfer Mode - Modo de Transferncia Assncrono

ATMF

Asynchronous Mode Transfer Forum Frum de discusso para ATM

AU

Administrative Unit Unidade Administrativa (SDH)

AUG

Administrative Unit Group Grupo de Unidades Administrativas (SDH)

AVC

Advanced Vdeo Coding Codificao Avanada de Vdeo

BE

Best Effort Melhor Esforo

BSC

Binary Synchronous Communication Comunicao Binria Sncrona

BSC

Base Station Controller - Controlador de Estao Base

BTS

Base Transceiver Station - Estao Base Transceptora de rdio

C++

Linguagem de Programao C orientada a objetos

CA

Corrente Alternada

CAS

Channel-Associated Signaling Sinalizao por Canal Associado

CBR

Constant Bit Rate Taxa de Bits Constante

CCS

Common Channel Signaling Sinalizao por Canal Comum

CD

Compact Disc Disco Compacto

CE

Customer Edge Equipamento Cliente

CES

Circuit Emulation Services Servios de Emulao de Circuitos

CESoPSN

Circuit Emulation Services over Packet-Switched Network Servios de

Emulao de Circuitos sobre Redes Comutadas em Modo Pacotes
COder/DECoder Codificador/Decodificador de Sinais de Voz e Vdeo

ADSL

CODEC

xvi

CRC

Cyclic Redundancy Check Verificao de integridade de dados atravs de

Cdigo de Redundncia Cclica
CS-ACELP Conjugate Structure Algebraic Code-Excited Linear Prediction Preditor
Linear Excitado por Cdigo Algbrico de Simetria Complementar
Circuit-Switched Network Rede Comutada em Modo Circuitos
CSN
CW

Control Word Palavra de Controle TDMoIP

DCO

Digitally Controlled Oscillator Oscilador Controlado Digitalmente

DSL

Digital Subscriber Line Linha de Assinante Digital

DSLAM
DSP

Digital Subscriber Line Access Module Mdulo de Acesso para Linha de

Assinante Digital
Digital Signal Processor Processador Digital de Sinais

DTH

Direct-To-Home Direto para Casa (TV por assinatura)

DVB

Digital Video Broadcasting Difuso de Vdeo Digital

DVD

Digital Versatile Disk Disco Verstil Digital

EILD

Explorao Industrial de Linha Dedicada

ENE

Departamento de Engenharia Eltrica/UnB

EWMA

Exponencially Weighted Moving Average Mdia Mvel Exponencialmente Ponderada ou Alisamento Exponencial
Frame Alignment Signal Sinal de Alinhamento de Quadro (TDM)

FAS
FDM
FLL

Frequency Division Multiplexing Multiplexao por Diviso de

Freqncia
Frequency-Locked Loop Enlace de Freqncia Capturada

FM

Freqncia Modulada

FR

Frame Relay Protocolo de Chaveamento de Quadros

FT

Faculdade de Tecnologia/UnB

FXO

Foreign eXchange Office Interface de linha analgica para operadora

FXS

Foreign eXchange Subscriber Interface de linha analgica para assinante

G.114

Recomendao ITU-T que define os valores aceitveis para o atraso em

redes de comunicao de voz, orientado a redes pblicas nacionais
Recomendao ITU-T que caracteriza e define as necessidades de controle
de eco em redes de comunicao de voz.
Recomendao ITU-T que especifica a estrutura de taxas de bits da
hierarquia digital PDH
Recomendao ITU-T que especifica as caractersticas fsicas e eltricas
das interfaces digtais PDH para taxas at 140 Mbps
Recomendao ITU-T que especifica as estruturas sncronas de quadro
utilizadas nas interfaces G.703 at 45 Mbps
Recomendao ITU-T que especifica os procedimentos de alinhamento de
quadro e clculo de CRC relacionados s estruturas bsicas de quadro
definidas pela recomendao G.704

G.131
G.702
G.703
G.704
G.706

xvii

G.707
G.711
G.723.1
G.726
G.729
G.751
G.775
G.810
G.823
G.824
G.826
GW
H.248
H.261
H.262
H.263
H.264
H.323
HDLC
HDSL
HTTP
IANA
IBGE

Recomendao ITU-T que especifica as taxas de bits das interfaces

utilizadas pelos ns da hierarquia digital SDH
Recomendao ITU-T que especifica a codificao PCM para freqncias
de voz, utilizando taxa de 64 kbps
Recomendao ITU-T que especifica um codificador de voz de dupla taxa
para comunicaes multimdia, transmitindo a 5,3 kbps e 6,3 kbps
Recomendao ITU-T
que especifica a codificao ADPCM para
freqncias de voz, utilizando taxas de 40 kbps, 32 kbps ou 16 kbps
Recomendao ITU-T que especifica a codificao de voz a taxas de 8
kbps, utilizando o algoritmo CS-ACELP.
Recomendao ITU-T que especifica os equipamentos de multiplexao
digital TDM operando com taxas de 3a. ordem (34,368 Mbps) e 4a.ordem
(139,264 Mbps), utilizando justificao positiva
Recomendao ITU-T que especifica os critrios para a deteco e
liberao dos defeitos indicados pelas condies LOS e AIS
Recomendao ITU-T que apresenta as definies e a terminologia
utilizada para redes de sincronismo
Recomendao ITU-T que especifica o controle do jitter e ander em redes
digitais baseadas na hierarquia digital PDH, para taxas de 2,048 Mbps (E1)
Recomendao ITU-T que especifica o controle do jitter e ander em redes
digitais baseadas na hierarquia digital PDH, para taxas de 1,544 Mbps (T1)
Recomendao ITU-T que especifica os objetivos e parmetros de
performance de erros para circuitos digitais internacionais operando a taxa
de bits constante (CBR), na taxa primria (E1/T1) ou acima desta
Gateway Equipamento de controle e/ou acesso de uma rede ou servio
Recomendao ITU-T que define o protocolo de comunicao entre media
gateways e o media gateway controller, tambm conhecido como
MEGACO em funo de seu desenvolvimento cooperativo com a IETF
Recomendao ITU-T para codificao de vdeo em sistemas audiovisuais
de faixa estreita
Designao ITU-T para o padro MPEG-2 de vdeo: codificao genrica
para imagens em movimento e informao de udio associada
Recomendao ITU-T para codificao otimizada de vdeo para uso com
taxas de bits inferiores quelas tipicamente utilizadas em H.261
Recomendao ITU-T para codificao avanada de vdeo para servios
audiovisuais genricos
Recomendao ITU-T para servios de comunicao multimdia baseados
em pacotes, incluindo videoconferncia
High-Level Data Link Control Controle de Enlace de Dados de Alto
Nvel
High-bit-rate Digital Subscriber Line Linha Digital de Assinante de para
Altas taxas de bits, de caractersticas simtricas
HiperText Transfer Protocol Protocolo de Transferncia de HiperTexto
Internet Assigned Numbers Authority Autoridade de Associao de
Nmeros para Internet
Instituto Brasileiro de Geografia e Estatstica

xviii

ICMP

IP

Internet Control Message Protocol Protocolo Internet de Mensagens de

Controle
Institute of Electrical and Electronics Engineers Instituto dos
Engenheiros Eletricistas e Eletrnicos
Internet Engineering Task Force Fora Tarefa para Engenharia da
Internet
Internet Low Bit-rate CODEC Codificador/Decodificador Internet a
Baixas Taxas
Internet Protocol Protocolo de Internet

IPTV

Internet Protocol TeleVision Televiso baseada em Protocolo de Internet

ISDN

Integrated Services Digital Network Rede Digital de Servios Integrados

ISO

IWF

International Organization for Standardization Organizao Internacional para Padronizao

Integrated Services User Part Protocolo de Sinalizao para Usurio de
Servios Integrados (SS7)
International Telecommunications Union Telecommunication Standardization Sector Unio Internacional de Telecomunicaes Setor de
Padronizao para Telefocomunicaes
InterWorking Function Funo de Interoperabilidade

HDTV

High-Definition TeleVision Televiso de Alta Definio

JVT

Joint Vdeo Team Equipe Conjunta de Vdeo

LABCOM

LAN

Laboratrio de Pesquisa e Desenvolvimento em Telecomunicaes do

Departamento de Engenharia Eltrica/UnB
Link Access Procedure Balanced Procedimento Balanceado de Acesso
para Enlace de Dados
Local Area Network Rede Local

LDP

Label Distribution Protocol Protocolo de Distribuio de Etiquetas

LEMOM

Laboratrio de Estruturas de Microondas e Ondas Milimtricas

LER

Label Edge Router Roteador de Borda MPLS

LOS

Loss of Signal Perda de Sinal (TDM)

LSR

Label-Switching Router Roteador de Comutao de Etiquetas MPLS

MAN

Metropolitan Area Network Rede Metropolitana

MEF

Metro Ethernet Forum Frum de discusso para Ethernet Metropolitana

MEGACO

MEdia GAteway COntrol Protocolo de Controle de MGC

MGC

Media Gateway Controller Controlador de Gateways de Mdia

MGCP

Media Gateway Control Protocol Protocolo de Controle de MGC

MOS

Mean Opinion Score Pontuao pela Opinio Mdia

IEEE
IETF
iLBC

ISUP
ITU-T

LAPB

MP-ACELP Multi Pulse Algebraic Code-Excited Linear Prediction Preditor Linear

Excitado por Cdigo Algbrico Multi-pulsos
xix

MP3

MPEG-1 Audio Layer 3 Camada 3 de udio do Padro MPEG-1

MPEG

MTU

Moving Picture Experts Group Grupo de Especialistas em Imagens em

Movimento (Vdeo)
Multi-Protocol Label Switching Protocolo de Comutao de Etiquetas
Multiprotocolos
Multi Pulse Maximum Likelihood Quantization Quantizao pela
Mxima Semelhana Multi-pulsos
Maximum Transmission Unit Unidade Mxima de Transmisso

MUX

MUltipleX Equipamento de Multiplexao

NEA

Nmero Equivalente de Assinante

NS

Nmero de Seqncia

NSP

Native Service Processing Processamento de Servio Nativo

NTSC
ONG

National Television Systems Committee Comit Nacional de Sistemas de

Televiso, padro norte-americano para televiso em cores
Organizao No-Governamental

ONU

Organizao das Naes Unidas

OOF

Out of Frame Alignment Synchronization Ausncia de Sincronismo de

Quadros
Open Shortest Path First Primeiro pelo Caminho Livre Mais Curto

MPLS
MP-MLQ

OSPF
PABX
PBX
PAL

Private Automatic Branch eXchange Equipamento Automtico de

Comutao Privada
Private Branch eXchange Equipamento de Comutao Privada

PC

Phase-Alternating Line Linha de Fase Alternada, padro europeu para

televiso em cores
Personal Computer Computador Pessoal ou Microcomputador

PCM

Pulse Code Modulation Modulao por Cdigo de Pulsos

PCS

Ponto de Controle de Sinalizao (SS7)

PDV

Packet Delay Variation Variao no Atraso dos Pacotes

PE

Provider Edge Equipamento Provedor

PESQ
PDH

Perceptual Evaluation of Speech Quality Avaliao Perceptiva da

Qualidade de Voz
Plesiochronous Digital Hierarchy Hierarquia Digital Plesicrona

PDU

Protocol Data Unit Unidade de Dados de Protocolo

PID

Controle Proporcional, Integral e Derivativo

PLC

Packet-Loss Concealment Mitigao de Perdas de Pacote

PLL

Phase-Locked Loop Enlace de Fase Capturada

PNAD

Pesquisa Nacional por Amostra de Domiclios

Ppm

Partes por milho

xx

PSN

Packet-Switched Network Rede Comutada em Modo Pacotes

PTS

Ponto de Transferncia de Sinalizao (SS7)

PW

Pseudo-Wire Pseudo-Circuito

PWE3
QoS

Pseudo-Wire Emulation Edge-to-Edge Emulao Fim a Fim de PseudoCircuitos

Quality of Service Qualidade de Servio

RAI

Remote Alarm Indication Sinal de Indicao de Alarme Remoto

RDI

Remote Defect Indication Sinal de Indicao de Defeito Remoto

REMAV

Rede Metropolitana de Alta Velocidade

RFC

Request for Comments Nomenclatura dos Padres IETF

RNP

Rede Nacional de Pesquisa

RTFC

Rede Telefnica Fixa Comutada

RTP

Real Time Protocol Protocolo para Dados em Tempo Real

RTCP

RTT

Real Time Control Protocol Protocolo de Controle para Dados em Tempo

Real
Real Time Streaming Protocol Protocolo de Transmisso de Vdeo em
Tempo Real
Round-Trip Time Tempo de ida e volta

Rx

Receptor

SAT

Structure-Agnostic Transport Transporte sem Conscincia da Estrutura

SAToIP

Structure-Agnostic Transport over Internet Protocol Transporte sem

Conscincia da Estrutura sobre Protocolo de Internet
Synchronous Digital Hierarchy Hierarquia Digital Sncrona

RTSP

SDH
SECAM
SIGTRAN

Squentiel Couleur Mmoire Cor seqencial com Memria, padro

francs para televiso em cores
SIGnaling TRANsport Protocol Protocolo de Transporte de Sinalizao

SG

Signaling Gateway Gateway de Sinalizao

SIP

Session Iniciation Protocol Protocolo de Iniciao de Sesso

SMP

Servio Mvel Pessoal

SNA

Synchronous Network Architecture Arquitetura de Rede Sncrona

SOHO

Small Office/Home Office Pequeno Escritrio/Escritrio Domstico

SONET

Synchronous Optical Network Rede ptica Sncrona

SS7

Signaling System Number 7 Sinalizao por Canal Comum Nmero 7

STM

Syncronous Transport Module Mdulo de Transporte Sncrono

STS

Synchronous Transport Signal Sinal de Transporte Sncrono

TDM

Time Domain Multiplexing Multiplexao no Domnio do Tempo

xxi

TDMoIP

Time Division Multiplexing over Internet Protocol Multiplexao no

Domnio do Tempo sobre Protocolo de Internet
TELENOR Telecommunications of Norway Telecomunicaes da Noruega
TIC

Telefones fixos e celulares, Internet, microComputadores, rdio e televiso

TG

Trunking Gateway Gateway de Entroncamento

TU

Tributary Unit Unidade Tributria (SDH)

TUG

Tributary Unit Group Grupo de Unidades Tributrias (SDH)

Tx

Transmissor

UDP

User Datagram Protocol Protocolo de Datagramas de Usurio

UFAC

Universidade Federal do Acre

UMTS
UN

Universal Mobile Telecommunication System - Sistema Universal de

Telecomunicaes Mveis
United Nations Naes Unidas

UnB

Universidade de Braslia

UNIR

Fundao Universidade Federal de Rondnia

UTFORS

Operadora de Telecomunicaes da Sucia, adquirida pela TELENOR

UTP

Unshielded Twisted Pair Par Tranado sem Blindagem

VBR

Variable Bit Rate Taxa de Bits Varivel

VC

Virtual Container Continer Virtual (SDH)

VCD

Video Compact Disc Disco Compacto de Vdeo

VCEG
VHF

Video Coding Experts Group Grupo de Especialistas Codificao de

Vdeo
Very High Frequency Freqncia Muito Alta

VHS

Vdeo Home System Sistema de Vdeo Domstico

VLC

VideoLan Client Cliente de Vdeo para LAN

VoD

Vdeo on Demand Transmisso de Vdeo sob Demanda

VoIP

Voice over IP Voz sobre Protocolo de Internet

VRML

WAN

Virtual Reality Modelling Language Linguagem para Modelamento de

Realidade Virtual
Vestigial-Sided Band Banda Lateral Vestigial, modulao utilizada na
transmisso de TV aberta no Brasil
Wide Area Network Rede de Grande Alcance

xDSL

x-Digital Subscriber Line Famlia de Linhas Digitais de Assinantes

Y.1413

Recomendao ITU-T que especifica a interoperabilidade entre redes TDM

e MPLS no plano de usurio
Recomendao ITU-T que especifica a interoperabilidade entre redes
MPLS e servios de voz

VSB

Y.1414

xxii

1 - INTRODUO E MOTIVAES

As Redes de Telecomunicaes esto completando 150 anos, e vm se desenvolvendo de

uma forma fascinante em diversos aspectos. Nas ltimas dcadas, em especial surgiram e
se consolidaram novas tecnologias que incrementam a capacidade dessas Redes de forma
assustadora, ao mesmo tempo em que as tornam mais simples e, portanto, mais confiveis,
mais eficientes e fceis de operar logo, mais baratas.
A ltima grande inovao nesse cenrio foi a disseminao das redes de transporte de alta
velocidade baseadas no protocolo IP (Internet Protocol), que trouxeram a simplicidade,
robustez, eficincia no uso da banda e baixo custo operacional - popularizadas com a
difuso da grande rede mundial de computadores, a Internet - para o mundo das
telecomunicaes tradicionais, originalmente dominado por tecnologias proprietrias, com
grande perodo de desenvolvimento e maturao, suportadas essencialmente por alguns
grandes fabricantes mundiais de equipamentos e construdas pelas grandes operadoras ao
longo das ltimas dcadas, em virtude dos vultosos investimentos associados.
No aspecto voz, servio para a qual foi desenvolvida, a infra-estrutura tradicional de
telecomunicaes, caracterizada pela famosa confiabilidade dos cinco noves (99,999%) e
pela boa qualidade de conversao, auferida por uma nota MOS (Mean Opinon Score)
superior a 4,0 segundo padres internacionais reconhecidos ver Tabela 1.1, tem
penetrao praticamente universal no mercado mundial, permitindo o estabelecimento de
intercomunicaes planetrias em poucos segundos e quase sempre de forma
completamente automtica. Sem dvida, essa uma caracterstica fundamental do servio e
da qual nenhum usurio abrir mo, devendo ser considerada quando da anlise de
qualquer alternativa s redes tradicionais.

Nota
Conceito

Tabela 1.1 - Escala de notas da avaliao subjetiva MOS

1,0
2,0
3,0
4,0
Ruim
Insatisfatrio
Regular
Bom

A1

5,0
Excelente

No aspecto dados, servio que passou a fazer parte das redes de telecomunicaes nos
ltimos 40 anos, com o desenvolvimento dos primeiros terminais interativos na dcada de
1960; tambm existem tecnologias tradicionais consagradas, que permitem a construo de
redes de transporte extremamente confiveis e seguras, sejam para o acesso remoto a
grandes centros de processamento, com supercomputadores para uso militar, pesquisas
cientficas ou data centers de grandes corporaes, ou para uma simples interconexo de
redes locais, utilizadas para suportar aplicaes comerciais, educacionais

ou de

entretenimento, como controlar remotamente o estoque de uma rede de farmcias, assistir a

uma aula por videoconferncia ou receber mensagens eletrnicas dos amigos.
Dentre as tecnologias desenvolvidas para a transmisso de dados, evolumos da jurssica
SNA (Synchronous Network Architecture) desenvolvida pela IBM para seus famosos
mainframes, reis absolutos do chamado processamento de dados at a dcada de 1980,
dos protocolos precursores de enlace como BSC (Binary Synchronous Communication)
HDLC (High-Level Data Link Control) e do LAPB (Link Access Procedure Balanced),
tambm conhecido como X.25, que consolidou a comutao de pacotes, para ficar entre os
mais famosos; at as tecnologias de transmisso de dados ainda hoje consagradas nas redes
de telecomunicaes das Operadoras, como o FR (Frame-Relay), uma evoluo do X.25, e
o ATM (Assyncronous Transfer Mode), grande promessa dos anos 1990 para as redes de
comunicao de dados, que acabou no alcanado nem a abrangncia e nem os resultados
esperados; ambas implantadas sobre redes pticas de transporte de grande capacidade e
confiabilidade, baseadas na arquitetura SDH/SONET (Synchronous Digital Hierarchy/
Synchronous Optical NETwork). Maiores informaes sobre a evoluo das redes de dados
e as caractersticas de cada uma dessas tecnologias podem ser encontradas em
[SOARES1995].
Contudo, uma rede desenvolvida sob conceitos relativamente simples, de arquitetura
extremamente flexvel, em funo dos seus requisitos originais de controle descentralizado
e capacidade para manter-se razoavelmente operacional sob extremas condies de falha
em boa parte de seus ns afinal, foi concebida para aplicaes militares; acabou se
tornando a grande vedete do final do sculo passado, e praticamente o padro atual para
transporte de dados, e uma alternativa crescente para todos os demais servios de

A2

telecomunicaes, incluindo a sesquicentenria voz e o cinqentenrio vdeo, que

juntos modificaram a civilizao humana no sculo XX.
O que torna as redes IP to atraentes, a ponto de provocar uma revoluo em mercados
consolidados como o broadcasting de vdeo, onde a televiso representa um consultor
domstico, o entretenimento mais acessvel, a bab eletrnica, o grande agregador (ou seria
desagregador?) da sociedade atual. No Brasil, no seria exagero dizer que a televiso
aberta, que entra todos os dias na casa de cada um de ns, constitui um verdadeiro Quarto
Poder da Repblica, com influncia at mais direta e imediata na nossa vida cotidiana do
que os tradicionais Executivo, Legislativo e Judicirio, nascidos em seu equilbrio nos
ideais libertrios franceses h 250 anos, 100 anos antes das Telecomunicaes.
Da mesma forma, no lado oposto, a miniaturizao e reduo nos preos dos equipamentos
de vdeo permite hoje a praticamente qualquer cidado de classe mdia a gerao de
contedos de udio e vdeo de boa qualidade, da forma e com o objetivo que desejar,
trazendo cada vez mais o protagonismo para a mdia de informao e entretenimento.
No meio desse caminho, temos as aplicaes que associam a facilidade na gerao de
contedo baseado em vdeo com a capacidade de transmisso e difuso desse contedo a
grandes distncias, de forma simples e barata. Essas aplicaes abrem um universo
completamente novo para servios de utilidade pblica, como tele-educao, tele-medicina
e tele-monitoramento; e inovaes praticamente ilimitadas no campo do entretenimento.
Essa revoluo sentida a cada instante, atravs de novos hbitos e costumes, como os
jogos eletrnicos em grupo e distncia, inimaginveis para a gerao, hoje na faixa dos
trinta anos, que passava suas tardes na companhia de um Atari 2600; a busca de
relacionamentos virtuais na segurana psicolgica do mundo digital, talvez a aplicao
que mais traga novos usurios para a Internet hoje em dia, como atestam o sucesso de stios
como o Orkut, o Myspaces e o Messenger , sejam eles pr-adolescentes curiosos ou
pessoas da melhor idade que encontram na tela de seus micros uma nova vida, longe de
suas limitaes fsicas; ou mesmo o velho cinema do sculo XIX, grande disseminador, no
sculo XX, do chamado american way of life para a cultura ocidental, e com ele boa parte
do poder da nica superpotncia mundial; que agora precisa ser repensado, uma vez que
A3

toda a produo mundial, incluindo um obscuro e independente filme iraniano ou indiano,

poderia estar disponvel, em nossa casa, ao toque de um boto do controle remoto.
Cmeras de segurana e monitoramento esto hoje integradas em nossas vidas, localizadas
na maioria dos grandes edifcios, tanto pblicos como privados, e mesmo nas ruas das
grandes cidades, concretizando a onipresena do big-brother, preconizado por George
Orwell em seu livro 1984, escrito em 1948. Essa realidade to presente e concreta que
pessoas se dispem, em todo o mundo, a serem observadas 24 horas por dia por milhes,
num programa de televiso muito popular no Brasil que as eleva condio de celebridade
instantnea, e cujo nome muito apropriadamente inspirado na obra de Orwell.
Nunca foi to fcil e barato, em toda a histria da humanidade, gerar contedo, seja voz,
vdeo, textos, imagens, msicas, sem depender de emissoras de rdio ou TV, editoras,
jornais, revistas ou gravadoras; da mesma forma, a Internet trouxe a possibilidade de
democratizao total desse contedo, inicialmente atravs dos e-mails, homepages e grupos
de discusso, depois dos blogs, fotologs e, agora, videologs e stios como YouTube,
MySpaces e Orkut, canais independentes e disponveis a quem estiver interessado e tiver a
pacincia de procurar. E mesmo essa pacincia hoje no precisa ser muito grande, com o
aperfeioamento constante das ferramentas de busca para achar qualquer coisa em qualquer
lugar dentro da grande rede mundial de computadores.
Contudo, esse admirvel mundo interconectado e digital, a princpio livre e democrtico,
ainda acessvel para somente 15% da populao mundial, a reduzida fatia que detm o
privilgio de acesso a um computador conectado rede Internet, conforme atestam os
indicadores da ONU criados em 2000 para acompanhamento das Metas do Milnio
[ONU2006], cujo grfico de penetrao percentual das principais tecnologias de
comunicao apresentado Figura 1.1.

A4

Figura 1.1 - Penetrao das tecnologias de comunicao na populao mundial (%).

No Brasil, cerca de 32 milhes de pessoas ou apenas 21% da populao acima de 10 anos
esto includos nesse seleto grupo segundo a PNAD (Pesquisa Nacional por Amostra de
Domiclios), realizada em 2005 pelo IBGE (Instituto Brasileiro de Geografia e Estatstica)
e recentemente divulgada [IBGE2006], como mostra o grfico de penetrao das
tecnologias, segundo essa pesquisa, apresentado na Figura 1.2.

Figura 1.2 - Penetrao das tecnologias de comunicao nos domiclios brasileiros.

A5

Entretanto, o mesmo grfico da Figura 1.2 demonstra que a quase totalidade dos lares
brasileiros tem pelo menos uma televiso e um equipamento de rdio, cerca de 40 milhes
de famlias tm tambm telefones fixos [ANATEL2006] e quase 96 milhes de pessoas
andam todos os dias com seus telefones celulares no bolso (ou na bolsa) [ANATEL2006a],
sendo esses os meios efetivamente disponveis para a divulgao massiva de contedo e/ou
prover servios de telecomunicaes populao.
Assim, a difuso (broadcasting) de vdeo e udio, dominada por grandes empresas/grupos
econmicos e dependentes de pesados investimentos; e as redes tradicionais de
telecomunicaes, fixas e mveis, ainda so os melhores instrumentos para alcanar a
grande maioria da populao, no Brasil e no mundo. Isso torna premente a necessidade de
buscar alternativas simples e baratas, como a mostrada na Figura 1.3, para levar o grande
universo de contedo disponvel no mundo Internet, bem como servios mais baratos de
telecomunicaes, aos equipamentos disponveis, preservando os investimentos realizados
e concentrando as evolues tecnolgicas na rede de transporte, onde beneficiam toda a
populao e no apenas um pequeno grupo que pode pagar pelos novos servios.

Gateway

TDMoIP
CODEC

Rede IP

CODEC
Gateway

TDMoIP

Tx
VHF

Figura 1.3 - Broadcasting de TV utilizando uma rede IP.

Considerando inicialmente o broadcasting de TV, fato consumado que somente uma
grande rede de televiso, sustentada por sua rede de patrocinadores, possui capacidade para
A6

manter transmisses nacionais via satlite, mas bastante provvel que uma grande
quantidade de emissoras comunitrias de baixo custo e cobertura local pudesse receber
programao nacional consistente, de carter educativo e social, gerada de diversas formas
e por diversas entidades, atravs da condio mostrada na Figura 1.3, para ento
retransmiti-la para sua comunidade.
Da mesma forma, somente uma grande operadora de telecomunicaes tem capacidade
para construir uma rede de abrangncia nacional utilizando as tecnologias tradicionais,
como SDH, mas uma pequena operadora poderia oferecer servios de voz e dados a baixos
custos, alugando determinada largura de banda de um provedor nacional que detenha
uma rede de transporte em modo pacotes de boa cobertura, como mostrado na Figura 1.4.

Gateway

TDMoIP
LAN

LAN

Gateway

TDMoIP
PABX

Rede IP

LAN

PABX

Gateway

TDMoIP

Gateway

TDMoIP
PABX

Figura 1.4 - Interconexo de PBXes e LANs, utilizando um backbone IP.

Nessa linha, considerando a grande penetrao das redes IP nos ltimos anos, como forma
de aproveitar sua popularizao, abrangncia e eficincia, esforos significativos vm
sendo feitos no desenvolvimento de novos servios que tragam aplicaes tradicionais da
rede de telecomunicaes para dentro dessas redes, tais como o mais difundido deles, VoIP
(Voice over IP), ou transmisso de voz sobre redes IP, com o objetivo de oferecer servios
de voz a tarifas bem mais baixas que as praticadas pelas Operadoras convencionais de
telecomunicaes, em funo do custo reduzido de transporte das chamadas nas redes IP
A7

quando comparado com as

redes TDM (Time Divison Multiplexing) tradicionais,

decorrentes da maior eficincia de ocupao de banda e simplicidade.

Em essncia, a tecnologia VoIP representa uma mudana revolucionria para as redes de
telecomunicaes atuais, exigindo a substituio de boa parte de seus componentes por
novos mdulos baseados na arquitetura IP, incluindo os equipamentos terminais, com
vantagens ainda um pouco nebulosas, padres no totalmente consolidados, tecnologias
ainda no completamente maduras e expectativas de longo prazo para retorno dos
investimentos. Dessa forma, as grandes Operadoras mundiais ainda caminham a passos
lentos e cautelosos em direo a essa migrao, sobretudo em funo da grande capacidade
ociosa das redes de transmisso implantadas com o boom do final da dcada de 90, onde se
projetava uma demanda exponencial por servios maravilhosos e vidos por banda larga,
que acabou no acontecendo de fato, comprometendo bastante os investimentos do setor
nos ltimos anos. Uma tecnologia cujo principal benefcio a reduo das tarifas de
servio aos clientes, em nome de uma melhoria na eficincia de aproveitamento das redes
de transporte, cuja capacidade atual deve suprir facilmente a demanda pelos prximos 10
anos sem maiores investimentos, no parece ser a prioridade atual das Operadoras
convencionais, sobretudo das concessionrias, tambm denominadas incumbents.
Nesse

cenrio,

aparecem

oportunidades

para

tecnologias

alternativas,

menos

revolucionrias e no to dependentes de grandes investimentos, dentre as quais a

emulao de circuitos tradicionais atravs de redes de transporte em modo pacotes,
sobretudo redes IP, conciliando as vantagens oferecidas pelas redes baseadas na comutao
de pacotes com a confiabilidade e estabilidade das redes baseadas na comutao de
circuitos, traando o chamado caminho evolucionrio, que prev a evoluo progressiva
das redes existentes em direo ao chamado Mundo IP.
Nessas tecnologias, onde o TDMoIP (Time Division Multiplexing over Internet Protocol),
ou seja, o transporte de circuitos tradicionais multiplexados no tempo sobre redes IP,
representa uma das alternativas, a rede IP efetivamente utilizada como rede de transporte,
mas de forma transparente para os equipamentos terminais, que mantm integralmente suas
funcionalidades e caractersticas, tais como qualidade de udio, protocolos de sinalizao e
interoperabilidade, preservando todos os investimentos realizados e permitindo a
A8

comunicao de voz, dados ou vdeo como se estivessem interligados por uma rede TDM
tradicional baseada em circuitos dedicados ou de alocados de forma determinstica. Isso,
claro, desde que sejam garantidos recursos suficientes dentro da rede IP para garantir a taxa
de transmisso (largura de banda, perdas de pacote) e a qualidade do canal (baixo atraso e
pequena variao nesse atraso).
Essa transparncia obtida atravs de Servios de Emulao de Circuitos ou CES (Circuit
Emulation Services), conceito onde um equipamento de interface colocado junto aos
dispositivos terminais, interagindo com os mesmos como se fosse um equipamento nativo
da rede TDM, empacotando os fluxos de dados e inserindo-os na rede de transporte em
modo pacotes ou PSN (Packet-Switching Network), bem como extraindo os pacotes
recebidos e recompondo o fluxo original TDM. O modelo de referncia desse conceito
CESoPSN (Circuit Emulation Services over Packet-Switched Network) apresentado na
Figura 1.5, para a emulao de um circuito TDM.

Modelo de Referncia CES (TDM) sobre PSN

Interface CES

IWF

Interface TDM

NSP

Servio
TDM

Rede comutada
a Pacotes

Interface TDM
Servio
TDM

Servio TDM Emulado

Interface CES

NSP

IWF

IWF (Interworking functions):

So os elementos de borda da rede comutada a pacotes

(roteadores).

NSP (Native Service Processor):

So os elementos terminais para os equipamentos TDM.

Figura 1.5 - Modelo de referncia CES sobre PSN.

As Figuras 1.6 e 1.7 ilustram os fluxos de transporte e controle envolvidos em uma
conversao entre dois telefones convencionais analgicos atravs de uma rede IP, do
ponto de vista da Operadora de Telecomunicaes. Elas ilustram claramente a diferena de

A9

complexidade e de investimentos entre as duas abordagens apresentadas: revolucionria

(servio VoIP) e evolucionria (servio TDMoIP).
Na Figura 1.6 so apresentados os elementos de rede e protocolos necessrios para o
estabelecimento de uma chamada entre dois telefones convencionais da RTFC (Rede
Telefnica Fixa Comutada) utilizando VoIP.

Signaling
Gateway

Signaling
Gateway

SS7

SS7

SIGTRAN

SIGTRAN

Rede IP
Media Gateway
Controller

Roteador
ISUP

Roteador

MGCP ou
H.248/MEGACO

Roteador

Roteador
Trunking
Gateway

ISUP

MGCP ou
H.248/MEGACO

Fluxo de Mdia
RTP/RTCP

Trunking
Gateway

RTFC

RTFC

Figura 1.6 - Comunicao entre dois telefones convencionais usando VoIP.

Alm da rede de transporte baseada no Protocolo IP e seus roteadores, responsveis pelo
encaminhamento dos pacotes IP, so necessrios, pelo menos, os seguintes elementos
[COLLINS2001]:
a) Dois Trunking Gateways (TG), um conectado RTFC de origem e outro rede de
destino, para realizar a converso do trfego de voz, codificado em PCM (Pulse Code
Modulation) dentro de um canal do circuito TDM (feixe DS0), em um fluxo de pacotes
IP correspondente, na origem, e a converso inversa, no destino;
b) Dois Signaling Gateways (SG), um conectado rede de sinalizao de origem e outro
rede de destino, para realizar a converso das mensagens de sinalizao SS7 do circuito
TDM (canal 16 do feixe E1), em um fluxo de pacotes IP correspondente;
c) Um Media Gateways Controller (MGC) ou Softswitch, conectado aos Trunking
Gateways atravs da rede IP , para realizar o encaminhamento e acompanhamento da
A10

chamada, controlando a troca de pacotes e o tipo de codificao utilizado entre os dois

Trunking Gateways.
Para o encaminhamento, controle e sinalizao da chamada, alm do protocolo de rede IP
(Internet Protocol) e dos protocolos de transporte UDP (User Datagram Protocol) e
RTP/RTCP (Real Time Protocol/Real Time Control Protocol), responsveis pela troca de
pacotes em tempo real entre origem e destino, so necessrios, pelo menos, mais dois
protocolos adicionais dentro da rede:
a) MGCP (Media Gateway Control Protocol) ou MEGACO/ H.248, para permitir ao
Softswitch o controle dos Trunking Gateways;
b) SIGTRAN (SIGnaling TRANsport Protocol) ou similar, para permitir o transporte das
mensagens de sinalizao dentro da rede IP de modo que possam ser interpretadas de
forma adequada pelo Softswitch e pelos Signaling Gateways.
Na Figura 1.7 so apresentados os elementos de rede e protocolos necessrios para o
estabelecimento de uma chamada entre dois telefones convencionais da RTFC (Rede
Telefnica Fixa Comutada) utilizando TDMoIP.

Rede IP
Roteador

Roteador

Roteador
Roteador
Gateway
TDMoIP

Fluxo de Pacotes
UDP

Gateway
TDMoIP

Figura 1.7 - Comunicao entre dois telefones convencionais usando TDMoIP.

A11

Alm da rede de transporte baseada no Protocolo IP e seus roteadores, so utilizados

apenas dois equipamentos conectados aos terminais, denominados Multiplex (MUX) ou
Gateways TDMoIP, que fazem a converso do trfego de voz, codificado em PCM
(realizando tambm essa codificao, no caso de conexo de um telefone analgico) dentro
de um canal do circuito TDM (feixe DS0), em um fluxo de pacotes IP correspondente para
o Gateway TDMoIP localizado na outra extremidade da rede IP, estabelecendo um
circuito ponto-a-ponto entre ambos, que corresponde ao circuito TDM emulado sobre a
rede IP.
A diferena de complexidade entre ambas as tecnologias evidente, caracterizando a
natureza evolucionria da abordagem TDMoIP quando comparada tecnologia VoIP.
Evidentemente, uma outra opo a soluo integralmente VoIP, com a utilizao de
telefones IP ou softphones e protocolos como o SIP (Session Iniciation Protocol) e o H.323
apresenta maior potencial, sobretudo em relao economia de banda em funo da
flexibilidade de codificao da voz e servios como videoconferncia, mensagens
integradas e multi-localizao, mas implica necessariamente em investimentos na
substituio dos equipamentos terminais, alm de no apresentar a maturidade das redes
TDM.
Considerando a situao de uma operadora entrante, que est construindo a sua rede e
visando a conquistar novos clientes ou a situao de um novo provedor de servios
buscando nichos de mercado que rentabilizem seu negcio, a utilizao da tecnologia VoIP
dentro de uma rede completamente convergente para voz, dados e vdeo pode parecer mais
interessante; mas para uma grande Operadora, cuja rede TDM implantada tem valor
significativo, possuindo clientes consolidados onde o investimento em telecomunicaes,
atravs de PBX (Private Branch eXchange) de grande porte e equipamentos similares
significativo, a extenso de circuitos utilizando TDMoIP pode ser uma forma bem mais
segura e interessante de oferecer tarifas competitivas.
Adicionando a isso a expanso observada das redes metropolitanas MAN (Metropolitan
Area Networks) e mesmo redes WAN (Wide Area Networks) baseadas na simplicidade e
robustez da tecnologia Ethernet (Metro Ethernet, Gigabit Ethernet e 10-Gigabit Ethernet),
A12

a interconexo direta de equipamentos TDM a essas redes, atravs de gateways TDMoIP,

pode ser um negcio bastante atrativo para os clientes finais, integrando suas redes de voz
e dados de forma simples e sem grandes investimentos adicionais, substituindo
integralmente todas as linhas dedicadas alugadas da Operadora tradicional, que apresentam
tarifas elevadas e independentes da sua utilizao efetiva e do volume de trfego cursado,
pelo acesso rede de transporte em modo pacotes de um provedor independente, onde a
largura de banda pode ser contratada de forma flexvel adequada s reais necessidades de
comunicao do cliente, com evidentes vantagens econmicas.
As tecnologias Metro Ethernet como rede de transporte metropolitana e TDMoIP como
interface de acesso podem assim ser consideradas complementares entre si, representando
real possibilidade de competio dentro do mercado das linhas dedicadas ponto a ponto
as chamadas leased lines - para a transmisso de voz e/ou dados em grandes corporaes,
hoje praticamente um monoplio das Operadoras locais, as chamadas incumbents,
favorecendo bastante a criao de redes e expanso de pontos de presena para Operadoras
entrantes e Provedores Internet.
A disseminao do acesso em banda larga, que alcanou 4,7 milhes de linhas no Brasil em
junho de 2006 segundo estudos da CISCO Systems [CISCO], ainda com forte
predominncia das tecnologias xDSL (Digital Subscriber Lines), outro importante fator
que pode alavancar a tecnologia TDMoIP como alternativa ao servio convencional
dedicado e mesmo aos servios VoIP, sobretudo para usurios empresariais de pequeno e
mdio porte que desejem preservar seus pequenos PBX, reduzindo os custos com
telecomunicaes sem investir muito ou se aventurar em solues duvidosas oferecidas por
pequenos provedores VoIP, com planos de negcio ainda no consolidados ou tecnologias
de pouca maturidade.
Dessa forma, inclusive pela total eliminao dos dispendiosos circuitos dedicados
interurbanos atravs do transporte pelas redes IP, os custos dessas linhas para os clientes
finais tendem a cair muito nos prximos anos, favorecendo a formao de redes privadas
de baixo custo baseadas em TDM.

A13

Como exemplo disso, a Tabela 1.2 apresenta uma comparao entre o custo mensal de
alguns circuitos interurbanos baseados em linhas dedicadas da operadora Brasil Telecom,
representados pelos produtos da famlia BrT Link, com o servio de conectividade IP com
qualidade assegurada, o produto Vetor; e o servio IP Dedicado de conexo, ambos
tambm da Brasil Telecom, para velocidades equivalentes a um circuito E1 (2Mbps). Os
valores utilizados correspondem aos preos mximos praticados, vigentes em
novembro/2006, obtidos com a Gerncia de Produtos e Servios daquela operadora.
Tabela 1.2 Custos mensais dos produtos Brasil Telecom para voz e dados.
Produto
VoiceLink
G.703
30 canais
DataLink
2 Mbps
VideoLink
2 Mbps
Vetor (MPLS)
2 Mbps
Classe Dados*
Vetor (MPLS)
2 Mbps
Classe Dados
Expressos*
Vetor (MPLS)
2 Mbps
Classe
Multimdia**
Vetor (MPLS)
2 Mbps
Classe Voz**
IP Dedicado
(100% Banda
assegurada)
2 Mbps

Circuito Braslia
Porto Alegre

Circuito
Braslia So Paulo

Circuito
Braslia
Rio de Janeiro

Circuito
Braslia Belo
Horizonte

Circuito
Braslia
Cuiab

R$ 13.000,00

R$ 10.787,40

R$ 11.500,00

R$ 11.500,00

R$ 13.000,00

R$ 23.507,91

R$ 9.727,71

R$ 9.484,51

R$ 8.322,74

R$ 24.061,95

R$ 15.500,00

R$ 14.000,00

R$ 15.000,00

R$ 15.000,00

R$ 15.500,00

R$ 7.605,02

R$ 7.227,84

R$ 7.529,87

R$ 6.870,54

R$ 7.671,16

R$ 9.489,21

R$ 9.057,69

R$ 9.428,67

R$ 8.618,65

R$ 9.569,96

R$ 12.116,27

R$ 11.802,14

R$ 12.051,05

R$ 11.289,26

R$ 11.030,45

R$ 9.063,20

R$ 9.847,89

R$ 10.126,93

R$ 8.541,76

R$ 10.268,23

R$ 4.700,00

R$ 4.700,00

R$ 4.700,00

R$ 4.700,00

R$ 4.700,00

* Inclui a locao mensal do roteador, no valor de R$ 270,00.

** Inclui a locao mensal do roteador para voz e dados, no valor de R$ 3.500,00.
Dessa tabela, pode ser observado que a utilizao do servio IP Dedicado para o
entroncamento de PBX, ao invs do VoiceLink tradicional, representaria uma reduo de
60% nos custos de transporte. Da mesma forma, a utilizao do Vetor (classe Dados) ou do
prprio IP Dedicado, ao invs do VideoLink oferecido s grandes redes de televiso para o
transporte de vdeo digital, representaria uma reduo, respectivamente, de 50% ou 70%
nos custos de transporte.

A14

Considerando ainda a opo, bem mais arriscada, de utilizao da Internet como rede de
transporte, o custo mensal mdio seria de R$ 253,00, para acessos entre 2 e 8Mbps,
conforme estudo apresentado em [CISCO2006] para os meses de abril a junho/2006, mais
R$ 100,00 com a locao do par de modems HDSL, ou seja, uma reduo superior a 90%
nos custos de transporte.
A alternativa TDMoIP est disponvel comercialmente desde 1999, quando sua primeira
gerao foi implantada pela operadora sueca UTFORS (adquirida em 2002 pela gigante
norueguesa TELENOR) como soluo para oferecimento de linhas dedicadas e servios
similares baseados em IP/Ethernet no mercado da Sucia. Nos anos seguintes, a tecnologia
TDMoIP foi implantada nos Estados Unidos, Frana, Inglaterra, ustria, frica, Rssia,
Turquia, China e Austrlia, possuindo mais de 40.000 portas E1/T1 nesses pases segundo
os dados apresentados por seu principal fabricante, a RAD Data Communications,
responsvel pelo registro da marca TDMoIP driven e por uma linha de equipamentos
para a construo de redes e servios baseados nessa tecnologia.
A tecnologia TDMoIP permite que pequenas empresas de telecomunicaes, assim como
provedores de servios IP em geral, possam ser bastante competitivos na disputa com as
grandes Operadoras pelo chamado Mercado Empresarial, constitudo pelas pequenas e
mdias empresas; e pelos pequenos escritrios e o nmero crescente de usurios que
trabalham em suas residncias, conhecidos como SOHO (Small Office/Home Office).
Segundo analistas, esse o segmento do mercado de telecomunicaes onde a competio
de fato acirrada, sendo o grande foco corrente das Operadoras devido ao potencial de
rentabilidade existente, uma vez que o Mercado Corporativo encontra-se saturado e com
baixssimas margens, em virtude da poltica predatria de preos praticada ao longo dos
ltimos anos, quando as redes de dados viraram uma commoditie, e o atendimento ao
Mercado Massa implica em vultosos investimentos em capilaridade, o que praticamente
garante o seu completo domnio pelas grandes Operadoras, restringindo-se a competio ao
pequeno universo de clientes mais rentveis e concentrados nos grandes aglomerados
urbanos.
Outra grande possibilidade da alternativa TDMoIP a reduo de custos operacionais
para as Operadoras mveis, sobretudo aquelas que operam de forma independente, uma
A15

vez que o uso de linhas dedicadas alugadas, tipicamente feixes T1 (1,544 Mbps, USA,
Japo) ou E1 (2,048 Mbps, Brasil, Europa) para a interligao de suas estaes rdio-base
s centrais de comutao e controle respondem por grande parte de seus custos de rede. Em
reas metropolitanas cobertas por redes de transporte comutadas em modo pacotes, como
Metro Ethernet e Gigabit Ethernet, a substituio dessas linhas dedicadas por gateways
TDMoIP para a interconexo das estaes rdio-base pode ser relativamente simples e
economicamente muito vantajosa.
Considerando todo esse cenrio, o objetivo deste trabalho aprofundar o estudo sobre a
alternativa TDMoIP e suas abordagens similares dentro do conceito de emulao de
circuitos sobre redes de transporte em modo pacotes (CESoPSN), em especial os circuitos
TDM sobre redes IP, com a finalidade de propor, discutir e validar essa tecnologia como
uma possvel alternativa de baixo custo para broadcasting de contedo de vdeo/udio
integrado a baixas taxas de transmisso, tipicamente at 1,5Mbps, permitindo a sua
produo e distribuio independente para fins sociais, educacionais e de entretenimento,
possibilitando, qui, dois grandes desdobramentos:
a) A disseminao de canais de servios IPTV (Internet Protocol TeleVision) com baixo
custo de transmisso e reduzido investimento em equipamentos, utilizando o mesmo
conceito das chamadas TVs corporativas, existentes nas grandes empresas, a fim de
levar contedo customizado e interativo a escolas, programas sociais de incluso
digital, ONGs (Organizaes No Governamentais) que promovam educao e
cidadania e outras instituies de carter educacional e social que desejem utilizar esses
contedos em seus programas de atendimento s comunidades;
b) A criao de uma rede nacional, interligada pela Internet ou outra rede capaz de prover
conectividade IP com maior disponibilidade de largura de banda, de emissoras locais de
TV para distribuio desse contedo, via interface de rdio convencional VHF (Very
High Frequency), com modulao analgica VSB (Vestigial-Sided Band) e canais de
6MHz, compatveis com a totalidade dos receptores existentes no Brasil e em boa parte
do mundo, com foco nas comunidades de baixa renda e nas regies menos atendidas,
contribuindo para a democratizao de acesso informao disponvel atravs da
Internet ou gerada de forma livre por produtores independentes, permitindo que esse
contedo chegue aos usurios finais desejados sem a necessidade de competio por
espao na programao das grandes redes de TV aberta do pas;
A16

Para tanto, foram definidas duas grandes Metas para direcionamento desse estudo, a fim de
delimitar o escopo a ser abordado na dissertao e definir ferramentas, cenrios e critrios
de anlise utilizados na implementao e avaliao dos resultados experimentais:
a) Demonstrar que a tecnologia TDMoIP com sincronizao adaptativa mais barata que
PDH/SDH dedicado e mais simples e eficiente que as principais tecnologias VoIP
(Voice over IP) utilizando o protocolo RTP, no transporte fim a fim de troncos de voz
TDM convencionais;
b) Validar (ou no) a tecnologia TDMoIP com sincronizao adaptativa pelo receptor
como alternativa simples e barata ao ATM/SDH para transporte de TV digital de baixa
definio, em qualidade compatvel com a TV analgica atual, e para broadcasting
IPTV a baixas taxas (at 1,5Mbps).
Com esses objetivos, o trabalho est organizado da seguinte forma:
No captulo 2 aprofundado o conceito de emulao de circuitos, sendo propostos novos
mecanismos para melhorar a robustez das solues existentes para os desafios enfrentados:
o seqenciamento dos pacotes e a recuperao do relgio de transmisso no receptor. Na
seqncia, feita uma comparao entre algumas caractersticas da emulao TDM e
VoIP, encerrando com aplicaes da tecnologia TDM sobre IP.
No captulo 3 abordada a transmisso de vdeo digital, com seus padres de codificao,
introduzindo em seguida o conceito de IPTV e suas principais tecnologias, para ento
propor as adequaes necessrias abordagem TDM sobre IP a fim de permitir sua
utilizao como alternativa para broadcasting de servios IPTV similares.
No captulo 4 realizada a validao dos novos mecanismos propostos, atravs da
simulao dos algoritmos e sua implementao em uma aplicao simples para TDM sobre
IP, utilizando Java. Alm disso, feita a experimentao de uma soluo comercial para
essa tecnologia, analisando seu desempenho e comparando-o com a soluo proposta.
Finalmente, no captulo 5, so feitas as concluses do trabalho, com base nos resultados de
validao e experimentao, apresentando tambm propostas para trabalhos futuros.

A17

A18

2 - EMULAO DE CIRCUITOS TDM EM REDES IP

2.1 - A EMULAO DE CIRCUITOS EM REDES DE PACOTES

O trfego mundial de telecomunicaes, em especial o de telefonia, convencionalmente
transportado atravs de circuitos dedicados, que consistem em enlaces bidirecionais
orientados a conexo, operando de forma sncrona ou plesicrona, e organizados em
agrupamentos de diferentes nveis, denominados hierarquias. Essas hierarquias so
conhecidas por redes ou servios TDM (Time-Divison Multiplexing), em funo da
caracterstica de compartilhamento do meio de transmisso utilizada, ou seja a
multiplexao por diviso de tempo, onde cada canal transmitido dentro de um intervalo
de tempo (timeslot) pr-definido e fixo durante a conexo.
A emulao de circuitos, ou CES (Circuit Emulation Services) uma tecnologia que
permite o transporte de servios TDM, tais como feixes E1/T1/E3/T3 da hierarquia digital
plesicrona, ou PDH (Plesiochronous Digital Hierarchy) e circuitos SONET/SDH
(Synchronous Optical Network/Synchronous Digital Hierarchy), atravs de redes de
transporte comutadas em modo pacotes, ou PSN (Packet-Switching Networks). A CES foi
originalmente concebida na dcada de 1990, dentro do chamado Mundo ATM
(Assynchronous Transfer Mode) [ATM1997]. A idia foi trazida para dentro das redes
comutadas a pacotes por uma srie de organismos internacionais ligados s redes de
telecomunicaes, como a IETF (Internet Engineering Task Force), o MEF (Metro
Ethernet Forum) e o MPLS (Multi-Protocol Label Switching ) Frum.
Os principais padres CES esto sendo definidos pelo grupo de trabalho PWE3 (PseudoWire Emulation Edge-to-Edge), constitudo pela IETF em 2001, com o objetivo de
desenvolver mtodos para transportar servios das camadas 1 e 2 atravs de redes
comutadas em modo pacotes, em especial IP e MPLS. Como principal trabalho desse
grupo foram geradas trs RFCs (Request for Comments) bsicas, documentos normativos
publicados pela IETF, estabelecendo os Requisitos para PWE3 [RFC3916], a Arquitetura
para PWE3 [RFC3985] e os Requisitos Especficos para Emulao de circuitos TDM
A19

atravs de PWE3 sobre redes comutadas em modo pacotes [RFC4197]; alm de quatro
RFCs abordando questes complementares, como o estabelecimento e manuteno de
pseudo-circuitos atravs do protocolo LDP (Label Distribution Protocol) [RFC4447],
mtodos de encapsulamento para o transporte Ethernet sobre redes MPLS [RFC4448],
alocaes IANA (Internet Assigned Numbers Authority) para PWE3 [RFC4446] e
definio da palavra de controle PWE3 para uso sobre redes MPLS [RFC4385]; bem como
alguns Internet-Drafts associados [IETF2006] [IETF2006a] [IETF2006b], j em chamada
final para publicao como RFCs, que vm orientando a maioria dos estudos sobre o
assunto e sero descritos na seqncia do trabalho.
2.1.1 - Os requisitos da emulao PWE3 de circuitos TDM sobre PSN
A RFC4197 define requisitos especficos para a Emulao de Pseudo-Circuitos Fim a Fim
(PWE3) no transporte de sinais digitais multiplexados TDM, tanto da Hierarquia Digital
Plesicrona (PDH) como da Hierarquia Digital Sncrona/Rede ptica Sncrona
(SDH/SONET), estabelecidos sobre redes de transporte comutadas em modo pacotes
(PSN), de forma alinhada com a Arquitetura PWE3 [RFC3985], descrita no Apndice A e
fazendo referncia aos requisitos aplicveis PWE3 [RFC3916], listados no Apndice B.
Esses requisitos especficos decorrem das caractersticas particulares dos servios TDM:

Necessidade de sincronizao entre os relgios dos Circuitos de Acesso (AC) de

origem e destino em cada uma das direes do pseudo-circuito;

Necessidade de manter o jitter e a flutuao (wander) do relgio, para o fluxo de dados

entregue ao AC de destino, dentro dos limites impostos pelos documentos normativos,
na presena das grandes variaes no atraso dos pacotes produzidas pela PSN.

Alm de caractersticas intrnsecas s aplicaes que utilizam circuitos TDM, como, por
exemplo, aplicaes de voz:

Necessidade de especial nfase na reduo dos atrasos de transmisso;

Relativa tolerncia a erros nos dados transmitidos.

Que so diferentes das caractersticas de outras aplicaes, como, por exemplo, o

transporte de informaes de sinalizao:

Relativa tolerncia aos atrasos de transmisso;

Extrema sensibilidade a erros nos dados transmitidos.

A20

2.1.2 - Modelo de referncia PWE3 para sincronizao de rede

A Figura 2.1 apresenta um Modelo de Referncia genrico para a sincronizao de redes
dentro da Arquitetura PWE3, envolvendo a seguinte notao:
CE1, CE2

so os Equipamentos Clientes onde terminam os circuitos TDM emulados;

PE1, PE2

so os Equipamentos Provedores que adaptam o servio nativo TDM ao

pseudo-circuito;

S1, S2

so os roteadores de ncleo da rede comutada em modo pacotes;

Phy

a interface fsica onde termina o circuito TDM;

Enc

a interface no PE de origem do pseudo-circuito, onde o encapsulamento

dos fluxos de dados realizado;

Dec

interface

no

PE

de

destino

do

pseudo-circuito,

onde

desencapsulamento dos fluxos de dados realizado. Essa interface contm

um buffer de compensao, tambm conhecido como jitter buffer, de
tamanho limitado;

=====>

so os Circuitos de Acesso (AC) para os circuitos TDM;

-------->

so os Pseudo-Circuitos (PW) provendo emulao fim a fim para os

circuitos TDM.

CkCE1

o relgio local (oscilador) disponvel e utilizado pelo CE1 para

transmisso do fluxo de dados TDM atravs do circuito de acesso em
direo a CE2;

Ck(R)CE1

o relgio recuperado por PE1 a partir do fluxo de dados TDM que chega
pelo circuito de acesso. CkCE1 e Ck(R)CE1 tm sempre a mesma freqncia;

Ck(Rp)PE2

o relgio utilizado pelo PE2 para transmisso do fluxo de dados TDM

atravs do circuito de acesso em direo a CE2, recuperado a partir dos
pacotes recebidos atravs do pseudo-circuito;

Ck(RpR)PE2 o relgio novamente recuperado por CE2 a partir do fluxo de dados TDM
que chega de PE2 pelo circuito de acesso. Ck(Rp)PE2 e Ck(RpR)PE2 tm
sempre a mesma freqncia;
CkCE2

o relgio local (oscilador) disponvel utilizado pelo CE2 para transmisso

do fluxo de dados TDM atravs do circuito de acesso em direo a CE1;

A21

Ck(R)CE2

o relgio recuperado por PE2 a partir do fluxo de dados TDM que chega
pelo circuito de acesso. CkCE2 e Ck(R)CE2 tm sempre a mesma freqncia;

Ck(Rp)PE1

o relgio utilizado pelo PE1 para transmisso do fluxo de dados TDM

atravs do circuito de acesso em direo a CE1, recuperado a partir dos
pacotes recebidos atravs do pseudo-circuito;

Ck(RpR)PE1 o relgio novamente recuperado por CE1 a partir do fluxo de dados TDM
que chega de PE1 pelo circuito de acesso. Ck(Rp)PE1 e Ck(RpR)PE1 tm
sempre a mesma freqncia;
CkPE1

o relgio (oscilador) local disponvel em PE1;

CkPE2

o relgio (oscilador) local disponvel em PE2;

CkPSN

o relgio comum de referncia da rede PSN, se existente, disponvel em

PE1 e PE2;

CkTDM

o relgio comum de referncia da rede TDM, se existente, disponvel em

CE1 e CE2, representando um caso particular, pois diferentes pares de
Equipamentos Cliente podem utilizar diferentes relgios de referncia,
sobretudo se pertencem a redes TDM distintas.

PE1

Ck(RpR)PE1

PE2
Rede de Pacotes

Ck(Rp)PE1

Phy

CE1

Dec

Phy

S1

Phy

Enc

S2

Phy

S1

Phy

Enc

Phy

Circuito de Acesso

S2

Phy

Dec

Phy

CE2

Ck(Rp)PE2

Ck(R)CE1
CkCE1

Ck(R)CE2

Pseudo-Circuito

Circuito de Acesso

CkCE2

Ck(RpR)PE2

CkPSN
CkPE1

CkPE2
CkTDM

Figura 2.1 - Modelo de referncia PWE3 para sincronizao de rede.

O requisito bsico da emulao fim a fim de um circuito TDM que tanto os relgios
Ck(R)CE1 e Ck(Rp)PE2, como os relgios Ck(R)CE2 e Ck(Rp)PE1 estejam na mesma
A22

freqncia. O mtodo mais adequado para garantir isso depende do esquema de

sincronizao da rede. Podem ser considerados os seguintes cenrios de sincronizao:
a) Cenrios de Sincronizao atravs de Redes Sncronas:
Dependendo de qual parte da rede sincronizada atravs de um relgio comum, existem
dois cenrios distintos:
a.1) Redes Sincronizadas pelo Equipamento Provedor (PE):
A Figura 2.2 a verso do Modelo de Referncia para sincronizao da rede, apresentando
o cenrio de sincronizao pelo PE:

O relgio comum de referncia da rede PSN CkPSN est disponvel para todos os
equipamentos PE, e os osciladores locais CkPE1 e CkPE2 so fixados em CkPSN.

Os

relgios Ck(Rp)PE2 e Ck(Rp)PE1 so os mesmos que CkPE2 e CkPE1,

respectivamente;

Os relgios CkCE1 e CkCE2 so os mesmos que Ck(RpR)PE1 e Ck(RpR)PE2,

respectivamente, ou seja, CE1 e CE2 utilizam um enlace fechado para sincronizao.

PE1

Ck(RpR)PE1

PE2

Ck(Rp)PE1

Phy

CE1

Dec

Phy

S1

Circuito de Acesso

Phy

Enc

CkCE2

Rede de Pacotes

Phy

Pseudo-Circuito

S1

S2

Phy

Enc

Phy

Circuito de Acesso

S2

Phy

Dec

Phy

CE2

Ck(Rp)PE2
CkCE1

Ck(RpR)PE2
CkPE1

CkPE2
CkPSN

Figura 2.2 - Cenrio de rede sincronizada pelo PE.

a.2) Redes Sincronizadas pelo Equipamento Cliente (CE):
A Figura 2.3 a verso do Modelo de Referncia para sincronizao da rede, apresentando
o cenrio de sincronizao pelo CE:

O relgio comum de referncia da rede TDM CkTDM est disponvel para todos os
equipamentos CE, e os osciladores locais CkCE1 e CkCE2 so fixados em CkTDM
A23

Os

relgios Ck(Rp)PE2 e Ck(Rp)PE1 so os mesmos que CkCE2 e CkCE1,

respectivamente, ou seja, PE1 e PE2 utilizam um enlace fechado para sincronizao.

PE1

PE2
Rede de Pacotes

Ck(Rp)PE1

Phy

CE1

Dec

Phy

S1

Circuito de Acesso

Phy

Enc

Phy

Pseudo-Circuito

S1

Ck(R)CE2

S2

Phy

Enc

Phy

Circuito de Acesso

S2

Phy

Dec

Phy

CE2

Ck(Rp)PE2

Ck(R)CE1
CkCE1

CkCE2

CkTDM

Figura 2.3 - Cenrio de rede sincronizada pelo CE.

Nenhuma informao de sincronizao precisa ser transmitida atravs do pseudo-circuito
para esses dois casos.
b) Cenrio de Sincronizao Relativa:
Neste caso, cada CE utiliza a sua prpria fonte de relgio de transmisso, que
transportada atravs da PSN e recuperada pelo respectivo PE remoto. A Figura 2.4 a
verso do Modelo de Referncia para a sincronizao relativa da rede nesse cenrio:

O relgio comum de referncia da rede PSN CkPSN est disponvel para todos os
equipamentos PE, e os osciladores locais CkPE1 e CkPE2 so fixados em CkPSN.

Os relgios CkCE1 e CkCE2 so gerados localmente, sem referncia a um relgio

comum;

Os

relgios Ck(Rp)PE2 e Ck(Rp)PE1 so os mesmos que CkPE2 e CkPE1,

respectivamente, que por sua vez so gerados com referncia ao relgio comum
disponvel para todos os equipamentos PE, CkPSN;

A24

Em uma pequena modificao desse cenrio, um e apenas um - dos equipamentos CE

pode utilizar o relgio recuperado a partir do fluxo de dados TDM que chega do respectivo
PE pelo circuito de acesso Ck(RpR)PE2, por exemplo, como seu relgio de transmisso
CkCE2, no exemplo, utilizando um enlace fechado para sincronizao.
Neste caso, a informao de sincronizao, correspondente diferena entre o relgio de
referncia comum CkPSN e o relgio independente CkCE1, por exemplo, precisa ser
explicitamente transferida do PE de origem para o PE de destino.

PE1

Ck(RpR)PE1

PE2

Ck(Rp)PE1

Phy

CE1

Dec

Phy

S1

Circuito de Acesso

Phy

Enc

CkCE2

Rede de Pacotes

Phy

Pseudo-Circuito

S1

S2

Phy

Enc

Phy

Circuito de Acesso

S2

Phy

Dec

Phy

CE2

Ck(Rp)PE2
CkCE1

Ck(RpR)PE2
CkPE1

CkPE2
CkPSN

Figura 2.4 - Cenrio de sincronizao relativa.

c) Cenrio de Sincronizao Adaptativa:
O cenrio de sincronizao adaptativa caracterizado pela completa independncia entre
os relgios de origem e destino, tanto dos Equipamentos Clientes (CEs) e circuitos TDM
nativos como dos Equipamentos Provedores (PEs) e a rede PSN, tornando a sincronizao
entre o relgio de transmisso utilizado pelo CE de origem e o relgio recuperado pelo PE
de destino muito mais difcil que nos outros cenrios. A Figura 2.5 a verso do Modelo
de Referncia para a sincronizao adaptativa da rede nesse cenrio:

Nenhum relgio comum de referncia da PSN CkPSN est disponvel para PE1 e PE2;

Nenhum relgio comum de referncia TDM CkTDM est disponvel para CE1 e CE2.

A25

PE1

Ck(RpR)PE1

PE2
Rede de Pacotes

Ck(Rp)PE1

Phy

CE1

Dec

Phy

S1

Circuito de Acesso

Phy

Enc

Phy

Pseudo-Circuito

S1

CkCE2

Ck(R)CE2

S2

Phy

Enc

S2

Phy

Dec

Phy

Circuito de Acesso

Phy

CE2

Ck(Rp)PE2

Ck(R)CE1
CkCE1

Ck(RpR)PE2

Figura 2.5 - Cenrio de sincronizao adaptativa.

Deve ser observado que a tolerncia entre os relgios CkCE1 e Ck(Rp)PE2 e entre os
relgios CkCE2 e Ck(Rp)PE1 deve ser pequena o bastante para assegurar que o jitter buffer
no tenha sua capacidade esgotada (overflow) ou seja rapidamente esvaziado (underflow),
causando a perda de continuidade do fluxo de dados TDM.
Neste caso, a informao de sincronizao, correspondente diferena entre o relgio de
transmisso CkCE1, por exemplo, e o relgio recuperado a partir dos pacotes Ck(Rp)PE2,
no mesmo exemplo, pode ser explicitamente transferida do PE de origem para o PE de
destino atravs do protocolo RTP ou mecanismo similar.
2.1.3 - As diversas propostas para emulao de circuitos TDM sobre PSN
Os esforos de padronizao das tecnologias para Emulao de Servios TDM sobre redes
de transporte com comutao em modo pacotes vem sendo desenvolvidos em diversos
fruns tcnicos e organismos internacionais de padronizao. Na IETF, isso est sendo
conduzido pelo Grupo de Trabalho PWE3, que aborda a emulao de servios fim a fim
atravs de pseudo-circuitos, descrito anteriormente e fonte dos principais documentos
abordados. No ITU-T, o Grupo de Estudo 13 (SG13) conduz o assunto, tendo desenvolvido
a Recomendao ITU-T Y.1414 para servios de voz sobre MPLS [ITU-T Y1414] e a
A26

Recomendao ITU-T Y.1413 sobre a interoperabilidade entre redes TDM e MPLS [ITU-T
Y1413]. Esse assunto tambm foi discutido pelo MPLS Forum [STEIN2003].
Dessa forma, diversos documentos tm sido gerados e revisados, caracterizando diversas
propostas distintas, cada uma abordando aspectos particulares do transporte TDM sobre as
redes de pacotes, conforme mostrado na Figura 2.6.

Emulao TDM
Taxas Clientes

Taxas Operadoras

(T1/E1/T3/E3)

Sem Conscincia
da Estrutura
(Structure-Agnostic)

SAToP

(SONET/SDH)

Consciente da
Estrutura
(Structure-Aware)

CESoPSN

TDMoIP

CEP

Figura 2.6 - Correntes da emulao TDM sobre redes de pacote.

Existem atualmente duas linhas de estudo dentro do grupo IETF PWE3, uma focada no
transporte TDM com elevadas taxas de transmisso, compatveis com os backbones das
grandes Operadoras, denominado CEP (SONET/SDH Circuit Emulation over Packet), ou
emulao de circuitos SONET/SDH sobre pacotes, definido pelo respectivo Internet-Draft
[IETF2006b]; e outra com foco no transporte TDM com taxas mais baixas, utilizadas pelos
clientes dessas Operadoras, por sua vez subdividida em trs propostas distintas:

SAToP (Structure-Agnostic TDM over Packet), ou transporte de servios TDM sobre

pacotes sem conscincia da estrutura,

definido pelo respectivo Internet-Draft

[RFC4553], que encontra-se na fila para publicao como RFC pela IETF ainda em
2006.

A27

CESoPSN (Structure-aware TDM Circuit Emulation Service over Packet Switched

Network), ou servio de emulao de circuitos TDM, consciente da estrutura, sobre
rede de pacotes, definido pelo respectivo Internet-Draft [IETF2006a].

TDMoIP (TDM over IP), ou transporte consciente da estrutura de servios TDM

sobre redes IP, posteriormente generalizada para outras redes, como MPLS, L2TPoIP e
Ethernet, criando o termo TDMoPW (TDM over Pseudo-Wire), ou transporte de
servios TDM sobre pseudo-circuitos,

definido pelo respectivo Internet-Draft

[IETF2006]. A nomenclatura original TDMoIP vem sendo mantida nos documentos

por consistncia histrica, mas hoje marca registrada da RAD Data Communications,
que cedeu IETF os direitos perptuos de reproduo para fins de desenvolvimento da
padronizao pelo grupo PWE3.
O SAToP um protocolo para transporte de servios TDM sobre pseudo-circuitos que trata
os dados TDM como um fluxo arbitrrio de bits, dividido em pacotes com tamanho fixo e
bem definido, conforme configurado entre os PEs de origem e destino, desprezando
completamente qualquer estrutura que possa existir dentro dele. Dessa forma, esse
protocolo adequado para o transporte de fluxos TDM efetivamente no estruturados,
como canais de vdeo codificados de forma digital; e para o transporte de fluxos TDM
estruturados onde no existe necessidade de preservar a integridade da estrutura, interpretar
ou manipular canais individuais durante esse transporte.
A abordagem SAToP adequada para PSNs que apresentam perda de pacotes em nveis
desprezveis e aplicaes que no requerem discriminao entre canais e nem interveno
na sinalizao TDM. Quando um pacote SAToP perdido, um padro todos os bits iguais
a um enviado interface TDM, o qual interpretado pelo terminal TDM de destino
como uma indicao AIS, que imediatamente dispara uma condio de falha para o
circuito. Essa condio admissvel por apenas 0,2% do tempo de utilizao do circuito,
conforme estabelecido pela Recomendao ITU-T G.826, de forma que o protocolo
SAToP, apesar de encontrar-se em estgio mais avanado de padronizao em virtude da
publicao iminente da respectiva RFC, tem sua aplicao limitada s redes de pacotes
extremamente confiveis e dotadas de disponibilidade excedente de largura de banda.

A28

Como essas condies no podem ser assumidas de maneira geral para as redes de pacotes,
o transporte TDM consciente de estrutura pode ser uma alternativa mais adequada para
muitas aplicaes, uma vez que nesse caso possvel preservar explicitamente a estrutura
TDM durante o transporte sobre a PSN, tornando possvel a mitigao efetiva das
eventuais perdas de pacotes.
O transporte consciente de estrutura leva em considerao pelo menos algum elemento da
estrutura TDM para aumentar a sua robustez em relao s perdas de pacote e outros
elementos no-determinsticos associados PSN. Os pseudo-circuitos TDM conscientes de
estrutura no necessitam transportar o overhead dessa estrutura atravs da rede de pacotes,
permitindo a eliminao de elementos como o FAS, que pode ser regenerado no PE de
destino. Outras vantagens dessa abordagem so a separao dos timeslots individuais
relativos a cada canal, permitindo a utilizao de tcnicas avanadas para a mitigao de
perdas de pacote; a identificao clara da sinalizao TDM, simplificando os mecanismos
para a sua utilizao e manuteno; e finalmente a conservao de largura de banda, atravs
de mecanismos para deteco de atividade de voz e/ou interpretao da sinalizao,
evitando a transmisso de timeslots ociosos.
Existem trs mtodos para assegurar a integridade fim a fim da estrutura TDM, cada um
com as suas vantagens e caractersticas especficas:

Fixao de estrutura (structure-locking) necessita que cada pacote seja montado a

partir do comeo de uma determinada estrutura TDM, seja ela um canal, um quadro ou
um multi-quadro, contendo sempre uma ou mais dessas estruturas completas. o
mtodo definido pela abordagem CESoPSN, que pressupe a transmisso independente
de cada canal Nx64Kbps, de forma a permitir a sua alocao dinmica, otimizando a
utilizao de largura de banda da rede e recompondo o fluxo TDM no PE de destino.

Indicao de estrutura (strutcure-indication) permite que os pacotes contenham

fragmentos arbitrrios das estruturas bsicas, mas emprega ponteiros para indicar onde
cada estrutura comea. o mtodo definido pela abordagem TDMoIP quando os
canais podem ser alocados de forma esttica e/ou necessria a interoperabilidade com
circuitos emulados baseados em AAL1 (ATM Adaptation Layer number 1), uma vez
que representa um fluxo de dados do tipo CBR, com taxa de transmisso constante.

A29

Regenerao de estrutura (structure-reassembly) faz sentido apenas para TDM

canalizado, onde o PE de origem extrai e armazena os canais individuais, encapsula
esses canais em pacotes e os transmite atravs da rede; enquanto o PE de destino
regenera a estrutura original com base nos pacotes recebidos, introduzindo o overhead
necessrio. o mtodo definido pela abordagem TDMoIP quando desejada a
alocao dinmica de canais e/ou necessria a interoperabilidade com circuitos
emulados baseados em AAL2 (ATM Adaptation Layer number 2), uma vez que
representa um fluxo de dados do tipo VBR, ou seja, com taxa de transmisso varivel.

Apesar do nome histrico, o protocolo em desenvolvimento segundo a proposta TDMoIP

pode operar sobre diversos tipos de redes de transporte comutadas em modo pacotes,
incluindo UDP (User Datagram Protocol) sobre IPv4 (Internet Protocol version 4) ou IPv6
(Internet Protocol version 6) , MPLS (Multi-Protocol Label Switching), L2TPv3 (Layer 2
Tunneling Protocol version 3) sobre IP, ou mesmo Ethernet pura, cada qual representando
uma das implementaes particulares definidas no respectivo Internet-Draft [IETF2006].
Em funo de suas caractersticas mais aderentes aos objetivos propostos, ou seja, o
transporte transparente de fluxos TDM utilizando redes IP como backbone para
transmisso de aplicaes de vdeo envolvendo taxas at 34Mbps (E3), sero aprofundadas
neste trabalho apenas as propostas SAToP, por ser a alternativa mais simples para o
transporte no consciente de estrutura atravs de redes homogneas com garantia de QoS, e
TDMoIP, por ser uma alternativa mais abrangente e robusta, permitindo o transporte
atravs de redes menos confiveis, em funo da camada de adaptao e da possibilidade
de utilizar sincronizao adaptativa.
A Tabela 2.1 apresenta um resumo das principais caractersticas de cada uma dessas
propostas para o transporte de circuitos TDM sobre redes comutadas em modo pacotes:

A30

Tabela 2.1 Comparao entre as propostas para transporte TDM sobre PSN.

Taxas de
Transmisso
Conscincia da
Estrutura
Adaptao do
Fluxo de Dados
Alinhamento
de Quadros
Tratamento de
Perdas de
Pacote
Palavra de
Controle
Nmero de
Seqncia
Utilizao
Protocolo RTP
Redes de
Pacotes
Compatveis
Tamanho por
Pacote (E1)

TDMoIP/
VBR
N x 64kbps

Sim

TDMoIP/
CBR
T1/E1 e
T3/E3
Sim

Inexistente

Inexistente

AAL1

AAL2

Inexistente
Padro de
uns

Fixao de
Estrutura
Permite
Mitigao

Indicao de
Estrutura
Permite
Mitigao

Regenerao
de Estrutura
Permite
Mitigao

32 bits

32 bits

32 bits

32 bits

16 bits
sem sinal
Opcional
(Se relgio
comum PEs)
UDP/IPv4-6
L2TPv3
MPLS

16 bits
sem sinal
Opcional
(Para relgio
comum PEs)
UDP/IPv4-6
L2TPv3
MPLS

Overhead
+
N x 256 bytes

Overhead
+
N x 32 bytes
(1ms a 5ms)

16 bits
sem sinal
Opcional
(Para relgio
comum PEs)
UDP/IPv4-6
L2TPv3
MPLS
Ethernet
Overhead
+
N x 48 bytes

16 bits
sem sinal
Opcional
(Para relgio
comum PEs)
UDP/IPv4-6
L2TPv3
MPLS
Ethernet
Overhead
+
N x 48 bytes

11,1%

12,5%

11,9% a
13,8%

15,6%

Dependente do
Servio

Complexa

Complexa

Simples

Simples

Complexa

Overhead para
256 octetos TDM
(UDP/IP s/ RTP)
Compatibilidade
ATM

SAToP

CESoPSN

T1/E1 e
T3/E3
No

N x 64kbps

Sim

CEP
STM-N
N=1,4,16,64
Sim
Dependente do
Servio
Indicao de
Estrutura
Sinalizao de
Erro
Mnimo
64 bits
16 bits
sem sinal
Opcional
UDP/IPv4-6
L2TPv3
MPLS
Overhead
+
N x 783 bytes
(STS-N)

2.2 - SERVIOS TDM SOBRE IP

2.2.1 - Diferenas essenciais entre as redes TDM e redes IP

As redes TDM convencionais baseadas em comutao de circuitos, tambm conhecidas
como CSN (Circuit-Switching Networks), como PDH e SONET/SDH, so fortemente
determinsticas, transmitindo um ou mais octetos desde o equipamento de origem at o
equipamento de destino atravs de um canal dedicado e com largura de banda definida, em
intervalos de 125us.

A31

O atraso sofrido pelos dados que trafegam dentro de uma rede TDM previsvel, baixo e
constante ao longo de todo o perodo da conexo, sendo a sincronizao entre origem e
destino provida atravs dos dados transmitidos e as variaes admitidas no relgio (clock)
TDM so estritamente definidas nas especificaes normativas. Alm disso, a infraestrutura das redes TDM suporta um rico conjunto de facilidades para os usurios atravs
de diversos protocolos de sinalizao, com grande maturidade e elevada confiabilidade.
Por sua vez, as redes de transporte em modo pacotes, conhecidas como PSN (PacketSwitching Networks), como as redes IP e os sistemas MPLS (Multi-Protocol Label
Switching), apresentam-se mais eficientes que as redes TDM devido ao compartilhamento
inerente da largura de banda disponvel. Entretanto, essa capacidade de compartilhamento
leva as redes de pacotes a tornarem-se inerentemente no-determinsticas.
Os dados ou pacotes enviados atravs dessas redes precisam competir pelos recursos
oferecidos, como largura de banda, filas e interfaces dos roteadores, o que causa variao
no atraso sofrido por cada um dos pacotes transmitidos e tambm a sua eventual perda
devido a descarte dentro da rede, em caso de congestionamento ou esgotamento de
recursos. Um equipamento de origem pode introduzir pacotes na rede a intervalos
regulares, semelhana de uma rede TDM, mas a PSN no oferece garantia de que esses
pacotes chegaro ao equipamento de destino nesses mesmos intervalos, na mesma ordem,
ou mesmo que todos os pacotes introduzidos efetivamente chegaro ao destino. Alm
disso, as redes IP e PSN em geral foram projetadas para o transporte de dados arbitrrios,
de forma que qualquer sinalizao relacionada s redes TDM no suportada.
2.2.2 - Transporte de servios TDM atravs de redes IP
Existem duas maneiras fundamentais pelas quais os servios tradicionais TDM podem ser
integrados s redes PSN baseadas em IP: A substituio completa da rede TDM e dos
equipamentos dos usurios por uma nova infra-estrutura com capacidade para prover
mecanismos inovadores para o transporte e sinalizao de dados de voz em tempo real; e
uma segunda alternativa que mantm intactos os equipamentos dos usurios, protocolos e
aplicaes, realizando o tunelamento dos dados TDM atravs da rede de transporte
comutada em modo pacotes.
A32

Dessa forma, a segunda alternativa representaria, em princpio, um caminho de migrao

mais simples e eficiente, sob o ponto de vista dos investimentos necessrios para
operadoras e fabricantes de equipamentos, sendo a essncia da proposta historicamente
conhecida como TDMoIP e suas evolues. [STEIN 2003]
As tecnologias SAToP e TDMoIP permitem a emulao de circuitos tradicionais TDM
(T1, E1, T3, E3 e Nx64Kbps) atravs da adaptao e encapsulamento, pelo n de origem,
do trfego TDM em pacotes a serem transportados atravs de redes IP, MPLS ou Ethernet,
conforme especificado no Apndice C.
Por adaptao entende-se o mecanismo que modifica o fluxo de dados TDM original
(payload) de forma a permitir a sua regenerao, pelo n de destino, no momento da
retirada dos pacotes da rede IP. Utilizando um processo adequado de adaptao, a
sinalizao e a sincronizao do fluxo TDM original podem ser recuperadas, e mesmo uma
certa quantidade de pacotes porventura perdidos pode ser acomodada, sem perda
significativa de qualidade para a comunicao estabelecida.
Por encapsulamento entende-se a acomodao do fluxo de dados adaptado em pacotes
dentro do formato e das caractersticas impostas pela tecnologia PSN utilizada. Formas de
encapsulamento TDMoIP esto hoje definidas para redes IP com transporte UDP (User
Datagram Protocol) - UDP/IP, redes MPLS, redes IP com L2TP (Layer 2 Tunneling
Protocol) - L2TP/IP e redes Ethernet, conforme estabelecido no Internet-Draft proposto
pelo Grupo PWE3 da IETF para padronizao da tecnologia TDMoIP. [IETF2006], cuja
publicao como RFC j foi requisitada.
O equipamento de interoperabilidade que conecta o circuito TDM tradicional rede PSN
chamado gateway TDMoIP ou IP-Mux, e pode estar localizado tanto no Equipamento
Provedor (PE) como no Equipamento Cliente (CE). O gateway que encapsula os dados
TDM e insere pacotes na rede PSN chamado de extremidade PSN (PSN-bound),
enquanto o gateway que extrai os dados TDM dos pacotes e gera trfego para a rede TDM
chamado de extremidade TDM(TDM-bound). Os circuitos TDM emulados atravs
dessa tecnologia so sempre ponto-a-ponto, bidirecionais, e transportam a mesma taxa de
bits em ambas as direes.
A33

2.2.3 - Implementao de pseudo-circuitos TDM

O aspecto crtico na implementao de pseudo-circuitos TDM a recuperao do relgio,
pois nas redes TDM tradicionais a camada fsica transporta informaes de temporizao
atravs do fluxo de dados, sncrono ou quase-sncrono, existindo em algum ponto da rede
um relgio primrio com preciso da ordem de 10-11; enquanto na grande maioria das
redes de pacotes essa sincronizao entre os ns no existe. Dessa forma, o relgio deve ser
extrado a partir dos pacotes recebidos, que sofrem diferentes atrasos em funo do
caminho percorrido e do trfego existente na PSN, resultando numa componente aleatria
conhecida como PDV (Packet Delay Variation). Isso implica no desenvolvimento de
mecanismos eficientes para reproduzir o relgio e a taxa constante do fluxo TDM.
O mecanismo mais utilizado, descrito em [CISCO2004], a utilizao de um buffer para
armazenamento temporrio dos dados recebidos em cada pacote, conhecido como jitter
buffer, onde os dados recebidos da PSN so escritos taxa varivel com que so recebidos,
mas lidos e enviados para o circuito TDM de destino a uma taxa constante, determinada
pela velocidade de extrao dos dados do buffer, que controlada pelo relgio do PE de
destino, conforme apresentado na Figura 2.7.

Pacotes
Enviados
(atraso constante)

PE1

Pacotes
Recebidos
(atraso varivel)

Rede de Pacotes
PSN

PE2

Pacotes
Escalonados
(atraso constante)

Jitter Buffer
CkTx

Figura 2.7 - Acomodao da variao no atraso dos pacotes pelo jitter buffer.

A34

Dessa forma, a componente aleatria de alta freqncia da variao no atraso sofrido pelos
pacotes (PDV) absorvida, acomodando essas variaes e tornando o atraso constante do
ponto de vista da rede TDM de destino, em troca da latncia adicional introduzida pelo
processo de armazenamento e espera. Nas condies ideais, o jitter buffer deveria operar
com metade de sua capacidade nominal preenchida, minimizando de forma idntica os
riscos de ser totalmente preenchido, obrigando ao descarte de pacotes (overflow) ou no
possuir pacotes para encaminhamento ao circuito TDM de destino num dado instante
(underflow). Nessa premissa, a latncia adicional introduzida no pseudo-circuito para
acomodao das variaes no atraso sofrido pelos pacotes equivalente metade do
tamanho desse buffer. Nas implementaes, o tamanho do jitter buffer deve ser
configurvel, ou ainda dinmico, aumentando ou diminuindo de acordo o atraso fim a fim
observado na PSN.
Alm disso, o relgio utilizado para a regenerao do fluxo TDM pelo PE de destino
precisa estar alinhado com o relgio utilizado pelo PE de origem, correspondente taxa do
fluxo TDM original, a fim de que a sincronizao seja mantida entre os CEs. Como no
existe, na grande maioria das PSN, um relgio comum aos PEs de origem e destino, a
freqncia de extrao dos dados do buffer costuma ser apenas nominalmente igual taxa
do fluxo TDM na origem, gerando flutuaes de baixa freqncia no circuito TDM de
destino, conhecidas como wander, que prejudicam a qualidade da conversao
bidirecional, podendo torn-la completamente invivel.
Como discutido anteriormente no Modelo de Referncia PWE3 para Sincronizao da
Rede, apresentado na seo 2.1.2, existem trs alternativas para resolver o problema de
sincronizao entre as redes TDM de origem e de destino em um pseudo-circuito
TDMoIP: a utilizao de redes sncronas, a sincronizao relativa e a sincronizao
adaptativa [AWEYA2003].
No primeiro caso, correspondente aos cenrios (a.1) e (a.2) do Modelo de Referncia
PWE3, a informao de relgio gerada diretamente atravs do PE de destino (a.2), ou por
enlace fechado a partir do circuito TDM de destino (a.1), os quais fazem parte ou tm
outras interfaces com uma rede sncrona comum. Essa situao, representada na Figura 2.8,
tem pequena abrangncia, sendo limitada ao caso de expanso de uma rede TDM existente,
A35

onde os circuitos de origem e destino j se encontram interligados por uma rede sncrona,
mas so desejadas novas rotas para transporte TDM atravs de uma rede de pacotes que
atenda ambas as extremidades; ou ao caso onde existe um relgio comum dentro da PSN,
distribudo a todos os PE.

Buffer
Pacotes

Fluxo
TDM

Dados

CkPSN

Relgio Tx
transmisso

- existe referncia de relgio comum;

- aplicado diretamente quando existe CkPSN disponvel;
- utiliza enlace fechado de sincronizao quando existe CkTDM disponvel.

Figura 2.8 - Recuperao do relgio no destino pelo mtodo sncrono.

No segundo caso, correspondente ao cenrio (b) do Modelo de Referncia PWE3, um
relgio comum tambm est disponvel para ambos os gateways TDMoIP, atravs da
PSN, mas como o relgio do circuito TDM de origem completamente independente, a
relao entre o relgio de origem e esse relgio comum inserida no pacote de dados,
utilizando o protocolo RTP (timestamp) ou os bits SRTS (Synchronous Residual
TimeStamp) no overhead AAL1. No PE de destino, essa relao inserida no pacote
somada ao valor do relgio comum, re-estabelecendo o relgio do circuito TDM de
origem, conforme representado na Figura 2.9. Essa situao, tpica no caso da emulao de
circuitos em redes ATM, tambm apresenta pequena abrangncia no caso das redes de
pacotes utilizadas em TDMoIP, como IP e Ethernet, uma vez que as mesmas no
apresentam, como caracterstica geral, um relgio comum a todos os seus ns.

A36

Pacotes
c/RTS

Buffer
Dados

RTS

CkPSN

Decodificador
SRTS

Fluxo
TDM

Relgio Tx

- utilizado quando existem mltiplas fontes de relgio (origem ATM);

- permite a conciliao de sinais de relgio diferentes;
- adequado para Sincronizao Relativa quando CkPSN disponvel;
- transmite CkCE1 atravs da PSN, sem afetar sua operao.

Figura 2.9 - Recuperao do relgio no destino pelo mtodo relativo SRTS

No ltimo caso, correspondente ao cenrio (c) do Modelo de Referncia PWE3, no existe
um relgio comum, devendo o relgio TDM de origem ser regenerado exclusivamente com
base em caractersticas observveis nos pacotes recebidos da PSN, como por exemplo o
instante exato de chegada ao PE de destino, associado ao instante de gerao do pacote
pelo PE de origem, que transmitido pela rede atravs do protocolo RTP (timestamp); ou
o nvel de preenchimento do jitter buffer em funo do tempo.
Em funo da variao no atraso dos pacotes, processos de filtragem que eliminem a
natureza estatstica dessas caractersticas devem ser empregados, tais como FLLs
(Frequency Locked Loops) e PLLs (Phase Locked Loops). Essa situao apresenta
abrangncia mais geral, sendo aplicvel a todas as redes de pacotes utilizadas em
TDMoIP, incluindo aquelas baseadas em datagramas IP e quadros Ethernet.
Qualquer que seja o mecanismo empregado, o fluxo TDM a partir do PE de destino deve
apresentar conformidade com as restries para jitter e wander estabelecidas nas
Recomendaes ITU-T G.823 e G.824 para os circuitos TDM tradicionais. Na Figura 2.10
representada a recuperao do relgio utilizando a timestamp transmitida atravs do
protocolo RTP.
A37

Buffer
Pacotes

Fluxo
TDM

Dados

Timestamp

Escalonador

PLL

Relgio Tx

- utilizado quando no existe referncia de relgio comum;

- regenera o relgio a partir da informao de timestamp nos pacotes RTP,
que o PLL reproduz no destino, quando as freqncias so idnticas.

Figura 2.10 - Recuperao do relgio no destino pelo mtodo adaptativo

utilizando timestamp atravs do protocolo RTP.
Enquanto na Figura 2.11 representada a recuperao do relgio utilizando a ocupao, no
tempo, do jitter buffer.

Fluxo
TDM

Buffer
Pacotes

Dados
Relgio+ Relgio-

Preenchimento
Buffer

PLL

Relgio Tx

- utilizado quando no existe referncia de relgio comum;

- baseado na taxa constante de gerao de pacotes pelo circuito de origem;
- regenera o relgio a partir da ocupao do jitter buffer, que o PLL tenta
manter constante.

Figura 2.11 - Recuperao do relgio no destino pelo mtodo adaptativo

utilizando a ocupao, no tempo, do jitter buffer.

A38

Contudo, os mtodos baseados na ocupao do jitter buffer ao longo do tempo so

sensveis s perdas de pacotes na PSN, pois a freqncia de sada fortemente dependente
do fluxo de chegada de pacotes.
Dessa forma, a sincronizao adaptativa utilizando timestamp representa uma forma mais
eficiente de regenerao do relgio utilizado pelo circuito TDM de origem, lembrando
ainda que o protocolo RTP pode ser dispensado caso seja garantido que o tamanho dos
pacotes e sua taxa de gerao sejam constantes, conforme j discutido. Nesse caso, como o
nmero de seqncia da Palavra de Controle TDMoIP gerado de forma monotnica e
cada pacote contm sempre o mesmo nmero de amostras, a timestamp seria simplesmente
uma funo linear do nmero de seqncia (NS), calculada atravs da Expresso (2.1),
considerando o nmero de seqncia inicial igual a zero, onde TamanhoPacote deve ser
fornecido em quadros TDM:
= NS .(

).(125s )

(2.1)

Outro aspecto fundamental a mitigao das perdas de pacotes inerentes s PSN, uma vez
que o fluxo de dados TDM pressupe a entrega de bits a uma taxa constante, tipicamente
sobre um canal dedicado, sendo tolerados alguns erros de bit, mas jamais a perda de dados
em trnsito. Qualquer rede de pacotes apresenta algum grau de desordenamento e perda de
pacotes, decorrente da possibilidade de caminhos mltiplos, enfileiramento e descarte em
seus roteadores, sobretudo em situaes de carga excessiva ou congestionamento de
enlaces crticos, e essas perdas e/ou recebimento fora de ordem precisam ser
adequadamente compensados para a continuidade do servio TDM, sobretudo em
aplicaes como voz interativa e transmisso de vdeo.
O mecanismo para mitigao da perda e recebimento de pacotes fora de ordem o
rastreamento dos nmeros de seqncia recebidos em cada pacote, armazenados dentro do
jitter buffer, identificando anomalias e realizando aes para cada caso. Quando a perda de
um ou mais pacotes detectada, esse mecanismo deve gerar pacotes de preenchimento a
fim de manter a sincronizao TDM, enquanto pacotes com nmeros de seqncia
incorretos ou com erros de cabealho devem ser descartados e substitudos, assegurando
que os padres necessrios regenerao do fluxo TDM no destino, como o FAS, sejam
A39

sempre encaminhados. Em caso de recebimento fora de ordem, os pacotes devem ser

reordenados em tempo hbil para que sejam encaminhados ao circuito TDM de destino no
instante correto dentro do fluxo original.
Enquanto a simples insero de pacotes arbitrrios de preenchimento pode ser suficiente
para manuteno da sincronizao no circuito TDM de destino, para o trfego de telefonia
isso pode causar problemas como voz entrecortada, rudo desconfortvel ou mesmo uma
conversao ininteligvel, enquanto para o trfego de vdeo isso pode causar distores
visveis nas imagens recebidas, com queda de qualidade. Dessa forma, quando a
probabilidade de perda for significativa, devem ser implementados mecanismos mais
apurados para a mitigao das perdas de pacotes, como a escolha adequada dos valores a
serem substitudos em caso de perda, com o objetivo de minimizar esses erros de
percepo.
Algumas possibilidades so a repetio dos dados contidos no pacote anteriormente
recebido e a gerao, quando existem recursos computacionais disponveis, de uma
estimativa dos dados perdidos com base na interpolao entre o pacote anterior ao perdido
e o prximo pacote do fluxo, uma vez que as perdas so usualmente detectadas pelo
recebimento bem sucedido do pacote seguinte ao faltante.
Evidentemente, mecanismos de Qualidade de Servio (QoS) tambm podem e devem ser
empregados sempre que possvel no estabelecimento dos pseudo-circuitos, a fim de
assegurar que a PSN oferea o melhor desempenho possvel para o fluxo TDMoIP
transportado, reduzindo as perdas de pacotes e melhorando a qualidade dos mesmos:

Servios de priorizao na Camada 2 podem ser solicitados utilizando o campo de

prioridade VLAN, desde que todos os comutadores (switches) envolvidos estejam aptos
a oferec-la;

A priorizao em redes MPLS deve ser realizada utilizando os bits EXP, sendo
sugerido um LSP especfico e adequado s taxas envolvidas no fluxo TDM;

A prioridade na camada IP deve ser controlada utilizando o campo ToS, desde que os
roteadores envolvidos estejam aptos a oferec-la;

A40

Em caso de utilizao de mecanismos DiffServ, a classe EF (Expedited forwarding)

deve ser utilizada, a fim de oferecer baixa latncia e a menor variao possvel no
atraso dos pacotes (jitter);

Em caso de utilizao de mecanismos IntServ, o servio GS (Guaranteed Service), com

reserva de largura de banda adequada s taxas envolvidas no fluxo TDM deve ser
utilizado, e o atraso introduzido pela PSN avaliado de forma a assegurar
compatibilidade com os requisitos de latncia para o pseudo-circuito TDM.

2.3 - PROPOSTA DE EVOLUO DA IMPLEMENTAO TDMOIP

Em funo das fragilidades ainda encontradas nas implementaes correntes da tecnologia
TDMoIP, esse trabalho prope novos mecanismos para as Subcamadas de
Seqenciamento e Sincronizao, buscando, na primeira, um tratamento mais completo e
eficiente da reordenao de pacotes com base em um novo algoritmo para o gerenciamento
do jitter buffer; e na segunda, uma abordagem menos sensvel QoS oferecida pela PSN
para a recuperao adaptativa do relgio de transmisso no receptor, utilizando filtragem
PLL e tcnicas clssicas de controle para garantir o acompanhamento estrito, pelo oscilador
local do receptor, da freqncia de transmisso utilizada no CE de origem do fluxo TDM.
Assim, essa proposta busca estender a possibilidade de regenerao adequada do fluxo
TDM no CE de destino, atendendo aos requisitos impostos pelos padres das redes TDM
tradicionais, at condies mais adversas do que as hoje toleradas no transporte de pseudocircuitos TDM sobre redes IP, assegurando o transporte de voz e vdeo nessas redes de
forma eficiente, confivel e completamente transparente aos equipamentos terminais.
2.3.1 - A implementao TDMoIP da RAD
A RAD Data Communications Ltd. a principal responsvel pelo desenvolvimento da
tecnologia TDMoIP, tanto no que se refere ao processo de padronizao, pois alguns de
seus engenheiros so os principais contribuidores do grupo PWE3, como tambm no
desenvolvimento de produtos comerciais, tendo colocado no mercado diversos
equipamentos com a marca TDMoIP Driven. Dessa forma, foram realizados contatos com
A41

seus representantes no Brasil, no sentido de buscar maiores informaes sobre seus

produtos e tambm obter equipamentos para demonstrao e anlise da tecnologia utilizada
nos mesmos.
Analisando a documentao a que tivemos acesso [RAD2005], foram descritas algumas
caractersticas da implementao TDMoIP da RAD, as quais foram confrontadas com a
arquitetura e os requisitos estabelecidos pelo grupo PWE3 para emulao de circuitos
TDM sobre PSN, descritos respectivamente, nos Apndices A e B.
Nesse confronto, foram enfatizados os dois aspectos identificados como os mais crticos
para o transporte de pseudo-circuitos TDM sobre redes de pacotes, ambos relativos
Camada de Encapsulamento: as Subcamadas de Seqenciamento e Sincronizao.
Para o seqenciamento, a implementao RAD utiliza um jitter buffer, que preenchido
pelos pacotes IP recebidos e esvaziado pela regenerao do fluxo TDM em direo ao CE
de destino. Essa regenerao iniciada somente aps o preenchimento de metade do buffer,
a fim de acomodar a variao no atraso sofrida pelos pacotes na PSN dentro de um limite
mximo de tolerncia, que tambm corresponde ao atraso adicional introduzido pelo jitter
buffer no pseudo-circuito. Assim, o tamanho do buffer configurvel entre 3ms e 300ms,
permitindo a acomodao de um atraso total, correspondente ao provocado pela PDV da
rede mais o atraso de empacotamento, entre 1,5ms e 150ms.
O atraso de empacotamento para uma dada configurao de canais, designada bundle na
documentao RAD, dado pela expresso (2.2).

AtrasoEmpa cot amento =

47.N .(125s)
TS

(2.2)

Onde:
N o nmero de octetos TDM por pacote, considerando o tamanho da clula AAL (48
octetos), como indicado na expresso (2.3). Em funo da MTU tpica na Ethernet, N
pode variar entre 1 (48 octetos) e 30 (1440 octetos);
TS o nmero de timeslots vlidos existentes no fluxo TDM (32 para E1 completo).

A42

(2.3)

N=

48

Evidentemente, existe um compromisso entre a largura de banda ocupada pelo pseudocircuito, que reduzida pela utilizao de um nmero maior de octetos TDM por pacote,
em funo do menor overhead correspondente aos cabealhos; e o atraso de
empacotamento, que aumenta pela necessidade de aguardar a chegada de mais quadros
TDM para montagem de um pacote.
O tamanho do jitter buffer deve ser configurado para o pseudo-circuito de acordo com a
expresso (2.4).
TamanhoBuffer = AtrasoEmpa cot amento + PDV

(2.4)

Onde PDV a mxima variao esperada para o atraso sofrido pelos pacotes, estimada ou
medida sobre a rede PSN, utilizando metade do valor RTT (Round-Trip Time) mdio, por
exemplo.
As funes de reordenao da subcamada de seqenciamento dependem do formato
escolhido para o fluxo de dados TDM, designadas V1 (Version 1) e V2 (Version 2) na
documentao:
No caso da Verso 1, onde utilizada AAL1 para adaptao do fluxo TDM, a reordenao
de pacotes recebidos fora de ordem de transmisso suportada apenas para valores mpares
de N, ou seja, 1x48, 3x48, ..., 29x48 octetos TDM por pacote, permitindo a recuperao da
ordenao original para at sete pacotes, em funo do limite que pode ser endereado pelo
ponteiro AAL1, de 3 bits.
No caso da Verso 2, onde utilizada AAL2 para adaptao do fluxo TDM, a reordenao
de pacotes recebidos fora de ordem de transmisso suportada para qualquer valor de N,
permitindo a recuperao da ordenao original para at 64 pacotes.

A43

Contudo, esses valores representam os limites mximos para a reordenao dos pacotes,
sendo os valores reais aplicveis a um determinado pseudo-circuito dependentes do
tamanho do jitter buffer e determinados pela expresso (2.5), permanecendo limitados s
quantidades mximas 7 (V1) e 64 (V2) mesmo que o resultado da expresso seja superior.

PacotesReordenaveis =

[(TamanhoBuffer (ms) 1)].(TS .8)

(2.5)

47.N

Ainda com relao ao seqenciamento, em caso de recebimento de um pacote duplicado, a

implementao RAD considera apenas aquele recebido por ltimo, e as perdas de pacote
so detectadas atravs dos erros de seqncia observados nos pacotes armazenados no jitter
buffer.
Assim, pode ser deduzido que existe um processo especfico de gerenciamento do jitter
buffer, que implementa a reordenao, quando possvel, substitui os pacotes duplicados e
monitora/trata a ocorrncia de erros. Tal caracterstica reforada pela descrio dos erros
de seqncia, underflow e overflow na documentao, que pressupe esse gerenciamento
explcito:

Erros de Seqncia: o gateway de destino verifica os nmeros de seqncia atravs do

mecanismo de recepo e espera que cada um dos novos pacotes recebidos esteja na
seqncia, em relao ao anterior (pacote 5 recebido aps o 4 e assim sucessivamente).
Quando, por alguma razo, isso no acontece, significa que houve um problema com a
integridade do fluxo de pacotes, e portanto com o transporte de voz/vdeo/dados, que
indicado atravs do incremento do contador Sequence Errors.

Erros de Underflow: aps a inicializao do pseudo-circuito, o jitter buffer armazena

pacotes at que esteja preenchido com metade da sua capacidade mxima,

correspondente ao espao ocupado pelo equivalente em pacotes do tamanho
configurado, em milissegundos. Somente aps esse ponto o gateway comea a gerar o
fluxo TDM em direo ao CE de destino. Os pacotes armazenados asseguram que o
equipamento TDM ser alimentado com um fluxo contnuo de dados mesmo se os
pacotes subseqentes sofrerem atrasos variveis na PSN. Obviamente, se esses pacotes
sofrem atrasos demasiado longos, o buffer ser gradualmente esvaziado at que no
existam mais pacotes disponveis para continuidade do fluxo TDM, situao que

A44

provoca o incremento do contador Jitter Buffer Underflow e indica um problema de

integridade fim a fim no transporte de voz/vdeo/dados.

Erros de Overflow: em regime permanente, o jitter buffer est preenchido at a

metade, o que significa que existe espao para armazenar uma quantidade equivalente
de novos pacotes recebidos. O overflow o fenmeno oposto ao underflow, isto ,
quando uma grande rajada de pacotes recebida pelo gateway, em nmero superior
sua capacidade de armazenamento, o buffer totalmente preenchido. Neste caso, um
nmero desconhecido de pacotes excedentes descartado e gerado um underflow
forado, em virtude do esvaziamento do jitter buffer para que o processo seja reiniciado
desde o princpio. Um overflow provoca o incremento do contador Jitter Buffer
Overflow e sempre resulta num underflow imediato, forado pelo gateway, com os
mesmos efeitos j descritos acima.
Para sincronizao do fluxo TDM no PE de destino, a implementao RAD no utiliza o
protocolo RTP, por isso permite a utilizao de apenas trs cenrios previstos no Modelo
de Referncia para Sincronizao de Rede descrito na seo 2.1.2, da seguinte forma:

Para o cenrio (a.1), ou seja, sincronizao atravs dos PEs, o relgio comum
disponvel na PSN aplicado s entradas EXT CLK dos gateways, que configurado
para utilizao de relgio externo, sendo os equipamentos TDM nas extremidades do
pseudo-circuito configurados para enlace fechado (loopback) de sincronizao, como
apresentado na Figura 2.12 (a.1).

Para o cenrio (a.2), ou seja, sincronizao atravs dos CEs, os gateways so

simplesmente configurados para enlace fechado (loopback) de sincronizao, sendo o
relgio comum garantido pelos equipamentos TDM nas extremidades do pseudocircuito, como apresentado na Figura 2.12 (a.2). .

Para o cenrio (c), ou seja, sincronizao adaptativa, um dos gateways configurado

para enlace fechado (loopback) de sincronizao, obtendo o relgio a partir do
equipamento TDM a ele conectado, enquanto o gateway na outra extremidade do
pseudo-circuito configurado para sincronizao adaptativa, como apresentado na
Figura 2.12 (c).

O cenrio (b), ou seja, sincronizao relativa, no implementado.

A45

Equipamento
TDM

Relgio
PSN
E1

Rede IP
Gateway TDMoIP
(relgio externo)

(loopback de
relgio)

E1
Gateway TDMoIP
(relgio externo)

(a.1)

Equipamento
TDM

(loopback de
relgio)

Relgio
TDM
Equipamento
TDM

E1

Equipamento
TDM

(relgio
primrio)

Rede IP
Gateway TDMoIP
(loopback de relgio)

(relgio
externo)

E1

E1
Gateway TDMoIP
(loopback de relgio)

(a.2)

Gateway TDMoIP
(loopback de relgio)

Rede IP

(c)

E1
Gateway TDMoIP
(relgio adaptativo)

Equipamento
TDM

(relgio
externo)

Equipamento
TDM

(loopback de
relgio)

Figura 2.12 - Esquemas de sincronizao para gateways TDMoIP RAD.

O algoritmo utilizado na sincronizao adaptativa a regenerao do relgio de
transmisso utilizado pelo CE de origem, atravs da monitorao do estado de
preenchimento do jitter buffer ao longo do tempo, como mostrado na Figura 2.11 acima.
Quando a ocupao do buffer cresce, a freqncia do relgio de transmisso gerado pelo
oscilador interno do gateway de destino incrementada, a fim de evitar um overflow do
mesmo; da mesma forma, quando o buffer comea a esvaziar, a freqncia do relgio de
transmisso reduzida, evitando o seu underflow.
Esse algoritmo, como j discutido, bastante sensvel a perdas e/ou variao no atraso
sofrido pelos pacotes que atravessam a PSN, de forma que a qualidade do relgio
regenerado est intimamente ligada qualidade oferecida pela rede ao trfego que
transporta o fluxo TDM, o que implica em necessidade de utilizao de ferramentas de
QoS, nem sempre disponveis, para sua operao satisfatria, comprometendo a robustez
da implementao RAD para o transporte de voz interativa e transmisso de vdeo nas
redes onde no possvel uma garantia de QoS fim a fim.
Um ltimo aspecto a destacar na implementao RAD a chamada Conectividade de
Operao e Manuteno (OAM Connectivity), que no definida pelo Internet-Draft do

A46

padro TDMoIP e, portanto, pode ser configurada ou no nos gateways. Essa

funcionalidade implementa, atravs de um nmero de bundle exclusivo, um canal de
controle entre os equipamentos de origem e destino, na forma do Canal Tipo 1 descrito
pela Arquitetura PWE3,

permitindo que o gateway de destino seja detectado e uma

conexo vlida reconhecida antes de iniciar o fluxo de dados TDM, evitando sobrecarga na
PSN pelo envio descontrolado de pacotes, em taxas elevadas, sem que o pseudo-circuito
esteja estabelecido e operacional. Atravs desse mecanismo, um gateway TDMoIP RAD
somente comea a transmitir os pacotes contendo dados TDM taxa plena quando detecta
um gateway remoto em condies para recebimento do fluxo de dados, evitando o
desperdcio de largura de banda na rede de pacotes.
2.3.2 O novo mecanismo para seqenciamento de pacotes proposto

Na

implementao RAD,

so observadas duas limitaes

na subcamada de

seqenciamento: a existncia de fortes restries para o processo de reordenao dos

pacotes recebidos no destino e a necessidade de gerenciamento do jitter buffer, levando
necessidade de reiniciar o pseudo-circuito, com o esvaziamento desse buffer, sempre que
sua capacidade excedida (overflow) durante a emulao de um pseudo-circuito.
Alm disso, o tamanho do jitter buffer fixado pelo operador no momento de
estabelecimento do pseudo-circuito, com base em estimativa ou medio do atraso
provocado pela PSN, no permitindo reconfigurao enquanto o mesmo estiver ativo.
Assim, como forma de melhorar a robustez da implementao, tornando-a menos sensvel
QoS oferecida pela PSN ao fluxo de pacotes contendo dados TDM, proposto um novo
mecanismo integrado de armazenamento, reordenao e mitigao de perdas de pacote,
implementado atravs de um buffer circular auto-gerencivel, que ser detalhado a seguir.
Nessa proposta, ao invs da abordagem tradicional de implementao do jitter buffer, onde
os pacotes recebidos so inicialmente armazenados em sua ordem de chegada, cabendo a
um segundo mecanismo a sua reordenao, quando possvel, substituda por um
mecanismo integrado onde o pacote recebido sempre armazenado diretamente em sua
posio correta dentro do buffer, de caracterstica circular, com base, exclusivamente, em
A47

seu nmero de seqncia; eliminando a necessidade de qualquer processo adicional de

reordenao ou gerenciamento desse buffer. Dessa forma, o processo de leitura dos dados
para regenerao do fluxo TDM realiza simplesmente uma varredura seqencial e contnua
do buffer circular, atrasada no tempo em relao ao processo de escrita, uma vez que a
ordem dos dados j foi assegurada pelo processo de escrita, tornando a operao no
receptor muito mais eficiente, como ilustrado na Figura 2.13, assumindo pacotes de 1ms e
um jitter buffer de 16 posies (16ms).
Transmissor
Receptor - Thread Escrita
Receptor - Thread Leitura
Posio a
Posio a
gravar
ler
Seqncia transmitida
Seqncia recebida
Fluxo TDM
Tempo
(ms)
NS
Contedo Ordem
NS
Contedo (NS mod 16) Ordem Ponteiro Contedo (seqencial)
0
16000
A
1
16001
B
2
16002
C
3
16003
D
Atraso mdio da rede: 8 ms = 50% buffer Atraso mdio da rede: 8 ms = 50% buffer
4
16004
E
5
16005
F
6
16006
G
7
16007
H
8
16008
1
16000
0
I
A
9
16009
2
16002
2
J
C
10
16010
3
16001
1
K
B
Incio Fluxo TDM: Atraso de 8ms =
11
16011
L
4
16003
D
3
50%Buffer
12
16012
5
16002
2
M
C
13
16013
6
16004
4
N
E
14
16014
7
16007
7
O
H
15
16015
8
16005
5
P
F
16
16016
9
16009
9
1
16000
0
Q
J
A
17
16017
10
16008
8
2
16001
1
R
I
B
18
16018
11
16010
10
3
16002
2
S
K
C
19
16019
T
12
16012
M
12
4
16003
D
3
20
16020
13
16014
14
5
16004
4
U
O
E
21
16021
V
14
16013
N
13
6
16005
F
5
22
16022
15
16011
11
7
16006 (vazio)
6
W
L
23
16023
16
16015
15
8
16007
7
X
P
H
24
16024
17
16017
1
9
16008
8
Y
R
I
25
16025
18
16016
0
10
16009
9
Z
Q
J
26
16026
19
16020
4
11
16010
10
AA
U
K
27
16027
20
16019
3
12
16011
11
AB
T
L
28
16028
AC
21
16018
S
2
13
16012
M
12
29
16029
22
16006
No gravar
14
16013
13
AD
G
N
30
16030
23
16023
7
15
16014
14
AF
X
O
31
16031
24
16025
9
16
16015
15
AG
Z
P
32
16032
25
16024
8
17
16016
0
AH
Y
Q
33
16033
26
16020
4
18
16017
1
AI
U
R
34
16034
27
16021
5
19
16018
2
AJ
V
S
35
16035
28
16022
6
20
16019
3
AK
W
T
36
16036
29
16026
10
21
16020
4
AL
AA
U
37
16037
AM
30
16018
S
No gravar
22
16021
V
5
38
16038
31
16027
11
23
16022
6
NA
AB
W
39
16039
AO
32
16029
AD
13
24
16023
X
7

Jitter Buffer
Posio
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

NS
Dado
Armazenado Armazenado
16000 16016
A
Q
16001 16017
B
R
16002 16018 C/C
S
16003 16019
D
T
16004 16020
E
U/U
16005 16021
F
V
0
16022 (vazio)
W
16007 16023
H
X
16008 16024
I
Y
16009 16025
J
Z
16010 16026
K
AA
16011 16027
L
AB
16012
0
M
16013 16029
N
AD
16014
0
O
16015
0
P

Ordem de Ordem de
Escrita
Leitura
1
18
1
16
3
17
2
18
2/5 21/30
3
19
4
20
4
20
6 19/26
5
21
8
27
6
22
22/28
7
23
7
23
8
24
10
25
9
9
24
10
11
29
11
15
31
12
12
13
14
32
14
13
15
16
16

Perda de pacote
Pacote atrasado
Pacote replicado

Figura 2.13 - Ilustrao do mecanismo de seqenciamento proposto.

As primeiras trs colunas representam o comportamento do transmissor, com pacotes
sendo transmitidos na seqncia a cada milissegundo, contendo os dados representados
pela seqncia alfabtica A, B, C, ..., AA, AB, AC, ... As quatro colunas seguintes, com
linhas deslocadas 8 ms do incio da transmisso, correspondente ao atraso provocado pela
rede, representam os pacotes recebidos no destino e tratados pela thread de escrita,
mostrando a ordem de chegada na primeira, o NS recebido na segunda e o dado do pacote
na terceira, indicando na quarta coluna a posio em que os mesmos so escritos no buffer
de acordo com o algoritmo proposto. Nas outras quatro colunas seguintes, representado o
processo de reproduo dos pacotes TDM executado pela thread de leitura, novamente
deslocado de metade do tamanho do buffer utilizado (8 ms) e mostrando na primeira coluna

A48

a ordem de reproduo, na segunda o NS do pacote reproduzido e na terceira o respectivo

dado, indicando na quarta coluna a posio onde este foi lido atravs do processo de
varredura seqencial. Um diagrama de ocupao de cada uma das 16 posies do buffer
tambm reproduzido na Figura 2.13, direita, mostrando as respectivas ordens de escrita e
leitura dos NS e dados dos pacotes em cada posio.
O primeiro pacote recebido o 16000, que pelo algoritmo gravado na posio 0,
enquanto o segundo o 16002, que gravado na posio 2; o terceiro pacote a chegar o
16001, que corretamente colocado na posio 1 de acordo com o algoritmo. O quinto
pacote recebido, no entanto, novamente o 16002 (indicado em verde), que sobrepe o
dado armazenado anteriormente de forma transparente, conforme definido pelo novo
algoritmo proposto. Esse processo continua indefinidamente, mas quando 50% do buffer
ocupado, tambm iniciado o processo de reproduo dos dados armazenados, varrendo de
forma seqencial e cclica as 16 posies. Pode ser ainda observado na Figura 2.13 que
quando chega o instante de reproduo do pacote 16006 (indicado em vermelho), este
ainda no foi recebido e o buffer est vazio, obrigando o receptor a executar um processo
de mitigao da perda. Quando esse pacote finalmente chega, como o vigsimo segundo
recebido, ele no mais vlido pois est demasiado atrasado e portanto no sequer
gravado no buffer (indicado em laranja).
Em caso de perda de pacotes na PSN, existe o risco de que os dados contidos na posio
corrente de leitura no sejam vlidos, mas referentes a um instante de tempo anterior, de
forma que sua validade precisa ser verificada pela continuidade do nmero de seqncia
armazenado e, em caso de inconsistncia, deve ser executado o processo de mitigao
previamente definido, como a transmisso de um padro constante, a reproduo dos dados
do pacote anterior ou a reconstruo dos dados com base na interpolao entre as posies
adjacentes do jitter buffer, por exemplo, garantindo assim uma taxa constante de bits na
sada do receptor: o fluxo TDM regenerado em direo ao CE de destino.
Nessa abordagem, no existe limitao para a quantidade de pacotes reordenveis, uma vez
que os mesmos podem ser escritos em suas posies corretas no momento em que so
recebidos, seja ele qual for, desde que ainda sejam vlidos com relao ao processo de
leitura e reproduo. Pacotes atrasados em relao ao processo de leitura, cuja perda j foi
mitigada, so automaticamente descartados (no armazenados) e pacotes que tenham sido
A49

replicados pela rede e cheguem novamente ao receptor vo automaticamente substituindo

seus antecessores, assegurando que no exista duplicidade no fluxo TDM de sada, tudo
isso de forma integrada, dentro do processo de escrita, que extremamente simples.
Da mesma forma, no necessrio que o pseudo-circuito seja reiniciado quando ocorrerem
rajadas de pacotes que excedam a capacidade do jitter buffer (overflow), com seu
esvaziamento e introduo de novo atraso at que seja novamente alcanada a metade de
sua capacidade, como na implementao RAD, uma vez que o armazenamento de pacotes
alm da posio corrente de leitura automaticamente tratado pelo processo de escrita,
substituindo todos os pacotes antigos previamente armazenados pelos que acabam de ser
recebidos, mais recentes. Isso no evita, evidentemente, os erros introduzidos nos dados
pela perda dos pacotes sobrepostos, que acabam tratados pelo processo de mitigao
definido, mas assegura a continuidade do pseudo-circuito aps essas rajadas, uma vez que
no existe condio de overflow, minimizando o impacto desses erros na disponibilidade
do circuito TDM, j que no so introduzidos atrasos adicionais nem existe
descontinuidade no fluxo de bits.
Essa caracterstica permite ainda que o tamanho do buffer circular possa ser alterado
enquanto o pseudo-circuito permanece ativo, acomodando automaticamente as perdas de
pacote ou de seqncia que possam ser introduzidas durante a reconfigurao, de forma a
que no haja perda de continuidade no fluxo de bits. Dessa forma, possvel introduzir
tcnicas de ajuste adaptativo nos parmetros de recepo do PE de destino, o que confere
maior robustez ao pseudo-circuito TDM em relao a grandes variaes de desempenho da
PSN, caracterstica extremamente desejvel para a grande variabilidade de condies
esperada numa aplicao de broadcasting IPTV. Uma vez que um dado receptor detecte
crescimento aprecivel no atraso sofrido pelos pacotes recebidos, o tamanho do jitter buffer
pode ser automaticamente incrementado, assegurando melhor acomodao do novo
patamar de atraso; da mesma forma, quando detectada a melhoria de desempenho da rede
em relao ao atraso, o tamanho do jitter buffer pode ser imediatamente reduzido por esse
receptor, preservando seus recursos, sem prejuzo da continuidade do fluxo TDM. A Figura
2.14 ilustra o comportamento transparente do mecanismo de seqenciamento durante uma
reconfigurao, supondo a mudana de tamanho no jitter buffer de 16 para 24 posies.

A50

Transmissor
Receptor - Thread Escrita
Receptor - Thread Leitura
Posio a
Posio a
gravar
ler
Seqncia transmitida
Seqncia recebida
Fluxo TDM
Tempo
(ms)
NS
Contedo Ordem
NS
Contedo (NS mod 16) Ordem Ponteiro Contedo (seqencial)
0
16000
A
B
1
16001
2
16002
C
3
16003
D
Atraso mdio da rede: 8 ms = 50% buffer Atraso mdio da rede: 8 ms = 50% buffer
4
16004
E
5
16005
F
6
16006
G
7
16007
H
8
16008
I
1
16000
A
0
J
C
9
16009
2
16002
2
10
16010
K
3
16001
B
1
11
16011
L
4
16003
D
3
Incio Fluxo TDM: Atraso de 8ms =
50%Buffer
12
16012
M
5
16002
C
2
13
16013
N
6
16004
E
4
O
H
14
16014
7
16007
7
15
16015
P
8
16005
F
5
16
16016
Q
9
16009
J
9
1
16000
A
0
17
16017
R
10
16008
I
8
2
16001
B
1
18
16018
S
11
16010
K
10
3
16002
C
2
19
16019
T
12
16012
M
12
4
16003
D
3
20
16020
U
13
16014
O
14
5
16004
E
4
21
16021
V
14
16013
N
13
6
16005
F
5
22
16022
W
15
16011
L
11
7
16006 (vazio)
6
X
P
H
23
16023
16
16015
15
8
16007
7
24
16024
Y
17
16017
R
1
9
16008
I
8
25
16025
Z
18
16016
Q
0
10
16009
J
9
26
16026
AA
19
16020
U
4
11
16010
K
10
AB
T
L
27
16027
20
16019
3
12
16011
11
28
16028
AC
21
16018
S
2
13
16012
M
12
29
16029
AD
22
16006
G
No gravar
14
16013
N
13
30
16030
AF
23
16023
X
7
15
16014
O
14
31
16031
AG
24
16025
Z
9
16
16015
P
15
Reconfigurao de 16 para 24 posies.
32
16032
AH
25
16024
Y
16
17
16016 (vazio)
8
33
16033
AI
26
16020
U
12
18
16017 (vazio)
9
AJ
V
34
16034
27
16021
13
19
16018 (vazio)
10
35
16035
AK
28
16022
W
14
20
16019 (vazio)
11
36
16036
AL
29
16026
AA
18
21
16020
U
12
37
16037
AM
30
16018
S
No gravar
22
16021
V
13
38
16038
NA
31
16027
AB
19
23
16022
W
14
39
16039
AO
32
16029
AD
21
24
16023 (vazio)
15

Jitter Buffer
Posio
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

NS
Dado
Armazenado Armazenado
16000 16016
A
Q
16001 16017
B
R
16002 16018 C/C
S
16003 16019
D
T
16004 16020
E
U
16005
F
16014
(vazio)
16007 16023
H
X
16008
I
(vazio)
16009 16025
J
(vazio)
16010
K
(vazio)
L
16011
(vazio)
16012 16020
M
U
16013 16021
N
V
16014 16022
O
W
16015
P
(vazio)
16024
Y

Ordem de Ordem de
Escrita
Leitura
1
18
1
3
17
2
2/5
21
3
4
20
4
6
19
5
8
6
22
7
7
23
8
10
9
17
9
24
10
18
11
30
11
19
15
12
20
12
26
13
21
14
27
14
22
13
28
15
23
16
16
24
25

16026
16027

AA
AB

29
31

16029

AD

32

Perda de pacote
Pacote atrasado
Pacote replicado

Figura 2.14 - Exemplo de reconfigurao dinmica do jitter buffer.

A seguir, apresentado um pseudo-cdigo para implementao do novo mecanismo de
seqenciamento de pacotes proposto nesse trabalho:

Aplicao para Recepo de dados TDM sobre PSN:

// Objetos globais compartilhados entre as threads:

PonteiroTDM
Inteiro 16 bits ; ponteiro de leitura dos pacotes no buffer
TamanhoBuffer
Inteiro
; tamanho, em pacotes, do buffer de recepo
TempoPacote
Inteiro
; durao, em ms, dos dados TDM em cada pacote
Buffer:
Estrutura
; buffer de armazenamento dos pacotes recebidos
Buffer.NS
(0..TamanhoBuffer-1) de Inteiro 16 bits
Buffer.Payload
(0..TamanhoBuffer-1) de Pacote
// Inicializao do buffer de recepo:
Posicao
Inteiro
(0)
ENQUANTO Posio < TamanhoBuffer
Buffer.NS(Posicao) = 0
Incrementa(Posicao)
FIM ENQUANTO ; assegura que NS = 0 para inicializao do buffer
AguardaPacotes()
; aguarda a chegada do primeiro pacote na porta 2142 (TDMoIP)
EscritaBuffer.inicio() ; inicia thread de escrita no buffer
Espera(TamanhoBuffer*TempoPacote*50%)
; aguarda ocupao de 50% do buffer
LeituraBuffer.inicio() ; inicia thread de leitura no buffer

A51

Thread de Escrita:

FUNCAO EscritaBuffer()
// Armazenamento dos pacotes no buffer de recepo:
NS
Inteiro 16 bits ; nmero de seqncia a escrever
Posicao
Inteiro
; posio de escrita no buffer
Payload
Pacote
; dados a escrever
PacoteRx:
Estrutura
; objeto para tratamento dos pacotes recebidos
PacoteRx.NS
Inteiro 16 bits
PacoteRx.Payload
Pacote
PacoteRx = BuscaPacote()
; obtm primeiro pacote recebido da interface de rede
NS = PacoteRx.NS
; obtm o nmero de seqncia desse pacote
Payload = PacoteRx.Payload
; obtm os dados desse pacote
Posicao = NS mod TamanhoBuffer ; define posio de escrita do primeiro pacote
Buffer.grava(Posicao, NS, Payload) ; grava primeiro pacote no buffer
PonteiroTDM = PacoteRx.NS
; define posio inicial do ponteiro de leitura
ENQUANTO AplicacaoAtiva
NS = PacoteRx.NS
; obtm o nmero de seqncia do pacote
Payload = PacoteRx.Payload
; obtm os dados do pacote
Posicao = NS mod TamanhoBuffer ; define posio de escrita
// Grava o pacote no buffer de recepo se este no estiver atrasado demais:
SE NS > PonteiroTDM ENTAO Buffer.grava(Posicao, NS, Payload)
PacoteRx = BuscaPacote()
; obtm novo pacote da interface de rede
FIM ENQUANTO

Thread de Leitura:

FUNCAO LeituraBuffer()
// Leitura dos pacotes do buffer de recepo e gerao do fluxo TDM de sada:
NS
Inteiro 16 bits ; nmero de seqncia lido do buffer
Posicao
Inteiro
; posio de leitura do buffer
Payload
Pacote
; dados lidos do buffer
PacoteRx:
Estrutura
; objeto para tratamento dos pacotes recebidos
PacoteRx.NS
Inteiro 16 bits
PacoteRx.Payload
Pacote
Posicao=PonteiroTDM mod TamanhoBuffer
; obtm posio de leitura no buffer
ENQUANTO AplicacaoAtiva
Payload = Buffer.le(Posicao,Payload)
; obtm os dados do pacote
TransmiteTDM(Payload)
; reproduz dados para fluxo TDM
Incrementa(PonteiroTDM)
; avana pacote a ser lido
Posicao=PonteiroTDM mod TamanhoBuffer ; obtm posio de leitura no buffer
NS = Buffer.le(Posicao,NS)
; obtm o nmero de seqncia do
; prximo pacote armazenado

A52

// Mitiga perda se o pacote armazenado no for o esperado pelo ponteiro:

SE NS <> PonteiroTDM ENTAO MitigaPerda()
// Executa processo de sincronizao do fluxo TDM:
Espera(TempoPacote)
FIM ENQUANTO
FUNCAO MitigaPerda()
// Exemplo de mitigao de pacotes perdidos:
Buffer.grava(Posicao, PonteiroTDM, Payload)

; grava os dados do pacote anterior na

; prxima posio do buffer a ser lida

Cabe observar que a implementao do mecanismo proposto extremamente simples, e

assegura robustez adicional para a utilizao de tcnicas avanadas para a mitigao das
perdas de pacote, uma vez que a verificao da validade do prximo pacote realizada
imediatamente aps a transmisso do ltimo pacote vlido, preparando a prxima
transmisso para dos dados fluxo TDM, o que assegura um intervalo equivalente durao
dos dados em cada pacote para o processamento dessa mitigao. Considerando um fluxo
E1, para 256 octetos de dados por pacote, a regenerao dos dados de um pacote perdido
poderia consumir at 1ms de processamento, sem afetar a continuidade desse fluxo.
2.3.3 O mecanismo alternativo para sincronizao TDM proposto

Na implementao RAD com sincronizao adaptativa, utilizada a monitorao do estado

de ocupao do jitter buffer ao longo tempo como mecanismo de sincronismo para a
regenerao do fluxo TDM, atuando diretamente sobre a freqncia de relgio do oscilador
local que controla a taxa de envio dos bits TDM interface de sada, conforme apresentado
anteriormente na Figura 2.11.
Como j evidenciado, essa caracterstica torna a preciso do relgio de sada fortemente
dependente do desempenho da PSN, uma vez que as perdas de pacote tm influncia direta
na ocupao do jitter buffer, tendendo a retardar o relgio do receptor mesmo que este
esteja reproduzindo fielmente o relgio do fluxo TDM de origem. Da mesma forma, uma
rajada de pacotes gerada por melhoria nas condies de enfileiramento em um dado n da
PSN, que alcance o receptor num intervalo relativamente curto, tende a acelerar o relgio
do receptor de forma equivocada. Ambas as situaes so indesejveis quando da
utilizao da tecnologia TDMoIP como alternativa para broadcasting IPTV, pois essas
A53

alteraes indevidas na taxa do fluxo de bits de sada tendem a ser agravadas pelos
algoritmos de decodificao de udio e vdeo nos receptores conectados ao CE de destino,
afetando negativamente a qualidade do servio emulado atravs do pseudo-circuito.
Desse forma, como a premissa da alternativa PWE3 para broadcasting de IPTV
estabelecer um fluxo de bits confivel, a taxa constante e transparente aos protocolos e
codificadores de udio e vdeo utilizados, necessrio utilizar uma tcnica de
sincronizao adaptativa diferente, que assegure a estabilidade e a preciso do relgio no
PE de destino mesmo em condies de QoS no assegurada pela PSN, como por exemplo
aquelas baseadas em transmisso de uma marcao de tempo (timestamp) explcita para os
pacotes, utilizando o protocolo RTP, conforme apresentado anteriormente na Figura 2.10.
Em [AWEYA2004] foi realizado um estudo dessa alternativa, incluindo o projeto de um
circuito PLL para garantia da sincronizao do relgio no receptor, de forma a atender aos
requisitos estabelecidos para a regenerao do fluxo TDM. Esse estudo foi validado atravs
de resultados experimentais, obtidos com a implementao do PLL na emulao de um
circuito T3 no estruturado, utilizando placas wanPMC-2T3E3 da SBE Inc. e uma rede
Ethernet com parmetros controlados, conforme apresentado em [AWEYA2004a].
Contudo, a utilizao do protocolo RTP para a transmisso explcita de timestamps atravs
da PSN no desejvel para nossa proposta de broadcasting IPTV, pois implica em maior
complexidade de implementao e num overhead adicional de 12 octetos para cada pacote
transmitido, reduzindo a eficincia de banda do pseudo-circuito.
Para fluxos onde a taxa de bits constante (CBR), a quantidade de octetos em cada pacote,
embora configurvel, invariante para o pseudo-circuito estabelecido, representando um
intervalo de tempo bem definido e fixo, como pode ser observado na Tabela 2.2.

A54

Tabela 2.2 - Durao das amostras TDM para cada tamanho do pacote de dados.
Tamanho do
Pacote
(Payload)
32 octetos
47 octetos
64 octetos
94 octetos
96 octetos
128 octetos
141 octetos
160 octetos
188 octetos
192 octetos
224 octetos
235 octetos
256 octetos
282 octetos
288 octetos
320 octetos
329 octetos
352 octetos
376 octetos
384 octetos
416 octetos
423 octetos
448 octetos
470 octetos
480 octetos
512 octetos
517 octetos
564 octetos
611 octetos
640 octetos
658 octetos
705 octetos
752 octetos
768 octetos
799 octetos
846 octetos
893 octetos
896 octetos
940 octetos
987 octetos
1024 octetos
1034 octetos
1081 octetos
1128 octetos
1152 octetos
1175 octetos
1222 octetos
1269 octetos
1280 octetos
1316 octetos
1363 octetos
1410 octetos

SAToP

CESoPSN
0,125 ms

TDMoIP/
CBR
0,184 ms

0,250 ms
0,367 ms
0,375 ms
0,500 ms
0,551 ms
0,625 ms
0,734 ms
0,750 ms
0,875 ms
0,918 ms
1,000 ms

1,000 ms
1,102 ms
1,125 ms
1,250 ms
1,285 ms
1,375 ms
1,469 ms
1,500 ms
1,625 ms
1,652 ms
1,750 ms
1,836 ms

2,000 ms

1,875 ms
2,000 ms
2,020 ms
2,203 ms
2,387 ms
2,500 ms
2,570 ms
2,754 ms
2,938 ms

3,000 ms

3,000 ms
3,121 ms
3,305 ms
3,488 ms
3,500 ms
3,672 ms
3,855 ms

4,000 ms

4,000 ms
4,039 ms
4,223 ms
4,406 ms
4,500 ms
4,590 ms
4,773 ms
4,957ms

5,000 ms

5,000 ms
5,141 ms
5,324 ms
5,508 ms

A55

Dessa forma, como o nmero de seqncia de cada pacote incrementado de forma

monotnica para cada pacote transmitido, e os pacotes precisam ser gerados a uma taxa
constante para acomodar a caracterstica CBR do fluxo TDM, tem-se que a timestamp
simplesmente uma funo linear do nmero de seqncia do pacote, dada pela expresso
(2.6). , o que torna a sua transmisso completamente dispensvel.
Timestamp n = ( NS n NS 0 ).TempoPa cot e + Timestamp0

(2.6)

Onde:
NS0

o nmero de seqncia inicial da sesso, aleatrio;

NSn

o nmero de seqncia do ensimo pacote recebido;

TempoPacote o intervalo de dados TDM contido no pacote (Tabela 2.2);

Timestamp0

a timestamp inicial definida para a sesso, aleatria;

Timestampn

a timestamp do ensimo pacote recebido.

Assim, a expresso (2.6) pode ser utilizada para determinao da timestamp a partir do
nmero de seqncia recebido, permitindo a utilizao da tcnica de sincronizao
adaptativa proposta em [AWEYA2004] sem necessidade de utilizao do protocolo RTP,
conforme apresentado na Figura 2.15, adaptada daquele trabalho, e descrito a seguir:
a) O receptor gera a timestamp para cada pacote recebido, a partir do NS recebido, do NS
inicial e da timestamp inicial, e armazena a mesma no buffer de timestamps;
b) Essa timestamp utilizada como entrada do PLL para a regenerao do relgio no
receptor, de forma sincronizada com o relgio de transmisso no PE de origem;
c) O relgio regenerado utilizado para controle da taxa de bits de sada e tambm para
incremento do contador do PLL, carregado inicialmente com a timestamp gerada a
partir do primeiro NS recebido;
d) O comparador associado ao mecanismo de controle do fluxo de bits de sada compara a
timestamp regenerada pelo contador do PLL, deslocada pelo valor de atraso esperado,
com a timestamp gerada a partir do NS recebido, que foi armazenada no buffer,
liberando os dados TDM para a interface de sada quando estas forem coincidentes.

A56

Dados

Buffer dados

timestamp

Buffer timestamp

Pacotes
Clculo
timestamp
NS

PLL

Valor do
contador

Fluxo
TDM
Timestamp
recebida

Timestamp
regenerada

+
-

Atraso
presumido
Freqncia de sada (taxa de bits)

Figura 2.15 - Mecanismo de recuperao do relgio baseado em timestamp e PLL.

Entretanto, uma anlise mais aprofundada do mecanismo acima permite observar que no
efetivamente necessrio o clculo explcito da timestamp, uma vez que esta uma funo
linear do nmero de seqncia tanto quando recebida como quando regenerada, sendo
possvel realizar todo o processo de sincronizao, incluindo a operao do PLL e a
comparao final para liberao do fluxo de bits de sada, exclusivamente com base nesse
nmero recebido. Associando esse fato ao novo mecanismo de seqenciamento proposto
na seo 2.3.2, onde a anlise do nmero de seqncia determina diretamente a posio de
escrita no jitter buffer, possvel simplificar ainda mais o mecanismo de sincronizao do
fluxo TDM no receptor, conforme apresentado na Figura 2.16 e descrito a seguir:
a) O NS recebido utilizado diretamente como entrada do PLL para a regenerao do
relgio no receptor, sendo tambm analisado para definio da posio de
armazenamento no buffer, conforme algoritmo de seqenciamento proposto;
b) O relgio regenerado utilizado para controle da taxa de bits de sada, atravs de um
escalonador, e tambm para incremento do contador do PLL, carregado inicialmente
com o primeiro NS recebido;
c) O comparador associado ao escalonador compara o NS regenerado (NPRESUMIDO) pelo
contador do PLL, deslocado por uma determinada quantidade de pacotes NESPERA, com
o NS recebido em cada pacote, armazenado no buffer, liberando os dados TDM para a

A57

interface de sada quando os mesmos forem coincidentes, o que assegura o sincronismo

entre o fluxo TDM em direo ao CE de destino e aquele recebido pelo PE de origem.

Pacotes

Analisador NS

NS

Dados
Fluxo
TDM
NS
pacote
NESPERA

Buffer

Escalonador

NS presumido

PLL

Freqncia de sada

Figura 2.16 - Recuperao do relgio no receptor pelo mtodo adaptativo proposto.

A quantidade de pacotes NESPERA define quantos pacotes devem ser armazenados no jitter
buffer antes que seja iniciada a regenerao do fluxo TDM na sada, correspondendo ao
atraso que deve ser introduzido para acomodao da PDV oferecida pela PSN.
Tipicamente, como o jitter buffer deve operar na condio central em regime permanente,
dado pela Expresso (2.7)
N ESPERA = 50%.TamanhoBuffer (

(2.7)

No Captulo 4 ser descrita em maiores detalhes a operao do mecanismo de

sincronizao apresentado na Figura 2.16, incluindo a descrio detalhada dos blocos que
compe o PLL e sua fundamentao matemtica, bem como a proposta desenvolvida nesse
trabalho para utilizao de tcnicas de controle clssico visando ao aprimoramento do seu
desempenho, a fim de atender aos requisitos de sincronismo para a utilizao da tecnologia
TDMoIP como alternativa para broadcasting IPTV.

A58

2.4 - COMPARAO ENTRE AS TECNOLOGIAS TDMoIP E VoIP

Em princpio, a tecnologia TDMoIP bem mais simples que VoIP por ser completamente
transparente sinalizao e aos protocolos de voz e dados, mesmo quando estes so
proprietrios, bem como em funo da inexistncia de modificaes nos equipamentos
terminais. Por mais que venha sendo rapidamente desenvolvida nos ltimos anos, a
tecnologia VoIP ainda apresenta algumas questes em aberto em relao a diversidade de
protocolos, compatibilizao entre os formatos de mdia existentes e desenvolvimento de
mecanismos eficientes para traduo entre os mecanismos de sinalizao envolvendo a
RFTC tradicional, o que vem limitando a criao de servios e funcionalidades s quais os
clientes j esto acostumados, enquanto TDMoIP aproveita todas as funcionalidades
existentes das centrais pblicas e privadas para comutao de voz, de forma transparente.
De maneira geral, entende-se que VoIP seja uma alternativa interessante para as novas
implementaes no transporte de voz, onde necessrio construir uma outra rede e adquirir
novos equipamentos, enquanto TDMoIP recomendvel para a racionalizao dos custos
de operao das redes existentes, sobretudo de transporte, bem como para a expanso
dessas redes com pequenos investimentos, quando no so desejados servios e
funcionalidades distintas daquelas j existentes.
2.4.1 Semelhanas entre as tecnologias

Ambas as tecnologias tm como objetivo fundamental a melhoria da eficincia de

ocupao de banda dentro da rede de transporte, atravs da substituio dos circuitos
dedicados, utilizados nas redes tradicionais, pela comutao de pacotes, que permite o
compartilhamento eficiente dos meios de transmisso entre pacotes de diversas origens e
destinos, contendo voz, dados e vdeo, reduzindo drasticamente os custos de transporte.
Os gateways VoIP so mais complexos, incluindo DSPs (Digital Signal Processors) que
permitem facilidades como compresso de voz e supresso de silncio, que reduzem
significativamente o consumo de largura de banda na transmisso e, portanto, apresentam
eficincia bem maior que o transporte TDM convencional. Contudo, isso feito s
expensas de uma menor qualidade de voz e maior latncia nessa transmisso, pela
A59

necessidade de armazenamento e processamento das amostras de voz, e no quase sempre

introduzindo pesado overhead na transmisso dos pacotes de voz propriamente ditos.
J a relativa simplicidade dos

gateways TDMoIP

tambm permite um melhor

aproveitamento da banda de transmisso que o transporte TDM convencional, eliminando

parte do overhead de estrutura e canais ociosos dentro do entroncamento, mas preserva a
qualidade de voz, apresenta latncia menor que o VoIP, e completamente transparente
para os terminais, evitando assim a substituio dos equipamentos TDM utilizados, como
centrais e PBX digitais, conservando os investimentos realizados e evitando novos custos
com treinamento, operao e manuteno dos equipamentos VoIP.
No que tange aos desafios enfrentados, as duas tecnologias buscam solues bastante
similares, pois ambas utilizam redes comutadas a pacotes para transporte de voz, sendo
fortemente afetadas pelas caractersticas no-determinsticas das mesmas: a perda de
pacotes e o atraso varivel ao atravessar a rede. Assim, so feitas algumas comparaes
diretas entre VoIP e as abordagens PWE3, considerando seu comportamento frente a essas
caractersticas, bem como aspectos importantes do ponto de vista de implementao, como
a eficincia de utilizao da largura de banda e a complexidade computacional envolvida,
que apresentam impacto direto nos custos da soluo adotada.
2.4.2 Sensibilidade s perdas de pacotes

A perda de pacotes durante o transporte dos sinais de voz provoca falhas ou intervalos
significativos no fluxo de amostras, produzindo sons entrecortados, desconfortveis ou
mesmo ininteligveis. O efeito preciso das perdas de pacotes na qualidade da voz
transmitida, bem como o desenvolvimento de algoritmos para mitigao dessas perdas,
conhecidos como PLC (Packet Loss Concealment) tem sido objeto de estudos avanados
dentro da comunidade VoIP, como o trabalho de anlise dos efeitos dessa mitigao para
diversos codificadores de voz, realizado pelo LabCom/UnB e disponvel em
[OBANDO2005]. Alguns resultados significativos desses estudos podem ser resumidos,
conforme apresentado em [STEIN2003]:
a) Cerca de 1% de perda de pacotes causam queda na qualidade de voz percebida,
baixando do padro normalmente reconhecido em telefonia fixa para nveis
A60

equivalentes qualidade observada em telefonia mvel celular, que utiliza

inerentemente algoritmos de compresso;
b) Acima de 2%, a perda de pacotes a causa dominante para a deteriorao da qualidade
de voz, tornando comparveis entre si, em termos de qualidade, sinais de voz com e
sem utilizao de algoritmos de compresso;
c) Utilizando algoritmos apropriados para mitigao da perda de pacotes, at 5% de perda
para sinais de voz no comprimidos ainda permitem qualidade comparvel ou superior
quela observada em telefonia mvel celular, com seus algoritmos de compresso.
Contudo, esses resultados no so diretamente aplicveis tecnologia TDMoIP, uma vez
que o pacote VoIP contm tipicamente entre 80 e 240 amostras do sinal de voz,
representando entre 10 e 30 ms de conversao; enquanto os pacotes TDMoIP podem
conter uma nica amostra, ou um nmero pequeno delas, representando at 0,625 ms de
conversao (para 5 amostras por canal, o limite para um tronco E1 considerando a MTU
Ethernet), o que reduz bastante sua sensibilidade s perdas de pacote, em funo da
elevada redundncia inerente aos sinais de voz. Assim, de um modo geral, esperado que
os canais de voz transportados atravs de um entroncamento TDMoIP suportem,
individualmente, perdas de pacotes bem superiores a esses limites, sem prejuzo
considervel da qualidade de conversao.
Na Tabela 2.3 apresentado um comparativo entre algumas configuraes VoIP e as trs
abordagens para transporte de circuitos TDM sobre redes de pacotes: TDMoIP, SAToP e
CESoPSN. Esse comparativo considera o codificador utilizado; sua designao usual; sua
taxa nominal de bits por canal; a avaliao MOS obtida segundo o algoritmo PESQ
(Perceptual Evaluation of Speech Quality), determinada de acordo com os experimentos
realizados no LabCom/UnB, apresentados em [OBANDO2005] - com exceo do
codificador G.726, onde foi utilizado o valor nominal apresentado em [COLLINS2001]; a
quantidade de amostras de voz por pacote, assumindo pacotes de 1 ms para as tecnologias
TDM; e o tempo de convergncia, em milissegundos, definido como o tempo que o estado
do decodificador leva, aps uma ocorrncia de perda de quadros (decorrente da perda de
pacotes na rede), para convergir ao mesmo estado em que se encontrava o codificador para
uma dada amostra, tambm de acordo com os experimentos realizados no LabCom/UnB.

A61

Tabela 2.3 - Amostras de voz por tecnologia e codificador utilizado.

Tecnologia

VoIP

TDMoIP
CESoPSN
SAToP

Codificador

Designao

G.711
G.723.1
G.723.1
G.726
G.729
iLBC
iLBC
G.711
G.711
G.711

PCM
MP-MLQ
MP-ACELP
ADPCM
CS-ACELP

Taxa Nominal
por Canal
(kbps)

MOS
(PESQ)

64,00
6,30
5,30
32,00
8,00
13,33
15,20
64,00
64,00
64,00

PCM
PCM
PCM

Amostras por
pacote

4,41
3,52
3,38
4,00
3,78
3,85
4,41
4,41
4,41

160
60
60
80
240
160
240
7,83
8
8

Tempo de
Convergncia
(ms)

0
128
132
80
30
0
0
0

Cabe observar, nessa tabela, que um pacote VoIP utilizando o codificador G.729 transporta
trinta vezes mais informao de voz que um pacote TDMoIP tpico, para um mesmo
canal, o que o torna bem mais sensvel a qualquer perda. Alm disso, a utilizao da
codificao G.711, sem compresso, torna as amostras de voz completamente isoladas
entre si, no existindo propagao da perda de um pacote para as demais amostras, como
descrito pelo tempo de convergncia nulo, contra um intervalo de 30ms a 132 ms para os
codificadores que utilizam compresso, o que tambm confere mais robustez s tecnologias
PWE3 em relao a VoIP quanto sensibilidade s perdas de pacote.
2.4.3 Eficincia de utilizao da largura de banda

A tecnologia VoIP apresenta uma maior eficincia de utilizao da largura de banda da

PSN para a transmisso de um nico canal de voz, em virtude da possibilidade de
utilizao de tcnicas de compresso de voz e supresso de silncio, presentes na nos
codificadores utilizados pela maioria das aplicaes desse tipo.
Contudo, quando consideramos a questo sob o ponto de vista de um entroncamento, onde
existem, por exemplo, 30 canais de voz sendo transportados, essa eficincia deixa de ser
to premente, uma vez que, por caracterstica, os canais VoIP so transportados
individualmente sobre a PSN, pois os pacotes de voz so gerados pelos equipamentos
terminais, que so conectados diretamente a essa rede de pacotes. Enquanto isso, na
tecnologia TDMoIP , o efeito de multiplexao das amostras de voz intrnseco, pois a

A62

mesma foi desenvolvida exatamente para o transporte de circuitos de entroncamento,

contendo mltiplos canais, atravs de um pseudo-circuito emulado dentro da PSN (PWE3).
Com isso, todo o overhead necessrio para o transporte dos pacotes dentro da rede acaba
sendo compartilhado por todos os canais transportados, reduzindo a distncia entre as duas
tecnologias no que se refere largura de banda total ocupada no transporte atravs da
PSN, como pode ser observado na Tabela 2.4, que apresenta as taxas efetivas de bits
considerando 30 canais independentes VoIP, com cada um dos codificadores e um circuito
E1 com os mesmos 30 canais transportados atravs de PWE3 para as trs abordagens,
considerando pacotes de 1 ms. Em todos os casos considerado o protocolo IP (cabealho
de 20 octetos), com transporte UDP (cabealho de 8 octetos), lembrando que para as
aplicaes VoIP e a abordagem CESoPSN utilizado tambm o protocolo RTP (cabealho
de 12 octetos).
Cabe observar, nessa tabela, que para o mesmo codificador G.711, as trs tecnologias
baseadas em PWE3 so mais eficientes que a tecnologia VoIP em decorrncia do efeito da
multiplexao sobre o overhead. Alm disso, a eficincia do codificador VoIP G.729 (CSACELP), sobre o G.711 utilizado em TDMoIP, que nominalmente oito vezes superior,
cai para menos de quatro vezes quando considerada a taxa efetiva de bits por canal, efeito
que se repete para os demais codificadores.
Tabela 2.4 - Overhead e taxa efetiva por tecnologia e codificador utilizado.
Taxa
Bits de
Nominal
Voz
por
Tecnologia Codificador Designao
por
Canal
Canal
(kbps)
PCM
64,00
1280
G.711
MP-MLQ
6,30
189
G.723.1
MP-ACELP
5,30
158
G.723.1
VoIP
ADPCM
32,00
640
G.726
CS-ACELP
8,00
240
G.729
13,33
304
iLBC
15,20
400
iLBC
PCM
64,00
62,7
TDMoIP
G.711
PCM
64,00
64,0
CESoPSN
G.711
PCM
64,00
64,0
SAToP
G.711

Bits de
Overhead
por
Canal
320
320
320
320
320
320
320
8,8
11,7
8,5

Taxa
Pacotes
Overhead Efetiva na
por
por Canal PSN por
segundo
(%)
Canal
(pps)
(kbps)
50,0
20%
80,0
33,3
63%
17,0
33,5
67%
16,0
50,0
33%
48,0
33,3
57%
18,7
43,8
51%
27,4
38,0
44%
27,4
1.021,3
12%
73,0
1.000,0
15%
75,7
1.000,0
12%
72,5

Evidentemente, a situao apresentada um caso particular de anlise, podendo ser

utilizadas tcnicas de compresso do cabealho IP/UDP, que reduziriam o overhead para o

A63

transporte dos canais VoIP, da mesma forma que existe um trfego adicional, no
considerado, do protocolo RTCP nas tecnologias que utilizam RTP.
Esses resultados apontam problemas com a utilizao de aplicaes VoIP em substituio
aos circuitos E1 convencionais no ambiente dos clientes, medida que cresce a quantidade
de canais transportados, em funo do excesso de overhead gerado sobre a PSN, pois cada
canal tratado de forma independente. Assim, tm surgido solues contemplando a
multiplexao desses canais no nvel do protocolo RTP, acopladas diretamente a
equipamentos PBX, permitindo que os mesmos sejam tratados como um arranjo nico, o
que melhoraria o overhead de transporte em cerca de 15% [RAD2003]. Dentro das redes IP
das operadoras, no entanto, o problema menos significativo, pois os canais de voz so
previamente agregados em troncos TDM convencionais e encaminhados PSN atravs de
trunking gateways.
2.4.4 Complexidade computacional

Em uma anlise preliminar das duas situaes apresentadas no Captulo 1, Figuras 1.6 e
1.7, onde realizada a comunicao entre dois telefones convencionais utilizando,
respectivamente, as tecnologias VoIP e TDMoIP, pode-se observar que a complexidade
inerente a uma aplicao VoIP bastante superior, conforme ser descrito a seguir.
Em princpio, para que a comunicao com a aplicao VoIP seja possvel entre duas
RTFC distintas, em um ambiente de operadora, so necessrios, pelo menos, cinco
equipamentos, alm dos roteadores e demais elementos da prpria PSN:

dois trunking gateways, um em cada RTFC, que recebem o trfego de voz analgica
gerado pelos telefones, j codificado pelas centrais da RTFC em canais digitais a
64kbps (G.711), dentro de um circuito TDM (tronco) de entrada. Uma vez recebidos,
os canais de voz so convertidos, atravs de um arranjo de DSPs apropriado, em
amostras de voz correspondentes ao codificador desejado (G.729, por exemplo), que
por sua vez so encapsuladas em pacotes de voz para transporte dentro da rede IP.
Chegando ao trunking gateway de destino, as amostras de voz so retiradas dos
pacotes e reconvertidas pelos DSPs em canais digitais a 64kbps, que so transmitidos

A64

atravs de um circuito TDM (tronco) de sada para a central de destino, onde o canal
decodificado em voz analgica que recebida pelo outro telefone.

dois signaling gateways, um em cada RTFC, que recebem a sinalizao ISUP (SS7)
correspondente ao circuito TDM (tronco) de entrada e realizam a sua converso,
tambm atravs de DSPs, gerando uma sinalizao equivalente para transporte dentro
da rede IP e reconvertendo os pacotes de sinalizao recebidos em mensagens ISUP
(SS7) correspondentes ao circuito TDM (tronco) de sada, de forma a assegurar a
continuidade de sinalizao entre nas duas RTFC.

um media gateway controller ou softswitch, para controlar o fluxo de pacotes, mapear

nmeros de telefone em endereos e definir o tipo de codificao utilizado entre os
dois trunking gateways, bem como acompanhar o estado da chamada em curso,
interpretando as mensagens recebidas das RTFC atravs dos signaling gateways.

Alm disso, para que esses cinco equipamentos possam comunicar-se adequadamente entre
si no desempenho das funes necessrias para assegurar a comunicao entre os dois
telefones, so necessrios, pelo menos, mais trs protocolos, que precisam estar
implementados em seus processadores, alm dos protocolos IP e UDP da PSN:

RTP/RTCP, para controlar o fluxo de pacotes de voz entre os dois trunking gateways,
assegurando a sincronizao das amostras de voz durante a conversao;

MGCP ou MEGACO/H.248, para realizar a comunicao entre os dois

trunking

gateways e o softswitch, assegurando o controle total deste sobre a chamada em curso;

SIGTRAN, para realizar a comunicao entre os dois

signaling gateways e o

softswitch, assegurando que mensagens de sinalizao possam ser recebidas e

interpretadas por estes, a fim de acompanhar e controlar o estado da chamada em curso.
Enquanto isso, para que a comunicao com a aplicao TDMoIP seja possvel entre as
mesmas duas RTFC distintas, so necessrios, alm dos roteadores e demais elementos da
prpria PSN, apenas dois gateways TDMoIP, um em cada RTFC, que tambm recebem o
trfego de voz analgica gerado pelos telefones, codificado em canais digitais a 64kbps
(G.711), dentro de um circuito TDM (tronco) de entrada. Uma vez recebido em cada
gateway TDMoIP, o canal de voz associado conversao compe, juntamente com os
demais canais presentes no circuito TDM, incluindo aqueles destinados sinalizao entre
as RTFC, um nico fluxo contnuo de bits, que subdividido a intervalos regulares
A65

previamente configurados pelo processador do gateway. Essas seqncias de bits so

encapsuladas em pacotes para transporte atravs da PSN, sendo agregada a cada pacote
uma Palavra de Controle. Chegando ao gateway TDMoIP de destino, as seqncias de
bits recebidas so retiradas dos pacotes e reagrupadas pelo processador do mesmo de
acordo com o seqenciamento estabelecido pela palavra de controle. Assim, o fluxo
contnuo de bits presente na respectiva origem recuperado para os circuitos TDM
(troncos) de sada em cada gateway TDMoIP, dentro dos quais esto inseridos os canais
digitais a 64kbps correspondentes aos telefones em conversao, que so transmitidos at
a respectiva central de destino e decodificados em voz analgica, recebida pelo outro
telefone.
Dessa forma, so realizados apenas processamentos locais e independentes entre si, como
montagem/desmontagem de pacotes, insero da Palavra de Controle, ponteiros AAL1, e
clculo de CRCs, no sendo necessrios protocolos de comunicao entre os dois gateways
ou entre esses e a RTFC, uma vez que a sinalizao transportada de forma transparente.
Existe, entretanto, um protocolo de Conectividade de Operao e Manuteno (OAM
Connectivity), com objetivo de reconhecer uma conexo vlida antes de iniciar o fluxo de
dados TDM, evitando sobrecarga de pacotes na PSN sem que o pseudo-circuito esteja
estabelecido e operacional com o gateway de destino para seu recebimento, mas esse
protocolo no essencial para funcionamento da tecnologia.
Deve ser observado que, na Figura 1.7, a comunicao no acontece atravs das RTFC,
mas pela conexo direta dos telefones ao gateway TDMoIP. Evidentemente, isso
possvel apenas quando o gateway possui uma interface FXS onde conectado o telefone.
Caso contrrio, tambm necessria a codificao prvia em canais digitais a 64kbps
(G.711), funcionalidade presente nos equipamentos PBX digitais existentes.
Existe razovel complexidade computacional na recepo dos fluxos

TDMoIP com

sincronizao adaptativa, em virtude dos mecanismos de recuperao de relgio, assim

como no caso de utilizao de tcnicas especiais para a mitigao das perdas de pacote
durante a regenerao do fluxo TDM, mas essa complexidade nas aplicaes baseadas em
VoIP demonstra-se bem superior.
A66

A maior complexidade computacional refletida nos investimentos necessrios para

implantao das duas solues, estimados [RAD2003], para um enlace T1 (24 canais de
voz) com qualidade de voz equivalente oferecida por uma operadora, em:

VoIP:

US$ 15.000,00/porta;

TDMoIP:

US$ 1.500,00/porta (confirmado pela RAD do Brasil).

2.4.5 Latncia e requisitos para transporte do trfego de voz

A latncia (delay) ou atraso total fim a fim experimentado pelos pacotes em uma dada
direo de conversao, assim como a variao desse atraso (PDV), tm impacto
significativo sobre a qualidade do transporte dos sinais de voz interativos utilizados em
telefonia, influenciando diretamente na percepo dos interlocutores. Um atraso muito
elevado compromete o dinamismo da conversao e gera colises, ou seja, ambos os
interlocutores acabam falando ao mesmo tempo, prejudicando o entendimento na
conversao. Um estudo aprofundado dos efeitos do atraso e variao do atraso em
aplicaes de voz encontrado em [BARRETO2001], mas pode ser considerada, para
anlise do seu impacto em telefonia, a escala apresentada na Tabela 2.5, elaborada a partir
dos requisitos apresentados na Recomendao ITU-T G.114.
Tabela 2.5 Efeito do atraso na qualidade do sinal de voz.
Latncia (ms) Qualidade do sinal reproduzido
0
Excelente
< 150
Bom
< 250
Regular
< 350
Pobre
< 450
Inaceitvel
Assim, so definidas pela Recomendao ITU-T G.114 trs faixas distintas para o atraso
experimentado em uma dada direo de conversao, assumindo, nesses casos, um controle
adequado do eco no circuito, que se torna necessrio para atrasos superiores a 25 ms. Essas
informaes, juntamente com as faixas normalmente aplicadas s redes privadas de
comunicao, esto compiladas na Tabela 2.6, e constituem os requisitos de latncia para
quaisquer aplicaes de transporte de voz atravs de redes de pacotes, independentemente
da tecnologia utilizada.

A67

Tabela 2.6 Especificaes de latncia mxima para redes pblicas e privadas.

Latncia (ms)
Descrio com base na Recomendao G.114
< 25
Aceitvel sem utilizao de canceladores de eco (G.131).
Aceitvel para a maioria das aplicaes dos usurios, presumindo
< 150
controle adequado de eco.
Aceitvel desde que os administradores da rede tenham
conscincia do tempo de transmisso e do impacto nas aplicaes
150-400
dos usurios.
Inaceitvel para planejamento de rede, pode ser excedido
> 400
excepcionalmente.
Latncia (ms)
Descrio normalmente aplicada para redes privadas
< 200
Aceitvel para redes privadas de comunicao.
< 250
Limite para redes privadas de comunicao.
Na Tabela 2.7 apresentado novo comparativo entre algumas configuraes VoIP e as trs
abordagens para transporte de circuitos TDM sobre redes de pacotes: TDMoIP, SAToP e
CESoPSN, descrevendo seus atrasos caractersticos. Esse comparativo considera o
codificador utilizado; sua designao usual; o atraso de codificao (COD), o atraso
algortmico associado a alguns tipos de codificadores (ALG), o atraso de decodificao
(DEC) e o atraso de processamento (PROC), conforme valores tpicos apresentados em
[CISCO2005] para cada uma dessas etapas, na tecnologia VoIP; e pacotes de 1 ms com
atraso de processamento tambm de 1 ms [RAD2005], para as trs abordagens PWE3. Nas
duas ltimas colunas so apresentados o atraso total, correspondente soma dos anteriores,
que representa o atraso fixo introduzido na comunicao, exclusivamente em decorrncia
da tecnologia e codificador utilizado; e a parcela da mxima latncia admissvel, de acordo
com a Recomendao ITU-T G.114, para uma comunicao de voz unidirecional.
Tabela 2.7 - Latncia fixa por tecnologia e codificador utilizado.
Tecnologia Codificador Designao

Atraso
COD
(ms)

Atraso
ALG
(ms)

Atraso
DEC
(ms)

Atraso de
PROC
(ms)

G.711
G.723.1
G.723.1
G.726
G.729
ILBC
ILBC
G.711
G.711
G.711

20,000
30,000
30,000
20,000
10,000
20,000
30,000
0,979
1,000
1,000

7,500
7,500
5,000
-

2,000
3,000
3,000
2,000
1,000
2,000
3,000
0,979
1,000
1,000

2,500
5,000
5,000
2,500
2,500
2,500
2,500
1,000
1,000
1,000

VoIP

TDMoIP
CESoPSN
SAToP

PCM
MP-MLQ
MP-ACELP
ADPCM
CS-ACELP

PCM
PCM
PCM

A68

Atraso % Latncia
Fixo Admissvel
(ms)
(150 ms)
24,5
45,5
45,5
24,5
18,5
24,5
35,5
3,0
3,0
3,0

16%
30%
30%
16%
12%
16%
24%
3%
3%
3%

Cabe observar, nessa tabela, que os codificadores utilizados nas aplicaes VoIP
comprometem, com atrasos fixos, entre 12% e 30% da latncia mxima admissvel no
transporte, enquanto as tecnologias PWE3 comprometem apenas 3%, entre quatro e dez
vezes menos, permitindo assim a utilizao de jitter buffers significativamente maiores,
com capacidade para acomodao de uma faixa mais larga de variaes no atraso sofrido
pelos pacotes dentro da PSN, o que lhes confere maior robustez em condies de
congestionamento ou ausncia de QoS.
Entretanto, dadas as caractersticas de agregao inerentes s tecnologias PWE3 para o
transporte de voz, na verdade feita atravs de emulao dos circuitos convencionais,
existem outros requisitos rgidos a serem atendidos, definidos pelos padres dos circuitos
TDM convencionais, que no so de fato crticos para a maioria das aplicaes VoIP,
conforme apresentado na Tabela 2.8.
Tabela 2.8 Comparao de requisitos PWE3 com relao a VoIP
Requisito
Taxa de bits
Desvio de
freqncia
jitter

PWE3
(Circuitos TDM)

2,048 Mbps
(E1)
mximo admissvel:
+/- 50ppm
(gera LOS ou OOF)
mximo:
<0,1 us

VoIP

admite maior flexibilidade de taxas

menos crtico, pois afeta apenas o
decodificador
(impacto na qualidade MOS)
no existe compromisso com jitter,
apenas com PDV

Assim, como no poderia ser diferente para tecnologias com abordagens to distintas para
o mesmo problema, so observadas vantagens e desvantagens em cada uma das solues,
recaindo a escolha nos requisitos e condies da aplicao desejada.
De maneira geral, a tecnologia VoIP apresenta maior flexibilidade, podendo operar de
forma integrada com diferentes classes de terminais individuais, como telefones IP,
softphones em microcomputadores pessoais, terminais analgicos conectados a gateways
FXS (Foreign eXchange Subscriber), PBX conectados a gateways FXO (Foreign
eXchange Office) ou mesmo redes inteiras de comutao convencionais conectadas atravs
de

trunking gateways, assegurando total acessibilidade e permitindo conversaes

A69

mltiplas entre eles, mas isso a custa de uma grande quantidade de elementos e protocolos
e, no raramente, excessivo overhead e latncia, exigindo um gerenciamento adequado da
QoS e dos recursos oferecidos pelas PSN utilizadas no transporte da voz em pacotes.
Por outro lado, as abordagens baseadas em PWE3, como a TDMoIP, apresentam menos
flexibilidade, mas oferecem em troca uma complexidade significativamente menor, maior
robustez em relao QoS e maior eficincia de recursos, sobretudo investimentos, quando
empregadas em solues ponto a ponto para emulao dos circuitos TDM convencionais
atravs das PSN, como o entroncamento e extenso de circuitos de voz para redes prexistentes formadas por terminais, PBX ou centrais convencionais, conforme ser ilustrado
na seo 2.5.1.

2.5 - PRINCIPAIS APLICAES TDM SOBRE IP E ETHERNET

Com o objetivo de ilustrar o grande potencial existente para a emulao de circuitos TDM
sobre redes de comutao em modo pacotes, so apresentadas a seguir algumas importantes
aplicaes das tecnologias PWE3 nas redes de comunicao atuais, com especial ateno
para o entroncamento e extenso de circuitos de voz, uma vez que a demonstrao da
tecnologia TDMoIP como alternativa de menor custo, maior simplicidade e melhor
eficincia para esse tipo de aplicao constitui um dos objetivos desse trabalho.
2.5.1 Entroncamento de voz e extenso de circuitos

O crescente interesse em utilizao das tecnologias IP para o transporte de servios TDM

evidencia a necessidade de aplicaes que atendam exatamente aquelas necessidades para
as quais esses circuitos TDM foram originalmente concebidos: o entroncamento entre
centrais e a transmisso dos canais de voz entre redes interurbanas. Isso vem acontecendo
tanto atravs da substituio das redes dedicadas de transmisso por alternativas mais
baratas, baseadas na comutao em modo pacotes, como pela extenso desses circuitos a
novos pontos de presena, com menores investimentos decorrentes do compartilhamento
das redes com servios de dados e vdeo.

A70

A Figura 2.17 apresenta uma configurao tpica de entroncamento interurbano entre duas
centrais telefnicas, atravs de uma rede TDM tradicional baseada em comutao de
circuitos, onde os enlaces digitais de transmisso, tipicamente n x E1 (PDH), chegam ao
n da rede interurbana mais prximo e so inseridos na estrutura STM-1 que trafega dentro
de um anel SDH, atravs de dispositivos cross-connects existentes nesses ns. Alm disso,
a sinalizao entre essas centrais trocada atravs de uma rede SS7, normalmente j
operando em modo pacotes, formada pelos respectivos PTS (Ponto de Transferncia de
Sinalizao) a elas conectados.
Dessa forma, cada enlace E1 de entroncamento possui um circuito dedicado entre as duas
centrais, devidamente provisionado dentro das unidades tributrias que trafegam dentro do
anel SDH, independentemente de estar ou no sendo utilizado num determinado momento,
reduzindo a eficincia da banda de transmisso SDH, pois mesmo que outra central tenha,
num dado momento, necessidade de trfego para ocupao desses canais, eles no podem
ser ocupados at que a configurao de provisionamento do STM-1 seja explicitamente
modificada.

SS7

PCS

PTS
A

PTS
B

SS7

SS7

ISUP

ISUP

Anel SDH
(STM-1)
PDH (n x E1)

RTFC

PDH (n x E1)

Central
Telefnica #1

Central
Telefnica #2

RTFC

Figura 2.17 - Entroncamento TDM convencional.

Assim, essa configurao representa uma grande oportunidade de melhoria da eficincia de
transmisso pela utilizao de uma rede comutada por clulas ou pacotes, ao invs do
A71

entroncamento convencional comutado a circuitos, mesmo que esta rede seja suportada
pelo prprio anel SDH original. Esse foi o grande objetivo e a essncia do desenvolvimento
das redes ATM, baseadas no chaveamento de clulas atravs do meio de transmisso e
permitindo a integrao dos diversos servios de voz, dados e vdeo na mesma rede, com
melhor aproveitamento da largura de banda disponvel.
Contudo, enquanto as redes ATM estavam sendo desenvolvidas e implantadas, envolvendo
vultosos investimentos por parte das operadoras mundiais, o crescimento das aplicaes e
redes baseadas na comutao em modo pacotes, como IP e ethernet, atingia uma
velocidade e abrangncia nunca vistas at ento. Assim, nada mais natural que surgissem
propostas para o entroncamento de circuitos TDM de voz e outros servios de faixa estreita
sobre essas redes de pacotes, de forma a assegurar um melhor aproveitamento da banda de
transmisso disponvel sem incorrer na alta complexidade e nos custos elevados oferecidos
pelas redes ATM.
Surgiram ento tecnologias como VoIP e PWE3, desenvolvidas especificamente para esse
tipo de aplicao, cujas abordagens detalhadas so realizadas em [AWEYA2003] e sero
brevemente descritas nessa seo.
A Figura 2.18 ilustra a abordagem do problema de entroncamento interurbano entre duas
centrais utilizando a tecnologia VoIP e seus elementos fundamentais nas camadas de mdia
e controle, incluindo converso da sinalizao SS7, que j foram abordados anteriormente;
oferecendo como principal caracterstica a grande flexibilidade, representada pela
possibilidade de acesso, para os terminais localizados nessas centrais, a qualquer telefone
IP ou softphone conectado PSN utilizada nesse entroncamento, que poderiam estar,
virtualmente, em qualquer lugar do mundo. Contudo, cabe esclarecer que aplicaes dessa
natureza so suportadas, na quase totalidade dos casos, por redes de pacotes desenvolvidas
e controladas com essa finalidade, onde assegurada a QoS necessria, tais como o
backbone IP/MPLS de uma grande operadora, no sendo concebvel a utilizao da Internet
pblica, por exemplo, como rede de transporte para entroncamento de voz.

A72

IP
Roteador

Roteador

Signaling
Gateway

Signaling
Gateway

Rede Comutada
a Pacotes

SS7

Roteador

SS7

Roteador
Media Gateway
Controller

Roteador

Roteador

ISUP

Trunking
Gateway

ISUP

Trunking
Gateway

RTFC

RTFC

Figura 2.18 - Entroncamento de servios atravs de VoIP.

A aplicao da tecnologia TDMoIP para o problema de entroncamento interurbano entre
duas centrais ilustrada na Figura 2.19, destacando que a emulao fim a fim dos circuitos
TDM a tornam completamente transparente para os equipamentos terminais, que
continuam recebendo apenas enlaces E1.

PTS
A

PTS
B

SS7

SS7
Roteador

ISUP

Gw IP

Roteador

Rede Comutada a Pacotes

n x E1

n x E1

RTFC

ISUP
Roteador Gw IP

Central
Telefnica #1

Central
Telefnica #2

Figura 2.19 - Entroncamento IP esttico utilizando TDMoIP.

A73

RTFC

Todas as funes necessrias para a emulao dos circuitos, como a converso do fluxo
contnuo de bits em pacotes, a regenerao desse fluxo no destino e a recuperao do
relgio de transmisso so desempenhadas exclusivamente pelos respectivos gateways
TDMoIP, instalados nas extremidades do entroncamento.
A limitao dessa configurao a ausncia de flexibilidade decorrente da configurao
esttica dos circuitos ponto-a-ponto, pois no existe comutao dentro do entroncamento,
sendo necessrio um circuito TDM emulado para cada par de centrais entroncadas. A
seleo entre os circuitos fica a cargo da matriz de comutao de cada central, da mesma
forma que aconteceria no entroncamento por circuitos TDM convencionais.
Outra alternativa, mais complexa, seria a utilizao de gateways TDMoIP

com

capacidade de comutao (switches), transferindo para o PE de origem parte da inteligncia

de seleo entre os pseudo-circuitos para a determinao da rota de entroncamento, atravs
de endereamento mltiplo dos pacotes encaminhados, como ilustrado na Figura 2.20.

PTS
C

PTS
A

RTFC

Gw IP

SS7

ISUP

ISUP

SS7

n x E1

PTS
B

Central
Telefnica #3

SS7

Roteador

Sw IP

Roteador

Rede Comutada a Pacotes

n x E1

Roteador

ISUP
Gw IP

n x E1

Roteador

RTFC

Central
Telefnica #1

Central
Telefnica #2

RTFC

Figura 2.20 - Entroncamento IP com comutao utilizando TDMoIP.

Finalmente, em funo da ausncia de flexibilidade da abordagem PWE3 para as
aplicaes de entroncamento, proposta em [AWEYA2003] uma alternativa envolvendo
interoperabilidade entre entroncamento TDMoIP e servios VoIP, ilustrada na Figura
A74

2.21. Nessa proposta seria feito, no Plano de Controle executado pelos gateways PWE3, o
mapeamento dos protocolos de sinalizao e controle de chamadas utilizados pelas
aplicaes VoIP, como o SIP, em mensagens de sinalizao compatveis com os terminais
ISDN (Integrated Services Digital Network), que assim poderiam ser interpretadas
diretamente pelas centrais de comutao, assegurando a acessibilidade dos terminais
conectados s mesmas a telefones IP e softphones, como se fossem terminais ISDN.

IP

PTS
A

SS7

PTS
B

SS7

SIP
Roteador

ISUP

Gw IP

ISDN

RTFC

Roteador

Rede Comutada a Pacotes

ISUP
Roteador Gw IP

n x E1

n x E1

SIP

Central
Telefnica #1

Central
Telefnica #2

RTFC

Figura 2.21 - Entroncamento IP utilizando TDMoIP com interoperabilidade VoIP.

2.5.2 Circuitos E1/T1 sobre redes de pacotes como rede de acesso local

No cenrio competitivo atual, onde as redes de acesso de maior capilaridade esto, em sua
quase totalidade, sob o controle das concessionrias ou incumbents, torna-se complexo e
dispendioso para qualquer nova empresa entrante o oferecimento de servios de voz alm
da abrangncia de sua prpria rede, freqentemente limitada em funo dos elevados
investimentos necessrios para construo das redes de acesso.
Nas condies da regulamentao brasileira, esses servios so oferecidos atravs do
aluguel de enlaces dedicados, normalmente E1, na modalidade conhecida como EILD
(Explorao Industrial de Linha Dedicada), atravs de contratos de interconexo exigidos e
supervisionados pela ANATEL, que representam, na prtica, o equilbrio de interesses
A75

entre as empresas. Dessa forma, as empresas que no controlam a rede de acesso acabam
tendo suas estratgias restritas pelas condies de disponibilidade de suas principais
concorrentes, limitando suas ofertas e a prpria capacidade de atendimento ao mercado.
Com a utilizao das tecnologias PWE3 para emulao transparente de circuitos TDM,
qualquer rede de pacotes existente pode ser utilizada para prover esses servios, a custo
reduzido em funo do inerente compartilhamento e sem necessidade de modificao nos
equipamentos dos clientes ou da prpria operadora. A expanso das redes que oferecem
conectividade IP e as ethernets metropolitanas (metroethernets), implantadas originalmente
para prover servios de dados, representam novas e importantes opes de rede de acesso
para as operadoras entrantes. Essas operadoras tm, inclusive, a opo de contratar
conectividade IP com seus clientes das prprias concessionrias, a custos mais baixos que
as linhas dedicadas, construindo sobre esse novo acesso desagregado (unbundled) a sua
rede multi-servios, incluindo o transporte de voz atravs da tecnologia TDMoIP, como
apresentado na Figura 2.22, onde os servios de voz so oferecidos aos clientes atravs de
uma rede do tipo gigabit ethernet metropolitana, completamente integrados aos demais
servios de dados.

Cliente #2: Dados e Internet

Cliente #1: Apenas Voz

Internet

Gateway

TDMoIP

Roteador

Roteador

PABX

Frame
Relay

RTFC

FR

Anel metropolitano
de terceiros
(Gigabit Ethernet)

PDH
(n x E1)
Central
Telefnica

Gateway

TDMoIP

Ponto de Presena
Operadora Entrante

Cliente #3: Voz e Frame Relay

LAN

PABX

FR

Gateway

TDMoIP

Figura 2.22 Utilizao de metroethernet como rede de acesso multi-servios.

A76

2.5.3 Servios de linha dedicada E1/T1 sobre redes de pacotes

As operadoras que tradicionalmente no oferecem servios de voz em virtude dos elevados

investimentos envolvidos, tendo focado seus negcios em servios como conectividade IP,
Internet ou formao de redes, tm na tecnologia de emulao de circuitos TDM uma
grande oportunidade de rentabilizar sua infra-estrutura.
Essas operadoras possuem, tipicamente, backbones metropolitanos ou interurbanos de alta
velocidade baseados em tecnologias como IP e MPLS, e no raramente apresentam largura
de banda subutilizada em suas redes, em funo da forte expanso das redes de dados nos
ltimos anos, muito alm da demanda que vem sendo colocada pelos clientes. Dessa forma,
se for possvel para a operadora o controle do atraso e da perda de pacotes em seus
backbones, assegurando uma QoS adequada, a oferta de servios de linha dedicada pela
emulao de circuitos TDM ponto a ponto, como os apresentados na Figura 2.23, uma
excelente alternativa para otimizao do uso de suas redes, agilizando o retorno dos seus
investimentos e permitindo que sejam praticados preos bastante competitivos com relao
aos enlaces E1/T1 tradicionais.

LAN

Roteador

Gw IP

Servio InterLAN
de alta velocidade

Gw IP

n x E1
Linha Dedicada #3
(pseudo-circuito
TDM emulado)

Roteador

n x E1
Linha Dedicada #2
(pseudo-circuito
TDM emulado)

Gw IP

n x E1

Rede IP
Roteador

Gw IP
Roteador

n x E1

Gw IP
Roteador

n x E1

Roteador

Linha Dedicada #1
(pseudo-circuito
TDM emulado)

LAN

Gw IP
n x E1

Figura 2.23 Servios de linha dedicada sobre redes de dados.

A77

Alm disso, as operadoras de comunicao de dados podem posicionar-se de forma

exclusiva no mercado, oferecendo enlaces E1 nos Estados Unidos ou enlaces T1 na Europa
ou no Brasil, permitindo a implantao imediata de servios at ento impossveis pela
incompatibilidade entre as duas hierarquias.
2.5.4 Backbone para redes mveis sobre redes de pacotes

O sucesso da telefonia mvel celular em todo o mundo o principal fenmeno do sculo

XXI. Na maioria dos pases, a quantidade de acessos mveis j supera, com larga
vantagem, a quantidade de acessos fixos em servio, o que significaria o fim da telefonia
fixa ao longo dos prximos anos, segundo alguns analistas.
Contudo, as redes de transporte das operadoras mveis so integralmente baseadas nos
enlaces TDM convencionais. Todas as conexes entre os principais elementos dessas redes,
como BTSs (Base Transceiver Stations), BSCs (Base-Station Controllers) e MSCs (Mobile
Switching Centers), so realizadas por circuitos TDM (E1/T1), atravs de linhas dedicadas
alugadas das concessionrias locais, a custos elevados; ou ainda de enlaces de microondas
ponto a ponto, que representam investimentos adicionais e enfrentam problemas como as
questes ambientais ligadas ao uso de radiofreqncia e a saturao do espectro de
freqncias nos grandes centros urbanos.
Segundo informaes do setor [RAD2003], o custo dos enlaces TDM representaria entre
40% e 60% do custo operacional das redes mveis, o que deixa essas operadoras
particularmente interessadas em solues que reduzam seus custos de transporte. Nesse
aspecto, a crescente expanso da conectividade IP nas regies metropolitanas tambm
coloca a tecnologia TDMoIP como uma excelente alternativa para essa aplicao,
permitindo o estabelecimento de pseudo-circuitos TDM atravs das PSN existentes, como
por exemplo uma rede de distribuio de TV a cabo que oferea servios IP, de forma
completamente transparente para os equipamentos de transmisso utilizados pelas
estaes-base, que continuariam, em suas interfaces, trafegando apenas enlaces E1/T1
convencionais.

A78

Dessa forma, a abordagem PWE3 permite que todo o backbone de uma rede mvel seja
implementado atravs de redes IP ou metroethernet, como mostrado na Figura 2.24, sem
qualquer modificao nos elementos existentes da rede, reduzindo significativamente os
custos associados ao transporte dos canais de voz entre as estaes-base, seus controladores
e a MSC. Essa soluo facilitaria tambm a migrao dessa rede para a chamada terceira
gerao, conhecida como UMTS (Universal Mobile Telecommunication System), uma vez
que vrias das solues em desenvolvimento, nesse caso, apontam para a utilizao de
conectividade IP entre seus elementos, possibilitando o compartilhamento total da rede de
transporte entre os elementos das duas geraes, assegurando melhor eficincia na
utilizao da banda disponvel.

RTFC
MSC
Gw IP
n x E1

Gw IP

n x E1

n x E1

BTS

Roteador
BSC

Gw IP

n x E1

Rede IP
Roteador

Roteador

Gw IP
n x E1

Roteador

Gw IP
BTS

BTS

Gw IP

n x E1

n x E1

BTS

Figura 2.24 - Backbone IP para uma rede mvel celular.

Como concluso da exposio realizada nesse captulo, mostrou-se que os desafios
enfrentados pelo transporte de TDM sobre PSN podem ser superados, utilizando dois
novos mecanismos para aprimoramento das tecnologias existentes. Alm disso, foi
observado que a implementao de pseudo-circuitos uma boa alternativa ao VoIP e uma
realidade comercial para diversas aplicaes.

No captulo 3 ser feita a proposta de

utilizao desses pseudo-circuitos na transmisso de vdeo digital, criando aplicaes

similares a IPTV suportadas atravs dessa tecnologia, aprimorada pelos novos mecanismos
apresentados.
A79

A80

3 - ALTERNATIVA TDMoIP PARA BROADCASTING IPTV

Nesse captulo discutida a questo da transmisso de vdeo digital, com uma rpida
reviso dos principais padres de codificao existentes e sua indicao para o transporte
atravs dos pseudo-circuitos propostos. Na seqncia apresentado o conceito usual de
IPTV, com suas caractersticas e requisitos, alm de uma breve descrio da tecnologia
empregada pelas aplicaes atuais. Finalmente, feita a correlao entre os novos
mecanismos propostos de seqenciamento e recuperao do relgio no receptor e as
adaptaes necessrias para a utilizao dos pseudo-circuitos em broadcasting de servios
IPTV similares.

3.1 - A TRANSMISSO DE VDEO DIGITAL

A utilizao de sinais digitais para a transmisso de informaes revolucionou as redes de

telecomunicaes a partir da metade do sculo XX, por oferecer soluo para o principal
problema enfrentado por qualquer sistema de comunicao a grandes distncias: o rudo
trmico presente no canal utilizado e/ou introduzido pelos componentes do sistema, que
limitava o processo de regenerao dos sinais ao longo do enlace, j que o rudo, presente
na mesma banda do sinal original, amplificado em cada uma das etapas de repetio,
degradando a relao sinal/rudo do canal a nveis inaceitveis a partir de determinada
distncia. Com a digitalizao dos sinais, o processo de regenerao foi reduzido
Contudo, apesar da forte digitalizao observada nas redes de telefonia e em outras
aplicaes de udio como o broadcasting de rdio, a transmisso digital de sinais de vdeo
enfrentou grandes obstculos, em funo da enorme largura de banda necessria para a sua
transmisso digital, permanecendo quase totalmente sob domnio analgico at meados da
dcada de 1980. Como ilustrao, a transmisso de um canal de TV analgico no Brasil
ocupa uma faixa de 6MHz no espectro VHF, enquanto para a transmisso digital do
mesmo canal, com qualidade similar e assumindo uma resoluo de 640x480 pontos, 30

A81

quadros por segundo e 16 bits para quantizao e codificao, seriam necessrios mais de
147Mbps de taxa de transmisso.
Assim, a efetiva utilizao do vdeo digital somente tornou-se possvel com a expanso da
microeletrnica e o advento dos DSPs, que permitiram o desenvolvimento de algoritmos
para a compresso e codificao mais eficiente dos sinais de vdeo, explorando suas
propriedades e a redundncia existente entre quadros sucessivos. Esses algoritmos foram
sendo aperfeioados e deram origem aos padres de codificao utilizados atualmente, que
permitiram o desenvolvimento de aplicaes como VCDs, DVDs, VoD, videotelefonia,
videoconferncia, TV por assinatura via satlite, broadcasting de TV Digital e IPTV.

3.2 - OS PADRES DE CODIFICAO DE VDEO

A codificao eficiente dos sinais de vdeo apresenta dois grandes objetivos, a reduo do
tamanho ocupado pelas amostras codificadas e a otimizao da banda utilizada em sua
transmisso. Esses objetivos so alcanados pelas tcnicas de compresso, que tm por
base duas premissas bsicas: a comprovao, atravs de estudos cientficos, de que a viso
humana incapaz de perceber toda a informao presente em uma imagem complexa em
movimento, permitindo que sejam desenvolvidos processos que descartem as informaes
imperceptveis; e o fato de que a maioria das seqncias de imagens apresenta muitas
regies repetidas, onde no acontece movimento, que podem ser transmitidas com
velocidade muito menor que a necessria para a imagem como um todo.
Com base nessas tcnicas, desde incio da dcada de 1990 foram desenvolvidos alguns
padres para a codificao digital de sinais de vdeo, sempre buscando uma melhor
qualidade de transmisso com maior eficincia de utilizao de banda, destacando-se as
Recomendaes ITU-T da srie H.2XX e a famlia desenvolvida pelo grupo MPEG.
Assim, sero descritos os padres mais utilizados nas aplicaes de transmisso de vdeo,
com o objetivo de mostrar as suas principais caractersticas e a sua possibilidade de
utilizao dentro da alternativa proposta para broadcasting IPTV.

A82

3.2.1 Os padres H.261 e MPEG-1

O padro de codificao de vdeo definido pela

Recomendao ITU-T H.261, para

utilizao em sistemas audiovisuais de faixa estreita, foi desenvolvido em 1990 para a

transmisso de sinais digitais de vdeo sobre linhas ISDN, ento a grande promessa para a
convergncia das redes de comunicao, operando em taxas mltiplas de 64 kbps,
definidas entre 40 kbps e 2Mbps e suportando quadros de vdeo com resolues de
352x288, 176x144 ou 88x72 pixels, para 25 quadros por segundo.
Da mesma forma, o padro MPEG-1 foi desenvolvido na mesma poca com o objetivo de
oferecer uma qualidade aceitvel de vdeo utilizando taxas de at 1,5Mbps, suportando
quadros com varredura progressiva (no entrelaados) com resoluo de 352x240 pixels,
para 30 quadros por segundo (sistema NTSC), ou 352x288 pixels, para 25 quadros por
segundo (sistemas PAL e SECAM); com qualidade de imagem comparvel oferecida
pelas antigas fitas VHS (Video Home System), que difundiram o contedo de vdeo para
uso domstico

na dcada de 1980. O MPEG-1 considerado o formato de maior

compatibilidade dentro da famlia MPEG, sendo reproduzido sem problemas pela grande
maioria dos aplicativos disponveis para computadores pessoais e aparelhos de VCD e
DVD. tambm um elemento desse padro o MPEG-1 Audio Layer 3, CODEC para
compresso de sinais de udio popularmente conhecido como MP3, que modificou as
estruturas da indstria fonogrfica mundial a partir do final da dcada passada, permitindo
de forma simples e eficiente o oferecimento e o intercmbio de msicas atravs da Internet.
Considerando a emulao de um circuito E1 sobre uma PSN utilizando a tecnologia
TDMoIP, esses padres de codificao, que operam a taxas inferiores a 2Mbps, podem ser
utilizados para broadcasting de IPTV de forma transparente atravs desse pseudo-circuito.
3.2.2 O padro H.262 ou MPEG-2 Vdeo

Conforme as tecnologias de processamento digital de sinais se tornaram mais poderosas e

baratas, dando condies para que equipamentos capazes de decodificar algoritmos mais
complexos fossem acessveis aos clientes residenciais, permitindo mais qualidade de vdeo,
foram desenvolvidos padres de codificao mais avanados. Em 1994 foi criado o MPEGA83

2, mais tarde definido na Recomendao ITU-T H.262, como tambm conhecido, cujo
principal objetivo foi a adaptao do MPEG-1 para dar suporte HDTV (High Definition
TeleVision), com resoluo tpica de 1280x720 pixels. Esse padro tipicamente utilizado
na codificao de sinais de udio e vdeo para broadcasting, exigindo equipamentos mais
poderosos, mas alcanando maior eficincia na codificao, ou seja, oferecendo melhor
qualidade por kbps utilizado na transmisso dos sinais.
O MPEG-2 o padro utilizado pelos DVDs, assim como nas transmisses diretas via
satlite (DTH) utilizando a banda Ku das TVs por assinatura, bem como nas transmisses
digitais de TV a cabo. Esse padro dividido em trs partes:
A parte Sistemas define dois formatos de encapsulamento, o chamado Transport Stream,
projetado para transportar sinais de udio e vdeo atravs de meios no confiveis, como
transmisso atravs do ar para TV digital; e o chamado Program Stream, projetado para
meios confiveis, como os discos utilizados nos padres DVD e SVCD.
A parte Vdeo semelhante ao MPEG-1, mas ao contrrio deste tambm suporta quadros
com varredura entrelaada, como os utilizados nos sistemas de transmisso de TV
analgica. O MPEG-2 no , como o primeiro, otimizado para taxas abaixo de 1Mbps, mas
supera a performance do MPEG-1 em taxas acima de 3Mbps, e seus decodificadores,
quando totalmente compatveis com o padro, so capazes de reproduzir MPEG-1.
Finalmente, a parte udio novamente uma evoluo do MPEG-1, com codificao de
sinais de udio em mais de dois canais, mas compatvel com os decodificadores MPEG-1
(MP3) atravs da reproduo dos dois canais principais em estreo.
Considerando suas caractersticas e a qualidade superior oferecida, a emulao de um
circuito E1 sobre uma rede de pacotes no seria suficiente para broadcasting de IPTV
utilizando o padro MPEG-2, e o desempenho apresentado pelos padres anteriores em
taxas inferiores a 2Mbps os credencia como a melhor escolha para a aplicao proposta.

A84

3.2.3 O padro H.263

O padro definido pela

Recomendao ITU-T H.263 um codificador de vdeo

desenvolvido em 1995 como soluo de compresso para baixas taxas de transmisso, em

aplicaes de videoconferncia. Esse padro foi desenvolvido como uma evoluo do
H.261, operando de forma otimizada em taxas inferiores quelas utilizadas pelo mesmo,
considerando tambm diversos aspectos dos padres MPEG-1 e MPEG-2, que o tornam
um substituto adequado para o primeiro em todas as taxas utilizadas, sobretudo em virtude
das suas evolues H.263v2/H.263+, desenvolvida em 1998, e H.263v3/H.263++, de 2000.
O padro H.263 foi projetado para utilizao em sistemas baseados na Recomendao ITUT H.324, para videotelefonia e videoconferncia sobre redes comutadas a circuitos, mas
tambm utilizado nas redes baseadas na Recomendao ITU-T H.323, para
videoconferncia em redes IP; e H.320, para videoconferncia em redes ISDN. Alm disso,
a maioria do contedo em Flash Video presente em stios Internet como o YouTube,
MySpace e similares apresentado com essa codificao.
Dessa forma, o H.263 apresenta-se como um excelente candidato para a aplicao proposta
de broadcasting de IPTV atravs da emulao de circuitos E1 sobre uma rede de pacotes,
utilizando a tecnologia TDMoIP.

3.2.4 O padro H.264 ou MPEG-4 Vdeo

O padro definido pela Recomendao ITU-T H.264, tambm conhecido como AVC
(Advanced Video Coding), que corresponde Parte 10 do padro MPEG-4 teve como
principal objetivo em seu desenvolvimento a capacidade de oferecer uma boa qualidade de
vdeo utilizando taxas 50% inferiores s utilizadas pelos padres anteriores, como o H.263,
o MPEG-2 e o prprio MPEG-4 Parte 2, fazendo isso sem grandes incrementos de
complexidade que tornassem a soluo impraticvel ou cara demais. Um segundo objetivo
era realizar tal tarefa de modo flexvel, permitindo que o padro pudesse ser aplicado a
uma grande variedade de aplicaes, envolvendo taxas e resolues de quadro tanto baixas
como elevadas, e que operasse sobre diversas redes e sistemas, como videotelefonia
comutada a circuitos, redes IP, transmisso de TV digital e armazenamento em DVDs.

A85

Esse padro tem como caracterstica a elevada compresso de dados, sendo produto de um
esforo conjunto entre os grupos VCEG (Video Coding Experts Group), patrocinado pelo
ITU-T, e o MPEG (Moving Picture Experts Group), formando a parceria denominada JVT
(Joint Vdeo Team), que apresentou sua primeira verso em 2003.
O padro MPEG-4 absorveu muitas caractersticas de seus antecessores MPEG-1 MPEG2, incluindo novas funcionalidades como suporte a renderizao tridimensional, objetos
VRML (Virtual Reality Modelling Language), suporte para a gerncia digital de direitos
autorais e interatividade. Foram tambm desenvolvidas extenses para suporte
codificao de vdeo com fidelidade superior, denominadas FRExt (Fidelity Range
Extensions), com maior preciso de amostragem, incluindo a codificao em 10 e 12 bits,
e uma melhor resoluo de cores, alm de tcnicas avanadas de processamento de sinais.
Em funo da premissa de simplicidade e baixos custos assumida para a proposta de
broadcasting IPTV discutida nesse trabalho, o padro MPEG-4, embora possa ser utilizado
em taxas compatveis com a emulao de um circuito E1 sobre uma rede de pacotes, no
recomendvel dada a baixa maturidade da tecnologia e ao elevado custo dos codificadores.

3.3 - SERVIOS IPTV: CARACTERSTICAS E REQUISITOS

A chamada IPTV (Internet Protocol TeleVision) um sistema de televiso digital por

assinatura onde utilizada uma rede de transporte IP, normalmente a Internet nas
aplicaes no corporativas, utilizando os acessos de banda larga dos clientes,
normalmente baseados em tecnologias do tipo xDSL.
Para o Mercado Residencial, onde o entretenimento o grande motivador para os usurios
de segmento superior o objetivo das operadoras prover aos clientes a chamada oferta
trplice, ou triple play, constituda pelos servios de voz (telefonia fixa), dados (acesso
Internet) e TV por assinatura (IPTV, VoD), sobre uma mesma conexo de acesso, com o
objetivo de manter fidelizada a sua base de clientes. No caso das operadoras tradicionais
brasileiras de telecomunicaes, a oferta trplice tem avanado da telefonia convencional,
A86

atravs da rede de cobre, para o ADSL, oferecendo servios Internet sobre essa rede, e
agora chega IPTV, uma vez que Telemar, Telefnica e Brasil Telecom j possuem testespiloto em andamento com essa tecnologia, com previso de lanamento comercial
prximo, embora de forma cautelosa em virtude das questes em aberto no que tange
regulamentao. Na outra ponta, as operadoras de TV por assinatura tambm passaram a
oferecer, nos ltimos anos, servios internet atravs de sua rede cabeada, e j esto
consolidadas ofertas comerciais de telefonia fixa atravs de VoIP, como a oferecida pela
Net/Embratel, qualificando-as, da mesma forma, ao oferecimento da oferta trplice.
Alm disso, est sendo adicionado agora mais um servio a esse pacote, a telefonia mvel,
caracterizando a chamada oferta qudrupla, buscando a convergncia total dos servios
de telecomunicaes, com benefcios tangveis para clientes e operadoras, como um nico
canal de relacionamento, faturamento na mesma conta, promoes e benefcios e cruzados.
Para os Mercados Corporativos e Governo, que j so potencialmente clientes de servios
como a videoconferncia e as chamadas TVs Executivas, a utilizao de IPTV atravs dos
servios de conectividade IP j contratados para suas redes de dados, normalmente mais
bem poderosos que as conexes ADSL residenciais, permite a criao, a custos bastante
reduzidos, de novas ferramentas poderosas para o ambiente corporativo, como o
treinamento distncia e auto-conduzido, eliminando o custo de viagens e permitindo a
administrao do tempo de cada participante; e a divulgao direta e instantnea de
contedos de interesse ao negcio, como palestras, eventos, seminrios e vdeos
institucionais, no prprio computador pessoal utilizado diariamente pelos seus
colaboradores, localizado em qualquer ponto de suas redes internas.
Como requisitos, as aplicaes IPTV devem apresentar qualidade semelhante quela
oferecida pelos servios tradicionais de TV por assinatura, como qualidade de transmisso
e confiabilidade da programao, assegurando conforto aos clientes. A maioria dos
sistemas IPTV implantados ainda no suportam padres de alta definio, como o HDTV,
mas somente outros sistemas de televiso digital como o DVB, que utiliza codificao
MPEG-2 e oferece qualidade muito prxima aos DVDs domsticos.

A87

Como todo o processo de transmisso baseado no protocolo IP, as aplicaes IPTV so

bastante sensveis s perdas de pacotes e aos atrasos sofridos dentro da rede, devendo haver
disponibilidade de banda suficiente para os servios desejados e se assegurada QoS
suficiente para um fluxo estvel de pacotes em cada um dos receptores, sendo esse o
principal desafio das tecnologias desenvolvidas para essa finalidade.

3.4 - TECNOLOGIAS PARA TRANSMISSO IPTV E VoD

Os servios IPTV e VoD, que diferem entre si apenas com relao ao contedo e grau de
interatividade oferecido, so tipicamente suportados por redes de transporte em modo
pacotes de alta velocidade, como backbones IP corporativos, Ethernet a 100Mbps ou
GigabitEthernet, s quais os clientes so conectados diretamente ou atravs de uma infraestrutura de acesso de banda larga, que pode ser compartilhada com a Internet pblica.
Nessa condio, tambm denominada TV sobre Internet, o contedo normalmente
pblico, obtido atravs de qualquer servidor dentro da rede mundial, no sendo oferecida
nenhuma garantia de qualidade, que fica dependente da disponibilidade de banda e do
trfego existente na rota entre o servidor e o cliente. Esse tipo de aplicao no pode ser
considerado um efetivo concorrente TV por assinatura, pois um usurio dificilmente
pagaria por um servio to precrio, estando mais prxima da simples e descompromissada
visualizao em HTTP, a partir de um computador pessoal, de vdeos curiosos e de curta
durao, em stios como o YouTube. Nesse mesmo grupo podem ser includos os cerca de
1.300 canais de TV sobre Internet gratuitos oferecidos em junho/2006 pelas grandes redes
mundiais de televiso aberta, que retransmitem sua programao tradicional e podem ser
acessados atravs de qualquer conexo Internet, utilizando computadores pessoais, TVs
conectadas a computadores, Vdeo iPODs ou telefones celulares 3G. Contudo, sua
utilizao limitada em virtude da baixa qualidade de transporte oferecida pela Internet.
Nas aplicaes comerciais IPTV, embora o acesso possa ser compartilhado com a Internet,
como mostrado na Figura 3.1, a distribuio de contedo feita atravs de redes privadas,
da mesma forma que nas redes tradicionais de TV assinatura, com a diferena fundamental
de que, ao invs de utilizar cabos ou receptores de sinais de satlite, onde todos os
A88

contedos disponveis so transmitidos de forma contnua para todos os assinantes, sendo

selecionados atravs de multiplexao FDM nos receptores (ou set-top boxes); o fluxo de
udio/vdeo entregue em pacotes IP, atravs de fluxos individuais estabelecidos
diretamente entre o servidor e o receptor, transportando exclusivamente o contedo
selecionado pelo cliente. Isso oferece duas vantagens: a reduo de largura de banda, pois
s transmitida a programao que efetivamente deseja ser recebida por algum dos clientes
conectados no momento, e a maior disponibilidade de contedos, pois no existe limitao
na quantidade de canais, oferecendo uma liberdade de escolha nunca antes disponvel nas
TVs por assinatura, exatamente o que caracteriza o termo Vdeo sob Demanda.

Servidores de Contedo

Operadora
Triple Play

Roteador

IPTV

Backbone IP Internet
Roteador

Cliente

Internet

IPTV
Roteador

Set-Top Box

DSLAM

ADSL

Voz
Telefonia

RTFC

Internet

Figura 3.1 Acesso IPTV numa configurao triple play.

Ao invs da restrio de contedo, a limitao dessa tecnologia a capacidade da rede de
transporte para estabelecer e gerenciar fluxos independentes, assegurando recursos
suficientes para manter a qualidade de vdeo. Cada cliente estabelece a sua sesso, ao invs
de aderir recepo do contedo escolhido, permitindo que um programa seja iniciado
exatamente no instante desejado e no em horrio pr-determinado. Isso permite que sejam
integradas ao servio ferramentas de interatividade, como a escolha de programao entre
milhares de opes disponveis, a consulta a bancos de dados relacionados ao programa
escolhido na tela do televisor ou a escolha de ngulos de cmera, recursos hoje disponveis
nos DVDs, mas com o inconveniente do deslocamento at a locadora.
A89

Quando so abordadas as questes de escolha de filmes e interatividade, o conceito IPTV

acaba confundido com o Vdeo sob Demanda (VoD), uma aplicao um pouco mais antiga,
criada originalmente para redes comutadas a circuitos, como a ISDN, mas que tambm foi
absorvida pela revoluo do Mundo IP na ltima dcada. Nesse servio, que ilustra bem
uma das aplicaes IPTV, o cliente navega em um catlogo de filmes apresentado em seu
televisor, assiste a trailers e escolhe o filme a que deseja assistir. Quase instantaneamente,
o filme iniciado em sua tela, com qualidade DVD, pois o fluxo de pacotes contendo os
dados de udio e vdeo do mesmo passa a ser recebido pelo decodificador MPEG-2
localizado no set-top box do cliente, atravs de uma conexo IP ponto a ponto estabelecida
entre este e o servidor da operadora onde est armazenado o filme. A fim de assegurar o
mesmo conforto de um DVD, funes usuais como pausa, avano e retrocesso de imagem
so permitidas, utilizando o protocolo RTSP (Real Time Streaming Protocol).
A Figura 3.2 apresenta um servio IPTV comercial sendo oferecido a uma grande
corporao, com

funcionrios espalhados por diversos ambientes geograficamente

distantes, atravs da rede IP (com QoS) contratada junto a uma operadora de dados,
utilizando o modelo ponto a ponto (unicast) descrito acima.

Servidores de Contedo

Roteador

LAN 2

Ethernet
10Mbps

Roteador

Programa 1
LAN 1

Ethernet
10Mbps

Roteador

Programa 3

Programa 1

Rede IP
com QoS
Programa 3

Programa 2
WLAN
11Mbps

Roteador

LAN 3
Roteador

Ethernet
10Mbps

Figura 3.2 Modelo convencional ponto a ponto para transmisso IPTV.

A90

No exemplo, o programa 1 o treinamento em vdeo para o pessoal da contabilidade,

enquanto o programa 2, um filme de divulgao do novo produto, est sendo assistido por
um consultor de vendas, em sua base remota. Ao mesmo tempo, est sendo assistida por
dois colaboradores, no programa 3, a mensagem de fim de ano do presidente da empresa.

3.5 - ADEQUAO TDMOIP PARA TRANSMISSO DE VDEO

A tecnologia IPTV apresentada vem sendo desenvolvida por grandes empresas de

tecnologia, como a gigante Microsoft, com foco nas aplicaes comerciais de
entretenimento voltadas para clientes de alto poder aquisitivo. Assim, a utilizao dos
equipamentos, protocolos e sistemas de gesto disponveis no mercado exigiria a justa
remunerao desse desenvolvimento,

atravs da aquisio de licenas de uso ou do

pagamento direto de royalties. Dessa forma, a criao de uma rede nacional de IPTV para
educao distncia, com objetivos puramente sociais, permitindo a transmisso ao vivo
de eventos, palestras ou seminrios, bem como a distribuio livre de contedos de vdeo
associados a questes acadmicas ou culturais, dependeria de pesados investimentos
governamentais, que restringiriam a sua abrangncia e capilaridade. Da mesma maneira, a
contratao de uma rede de transporte com a QoS necessria para aplicaes IPTV na
forma apresentada tornaria o custo operacional do projeto, para uma abrangncia nacional,
quase proibitivo, como pode ser deduzido a partir da Tabela 1.1, onde a formao dos
cinco circuitos propostos, ligando Braslia a So Paulo, Rio de Janeiro, Belo Horizonte,
Cuiab e Porto Alegre, utilizando o servio Vetor para dados multimdia, o mais indicado
nesse tipo de aplicao, teria um custo mensal estimado em quase R$ 60 mil, apenas para a
rede de transporte e considerando um nico ponto de acesso em cada uma dessas cidades.
Assim, este trabalho prope a utilizao da emulao de pseudo-circuitos E1, utilizando as
tecnologias TDMoIP ou SAToP com os aprimoramentos propostos para o
seqenciamento de pacotes e a sincronizao adaptativa dos receptores, como alternativa
para a formao dessa rede nacional de tele-educao, utilizando a conectividade IP
oferecida pelas redes de alta velocidade espalhadas pelas comunidades acadmicas do pas,
como o Projeto REMAV (Redes Metropolitanas de Alta Velocidade), interconectadas
atravs do backbone RNP2, da RNP (Rede Nacional de Pesquisa) ou, quando necessrio,
A91

dos backbones das operadoras nacionais, utilizando conectividade IP sem QoS assegurada,
mas com garantia de banda, como o IP Dedicado da Brasil Telecom, muito mais baratos.
Como referncia, a conectividade nesse servio para as mesmas cidades acima,
considerando um nico ponto de acesso em cada uma, teria um custo mensal estimado em
menos de R$ 12 mil, cinco vezes menos, para a mesma velocidade de 2Mbps.
Dessa forma, a tecnologia PWE3 proposta permitiria a emulao de circuitos E1 dedicados
entre os pontos desejados para gerao e recepo de contedo dentro da comunidade
acadmica interligada atravs dessa rede nacional, completamente transparentes aos
servios e protocolos nativos dos equipamentos de udio e vdeo disponveis, desde que
utilizando taxas inferiores a 1,5Mbps, como os codificadores MPEG-1, H.261, e H.263,
assegurando qualidade de vdeo comparvel aos sistemas VHS e VCD.
A Figura 3.3 apresenta essa alternativa de broadcasting IPTV utilizando TDMoIP, para
diversas redes geograficamente distantes, ilustrando tambm a reduo na ocupao de
banda dentro do backbone pela utilizao de roteadores com suporte a conexes pontomultiponto (multicast). Os programas so gerados na origem, em codificao nativa, e
encaminhados dentro dos pseudo-circuitos E1 de forma transparente at os roteadores de
destino, considerando o endereo multicast de cada um dos grupos desejados. A partir de
ento, os pacotes so encaminhados a cada um dos destinos envolvidos na recepo do
programa, ficando cada receptor encarregado de fazer o seqenciamento e a sincronizao
adaptativa de seu prprio fluxo, como ser discutido na seo 3.6.3.

Esses receptores

podem ser microcomputadores implementando a funo gateway TDMoIP, como

indicado, que j fariam tambm a decodificao do vdeo sem nenhum hardware adicional,
atravs de programas como o VLC (VideoLan Client) utilizado no ambiente descrito em
[SCHULTER2002] e desenvolvido em cdigo aberto por pesquisadores da cole Centrale
de Paris; ou ainda por um gateway TDMoIP propriamente dito, entregando o sinal E1
regenerado para um CODEC e permitindo a sua exibio atravs de sistemas de vdeo
analgico, como diversos televisores em um circuito interno de vdeo ou o transmissor
VHF da TV educativa local, para transmisso em maior alcance, como campi remotos,
postos avanados de extenso ou escolas municipais ou estaduais, incluindo a zona rural.

A92

Contedo
ao vivo

CODEC

Servidores de
Contedo
Armazenado
Gateways E1
TDMoIP

E1

LAN 2
Roteador

LAN 1

Ethernet
10Mbps

Ethernet
10Mbps

Roteador

Programa 2

Roteador

Programa 1

Rede IP
Programa 3

Programa 1
WLAN
11Mbps

LAN 3
Roteador

Roteador

Ethernet
10Mbps

Figura 3.3 Alternativa de broadcasting IPTV usando TDMoIP e multicast.

Fazendo um paralelo com a aplicao IPTV corporativa descrita, os estudantes do
laboratrio de sistemas da universidade LAN1, assim como os alunos espalhados pelo
campus da universidade WLAN estariam assistindo a uma palestra sobre redes de alta
velocidade, transmitida ao vivo pela UnB, enquanto os professores de uma grande escola
estadual vizinha LAN2 estariam assistindo defesa de doutorado em educao de adultos
de uma de suas colegas, gravada h duas semanas; e na universidade LAN3 estaria sendo
exibida aos alunos uma cirurgia crtica gravada num hospital de Braslia.
Na proposta desse trabalho, todos os desafios associados transmisso IPTV atravs da
rede, que convencionalmente so abordados utilizando protocolos como o RTP e tcnicas
de mitigao de perdas dentro da camada de aplicao, so transferidos para o que seria, do
ponto de vista de uma aplicao de vdeo, a camada de enlace, representada pelo pseudocircuito emulado, exatamente como no paralelo apresentado anteriormente entre as
abordagens VoIP e TDMoIP. A emulao PWE3 proposta representa assim um tubo
para a aplicao de transmisso e recepo de vdeo, exatamente como se os equipamentos
de origem e destino estivessem conectados por um circuito dedicado, como acontece nas
aplicaes comerciais baseadas em ATM.

A93

Contudo, para que a tecnologia PWE3 possa efetivamente ser utilizada, so necessrias
algumas adaptaes baseadas nos mecanismos propostos nas sees 2.3.2 e 2.3.3, a fim de
assegurar maior robustez em relao ao atraso e perda dos pacotes transportados pela PSN.
3.5.1 - Fragmentao do fluxo de vdeo em pacotes

O primeiro aspecto a considerar na transmisso de sinais de vdeo digital codificado, que

consiste num fluxo contnuo de bits, atravs de um pseudo-circuito emulado sobre uma
rede de pacotes, onde os dados fluem de natureza discreta, exatamente a fragmentao
desse fluxo para montagem dos pacotes. Na transmisso de canais de voz, os pontos de
fragmentao apresentam-se de forma mais intuitiva na abordagem SAToP, em funo da
fixao de estrutura, mas no so determinantes para a abordagem TDMoIP, que tratam a
separao dos canais por indicao de estrutura, mas ambas permitem a retirada, do fluxo
dos pacotes, dos dados associados a canais ociosos. Em termos prticos, como nos sinais
de vdeo toda a redundncia j foi absorvida no processo de codificao, a fragmentao do
fluxo contnuo em pacotes deve observar duas premissas bsicas:
a) O compromisso entre a latncia fim a fim dentro do circuito, que cresce com o uso de
pacotes maiores; e o overhead transmitido atravs da rede, que cresce com o uso de
pacotes menores, conforme indicado nas Tabelas 3.1 e 3.2.
b) A propagao de erros no caso de perda de pacotes, uma vez que os algoritmos de
codificao de vdeo apresentam interdependncia entre as amostras transmitidas, j
que mesmo nas abordagens envolvendo a transmisso de um nico quadro por pacote
pode haver necessidade de fragmentao, quando o tamanho do quadro supera a MTU
da rede. Essa questo complexa e foge ao escopo do trabalho, cabendo apenas
registrar que so aproveitadas algumas caractersticas de fracionamento existentes em
cada tipo de codificador para otimizar o ponto de fragmentao dos pacotes.
Tabela 3.1 Overhead na PSN x tamanho dos pacotes na tecnologia SAToP.
Total Octetos
PDUs Octetos TDM Overhead
1
288
256
11,11%
2
544
512
5,88%
3
800
768
4,00%
4
1056
1024
3,03%
5
1312
1280
2,44%

Tempo
(ms)
1,000
2,000
3,000
4,000
5,000

A94

Pacotes/s
1.000,000
500,000
333,333
250,000
200,000

Taxa TDM
(bps)
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000

Taxa Real
(bps)
2.304.000
2.176.000
2.133.333
2.112.000
2.099.200

Tabela 3.2 Overhead na PSN x tamanho dos pacotes na tecnologia TDMoIP.

PDUs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

Total
Octetos
80
128
176
224
272
320
368
416
464
512
560
608
656
704
752
800
848
896
944
992
1040
1088
1136
1184
1232
1280
1328
1376
1424
1472

Octetos
TDM Overhead
47
41,25%
94
26,56%
141
19,89%
188
16,07%
235
13,60%
282
11,88%
329
10,60%
376
9,62%
423
8,84%
470
8,20%
517
7,68%
564
7,24%
611
6,86%
658
6,53%
705
6,25%
752
6,00%
799
5,78%
846
5,58%
893
5,40%
940
5,24%
987
5,10%
1034
4,96%
1081
4,84%
1128
4,73%
1175
4,63%
1222
4,53%
1269
4,44%
1316
4,36%
1363
4,28%
1410
4,21%

Tempo
(ms)
0,184
0,367
0,551
0,734
0,918
1,102
1,285
1,469
1,652
1,836
2,020
2,203
2,387
2,570
2,754
2,938
3,121
3,305
3,488
3,672
3,855
4,039
4,223
4,406
4,590
4,773
4,957
5,141
5,324
5,508

Pacotes/s
5.446,809
2.723,404
1.815,603
1.361,702
1.089,362
907,801
778,116
680,851
605,201
544,681
495,164
453,901
418,985
389,058
363,121
340,426
320,401
302,600
286,674
272,340
259,372
247,582
236,818
226,950
217,872
209,493
201,734
194,529
187,821
181,560

Taxa TDM
(bps)
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000
2.048.000

Taxa Real
(bps)
3.485.957
2.788.766
2.556.369
2.440.170
2.370.451
2.323.972
2.290.772
2.265.872
2.246.506
2.231.013
2.218.337
2.207.773
2.198.835
2.191.173
2.184.533
2.178.723
2.173.597
2.169.040
2.164.963
2.161.294
2.157.974
2.154.956
2.152.200
2.149.674
2.147.350
2.145.205
2.143.218
2.141.374
2.139.657
2.138.054

O tamanho dos pacotes a ser utilizado, definido pela quantidade de PDUs em cada pacote,
depende das caractersticas da PSN , da distncia entre as extremidades do pseudo-circuito
e do codificador, devendo considerar como limite mximo a MTU da rede, normalmente
1500 octetos quando existe um segmento ethernet, e o overhead mximo admissvel em
funo da banda disponvel. Para a abordagem TDMoIP, pacotes com menos de 5 PDUs,
indicados em cinza na tabela 3.1, so considerados proibitivos pela baixa eficincia no uso
de banda, alm de necessitarem de elevadas taxas de processamento, em pacotes por
segundo, nos roteadores, e no serem compatveis com a banda proposta de 2Mbps, quando
utilizada da taxa de 1,5Mbps de dados TDM pelo codificador. Para a abordagem SAToP,
todos os tamanhos indicados so possveis.

A95

3.5.2 - Absoro de PDV na transmisso IPTV

O segundo aspecto a considerar a necessidade de absoro da variao no atraso sofrida

pelos pacotes (PDV) que chegam ao receptor, atravs da utilizao de um jitter buffer,
como na maioria das aplicaes em tempo real sobre redes de pacotes.
Entretanto, exatamente nesse ponto que o novo mecanismo proposto nesse trabalho para
seqenciamento dos pacotes, apresentado na seo 2.3.2 oferece a grande contribuio para
o aprimoramento da tecnologia PWE3 para o broadcasting de IPTV, pois permite que
sejam dispensados os timestamps, reduzindo o overhead, e realiza o controle do
reordenamento dos pacotes exclusivamente atravs do nmero de seqncia recebido,
dentro do prprio processo de escrita no buffer, que circular e tambm no necessita de
qualquer tipo de gerenciamento; assegurando um excelente desempenho e permitindo a
recuperao automtica de qualquer pacote atrasado ou adiantado que seja recebido,
respectivamente, at o instante anterior ao de reproduo do mesmo; e imediatamente aps
a reproduo da posio corrente.
Essa caracterstica, bem superior quela utilizada pela implementao RAD, que define a
possibilidade de reordenao entre 0 e 7 pacotes devido ao ponteiro AAL1, exatamente o
que melhora a robustez do pseudo-circuito para utilizao em redes PSN que assegurem a
banda, mas no ofeream garantia de entrega ou controle de atraso. Em funo da aplicao
de broadcasting IPTV proposta ser basicamente unidirecional, com interatividade bsica
exclusivamente para o controle da reproduo do vdeo e no contemplando funes de
videotelefonia ou videoconferncia, o jitter buffer pode ter tamanho elevado, no existindo
a restrio de 150ms para a latncia fim a fim estabelecida como requisito para o transporte
de canais de voz TDM. Dessa forma, cada um dos receptores envolvidos pode se ajustar,
dinamicamente, s caractersticas de atraso dos pacotes que so recebidos, assegurando a
reproduo de um fluxo contnuo de dados para o codificador de vdeo
Alm disso, como vrias das tcnicas propostas para mitigao das perdas de pacote em
transmisso multimdia atravs de redes IP esto baseadas em solicitao de retransmisso
[RFC2354], o mecanismo de seqenciamento desenvolvido, que grava os pacotes dentro
do buffer em funo do nmero de seqncia recebido, permite um tratamento simples e
A96

eficiente das retransmisses pelo receptor, pois pacotes recebidos a qualquer momento,
desde que anteriores ao instante programado para a sua reproduo, so diretamente
acomodados na seqncia correta. Assim, embora a retransmisso no seja uma situao
desejada em PWE3, na aplicao de broadcasting IPTV pode ser criado um processo
adicional, monitorando as falhas dentro do buffer, em intervalos compatveis com o
RTT do pseudo-circuito, e solicitando a retransmisso de um pacote perdido a tempo de
que possa ser reproduzido normalmente, no instante programado, sem que seja necessria
nenhuma modificao no processo de gravao ou leitura do buffer no receptor.
Finalmente, em funo da total independncia entre o processo de seqenciamento dos
pacotes, realizado durante a escrita no buffer, do processo de reproduo taxa constante,
as funes tpicas de parada, avano, atraso, exibio quadro a quadro e em velocidade
mais lenta ou mais acelerada podem ser facilmente implementadas, envolvendo
exclusivamente cada receptor, desde que exista capacidade de armazenamento suficiente
no buffer, o que confere aplicao um desempenho bem mais prximo da reproduo de
vdeos em VHS ou DVD do que os usuais vdeos reproduzidos da Internet atravs do
protocolo http, onde o acionamento de qualquer dessas funes prejudica o fluxo de vdeo,
obrigando a que os pacotes sejam novamente requisitados do servidor e gerando atrasos
desconfortveis na continuidade da reproduo.
3.5.3 - Sincronizao dos receptores na transmisso IPTV

O esquema normalmente utilizado para controle da qualidade de vdeo em IPTV, incluindo

a regenerao do relgio para controle do fluxo de bits entregue ao decodificador,
demonstrado na Figura 3.4, para uma transmisso unidirecional ponto a ponto (unicast).
Nesse tipo de esquema de controle, para o qual apresentada em [GENEL2003] uma
proposta com o codificador H.263+, utilizando a Internet, existe uma interdependncia
muito grande entre o receptor e o transmissor, uma vez que a qualidade percebida no
destino explicitamente sinalizada para a origem, que por sua vez precisa adequar as
condies de transmisso a fim de melhorar a qualidade no receptor em funo das
variaes de desempenho da PSN no transporte dos pacotes.

A97

Codificador de
Vdeo

Segmentao em
Pacotes

Decodificador de
Vdeo

Controle de Taxa
de Transmisso

Sinalizao de
Retransmisso
e Adequao
da Taxa de
Transmisso
(VBR)

Interface de Rede
(Transmissor)

Controle de
Erros

Remontagem dos
Pacotes

Interface de Rede
(Receptor)

Rede IP

Figura 3.4 Esquema usual para controle de qualidade em IPTV.

Como observado na Figura 3.4, nesse esquema usual o codificador realizada a
compresso dos sinais de vdeo e os entrega para o processo de segmentao, onde o fluxo
acomodado em pacotes e marcaes de tempo (timestamps) so agregadas aos mesmos
atravs do protocolo RTP, para ento serem encaminhados atravs da rede IP. O receptor,
recebendo os pacotes, extrai os dados e marcaes de tempo e efetua a regenerao do
fluxo contnuo de bits do sinal de vdeo codificado, que entregue ao decodificador.
Enquanto isso, pacotes de controle so trocados entre o transmissor e o receptor atravs do
protocolo RTCP, em portas IP separadas, contendo informaes e estatsticas do enlace
coletadas no destino para realimentao do transmissor, incluindo a perda de pacotes, a fim
de que o mesmo possa adequar sua operao, seja retransmitindo o pacote perdido, seja
reduzindo a taxa de transmisso, no caso de codificadores operando em VBR, ou ainda
atuando diretamente no codificador para modificar a forma de tratamento dos quadros,
tornando a codificao mais robusta a perdas.
Na alternativa de broadcasting IPTV proposta, essa interao direta entre receptor e
transmissor para controle do fluxo de pacotes e do processo de codificao, que se
apresenta como grande complicador em aplicaes ponto-multiponto, no necessria,
pois existe um circuito E1 dedicado entre transmissor e receptor; ou entre este e cada um
dos receptores, se o fluxo de pacotes for replicado pelos roteadores ao longo da rota em
A98

funo da utilizao de protocolos multicast. Assim, os equipamentos podem ser

configurados para processos de codificao/decodificao mais simples, pressupondo a
existncia de meios de transmisso confiveis, como no caso do Program Stream ao invs
do Transport Stream para o MPEG2.
Essa alternativa apresentada na Figura 3.5, onde toda a atividade de controle executada
exclusivamente no receptor, atravs do mecanismo de sincronizao adaptativa proposto,
cujo principal objetivo assegurar a estabilidade do fluxo de bits dentro do pseudocircuito, e no a qualidade da decodificao em si. Dessa forma, toda a responsabilidade
pela qualidade da conexo, do pseudo-circuito, que seria uma camada de enlace para a
aplicao, sendo a codificao/decodificao realizada com taxas constantes e de forma
completamente independente. Mecanismos de retransmisso de pacotes, se existentes, so
tambm tratados ao nvel do pseudo-circuito, de forma transparente para o decodificador.

Codificador de
Vdeo

Circuito E1 dedicado
(Emulao PWE3)

Segmentao em
Pacotes

Decodificador de
Vdeo

Remontagem dos
Pacotes
Sincronizao
Adaptativa

Interface de Rede
(Transmissor)

Interface de Rede
(Receptor)

Rede IP

Figura 3.5 Proposta de controle de qualidade baseado exclusivamente no receptor.

Como mostrado na Figura 3.5, o transmissor opera de forma livre, gerando um fluxo
contnuo de pacotes contendo o sinal de vdeo codificado, cabendo ao receptor a funo de
regenerar esse sinal para o decodificador, baseado exclusivamente na informao de
nmero de seqncia dos pacotes recebidos, atravs do novo mecanismo de
A99

seqenciamento desenvolvido, j discutido acima, e da recuperao do relgio do

transmissor atravs do mecanismo de sincronizao adaptativa baseado em PLL
apresentado na seo 2.3.3.
Do ponto de vista da aplicao, o circuito E1 emulado pode ser interpretado como um
simples cabo de conexo entre o codificador e o decodificador, no importando se ambos
os equipamentos encontram-se no mesmo prdio ou a centenas de quilmetros de distncia.
Felizmente, em funo do carter unidirecional da transmisso, os requisitos de preciso
para recuperao do relgio, assegurando boa qualidade na reproduo do sinal de vdeo
para o decodificador, so bastante inferiores aos necessrios nas aplicaes TDM para
transmisso de voz definidos pela Recomendao ITU-T G.823, o que simplifica bastante
essa tarefa para as taxas at 1,5Mbps definidas no escopo desse trabalho.
Em funo das caractersticas definidas para o broadcasting IPTV proposto, com objetivos
educacionais ou sociais, no existiriam grandes problemas se a recepo de um programa
iniciasse alguns segundos mais tarde para alguns receptores, em decorrncia de um tempo
de aquisio mais elevado do PLL ou da necessidade de um pr-armazenamento maior de
pacotes no buffer, desde que, a partir do incio da reproduo, a qualidade de vdeo se
mantivesse adequada, sem cortes ou interrupes.
Cabe observar ainda que, mesmo em aplicaes comerciais domsticas, sobretudo quando
no feita a conexo aos televisores atravs de entradas vdeo componente, no existe
grande criticidade, do ponto de vista do decodificador de vdeo, para a recuperao do
relgio no receptor, sendo comum a utilizao de osciladores locais nos set-top boxes para
controlar o processo de reproduo analgica dos sinais de vdeo.
Embora no baseada em PWE3, uma abordagem similar proposta, considerando o uso de
PLL para recuperao do relgio no receptor atravs de timestamps, apresentada em
[TRYFONAS1999] para sistemas de transmisso MPEG-2, demonstrando excelente
desempenho em aplicaes onde existem requisitos crticos para a recuperao do relgio.

A100

Como concluso das discusses realizadas nesse captulo, foi observado que existem
padres de codificao disponveis e bastante difundidos para atendimento restrio de
taxa de transmisso, em 1,5Mbps, como o MPEG-1 e o grupo H.323, sendo possvel
oferecer qualidade similar TV analgica existente com os pseudo-circuitos E1 propostos.
Alm disso, pde ser caracterizada a transferncia da responsabilidade, pela qualidade do
vdeo, da camada de aplicao para a camada de enlace representada pelo pseudocircuito, desacoplando o processo do transmissor e permitindo o controle dessa qualidade
em cada receptor, pela utilizao dos novos mecanismos de melhoria propostos no
trabalho. No captulo 4 ser feita a validao desses mecanismos, atravs da sua
implementao utilizando simulao e uma aplicao simples desenvolvida em Java, alm
da experimentao de um pseudo-circuito utilizando equipamentos comerciais, dentro da
rede LabCom/UnB.

A101

A102

4 - IMPLEMENTAO E RESULTADOS EXPERIMENTAIS

Nesse captulo realizada a implantao dos mecanismos propostos, inicialmente atravs

de simulao, com a descrio detalhada da modelagem utilizada para recuperao do
relgio no transmissor, em especial o PLL. Em seguida, so apresentados os resultados
experimentais da utilizao de um produto comercial para estabelecimento de um pseudocircuito para entroncamento de voz em uma central telefnica. Na seqncia, apresentada
a tentativa de implementao de uma aplicao em Java para a emulao de circuitos TDM
sobre redes IP, utilizando os mecanismos propostos, comparando seu desempenho com o
produto comercial atravs de experimentao dentro da rede LabCom/UnB. Finalmente,
so analisados os resultados obtidos na simulao e nos experimentos realizados.

4.1 - MODELAGEM TDMoIP UTILIZANDO MATLAB E SIMULINK

Com o objetivo de validar e avaliar o desempenho do novo mecanismo de seqenciamento

de pacotes, proposto na seo 2.3.2, e do mecanismo alternativo de sincronizao TDM,
proposto na seo 2.3.3, foram realizadas suas implementaes em ambiente de simulao,
atravs das ferramentas MatLab e Simulink, na verso 6.0.0.88 Release 12.
4.1.1 Modelagem TDMoIP no MatLab e Simulink

Em funo das caractersticas distintas dos mecanismos propostos, foi analisada a melhor
alternativa para sua simulao dentro das ferramentas de simulao disponveis.
Para o novo mecanismo de seqenciamento, por tratar-se de um algoritmo passvel de
implementao matemtica, foram criadas funes dentro do MatLab que executassem o
tratamento desejado dos dados, sendo os principais desafios a modelagem dos pacotes
como variveis matemticas e, fundamentalmente, a modelagem do comportamento de

A103

uma rede PSN, refletindo o atraso sofrido pelos pacotes e, por conseqncia, sua perda e/ou
recebimento fora de ordem.
Para o mecanismo alternativo de sincronizao, contudo, embora a operao PLL tambm
seja baseada em fundamentao matemtica, a complexidade de modelagem atravs de
simples funes de manipulao dos dados seria demasiado grande, e no permitiria uma
correta visualizao das questes envolvidas. Assim, optou-se pela utilizao da ferramenta
Simulink, inclusa no pacote MatLab, que possui modelos disponveis de todos os blocos
bsicos necessrios para a construo dos circuitos que implementam o mecanismo
proposto, caracterizando assim uma simulao do hardware associado ao mesmo.

4.1.2 Simulao MatLab do algoritmo de seqenciamento de pacotes

A anlise do problema de variao do atraso e perda de pacotes em uma rede PSN,

realizada para a Internet em [BOLOT1993], apresenta o modelo da rede, do ponto de vista
de um pacote transmitido entre dois pontos, como uma fila onde o tempo de servio uma
varivel aleatria que segue uma determinada estatstica, caracterstica da PSN analisada.
Esse modelo foi entendido como satisfatrio para a validao do algoritmo proposto para
seqenciamento de pacotes, de modo que a modelagem matemtica, dentro do MatLab,
foi totalmente baseada nessa abordagem. Dessa forma, cada pacote gerado e transmitido
atravs da rede foi modelado como a linha de uma matriz, ao qual foram associados trs
atributos, armazenados em cada uma das colunas da mesma:

O nmero de seqncia (NS), cujo valor inicial determinado randomicamente dentro

do intervalo [0; 216-1] e incrementado a cada novo pacote (nova linha da matriz);

O instante de transmisso do pacote (t), cujo valor inicial zero para o primeiro pacote,
somando-se aos demais a durao dos dados TDM dentro de cada pacote (1ms);

O instante de recepo do pacote, correspondente soma do instante de transmisso (t)

com um valor aleatrio, com mdia equivalente metade do RTT (Round-Trip Time)
estabelecido para a simulao e distribuio estatstica definida.

A Tabela 4.1 ilustra matriz utilizada na modelagem da transmisso dos pacotes na PSN.
A104

Tabela 4.1 Matriz de simulao da transmisso de pacotes atravs da PSN.

Pacote
Simulado
1
2
3
4
5
6
7
8
9
10
...
500

Nmero de
Seqncia
16327
16328
16329
16330
16331
16332
16333
16334
16335
16336

Instante de
Transmisso
0 ms
1 ms
2 ms
3 ms
4 ms
5 ms
6 ms
7 ms
8 ms
9 ms

Instante de
Recepo
20 ms
26 ms
39 ms
24 ms
23 ms
Infinito (perdido)
38 ms
29 ms
Infinito (perdido)
37 ms

16827

499 ms

528 ms

Com o objetivo de permitir um controle mais efetivo do comportamento dos algoritmos de

seqenciamento na ocorrncia de perdas de pacote dentro da simulao, foi includa ainda
uma outra varivel, independente da estatstica de distribuio definida para a PSN, com o
objetivo de levar o atraso ao infinito, simulando um pacote perdido, para determinado
percentual de pacotes previamente definido.
Dessa forma, para que a simulao fosse realizada, comparando o desempenho entre o
algoritmo apresentado no Internet-Draft TDMoIP (reproduzido no Apndice A) e o
proposto na seo 2.3.2, era preciso definir, nesse modelo, um comportamento estatstico
para o atraso dos pacotes condizente com aquele observado nas redes de interesse.
Assim, foram definidas duas estratgias para a obteno de amostras do atraso sofrido
pelos pacotes em uma WAN de abrangncia nacional, que permitisse a caracterizao das
situaes a serem enfrentadas pelo problema de broadcasting PTV:
1) A medio do RTT para pacotes gerados na rede LabCom/UnB e encaminhados atravs
da Internet para destinos nas principais capitais do pas, utilizando o protocolo ICMP
(Internet Control Message Protocol) com pacotes de 300 octetos (representando 1ms
de trfego TDM), em diversos horrios e dias da semana ao longo do ms de
agosto/2006, a fim de refletir o comportamento em redes sem controles ou garantias,
baseadas apenas no servio de melhor esforo, ou BE (Best-Effort);

A105

2) A medio dos atrasos sofridos pelo trfego real dos clientes, em diversos ns do
backbone IP da Brasil Telecom e para as diversas classes do servio Vetor, a fim de
refletir o comportamento de uma rede bem controlada e com garantia de QoS aos
clientes, alm do uso sistemtico de tcnicas de engenharia de trfego.
Infelizmente, a segunda estratgia no pde ser executada, em funo de mudanas na
configurao da gerncia da rede IP da Brasil Telecom, que impossibilitaram as medies,
de forma que a estatstica acabou sendo gerada exclusivamente com base nos RTTs
medidos atravs da Internet, utilizando como endereo de destino os stios das principais
universidades federais do pas e os portais dos governos estaduais. Evidentemente, essa
abordagem foi impactada por outras variveis alm do atraso oferecido pela rede, como o
desempenho dos servidores de domnio, a velocidade dos enlaces no destino e a carga dos
servidores de hospedagem desses stios, mas a quantidade de medies foi razovel e o
comportamento estatstico obtido, apresentado na Figura 4.1, ficou dentro das expectativas
previstas, com um RTT mdio geral de 84,1 ms e 30% de perda de pacotes para todo o
conjunto de medies realizadas.

160
140
120
100
80
60
40
20

10
20
30
40
50
60
70
80
90
10
0
11
0
12
0
13
0
14
0
15
0
16
0
17
0
18
0
19
0
20
0
21
0
22
0
23
0

RTT medido (ms)

Figura 4.1 Histograma de freqncias na medio do RTT entre o LabCom/UnB e os

stios Internet das universidades federais e portais dos governos estaduais brasileiros.

A106

A inspeo visual do histograma obtido para os RTTs medidos permite ajustar o

comportamento do atraso a uma distribuio lognormal, em funo da cauda representada pelos RTTs acima de 200ms, medidos para stios na regio norte do pas, da UFAC
(Universidade Federal do Acre) e UNIR (Fundao Universidade de Rondnia).
Contudo, considerando pouco representativa a mdia encontrada para o RTT, na faixa dos
80ms, e a concentrao dos valores medidos no intervalo [40ms; 120ms], optou-se por
considerar distribuio uniforme dentro desse intervalo na simulao, entendendo que isso
representa bem o comportamento do atraso de pacotes para comparao entre os algoritmos
de seqenciamento, alm de ser mais facilmente implementado no MatLab.
Assim, o atributo Instante de Recepo foi modelado como uma varivel aleatria de
distribuio uniforme entre os valores RTT/2 e RTT/2+RTT, para um RTT de 80 ms,
sendo os resultados da simulao apresentados na Figura 4.2, onde os pontos em azul
representam o nmero de seqncia de cada pacote transmitido, no instante de transmisso;
enquanto os pontos em verde representam o mesmo nmero de seqncia, no respectivo
instante de recebimento, funo do atraso aleatrio sofrido por cada pacote dentro da rede.

Figura 4.2 Grfico da simulao MatLab, apresentando os

pacotes transmitidos (azul) e recebidos (verde).

A107

Nesse grfico, o atraso aleatrio sofrido por cada um dos pacotes indicado pela distncia,
no eixo horizontal, entre o ponto em azul e o ponto em verde.
Na Figura 4.3 mostrado o instante de recebimento de cada pacote, por ordem de chegada,
apresentando uma viso mais intuitiva do processo. Pode ser observado que os primeiros
pacotes so recebidos na ordem correta, formando uma pequena reta de inclinao positiva,
a partir do pacote de nmero de seqncia 9.265 comeam a haver degraus, indicando
mudana na ordem de natural de recebimento, e a partir do pacote 9.275, a inclinao da
reta torna-se bruscamente negativa, indicando que uma grande quantidade de pacotes com
nmero de seqncia inferior a este foi recebido. Esse fenmeno se repete inmeras vezes
para os 400 pacotes da simulao, cuja taxa de pacotes perdidos foi de 10%, em funo da
elevada disperso do atraso gerada pela distribuio uniforme utilizada.

Figura 4.3 Grfico da simulao MatLab, apresentando os instantes de

transmisso (azul) e recepo (verde) de cada pacote.
A partir da situao mostrada nos grficos anteriores, representada na simulao pela
matriz descrita anteriormente, so aplicados os dois algoritmos de simulao em anlise,
com o objetivo de restabelecer o seqenciamento dos pacotes, com a menor perda de
informao possvel.

A108

Assim, na Figura 4.4 apresentado o resultado da aplicao do algoritmo apresentado em

[IETF2006], reproduzido no Apndice D, utilizando como mitigao para os pacotes
considerados perdidos a reproduo do ltimo pacote recebido, considerando o parmetro
R=40, ou seja, aceitando pacotes atrasados com desvio de at quarenta posies em relao
esperada, conforme definido pelo algoritmo. Esse valor representa o mximo possvel
para a simulao realizada, onde a reproduo dos pacotes comea 40 ms aps o
recebimento do primeiro. Os pontos em vermelho representam o nmero de seqncia de
cada pacote transmitido, no respectivo instante de reproduo para o fluxo TDM de sada.

Figura 4.4 Grfico da simulao MatLab, utilizando o algoritmo proposto pelo

IETF para seqenciamento, apresentado no Apndice A.
Como pode ser observado pelos pontos em vermelho, o desempenho desse algoritmo
muito ruim para o comportamento fortemente aleatrio do atraso assumido, mesmo
admitindo-se a recuperao de pacotes atrasados em at 40ms. A existncia dos
patamares mostrados na figura decorrente da estratgia de preenchimento integral das
posies remanescentes do buffer, utilizando o contedo do ltimo pacote vlido, sempre
que for recebido um pacote de nmero de seqncia superior ao esperado pelo algoritmo.
Essas posies preenchidas, em princpio, teriam seu contedo substitudo pelos dados
reais medida que os pacotes atrasados fossem chegando, limitados ao instante de
reproduo, mas isso, em funo da elevada disperso do atraso no modelo de rede

A109

simulado, no ocorre com a freqncia necessria para que a linha vermelha reproduzisse
fielmente o seqenciamento original dos pacotes, apresentado na linha em azul.
Finalmente, na Figura 4.5 apresentado o resultado da aplicao do algoritmo proposto
nesse trabalho, utilizando como regra de mitigao, para os pacotes considerados perdidos,
tambm a reproduo do ltimo pacote recebido sem problemas. Os pontos em vermelho
novamente representam o nmero de seqncia de cada pacote transmitido, no respectivo
instante de reproduo para o fluxo de sada.
Como pode ser observado pela reta em vermelho, o algoritmo absorveu completamente os
pacotes recebidos fora da ordem esperada, em verde, recolocando-os com sucesso na
ordem original em que foram transmitidos, indicada pela reta em azul. O deslocamento de
aproximadamente 80 ms na horizontal entre as retas vermelha e azul decorrente dos 40ms
de atraso mdio definido na simulao da rede, mais o atraso introduzido pelo buffer de
reproduo, configurado para um tamanho de 80ms e incio da reproduo dos pacotes,
contendo 1ms de dados TDM, a partir de 50% de ocupao.

Figura 4.5 Grfico da simulao MatLab, utilizando o novo mecanismo

proposto de gravao no jitter buffer para seqenciamento.

A110

Nesse exemplo mostrado em particular, foram considerados perdidos e mitigados 42 dos

400 pacotes simulados, em funo do seu recebimento no ter ocorrido a tempo de serem
reproduzidos no fluxo de sada.
As funes MatLab desenvolvidas para a implementao dos dois algoritmos
apresentados acima esto listadas no Apndice B.
4.1.3 Simulao Simulink do PLL para sincronizao do receptor

O princpio geral de operao do PLL para sincronizao adaptativa do receptor na

emulao de circuitos TDM sobre uma rede de pacotes, conforme proposto na seo 2.3.3,
ilustrado pela Figura 4.6, adaptada de [AWEYA2004].

Transmissor

Fluxo
TDM

Pacotes
Enviados
(atraso constante)

Pacotes
Recebidos
(atraso varivel)

Montagem
Pacotes

Oscilador

Pulsos

Contador

Jitter Buffer

PSN
Dados
NS

CkTx

Receptor

Fluxo
TDM

CkRx

Detetor
de Fase

Sinal de
Erro

NS

CkTx

Sinal de
Controle
Filtro de
Realimentao

Oscilador

DCO

Pulsos

Contador

CkRx

Figura 4.6 Princpio de operao da sincronizao adaptativa usando PLL.

O transmissor realiza a montagem dos pacotes, a uma taxa constante determinada por seu
oscilador local, normalmente sincronizado com o relgio regenerado a partir do fluxo TDM
original, que por sua vez estaria sincronizado com o restante da rede TDM. A cada um
desses pacotes, cujo tamanho em durao dos dados TDM fixo, adicionado um nmero
de seqncia representativo do mesmo, que na figura gerado por um contador de pulsos
conectado ao relgio local CkTx. Na seqncia, os pacotes assim montados so
encaminhados, atravs da PSN, ao receptor.
A111

Quando os pacotes chegam ao receptor, so desmontados e armazenados no jitter buffer,

aguardando o instante de sua reproduo no fluxo TDM de sada, que determinado pelo
seu prprio relgio local CkRx. A funo do PLL exatamente fazer com que CkTx
mantenha-se sempre preso (locked) a CkRx, independentemente das flutuaes dos
osciladores e, fundamentalmente, do atraso varivel sofrido pelos pacotes que trafegam
atravs da rede.
O circuito PLL proposto, conceitualmente bastante similar quele utilizado em aplicaes
de demodulao de sinais de udio, como em receptores de rdio FM (Freqncia
Modulada), composto por quatro mdulos bsicos, mostrados na Figura 4.6:
a) Detetor de fase: responsvel pelo clculo da diferena entre um sinal de referncia,
no caso o nmero de seqncia recebido em cada pacote, e a sada do PLL, no caso o
nmero de seqncia presumido para o pacote, determinando o chamado Sinal de Erro;
b) Filtro de realimentao: um filtro de caracterstica passa-baixas, que elimina os
efeitos indesejados presentes no sinal de referncia, como rudos e, no caso, as
flutuaes decorrentes da diferena de atraso sofrida pelos pacotes dentro da PSN
(PDV), gerando o chamado Sinal de Controle;
c) DCO (Digitally Controlled Oscillator): um oscilador controlado digitalmente, que
gera o relgio utilizado no receptor, exatamente na freqncia determinada pelo Sinal
de Controle;
d) Contador de Pulsos: um contador idntico ao utilizado pelo transmissor para a
gerao dos nmeros de seqncia dos pacotes, conectado sada do DCO, que
responsvel pela gerao do nmero de seqncia presumido para os pacotes, que
constitui a sada do PLL.
Em sua operao na sincronizao de circuitos TDM emulados sobre redes de pacote, o
PLL enfrenta dois grandes desafios opostos na sua implementao:

Apresentar uma freqncia de corte bem definida, a fim se suavizar de forma adequada
os efeitos da variao no atraso sofrido pelos pacotes (PDV) dentro da rede;

Responder rapidamente s variaes na freqncia do transmissor, percebida a partir

dos pacotes recebidos, a fim de reduzir o chamado tempo de aquisio, ou seja, o

A112

intervalo de tempo necessrio para que a freqncia gerada pelo DCO seja exatamente
a freqncia do oscilador local do transmissor, em regime permanente de operao.
A chave para compatibilizao desses dois desafios mutuamente excludentes exatamente
o projeto adequado do Filtro de Realimentao, cujos requisitos fundamentais so:

Eliminar de forma satisfatria os efeitos da variao no atraso dos pacotes (PDV) sobre
o Sinal de Controle do DCO;

No retardar a resposta do PLL a flutuaes na freqncia do transmissor;

No elevar o tempo de recuperao do relgio durante o restabelecimento do pseudocircuito, aps mudanas na PSN como o rearranjo de rotas ou a recuperao de
congestionamentos, uma vez que isso levaria a overflow do jitter buffer, com descarte
de pacotes e gerao de AIS para o enlace TDM.

Para melhor compreenso desses requisitos, feita uma descrio matemtica da operao
do PLL, utilizando o desenvolvimento em [AWEYA2004], com as devidas adaptaes e a
ajuda do diagrama de blocos do PLL em malha fechada apresentado na Figura 4.7.

NS
recebidos

T(n)

Freqncia
recuperada

T(n)

+
-

z-1 T(n-1)
atraso de

um pacote

e(n)

u(n)

k0.

f (n)
s

R(n)

R(n)

Contador

-1
z
R(n-1) atraso de

um pacote

Figura 4.7 Diagrama de blocos do PLL em malha fechada.

Considerando que existem dois osciladores completamente independentes no transmissor e
no receptor, cujas freqncias so definidas nas equaes (4.1) e (4.2):

A113

fs =

(4.1)

1
fs =
s

(4.2)

E definindo as seguintes variveis discretas:

n = 0 ,1,2 ,

"

T ( n) !
R ( n) !
d(n)
d(n 1 )
Tem-se a equao (4.3), que relaciona os nmeros de seqncia do transmissor e receptor:
R(n) = T (n) + d (n)

(4.3)

Pode ser tambm definida matematicamente na equao (4.4) a variao no atraso sofrido
por cada pacote j(n), aqui denominada jitter, como sendo:
j(n) = d (n) d (n 1)

(4.4)

Considerando ainda os intervalos entre pacotes gerados pelo transmissor, dados pela
equao (4.5), que so constantes em funo das caractersticas do circuito TDM emulado:
T(n) = T (n) T (n 1) = K TDM

(4.5)

E os intervalos entre os pacotes que chegam ao receptor, dados pela equao (4.6):
R(n) = R (n) R (n 1)

(4.6)

A equao (4.6) pode se reescrita da seguinte forma, gerando a equao (4.7):

R(n) = R (n) R(n 1)

R(n) = T (n) + d (n) [T (n 1) + d (n 1)] = T (n) T (n 1) + d (n) d (n 1)

R(n) = T (n) + j (n)

R(n) = T(n) + j (n) = K TDM + j (n)

A114

(4.7)

Ou seja, o intervalo de chegada dos pacotes ao receptor apresenta duas componentes, uma
constante, correspondente durao dos dados TDM dentro do pacote, e outra varivel,
que corresponde ao jitter (ou PDV), no sentido definido acima.
Assim, o problema fundamental do PLL consiste em controlar a freqncia de oscilao no
receptor, fs , de modo que os dois intervalos entre pacotes sejam idnticos:
R(n) = T (n) j (n) = 0

Para isso, calculado pelo Comparador de Fase o Sinal de Erro e(n) entre ambos, definido
na equao (4.8), que corresponde ao prprio j(n) medido, como indicado na Figura 4.7:
e(n) = T (n) R(n) = j (n)

(4.8)

Esse Sinal de Erro aplicado ao Filtro de Realimentao, modelado como um sistema

linear com funo de transferncia h, em princpio invariante no tempo, de modo que o
Sinal de Controle u(n) a resultante da convoluo entre ambos, dada pela equao (4.9):
u(n) = h * e(n)

(4.9)

O Sinal de Controle, por sua vez, aplicado ao DCO, que pode ser modelado, numa
primeira anlise, pela equao (4.10), onde Ko o ganho do DCO:
fs = K o .

u ( n)

(4.10)

Assim, na sada do DCO, obtida a freqncia do oscilador no receptor, como funo

direta do nmero de seqncia gerado atravs do Contador para os pacotes que chegam ao
mesmo, conforme dado pela equao (4.11):
fs = K o .

u ( n) = K o .

fs = K o .

h * [K TDM (R(n) R(n 1) )]

h * e(n) =K o .

fs = K o .

h * (T (n) R(n)) =K o .

h * [K TDM (R (n) R (n 1) )]

h * (K TDM R(n))

(4.11)

Como a freqncia do DCO no receptor fs , utilizada para gerar R(n) atravs do contador na
sada do PLL, nada mais que uma estimativa da freqncia f s do oscilador utilizado no
transmissor para gerao de T(n) atravs do respectivo contador, tem-se a condio descrita

A115

pela equao (4.12), que assegura a captura da freqncia do transmissor pelo PLL,
garantindo a sincronizao do fluxo TDM de sada no receptor:
R(n) R(n 1) = R(n) = T (n) = K TDM f s = fs

(4.12)

Logo, fica provado matematicamente que o fluxo TDM que chega ao transmissor pode ser
regenerado fielmente na sada do receptor atravs, exclusivamente, dos nmeros de
seqncia T(n) originais, recebidos dentro de cada pacote, e dos nmeros de seqncia R(n)
presumidos, gerados pelo prprio receptor, no havendo necessidade de transmisso
explcita de marcaes de tempo (timestamps) nos pacotes TDM.
Entretanto, a equao (4.11), apesar de direta, no pode ser implementada de maneira
simples, j que os elementos representados pela funo de transferncia h e pelo integrador
discreto , so relativamente complexos, assim como a operao de convoluo. Dessa
forma, esses dois elementos e suas implementaes precisam ser descritos em maiores
detalhes antes que possa ser discutida a sua modelagem dentro do Simulink.
Assim, na Figura 4.8 apresentado o diagrama de blocos para um filtro de realimentao
do tipo EWMA (Exponencially Weighted Moving Average), acompanhado por um breve
desenvolvimento de sua funo de transferncia em Z, conforme proposto em
[AWEYA2004], onde podem ser encontradas maiores informaes a respeito desse filtro,
assim como as motivaes do autor para sua utilizao.

h
Entrada
Filtro

e(n)

s(n)

z-1
s(n-1)

(1-1)

u(n)

z-1
u(n-1)

(1-2)

Figura 4.8 Diagrama de blocos do filtro EWMA duplo.

A116

Sada
Filtro

Como observado na seqncia dos blocos na Figura 4.8, o filtro caracterizado por dois
estgios idnticos em cascata, que podem ser matematicamente descritos pelo par de
equaes a diferenas (4.13) e (4.14), onde 0 < 1 , 2 < 1 :
s(n) = (1 1 ).s(n 1 ) + 1 .e(n)

(4.13)

u (n) = (1 2 ).s(n 1 ) + 2 .s (n)

(4.14)

Aplicando a transformada Z a essas equaes ou seguindo o fluxo dos blocos, obtida a

funo de transferncia apresentada na equao (4.15), onde 1 = 1 1 2 = 1 2 :
H ( z) =

1 .z
2 .z
1 . 2 .z 2
U (z)
=
.
= 2
E ( z ) z (1 1 ) z (1 2 ) z ( 1 + 2 ).z + 1 . 2

(4.15)

Esse filtro, utilizando a parametrizao apresentada em [AWEYA2004a], foi

implementado no Simulink como referncia para as simulaes realizadas com o
mecanismo alternativo de sincronizao adaptativa proposto neste trabalho, utilizando uma
tcnica de controle clssico, o controlador PID, para gerao do sinal de controle dentro do
PLL, a partir do sinal de erro medido.
O controlador PID a tcnica de controle clssico de estrutura fixa mais utilizada nas
aplicaes industriais, em processos com funes de transferncia aproximadas por
sistemas lineares de 1a ou 2a ordem, permitindo assim a utilizao de controladores
baseados em poucos parmetros, muitas vezes determinados de forma emprica. Para
processos mais complexos, so utilizadas normalmente tcnicas do chamado controle
moderno, baseadas em realimentao de estado e implementadas por controladores digitais.
Maiores informaes sobre essas tcnicas de controle podem ser encontradas em
[DAZZO1988]. O termo PID significa Proporcional+Integral+Derivativo, que so as trs
aes independentes executadas por esse controlador sobre a varivel determinada:

Ao Proporcional (P): consiste basicamente na utilizao de um ganho Kp aplicado

ao sinal de erro, oferecendo resultados razoveis para sistemas lineares de 1a ordem que
proporcionam, em malha fechada, um erro esttico pequeno e uma resposta transitria
bastante rpida. Em sistemas de ordem superior, no entanto, so necessrios valores
elevados de ganho para reduo do erro esttico, e isso costuma levar os sistemas
instabilidade, o que torna a ao proporcional pouco recomendvel, isoladamente.

A117

Ao Integral (I): consiste basicamente em introduzir capacidade de memorizao no

processo, ponderada pelo ganho KI, atravs da utilizao de um integrador (plo na

origem do plano s) no controlador, fazendo com que o sistema, em malha fechada,
tenha resposta oscilatria e mais lenta, oferecendo bons resultados quando as
caractersticas do sistema no atendem s especificaes de erro nulo para
determinadas entradas ou perturbaes. Costuma ser sempre acompanhada por uma
ao Proporcional.

Ao Derivativa (D): consiste basicamente em introduzir sensibilidade taxa de

variao do processo, ponderada pelo ganho KD, com o objetivo de melhorar as

caractersticas transitrias do comportamento do sistema, oferecendo respostas rpidas
s variaes bruscas detectadas e ao nula sobre o regime permanente. Costuma ser
sempre acompanhada pelas aes Proporcional e Integral.
Dessa forma, analisando os requisitos impostos ao Filtro de Realimentao utilizado pelo
PLL, foi feita uma associao imediata com as caractersticas de ao independente de um
controlador PID, sendo proposta a sua utilizao como alternativa s abordagens
tradicionais baseadas nos diversos tipos de filtros passa-baixas, como o EWMA citado
anteriormente.
O controlador PID oferece a ao proporcional necessria para o ajuste de escala entre a
variabilidade dos nmeros de seqncia, dependente do volume de pacotes recebidos fora
de ordem da PSN, com o sinal de controle do DCO e sua capacidade de deslocamento em
torno da sua freqncia central. Ao mesmo tempo, a ao integral assegura, atravs da
memorizao, o amortecimento do rudo gerado pelas grandes variaes no intervalo de
recebimento dos pacotes, caracterstica bsica da funo desempenhada pelos filtros passabaixas. Finalmente, a ao derivativa possibilitaria uma resposta rpida quando do
restabelecimento do pseudo-circuito em decorrncia de variaes na configurao da PSN
ou escorregamento da freqncia do transmissor, garantindo um tempo de aquisio
reduzido para o PLL. Assim, foi entendido que, com a sua utilizao ao invs de um
simples filtro, seria possvel ajustar cada uma dessas caractersticas de forma independente,
assegurando o melhor desempenho para o PLL em todas as situaes.

A118

O diagrama de blocos do controlador PID discreto utilizado apresentado na Figura 4.9,

assim como suas equaes a diferenas e a respectiva funo de transferncia em Z
utilizada na implementao Simulink.

PID
Entrada
Filtro

e(n)

(1+TD)
z-1

e(n-1)

u(n)

Sada
Filtro

z-1
-1

(TI -1-2.TD)

u(n-1)

z-1
e(n-2)

TD

Figura 4.9 Diagrama de blocos do controlador PID.

Atravs da simples lgebra de blocos aplicada Figura 4.9, o controlador PID
matematicamente descrito pela equao a diferenas (4.16), onde KP o ganho
Proporcional K I = K P . T1I o ganho Integral e K D = K P .TD o ganho Derivativo:

u ( n ) = K p . e( n) +

1 n 1
. e(i ) + TD .[e(n) e(n 1)]
TI i = 0

(4.16)

Essa equao a diferenas representa literalmente as caractersticas do controlador, mas

tem o inconveniente de necessitar, devido componente integral, da armazenagem de todas
as amostras anteriores. Contudo, como observado pela seqncia de blocos na Figura 4.9,
ela pode ser reescrita na forma da equao (4.16a), em funo da sada anterior e de apenas
duas das amostras anteriores, uma vez que o controlador PID um sistema de 2a. ordem.

A119

u (n) = K p .e(n) +

Kp

TI

n 1
i =0

u (n 1) = K p .e(n 1) +

e(i ) + K p .TD .[e(n) e(n 1)]

Kp
TI

u (n) u (n 1) = K p .e(n) +
K p .e(n 1) +

Kp
TI

n2
i =0

Kp
TI

n 2
i =0

n2
i =0

Kp
TI

e(i ) + K p .TD .[e(n 1) e(n 2)]

.

n 1
i =0

e(i ) + K p .TD .[e(n) e(n 1)]

e(i ) + K p .TD .[e(n 1) e(n 2)]

u (n) = u (n 1) + K p .e(n) +
K p .e(n 1)

Kp
TI

.e(n 1) +

Kp
TI

n2
i=0

e(i ) + K p TD .e(n) K pTD .e(n 1)

e(i ) K p .TD .e(n 1) + K p .TD .e(n 2)

u (n) = u (n 1) + K p .[1 + TD ].e(n) + K p .

Kp

u (n) = u (n 1) + K p .[1 + TD ].e(n) + K p .

Kp

TI

TI

1 2.TD .e(n 1) + K p .[TD ].e(n 2)

1 2.TD .e(n 1) + K p .[TD ].e(n 2)

(4.16a)

Aplicando a transformada Z equao (4.16a) e reagrupando os termos, obtida a funo

de transferncia para o controlador PID, apresentada na equao (4.17):
Z {u (n)} = Z u (n 1) + K p .[1 + TD ].e(n) + K p .

Kp
TI

1 2.TD .e(n 1) + K p .[TD ].e(n 2)

Z {u (n)} = Z {u (n 1)} + Z {Kp.[1 + TD ].e(n)} + Z Kp.

U ( z ) = z 1 .U ( z ) + Kp.[1 + TD ].E ( z ) + Kp.

1
TI

1
1 2.TD .z 1 .E ( z ) + Kp.[TD ].z 2 .E ( z )
TI

1
1 2.TD .z 1 + [TD ].z 2 .E ( z )
TI

(1 z 1 ).U ( z ) = Kp. [1 + TD ] +

[1 + TD ] +
U ( z)
= Kp.
E( z)

1
1 2.TD .e(n 1) + Z {Kp.[TD ].e(n 2)}
TI

1 2.TD .z 1 + [TD ].z 2 . z 2

. 2
(1 z 1 )
z

[1 + TD ].z 2 + T1I 1 2.TD .z + [TD ]

U ( z)
= Kp.
E( z)
( z 1).z
H ( z) =

(1 + TD ).z 2 (1 + 2.TD T1I ).z + TD

U ( z)
= KP.
E( z)
( z 1).z

A120

(4.17)

O segundo elemento de maior complexidade para a construo do PLL o DCO, que na

verdade acaba sendo implementado de forma bastante simples, considerando as
caractersticas disponveis nos contadores digitais. Um DCO na verdade um divisor de
freqncia por N, sendo este programvel, ao qual aplicado um relgio de freqncia
mais elevada, tipicamente acima de 100 para o caso do PLL, conforme apresentado na
Figura 4.10 e no desenvolvimento matemtico correspondente.

DCO
Ncorr(n-1)
Sada
Filtro

NDCO(n)

k0

f (n)
s

nom

Relgio do
Receptor

Reset

nom

Contador

Oscilador

Pulsos

f =
O

Figura 4.10 Diagrama de blocos do DCO.

O DCO construdo a partir de um contador, ao qual so aplicados os pulsos produzidos
por um oscilador fixo independente de alta freqncia, definida pela equao (4.18):

fo =

(4.18)

A sada desse contador aplicada a um comparador, que realiza a comparao da contagem

com um valor NDCO(n) de referncia, correspondente entrada do DCO, enquanto sua sada
ligada entrada de reinicializao (reset) do contador, como mostrado na Figura 4.10.
Assim, sempre que a contagem alcana o valor de referncia NDCO(n), o contador
reiniciado, comeando um novo ciclo. Isso significa que a freqncia do oscilador fixo
aplicado na entrada do contador aparece, na sada do comparador, dividida pelo valor
NDCO(n). Tomando-se a sada do comparador como sinal de sada do DCO e assumindo que

A121

o valor de referncia NDCO(n) uma entrada digital de controle, implementado um

oscilador digitalmente controlvel, cuja freqncia de sada definida pela equao (4.19).
f DCO (n) =

(4.19)

DCO (n)

Assumindo para esse DCO uma freqncia central, definida pela equao (4.20), cujo valor
corresponde diviso da freqncia do oscilador fixo fo por um valor Nnom , definido pela
equao (4.21), caracterizada a condio demonstrada na Figura 4.10:
f nom =

(4.20)

nom

nom
o

(4.21)

Considerando ainda um sinal de correo Ncorr(n-1) aplicado quando da chegada do pacote

anterior, definido na equao (4.22) como um ajuste corr(n-1) no perodo de oscilao do
DCO, dado pelo ganho Ko, que resulta no novo perodo DCO(n), dado pela equao (4.23):
corr

(n 1) =

1 corr (n 1)
.
Ko
o

DCO (n) =

(n 1)

(4.22)
(4.23)

Aplicando as definies anteriores em (4.23), so obtidas as equaes (4.24) e (4.25), para

o perodo DCO(n) e o divisor NDCO(n) em funo do sinal de correo Ncorr(n-1):

DCO (n) =
DCO (n) =
DCO (n) = [
DCO (n)
=[
o

(n 1)

. o K o $

(n 1). o

(n 1)]. o

(n 1)] = N DCO (n)

(n) = [

Ko $

(n 1)]. o

(4.24)

( n) =

Ko $

(n 1)

(4.25)

Dessa forma, como Ncorr(n-1) corresponde sada do filtro de realimentao, ou seja, ao

sinal de controle u(n-1), o perodo de oscilao resultante , na verdade, uma estimativa do
perodo do relgio utilizado pelo transmissor s, conforme indicado pela expresso (4.26):

A122

 DCO = s =

1 estimativa
1

s =
f
fs
s

(4.26)

Descrito o funcionamento de cada um de seus blocos componentes, na Figura 4.11,

apresentada a operao completa do PLL para a recuperao do sincronismo no receptor.

T(n)

Relgio do
Receptor

PLL

NS
recebidos

T(n)

+
-

z-1 T(n-1)

e(n)

u(n)

f (n)

k0.

R(n)

+
-

Relgio
utilizado na
reproduo
TDM
(bit a bit)

R(n)

z-1
R(n-1)

Contador
1

Contador
inicializado
com o
primeiro NS
recebido

NS presumido
comparado com NS no
buffer para reproduo
(aps 50% ocupao)

NS
presumido

Figura 4.11 Operao do PLL na recuperao do sincronismo no receptor.

Quando o primeiro pacote recebido, o contador inicializado com o valor do seu nmero
de seqncia (1); conforme os demais pacotes vo sendo recebidos, o PLL calcula a
diferena entre o nmero de seqncia do pacote que chega T(n) e o anterior T(n-1) e inicia
a operao em malha fechada, comparando essa diferena T(n) com a sada atual R(n) do
contador R(n), subtrada da contagem anterior R(n-1), ou seja, R(n). A diferena entre os
dois valores gera um sinal de erro e(n), que ento filtrado por h, cuja sada u(n) utilizada
para ajustar a freqncia do DCO, fs , que gera os pulsos para o contador, fechando assim
a malha de realimentao. Quando o intervalo entre nmeros de seqncia recebidos T(n)
maior que o intervalo na contagem R(n), significa que a freqncia do DCO est mais
rpida que a de transmisso, devendo ser reduzida atravs do aumento do divisor NDCO;
caso contrrio, a freqncia do DCO deve ser acelerada pela reduo desse divisor, at que
ambos os intervalos sejam iguais. Nessa condio, os nmeros de seqncia gerados no
A123

contador sero

idnticos aos armazenados no jitter buffer para reproduo de cada

conjunto de dados TDM, aps o perodo de espera necessrio para acomodao do atraso
mdio introduzido pela PSN, tipicamente 50% da ocupao do buffer (2) em regime
permanente. Ao mesmo tempo, a freqncia na sada do DCO corresponde exatamente ao
relgio utilizado na montagem dos pacotes com o fluxo TDM no transmissor, permitindo
desmontagem sincronizada e regenerao exata desse fluxo, bit a bit, no receptor (3).
O mecanismo de regenerao do relgio no receptor atravs do PLL foi implementado no
Simulink, conforme apresentado na Figura 4.12, fazendo as devidas adaptaes para o
ambiente de simulao, com o objetivo de avaliar seu desempenho nas condies
encontradas na emulao de circuitos TDM sobre PSN, como variao no atraso e perda de
pacotes, bem como leves desvios na freqncia do transmissor, analisando o tempo de
captura do PLL para condies de jitter e o wander presentes no fluxo TDM.

Modelo do Transmissor

Modelo da PSN

Modelo do Receptor

Figura 4.12 Implementao do PLL com filtro EWMA no Simulink.

A124

O modelo foi construdo dentro do Simulink utilizando os blocos disponveis para a

implementao do PLL, e tambm modelos de osciloscpio e display para a monitorao
contnua dos principais sinais envolvidos., como o atraso nos pacotes provocado pela PSN,
a sada do DCO, os sinais T(n) e R(n), o valor dos contadores no transmissor, recebido
T(n) e regenerado R(n) no receptor, a diferena entre ambos d(n), as freqncias no
transmissor f s e no receptor fs , o sinal de controle do DCO, Ko.u(n), e o valor do divisor
de freqncia corrente, NDCO(n).
O modelo criado utiliza quatro parmetros de configurao, que precisam ser previamente
definidos antes que a simulao seja executada:

Intervalo entre gerao de pacotes (T), em milissegundos, que corresponde ao

perodo do oscilador no transmissor s;

Divisor nominal de freqncia (N), o valor de Nnom que determina a freqncia

central do DCO, configurando o nmero de vezes que o perodo o do oscilador de alta

freqncia superior a s, e conseqentemente o passo disponvel para ajuste do DCO;

Atraso mdio PSN (D), o valor mdio de atraso sofrido pelos pacotes que atravessam a

PSN, utilizado para compensao da diferena entre os contadores do receptor e do

transmissor;

Nmero de seqncia inicial (NS1), o nmero de seqncia do primeiro pacote

recebido, que carregado como valor inicial do contador do receptor.

A simulao do mecanismo de sincronizao desenvolvida no Simulink composta por
trs modelos, indicados na Figura 4.12 atravs de linhas tracejadas e descritos a seguir:

Modelo do transmissor, bastante simples, implementado atravs de um contador, cuja

sada o nmero de seqncia dos pacotes transmitidos, alimentado por um oscilador

cuja freqncia corresponde taxa constante de gerao de pacotes do fluxo TDM;

Modelo da PSN, implementado atravs de um deslocamento negativo do nmero de

seqncia gerado pelo transmissor, correspondente ao atraso mdio sofrido pelos

pacotes dentro da rede de transporte, mais uma componente aleatria de distribuio
normal em torno do atraso mdio e varincia de modo a assegurar que 99% dos atrasos
estaro compreendidos no intervalo [D/2; 3D/2]; com o objetivo de simular o
comportamento varivel do nmero de seqncia dos pacotes que chegam ao receptor;

A125

Modelo do receptor, o PLL em si, implementado atravs da composio dos blocos

que realizam as funes anteriormente descritas para cada um de seus componentes.

Para o filtro EWMA, foram utilizados os coeficientes experimentais apresentados em
[AWEYA2004a], entendidos como os melhores ajustes obtidos para esse filtro pelo
autor na aplicao PLL, sendo tambm buscada uma equivalncia, dentro das
limitaes do Simulink, entre os parmetros de configurao utilizados naquela
implementao e aqueles configurados no modelo, conforme mostrado na Tabela 4.2.
Tabela 4.2 Equivalncia entre parmetros experimentais e os utilizados no PLL Simulink.
Parmetro
Unidade
NS inicial (NS1)
ms
s (T)
fo/fnom (N)
Atraso PSN (D)
ms
Preciso ajuste DCO
ppm
Desvio fDCO max
ppm
Desvio fDCO min
ppm
u(n) para fDCO max
u(n) para fDCO = fnom
u(n) para fDCO min
Freqncia fnom
kHz
Desvio min de fnom
Hz
Desvio min de fnom
Hz
Ganho DCO (Ko)

wanPMC2T3E3
aleatrio
0,000022
20.000.000
100
0,05
125,25
-79,5
0,00444
0,00000
-0,00360
44.736
5.603
-3.557
25.466

Simulink
16000
0,2
1.000
100
1000
111
-90
0,00444
0,00000
-0,00360
5
0,5
-0,4
25

Na implementao em referncia, utilizado um feixe T3, de 44,736 Mbps, sendo

controlada diretamente a freqncia de relgio do fluxo de bits. Na simulao, utilizada a
taxa de gerao dos pacotes e no a freqncia da linha, que de aproximadamente 5000
(4.723) pacotes/s, considerando os dois quadros T3 por pacote, com 592 octetos cada um.
Dessa forma, a fnom utilizada na simulao 5 kHz, considerando um pacote gerado a cada
200us. Considerando um Nnom de 1000, o erro de quantizao para a freqncia inferior a
0,5o, permitindo passos de ajuste de 0,5Hz, suficiente para os objetivos aqui propostos.
Dessa forma, o ganho DCO ajustado para que a sada do filtro de realimentao produza
efeitos similares no desvio de freqncia, assegurando a equivalncia entre os parmetros.

A126

Inicialmente, o modelo Simulink foi validado utilizando as mesmas condies simuladas

no MatLab para o mecanismo de seqenciamento de pacotes, ou seja, considerando a
emulao de um circuito E1, com 1ms de dados TDM por pacote e, portanto, taxa de
gerao de 1000 pacotes/s. Da mesma forma, foi considerado um atraso mdio na PSN de
80ms, admitindo-se a variao desse atraso dentro do intervalo [40ms;120ms], embora
nesse caso usando uma distribuio normal ao invs de uniforme, sendo o resultado obtido
para o erro entre as contagens T(n) e R(n) apresentado na Figura 4.13.

Figura 4.13 Evoluo do erro entre T(n) e R(n) para o filtro EWMA no Simulink.
Para a simulao, foram utilizados os parmetros de equivalncia da Tabela 4.2, sendo
criado um experimento semelhante a um dos testes realizados em [AWEYA2004a], para
avaliao da resposta do PLL flutuao na freqncia do transmissor. Assim, foi gerado
um desvio de 7,5Hz (0,15% ou 15000ppm) na freqncia de 5kHz utilizada para a
montagem de pacotes no transmissor, e monitorado o erro entre T(n) e R(n) durante o
processo de reao do PLL para compensao desse desvio no receptor.

A127

O resultado obtido para o erro entre as contagens T(n) e R(n), utilizando o PLL com filtro
EWMA, para PDV de 15ms no modelo da rede, mostrado na Figura 4.14.

Figura 4.14 Evoluo do erro T(n) - R(n) para o filtro EWMA c/desvio de 7,5Hz.
Pode ser observado na Figura 4.14 que o PLL responde variao intencional da
freqncia no transmissor, percebida como um erro negativo entre as contagens T(n) e
R(n), desacelerando a freqncia no receptor. Contudo, esse efeito forte demais, gerando
um erro positivo crescente que no consegue ser revertido nos 100ms de simulao.
Na Figura 4.15 mostrada a evoluo do sinal na sada do filtro EWMA, utilizado para
controle do DCO, onde pode ser verificada a resposta lenta desse sinal em funo de sua
caracterstica superamortecida. Para que a freqncia do transmissor seja efetivamente
capturada, o sinal de controle deve estar entre +1 e +2, ao invs dos 7,5 indicados ao final
dos primeiros 100ms, o que levar pelo menos mais 150ms, assumindo que no exista nova
ultrapassagem. Com isso, o tempo de captura do PLL projetado em mais de 250ms para
um desvio de 0,15% na freqncia, quando utilizado o filtro EWMA.

A128

Figura 4.15 Sinal de controle para o filtro EWMA c/desvio de 7,5Hz

Uma vez obtido, atravs da simulao, o desempenho do PLL com o filtro EWMA
apresentado em [AWEYA2004a], foi feita a substituio desse filtro pelo controlador PID
proposto nesse trabalho.
Para ajuste inicial dos parmetros utilizados pelo controlador,

KP, TI e TD,

foram

utilizadas as regras empricas definidas pelo mtodo Zieger-Nichols (1942) para sistemas
de controle em malha fechada, determinando atravs da variao de KP, com TI e TD nulos,
o limiar de estabilidade do sistema, caracterizado pelo comportamento oscilatrio do erro
entre as contagens; considerando KO= KP (oscilatrio) , TO o perodo de oscilao e
utilizando a Tabela 4.3.
Tabela 4.3 Regras de Zieger-Nichols em malha fechada para ajuste de controladores PID.
Controlador
P
PI
PID

KP
0,5 KO
0,4 KO
0,6 KO

A129

TI
0,8 TO
0,5 TO

TD
0,12 TO

O modelo Simulink para o PLL com o controlador PID apresentado na Figura 4.16.

Modelo do Transmissor

Modelo da PSN

Modelo do Receptor

Figura 4.16 Implementao do PLL com o controlador PID proposto no Simulink.

Esse modelo utiliza, alm dos mesmos quatro parmetros de configurao do modelo
anterior, os trs parmetros adicionais referentes ao controlador PID, que precisam ser
definidos antes que a simulao seja executada:

Ganho proporcional (Kp), valor correspondente ao ganho da ao proporcional;

Termo integral (Ti), valor que, dividindo o ganho proporcional, pondera a ao

integral do controlador PID;

Termo derivativo (Td), valor que, multiplicando o ganho proporcional, pondera a

ao derivativa do controlador PID.

Aps diversas anlises de desempenho apresentado segundo os critrios definidos na
Tabela 4.3, com ajustes empricos, os parmetros do controlador foram ajustados para:
KP

TI

0,002

TD

0,000001
A130

Dessa forma, foi repetido para esse modelo o experimento anterior, nas mesmas condies.
Os resultado obtido para o erro entre as contagens T(n) e R(n), tambm com PDV de 15ms
no modelo da rede, mostrado na Figura 4.17.

Figura 4.17 Evoluo do erro T(n) - R(n) para o controlador PID c/desvio de 7,5Hz.
Como pode ser observado na Figura 4.17, o erro manteve-se entre 0 e +1 ao longo de
praticamente todo o perodo de simulao, aps a rpida correo do valor 1, em virtude
do receptor estar com a freqncia 7,5Hz mais rpida que o transmissor, permanecendo
nesse intervalo mesmo com a variao aleatria no atraso sofrido pelos pacotes, inerente ao
modelo utilizado para a PSN.
Na Figura 4.18 mostrada a evoluo do sinal na sada do filtro controlador PID, utilizado
para controle do DCO de modo a assegurar a manuteno das diferenas entre as contagens
T(n) e R(n). Como a resoluo utilizada de 5 Hz, pois N=1000, a oscilao entre +1 e +3
para esse sinal de controle pode ser considerada normal em regime permanente, o que
significa um tempo de captura do PLL de cerca de 1ms para um desvio de 0,15% na
freqncia, quando utilizado o controlador PID.

A131

Figura 4.18 Sinal de controle para o controlador PID c/desvio de 7,5Hz.

Comparando os resultados obtidos entre as duas implementaes PLL, atravs das Figuras
4.14 e 4.17, que apresentam a evoluo do erro entre as contagens T(n) e R(n), tomada na
mesma escala, verificado um desempenho bastante superior do controlador PID na
simulao.

4.2 - EXPERIMENTAO TDMoIP NA REDE LABCOM/UnB

Aps o estudo realizado para compreenso das caractersticas, pontos fortes e limitaes da
emulao de circuitos TDM sobre redes comutadas em modo pacotes, propondo novos
mecanismos para tratamento das questes-chave envolvidas e validando esses mecanismos
atravs de simulao, foram buscadas formas de experimentao da tecnologia PWE3 e dos
novos algoritmos propostos, a fim de assegurar a sua validade sob condies reais de
operao nas redes existentes. Para isso, foi concebido um ambiente experimental, cujo
modelo conceitual apresentado na Figura 4.19.

A132

Ajuste de parmetros da Rede:

Largura de banda
Atraso
QoS
Gerador de
Trfego
concorrente

Gerador de
Trfego TDM
sobre pacotes

Receptor de
Trfego TDM
sobre pacotes

Rede IP sobre Ethernet

Medio de desempenho
Taxa Efetiva
Perda de Pacotes
Atraso

Receptor de
Trfego
concorrente

Figura 4.19 Modelo conceitual do ambiente experimental.

Nesse modelo conceitual, utilizada uma rede IP, construda sobre Ethernet, na qual seja
possvel, de alguma forma, controlar os parmetros associados ao transporte dos pacotes,
como a largura de banda oferecida, o atraso sofrido e, eventualmente, mecanismos de QoS.
Alm disso, devem existir formas de monitorar o desempenho da rede, atravs da medio
da taxa efetiva oferecida aos fluxos, da contagem da perda de pacotes e da determinao
dos parmetros de atraso, como sua mdia e variao (PDV).
Para a gerao do fluxo TDM sobre IP de interesse, utilizado um gerador e um
transmissor de pacotes, construdos de acordo com as especificaes PWE3, de forma a
caracterizar uma aplicao real de transporte. Finalmente, deve haver condies de
perturbar esses fluxos TDM sobre IP, atravs da gerao e recepo, controlvel, de trfego
concorrente para competir com os mesmos pelos recursos limitados da rede IP, como a
banda disponvel e as filas nos roteadores, gerando situaes de congestionamento.
4.2.1 Definio da topologia e configurao da rede LabCom

O prximo passo para transformar esse modelo conceitual em realidade, criando uma
plataforma de testes para a tecnologia PWE3, foi construir esse ambiente experimental a
partir do ambiente de teste e medio para redes convergentes criado no LabCom/UnB

A133

[ABDALA2005], adaptando-o segundo as necessidades desse trabalho. A topologia

completa da plataforma de testes desenvolvida apresentada na Figura 4.20.

172.1.16.45

Rede
ENE

Eth2
10.0.6.2

164.41.46.0

Eth0
10.0.7.2

WLAN
LabCom

172.1.16.0

Eth1
10.0.8.2

10.0.5.0

Gateway
IPmux-11
172.1.20.100

LSR02

Eth2
172.1.20.1

Hdlc0
10.0.5.3

LER03

172.1.20.0

10.0.6.0

Eth0
10.0.6.3

172.1.20.45

172.1.20.55

Mux-IP PC

E1

Eth0
10.0.7.1

Eth1
172.24.1.1

LER01

Eth1
10.0.10.3

10.0.10.0

Analisador

10.0.7.0

10.0.9.0

Eth0
10.0.8.4
Eth2
10.0.10.4

LSR04

Rota 0 (Sada)

Eth1
Eth4 172.24.1.111
1
10.0.9.1

172.24.1.0

LAN LabCom
Switch
3716XL

172.24.1.100

E1

Analisador
Eth1
10.0.9.4

Gateway
IPmux-11

172.24.1.45

172.24.1.2
172.24.1.178

Mux-IP PC

JU 00080000

Rota 1024 (Entrada)

JU 00070000

5582-1000
NEA 00210000

Central
Trpico-RA

5582-1030

NEA 00210114

Figura 4.20 - Topologia da plataforma de testes PWE3.

Como rede IP, foi utilizado o ncleo MPLS existente, formado por quatro
microcomputadores com funo de roteadores, utilizando o deamon Zebra com roteamento
OSPF (Open Shortest Path First) sobre sistema operacional Linux, distribuio Mandrake
9.1 (Bamboo) e kernel 2.4.21-0.13, conectados atravs de mltiplas interfaces Ethernet.
Em princpio, as nicas alteraes feitas em sua configurao original foram a restrio
forada das velocidades das interfaces taxa de 10Mbps, e o controle das taxas efetivas em
cada um dos enlaces atravs da introduo de disciplina de filas (comandos tc qdisc) para
as respectivas interfaces, limitando a taxa de transmisso atravs de um token bucket.
Como localizao para os PEs de origem e destino, foi utilizada a rede LAN j existente no
LabCom, 172.24.1.0, qual j era conectada a respectiva WLAN, 172.1.16.0, em uma das
extremidades do ncleo; e criada uma nova rede, 172.1.20.0, na outra extremidade, onde
originalmente existia o enlace de rdio digital 2Mbps com a rede do Departamento de
Engenharia Eltrica (ENE), no prdio da Faculdade de Tecnologia (FT) da UnB, distante
cerca de 200m das instalaes do LabCom, no segundo piso do prdio SG-11.

A134

A essas duas redes foram conectados diversos equipamentos, utilizados para gerar e
receber os fluxos de pacotes contendo dados TDM e o trfego concorrente, como
microcomputadores, notebooks e o par de gateways IPmux-11, fornecidos pela RAD do
Brasil como demonstrao para a realizao do trabalho.
Na gerao do trfego TDM nativo para esses gateways IPmux-11, foi utilizada a central
Trpico-RA, de fabricao Alcatel, instalada no LabCom , atravs de um feixe E1 da rota
de entroncamento com a central Sistema-12 tambm existente na rede LabCom.
Para a gerao do trfego concorrente, foi utilizada a ferramenta Analisador,
desenvolvida no LabCom/UnB para anlise de redes IP [BEZERRA2004], que apresenta
facilidades para a configurao e agendamento de diversos tipos de trfego.

A tela

principal dessa ferramenta, com alguns trfegos configurados, apresentada na Figura

4.21.

Figura 4.21 Tela principal da ferramenta Analisador, do LabCom/UnB.

A135

Finalmente, para monitorao do desempenho da rede, foi utilizada a ferramenta tcpdump,

disponvel nos roteadores Linux, para captura dos pacotes de cada um dos fluxos e medio
dos respectivos instantes de recebimento, alm da contagem de pacotes perdidos
diretamente pelas aplicaes nos microcomputadores e nos gateways IPmux-11 .
4.2.2 Estudo e configurao dos equipamentos RAD IPmux-11

Assim que os gateways IPmux-11 enviados pela RAD do Brasil chegaram ao LabCom, foi
realizado um estudo de seus manuais, a fim de entender seus procedimentos de instalao e
configurao. Um dos gateways utilizados mostrado na Figura 4.22.

Figura 4.22 - Gateway IPmux-11 da RAD utilizado nos testes.

A instalao dos mesmos foi simples, pois podem ser alimentados em 220V CA,
consistindo exclusivamente na montagem dos conectores utilizados nos cabos coaxiais
instalados na central, ativada semanas antes, no padro G.703. Esses cabos so conectados
ao gateway atravs de um adaptador, fornecido com o mesmo, que converte os dois
conectores coaxiais, de transmisso e recepo, num nico conector RJ-45, como utilizado
nos cabos UTP. A conexo do respectivo cabo ethernet concluiu o processo de instalao,
sendo que o IPmux-11 possui uma bridge interna com duas portas ethernet adicionais,

A136

utilizadas para conectar os microcomputadores na rede 172.1.20.0, evitando a necessidade

de outros equipamentos.
A configurao tambm foi bastante simples, pois os IPmux-11 possuem uma interface
serial RS-232C, para conexo a terminais VT100, atravs da qual feito o acesso inicial
sua configurao, conforme tela apresentada na Figura 4.23.

Figura 4.23 Tela de configurao bsica do gateway IPmux-11 utilizado nos testes.
A configurao inicial realizada atravs da seqncia 1.System e 1.Host IP. Uma vez
configurados seus endereos IP, 172.24.1.100 e 172.1.20.100 respectivamente, as mscaras
de subrede e os respectivos roteadores, os gateways podem ser acessados atravs de
TELNET, via terminal, ou HTTP, via qualquer navegador, com acesso integral a todas as
suas facilidades. Assim, a configurao bsica foi concluda com a atualizao dos relgios
internos, que foram sincronizados manualmente no mesmo segundo atravs da seqncia
1.System e 4.Date/Time.
A prxima etapa foi a configurao fsica do fluxo TDM em cada gateway, utilizando a
seqncia 2.Configuration, 3.Physical Layer e 1.TDM configuration, sendo definido:

A137

Configuration>Physical layer>TDM configuration (E1)

Channel ID
(1)
Restoration time
(CCITT)
Signaling mode
(CAS disabled)
1.Admin status:
2.Transmit clock source
3.Rx sensitivity
4.Line type
5.Idle code[0 - ff]
6.Send upon fail
7.OOS code[0 - ff]

(Enable)
(Adaptive) ou (Loopback)
(Short haul)
(Framed G.704 CRC)
(7E)
(AIS)
(FF)

Como tipo de linha foi definido o sinal TDM utilizado pela rota da Trpico-RA, G.704
com uso de CRC, estruturado com canalizao e CRC: (Framed G.704 CRC).
Em relao ao relgio de transmisso, o gateway localizado na rede 172.1.20.0, fisicamente
mais prximo da central e recebendo dados da rota de sada, foi configurado para
recuperao do relgio a partir do fluxo TDM recebido da central (Loopback), enquanto o
gateway localizado na rede 172.24.1.0 foi configurado para recuperao de relgio
adaptativa (Adaptive) utilizando o fluxo de pacotes recebido, estabelecendo o esquema
indicado na Figura 2.12c, apresentada na seo 2.3.1.
Na seqncia, foi realizada a configurao da conexo ethernet, utilizando a seqncia
2.Configuration, 3.Physical Layer e 2.Eth configuration, sendo definida a velocidade de
10Mbps, full-duplex:
Configuration>Physical layer>Eth configuration
Channel
(Network-Eth1)
1. Channel state
2. Auto negotiation
3. Max capability advertised
4. Default type

(Enable)
(Enable)
(10baseT full duplex)
(10baseT half duplex)

Finalmente, foi realizada a configurao da conexo TDMoIP propriamente dita,

utilizando a seqncia 2.Configuration, 3.Connection e 2.DS0Bundle, para definir os
canais a transmitir; e 2.Configuration, 3.Connection e 3.Bundle connection, para definir os
parmetros de emulao do enlace, conforme estabelecido na Tabela 4.4:

A138

Tabela 4.4 Configurao de parmetros para os gateways IPmux-11.

Parmetro

Endereo IP
Sinalizao
Relgio
Adaptao dos dados
Nmero de canais
Tamanho do buffer

IPmux-11
(local)

IPmux-11
(remoto)

172.24.1.100

172.1.20.100

G.704 CRC
adaptativo
AAL1
31
50ms

G.704 CRC
loopback
AAL1
31
50ms

Configuration>Connection>Bundle connection
1. Destination IP address
(172.1.20.100) ou (172.24.1.100)
2. Next hop
(172.24.1.111) ou (172.1.20.1)
3. IP TOS[0 - 255]
(0)
4. Connection status
(Enable)
5. Destination bundle[1 - 8063]
(1)
6. TDM bytes in frame(x48 bytes)[1 - 30] (5)
7. Payload format
(V1)
8. OAM connectivity
(Disable)
9. Jitter buffer [msec][3 - 300]
(50)
10. VLAN tagging
(Disable)
Assim, foi concludo o processo de configurao, ativando a conexo TDMoIP assim que
os parmetros foram salvos. Dessa forma, foi criado um pseudo-circuito TDM, interligando
com sucesso as rotas de entrada (1024) e sada (0) da central Trpico-RA atravs da rede IP
do LabCom, que passou a ser monitorado, em relao aos sinais TDM,
seqncia 3.Monitoring, 1.Statistics e 1.TDM physical layer, apresentando:
Monitoring>Statistics>TDM physical layer (E1)
Channel ID
LOS:
LOF (Red):
LCV:
RAI (Yellow):
AIS:
FEBE:
BES:
Time start:
1. Interval

(1)
(0)
(0)
(0)
(0)
(0)
(0)
(0)

DM:
ES:
SES:
UAS:
LOMF:

(21:30:00 2006-09-09)
... (1)

A139

(0)
(0)
(0)
(0)
(0)

atravs da

Em relao conexo TDMoIP , a monitorao feita atravs da seqncia 3.Monitoring,

1.Statistics e 2.Connection, apresentando:
Monitoring>Statistics>Connection
Sequence errors:
Jitter buffer underflows:
Jitter buffer overflows:
Max Jitter buffer deviation [msec]:
Time since [sec]:
1. Bundle ID[1 - 1]
2. Interval

(0)
(0)
(0)
(4)
(487)
(1)
(0)

Em ambos os casos, a monitorao feita dentro de uma janela (Interval) de 15 minutos

(900s), por at 24h, totalizando 96 janelas que ficam armazenadas no gateway.
Para efeito de monitoramento, existe ainda mais uma opo, atravs da seqncia Em
relao conexo TDMoIP , a monitorao feita atravs da seqncia 3.Monitoring,
2.Status e 2.Connection, que permite a verificao do estado da conexo, apresentando:
Monitoring>Status>Connection
Destination IP address: (172.1.20.100)
Next hop MAC address: (00E07DF5A8EE)
Connectivity status: > (OK
)
Sequence errors:
(0)
Jitter buffer underflows: (0)
Jitter buffer overflows:
(0)
1. Bundle ID[1 - 1]
(1)
E, finalmente, o arquivo de registro de eventos (event log), acessado atravs da seqncia
3.Monitoring, 3.Event log e 2.Read log file, conforme mostrado na Tabela 4.5.
Tabela 4.5 Registro de eventos do IPmux-11, acesso HTTP.
Index Log entry
56

2006-09-09 19:52:15 LOGIN VIA TELNET

55

2006-09-08 20:38:03 SN ERRORS TDM SLOT BUNDLE 1 1 EVENTS

54

2006-09-08 20:38:02 SN ERRORS TDM SLOT BUNDLE 1 5 EVENTS

53

2006-09-08 20:37:57 SN ERRORS TDM SLOT BUNDLE 1 7 EVENTS

52

2006-09-08 20:37:23 SN ERRORS TDM SLOT BUNDLE 1 9 EVENTS

A140

Em seguida, foram feitos testes de conversao atravs dos dois telefones analgicos
instalados na central, no sendo percebida qualquer diferena de qualidade entre as
chamadas transportadas pelo enlace TDM nativo, com conexo direta do juntor de sada ao
juntor de entrada pelo cabo coaxial; e as transportadas atravs do enlace TDMoIP.
4.2.3 Estudo e configurao da central Trpico-RA

A ativao da central Trpico-RA do LabCom/UnB foi a fase mais difcil da montagem do

ambiente experimental, pois a mesma no era utilizada desde 2004 e apresentava
problemas no sistema configurado de acesso TELNET atravs do concentrador Cyclades.
Assim, foi necessrio o acesso direto via interface RS-232C ao processador 2, de O&M.
Resolvido o problema de acesso, a central tambm no respondeu s rotinas normais de
inicializao, apresentando vrios processadores que no carregavam, os quais tiveram que
ser levantados individualmente, obrigando a um estudo relativamente profundo da
documentao

disponvel

[PROMOM1999]

[PROMOM1999a]

[PROMOM1999b]

[PROMOM1999c] [ALCATEL2002] [ALCATEL2002a] [ITS2002] [ITS2002a]. No caso

do processador 21, responsvel pelo gerenciamento do mdulo de assinantes, houve
necessidade de substituio da placa processadora por uma sobressalente, e alguns mdulos
no estavam operacionais, como a sinalizao SS7, mas foi possvel utilizar os assinantes e
os juntores de entrada e sada, condio suficiente para os objetivos do trabalho.
Como problema adicional, o sistema de baterias mostrou-se inoperante, fazendo com que a
central perdesse a alimentao quando das quedas de energia no prdio SG-11, obrigando a
sua reativao, felizmente agora bem mais simples, por diversas vezes ao longo dos cerca
de 45 dias de teste.
Nessa central Trpico-RA, foram instalados telefones em dois assinantes analgicos que j
estavam previamente criados, utilizando os NEAs 00210000 e 00210114, ou seja,
processador 21, placa 0, posio 0, para o assinante 5582-1000; e processador 21, placa 1,
posio 14, para o assinante 5582-1030.

A141

A Figura 4.24 mostra a central Trpico-RA do LabCom/UnB, ativada, com os trs

bastidores abertos.

Figura 4.24 Central Trpico-RA utilizada nos testes para gerao de feixe E1.
Aps realizar diversos testes com esses assinantes, utilizando diretamente a comutao
local, foi configurado um plano de encaminhamento alternativo, usando o plano #1
(Reserva) armazenado, que direcionava para a rota de sada 0, localizada fisicamente no
juntor 00080000, processador 8, placa 0, enlace 0; as chamadas cuja marcao fosse
iniciada com o dgito 1. Da mesma forma, foi reconfigurada a rota de entrada 1024,
localizada fisicamente no juntor 0007000, processador 7, placa 0, enlace 0, de forma que os
dgitos recebidos atravs da mesma fossem considerados como rota rpida para os
terminais da prpria central.
Assim, atravs dos cabos coaxiais, foi ligado o sinal Tx do enlace E1 do juntor 00080000
no sinal Rx do enlace E1 do juntor 00070000, e vice-versa, de modo que as rotas 0 e 1024
fossem externamente interligadas, no mais atravs da central Sistema-12, mas
diretamente. Os demais enlaces dos mesmos juntores permaneceram como estavam, em
loopback.

A142

Dessa forma, quando do terminal 5582-1000 era teclado 11030, a chamada era
encaminhada rota 0 de sada, sendo recebida pela rota 1024 de entrada e reencaminhada
ao assinante 5582-1030, fazendo com que a conversao fosse conduzida atravs do enlace
E1. Quando uma chamada para o destino 11000 era originada do terminal 5582-1030,
ocorria exatamente o inverso.
Mais tarde, quando foram ativados os gateways IPmux-11, os cabos Tx e Rx do juntor
00080000 foram conectados ao gateway remoto e os cabos do juntor 0007000 ao gateway
local, fazendo com que o entroncamento fosse realizado atravs do ncleo MPLS,
utilizando a emulao do circuito TDM E1 atravs de TDMoIP.
4.2.4 Ensaios de desempenho TDMoIP

Concluda a fase de configurao dos terminais, assegurando que os fluxos TDM gerados
pela central eram recebidos pelos gateways IPmux-11, encapsulados em pacotes e
encaminhados atravs das respectivas interfaces Ethernet aos roteadores de borda (LER) do
ncleo, foi realizada a configurao desse ncleo, de forma a permitir a realizao dos
ensaios de desempenho.
Como o objetivo desse trabalho a utilizao de PWE3 em PSN onde existe garantia de
banda, mas no QoS, as disciplinas de fila para implementao de MPLS no foram
utilizadas; contudo, a fim de aumentar o nmero de saltos dentro do caminho percorrido
pelos pacotes dentro do ncleo, aumentando sua sensibilidade aos parmetros da rede,
foram fixados limites muito estreitos para o trfego em rajadas no token bucket configurado
para as interfaces eth0 do LSR02 e eth2 do LSR04, que assim provocaram, pela atuao do
OSPF, mudanas nas tabelas de roteamento, modificando a rota original entre as redes
172.24.1.0 e 172.1.20.0 atravs do ncleo, como mostrado na Figura 4.25:

Roteamento Original OSPF:

LER03->LSR02->LER01->172.24.1.100 (3 saltos);

Novo Roteamento OSPF:

LER03->LSR02->LSR04->LER01->172.24.1.100 (4 saltos).

A143

172.1.16.45

Rede
ENE
164.41.46.0

Eth0
10.0.7.2

WLAN
LabCom

172.1.16.0

Eth1
10.0.8.2

10.0.5.0

Gateway
IPmux-11
172.1.20.100

LSR02

Eth2
10.0.6.2

Eth2
172.1.20.1

Hdlc0
10.0.5.3

LER03

172.1.20.0

10.0.6.0

Eth0
10.0.6.3

172.1.20.45

172.1.20.55

Mux-IP PC

E1

Eth0
10.0.7.1

Eth1
172.24.1.1

LER01

Eth1
10.0.10.3

10.0.10.0

Analisador

10.0.7.0

10.0.9.0

Eth0
10.0.8.4
Eth2
10.0.10.4

LSR04

Eth1
Eth4 172.24.1.111
1
10.0.9.1

172.24.1.0

LAN LabCom
Switch
3716XL

172.24.1.100

E1

Analisador
Eth1
10.0.9.4

Rota 0 (Sada)

Gateway
IPmux-11

172.24.1.45

172.24.1.2
172.24.1.178

Mux-IP PC

JU 00080000

Rota 1024 (Entrada)

JU 00070000

5582-1000
NEA 00210000

Central
Trpico-RA

5582-1030

NEA 00210114

Figura 4.25 Caminho utilizado pelos pacotes no pseudo-circuito TDM.

Depois de configurado o ambiente experimental em todos os seus aspectos, foram
definidas as caractersticas para o trfego concorrente gerado pelo Analisador, buscando
representar, da melhor forma possvel, as condies que seriam encontradas, guardadas as
devidas propores, em uma rede IP real.
Assim, foi definido um padro de trfego na ferramenta Analisador, utilizando o tipo autosimilar gaussiano, na configurao bsica, com taxa de 500 pacotes/s parmetro de hurst de
0,85, o que assegura boa representatividade para o fluxo concorrente de pacotes. Maiores
detalhes sobre as caractersticas do trfego auto-similar gaussiano podem ser encontrados
em [BARRETO2005].
A banda efetivamente ocupada pelo trfego concorrente foi controlada pela variao no
tamanho do pacote, permitida pela ferramenta Analisador, sendo utilizada uma distribuio
normal para esse tamanho, com mdia configurvel e varincia calculada de tal forma que
a disperso fosse de 30% da mdia em 95% dos casos.
Dessa forma, o trfego concorrente gerado obedeceu, em todos os ensaios realizados, ao
regime de variao apresentado na Tabela 4.6, de maneira a garantir um carregamento

A144

progressivo dos enlaces, at a ocupao total da banda disponvel. Para alguns ensaios, foi
feito tambm um descarregamento progressivo, obedecendo regra inversa.
Tabela 4.6 Regime de gerao do trfego concorrente.
Distribuio do
Tamanho dos Pacotes
- Mdia (octetos)
- Varincia
Tamanho Mnimo (95%)
Tamanho Mximo (95%)
Taxa na PSN (bps)
Ocupao do Enlace 4Mbps

Normal
256
655,36
179,2
332,8
1.024.000
25%

Normal
512
2.621,44
358,4
665,6
2.048.000
50%

Normal
768
5.898,24
537,6
998,4
3.072.000
75%

Normal
1024
10.485,76
716,8
1.331,2
4.096.000
100%

Definidas todas as caractersticas para a rede, o fluxo TDM e o trfego concorrente, foram
realizados algumas medies, buscando determinar a estabilidade do pseudo-circuito e a
sua sensibilidade ocupao da rede, bem como o efeito da quantidade de PDUs AAL1
utilizadas em cada pacote, ou seja, do tamanho do pacote contendo dados TDM, nesse
desempenho, conforme abordado em [PILATI2004], a fim de tecer algumas comparaes.
a) Ensaio de desempenho em 24h, considerando a largura de banda varivel:
Nesse ensaio, foram configurados ciclos de 2 horas para cada uma das condies de trfego
concorrente, carregando e descarregando a rede, com intervalo de 30 minutos entre cada
uma delas, a fim de assegurar que houvesse pelo menos uma janela de medio de 15
minutos, pelos IPmux-11, sem a presena desse trfego. O tamanho dos pacotes foi fixado
em 5 PDUs (240 octetos AAL1) e as medies foram realizadas para taxas nominais nos
enlaces de 4Mbps, 6Mbps, 8Mbps e 10Mbps.
Em cada cenrio, foram monitoradas as perdas de pacotes, a quantidade de underflows e
overflows e ocupao mxima do buffer dentro de cada janela de 15 minutos.
As Figuras 4.26, 4.27, 4.28 e 4.29 apresentam, respectivamente, o desempenho observado
ao longo das 24h de teste para cada uma dessas variveis, para enlaces de 4Mbps, 6Mbps,
8Mbps e 10Mbps. Nessas figuras indicado o intervalo de gerao do trfego de
perturbao e a qualidade do enlace TDM percebida pela central Trpico-RA.

A145

1000

Intervalo
(ms)

Ensaio de 24h: 5 PDUs e 4 Mbps

Quantidade
Degradado

Enlace Inaceitvel

50

30

500

25

400

20

300

15

Perdas Pacotes

Underflow

Overflow

10

5
12

15

18

21

24

27

30

33

36

39

42

45

48

51

54

57

60

63

66

69

72

75

78

81

87

90

93

96

100

84

200

1Mbps

600

2Mbps

35

3Mbps

700

4Mbps

40

3Mbps

800

2Mbps

45

1Mbps

900

Desvio Buffer (ms)

Figura 4.26 Desempenho de um pseudo-circuito E1 para enlaces de 4Mbps

Enlace

1000

Intervalo
(ms)

Ensaio de 24h: 5 PDUs e 6 Mbps

Quantidade

Enlace Inaceitvel

Degradado

50

25

400
300

20
15

200

1Mbps

500

2Mbps

35
30

3Mbps

700
600

4Mbps

40

3Mbps

800

2Mbps

45

1Mbps

900

10

Perdas Pacotes

Underflow

Overflow

12

16

20

24

28

32

36

40

44

48

52

56

60

64

68

72

76

80

84

88

92

5
96

100

Desvio Buffer (ms)

Figura 4.27 Desempenho de um pseudo-circuito E1 para enlaces de 6Mbps

A146

Intervalo
(ms)

Ensaio de 24h: 5 PDUs e 8 Mbps

Quantidade
Enlace Degradado

Enlace Inaceitvel

Degradado

700

50

600

45
40

500

35

400

30

Perdas Pacotes

Underflow

1Mbps

10
5
0

12

16

2Mbps

20

24

28

32

3Mbps

Overflow

36

40

44

48

52

56

60

64

68

72

76

80

84

88

92

96

100

4Mbps

15

3Mbps

200

2Mbps

25
20
1Mbps

300

Desvio Buffer (ms)

Figura 4.28 Desempenho de um pseudo-circuito E1 para enlaces de 8Mbps

Intervalo
(ms)

Ensaio de 24h: 5 PDUs e 10 Mbps

Quantidade

Enlace Degradado

300

50
45

250

40

200

35

150

25

30
20
1Mbps

2Mbps

3Mbps

4Mbps

15
10

Perdas Pacotes

Underflow

Overflow

12

16

20

24

28

32

36

40

44

48

52

56

60

64

68

72

76

80

84

88

92

5
96

3Mbps

50

2Mbps

1Mbps

100

Desvio Buffer (ms)

Figura 4.29 Desempenho de um pseudo-circuito E1 para enlaces de 10Mbps

A qualidade do enlace PCM medida pela Trpico-RA obtida atravs da monitorao de
seu arquivo de alarmes aps a realizao dos testes, conforme apresentado na Tabela 4.7.

A147

Tabela 4.7 Condies de alarme para enlaces PCM na Trpico-RA .

Alarme

Situao
Enlace PCM com taxa de escorregamento na
GSINC_00
condio degradada
Enlace PCM com taxa de escorregamento na
GSINC_01
condio inaceitvel

Condio
> 5 escorregamentos
em 24 horas
>30 escorregamentos
em 1 hora

Prioridade
No Urgente
Semi-Urgente

Cabe salientar que as condies de monitorao da central utilizam intervalos demasiado

elsticos, se comparados aos intervalos de medio considerados nos ensaios, sendo apenas
uma referncia durante os testes. Para uma anlise efetiva da qualidade dos enlaces PCM
nesse tipo de teste seria necessrio utilizar um analisador de protocolo, a fim de medir com
preciso os escorregamentos e o jitter presente no fluxo TDM de sada do gateway remoto.
b) Ensaio de desempenho considerando a quantidade de PDUs varivel:
Nesse ensaio, foram configurados ciclos de 1 minuto para cada uma das condies de
trfego concorrente, com intervalo de pelo menos 15 minutos entre cada uma delas, a fim
de assegurar que os efeitos de cada condio de ocupao fossem restritos a uma nica
janela. A taxa nominal nos enlaces foi fixada em 4Mbps e as medies foram realizadas
para tamanhos de pacotes com 1 PDU (48 octetos), 5 PDUs (240 octetos), 15 PDUs (720
octetos) e 30 PDUs (1440 octetos).
Em cada cenrio, foram monitoradas as perdas de pacotes, a quantidade de underflows e
overflows e ocupao mxima do buffer dentro de cada janela de 15 minutos.
As Figuras 4.30, 4.31, 4.32 e 4.33 apresentam, respectivamente, o desempenho observado
para cada uma dessas variveis, considerando pacotes de 1, 5, 15, e 30 PDUs. Nessas
figuras tambm indicado o intervalo de gerao do trfego de perturbao e a qualidade
do enlace TDM percebida pela central Trpico-RA.

A148

Intervalo
(ms)

Ensaio 1h: 1 PDU e 4 Mbps

Quantidade
Enlace Degradado

Enlace Inaceitvel

120

50
45
40
35
30
25
20
15
10
5
0

100
80
60

50

49

48

47

Perdas Pacotes

46

45

Underflow

4Mbps

51

3Mbps

2Mbps

20

1Mbps

40

44

43

Overflow

42

43

42

41

40

Desvio Buffer (ms)

Figura 4.30 Desempenho de um pseudo-circuito E1 para 48 octetos por pacote.

Intervalo
(ms)

Ensaio 1h: 5 PDUs e 4 Mbps

Quantidade

Enlace Degradado

Enlace Inaceitvel

600
500
400
300

4Mbps

13

3Mbps

2Mbps

100

1Mbps

200

12

11

10

Perdas Pacotes

Underflow

Overflow

50
45
40
35
30
25
20
15
10
5
0

Desvio Buffer (ms)

Figura 4.31 Desempenho de um pseudo-circuito E1 para 240 octetos por pacote.

A149

Quantidade

Intervalo
(ms)

Ensaio 1h: 15 PDUs e 4 Mbps

Enlace Inaceitvel

70
60
50
40

4Mbps

4Mbps

1Mbps

2Mbps

3Mbps

3Mbps

10

2Mbps

20

1Mbps

30

10

Perdas Pacotes

Underflow

Overflow

50
45
40
35
30
25
20
15
10
5
0

Desvio Buffer (ms)

Figura 4.32 Desempenho de um pseudo-circuito E1 para 720 octetos por pacote.

Quantidade

Intervalo
(ms)

Ensaio 1h: 30 PDUs e 4 Mbps

Enlace Inaceitvel

Enlace Degradado

Inaceitvel

350
300
250
200

Perdas Pacotes

4Mbps

3Mbps

50

2Mbps

100

1Mbps

150

Underflow

Overflow

50
45
40
35
30
25
20
15
10
5
0

Desvio Buffer (ms)

Figura 4.33 Desempenho de um pseudo-circuito E1 para 1440 octetos por pacote.

A150

Alm dos ensaios monitorados, o enlace ficou quase o tempo inteiro ativo durante 45 dias,
at que a central fosse desligada em funo da elevada temperatura do laboratrio, devido
falha nos sistemas de ar condicionado. Nesse perodo, salvo quando os enlaces foram
sobrecarregados pelos testes, o desempenho dos gateways IPmux-11 foi excelente, com
baixssima perda de pacotes e sem indicao de escorregamento degradado ou inaceitvel
pela central Trpico-RA, ficando as falhas limitadas s quedas de energia.
Quando a central foi desativada, os enlaces permaneceram ativos, tendo sido modificada a
configurao de relgio do gateway remoto, de loopback para interno e ligados os
terminais Tx e Rx de cada IPmux-11 atravs de um cabo coaxial. Nessa condio, que foi
utilizada nos ensaios com a aplicao em Java, foram registrados 11 dias de funcionamento
ininterrupto, no sendo registrada nenhuma perda de pacotes no gateway remoto.

4.3 - IMPLEMENTAO TDMOIP EM JAVA

Com o objetivo de comprovar o desempenho dos algoritmos propostos, e em funo da

incerteza inicial da possibilidade de testes com equipamentos comerciais para validao da
tecnologia, foi iniciado em 2005 um projeto envolvendo alunos de graduao do Curso de
Engenharia de Redes da UnB, vinculados ao LEMOM (Laboratrio de Estruturas de
Microondas e Ondas Milimtricas), com o objetivo de desenvolver uma aplicao TDM
sobre IP, a ser utilizada na obteno dos resultados experimentais desse trabalho. Essa
aplicao seria o trabalho de concluso do curso desses alunos.
4.3.1 Desenvolvimento das ferramentas de transmisso e recepo

Dentro das premissas de desenvolvimento da aplicao de emulao TDM sobre IP, foi
adotado o nome Mux-IP PC, tendo sido escolhida a linguagem Java em funo de outros
projetos existentes no LEMOM e do interesse dos alunos no aprendizado da linguagem.
Durante o projeto, foram concebidas duas aplicaes. Uma delas responsvel pela
gerao de pacotes conforme definido pelos Internet-Drafts, sendo adotada a abordagem
SAToP por simplicidade, uma vez que a proposta de utilizao dos pseudo-circuitos para
A151

broadcasting IPTV no implica na manipulao isolada dos canais de voz. E a outra

responsvel pela recepo desses pacotes, onde foi implementado o novo mecanismo
proposto para seqenciamento. A especificao original dessas duas aplicaes descrita
pelo diagrama de blocos funcionais apresentado na Figura 4.34.

Aplicao de
Transmisso

Aplicao de
Recepo

Arquivo

CODEC
G.711
Arquivo
MIC

Montagem de
Pacotes
SAToP

NSRECEBIDO

PLL

Configurao
do Tamanho

Reproduo
dos Dados

NSPRESUMIDO
NSBUFFER

Gerao
NS (16 bits)
Palavra de Controle

Buffer
Transmisso

Encaminhamento
UDP/IP sobre
Ethernet

Relgio de
sada

Seqenciamento
de Pacotes

Buffer
Recepo

Anlise NS

Desmontagem
de Pacotes
SAToP

Rede IP/Ethernet

Recepo
UDP/IP sobre
Ethernet

Figura 4.34 Diagrama de blocos do Mux-IP PC.

Na aplicao de transmisso, a idia original do projeto era que os pacotes fossem
montados a partir de um arquivo de voz ou vdeo, lido pela aplicao utilizando base de
tempo fixa, equivalente a um sinal TDM efetivo. No caso de voz, as amostras de 8 bits, j
codificadas seguindo a lei A da Recomendao ITU-T G.711, seriam acomodadas dentro
de um determinado canal do quadro E1, configurvel pela aplicao. No caso de vdeo, a
transmisso do arquivo ocuparia todo o fluxo de bits, de forma contnua. Em uma segunda
abordagem, seria utilizado o microfone da placa de som instalada no PC para codificao
G.711 (lei A) em tempo real do sinal de voz, a fim de que este fosse acomodado em um
dos canais. Na seqncia a aplicao faz a montagem dos pacotes, utilizando a abordagem
SAToP, permitindo a configurao do seu tamanho entre 1 e 5 quadros E1, ou 1 ms de
dados TSM, correspondentes a 256, 512, 768, 1024 ou 1280 octetos; gerando um nmero
de seqncia de 16 bits, com valor inicial configurvel, que acomodado dentro da palavra
de controle. Uma vez montados, os pacotes so armazenados num buffer de transmisso,
aguardando o envio pela interface ethernet, que realizado por uma classe nativa do Java.
A152

Na aplicao de recepo, os pacotes so obtidos da interface ethernet e entregues ao

processo tambm por uma classe nativa do Java, que realiza a sua desmontagem, retirando
a palavra de controle e dela extraindo o nmero de seqncia, que utilizado pelo
algoritmo de seqenciamento para determinar a posio de escrita no buffer circular autogerencivel de recepo, assegurando assim a seqncia correta dos dados quando forem
retirados pelo processo de leitura do buffer. Da mesma forma nesse caso, a idia original
era que o processo de recuperao do relgio a partir do nmero de seqncia fosse
implementado na aplicao, construindo o PLL em blocos de software, ou mesmo
utilizando algum hardware para facilitar o processo de gerao da freqncia de relgio
para reproduo dos dados de cada pacote no fluxo de sada. Alm disso, estava prevista a
gravao dos dados de udio ou vdeo recebidos em arquivo, para que pudessem ser
comparados com a informao transmitida, evidenciando a eventual perda de qualidade.
No caso dos sinais de voz, estava prevista a utilizao do algoritmo PESQ para avaliao
da qualidade MOS do sinal recebido, utilizando a implementao realizada em
[OBANDO2005]. Finalmente, em uma segunda abordagem, esperava-se poder reproduzir o
contedo de um determinado canal G.711 diretamente na placa de som do PC, permitindo
assim uma experincia de conversao em tempo real, utilizando o circuito E1 emulado, da
mesma forma que foi realizado para os telefones analgicos utilizando o roteamento da
central Trpico-RA.
Contudo, apenas parte dessa especificao original pde ser implementada, uma vez que a
escolha inicial do Java demonstrou-se desastrada para as necessidades desse tipo de
aplicao, onde seriam necessrias bases de tempo precisas e o controle total da mquina,
eventualmente com a incorporao de mdulos de hardware no receptor ou a utilizao de
interrupes. Foram analisadas, pelos alunos envolvidos no projeto, diversas tcnicas para
melhorar a temporizao no Java, incluindo cdigos nativos em C++, sem obter sucesso.
A leitura, manipulao e gravao de arquivos chegou a ser implementada em algumas
verses, mas tornava o processo to lento dentro da mquina virtual Java que comprometia
totalmente as taxas de transmisso, tendo que ser abandonada.

A153

Entretanto, o desempenho do algoritmo de seqenciamento implementado na aplicao,

que independe de bases de tempo precisas, demonstrou-se muito bom, sendo testada,
inclusive, a sua resposta em transmisses atravs da Internet pelos alunos do projeto. A fim
de assegurar, de forma definitiva, a validade desse algoritmo, foram realizados testes
provocando desordenamento intencional dos pacotes pelo prprio transmissor, sendo a
ordem seqencial correta re-estabelecida perfeitamente na sada. A Figura 4.35 apresenta
as duas aplicaes independentes do MUX-IP PC desenvolvido.

Figura 4.35 Telas das aplicaes Mux-IP PC.

Em funo dessas dificuldades com o Java, que implicariam em refazer o desenvolvimento
utilizando outra linguagem que permitisse o domnio mais preciso das bases de tempo,
como o C++, o projeto inicial foi abandonado, mantendo-se a aplicao apenas com as
funcionalidades bsicas, o que limitou a realizao dos ensaios de desempenho.
4.3.2 Ensaios de desempenho TDMoIP

Como a aplicao MUX-IP PC desenvolvida consegue implementar apenas o novo

mecanismo de seqenciamento, foram realizados ensaios para comparao direta do
desempenho das duas aplicaes, fazendo com que ambos os fluxos trafegassem ao mesmo

A154

tempo atravs do ncleo, a fim de determinar qual delas apresenta melhor desempenho na
competio pelos recursos da rede com o trfego concorrente e entre si, conforme mostrado
na Figura 4.36, onde em vermelho com linha pontilhada indicado o fluxo 2Mbps entre os
IPmux-11, em vermelho com linha contnua indicado o trfego entre as aplicaes MuxIP PC e em azul o trfego concorrente gerado pelo Analisador.

Rede
ENE

Eth2
10.0.6.2

164.41.46.0

Eth0
10.0.7.2

WLAN
LabCom

172.1.16.0

Eth1
10.0.8.2

10.0.5.0

Gateway
IPmux-11
172.1.20.100

LSR02

Eth2
172.1.20.1

Hdlc0
10.0.5.3

LER03

172.1.20.0

10.0.6.0

Eth0
10.0.6.3

172.1.20.55

Mux-IP PC
E1

Analisador

Eth0
10.0.7.1

Eth1
172.24.1.1

LER01

Eth1
10.0.10.3

10.0.10.0
172.1.20.45

10.0.7.0

10.0.9.0

Eth1
Eth4 172.24.1.111
1
10.0.9.1

172.24.1.0

LAN LabCom
Switch
3716XL

Gateway
IPmux-11

172.24.1.100

E1

Eth0
10.0.8.4
Eth2
10.0.10.4

LSR04

Eth1
10.0.9.4

172.24.1.2

Analisador 172.24.1.178

Rota 0 (Sada)

Mux-IP PC

JU 00080000

Rota 1024 (Entrada)

JU 00070000

5582-1000
NEA 00210000

Central
Trpico-RA

5582-1030

NEA 00210114

Figura 4.36 Ensaio comparativo entre IPmux-11 e Mux-IP PC.

Como a premissa da emulao de circuitos TDM sobre as redes de pacotes a garantia da
banda, foi definida a taxa nominal nos enlaces de 6Mbps, assegurando 2Mbps de banda
para cada uma das aplicaes, restando mais 2Mbps para o trfego concorrente.
Para o ensaio, foram configurados ciclos de 1 minuto para cada uma das condies de
trfego concorrente, com intervalo de pelo menos 15 minutos entre cada uma delas, a fim
de assegurar que os efeitos de cada condio de ocupao fossem restritos a uma nica
janela do IPmux-11. O tamanho dos pacotes para o Mux-IP PC foi fixado em 1ms (256
octetos), sendo monitoradas apenas as perdas de pacotes, enquanto para os gateways foram
configuradas 30 PDUs (1440 octetos AAL1), e em seguida 5 PDUs (240 octetos AAL1),
sendo monitoradas as perdas de pacotes, a quantidade de underflows e overflows e
ocupao mxima do buffer dentro de cada janela de 15 minutos.

A155

O padro de variao do trfego concorrente foi o apresentado na tabela 4.6. O fluxo entre
os IPmux-11 demandava 2,077 Mbps (176 pacotes/s) para 30 PDUs e 2,308 Mbps (1.058
pacotes/s) para 5 PDUs; e o Mux-IP PC demandava 2,304 Mbps (1.000 pacotes/s). As
Figuras 4.37 e 4.38 apresentam, respectivamente, o desempenho de cada um.

Intervalo
(ms)

IPmux-11 - Ensaio 1h: 30 PDUs, 5 PDUs e 6 Mbps

Quantidade

IPmux-11 2Mbps - 30 PDUs/pacote

80

5 PDUs/pacote

70
60
50
40

1Mbps

2Mbps

3Mbps

4Mbps

4Mbps

10

3Mbps

1Mbps

20

2Mbps

30

Mux-IP PC 2 Mbps

12

11

10

Perdas Pacotes

Underflow

Overflow

50
45
40
35
30
25
20
15
10
5
0

Desvio Buffer (ms)

Figura 4.37 Desempenho IPmux-11 no ensaio comparativo para 6Mbps.

MUX-IP PC - Ensaio 1h: 30 PDUs, 5 PDUs e 6 Mbps

Quantidade

IPmux-11 2Mbps - 30 PDUs/pacote

1.400

5 PDUs/pacote

1.200
1.000
800

1Mbps

2Mbps

3Mbps

4Mbps

4Mbps

200

3Mbps

1Mbps

400

2Mbps

600

Mux-IP PC 2 Mbps

12

11

10

Perdas MuxIP

Figura 4.38 Desempenho Mux-IP PC no ensaio comparativo para 6Mbps.

A156

4.4 -ANLISE DOS RESULTADOS EXPERIMENTAIS

4.4.1 Desempenho do algoritmo de seqenciamento de pacotes

O desempenho comparativo entre o novo algoritmo de seqenciamento proposto neste

trabalho e aquele originalmente apresentado no Internet-Draft [IETF2006], considerando
pacotes efetivamente perdidos e mitigados, de acordo com as condies de simulao
descritas na seo 4.1.2 e sem perda induzida de pacotes, apresentado na Tabela 4.8, para
as quantidades de pacotes e probabilidades de recebimento fora de ordem indicadas, sendo
a melhoria de desempenho comparada entre o novo algoritmo e o IETF com R=40.
Tabela 4.8 Comparao perdas efetivas de pacote nos dois algoritmos simulados.
Simulao
Probabilidade
de Pacotes
Desordenados
Algoritmo
IETF
R=0
Algoritmo
IETF
R=10
Algoritmo
IETF
R=20
Algoritmo
IETF
R=40
Novo
Algoritmo
Proposto
Melhoria de
Desempenho

400 pacotes

1600 pacotes

1%

5%

10%

20%

1%

5%

10%

20%

6
pacotes
1,5%
5
pacotes
1,3%
3
pacotes
0,8%
2
pacotes
0,5%
1
pacote
0,3%

20
pacotes
5,0%
16
pacotes
4,0%
9
pacotes
2,3%
7
pacotes
1,8%
5
pacotes
1,3%

40
pacotes
10,0%
34
pacotes
8,5%
25
pacotes
6,3%
19
pacotes
4,8%
13
pacotes
3,3%

87
pacotes
21,8%
58
pacotes
14,5%
54
pacotes
13,5%
42
pacotes
10,5%
28
pacotes
7,0%

24
pacotes
1,5%
18
pacotes
1,1%
6
pacotes
0,4%
2
pacotes
0,1%
1
pacotes
0,1%

80
pacotes
5,0%
74
pacotes
4,6%
67
pacotes
4,2%
41
pacotes
2,6%
30
pacotes
1,9%

163
pacotes
10,2%
149
pacotes
9,3%
119
pacotes
7,4%
74
pacotes
4,6%
64
pacotes
4,0%

320
pacotes
20,0%
281
pacotes
17,6%
253
pacotes
15,8%
153
pacotes
9,6%
134
pacotes
8,4%

-0,3%

-0,5% -1,5%

-3,5%

-0,1%

-0,7%

-0,6%

-1,2%

A anlise desses dados demonstra que o novo algoritmo de seqenciamento proposto, alm
de ser conceitualmente mais simples, pois no necessita de processos especiais para
gerenciamento do buffer e monitorao dos flags de esgotamento e esvaziamento;
demonstra desempenho bem superior ao apresentado pelo algoritmo sugerido no InternetDraft para R = 0, 10 e 20, permitindo a recuperao transparente de uma quantidade maior
A157

de pacotes, em todas as situaes analisadas, inclusive R=40. Cabe salientar tambm que as
diferenas entre o novo algoritmo e o sugerido no documento IETF so mais significativas
para probabilidades mais elevadas de recebimento fora de ordem, indicando o melhor
desempenho exatamente nas piores condies oferecidas pela PSN.
Dessa forma, o algoritmo desenvolvido pode ser considerado uma tima alternativa de
evoluo para a tecnologia TDMoIP, permitindo sua utilizao em redes PSN com perdas
de pacotes mais elevadas e piores desempenhos em relao ao atraso e, sobretudo,
variao desse atraso (PDV), indo ao encontro dos requisitos de utilizao dessa tecnologia
como alternativa de broadcasting para aplicaes IPTV.
4.4.2 Desempenho do PLL para sincronizao do receptor

O desempenho comparativo entre o PLL com filtro de realimentao EWMA e aquele

utilizando um controlador PID para realimentao do sinal de controle para o DCO
evidenciado pelo comportamento do erro entre as contagens T(n) e R(n), mostrados,
respectivamente nas figuras 4.14 e 4.17, juntamente com o sinal u(n) na sada do
controlador ao longo de toda a simulao, nas Figuras 4.15 e 4.18.
O filtro EWMA apresenta uma caracterstica superamortecida, respondendo lentamente
variao intencional na freqncia do transmissor, como pode ser observado pelo sinal de
controle na Figura 4.15. Dessa forma, mesmo transcorridos 100ms de simulao, o filtro
ainda no conseguiu responder inverso no sentido original do erro pela sua primeira
atuao, tendo continuado a desacelerar o relgio do receptor, chegando a um erro de trs
contagens, e agora levar um tempo muito maior para voltar condio de equilbrio.
Enquanto isso, o PLL, por implementar um sistema subamortecido, respondeu quase
instantaneamente ao erro inicial, desacelerando o relgio do receptor em cerca de 1 ms,
devido componente derivativa. Na seqncia, a componente integral passou a atuar,
impedindo que o relgio desacelerasse demais como no caso anterior, e ficou mantendo o
erro oscilando entre zero e uma contagem, ao longo dos 99 ms seguintes,
independentemente da PDV associada aos pacotes que foram recebidos nesse perodo,
como pode ser observado na Figura 4.18.
A158

Assim, o desempenho do PLL com o controlador PID demonstra-se muito superior

abordagem com o filtro EWMA, para leves desvios na freqncia do transmissor, tendo
feito o ajuste preciso e quase instantneo do desvio intencional provocado.
4.4.3 Desempenho do IPMux-11 na emulao de um enlace TDM

a) Desempenho para largura de banda da rede varivel:

Analisando o entroncamento TDM realizado atravs do pseudo-circuito entre os gateways
IPmux-11, nos ensaios de 24 horas utilizando taxas nominais de 4Mbps, 6Mbps, 8Mbps e
10Mbps nos enlaces do ncleo MPLS, pode ser observado que a qualidade da conexo
bastante sensvel taxa efetivamente disponvel na rede para esse fluxo, lembrando que
para as 5 PDUs consideradas nos ensaios a taxa efetiva de 2,3Mbps.
Observando a Figura 4.26, para 4Mbps nos enlaces, a ocupao do buffer mantm-se
abaixo dos 50ms quando so gerados trfegos concorrentes de 1Mbps e 2Mbps, apesar de
crescer bastante; e a perda de pacotes cresce violentamente quando a concorrncia cresce
de 1Mbps para 2Mbps, embora no cheguem a ocorrer fenmenos de overflow ou
underflow. Contudo, para os trfegos concorrentes de 3Mbps e 4Mbps, onde claramente a
rede no consegue dar vazo a toda a demanda e congestiona, esses fenmenos aparecem
fortemente, com a saturao do buffer e a perda sistemtica de dados. ainda interessante
observar a simetria do grfico, indicando que a o enlace consegue se recuperar aps o
congestionamento, e o fato da condio de escorregamento do enlace PCM j ser
considerada inaceitvel pela central Trpico-RA mesmo para o trfego de 1Mbps.
Observando a Figura 4.27, para 6Mbps nos enlaces, verifica-se que j no ocorre a
saturao do buffer para nenhum trfego, mantendo-se na faixa dos 30 ms; a perda de
pacotes existe para todos os casos e cresce com o congestionamento, mas no ocorrem
fenmenos de overflow ou underflow mesmo quando o trfego chega a 4Mbps. A simetria
do grfico no mantida nesse caso, pois a segunda aplicao dos trfegos de 3Mbps,
2Mbps e 1Mbps no provocam tanta perda de pacotes, provavelmente pela fixao, devido
ao trfego de 4Mbps, do ponto de leitura numa posio avanada, mais prxima de 100%
do buffer. Isso se reflete na condio de escorregamento do enlace PCM percebida pela
central Trpico-RA, que deixa de ser inaceitvel ao final do trfego de 3Mbps.
A159

Observando as Figuras 4.28 e 4.29, para 8Mbps e 10Mbps nos enlaces, respectivamente,
verifica-se que o comportamento bem melhor, tambm no ocorre a saturao do buffer
para nenhum trfego; s existe perda de pacotes para 3Mbps e 4Mbps, no havendo
tambm overflow ou underflow. O grfico volta a ter comportamento simtrico e tudo isso
aparece na condio de escorregamento do enlace PCM percebida pela central Trpico-RA,
que fica inaceitvel apenas para os trfegos de 3Mbps e 4Mbps, para o enlace de 8Mbps,
permanecendo apenas degradada para todos os trfegos com o enlace de 10Mbps.
Assim, confirmada a premissa de que a existncia de banda suficiente para a taxa de
transmisso exigida pelo fluxo TDM nativo condio fundamental para a emulao de
circuitos TDM sobre as redes de pacotes, uma vez que os mecanismos de controle podem
compensar fatores como atraso e PDV, mas a manuteno de um fluxo constante de bits
somente possvel se os pacotes gerados taxa constante encontrarem capacidade de
vazo dentro da rede.
Evidentemente, o desempenho do fluxo de pacotes TDM em relao ao trfego concorrente
gerado seria muito superior se fossem utilizados tneis MPLS no ncleo para sua
priorizao, como usual em VoIP, mas isso foge aos objetivos desse trabalho, por
envolver custos adicionais na rede de transporte.
b) Desempenho para quantidade de PDUs varivel:
Analisando o entroncamento TDM realizado atravs do pseudo-circuito entre os gateways
IPmux-11, em ensaios de 1h com enlaces de 4Mbps, para vrios tamanhos de pacote
(quantidade de PDUs), observa-se um comportamento similar nas Figuras 4.31, 4.32 e
4.33, indicando, como esperado, que a qualidade cai conforme o congestionamento da rede
aumenta, com aumento das perdas de pacote e eventos de overflow e underflow crescentes
com o aumento do trfego concorrente, incluindo a saturao do buffer em 50 ms.
No que tange percepo da qualidade do enlace TDM pela central Trpico-RA, em
princpio o escorregamento considerado inaceitvel quando a perda de pacotes cresce e o
buffer satura, mas essa medio no to confivel como no caso anterior pois o intervalo
de coleta dos dados pela central de uma hora, exatamente o tempo total de cada ensaio.
A160

Contudo, cabe destacar a Figura 4.30, envolvendo pacotes com apenas 1 PDU. Nesse caso,
observa-se uma surpreendente melhoria do comportamento para os trfegos de 3Mbps e
4Mbps, com reduo a quase zero da perda de pacotes e dos eventos de overflow e
underflow, em funo da sada do buffer da condio de saturao nesses casos. Isso
acontece em funo do mecanismo utilizado no ensaio para a gerao do trfego
concorrente, que baseado no aumento da mdia do tamanho do pacote, no caso para 768 e
1024 octetos. Quando esse trfego de pacotes grande colocado para competir pelos
recursos da rede com os pacotes TDM, contendo apenas 48 octetos, a vantagem para este
nas filas dos roteadores evidente, deixando presos no congestionamento os pacotes
concorrentes.
Assim, tambm confirmada a expectativa de que pacotes com dados TDM sobre IP, por
apresentarem, em princpio, tamanhos inferiores aos utilizados pelas aplicaes VoIP,
conseguem melhor desempenho em redes congestionadas e sem garantia de QoS.
Evidentemente, o overhead para transmisso de apenas uma PDU, proibitivo na maioria
das aplicaes com banda restrita.
As concluses obtidas esto coerentes com os resultados apresentados em [PILATI2004],
tomados como referncia para a criao dos cenrios experimentais.
4.4.4 Anlise comparativa entre IPMux-11 e aplicao Java

Numa primeira anlise das Figuras 4.37 e 4.38, pode parecer que o desempenho da
aplicao Java foi muito ruim, uma vez que apresentou perdas superiores a 1.000 e 1.200
pacotes, quando o trfego concorrente foi, respectivamente, de 3Mbps e 4Mbps, enquanto
o gateway IPmux-11 perdeu, diretamente, entre 50 e 65 pacotes na mesma condio.
Contudo, essa anlise simplista no representa a realidade dos problemas dentro do
pseudo-circuito, uma vez que a implementao da RAD est sujeita a processos de
overflow e underflow, que tambm passaram a acontecer quando o carregamento da rede
cresceu, como est indicado na Figura 4.37.

A161

Quando um overflow acontece, diversos pacotes so perdidos, pois no existe mais espao
para seu armazenamento. Alm disso, como descrito na seo 2.3.1, a implementao da
RAD aciona um processo automtico de limpeza do buffer, sempre que esse evento ocorre,
reiniciando o processo de espera para a reproduo do fluxo TDM de sada. Dessa forma,
considerando que o buffer, para o pseudo-circuito TDM em regime permanente, teria 50%
de ocupao, de forma que o processo de reproduo estaria defasado do processo de
escrita dessa mesma ordem, razovel supor que, quando um overflow ocorre, pelo menos
metade dos dados armazenados ainda no foram reproduzidos no fluxo de sada, e so
perdidos. Assim, a perda efetiva de pacotes para o IPmux-11 deve ser considerada atravs
da expresso (4.27):
Perdas RAD = Perdas NS + N Overflow .(50%.TBuffer )

(4.27)

Onde:
PerdasRAD a quantidade efetiva de pacotes perdidos;
PerdasNS a quantidade de pacotes perdidos detectados atravs do nmero de seqncia;
Noverflow a quantidade de eventos de overflow no perodo;
Tbuffer o tamanho do buffer, em pacotes.
Como no IPmux-11 o tamanho do buffer alocado em tempo, tendo sido configurado para
50 ms, a Tabela 4.9 precisa ser utilizada para determinar Tbuffer.
Tabela 4.9 Durao dos dados TDM e quantidade de pacotes para PDUs AAL1.
PDUs
1
5
10
15
20
25
30

Dados TDM (ms)

0,184
0,918
1,836
2,754
3,672
4,590
5,625

Pacotes (50ms)
272
54
27
18
14
11
9

Alm disso, como os pacotes no transportam a mesma quantidade de dados TDM para os
dois fluxos, sobretudo quando so utilizadas 30 PDUs no IPmux-11, necessrio
determinar a quantidade efetiva de dados perdidos com cada um dos pacotes.

A162

Assim, a Tabela 4.10 apresenta os resultados efetivos do ensaio para comparao mais
justa do desempenho obtido entre os dois fluxos, onde as Perdas RAD foram calculadas
atravs da expresso (4.27).
Tabela 4.10 Comparao do desempenho entre o IPmux-11 e a aplicao Java.
PDUs
AAL1
30

Trfego
Concorrente
1Mbps
2Mbps
3Mbps
4Mbps
1Mbps
2Mbps
3Mbps
4Mbps

Em Perda de Pacotes
Perdas
Perdas
RAD
Mux-IP
% Melhoria
124
71
-42,9%
297
253
-14,8%
319
569
78,5%
343
1.289
275,8%
56
55
-1,8%
88
137
55,3%
662
511
-22,8%
1.374
1.048
-23,7%

Em Perda de Dados TDM

Perdas
Perdas
RAD (ms) Mux-IP (ms) % Melhoria
700
71
-89,9%
1.671
253
-84,9%
1.793
569
-68,3%
1.929
1.289
-33,2%
51
55
7,0%
81
137
69,1%
608
511
-15,9%
1.262
1.048
-16,9%

A anlise desses dados demonstra que a aplicao Java, utilizando o novo algoritmo de
seqenciamento proposto, apresenta melhora de desempenho em sete das oito situaes,
mostrando-se inferior ao IPmux-11 apenas quando a quantidade de pacotes foi
praticamente a mesma, uma vez que cada pacote SAToP usado no Java carrega 1ms de
dados TDM, enquanto 5 PDUs AAL carregam 0,918 ms. Esse melhor desempenho
justificado pela maior quantidade de pacotes atrasados recuperveis, mas sobretudo pelo
problema que o overflow representa quando o fluxo prejudicado por um
congestionamento da rede, quando o trfego supera demais a taxa dos enlaces.
Deve ser considerada, de fato, apenas a melhoria obtida quando os fluxos possuem pacotes
semelhantes, ou seja, as linhas para 5 PDUs AAL1, pois pacotes de maior tamanho so
mais prejudicados pelo congestionamento nos roteadores que os pacotes menores, alm de
conterem quantidade bem maior de dados, no podendo ser feita uma comparao direta.
Como concluso das implementaes e experimentos desse captulo, foi validado o novo
mecanismo de seqenciamento, tanto na simulao MatLab como na implementao em
Java, demonstrando resultados melhores que o algoritmo IETF e a aplicao comercial. Da
mesma forma foi validada, atravs de simulao, a proposta de PLL com controlador PID
para a regenerao do relgio no receptor. Finalmente, foram comprovadas algumas
premissas do transporte TDM sobre IP, como a necessidade de garantia de banda e o bom

A163

desempenho decorrente da utilizao de pacotes de menor tamanho. Finalmente, foi

atestada a possibilidade de utilizao da tecnologia TDMoIP da RAD para emulao de
circuitos E1 no entroncamento de centrais, com bastante sucesso.

A164

5 CONCLUSES E TRABALHOS FUTUROS

O estudo aprofundado das tecnologias de emulao de circuitos TDM sobre redes de

pacotes realizado nesse trabalho permite concluir que a tecnologia de emulao fim a fim
de circuitos TDM sobre redes IP vivel, e realmente apresenta vantagens em relao
tecnologia VoIP em algumas aplicaes, sobretudo quando pr-existentes e no houver
interesse em fazer novos investimentos, aproveitando apenas a melhor eficincia de
utilizao da banda de transmisso na rede de transporte, permitindo assim a reduo de
custos com esses servios.
Essa viabilidade foi comprovada atravs da demonstrao de que os principais desafios
enfrentados no transporte atravs de rede de pacotes de servios extremamente sensveis a
atraso e variao nesse atraso, como os circuitos TDM, podem ser superados, mesmo em
redes onde no existam garantias de QoS, desde que exista largura banda disponvel para
assegurar a vazo de dados requerida por esse tipo de servio, caracterizado pelo envio de
pacotes a taxas constantes.
A superao desses desafios foi comprovada pelo desenvolvimento de um novo algoritmo,
bastante simples, que se demonstrou eficiente e robusto na simulao e experimentao
realizada, para o seqenciamento dos pacotes no receptor, um dos grandes problemas
enfrentados pelas redes IP com transporte UDP. A base desse algoritmo a utilizao de
um buffer circular, completamente auto-gerencivel, onde a ordenao dos pacotes
definida exclusivamente com base no nmero de seqncia recebido na palavra de controle
do encapsulamento utilizado para os pacotes, j durante seu armazenamento nesse buffer, o
que torna trivial o processo de leitura e reproduo do fluxo TDM na sada do receptor,
assim como permite o tempo equivalente a pelo menos um pacote de durao dos dados
TDM para a mitigao de eventuais perdas, sendo compatvel, tambm, com processos de
retransmisso comumente utilizados na transmisso de vdeo. A melhoria de desempenho
com a utilizao desse algoritmo chegou, na simulao, a 20% em relao ao algoritmo de
processamento do nmero de seqncia proposto no Internet-Draft TDMoIP, reproduzido
no Apndice D.

A165

Outro resultado interessante foi obtido com a simulao da proposta de utilizao de um

PLL para a recuperao do relgio de transmisso dos pacotes TDM, no receptor,
utilizando exclusivamente os

nmeros

de seqncia recebidos

e dispensando

completamente, para circuitos taxa constante, a utilizao de timestamps de qualquer

espcie, com a conseqente otimizao no uso de banda pela ausncia do overhead do
protocolo RTP. Infelizmente, no foi possvel a implementao desse mecanismo para
testes em uma rede real, mas os resultados de simulao foram bastante promissores,
incorporando as caractersticas robustas de um controlador PID necessidade de
estabilizao e baixo tempo de aquisio do PLL.
Ainda sobre a tecnologia em si, a comparao com a abordagem VoIP, para aplicaes
especficas de substituio dos entroncamentos de voz convencionais buscando reduo de
custos, demonstrou que o transporte de TDM sobre IP apresenta menor latncia,
possibilitando a utilizao de buffers maiores, e assim acomodar maiores variaes no
atraso sofrido pelos pacotes, assim como menor sensibilidade perda de pacotes, em
virtude da menor quantidade de informao dentro de cada um deles e grande
redundncia existente na codificao padro G.711, que tambm assegura uma qualidade
MOS muito prxima da telefonia normal.
Dessa forma, o trabalho atingiu sua primeira grande Meta, tendo demonstrado que a
tecnologia TDMoIP, com sincronizao adaptativa, mais barata que PDH/SDH
dedicado, conforme comparativo de custos realizado no Captulo 1, e mais simples e
eficiente que as principais tecnologias VoIP (Voice over IP) utilizando o protocolo RTP, no
transporte fim a fim de troncos de voz TDM convencionais, conforme demonstrado, com
base em resultados VoIP obtidos nas referncias, no Captulo 2.
Considerando a proposta-ttulo do trabalho, o estudo dos padres de codificao para
transmisso de vdeo digital demonstrou que possvel atender, mantendo qualidade de
vdeo compatvel com os objetivos propostos, restrio de taxa de transmisso, em
1,5Mbps, permitindo o broadcasting de vdeo sobre IP atravs de pseudo-circuitos E1.
Nesse cenrio, foi proposta modificao do mecanismo de controle de qualidade para as
transmisses de vdeo digital, eliminando o acoplamento receptor/transmissor e deixando a
A166

atividade para o pseudo-circuito emulado, implementado como uma camada de enlace do

ponto de vista da aplicao, fornecendo a esta um tubo de bits fim a fim confivel para o
transporte dos sinais de vdeo digital atravs da rede comutada em modo pacotes, e
utilizando os mecanismos propostos de seqenciamento e recuperao do relgio de
transmisso exatamente para assegurar essa qualidade desde que, evidentemente, exista
banda disponvel suficiente na rede para dar vazo quantidade de pacotes necessria para
a transmisso.
Quanto segunda grande Meta, validar a tecnologia TDMoIP com sincronizao
adaptativa pelo receptor como alternativa simples e barata ao ATM/SDH para transporte de
TV digital de baixa definio, em qualidade compatvel com a TV analgica atual, e para
broadcasting IPTV a baixas taxas (at 1,5Mbps); infelizmente os estudos realizados no
podem ser utilizados para uma concluso definitiva, mas podemos considerar essa
alternativa ainda promissora, em virtude do comportamento apresentado pelos pseudocircuitos nas simulaes e experimentos realizados.
Como base nos resultados obtidos, existe perspectiva de publicao de partes desse
trabalho, envolvendo principalmente os novos mecanismos desenvolvidos e a avaliao da
tecnologia TDMoIP no entroncamento de voz da central Trpico-RA.
Como perspectiva de continuidade dos trabalhos, sugerida a retomada do
desenvolvimento da aplicao Mux-IP PC de acordo com a sua especificao original,
utilizando uma linguagem de programao mais adequada s necessidades de controle de
tempo e acesso aos recursos da mquina, podendo envolver o desenvolvimento de
hardware dedicado para permitir a construo de uma interface compatvel com G.703, a
fim de que circuitos E1 possam ser conectados diretamente aplicao. Uma alternativa
seria a utilizao de placas comerciais, similares citada em [AWEYA2004a], para
realizao da interface.
Um grande aspecto no foi esgotado nesse trabalho, a validao desse tubo de bits
criado atravs da emulao de circuitos TDM para testes de transporte de vdeo, sob
demanda e em tempo real. Isso pode ser feito, de forma mais simples, utilizando arquivos
de vdeo codificado carregados no prprio computador, fazendo a sua segmentao em
A167

pacotes e transmitindo sobre a rede, verificando o efeito da transmisso sob diversas

condies de enlace e buffer.

Outra alternativa, dependente do desenvolvimento da

interface fsica para a aplicao Mux-IP PC, ou da utilizao de produtos comerciais, a

aplicao direta do sinal de sada dos equipamentos codificadores, como cmeras e
dispositivos de videoconferncia, comparando seu desempenho com as tecnologias usuais
de transmisso de vdeo sobre IP.
Finalmente, podem ser desenvolvidos estudos comparativos mais detalhados entre as
aplicaes TDM sobre IP e VoIP, utilizando a plataforma VoIP implantada na rede
LabCom/UnB, fazendo a conectividade entre as duas aplicaes e a central Trpico-RA, a
fim de criar um ambiente similar de convergncia ao existente nas operadoras.

A168

REFERNCIAS BIBLIOGRFICAS

[ABDALA2005]

ABDALA Jr., H., SOARES, A. M., CARVALHO, P.H.P, BARRETO,

P.S. ANVAME-N-Z, G. e LAMBERT, R.; Implementao de um
Ambiente de Teste e Medio para Redes Convergentes, XXII
Simpsio Brasileiro de Telecomunicaes, SBRT05, Campinas,
Setembro, 2005;

[ALCATEL2002]

ALCATEL S.A.; Projeto de Instalao LABCOM-CDT-UNBBRASLIA, Tomo A, Alcatel S.A., Braslia, Maro, 2002;

[ALCATEL2002a] ALCATEL S.A.; Programao da Central PRO LABCDT,

Alcatel S.A., Braslia, Maro, 2002;
[ANATEL2006]

ANATEL;

Indicadores

do

Plano

Geral

de

Metas

de

Universalizao: Resultados Mensais, Setembro, 2006, disponvel

em:

http://www.anatel.gov.br/index.asp?link=/Telefonia_Fixa/stfc/

indicadorespgmu /2006/tabela.htm?Cod=1820;
[ANATEL2006a]

ANATEL; SMC e SMP Controle de Estaes Mveis: Brasil

Estaes em Operao, Setembro, 2006, disponvel em:
http://sistemas.anatel.gov.br/smp/administracao/consulta/acompanham
entoestacoes/tela.asp?CodTopico=2440&CodArea=31&CodTemplate
=413&CodMenuServico=43;

[ANSI105]

ANSI T1.105 - 2001; Synchronous Optical Network (SONET) Basic Description including Multiplex Structure, Rates, and
Formats, Maio, 2001;

[ANSI107]

ANSI T1.107 - 1995; Digital Hierarchy - Format Specification,

1995;

A169

[ATM1997]

ATM

Forum;

Circuit

Emulation

Service

Interoperability

Specification 2.0, Janeiro, 1997;

[AWEYA2003]

AWEYA, James; Trunking of TDM and Narrowband Services over

IP Networks, International Journal of Network Management no13,
pginas 33-60, John Wiley & Sons, Ltd., Novembro, 2003;

[AWEYA2004]

AWEYA, James; Circuit Emulation Services over Ethernet Part 1:

Clock Synchonization using Timestamps, International Journal of
Network Management no14, pginas 29-44, John Wiley & Sons, Ltd.,
2004;

[AWEYA2004a]

AWEYA, James; Circuit Emulation Services over Ethernet Part 2:

Prototype and Experimental Results,

International Journal of

Network Management n 14, pginas 45-58, John Wiley & Sons, Ltd.,
2004;
[BARRETO2001] BARRETO, Luis A. N., Desenvolvimento de Metodologias de
Projeto de Redes de Voz sobre IP, Dissertao de Mestrado,
Universidade de Braslia, Faculdade de Tecnologia, Departamento de
Engenharia Eltrica, Distrito Federal, 2001;
[BARRETO2005] BARRETO, Priscila S., Otimizao de Roteamento Adaptativo em
Redes

Convergentes com Trfego Auto-Similar, Exame de

Qualificao de Doutorado, Universidade de Braslia, Faculdade de

Tecnologia, Departamento de Engenharia Eltrica, Distrito Federal,
Abril, 2005, trabalho em andamento;
[BEZERRA2004]

BEZERRA, R.S., ABDALA Jr., H., SOARES, A. M., CARVALHO,

P.H.P, BARRETO, P.S.; Uma Ferramenta em Cdigo Aberto para
Anlise de Redes Convergentes, 11th International Conference on
Telecommunications poster session, ICT 2004, Fortaleza, Agosto,
2004;
A170

[BOLOT1993]

BOLOT, J. C., Characterizing End-to-End Packet Delay and Loss in

the Internet, Journal of High-Speed Networks, vol.2, no3, pginas
305-323, December, 1993;

[CISCO2006]

CISCO Systems S.A.; Barmetro CISCO da Banda Larga: Anlise

de Mercado 2o.Trimestre/2006, IDC Brasil, 2006;

[CISCO2004]

White Paper; Understanding Jitter in Packet Voice Networks,

CISCO Systems, Inc, 2004;

[CISCO2005]

White Paper; Understanding Delay in Packet Voice Networks,

CISCO Systems, Inc, 2001;

[COLLINS2001]

COLLINS, Daniel; Carrier Grade Voice over IP, The McGraw-Hill

Companies, Inc., USA, 2001;

[DAZZO1988]

DAZZO, John J. e HOUPIS, Constantine H.; Anlise e Projeto de

Sistemas de Controle Lineares, 2a.edio, Editora Guanabara., Rio de
Janeiro, 1988;

[GENEL2003]

GENEL, Hayrettin e ERTEN, Y.M.; An End-to-End QoS Control

Scheme for Video Transmission over Internet, 8th International
Symposium on Computers and Communication Proceedings, ISCC
2003, Kiris-Kemer, Turkey, Junho, 2003;

[IBGE2006]

IBGE; PNAD Pesquisa Nacional por Amostragem de Domiclios,

Sntese de Indicadores, Instituto Brasileiro de Geografia e Estatstica,
Rio de Janeiro, 2006 p. 205 e 206;

[IEEE802.3]

IEEE 802.3; IEEE Standard Local and Metropolitan Area Networks

- Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications, 2002;

A171

[IEEE802.1Q]

IEEE 802.1Q; IEEE Standard Local and Metropolitan Area

Networks Virtual Bridged Local Area Networks, 2003;

[IETF2006]

IETF PWE3 Working Group Internet-Draft; TDM over IP, Junho,

2006, trabalho em andamento, disponvel em:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-05.txt;

[IETF2006a]

IETF PWE3 Working Group Internet-Draft; Structure-aware TDM

Circuit

Emulation

Service

over

Packet

Switched

Network

(CESoPSN), Maio, 2006, trabalho em andamento, disponvel em:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-07.txt;
[IETF2006b]

IETF PWE3 Group Internet-Draft; SONET/SDH Circuit Emulation

over Packet (CEP), Janeiro, 2006, trabalho em andamento,
disponvel em:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-12.txt;

[ITS2002]

ITS; Introduo Trpico RA, Apostila de treinamento, Instituto de

Tecnologia de Software de So Paulo - ITS, Campinas, Julho, 2002;

[ITS2002a]

ITS; Operao, Manuteno e Superviso Trpico RA, Apostila de

treinamento, Instituto de Tecnologia de Software de So Paulo - ITS,
Campinas, Julho, 2002;

[ITU-T G702]

ITU-T Recommendation G.702;

Digital Hierarchy Bit Rates,

Novembro, 1988;
[ITU-T G704]

ITU-T Recommendation G.704;

Synchronous Frame Structures

used at 1,544, 6,312, 2,048, 8,448 and 44,736 kbit/s Hierarchical

Levels, Outubro, 1998;
[ITU-T G706]

ITU-T Recommendation G.706;

Frame Alignment and Cyclic

Redundancy Check (CRC) Procedures relating to Basic Frame

Structures defined in Recommendation G.704, Abril, 1991;

A172

[ITU-T G707]

ITU-T Recommendation G.707; Network Node Interface for the

Synchronous Digital Hierarchy (SDH), Outubro, 2000;

[ITU-T G751]

ITU-T Recommendation G.751;

Digital Multiplex Equipments

operating at the Third Order bit rate of 34,368 kbit/s and the Fourth
Order bit rate of 139,264 kbit/s and using Positive Justification,
Novembro, 1988;
[ITU-T G810]

ITU-T Recommendation G.810; Definitions and Terminology for

Synchronization Networks, Agosto, 1996;

[ITU-T Y1413]

ITU-T

Recommendation

Y.1413;

TDM-MPLS

Network

Interworking User Plane Interworking, Maro, 2004;

[ITU-T Y1414]

ITU-T Recommendation Y.1414; Voice Services MPLS Network

Interworking, Julho, 2004;

[OBANDO2005]

OBANDO, Martin D. Bravo, Comparao do Desempenho dos

Codificadores de Voz G.711, G.729, G.723.1 e iLBC em transmisso
com perda de pacotes, Dissertao de Mestrado, Universidade de
Braslia, Faculdade de Tecnologia, Departamento de Engenharia
Eltrica, Distrito Federal, 2005;

[ONU2006]

Organizao das Naes Unidas, The Millenium Development Goals

Report 2006, United Nations, New York, 2006, p.25;

[PROMOM1999]

PROMOM Ltda.; Trpico RA: Manual de Comandos Verso

S10.0, Cdigo 45001049-6, PROMOM Eletrnica Ltda, Junho,
1999;

[PROMOM1999a] PROMOM Ltda.; Trpico RA: Manual de Atividades de Manuteno

Corretiva Verso S10.0, Cdigo 45001047-7, PROMOM
Eletrnica Ltda, Junho, 1999;
A173

[PROMOM1999b] PROMOM Ltda.; Trpico RA: Manual de Atividades de Manuteno

Preventiva Verso S10.0, Cdigo 45009268-9, PROMOM
Eletrnica Ltda, Junho, 1999;
[PROMOM1999c] PROMOM Ltda.; Trpico RA: Manual de Atividades de Manuseio
Verso S10.0, Cdigo 45009267-4, PROMOM Eletrnica Ltda,
Junho, 1999;
[PILATI2004]

PILATI, Tarcisio B. e ZUCCHI, Wagner L.; TDMoIP over Ethernet

Backbones,

International

Workshop

on

Telecommunications

Proceedings, IWT2004, Santa Rita do Sapuca, Agosto, 2004;

[RAD2003]

White Paper.; TDMoIP x VoIP: Matching Technology to

Requirements, RAD Data Communications Ltd., 2005;

[RAD2005]

RAD Data Communications Ltd.; IPmux-11 TDMoIP Gateway

Installation and Operation Manual, RAD Data Communications
Ltd., 2005;

[RFC768]

IETF RFC768; User Datagram Protocol (UDP), contedo on-line:

http://www.ietf.org/rfc/rfc768.txt, Agosto, 1980;

[RFC791]

IETF

RFC791;

Internet

Protocol

(IP),

contedo

on-line:

http://www.ietf.org/rfc/rfc791.txt, Setembro, 1981;

[RFC2354]

IETF RFC2354; Options for Repair of Streaming Media, contedo

on-line: http://www.ietf.org/rfc/rfc3550.txt, Junho, 1998;

[RFC3550]

IETF RFC3550; RTP: A Transport Protocol for Real-Time

Applications, contedo on-line: http://www.ietf.org/rfc/rfc3550.txt,
Julho, 2003;

A174

[RFC3916]

IETF RFC3916; Requirements for Pseudo-Wire Emulation Edge-toEdge (PWE3), contedo on-line: http://www.ietf.org/rfc/rfc3916.txt,
Setembro, 2004;

[RFC3985]

IETF RFC3985; Pseudo-Wire Emulation Edge-to-Edge (PWE3)

Architecture, contedo on-line: http://www.ietf.org/rfc/rfc3985.txt,
Maro, 2005;

[RFC4197]

IETF RFC4197; Requirements for Edge-to-Edge Emulation of Time

Division Multiplexed (TDM) Circuits over Packet Switching
Networks, contedo on-line: http://www.ietf.org/rfc/rfc4197.txt,
Outubro, 2005;

[RFC4385]

IETF RFC4385; Pseudowire Emulation Edge-to-Edge (PWE3)

Control Word for Use over an MPLS PSN, contedo on-line:
http://www.ietf.org/rfc/rfc4385.txt, Fevereiro, 2006;

[RFC4446]

IETF RFC4446; IANA Allocations for Pseudowire Edge to Edge

Emulation(PWE3),

contedo

on-line:

http://www.ietf.org/rfc/rfc4446.txt, Abril, 2006;

[RFC4447]

IETF RFC4447; Pseudowire Setup and Maintenance

Label

Distribution

Protocol

(LDP),

contedo

Using the
on-line:

http://www.ietf.org/rfc/rfc4447.txt, Abril, 2006;

[RFC4448]

IETF RFC4448; Encapsulation Methods for Transport of Ethernet

over

MPLS

Networks,

contedo

on-line:

http://www.ietf.org/rfc/rfc4448.txt, Abril, 2006;

[RFC4553]

IETF RFC4553; Structure-Agnostic TDM over Packet (SAToP),

contedo on-line: http://www.ietf.org/rfc/rfc4553.txt, Junho, 2006;

A175

[SCHULTER2002] SCHULTER, A., RIBEIRO, L., BECKER, V. e CAETANO, M.; Um

ambiente de Distribuio de Vdeo MPEG2 com Suporte Multicast em
Cdigo Aberto para o Projeto I2TV, 4o.Workshop RNP2, Natal,
2002;
[SOARES1995]

SOARES, L. F. G., LEMOS, G. e COLCHER, S.; Redes de

Computadores: das LANs, MANs e WANs s Redes ATM, Editora
Campus, Rio de Janeiro, 1995;

[STEIN2003]

STEIN, Yaakov e STROEHLEIN, Brian; Taking an Inside Look at

TDMoIP: A Tutorial, Maro, 2003; disponvel em:
http://www.commsdesign.com/design_corner/OEG20030326S0012;

[STEIN2003a]

STEIN, Yaakov; In-depth Comparision of TDMoIP and CESoPSN,

Junho, 2003, disponvel em:
www.dspcsp.com/tdmoip/compare.pdf;

[STEIN2005]

STEIN, Yaakov e SCHWARTZ, Eitan; Circuit Extension over IP:

The Evolutionary Approach to Transporting Voice and Legacy Data
over IP Networks version 2.0, Maio 2004 , disponvel em:
http://www.dspcsp.com/tdmoip/tdmoip-wp.pdf

[TRYFONAS1999] TRYFONAS, Christos e VARMA, Anujan; Timestamping Schemes

for MPEG-2 Systems Layer and Their Effect on Receiver Clock
Recovery, IEEE Transactions on Multimedia, Vol.1, No.3, pginas
251-263, September, 1999;
[WEIHUA2003]

WEIHUA, Zhou et al.; A New Architecture of Converged Networks,

International Conference on Communication Technology 2003
Proceedings, ICCT 2003, Beijing, China, 2003.

TDMoIP e TDMoIP driven so marcas registradas da RAD Data Communications, Inc.

MatLab marca registrada da The MathWorks, Inc.
Microsoft marca registrada da Microsoft Corporation.
A176

APNDICE A ARQUITETURA PWE3

A RFC3985 descreve a arquitetura utilizada para PWE3, ou seja, a Emulao por PseudoCircuitos Fim a Fim, para emulao de servios como ATM, Frame-Relay, Ethernet, TDM
e SONET/SDH, sobre redes de transporte em modo pacotes (PSN), usando especificamente
redes IP e MPLS. Essa RFC apresenta a arquitetura dos quadros, define a terminologia e
especifica os diversos elementos de protocolo envolvidos e suas respectivas funes.
Os pseudo-circuitos (PW) devem prover as seguintes funes com o objetivo de emular o
comportamento e as caractersticas do servio nativo:
a) encapsulamento das PDU especficas do servio emulado ou fluxos de dados que
chegam porta (fsica ou lgica) do PE de origem;
b) transporte dos dados encapsulados atravs de tunelamento dentro da rede de transporte
em modo pacotes;
c) estabelecimento do pseudo-circuito, incluindo a troca e/ou distribuio de
identificadores do PW utilizado pelos ns terminais do tnel dentro da rede de
transporte em modo pacotes;
d) gerenciamento de sinalizao, sincronizao, ordenao e quaisquer outros aspectos do
servio dentro dos limites do pseudo-circuito;
e) gerenciamento de alarmes e condies especficas do servio emulado.
A.1 - TERMINOLOGIA UTILIZADA NA ARQUITETURA PWE3

A Arquitetura da Emulao por Pseudo-Circuitos Fim a Fim (PWE3) utiliza a seguinte

terminologia formal, definida na RFC3985, cujos principais elementos j foram
apresentados no Modelo de Referncia PWE3 e so agora descritos em maiores detalhes:

A1

Attachment Circuit (AC)

Circuito de Acesso

o circuito fsico ou virtual de acesso que conecta um CE a um PE, utilizando o servio

nativo que emulado pelo pseudo-circuito (PW). Um Circuito de Acesso pode ser, por
exemplo, um DLCI (Data-Link Connection Identifier) Frame Relay, um VPI/VCI (Virtual
Path Identifier/Virtual Circuit Identifier) ATM, uma porta Ethernet, uma VLAN (Virtual
Local rea Network), uma conexo PPP (Point-to-Point Protocol) sobre uma interface
fsica,

uma sesso PPP atravs de um tnel L2TP, ou um LSP (Label-Switching Path)

MPLS.
CE-bound
Sentido de Destino do Pseudo-Circuito

a direo de trfego onde as PW-PDUs so recebidas em um pseudo-circuito, a partir da

rede de pacotes, processadas e ento encaminhadas ao equipamento cliente (CE) de
destino.
CE-Signaling
Sinalizao CE

o conjunto de mensagens enviadas e recebidas pelo Plano de Controle, no servio nativo,

do equipamento do cliente (CE). Pode ser desejvel, ou mesmo necessrio para o
equipamento provedor (PE) do pseudo-circuito, monitorar ou interagir com essa
sinalizao a fim de emular efetivamente o servio.
Control Word (CW)
Palavra de Controle

um cabealho de quatro octetos utilizado em alguns encapsulamentos para transportar

informaes associadas a cada pacote quando a rede de pacotes MPLS.
Costumer Edge (CE)
Equipamento Cliente

o dispositivo de origem ou destino do servio nativo suportado pelo pseudo-circuito de

forma transparente. O CE no tem conscincia de que est usando um servio emulado ao
invs do servio nativo.
Forwarder (FWRD)
Mdulo de Encaminhamento

um subsistema do equipamento provedor (PE) que seleciona o pseudo-circuito a utilizar

na transmisso de um fluxo de dados (payload) recebido a partir do Circuito de Acesso.
A2

Fragmentation
Fragmentao

a ao de subdividir uma nica PDU do servio nativo em mltiplas PDUs antes da sua
transmisso atravs da PSN, esperando que a PDU original seja reconstruda em algum
outro lugar na rede. Os pacotes podem ser submetidos fragmentao quando tiverem
tamanho superior MTU da rede atravs da qual eles sero encaminhados.
Maximum Transmission Unit (MTU)
Unidade Mxima de Transmisso

o tamanho mximo do pacote (excluindo o cabealho do protocolo de enlace) que um

determinado tipo de interface pode transmitir sem necessidade de fragmentao.
Native Service Processing (NSP)
Processamento do Servio Nativo

o processamento do fluxo de dados recebido pelo PE de origem a partir do CE de

origem, antes do encaminhamento ao pseudo-circuito para transmisso atravs do ncleo
da rede de pacotes, ou o processamento dos dados recebidos pelo PE de destino a partir do
pseudo-circuito estendido sobre a PSN, antes de seu encaminhamento atravs do circuito
de acesso (AC) para o CE de destino, ambos considerando as funcionalidades originais do
servio nativo, que so definidas por outros rgos de padronizao que no o IETF, como
ITU-T (International Telecommunications Union Telecommunication Standardization
Sector), ANSI (American National Standards Institute) e AMTF (Asynchronous Mode
Transfer Forum).
Packet-Switched Network (PSN)
Rede de Transporte comutada em Modo Pacotes

Dentro do contexto PWE3, uma rede que utiliza IP ou MPLS como mecanismo de
encaminhamento de pacotes.
PE-bound
Sentido de Origem do Pseudo-Circuito

a direo de trfego onde as informaes recebidas do equipamento cliente (CE) de

origem so adaptadas a um pseudo-circuito, e as PW-PDUs correspondentes so
encaminhadas atravs da rede de pacotes.
PE/PW Maintenance
Mdulo de Manuteno do Pseudo-Circuito a partir do Provedor (PE)

utilizada pelo PE para estabelecer, manter e desconectar um pseudo-circuito. Pode ser

acoplada sinalizao CE a fim de permitir o gerenciamento efetivo desse pseudo-circuito.
A3

Protocol Data Unit (PDU)

Unidade de Dados de Protocolo

a unidade de dados encaminhada/recebida para/de uma rede por uma determinada

camada de protocolo.
Provider Edge (PE)
Equipamento Provedor

o equipamento provedor, de origem ou destino, que estabelece um pseudo-circuito fim a

fim (PWE3) entre um CE de origem e um CE de destino, para a emulao de um
determinado servio.
Pseudo Wire (PW)
Pseudo-Circuito

um mecanismo que transporta os elementos essenciais de um servio emulado a partir de

um determinado PE de origem at outro(s) PE(s) de destino, atravs de uma rede de
transporte comutada em modo pacotes.
Pseudo Wire Emulation Edge-to-Edge (PWE3)
Emulao por Pseudo-Circuitos Fim a Fim

um mecanismo que emula os atributos essenciais de um servio de transporte, como um

feixe E1 sobre linha dedicada ou Frame Relay, estabelecendo conectividade fim a fim entre
a origem e o destino do fluxo de dados associado a esse servio atravs de uma rede de
transporte comutada em modo pacotes.
Pseudo Wire PDU (PW-PDU)
PDU associada ao Pseudo-Circuito

uma PDU encaminhada atravs do pseudo-circuito que contm todo o fluxo de dados e
as informaes de controle necessrias para emular o servio desejado.
PSN Tunnel
Tnel PSN

um tnel estabelecido atravs da rede de pacotes, dentro do qual um ou mais pseudocircuitos podem ser transportados.
PSN Tunnel Signaling
Sinalizao do Tnel PSN

a sinalizao utilizada para estabelecer, manter e eliminar um tnel PSN.

A4

PW Demultiplexer
Demultiplexador de pseudo-circuitos

um mtodo definido no Plano de Dados para identificar um pseudo-circuito estabelecido

at um PE.
Time Division Multiplexing or Time Domain Multiplexing (TDM)
Multiplexao por Diviso no Tempo ou no Domnio do Tempo

uma designao freqentemente utilizada em referncia ao fluxo sncrono de bits de

dados estabelecido s taxas definidas pela Recomendao ITU-T G.702 (feixes T1, E1, T3,
E3).
Tunnel
Tnel

um mtodo para transportar informaes de forma transparente atravs de uma rede.

A aplicabilidade da PWE3, ou seja, da Emulao por Pseudo-Circuitos Fim a Fim, a um
servio em particular depende da sensibilidade desse servio (ou de sua implementao no
equipamento cliente) aos efeitos inerentes s redes de transporte por comutao em modo
pacotes, tais como perda de pacotes, atraso, variao no atraso e reordenao; e da
habilidade da camada de adaptao definida na arquitetura em minimizar esses efeitos
indesejveis.
Alguns servios, como IP sobre Frame Relay sobre PWE3, podem adaptar-se de forma
bastante robusta s caractersticas das redes de pacotes baseadas em IP e MPLS. Outros,
como a interconexo de sistemas PBX, necessitam de consideraes mais cuidadosas na
camada de adaptao e dentro da rede de pacotes, como funes de engenharia de trfego.
Alm disso, em alguns casos, as restries impostas pela PSN podem tornar as garantias
requeridas pelo servio nativo impossveis de serem providas pelo pseudo-circuito.
Complementando a terminologia, so apresentados alguns termos e acrnimos utilizados
com os Servios TDM, nos seus processos particulares de sinalizao, sincronizao e
indicao de alarmes. A sinalizao um elemento fundamental dos circuitos TDM, sendo
utilizada para supervisionar e indicar o estado das aplicaes de telefonia, prover alertas a
estas aplicaes (como requisies de conexo e desconexo), e transferir informaes de
roteamento e endereamento. Esses sinais precisam ser transportados de forma confivel
A5

sobre os pseudo-circuitos estendidos sobre as redes de pacote para que os servios nativos
de telefonia, nas extremidades de origem e destino, funcionem de maneira adequada.
Channel-Associated Signaling (CAS)
Sinalizao por Canal Associado

A sinalizao CAS transportada atravs de um canal especfico (ou timeslot,

normalmente o 16, para E1) no mesmo quadro T1 ou E1 dos sinais de voz, alocando 4 bits
de sinalizao para cada um dos canais de voz do feixe, o chamado Canal Associado
(normalmente com taxa de 2kbps). Como a sinalizao no feita na mesma faixa de voz
(out-band), ela pode ser transferida numa taxa mais baixa que o trfego de dados TDM,
no sendo necessria a atualizao de todos os bits CAS em cada quadro TDM transmitido.
Assim, um ciclo CAS atualizando todos os bits de sinalizao acontece somente aps um
determinado nmero de quadros, o que define uma nova estrutura conhecida como multiquadro ou superquadro, sendo as mais comuns as que compreendem 12, 16 ou 24 quadros,
correspondendo a 1,5 ms, 2 ms e 3 ms de durao do fluxo de bits. Na transmisso de
canais telefnicos no Brasil utilizada uma estrutura de 16 quadros por multi-quadro, com
durao de 2 ms, para os 30 canais de voz de um feixe E1 tpico, conforme mostrado na
Figura A.1.

Estrutura do Feixe E1 utilizado no Brasil para Multiplexao de Canais de Voz,

com Sinalizao por Canal Associado:
Tempo (us)
125
250
375
500
625
750
875
1000
1125
1250
1375
1500
1625
1750
1875
2000

bits
256
512
768
1024
1280
1536
1792
2048
2304
2560
2816
3072
3328
3584
3840
4096

bytes
32
64
96
128
160
192
224
256
288
320
352
384
416
448
480
512

SuperQuadro

SS 1

SS 2

Quadros
Quadro 0
Quadro 1
Quadro 2
Quadro 3
Quadro 4
Quadro 5
Quadro 6
Quadro 7
Quadro 8
Quadro 9
Quadro 10
Quadro 11
Quadro 12
Quadro 13
Quadro 14
Quadro 15

I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1

Canal 0
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N

1
N
1
N
1
N
1
N
1
N
1
N
1
N
1
N

1
N
1
N
1
N
1
N
1
N
1
N
1
N
1
N

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Canal 16
17 18 19 20 .
0 0 0 0 N Y N N
1

1 1

1 16 16 16 16

2 2

2 17 17 17 17

3 3

3 18 18 18 18

4 4

4 19 19 19 19

5 5

5 20 20 20 20

6 6

6 21 21 21 21

7 7

7 22 22 22 22

8 8

8 23 23 23 23

9 9

9 24 24 24 24

10 10 10 10 25 25 25 25
11 11 11 11 26 26 26 26
12 12 12 12 27 27 27 27
13 13 13 13 28 28 28 28
14 14 14 14 29 29 29 29
15 15 15 15 30 30 30 30

Bits de alinhamento de quadro;

Bit de Alarme para extremidade remota;
Canal de 8 Kbps reservado para uso internacional (manter em 1)
Canal de 20 Kbps reservado para uso nacional (manter em 1)
Bits de alinhamento de superquadro
Bit de Alarme de perda de superquadro para extremidade remota
Reservado para uso nacional (manter em 1)
Canal de 2 Kbps ou 4 bits de sinalizao por canal associado, para cada um dos 30 canais
Dados dos Canais de Voz, amostardos a 8 KHz, utilizando Lei A

Figura A.1 Multi-quadro com 16 quadros e sinalizao CAS.

A6

. 31

Common Channel Signaling (CCS)

Sinalizao por Canal Comum

A sinalizao CCS utiliza um canal digital em separado para transportar mensagens

assncronas relacionadas ao estado das aplicaes de telefonia em cada canal de um
determinado tronco TDM. Esse canal de sinalizao pode estar fisicamente localizado
em um ou mais timeslots adjacentes do mesmo tronco TDM, denominado CCS associado
ao tronco, como mostrado na Figura A.2, onde utilizado o canal 16 do feixe E1 como
canal de sinalizao; ou ser transportado atravs de uma rede independente, especfica para
sinalizao e comutada em modo pacotes. A sinalizao CCS tipicamente baseada no
protocolo HDLC, com cdigos ociosos ou mensagens do tipo manter-vivo sendo
enviadas at que um evento que necessite de sinalizao, como a mudana de estado de
um terminal de no gancho para fora do gancho ocorra. Alguns exemplos de sistemas
de sinalizao por canal comum so a SS7 (Signaling System Number 7), definida pela
Recomendao ITU-T Q.700, e a sinalizao ISDN-PRI (Integrated Services Digital
Network-Primary Rate Interface) ou RSDI-PRI (Rede Digital de Circuitos Integrados
Interface Primria), definida pela Recomendao ITU-T Q.931.

Estrutura do Feixe E1 utilizado no Brasil para Multiplexao de Canais de Voz,

com Sinalizao por Canal Comum:
Tempo (us)
125
250
375
500
625
750
875
1000
1125
1250
1375
1500
1625
1750
1875
2000

bits
256
512
768
1024
1280
1536
1792
2048
2304
2560
2816
3072
3328
3584
3840
4096

bytes
32
64
96
128
160
192
224
256
288
320
352
384
416
448
480
512

Quadros
Quadro 0
Quadro 1
Quadro 2
Quadro 3
Quadro 4
Quadro 5
Quadro 6
Quadro 7
Quadro 8
Quadro 9
Quadro 10
Quadro 11
Quadro 12
Quadro 13
Quadro 14
Quadro 15

I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1

Canal 0
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N
0 1 1 0
A N N N

1
N
1
N
1
N
1
N
1
N
1
N
1
N
1
N

1
N
1
N
1
N
1
N
1
N
1
N
1
N
1
N

1 2 3 4 5 6 7 8 9 10 11 12 13 14 16 Canal 16 17 18 19 20 .
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS
CCS

Bits de alinhamento de quadro;

Bit de Alarme para extremidade remota;
Canal de 8 Kbps reservado para uso internacional (manter em 1)
Canal de 20 Kbps reservado para uso nacional (manter em 1)
Canal de 64 Kbps para mensagens CCS
Dados dos Canais de Voz, amostardos a 8 KHz, utilizando Lei A

Figura A.2 - Utilizao do canal 16 para sinalizao CCS de um feixe E1.

A7

. 31

Packet Delay Variation (PDV)

Variao no Atraso dos Pacotes

o termo geral utilizado pela IETF para descrever as variaes observadas no atraso
sofrido por cada um dos pacotes que atravessam a rede (PSN). Os termos especficos jitter
(escorregamento de bits) e wander (flutuao de relgio) sero utilizados apenas no
contexto das redes TDM, conforme definidos na Recomendao ITU-T G.810 [ITU-T
G810], para descrever as variaes de curta e longa durao, respectivamente, observadas
no fluxo de bits do sinal digital.
Loss of Signal (LOS)
Perda de Sinal

um termo utilizado para designar a condio na qual um sinal TDM vlido no pode ser
extrado da camada fsica, cujos critrios efetivos de deteco e liberao esto descritos na
Recomendao ITU-T G.775.
Frame Alignment Signal (FAS)
Sinal de Alinhamento de Quadro

um termo utilizado para designar o padro especial e peridico de bits que impe a
estrutura dos quadros E1 e T1, conforme descrito na Recomendao ITU-T G.704.
Out of Frame Alignment Synchronization (OOF)
Ausncia de Sincronismo de Quadros

um termo utilizado para designar o estado de um receptor TDM quando este no

encontra um FAS vlido, cujos critrios efetivos de deteco e liberao esto descritos na
Recomendao ITU-T G.706. Essa condio invalida os dados TDM recebidos.
Alarm Indication Signal (AIS)
Sinal de Indicao de Alarme

um termo utilizado para designar um padro especial de bits dentro do fluxo TDM que
indica a presena de falha em um circuito de origem, cujos critrios efetivos de indicao e
liberao esto descritos na Recomendao ITU-T G.775.
Remote Alarm Indication (RAI) e Remote Defect Indication (RDI)
Sinais de Indicao de Alarme ou Defeito Remoto

So termos (normalmente sinnimos) utilizados para designar um padro especial dentro

do quadro de um servio TDM, que enviado de volta origem pelo receptor que recebe
um sinal AIS. Esse sinal no pode ser detectado quando uma condio LOS ou OOF
detectada ou um sinal AIS recebido. As regras especficas para a codificao desse
padro no enquadramento TDM so discutidas na Recomendao ITU-T G.775.
A8

A.2 - PROTOCOLOS UTILIZADOS NA ARQUITETURA PWE3

A RFC3985 estabelece um modelo lgico de Pilha de Protocolos com o objetivo de

minimizar as diferenas entre pseudo-circuitos operando sobre diferentes tipos de redes de
transporte comutadas em modo pacotes (PSN). A definio dessa pilha de protocolos, cujo
modelo lgico mostrado na Figura A.3, tem como objetivos tornar a definio de cada
pseudo-circuito independente da rede sobre a qual o mesmo estabelecido e maximizar a
reutilizao das definies de protocolo do IETF e suas respectivas implementaes.
Fluxo de Dados
(payload)
Encapsulamento
(encapsulation)

Pode ser vazia

Demultiplexao PW
(PW demultiplexer)
Convergncia PSN
(PSN convergence)

Pode ser vazia

Rede de Pacotes
(packet-switching)
Enlace
(data-link)
Fsica
(physical)

Figura A.3 - Modelo lgico da pilha de protocolos PWE3.

O fluxo de dados (payload) transportado sobre a Camada de Encapsulamento, que por
sua vez transporta qualquer outra informao que no esteja presente nesse fluxo de dados,
mas seja necessria para que o PE de destino do pseudo-circuito (PW) possa encaminhar
esse fluxo de dados ao CE de destino, atravs da interface fsica. Caso nenhuma
informao complementar seja necessria alm do fluxo de dados em si, essa camada
vazia.
A Camada de Encapsulamento tambm prov suporte para processamento em tempo real e,
se necessrio, para seqenciamento dos pacotes.

A9

A Camada de Demultiplexao dos pseudo-circuitos prov a habilidade de oferecer

mltiplos PWs sobre um nico tnel atravs da PSN. O valor do Demultiplexador PW
utilizado para identificar um determinado PW dentro do Plano de Dados deve ser nico
para cada PE, mas esse no um requisito PWE3. Ele deve, contudo, ser nico para cada
extremidade de destino do tnel. Caso seja necessrio identificar um tnel em particular,
isso responsabilidade da Camada de Rede (PSN).
A Camada de Convergncia PSN prov os acrscimos necessrios para estabelecer a
conformidade da rede de pacotes utilizada com os requisitos assumidos para a PSN pelo
servio emulado. Assim, essa camada estabelece uma interface consistente para o pseudocircuito, tornando-o independente do tipo de rede de pacotes utilizada. Caso a PSN j
atenda inerentemente aos requisitos do servio emulado, essa camada vazia.
As ltimas trs camadas so tradicionalmente encontradas nas redes de transporte e
dependem do tipo de rede, de enlace e de interface fsica utilizada, sendo inerentes rede
de transporte em modo pacotes onde o servio emulado. Essa PSN pode ser uma rede
IPv4 (Internet Protocol version 4), IPv6 (Internet Protocol version 6) ou MPLS.
Assim, PWE3 define a Camada de Encapsulamento, os mtodos de transporte para os
diversos tipos de fluxos de dados dos servios nativos e a interface com as Camadas de
Demultiplexao PW e Convergncia PSN, esperando que os mtodos de tunelamento
sobre a PSN, como L2TP ou MPLS, sejam providos pelas demais camadas inferiores.
A.3 - TIPOS DE FLUXOS DE DADOS NA ARQUITETURA PWE3

Os tipos de fluxos de dados (payloads) so classificados dentro dos seguintes grupos de

dados nativos, correspondentes aos tipos especficos de servio:

Pacotes Ethernet (todos), HDLC framing, Frame Relay, ATM AAL5 PDU;

Clulas ATM, de modo geral;

Fluxo de bits Feixes no estruturados E1, T1, E3, T3;

Fluxo estruturado de bits SONET/SDH.

A10

Cada um desses tipos caracterizado e tem suas funcionalidades particulares estabelecidas

pela RFC3985:
a) Dados em Pacotes

Um payload baseado em pacotes uma unidade de dados de tamanho varivel, entregue ao

Equipamento Provedor (PE) atravs do Circuito de Acesso (AC), que pode ser
relativamente grande quando comparado MTU da rede de pacotes. A definio dos
limites do pacote depende do encapsulamento utilizado, e na grande maioria das aplicaes
o overhead de transmisso, como os flags e stuffing bits do protocolo HDLC, eliminado
antes do encaminhamento atravs do pseudo-circuito.
Os pacotes so normalmente encaminhados atravs do pseudo-circuito como um nico
bloco. Entretanto, podem existir casos onde o tamanho combinado entre o pacote de dados
e os cabealhos PWE3 e PSN excede o MTU de um determinado caminho dentro da rede
de pacotes. Nestes casos, algum mtodo de fragmentao precisa ser aplicado, como
quando utilizada uma rede Ethernet para conexo ao provedor do servio PWE3, ou
quando esto envolvidos pseudo-circuitos aninhados.
Um fluxo de dados em pacotes pode necessitar de suporte para seqenciamento (nmeros
de seqncia), permitindo o controle da sua ordenao, ou de suporte para aplicaes em
tempo real.
Em algumas situaes, os pacotes podem ser selecionados a partir do universo de pacotes
apresentado ao circuito emulado, com base em alguma tcnica de multiplexao, para
compartilhamento do pseudo-circuito existente. Por exemplo, um ou mais PDUs Frame
Relay podem ser selecionadas para transporte sobre um pseudo-circuito particular com base
no identificador DLCI ou, em caso de pacotes Ethernet, pela utilizao de um filtro
adequado atravs da camada MAC (Media Access Control). Essa uma funo do mdulo
de encaminhamento, e portanto a seleo realizada antes do pacote ser entregue
Camada de Encapsulamento do pseudo-circuito, ou seja, na Camada de Demultiplexao.
b) Dados em Clulas

Um payload baseado em clulas criado pela captura, transporte e reproduo de grupos

de octetos apresentados ao circuito em um formato de tamanho fixo. A delimitao do
grupo de bits que compreende a clula especfica para o tipo de encapsulamento. Dois
exemplos comuns de clulas so as clulas de 53 octetos do ATM, e as grandes clulas de
188 octetos utilizadas no fluxo de transporte MPEG (Moving Picture Experts Group)
utilizado no padro europeu de TV Digital DVB (Digital Vdeo Broadcasting).
A11

Com o objetivo de reduzir o overhead em cada pacote encaminhado atravs da PSN,

mltiplas clulas podem ser concatenadas em um nico fluxo de dados. A Camada de
Encapsulamento pode considerar o pacote de dados completo ao fim de um determinado
intervalo de temporizao, aps um determinado nmero de clulas ser recebido ou quando
uma clula especial - uma clula ATM OAM (Operation and Maintenance), por exemplo for recebida. A vantagem de concatenar mltiplas PDUs deve ser ponderada pelo possvel
aumento na variao do atraso sofrido pelos pacotes e pelo maior potencial de perda de
dados em caso de perda de pacotes. Em alguns casos, para minimizar esse impacto e
melhorar o desempenho do pseudo-circuito, pode ser apropriado para a Camada de
Encapsulamento implementar algum tipo de compresso, tal como supresso de silncio e
compresso de voz.
Esse servio de transporte sob a forma de clulas normalmente necessita de suporte para
seqenciamento e tambm pode necessitar de suporte para aplicaes em tempo real, mas
usualmente no necessita de fragmentao, podendo implementar algum tipo de
compresso, como a supresso de clulas vazias.
Em algumas situaes, as clulas a serem incorporadas ao fluxo de dados podem ser
selecionadas por filtragem a partir do fluxo de clulas apresentado ao circuito emulado. Por
exemplo, um servio ATM PWE3 pode selecionar clulas para transporte sobre um
pseudo-circuito com base em seus campos VCI ou VPI.
Essa uma funo do mdulo de encaminhamento, e portanto a seleo realizada antes
do pacote ser entregue Camada de Encapsulamento do pseudo-circuito, ou seja, na
Camada de Demultiplexao.
c) Dados em Fluxo de Bits

Um payload baseado em fluxo de bits criado pela captura, transporte e reproduo de

padres de bits sobre o circuito emulado, sem obter vantagens a partir de qualquer
estruturao que, atravs de inspeo, possa estar disponvel dentro do trfego
transportado; ou seja, a estrutura interna do fluxo no tem efeito sobre a fragmentao em
pacotes.
Esse servio baseado em fluxo de bits necessita de suporte para seqenciamento e para
aplicaes em tempo real.
Em algumas situaes, possvel aplicar supresso ao fluxo de bits. Por exemplo, E1 e T1
enviam sempre uns para indicar falha. Essa condio pode ser detectada sem nenhum
conhecimento pr-determinado da estrutura do fluxo de bits, e a transmisso desses dados
pode ser suprimida.
A12

d) Dados em Fluxo Estruturado de Bits

Um payload baseado em fluxo estruturado de bits criado pelo uso de algum tipo de
conhecimento da estrutura interna do fluxo de bits para captura, transporte e reproduo de
padres de bits sobre o circuito emulado.
Duas importantes caractersticas distinguem os fluxos de bits estruturados, com relao aos
fluxos no-estruturados:
Algumas componentes do fluxo de bits original podem ser eliminadas na direo de origem
(PE-bound) por um bloco NSP. Por exemplo, em um fluxo SONET estruturado, os
overheads de seo e linha (e, possivelmente, mais), podem ser eliminados, atravs de um
bloco montador/desmontador de quadros. Esse bloco tambm necessrio para
alinhamento de quadros em aplicaes com feixes E1/T1 fracionrios;
O pseudo-circuito deve preservar a estrutura atravs da rede de pacotes, de forma que o
bloco NSP na direo de destino (CE-bound) possa inseri-la corretamente dentro do fluxo
de bits no-estruturado reconstrudo. A informao eliminada (como justificaes de
ponteiro SONET) pode aparecer na Camada de Encapsulamento para facilitar essa
reconstituio.
Esse servio baseado em fluxo estruturado de bits necessita de suporte para
seqenciamento e para aplicaes em tempo real, podendo implementar na Camada de
Encapsulamento, como opo, a supresso de silncio/bits ociosos ou compresso similar.
Os fluxos estruturados de bits so distintos dos fluxos de dados em clulas, pois as suas
estruturas podem ser grandes demais para serem transportadas em um nico pacote.
Quando essas estruturas so pequenas, a distino desaparece, podendo ser utilizados no
transporte os mesmos mtodos desenvolvidos para os fluxos de dados em clulas.
A.4 - PILHA DE PROTOCOLOS NA ARQUITETURA PWE3

O Modelo de Referncia para a pilha de protocolos de um pseudo-circuito emulado fim a

fim, como estabelecida na RFC3985, ilustrado na Figura A.4, seu objetivo reduzir as
diferenas entre pseudo-circuitos estendidos sobre diferentes tipos de redes de pacotes
[WEIHUA2003]. O pseudo-circuito prov ao Equipamento Cliente (CE) uma conexo
emulada fsica ou virtual desde a sua porta de sada at o destino remoto. As PDUs nativas
provenientes do CE de origem so entregues Camada de Encapsulamento no
Equipamento Provedor (PE) de origem e ento encaminhadas atravs do tnel formado
A13

dentro da rede de pacotes. O PE de destino remove o encapsulamento e restaura as PDUs

ao seu formato nativo para transmisso ao CE de destino.

Servio Emulado
(TDM, ATM, etc)

Servio Emulado

Servio Emulado
(TDM, ATM, etc)

Encapsulamento
do Fluxo de Dados

Pseudo-Circuito

Encapsulamento
do Fluxo de Dados

Tnel PSN

Demultiplexador PW
Tnel sobre a PSN
PSN
Camadas Fsicas

Demultiplexador PW
Tnel sobre a PSN
PSN
Camadas Fsicas

Rede de Pacotes

Figura A.4 - Modelo de referncia para a pilha de protocolos PWE3.

A seguir so detalhadas as caractersticas da Camada de Encapsulamento e o papel das
camadas inferiores na implementao de um pseudo-circuito atravs da Arquitetura PWE3:
a) Camada de Encapsulamento:
A Camada de Encapsulamento prov a infra-estrutura necessria para adaptar o tipo
especfico de fluxo de dados que est sendo transportado atravs do pseudo-circuito s
condies esperadas pela Camada de Demultiplexao PW utilizada para estabelecer esse
pseudo-circuito atravs da rede de pacotes, sendo constituda de trs subcamadas, conforme
apresentado na Figura A.5:

Convergncia do Fluxo de Dados;

Seqenciamento;

Sincronizao.

A14

Fluxo de Dados
(payload)
Convergncia do Fluxo de Dados

(payload convergence)
Sincronizao
(timing)

Encapsulamento
(encapsulation)

Seqenciamento
(sequencing)

Demultiplexao PW
(PW demultiplexer)
Convergncia PSN
(PSN convergence)
Rede de Pacotes
(packet-switching)
Enlace
(data-link)
Fsica
(physical)

Figura A.5 - Detalhamento da camada de encapsulamento PWE3.

A subcamada de Convergncia do Fluxo de Dados fortemente ajustada ao tipo especfico
de fluxo de dados, de forma que desejvel agrupar um certo nmero de tipos desejados de
fluxo em uma classe genrica e estabelecer um nico tipo de subcamada de convergncia
para esse grupo, limitando o nmero de tipos de subcamada necessrios e reduzindo a
complexidade de implementao. A sinalizao por pacote ou qualquer outra informao
do tipo fora da faixa (out-band), exceto sincronizao e seqenciamento, deve ser
provida por essa camada.
As subcamadas de Sincronizao e Seqenciamento provm servios para a subcamada de
Convergncia do Fluxo de Dados para todos os tipos de fluxo onde existe essa necessidade.
a.1) Subcamada de Convergncia do Fluxo de Dados:
O objetivo principal dessa subcamada o encapsulamento do fluxo de dados dento das
PW-PDUs. As PDUs nativas a serem encapsuladas podem conter cabealhos introduzidos
pelas camadas 1 e 2 do servio emulado, necessrias para a conectividade original de forma
especfica para cada servio,

enquanto o cabealho da subcamada de Convergncia do

Fluxo de Dados carrega a informao adicional necessria para reproduzir essas PDUs
nativas para a interface fsica do CE de destino. Nem todas as informaes adicionais
A15

necessrias para reproduzir as PDUs nativas precisam ser transportadas no cabealho das
PW-PDUs, uma vez que algumas informaes (como, por exemplo, o tipo de pseudocircuito) podem ser armazenadas como informaes de estado no PE de destino durante o
estabelecimento do pseudo-circuito.
A Camada de Encapsulamento e sua sinalizao associada necessitam de um ou mais dos
quatro tipos seguintes de canais, a serem providos pelas camadas inferiores de
Demultiplexao PW e da PSN, sendo necessrios um canal do tipo 1 e um ou mais
canais dos tipos 2, 3 e 4:
Tipo 1: Um canal de controle confivel para sinalizao de eventos de linha, indicao de

estado e, em casos excepcionais, eventos entre os CEs que necessitem ser

convertidos e transmitidos de forma confivel entre os PEs. PWE3 pode necessitar
deste tipo de canal de controle para prover emulao confivel de protocolos de
enlace mais complexos.
Tipo 2: Um canal seqencial de alta prioridade, no confivel, para uso tpico na

sinalizao entre os CEs. A alta prioridade pode ser indicada simplesmente atravs
dos bits DSCP (Differentiated Services CodePoint) no protocolo IP ou dos bits
EXP (Expedited) no MPLS, dando prioridade ao pacote durante a transmisso.
Esse canal pode ser indicado por uma classe diferenciada, para indicar que os
pacotes recebidos pelo PE devem ser processados com maior prioridade.
Tipo 3: Um canal seqencial comum, para o trfego de dados sensveis reordenao de

pacotes, como qualquer trfego no-IP.

Tipo 4: Um canal no seqencial, para o trfego de dados insensveis ordem dos pacotes,

como datagramas IP.

Os canais de dados (tipos 2, 3 e 4) devem ser transportados nas PW-PDUs de dados (inband), estendendo esse conceito o tanto quanto possvel para uma rede de pacotes. Onde
possvel, desejvel que sejam empregados mecanismos de suporte Qualidade de
Servio, usualmente designada QoS (Quality of Service) na transmisso das PW-PDUs
atravs da rede de transporte comutada em modo pacotes.
Nos casos em que a conectividade fim a fim possa ser interrompida por ns NAT (Network
Address Translation) , listas de controle de acesso, firewalls, etc. o canal de controle deve
A16

estar apto a manter a conectividade e estabelecer o pseudo-circuito, apesar do trfego de

dados ser bloqueado por um ou mais desses mecanismos. Nesses casos, a menos que o
canal de controle seja transportado no mesmo pseudo-circuito dos dados (in-band), a
sinalizao para estabelecimento de um pseudo-circuito no confirmar a existncia de um
caminho de dados fim a fim. Em alguns casos, existe ainda a necessidade de sincronizar
eventos CE com os dados transportados no pseudo-circuito. Esse especialmente o caso
dos circuitos TDM, onde eventos do tipo no gancho/fora do gancho nos comutadores da
RTFC (Rede Telefnica Fixa Comutada) precisam ser transportados atravs um canal de
controle confivel enquanto o fluxo de bits associado transportado atravs de um canal
seqencial de dados.
As Subcamadas de Seqenciamento Sincronizao so opcionais e somente utilizadas
quando um servio emulado em particular necessita dos respectivos servios oferecidos.
Caso contrrio, o cabealho associado pode ser omitido a fim de preservar recursos de
processamento e da prpria rede.
Algumas vezes, um tipo especfico de fluxo de dados ir demandar o transporte com ou
sem seqenciamento e/ou suporte para aplicaes em tempo real. Por exemplo, uma
garantia do transporte em servios Frame Relay a preservao da ordem dos pacotes, de
forma que muitas aplicaes que o utilizam esperam a entrega dos mesmos em ordem e no
esto preparadas para realizar, por si mesmas, a reordenao dos quadros, sendo
fundamental que o servio de seqenciamento seja provido pelo pseudo-circuito emulado.
Contudo, caso o servio Frame Relay seja utilizado somente para transportar trfego IP,
pode ser desejvel ignorar essa necessidade a fim de reduzir o custo de processamento por
pacote.
O princpio bsico que, sempre que possvel, um protocolo IETF existente deve ser usado
para prover estes servios. Quando um protocolo adequado no estiver disponvel, o
protocolo existente deve ser estendido ou modificado para atingir os requisitos PWE3,
tornando-o ento disponvel para outras utilizaes dentro do IETF.
a.2) Subcamada de Seqenciamento:
A Subcamada de Seqenciamento deve prover trs servios: ordenao de quadros,
deteco de quadros duplicados e deteco de perda de quadros. Esses servios permitem a
A17

emulao das propriedades intrnsecas de um circuito fsico, e o suporte a esses servios

pode ser omitido da implementao PWE3 caso no seja necessrio.
O tamanho da faixa de nmeros de seqncia depende da velocidade do servio emulado e
da durao mxima das condies transientes dentro da rede transporte comutada em
pacotes utilizada. Uma faixa superior a 216 (65.536) pode, portanto, ser necessria para
evitar a sobreposio de nmeros de seqncia durante a durao dessa condio que
representa o tempo de vida do pacote, tipicamente o atraso mximo sofrido pelo mesmo
dentro da rede na transmisso fim a fim, considerado como a metade do RTT (Round-Trip
Time) mximo medido na rede para os ns de origem e destino (PEs) do pseudo-circuito.
a.2.1) Ordenao de Quadros:
Quando pacotes transportando as PW-PDUs atravessam uma rede de pacotes, podem
naturalmente chegar fora de ordem ao PE de destino. Para alguns servios, os quadros (de
controle, dados ou ambos) devem ser entregues em ordem, de forma que algum mecanismo
deve ser implementado para assegurar a entrega na ordem, da mesma forma que no servio
nativo. Definir um nmero de seqncia no cabealho da Subcamada de Seqenciamento
de cada pacote uma das aproximaes possveis. Alternativamente, pode-se observar que
o seqenciamento uma parte do problema da entrega de pacotes para aplicaes em
tempo real, e um nico mecanismo combinado como o protocolo RTP (Real Time
Protocol), definido pela RFC3550 [RFC3550] , poderia ser empregado.
Existem duas estratgias possveis para assegurar a ordenao dos quadros:

Descartar as PW-PDUs recebidas fora da ordem esperada;

Tentar classificar as PW-PDUs recebidas, na ordem correta.

A escolha da estratgia mais adequada a um determinado servio emulado atravs de um

pseudo-circuito PWE3 depender de alguns fatores, tais como:

Criticidade da perda de pacotes para a operao do pseudo-circuito, determinada, por

exemplo, pela taxa de erros de bit, ou BER (Bit Error Rate) aceitvel;

Velocidades do pseudo-circuito e da rede de transporte comutada em modo pacotes

utilizada;

A18

Atraso aceitvel para os pacotes, uma vez que mais atraso precisa ser introduzido para
permitir a reordenao;

A incidncia esperada de pacotes recebidos fora de ordem.

a.2.2) Deteco de Quadros Duplicados:

Em alguns casos raros, os pacotes transportando as PW-PDUs podem ser duplicados pela
rede de pacotes sobre a qual estabelecido o pseudo-circuito. Para alguns servios, isso
no aceitvel, sendo necessria a implementao de algum mecanismo que assegure que
os quadros duplicados no sero entregues ao CE de destino. Esse mecanismo pode ser o
mesmo empregado para assegurar a entrega de quadros na ordem correta.
a.2.3) Deteco de Perda de Quadros:
O Equipamento Provedor (PE) de destino pode determinar quando um quadro foi perdido
pelo rastreamento dos nmeros de seqncia das PW-PDU recebidas. Em algumas
implementaes, se uma PW-PDU no entregue at o instante de tempo correto, o PE de
destino ir presumir que a mesma foi perdida. Caso essa PW-PDU processada como
perdida seja entregue posteriormente, ela deve ser simplesmente descartada pelo PE de
destino.
a.3) Subcamada de Sincronizao:
A Subcamada de Sincronizao prov os servios necessrios para reproduzir, da forma
mais prxima possvel, as caractersticas de sincronizao projetadas para as redes onde os
servios nativos seriam transmitidos, uma vez que um grande nmero desses servios tem
expectativas de sincronizao baseadas nessas redes.
Essa camada, fundamental para diversos servios emulados, deve permitir a entrega do
trfego nativo com uma taxa de transmisso de bits (bit rate), um atraso percebido pelos
quadros (delay), uma variao mxima desse atraso (jitter) e uma flutuao de relgio
(wander) similar quela recebida pelo Equipamento Provedor (PE) de origem a partir do
Equipamento Cliente (CE) de origem.
Nestes casos, o PE de destino deve reproduzir o trfego nativo exatamente como ele foi
recebido pelo PE de origem. Isso implica no encaminhamento da informao de
A19

sincronizao entre os dois PEs, ou, em alguns casos, no seu recebimento a partir de uma
referncia externa.
Portanto, a Subcamada de Sincronizao deve prover dois servios: recuperao de relgio
e sincronizao do fluxo de dados reproduzido, ou seja, entrega de cada quadro no
intervalo de tempo esperado pelo servio nativo. Cada servio especfico emulado atravs
de um pseudo-circuito pode necessitar de um deles ou de ambos simultaneamente.
a.3.1) Recuperao de Relgio:
A Recuperao de Relgio a extrao da informao de temporizao, ou relgio,
utilizada na transmisso do fluxo de bits de sada do PE para o CE de destino, tendo como
base o fluxo de pacotes entregue pela PSN a esse PE de destino, e necessita de um
mecanismo adequado. Um circuito fsico carrega a informao de relgio de forma
intrnseca, mas a sua extrao a partir de uma fonte altamente afetada pelo jitter, como um
fluxo de pacotes, uma tarefa relativamente complexa. Assim, desejvel que um
protocolo existente para suporte a aplicaes em tempo real, como o RTP, seja utilizado
com esse propsito, a menos que possa ser demonstrado que o mesmo inadequado ou
desnecessrio para um tipo particular de fluxo de dados.
a.3.2) Sincronizao do Fluxo de Dados Reproduzido:
A Sincronizao do Fluxo de Dados Reproduzido a entrega das PW-PDUs no adjacentes
recebidas atravs da PSN interface de sada do pseudo-circuito, com um atraso constante
em relao interface de entrada do mesmo, a fim de preservar a sincronizao do fluxo de
dados para o servio nativo. A temporizao dessa entrega pode ser relativa a um relgio
recuperado a partir do fluxo de pacotes recebido atravs da PSN, ou relativa a um relgio
externo.
a.4) Fragmentao:
O ultimo aspecto associado Camada de Encapsulamento diz respeito Fragmentao:
Nas condies ideais, um fluxo de dados seria transmitido atravs do pseudo-circuito em
uma nica PW-PDU. Entretanto, existiro casos onde o tamanho combinado do fluxo de
dados e seus cabealhos PWE3 e PSN associados excedero a MTU de um determinado
caminho dentro da rede de transporte comutada a pacotes. Quando o tamanho do pacote
excede a MTU de uma dada rede, a fragmentao e posterior remontagem precisam ser
A20

implementadas para que esse pacote seja entregue. Uma vez que ambas as operaes
consomem considerveis recursos adicionais da rede, quando comparadas simples
comutao de um pacote inteiro, a necessidade de fragmentao e remontagem ao longo da
rede deve ser reduzida ou eliminada tanto quanto possvel, sendo uma preocupao
particular em pontos de agregao onde um grande nmero de pseudo-circuitos so
processados, como por exemplo nos PEs.
No caso ideal, o equipamento de origem do trfego encaminhado atravs do pseudocircuito possui mecanismos locais adaptativos para assegurar que pacotes com necessidade
de fragmentao no sejam enviados. Quando isso no acontece, o ponto mais prximo do
n de origem dentro da rede, dotado de capacidade para fragmentao e remontagem, deve
tentar reduzir o tamanho dos pacotes a fim de satisfazer MTU da PSN. Portanto, no
Modelo de Referncia PWE3 apresentado na Figura 2.1, a fragmentao deve ser
primeiramente realizada no CE de origem, se possvel. Somente quando o CE no possa
garantir um tamanho aceitvel para a MTU do pseudo-circuito, o PE de origem deve tentar
o seu prprio mtodo de fragmentao.
Nos casos onde o gerenciamento da MTU falha em limitar o fluxo de dados a um tamanho
adequado para transmisso pelo pseudo-circuito, o PE pode assumir tanto um mtodo
genrico de fragmentao da PW-PDU como, se disponvel, utilizar o servio de
fragmentao da PSN das camadas inferiores, sendo aceitvel uma implementao PE sem
suporte fragmentao, que simplesmente descarte os pacotes que excedem a MTU da
rede de pacotes, notificando essa ocorrncia ao Plano de Gerncia do Equipamento
Provedor (PE) de origem.
Caso o comprimento de um quadro das camadas 1 e 2 no PE de destino, restaurado a partir
de uma PW-PDU, exceda a MTU do Circuito de Acesso (AC) de destino, ele deve ser
descartado. Neste caso, o Plano de Gerncia do Equipamento Provedor (PE) de destino
pode ser notificado.
b) Demais Camadas inferiores:
A Arquitetura PWE3 apresenta trs requisitos de servio s camadas inferiores de
protocolo utilizadas para transportar os pseudo-circuitos atravs de uma rede de transporte
comutada em modo pacotes:
A21

Multiplexao, implementada na Camada de Demultiplexao PW;

Fragmentao;

Entrega e Informao de Comprimento das PW-PDUs.

b.1) Camada de Demultiplexao dos Pseudo-Circuitos (PW):

O objetivo da Camada de Demultiplexao PW permitir que mltiplos pseudo-circuitos
sejam carregados em um nico tnel, a fim de reduzir complexidade e preservar recursos.
Alguns tipos de servios nativos so capazes de agrupar mltiplos circuitos em um nico
tronco, como por exemplo mltiplos ATM VCs (Virtual Circuits) em um VP (Virtual
Path), mltiplas Ethernet VLANs em um nico meio fsico ou mltiplos feixes
independentes DS0 (64 kbps) em um nico feixe T1 ou E1. Um pseudo-circuito pode
realizar a interconexo entre esses troncos, e cada um dos circuitos nele contidos teria seu
prprio identificador de multiplexao.
b.2) Fragmentao:
Caso a rede de pacotes possa prover os servios de fragmentao e remontagem com
performance adequada, ela pode ser utilizada para obteno de um MTU efetivo grande o
bastante para transportar as PW-PDUs, conforme discutido anteriormente.
b.3) Camada de Rede (PSN):
A entrega das PW-PDUs ao Equipamento Provedor (PE) de destino um servio da
Camada de Rede, no caso, da rede de transporte comutada em modo pacotes. Da mesma
forma, a informao de comprimento dessa PW-PDU carregada no cabealho PSN. Caso
a Camada de Rede inferior no provenha toda a informao necessria para determinar o
comprimento de uma PW-PDU, a Camada de Encapsulamento deve prov-la.
A.5 - DETECO DE ERROS EM PWE3

uma prtica comum utilizar algum mecanismo de deteco de erros para validao das
PW-PDUs, tal como um Cdigo de Redundncia Cclica,

CRC (Cyclic Redundancy

Checks) ou um algoritmo verificador similar, conhecido genericamente como checksum

para assegurar a integridade fim a fim dos quadros. Os mecanismos especficos de cada
servio emulado atravs do pseudo-circuito devem definir quais checksums dos pacotes
A22

devem ser preservados atravs do pseudo-circuito e quais devem ser removidos das PWPDUs no PE de origem e recalculados para insero, pelo PE de destino, dentro do fluxo de
dados encaminhado para o CE de destino.
A primeira hiptese minimiza o processamento, enquanto a ltima economiza largura de
banda. Para uma dada implementao, a escolha pode ser ditada por restries de
hardware, que pode no permitir a preservao do checksum ao longo do pseudo-circuito.
Para protocolos como ATM e Frame Relay, a abrangncia do checksum est restrita a um
nico enlace, uma vez que os identificadores de circuito DLCI (Frame Relay) e VPI/VCI
(ATM) tm apenas significado local e mudam a cada salto. Caso o identificador do circuito
(e, portanto, o checksum) deva mudar em funo de um salto atravs do pseudo-circuito,
seria mais eficiente elimin-lo e recalcular o checksum no destino.
O documento que define o servio especfico para cada protocolo deve descrever o
esquema de validao das PW-PDUs a ser utilizado.
A.6 - CONGESTIONAMENTO EM PWE3

A rede de pacotes que transporta o pseudo-circuito pode estar sujeita a congestionamento,

cujas caractersticas podem variar de acordo com o tipo de rede, sua arquitetura e
configurao, bem como com a carga oferecida mesma.
Caso o trfego transportado atravs do pseudo-circuito seja conhecido (atravs de inspeo
nos pacotes, por exemplo) e de caracterstica TCP-amigvel, ou seja, baseado no
protocolo TCP (Transmission Control Protocol), que permite retransmisso, o descarte de
pacotes pela rede ir promover a reduo necessria na carga oferecida rede, e nenhuma
ao adicional para evitar congestionamento necessria.
Caso o pseudo-circuito esteja estabelecido sobre uma rede de pacotes que provenha
servios de entrega mais confiveis, como DiffServ, o PE de destino deve monitorar a
perda de pacotes para assegurar que o servio requisitado est realmente sendo oferecido.
Caso no esteja, o PE deve assumir que a PSN est provendo um servio de melhor
esforo, ou BE (Best-Effort) e utilizar as medidas correspondentes para evitar
congestionamento, descritas a seguir.
A23

Caso um servio BE esteja sendo usado e o trfego no seja conhecido como TCPamigvel, o PE de destino deve monitorar a perda de pacotes para assegurar que a taxa de
perdas encontra-se dentro do limite aceitvel. A perda de pacotes considerada aceitvel se
um fluxo de pacotes TCP atravs do mesmo caminho de rede e experimentando as mesmas
condies atingiria uma vazo mdia, medida em escala de tempo razovel, no inferior
quela que o fluxo do pseudo-circuito est atingindo. Essa condio pode ser satisfeita pela
implementao de medidas de limitao de taxa de transmisso no NSP, ou pela
desconexo de um ou mais pseudo-circuitos, dependendo do tipo de trfego que est sendo
transportado. Quando o congestionamento evitado pela desconexo de um pseudocircuito, um mecanismo adequado deve ser implementado para evitar que o mesmo retorne
imediatamente ao servio, causando uma srie de picos de congestionamento.
A comparao ao TCP no pode ser especificada exatamente, mas pretende estabelecer
uma ordem de grandeza em termos de vazo e escala de tempo, estabelecida como o
intervalo de ida e volta de um pacote, ou RTT (Round-Trip Time) numa conexo fim a fim.
Em essncia, esse requisito estabelece que no aceitvel implantar uma aplicao, usando
PWE3 ou qualquer outro protocolo de transporte, na Internet baseada no melhor esforo,
quando este consome largura de banda de forma arbitrria e no compete de forma justa
com os pacotes TCP na mesma ordem de magnitude.
A.7 - PLANO DE CONTROLE DA ARQUITETURA PWE3

Como aspecto final abordado na Arquitetura PWE3, temos o Plano de Controle, que define
o estabelecimento e desconexo de pseudo-circuitos. Um pseudo-circuito deve ser
estabelecido antes que um servio emulado possa ser estabelecido e deve ser desconectado
quando o servio emulado no for mais necessrio.
O estabelecimento e desconexo de um pseudo-circuito pode ser provocando por um
comando manual a partir do Plano de Gerncia de um Equipamento Provedor (PE), pela
sinalizao de estabelecimento ou desconexo de um Circuito de Acesso (AC), como por
exemplo um quadro ATM SVC (Signaling Virtual Channel), ou por um mecanismo de
auto-descoberta.

A24

Durante o processo de estabelecimento, os PEs precisam trocar informaes, como a

apresentao das capacidades de cada um, de forma que um tnel de sinalizao precisa ser
estendido para prover os mecanismos que habilitem os PEs a trocar todas as informaes
necessrias no interesse do pseudo-circuito a ser estabelecido. A configurao manual dos
pseudo-circuitos considerada um tipo especial de sinalizao e permitida na Arquitetura
PWE3.
A.8 - IMPLEMENTAO DA ARQUITETURA PWE3 SOBRE IP

Considerando que a definio da Arquitetura PWE3 deve empregar os protocolos IETF

onde possvel, a Figura A.6 apresenta uma implementao sobre uma rede de pacotes
baseada no protocolo IP, descrevendo a arquitetura de protocolos IETF utilizados em cada
uma das camadas estabelecidas pelo modelo de referncia da pilha de protocolos.

Fluxo de Dados
(payload)

Fluxo limpo, se possvel

Convergncia do Fluxo de Dados

(payload convergence)

Flags, nmero seqncia, etc.

Sincronizao
(timing)
Seqenciamento
(sequencing)

RTP
um dos
dois

Demultiplexao PW
(PW demultiplexer)

L2TP, MPLS, etc.

Convergncia PSN
(PSN convergence)

(no necessria)

Rede de Pacotes
(packet-switching)

IP

Enlace
(data-link)

Enlace
(data-link)

Fsica
(physical)

Fsica
(physical)

Figura A.6 - Arquitetura PWE3 sobre uma rede IP.

Como regra, o fluxo de dados deve ser transportado da forma como recebido do servio
nativo, com a adequao pela Subcamada de Convergncia do Fluxo de Dados, quando
necessrio. Contudo, em certas circunstncias pode ser justificvel transmitir esse fluxo
aps alguma forma de processamento, cujas razes devem estar descritas na definio da
Camada de Encapsulamento para o tipo especfico de fluxo de dados.
A25

Onde apropriado, a sincronizao explcita implementada pelo protocolo RTP que,

quando utilizado, tambm prov o servio de seqenciamento. Quando a rede de pacotes
UDP/IP (User Datagram Protocol/Internet Protocol), o cabealho RTP segue o cabealho
UDP e precede o cabealho PW. Para todos os outros casos o cabealho RTP segue o
cabealho PW. A Camada de Encapsulamento pode, adicionalmente, conter um nmero de
seqncia, de forma que o seqenciamento pode ser provido tanto pelo RTP como pela
Camada de Encapsulamento, mas no por ambos.
A Camada de Demultiplexao PW provida pela etiqueta PW, que pode assumir
formatos especficos em um grande nmero de protocolos IETF: uma etiqueta MPLS, um
Session ID L2TP ou uma porta UDP. Quando o pseudo-circuito transportado atravs de
uma rede IP, nenhuma Camada de Convergncia PSN necessria. No caso especial onde
a Camada de Demultiplexao PW uma etiqueta MPLS, pode ser usada a arquitetura de
protocolos apresentada na Figura A.7, em substituio quela apresentada na Figura A.6.

Fluxo de Dados
(payload)
Convergncia do Fluxo de Dados
(payload convergence)
Sincronizao
(timing)

RTP

Seqenciamento
(sequencing)

Flags, nmero seqncia,

fragmentao, comprimento,etc.

Demultiplexao PW
(PW demultiplexer)

Etiqueta interna PW

Convergncia PSN
(PSN convergence)

Etiqueta externa ou
encapsulamento MPLSoIP

Rede de Pacotes
(packet-switching)
Enlace
(data-link)
Fsica
(physical)

Figura A.7 - Arquitetura PWE3 sobre rede MPLS com palavra de controle.
Como pode ser observado na Figura A.7, o uso de MPLS agrega eficincia ao circuito
emulado, uma vez que diversos componentes das camadas da Arquitetura PWE3 podem
ser comprimidos para aumentar essa eficincia.

A26

Uma etiqueta MPLS interna usada para prover a funo da Camada de Demultiplexao
PW, enquanto uma Palavra de Controle, ou CW (Control Word) utilizada para transportar
a maior parte das informaes necessrias para as Camadas de Encapsulamento e de
Convergncia PSN, em um formato compacto: Os flags na Palavra de Controle realizam a
convergncia necessria para o fluxo de dados, e um campo de nmero de seqncia
suporta tanto a entrega ordenada dos pacotes como o servio de fragmentao dentro da
Camada de Convergncia PSN (suportada por um mtodo de controle de fragmentao).
Contudo, a Ethernet alinha todos os quadros para o tamanho mnimo de 64 octetos, e o
cabealho MPLS no inclui um indicador de comprimento. Portanto, para permitir que
pseudo-circuitos PWE3 transportados em uma rede MPLS atravessem corretamente um
enlace Ethernet, um campo para correo de comprimento necessrio na Palavra de
Controle. Alm disso, como nas redes IP, a sincronizao implementada, quando
necessrio, pelo protocolo RTP.
Em algumas redes, pode ser necessrio transportar pseudo-circuitos PWE3 sobre MPLS
sobre IP. Nessas circunstncias, o pseudo-circuito encapsulado para transporte MPLS
como descrito, ento um mtodo de transporte de MPLS sobre redes IP aplicado PWPDU resultante.
Para redes MPLS, existe uma restrio adicional para o formato do pacote PW (PW-PDU):
Alguns roteadores detectam pacotes IP com base nos quatro bits iniciais do contedo do
pacote, de forma que, para facilitar a operao, esses bits na PW-PDU no devem ser
idnticos os nmeros de verso IP em uso corrente.

A27

A28

APNDICE B REQUISITOS PWE3

B.1 - REQUISITOS GERAIS PARA PWE3

A RFC3916 define PWE3, ou seja, a Emulao por Pseudo-Circuitos Fim a Fim como um
mecanismo que emula os atributos essenciais de um servio como ATM, Frame-Relay ou
Ethernet sobre uma rede de transporte em modo pacotes, estabelecendo que as funes
requeridas para os pseudo-circuitos incluem:
a) o encapsulamento das PDU (Protocol Data Units) especficas de cada servio que
chegam porta de ingresso na PSN, usualmente um roteador de borda da rede de
transporte em modo pacotes;
b) o transporte dessas PDU atravs de um caminho de rede ou tnel;
c) o gerenciamento da sincronizao e ordenao das PDU no destino;
d) quaisquer outras operaes necessrias para emular o comportamento e as
caractersticas do servio de forma to fiel quanto possvel.
A RFC3916 estabelece, ainda que, do ponto de vista do usurio, o pseudo-circuito deve ser
percebido como um enlace ou circuito dedicado do servio desejado, podendo, no entanto,
haver algumas deficincias que impedem algumas aplicaes de serem transportadas
atravs do pseudo-circuito, as quais devem estar completamente descritas nos documentos
especficos de cada servio.
O modelo de referncia estabelecido pela IETF na RFC3916, Figura B.1, define um
pseudo-circuito, ou pseudo-wire, da seguinte forma:
Pseudo-Wire (PW) uma conexo fim a fim entre dois equipamentos provedores do

servio emulado, ou PE (Provider Edges), conectados aos equipamentos dos clientes, ou

CE (Costumer Edges), atravs de circuitos de acesso dedicados, ou AC (Attachments
Circuits). Pode ser um enlace Frame Relay, um ATM VPI/VCI, uma porta Ethernet, uma
VLAN, um enlace HDLC, uma conexo PPP, um tnel L2TP, um LSP MPLS, etc.

A29

Servio Emulado
Pseudo-circuito
Tnel sobre PSN

PW1

CE1

Circuito de Acesso

Equipament
o Client 1
e

PE1
Equipament
oProvedor
1

Rede de Pacotes

PE2

PW2

Equipament
oProvedor
2

CE2

Circuito de Acesso

Equipament
o Cliente
2

Figura B.1 - Modelo de referncia PWE3.

Durante o estabelecimento de um pseudo-circuito (PW), os dois PE de origem e destino
so configurados ou trocam automaticamente informaes sobre o servio a ser emulado,
de forma a entender como os pacotes provenientes da origem e encaminhados ao destino
devem ser processados.
Depois que o PW estabelecido entre os dois PE, os quadros recebidos pelo PE de origem,
provenientes do CE de origem pelo circuito de acesso no servio nativo, so encapsulados
e encaminhados via pseudo-circuito atravs da rede de pacotes, at o PE remoto de destino,
onde os quadros nativos so reconstrudos e encaminhados pelo circuito de acesso at o CE
remoto de destino.
No cenrio original, a emulao de pseudo-circuitos um servio oferecido pelo provedor
da rede de transporte comutada a pacotes, atravs de um dispositivo de interoperabilidade,
ou IWF (InterWorking Functions), que aceita a conexo direta a partir do servio nativo,
utilizando a rede de pacotes apenas como backbone, como mostrado na Figura B.2.

A30

Servio Emulado
Pseudo-circuito
Tnel sobre PSN

CE1

Servi
oNativ
o
de
EquipamentCircuito
Acesso
o Cliente
1

IWF

PE1

Rede de Pacotes

Equipament
oProvedor
1

PW

PE2
Equipament
oProvedor
2

IWF

CE2

Servi
oNativ
o
Circuito
de Equipament
Acesso o Cliente
2

Figura B.2 - Cenrio original: pseudo-circuito PE a PE.

Essa abordagem apresenta duas vantagens principais:

No necessita de qualquer modificao/ investimento nos equipamentos do cliente;

A Responsabilidade de instalao/manuteno IWF do provedor do servio,

permitindo o compartilhamento dos IWF para atender a mltiplos clientes.

E duas grandes desvantagens potenciais:

Os custos do circuito de acesso, no servio nativo, continuam sob a responsabilidade do

cliente;

No permite o agrupamento de servios sobre uma mesma conexo, no ambiente do

cliente.

Dessa forma, esse cenrio torna-se mais adequado para clientes de pequeno porte, onde
existem poucas portas/filiais e o circuito de acesso ao provedor largamente disponvel ou
relativamente barato.
Com a evoluo do modelo PWE3, foi proposto um cenrio alternativo, onde a emulao
de pseudo-circuitos pode ser implantada pelo prprio cliente, que contrata um servio PSN
do provedor da rede de transporte comutada a pacotes, trazendo o dispositivo de
interoperabilidade, ou IWF (InterWorking Functions), para as suas prprias instalaes,
como mostrado na Figura B.3, eliminando as linhas dedicadas de acesso ao provedor.
A31

Servio Emulado
Pseudo-circuito
Tnel sobre PSN

CE1
Equipament
o Cliente
1

IWF

Acess
PSN

PE1

Rede de Pacotes
PW

Circuito de Equipament
Acesso oProvedor
1

PE2

Acess
PSN

IWF

EquipamentCircuito de
oProvedor
Acesso
2

CE2
Equipament
o Cliente
2

Figura B.3 - Cenrio alternativo: pseudo-circuito CE a CE.

Essa nova abordagem apresenta outras duas vantagens principais:

O acesso local em modo pacotes, tipicamente IP ou Metro Ethernet, em princpio

bem mais barato que uma linha dedicada TDM ou conexes FR e ATM;

Essa arquitetura oferece a possibilidade de agrupamento de diferentes servios sobre o

mesmo acesso, tipicamente dos servios de voz e vdeo com a interconexo da rede de
dados do cliente.

E uma desvantagem potencial:

A Responsabilidade de instalao/manuteno IWF do cliente, existindo

investimentos diretos em equipamentos.

Dessa forma, esse cenrio torna-se mais adequado para clientes corporativos ou de porte
mdio, onde existem muitas portas/filiais, uma vez que a conexo PSN pode ser
implementada de forma simples e integrada, utilizando, por exemplo, tecnologias xDSL.
Alm dessas definies e cenrios, a IETF estabelece alguns outros requisitos gerais para
as aplicaes PWE3, independentemente do tipo particular de servio que esteja sendo
emulado.

A32

Os requisitos de processamento de pacotes devem prever mecanismos para:

a) o encapsulamento dos quadros do servio nativo, correspondentes PDU

desse

servio, tipicamente envolvendo protocolos de camada 2 do modelo de referncia OSI,

de forma a possibilitar a sua transmisso atravs da PSN e a reconstruo das mesmas
no destino;
b) a reordenao de quadros do servio nativo, com base nos pacotes recebidos, sendo
sugerida a incluso de um nmero de seqncia no cabealho PW de cada pacote, a
RFC3916 define a necessidade desses mecanismos, mas considera que a sua
implementao foge ao escopo dos requisitos;
c) a eliminao de quadros duplicados antes da entrega dos dados ao servio nativo no
destino, que podem ser os mesmos utilizados para assegurar a reordenao dos quadros;
d) o controle de fragmentao, quando o quadro do servio nativo (payload) e os
cabealhos PW e da PSN propriamente dita excedem a MTU (Maximum Transmission
Unit) da rede de transporte em modo pacotes utilizada, gerando necessidade de
fragmentao do fluxo de dados, com impactos na performance do pseudo-circuito;
e) o controle do overhead por pacote encaminhado atravs da PSN, quando o quadro do
servio nativo (payload) relativamente pequeno, podendo ser agrupado em mltiplas
unidades dentro de um mesmo pacote para reduo do overhead introduzido pelo
cabealho da PSN, caracterstica que deve ser ponderada pelo impacto causado pelo
atraso de processamento para montagem/desmontagem dos pacotes e maior potencial
de perda de dados em caso de perda de pacotes.
Os requisitos de manuteno dos servios emulados so claramente definidos, devendo
prever mecanismos para:
a) o estabelecimento e desconexo de pseudo-circuitos para a emulao dos servios, que
pode ser provocado por um comando atravs do plano de gerncia do PE,
automaticamente pelo estabelecimento/desconexo de um circuito de acesso (AC), ou
por algum mecanismo de auto-descoberta; devendo prever a troca de informaes entre
os PE de origem e destino para esse estabelecimento e a coordenao entre os dois PW
criados, caso o circuito correspondente do servio nativo seja bidirecional;
b) o tratamento de mensagens de manuteno dos servios nativos;
c) a iniciao de mensagens de manuteno para o servio emulado, a partir do PE.

A33

Os requisitos de gerncia dos servios emulados so claramente definidos, devendo prever

mecanismos para:
a) criao, leitura e atualizao de MIB (Management Information Bases);
b) configurao e provisionamento dos canais de acesso;
c) monitorao de performance;
d) gerenciamento de falhas e notificaes;
e) verificao de conexo e rastreamento (traceroute) de pseudo-circuitos.
Os requisitos de fidelidade dos servios emulados so tambm abordados na RFC3916,
estabelecendo:
a) as caractersticas dos servios emulados que devem corresponder, de forma fiel, s
caractersticas dos servios nativos, tais como:
a.1) tipo, velocidade e MTU do servio emulado, que devem ser definidas para o
servio emulado, caso o sejam para o servio nativo;
a.2) transparncia, para os servios nativos emulados entre dois CE de origem e
destino, de um eventual compartilhamento de caminhos por dois pseudo-circuitos entre
dois PE de origem e destino, dentro da rede de pacotes;
a.3) garantia de notificao de ambos os CE do servio nativo em caso de falha do
circuito emulado, seja no trecho do PW, seja no trecho dos AC, caso essa notificao
exista no servio nativo;
a.4) transparncia, sobre os circuitos dos servios emulados, a protocolos de
roteamento que possam ser estabelecidos sobre os circuitos do servio nativo;
b) que no existe requisito de que os servios emulados devam prover a mesma qualidade
de servio que os servios nativos.
Alm desses requisitos, so realizadas na RFC3916 algumas breves consideraes sobre
Qualidade de Servio, ou QoS (Quality of Service), trfego inter-domnios e segurana.

A34

B.2 - REQUISITOS PARA PWE3 EMULANDO SERVIOS TDM

Os requisitos complementares aos definidos pela RFC3916 para a utilizao de pseudocircuitos emulando servios TDM, descritos na RFC4197, so os seguintes:
a) Transporte de informaes necessrias para reconstruo do fluxo no destino:
Para transporte sem conscincia de estrutura (SAT), essa funcionalidade pode ser
provida pela Camada de Fluxo de Dados;
Para transporte consciente de estrutura, a informao precisa ser provida pela
Camada de Encapsulamento;
Para transporte de circuitos SDH/SONET, deve ser preservado o overhead de
caminho como parte do fluxo de dados. Os componentes relevantes do overhead de
transporte podem ser carregados na Camada de Encapsulamento.
b) Suporte multiplexao e demultiplexao:
Deve existir caso essas funes sejam suportadas pelos servios nativos. Isso
relevante para NxDS0 circuitos (com ou sem sinalizao) e NxVT-x em um nico STS1 ou VC-4.
Para esses circuitos, a combinao entre as Camadas de Encapsulamento e Fluxo de
Dados deve prover tratamento separado para cada sub-circuito;
O pseudo-circuito deve prover suficiente informao para permitir multiplexao e
demultiplexao pelo prprio NSP. A reduo de complexidade da emulao PWE3
atravs do uso das capacidades do NSP para esse fim pode ser a soluo preferencial.
c) Interpretao ou transferncia transparente de mensagens de manuteno:
Quando geradas pelos servios nativos, dependendo do cenrio em particular.
d) Deteco e tratamento de defeitos no pseudo-circuito.
e) Fragmentao:
Indicaes de fragmentao podem ser utilizadas quando excedem o atraso de
empacotamento desejado e/ou a MTU da rede entre PEs de origem e destino. Contudo,
o suporte a PDUs de tamanho varivel [RFC3916], no aplicvel emulao TDM.
f) Seqenciamento:
Esse servio deve ser provido pela Camada de Encapsulamento, associado a servios de
sincronizao quando necessrios. A informao de comprimento da PW-PDU tambm
pode ser provida por essa camada, mas no necessria para servios TDM.

A35

g) Adaptao do Fluxo de Dados:

Caso necessrio, pode ser utilizada alguma forma de adaptao do fluxo TDM nativo, a
fim de atingir objetivos especficos e bem documentados, devendo ser utilizadas
tcnicas padronizadas de adaptao.
h) Conectividade:

A emulao deve suportar o transporte de sinais entre Circuitos de Acesso (ACs) de

mesmo tipo e, sempre que apropriado, mesma taxa de transmisso.

A Camada de Encapsulamento no deve ser afetada caractersticas particulares de

conexo entre o Circuito de Acesso (AC) e o Equipamentos Provedor (PE), em
ambas as extremidades do pseudo-circuito.

i) Sincronizao:
A Camada de Encapsulamento deve prover servio de sincronizao suficiente para:

Alinhar os relgios de origem e destino do servio emulado, sem considerar o

cenrio especfico de sincronizao da rede;

Manter o jitter e o wander do relgio de destino do servio emulado dentro dos

limites especficos definidos pelas referncias normativas apropriadas;

Caso uma mesma fonte de sincronismo de alta preciso esteja disponvel para todos os
PEs de um determinado domnio, a Camada de Encapsulamento deve ser capaz de fazer
uso disso para recuperao do relgio do servio nativo.
j) Robustez:
A robustez do servio emulado depende no apenas do protocolo PWE3, mas tambm
da implementao adequada dos seguintes procedimentos:
j.1) Controle da perda de pacotes:
A emulao fim a fim de circuitos TDM pressupe baixa probabilidade de perda de
pacotes entre os PEs de origem e destino, no sendo requerido nenhum mecanismo
de retransmisso.
Para minimizar o efeito da perda de pacotes, a Camada de Encapsulamento deve:

Habilitar a interpretao independente dos dados TDM em cada pacote pelo PE

de destino;

Permitir deteco confivel dos pacotes perdidos, estimando o intervalo de

chegada do prximo pacote e baseando a deteco nessa estimativa;

Minimizar possveis efeitos da perda de pacotes na recuperao do relgio do

circuito pelo PE de destino;
A36

Aumentar a resilincia da interface TDM do CE perda de pacotes, permitindo

a substituio, pelo PE de destino, dos dados apropriados.

j.2) Tratamento da entrega de pacotes fora de ordem:

A Camada de Encapsulamento deve prover os mecanismos necessrios para
garantir a entrega ordenada de pacotes que estejam transportando dados TDM sobre
a rede. Os pacotes que chegam ao PE de destino fora da ordem devem:

Ser corretamente detectados;

Ser reordenados, caso no sejam recebidos tarde ou cedo demais para a

reproduo no fluxo TDM encaminhado ao CE;

Ser tratados como perdidos, caso no possam ser reordenados.

k) Sinalizao de aplicaes CE:

Circuitos TDM no estruturados normalmente no necessitam de qualquer mecanismo
especial para transporte da sinalizao do Equipamento Cliente (CE), uma vez que esta
transportada como parte do servio emulado. Contudo, algumas aplicaes CE
envolvendo circuitos TDM estruturados, como telefonia, precisam de sinalizao
especfica para indicao das mudanas de estado dessas aplicaes com relao ao
fluxo TDM.
A Camada de Encapsulamento deve suportar a sinalizao de estado das aplicaes CE
para os circuitos relevantes, envolvendo:

Capacidade de suportar diferentes esquemas de sinalizao com mnimo impacto

sobre o encapsulamento do fluxo TDM;

Multiplexao de sinais especficos da aplicao CE e dados do servio TDM no

mesmo pseudo-circuito;

Sincronizao, dentro dos limites de tolerncia especficos da aplicao, entre os

sinais CE e os dados na sada do pseudo-circuito;

Recuperao probabilstica contra perdas ocasionais de pacotes na PSN;

Recuperao determinstica do estado da aplicao CE aps estabelecimento do

pseudo-circuito ou falhas da rede;

A sinalizao CE utilizada para propsitos de manuteno, como comandos loopback,

recuperao de dados de monitorao de performance, etc. deve utilizar o protocolo
genrico de manuteno PWE3.
l) Utilizao de largura de banda da rede de pacotes:

A37

A Camada de Encapsulamento deve buscar compromisso eficiente entre esses

requisitos:
Utilizao eficiente da largura de banda.
Assumindo que o tamanho do cabealho da camada de encapsulamento no
depende do tamanho do conjunto de dados encapsulados, um aumento no tamanho
desse conjunto de dados por pacote resulta em aumento de eficincia;
Baixa latncia fim a fim.
Esse um requisito comum para aplicaes de voz sobre servios TDM. O atraso
de empacotamento um dos componentes da latncia fim a fim, que diminui com a
reduo do tamanho do conjunto de dados por pacote. O buffer de compensao
utilizado no PE de destino aumenta a latncia do circuito emulado, e os atrasos
adicionais introduzidos por esse buffer no devem exceder a variao no atraso dos
pacotes (PDV) observada na PSN.
A Camada de Encapsulamento pode tambm economizar largura de banda:
Deixando de enviar dados corrompidos do fluxo TDM atravs da PSN;
Deixando de enviar atravs da PSN os canais que se encontram permanentemente
inativos, no caso de transporte consciente de estrutura;
Habilitando a supresso dinmica de canais temporariamente ociosos, tambm no
caso de transporte consciente de estrutura, desde que isso no viole a integridade
das estruturas entregues atravs do pseudo-circuito;
Para circuitos Nx64kbps, a Camada de Encapsulamento deve prover a capacidade de
manter o atraso fim a fim independente da taxa do servio emulado.
m) Variao no atraso dos pacotes:
A Camada de Encapsulamento deve prover a capacidade de compensao das variaes
no atraso sofrido pelos pacotes, enquanto mantm jitter e wander do relgio do
servio emulado dentro das tolerncias especificadas nas referncias normativas no PE
de destino.
Essa camada pode permitir a adaptao dinmica do atraso introduzido pelo jitter
buffer, caso as variaes no atraso dos pacotes se modifiquem com o tempo; tal
adaptao pode introduzir um pequeno nvel de erros, dentro dos limites tolerados pela
aplicao, mas no deve introduzir wander adicional para o relgio do servio
emulado, no PE de destino.
n) Compatibilidade com a infra-estrutura das PSN existentes:
A38

A combinao das Camadas de Encapsulamento e Tnel PSN para emulao fim a fim
de circuitos TDM deve ser compatvel com a infra-estrutura das PSN existentes, em
particular com mecanismos de compresso de cabealho onde essa capacidade um
diferencial.
o) Controle de congestionamento:
Os circuitos TDM operam a taxas constantes, oferecendo carga fixa para a rede de
pacotes. Assim, o mecanismo de variao da taxa de transmisso utilizado pelo
protocolo TCP para ajustar a demanda ao estado de congestionamento da PSN no
aplicvel, sendo necessria a capacidade de desconectar um pseudo-circuito TDM
quando o congestionamento detectado. Alm disso, devem ser evitadas situaes
onde mltiplos PWs TDM sejam desconectados ou restabelecidos, levando a PSN
instabilidade.
p) Deteco e tratamento de defeitos:
A Camada de Encapsulamento para emulao fim a fim de servios TDM deve,
isoladamente ou em conjunto com as camadas inferiores da pilha de protocolos PWE3,
prover a deteco, tratamento e notificao dos seguintes defeitos:
Conexo indevida, ou pacotes extraviados.
A importncia desse requisito baseada na expectativa dos usurios em funo da
deteco bastante confivel de conexes indevidas nas redes SONET/SDH;
Perda de pacotes.
A deteco de pacotes perdidos requisito para manter a integridade do relgio,
bem como prover a localizao do problema no pseudo-circuito.
Pacotes com problemas de montagem.
q) Monitorao de performance:
A Camada de Encapsulamento para emulao de servios TDM deve prover coleta de
dados de performance compatvel com os parmetros definidos para o TDM nativo.
r) Segurana:
Alm das consideraes gerais definidas na RFC3916 e totalmente aplicveis, os
servios TDM so especialmente sensveis variao no atraso dos pacotes, e portanto
precisam ser protegidos contra esse mtodo de ataque.

A39

A40

APNDICE C ESPECIFICAES TDMoIP

C.1 SUBCAMADA DE ENCAPSULAMENTO

Nos pacotes TDMoIP, cujo formato geral apresentado na Figura C.1, a informao
contida no fluxo de dados adaptado imediatamente precedida por uma palavra de
controle, ou CW (Control Word), de 32 bits, contendo indicadores de alarme, o
comprimento do pacote e o nmero de seqncia do mesmo, utilizado para detectar perdas
e proceder a sua reordenao, conforme definido em [IEFT2006].

Cabealhos PSN
(PSN Headers)
Palavra de Controle TDM
(TDM Control Word)
Fluxo de Dados Adaptado
(Adapted Payload)

Figura C.1 - Formato geral de um pacote TDMoIP.

Os cabealhos PSN so aqueles previstos pelos protocolos UDP/IP, L2TPv3/IP, MPLS ou
Ethernet, contendo todas as informaes necessrias para encaminhar o pacote atravs da
PSN, desde a extremidade PSN-bound at a TDM-bound. A rede de pacotes assumida
pela tecnologia como razoavelmente confivel e com largura de banda suficiente para
permitir o transporte dos dados TDM desejados.

A41

Alm desses, um cabealho opcional RTP de 12 octetos pode ser utilizado para transmitir
de forma explcita a informao de temporizao, atravs de uma timestamp que indica o
instante de criao do pacote em unidades de um relgio comum disponvel aos gateways
TDMoIP. Quando utilizado, o cabealho fixo RTP deve seguir imediatamente a palavra
de controle (CW) para todos os tipos de PSN, com exceo de UDP/IP, na qual o
cabealho RTP deve preceder a palavra de controle (CW), conforme definido pelo InternetDraft [IEFT2006]. A timestamp deve ser gerada de acordo com as regras definidas para o
RTP [RFC3550] e o relgio deve ser um inteiro mltiplo de 8kHz, escolhido de modo a
permitir a recuperao de sincronismo dentro dos padres estabelecidos para o fluxo TDM.
A recuperao do sincronismo com base timestamp transportada atravs do RTP depende
da existncia de um relgio comum a ambas as extremidades do pseudo-circuito, o que no
muito comum nas PSNs, o que restringe a sua utilizao. Alm disso, como a timestamp
funo linear do nmero de seqncia replicado na palavra de controle, o cabealho e o
protocolo RTP podem ser dispensados na maioria das aplicaes envolvendo a emulao
de pseudo-circuitos TDM, reduzindo o overhead.
A palavra de controle (CW) de 32 bits deve aparecer em todos os pacotes TDMoIP
gerados, sendo seu formato apresentado na Figura C.2.

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RES

L R M RES Comprimento

Nmero de Seqncia

Figura C.2 - Palavra de controle TDMoIP de 32 bits.

A42

A distribuio dos 32 bits da palavra de controle feita da seguinte forma:

RES (Reservados), 4 bits - o primeiro nibble da palavra de controle deve ser zero
quando a rede de pacotes utiliza MPLS, a fim de assegurar que o pacote no seja
interpretado com um pacote IP quando executada uma inspeo profunda pelos
roteadores. Nas demais redes, recomendvel que esses bits sejam zero.
L (Falha Local), 1 bit o flag L ativado quanto o gateway TDMoIP detecta ou
informado de uma falha no circuito TDM de origem com impacto sobre o fluxo de
dados TDM sendo encaminhado, como perda de sinal, perda da sincronizao de quadro
ou recebimento de um AIS. Quando o flag L ativado o contedo do pacote pode no
ser significativo, e o fluxo de dados pode ser suprimido a fim de conservar largura de
banda. Aps a remoo da falha, o flag L deve ser desativado.
R (Falha Remota), 1 bit o flag R ativado quanto o gateway TDMoIP detecta ou
informado que os dados TDM no esto sendo recebidos pelo circuito TDM de destino
(rede TDM remota), indicando uma falha na direo reversa da conexo bidirecional. O
gateway deve gerar um RDI aps receber um pacote com o flag R ativo, e o flag R deve
ser ativado quando do recebimento de um RDI atravs do circuito TDM.
M (Modificador de Falha), 2 bits o uso do campo M opcional, e quando utilizado
complementa o significado do flag L.
Quando L no est ativado, indicando dados TDM vlidos, o campo M usado com o
seguinte significado:
- 00 indica a no utilizao local da modificao de falha;
- 01 reservado;
- 10 reservado;
- 11 reservado;
Quando L est ativado, indicando dados TDM invlidos, o campo M usado com o
seguinte significado:
- 00 indica uma falha no circuito TDM que deve disparar a gerao de um AIS no PE de
destino (TDM-bound);
- 01 indica dados TDM ociosos ,que no devem disparar nenhum alarme.
Caso o fluxo de dados tenha sido suprimido, os cdigos de ociosidade pr-configurados
devem ser gerados pelo PE de destino para o circuito TDM;
- 10 indica dados TDM corrompidos mas potencialmente recuperveis;
- 11 reservado;
A43

 RES (Reservados), 2 bits esses bits so reservados e devem ser colocados em zero.
Comprimento (Length), 6 bits usado para indicar o comprimento do pacote
TDMoIP (palavra de controle e dados encapsulados), em caso de bits de alinhamento
(padding) serem empregados para atingir requisitos de unidade mnima de transmisso
da rede de pacotes. Ele deve ser usado se o comprimento total do pacote, incluindo
cabealhos PSN, cabealho RTP opcional, palavra de controle e dados encapsulados, for
menor que 64 octetos, e deve ser colocado em zero quando no utilizado.
Nmero de Seqncia, 16 bits usado para prover a funo de seqenciamento do
pseudo-circuito descrita nos requisitos PWE3, habilitando a deteco de perdas ou
desordenamento de pacotes. A janela de seqenciamento uma faixa circular de 16
bits, sem sinal; o valor inicial do nmero de seqncia deve ser randmico e
imprevisvel, para fins de segurana e o mesmo deve ser incrementado em mdulo 216,
de forma independente para cada pseudo-circuito.
Para o encapsulamento do fluxo de dados TDM dentro dos pacotes TDMoIP, o PE de
origem (PSN-bound) extrai octetos consecutivos do fluxo TDM contnuo, preenchendo
cada octeto a partir de seu bit mais significativo. Os octetos extrados so ento adaptados
utilizando os algoritmos AAL1 ou AAL2 e o fluxo de dados resultante colocado dentro
do pacote, acompanhados dos respectivos cabealhos caractersticos da PSN utilizada:
a) TDM sobre UDP/IP

Quando a rede comutada em modo pacotes utilizada IP, deve ser utilizado o protocolo
UDP, uma vez que retransmisses no fazem sentido dadas as caractersticas de tempo real
dos circuitos TDM.
Os cabealhos IP [RFC3550] e UDP [RFC768] esto descritos nas respectivas RFCs,
devendo preceder os dados TDMoIP, sendo o formato completo do pacote TDM sobre
UDP/IPv4, incluindo o cabealho do protocolo RTP opcional, apresentado na Figura C.3.

A44

Terminal H.323[IETF1980] [IETF Comprimento Total

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
IPVer

IHL

IP ToS

Comprimento Total
Flags

Identificao
TTL

Protocolo

Ponteiro Fragmentao

CheckSum do Cabealho IP

Endereo IP de Origem
Endereo IP de Destino
Nmero da Porta de Origem

Nmero da Porta de Destino

Comprimento UDP

CheckSum UDP

RTV P X

CC

M Comprimento

Nmero de Seqncia RTP

Marcao de Tempo (Timestamp)

Identificador SSRC
RES

L R M RES Comprimento

Nmero de Seqncia

Fluxo de Dados Adaptado

Figura C.3 - Formato de um pacote TDMoIP sobre UDP/IP.

As primeiras 5 linhas de 32 bits so o cabealho IP, totalizando 20 octetos; a sexta e stima
linhas so o cabealho UDP, totalizando 8 octetos; as linhas 8, 9 e 10 so o cabealho
opcional RTP, constitudo por 12 octetos; a linha 11 a Palavra de Controle TDMoIP, de
4 octetos; e as seguintes representam os dados TDM encapsulados utilizando AAL1 ou
AAL2. Segue a descrio dos campos desse pacote, com exceo da Palavra de Controle,
j descrita anteriormente:

A45

 IPver (IP version), 4 bits a verso do protocolo IP; no caso, IPver=4;

IHL (IP Header Length), 4 bits o comprimento, em palavras de 32 bits, do
cabealho IP; no caso, IHL=5;
IP ToS (IP Type of Service), 8 bits campo com o tipo de servio IP;
Comprimento Total, 16 bits o comprimento, em octetos, do pacote, incluindo
cabealhos e dados;
Identificao, 16 bits o campo de identificao de fragmentao IP;
Flags, 3 bits so os flags de controle IP e devem ser definidos como Flags=010 para
evitar fragmentao;
Ponteiro Fragmentao, 13 bits localiza o fragmento dentro do datagrama IP em no
utilizado para TDMoIP;
TTL (Time to Live), 8 bits campo IP que indica o tempo de vida do pacote,
datagramas com zero neste campo so descartados pela rede;
Protocolo, 8 bits indica o protocolo utilizado, deve ser definido como 0x11 ou 17, que
significa UDP;
Checksum do cabealho IP, 16 bits a soma de verificao (checksum) do cabealho
IP;
Endereo IP de Origem, 32 bits o endereo IP do PE de origem;
Endereo IP de Destino, 32 bits o endereo IP do PE de destino;
Nmeros de Porta de Origem e Destino, 16 bits cada indica a porta UDP utilizada
pelos PEs de origem e destino para o servio PWE3, devendo ser manualmente
configuradas de modo a indicar o rtulo do pseudo-circuito criado, de forma que o
endereo IP de destino e um dos nmeros de porta identifique unicamente o fluxo TDM
sendo transportado. A escolha do nmero de porta de origem ou de destino para esse
rtulo dependente da implementao, mas deve ser acordada pelos dois PEs. Quando
utilizada como identificador do fluxo TDM, o nmero de porta UDP deve estar
compreendido na faixa de alocao dinmica, ou seja, de 49152 a 65535. O valor 0
reservado, e o valor 8191 (0x1FFF) pr-configurado para o pseudo-circuito de
operao e manuteno (OAM). Alm disso, quando a porta de origem utilizada para
identificar o fluxo TDM, a porta de destino deve ser fixada em 2142 (0x085E), o
nmero alocado pela IANA (Internet Assigned Numbers Authority) para TDMoIP.
Comprimento UDP, 16 bits o comprimento, em octetos, do cabealho UDP e
dados;
A46

 Checksum UDP, 16 bits a soma de verificao (checksum) dos cabealhos UDP/IP e

dados, caso no calculado, deve ser definido como zero;
RTV (RTP Version), 2 bits a verso do protocolo RTP; no caso, RTV=2;
P (Padding), 1 bit indica que o pacote contm um ou mais octetos de alinhamento ao
final do fluxo de dados, deve ser colocado em zero nas aplicaes TDMoIP;
X (Header Extension), 1 bit indica a existncia de uma extenso do cabealho fixo
RTP, deve ser colocado em zero nas aplicaes TDMoIP;
CC (CSRC count), 4 bits contm o nmero de identificadores CSRC (Contributing
SouRCe) que seguem o cabealho fixo RTP, deve ser colocado em zero nas aplicaes
TDMoIP;
M (Marker)), 1 bit permite a marcao de eventos significativos dentro do fluxo de
pacotes, como o limite dos quadros, deve ser colocado em zero nas aplicaes
TDMoIP;
PT (Payload Type), 7 bits identifica o formato do fluxo de pacotes RTP e determina a
sua interpretao pela camada de aplicao, deve ser alocado na faixa de mapeamento
dinmico de cdigos;
Nmero de Seqncia RTP, 16 bits um nmero incrementado de um a cada pacote
de dados RTP enviado, que pode ser utilizado pelo receptor para detectar a perda e/ou
restaurar a seqncia dos pacotes recebidos, seu valor inicial aleatrio e deve ser
idntico ao nmero de seqncia utilizado na palavra de controle TDMoIP;
Timestamp, 32 bits a marcao de tempo (timestamp) reflete o instante de
amostragem do primeiro octeto no pacote de dados RTP, derivada do relgio do sistema
e incrementada monotnica e linearmente no tempo para permitir a sincronizao e o
clculo do jitter. A resoluo do relgio deve ser suficiente para assegurar a preciso de
sincronizao desejada;
Identificador SSRC (Synchronization SouRCe), 32 bits identifica a fonte de
sincronizao, ou seja, a referncia para o nmero de seqncia e a timestamp do fluxo
de pacotes RTP , deve ser escolhido de forma aleatria para evitar que duas fontes
possuam o mesmo identificador numa mesma sesso RTP.

A47

b) TDM sobre MPLS

Quando a rede de pacotes utilizada MPLS, seu cabealho, incluindo as etiquetas do tnel
e do pseudo-circuito, deve preceder diretamente a Palavra de Controle TDMoIP, seguida
pelo cabealho do protocolo RTP opcional, conforme apresentado na Figura C.4.
Terminal H.323[IETF1980] [IETF Comprimento Total

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

RES
RTV P X

Etiqueta do Tnel

EXP S

TTL

Rtulo do Pseudo-Circuito

EXP 1

TTL

L R M RES Comprimento
CC

M Comprimento

Nmero de Seqncia
Nmero de Seqncia RTP

Marcao de Tempo (Timestamp)

Identificador SSRC

Fluxo de Dados Adaptado

Figura C.4 - Formato de um pacote TDMoIP sobre MPLS.

As primeiras 2 linhas de 32 bits so o cabealho MPLS, totalizando 8 octetos; a terceira
linha a Palavra de Controle TDMoIP de 4 octetos; as linhas 4, 5 e 6 so o cabealho
opcional RTP, de 12 octetos; e as seguintes so os dados TDM encapsulados utilizando
AAL1 ou AAL2. Segue a descrio dos campos desse pacote ainda no abordados:
Etiqueta do Tnel, 20 bits a etiqueta que identifica os LSPs (Label Switching Paths),

tambm denominado tneis MPLS atravs dos quais os pacotes contendo dados TDM
devem ser encaminhados atravs da rede MPLS. Essa etiqueta pode ser associada tanto
atravs de provisionamento manual como via um protocolo de controle MPLS, como o
LDP (Label Distribution Protocol). Enquanto o pacote encaminhado pela rede MPLS
podem haver zero, uma ou mltiplas etiquetas empilhadas.
A48

 EXP (Experimental), 3 bits um campo experimental, pode ser utilizado para

transportar a classificao DiffServ para as etiquetas dos tneis.
S (Stacking), 1 bit o bit de pilha indica o fundo da pilha MPLS, S=0 para todas as
etiquetas associadas a tneis, e S=1 para o rtulo do pseudo-circuito.
TTL (Time to Live), 8 bits campo MPLS que indica o tempo de vida do pacote
dentro do tnel (LSP).
Rtulo do Pseudo-Circuito, 20 bits o rtulo que identifica o pseudo-circuito
estendido entre os PEs de origem e destino atravs da rede MPLS; esse rtulo deve ser
uma etiqueta MPLS vlida e pode ser configurado manualmente ou atravs de um
protocolo de sinalizao.
c) TDM sobre Ethernet

Um pacote TDMoIP (Palavra de Controle, cabealho do protocolo RTP opcional e dados

adaptados atravs deAAL1 ou AAL2) pode ser encapsulado diretamente em um quadro
Ethernet, quando precedido pelos respectivos endereos MAC (Media Access Control) de
destino e origem, e sucedido pelos 4 bytes FCS (Frame Check Sequence) da seqncia de
verificao de quadro. As implementaes TDMoIP devem estar aptas a receber quadros
tanto no padro Ethernet DIX (Digital, Intel e Xerox - o consrcio de desenvolvedores
originais), como no padro IEEE 802.3 [IEEE802.3], devendo transmitir apenas quadros no
padro Ethernet DIX. Esse pacote apresentado na Figura C.5.
O encapsulamento Ethernet introduz restries para o tamanho dos pacotes: Caso o pacote
contendo dados TDM tenha menos de 64 octetos, o tamanho mnimo, bits de alinhamento
devem ser introduzidos e o comprimento real indicado atravs do campo Comprimento
na Palavra de Controle. Da mesma forma, a fim de evitar fragmentao, a quantidade de
dados TDM no pacote deve ser restrita a um tamanho mximo, evitando que o MTU de
1500 octetos seja superado.

A49

Terminal H.323[IETF1980] [IETF Comprimento Total

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Endereo MAC de Destino
Endereo MAC de Destino (continuao)
Endereo MAC de Origem
Endereo MAC de Origem (contin.)
VLP C

VLAN Ethertype (opcional)

Ethertype

VLAN ID (opcional)
Rtulo do Pseudo-Circuito

RES
RTV P X

L R M RES Comprimento
CC

M Comprimento

RES 1

RES

Nmero de Seqncia
Nmero de Seqncia RTP

Marcao de Tempo (Timestamp)

Identificador SSRC

Fluxo de Dados Adaptado

FCS

Figura C.5 - Formato de um pacote TDMoIP sobre Ethernet.

As primeiras 5 linhas de 32 bits so o cabealho Ethernet (DIX), totalizando 18 octetos,
podendo haver campos adicionais no caso do padro IEEE 802.3; a sexta linha um rtulo
no formato da etiqueta MPLS; a stima linha a Palavra de Controle TDMoIP de 4
octetos; as linhas 8, 9 e 10 so o cabealho opcional RTP, de 12 octetos; e as seguintes
representam os dados TDM encapsulados utilizando AAL1 ou AAL2, com exceo da
ltima linha, que corresponde Seqncia de Verificao de Quadro (FCS) Ethernet, com
4 octetos. Segue a descrio dos campos ainda no abordados que formam esse pacote:
A50

 Endereo MAC de Destino, 48 bits o endereo global nico da interface de rede

que deve receber o pacote, no PE de destino; seu formato definido em IEEE802.3;
Endereo MAC de Origem, 48 bits o endereo global nico da interface de rede
que originou o pacote, no PE de origem; seu formato definido em IEEE802.3.
VLAN Ethertype, 16 bits um valor 33024 (0x8100) nesse campo indica uma
marcao de LAN virtual (VLAN) de acordo com o padro IEEE 802.1.Q, e que os
prximos dois octetos contm os campos VLP, C e VLAN ID, conforme definido em
[IEEE802.1Q]. As marcaes VLAN podem ser empilhadas, de forma que o campo de
dois octetos que sucede o VLAN ID pode ser novamente um VLAN Ethertype.
VLP (VLAN Priority), 3 bits indica a prioridade da VLAN, conforme definido pelo
padro IEEE 802.1.Q;
C (Canonical Format Indicator), 1 bit quando ativado, indica que os descritores de
rota esto presentes, conforme definido pelo padro IEEE 802.1.Q;
VLAN ID (VLAN Identifier), 12 bits identifica de forma unvoca a VLAN a que o
quadro pertence. Caso seja definido como zero, apenas o campo VLP significativo. Os
valores de 1 at 4095 (0xFFF) so reservados, os outros 4193 valores so vlidos como
identificadores VLAN.
Ethertype, 16 bits identifica o protocolo utilizado, conforme valores alocados pelo
IEEE. O valor alocado para CES over Ethernet 35032 (0x88D8), mas tambm pode
ser utilizado o 34887 (0x8847), correspondente ao valor Ethertype para o MPLS.
Rtulo do Pseudo-Circuito, 20 bits o rtulo que identifica o pseudo-circuito
estendido entre os PEs de origem e destino atravs da rede MPLS. Esse rtulo deve ser
manualmente configurado e o restante da linha deve ser formatado para que seja
semelhante a uma etiqueta MPLS.
FCS (Frame Check Sequence), 32 bits o campo contendo o cdigo CRC para
deteco de erros no quadro Ethernet, calculado conforme estabelecido pelo padro
IEEE 802.3 [IEEE802.3].
Cabe observar que quadros Ethernet podem ser utilizados para o transporte de pseudocircuitos TDM sem necessidade das camadas IP ou MPLS; contudo, uma etiqueta no
formato MPLS deve estar sempre presente, com seu cabealho de quatro octetos, o bit S=1
e todos os outros bits que no fazem parte da etiqueta reservados, sendo definidos como
zero na direo PSN-bound e ignorados na direo TDM-bound.
A51

C.2 SUBCAMADA DE ADAPTAO

A tecnologia SAToP [RFC4553], trata o pseudo-circuito como um fluxo contnuo e

arbitrrio de bits, no prevendo qualquer adaptao dos dados TDM e transportando, em
cada pacote, apenas um nmero fixo de octetos recebidos do circuito de acesso TDM, a fim
de facilitar o tratamento das perdas de pacotes na PSN. Esse tamanho do pacote definido
durante o estabelecimento do pseudo-circuito e precisa ser o mesmo em ambas as direes,
permanecendo inalterado durante toda a conexo. As regras para a acomodao dos bits
TDM dentro dos pacotes SAToP so as seguintes:

A ordem dos octetos dentro do pacote a mesma do circuito de acesso TDM;

Os bits consecutivos provenientes do fluxo TDM preenchem cada octeto do pacote

iniciando pelo bit mais significativo e seguindo at o bit menos significativo;

Todas as implementaes SAToP devem ser capazes de suportar os seguintes tamanhos

de pacote para o fluxo de dados:
o E1: 256 octetos;
o T1: 192 octetos;
o E3/T3: 1024 octetos.

A tecnologia TDMoIP [IETF2006] pode utilizar diferentes tcnicas de adaptao,

dependendo das caractersticas do trfego TDM. Sempre que possvel, devem ser utilizados
mecanismos de adaptao originalmente desenvolvidos para ATM, o que traz como
benefcio a interoperabilidade com servios de emulao de circuitos transportados sobre
redes ATM. Essa foi uma escolha natural no desenvolvimento da tecnologia, pois os
mecanismos da famlia de protocolos AAL (ATM Adaptation Layer), desenvolvidos
originalmente para adaptar os vrios tipos de dados ao rgido formato do ATM, so
solues gerais para o problema de transporte de fluxos de dados em tempo real, a taxas
constantes ou variveis, sobre uma rede comutada em modo pacotes.
Para os troncos TDM tradicionais, estaticamente alocados e com taxa de transmisso de
bits constante, ou CBR (Constant Bit-Rate), utilizada uma camada de adaptao AAL1
(ATM Adaptation Layer number 1), desenvolvida para o transporte de servios CBR sobre
redes ATM. Essa camada realiza a segmentao do fluxo contnuo de bits TDM em
pequenas clulas de 48 octetos, inserindo informaes de seqenciamento, temporizao,
recuperao de erros e sincronizao. Por exemplo, caso o fluxo TDM seja composto por
A52

um feixe E1 com sinalizao por canal associado (CAS), a camada AAL1 insere um
ponteiro no comeo do prximo superquadro, de forma que, mesmo se algumas clulas
forem perdidas, o ponteiro permite a recuperao da sinalizao no prximo superquadro.
Essa tcnica permite a concatenao de qualquer nmero de clulas AAL1 em um pacote,
de modo a permitir flexibilidade no compromisso entre o atraso de empacotamento, que
diminui com a reduo de clulas por pacote, e a eficincia de utilizao da largura de
banda, que aumenta com seu incremento, em virtude da reduo do overhead.
Para enlaces TDM dinamicamente alocados, onde a taxa de transmisso de bits varia com a
ativao de timeslots e/ou mecanismos de deteco de atividade de voz, a fim de evitar a
transmisso de canais ociosos e economizar largura de banda, utilizada uma camada de
adaptao AAL2 (ATM Adaptation Layer number 2), desenvolvida para o transporte de
servios de taxa varivel, ou VBR (Variable Bit-Rate) sobre redes ATM. Essa camada
acomoda cada timeslot TDM em pequenas mini-clulas, inserindo informaes de
identificao, definio de comprimento e seqenciamento, enviando somente aquelas que
carregam informaes vlidas, dentro de um nico pacote. Para timeslots carregando
informaes HDLC, como aqueles utilizados na sinalizao por canal comum (CCS), uma
adaptao especial provida a fim de assegurar o seu encapsulamento direto.
a) Formato AAL1

Para situaes onde predominante o uso de TDM no canalizado, ou TDM canalizado

com alocao de canais esttica, conhecida como emulao de circuitos, o fluxo de dados
pode ser encapsulado de forma eficiente utilizando AAL1, desenvolvida para fluxos com
taxa de bits constante(CBR), cujas caractersticas fundamentais so aqui apresentadas.
O primeiro octeto de uma PDU AAL1 contm um nmero de seqncia de trs bits,
protegido contra erros, como apresentado na Figura C.6.

A53

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
C

NS

CRC P

47 octetos de dados

Figura C.6 - Estrutura AAL1 de 48 octetos.

C (Indicao de Convergncia), 1 bit seu uso limitado indicao da existncia de
um ponteiro no prximo octeto:
C=0, significa sem ponteiro;
C=1, significa que o ponteiro est presente.
NS (Nmero de Seqncia), 3 bits o nmero de seqncia AAL1, incrementado a
cada PDU, formando um ciclo de 8 PDUs;
CRC (Cdigo de Redundncia Cclica), 3 bits o cdigo de deteco de erro
associado ao conjunto C+SN (4 bits);
P (Paridade), 1 bit o bit de paridade par do octeto formado pelo conjunto.
A estrutura dos 47 octetos remanescentes na PDU AAL1 depende do tipo de PDU, com
trs possibilidades de acordo com os servios de emulao definidos no ATM, assim
denominados: emulao de circuitos no estruturada, correspondente ao transporte TDM
sem conscincia de estrutura; emulao de circuitos estruturada e emulao de circuitos
estruturada com CAS, ambas correspondentes ao transporte TDM consciente de estrutura.
A PDU mais simples a no estruturada, utilizada para transporte transparente de circuitos
completos E1, T1, E3 e T3, que representada na Figura 2.20. Para AAL1 no estruturado,
os 47 octetos aps o nmero de seqncia contm todos os 376 bits com o fluxo de dados
TDM, nenhuma sincronizao de quadro suportada e o enquadramento de inteira
responsabilidade dos equipamentos terminais, permitindo o transporte de dados com
sincronizao de quadro no padronizada. Para um circuito E1, o quadro formado por
256 bits, ajustando 1 15/32 quadros em cada PDU.
Para o transporte sem conscincia de estrutura, a adaptao AAL1 proposta pelo TDMoIP
no apresenta grandes vantagens quando comparada abordagem SAToP, com tamanho
A54

fixo de pacotes, mas pode ser desejvel quando da interoperabilidade com circuitos
emulados ATM que a utilizem, ou para permitir mecanismos de recuperao de relgio
baseados na AAL1.
Para o transporte consciente de estrutura, a PDU para emulao estruturada demonstra-se
adequada para circuitos TDM canalizados de acordo com a Recomendao ITU-T G.704
[ITU-T G704], em particular quando esto envolvidos circuitos E1/T1 fracionrios. A
AAL1 estruturada considera os dados no apenas como um fluxo contnuo de bits, mas
como um arranjo de canais. Os N octetos dos N canais a transportar so primeiro
ordenados pelo nmero do canal; assim, se os canais 2, 3, 5, 7 e 11 devem ser
transportados, seus cinco octetos correspondentes so colocados na PDU imediatamente
aps o nmero de seqncia, sendo esse procedimento repetido at que todos os 47 octetos
estejam ocupados, como mostrado na Figura C.7(a). A prxima PDU iniciada a partir do
prximo canal dessa seqncia que ficou de fora, como mostrado na Figura C.7(b). e
assim por diante. O conjunto de canais 2, 3, 5, 7 e 11 constitui a estrutura bsica e o ponto
onde essa estrutura termina e a prxima inicia o limite da estrutura do fluxo TDM. O
problema com esse arranjo a ausncia de indicao explcita da identidade de cada octeto,
pois cada PDU AAL1 iniciada com um canal diferente, de forma que uma simples perda
de pacote resulta no embaralhamento dos canais, sem possibilidade de recuperao.

Octeto 01 02 03 04 05 06 07

41 42 43 44 45 46 47

Canal

11

11

(a)

Octeto 01 02 03 04 05 06 07

41 42 43 44 45 46 47

Canal

11

11

(b)

Figura C.7 - Exemplo de alocao dos canais TDM nos octetos das PDUs AAL1 para
emulao de circuitos estruturada.

A55

A soluo para o problema a introduo peridica de um ponteiro para o prximo limite

da estrutura, que no precisa ser muito freqente, pois a identificao de cada canal
unvoca a menos que pacotes sejam perdidos. Assim, a sincronizao de quadro TDM
mantida pela insero desse ponteiro no cabealho da PDU AAL1, indicando o incio do
prximo quadro, uma vez a cada ciclo de 8 PDUs. Esse ponteiro possui 7 bits, suficientes
para representar um deslocamento de 128 posies, e protegido por um bit de paridade
par no bit mais significativo do respectivo octeto. Dessa forma, os ponteiros podem ser
encaminhados somente nas PDUs de nmero de seqncia par, j que o mesmo pode
indicar qualquer octeto entre os 46 da PDU que o contm e os 47 da prxima, totalizando
93 posies possveis. Essas PDUs so denominadas P-format PDUs e seu formato
apresentado na Figura C.8.

0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
C

NS

CRC P E

Ponteiro

46 octetos de dados

Figura C.8 - Estrutura de uma P-format PDU AAL1

para emulao de circuitos estruturada.
C (Indicao de Convergncia), 1 bit C=1, para P-format PDUs;
NS (Nmero de Seqncia), 3 bits o nmero de seqncia AAL1, incrementado a
cada PDU, formando um ciclo de 8 PDUs;
CRC (Cdigo de Redundncia Cclica), 3 bits o checksum para C+SN (4 bits);
P (Paridade), 1 bit o bit de paridade par do octeto formado por C+SN+CRC.
E (Paridade), 1 bit o bit de paridade par do octeto que contm o ponteiro.
Ponteiro, 7 bits o ponteiro para o prximo limite da estrutura do fluxo TDM.
Se o Ponteiro igual a zero, significa que a estrutura se inicia no prximo octeto, isto , o
prximo octeto de dados pertence ao canal de numerao mais baixa (no exemplo anterior,
o canal 2); ponteiro igual a 93 significa que o ltimo octeto da prxima PDU o ltimo da
estrutura, e a PDU que o segue inicia uma nova estrutura. P valor especial 127 indica que
no existe limite a ser indicado nesse ciclo, necessrio quando estruturas muito grandes
esto sendo transportadas, cujos limites se estendem alm das 8 PDUs do ciclo. A P-format
A56

PDU sempre colocada na primeira posio possvel do ciclo de 8 PDUs (indicado pelo
nmero de seqncia) onde o limite da estrutura ocorre, e somente pode ocorrer uma vez a
cada ciclo.
A PDU de emulao estruturada com CAS similar anterior, tendo como diferena
apenas a definio de estrutura: enquanto naquela a estrutura composta apenas pelos N
canais, nesta a estrutura engloba o multi-quadro composto pela mltipla repetio dos N
canais e tambm seus respectivos bits de sinalizao CAS. Os 4 bits CAS de cada canal so
agrupados em octetos e o octeto final completado com zeros, se necessrio, fechando
assim a estrutura. Assim, a sincronizao de quadro TDM mantida pela insero de
ponteiros no cabealho da PDU AAL1, indicando o incio do prximo multi-quadro, alm
da transmisso de uma sub-estrutura incluindo os bits CAS dos respectivos canais.
Por exemplo, em circuitos E1 os bits de sinalizao CAS so atualizados a cada multiquadro de 16 quadros. Assim, uma estrutura N x 64kbps derivada de um circuito E1
utilizando sinalizao CAS consiste de 16 repeties dos N octetos correspondentes a cada
canal, seguida por N conjuntos com os 4 bits de sinalizao ABCD de cada canal, e
finalmente 4 zeros se N for mpar, conforme indicado na Figura C.9, assumindo a
transmisso dos canais 2, 3 e 5.

PDU 0 (P-Format)
Octeto 01 02 03 04 05 06 07

40 41 42 43 44 45 46

Canal

PDU 1
Octeto 01 02 03 04 05 06 07

41 42 43 44 45 46 47

Canal

ABCD ABCD ABCD

2
3
5

0000

Limite da nova estrutura

Figura C.9 - Exemplo de alocao de canais nos octetos das PDUs AAL1.

A57

No modo AAL1, o fluxo de dados TDMoIP consiste em pelo menos uma PDU de 48
octetos encapsulada dentro de cada pacote, conforme mostrado na Figura C.10. O nmero
de PDUs deve ser pr-configurado e escolhido de forma que o tamanho total do pacote no
exceda a MTU da rede. Para redes Ethernet, onde o MTU de 1500 octetos, 30 o limite.
O nmero exato de PDUs por pacote escolhido considerando as restries de latncia e
largura de banda existentes, pois uma nica PDU oferece a mnima latncia, mas implica
em elevado overhead. Todas as implementaes TDMoIP devem suportar entre 1 e 8
PDUs por pacote para circuitos E1 e T1, e entre 5 e 15 PDUs para circuitos E3 e T3.

Cabealhos
PSN

Palavra de
Controle

PDU
AAL1

(a) Uma nica PDU AAL1 por pacote.

Cabealhos
PSN

Palavra de
Controle

PDU
AAL1

PDU
AAL1

PDU
AAL1

(b) Mltiplas PDUs AAL1 por pacote.

Figura C.10 - PDUs AAL1 dentro do s pacotes TDMoIP.

b) Formato AAL2

Apesar do formato AAL1 poder ser configurado para o transporte de circuitos E1 e T1

fracionrios (N x 64kbps), a alocao dos canais transportados precisa ser esttica, uma vez
que AAL1 transporta apenas fluxos a taxas de bit constantes (CBR). Contudo, pode ser
freqente a situao onde nem todos os canais se encontram ativos simultaneamente, o que
detectado pela observao da sinalizao dos canais TDM; e mesmo em canais ativos
cerca de metade do tempo de conversao ocupado por silncio, que pode ser identificado
atravs tcnicas de deteco de atividade de voz. Nesses casos, o fluxo de dados
encapsulado de forma mais eficiente utilizando a adaptao AAL2, desenvolvida para
fluxos de dados com taxa de bits varivel (VBR), que permite a alocao dinmica dos
canais efetivamente utilizados, conhecida como emulao de enlaces, conservando
largura de banda.
A58

No modo AAL2, o fluxo de dados TDMoIP consiste em uma ou mais PDUs AAL2 de
tamanho varivel. Cada PDU AAL2 contm trs octetos de overhead e entre 1 e 64 octetos
de dados. Um pacote pode ser construdo atravs da insero de PDUs correspondentes aos
canais ativos, adicionando todas as PDUs que estiverem completas num certo instante, ou
utilizando qualquer outra tcnica semelhante, de forma que mais de uma PDU pertencente
a um nico canal pode estar contida em um dado pacote.
Como a proposta do trabalho a emulao de circuitos TDM e o transporte transparente de
sinais de vdeo digital atravs dos mesmos, no necessrio descrever adaptao AAL2.
c) Formato HDLC

A motivao para tratamento de HDLC em TDMoIP

o transporte eficiente de

sinalizao por canal comum (CCS), como SS7 ou a utilizada em RDSI-PRI, quando
inserida no fluxo TDM. O mecanismo proposto no genrico para todos os dados HDLC,
e assume que as mensagens transportadas so sempre menores que o tamanho mximo do
pacote.
O modo HDLC deve ser usado somente quando esperado que a maioria da banda
utilizada pelo fluxo HDLC seja ocupada por bits ociosos, caso contrrio o canal CCS deve
ser tratado como um canal convencional. Esse modo baseado na existncia de um
pseudo-circuito em separado, para transporte transparente dos dados e mensagens de
controle associados CCS:
O PE de origem (PSN-bound) monitora os flags at que um quadro seja detectado. O
contedo desse quadro coletado e tem seu FCS testado; se o FCS incorreto, o quadro
descartado, caso contrrio enviado atravs do pseudo-circuito em separado, tendo seu
FCS descartado e os bits ociosos removidos para economia de banda. Quando esse quadro
recebido pelo PE de destino (TDM-bound), seu FCS recalculado e o quadro original
CCS reconstrudo.

A59

C.3 SERVIOS TDM EMULADOS

Os servios TDM que podem ser emulados atravs da Arquitetura PWE3, segundo a
RFC4197, so os seguintes:
a) SAT (Transporte No-consciente de Estrutura) para Sinais da Hierarquia PDH:
O transporte sem conscincia de estrutura pressuposto para os seguintes sinais:

E1 como descrito na Recomendao ITU-T G.704;

T1 (ou DS1) como descrito na Recomendao ITU-T G.704;

E3 como descrito na Recomendao ITU-T G.751;

T3 (ou DS3) como descrito na Recomendao ANSI T1.107;

b) Transporte Consciente de Estrutura para Sinais da Hierarquia PDH:

O transporte com conscincia de estrutura pressuposto para os seguintes sinais:

E1 com estruturas de quadro, como descrito na Recomendao ITU-T G.704;

NxDS0 (64 kbps), como ou sem sinalizao CAS;

c) Transporte Consciente de Estrutura de Circuitos da Hierarquia SDH/SONET:

O transporte com conscincia de estrutura pressuposto para os seguintes circuitos
SONET STS (Synchronous Transport Signal) e VT (Virtual Tributaries) ou SDH VCs
(Virtual Containers), no fazendo grande sentido o transporte SAT para SDH/SONET:

SONET STS-1 SPE (Synchronous Payload Envelope) ou SDH VC-3;

SONET STS-Nc (N=3,12,48,192) ou SDH VC-4, VC-4-4c, VC-4-16c e VC-4-64c;

SONET VT-N (N=1.5, 2, 3, 6) ou SDH VC-11, VC-12, VC-2;

SONET NxVT-N ou SDH NxVC-11, NxVC-12, NxVC-2, NxVC-3.

Revisando as duas hierarquias:

a) Hierarquia PDH:

A Hierarquia Digital Plesicrona (PDH) apresenta diversidade de padronizao. As taxas

de transmisso tradicionalmente utilizadas so detalhadas na Recomendao ITU-T G.702
[ITU-T G702] e mostradas na Figura C.11. Na Amrica do Norte, os fluxos de bits
designados como T1 (1,544 Mbps) e T3 (44,736 Mbps) so mandatrios, enquanto no
Brasil e na Europa os fluxos de bits designados como E1 (2,048 Mbps) e E3 (34,368 Mbps)
so os mais utilizados.
A60

Canal B
64 Kbps

Brasil e Europa:

0
E1
x32 2.048 Kbps

E2
8.448 Kbps
x4

31

E3
34.364 Kbps

E4
139,264
Mbps

x4
x4

DS0
64 Kbps

Japo:

DS2 ou T2
6.312 Kbps

1
x24

x5

DS1 ou T1
1.544 Kbps

24

x4

J1
32.064 Kbps

DS2 ou T2
6.312 Kbps

x3

J2
97.728 Kbps
x4

J3
397,20
Mbps

DS3 ou T3
44.736 Kbps

Amrica do
Norte:

x7
DS2 ou T2
6.312 Kbps

x6

DS4 ou T4
274,176
Mbps

Figura C.11 - Hierarquia digital plesicrona.

Apesar dos circuitos TDM poderem ser utilizados para transportar qualquer fluxo de bits
com as taxas definidas na Recomendao G.702, existe um mtodo padronizado para
transporte desses fluxos em unidades chamadas quadros, contendo sempre o mesmo
nmero de bits. Em funo da freqncia de amostragem de 8 kHz para o trfego de voz,
com base no Teorema de Shannon, a taxa de bits sempre um mltiplo de 8.000, de forma
que um quadro T1 consiste em 193 bits e um quadro E1 formado por 256 bits. Nos fluxos
TDM sem enquadramento, ou no-estruturados, todos esses bits esto disponveis para o
fluxo de dados.
Quando existe enquadramento, o mesmo imposto pela introduo de um padro peridico
dentro do fluxo de bits para identificao dos limites do quadro. Esse padro formado por
um bit para quadros T1 e oito bits para quadros E1, maiores detalhes sobre a gerao e
utilizao desses bits so encontrados nas Recomendaes ITU-T G.704 [ITU-T G704] ,
G.706 [ITU-T G706] e G.751 [ITU-T G751] e no Padro ANSI T1.107 [ANSI107].
Os fluxos TDM com enquadramento so utilizados para multiplexar canais, usualmente
voz com 8.000 amostras de 8 bits por segundo 64 kbps, em uma seqncia de timeslots
A61

recorrentes, sempre na mesma ordem dentro de cada quadro. Esse arranjo chamado
TDM canalizado e introduz uma estrutura adicional. Em alguns casos, so tambm
definidos grupos de quadros consecutivos, os superquadros, impondo mais um nvel na
estrutura.

Quadro T1 ou DS1: 1.544 kbps (Amrica do Norte e Japo):

Quadro: 1+24 x 8bits = 193 bits (125us)
F

Time Slot 1

Time Slot 2

Time Slot 3

Time Slot 4

Time Slot 5

0 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Bit de
Alinhamento
de Quadro

Time Slot 23

Time Slot 24

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Canal 2

Canal 24

Quadro E1: 2.048 kbps (Brasil e Europa):

Quadro: 32 x 8bits = 256 bits (125us)
Time Slot 16

Time Slot 29 Time Slot 30 Time Slot 31

I 0 0 1 1 0 1 1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Time Slot 0

Time Slot 1

Time Slot 2

Time Slot 3

Time Slot 4

0 0 0 0 0 0 0 0

0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7

Canal de
Alinhamento
de Quadro

Canal de
Sinalizao

Canal 2

Canal 30

Figura C.12 - Fluxo TDM estruturado com canalizao.

Em relao ao transporte TDM dentro de pseudo-circuitos, existem duas abordagens:

SAT (Structure-Agnostic Transport) o transporte de circuitos TDM no-

estruturados, ou de circuitos TDM estruturados quando a estrutura considerada

irrelevante do ponto de vista do transporte. Nesse transporte no-consciente de
estrutura, qualquer overhead estrutural que esteja presente no fluxo de dados
transportado de forma transparente, e o encapsulamento no prov nenhum mecanismo
para sua localizao ou utilizao.

Structure-Aware Transport o transporte de circuitos TDM estruturados, levando

em considerao pelo menos algum dos nveis da estrutura. Nesse transporte consciente
de estrutura, no existe garantia de que todos os bits do fluxo TDM sero transportados
atravs da rede de pacotes (especificamente, os bits de sincronizao e overhead
relacionado podem ser eliminados na origem e regenerados no destino) ou que os bits
transportados estaro localizados no pacote em sua ordem original dentro do fluxo
(nesse caso, a ordem dos bits geralmente recuperada no destino).
A62

b) Hierarquia SDH/SONET:

O termo SONET se refere Rede ptica Sncrona utilizada na Amrica do Norte e

especificada pelo Padro ANSI T1.105 [ANSI105], baseada no conceito de um continer
de dados de Nx783 octetos, repetido a cada 125us. Esse fluxo bsico de dados se refere a
um STS-1 (Synchronous Transport Signal level 1), comumente utilizado para transportar
circuitos T3 ou E3, mas podendo ser concatenado em circuitos de maior ordem e largura de
banda, como STS-Nc (Synchronous Transport Signal level N, concatenado), utilizados
para transportar qualquer tipo de dados, como clulas ATM e sinais de vdeo digital; ou
subdividido em circuitos de menor ordem, denominados tributrios virtuais ou VTs
(Virtual Tributaries), comumente utilizados para transportar circuitos T1 ou E1.
A Hierarquia Digital Sncrona (SDH) o equivalente internacional aprimorado da rede
SONET, como tentativa de padronizao das hierarquias digitais existentes em um
esquema nico de multiplexao, especificada pela Recomendao ITU-T G.707 e
mostrada na Figura C.13. Maiores informaes sobre essas hierarquias podem ser
encontradas em [SOARES1988], ou nos documentos normativos citados.

T1
1.544 Kbps
E1
2.048 Kbps
T2
6.312 Kbps
E2
8.448 kbps
T3
34 Mbps
E3
44 Mbps
E4
139 Mbps
STS-12
622 Mbps
STS-48
2,5 Gbps
STS-192
10 Gbps

C-11

VC-11

TU-11 x4

C-12

VC-12

TU-12 x3

C-2

VC-2

TU-2

C-3

VC-3

TU-3

C-3

VC-3

TU-3

Entidades SDH:
Continers Viruais (VCs)
Mdulos de Transporte Sncrono (STMs)
TUG-2 x7

VC-3

AU-3

STM-0

52 Mbps

No
mapevel

x7
TUG-3
x3

x3

C-4

VC-4

AU-4

C-4-4c

VC-4-4c

AU-4-4c

C-4-16c

VC-4-16c

AU-4-16c

C-4-64c

VC-4-64c

AU-4-64c

AUG-1

STM-1

x4
AUG-4

STM-4

x4
AUG-16

STM-16

x4

Mapeamento em:
Continers (C)

Alinhamento em:
Unidades Tributrias (TUs)
Unidades Administrativas (AUs)

AUG-64

622 Mbps
2,5 Gbps
10 Gbps

Multiplexao em:
Grupos de Unidades Tributrias (TUGs)
Grupos de Unidades Administrativas (AUGs)

Figura C.13 - Hierarquia digital sncrona.

A63

STM-64

155 Mbps

As redes SDH/SONET tm por caracterstica a incluso de uma quantidade substancial de

overhead, utilizado para monitorao de performance, isolamento de defeitos e outras
funes de manuteno ao longo dos diferentes enlaces pticos ou eltricos. Isso inclui
tambm um mecanismo de ponteiros para o transporte de dados de forma assncrona.
Adicionalmente, cada continer inclui overhead para monitoramento da performance fim a
fim, isolamento de defeitos e manuteno para o servio que est sendo transportado. Caso
esse continer seja subdividido em circuitos de menor taxa, como T1/E1, novo overhead
includo para monitoramento fim a fim dos circuitos T1/E1 individuais.
C.4 GERENCIAMENTO DE FALHAS

As redes TDM nativas representam as falhas detectadas atravs das indicaes AIS (para
falha local) e RDI (para falha remota), que so padres especiais inseridos no fluxo
contnuo de bits. Os mecanismos de transporte sem conscincia de estrutura, como o
SAToP, carregam essas indicaes de forma transparente, mas para mecanismos
conscientes da estrutura, onde o PE de origem pode remover o overhead do fluxo TDM,
incluindo essas indicaes, necessria uma sinalizao explcita das condies de defeito
nos circuitos TDM nativos, em ambas as extremidades.
Essa sinalizao transportada atravs dos flags existentes na Palavra de Controle, contida
em cada um dos pacotes transmitidos atravs da PSN, o que de certa forma simula o
comportamento dos mecanismos nativos de Operao e Manuteno dos circuitos TDM,
baseados em padres de bits inseridos no fluxo. Estes flags foram projetados para o envio
de mensagens urgentes, ou seja, mensagens cujo contedo no pode ser significativamente
atrasado em relao aos dados TDM que so potencialmente impactados pelas mesmas.
A operao do tratamento de falhas para TDMoIP demonstrada na Figura C.14,
considerando um fluxo TDM sendo transmitido do Equipamento Cliente 1 (CE1) para o
Equipamento Cliente 2 (CE2), utilizando gateways TDMoIP (IWF1 e IWF2), que
constituem os Equipamentos Provedores (PE1 e PE2), atravs de uma rede comutada em
modo pacotes (PSN). O tratamento das falhas ocorridas nos circuitos TDM1, TDM2 ou na
PSN no deve restringir-se apenas sua deteco, mas tambm permitir a sua correta
localizao, gerando alarmes somente dentro da rede afetada.
A64

Rede de Pacotes
PSN

AIS

TDM

CE1

TDMoIP

Circuito TDM 1
RDI

TDMoIP

PE1

PE2

IWF1

AIS
Circuito TDM 2

IWF2

RDI

TDM

CE2

Sentido Direto do Fluxo TDM

Figura C.14 - Configurao tpica de uma rede TDMoIP.

Nesse contexto, dependendo das caractersticas atribudas ao mesmo, podem existir dois
cenrios de Operao e Manuteno para o pseudo-circuito TDM entre CE1 e CE2:
terminao local e terminao estendida.
No cenrio de terminao local, somente os dados vlidos so transmitidos entre os
Circuitos TDM1 e TDM2, os gateways IWF1 e IWF2 so considerados como terminao
de cada circuito, e nenhuma falha detectada no Circuito TDM1 transmitida ao Circuito
TDM2, ou o contrrio. Assim, os sinais AIS no devem ser propagados atravs da PSN.
No cenrio de terminao estendida, caso ocorra uma falha no Circuito TDM1, como perda
total de sinal ou perda de sincronismo de quadro, em localizao distinta do ltimo enlace
at PE1, o n TDM de destino do enlace em falha ir gerar um AIS em direo a PE1; caso
a falha ocorra no ltimo enlace, o prprio PE1 ir detectar o problema. Em ambos os casos,
o gateway IWF1 ativa o flag de Falha Local (L) na Palavra de Controle TDMoIP dos
pacotes que esto sendo encaminhados atravs da rede PSN, o que estende a informao da
falha at o Circuito TDM2.
Enquanto as indicaes diretas de falha, ocorridas na direo do fluxo TDM, podem ser
geradas por quaisquer elementos da rede que as detecte, as indicaes reversas so geradas
somente pelos equipamentos terminais. Assim, em um cenrio de terminao local, o
gateway IWF1 representa uma terminao para o Circuito TDM1, e quando detecta a perda
de validade do sinal TDM ou recebe informaes de problemas em outro ponto da rede,
A65

pode gerar um sinal TDM RDI em direo ao Equipamento Cliente CE1. Contudo, se o
cenrio for de terminao estendida, o gateway IWF1 no uma terminao para o fluxo
TDM e portanto no deve gerar nenhum sinal RDI, ativando o flag L ao invs disso. Esse
flag, ao ser recebido pelo IWF2, provoca a gerao de um sinal AIS no fluxo TDM em
direo ao Equipamento Cliente CE2, que a terminao efetiva nesse cenrio, o qual pode
ento gerar o sinal TDM RDI no fluxo reverso.
Quando o flag L ativado, o pacote pode ser tratado de quatro formas:

a forma padro o preenchimento, pelo IWF1 do contedo com uma quantidade

apropriada de dados correspondente a um sinal TDM AIS (usualmente, todos os bits
iguais a 1) ou o simples encaminhamento dos dados TDM referentes ao AIS
recebido;

alternativamente, para o transporte consciente de estrutura de TDM canalizado, o

contedo deve ser preenchido com uma mensagem de condicionamento de tronco,
que envolve um padro de dados previamente configurado como fora de servio,
sobretudo quando estiver sendo utilizada a agregao canais provenientes de diversos
troncos TDM tradicionais num nico pseudo-circuito TDM;

a terceira possibilidade simplesmente suprimir o contedo para esses pacotes,

economizando largura de banda na rede de pacotes;

finalmente, caso o IWF1 presumo que o impacto da falha sobre os dados reduzido ou
passvel de correo, como uma perda de sincronismo de multi-quadro, o contedo
pode ser preenchido com os dados TDM recebidos, indicando atravs do campo M que
os dados esto corrompidos, mas so potencialmente recuperveis.

Quando o IWF2 recebe uma indicao de falha local sem o campo M, ele encaminha (ou
gera, se os dados TDM tiverem sido suprimidos do pacote) um sinal AIS ou de
condicionamento de tronco, se assim previamente configurado, em direo ao CE2,
emulando o que aconteceria numa rede TDM convencional. Essa situao indica
exclusivamente que uma falha ocorreu no Circuito TDM1, estando o restante da rede em
perfeitas condies operacionais.
Se o campo M indica que os dados TDM so potencialmente recuperveis, algoritmos
especficos podem ser utilizados para minimizar os impactos da falha sobre o pseudocircuito. Caso esse campo indique que os dados TDM so ociosos, nenhum alarme deve ser
A66

gerado e o IWF2 pode tratar o contedo do pacote da mesma maneira que os demais dados
TDM, gerando, se necessrio, um sinal de condicionamento de tronco ao invs de um AIS.
Quando ocorre uma falha no Circuito TDM2, gerado um sinal TDM AIS em direo a
CE2, que pode ser respondido pelo envio de um sinal TDM RDI na direo reversa do
fluxo. No cenrio de terminao local esse sinal restrito ao Circuito TDM2, enquanto no
cenrio de terminao estendida o IWF2, detectando o sinal RDI inserido como dado TDM
vlido, deve ativar o flag de Falha Remota (R) na Palavra de Controle TDMoIP dos
pacotes enviados de volta ao IWF1 atravs da rede de pacotes. O IWF1, recebendo essa
indicao, gera um sinal TDM RDI em direo a CE1, emulando o comportamento de uma
rede TDM convencional.
A ltima situao possvel a ocorrncia de falha unidirecional na rede de pacotes, caso
em que o IWF1 encaminha os pacotes em direo ao IWF2, mas esses no so recebidos.
Nesse caso, o IWF2 deve alarmar o problema para a gerncia da PSN, gerando sinais TDM
AIS em direo a CE2. Este, por sua vez, pode responder com um sinal TDM RDI, que
seria propagado ao Circuito TDM1 atravs da ativao, pelo IWF2, do flag R no cenrio de
terminao estendida. Uma vez recebido esse flag pelo IWF1, o mesmo deve gerar um
sinal TDM RDI em direo a CE1.
Em todos esses casos, se a condio de falha persiste por um dado intervalo de tempo, cujo
valor padro 2,5s, uma falha no servio declarada. Como os pseudo-circuitos so
inerentemente bidirecionais, uma falha dessas em qualquer das direes resulta em falha
bidirecional, e o pseudo-circuito desconectado, passando ambos os gateways TDMoIP a
encaminhar sinais AIS para seus respectivos circuitos TDM, at que a conectividade seja
re-estabelecida pelo estabelecimento de um novo pseudo-circuito.

A67

A68

APNDICE D PROCESSAMENTO DO NMERO DE SEQENCIA

O algoritmo para processamento do nmero de seqncia para aplicaes TDMoIP

apresentado em [IETF2006] descrito a seguir, atravs da traduo e adaptao integral do
respectivo apndice A. Esse algoritmo no especifica o gerenciamento do buffer de
reproduo utilizado, mas sua anlise permite deduzir que isso realizado por um outro
processo externo executado de forma assncrona, uma vez que esse gerenciamento
fundamental para a operao do algoritmo descrito, pois so utilizados dois flags externos
indicativos de esgotamento e esvaziamento do buffer, e seriam necessrios ponteiros para
indicar as posies de escrita e leitura dos pacotes que esto sendo recebidos ou
reproduzidos, tambm no indicados.
O campo nmero de seqncia na Palavra de Controle permite a deteco de pacotes
perdidos e recebidos fora de ordem. Aqui fornecido o pseudo-cdigo de um algoritmo de
exemplo para seu tratamento, a fim de esclarecer as questes envolvidas. Essas questes
so especficas de cada implementao e nenhuma explicao simples pode apreender
todas as possibilidades envolvidas.
A fim de simplificar a descrio, a aritmtica em mdulo (resto da diviso entre inteiros)
consistentemente utilizada no tratamento da ciclicidade. Todas as diferenas entre ndices
so explicitamente convertidas para o intervalo [-215...+ 215.-1]

com o objetivo de

assegurar que a simples verificao do sinal da diferena permita a previso correta da

ordem de chegada dos pacotes
Alm disso, introduzida a noo de um buffer de reproduo, a fim de definir sem
ambigidade os pacotes que chegam atrasados. Quando um pacote chega, aps ter sido
previamente assumido como perdido, o gateway de destino pode descart-lo e continuar
tratando-o como perdido. Alternativamente, se o dados de preenchimento que foi inserido
em seu lugar ainda no foi reproduzido no fluxo de sada, existe a opo de inserir o dado
real no buffer de reproduo. Evidentemente, o dado de preenchimento pode ser gerado no
momento da deteco inicial de um pacote perdido ou em qualquer instante at a sua
A69

reproduo. A descrio anterior pressupe um buffer de reproduo orientado a pacotes,

ao invs de orientado a octetos TDM; contudo, este no um requisito real para as
implementaes de reordenao, uma vez que o segundo poderia ser utilizado sem
problemas, considerando ponteiros indicando o incio de cada pacote dentro do fluxo
TDM.
Uma vez introduzido o buffer de recepo, sero tratadas explicitamente as condies de
esgotamento e esvaziamento desse buffer. O esgotamento (overflow ou over-run) ocorre
quando os pacotes chegam to rapidamente que no podem ser armazenados para posterior
reproduo. Isso usualmente uma indicao de impreciso grosseira de sincronismo ou
configurao incorreta. O esvaziamento (underflow ou under-run), usualmente um sinal
de paralizao da rede, como resultado de congestionamento ou falha.
// Variveis externas utilizadas no pseudo-cdigo:
Received
Inteiro 16 bits ; nmero de seqncia do pacote recebido
Played
Inteiro 16 bits ; nmero de seqncia do pacote sendo reproduzido (Nota 1)
Filler
Pacote
; dados de preenchimento para pacotes perdidos (1s)
OverRun
Booleano
; o buffer de reproduo est cheio (Nota 3)
UnderRun
Booleano
; o buffer de reproduo est vazio (Nota 3)
// Variveis internas utilizadas no pseudo-cdigo:
Expected
Inteiro 16 bits ; prximo nmero de seqncia esperado
D
Inteiro 16 bits ; diferena entre esperado e recebido (Nota 2)
L
Inteiro 16 bits ; diferena entre os nmeros de seqncia do pacote que est
; sendo reproduzido e aquele que acabou de ser recebido
; (Notas 1 e 2)
// Parmetro do algoritmo:
R
; mximo atraso recupervel para um pacote
; se R=0, o pacote que chega atrasado sempre descartado.
Nota 1:
Nota 2:
Nota 3:

Somente requeridos quando existe reordenao (opcional)

Estes nmeros esto sempre no intervalo [-215...+ 215.-1]
O buffer de reproduo esvaziado pelo processo de regenerao do fluxo
TDM, que executado de forma assncrona com o processo de chegada de
pacotes, no especificado nesse documento.

A70

// Algoritmo para Processamento do Nmero de Seqncia:

ENQUANTO AplicacaoAtiva
Aguarda(RecebimentoPacote)
; aguarda recebimento do prximo pacote
SE Received = Expected
; trata pacote como em ordem
IF NOT OverRun ENTAO
GRAVA(Pacote)
; coloca contedo do pacote no buffer
SENAO
DESCARTA(Pacote) ; despreza o pacote
Expected = (Received + 1) mod 2^16
SENAO
; trata pacote como fora de ordem
D = ((Expected - Received) mod 2^16) - 2^15
SE D > 0 ENTAO
; pacotes Expected, Expected+1, ,
; Received-1 foram perdidos
ENQUANTO NOT OverRun
GRAVA(Filler) ; coloca seqncia de preenchimento(1s)
; ou dados interpolados no buffer
IF NOT OverRun ENTAO
GRAVA(Pacote) ; coloca contedo do pacote no
; buffer
SENAO
DESCARTA(Pacote) ; despreza o pacote
Expected = (Received + 1) mod 2^16
FIM ENQUANTO
SENAO
; no incrementa Expected
SE NOT UnderRun ENTAO
L = ( (Played - Received) mod 2^16 ) - 2^15
SE 0 < L <= R ENTAO
; substitui os dados do pacote
GRAVA(Pacote)
; previamente marcado como
; perdido
SENAO
DESCARTA(Pacote) ; despreza o pacote
FIM ENQUANTO
Caso seja assumido pela aplicao que no necessria a reordenao, ou seja, os pacotes
que chegam atrasados no so recuperados (R = 0), o final do algoritmo (indicado em
itlico), pode ser substitudo, simplesmente, por:
SENAO

; no incrementa Expected

DESCARTA(Pacote) ; despreza o pacote

FIM ENQUANTO

A71

A72

APNDICE E LISTAGEM DE FUNES MATLAB

E.1 FUNO PARA SIMULAO DE PACOTES COM O ALGORITMO IETF

function SimulaPacotesIETFDC(Quantidade,OcupacaoMinima,Recuperaveis,ProbDesordem)
%%% Arquivo: SimulaPacotesIETFDC.m
%%% Autor:
Eng. Wilson Dutra Sampaio - LabCom - ENE/UnB
%%% Objetivo: Simulao do atraso sofrido pelos pacotes em uma PSN e seqenciamento
%%%
desses pacotes na recepcao
%%% Algoritmo: Buffer linear (por simplicidade de gerenciamento) escrita e leitura sequencial
%%%
(Apresentado IETF-PWE3 TDMoIP Internet-Draft)
% Parmetros:
% Round-trip time da rede (em ms):
RTT=80;
% Tamanho do jitter buffer (em ms)- assumido linear, com capacidade para todos os pacotes, por
simplicidade de gerenciamento:
BufferSize=Quantidade;
% Ocupacao para inicio da reproducao:
Ocupacao=OcupacaoMinima;
% Duraao de cada pacote (em ms):
Tpacote=1;
% Numero de pacotes da simulacao:
Pacotes=Quantidade;
% Intervalo de pacotes atrasados passiveis de recuperacao:
R=Recuperaveis;
% Base de tempo:
t = [0:Tpacote:Pacotes*Tpacote];
N = length(t);
% Gera pacotes:
Tx = zeros(3,N);
NS=round(rand(1)*2^16);
Tx(1,1)=NS;
for k=2:N;
Tx(1,k)=NS+k-1;
end
Tx(2,:)=t;
% Transmite pacotes, atribuindo um instante de chegada aleatorio entre [RTT/2; RTT/2+RTT]:
for k=1:N;
Tx(3,k)=t(:,k)+RTT/2;
if rand(1) < ProbDesordem
Tx(3,k)=Tx(3,k)+rand(1)*RTT;
end
end
% Plota instantes de transmissao e recepcao
figure(1);
plot (Tx(2,:),Tx(1,:),'b.',Tx(3,:),Tx(1,:),'g.');
title('Instantes de Transmissao e Recepcao dos pacotes');
xlabel('t (ms)'); ylabel('Numero Sequencia');
disp('Pressione uma tecla para continuar.');
pause;
% Torna o sistema causal, gerando Rx com os pacotes recebidos por ordem de chegada:
Rx = zeros(2,N);
Cx=Tx;
for k=1:N;
Rx(2,k)=100*RTT; % Forca um instante de recepcao muito grande

A73

for i=1:N;
if Cx(3,i)<=Rx(2,k); % Se o instante de recepcao de Cx (imagem de Tx) e menor que Rx
corrente, troca.
Rx(1,k)=Cx(1,i); % Assume o NS recebido de Cx
Rx(2,k)=Cx(3,i); % Assume o instante de recepcao de Cx
ok=i;
end
end
Cx(3,ok)=200*RTT; % Forca um instante de recepcao maior ainda para o Cx ja' carregado em
Rx
end
% Plota transmissao x recepcao
figure(2);
plot (Tx(2,:),Tx(1,:),'b',Rx(2,:),Rx(1,:),'g');
title('Recepcao de pacotes por ordem de chegada');
xlabel('t (ms)'); ylabel('Numero Sequencia');
disp('Pressione uma tecla para continuar.');
pause;
% Acomoda pacotes no buffer e gera fluxo de saida:
Buffer=zeros(1,BufferSize);
Playout=zeros(1,Pacotes);
% Inicializacao da Thread de Escrita:
% Grava o primeiro pacote recebido:
Buffer(1,1)=Rx(1,1);
% Inicializa Ponteiro Playout com primeiro pacote recebido
PonteiroTDM=Rx(1,1);
% Inicializacao da Thread de Leitura:
Perdas=0;
Expected=PonteiroTDM+1;
% Simula Aplicacao ativa no Receptor:
for k=2:Pacotes+RTT*Ocupacao;
% Simula Thread de Escrita:
% Escreve pacotes de forma reordenada
if k<=Pacotes;
Received=Rx(1,k);
if Received==Expected;
% Pacote em ordem
% Grava pacote no buffer de reproducao
Buffer(1,k)=Rx(1,k);
Expected=Received+1;
else
% Pacote fora de ordem
D=Received-Expected;
if D>0;
% Recebido e' mais novo (maior) que o esperado
% Interpreta que anteriores foram perdidos
% Mitiga Perdas de pacote
i=k;
while i<=BufferSize;
% Coloca ultimo pacote recebido com sucesso n as posicoes remanescentes do buffer
Buffer(1,i)=Buffer(1,k-1);
i=i+1;
end
Expected=Received+1;
% Incrementa contador de perdas em 'D' unidades, do recebido ao esperado
Perdas=Perdas+D;
else
% Recebido e' mais antigo (menor) que o esperado
L=Received-PonteiroTDM;
% Verifica se esta no intervalo admitido para recuperacao de pacotes atrasados
if L>0 & L<=R;
% Coloca o pacote atrasado recebido na posicao correta no buffer
Buffer(1,(Received-Rx(1,1)+1))=Rx(1,k);

A74

% Decrementa contador de perdas para o pacote recuperado

Perdas=Perdas-1;
end
end
end
end
% Simula Thread de Leitura:
% Le pacotes de forma sequencial
if k>RTT*Ocupacao;
% Reproduz pacote corrente
Playout(1,k-RTT*Ocupacao)=Buffer(1,PonteiroTDM-Buffer(1,1)+1);
PonteiroTDM=PonteiroTDM+1;
end
end
% Base de tempo para Reproducao:
tp=[RTT/2+(RTT*Ocupacao+1)*Tpacote:Tpacote:RTT/2+(Pacotes+RTT*Ocupacao)*Tpacote];
% Informa a quantidade de pacotes perdidos nao recuperados como saida da funcao
SimulaPacotesIETFDC=Perdas
% Plota processo de Reproducao a partir do buffer
figure(3);
plot (Tx(2,:),Tx(1,:),'b',Rx(2,:),Rx(1,:),'g',tp,Playout(1,:),'r');
title('Sequenciamento e Reproducao dos pacotes recebidos ');
xlabel('t (ms)'); ylabel('Numero Sequencia');
drawnow;

E.2 FUNO PARA SIMULAO DE PACOTES COM O NOVO ALGORITMO

function SimulaPacotesNADC(Quantidade,OcupacaoMinima,ProbDesordem)
%%% Arquivo: SimulaPacotesNADC.m
%%% Autor:
Eng. Wilson Dutra Sampaio - LabCom - ENE/UnB
%%% Objetivo: Simulao do atraso sofrido pelos pacotes em uma PSN e sequenciamento
%%%
desses pacotes na recepcao
%%% Algoritmo: Buffer circular auto-gerenciavel com escrita ordenada e leitura sequencial
%%%
(Proposta indita para Dissertao de Mestrado)
% Parmetros:
% Round-trip time da rede (em ms):
RTT=80;
% Tamanho do jitter buffer (em ms):
BufferSize=RTT;
% Ocupacao para inicio da reproducao:
Ocupacao=OcupacaoMinima;
% Duraao de cada pacote (em ms):
Tpacote=1;
% Numero de pacotes da simulacao:
Pacotes=Quantidade;
% Base de tempo:
t = [0:Tpacote:Pacotes*Tpacote];
N = length(t);
% Gera pacotes:
Tx = zeros(3,N);
NS=round(rand(1)*2^16);
Tx(1,1)=NS;
for k=2:N;
Tx(1,k)=NS+k-1;
end
Tx(2,:)=t;
% Transmite pacotes, atribuindo um instante de chegada aleatorio entre [RTT/2; RTT/2+RTT]:
for k=1:N;
Tx(3,k)=t(:,k)+RTT/2;

A75

if rand(1) < ProbDesordem

Tx(3,k)=Tx(3,k)+rand(1)*RTT;
end
end
% Plota pacotes transmitidos e recebidos
figure(1);
plot (Tx(2,:),Tx(1,:),'b.',Tx(3,:),Tx(1,:),'g.');
title('Instantes de Transmissao e Recepcao dos pacotes');
xlabel('t (ms)'); ylabel('Numero Sequencia');
disp('Pressione uma tecla para continuar.');
pause;
% Torna o sistema causal, gerando Rx com os pacotes recebidos por ordem de chegada:
Rx = zeros(2,N);
Cx=Tx;
for k=1:N;
Rx(2,k)=100*RTT; % Forca um instante de recepcao muito grande
for i=1:N;
if Cx(3,i)<=Rx(2,k); % Se o instante de recepcao de Cx (imagem de Tx) e menor que Rx
corrente, troca.
Rx(1,k)=Cx(1,i); % Assume o NS recebido de Cx
Rx(2,k)=Cx(3,i); % Assume o instante de recepcao de Cx
ok=i;
end
end
Cx(3,ok)=200*RTT; % Forca um instante de recepcao maior ainda para o Cx ja' carregado em
Rx
end
% Plota instantes de transmissao e recepcao
figure(2);
plot (Tx(2,:),Tx(1,:),'b',Rx(2,:),Rx(1,:),'g');
title('Recepcao de pacotes por ordem de chegada');
xlabel('t (ms)'); ylabel('Numero Sequencia');
disp('Pressione uma tecla para continuar.');
pause;
% Acomoda pacotes no buffer e gera fluxo de saida:
Buffer=zeros(2,BufferSize);
Playout=zeros(1,Pacotes);
% Inicializacao da Thread de Escrita:
% Grava o primeiro NS e pacote recebido:
NS=Rx(1,1);
PosicaoE=mod(NS,BufferSize)+1; % Porque nao existe indice 0 na matriz
Buffer(1,PosicaoE)=Rx(1,1);
Buffer(2,PosicaoE)=Rx(2,1);
% Inicializa Ponteiro Playout com primeiro NS recebido
PonteiroTDM=NS;
% Inicializacao da Thread de Leitura:
PosicaoL=mod(PonteiroTDM,BufferSize)+1; % Porque nao existe indice 0 na matriz
Perdas=0;
% Simula Aplicacao ativa no Receptor:
for k=2:Pacotes+BufferSize*Ocupacao;
% Simula Thread de Escrita:
% Escreve pacotes de forma reordenada
if k<=Pacotes;
NS=Rx(1,k);
PosicaoE=mod(NS,BufferSize)+1; % Porque nao existe indice 0 na matriz
if NS>PonteiroTDM;
% Grava NS e instante de envio no buffer de reproducao
Buffer(1,PosicaoE)=Rx(1,k);
Buffer(2,PosicaoE)=Rx(2,k);
end
end
% Simula Thread de Leitura:
% Le pacotes de forma sequencial

A76

if k>BufferSize*Ocupacao;
% Reproduz pacote corrente
Playout(1,k-BufferSize*Ocupacao)=Buffer(1,PosicaoL);
PonteiroTDM=PonteiroTDM+1;
PosicaoL=mod(PonteiroTDM,BufferSize)+1; % Porque nao existe indice 0 na matriz
NSLido=Buffer(1,PosicaoL);
if NSLido ~= PonteiroTDM;
% Mitiga Perdas
% Grava PonteiroTDM na posicao corrente, pois NS nao e' o esperado, indicando que esta
atrasado ou perdido
Buffer(1,PosicaoL)=PonteiroTDM;
% Incrementa contador de perdas
if k< Pacotes+BufferSize*Ocupacao;
Perdas=Perdas+1;
end
end
end
end
% Base de tempo para Reproducao:
tp=[RTT/2+(BufferSize*Ocupacao+1)*Tpacote:Tpacote:RTT/2+(Pacotes+BufferSize*Ocupacao)*Tp
acote];
% Informa a quantidade de pacotes perdidos nao recuperados como saida da funcao
SimulaPacotesNADC=Perdas
% Plota processo de Reproducao a partir do buffer
figure(3);
plot (Tx(2,:),Tx(1,:),'b',Rx(2,:),Rx(1,:),'g',tp,Playout(1,:),'r');
title('Sequenciamento e Reproducao dos pacotes recebidos ');
xlabel('t (ms)'); ylabel('Numero Sequencia');
drawnow;

A77