Você está na página 1de 110

MESTRADO PROFISSIONAL EM COMPUTAÇÃO APLICADA – MPCOMP

Universidade Estadual do Ceará - UECE


Centro de Ciências Tecnológicas - CCT

Instituto Federal de Educação, Ciência e Tecnologia do


Ceará - IFCE
Pró-reitoria de Pesquisa, Pós-Graduação e Inovação – PRPI

MICHELLE QUEIROZ DA SILVA

SISTEMA AUTOMATIZADO PARA TESTES


REMOTOS EM REDES METRO ETHERNET

Fortaleza
2013
MICHELLE QUEIROZ DA SILVA

SISTEMA AUTOMATIZADO PARA TESTES


REMOTOS EM REDES METRO ETHERNET

Dissertação apresentada ao Programa de


Mestrado Profissional em Computação
Aplicada da Universidade Estadual do Ceará e
do Instituto Federal de Educação, Ciência e
Tecnologia do Ceará, como requisito parcial
para obtenção do Grau de Mestre em
Computação Aplicada.
Orientador: Prof. Dr. Anilton Salles Garcia.
Co-orientadora: Profª Dra. Verônica Pimentel.
.

Fortaleza
2013

ii
Universidade Estadual do Ceará
Biblioteca Central Prof. Antônio Martins Filho
Bibliotecário (a) Leila Cavalcante Sátiro – CRB-3 / 544

S586s Silva, Michelle Queiroz da.


Sistema automatizado para teste remotos em redes metro
ethernet/Michelle Queiroz da Silva.— 2013.
CD-ROM 109f. : il. (algumas color.); 4 ¾ pol.

“CD-ROM contendo o arquivo no formato PDF do trabalho


acadêmico, acondicionado em caixa de DVD Slin (19 x 14 cm x 7 mm)”.
Dissertação (mestrado) – Universidade Estadual do Ceará, Centro de
Ciências e Tecnologia, Mestrado Profissional em Computação Aplicada,
Fortaleza, 2013.
Área de Concentração: Redes de Computadores.
Orientação: Profª. Drª. Anilton Salles Garcia.
Co-oreintacão: Profª. Drª. Verônica Lima Pimentel de Sousa.
1. Redes de comunicação. 2. Metro ethernet. 3. Teste. 4. RFC 2544. 5.
Gerenciamento remoto. I. Título.

CDD: 001.6

iii
iv
À minha mãe,
Rozimá, mulher guerreira, inspiração da minha
vida e que tanto me apoiou nos momentos
difíceis.

v
AGRADECIMENTOS

Ao Senhor, por ter sido meu refúgio e fortaleza nos momentos mais difíceis e em
todos os outros.

Aos meus orientadores, Prof Dr. Anilton Salles e Profª Dr. Verônica Pimentel,
pelo apoio, paciência, compreensão e companheirismo.

À minha companheira de empreitada, Rita de Cássia, por todo apoio, motivação e


força.

Aos meus amigos e parceiros de MPCOMP, Hédwio, Sales, Germano, Fred,


Hélio, Osman e todos os outros, pela força e torcida.

Ao Prof Dr. Marcos Negreiros por toda compreensão e apoio.

A todo o corpo docente do MPCOMP.

À equipe do SENAI e da Datacom, pela parceria e disponibilidade.

À equipe de apoio administrativo do MPCOMP, Tom e Érika, pela presteza com


que nos atende.

Aos meus grandes amigos Prof. Moisés Oliveira, Prof. Ronaldo Ramos, Profª
Cinthya Machado e Prof. Wellington Belo por todo apoio e motivação para realização deste
mestrado.

Aos amigos e companheiros de trabalho Cid Fraga, Francisco Rafael Secundino,


Maria Auxiliadora Bandeira e Lúcia Leite por todo apoio e presteza.

Ao Prof. Pedro Nascimento, diretor do IFCE Campus Tauá por estar sempre ao
meu lado nos momentos difíceis.

vi
RESUMO

Provedoras de acesso à Internet necessitam utilizar equipamentos de testes para


verificar se os dispositivos de interconexão de redes estão de acordo com as normas e padrões
internacionais. Além disso, é fundamental analisar o desempenho desses equipamentos de
rede, uma vez que as operadoras prestadoras de serviço de acesso à Internet são cobradas pelo
serviço prestado aos seus clientes. Nesse contexto, observa-se a necessidade dos
equipamentos de testes ofertados por uma grande variedade de fabricantes, como o caso do
equipamento TSW900ETH fabricado pela empresa DATACOM. O TSW900ETH é um
dispositivo embarcado que possui diversas funcionalidades para analisar a conformidade e o
desempenho de uma rede de computadores. As principais funcionalidades que se destacam
são: realização de testes de acordo com a RFC 2544, geração de tráfego em diferentes
camadas do modelo OSI (Open Systems Interconnection), análise de um dispositivo de rede
em modo loopback, geração de relatórios, entre outras. Entretanto, esse equipamento testador
possui algumas limitações por ser um dispositivo embarcado. Uma das principais limitações é
a configuração e análise dos resultados de forma amigável e intuitiva. Com isso, o
desenvolvimento de um sistema de testes capaz de realizar monitoração, configuração e testes
remotos surgiu como uma alternativa para solucionar as limitações do tradicional
equipamento TSW900ETH. Espera-se que com a nova versão deste Test Set, além da
possibilidade de testes remotos, possa tornar este equipamento testador mais amigável para os
usuários finais, isto é, tornar as configurações e resultados mais fáceis e intuitivos de modo
que pessoas com menor conhecimento técnico em redes de computadores possam utilizar o
TSW900ETH em testes básicos. Para que isso seja possível, é desenvolvido um protótipo de
sistema que realiza a comunicação do TSW900ETH com um computador pessoal,
possibilitando a configuração dos cenários de testes através de scripts, ou telas amigáveis. É
utilizado como cenário de validação o acesso remoto a vários testadores simultaneamente em
diversos pontos de uma rede Ethernet. Este cenário foi proporcionado pela empresa de
Telecomunicações OI que disponibilizou vários links em localidades remotas para realização
dos testes.

Palavras-Chave: Redes de Comunicação, Metro Ethernet, Testes, RFC 2544, Gerenciamento


Remoto.

vii
ABSTRACT

Internet service providers need to use testing equipment to verify if the


interconnection network devices are in accordance with the international rules and standards.
Besides that, it is fundamental to analyze the performance of these pieces of networking
equipment, once the Internet companies are charged for the service provided to his/her clients.
In this context, a wide variety of testing equipment is noticed, like the TSW900ETH of
DATACOM. The TSW900ETH is an embedded device that has various functionalities to
analyze the conformity and performance of a computer network. The main functionalities
which are highlighted are: testing according to a RFC 2544, traffic generation in different
levels of the model OSI (Open Systems Interconnection), analysis of a network device in
loopback mode, report generation, among others. However, this piece of testing equipment
has some limitations because it is an embedded device. One of the main limitations is the
configuration and the analysis of the results in a friendly and intuitive way. Thus, the
development of a testing system which is able to monitor, set and do remote tests has arisen as
an alternative to solve the limitations of the traditional equipment TSW900ETH. It is
expected that the new version of this Test Set, besides the possibility of remote tests, make
this testing equipment friendlier for its final users, in other words, make its configurations and
results easy and intuitive so that people who have little technical knowledge about computer
network can be able to use the TSW900ETH in basic tests. In order to make this possible, it
was developed a system that establishes the communication of the TSW900ETH with a
personal computer, enabling the configuration of testing sets through scripts, or friendly
screens. It is used as a validation set, the remote access to several testers simultaneously in
varied points of an Ethernet network. This set was provided by OI Telecommunications which
made several links in remote localities for doing the tests available.

Keywords: Communication Networks, Metro Ethernet, Tests, RFC 2544, Remote


Management.

viii
LISTA DE FIGURAS

Figura 1: Projeto original de Metcalf para o padrão Ethernet (10BASE5) .............................. 11


Figura 2: Diferentes padrões Ethernet ...................................................................................... 12
Figura 3: Estrutura do quadro Ethernet .................................................................................... 13
Figura 4: Funcionamento do mecanismo CSMA/CD............................................................... 14
Figura 5: Esquema de Funcionamento do CSMA/CD ............................................................. 15
Figura 6: IEEE 802.3 ................................................................................................................ 16
Figura 7: Modelo básico de uma Rede Metro Ethernet............................................................ 19
Figura 8: Serviço Metro Ethernet ............................................................................................. 20
Figura 9: Serviço Ethernet Line ............................................................................................... 20
Figura 10: Serviço Ethernet Lan .............................................................................................. 20
Figura 11: Modelo de referência de rede .................................................................................. 21
Figura 12: Modelo de Camadas ................................................................................................ 22
Figura 13: Modelo de teste para a RFC 2544 ........................................................................... 24
Figura 14: Esquema de Teste com o TSW900ETH ................................................................. 33
Figura 15: Teste de cabo no TSW900ETH .............................................................................. 34
Figura 16: Teste do sinal óptico ............................................................................................... 34
Figura 17: Teste de Loopback .................................................................................................. 35
Figura 18: Ilustração do modo como os testes de Tráfego e da RFC 2544 devem ser
realizados ................................................................................................................................. 36
Figura 19: Teste de PING e TRACE ROUTE ........................................................................... 38
Figura 20: Redes Metro Ethernet interligadas através de backbones. ...................................... 42
Figura 21: Interligação de redes utilizando Metro Ethernet ..................................................... 43
Figura 22: Teste de um serviço Ethernet .................................................................................. 54
Figura 23: Diagrama de Caso de Uso ....................................................................................... 61
Figura 24: Tela inicial do test set TSW900ETH ...................................................................... 63
Figura 25: Tela de Telnet .......................................................................................................... 64
Figura 26: Execução de Comando via Terminal ...................................................................... 65
Figura 27: Seleção de múltiplas conexões................................................................................ 66
Figura 28: Envio de Configurações via Interface Gráfica ........................................................ 67
Figura 29: Iniciando execução de uma sequência de comandos .............................................. 68
Figura 30: Leitura de Contadores Via Terminal ....................................................................... 69
ix
Figura 31: Exemplo de Relatório Criado pela Aplicação, nesse caso Throughput .................. 70
Figura 32: Gráfico Gerado para Acompanhamento do Teste de Throughput .......................... 71
Figura 33: Listagem dos Scripts prontos para Execução .......................................................... 72
Figura 34: Disposição para Conversão de Scripts .................................................................... 73
Figura 35: Carregando Perfis já Salvos Anteriormente ............................................................ 74
Figura 36: Exportando e Salvando Relatórios em PDF............................................................ 75
Figura 37: Tela para Login de Usuários ................................................................................... 76
Figura 38: Tela para Inserção de Chave de Liberação ............................................................. 77
Figura 39: Gráfico de Tempo Médio de Tratamento de BA (boletim de atendimento) em
Horas. Dados referentes ao período entre 1 e 07 de Outubro/2012 .......................................... 85
Figura 40: Tempo médio de reparo em circuitos ...................................................................... 87

x
LISTA DE TABELAS

Tabela 1: Padrão IEEE 802.3 ................................................................................................... 16


Tabela 2: Vazão máxima para diferentes tipos de pacotes ....................................................... 25
Tabela 3: Vazão Típica de Algumas Aplicações ...................................................................... 26
Tabela 4: Ocupação dos Links da OI por geografia.................................................................. 86

xi
LISTA DE ABREVIATURAS E SIGLAS

BACKBONE Designa o esquema de ligações centrais de um sistema mais amplo,


tipicamente de elevado desempenho.
BERT Bit Error Rate Test (Taxa de erro de BIT).
BURSTS Rajada de tráfego de curta duração.
CAPES Coordenação de Aperfeiçoamento de Pessoal de Nível Superior.
DHCP Dynamic Host Configuration Protocol (Protocolo de configuração dinâmica de
host).
DTU Data Terminal Unit (Nome designado ao equipamento, componente ou sistema a
ser testado).
DWDM Dense wavelength division multiplexing (Multiplexação por Divisão de
Comprimento de Onda).
EPO European Patente Office (Escritório de patentes da Europa).
FINEP Financiadora de Estudos e Projetos é uma empresa pública vinculada ao
Ministério da Ciência e Tecnologia (MCT).
FTP File Transfer Protocol (Protocolo de Transferência de Arquivos).
G.114 Recomendação que define características de codificação e decodificação de canais
HTTP Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto.
IETF Internet Engineering Task Force.
INPI Instituto Nacional de Propriedade Industrial.
IPG Interpacket Gap.
ITU-T Telecommunication Standardization Sector.
LAN Local Area Network (Rede de Área Local).
MAC Media Access Control.
MEF Metro Ethernet Forum.
MEN Metro Ethernet Network.
NCITS TR-25:1999 Padrões de Teste de erro de Bit.
OTN Optical Transport Network (Rede Óptica de Transporte).
P2P Peer to Peer (Arquitetura de sistemas distribuídos, caracterizada pela
descentralização das funções na rede, onde cada nó realiza tanto funções de servidor quanto
de cliente)
PCM Pulse Code Modulation (Modulação por codificação de pulso).
xii
PAYLOAD Informação útil do pacote
PING Utilitário que usa o protocolo ICMP para testar a conectividade entre
equipamentos
PIPE Redirecionamento da saída padrão de um programa para a entrada padrão de outro
Q-in-Q Queue-in-Queue. Forma de encapsulamento de protocolos
QoS Quality of Service
SLA Service Level Agreement (Acordo de nível de Serviço).
TIC Tecnologia da Informação e Comunicação.
TCP/IP Transmission Control Protocol / Internet Protocol.
TELNET Protocolo que permite a interface de terminais e de aplicações através da Internet.
TIMESTAMP Informação codificada identificando quando um determinado evento
ocorrer.
Trace Route Ferramenta de diagnóstico que rastreia a rota de um pacote através de
uma rede de computadores.
UNI User Network Interface.
USPTO Escritório Norte-Americano de Patentes
VLAN Virtual Local Area Network
VPN Virtual Private Network
WEB Word Wide Web

xiii
SUMÁRIO

1 INTRODUÇÃO ................................................................................................................. 1

1.1 CONTEXTUALIZAÇÃO ..................................................................................................................................... 1


1.2 MOTIVAÇÃO DO TRABALHO ................................................................................................................... 3
1.3 JUSTIFICATIVA DO TRABALHO ....................................................................................................................... 5
1.4 OBJETIVOS ..................................................................................................................................................... 5
1.4.1 Objetivo Geral ....................................................................................................................................... 5
1.4.2 Objetivos Específicos ............................................................................................................................. 6
1.5 METODOLOGIA DE DESENVOLVIMENTO DO TRABALHO ................................................................................. 6
1.6 RESULTADOS A SEREM OBTIDOS ................................................................................................................... 7
1.7 PRINCIPAIS CONTRIBUIÇÕES .......................................................................................................................... 7
1.8 ORGANIZAÇÃO DO TRABALHO ....................................................................................................................... 8

2 REDES METRO ETHERNET E PADRÕES DE TESTES................................................ 9

2.1 APRESENTAÇÃO DO CAPÍTULO ....................................................................................................................... 9


2.2 INTRODUÇÃO ................................................................................................................................................. 9
2.3 O PADRÃO ETHERNET .................................................................................................................................. 10
2.3.1 Evolução do Padrão Ethernet.............................................................................................................. 11
2.3.1.1 Estrutura do quadro Ethernet .........................................................................................................................13
2.3.1.2. CSMA/CD: O protocolo de acesso múltiplo da Ethernet...............................................................................13
2.3.2 IEEE 802.3........................................................................................................................................... 15
2.3.3 Redes Metro Ethernet .......................................................................................................................... 18
2.3.3.1 Arquitetura ......................................................................................................................................................21
2.4 RFC 2544 .................................................................................................................................................... 22
2.4.1 Vazão ................................................................................................................................................... 24
2.4.2 Latência ............................................................................................................................................... 26
2.4.3 Jitter ..................................................................................................................................................... 26
2.4.4 Perda de Quadro .............................................................................................................................. 28
2.4.5 Erro ...................................................................................................................................................... 28
2.4.6 Sobrecarga Excessiva .......................................................................................................................... 28
2.4.7 Atraso Excessivo .................................................................................................................................. 29
2.4.8 Análise Fim-a-Fim (end to end)........................................................................................................... 29
2.4.9 Largura de Banda ............................................................................................................................... 30
2.5 EQUIPAMENTOS DE T ESTE PARA REDES METRO ETHERNET ....................................................................... 31
2.5.1 Testes Disponíveis .............................................................................................................................. 33
2.5.1.1 Teste de Diagnóstico de Cabo.........................................................................................................................33
2.5.1.2 Teste de Sinal Óptico ......................................................................................................................................34
2.5.1.3 Teste de Loopback ..........................................................................................................................................34

xiv
2.5.1.4 Teste de Camada 2 ..........................................................................................................................................35
2.5.1.5 Teste de Tráfego .............................................................................................................................................36
2.5.1.6 Teste da RFC 2544 .........................................................................................................................................36
2.5.1.7 Teste de Camada 3 (Rede) ..............................................................................................................................37
2.6 CONSIDERAÇÕES FINAIS DO CAPÍTULO ........................................................................................................ 38

3 TESTES EM REDES DE COMUNICAÇÃO ............................................................... 39

3.1 APRESENTAÇÃO DO CAPÍTULO ..................................................................................................................... 39


3.2 VISÃO GERAL SOBRE REDES MULTIMÍDIA ................................................................................................... 39
3.2 TESTES EM REDES MULTIMÍDIA ................................................................................................................... 41
3.3.1 Tipos de Testes ..................................................................................................................................... 43
3.3.1.1 Teste Digital ...................................................................................................................................................43
3.3.1.1.1 Interface G703 ........................................................................................................................................43
3.3.1.1.2 Interface Ethernet ...................................................................................................................................45
3.3.1.1.3 Interface Óptica.......................................................................................................................................46
3.4 TRABALHOS RELEVANTES – O ESTADO DA ARTE ........................................................................................ 46
3.5 CONSIDERAÇÕES FINAIS DO CAPÍTULO ........................................................................................................ 52

4 DECLARAÇÃO DO PROBLEMA ............................................................................... 53

4.1 APRESENTAÇÃO DO CAPÍTULO ..................................................................................................................... 53


4.2 CONTEXTUALIZAÇÃO DO PROBLEMA ........................................................................................................... 53
4.3 SISTEMA PROPOSTO PARA TESTES EM REDES METRO ETHERNET ................................................................. 56
4.3.1 Resumo das Características Funcionais da Plataforma de Teste........................................................ 57
4.3.2 Requisitos do Software......................................................................................................................... 58
4.4 SOLUÇÃO TECNOLÓGICA PARA IMPLEMENTAÇÃO DA PLATAFORMA ........................................................... 60
4.4.1 Interfaces e Protocolos ........................................................................................................................ 62
4.4.2 Implementação da Ferramenta ............................................................................................................ 62
4.5 TESTES INICIAIS DE VALIDAÇÃO DO PROTÓTIPO .......................................................................................... 77
4.5.1. Conexão com o TSW900ETH.............................................................................................................. 77
4.5.1.1 Conectar-se a um TSW900ETH .....................................................................................................................77
4.5.1.2. Múltiplas Conexões .......................................................................................................................................79
4.5.2. Configuração Remota ......................................................................................................................... 79
4.5.2.1 Configurações Manuais ..................................................................................................................................79
4.5.2.2 Profile .............................................................................................................................................................80
4.5.3. Atualização dos Comandos ................................................................................................................. 81
Testes sugeridos ............................................................................................................................................ 81
4.5.4. Arquivos de Script .lua........................................................................................................................ 81
4.5.5. Conversão de Scripts .......................................................................................................................... 81
Testes Sugeridos ........................................................................................................................................... 81
4.5.6. Relatórios............................................................................................................................................ 82
4.6 CONSIDERAÇÕES FINAIS DO CAPÍTULO ........................................................................................................ 83

xv
5 CONCLUSÕES, TRABALHOS FUTUROS .................................................................... 84

5.1 CONCLUSÕES ............................................................................................................................................... 84


5.2 TRABALHOS FUTUROS ................................................................................................................................. 87

REFERÊNCIAS ..................................................................................................................... 89

xvi
1 INTRODUÇÃO

1.1 Contextualização

O avanço tecnológico que o mundo vem sofrendo é notório. Cada vez mais novas
tecnologias são implementadas, trazendo melhorias sobre sistemas já existentes ou inovando
com novas soluções. Essa evolução é comprovada no que se refere às telecomunicações,
interligando as redes digitais, proporcionando a convergência de informações, a transmissão
de dados em alta velocidade e baixo custo.
Na era da convergência, grande parte das informações é transmitida através da
Web1. Empresas de todos os portes são interligadas e se comunicam através de backbones2
(redes de transporte) de alta velocidade. Usuários residenciais se conectam à Internet através
de redes de acesso em banda larga, possibilitando a utilização de todos os tipos de
informações e serviços disponíveis.
Metro Ethernet são redes que utilizam o padrão Ethernet para áreas
metropolitanas e geograficamente distribuídas. São consideradas plataformas multisserviços
por darem suporte a diversas aplicações e serviços multimídia e em rede (MEF, 2011). O
conceito de redes Metro Ethernet surgiu devido a convergência de redes que suportem
aplicações multimídia, agregando baixo custo e altas velocidades. Novas tecnologias foram
agregadas e se fez necessário a criação de novos equipamentos e protocolos para transporte de
informação a longa distância. A tecnologia Ethernet, que já se mostrava eficiente para
aplicações em redes locais (LANs), foi escolhida para transporte de dados a longa distância
devido a seu baixo custo, flexibilidade e facilidade de manutenção. Essa tecnologia está sendo
uma das mais implementadas para aplicações de transporte de dados em alta velocidade,
principalmente pelas operadoras de telecomunicações (MEF, 2011). Do ponto de vista das
operadoras de telecomunicações para redes de longa distância, as soluções mais eficientes e
viáveis utilizam a Rede Metro Ethernet encapsulada em OTN (Optical Transport Networks).
Segundo levantamento realizado pela operadora OI, em Outubro de 2012 os trechos atendidos
por essas tecnologias apresentavam congestionamento e consequentemente necessidade de

1
Web - Word Wide Web.
2
Backbone - No contexto de redes de computadores, o backbone (backbone traduzindo para português, espinha
dorsal, embora no contexto de redes, backbone signifique rede de transporte) designa o esquema de ligações
centrais de um sistema mais amplo, tipicamente de elevado desempenho.
1
expansão, devido ao crescimento da demanda (TNL PCS, 2012). As redes OTN utilizam
fibras ópticas para o transporte de informação. Além disso, fazem uso da multiplexação
DWDM3 (Dense Wavelength Division Multiplexing), ou seja, a multiplexação por divisão de
comprimento de onda, para otimizar recursos e largura de banda.
Destacam-se, nesta dissertação, os esforços que vêm sendo realizados pelas
empresas da área de Telecomunicações em proporcionar tecnologias de comunicação que
atendam a essa demanda agregando alta qualidade e baixo custo. A tecnologia em foco nesta
pesquisa são os anéis Metro Ethernet disponibilizados pelas operadoras de Telecomunicações
e regulamentados através do padrão IEEE 802.3 (IEEE 802.3, 2011) e da RFC 2544 (IETF
RFC 2544, 1999), que definem o protocolo Ethernet e os padrões de teste para o protocolo
Ethernet.
As Redes Metro Ethernet utilizam fibras ópticas como meio físico de transmissão,
disponibilizando velocidades que podem variar de 10Mbps (Padrão Ethernet), 20Mbps,
34Mbps, 100Mbps (Padrão Fast Ethernet), 1Gbps (Padrão Gigabit Ethernet), 10Gbps (Padrão
10 Gigabit Ethernet), chegando a 100 Gigabit Ethernet. Além disso, podem ser
implementadas nas topologias em estrela, em anel, malha total ou parcial. Essa tecnologia
vem expandindo-se como solução para as interligações de redes em alta velocidade, bem
como para o provimento de acesso a Internet através do uso de tecnologias de banda larga,
devido a sua capilaridade de alcance metropolitano, alta confiabilidade, facilidade na sua
instalação, flexibilidade e economia. Todas essas vantagens são possibilitadas pela utilização
do padrão Ethernet em redes de alcance metropolitano, agregando baixo custo, segurança e
taxas de transmissão em alta velocidade (IEEE 802.3, 2011).
Os usuários desses tipos de acesso buscam uma alta disponibilidade de operação
de seus links, fazendo com que as operadoras forneçam SLAs4 (Service Level Agreement)
variando entre 95% a 99% de disponibilidade de acesso (ANATEL, 2010). Para garantir esse
rígido acordo de nível de serviço é necessário que as operadoras de Telecomunicações
otimizem e automatizem o processo de manutenção dos acessos de seus usuários,
possibilitando a redução de tempo na correção dos defeitos e restauração do funcionamento
dos acessos.

3
DWDM – Multiplexação por Divisão de Comprimento de Onda.
4 SLA – Acordo de nível de serviço. Um Acordo de Nível de Serviço (ANS ou SLA, do inglês Service Level
Agreement) é um acordo firmado entre a área de TI e seu cliente interno, que descreve o serviço de TI, suas
metas de nível de serviço, além dos papéis e responsabilidades das partes envolvidas no acordo.
2
Grande parte das redes de comunicações das operadoras de telecomunicações
possui gerenciamento remoto, o que possibilita a verificação de falhas e alguns testes de
diagnósticos remotos. Porém, para correção de defeitos, mesmo possuindo o gerenciamento
de suas redes, faz-se necessário o acionamento de um técnico para verificação e testes locais.
Dependendo da capilaridade do circuito, o técnico necessita realizar diversos deslocamentos
para testes em todos os pontos dos circuitos. Isso demanda bastante tempo, o que prejudica o
SLA contratado pelo cliente, gerando multas, algumas vezes gigantescas, para as empresas
operadoras.
Tendo em vista a necessidade de otimização do tempo de reparo dos circuitos de
comunicação de dados das operadoras de telecomunicações, surgiu a motivação para o
desenvolvimento de um sistema automatizado de testes remotos, foco desta dissertação. Este
sistema proporciona o acesso remoto a todos os pontos da rede, possibilitando a realização de
testes e diagnóstico de falhas a distância, otimizando recursos e principalmente o tempo de
deslocamento dos técnicos nas manutenções.

1.2 Motivação do Trabalho

O SENAI (Serviço Nacional de Aprendizagem Industrial) atua constantemente em


pesquisas que buscam soluções de melhorias e otimização do processo industrial. Essa
instituição tem como missão promover a educação profissional e tecnológica, a inovação e a
transferência de tecnologias industriais, contribuindo para elevar a competitividade da
Indústria (SENAI, 2010).
Visando essa otimização no processo de manutenção em circuitos de comunicação
de dados das grandes operadoras de telecomunicações, surgiu, no SENAI, um grupo de
estudos voltados para a pesquisa e o desenvolvimento de uma solução que possibilitasse a
automatização dos processos de testes e manutenção em redes Metro Ethernet.
Atualmente, os equipamentos utilizados para testes, denominados de test set5,
realizam testes locais ou ponto a ponto (que utilizam um par de equipamentos) que estão
especificados na RFC 2544. Essa RFC define uma série de testes que podem ser realizados
para avaliação do desempenho de uma rede de comunicação (IETF RFC 2544, 1999). Além
disto, essa RFC define como os resultados desses testes devem ser apresentados (gráficos,
estatísticas, dentre outros).

5
Teste Set: Equipamento utilizando para testes em circuitos e links
3
Na realização de testes utilizando os test set, observam-se algumas limitações e
inconveniências. Muitas vezes os testes locais não são suficientes, pois há a necessidade de
deslocamento para outra ponta do circuito em rede, usando outro tipo de teste, o ponto a
ponto, o que demanda dois instrumentos, dois técnicos, tempo de deslocamento e outras
inconveniências associadas (chuvas, congestionamento, greves no sistema de transporte,
dentre outros). Surge assim, a necessidade de implementação de melhorias nesse processo de
teste em redes. Esta dissertação tem por interesse maior a busca de uma solução para o
processo de testes em redes Metro Ethernet.
A autora desta dissertação vivenciou a função de Técnica de Manutenção de
Circuitos de Dados da Empresa OI (OI Telecom) do grupo TNL PCS (2001 a 2008). No
exercício da função de manutenção, um técnico enfrenta adversidades que, muitas vezes,
atrapalham o bom andamento e agilidade da manutenção a ser executada. Há uma real
necessidade de otimizar os recursos humanos, bem como os recursos materiais, nos
procedimentos de testes em redes de comunicação. Como mencionado anteriormente, uma
empresa que presta serviços de telecomunicações a clientes exigentes, pode ter sérios
prejuízos quando os contratos (SLAs) não são rigorosamente cumpridos. Equipamentos que
não atendem às necessidades ou com funcionalidades limitadas são fatores de baixa
produtividade na atividade de testes. A Indústria deve ter interesse em desenvolver
inteligência e automação para processos dessa natureza.
Objetivando o cumprimento de sua missão de inovação, motivado pelo potencial
de demanda por automatização do processo de testes em circuitos de comunicação, o SENAI
observou, neste segmento de mercado, uma excelente oportunidade de negócios. Com isso,
para promover a inovação e contribuir para a elevação da competitividade da Indústria, o
SENAI está fornecendo condições para que um grupo de pesquisa atue no seu
desenvolvimento.
Vislumbrando um produto inovador para automatização de testes, surgiu a ideia
de se buscar parceria com a indústria Datacom6 e desenvolver um projeto concreto de um
equipamento mais inteligente e produtivo para teste em redes de comunicação.

6
Datacom – Empresa fabricante de equipamentos de telecomunicações e instrumentos de testes
4
1.3 Justificativa do Trabalho

A implementação de uma rede multimídia, voltada à integração dos serviços de


voz, dados, mensagens, imagens e vídeo é algo irreversível, principalmente pela redução
significativa com custos de infraestrutura e melhoria da qualidade nas transmissões. A
convergência entre as redes comutadas por circuitos e pacotes em uma única rede,
implementada pela tecnologia IP (Internet Protocol), é uma realidade no mercado de
tecnologia da informação e comunicação (TIC), que se observa pelo crescimento, ampliação e
largura de banda dos backbones de comunicação. Essa convergência teve sua expansão
favorecida com a popularização da Internet, dos acessos em banda larga e do crescimento das
capacidades de processamento e de transmissão.
Além desse crescimento em infraestrutura, a evolução digital associada às TICs,
possibilitou a convergência de plataformas e serviços. Com a popularização da Internet e
diversificação de seus serviços, tecnologias como as redes Metro Ethernet, passaram a
implementar novos tipos de recursos e ainda possibilitaram a redução de custos em seus
serviços para clientes residenciais e coorporativos.
A infraestrutura das redes Metro Ethernet necessita de manutenções otimizadas,
eficientes e rápidas, dada a sua importância. Este trabalho de pesquisa justifica-se pela
importância da agilidade no processo de manutenção de redes, principalmente quando essas
constituem a infraestrutura de comunicação e proveem acessos a serviços multimídia para um
grande público de usuários.

1.4 Objetivos

1.4.1 Objetivo Geral


Desenvolver um sistema de comunicação que será instalado em equipamentos de
testes para redes Metro Ethernet, que possibilite a realização de testes e configurações de
forma remota.

5
1.4.2 Objetivos Específicos
Para alcançar o objetivo geral, foram definidos alguns objetivos específicos:
• Desenvolver um software que possibilite a automatização de testes.
• Definir o tipo de interface e o protocolo de comunicação que possibilitarão a
comunicação do equipamento com a rede e o PC.
• Instalar o software de comunicação no equipamento de teste.
• Realizar os testes do equipamento em laboratório e em ambiente real.
• Documentar, analisar e criticar os resultados obtidos com os testes.

1.5 Metodologia de Desenvolvimento do Trabalho

Do ponto de vista de seu objetivo geral, esta dissertação caracteriza-se, quanto a


sua natureza, como uma pesquisa aplicada, ou tecnológica, uma vez que se destina à geração
de conhecimentos para aplicação prática, dirigidos à solução de problemas específicos.
Quanto aos procedimentos metodológicos, visando atingir os objetivos propostos, este
trabalho de pesquisa foi dividido em algumas etapas, conforme apresentado a seguir:
• Pesquisa bibliográfica e estudo do padrão de comunicação Ethernet e dos padrões
de testes da RFC 2544.
• Estudo aprofundado das funcionalidades do equipamento TSW900ETH7 em
laboratório, observando e registrando o seu comportamento.
• Desenvolvimento do software que possibilitará a automatização dos testes
existentes do equipamento em questão em plataforma de programação. É utilizada
a linguagem Java, por ser multiplataforma e a linguagem Lua devido ao fato dessa
linguagem já existir e ser utilizada para interpretação de scripts no test set
TSW900ETH.
• Definição da interface de comunicação que possibilitará a interligação do
equipamento ao PC. Para isso é realizado um estudo nas interfaces já existentes no
equipamento, para verificar a viabilidade de utilização de uma das portas de acesso
do equipamento como interface de comunicação sem causar prejuízo ao mesmo.

7
TSW900ETH: Equipamento de teste fabricado pela empresa Datacom escolhido para implementação do
sistema.
6
• Instalação do software desenvolvido no equipamento alvo, como firmware que
possibilitará os testes de forma remota.
• Validação das novas funcionalidades do equipamento em ambiente real, utilizando
um determinado circuito Metro Ethernet disponibilizado pela operadora OI
Telecom.
• Documentação e análise de todos os resultados dos testes.

1.6 Resultados a Serem Obtidos

Como principais resultados a serem obtidos nesta dissertação têm-se:


• Produção de um software mais inteligente para testes.
• Implementação da facilidade de testes de forma remota, bem como o acesso remoto ao
teste set TSW900ETH, produzido pela empresa Datacom.
• Redução de custos, implantação de melhorias e facilidades em serviços de manutenção
e certificação de redes Metro Ethernet.
• Criação de um produto Inovador que será posteriormente submetido ao processo de
patente junto ao INPI.

1.7 Principais Contribuições

A implementação de uma plataforma de teste automatizada, acoplada ao


equipamento TSW900ETH (produzido e comercializado pela empresa Datacom), possibilita a
realização de testes, manutenção e certificação em redes Metro Ethernet, de forma remota,
gerando com isso uma redução significativa nos custos de manutenção e/ou certificação
dessas redes. A funcionalidade de acesso remoto é um grande diferencial nesse tipo de
equipamento portátil, onde se pode também armazenar os dados resultantes em um servidor
web possibilitando a análise remota dos testes. A plataforma de teste foi desenvolvida através
de financiamento disponibilizado pela empresa Datacom e o SENAI - Departamento Regional
do Ceará, somando a experiência e a popularidade dessas duas instituições na garantia de seu
sucesso, bem como seu posterior patenteamento e comercialização.
Além da contribuição no investimento em tecnologia e em patentes brasileiras, o
desenvolvimento desta dissertação tem um impacto social, econômico e ambiental, gerando

7
emprego e renda de forma direta e indireta, aumentando a capacidade produtiva da empresa
Datacom e ampliando o acervo tecnológico do SENAI em seus treinamentos.

1.8 Organização do Trabalho

Esta dissertação está organizada em cinco capítulos. Além deste capítulo, que
apresenta a Introdução, há mais quatro capítulos com o seguinte conteúdo:

• No Capítulo 2 é apresentada uma Fundamentação Teórica composta de uma


revisão da literatura sobre os principais conceitos que envolvem o domínio de
conhecimento acerca de Redes Metro Ethernet, monitoramento e padrões de testes.
• No Capítulo 3 é apresentada a proposta da dissertação propriamente dita. São
apresentadas as argumentações, os trabalhos relacionados e a proposta da pesquisa
em si. Neste capítulo é dado destaque aos trabalhos relacionados ao tema em
estudo, enfatizando ainda as principais características desses trabalhos, as lacunas
encontradas e os pontos a serem considerados.
• No Capítulo 4 é apresentada uma discussão a respeito dos diversos testes
realizados em redes de comunicação, focando em redes de longa distância e nas
ferramentas e equipamentos de testes existentes. Neste capítulo também são
apresentados os testes e as análises dos mesmos quanto as novas funcionalidades
do equipamento ao qual se agregam novos valores.
• No Capítulo 5 encontram-se as conclusões do trabalho, as contribuições, as
dificuldades e as propostas de trabalhos futuros.

8
2 REDES METRO ETHERNET E PADRÕES DE TESTES

2.1 Apresentação do Capítulo

Conforme o objetivo desta dissertação que visa novas funcionalidades em


equipamentos de teste para redes de tecnologia Metro Ethernet, este capítulo aborda três
tópicos básicos para o entendimento da proposta:
- O primeiro diz respeito à própria tecnologia básica da infraestrutura de rede de
comunicação de alcance metropolitano, o padrão Ethernet.
- O segundo refere-se à RFC 2544 que especifica os procedimentos de testes em
redes de comunicação.
- O terceiro aborda os equipamentos utilizados em testes de redes de comunicação
com tecnologia Ethernet.
O texto tem por objetivo mostrar a fundamentação teórica, através da explanação
dos conceitos clássicos da disciplina na qual o presente trabalho se insere.

2.2 Introdução

O setor de TICs vem passando por constante evolução, propiciada principalmente


pela redução de custos com acesso à Internet via banda larga. A primeira década do século
XXI foi marcada pelo crescimento da população com acesso à Internet. No início dos anos
1990, a Internet iniciou sua expansão mundial e, em menos de duas décadas, mudou a vida
das pessoas em todo o mundo cumprindo bem o papel referente à sua característica primária,
a de garantir a efetiva eliminação de distâncias para a troca de informações. O surgimento da
World Wide Web (WWW) levou a Internet para os lares, empresas e a milhões de pessoas no
mundo inteiro, servindo, dessa forma, como plataforma para a habilitação e a disponibilização
de centenas de novas aplicações (KUROSE e ROSS, 2010), possibilitando a expansão em
escala mundial da Tecnologia da Informação e Comunicação.
Em 2000 o número de domicílios com acesso à Internet banda larga era de 200
mil e, segundo o senso, em 2010 passou para 17,4 milhões, representando um crescimento de
mais de 80 vezes nos últimos dez anos (IBOPE, 2010). Segundo o IBOPE/ NetRatings, somos
79,9 milhões de internautas no Brasil, sendo o Brasil o 5º país mais conectado (IBOPE, 2010).

9
De acordo com a Fecomércio8, o percentual de brasileiros conectados à Internet aumentou de
27% para 48%, entre 2007 e 2011 (FECOMÉRCIO, 2011). Ainda falando do cenário
brasileiro, existe o Plano Nacional de Banda Larga (PNBL) que favorece ainda mais esse
crescimento. No cenário mundial esse cenário não poderia ser diferente. De acordo com
estimativas da União Internacional de Telecomunicações (UIT), a banda larga móvel no
mundo cresceu 26,2% em 2011. No Japão, por exemplo, mais de 50% da receita líquida das
operadoras é representada por uso de dados; nos Estados Unidos, 40%; na Europa esse
número já supera os 30% (UIT, 2011). No Brasil, a receita bruta de dados representou 20,9%
da receita de serviços das operadoras em 2011 e tende a aumentar devido à convergência de
informação (UIT, 2011). Esse aumento na quantidade de serviços de acesso à Internet foi
propiciado principalmente com a redução da infraestrutura necessária para prover acessos à
Internet, pela evolução das tecnologias de transmissão, pela evolução dos protocolos de
comunicação e pela evolução das tecnologias de redes de alta velocidade.
A rápida evolução de serviços Ethernet possibilitou o surgimento de soluções
integradas, padronizadas e simplificadas, ferramentas de gerência, aplicações em classes de
serviços, disponibilizando maior acessibilidade e gerando oportunidades estratégicas,
reduzindo custos e com isso ampliando receitas e trazendo vantagem competitiva para
empresas, provedores de serviços e operadoras através de uma rede globalizada (MEF, 2011).
Como se pode ver, são grandes as contribuições para esse avanço tecnológico que se
está vivenciando no setor de TICs. Tomando-se por base esse avanço, esta dissertação
contempla o desenvolvimento de uma plataforma de testes automatizado que possibilita a
implementação de inúmeras melhorias nos serviços de comunicação de dados das operadoras
de Telecomunicações e das diversas empresas que possuam a tecnologia Metro Ethernet em
seu parque tecnológico.

2.3 O Padrão Ethernet

O Padrão Ethernet praticamente tomou conta do mercado de LANs (Local Area


Network). Desde sua invenção, em meados da década de 1970, a Ethernet continuou a se
desenvolver e crescer e conservou sua posição dominante no mercado. Hoje, ela é
notadamente a tecnologia preponderante de LAN e devido aos seus inúmeros benefícios, essa

8
FECOMÉRCIO: Federação do Comércio
10
tecnologia está sendo utilizada e vem expandindo-se para aplicações em redes metropolitanas
(KUROSE e ROSS, 2010).
A tecnologia Ethernet aparece em diferentes versões e foi padronizada através dos
anos pelo grupo de trabalho IEEE 802.3. Essas diversas versões da tecnologia são expressas
através dos acrônimos 10BASE-T, 10BASE-2, 100BASE-T, 1000BASE-LX e 10GBASE-T.
A primeira parte do acrônimo refere-se à velocidade padrão: 10, 100, 1000 ou 10G, por 10
Megabits (por segundo), 100 Megabits e 10 Gigabits Ethernet, respectivamente. “BASE” se
refere à transmissão em banda base da Ethernet, significando que a mídia só suporta um sinal
por vez. A parte final do acrônimo faz referência à mídia em si; a Ethernet é tanto uma
camada de enlace como uma camada física que inclui um cabo coaxial, fio de cobre e fibra
óptica. Essas características definem essa tecnologia e suas variações (IEEE 802.3, 2011).
Inúmeras são as vantagens do padrão Ethernet e suas variações. Dentre elas,
podem-se destacar: a popularidade da tecnologia, o baixo custo para a implantação,
transmissão de dados em alta velocidade, protocolo bem consolidado, facilidade e
flexibilidade em sua instalação/manutenção. Tendo em vista as inúmeras qualidades e
facilidades existentes na tecnologia Ethernet, esse padrão estendeu-se e passou a ser utilizado
em redes Metropolitanas (MANs), dando origem as Redes Metro Ethernet.

2.3.1 Evolução do Padrão Ethernet

Segundo Kurose (KUROSE e ROSS, 2010) a Lan Ethernet original foi inventada
em meados da década de 1970 por Bob Metcalf e David Boggs. A Figura 1, a seguir,
representa o desenho esquemático da proposta original.

Figura 1: Projeto original de Metcalf para o padrão Ethernet (10BASE5)


Fonte: (KUROSE e ROSS, 2010)

11
O projeto original utilizava um barramento coaxial. Esse tipo de topologia em
barramento foi bastante utilizado durante toda a década de 1980 até meados da década de 90.
Com essa topologia a transmissão ocorria no modo broadcast. No final da década de 90 a
topologia estrela para esse tipo de rede se popularizou (KUROSE e ROSS, 2010).
Uma rede Ethernet a princípio era composta por um segmento de um cabo
coaxial. Os primeiros padrões 10BASE-2 e 10 BASE5 possibilitavam transmissão a 10Mbps
Ethernet sobre dois tipos de cabos coaxiais, limitados a um comprimento de 200 metros e 500
metros, respectivamente. Esse modelo passou por uma grande evolução e a Ethernet atual é
bastante diferente do modelo inicial proposto. No final da década de 90 foi criado o padrão
100 Mbps, 10 vezes mais rápido. Esse padrão preservou o protocolo Ethernet original, porém
foram definidas camadas físicas de alta velocidade para fios de cobre e fibra óptica. Com isso
surge a rede Gigabit Ethernet, uma extensão muito bem sucedida dos padrões 10 Mbps e 100
Mbps. Oferecendo velocidade de 1000 Mbps, a Gigabit Ethernet mantém total
compatibilidade com a imensa base instalada de equipamentos Ethernet. A Ethernet 10 Gbps
foi padronizada em 2007 possibilitando velocidade ainda mais alta de transmissão (KUROSE
e ROSS, 2010).

A Figura 2, a seguir, mostra os diferentes padrões.

Figura 2: Diferentes padrões Ethernet


Fonte: (KUROSE e ROSS, 2010)

Todas as tecnologias Ethernet fornecem serviço não orientado a conexão para a


camada de rede e fornecem um serviço não confiável para essa camada (KUROSE e ROSS,
2010).

12
2.3.1.1 Estrutura do quadro Ethernet

O padrão Ethernet na camada de enlace é responsável pelo endereçamento


Ethernet, tipicamente chamado de hardware ou MAC address. É também responsável pelo
encapsulamento dos pacotes recebidos da camada de Rede e pela preparação deles para
transmissão pela rede local, através do método do acesso ao meio por contenção
(FILIPPETTI, 2008).
A Figura 3 a seguir mostra a estrutura do quadro Ethernet.

Figura 3: Estrutura do quadro Ethernet


Fonte: (MEF, 2011)

Detalhamento da estrutura do quadro Ethernet (KUROSE e ROSS, 2010):


Preâmbulo: Campo composto por 7 bytes com padrão 10101010 seguido por um byte com
padrão 10101011. Esse campo é utilizado para sincronizar transmissor e receptor.
Endereços: Campo composto por 6 bytes. O quadro é recebido por todos os adaptadores e
descartado se o endereço do quadro não coincide com o endereço do adaptador.
Tipo: Indica o protocolo da camada superior, geralmente é o protocolo IP, mas outros podem
ser suportados tais como Novell IPX e AppleTalk.
CRC (Verificação de redundância cíclica): Permite que o adaptador receptor detecte se algum
erro foi introduzido no quadro.

2.3.1.2. CSMA/CD: O protocolo de acesso múltiplo da Ethernet

Como visto anteriormente, Ethernet é um método de acesso ao meio por


contenção (contention media access method) que permite que todos os dispositivos em uma
rede Ethernet compartilhem a mesma largura de banda de um link. O padrão Ethernet utiliza
especificações das camadas de Enlace e Física. Redes Ethernet utilizam uma técnica de acesso
chamada Carrier Sense Multiple Access with Collision Detection (CSMA/CD), que permite
aos dispositivos o compartilhamento homogêneo da largura de banda, detectando possíveis
colisões. Esse método usa um algoritmo randômico para tentar evitar que essas colisões
voltem a ocorrer (exponencial backoff) (FILIPPETTI, 2008).
13
O funcionamento do mecanismo CSMA/CD é relativamente simples e
apresentado na Figura 4 a seguir.

Figura 4: Funcionamento do mecanismo CSMA/CD


Fonte: (FILIPPETTI, 2008)

No intervalo de tempo entre o término da transmissão de um pacote e a geração de


novos, outros hosts podem utilizar o meio de comunicação para enviar seus próprios pacotes.
Quando um host deseja transmitir através da rede, ele primeiramente verifica se há presença
de sinal no meio. Caso não seja constatada a presença de sinal, o host inicia sua transmissão.
O host constantemente monitora o meio e, caso seja detectado outro sinal dele, um sinal de
congestionamento é enviado ocasionando uma pausa na transmissão de dados pelos outros
hosts. Os hosts respondem ao sinal de congestionamento esperando um determinado intervalo
de tempo antes de tentarem novamente o envio de dados. Após quinze tentativas, um time-out
ocorrerá (FILIPPETTI, 2008). A Figura 5 a seguir ilustra esse procedimento

14
Figura 5: Esquema de Funcionamento do CSMA/CD
Fonte: (PUC, 2011)

2.3.2 IEEE 802.3

O IEEE 802.3 é um grupo de trabalho que desenvolve padrões para a Ethernet


baseado em LAN. Esses padrões especificam a camada física e a subcamada MAC9 da
camada de enlace do Modelo OSI para o protocolo Ethernet, tipicamente uma tecnologia
LAN com algumas aplicações WAN. As ligações físicas são estabelecidas entre nós e/ou
dispositivos da infraestrutura (concentradores, comutadores, roteadores) por vários tipos de
cabos de cobre ou fibra óptica (IEEE 802.3, 2011). A Figura 6, a seguir, ilustra essa
organização em camadas e o comparativo com o modelo OSI.

9
MAC: Media Access Control é um endereço físico associado à interface de comunicação, que conecta um
dispositivo à rede.
15
Figura 6: IEEE 802.3
Fonte: (PUC, 2011)

A Tabela 1 mostra um resumo do padrão IEEE 802.3 e sua evolução.


Tabela 1: Padrão IEEE 802.3
Padrão Ethernet Data Descrição
Ethernet Experimental 1972 2.94 Mbit/s (367 kB/s) usando cabo coaxial (coax) Cabo de barramento
10 Mbit/s (1.25 MB/s) Cabo coaxial fino (thinnet) - Quadros possuem
Ethernet II (DIX v2.0) 1982 tipos de campos (Type field). O formato desse quadro é usado em todos
padrões Ethernet pelos protocolos TCP/IP.
10BASE5 10 Mbit/s (1.25 MB/s) Coaxial grosso pelo padrão 802.2 o
IEEE 802.3 1983
cabeçalho LLC segue o cabeçalho do 802.3
802.3a 1985 10BASE2 10 Mbit/s (1.25 MB/s) Coaxial fino (thinnet ou cheapernet)
802.3b 1985 10BROAD36
802.3c 1985 10 Mbit/s (1.25 MB/s) Especificações de um repetidor
802.3d 1987 FOIRL (Link de fibra ótica entre repetidores)
802.3e 1987 1BASE5 ou StarLAN
802.3i 1990 10BASE-T 10 Mbit/s (1.25 MB/s) usando Cabo de par trançado
802.3j 1993 10BASE-F 10 Mbit/s (1.25 MB/s) com Fibra ótica
802.3q 1993 Padrão de VLAN
100BASE-TX, 100BASE-T4, 100BASE-FX Fast Ethernet com 100
802.3u 1995
Mbit/s (12.5 MB/s) com negociação automática
Full Duplex e controle de fluxo; também incorporada quadros DIX,
802.3x 1997
portanto não possui uma quebra com o DIX/802.3
100BASE-T2 100 Mbit/s (12.5 MB/s) usando cabo par trançado de
802.3y 1998
baixo custo
802.3z 1998 1000BASE-X Gbit/s Ethernet usando Fibra ótica a 1 Gbit/s (125 MB/s)
802.3-1998 1998 Uma revisão de padrões básicos com incorporações e erratas.

16
1000BASE-T Gbit/s Ethernet sobre cabo par trançado a 1 Gbit/s (125
802.3ab 1999
MB/s)
Tamanho máximo do quadro 1522 bytes (para permitir "Q-tag"). O Q-
802.3ac 1998 tag é visto na norma 802.1Q VLAN e 802.1p priorização de
informações.
802.3ad 2000 Agregação de links (bundling)
802.3-2002 2002 Uma revisão de padrões básicos com incorporações e erratas.
10 Gbit/s (1,250 MB/s) Ethernet usando Fibra ótica; 10GBASE-SR,
802.3ae 2003 10GBASE-LR, 10GBASE-ER, 10GBASE-SW, 10GBASE-LW,
10GBASE-EW
Power Over Ethernet um formato para enviar dados junto com energia
802.3af 2003
elétrica AC.
802.3ah 2004 Para acesso a redes em uma rede MAN
10GBASE-CX4 10 Gbit/s (1,250 MB/s) Ethernet sobre cabo de cobre a
802.3ak 2004
baixo custo
802.3-2005 2005 Revisão da estrutura básica incorporando 4 padrões e errata.
10GBASE-T 10 Gbit/s (1,250 MB/s) Ethernet usando unshielded
802.3an 2006
twisted pair(UTP)
Backplane Ethernet (1 and 10 Gbit/s (125 and 1,250 MB/s) usando
802.3ap 2007
placa de circuito impresso)
10GBASE-LRM 10 Gbit/s (1,250 MB/s) Ethernet usando Fibra
802.3aq 2006
multimodo
802.3ar 2008 Gerencia de congestionamento
802.3as 2006 Expansão de quadro
802.3at 2008 Melhoras usando Ethernet na rede elétrica
Isolamento necessário para Ethernet na rede elétrica (802.3-2005/Cor
802.3au 2006
1)
802.3av 2009 10 Gbit/s EPON usando fibra ótica
Correção de equação na publicação 10GBASE-T (lançada como 802.3-
802.3aw 2007
2005/Cor 2)
802.3ax 2008 Retirada do Link aggregation do 802.3 para IEEE 802.1
802.3ay 2008 Manutenção do padrão básico
Grupo de Estudo para redes de alta velocidade. 40 Gbit/s sobre 1m
backplane, 10m cabo Cu (4x25 Gbit ou 10x10 Gbit) e 100 m de fibra
802.3ba 2009 ótica multimodo e até 100 Gbit/s para 10 m ou cabo Cu, 100 m de fibra
ótica multimodo ou para 40 km de fibra ótica monomodo
respectivamente.
802.3bd 2011 MAC Control Frame for Priority-based Flow Control.
802.3be 2011 Ethernet MIBs

2011 Ethernet Support for the IEEE P802.1AS Time Synchronization


802.3bf Protocol
802.3bg 2011 40Gb/s Ethernet Single-mode Fibre PMD
P802.3 2001 Ethernet over LAPS liaison Ad hoc
P802.3 2002 Static Discharge in Copper Cables Ad hoc
P802.3 2002 100BASE-FX over dual Single Mode Fibre Call For Interest.
Fonte: (IEEE 802.3, 2011)

17
2.3.3 Redes Metro Ethernet

Metro Ethernet são redes que utilizam a Ethernet para áreas metropolitanas e
geograficamente distribuídas e fornecem uma arquitetura de rede que possibilita o
fornecimento de serviços de conexão de redes MAN/WAN de nível 2 através de UNIs (User
Network Interface) Ethernet. São consideradas plataformas multiserviços por darem suporte a
diversas aplicações e serviços (MEF, 2004).
O conceito de redes Metro Ethernet surgiu devido a convergência de redes que
suportem aplicações multimídia agregando baixo custo e altas velocidades. Isso tornou
obsoleta a utilização da tecnologia TDM (Multiplexação por Divisão de Tempo) e fez-se
necessária a criação de novas tecnologias para transporte de informação a longa distância. A
tecnologia Ethernet foi escolhida para transporte de dados a longa distância devido a seu
baixo custo, eficiência em redes locais, flexibilidade e facilidade de manutenção. Essa
tecnologia é uma das mais implementadas e conhecidas no transporte de dados,
principalmente pelas operadoras de telecomunicações (MEF, 2004).
As redes Metro Ethernet também utilizam fibras ópticas como meio físico de
transmissão, disponibilizando velocidades que podem variar de 10Mbps, 20Mbps, 34Mbps,
100Mbps, 1Gbps, 10Gbps, chegando a 100Gbps. Além disso, podem ser implementadas nas
topologias em estrela, anel, malha total ou parcial (MEF, 2004). A Figura 7, a seguir, ilustra
um exemplo de aplicação da tecnologia Metro Ethernet.

18
Figura 7: Modelo básico de uma Rede Metro Ethernet
Fonte: (MEF, 2006a)

Os benefícios oferecidos pelas redes Metro Ethernet são (MEF, 2006b):


• Capilaridade de alcance metropolitano.
• Alta confiabilidade.
• Facilidade na utilização.
• Economia com os custos de interconexão.
• Flexibilidade.
Quando se trata de aplicações de assinantes, muita das vezes refere-se à conexão
da rede do assinante com um site, por exemplo. Porém, é possível ter vários assinantes (UNIs)
conectando-se em um único site. Da perspectiva de um assinante, tais serviços podem ser
suportados sobre uma variedade de redes de transportes e diversas tecnologias e protocolos
como SDH/SONET (Synchronous Digital Hierarchy/Synchronous Optical NETwork),
DWDM, MPLS (Multi Protocol Label Switching), GFP (Generic Frame Proceduring), dentre
outras (MEF, 2006b).
O esquema básico do serviço Metro Ethernet é mostrado na Figura 8, a seguir. O
provedor da MEN (Metro Ethernet Network) provê os serviços aos clientes. A ponta do
cliente (CE) é conectada a MEN através da interface de rede do usuário (UNI). Do ponto de
vista do provedor da MEN, os serviços podem ser oferecidos baseados em diversas
tecnologias e protocolos, como SDH/SONET, DWDM, MPLS, FRAME RELAY, dentre
19
outros. Do ponto de vista do assinante, a conexão é feita com uma interface Ethernet comum
(MEF, 2006b).

Figura 8: Serviço Metro Ethernet


Fonte: (MEF, 2006b)

O funcionamento básico dos serviços Metro Ethernet é descrito da seguinte


forma: o provedor Metro Ethernet Network (MEN) é responsável por prover os serviços aos
clientes da rede metro. O cliente (CE) é conectado a MEN através da interface de rede do
usuário (UNI), utilizando interfaces Ethernet. Dessa forma, a tecnologia Metro Ethernet
fornece dois tipos de serviços: o serviço Ethernet Line e o serviço Ethernet Lan. Para acesso a
esses serviços, os usuários deverão estar conectados à rede metro através da UNI (interface do
usuário). O Serviço Ethernet Line, ilustrado na Figura 9 a seguir, é responsável pela
comunicação ponto a ponto entre duas UNIs. Já o serviço Ethernet Lan, ilustrado na Figura
10 a seguir, é responsável pela comunicação multiponto entre duas ou mais UNIs. (MEF,
2006c).

Figura 9: Serviço Ethernet Line


Fonte: (MEF, 2006b)

Figura 10: Serviço Ethernet Lan


Fonte: (MEF, 2006b)

20
2.3.3.1 Arquitetura

Para a definição da arquitetura de uma rede Metro Ethernet são utilizados dois
modelos genéricos, ou seja, um modelo que trata da rede mais especificamente e outro que
trata das camadas de rede. A seguir é apresentado o detalhamento dos dois modelos (MEF,
2004):
• Modelo de referência de rede: A Figura 11, a seguir, apresenta o detalhamento sobre
os equipamentos que irão compor a rede e suas interações.

Figura 11: Modelo de referência de rede


Fonte: (MEF, 2004)

Modelo de camadas: A Figura 12, a seguir, apresenta a divisão em camadas do


padrão Metro Ethernet.

21
Figura 12: Modelo de Camadas
Fonte: (MEF, 2004)

A camada de serviços de aplicação, chamada de APP, oferece suporte a aplicações


baseadas nos serviços Ethernet através da MEN. Já a camada de serviços Ethernet, conhecida
como camada ETH é responsável pelos serviços do MAC (controle de acesso ao meio) e pela
entrega dos quadros nas interfaces e nos pontos associados. A camada de serviços de
transporte, conhecida como camada TRAN oferece suporte para conectividade entre os
elementos da camada ETH independentemente dos serviços (MAZZONI, 2008).

2.4 RFC 2544

A RFC 2544 discute e define uma série de testes que podem ser utilizados para
descrever as características e padrões de desempenho de uma rede de comunicação. Além de
definir esses parâmetros, descreve também formatos específicos para comunicação dos
resultados obtidos com esses testes (IETF RFC 2544, 1999)10. Com esses parâmetros torna

10
IETF: (sigla em inglês de Internet Engineering Task Force) é uma comunidade internacional ampla e aberta
(técnicos, agências, fabricantes, fornecedores, pesquisadores) preocupada com a evolução da arquitetura da
Internet e seu perfeito funcionamento. A IETF tem como missão identificar e propor soluções a
questões/problemas relacionados à utilização da Internet, além de propor padronização das tecnologias e
protocolos envolvidos. As recomendações da IETF são usualmente publicadas em documentos denominados
RFCs (Request for Comments).
22
possível ao usuário verificar o desempenho de sua rede conforme o SLA contratado. Para
elaboração desse documento foi utilizado como referência a RFC 1242 (IETF RFC 1242,
1991) que especifica a forma de como interligar dispositivos de redes, onde muitos termos e
terminologias foram aproveitados desse documento.
A RFC 2544 apresenta diversos testes e ensaios possíveis, porém dependendo do
cenário e dos equipamentos utilizados nem todos os testes se aplicam. O recomendado é que
os equipamentos de teste de redes, ou seja, os test set, sigam as recomendações dessa RFC.
A RFC 2544 define que sejam utilizados para teste quadros com vários tamanhos
(64, 128, 256, 512, 1024, 1280 e 1518 bytes) e que sejam enviados por um determinado
intervalo de tempo e por um número definido de vezes. Isso porque todos esses tamanhos de
quadro poderão ser usados na rede e, dessa forma, é necessário verificar os resultados de cada
um deles (BURGESS, 2004).
Os testes mencionados na RFC 2544 são definidos por vazão, latência,
perda de quadros e análise fim-a-fim (end-to-end). O teste tráfego de quadros
entre equipamentos trata de enviar ao DUT11 um Burst12(Rajada) com espaços mínimos
entre quadros e contar o número de quadros que forem encaminhados pelo
DUT. Se o número de quadros encaminhados for igual ao número de quadros
transmitidos, o comprimento do Burst será aumentado e o teste será executado
novamente. Se o número de quadros encaminhados for menor do que o
número transmitido, o comprimento do Burst será reduzido e o teste será
executado novamente. O valor fim-a-fim será o número de quadros do Burst mais longo que o
DUT consegue tratar sem perder nenhum quadro (BRADNER e MCQUAID, 1999).
A Figura 13 a seguir, define o modelo de testes projetado para atender os
critérios de análise da RFC 2544.

11 DUT: Nome designado ao equipamento, componente ou sistema a ser testado.


12 Bursts: Rajada de tráfego de curta duração.
23
Figura 13: Modelo de teste para a RFC 2544
Fonte: (IETF RFC 2544, 1999)

Para os testes embasados na RFC 2544 recomenda-se que os resultados sejam


apresentados nos formatos de texto e gráfico. Os resultados poderão, então, fornecer dados
concretos de desempenho para o provedor de serviço e o cliente (IETF RFC 2544, 1999).

2.4.1 Vazão

Em geral, o conceito de desempenho da rede é associado à sua velocidade. A vazão


de dados expressa a quantidade máxima de dados que pode ser transportada de uma
origem até o seu respectivo destino. Entretanto, a definição e medição da vazão são
complexas pela necessidade de se definir um nível aceitável de qualidade. Por exemplo,
se for considerado que é aceitável um número de 10% de quadros com erros ou perdidos,
então a vazão é medida a uma taxa de erros de 10%. Em qualquer sistema Ethernet, a banda
passante máxima absoluta será igual à taxa de dados, por exemplo, 10 Mbit/s, 100 Mbit/s ou
1000 Mbit/s. Em termos reais, esses números não podem ser alcançados, devido aos
campos adicionais para que os quadros possam ser transportados e pelo espaçamento
entre quadros, necessário para o funcionamento da rede.
Os pacotes menores têm uma vazão efetiva menor do que o dos pacotes
maiores, devido à inclusão dos bytes de cabeçalho e do espaço entre pacotes,
que não contam como dados (BURGESS, 2004). A vazão máxima (teórica) que pode ser
obtida para os diversos tamanhos de quadro está apresentada na Tabela 2, a seguir:
24
Tabela 2: Vazão máxima para diferentes tipos de pacotes

Fonte: (BURGESS, 2004)

A largura de banda expressa a maior capacidade que pode ser obtida através
da transferência. A vazão representa a taxa na qual a informação trafega nivelado pelo
menor valor de transferência (MONTEIRO, SAMPAIO e FIGUEREDO, 2003). A Tabela 3,
a seguir, apresenta os valores indicados para cada tipo de aplicação no serviço Ethernet:

25
Tabela 3: Vazão Típica de Algumas Aplicações

Fonte: (MONTEIRO, SAMPAIO e FIGUEREDO, 2003)

A vazão é uma das métricas mais importantes quando se avalia qualidade de


serviço de uma rede e é necessária para a operação correta de qualquer aplicação. Em
termos práticos as aplicações geram vazões que devem ser atendidas pela rede
(MONTEIRO, SAMPAIO e FIGUEREDO, 2003).

2.4.2 Latência

Latência é o tempo total gasto por um quadro desde a origem até o destino. Esse
tempo absoluto é a soma dos atrasos do processamento nos elementos da rede e o atraso de
propagação ao longo do meio de transmissão (BURGESS, 2004). Para medir a latência, um
quadro de teste contendo uma marca de tempo (timestamp) é transmitido pela rede. A
marca de tempo é então analisada quando o quadro é recebido. Para que isso ocorra, o
quadro de teste precisa voltar ao testador original por um laço de retorno (atraso de ida e
volta). Uma grande latência não indica que ocorrerá degradação da voz, o que pode ocorrer é
uma perda de sincronização. Por exemplo, para que se obtenha uma boa qualidade em
conexões telefônicas, a latência deve possuir um valor abaixo do patamar de 150 ms. Para
que isso aconteça, devem ser tomadas algumas medidas de forma a estabelecer as
alterações que deverão ser tomadas para que incida a diminuição do tempo de
empacotamento, transmissão e transporte dos dados (BURGESS, 2004).

2.4.3 Jitter

A variação de tempo entre chegadas de pacotes do endereço de origem


caracteriza-se como Jitter. Caso ocorresse uma taxa de transmissão constante com intervalo
26
de 20 ms ente cada transmissão de um pacote e outro, tais pacotes deveriam chegar ao
destino com intervalo de 20 ms. Entretanto, como cada pacote pode trafegar na rede por
diferentes rotas e diferentes meios, esse tempo de chegada pode variar, fato este que diminuiria
a qualidade do serviço (BURGESS, 2004).
O Jitter, por exemplo, pode resultar em intervalos de tempo vazios dentro de um
Burst de voz, de forma que a diminuição, ou até mesmo a perda desses intervalos,
resultaria na falta de interpretação da informação no destino. Um valor máximo tolerado,
sem que haja comprometimento da qualidade de voz, calculado segundo uma média
Gaussiana13, considera que os valores devem ser menores do que 225 ms (BURGESS, 2004).
O Jitter causa não somente uma entrega com periodicidade variável (Variação de Pacotes
por Atraso), como também a entrega de pacotes fora de ordem (BURGESS, 2004).
Inicialmente, o problema dos pacotes desordenados poderia ser resolvido
com o auxílio de um protocolo de transporte como o TCP (Transmission Control
Protocol) que verifica o sequenciamento das mensagens e faz as devidas
correções. Entretanto, na prática, a grande maioria das aplicações multimídia
optam por utilizar o UDP (User Datagram Protocol) em vez de TCP, pela maior
simplicidade e menor sobrecarga desse protocolo. Além disso, muitas
estruturas de redes para telecomunicações possuem um desordenamento natural
de pacotes, como por exemplo, multiplexadores PDH 16E1/4E1 que fazem
interação com interfaces Ethernet. Nesses casos, o problema de
sub sequenciamento deve ser resolvido por protocolos de mais alto nível
normalmente incorporados à aplicação como, por exemplo, o RTP (Real Time
Transfer Protocol) ou utilizando técnicas de reordenamento de pacotes em
nível de lógica (BURGESS, 2004).
O Jitter insere variação no processamento da informação na recepção e deve ter
controles específicos de compensação e métodos que dependem da aplicação em questão.
Em geral, uma das soluções mais comuns para o problema consiste na utilização de
Buffers14 (BRADNER e MCQUAID, 1999).

13
Gaussiana: Descreve uma série de fenômenos físicos e financeiros. Possui grande uso na estatística de
inferência. É inteiramente descrita por seus parâmetros de média e desvio padrão, ou seja, conhecendo-se esses é
possível determinar qualquer probabilidade em uma Normal.
14
Buffers: Região de memória temporária utilizada para escrita e leitura de dados
27
2.4.4 Perda de Quadro

A perda de quadros analisa o número de quadros que foram enviados pelo


transmissor e que nunca foram recebidos em seu destino. É normalmente chamada de taxa de
perda de quadros, sendo expressa como uma porcentagem do número total de quadros
transmitidos. Por exemplo, se 1000 quadros foram enviados, mas somente 900 recebidos, a
taxa de perda de quadros seria (1000-900) / 1000 x 100% = 10%. Os quadros podem ser
perdidos ou descartados por várias razões, incluindo erros e atraso excessivo (BURGESS,
2004).
A perda de quadros é outro item crítico que implica de forma direta na
qualidade de serviço. Pacotes perdidos em aplicações que utilizam o protocolo UDP e RTP
não podem ser retransmitidos e mesmo que pudessem não seria nada interessante já que duas
mensagens enviadas em sequência poderiam chegar na ordem inversa, o que não é tolerável
em aplicações de tempo-real (BURGESS, 2004).

2.4.5 Erro

A maioria dos dispositivos da camada 2 descartará um quadro que tiver o valor


de verificação do quadro incorreto (FCS - Frame Check Sequence). Isso significa que um
único erro de bit na transmissão fará com que todo o quadro seja descartado. Esse é um dos
motivos que faz com que o BER, que é a medida mais fundamental em um serviço
SONET/SDH, não tenha significado em Ethernet, pois a relação entre bits corretos e
incorretos não pode ser averiguada (BURGESS, 2004).

2.4.6 Sobrecarga Excessiva

O fator mais comum para a perda de quadros é a sobrecarga excessiva da largura


de banda disponível. Por exemplo, se dois serviços Ethernet de 1000 Mbit/s são mapeados
em um único pipe15 SONET/SDH de 622 Mbit/s (um cenário comum), a largura de banda
será alcançada rapidamente. Quando o limite for atingido, pode haver descarte de quadros
(BURGESS, 2004).

15
Pipe: Tubo/Pacote
28
2.4.7 Atraso Excessivo

O atraso na rede varia do atraso em cada nó e na quantidade de nós entre origem e


destino. A natureza das redes Ethernet torna possível o atraso de quadros por períodos
consideráveis de tempo. Isso é importante para a análise, pois o testador estará “esperando”
que todos os quadros transmitidos sejam recebidos e contados. Em algum momento, o
testador tem que decidir que o quadro transmitido não será mais recebido e contar esse quadro
como perdido. O intervalo de tempo mais comum usado para tomar essa decisão
segundo a RFC 2544 é de dois segundos (IETF RFC 2544, 1999). Assim, qualquer quadro
recebido mais de dois segundos após ter sido transmitido será contado como perdido.

2.4.8 Análise Fim-a-Fim (end to end)

A análise de quadros entre equipamentos envolve enviar ao equipamento testado


(DUT) um Burst com espaços pequenos entre quadros e contar o número de quadros
conduzidos por este. Se o número de quadros encaminhados for igual ao número de
quadros transmitidos, o tamanho do Burst será aumentado e o teste será executado
novamente. Caso o número de quadros encaminhados for menor do que o número de quadros
transmitidos, o comprimento do Burst será reduzido e o teste será executado novamente.
O valor fim-a-fim será o número de quadros do Burst mais longo que o DUT consegue tratar
sem perder nenhum quadro (BURGESS, 2004).
Conforme SOUZA (SOUZA, 2006) o atraso fim-a-fim possui componentes de
natureza fixa e de natureza variável. Esses componentes são definidos como:
• Atraso de Propagação: Esse atraso é diretamente relacionado com o tempo de
propagação do sinal no meio de transmissão, sendo este, função da velocidade da
luz no meio. O atraso de propagação depende do tipo de meio, da distância percorrida
e é considerado atraso fixo;
• Atraso de Empacotamento: Tempo necessário para se gerar um número suficiente de
quadros para preencher o payload16 do pacote IP. Para que esse atraso não atinja
valores muito altos, os pacotes enviados podem conter somente um quadro, porém,
isto reduz a eficiência do sistema.

16
Payload: Informação útil do pacote IP
29
• Atraso nos Nós da Rede: O atraso de enfileiramento é o principal atraso que os pacotes
sofrem dentro da rede. Esse atraso é composto de duas parcelas: uma fixa, referente ao
tempo de transmissão do pacote, e outra variável, correspondente ao tempo de espera
na fila até que o pacote seja atendido. Esse atraso é responsável pela aleatoriedade do
atraso total ao qual o pacote é exposto, assumindo valores inaceitáveis quando a rede
estiver congestionada.
• Atraso devido ao “Dejitter Buffer”: O Jitter é introduzido no sistema através do
comportamento aleatório do tempo de enfileiramento dos pacotes nos roteadores.
Uma das soluções que pode ser usada para compensar essa variação é a introdução de
Buffers (“Dejitter Buffers”), com a função de armazenar os pacotes que chegam
com atraso variável e entregá-los ao receptor. Se a variação do atraso for muito
alta, o atraso adicional necessário para compensar a variação pode resultar em um
atraso fim-a-fim inaceitável. É definido, então, um valor máximo de atraso
aceitável para o “Dejitter Buffer”. Qualquer pacote que chegar após esse tempo será
descartado.
O alcance máximo de atraso fim-a-fim é firmado em 300ms pela recomendação
17
ITU-T G.11418 (ITU-T G114, 2003). Sendo esse valor um limite máximo, isso quer dizer
que acima desse valor a qualidade da transmissão torna-se inaceitável. O limite confortável
é estabelecido em 150ms. Atrasos entre esses dois valores delimitam uma região de
qualidade marginal, que pode ser aceitável para algumas aplicações de voz (SOUZA,
2006).

2.4.9 Largura de Banda

A largura de banda para a transmissão de informação depende de vários fatores e


pode ser calculada, com facilidade, de acordo com informações de diagnóstico, quantização,
algoritmos de compressão, etc. Além da transmissão de voz, as redes também são usadas
para transmissão multimídia. Como a transmissão de voz em uma conversação telefônica
deve ocorrer em tempo real, tais dados devem possuir uma prioridade em relação a outros

17
ITU-T: ITU Telecommunication Standardization Sector (ITU-T) é um dos três setores (divisões ou unidades)
da International Telecommunication Union (ITU), que coordena os padrões de telecomunicações.
18
G.114: Recomendação que define características de codificação e decodificação de canais PCM a 4 fios.
O conteúdo da presente recomendação está agora coberto pela ITU-T G.712
30
dados com menor importância. Obviamente, a decisão de se usar uma largura de banda maior
ou menor deve ser tomada conforme as necessidades e prioridades da rede. Vale
ressaltar que uma banda muito estreita para a transmissão de voz influencia negativamente
na qualidade do serviço (SOUZA, 2006).

2.5 Equipamentos de Teste para Redes Metro Ethernet

Na literatura, encontram-se diversas discussões sobre os tipos e as funcionalidades


dos equipamentos de testes utilizados em redes Metro Ethernet. Esses instrumentos são
utilizados em testes do tipo local e ponto a ponto e suas principais funcionalidades são
definidas na RFC2544.
Empresas como a Datacom, Wise, Siemens, Redex, dentre outras, fabricam e/ou
distribuem esses tipos de instrumentos, seguindo rigorosamente as recomendações existentes
na RFC 2544.
Independente do fabricante, os procedimentos de teste são padronizados e atendem às
demandas das manutenções de circuitos. Para fins desta dissertação, devido ao contexto de
parceria com o fabricante Datacom, o foco da pesquisa é o equipamento TSW900ETH.
Conforme o manual do equipamento, o test set TSW900ETH é um equipamento de
teste portátil que pode ser utilizado na instalação, manutenção e certificação de circuitos e
equipamentos Metro Ethernet, possuindo funcionalidades como loopback, testes de
diagnósticos do meio físico, testes com tráfego de dados configurável e realização automática
de todos os testes previstos na RFC 2544, que são: throughput, latency, frame loss rate, back-
to-back frame. (DATACOM, 2012).
Com o TSW900ETH é possível realizar testes nas camadas físicas, Ethernet e IP
(Modelo OSI). Além disso, segue as especificações existentes na RFC 2544, padrão IEEE
802.3 e padrão IEE 802.1q. A seguir, é apresentado o detalhamento dos testes:
Camada física:
- Verifica o sinal óptico, sua potência, o tipo de fibra (monomodo ou multimodo) entre várias
outras medidas.
- Verifica o estado dos pares do cabo elétrico, mostrando curtos e interferências entre eles e se
o sinal remoto foi detectado.
Camada Ethernet (layer 2):
- Gera e mede o tráfego na intensidade que se deseja.

31
- Efetua os testes da RFC2544 para verificar a capacidade máxima da rede, seu retardo, o
ponto de sobrecarga, dentre outros.
- Faz loopback retornando todos os quadros que se destinam a ele para possibilitar que o
gerador de tráfego receba de volta os quadros e efetuar as medidas necessárias.
Camada IP (layer 3):
- Envia e responde ao Ping para verificar a conectividade e tempo de resposta.
- Faz o teste de Trace Route para levantar a rota até o destino.
- Faz os mesmos testes da camada Ethernet para a camada IP.

O TSW900ETH possui duas portas completamente independentes, cada uma


podendo ser utilizada via interface elétrica (duas entradas RJ-45 para 10/100/1000 Base-T)
ou óptica (duas entradas para módulos SFP - Small Form Factor Pluggable). Isso permite
que técnicos de campo realizem testes simultâneos em dois circuitos, que podem ser de
clientes/redes completamente diferentes, ou podem representar dois roteadores de uma mesma
rede (DATACOM, 2012). O TSW900ETH é um equipamento portátil que pode ser operado
através de um teclado e um display de cristal líquido. Os caracteres possuem diversos
tamanhos para facilitar a operação e a visualização dos resultados. Além disso, apresenta um
conjunto de LEDs que ajuda a verificar o status das suas operações. O equipamento é
alimentado por um conjunto de baterias internas que devem ser carregadas utilizando fonte
própria fornecida juntamente com o produto. A Figura 14, a seguir, ilustra um cenário de teste.

32
Figura 14: Esquema de Teste com o TSW900ETH
Fonte: (DATACOM, 2012)

2.5.1 Testes Disponíveis

2.5.1.1 Teste de Diagnóstico de Cabo

O teste de cabo pode ser aplicado com o TSW900ETH antes de ser usado para
transmissão de dados. Normalmente, ele é aplicado em situações fora de serviço para
determinar o estado de cada par MDI19 ou MDIX20, os pares atribuídos para links de 1000
Mbps ou alguma disfunção nos pares. Se o link estiver inativo o equipamento poderá ser
utilizado para determinar a natureza da falha e a distância do problema (DATACOM, 2012),
conforme ilustrado na Figura 15 a seguir.

19
MDI: Medium Dependent Interface. Fornece a ligação física e elétrica ao meio cabeado.
20
MDIX: Medium Dependent Interface Crossover. Permite a ligação entre dispositivos semelhantes.
33
Figura 15: Teste de cabo no TSW900ETH
Fonte: (DATACOM, 2012)

Observação:
- Ligação entre portas MDI: cabo cruzado
- Ligação entre portas MDIX: cabo cruzado
- Ligação entre uma porta MDI e uma porta MDIX: cabo direto

2.5.1.2 Teste de Sinal Óptico

Com o TSW900ETH também é possível realizar testes no cabo óptico, realizando


a verificação de seu sinal (DATACOM, 2012), conforme ilustrado na Figura 16 a seguir.

Figura 16: Teste do sinal óptico


Fonte: (DATACOM, 2012)

2.5.1.3 Teste de Loopback

Quando configurado no modo Loopback, o TSW900ETH reenvia para o endereço


de origem todos os quadros que forem recebidos e destinados a ele. A interface escolhida no
equipamento para o modo Loopback pode ser ETH1 ou ETH2 no caso de link elétrico, e
34
SFP1 ou SFP2 no caso de link óptico (DATACOM, 2012).
Se o equipamento estiver em modo Loopback, ele retornará os quadros recebidos
a ele nas seguintes situações:
1. Se estiver operando na camada 2 (framing = Ethernet), somente retornará os quadros se
o endereço MAC21 de destino do quadro recebido for igual ao endereço MAC de origem da
porta do TSW900ETH que estiver em Loopback.
2. Se estiver operando na camada 3 (framing = Ethernet/IPv4), somente retornará os
quadros com o endereço MAC e IP de destino igual ao endereço MAC e IP de origem
da porta do TSW900ETH que estiver em Loopback. Operando nessa camada pode-se
configurar para utilizar ARP (Address Resolution Protocol), dessa forma não é necessário
configurar o endereço MAC de destino de quadro. A Figura 17, a seguir, ilustra como
realizar os testes de Loopback.

.
Figura 17: Teste de Loopback
Fonte: (DATACOM, 2012)

2.5.1.4 Teste de Camada 2

Para os testes de camada 2 o TSW900ETH é ligado na rede/equipamento a ser


testado, e nessa rede/equipamento é ligado um equipamento em modo Loopback (que pode
ser a outra porta do mesmo TSW900ETH, outro TSW900ETH ou outro aparelho com a
mesma função). Assim, o aparelho com função de Loopback irá receber os quadros emitidos

21
MAC: Media Access Control
35
e reenviá-los ao TSW900ETH, que a partir disso irá testar o tráfego ou realizar os testes da
RFC 2544, como pode ser visualizado na Figura 18 a seguir. Pode-se escolher uma das
interfaces ETH1/SFP1/ETH2/SFP2 para iniciar um dos testes, e outra correspondente do
TSW900ETH para fazer o Loopback (supondo o uso da outra porta do mesmo TSW900ETH
como Loopback), por exemplo: utilizar a porta ETH1 para iniciar o teste e a porta ETH2 como
Loopback.

Figura 18: Ilustração do modo como os testes de Tráfego e da RFC 2544 devem ser realizados
Fonte: (DATACOM, 2012)

2.5.1.5 Teste de Tráfego

O teste de tráfego tem como objetivo verificar erros de bit, CRC e a capacidade
do DUT. Nesse teste, o TSW900ETH envia tráfego fixo ou variável e verifica o
comportamento do DUT. O percentual de banda pode ser fixo (Constant), em rampa (Ramp),
em rajadas (Burst) ou fixo a 100% real da banda (Flood), que gera uma sobrecarga, pois o
canal por especificação não deve ser utilizado à taxa de 100% real. O payload pode ser
usado para carregar uma marcação de tempo (Timestamp) ou uma sequência a ser usada no
teste de BERT, que pode ser fixa ou pseudoaleatória. Para efetuar medidas de delay e jitter,
deve-se utilizar “Timestamp” como payload, e para efetuar testes de BERT, que tem como
objetivo verificar a taxa de erro dos bits deve-se escolher “BERT” como payload
(DATACOM, 2012).

2.5.1.6 Teste da RFC 2544

Os testes da RFC 2544 disponibilizam uma série de informações sobre o DUT. A

36
seguir, são descritos o funcionamento e o objetivo dos testes da RFC 2544 (IETF RFC
2544, 1999) disponíveis na versão atual do TSW900ETH (DATACOM, 2012).
• Throughput: O objetivo desse teste é encontrar a taxa limite de uso do DUT sem que
haja perda.
• Latency: Esse teste tem como objetivo verificar o atraso de ida e volta de um quadro
no DUT no throughput máximo. Seu funcionamento é baseado no cálculo da média da
latência encontrada para cada tentativa.
• Frame Loss: O objetivo principal desse teste é levantar o ponto de sobrecarga do
DUT, ou seja, onde a perda de quadro se torna mais severa.

• end-to-end: Seu objetivo principal é verificar a capacidade do DUT retransmitir sem


um intervalo de tempo.

2.5.1.7 Teste de Camada 3 (Rede)

Para essa camada, o TSW900ETH executa os mesmos testes descritos na RFC


2544, porém deve-se configurar o endereço IP de destino da porta que executará o teste para o
endereço IP de origem do loopback e habilitar o ARP ou configurar o MAC de destino da
mesma forma que no teste de camada 2. Nessa camada também estão disponíveis os testes de
Ping e Trace Route conforme ilustrado na Figura 19 a seguir.

• Testes de Ping: A função de Ping pode ser utilizada para verificar a conectividade e
o RTT (Round-Trip Time) com outro aparelho que opere na camada 3 (Rede) e
responda a requisições ICMP. Ao realizar o teste de Ping, o TSW900ETH irá
enviar requisições de pacotes ICMP e esperará as respostas a essas requisições.
• Teste de Trace Route: O teste de Trace Route (rastreio de rota) consiste em obter o
caminho que um pacote IP percorre na rede até chegar ao destinatário. O Trace Route
também ajuda a detectar onde ocorrem possíveis congestionamentos na rede, já que
descreve o RTT (Round-Trip Time) até cada ponto da rede.

37
Figura 19: Teste de PING e TRACE ROUTE
Fonte: (DATACOM, 2012)

A figura 19 apresenta o esquema para realização de testes de PING e TRACE


ROUTE.

2.6 Considerações Finais do Capítulo

Este capítulo apresentou as informações sobre o padrão IEEE 802.3 e toda sua
evolução até chegar ao contexto de redes atuais, focando nas Redes Metro Ethernet. Além
disso, foi apresentada a RFC 2544, que padroniza os testes de desempenho de redes e o
conceito sobre instrumentos de testes para redes de alta velocidade, destacando o equipamento
TSW900ETH foco desta pesquisa. Nesse sentido, foram discutidos os principais conceitos,
procurando delinear os aspectos intrínsecos ao padrão IEEE 802.3 e da RFC 2544. Foi dada
ênfase maior as redes Metro Ethernet e seus padrões de testes, por tratar-se do objeto de
estudo desta dissertação. As discussões realizadas neste capítulo, em adicional ao apresentado
na introdução desta dissertação, demonstram que o desenvolvimento de uma plataforma
automatizada para realização de testes em redes Metro Ethernet de forma remota e mais
interativa e de fácil interface com o usuário, contribuirá para a melhoria do desenvolvimento
do setor de TICs das operadoras de telecomunicações, onde essas terão um processo mais
otimizado de manutenção, garantindo o SLA dos clientes. Desse modo, fabricantes de
equipamentos de testes, provedores de serviços e usuários em geral poderão facilmente testar
e verificar os padrões de desempenho de suas redes de comunicação.

38
3 TESTES EM REDES DE COMUNICAÇÃO

3.1 Apresentação do Capítulo

O objetivo deste capítulo é apresentar a proposta da dissertação propriamente dita.


É dado destaque, ainda, aos trabalhos relacionados ao tema em estudo, apresentando as
principais iniciativas, patentes e modelos de utilidade e suas contribuições, buscando delinear
o estado da arte nesse contexto. Isso se dá a partir de uma breve descrição sobre cada trabalho
relacionado ao objeto de estudo desta dissertação, com o intuito de expor uma síntese das
lacunas e oportunidades existentes no que se refere a instrumentos para testes em redes de
longa distância de forma remota e automatizada, cujos desafios são os motivadores desta
dissertação. Por se tratar de algo inovador, fez-se necessário o estudo de patentes relacionadas
ao tema.

3.2 Visão Geral sobre Redes Multimídia

Segundo KUROSE (KUROSE e ROSS, 2010), o momento atual é caracterizado


por um grande avanço e uma grande demanda por aplicações multimídia. Inúmeros sites
disponibilizam conteúdo de áudio e vídeo, como o YOUTUBE, por exemplo. Outros como o
SKYPE e o MSN, disponibilizam aplicações relacionadas à telefonia e videoconferência.
Ainda existem alguns canais tradicionais de televisão transmitidos pela internet. Essa
explosão de aplicações multimídia da Internet, conforme descrito anteriormente, foi possível
devido à expansão dos acessos em banda larga, possibilitada principalmente pela redução de
custos com infraestrutura. Ainda segundo KUROSE (KUROSE e ROSS, 2010), essas taxas
de transmissão em banda larga continuarão a aumentar e com isso surgirá espaço para novas
aplicações multimídia, o que exigirá mais das redes de comunicação.
Tais aplicações multimídia diferem das tradicionais aplicações elásticas, como e-
mail, navegação na WEB, login remoto, download, compartilhamento de arquivo, dentre
outras. São aplicações mais sensíveis a atrasos ponto a ponto e a variações de atrasos, porém
podem tolerar casuais perdas de informações (KUROSE e ROSS, 2010). Um exemplo muito
claro disso é o caso de ligações telefônicas baseadas em pacotes IP que, para ser eficiente,
deve ter a mesma qualidade de uma ligação feita pelo sistema convencional de telefonia
(FILIPPETTI, 2008).

39
A Internet, essa enorme WAN (Wide Area Network), suporta diversas aplicações
multimídia, onde se destacam áudio e vídeo de fluxo contínuo e armazenado, áudio e vídeo de
fluxo contínuo ao vivo e áudio e vídeo interativos em tempo real. Destacam-se também as
aplicações elásticas cujos dados são transportados antes e reproduzidos depois, como é o caso
da transferência de arquivos (HTTP22 e FTP23) e sistemas de compartilhamento P2P24
(KUROSE e ROSS, 2010).
Nas aplicações de áudio e vídeo de fluxo contínuo e armazenado, os clientes
solicitam arquivos de áudio e vídeo que estão armazenados em servidores remotos. Essas
aplicações possuem três características principais: mídia armazenada, fluxo contínuo e
reprodução contínua (KUROSE e ROSS, 2010). Já as aplicações de áudio e vídeo de fluxo
contínuo ao vivo são semelhantes à transmissão tradicional de rádio e TV, tendo o diferencial
de utilizar a Internet para transporte das informações. (KUROSE e ROSS, 2010).
Essas aplicações necessitam de redes cada vez mais potentes e com grande largura
de banda. Com isso, os equipamentos que compõem a infraestrutura dessas redes devem
possuir tecnologias robustas e de baixo custo que atendam a essas necessidades, como é o
caso das Redes Metro Ethernet, por utilizar o padrão Ethernet para alcance metropolitano. Por
outro lado, os usuários desse tipo de aplicação estão cada vez mais exigentes no que se refere
à velocidade de transmissão e à disponibilidade nos seus links de interconexão. Esse fato leva
as operadoras de telecomunicações e provedores de serviços a buscarem soluções de
manutenção otimizadas e de baixo custo. Devido a essa necessidade de otimização e redução
no tempo de manutenção dos links de acesso, surgiu a motivação para o desenvolvimento da
plataforma de teste automatizada, objeto desta dissertação.

22
HTTP: Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto.
23
FTP: File Transfer Protocol (Protocolo de Transferência de Arquivos).
24
P2P: Arquitetura de sistemas distribuídos caracterizada pela descentralização das funções na rede, onde cada
nó realiza tanto funções de servidor quanto de cliente (TANENBAUM, 2003).
40
3.2 Testes em Redes Multimídia

O padrão Ethernet é comumente utilizado na arquitetura de redes locais (LANs)


corporativas no mundo todo. Assim como o protocolo IP - sendo geralmente utilizados em
conjunto - tem na economia de escala um dos fatores de seu sucesso.
Por muitos anos, o padrão Ethernet tem sido o protocolo dominante em redes
LAN; hoje, mais de 98% do tráfego corporativo passa por interfaces Ethernet. Isso é motivado
pela simplicidade, facilidade de operação, elevado grau de integração e padronização do
protocolo Ethernet, o que torna essa tecnologia extremamente atrativa em termos de custo.
Por outro lado, o mesmo não acontece com as redes MAN e WAN, com as operadoras
oferecendo serviços baseados em ATM (Asynchronous Transfer Mode), Frame Relay, SDH,
linhas privativas, dentre outros, todos significativamente mais complexos e com custo mais
elevado. Atualmente, os mais importantes serviços demandados pela área corporativa e que
mais tem crescido são a interconexão das redes LAN geograficamente distribuídas e a
conectividade à Internet. Devido a esses serviços e à crescente exigência do mercado por
baixos custos, as operadoras de serviços se deparam com a necessidade de readequar suas
redes metropolitanas, sendo as redes Metro Ethernet uma escolha de destaque tanto pelo
aspecto técnico como econômico (OI TNL PCS, 2009a).
Uma rede Metro Ethernet (MEN – Metropolitan Ethernet Network) é definida
basicamente como uma rede que interconecta LANs corporativas geograficamente separadas,
interconectando-se ainda a uma rede WAN ou backbone operada pelo provedor de serviços.
Com as redes Metro Ethernet, podem-se estender as vantagens do padrão Ethernet geralmente
utilizado em LANs (redes locais) às redes metropolitanas (MANs), incorporando
escalabilidade, confiabilidade e uma abrangência maior às redes locais. A comunicação entre
pontos espalhados em uma mesma cidade (área metropolitana) funciona de modo
transparente, como se os pontos estivessem situados dentro de um mesmo site, em uma
mesma rede local - com as velocidades nativas da Ethernet. Assim, o gargalo já tradicional na
comunicação entre LANs e MANs/WANs passa a ser combatido e resolvido. Seu
funcionamento é semelhante ao de uma rede local, mas com amplitude muito maior, podendo
conectar pontos espalhados pela cidade ou centros metropolitanos (OI TNL PCS, 2009a). A
Figura 20, a seguir, detalha o esquema de interconexão através de redes Metro Ethernet.

41
Figura 20: Redes Metro Ethernet interligadas através de backbones.
Fonte: (OI TNL PCS, 2009a)

Seu alto desempenho, grande largura de banda e baixo tempo de resposta em


aplicações cliente/servidor, por exemplo, atende antigas necessidades. Se antes o senso
comum dizia que 80% do tráfego estava restrito à rede local e apenas 20% saía dessa
(utilizando o backbone da operadora, na WAN), hoje essa proporção está se invertendo - muito
em função dos ambientes de negócios das empresas e de suas arquiteturas de rede, que
refletem uma nova realidade (OI TNL PCS, 2009a). Essas redes utilizam redes ópticas
baseadas em switches25.
Entre os benefícios dessa solução, pode-se destacar:
• Equipamentos (CPEs) mais baratos: na maior parte dos casos, não é necessária a
utilização de roteadores, ou seja, bastam o uso de switches.
• Confiabilidade: permite a formação de redes e de circuitos LAN-to-LAN com altíssimo
desempenho.
• Integração e compatibilidade: quando se transmite de redes locais (LANs) baseadas em
Ethernet para redes metropolitanas (MANs) também baseadas em Ethernet, não há
conversões de protocolos; assim, evita-se introdução de overhead, vantagem para o
desempenho do serviço.
• Adequação ao ambiente de convergência: em bandas altas, é uma excelente
infraestrutura para serviços convergentes.
• Praticidade: o usuário já recebe uma fibra óptica ou par metálico com interface RJ-
4526.
• Escalabilidade: agilidade na expansão para maiores velocidades.
A Figura 21, a seguir, apresenta uma aplicação Metro Ethernet.

25
Switches: Um comutador ou switch é um dispositivo utilizado em redes de computadores para reencaminhar
módulos (frames) entre os diversos nós (TANENBAUM, 2003).
26
RJ 45: O padrão Registered jack (RJ) especifica o RJ45 como um conector físico e seus cabos.
42
Figura 21: Interligação de redes utilizando Metro Ethernet
Fonte: (OI TNL PCS, 2009a)

Por se tratar de uma tecnologia que suporta aplicações multimídia e que está em
plena expansão este capítulo se concentra nos testes em redes Metro Ethernet.

3.3.1 Tipos de Testes

Para definição dos tipos de testes, além das recomendações e normas existentes,
foi utilizado o documento que descreve o procedimento operacional padrão de testes da
operadora OI. Todos os padrões explicitados são baseados na RFC 2544.

3.3.1.1 Teste Digital

Teste executado para detecção de taxa de erro de bits, através do equipamento test
set. O resultado indicará se o circuito de dados está apto ou não para ser entregue ao usuário.
Consiste na utilização de test set calibrado e aferido, realizando teste durante pelo menos 30
minutos, ou casos em que o usuário solicite um tempo diferenciado devido a norma interna da
empresa ou recomendações internacionais (OI TNL PCS, 2009b).

3.3.1.1.1 Interface G703

A Interface G703 é um padrão da ITU-T para transmissão de voz ou dados em


meios digitais, tais como T1 e E1 (ITU-T, 2001).

3.3.1.1.1.1 Teste Ponto a Ponto

Para a realização desse tipo de teste é necessário a utilização de dois


equipamentos de teste (test set), um em cada ponta do circuito, e consequentemente dois
profissionais, para realizar as devidas operações nos equipamentos de teste. Os dois
43
equipamentos de teste devem ter os mesmos parâmetros de configuração e interfaces digitais
selecionadas compatíveis com a tecnologia de rede que estão utilizando. Em seguida é
executado o teste de BERT27. Os testes devem apresentar os seguintes resultados (OI TNL
PCS, 2009b):
• Taxa de Erro (BERT) = 0.
• Escorregamento de relógio (Clock Slip) = 0.
• Falha de sincronismo (Sinc Loss) = 0.
Em caso de incremento em qualquer um dos parâmetros anteriores, os
equipamentos (Modens, conversores, dentre outros) devem ser verificados, pois
possivelmente estão com seus funcionamentos comprometidos e deverão ser substituídos (OI
TNL PCS, 2009b).

3.3.1.1.1.2 Teste de Loop na Ponta Remota

Em circuitos de comunicação de dados em que é possível o acionamento de Loops


no equipamento remoto, também é possível a realização de testes, da seguinte forma: com a
utilização de um test set, conectar o cabo lógico à interface digital do equipamento remoto de
Interface local, acionar o loop remoto no equipamento e executar o teste de BERT. Os testes
devem apresentar os seguintes parâmetros (OI TNL PCS, 2009b):
• Taxa de Erro (BERT) = 0;
• Escorregamento de relógio (Clock Slip) = 0;
• Falha de sincronismo (Sinc Loss) = 0;
Em caso de incremento em qualquer um dos parâmetros anteriores, os
equipamentos (Modens, conversores, dentre outros) devem ser verificados (OI TNL PCS,
2009b).

3.3.1.1.1.3 Teste em Loop por Trecho no Circuito de Comunicação de Dados

É possível realizar testes em loop por trecho no circuito de comunicação de dados


nas seguintes condições (OI TNL PCS, 2009b):

27
BERT: Taxa de erro de BIT
44
• Quando os testes realizados ponto-a-ponto ou em loop na ponta remota, não
apresentem resultados satisfatórios e deseja-se identificar o trecho do circuito que
apresenta problemas.
• Quando não seja possível a realização de testes ponto-a-ponto ou em loop na ponta
remota.
Para esse tipo de teste devem ser realizados os loops do ponto mais distante até o
mais próximo. Esses loop´s podem ser realizados nas estações (site da operadora), nas pontas
do circuito ou nas estações intermediárias. Com a utilização de um test set, deve ser conectado
o cabo lógico na interface digital do equipamento de Interface local e executar o teste de
BERT. É considerado apto o trecho que apresentar:
• Taxa de Erro (BERT) = 0.
• Escorregamento de relógio (Clock Slip) = 0.
• Falha de sincronismo (Sinc Loss) = 0.
Em caso de incremento em qualquer um dos parâmetros anteriores, os
equipamentos (Modens, conversores, dentre outros) devem ser verificados (OI TNL PCS,
2009b).

3.3.1.1.2 Interface Ethernet

3.3.1.1.2.1 Teste Ponto a Ponto

Para a realização desse tipo de teste é necessária a utilização de 2 (dois)


Analisadores (test set, podendo ser o TSW900ETH ou similar) ou notebooks um em cada
ponta do circuito. Com isso, necessita de dois profissionais para realizar a operação dos
instrumentos de testes ou notebooks (OI TNL PCS, 2009b).
1 - Teste com Analisador TSW900ETH ou similar:
Os dois analisadores devem ser colocados um em cada ponta do circuito e efetuar
os testes de camada 2 e 3, durante pelo menos quinze minutos. O resultado desse teste não
pode ter perda de pacotes (OI TNL PCS, 2009b).
2 - Teste com notebook:

45
Em cada um dos notebooks devem ser programados IPs fixos e colocados um
notebook em cada ponta. Os dois técnicos devem fazer testes de “pings28” continuamente,
inclusive aumentando o tamanho dos pacotes. O resultado desse teste não pode ter perda de
pacotes (OI TNL PCS, 2009b).

3.3.1.1.2.2 Teste de Ping com as Redes

Nesse tipo de teste, o profissional também pode, em alguns casos, testar com
pings até o ponto de entrada na nuvem IP. O resultado desse teste não pode ter perda de
pacotes (OI TNL PCS, 2009b).

3.3.1.1.3 Interface Óptica

Para circuitos que utilizam interfaces ópticas (circuitos entregues em fibra óptica),
deverão ser testados com equipamento TSW900ETH ou similar com interface óptica e seguir
os mesmos procedimentos e ações de quando for utilizada interface elétrica (OI TNL PCS,
2009b).

3.4 Trabalhos Relacionados – O Estado da Arte

A Inovação Tecnológica é uma realidade presente em empresas de todos os


setores, inclusive em instituições de ensino (ABRAHAM, 2010). A inovação é um diferencial
na subsistência e sucesso dessas empresas e instituições (YONEZAWA, 2003). Corroborando
essa afirmativa, cada vez mais novos projetos de inovação tecnológica são desenvolvidos
através do financiamento de agências de fomento como a FINEP29, possibilitando o
crescimento econômico e financeiro dessas empresas e instituições. Projetos de inovação

28
Ping: Utilitário que usa o protocolo ICMP para testar a conectividade entre equipamentos.
29
FINEP: Financiadora de Estudos e Projetos é uma empresa pública vinculada ao Ministério da Ciência e
Tecnologia (MCT). Foi criada em 24 de julho de 1967, para institucionalizar o Fundo de Financiamento de
Estudos de Projetos e Programas, criado em 1965 (FINEP, 2011).

46
tecnológica envolvem um grande grau de riscos devido ao seu teor (SILVA e FERREIRA,
2012).

Segundo o PMBOK (PMI, 2008), um projeto é um esforço temporário, destinado


a criar um produto, serviço ou resultado único. Sendo assim, as atividades são elaboradas e
controladas de modo a possibilitarem a maior eficiência e eficácia do projeto. Por outro lado,
na visão das agências de fomento30, projeto é o conjunto de informações que definem a
alocação de recursos para uma atividade ou empreendimento que permitam a avaliação da
conveniência da participação financeira nessas atividades (BNDES, 2011). Dentro dessa
visão, os projetos são formulados por quem solicita recursos às agências de fomento (BCB,
2011), pleiteando o financiamento dos mesmos (DINSMORE, 2005). Um bom projeto deve
conter um texto plausível, sanando todos os tópicos requeridos pela agência de fomento no
edital (SILVA e FERREIRA, 2012).

Uma inovação é a implementação de um produto (bem ou serviço) novo ou


significativamente melhorado, ou um processo, ou um novo método de marketing, ou um
novo método organizacional nas práticas de negócios, na organização do local de trabalho ou
nas relações externas (FINEP, 1997). Essa definição abrangente de inovação compreende um
amplo conjunto de inovações possíveis. O requisito mínimo para se definir uma inovação é
que o produto, o processo, o método de marketing ou organizacional sejam novos (ou
significativamente melhorados) para a empresa. Isso pode incluir produtos, processos e
métodos que as empresas são as pioneiras a envolver e aqueles que foram adotados de outras
empresas ou organizações. Um aspecto geral de uma inovação é que ela deve ter sido
implementada. Um produto novo ou melhorado é implementado quando inserido no mercado.
Novos processos, métodos de marketing e métodos organizacionais são implementados
quando eles são efetivamente utilizados nas operações das empresas (FINEP, 1997).

Em aplicações práticas, um projeto de inovação trata da implantação e


desenvolvimento de um produto ou processo com características de desempenho aprimoradas.
Quando se fala em inovação tecnológica, tem-se o foco nas atividades de Pesquisa,
Desenvolvimento e Inovação (PD&I) (FINEP, 1997). Dentro desse contexto, espera-se que
um projeto de inovação tecnológica apresente inúmeros fatores de risco, tanto quanto as

30
As agências de fomento têm como objeto social a concessão de financiamento de capital fixo e de giro
associado a projetos na Unidade da Federação onde tenham sede (BCB, 2011).
47
incertezas envolvidas em produtos ou processos inovadores. Essas incertezas vão desde a
concepção do produto ou processo até sua inserção no mercado (SILVA e FERREIRA, 2012).

É importante garantir a utilização racional dos recursos financeiros dentro do


planejado, bem como do tempo para desenvolvimento do projeto. Entretanto, o risco maior
nesse tipo de projeto está na própria tecnologia desenvolvida onde, no decorrer do
desenvolvimento do projeto, por se tratar de algo inovador, não apresente o desempenho
planejado, dificultando ou impossibilitando a inserção do produto no mercado (CLEMENTE,
ROCHA, et al., 2004). A realização de uma eficiente análise de viabilidade técnica,
econômica e financeira reduz os riscos de fracasso de um projeto de inovação tecnológica
(SILVA e FERREIRA, 2012).

Como as agências de fomento financiam investimentos em PD&I mediante a


apresentação de propostas de projetos de inovação, esses projetos deverão ser elaborados com
o planejamento, os investimentos e a análise de riscos bastante detalhados, de forma a garantir
a aceitação do investimento das agências nos projetos de inovação tecnológica. Grande parte
do sucesso e do financiamento dos projetos de inovação tecnológica é determinado nas etapas
de planejamento e formulação dos projetos (SILVA e FERREIRA, 2012).

As empresas e organizações dependem cada vez mais de investimentos em


inovação tecnológica. Como a tecnologia é fator determinante no que se refere à
competitividade, onde nem sempre as empresas podem custear a aquisição de novas
tecnologias e o custo com desenvolvimento tecnológico é cada vez maior, o financiamento
com inovação tecnológica possibilita também o crescimento econômico e financeiro dessas
organizações (SILVA e FERREIRA, 2012)

Em projetos de inovação tecnológica, além da existência dos riscos comuns a


projetos de investimento industrial (risco de inviabilidade econômica, risco de mercado, risco
político, entre outros), ainda estão sujeitos a riscos e a incertezas vinculados à própria
tecnologia a ser desenvolvida. (WEISZ, 2009, p. 80 e 81).

O foco desta dissertação é o desenvolvimento de um novo produto que trata de


uma inovação tecnológica. A plataforma de testes automatizada acoplada ao equipamento
TSW900ETH (test set Ethernet de fabricação da Datacom) possibilita a interligação do
instrumento de teste para redes Metro Ethernet ao PC (através de um sistema de
comunicação) ou a qualquer ponto de uma rede Metro Ethernet, realizando testes e
certificação em redes de forma remota, além de possuir uma interface gráfica mais amigável e
48
a possibilidade de armazenamento dos dados resultantes desses testes em um servidor para
posterior análise e geração de relatórios. Este produto inovador foi financiado através do
Edital SESI SENAI31 de Inovação Tecnológica 2010 (SENAI, 2010), onde recebeu um aporte
de R$ 300.000,00 de fomento para desenvolvimento dessa nova tecnologia. A ideia de
desenvolvimento dessa nova tecnologia surgiu devido à necessidade de diminuição do tempo
de reparo dos circuitos de comunicação de dados das operadoras de telecomunicações. A
plataforma de testes automatizada, acoplada ao instrumento de teste de redes já utilizado pelos
técnicos de campo responsáveis pelas manutenções (TSW900ETH), possibilita o acesso
remoto a todos os pontos da rede, realizando testes e diagnósticos de forma remota,
diminuindo recursos e tempo de deslocamento dos técnicos nas manutenções (SILVA e
FERREIRA, 2012).

Por se tratar de um produto inovador foram realizadas pesquisas de anterioridade


em bases de patentes nacionais (INPI32 e Portal CAPES33) e Internacionais (EPO34, USPTO35
e Escritório Japonês de Patentes) na busca de trabalhos relacionados, patentes, marcas e
modelos de utilidade que desabonassem o caráter inovador do trabalho.

Ao analisar equipamentos de testes em Redes Metro Ethernet de redes com


funcionalidades de acesso remoto e interface gráfica amigável, a literatura revela que os
esforços nesse sentido ainda são raros, até mesmo por se tratar de um modelo recente e
inovador para a indústria de manufatura desse tipo de equipamento. Como parte das
iniciativas de se estabelecer padrões para as redes Metro Ethernet e seus serviços, em 2001 foi
criado o Metro Ethernet Forum (MEF). O MEF é composto principalmente por provedores de
serviços, grandes operadoras, fornecedores de equipamentos de rede e empresas que atuam na
área de redes e compartilham interesse em redes Metro Ethernet (MEF, 2011). O MEF é uma
combinação de um fórum técnico e um fórum de marketing para promover a adoção da

31
O Serviço Social da Indústria (SESI) e Serviço Nacional de Aprendizagem Industrial (SENAI) são instituições
privadas brasileiras, vinculadas a Confederação Nacional das Indústrias, sem fins lucrativos e de atuação em
âmbito nacional, criadas com a finalidade de promover a formação profisional (SENAI), o bem-estar social, o
desenvolvimento cultural e a melhoria da qualidade de vida do trabalhador (SESI) que atua nas indústrias, de sua
família e da comunidade na qual as indústrias estão inseridas.
32
INPI: Instituto Nacional de Propriedade Industrial.
33
CAPES: Coordenação de Aperfeiçoamento de Pessoal de Nível Superior
34
EPO: European patente office
35
USPTO: Escritório Norte-Americano de Patentes
49
tecnologia Metro Ethernet. Este é um importante diferencial de outros organismos de
normalização, como a Internet Engineering Task Force (IETF) e do The Institute of Electrical
and Electronics Engineers (IEEE). O fórum faz recomendações aos organismos de
normalização e cria especificações que não estão sendo desenvolvidos por outros organismos
de normalização (MEF, 2011).

No contexto de equipamentos de testes para redes de comunicação, foram


encontrados alguns modelos de utilidade e patentes, porém nenhum desses se propõe a
disponibilizar o acesso remoto de qualquer ponto de uma rede Metro Ethernet.

A patente de número PI 9400198-7 refere-se a um equipamento de teste de


interface de assinantes de módulos de telecomunicações para testes nos antigos sistemas
PCM36. Trata-se de um equipamento da empresa PROMON Eletrônica LTDA, onde a
interface homem-máquina é feita através de um teclado padrão telefônico (12 teclas) e um
conjunto de 16 displays, além de uma impressora para emissão de medidas e relatórios. Esse
equipamento além de ser utilizado para testes em tecnologias já obsoletas, não possui a função
de acesso remoto (FILHO e DELANHESE, 2003). O mesmo aplica-se à patente PI 8903020-
6, referente a um sistema de teste automático para rede telefônica convencional, não sendo
utilizado para testes em redes de comunicação de dados (SILVA e CARDOSO, 1995). Já a
patente PI 9105973-9, sistema de teste de linhas de telecomunicações, só realiza testes locais
ou ponto a ponto com dois instrumentos (SNIADOWER e GLIGA, 1999). A patente PI
9506015-4, sistema portátil de teste remoto de linha de assinante, assemelha-se ao
equipamento da patente PI 8903020-6 e mesmo sendo portátil, aplica-se a testes em linhas
telefônicas tradicionais e não possui acesso remoto (SELING e ONOFRIO, 2011). Outra
patente com as mesmas aplicações das anteriores é a PI 9307422-0 (PRYOR, CHALLIS e
LEEUW, 2000), arranjo para testes de canais de comunicações que também não atende às
necessidades do trabalho desenvolvido através desta pesquisa. Ainda referente a equipamento
de testes para canais telefônicos comuns, tem-se a patente PI 0709756-5 da AT&T
Intellectual Property e Adaptive Spectrum and Signal Alignment, Inc (CIOFFI, GENIS, et al.,
2011).
Na patente PI 9707937-5, processo de teste remoto e terminal de uma conexão de
assinante sem fio, sistema para implementar uma conexão de assinante sem fio e rede de
transmissão de dados, já se observam os esforços para a realização de teste remoto, visando à

36
PCM: Modulação por Codificação de Pulso
50
otimização desse processo. Trata-se de uma patente da Nokia Telecommunications
(VIMPARI, 2002). A patente PI 9814489-8, sistema e método de teste de acesso para redes de
comunicação digital, prevê testes em redes multimídia, porém testes ponto a ponto ou em
loopback (KRAMARCZYK, FONI, et al., 2011). A Patente PI 7907633-5 da Brasilian
Telecom, equipamento de teste automático remoto de transmissão, embora se proponha a
realizar testes remotos em sistema de transmissão, assim como a patente anteriormente citada,
essa funcionalidade só funciona através de loopback ou testes ponto a ponto (DINARDO,
1995).
Finalizando a descrição das patentes encontradas no INPI (INPI, 2012), há a
patente PI 8101338-2, da antiga TELESP que propõe um equipamento de teste de circuitos de
telecomunicações, porém voltado para sistemas analógicos tradicionais ainda baseados em
PCM37 (DINARDO, 1984). Por fim a patente PI 9815810-4 da ADC Telecommunications,
apresenta um sistema de monitoração de desempenho e acesso de teste e método para conexão
cruzada de redes de comunicação, sistema este mais voltado para a análise de desempenho de
redes (JACOBSON, FONI e KRAMARCZYK, 2011).

Analisando a base de patentes americanas foi encontrada a patente de número US


409729 que trata de um sistema para monitoramento, teste e acesso a rede de transmissão de
dados em sistemas multiplexados. Diferente do trabalho desenvolvido nesta dissertação as
funções de acesso remoto não fazem parte desse equipamento (EDDY, WESLEY L, et al.,
1976). Ainda na base americana foi encontrada a patente de número US 4996695, arranjo para
acessar e testar circuitos de telecomunicações. Trata-se de uma patente da Hewlett-Packard
com características semelhantes à patente anteriormente citada (DACK, G, et al., 1990).

Partindo para Modelo de utilidade, ou seja, a denominação dada para a proteção


de uma nova forma, disposição ou projeto que melhora um produto já existente ou que traz
um aperfeiçoamento na sua aplicação (JUNGMANN, 2010), foi encontrado o MU 7400473-5
referente à configuração construtiva aplicada ao equipamento de teste em telefonia (ROXO,
2001). A proposta desta dissertação trata-se de um possível modelo de utilidade por se tratar
de uma implementação de melhoria em um equipamento de teste já existente e já patenteado.

A pesquisa para seleção dos trabalhos relacionados com o tema aqui abordado
revelou diversas inicitaivas de pesquisadores e empresas na construção de equipamentos de
testes para redes de comunicação que venham a facilitar e otimizar o processo de testes em

37
PCM: Modulação por Codificação de Pulso
51
redes multimídia. Independente das bases de patentes pesquisadas não foi encontrado nenhum
trabalho com as funcionalidades da proposta objetivo desta dissertação que no futuro poderá
ser submetida ao processo de patente junto ao INPI.

3.5 Considerações Finais do Capítulo

Este capítulo apresentou uma análise de patentes e modelos de utilidade cuja


proposta se assemelha ao trabalho desenvolvido. Inúmeras são as iniciativas para
desenvolvimento de equipamentos de teste que otimizem o tempo de manutenção das redes
especializadas. Por se tratar de uma ideia inovadora existiu a dificuldade em encontrar
trabalhos técnico-científicos relacionados ao tema, fazendo com que grande parte da pesquisa
tenha sido realizada em bases de patentes brasileiras, europeias, japonesas e americanas. Para
isso foi feito uma breve apresentação sobre propriedade industrial para facilitar o
entendimento do trabalho. A Propriedade Industrial é uma importante ferramenta para a
promoção e o desenvolvimento de um país, pois ela decorre diretamente da capacidade
inventiva ou criadora de seus habitantes (JUNGMANN, 2010).
O desenvolvimento de uma nova tecnologia totalmente inovadora é de extrema
importância para o país. Para a revisão da literatura deste trabalho, existiu uma grande
dificuldade em fontes de pesquisas sobre o tema, por se tratar de uma inovação incremental de
um produto já existente. Essas dificuldades foram sanadas através de consulta às bases de
patentes e das literaturas voltadas à inovação tecnológica. Portanto, baseado nos estudos
apresentados nos Capítulos 2 e 3, bem como no estudo acerca de novos processos de testes,
gerenciamento e acesso remoto de instrumentos de testes, junto a alguns fabricantes como a
Datacom38 e a Wise39, é possível desenvolver a Plataforma de Teste Automatizada, conforme
o objetivo principal desta dissertação.

38
Datacom: Teracom Telemática LTDA, empresa fabricante de equipamentos de telecomunicações.
39
Wise: Wise Telecomunicações, empresa fabricante de equipamentos de telecomunicações.

52
4 DECLARAÇÃO DO PROBLEMA

4.1 Apresentação do Capítulo

Este capítulo apresenta o contexto geral do problema pesquisado, procurando


relacionar as oportunidades de um sistema de teste automatizado no cenário das
telecomunicações. Também é apresentada a metodologia utilizada para desenvolvimento do
sistema proposto.
É importante destacar que por se tratar de uma plataforma para acesso remoto a
redes, a mesma é composta por interface e software, onde a implementação do software foi
fator essencial para o desenvolvimento do protótipo funcional utilizado para os testes e
validação.

4.2 Contextualização do Problema

A rápida evolução de serviços Ethernet nos últimos anos deu origem a soluções
integradas, padronizadas e simplificadas, ferramentas de gerenciamento e manutenção
avançadas, aplicações com classes de serviços garantidas, disponibilizando maior
acessibilidade e alavancando oportunidades estratégicas. Essas Vantagens se refletem em
redução de custos, ampliação das receitas com esse tipo de serviço, trazendo vantagem
competitiva para empresas em todo o mundo, através de uma rede globalizada (OI TNL PCS,
2009a).
Atualmente, a grande oferta de serviços pela Internet fez crescer o tráfego nas
redes e a demanda por maiores velocidades vem crescendo em grande escala. Desde as
grandes corporações, passando pelas PMEs (pequenas e micro empresas) até chegar aos
usuários residenciais, todos buscam soluções de conectividade que agreguem qualidade de
serviço, velocidade de transmissão e redução de custos. Diante desse cenário, tecnologias
que possibilitem esse tripé merecem destaque, como é o caso das Redes Metro Ethernet.
Com a grande demanda de aplicações via web e de transmissão de informação
multimídia, as operadoras de telecomunicações e os provedores devem possuir tecnologias e

53
ferramentas eficientes que garantam o SLA40 contratado pelos seus clientes. O problema base
desta investigação trata da necessidade de otimizar o processo de manutenção dos circuitos de
comunicação de dados dessas operadoras e provedores, reduzindo o tempo de reparo nesses
links e, por sua vez, disponibilizando uma maior garantia quanto ao cumprimento do SLA
contratado. Empresas que consigam garantir o SLA a seus clientes, somando a isso um baixo
custo financeiro, atendem a um grande nicho de mercado e superam a concorrência (WISE
TELEMÁTICA, 2012).
Conforme explicado no capítulo 2, a grande importância dos testes Ethernet recai
sobre a instalação, ativação e manutenção de serviços e equipamentos Ethernet. Como em
qualquer outro serviço, a ativação e a manutenção de redes Ethernet é crítica para se ter uma
confirmação de que o serviço está funcionando conforme especificado ou acordado entre um
provedor e seu cliente (SLA). A única forma de verificar serviços Ethernet é gerando tráfego
de dados e medindo os parâmetros e características desse tráfego. Durante a realização desses
testes são tratados os tipos de tráfego e parâmetros que precisam ser configurados e gerados,
bem como as medidas e análises que precisam ser realizadas, para que se tenham informações
confiáveis a respeito do funcionamento e desempenho do serviço Ethernet. A figura 22 a
seguir apresenta um exemplo desse tipo de teste (WISE TELEMÁTICA, 2012).

Figura 22: Teste de um serviço Ethernet


Fonte: (WISE TELEMÁTICA, 2012)

40
SLA: Service Level Agreement
54
Une-se ao cenário descrito a problemática relacionada às formas, instrumentos e
ferramentas de testes desses tipos de links. De um modo geral, as diferentes soluções
tecnológicas para teste e diagnóstico de falhas em redes Metro Ethernet demandam tempo, o
que prejudica a questão do SLA. Para realização desses testes existe a necessidade de dois
técnicos e consequentemente dois instrumentos de testes e a disponibilidade de dois técnicos
para execução e análise dos resultados dos testes realizados. Outra solução, também descrita
no capítulo 2, seria a realização de testes através de loopback, onde pode existir a necessidade
de vários deslocamentos do técnico, dependendo da capilaridade do circuito. Ambas as
soluções demandam custos com deslocamento e principalmente tempo de reparo, fator crucial
para garantia da qualidade do serviço prestado.
Embora os instrumentos de testes comercializados, independente dos fabricantes,
sigam as recomendações da RFC 2544 (IETF RFC 2544, 1999), o método para realização,
análise e monitoramento desses testes, seguem sempre os procedimentos citados
anteriormente. Ao se analisar esse cenário, percebem-se as falhas referentes a tempo de
manutenção e custos com essa atividade. Com isso, um processo de teste automatizado para
esses tipos de link mostra-se bastante eficiente e vem atender essa lacuna existente, tornando
possível a redução de tempo de manutenção e custos, facilitando para os clientes a garantia do
serviço (QoS41) contratado pelas operadoras ou provedores.
Neste contexto de necessidade de avanço tecnológico e em acompanhamento das
atividades de testes realizadas pelas operadoras de telecomunicações, foi idealizado o
desenvolvimento e implementação de novas funcionalidades em equipamentos de testes de
redes. Para isso, buscou-se apoio das empresas Wise e Datacom, no sentido de se obter acesso
a arquitetura dos equipamentos tradicionais já fabricados por essas empresas. Além disso,
buscou-se recursos financeiros junto a agências de fomento a inovação para financiamento e
apoio da pesquisa para desenvolvimento da solução proposta. Com isso, foi possível
desenvolver uma nova versão do equipamento de teste TSW900ETH com novas
funcionalidades inovadoras de teste. Dentro desse cenário, foi escolhida a tecnologia Metro
Ethernet devido a seu baixo custo e capilaridade.
Buscou-se parceria com as empresas Wise e Datacom que fabricam e
comercializam o equipamento de teste tradicional TSW900ETH. Por serem empresas
nacionais, isso facilitou as negociações para liberação de documentos e arquitetura do
equipamento. Além disso, com o protótipo funcional testado e validado, tem-se um modelo de

41
Qos: Quality of Service
55
utilidade gerando royalties para essas empresas e para técnicos diretamente envolvidos no
desenho e implementação da solução.
Nessa parceria para desenvolvimento da Plataforma de Testes Automatizada, a
Wise e a Datacom, participaram do desenvolvimento do protótipo cedendo as documentações
necessárias para a realização de pesquisas, a liberação da arquitetura do equipamento
TSW900ETH, liberação de seus laboratórios de PD&I para desenvolvimento e testes. Com a
validação do protótipo funcional, essas empresas poderão inserir esse produto com essa nova
funcionalidade em suas linhas de produção, enfatizando que a equipe de desenvolvimento tem
direito a royalties sobre o que for comercializado.

4.3 Sistema Proposto para Testes em Redes Metro Ethernet

Provedoras de acesso e à Internet necessitam utilizar equipamentos de testes para


verificar se os dispositivos de interconexão de redes estão de acordo com as normas de
fabricação. Além disso, é fundamental analisar o desempenho desses equipamentos de rede,
uma vez que esses provedores devem garantir o SLA contratado pelos seus clientes. Nesse
contexto, equipamentos de testes são largamente utilizados, como é o caso do TSW900ETH42
da empresa DATACOM, foco deste trabalho (WISE TELEMÁTICA, 2012).
O TSW900ETH é um dispositivo embarcado que possui diversas funcionalidades para
analisar a conformidade e o desempenho de uma rede de computadores. As principais
funcionalidades que se podem destacar são: realização de testes de acordo com a RFC 2544,
geração de tráfego em diferentes camadas do modelo OSI (Open Systems Interconnection),
análise de um dispositivo de rede em modo loopback, geração de relatórios, entre outras.
Entretanto, esse equipamento possui algumas limitações por ser um dispositivo embarcado.
Uma das principais limitações é a configuração e análise dos resultados de forma amigável e
intuitiva (WISE TELEMÁTICA, 2012).
O desenvolvimento de um processo automatizado de teste, envolvendo hardware e
software surgiu como uma alternativa para solucionar as limitações do equipamento
TSW900ETH e dos demais equipamentos de testes de funcionamento similar. Para esta
dissertação, o equipamento focal é o test set TSW900ETH, conforme citado nos capítulos
anteriores. Com isso, o equipamento torna-se mais amigável para os usuários finais, isto é,
torna as configurações e resultados fáceis e intuitivos para pessoas com menor conhecimento

42
TSW900ETH: Instrumento de teste para padrões Ethernet de fabricação da Datacom em parceria com a Wise.
56
técnico em redes de computadores poderem utilizar o TSW900ETH. Para isso é desenvolvido
um software, uma interface de comunicação e a utilização de alguns protocolos de
comunicação que possibilita a comunicação do TSW900ETH com um computador pessoal,
possibilitando a configuração dos cenários de testes através de scripts, ou telas amigáveis.
Além disso, é possível o acesso remoto a vários test set simultaneamente em diversos pontos
de uma rede Ethernet, aumentando a usabilidade do equipamento de teste desenvolvido pela
empresa DATACOM, tratando-se de uma inovação na área.
A próxima seção especifica os principais tópicos referentes ao software, de modo
detalhado, esclarecendo questões referentes aos requisitos de implementação.

4.3.1 Resumo das Características Funcionais da Plataforma de Teste

As características funcionais relacionadas a seguir indicam as atividades que o


sistema deve fazer para atender aos objetivos propostos.

Características já existentes no equipamento:


• Geração e monitoração de tráfego nas camadas 2 e 3 a 10/100/1000 Mbps para
interface elétrica (10/100/1000BaseT) ou 100/1000 para a interface óptica
(100/1000BaseX).
• Configuração de VLAN43 e Q-in-Q44.
• Configuração de tráfego em diferentes perfis (constante, rajada, rampa ou tempo).

43
VLAN: Rede Local Virtual.

44
Q-in-Q: Nos serviços Ethernet Metro ou WAN, que também são inerentemente serviços de camada 2, a rede
um prestador de serviços com frequência adicionará uma segunda etiqueta aos tags de um cliente interno de rede
Ethernet 802.1Q VLAN. A etiqueta adicional cria a VPN através da WAN, de forma a manter o tráfego do cliente
segregado de outros tráfegos WAN. O prestador do serviço preserva as etiquetas das VLAN originais, mantendo
assim os grupos de usuários e respectivos direitos de acesso definidos pelos clientes através da WAN. Esta
remarcação pode ser pensada como a criação de uma VPN local dentro de outra VPN, ou, mais precisamente,
uma VLAN em uma VPN. Este serviço de rede virtual é muitas vezes referenciado pela tecnologia baseada em
padrões que ele usa, sendo chamado de 802.1Q-in-Q, ou apenas Q-in-Q (TELECO, 2010).
57
• Taxa de geração de tráfego configurável de 0,001 a 100%, com precisão de até
0,001%.
• Testes de camada física: diagnóstico de cabo e teste de sinal óptico.
• Payload45 tipo Timestamp46 ou BERT (com vários padrões e opções de
personalização).
• Geração de padrão NCITS TR-25:1999: CJPAT, CRPAT e CSPAT47.
• Filtros para cabeçalhos Ethernet, IPv4 e IPv6.
• Contadores e estatísticas do tráfego recebido e transmitido.
• Modo Loopback.
• Testes de Ping e Trace Route48.
• Suporte a ARP e DHCP49.

Novas funcionalidade implementadas:


• Comandos de Loopback Remoto (capacidade de colocar outro test set TSW900ETH
em modo Loopback, remotamente, através da rede Ethernet).
• Geração e transmissão de até 8 fluxos de dados por porta, sendo cada fluxo
configurado e analisado de forma independente (funcionalidade opcional).
• Criação de vários perfis de usuários, através da possibilidade de salvar e carregar
configurações facilmente.
• Visualização gráfica dos resultados dos testes da RFC 2544 na tela do test set e na
Interface Web.
• Geração de scripts de teste personalizados, para testes específicos e automatizados.
• Verificações de Qualidade de Serviço (QoS).

4.3.2 Requisitos do Software

Segundo Sommerville (SOMMERVILLE, 2003), os requisitos funcionais são


aqueles que descrevem o comportamento do sistema, suas ações para cada entrada específica,

45
Payload: parte útil dos dados transmitidos
46
Timestamp: informação codificada identificando quando um determinado evento ocorrer
47
NCITS TR-25:1999: Padrões de Teste de Erro de Bit.
48
Trace Route: Ferramenta de diagnóstico que rastreia a rota de um pacote através de uma rede de computadores
49
DHCP: Dynamic Host Configuration Protocol (Protocolo de configuração dinâmica de host).
58
ou seja, é aquilo que descreve o que tem que ser feito pelo sistema. Descrevem as
funcionalidades que o sistema deve dispor e dependem do tipo de software que está sendo
desenvolvido, dos usuários e do tipo de sistema que está sendo proposto. Já os requisitos não
funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, ou seja, são
aqueles que não dizem respeito diretamente às funções específicas fornecidas pelo sistema.
Sabe-se que a especificação de requisitos é uma das tarefas mais importantes na
fase de elaboração de um software. A seguir tem-se as especificações dos requisitos para o
desenvolvimento do software implementado no equipamento TWS900ETH.

- Requisitos funcionais:

• Realizar conexão via Telnet.


• Executar sequência de comandos e grupo de comandos.
• Possibilitar a conexão e analise dos resultados de vários equipamentos
simultaneamente.
• Utilizar comandos de configuração via terminal ou a partir de interface gráfica
amigável
• Identificar e executar sequências de comandos, utilizando scripts, facilitando sua
operação.
• Reconhecer todos os comandos fornecidos do TSW900ETH e aceitar novos comandos
a partir de uma lista/lib.
• Permitir via comandos de scripts, aceitos pelo TSW900ETH, configurar, executar
testar, ler contadores e ver resultados.
• Disponibilizar relatórios de testes.
• Possuir Interface gráfica amigável.
• Listar scripts prontos, podendo inseri-los em novos scripts.
• Permitir tela de log para acompanhamento da execução dos scripts.
• Permitir a utilização de sequência de comandos passo-a-passo.
• Converter scripts remotos, para scripts embarcados.
• Permitir configurar, ler contadores, iniciar e controlar testes do TSW900ETH
realizando registros dos dados da rede.
• Permitir realizar a monitoração de perfil da rede testada.
• Permitir funções automáticas de configuração de perfis no equipamento.
59
• Permitir visualizar, salvar e exportar relatórios de resultados.
• Permitir copiar configuração atual do equipamento e salvar no PC.
• Permitir pré-visualizar configurações salvas do equipamento.
• Possuir sistema de login para diferentes grupos de usuários.
• Permitir liberar funções para usuários mediante códigos.

- Requisitos não funcionais:

• Ser compatível com o sistema operacional Windows e escrito em linguagem Java e


Lua. O software é baseado e desenvolvido para Windows podendo ser executado em
Linux (desejável). É compatível com Windows XP ou superior e Linux Ubuntu 10.04
ou superior tendo as mesmas funcionalidades para ambos os sistemas operacionais.

4.4 Solução Tecnológica para Implementação da Plataforma

Para desenvolvimento e implementação do sistema utilizou-se as linguagens de


programação Java e Lua, possibilitando a compatibilidade com os sistemas operacionais
Windows, Linux e Mac OS.
Segundo o Fórum Lua (LUA FORUM, 2012), Lua é uma linguagem de
programação poderosa, rápida e leve, projetada para estender aplicações. Ela combina sintaxe
simples para programação procedural com poderosas construções para descrição de dados
baseadas em tabelas associativas e semântica extensível. Essa linguagem é tipada
dinamicamente, e interpretada a partir de bytecodes para uma máquina virtual baseada em
registradores, e tem gerenciamento automático de memória com coleta de lixo incremental.
Essas características fazem de Lua uma linguagem ideal para configuração, automação
(scripting) e prototipagem rápida. Foi inteiramente projetada, implementada e desenvolvida
no Brasil, por uma equipe na PUC-Rio (Pontifícia Universidade Católica do Rio de Janeiro).
É distribuída via um pequeno pacote e compila sem modificações em todas as plataformas
que têm um compilador C padrão. Ela roda em todos os tipos de sistemas operacionais, Unix,
Windows, e também em dispositivos móveis (usando Android, IOS, BREW, Symbian,
Windows Phone), em microprocessadores embutidos (como ARM e Rabbit, para aplicações
como Lego MindStorms), e até mainframes IBM. (LUA FORUM, 2012).

60
Já a linguagem Java é orientada a objetos (comportamento dos objetos
determinados por classes). Diferente de outras linguagens que são compiladas para código
nativo, a linguagem Java é compilada para um bytecode que é executado por uma máquina
virtual (JAVA COMMUNITY PROCESS, 2012).
Essas linguagens foram escolhidas por se tratar de uma linguagem
multiplataforma (Java) e devido à existência dessa linguagem para interpretação de scripts no
test set (Lua). Com isso foi facilmente adaptada para o desenvolvimento das novas
funcionalidades do TSW900ETH, foco deste trabalho.
Para fins de testes, são utilizados dois ambientes, ou seja, a primeira etapa dos
testes aconteceu nos laboratórios do SENAI e da Datacom. Já a etapa final de validação está
em processo de testes em um circuito Metro Ethernet interestadual disponibilizado pela
operadora OI e também será validado por especialistas dessa operadora por se tratar de
clientes em potencial.
As ações de cada um dos atores do processo podem ser visualizadas no Diagrama
de Caso de Uso representado na Figura 23, que tem como finalidade representar as principais
funcionalidades da ferramenta.

Figura 23: Diagrama de Caso de Uso


Fonte: Elaboração Própria

61
4.4.1 Interfaces e Protocolos

Para implementação da Plataforma de Teste Automatizada acoplada ao


equipamento TSW900ETH, desenvolveu-se uma interface de gerência amigável para os
usuários finais. Isso para facilitar e tornar intuitivo as configurações e resultados de testes,
onde o equipamento pode ser operado por pessoas com menor conhecimento técnico em redes
de computadores, reduzindo o custo com mão de obra especializada. A interface de
comunicação com a gerência (ou com o PC ou notebook) é Ethernet através de uma porta
RJ45 existente no equipamento. O software desenvolvido se conecta através de telnet50 nessa
interface. Ele abre a conexão telnet com o endereço IP de gerência do equipamento e trocam
mensagens em TCP/IP51 com as informações de configuração e status.
No funcionamento do equipamento, os testes são realizados em camada física,
camada 2 (Ethernet) ou camada 3 (IP). Esse endereço IP de gerência é configurável, pode
mudar conforme a necessidade, além de ser independente dos endereços IPs das conexões de
teste. Se o PC estiver conectado diretamente no TSW900ETH, ambos devem estar
configurados para a mesma rede. Caso contrário, o PC e o TSW900ETH podem estar em
redes diferentes e mesmo assim se comunicar (como se fossem 2 PCs se comunicando em
redes diferentes) (WISE TELEMÁTICA, 2012). Em ambos os casos, para a realização do
acesso remoto, os links de interconexão entre as redes ou entre equipamento e PC devem estar
em seu pleno funcionamento.

4.4.2 Implementação da Ferramenta

Por se tratar de um projeto de inovação que será submetido a patente, o código


fonte não será disponibilizado nesta dissertação, porém é apresentada a aplicação em seu
perfeito funcionamento.
A seguir são apresentadas as características do software desenvolvido:

50
Telnet: Protocolo que permite a interface de terminais e de aplicações através da Internet.
51
TCP/IP: Conjunto de protocolos de comunicação entre computadores em rede (também chamado de pilha de
protocolos TCP/IP). Seu nome vem de dois protocolos: o TCP (Transmission Control Protocol - Protocolo de
Controle de Transmissão) e o IP (Internet Protocol - Protocolo de Interconexão)
62
- Compatível com o sistema operacional Windows:
As entregas foram realizadas visando o funcionamento para sistema Windows, já
que os testes de funcionamento foram realizados no SENAI, na Datacom e em um circuito
simulado da OI e essas empresas utilizam o sistema operacional Windows em sua maioria. A
figura 24, a seguir, mostra a tela inicial da ferramenta.

Figura 24: Tela inicial do test set TSW900ETH

- Realizar Conexão via Telnet:


Com essa funcionalidade possibilita ao usuário conectar-se a um aparelho
TSW900ETH através de seu endereço IP. O mesmo necessita estar na rede possibilitando a
conexão Telnet do software. A Figura 25 a seguir, apresenta a tela de conexão da ferramenta.

63
Figura 25: Tela de Telnet

- Executar sequência de comandos e grupo de comandos:


O software é capaz de executar comandos em sequência, um a um (reconhecido
pelo aparelho TSW900ETH), através de um Terminal visual da aplicação. Além disso, deve
ser possível executar grupos de comandos através de arquivos (Scripts) escritos em Lua com
sequências de comandos. A figura 26 a seguir apresenta essa funcionalidade.

64
Figura 26: Execução de Comando via Terminal

- Possibilitar a conexão e análise dos resultados de vários equipamentos


simultaneamente:
Com essa funcionalidade é possível conectar-se em mais de um aparelho
TSW900ETH, através da Plataforma Automatizada. As tarefas são executadas no
TSW900ETH selecionado pela aplicação, possibilitando assim a execução de tarefas em
diferentes TSW900ETH. A análise da rede poderá ser feita através das funcionalidades do
TSW900ETH. A figura 27 a seguir, apresenta essa funcionalidade.

65
Figura 27: Seleção de múltiplas conexões

- Utilizar comandos de configuração via terminal ou a partir de interface gráfica:


Os comandos poderão ser enviados via Terminal da aplicação (semelhante ao
Shell Linux) ou através do Profile para configuração de parâmetros de rede do TSW900ETH.
O Profile permite configurar Link Settings, Ethernet Settings e IP Settings através de uma
interface gráfica intuitiva e de fácil manipulação. A figura 28 a seguir, mostra a tela de
configuração do equipamento via terminal ou interface gráfica.

66
Figura 28: Envio de Configurações via Interface Gráfica

- Identificar e executar sequências de comandos, utilizando script:


Através da indicação do caminho de um arquivo, em linguagem de scripts do
TSW900ETH, a aplicação é capaz de identificar a sequência de comandos contidas no
arquivo (Script) e executá-las no aparelho indicado pela aplicação. A figura 29 a seguir,
mostra como utilizar scripts existentes e armazenados.

67
Figura 29: Iniciando execução de uma sequência de comandos

- Reconhecer todos os comandos fornecidos do TSW900ETH e aceitar novos comandos a


partir de uma lista/lib:
A aplicação contém uma base de dados com todos os comandos aceitos pelo
TSW900ETH, utilizada para auxílio ao usuário. A mesma pode ser atualizada quando o
usuário solicitar, através de um botão “Atualizar”. Essa atualização é feita de forma
automática pelo software que deve estar conectado ao TSW900ETH, onde são carregados os
comandos aceitos pelo mesmo.
A utilização dos comandos fornecidos do TSW900ETH para auto complete pode
ser vista na figura 29.

- Permitir via comandos de scripts, aceitos pelo TSW900ETH, configurar, executar


testes, ler contadores e ver resultados:
Através de um arquivo, em linguagem de scripts do TSW900ETH, o software
executa a sequência de comandos no TSW900ETH. Após a execução poderão ser lidos os
contadores de resultados através de comandos via Terminal da aplicação. A figura 30 a seguir,
apresenta alguns resultados.

68
Figura 30: Leitura de Contadores Via Terminal

- Disponibilizar relatórios de testes:


O software gera relatórios dos testes solicitados. Os relatórios conterão resultados
de testes descritos pela RFC2544, testes de Tráfego e de contadores. Os mesmos podem ser
visualizados diretamente na aplicação e o usuário pode escolher se deseja salvá-los.
Para os demais testes feitos diretamente no TSW900ETH a aplicação estará indicando na Web
local do TSW900ETH os resultados contidos no mesmo, onde será possível a exportação dos
Relatórios para PDF. A figura 31 a seguir, apresenta alguns relatórios de testes.

69
Figura 31: Exemplo de Relatório Criado pela Aplicação, nesse caso Throughput

- Possuir Interface gráfica:


Através da interface da aplicação podem ser acessados Relatórios e Gráficos
gerados com informações contidas no TSW900ETH, atualizados constantemente através do
pedido feito pelo usuário. Além disso, serão gerados histogramas de arquivos de scripts
executados na aplicação, através do comando “save_results”. Por exemplo, executar um script
que fique analisando a banda de minuto em minuto, o resultado poderá ser mostrado em um
histograma com uma janela de tempo. A figura 32 a seguir, apresenta um modelo de relatório
gráfico.

70
Figura 32: Gráfico Gerado para Acompanhamento do Teste de Throughput

- Listar scripts prontos e inseri-los em novos scripts:


Arquivos de scripts salvos pela aplicação são listados para uso futuro e
disponibilizados na interface para que possam ser executados quando necessário com maior
facilidade. A figura 33 a seguir, mostra como utilizar a lista de scripts existentes.

71
Figura 33: Listagem dos Scripts prontos para Execução

- Permitir tela de log para acompanhamento da execução dos scripts:


Os Scripts executados pela aplicação terão acompanhamento de mensagens
apresentadas, em tempo real de acordo com o comando que estiver sendo executado, no
terminal da aplicação.

72
- Permitir utilizar sequência de comandos passo-a-passo:
A aplicação permite que sejam executadas sequências de comandos reconhecidas
pelo TSW900ETH e no padrão DATACOM.

- Converter scripts remotos, para scripts embarcados:


É possível a conversão de scripts Embarcados para Remotos. Como resultado esta
função irá gerar outro arquivo, não danificando o arquivo inicial, com a conversão desejada.
Esta função será habilitada somente para alguns usuários, mediante licença. A figura 34, a
seguir, mostra a conversão de scripts.

Figura 34: Disposição para Conversão de Scripts

73
- Permite configurar, ler contadores, iniciar e controlar testes do TSW900ETH
realizando registros dos dados da rede:
É possível configurar e ler informações do TSW900ETH, através de comandos
enviados do Terminal da aplicação. Além disso, será possível iniciar e parar testes realizados
pelo TSW900ETH.

- Permitir monitoração de perfil da rede


Utilização de monitoração de uma porta do TSW900ETH. Para esta função pode
ser necessária a utilização de equipamentos adicionais. Este cenário pode ser realizado
utilizando um switch Datacom, com uma das portas como espaço para a porta onde está
conectado o TSW900ETH. A plataforma irá ler os contadores desejados (de banda, por
exemplo) registrando de tempo em tempo (conforme configurado) em memória do PC. As
informações dos contadores poderão ser visualizadas graficamente posteriormente.

- Permitir funções automáticas de configuração de perfis no equipamento:


Permite que sejam carregados perfis de configuração do TSW900ETH criados
pelo usuário, através do Profile e/ou perfis de fábrica. A figura 35, a seguir, mostra os perfis
automáticos.

Figura 35: Carregando Perfis já Salvos Anteriormente


74
- Permitir visualizar, salvar e exportar relatórios de resultados
Além de gerar relatório é possível exportar e salvar qualquer tipo nos formatos.

PDF e HTML. A figura 36 mostra os relatórios sendo salvos.


Figura 36: Exportando e Salvando Relatórios em PDF

- Permitir copiar configuração atual do equipamento e salvar no PC


O Profile, Interface visual de configuração do equipamento, permite que sejam
salvas as configurações do TSW900ETH no banco de dados, essas configurações poderão
posteriormente ser aplicadas a qualquer TSW900ETH.

- Permitir pré-visualizar configurações salvas do equipamento


Ao carregar uma configuração salva no banco via Profile da aplicação, o usuário
visualizará todos os parâmetros e caso deseje, pode altera-los antes que a configuração seja
enviada ao TSW900ETH.
É possível carregar as configurações atuais através do Profile, alterá-las e reenviá-
las ao TSW900ETH, através do Profile.

75
- Possuir sistema de login para diferentes grupos de usuários
A aplicação permite que usuários sejam cadastrados para fim de utilização de
informações, como nome, do mesmo em determinados pontos, como relatórios. Os usuários
terão permissão de executar as ações liberadas pela chave de licença do software. A figura 37,
a seguir, apresenta a tela de login.

Figura 37: Tela para Login de Usuários

76
- Permitir liberar funções para usuários mediante códigos
As funcionalidades da aplicação são liberadas mediante a inserção de uma chave
de liberação fornecida pela DATACOM. Com isso possibilitará que o sistema seja utilizado

em módulos, de acordo com suas funcionalidades. A figura 38 mostra a tela de bloqueio.


Figura 38: Tela para Inserção de Chave de Liberação

4.5 Testes Iniciais de Validação do Protótipo

A seguir, são apresentadas algumas especificações dos testes iniciais de


verificação da aplicação Remote TSW900ETH.

4.5.1. Conexão com o TSW900ETH

4.5.1.1 Conectar-se a um TSW900ETH

Para testar a realização de uma conexão com um TSW900ETH, deve-se utilizar o


menu Connect da tela principal na opção Connect To. A janela de conexão deve aparecer com
77
os campos de endereço IP e nome da conexão, além dos botões para salvar, editar ou apagar
uma conexão, juntamente com uma lista das conexões salvas previamente. Após preencher os
campos com o nome e endereço IP da conexão, basta selecionar Connect para realizar a
conexão com o equipamento ou Cancel para voltar ao menu principal.
Para salvar uma conexão é necessário preencher os campos de IP da conexão,
sendo o campo nome opcional. Não é possível salvar duas conexões com o mesmo endereço
IP. Após preencher os campos, basta selecionar o botão de Save.
Para editar uma conexão é necessário selecionar uma das conexões salvas exibidas
no painel e selecionar Edit. Na janela de edição, é possível alterar o nome da conexão e o seu
endereço IP. A aplicação não permite a alteração para um endereço IP já existente nas
configurações salvas.
Para excluir uma conexão é necessário selecionar uma das conexões salvas exibidas no painel
e selecionar Remove.
Caso o TSW900ETH destino já possua uma conexão Telnet com outra máquina, a
aplicação propõe a possibilidade de eliminar a conexão anterior (conectando-se a porta 5002,
conforme o manual do TSW900ETH). Selecionando Yes, a aplicação elimina a conexão
anterior e conecta-se ao equipamento. Selecionando No, a aplicação cancela a tentativa de
conexão.
Testes sugeridos
• A verificação de caracteres nos campos IP e Nome. Não deve ser possível inserir
letras ou símbolos no campo IP, somente números. O campo Name deve permitir
quaisquer caracteres, inclusive os especiais. A exceção se dá ao caractere ', utilizado
nas consultas SQL ao banco. O caractere é substituído pelo caractere`.
• Tentar salvar dois ou mais endereços IPs iguais. Ocasionar situações onde seja
possível configurar dois endereços IPs iguais e verificar se a aplicação realiza o
controle ao tentar salvar a conexão.
• Apagar uma conexão e verificar se esta conexão realmente é excluída do banco.
Ex.: Excluir uma conexão, fechar e abrir novamente a aplicação e verificar se a
conexão está na lista de conexões salvas. Outra forma seria, após a exclusão, tentar
salvar novamente a conexão.
• Tentar realizar uma conexão com um equipamento que já possua uma conexão Telnet
ativa. Testar as duas opções, verificando se a conexão é eliminada ou preservada
corretamente.

78
4.5.1.2. Múltiplas Conexões

O Remote TSW900ETH permite a conexão com múltiplos equipamentos


TSW900ETH de forma simultânea, operando os equipamentos separadamente. Com isso é
possível configurar cada equipamento de forma independente, selecionando a conexão
correspondente ao equipamento desejado. Para realizar uma nova conexão, basta repetir os
passos da sessão anterior, indo no menu Connect da tela principal na opção Connect To.
Após conectar-se a mais de um equipamento, é possível selecionar o equipamento
a ser operado através da combo box no menu principal. Para desconectar-se de um
equipamento específico, selecione a conexão correspondente e pressione o botão Disconnect a
direta.
Testes sugeridos
• Conectar-se a mais de 2 equipamentos. Verificar na tela principal a lista de
equipamentos conectados, alternando entre as conexões existentes.
• Desconectar-se de todas as conexões. Da mesma forma, alternar entre conexões e
desconexões. Verificar se após se desconectar de um TSW900ETH é possível se
conectar a ele novamente.

4.5.2. Configuração Remota

4.5.2.1 Configurações Manuais

O Remote TSW900ETH permite a configuração e operação Telnet de um


equipamento forma manual, através do CLI presente na tela principal. O CLI da aplicação,
que opera de forma bem semelhante a uma conexão Telnet realizada por uma máquina ao
equipamento, possui as opções de auto completar e histórico de comandos utilizados. É
possível utilizar os comandos Telnet do CLI da aplicação e visualizar seu retorno.
Caso a aplicação esteja conectada a mais de um TWS900ETH, os comandos serão enviados a
conexão que estiver selecionada. A validação deste item consiste apenas na verificação dos
comandos.

79
4.5.2.2 Profile

O profile refere-se à parte de configuração remota via Telnet de uma das portas do
TSW900ETH através de uma interface gráfica que reproduz os menus de configuração da
aplicação presente no equipamento. O profile é acessado através TSW900ETH Settings, em
Settings no menu principal. A janela de configuração deve aparecer mostrando os campos dos
menus de configuração das camadas L1, L2 e L3 (Link, Ethernet e IP Settings
respectivamente). Além disso, há ainda a possibilidade da configuração de outros campos da
aplicação, como a inserção de tags de VLAN e Q-in-Q e ativação de filtros L2/L3.
O menu permite selecionar em qual porta deseja configurar os campos, além de
oferecer as opções para armazenar uma configuração, com os valores atuais dos campos, e
carregar uma configuração existente (a configuração padrão sempre aparece como opção,
como forma de resetar a configuração. Esta opção não pode ser editada ou apagada).
Testes sugeridos
• Conectar-se a mais de 2 equipamentos. Utilizar configurações distintas em cada
conexão e verificar se uma configuração não influiu na outra.
• Testar as restrições de contexto do menu.
Ex.: Não deve ser possível configurar os campos de endereço IP caso a aplicação
esteja com Framing Ethernet ou ativar o modo ARP caso o valor do campo de MAC
Source Type esteja como Random.
• Atualizar o profile do Remote TSW900ETH obtendo as configurações atuais da
aplicação.
• Tentar salvar dois ou mais profiles iguais. Ocasionar situações onde seja possível
configurar dois profiles iguais e verificar se a aplicação realiza o controle ao tentar
salvar o profile.
• Carregar um profile salvo no banco.
• Apagar um profile e verificar se ele realmente é excluído do banco.
• Após salvar uma configuração, selecionar outra conexão e tentar carregar a conexão
salva anteriormente no novo equipamento.

80
4.5.3. Atualização dos Comandos

Para atualizar a lista de comandos da aplicação, basta acessar a janela principal e


clicar em File e sem seguida selecionar a opção Refresh Command List. Em seguida uma
janela de wait é exibida, enquanto a aplicação atualiza seu banco.
Testes sugeridos
• Iniciar a atualização e interromper a conexão ou cancelar a atualização. Verificar a
integridade do banco e se as opções de comando não foram alteradas.
• Após concluída a atualização, tentar usar um dos novos comandos.

4.5.4. Arquivos de Script .lua

Para iniciar um script .lua deve-se ir no menu Scripts opção Run Script. Na janela
de seleção de scripts, selecionar o arquivo .lua desejado. Quando o script iniciar aparecerá no
terminal a mensagem no terminal 'You Chose to open this file: "nome do script"'. É possível
acompanhar os comandos enviados para o test set através do terminal.
Testes Sugeridos
• Executar vários scripts em diferentes test set e verificar se as configurações do script
estão executando no test set correto.
• Executar scripts que levam grandes quantidades de tempo para terminar.
Ex.: Script que demore um dia.
• Iniciar scripts e para-los através da opção Stop Script no menu Scripts. Verificar se o
script realmente para de ser executados.

4.5.5. Conversão de Scripts

Para converter scripts embarcados para remotos utilize a opção Convert do menus
Scripts. O script convertido será adicionado na mesma pasta que a aplicação se encontra.
Testes Sugeridos
• Utilizar scripts que contenham comandos de concatenação por '..' e concatenação com
a função 'concat'.
• Verificar se script convertido funciona exatamente como o script original.

81
++ Configuração de Testes por Fluxograma ++
Para configuração de testes por fluxograma deve-se selecionar o tipo de teste na
paleta Test Library e em seguida selecionar o subtipo do teste que deseja-se realizar.
Ex.: Selecionar Traffic Test na paleta Test Library e depois a opção Single Stream.
Para configurar os parâmetros do teste selecionado, clique com o botão direito do
mouse sobre o teste dentro do campo de edição e selecione a opção Configure. Para conectar
os diferentes tipos de teste selecione na combo box Mouse Mode a opção Editing e ligue os
testes na ordem em que deseja-se executa-los. Para finalizar, selecione a porta em que as
configurações serão realizadas e clique em Execute.
Testes Sugeridos
• Testar opções da combo box Mouse Mode:
1. Editing: possibilita conectar testes.
2. Picking: seleciona testes e movimenta-os dentro do campo de edição.
3. Transforming: move todos os testes.
• Verificar se configurações ocorrem na porta desejada.
• Desconectar do test set durante a execução do fluxograma.

4.5.6. Relatórios

A aplicação permite criar relatórios, similar ao que é feito pela parte Web do
TSW900ETH. Para visualizar o relatório, vá ao menu Reports e selecione os contadores que
deseja.
Testes Sugeridos
• Verificar se os valores apresentados no relatório gerado conferem com os que são
apresentados pelo test set.
• Importa reports para .pdf.

82
4.6 Considerações Finais do Capítulo

Este capítulo apresentou o desenvolvimento e algumas etapas de testes do


protótipo funcional da Plataforma de Teste Automatizada, focando na sua parte principal, ou
seja, no software. Trata-se de um primeiro protótipo que ainda se encontra em fase final de
testes em ambiente real para validação de todas as suas funcionalidades. Foram apresentadas
também algumas funcionalidades implementadas no TSW900ETH, devidamente testadas e
em pleno funcionamento. Foram realizados testes iniciais em laboratório e testes em ambiente
real em um circuito Metro Ethernet disponibilizado pela operadora OI.
Trata-se de uma inovação incremental que trará um grande valor agregado para os
envolvidos, pois trata-se de uma tecnologia nacional com possibilidade de obtenção de
patente para o Brasil.

83
5 CONCLUSÕES E TRABALHOS FUTUROS

Este capítulo tem como objetivo apresentar as principais conclusões do trabalho


desenvolvido. São apresentados os resultados obtidos, sobre os quais são feitas considerações
finais e sugeridos tópicos para trabalhos futuros.

5.1 Conclusões

Esta dissertação apresentou todo o processo de desenvolvimento e implementação


de uma plataforma de teste automatizada acoplada a um equipamento de teste para redes
Ethernet e suas variações, o TSW900ETH, de fabricação da empresa Datacom e
comercialização pelas empresas Datacom e Wise.
Como resultados diretos obtidos com o desenvolvimento desta dissertação destacam-
se:
- Desenvolvimento de uma interface física que possibilitou a conexão física entre o
equipamento e um PC.
- Desenvolvimento de um software de comunicação que possibilitou a conexão lógica
entre o instrumento de teste e o PC.
- Realização de testes e validação do funcionamento da Plataforma de Testes
Automatizada do Equipamento TSW900ETH.
A implementação da plataforma de teste automatizada no equipamento TSW900ETH
possibilita a interligação do test set tradicional ao PC permitindo a realização de testes e
certificação em redes Metro Ethernet de forma remota, além da possibilidade de armazenar os
dados resultantes em um servidor web possibilitando a análise remota dos resultados dos
testes e/ou certificação. A funcionalidade de acesso remoto desenvolvida é um grande
diferencial nesse tipo de equipamento portátil.
Durante o desenvolvimento da plataforma de testes automatizada, foram
realizados diversos testes e ensaios em laboratório, garantindo com isso sua eficiência dentro
da ideia proposta. Todos esses testes tiveram os seus resultados registrados, documentados e
analisados, garantido a eficiência no funcionamento do mesmo, seguindo todos os padrões
técnicos e de segurança. Após os testes em laboratório, foi feita uma simulação em ambiente
real, ou seja, em uma operadora de telecomunicações por um período de vinte dias, onde foi
atestado de seu desempenho, funcionalidades e capacidade.
84
A figura 39 a seguir, disponibilizada pela operadora OI, mostra o tempo médio de
manutenção em circuitos ADSL que utilizam anéis Metro Ethernet.

Figura 39: Gráfico de Tempo Médio de Tratamento de BA (boletim de atendimento) em Horas. Dados referentes ao
período entre 1 e 07 de Outubro/2012
Fonte: (PCS, 2012)

Com os testes preliminares, onde com as novas funcionalidades de acesso e testes


remotos implementadas no equipamento TSW900ETH, é possível a redução considerável do
tempo de atendimento e solução desses defeitos.
A tabela 4 a seguir, também fornecida pela OI, mostra as localidades que
apresentam congestionamento em seus links e também as regiões e tecnologias mais
problemáticas. Analisando essa tabela, observa-se que os pontos atendidos pelos anéis Metro
Ethernet são pontos críticos e com as novas funcionalidades introduzidas nos equipamentos
de testes para essas tecnologias, esses pontos de falhas poderão ser detectados e corrigidos
com menor custo e com redução de tempo, gerando lucro para a operadora.

85
Tabela 4: Ocupação dos Links da OI por geografia

Fonte: (PCS, 2012)

Legenda:

Na figura 40 a seguir tem-se o tempo médio de manutenção em circuitos de


comunicação de dados da Operadora OI no último trimestre de 2012. Observa-se uma redução
no tempo de manutenção na Regional Sul e Ceará dessa operadora. Essa redução se deve em
grande parte a utilização da plataforma de teste automatizada do equipamento TSW900ETH.
Os testes em ambiente real dos equipamentos com suas novas funcionalidades foram
realizados nessas duas regionais, onde foram disponibilizados vários equipamentos para
utilização da operadora OI.

86
13
12
10 10 10
9 9
8 8
7 7 7 7 7 7
6
5 5
4 4 4 4 4
3

Reg. RJ Reg. NO Reg. PE Reg. MG Reg. CE Reg. BA Reg. Sul Reg. CO

1 semana 2 semana 3 semana

Figura 40: Tempo médio de reparo em circuitos


Fonte: (PCS, 2012)

O propósito industrial e comercial do projeto, desenvolvido com o apoio da


Datacom e do SENAI foi permitir o desenvolvimento de uma nova tecnologia para o setor de
telecomunicações, otimizando o processo de testes em circuitos de comunicação de dados. O
produto resultante desta dissertação poderá ser utilizado pelas operadoras de
telecomunicações e por provedores de acesso a internet. Isto permite otimizar o processo de
testes e manutenção em links de forma remota, sem a necessidade de deslocamento de
técnicos, o que facilitará a garantia do SLA e a disponibilização de serviços mais rapidamente
de formas confiáveis e eficazes.
Além disso, tem-se, por resultado deste trabalho, a pesquisa e o investimento em
inovação que irão gerar patentes. O produto entrará na linha de produção da empresa
Datacom, gerando retorno financeiro para os envolvidos neste desenvolvimento. É esperado
também um impacto social, econômico e ambiental, gerando emprego e renda de forma direta
e indireta, aumentando a capacidade produtiva da empresa parceira, além da atualização
tecnológica em atendimento às demandas de mercado.

5.2 Trabalhos Futuros

Fundamentalmente, a principal proposta para trabalhos futuros é o


desenvolvimento e a implementação dessa plataforma em instrumentos de testes de outros
fabricantes, bem como a implementação o desenvolvimento de novos padrões de testes, e de
novas interfaces e protocolos que venham a otimizar todo o processo de testes e certificação
de links para quaisquer tecnologias.

87
A partir da comercialização do equipamento pela Datacom, espera-se uma
abertura maior por parte da concorrência para que se possa ter acesso às documentações de
seus equipamentos de testes e com isso ser possível desenvolver diversas funcionalidades
nesses equipamentos, gerando novas tecnologias e recursos financeiros. Tudo isso, sem a
necessidade de importação de tecnologias com a expertise interna para desenvolvimento de
novos produtos e aplicações.

88
REFERÊNCIAS

ABRAHAM, M. B. R. Explosão da inovação - aprenda e inove de forma explosiva. 1ª. ed.


São Paulo: Epse, 2010.

ANATEL. Anatel. Anatel, 2010. Disponivel em: <http://www.anatel.gov.br>. Acesso em: 20


Março 2012.

BCB, B. C. D. B. Agências de fomento. Site do Banco Central, 2011. Disponivel em:


<http://www.bcb.gov.br/pre/composicao/af.asp>. Acesso em: 2 agosto 2011.

BNDES, B. N. D. D. Site do BNDES. BNDES - Banco Nacional do Desenvolvimento,


2011. Disponivel em: <http://www.bndes.gov.br>. Acesso em: 12 Julho 2011.

BRADNER, S.; MCQUAID, J. Benchmarking Methodology for Network. [S.l.]: Internet


Engineering Task Force, Network Working Group, 1999.

BURGESS, N. Testing of Ethernet Services in Telecom Network: RFC 2544. [S.l.]:


Agilent Technologies, 2004.

CIOFFI, J. M. et al. MÉTODO E APARELHO PARA A REALIZAÇÃO DE TESTES


DE LINHA EM INSTALAÇÕES DO CONSUMIDOR. PI 0709756-5A, 20 Dezembro
2011.

CLEMENTE, A. et al. Planejamento do negócio - como trasformar ideias em realizações.


2ª. ed. Brasília: Lucerna, 2004.

DACK et al. Arrangement for accessing and testing telecommunication circuits. US


4996695, 02 Abril 1990.

DATACOM. Manual do Equipamento TSW900ETH. Porto Alegre: [s.n.], 2012.

89
DINARDO, J. EQUIPAMENTO DE TESTE DE CIRCUITOS DE
TELECOMUNICACOES. PI 8101338-8, 17 Julho 1984.

DINARDO, J. EQUIPAMENTO DE TESTE AUTOMATICO REMOTO DE


TRANSMISSAO. PI 7907633-5, 2 Maio 1995.

DINSMORE, P. C. Como se tornar um profissional em gerenciamento de projetos - livro


Base de preparação para a certificação PMP. Rio de Janeiro: Quallymark, 2005.

EDDY et al. Method and system for selectively accessing multiplexed data transmission
network for monitoring and testing of the network. US 4996695, 9 Junho 1976.

FECOMÉRCIO. Site da FECOMÉRCIO, 2011. Disponivel em:


<http://www.fecomercio.com.br>. Acesso em: 10 Janeiro 2012.

FILHO, A. F. S.; DELANHESE, A. EQUIPAMENTO AUTOMÁTICO DE TESTE DE


INTERFACE DE ASSINANTES EM MÓDULOS DE TELECOMUNICAÇÕES.
PI9400198-7 A2 , 18 Fevereiro 2003.

FILIPPETTI, M. A. CCNA 4.1 - Guia Completo de Estudo. 1a. ed. Florianopólis: Visual
Books, 2008.

FINEP. Manual de Oslo - proposta e diretrizes para coleta e interpretação de dados


sobre inovação tecnológica. 3. ed. Brasília: OECD, 1997.

FINEP. A Empresa. Página da FINEP, 2011. Disponivel em:


<http://www.finep.gov.br/o_que_e_a_finep/a_empresa.asp>. Acesso em: 1 Agosto 2011.

IBOPE. Site do IBOPE, 2010. Disponivel em: <http://www.ibope.com.br>. Acesso em: 5


Janeiro 2012.

IEEE 802.3. Site do IEEE, 2011. Disponivel em: <http://www.ieee802.org/3/>. Acesso em: 5
janeiro 2011.

90
IETF RFC 1242. IETF, 1991. Disponivel em: <http://www.ietf.org/rfc/rfc1242.txt>. Acesso
em: 14 OUTUBRO 2013.

IETF RFC 2544. IETF, 1999. Disponivel em: <http://www6.ietf.org/rfc/rfc2544>. Acesso


em: 20 Janeiro 2012.

INPI. INPI. INPI, 2012. Disponivel em:


<http://www.inpi.gov.br/portal/artigo/busca_patentes>. Acesso em: 16 Janeiro 2013.

ITU-T. ITU-T G.703. [S.l.]: [s.n.], 2001.

ITU-T G114. Telecommunication Standartization Sector of ITU Series G: Transmission


Systems and Media, Digital Systems and Networks. [S.l.]: [s.n.], 2003.

JACOBSON, H.; FONI, D.; KRAMARCZYK, M. SISTEMA DE MONITORAÇÃO DE


DESEMPENHO E ACESSO DE TESTE E MÉTODO PARA CONEXÃO CRUZADA
DE REDES DE COMUNICAÇÃO. PI 9815810-4, 29 Novembro 2011.

JAVA COMMUNITY PROCESS. Java Community Process. [S.l.]: [s.n.], 2012.

JUNGMANN, D. D. M. Inovação e Propriedade Intelectual. Brasília: SENAI, 2010.


KRAMARCZYK, M. et al. SISTEMA E MÉTODO DE TESTE DE ACESSO PARA
REDES DE COMUNICAÇÃO DIGITAL. PI 9814489-8, 29 Novembro 2011.

KUROSE, J. F.; ROSS, K. W. Redes de computadores e a Internet: Uma abordagem top-


dow. 5a. ed. São paulo: Pearson, 2010.

LUA FORUM. Lua Forum. [S.l.]: [s.n.], 2012.

MAZZONI, P. H. M. Metro Ethernet. UFRJ, 2008. Disponivel em:


<http://www.gta.ufrj.br/grad/04_2/metro>. Acesso em: 09 set. 2012.

MEF. Metro Ethernet Networks - A Technical Overview. MEF, 2004. 1-17.

91
MEF. Metro Ethernet Services - A Technical Overview. Metro Ethernet Forum, 2006a. 1.

MEF. Metro Ethernet Services - A Technical Overview. Metro Ethernet Forum, 2006b. 1-4.

MEF. Metro Ethernet Services - A Technical Overview. Metro Ethernet, 2006c. 1-19.

MEF. Site do Metro Ethernet Forum, 2011. Disponivel em:


<http://metroethernetforum.org/>. Acesso em: 23 julho 2011.

MEF. MEF. Site do Metro Ethernet Forum, 2011. Disponivel em:


<http://metroethernetforum.org/>. Acesso em: 23 julho 2011.

MONTEIRO, J. A. S.; SAMPAIO, L.; FIGUEREDO, M. GT-QoS: documento de avaliação


dos pilotos. [S.l.]: RNP, 2003.

OI TNL PCS. Produtos e Serviços da OI. Rio de Janeiro: OI, 2009a.

OI TNL PCS. Roteiro para Realização de Testes. Rio de Janeiro: OI, 2009b.

PCS, O. T. Readq_Velox2012. OI. Rio de Janeiro. 2012.

PMI. Guia PMBOK - um guia do conjunto de conhecimentos em gerenciamento de


projetos. 4ª. ed. Coraopolis: PMI, 2008.

PRYOR, D. M. P.; CHALLIS, M.; LEEUW, L. V. ARRANJO PARA TESTE DE CANAL


DE COMUNICAÇÕES. PI 9307422-0, 7 Julho 2000.

PUC. Site da PUC Rio, 2011. Disponivel em: <http://www.inf.puc-


rio.br/~inf2056/inf2056_files/menu/material/transparencias/colcher/Ethernet.pdf>. Acesso
em: 30 Maio 2012.

ROXO, S. O. CONFIGURAÇÃO CONSTRUTIVA APLICADA A EQUIPAMENTO DE


TESTE EM TELEFONIA. MU 7400473-5, 28 Fevereiro 2001.

92
SELING, K. R.; ONOFRIO, S. SISTEMA PORTÁTIL DE TESTE REMOTO DE LINHA
DE ASSINANTE. PI 9506015-4, 5 Abril 2011.

SENAI. Technix - sistema de gerenciamento de projetos. Technix, 2010. Disponivel em:


<www.senai.br/technix>. Acesso em: 7 Agosto 2011.

SILVA, J. M. O.; CARDOSO, P. K. F. SISTEMA DE TESTE AUTOMÁTICO DA REDE


TELEFÔNICA. PI 8903020-6, 12 Setembro 1995.

SILVA, M. Q.; FERREIRA, S. P. Gerenciamento de Riscos em Projetos de Inovação


Tecnológica Financiados Por Agências de Foemnto. Revista Brasileira de Gerenciamento
de Projetos, Pinhais, v. 9, n. Segunda, p. 100, Novembro 2012. ISSN ISSN 1679-902X.

SNIADOWER, L.; GLIGA, A. S. SISTEMA DE TESTE DE LINHA DE


TELECOMUNICAÇÕES. PI 9105973, 15 Junho 1999.

SOMMERVILLE, I. Engenharia de software. 6ª. ed. São Paulo: Addison, 2003.

SOUZA, F. N. M. D. A. Monitoração de Desempenho de Voz sobre IP. [S.l.]: [s.n.], 2006.

TANENBAUM, A. S. Rede de Computadores. 4a. ed. São Paulo: Campos, 2003.

TELECO. Teleco. Teleco, 2010. Disponivel em:


<http://www.teleco.com.br/tutoriais/tutorialvirt/pagina_3.asp>. Acesso em: 19 Janeiro 2013.

TNL PCS. Relatório de desempenho de redes de dados. OI. Rio de Janeiro. 2012.

UIT. Site da União Internacional de Telecomunicações, 2011. Disponivel em:


<http://www.onu.org.br/onu-no-brasil/uit>. Acesso em: 10 Novembro 2011.

VIMPARI, M. PROCESSO DE TESTE REMOTO E TERMINAL DE UMA CONEXÃO


DE ASSINANTE SEM FIO, SISTEMA PARA IMPLEMENTAR UMA CONEXÃO DE

93
ASSINANTE SEM FIO E REDE DE TRANSMISSÃO DE DADOS. PI 9707937-5, 24
dez. 2002.

WEISZ, J. Projetos de inovação tecnológica - planejamento, formulação, avaliação,


tomada de decisões. 1ª. ed. Brasília: IEL, 2009.

WISE TELEMÁTICA. Manual do Equipamento TSW900ETH. Brasília: [s.n.], 2012.

YONEZAWA, W. M. Comércio eletrônico: estratégias e implementação. Universidade


Estadual Paulista, 2003. Disponivel em: <http://wwwp.fc.unesp.br/~yonezawa/ec-
estrategia.pdf>. Acesso em: 11 julho 2011.

94

Você também pode gostar