Gestão de Home Networks
Wilson Vieira da Silva
Orientador: Salviano Filipe Silva Pinto Soares
Co-orientador: Pedro Miguel Mestre Alves da Silva
Vila Real, 2009
Gestão de Home Networks
Wilson Vieira da Silva
Orientador: Salviano Filipe Silva Pinto Soares
Co-orientador: Pedro Miguel Mestre Alves da Silva
Dissertação submetida à
Universidade de Trás-os-Montes e Alto Douro
Para a obtenção do grau de
Mestre
em Engenharia Electrotécnica e de Computadores, de acordo com o disposto no
DR – I série – A, Decreto-Lei n.º 74/2006 de 24 de Março e no
Regulamento de Estudos Pós-Graduados da UTAD
DR, 2.ª série – Deliberação n.º 2391/2007
Orientação Científica:
Salviano Filipe Silva Pinto Soares
Professor Auxiliar do
Departamento de Engenharias da Escola de Ciências e Tecnologia da Universidade de
Trás-os-Montes e Alto Douro
UTAD
Pedro Miguel Mestre Alves da Silva
Professor Auxiliar do
Departamento de Engenharias da Escola de Ciências e Tecnologia da Universidade de
Trás-os-Montes e Alto Douro
UTAD
Trabalho realizado em parceria com estágio curricular realizado na PT Inovação no
âmbito do Programa Talento 2008/2009
Acompanhamento do trabalho:
Eng. Alexandre Laranjeira
Colaborador da PT Inovação
iii
iv
À minha família e amigos
à UTAD
e
à PT Inovação
v
vi
Gestão de Home Networks
Wilson Vieira da Silva
Submetido na Universidade de Trás-os-Montes e Alto Douro para o preenchimento dos
requisitos parciais para obtenção do grau de Mestre em Engenharia Electrotécnica e de
Computadores
Resumo –
A evolução da banda larga e a introdução de novos equipamentos
especializados em determinado tipo de serviço exigem a adopção de soluções
inovadoras que permitam uma gestão e configuração rápida e flexível de acordo com as
necessidades específicas de cada equipamento e cliente.
A recente convergência de diversos serviços (voz, dados, wireless e televisão) num
mesmo canal de acesso (Triple Play e Quadruple Play) e a profusão de aplicações têm
dificultado a gestão, segurança e garantia do QoS (Quality of Service) nas redes,
provocando assim a procura de novas soluções.
Garantir a configuração, integridade e despiste de casos de avaria, são nesta altura
grandes desafios para os sistemas de suporte à operação dos operadores.
A PT Inovação dispõe de um sistema, o Network Activator, que é responsável pela
mediação entre os sistemas de suporte à operação e os equipamentos da rede.
Este trabalho apresenta um módulo de gestão de equipamentos baseado no recente
protocolo de gestão remoto CWMP (CPE WAN Management Protocol), com o
objectivo de um dia vir a ser integrado à plataforma da PT Inovação.
Palavras-chave: Gestão de Redes, Home Networking, Protocolos de Gestão, CPE
WAN Management Protocol, Simple Network Management Protocol, Universal Plug
and Play, Network Configuration, Command Line Interface, BroadBand Forum,
Application Programing Interface, Java, API_TR069.
vii
viii
Management of Home Networks
Wilson Vieira da Silva
Submitted to the University of Trás-os-Montes and Alto Douro in partial fulfillment of
the requirements for the degree of Master of Science in Electrical and Computers
Engineering
Abstract
– The broadband evolution and the new specialized equipment
introduction at specific type of service require innovative solutions that enable
management and fast and flexible configuration, according to the specific needs of each
client and equipment.
The recent convergence of various services (voice, data, wireless and television) in the
same channel access (Triple Play and Quadruple Play), and the increase of the number
of applications has hindered the management, security and QoS (Quality of Service) in
data networks, thus causing a demand for new solutions.
Ensure the configuration, integrity, and screening of cases of failure, are, at this time
great challenges in the operation support systems of the operators.
PT Inovação has a system, Network Activator, which is responsible for mediating
between operation support systems and network equipment.
This work presents a module equipment management based on recent remote
management protocol CWMP (CPE WAN Management Protocol), with the aim of
being able to be integrated into the platform of PT Inovação.
Keywords: Network Management, Home Networking, Management Protocols, CPE
WAN Management Protocol, Simple Network Management Protocol, Universal Plug
and Play, Network Configuration, Command Line Interface, BroadBand Forum,
Application Programming Interface, Java, API_TR069.
ix
x
Agradecimentos
Além das pessoas que aqui vou citar, agradeço também a todas as outras que comigo
conviveram não só durante o período de realização deste trabalho, mas durante todos
estes meus anos de vida; sem eles o resultado final nunca teria sido o mesmo.
Institucionalmente, os meus agradecimentos ao Magnífico Reitor da Universidade de
Trás-os-Montes e Alto Douro, Professor Doutor Mascarenhas Ferreira, ao director da
Escola de Ciências e Tecnologia da Universidade de Trás-os-Montes e Alto Douro,
Professor Doutor José Afonso Moreno Bulas Cruz, ao director do Departamento de
Engenharias da ECT professor doutor Luís Ramos e ao pessoal administrativo, pelas
facilidades concedidas e meios colocados à disposição para a realização deste.
Ao Professor Doutor Salviano Filipe Silva Pinto Soares, orientador deste trabalho, por
todo o apoio e orientação que me deu, desde o primeiro ao último momento.
Ao Professor Doutor Pedro Mestre, na qualidade de co-orientador, pelas suas sugestões
e ideias que viabilizaram e traçaram de forma significativa, o rumo deste trabalho.
Ao Engenheiro Alexandre Laranjeira, meu orientador no estágio curricular realizado na
PT Inovação, pelo grande conhecimento e experiência que me passou durante este
período, tendo sido bastante agradável trabalhar ao lado deste grande profissional.
A toda a PT Inovação pela oportunidade de realização deste estágio, pelas óptimas
condições que me disponibilizaram durante a realização do projecto e pela grande
camaradagem que recebi de todos os profissionais desta empresa.
Finalmente, gostaria de expressar a minha mais profunda gratidão a toda a minha
família, sendo eles os grandes responsáveis por tudo aquilo o que sou e tenho.
A todos, muito obrigado.
UTAD, Vila Real
Wilson Vieira da Silva
31 de Outubro, 2009.
xi
xii
Índice
Resumo…………………………………………………………………… ..
vii
Abstract…………………………………………………………………… ..
ix
Agradecimentos…………………………………………………………….
xi
Índice……………………………………………………………………….
xiii
Índice de Figuras…………………………………………………………....
xv
Índice de Tabelas……………………………………………………………
xvii
Acrónimos…………………………………………………………………..
xix
1
1.1
1.2
1.3
1
3
4
4
Introdução………………………………………………………….
Motivação…………………………………………………...
Objectivos…………………………………………………...
Organização da Dissertação………………………………....
2
Protocolos de Gestão………………………………………………
2.1
Universal Plug and Play…………………………………….
2.2
Interface de Linha de Comando…………………………….
2.3
Simple Network Management Protocol…………………….
2.4
Network Configuration……………………………………..
2.5
CPE WAN Management Protocol………………………….
2.5.1
BroadBand Forum………………………………….
2.5.2
Descrição da norma CWMP (TR-069)……………. .
2.5.3
Funcionalidades…………………………………… .
2.5.4
Arquitectura..……………………………………… .
2.5.5
Parâmetros………………………………………… .
2.5.6
Estabelecimento de Sessões………………………...
2.5.7
Modelo de Comunicação………………………….. .
2.5.8
Métodos RPC……………………………………... .
2.5.8.1
Métodos CPE……………………………… .
2.5.8.2
Métodos ACS……………………………….
2.5.9
Integração de TR-069 com UPnP…………………. .
2.5.10
Extensões TR-069………………………………… .
7
9
10
11
13
14
15
16
18
19
20
21
22
24
25
27
28
30
3
33
Concepção da API_TR069………………………………………
xiii
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.4.2.1
3.4.2.2
3.4.2.3
Requisitos…………………………………………………..
Use Cases……………………………………………………
Reboot……………………………………………….
Upgrade de Firmware………………………………..
Configuração de um Serviço………………………..
Detecção de Falha de Energia……………………….
Arquitectura……………………………………………….. ..
Actores Externos……………………………………
Componentes Internas………………………………
Diagramas…………………………………………………...
Diagrama de Classes…………………………………
Diagrama de Sequência……………………………..
Reboot………………………………………
Download de Firmware…………………….
Inform não Requisitado ………………………
34
35
35
36
36
37
38
38
39
41
41
43
44
47
48
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Implementação da API_TR069…………………………………. .
CPE_Entity………………………………………………..
CPE Factory……………………………………………….
Session Manager…………………………………………..
Request Client……………………………………………..
Connection Manager………………………………………
ACS_Entity………………………………………………..
Interfaces Externas………………………………………..
49
49
50
50
51
51
52
52
5
5.1
5.2
5.3
5.4
5.5
5.6
Testes……………………………………………………………..
Reboot…………………………………………………….
Factory Reset……………………………………………...
Download…………………………………………………
Várias Sessões Activas……………………………………
Configuração de Serviço………………………………….
Recolha de Informação e detecção de erros na Comunicação
55
56
58
59
60
62
63
6
Conclusões e Trabalhos Futuros………………………………..
65
Bibliografia………………………………………………………………
xiv
67
Índice de Tabelas
1
2
Camadas protocolares do protocolo CWMP………………
Métodos TR-069…………………………………………...
xv
19
25
xvi
Índice de Figuras
1 Ambiente UPnP………………………………………………………….
9
2 Ambiente de gestão SNMP………………………………………………
12
3 Ambiente de gestão utilizando o protocolo CWMP……………………..
17
4 Exemplo de uma transacção de mensagens numa sessão TR-069……….
23
5 Integração de TR-069 com UPnP………………………………………..
29
6 Conjunto de extensões pertencentes ao âmbito de aplicação do CWMP..
31
7 Arquitectura e componentes da API_TR069…………………………… .
38
8 Diagrama de Classes da API_TR069…………………………………….
41
9 Diagrama de Sequência referente a invocação do método de Reboot……
44
10 Diagrama de Sequência referente a invocação do método de Download.
47
11 Diagrama de Sequência de um Inform não Requesitado……………….
48
xvii
xviii
Acrónimos
ACS – Auto-Configuration Server, servidor responsável pela auto configuração de
CPE.
API – Application Programming Interface, trata-se de um conjunto de rotinas e padrões
estabelecidos por um software.
BEEP – Blocks Extensible Exchange Protocol, geralmente também conhecido por
BXXP, corre tipicamente sobre TCP e possibilita a troca de mensagens (frames). Ao
contrário de HTTP e de outros protocolos semelhantes, este permite que ambos os
extremos da conexão consigam enviar mensagens a qualquer momento.
CLI – Command-line Interface, mecanismo que permite interagir com um software
através da digitação de comandos para realizar determinadas tarefas.
CPE – Customer-Premises Equipment ou também conhecido por Customer-Provided
Equipment, equipamento localizado nas instalações do cliente e conectado a um canal
de uma operadora de telecomunicações.
CWMP – CPE WAN Management Protocol, também bem conhecido por TR-069,
trata-se de um protocolo da camada de aplicação que permite gestão remota de CPE.
EPON – Ethernet PON, tecnologia PON que utilize pacotes Ethernet em vez de células
ATM.
HTTP – HyperText Transfer Protocol, protocolo da camada de aplicação utilizado para
transferir dados por intranets e pela World Wide Web.
HTTPS – HyperText Transfer Protocol Secure, implementação do protocolo HTTP
sobre uma camada SSL ou TLS.
IDE – Integrated Development Environment, trata-se de um ambiente integrado para
desenvolvimento de software.
IETF – Internet Engineering Task Force, grupo internacional cuja função é estruturar
correctamente a evolução da arquitectura da internet e garantir o seu correcto
funcionamento.
IP – Internet Protocol, protocolo sob o qual assenta a infra-estrutura da Internet.
IPTV – IPTV ou TVIP trata-se de um método de transmissão de sinais televisivos
utilizando o protocolo IP.
ISP – Internet Service Provider, corresponde ao fornecedor do acesso à internet.
xix
JDK – Java Development Kit, é um conjunto de utilitários que permitem criar sistemas
de software para a plataforma java. É composto por compilador e bibliotecas.
LAN – Local Area Network, rede de computadores de pequena dimensão, cobrindo por
exemplo a área de uma casa, escritório ou mesmo de um pequeno grupo de edifícios.
MIB – Management Information Base, tipo de base de dados usada para gerir
dispositivos em redes de comunicações.
NAT – Network Address Translation, é uma técnica que consiste em alterar o endereço
IP de origem de um pacote que passa por um router ou firewall de maneira que um
computador de uma rede interna tenha acesso ao exterior (rede publica).
NETCONF – Network Configuration, é um protocolo de gestão de redes desenvolvido
pelo IETF.
NGN – Next Generation Networking, termo amplo que descreve as recentes e futuras
evoluções arquitecturais nas redes de telecomunicações.
OSI – Open Systems Interconnection, arquitectura que define uma forma comum de
conectar computadores.
OSS – Operations Suport System, trata-se de sistemas computacionais usados pelos
fornecedores de serviços de telecomunicações para dar suporte aos seus clientes.
PDA – Personal Digital Assistants, é um computador de dimensões reduzidas dotado de
uma grande capacidade computacional.
PON – Passive Optical Network, é a tecnologia que permite transmissão de dados
através de fibra óptica.
QoS – Quality of Service, refere-se a capacidade de fornecer um serviço conforme as
exigências.
RPC – Remote Procedure Call, trata-se de um processo de comunicação que permite
que um programa local invoque remotamente a execução de um outro programa.
SNMP – Simple Network Management Protocol, é um protocolo da camada de
aplicação utilizado para gestão de redes TCP/IP.
SOAP – Simple Object Access Protocol, é um protocolo utilizado para troca de
informações utilizando tecnologias baseadas em XML.
SSL – Secure Sockets Layer, protocolo utilizado para transmitir documentos de forma
segura através da internet.
SSH – Secure Shell, trata-se de um protocolo de rede que permite a conexão com outro
computador na rede de forma a executar comandos remotamente.
STB – Set-Top Box ou conversor, é um termo que descreve um equipamento que se
conecta a um televisor e a uma fonte externa de sinal, e transforma este sinal em
conteúdo no formato que possa ser apresentado em uma tela.
xx
TCP – Transmission Control Protocol, é um dos protocolos sob os quais assenta o
núcleo da Internet. Ele verifica se os dados são enviados de forma correcta, na
sequência apropriada e sem erros, pela rede.
TCP/IP – Corresponde a um conjunto de protocolos utilizados para comunicação entre
computadores em rede.
TLS – Transport Layer Security, tal como o seu predecessor trata-se de um protocolo
encriptado que promove uma comunicação segura através da Internet.
TR-064 – Technical Report 64, desenvolvido pelo actual BroadBand Forum,
corresponde a norma que especifica como deverá ser feita a comunicação entre o
Residential Gateway e os hosts da LAN.
TR-069 – Technical Report 69, desenvolvido pelo actual BroadBand Forum,
corresponde a norma de especificação do protocolo CWMP.
TR-111 – Technical Report 111, desenvolvido pelo actual BroadBand Forum,
corresponde a norma que define a gestão de dispositivos pertencentes a home network
através do protocolo TR-069.
UML – Unified Modeling Language, é uma linguagem que auxilia a visualização do
desenho da comunicação entre objectos.
UPnP – Universal Plug and Play, é um conjunto de protocolos de redes de
computadores que permite conexões directas e simplificadas para implementação de
redes em casas e escritórios.
VoIP – Voice over Internet Protocol, tecnologia que permite transmissão de
comunicações de voz sobre redes IP.
WAN – Wide Area Network, rede de computadores que cobre uma grande área.
WS – Web Services, trata-se de sistemas de software desenhados para suportar interoperacionalidade e interacção de sistemas computacionais através da rede.
xDSL – Família de tecnologias que fornecem um meio de transmissão digital de dados
(ex: ADSL, HDSL, VDSL, SDSL, UDSL), aproveitando a própria rede de telefonia que
chega na maioria das residências.
XML – Extensible Markup Language, é uma linguagem utilizada para facilitar o
transporte e armazenamento de informação.
xxi
xxii
1
Introdução
As comunicações electrónicas têm convergido para um modelo de redes de multiserviço baseadas em tecnologias integradoras, designadas de Next Generation
Networking (NGN) [42].
Para os Internet Service Provider (ISP), as actuais redes de acesso de banda larga
representam não só um acrescido risco de segurança nas redes dos seus clientes, mas
também, uma maior dificuldade em garantir a respectiva QoS (Quality of Service). Tais
dificuldades devem-se à associação de quatro factores: elevados débitos disponíveis
para cada um dos clientes; elevado número de clientes servidos por cada ISP;
permanente solicitação das ligações (xDSL, cabo, fibra, 3G); e a falta de conhecimentos
técnicos dos clientes que garanta a correcta gestão da sua rede doméstica.
Ainda que parte das dificuldades actuais já existissem anteriormente, o carácter
intermitente das ligações dial-up clássicas e os reduzidos débitos disponíveis, tornavam
mais simples aos ISP a tarefa de detectar e controlar situações de risco para as suas
redes, para os seus clientes ou terceiros.
A recente convergência de diversos serviços (voz, dados, wireless e televisão) num
mesmo canal de acesso (Triple Play e Quadruple Play) e a profusão de aplicações têm
1
dificultado a gestão, segurança e garantia do QoS nas redes, provocando assim a
procura de novas soluções.
Os ISP têm considerado que a gestão e segurança da rede do cliente estão fora da sua
esfera de influência, devendo ser administrada autonomamente pelo cliente.
Normalmente, os operadores consideram que a sua esfera de influência acaba no seu
equipamento de fronteira, sendo responsabilidade do cliente a gestão dos seus próprios
equipamentos de home gateway e de tudo o que esteja para lá desses equipamentos.
Actualmente as redes Triple e Quadruple Play alteram parcialmente esta perspectiva,
passando a ser necessárias e aceites algumas intervenções do operador no interior da
rede do cliente, nomeadamente para administrar remotamente set-top box (STB) e
gateways de serviço telefónico.
A entrada dos operadores nas redes domésticas tem influenciado que entidades tais
como BroadBand Forum [4] e Home Gateway Initiative [16] apostem na normalização
das tecnologias que permitem administrar e monitorizar remotamente não só os
equipamentos de fronteira home gateway mas também outros equipamentos CPE
(Customer Premise Equipment) localizados na rede do cliente.
As principais ferramentas utilizadas pelos administradores das redes para gerir seus
equipamentos foram as interfaces de linha de comando CLI, oferecidas pelos fabricantes
do equipamento, e o protocolo de aplicação SNMP (Simple Network Management
Protocol) desenvolvido pelo IETF [19]. Actualmente tem-se optado pela norma CWMP
(CPE WAN Management Protocol), também conhecida como TR-069.
O TR-069 pertence ao âmbito das Broadband Suites do referido fórum, fazendo assim
parte de uma família de normas e protocolos extensíveis e orientados para a gestão em
ambientes de banda larga.
Esta norma tem vindo a conhecer crescente aceitação, sendo de esperar que seja
gradualmente integrada por todas as aplicações de administração, do lado dos
operadores, e por todos os equipamentos, no lado dos fabricantes de CPE (em especial
routers/modems ADSL e set-top boxes).
A adopção do TR-069, permite que seja relativamente simples ao operador disseminar
novas regras e configurações para grupos alargados de utilizadores, em função dos
respectivos perfis e equipamentos instalados.
A gestão de configurações é realizada recorrendo a um servidor de auto-configuração
(ACS, ou Auto-configuration Server, segundo a terminologia TR-069), que realiza a
distribuição de actualizações de software dos CPE, a adição de novos serviços e a
gestão dos perfis do ambiente.
Outras tecnologias recentes tais como UPnP (Universsal Plug and Play) e NetConf
(Network Configuration) foram também padronizadas para apoiar e responder às actuais
necessidades de gestão das redes.
2
O nosso objectivo principal foi desenvolver uma solução de gestão de equipamentos
utilizando o protocolo CWMP que se comporta como servidor ACS para gerir CPE TR069, permitindo configurar remotamente equipamentos de clientes sem que estes
necessitem de possuir conhecimento técnico. Permite também a configuração de
equipamentos de variadíssimos fabricantes, desde que suportem as normas TR-069 ou
TR-064 (protocolo que possibilita interacção entre os protocolos UPnP e o standard TR069).
Deste trabalho resultou um protótipo capaz de gerir equipamentos TR-069 e isolar as
especificações deste protocolo de outros sistemas ou utilizadores que virão a utilizar
esta ferramenta. Pretende-se que uma versão evoluída desta ferramenta venha a ser
integrada na plataforma Network Activator [28] da PT Inovação.
Esta solução trata-se de uma API (Application Programming Interface) desenvolvida na
linguagem de programação orientada a objectos Java [33] [24], tendo sido utilizado o
software gratuito NetBeans IDE 6.5.1 instalado com a versão 6 do Kit de
Desenvolvimento Java (JDK) da Sun [25], como ferramenta de compilação e
desenvolvimento da API.
1.1 Motivação
O TR-069 tem-se vindo a tornar cada vez mais como protocolo padrão na gestão e
configuração remota de CPE, a sua utilidade suscitou o interesse da PT Inovação para a
criação de uma proposta de estágio curricular com o objectivo de implementar um
módulo de gestão baseado nesta norma.
A PT Inovação pretende que este módulo desenvolvido seja o ponto de partida para que
num futuro próximo a sua plataforma Network Activator conte com uma solução TR069 de forma a melhor servir os seus clientes.
O projecto desta dissertação de Mestrado foi integrado neste estágio curricular realizado
nas instalações da PT Inovação em Aveiro durante o período 1/12/2008 a 1/9/2009.
3
1.2 Objectivos
Os objectivos projectados no enquadramento desta proposta de dissertação foram os
seguintes:
Aquisição/consolidação de Conhecimentos
Estudo da norma TR-069 e aquisição de valências necessárias para a realização do
projecto.
Implementação de um ACS
Construção de um módulo de gestão de equipamentos baseado no recente protocolo de
gestão remoto CWMP.
Realização de testes com equipamentos da PT Inovação
O ACS implementado deverá ser testado convenientemente.
1.3 Organização da Dissertação
Além deste capítulo introdutório, que visa enquadrar este trabalho, apresentar os
objectivos traçados e sua motivação, esta dissertação é composta por mais cinco
capítulos.
O capítulo dois, “Protocolos de Gestão”, apresenta a importância da gestão de
equipamentos na realidade das redes actuais e futuras, e contem uma descrição de
diversas tecnologias de gestão, sendo dedicado especial atenção a tecnologia de gestão
remota utilizada na realização deste projecto, o CPE WAN Management Protocol.
Os três capítulos seguintes, “Concepção”, “Implementação” e “Testes”, correspondem a
uma descrição detalhada das fases do desenvolvimento e funcionamento do módulo de
configuração e gestão de equipamentos TR-069 construído.
O capítulo “Concepção”, capítulo três, descreve a análise teórica realizada antes da
implementação prática da aplicação. Aqui serão apresentados requisitos, casos de
utilização, arquitectura e diagramas de classes e fluxo que explicam o funcionamento da
aplicação. Este esboço teórico foi feito, com o intuito de prever as necessidades a ter em
conta durante o seu desenvolvimento; a correcta forma de implementação; e o
funcionamento e resultado final.
Por outro lado, o quarto capítulo, “Implementação” corresponde a uma análise mais
detalhada e a explicação dos procedimentos práticos escolhidos para a implementação
do sistema. Aqui será descrito sucintamente o funcionamento do servidor ACS; serão
apresentadas as funcionalidades que o sistema suporta e será também explicada a forma
como o utilizador ou um sistema interage com a aplicação.
4
No quinto capítulo, “Testes”, são apresentados os resultados obtidos com a aplicação
desenvolvida.
Por último, o capitulo seis, “Conclusões e Trabalhos Futuros”, tal como o nome do
capítulo indica, é onde é feita uma apreciação final e global acerca da API_TR069 e são
referidos trabalhos que poderão ser realizados ainda no âmbito deste projecto.
No fim do documento são citadas as fontes que me auxiliaram na elaboração deste
documento.
5
6
2
Protocolos de Gestão
Desde o aparecimento do primeiro computador no inicio dos anos 60 do século passado,
tem-se verificado que tecnologia tem gerado tecnologia a uma velocidade
impressionante.
Em particular duas áreas que continuam a registar uma forte evolução tecnológica são
as redes de telecomunicações e redes de computadores, encontrando-se ambas
actualmente em sentido de convergência. Esta convergência associada aos novos
avanços tecnológicos das redes tem levado a que estas duas áreas actuem numa
dimensão comum, que é o fornecimento de múltiplos serviços baseados em uma única
infra-estrutura.
O conceito de convergência, o "internetwork", que corresponde a um conjunto de
dispositivos e procedimentos que permitem a interconexão de redes individuais,
formando redes de maiores dimensões e capacidades. Estas redes são baseadas no
emprego de computadores e seus recursos de controlo, aliadas à utilização de técnicas
de comutação de pacotes e transmissão de dados dos sistemas de telecomunicações,
sendo, portanto, uma combinação de ambas as tecnologias.
O grande símbolo desta convergência de tecnologias é a Internet.
Num futuro próximo e de uma forma global todos os nossos equipamentos domésticos
(televisão, fogão, microondas, lâmpadas, etc.) serão implementados com interfaces de
7
rede, possibilitando a sua conexão à Internet. Tudo poderá ser equipado com tais
aparelhos de rede, possibilitando uma forma de vida cada vez mais conveniente, indo ao
encontro da célebre frase citada por Max Frisch "Tecnologia é a habilidade de organizar
o mundo de forma que não tenhamos que senti-lo" [13].
A criação do modelo de referência OSI [15] [44] corresponde a um dos maiores passos
dados na gestão de redes. Este modelo promoveu a coordenação e estruturação das
comunicações de dados, permitindo redução da complexidade de desenvolvimento de
normas; maior flexibilidade e simplicidade de implementação de alterações e
funcionalidades nas camadas; incorporação de novas tecnologias e compatibilidade
entre fabricantes [41].
Durante muito tempo a existência de um único protocolo padronizado (SNMP) e as
interfaces CLI integradas nos equipamentos, foram suficientes para garantir uma
correcta gestão e monitorização de equipamentos e serviços nas nossas redes.
No entanto, o SNMP nunca se afirmou como uma solução fiável e segura em termos de
configuração e as interfaces de linhas de comando (CLI) sempre se apresentaram
mecanismos muito pouco flexíveis, visto certos aspectos funcionais dependerem
directamente do fabricante do equipamento.
Se adicionarmos a estes factores o aumento da dimensão das redes IP, concluí-se
facilmente que estas ferramentas não atendem às necessidades de configuração das
redes modernas actuais, daí a necessidade da criação de soluções de gestão automáticas
e capazes de configurar sistemas a partir de protocolos padronizados e extensíveis.
Existem várias razões que tornaram o TR-069 como tecnologia padrão na gestão de
equipamentos dos clientes dos ISP.
A criação de um protocolo de gestão remota como o CPE WAN Management Protocol
(TR-069) representa a possibilidade, de que ISP sejam capazes de aceder remotamente a
diferentes equipamentos de diferentes fabricantes, através de uma tecnologia
completamente padronizada e através da mesma infra-estrutura.
Apesar do âmbito de aplicação deste protocolo ser de configuração ponto a ponto dentro
de uma rede WAN, o mesmo foi desenhado para ser compatível com outras tecnologias,
nomeadamente o UPnP, tornando-o assim um protocolo extensível e capaz de chegar
também as nossas LAN.
Uma outra característica deste protocolo é a sua flexibilidade: baseia-se em protocolos
completamente normalizados e de utilização aberta (SOAP [47], XML [50],
HTTP/HTTPS [45], TCP [27]), permitindo assim que os próprios ISP desenvolvam as
suas próprias ferramentas de gestão.
Disponibiliza também mecanismos que permitem facilmente instalar novos serviços e
software nos equipamentos. Garante ainda uma comunicação bastante segura e fiável
entre servidor e cliente TR-069.
8
Face as limitações de configuração apresentadas pelo protocolo SNMP, o IETF
desenvolveu o Network Configuration (NetConf), tratando-se também de um protocolo
de configuração e gestão remota baseado em tecnologias abertas e padronizadas.
Relativamente ao TR-069, o NetConf tem como única diferença o facto de permitir ser
encapsulado e transportado através de diferentes tecnologias (SOAP, BEEP, SSH). É
igualmente bastante seguro em todas as suas implementações.
Neste capítulo iremos falar um pouco de todas estas soluções de gestão, no entanto será
dedicado especial atenção ao protocolo de gestão remota CPE WAN Management
Protocol ou também conhecido por TR-069.
2.1 Universal Plug and Play
A tecnologia Universal Plug and Play (UPnP) [35] estende do Plug and Play; é
constituída por protocolos abertos (TCP/IP [48]) direccionados para a comunicação na
Internet e por tecnologias Web; é promulgada pelo UPnP Forum [34]; define uma
arquitectura capaz de estabelecer conexão ponto a ponto em redes de dispositivos
inteligentes e é projectada para proporcionar fácil utilização e flexibilidade, dado
basear-se em padrões de conectividade ad-hoc [36] [37].
Estas redes são pequenas tais como as que temos em nossas casas, pequenos negócios
ou mesmo espaços públicos onde poderá existir ou não conexão à internet. Esta
tecnologia pretende facilitar a implementação e instalação destas redes, a partilha de
dados e comunicações entre dispositivos.
Figura 1 – Ambiente UPnP [18].
A existência desta tecnologia faz com que o conceito futurista “All-IP” (tudo possuirá
endereço IP) se torne possível num futuro não muito distante. Podemos imaginar um
9
despertador activado pela rede que sabe das suas reuniões, verifica o trânsito e a
previsão do tempo, calcula quando você precisa acordar e, pela manhã, o informa do
horário do seu voo, a previsão do local de destino, e quando você precisa sair. Em
direcção ao aeroporto, o seu assistente pessoal digital (PDA) activado pelo UPnP
encontra o melhor lugar para estacionar o carro e solicita um jornal para você se
informar sobre a actualidade. Enquanto viaja, o seu PDA verifica as suas reuniões, faz
as reservas dos restaurantes e hotéis e pede alguns petiscos para quando você chegar a
casa. Actualmente estas extravagâncias ainda não existem, mas serão possíveis com a
existência do UPnP [11].
Quando os dispositivos que incorporam a tecnologia UPnP são fisicamente conectados à
rede conectam-se automaticamente uns aos outros, sem a necessidade de o utilizador
configurar ou centralizar serviços e servidores.
A especificação UPnP é baseada em protocolos de rede tais como: IP, TCP, UDP,
HTTP e XML. Permitindo assim que os dispositivos comuniquem facilmente entre si,
negociem portas e permitam que aplicações UPnP trabalhem de forma transparente sem
a necessidade de configuração. Daí a razão pela qual ser chamada de universal pois não
necessitar de drivers específicos de dispositivo, usando esses protocolos padrões em seu
lugar.
Os dispositivos UPnP podem configurar automaticamente o endereçamento de rede,
anunciar sua presença em uma sub-rede e permitir a troca de descrições de serviços e
dispositivos. Um computador com o Windows XP ou Windows Vista pode actuar como
um ponto de controlo de UPnP, descobrindo e controlando dispositivos através de uma
interface de rede.
Basicamente, dispositivos UPnP transmitem as suas capacidades a todos os pontos na
rede e permitem que clientes UPnP ajam como pontos de controlo.
Comparativamente aos resultados verificados com a tecnologia Plug and Play, que
facilitou as acções de configuração e adição de novos periféricos a um único
computador, o UPnP não se apresenta como uma novidade tão revolucionária. No
entanto certamente trata-se de um grande e importante passo na evolução das nossas
redes.
2.2 Interface de Linha de Comando
Uma interface de linha de comando é um mecanismo que permite o envio de comandos
para realizar tarefas em determinado computador ou sistema, possibilitando assim uma
interacção com o mesmo [40].
10
Este mecanismo poderá ser utilizado na gestão de equipamentos, sendo uma técnica
amplamente utilizada em todo o universo informático.
Este método de gerir um computador, para executar uma determinada tarefa, baseia-se
na escrita de um comando na linha de comandos e respectivo envio do comando. O
envio desse comando será feito após seja pressionada a tecla “Enter”. Nesse momento o
interpretador da linha de comandos recebe, analisa e executa o referido comando [32].
Este interpretador de linha de comandos deverá estar a correr num terminal de texto
localmente ou numa janela shell, remotamente como por exemplo um cliente PuTTY.
Após a conclusão, o comando geralmente retorna ao utilizador o resultado da execução
da operação em formato texto na CLI.
Os fabricantes dos equipamentos de rede (tipicamente Switchs, Routers, Hubs, Bridges)
incorporam nos seus equipamentos mecanismos que permitem configura-los através de
CLI, proporcionando aos administradores das redes, técnicas fáceis de configuração. No
entanto, estas ferramentas variam de fabricante para fabricante. O seu uso representa um
elevado custo operacional, associado ao desenvolvimento dos scripts e da sua
manutenção. De salientar ainda o facto de o administrador necessitar de conhecer bem o
equipamento e os comandos que ele incorpora.
2.3 Simple Network Management Protocol
No início da década de 80, o protocolo Simple Network Management Protocol (SNMP)
começou a ser desenvolvido pelo Internet Engineering Task Force (IETF), com o
objectivo de disponibilizar uma forma simples e prática de gerir equipamentos numa
rede de computadores.
O SNMP é um protocolo de gestão pertencente a camada de aplicação do modelo OSI.
Pode ser utilizado tanto para obter informações, como alterar a configuração de
equipamentos SNMP que se encontram espalhados numa rede baseada na pilha de
protocolos TCP/IP.
Estes equipamentos são denominados de agentes SNMP, enquanto a entidade que gere
estes agentes é denominado por gestor.
A informação de gestão dos agentes pode ser acedida através do repositório conhecido
por Management Information Base (MIB). Na realidade este repositório não contém
qualquer tipo de dados, mas sim a informação acerca de que dados podem ser usados
para gerir o agente.
11
O funcionamento do SNMP é baseado numa troca de informações entre a MIB do
agente e a aplicação do gestor. As acções de gestão são realizadas através do envio de
pedidos por parte do gerente a um ou mais agentes utilizando o protocolo de transporte
UDP (User Datagram Protocol).
Figura 2 – Ambiente de gestão SNMP [39].
Em termos de operações, o SNMP disponibiliza duas operações básicas (SET e GET) e
suas derivações (GET-NEXT e TRAP).
A operação SET é utilizada para alterar o valor de determinada variável; o gestor
solicita que o agente faça uma alteração no valor da variável.
A operação GET é utilizada para ler o valor de determinada variável; o gestor solicita
que o agente obtenha o valor da referida variável.
A operação GET-NEXT é utilizada para ler o valor da variável seguinte; neste caso o
gestor fornece o nome de uma variável e obtém o valor e o nome da próxima variável;
também utilizado para obter valores e nomes de variáveis de uma tabela de tamanho
desconhecido;
A operação de TRAP é utilizada para informar o gestor da ocorrência de determinado
evento.
Apesar do SNMP ser um protocolo muito bom em termos de monitorização, o mesmo
não se reflecte nas acções de configuração. O facto de utilizar datagramas UDP para
transporte da sua informação de gestão, faz dele um protocolo muito pouco fiável e
seguro. Devido a estas deficiências, o IETF tem vindo a desenvolver novas versões
deste protocolo (SNMPv2 e SNMPv3).
Se adicionarmos a estas lacunas o facto do acesso aos agentes não ser controlado nem
registado, e ainda o facto da arquitectura das MIBs variarem entre alguns fabricantes,
faz com que o SNMP muito dificilmente se torne um protocolo talhado para a
configuração de equipamentos.
12
Uma especificação completa e detalhada deste protocolo pode ser encontrada no RFC
1157 [10].
2.4 Network Configuration
O Network Configuration (NetConf) trata-se de uma tecnologia de gestão e
configuração de rede. A sua implementação foi iniciada em Maio de 2003 e foi
publicado em Dezembro de 2006 pelo Internet Engineering Task Force (IETF) [12].
O NetConf disponibiliza mecanismos capazes de instalar, recuperar, manipular e apagar
configurações de dispositivos de rede. A sua utilidade é semelhante à utilização de
linhas de comando e interfaces Web quando estas são utilizadas como técnicas de
configuração de equipamentos de rede. Estas técnicas geralmente são direccionadas à
interacção directa do humano com o equipamento e o seu uso é muitas vezes meramente
local. O NetConf pode ser utilizado para gerir equipamentos remotamente, e
disponibiliza uma interface flexível e programável, fomentando a criação de aplicações
automáticas de configuração e monitorização de dispositivos de rede.
Sessões NetConf possibilitam efectuar múltiplas alterações de configuração simultâneas
dentro da mesma sessão. Nestas sessões é possível realizar alterações e só depois decidir
aplica-las, evitando que operadores de rede cometam erros de configuração.
O grupo de trabalho NetConf preocupou-se em produzir um protocolo adequado à
configuração de rede com as seguintes principais características:
•
•
•
•
•
•
•
•
Capaz de fornecer mecanismos que diferenciem dados configuráveis de dados
não configuráveis;
Seja suficientemente extensível para que fabricantes proporcionem acesso a
todos os dados de configuração dos dispositivos usando um protocolo único;
Interface aberta e programável;
Utilize uma representação textual dos dados, de forma a serem facilmente
editados, não havendo assim necessidade da utilização de ferramentas
complexas de manipulação;
Permita integração com os actuais métodos de autenticação do utilizador;
Independência a nível de transporte;
Suporte um conjunto de operações de configuração;
Promova suporte a notificações assíncronas.
Antes do NetConf a opção natural de configuração era o Simple Network Management
Protocol (SNMP). Foi largamente difundido entre fornecedores e portanto
frequentemente encontrado em dispositivos comerciais. Porém, para ser utilizado
concretamente como protocolo de configuração, o utilizador do SNMP precisa levar em
13
consideração as carências do protocolo, particularmente a nível de fiabilidade e
segurança. O SMNP continua a apresentar-se como um excelente protocolo de
monitorização, apesar de apresentar as referidas limitações a nível de configuração.
Com a criação do NetConf, o IETF apresentou um protocolo de configuração sem as
limitações existentes no SNMP, como também um protocolo baseado nas novas
tecnologias de Web Services (WS) [49], que têm sido alvo de grande investigação no
contexto de gestão de redes.
O objectivo principal do NetConf é unificar a maneira pela qual os dispositivos de rede
são configurados, propondo padrões que sejam simples e suficientemente genéricos para
abranger diversos tipos de dispositivos.
De forma geral, pode-se dizer que o NETCONF é um conjunto de definições para
formação de documentos Extensible Markup Language (XML) de configuração.
Dentre as características dos WS, pode-se citar sua simplicidade e padronização, que
contribuem para a obtenção da interoperabilidade entre aplicações. O protocolo
largamente utilizado para troca de mensagens WS é o Simple Object Access Protocol
(SOAP) baseado em XML e transportado geralmente via HTTP.
O IETF propõe as seguintes formas de transportar o protocolo NetConf:
•
•
•
•
•
NetConf encapsulado em mensagens SOAP sobre HTTP [17];
NetConf encapsulado em mensagens SOAP sobre HTTPS (via SSL-TLS) [1];
NetConf encapsulado em mensagens SOAP sobre BEEP [14];
NetConf directamente sobre BEEP (Blocks Extensible Exchange Protocol)
[23][29];
NetConf directamente sobre SSH (Secure Shell) [38].
O princípio de funcionamento do NETCONF é baseado no paradigma RPC (Remote
Procedure Call), através do qual é definido um conjunto de operações do protocolo [26].
Basicamente o gerente NETCONF (cliente) codifica uma requisição RPC em XML e a
envia ao agente NETCONF (servidor). O agente, ao receber uma mensagem
NETCONF, processa a requisição e envia uma resposta RPC de volta ao gerente. Tanto
mensagem de pedido como resposta são enviadas em formato XML, e têm as suas
estruturas totalmente descritas em schema XML [46], permitindo ao gerente e agente
NETCONF validarem as mensagens recebidas.
2.5 CPE WAN Management Protocol
O CPE Wan Management Protocol foi publicado em Maio de 2004 no relatório técnico
69 do DSL Fórum (actual BroadBand Forum), daí o protocolo ser também conhecido
14
por TR-069. Trata-se de um protocolo de gestão remota de dispositivos e já encontrou
ampla aceitação por grandes fabricantes, tais como a Thomson, Alcatel e Cisco, que
implementam clientes TR-069 em seus dispositivos [5].
2.5.1 BroadBand Forum
O BroadBand Forum corresponde a um consórcio global constituído por cerca de 200
líderes da indústria das telecomunicações, computação, redes e empresas provedoras de
serviços. Fundado em 1994 originalmente com o nome de ADSL Forum e
posteriormente DSL Forum. Actualmente é conhecido por BroadBand Forum onde a 18
de Maio de 2009 conseguiu uma forte união com o IP/MPLS Forum.
O IP/MPLS Forum trata-se de uma organização internacional cujos seus membros são
entidades tais como: provedores de serviço, fabricantes de equipamentos, centros de
teste e utilizadores empresariais. A sua missão é indicar soluções e aplicações
direccionadas à correcta utilização de diversas tecnologias de rede.
Com esta união, o BroadBand Forum tornou-se o órgão central para especificações da
próxima geração de redes IP.
O BroadBand Forum age em benefício dos seus membros, reconhecendo a
competitividade verificada entre eles, e procura definir leis globais que tornem essa
competitividade saudável. Com estas leis o BroadBand Forum pretende ainda garantir
uma correcta utilização das técnicas especificadas, partilhar as melhores práticas de
implementação, promover o mercado da banda larga e facilitar o desenvolvimento
interoperacional da banda larga com base em componentes de rede.
Desde 1994, este Forum desenvolveu mais de 100 especificações baseadas na definição
da tecnologia DSL (Digital Subscriber Line) para fornecer máxima eficiência de gestão
da banda larga. Dado abordar todas as formas da tecnologia DSL, o seu nome foi
alterado para DSL Forum em 1999.
Ao longo dos anos, esta organização focou o seu trabalho no desenvolvimento da
arquitectura de fibra óptica e em garantir que prestadores de serviço fossem capazes de
gerir as suas próprias redes a partir de uma plataforma de endereçamento IP. De modo a
realçar esse trabalho desenvolvido, em 2008 o seu nome foi novamente alterado para
BroadBand Forum.
Em 2005, foi criado o BroadBandSuite, que agrupou uma serie de soluções técnicas de
transporte, gestão da rede digital e apoio ao cliente. Actualmente o BroadBandSuite
destaca 3 conjuntos de soluções desenvolvidas pelo BroadBand Forum: rede,
administração e especificações orientadas ao utilizador.
15
Algumas das principais especificações de rede desenvolvidas até ao momento tratam-se
soluções para tecnologias tais como ADSL, SHDSL e ADSL2/2plus. Até ao fim de
2009 serão ainda concluídos testes de performance da tecnologia VDSL2.
Para além de trabalhos desenvolvidos associados a este vasto conjunto de tecnologias
DSL, tem surgido outros trabalhos associados a outras tecnologias tais como: PON,
EPON e desenvolvimento de normas Ethernet ponto a ponto.
O BroadBand Fórum também tem tido preocupações relacionadas com a eficiência
energética, tencionando propor medidas que permitam a aderência de indústrias aos
compromissos globais de redução de energia.
O trabalho desenvolvido inclui também especificações direccionadas a configuração de
redes, aos sistemas de controlo de acesso e aos sistemas de suporte a operações. Estas
especificações correspondem a práticas correctas para solucionar problemas em banda
larga, incluindo mecanismos de controlo de frames e fornecendo mecanismos de
controlo direccionados a operadores remotos de linhas fixas.
O desenvolvimento do protocolo de gestão remota da rede digital doméstica (TR-069)
corresponde a um marco importante na história do BroadBand Forum, tornando-se
mesmo como protocolo padrão para gestão remota. A capacidade de facilmente
adicionar modelos de objectos a novos equipamentos tem contribuído para que
provedores de serviço sejam capazes de manter sempre actualizados serviços e
aplicações nos dispositivos.
2.5.2 Descrição da norma CWMP (TR-069)
A finalidade da criação deste protocolo foi desenvolver um padrão de gestão de
equipamentos em ambiente WAN. Com base nesta plataforma de gestão comum,
provedores de serviço são capazes de gerir todos os seus equipamentos através da
internet, independentemente do dispositivo ou fabricante. Até aqui nunca tinha existido
uma plataforma de gestão semelhante, devido ao facto dos fabricantes de equipamentos
criarem seus próprios mecanismos de configuração e não partilharem esses mecanismos
com os seus concorrentes.
O TR-069 trata-se de um protocolo da camada de aplicação que proporciona
comunicação bidireccional entre determinado equipamento que se pretenda configurar e
a respectiva entidade configuradora. Essa comunicação é baseada em mensagens SOAP
sobre HTTP e garante uma configuração segura.
O desenvolvimento do padrão TR-069 trata-se de uma resposta à complexidade
registada na configuração dos equipamentos do utilizador comum.
16
O TR-069 é utilizado para gestão/configuração remota de equipamentos domésticos
(modems, routers, gateways, set-top box, telefones VoIP) TR-069 do utilizador comum.
Sendo a sua grande maioria gateways residenciais, poderá também ser utilizado para a
gestão de outros equipamentos não TR-069, visto ser possível a sua integração com a
tecnologia UPnP, tornando-o assim capaz de alcançar uma vasta quantidade de
dispositivos nas nossas redes.
Num ambiente TR-069, o elemento responsável pela gestão dos equipamentos CPE
(Customer Premises Equipment) é o ACS (Auto Configuration Server) que terá duas
interfaces de comunicação distintas como se pode observar na figura 3. Uma diz
respeito à informação trocada com fornecedores de serviço, sistemas de controlo de
acesso e operadores que estarão a utilizar este servidor (esta interface está fora do
âmbito de aplicação do TR-069). A outra interface corresponde à comunicação deste
servidor com os dispositivos TR-069.
Cada CPE só pode ser gerido por um único ACS, num ambiente multi-provedor. Poderá
ser limitativo, dado que toda a configuração de gestão de determinado CPE terá de ser
mantida num único ACS que será responsável por resolver todos os conflitos
relacionados com a configuração dos dados de configuração e distribuir a configuração
para os respectivos dispositivos.
Figura 3 – Ambiente de gestão utilizando o protocolo CWMP [5].
A figura 3 representa um ambiente TR-069 contendo as entidades já referidas.
O TR-069 apresenta vantagens sobre outros protocolos de gestão, tais como SNMP ou
NETCONF. Utiliza TCP como protocolo de transporte em vez de datagramas UDP
usados no SNMP, aumentando assim a fiabilidade que se trata de uma característica
bastante importante num protocolo de configuração.
Outra característica importante do TR-069 trata-se do facto de não usar conexões TCP
persistentes entre a aplicação gestora e o equipamento, permitindo assim que o ACS
17
seja capaz de gerir uma grande quantidade de CPE simultaneamente ao contrário de
algumas implementações de NetConf, que necessitam de manter a sua conexão de
gestão sempre aberta com o equipamento que está a operar.
Comparativamente ao NetConf, o TR-069 apresenta-se bastante mais flexível visto
existirem extensões que o colocam compatível com tecnologias modernas tais como o
UPnP, conseguindo assim alcançar equipamentos das LAN e equipamentos não TR069.
Em termos de flexibilidade de operacionalidade o TR-069 incorpora um mecanismo que
proporciona que tanto ACS como CPE sejam capazes de iniciarem o estabelecimento de
sessões TR-069.
O TR-069 foi também projectado para promover um elevado nível de segurança e para
impedir a manipulação ilícita das operações efectuadas entre um CPE e respectivo ACS.
Fornece ainda confidencialidade para essas operações, e permite vários níveis de
autenticação.
2.5.3 Funcionalidades
O TR-069 oferece as seguintes ferramentas e funcionalidades de gestão:
•
Auto-configuração e provisionamento dinâmico de serviço.
Capacidade de reconfigurar e permitir recolha de informação de CPE TR-069.
•
Download Software / Firmware.
Oferece ferramentas de gestão de download do software CPE bem como a actualização
de ficheiros de firmware. Coloca ainda ao nosso dispor mecanismos para identificação
da versão, iniciação do download, e notificação acerca do sucesso ou falha de
download.
Quando o Download é iniciado pelo ACS, o ACS fornece ao CPE a localização do
arquivo a ser transferido. O CPE, em seguida, efectua a transferência, e notifica o ACS.
No entanto estas transferências podem ser opcionalmente iniciadas pelo próprio CPE.
Nesse caso, o CPE envia um pedido de download de um determinado tipo de arquivo ao
ACS. O ACS responde iniciando o download seguindo os mesmos passos como se fosse
o ACS a fazer o download.
•
Acompanhamento de Estado e Desempenho.
18
Proporciona suporte a CPE de forma a tornar disponível informação com a qual o ACS
poderá usar para monitorar o estado e performance do CPE. Também define um
conjunto de mecanismos que permite que o CPE notifique o ACS de alterações no seu
estado.
Diagnóstico
•
Promove suporte a CPE de forma a tornar disponível informação com a qual o ACS
poderá usar para diagnosticar e resolver problemas de conectividade ou serviços, bem
como a habilidade de executar definidos testes de diagnóstico.
2.5.4 Arquitectura
O CPE WAN Management Protocol contém mecanismos exclusivos, no entanto o seu
funcionamento baseia-se no uso de diversos protocolos padrão.
A tabela 1 mostra as camadas protocolares no qual o protocolo CWMP é constituído.
Camada
CPE/ACS
Application
Descrição
Aplicações CWMP usadas nas entidades CPE e ACS. A
aplicação é localmente definida e não faz parte do CPE WAN
Management Protocol
RPC Methods
Métodos RPC especificados
Management Protocol
SOAP
Uma norma baseada em sintaxe XML utilizada para codificar
RPC Methods. Especificamente SOAP 1.1
HTTP
SSL/TLS
TCP/IP
na norma do
CPE WAN
HTTP 1.1
Padrão do Internet Transport Layer Security Protocols.
Especificamente, SSL 3.0 (Secure Socket Layer) ou TLS 1.0
(Transport Layer Security).
Padrão TCP/IP.
Tabela 1 – Camadas protocolares do protocolo CWMP.
O uso de SSL / TLS para transporte do CWMP é recomendado, embora o protocolo
pode ser utilizado directamente sobre uma conexão TCP. Se SSL / TLS não for
utilizada, alguns aspectos da segurança serão sacrificados. SSL / TLS fornece
confidencialidade e integridade dos dados e permite autenticação em ambos os
terminais.
19
Determinadas restrições sobre a utilização de SSL / TLS e TCP são definidas na norma
do CWMP [5].
O funcionamento básico deste protocolo de configuração baseia-se em troca de
mensagens SOAP transaccionadas entre CPE e ACS através de HTTP 1.1, onde o CPE
comporta-se como cliente HTTP e ACS como servidor HTTP. No entanto o protocolo
contém também um mecanismo de pedidos de conexão que permite ao ACS comportarse como cliente e CPE por sua vez como servidor.
As operações e informações CWMP enviadas nas mensagens SOAP são emitidas em
formato textual e codificadas na linguagem de transporte XML.
Um ACS é capaz de configurar e monitorar um CPE através de uma série de métodos
RPC (Get, Set, Inform, Download, Upload, Reboot entre outros) disponibilizados pelo
protocolo.
Este protocolo possibilita que programadores com base em ferramentas de
desenvolvimento, construam de uma forma aberta aplicações de configuração seguras,
dinâmicas e escaláveis.
2.5.5 Parâmetros
O CPE WAN Management Protocol define mecanismos através dos quais um ACS é
capaz de ler, alterar ou mesmo apagar parâmetros internos dos equipamentos,
atribuindo-lhe assim capacidades tais como configuração, monitorização e
edição/adição fácil de novos serviços aos equipamentos. Parâmetros de diferentes tipos
de CPE são definidos em normas separadas.
TR-106: Modelo de Dados para Equipamentos TR-069 [7].
TR-098: Modelo de Dados para Internet Gateway Device TR-069 [3].
TR-104: Modelo de Dados para VoIP CPE [8].
Cada parâmetro consiste num par nome/valor. O nome identifica um determinado
parâmetro, e possui uma estrutura hierárquica semelhante para arquivos num directório,
com cada nível separados por um "." (ponto). O valor de uma
Parâmetro pode ser uma definição de diversos tipos de dados.
Os parâmetros podem ser definidos como de leitura ou leitura e escrita. Parâmetros só
de leitura podem ser utilizados pelo ACS para determinar características específicas do
funcionamento de determinado CPE, observar o estado actual do dele ou reunir dados
estatísticos.
20
Parâmetros que possibilitem leitura e escrita, permitem que um ACS seja capaz de
personalizar vários aspectos do funcionamento do CPE de forma a melhorar e corrigir o
seu desempenho.
Apesar de certos parâmetros serem passíveis a alteração, contém informação
confidencial (por exemplo passwords de determinado utilizador); nessas situações, caso
seja pretendida a leitura desses valores, será retornado um valor vazio. O valor de
alguns parâmetros de escrita podem ser modificáveis por outros meios, por exemplo via
alguma auto-configuração existente na LAN. Daí a necessidade de precaução na
implementação dos mecanismos de auto-configuração tanto do lado WAN como LAN.
2.5.6 Estabelecimento de Sessões
O CPE WAN Management Protocol tem definido mecanismos que permitem que o CPE
se conecte ao ACS em diversas condições, garantindo assim que a comunicação CPE –
ACS ocorra com alguma frequência mínima.
Conhecendo previamente o endereço do ACS, CPE poderá a qualquer momento
estabelecer sessão com o ACS, essa sessão entre os dois terminais é iniciada após o
CPE enviar ao ACS uma mensagem Inform num POST HTTP. Este Inform trata-se de
um método RPC invocado pelo CPE e executado no ACS, e é utilizado para estabelecer
as sessões de transacção entre CPE e ACS. A invocação deste método contém
informação relevante acerca do equipamento e informa o ACS das razões pela qual ele
pretende estabelecer sessão.
O CPE inicia comunicação com ACS em diversas situações tais como o momento em
que é ligado à rede após a sua instalação inicial; sempre que seja ligado ou reiniciado ou
mesmo quando ocorrem eventos que devam ser comunicados ao ACS (como por
exemplo quando o endereço IP do CPE é alterado). Além destas condições é ainda
definido no CPE um período de tempo no qual estabelece comunicação periódica com o
ACS sobre uma base de tempo contínua. Caso a mensagem de Inform se trate de uma
invocação periódica deste método, a mensagem SOAP deverá indicar na estrutura de
eventos a ocorrência do evento PERIODIC.
Este protocolo contém, no entanto, um mecanismo que permite estabelecimento
assíncrono de sessões. Cada CPE TR-069 possui um serviço HTTP suportando
autenticação do tipo digest no qual o ACS poderá actuar como cliente HTTP, podendo
assim informar o CPE de que se pretende comunicar com ele. Uma vez que o CPE
receba um pedido de conexão enviado pelo ACS, irá responder nos próximos 30
segundos com a invocação do método Inform, indicando a ocorrência do evento de
CONNECTION REQUEST.
Em cada caso, quando a comunicação é estabelecida o CPE identifica-se
21
exclusivamente através da informação de fabrico (serial number), de modo ao ACS
conhecer o CPE com quem se esta a comunicar e possa responder de forma correcta.
2.5.7 Modelo de Comunicação
A comunicação estabelecida pelo protocolo TR-069 corresponde a uma troca
bidireccional de pedidos e respostas RPC. Esta transacção é concluída quando ambos os
terminais não tem mais mensagens para enviar. O CPE é responsável por estabelecer e
terminar as sessões TR-069.
De modo a possibilitar uma troca sequencial de operações numa única sessão, o CPE
deverá manter a conexão TCP durante toda sessão.
A figura 4 contém um exemplo de uma transacção entre CPE e ACS e demonstra o
fluxo da comunicação e como a mesma ocorre em ambos os sentidos. Neste exemplo o
ACS invoca no CPE os métodos GetParameterValues e SetParameterValues, e recebe
do CPE as respostas das invocações desses métodos.
22
Figura 4 – Exemplo de uma transacção de mensagens numa sessão TR-069 [5].
•
•
•
•
•
•
A sessão inicia com o estabelecimento da conexão TCP.
Estabelecimento e activação de SSL e respectiva activação do mecanismo de
segurança.
Neste momento o CPE envia um POST HTTP invocando o método Inform para
inicializar a transacção de operações com o ACS.
O ACS responde com InformResponse, indicando ao CPE de que o Inform
enviado foi recebido com sucesso e que o CPE foi autenticado com sucesso.
No seguimento da chegada do InformResponse o CPE entrega ao ACS um
POST HTTP vazio indicando que a sessão foi estabelecida com sucesso e que
esta pronto a receber pedidos de invocação de métodos RPC.
Em resposta ao POST vazio, o ACS responde invocando no CPE uma operação,
sendo neste caso do exemplo apresentado na imagem, um GetParameterValues.
23
•
•
•
•
•
O CPE responde num novo POST com o GetParameterValuesResponse
retornando o resultado à invocação do referido método.
O ACS opta por invocar nova operação, desta feita um SetParameterValues.
O CPE retorna o resultado dessa operação no SetParameterValuesResponse.
O ACS envia uma mensagem vazia ao equipamento informando que não
pretende invocar mais operações.
O CPE termina sessão e de seguida irá iniciar uma conexão do tipo “standby”
podendo vir a ser aproveitada novamente pelo ACS assim que pretenda.
2.5.8 Métodos RPC
O CPE WAN Management Protocol, utiliza um mecanismo bidireccional de chamada
de procedimentos remotos (RPC) que permite que uma aplicação utilize serviços de
uma outra aplicação a correr numa maquina remota. A aplicação que invoca a execução
dos procedimentos envia mensagens contendo indicação do procedimento a executar e
os dados necessários para a execução remota do programa. Uma vez executados, os
respectivos resultados serão enviados à aplicação que fez a chamada dos procedimentos.
O equipamento CPE deverá suportar uma série de métodos RPC, que poderão ser
invocados pelo servidor de auto-configuração ACS, por outro lado o próprio CPE
poderá invocar chamadas de procedimentos no ACS.
Na tabela 2 estão listados os métodos requeridos e opcionais existentes em ambos os
lados, conforme é especificado na norma TR-069 [5].
24
Tabela 2 – Métodos TR-069 [5].
2.5.8.1 Métodos CPE
A invocação destes métodos será unicamente da responsabilidade do ACS. Contudo
existe a excepção do método de Reboot, no qual, o próprio equipamento poderá em
situações pontuais decidir iniciar a execução própria desse método.
Os seguintes métodos correspondem as principais operações que podem ser executadas
em equipamentos TR-069.
GetRPCMethods
Este método será utilizado para conhecer o conjunto de métodos suportados pelo CPE.
A invocação deste método não terá qualquer tipo de argumentos e a resposta a sua
invocação será uma lista dos nomes dos métodos que o CPE incorpora.
25
SetParameterValues
Este método deverá ser chamado pelo ACS de modo a modificar o valor de um ou mais
parâmetros do CPE. A invocação deste método necessita ter como parâmetros de
entrada uma lista de pares nome – valor, onde o nome corresponderá ao nome do
parâmetro e o valor será o valor que se pretende atribuir ao parâmetro. A resposta a
invocação deste método informa se todos os parâmetros foram validados e aplicados
com sucesso ou todos os parâmetros foram validados mas alguns ainda não aplicados.
GetParameterValues
Este método deverá ser chamado pelo ACS de modo a obter o valor de um ou mais
parâmetros do CPE. A invocação deste método necessita ter como parâmetros de
entrada uma lista com os nomes dos parâmetros que pretendemos conhecer. A resposta
a sua invocação será uma lista de pares nome – valor contendo o nome e o respectivo
valor do parâmetro.
GetParameterNames
Este método deverá ser chamado pelo ACS de modo a obter os parâmetros acessíveis
em determinado CPE. A invocação deste método necessita ter como parâmetros de
entrada um apontador e um booleano. O apontador apontará para um nó da hierarquia
de parâmetros, correspondendo assim ao directório completo de um parâmetro ou uma
parte parcial desse directório. Caso o apontador seja vazio o apontador fica a apontar
para o topo da hierarquia.
Caso o booleano seja falso, a resposta deverá conter todos os parâmetros cujo nome
contenha o apontador passado. Caso verdadeiro a resposta deverá conter somente os nós
filho do apontador passado.
A resposta além de conter a informação dos nomes dos parâmetros que se pretendem
visualizar, contem também a indicação se o parâmetro é só de leitura ou de leitura e
escrita.
Reboot
Este método provoca que o CPE se reinicie. A invocação deste método é mais destinada
a ser feita do lado do CPE do que ACS, visto ser rara a situação em que após uma
alteração da configuração do CPE, seja necessário efectuar um Reboot ao equipamento,
e quando isso acontece o próprio CPE deverá executar o seu próprio Reboot. Contudo
opcionalmente poderá também ser implementado do lado do ACS.
O uso do método no entanto é bastante simples, unicamente é usado um parâmetro
vazio na sua invocação, sendo a resposta também vazia.
26
Factory Reset
Este método repõe a configuração do equipamento no estado em que foi definido pelo
fabricante.
Download
Este método deverá ser usado pelo ACS para fazer com que o CPE inicie determinado
download a partir de um URL designado pelo ACS. Para a invocação deste método são
necessários bastantes mais parâmetros comparativamente aos outros métodos ate aqui
falados, fazendo dele, um dos métodos mais complexos do CWMP. De entre todos
esses parâmetros convêm salientar os mais importantes, tais como uma indicação do
tipo de download que pretendemos que o CPE efectue (Firmware Upgrade Image, Web
Content ou Vendor Configuration File). Uma indicação do URL onde se encontra
localizado o ficheiro. Dados de utilizador e palavra-chave, necessários para autenticação
no servidor onde se encontra o ficheiro (caso não seja necessária autenticação, estes
dados deverão ser vazios). Deverá ser ainda especificado o nome e tamanho do ficheiro
em bytes.
Em resposta à invocação deste método o CPE indica se o Download foi ou não
completado e aplicado com sucesso, o momento em que iniciou o download e o
momento em que terminou essa acção.
2.5.8.2 Métodos ACS
A invocação destes métodos será unicamente da responsabilidade dos CPE.
Os seguintes métodos correspondem as principais operações que podem ser invocadas
num ACS.
GetRPCMethods
Este método será utilizado para conhecer o conjunto de métodos suportados pelo ACS.
A invocação deste método não terá qualquer tipo de argumentos e a resposta a sua
invocação será uma lista dos nomes dos métodos que o ACS incorpora.
Inform
27
O CPE deverá chamar este método para iniciar a sequência de transacção sempre que
seja necessário estabelecer sessão com o ACS.
A mensagem de inform deverá conter diversa informação tal como: Identificação do
equipamento (Organizationally Unique Identifier, serial number, Manufacturer,
ProductClass), listagem dos eventos ocorridos no equipamento durante o período de
tempo compreendido entre o ultimo inform e este. A data e hora actual, e ainda alguma
informação de configuração do equipamento.
TransferComplete
O CPE invoca este método de forma a informar o ACS que foi concluída uma
transferência de um download ou upload anteriormente inicializado após a invocação do
método de Download ou Upload.
A mensagem de TransferComplete conterá no seu conteúdo, indicação de sucesso ou
falha de determina acção e respectivos instantes de início e finalização da acção.
2.5.9 Integração de TR-069 com UPnP
Dado o âmbito de aplicação da tecnologia UPnP ser meramente local, os equipamentos
que suportam UPnP mas não suportem TR-069, não poderão ser configurados
remotamente.
Um componente intermediário entre os protocolos TR-069 e UPnP permitirá ao ACS
descobrir, controlar e receber eventos de dispositivos UPnP, mesmo que o servidor se
encontre numa rede diferente.
Este componente intermédio actuara como proxy e terá como objectivo traduzir a
comunicação utilizada por ambos os protocolos, a sua localização será dentro da rede
local e terá conexão com o ACS [30].
A implementação de uma proxy deste tipo trata-se de uma componente de software
desenvolvida em linguagem de programação Java, daí o único requisito necessário neste
dispositivo ser a existência da instalação de uma máquina virtual Java.
A arquitectura geral desta proxy pode ser observada na figura 5.
28
Figura 5 – Integração de TR-069 com UPnP.
O desenvolvimento do protocolo TR-064
TR
(LAN-side CPE Configuration Specification)
é o grande responsável pela possibilidade de integração destas duas tecnologias [31].
O TR-064 trata-se
se de um complemento ao protocolo TR-069
TR
e assenta em
especificações UPnP. Este protocolo permite que um gateway TR-069
TR
consiga auto
configurar e gerir equipamentos na sua LAN, possibilitando assim que um ACS TR-069
TR
consiga alcançar e gerir remotamente equipamentos (TR-069
(TR 069 ou não TR-069)
TR
nas
nossas LAN.
O TR-064
064 é dividido em duas grandes componentes, a arquitectura do dispositivo
disposit
UPnP, na qual define como o software do dispositivo consegue descobrir e apreender
dinamicamente as capacidades de outros pontos UPnP e assim controla-los
controla
e configuralos [21].. E um modelo que anuncia as suas próprias capacidades e funções.
Dado o facto de TR--064
064 assentar em especificações UPnP, permite uma estrutura de
gestão comum a vários fabricantes de dispositivos,
dispositi
facilitando a taarefa aos ISP.
Os ISP têm geralmente optado por protocolos padrão para suporte e activação de
d
serviços em todos os seus CPE.
CP No entanto, as ferramentas annteriormente existentes
para este fim apresentavam lacunas e complexidade e nenhuma delas provou ser
robusta, segura, bem definida e extensível o suficiente.
A solução para encontrar uma tecnologia que permitisse aos ISP interagir com os
subscritores residenciais e capaz de contornar as limitações apresentadas anteriormente,
passou por uma combinação normalizada entre as redes WAN e LAN.
A referida combinação foi possível após o aparecimento dos protocolos TR-069
TR
e TR064.
Dados dos CPE podem ser usados e manipulados por ambos os protocolos (TR-069
(TR
e
TR-064),
064), permitindo uma gestão de ponto a ponto sem qualquer tipo de
descontinuidades.
Por exemplo, num serviço VoIP os dados de configuração podem ser descarregados
para o dispositivo
positivo através de um ACS TR-069
TR 069 no ISP, enquanto uma aplicação TR-064
T
existente no PC do utilizador é responsável pala subscrição do serviço.
Caso o utilizador registar algum
a
problema com o serviço, poderá facilmente executar
localmente uma aplicação
aplica
TR-064
064 de forma a diagnosticar e restaurar o dispositivo. Por
29
outro lado a aplicação de gestão TR-069 será utilizada para monitorar o desempenho e a
disponibilidade do serviço.
2.5.10 Extensões TR-069
A popularidade desta tecnologia e a sua larga difusão impulsionou o aparecimento das
recentes normas e de relatórios técnicos.
Esses novos mecanismos e aperfeiçoamentos têm sido adicionados ao protocolo,
permitido uma melhoria e flexibilidade do seu acesso a ambientes de gestão.
De entre as diversas melhorias e extensões, podemos focar três bastante importantes. A
primeira trata-se de permitir que um gateway residencial num ambiente multifornecedor não utilize unicamente o ACS pré configurado, mas seja capaz de auto
descobrir o ACS ao qual foi subscrito, logo no momento em que este seja ligado.
Outra importante melhoria foi a possibilidade de diagnóstico a partir da utilização do
comando PING, permitindo que um ACS consiga testar a sua conectividade a pedido do
dispositivo. Dado o dispositivo poder ser gerido por múltiplos provedores de serviço,
poderá ocorrer congestionamento de conexões, daí a utilidade do procedimento PING.
A última extensão ao protocolo, que aqui é relatada corresponde à habilitação de
configuração de equipamentos LAN TR-069. Este caso de utilização do protocolo é
descrito no relatório técnico TR-111 [2] e especifica esta implementação em duas
situações distintas. A situação em que o ACS se encontra conectado primeiramente a
uma NAT antes de chegar ao dispositivo e no caso em que o ACS se encontra
directamente conectado ao dispositivo.
A figura 6 apresenta um ambiente DSL completo, desde o operador remoto e ISP até a
rede local do cliente. Esquematiza onde as diferentes normas e extensões especificadas
pelo BroadBand Forum são aplicadas.
30
Figura 6 – Conjunto de extensões pertencentes ao âmbito de aplicação do CWMP [9].
O BroadBand Forum possui no seu site uma lista detalhada [6] de todas as extensões e
relatórios técnicos que têm sido desenvolvidos e adicionados ao funcionamento do
CWMP.
31
32
3
Concepção da API_TR069
Com o desenvolvimento deste trabalho, pretende-se criar uma solução capaz de gerir
equipamentos TR-069 e isolar as especificações do protocolo de outros sistemas ou
utilizadores que virão a utilizar esta ferramenta.
Neste capítulo é apresentada a análise teórica realizada antes da implementação da
respectiva API, de forma a antever as respectivas necessidades e precauções a ter
durante o seu desenvolvimento; a correcta forma de implementação; e o funcionamento
e resultado final.
A análise foi baseada na especificação dos seguintes tópicos:
•
•
•
•
Requisitos;
Use cases;
Arquitectura;
Diagramas.
33
3.1 Requisitos da API_TR069
Este módulo de gestão foi desenhado para satisfazer e apresentar os seguintes requisitos
e funcionalidades:
BroadBand Forum Compliant
•
API TR-069 que implemente os respectivos métodos obrigatórios e
procedimentos referenciados pela norma TR-069 do BroadBand Forum.
Comunicação entre ACS e CPE
•
•
•
•
•
•
Suportar sessões SSL/TLS de HTTPs ou HTTP.
Suportar autenticação Básica e Digest.
Suportar simultaneamente múltiplas sessões TR-069 com equipamentos
diferentes.
Aproveitar sessões já criadas para novos pedidos de configuração.
Ter capacidade para invocar todos os métodos cuja implementação é obrigatória
por parte do CPE.
Além destes métodos, implementar também: Reboot, FactoryReset e
GetRPCMethods.
Configuração
•
•
Capacidade de reconfiguração e instalação de novo firmware nos CPE.
Configuração de serviços.
Permitir Recolha de Informação (Configuração; Falhas e Desempenho):
Configuração
•
•
Capacidade de recolha de informação de configuração de CPE.
Entrega de informação para cadastro externo dos CPE.
Falhas
•
Detecção de notificações de falhas.
Desempenho
•
Recolha de informação de desempenho.
34
Comunicação Externa
•
•
•
Capacidade para pedir autenticação de CPE a uma plataforma externa de
Controlo de Acessos.
Capacidade de notificação de plataformas externas de gestão de falhas.
Capacidade de fornecer informação para Cadastro de CPE.
3.2 Use Cases
Para melhor entender a interacção desta aplicação de gestão com o utilizador, são
descritas quatro aplicações desta API de gestão:
•
•
•
•
Invocação do método de Reboot
Invocação de um Upgrade de firmware
Configuração de um serviço num CPE
Detecção de Falha de Energia
3.2.1 Reboot
- Utilizador pede a API uma entidade CPE passando o ID do CPE;
- Utilizador Invoca método Reboot;
- CPE envia ao ACS a resposta ao método de Reboot;
- Caso a API receba a resposta de Reboot com sucesso:
- Utilizador recebe resposta;
- Utilizador Invoca novas operações ou termina Sessão;
- Caso contrário:
- Utilizador recebe mensagem de erro;
- Sessão é terminada;
35
3.2.2 Upgrade de Firmware
- Utilizador pede a API um elemento CPE passando o ID do CPE;
- Utilizador Invoca o método Download com o respectivo URL da localização do
ficheiro;
- O CPE envia ao ACS a resposta ao método de Download;
- Caso o download tenha sido feito e aplicado com sucesso:
- Utilizador recebe resposta;
- Utilizador Invoca novas operações ou termina Sessão;
- Caso contrário:
- Utilizador recebe resposta;
- É esperado que nas próximas sessões o CPE indique a ocorrência do evento de
TransferComplete e que envie uma mensagem TransferComplete informando se
o download foi executado e aplicado com sucesso ou ocorreu algum erro durante
o download;
- Utilizador Invoca novas operações ou termina Sessão;
3.2.3 Configuração de um Serviço
- Utilizador pede a API uma entidade CPE passando o ID do CPE;
- Utilizador Invoca método SetParameterValues indicando as respectivas alterações que
pretende efectuar na configuração do CPE;
- CPE envia ao ACS a resposta ao método;
- Caso as alterações tenham sido feitas e aplicadas com sucesso:
- Utilizador é notificado da alteração dos parâmetros e respectiva activação do
serviço;
- Utilizador Invoca novas operações ou termina Sessão;
- Caso alterações executadas mas não aplicadas:
36
- Utilizador é notificado das alterações e da necessidade de invocar o método
Reboot;
- Utilizador invoca método Reboot;
- Utilizador Invoca novas operações ou termina Sessão;
3.2.4 Detecção de Falha de Energia
- Uma vez que o CPE reinicie, ele invocará automaticamente o método Inform:
- Verificada a ocorrência do evento BOOT;
- Utilizador é notificado da ocorrência deste evento.
37
3.3 Arquitectura
A figura 7 corresponde à arquitectura da API_TR069. Esta figura apresenta a
comunicação entre as suas componentes internas,
internas e as diferentes comunicações com os
seus actores externos.
Figura 7 – Arquitectura e componentes da API_TR069.
3.3.1 Actores Externos
H. N. (Home Network)
Rede doméstica do Cliente.
CONF
Plataforma externa responsável pela invocação de pedidos de configuração no nosso
sistema.
38
DIAG
Plataforma externa responsável pela invocação de pedidos de diagnóstico no nosso
sistema.
CAD
Plataforma externa que poderá ser acedida pelo nosso sistema com o intuito de lhe
oferecer informação relativa ao cadastro de equipamentos.
G. F. (Gestão de Falhas)
Plataforma externa que poderá ser acedida pelo nosso sistema com o intuito de lhe
oferecer informação da ocorrência de falhas.
DES
Plataforma externa que poderá ser acedida pelo nosso sistema com o intuito de lhe
oferecer informação de desempenho.
C. A. (Controlo de Acesso)
Plataforma externa cujo nosso sistema recorrerá para resolver questões de Autenticação.
3.3.2 Componentes Internas
CPE Layer
Componente que irá atender os diferentes pedidos externos. A cada um destes pedidos,
irá criar uma nova entidade que permitirá comunicação TR-069 entre o nosso ACS e o
respectivo CPE.
Para que o CPE Layer consiga criar esta entidade é necessária informação de
identificação do CPE e uma sessão activa com este CPE.
39
A informação de identificação do CPE será passada pelo próprio utilizador externo,
enquanto a sessão será pedida à componente Session Manager, que se encarregará de a
criar e entregar ao nosso CPE Layer para que possa criar a referida entidade (fig. 7).
Esta camada tem como responsabilidade representar os equipamentos home gateway
perante o utilizador da API. Para cada sessão criada, será instanciada uma classe que
representará o equipamento. Através dessa classe o utilizador poderá invocar os
métodos TR-069.
Session Manager
Bloco responsável pela gestão do ciclo de vida das sessões.
Ele conterá o registo dos diferentes pedidos de sessão e de todas as sessões activas.
O Session Manager recorrerá a componente Connection Request para a criação da
referida sessão.
Além de criar sessões, este bloco também tem a capacidade de as terminar.
Connection Request
Bloco responsável por enviar pedidos de conexão aos respectivos CPE, actuando como
cliente HTTP.
A recepção de cada pedido de conexão no CPE provocará o envio de uma mensagem
TR-069 de retorno ao nosso ACS. Esta mensagem permitirá estabelecer uma sessão TR069 entre ele e o ACS.
Connection Manager
Este bloco detecta a chegada de todas as mensagens TR-069 direccionadas ao nosso
ACS.
O Connection Manager terá as funções de recorrer ao Session Manager a fim de
verificar se existe interesse nesta conexão ou passar ao ACS Layer a respectiva
mensagem caso ela se trate da invocação de um método ACS.
ACS Layer
Esta componente tem a função de processar as mensagens que correspondem a
invocações de métodos ACS, executar esses métodos e enviar a respectiva mensagem
de resposta, podendo vir a comunicar com sistemas externos.
40
3.4 Diagramas
Os seguintes diagramas de classes e de sequência foram criados com a ferramenta de
software gratuita JUDE/Community [20], utilizando a linguagem UML [43].
3.4.1 Diagrama de Classes
Os diagramas de classe facilitam a compreensão e elaboração da estrutura interna do
projecto. Neste diagrama são identificadas todas as classes e blocos que o sistema
necessita possuir e mostra a dependência e associação entre classes e como elas irão
comunicar entre si.
O correcto esboço de um diagrama de classes, além de facilitar a análise do
funcionamento do sistema, é também importante para que esse mesmo sistema seja
construído correcta e eficazmente. De seguida irá ser explicado passo a passo a
elaboração deste diagrama.
Analisando o sistema que pretendemos desenvolver, partimos do princípio que
necessitamos de um bloco responsável por criar entidades CPE, ele será denominado
por CPE FACTORY.
Assim sendo começaremos o nosso diagrama por este mesmo bloco (fig. 8).
Figura 8 – Diagrama de Classes da API_TR069.
41
Para o bloco CPE FACTORY conseguir criar a respectiva entidade CPE, necessitará
informação de identificação do equipamento e de uma sessão TR-069. Essa informação
de identificação será dada pela própria plataforma que está a utilizar esta API, no
entanto a sessão ser-lhe-á retornada mais tarde pelo bloco SESSION MANAGER.
Como se pode ver na figura 8, o CPE FACTORY estará associado a um bloco gestor de
sessões (SESSION MANAGER) no qual ele registará o pedido para obter uma sessão
com determinado equipamento. O SESSION MANAGER terá de ser capaz de agregar
múltiplas sessões e geri-las conforme as necessidades dos diferentes pedidos de
configuração e diagnóstico.
Este bloco não só terá conhecimento dos pedidos de sessão, mas também das sessões
que se encontram activas.
Os CPE TR-069 incorporam um servidor HTTP no qual poderá ser utilizado para
informar o respectivo CPE de que este ACS se pretende comunicar. Este serviço
encontra-se permanentemente à escuta e para se conseguir aceder é necessária a devida
autenticação.
Como se pode observar na figura 8, o SESSION MANAGER estará também associado
a um bloco responsável por enviar pedidos de conexão aos CPE que é o REQUEST
CLIENT e funcionará como um cliente HTTP.
Assim que seja registado no SESSION MANEGER o interesse de sessão com
determinado equipamento, será passado ao REQUEST CLIENT a informação
necessária para que o nosso sistema possa informar o respectivo CPE da necessidade de
se comunicar com ele.
A este pedido HTTP enviado pelo REQUEST CLIENT, o equipamento deverá
responder com uma outra mensagem que permitirá estabelecer uma sessão TR-069 entre
ele e o nosso ACS.
Necessitamos assim de um bloco que funcione como servidor HTTP, e que processe as
mensagens que cheguem. Esse bloco é o CONNECTION MANAGER e a ele
encontram-se associados os blocos ACS e SESSION MANAGER.
O bloco ACS (fig. 8) é o bloco que incorpora as operações TR-069 que podem ser
invocadas no nosso ACS pelos CPE.
Caso o pedido HTTP corresponda a uma invocação de um método do ACS, o
CONNECTION MANAGER recorre ao ACS para processar a respectiva operação e
criar/enviar a mensagem de resposta.
De seguida o CONNECTION MANAGER recorre ao SESSION MANAGER
informando que existe conexão com determinado equipamento.
42
Com esta informação o bloco SESSION MANAGER decide criar uma sessão, que
corresponde ao bloco SESSION (fig. 8) que simboliza uma sessão activa com
determinado equipamento.
Toda a comunicação entre CPE e ACS passará pelo bloco CONNECTION
MANAGER e por sua vez será entregue ao SESSION MANAGER que saberá
encaminhar essa informação à respectiva sessão.
Finalmente este diagrama fica concluído quando esta sessão que foi criada é retornada
ao bloco CPE FACTORY que a utilizará para criar o elemento CPE (fig. 8).
Este CPE incorpora as operações que poderão ser executadas no equipamento através do
protocolo de gestão remota TR-069.
Neste momento quem estiver a utilizar a API tem reunidas as condições necessárias
para gerir o respectivo equipamento remotamente.
Como podemos observar na figura 8, o bloco com maior número de associações é o
SESSION MANAGER, tratando-se assim um dos blocos mais complexos de toda a
API, sendo responsável pelas seguintes funções:
- Conhecer todos os pedidos de sessão;
- Conhecer todas as sessões activas;
- Passar pedidos ao REQUEST CLIENT;
- Criar sessões;
- Entregar as sessões criadas às respectivas entidades que realizaram os pedidos;
- Entregar mensagens de resposta às respectivas sessões;
- Terminar sessões.
3.4.2 Diagramas de Sequência
Pretende-se com os seguintes diagramas facilitar a compreensão do funcionamento e da
comunicação interna e externa do sistema. O primeiro diagrama ilustra o funcionamento
genérico da aplicação. Este diagrama corresponde ao caso de utilização da invocação do
método de Reboot sendo o diagrama semelhante para a invocação das restantes
operações TR-069.
Num segundo diagrama é apresentado o caso de utilização em que o utilizador da API
pretende executar um Download de firmware. Neste caso, como iremos observar no
43
respectivo diagrama, após a invocação desta operação além da resposta ao método de
Download o CPE envia uma mensagem de TransferComplete.
O último diagrama apresenta uma situação em que é detectada a chegada de uma
mensagem de inform (mensagem utilizada para o estabelecimento de sessões TR-069)
que não foi requerida. Esta situação é importante, dado que os CPE TR-069 poderem
enviar este tipo de mensagens em diversas situações.
3.4.2.1 Reboot
Figura 9 – Diagrama de Sequência referente a invocação do método de Reboot.
44
Este diagrama (fig. 9) corresponde a uma situação em que o utilizador da API pretende
invocar a operação de Reboot em determinado CPE. Este diagrama ilustra de forma
pormenorizada como a API reage a invocação da operação e chegada da respectiva
resposta.
Nesta situação são utilizados todos os blocos referidos no diagrama de classes, e segue a
seguinte sequência:
1 O CPE FACTORY recebe um pedido para criação de uma entidade CPE.
1.1 O CPE FACTORY pede uma sessão ao SESSION MANAGER.
1.1.1 O SESSION MANAGER procura pedidos de sessões.
1.1.2 O pedido é passado ao REQUEST CLIENT.
1.1.2.1 O REQUEST CLIENT pede ao equipamento para estabelecer conexão.
1.1.2.1.1 O equipamento envia mensagem Inform para estabelecer conexão.
1.1.2.1.1.1 O CONNECTION MANAGER recorre a entidade ACS para processar a
mensagem de Inform.
1.1.2.1.1.1.1 O ACS verifica de conhece o CPE através de uma plataforma externa de
controlo e acesso CA.
1.1.2.1.1.1.2 O ACS regista informação do CPE numa plataforma externa de Cadastro.
1.1.2.1.1.1.3 O ACS regista na plataforma externa Event Manager os eventos ocorridos
no CPE.
1.1.2.1.1.1.4 O ACS envia ao CPE a resposta a este Inform.
1.1.2.1.2 CPE envia POST vazio.
1.1.2.1.2.1 O CONNECTION MANAGER informa o SESSION MANAGER da
chegada de um POST vazio.
1.1.3 O SESSION MANAGER verifica a existência de pedido de sessão para este CPE.
1.1.4 O SESSION MANAGER cria uma sessão e retorna-a ao CPE FACTORY.
1.2 O CPE FACTORY cria uma entidade CPE.
1.3 O CPE FACTORY atribui à entidade CPE criada a sessão que lhe foi retornada pelo
SESSION MANAGER.
2 O utilizador invoca na entidade CPE a operação de Reboot.
2.1 A entidade CPE passa a mensagem de Reboot à sessão SESSION.
45
2.1.1 A sessão SESSION envia essa mensagem ao equipamento, de forma a invocar a
operação de Reboot no equipamento.
2.1.1.1 O CPE responde com uma mensagem de RebootResponse.
2.1.1.1.1 O CONNECTION MANAGER recebe esta mensagem e passa-a ao SESSION
MANAGER.
2.1.1.1.1.1 O SESSION MANAGER verifica se existe sessão activa com este
equipamento que enviou a mensagem.
2.1.1.1.1.2 O SESSION MANAGER entrega a resposta a sessão SESSION e o
utilizador é notificado do resultado da operação, podendo assim executar mais
operações caso pretenda.
3 O utilizador informa que não pretende executar mais operações no CPE.
3.1 O SESSION MANAGER é informado da necessidade de terminar determinada
sessão.
3.1.1 O SESSION MANAGER verifica se existe algum pedido para esta sessão.
3.1.2 O SESSION MANAGER elimina o registo desta sessão como activa e informa a
sessão SESSION que ela deverá terminar.
3.1.2.1 A sessão SESSION envia uma mensagem vazia ao equipamento.
3.1.2.1.1 O equipamento responde com uma mensagem vazia.
3.1.2.1.1.1 O CONNECTION MANAGER informa o SESSION MANAGER da
chegada de uma mensagem vazia vinda de determinado equipamento.
3.1.3 O SESSION MANAGER verifica a existência de pedido para sessão com este
equipamento.
3.1.4 Visto não existir pedido de sessão, o SESSION MANAGER informa a sessão
SESSION que ela deverá ser completamente terminada.
3.1.4 Sessão SESSION envia uma segunda mensagem vazia ao CPE e é terminada a
sessão TR-069.
46
3.4.2.2 Download de Firmware
Figura 10 – Diagrama de Sequência referente a invocação do método de Download.
Como se pode observar na figura 10, este diagrama mantêm-se bastante idêntico ao
diagrama anterior, a única diferença é o facto que após terminada a sessão, o CPE
inicializará o download da respectiva imagem de software.
Após ter iniciado o download e após um determinado período de tempo o CPE invocará
no nosso ACS o método de TransferComplete indicando o estado da operação de
download.
47
3.4.2.3 Inform não Requisitado
Figura 11 – Diagrama de Sequência de um Inform não Requisitado.
Este diagrama (fig. 11) demonstra como o sistema reage à chegada de um Inform que
não corresponde a um pedido de conexão realizado pelo Client Request. Este exemplo
pode por exemplo corresponder a um Inform periódico.
Uma vez chegado o Inform, este é atendido da mesma forma como qualquer outro.
Dado não existir registo de pedido para esta conexão no SESSION MANAGER, ele
próprio encarrega-se de terminar essa conexão.
Entretanto quando chegar este Inform, caso exista registo de um pedido de sessão para
este CPE, ele será aproveitado para a criação de uma sessão.
48
4
Implementação da API_TR069
De seguida irá ser descrita a metodologia adoptada na implementação de cada um dos
blocos identificados anteriormente, bem como as funcionalidades do sistema
desenvolvido. No documento anexo javadocs, pode ser analisada ao pormenor toda a
estrutura do projecto desenvolvido.
4.1 CPE_Entity
A entidade CPE é constituída por uma única classe que incorpora os métodos referentes
as diferentes operações TR-069 que podem ser invocadas nos CPE pela API_TR069. As
mensagens SOAP das operações são aqui criadas em formato XML e entregues à
respectiva sessão que se encarregará de as enviar ao respectivo equipamento. Em
retorno ao envio desta mensagem é recebida uma outra mensagem SOAP que
corresponde a resposta de execução desta operação no CPE. Dessa resposta é extraída a
informação relevante e entregue a quem esta a utilizar esta API.
49
4.2 CPE Factory
Este bloco como o seu próprio nome indica, é responsável por criar entidades CPE e
passa-las a quem as requisitou. É constituído também por uma única classe singleton (só
existirá uma instancia deste objecto) que incorpora o método getCpeInstance(), que tem
como função registar o pedido de sessão no Session Manager e espera até que lhe seja
entregue a respectiva sessão. De seguida cria uma nova entidade CPE e entrega-a a
quem a pediu.
4.3 Session Manager
Este bloco é considerado um dos mais complexos de toda a API_TR069. Como já foi
dito anteriormente, terá de ser capaz de registar e eliminar os diferentes pedidos de
sessões; criar/terminar sessões; entregar sessões; passar à respectiva sessão as
mensagens de resposta aos métodos invocados por ela; e eliminar o registo de sessões
activas.
Além da classe Session Manager, este bloco é constituído pelas classes Session
Manager Worker e Handle Connection Request.
A classe Session Manager é singleton e incorpora uma série de métodos como se pode
verificar no documento de anexo - java docs. De entre todos estes métodos, o método
responsável por desencadear o funcionamento base da API_TR069 é o getSession().
Este método regista o pedido de sessão para determinado CPE numa lista de pedidos.
Sempre que chega um novo elemento à fila de sessões criadas, é verificado se o pedido
criado anteriormente corresponde à sessão criada. Caso essa relação seja verdadeira,
essa sessão é removida da lista de sessões criadas e é entregue a entidade que a pediu.
O Session Manager Worker corresponde a uma Thread que é arrancada quando o
Session Manager é instanciado. Esta Thread tem como objectivo detectar a chegada de
novos pedidos de sessão à lista de pedidos e atende-los separadamente.
Dado o processo de criação de sessões ser bastante lento, esta criação é feita por threads
independentes. Para cada pedido de sessão distinto é lançada uma nova thread pelo
Session Manager Worker para a criação dessa sessão. Essas Threads são as Handle
Connection Request e recorrem ao Request Client para enviar os pedidos de sessão aos
CPE, morrendo de seguida.
50
4.4 Request Client
Como o nome indica, este bloco funciona como um cliente que envia pedidos. É
constituído pela classe Request Client e incorpora o método sendRequest(). Este método
tem a função enviar um pedido HTTP (GET) a um determinado CPE utilizando
autenticação do tipo digest. Este pedido será direccionado para um URL configurado
previamente no CPE para receber pedidos de conexão. Em resposta à chegada deste
pedido de conexão, o CPE enviará um POST HTTP contendo uma mensagem SOAP
com o método de Inform usado para estabelecer sessões TR-069.
Para a criação deste cliente HTTP foi utilizada a API commons-httpclient.jar da apache
que incorpora uma série de funcionalidades direccionadas a implementação de clientes
HTTP.
4.5 Connection Manager
Este bloco é constituído por duas classes, Connection Manager e a Handle Request.
A classe Connection Manager implementa um servidor HTTP que se encontra à escuta
de pedidos.
Para a implementação deste servidor foi aproveitado o facto da versão 6 do JDK da Sun
já possuir uma classe HttpServer fácil de utilizar e implementar, não sendo necessário
utilizar uma API externa.
Para cada pedido que chegue a este servidor, é lançado o método handle(HttpExchange)
com um pacote de dados que permite comunicação HTTP com a entidade que efectuou
o pedido.
Esta classe é do tipo singleton e é lançada assim que a API_TR069 seja iniciada.
Dado poderem chegar múltiplos pedidos HTTP simultaneamente, e para não
sobrecarregar a Thread que se encontra a correr este serviço HTTP, optou-se por lançar
uma Thread distinta (Handle Request) para processar separadamente cada um destes
pedidos HTTP.
Esta Thread Handle Request é lançada dentro do método handle(HttpExchange) do
Connection Manager e tem como objectivo processar estes pedidos.
Os pedidos enviados pelos CPE podem ser de três tipos:
•
Post referente a invocação de um método ACS.
51
•
•
Post vazio.
Post desconhecido.
Caso o pedido se trate de uma invocação de um dos métodos ACS, esta Thread irá
recorrer ao ACS_Entity, onde irá executar o respectivo método e enviar a respectiva
mensagem de resposta ao CPE.
Caso se trate de um POST vazio, o Handle Request informará o Session Manager da
chegada deste POST e ai o Session Manager saberá qual o propósito da chegada desse
POST.
Caso se trate de um pedido desconhecido, é lançada uma excepção e uma mensagem de
ERRO.
4.6 ACS_Entity
A entidade ACS é constituída por uma única classe que incorpora os métodos referentes
às diferentes operações TR-069 que os CPE podem invocar no nosso ACS.
Além de executar essas operações, o ACS_Entity também tem as tarefas de criar e
enviar as respectivas mensagens SOAP de resposta em formato XML.
4.7 Interfaces Externas
Além destes blocos principais da API_TR069, também foram definidas três interfaces e
respectivas classes que permitirão à API comunicar para o exterior. São elas CA, Event
Manager e Cadastro.
A interface CA permite que a API_TR069, recorra a um serviço de controlo de acessos
externo para garantir a autenticação dos CPE no ACS.
A API_TR069 entrega informação de identificação do CPE ao CA e recebe uma
notificação acerca deste CPE.
A API_TR069 entregará ao Event Manager estruturas de eventos ocorridos nos
respectivos CPE. O objectivo do Event Manager é conter o registo dos eventos relativos
aos CPE pertencentes ao domínio de gestão.
52
Outro sistema externo que a API_TR069 poderá recorrer, será o de Cadastro. Este
sistema reunirá informação acerca dos clientes que se comunicam com este sistema.
A API_TR069 entrega ao Cadastro diversas informações dos CPE, tais como:
Fabricante; OUI (identificador único); tipo de CPE; Serial Number.
Estas três interfaces recebem da API_TR069 os dados necessários para que elas possam
vir a ser usadas caso seja pretendido.
53
54
5
Testes
Neste capítulo são apresentados os relatórios que resultaram de algumas situações de
teste realizadas. Estes testes serviram não só para verificar o correcto funcionamento da
API, detecção de bugs e falhas no sistema, mas também para provar que a API_TR069
suporta os requisitos que foram definidos durante a sua concepção.
Para isso, foi criado um ambiente de testes TR-069, onde o nosso ACS actuou como
entidade gestora de dois CPE.
Foram também criadas e adicionadas três novas classes java ao projecto, permitindo
assim efectuar os respectivos testes.
Classes pertencentes ao ambiente de testes:
ClassPrincipal – Classe responsável por iniciar o sistema de log, iniciar o serviço
HTTP do ConnectionManager e permitir que o utilizador desta API introduza a
identificação dos CPE que pretende gerir. De seguida é lançado um Thread (Utilizador)
para cada pedido de configuração, simulando assim diferentes pedidos de sessão
efectuados por diferentes entidades.
Utilizador – Thread que pede uma nova entidade CPE ao CPE Factory, para com ela
poder invocar os métodos TR-069 no CPE.
Menu – Esta classe é responsável por entregar ao utilizador da API um menu de
operações TR-069, permitindo assim uma fácil interacção entre o utilizador e a
API_TR069.
55
Estes relatórios de teste, correspondem aos relatórios de mensagens de logs geradas pela
própria API_TR069, no entanto, dado estes relatórios serem bastante extensos, optou-se
por apresentar filtros dos relatórios originais.
Os relatórios originais destes relatórios aqui apresentados poderão ser consultados no
documento anexo “AnexoRelatóriosDeTeste”.
Como poderá ser verificado nos relatórios originais o procedimentos de criação e
entrega de sessões, e os de pedidos e entrega das entidades CPE mantêm-se sempre
iguais independentemente das operações que se pretendam efectuar. Logo no primeiro
teste (Reboot) será explicado detalhadamente o funcionamento integral da API, ao
contrário dos testes seguintes que terão uma análise mais simplificada.
De seguida são apresentados relatórios referentes a cinco situações de teste distintas.
5.1 Reboot
0 INFO [2009-08-19 14:45:34,028:main] tr069.testes.ClassPrincipal - Sistema de logs iniciado!!!
5 INFO [2009-08-19 14:45:34,033:main] tr069.testes.ClassPrincipal - ********************
7 INFO [2009-08-19 14:45:34,035:main] tr069.testes.ClassPrincipal - *
*
9 INFO [2009-08-19 14:45:34,037:main] tr069.testes.ClassPrincipal - *
*
10 INFO [2009-08-19 14:45:34,038:main] tr069.testes.ClassPrincipal - * Modulo Gestao
*
12 INFO [2009-08-19 14:45:34,040:main] tr069.testes.ClassPrincipal - *
*
14 INFO [2009-08-19 14:45:34,042:main] tr069.testes.ClassPrincipal - *
TR069
*
16 INFO [2009-08-19 14:45:34,044:main] tr069.testes.ClassPrincipal - *
*
18 INFO [2009-08-19 14:45:34,046:main] tr069.testes.ClassPrincipal - *
*
20 INFO [2009-08-19 14:45:34,048:main] tr069.testes.ClassPrincipal - *
*
22 INFO [2009-08-19 14:45:34,050:main] tr069.testes.ClassPrincipal - *
V1.0 *
24 INFO [2009-08-19 14:45:34,052:main] tr069.testes.ClassPrincipal - ********************
35 INFO [2009-08-19 14:45:34,063:main] tr069.api_tr069.ConnectionManager - Start Connection
Manager
153 INFO [2009-08-19 14:45:34,181:main] tr069.testes.ClassPrincipal - Menu Principal
155 INFO [2009-08-19 14:45:34,183:main] tr069.testes.ClassPrincipal - 1 - Get CPE
157 INFO [2009-08-19 14:45:34,185:main] tr069.testes.ClassPrincipal - 2 - Configurar CPEs
160 INFO [2009-08-19 14:45:34,188:main] tr069.testes.ClassPrincipal - 0 - Sair
162 INFO [2009-08-19 14:45:34,190:main] tr069.testes.ClassPrincipal 1200 INFO [2009-08-19 14:45:35,228:main] tr069.testes.ClassPrincipal - 1
1202 INFO [2009-08-19 14:45:35,230:main] tr069.testes.ClassPrincipal - Escolha o Id do CPE TR069
que pretende configurar
1203 INFO [2009-08-19 14:45:35,231:main] tr069.testes.ClassPrincipal - 1 - 192.168.125.78
1204 INFO [2009-08-19 14:45:35,232:main] tr069.testes.ClassPrincipal - 2 - 192.168.125.80
1205 INFO [2009-08-19 14:45:35,233:main] tr069.testes.ClassPrincipal 1957 INFO [2009-08-19 14:45:35,985:main] tr069.testes.ClassPrincipal - 1
1957 INFO [2009-08-19 14:45:35,985:main] tr069.testes.ClassPrincipal - Menu Principal
1958 INFO [2009-08-19 14:45:35,986:main] tr069.testes.ClassPrincipal - 1 - Get CPE
1958 INFO [2009-08-19 14:45:35,986:main] tr069.testes.ClassPrincipal - 2 - Configurar CPEs
1958 INFO [2009-08-19 14:45:35,986:main] tr069.testes.ClassPrincipal - 0 - Sair
1959 INFO [2009-08-19 14:45:35,987:main] tr069.testes.ClassPrincipal 2827 INFO [2009-08-19 14:45:36,855:main] tr069.testes.ClassPrincipal - 2
6958 INFO [2009-08-19 14:45:40,986:Thread-3] tr069.testes.Utilizador - Start new utilizador
6962 INFO [2009-08-19 14:45:40,990:Thread-3] tr069.api_tr069.CpeFactory - Start CpeFactory
6964 INFO [2009-08-19 14:45:40,992:Thread-3] tr069.api_tr069.CpeFactory - Entrou no Cpe Factory
7020 INFO [2009-08-19 14:45:41,048:Thread-3] tr069.api_tr069.SessionManager - Start Session Manager
7027 INFO [2009-08-19 14:45:41,055:Thread-3] tr069.api_tr069.SessionManager - Registou pedido de
Sessao para o CPE com IP: 192.168.125.78
7079 INFO [2009-08-19 14:45:41,107:Thread-4] tr069.api_tr069.SessionManagerWorker - Start Session
Manager Worker
8096 INFO [2009-08-19 14:45:42,124:Thread-5] tr069.api_tr069.HandleConnectionRequest - Entrou no
Handler Connection Request
8097 DEBUG [2009-08-19 14:45:42,125:Thread-5] tr069.api_tr069.HandleConnectionRequest - Vai atender
pedido:::192.168.125.78
8120 INFO [2009-08-19 14:45:42,148:Thread-5] tr069.api_tr069.RequestClient - Entrou no
RequestClient
9568 DEBUG [2009-08-19 14:45:43,596:Thread-5] commons.httpclient.HttpConnection - Open connection to
192.168.125.78:51005
9987 INFO [2009-08-19 14:45:44,015:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
56
9997 INFO [2009-08-19 14:45:44,025:Thread-7] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
10012 INFO [2009-08-19 14:45:44,040:Thread-5] tr069.api_tr069.HandleConnectionRequest - Morreu
HandleConnectionRequest
15340 INFO [2009-08-19 14:45:49,368:Thread-7] tr069.api_tr069.HandleRequest - Chegou Inform vindo
de: 192.168.125.78
15349 INFO [2009-08-19 14:45:49,377:Thread-7] tr069.api_tr069.CA - CPE conhecido
15353 INFO [2009-08-19 14:45:49,381:Thread-7] tr069.api_tr069.Cadastro - Manufacturer: THOMSON
15354 INFO [2009-08-19 14:45:49,382:Thread-7] tr069.api_tr069.Cadastro - OUI: 00147F
15356 INFO [2009-08-19 14:45:49,384:Thread-7] tr069.api_tr069.Cadastro - ProductClass: SpeedTouch
780
15357 INFO [2009-08-19 14:45:49,385:Thread-7] tr069.api_tr069.Cadastro - SerialNumber: CP0610JT7YB
15370 INFO [2009-08-19 14:45:49,398:Thread-7] tr069.api_tr069.EventManager - EVENTO: CONNECTION
REQUEST, A sessao foi estabelcida apos um pedido realizado pelo ACS
15372 INFO [2009-08-19 14:45:49,400:Thread-7] tr069.api_tr069.ACS_Entity - Vai enviar InformResponse
15527 INFO [2009-08-19 14:45:49,555:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
15530 INFO [2009-08-19 14:45:49,558:Thread-8] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
15532 INFO [2009-08-19 14:45:49,560:Thread-8] tr069.api_tr069.HandleRequest - Chegou Post Vazio
vindo de: 192.168.125.78
15536 INFO [2009-08-19 14:45:49,564:Thread-8] tr069.api_tr069.SessionManager - Existe Pedido de
Sessao para o CPE com o IP: 192.168.125.78
15538 INFO [2009-08-19 14:45:49,566:Thread-8] tr069.api_tr069.SessionManager - Vai ser criada uma
Sessao TR069 com o CPE com o IP: 192.168.125.78
15608 INFO [2009-08-19 14:45:49,636:Thread-3] tr069.api_tr069.CpeFactory - Sessao
recebida:192.168.125.78
15613 INFO [2009-08-19 14:45:49,641:Thread-3] tr069.api_tr069.CPE_Entity - Foi criada uma nova
entidade CPE
15615 INFO [2009-08-19 14:45:49,643:Thread-3] tr069.api_tr069.CpeFactory - Criou Entidade CPE com a
respectiva Sessao TR069 com o host 192.168.125.78
15617 INFO [2009-08-19 14:45:49,645:Thread-3] tr069.api_tr069.CpeFactory - Entregou Entidade CPE ao
utilizador da API
15620 INFO [2009-08-19 14:45:49,648:Thread-3] tr069.testes.MenuTR069 15621 INFO [2009-08-19 14:45:49,649:Thread-3] tr069.testes.MenuTR069 - Menu Operacoes TR069
15622 INFO [2009-08-19 14:45:49,650:Thread-3] tr069.testes.MenuTR069 - 1 - Set Parameter Values
15624 INFO [2009-08-19 14:45:49,652:Thread-3] tr069.testes.MenuTR069 - 2 - Get Parameter Values
15626 INFO [2009-08-19 14:45:49,654:Thread-3] tr069.testes.MenuTR069 - 3 - Get Parameter Names
15627 INFO [2009-08-19 14:45:49,655:Thread-3] tr069.testes.MenuTR069 - 4 - Reboot
15628 INFO [2009-08-19 14:45:49,656:Thread-3] tr069.testes.MenuTR069 - 5 - Download
15629 INFO [2009-08-19 14:45:49,657:Thread-3] tr069.testes.MenuTR069 - 6 - Factory Reset
15631 INFO [2009-08-19 14:45:49,659:Thread-3] tr069.testes.MenuTR069 - 7 - GetRPCMethods
15632 INFO [2009-08-19 14:45:49,660:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
15633 INFO [2009-08-19 14:45:49,661:Thread-3] tr069.testes.MenuTR069 18887 INFO [2009-08-19 14:45:52,915:Thread-3] tr069.testes.MenuTR069 - 4
18889 INFO [2009-08-19 14:45:52,917:Thread-3] tr069.testes.MenuTR069 - Operacao Reboot
18943 INFO [2009-08-19 14:45:52,971:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
18945 INFO [2009-08-19 14:45:52,973:Thread-9] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
18959 INFO [2009-08-19 14:45:52,987:Thread-9] tr069.api_tr069.HandleRequest - Chegou RebootResponse
vindo de: 192.168.125.78
18964 DEBUG [2009-08-19 14:45:52,992:Thread-3] tr069.api_tr069.CPE_Entity - Reboot Executado com
Sucesso
18970 INFO [2009-08-19 14:45:52,998:Thread-3] tr069.testes.MenuTR069 18971 INFO [2009-08-19 14:45:52,999:Thread-3] tr069.testes.MenuTR069 18973 INFO [2009-08-19 14:45:53,001:Thread-3] tr069.testes.MenuTR069 - Menu Operacoes TR069
18974 INFO [2009-08-19 14:45:53,002:Thread-3] tr069.testes.MenuTR069 - 1 - Set Parameter Values
18974 INFO [2009-08-19 14:45:53,002:Thread-3] tr069.testes.MenuTR069 - 2 - Get Parameter Values
18975 INFO [2009-08-19 14:45:53,003:Thread-3] tr069.testes.MenuTR069 - 3 - Get Parameter Names
18976 INFO [2009-08-19 14:45:53,004:Thread-3] tr069.testes.MenuTR069 - 4 - Reboot
18976 INFO [2009-08-19 14:45:53,004:Thread-3] tr069.testes.MenuTR069 - 5 - Download
18977 INFO [2009-08-19 14:45:53,005:Thread-3] tr069.testes.MenuTR069 - 6 - Factory Reset
18978 INFO [2009-08-19 14:45:53,006:Thread-3] tr069.testes.MenuTR069 - 7 - GetRPCMethods
18978 INFO [2009-08-19 14:45:53,006:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
18979 INFO [2009-08-19 14:45:53,007:Thread-3] tr069.testes.MenuTR069 20526 INFO [2009-08-19 14:45:54,554:Thread-3] tr069.testes.MenuTR069 - 0
20527 INFO [2009-08-19 14:45:54,555:Thread-3] tr069.testes.MenuTR069 - Terminar Sessao
20531 DEBUG [2009-08-19 14:45:54,559:Thread-3] tr069.api_tr069.SessionManager - Removeu pedido
20531 INFO [2009-08-19 14:45:54,559:Thread-3] tr069.api_tr069.SessionManager - Existem 0 Pedidos
para atender
20534 INFO [2009-08-19 14:45:54,562:Thread-3] tr069.api_tr069.SessionManager - Sessao foi Terminada
Este teste serviu para testar o correcto funcionamento do método de Reboot.
Como se pode observar no relatório, para testar a API_TR069 começamos por indicar
na Thread de testes ClassPrincipal (main) que se pretende configurar o CPE com o IP
192.168.125.78, sendo lançada uma outra Thread de testes Thread Utilizador (Thread 3)
que pede ao CPE Factory uma entidade CPE. O Cpe Factory encarrega-se por registar
um novo pedido para uma sessão TR069 no SessionManager e aguarda que ela lhe seja
entregue para que possa criar e devolver a entidade CPE ao Utilizador.
57
O SessionManagerWorker (Thread 4) detecta o pedido para uma nova sessão e lança
uma nova thread (Thread 5) para que o RequestClient envie o pedido de conexão ao
respectivo equipamento.
O CPE responde com um POST HTTP contendo a mensagem de Inform, que é recebida
pelo ConnectionManager. A Thread ConnectionManager (Thread 2) detecta a chegada
do novo POST e lança uma Thread HandleRequest (Thread 7) para atender e processar
esse mesmo POST.
Este HandleRequest (Thread 7) recorre a entidade CA a fim de determinar se conhece o
CPE, regista informação de identificação e eventos no Cadastro e EventManager
respectivamente. De seguida envia ao CPE a respectiva mensagem de InformResponse e
morre.
O ConnectionManager (Thread 2) detecta a chegada de um POST vazio e lança outro
HandleRequest (Thread 8) para atender este novo POST.
Este Thread (Thread 8) informa o SessionManager da chegada de um POST vazio,
decide criar uma nova sessão, entrega-a a entidade que a pediu (Thread 3) e de seguida
morre.
Com esta sessão o CPE Factory (Thread 3) cria a entidade CPE e passa-a ao Utilizador,
que instancia a classe de testes Menu com a entidade CPE que lhe foi entregue e opta
pela operação de Reboot.
De seguida o ConnectionManager (Thread 2) detecta a chegada de um novo POST
contendo a mensagem de RebootResponse, e lança uma nova Thread HandleRequest
(Thread 9) para atender este POST.
Para terminar o teste o utilizador opta pela opção de terminar a sessão, e o
SessionManager encarrega-se por fechar a sessão caso não encontre nenhum pedido de
interesse para esta sessão.
De notar que o Reboot só é realizado quando a sessão TR-069 for terminada.
5.2 Factory Reset
19389 INFO [2009-08-20
19390 INFO [2009-08-20
19392 INFO [2009-08-20
19394 INFO [2009-08-20
19396 INFO [2009-08-20
19397 INFO [2009-08-20
19399 INFO [2009-08-20
19401 INFO [2009-08-20
19402 INFO [2009-08-20
19404 INFO [2009-08-20
23149 INFO [2009-08-20
23149 INFO [2009-08-20
23192 INFO [2009-08-20
Post HTTP ao Connection
23193 INFO [2009-08-20
Request
20:39:56,172:Thread-3]
20:39:56,173:Thread-3]
20:39:56,175:Thread-3]
20:39:56,177:Thread-3]
20:39:56,179:Thread-3]
20:39:56,180:Thread-3]
20:39:56,182:Thread-3]
20:39:56,184:Thread-3]
20:39:56,185:Thread-3]
20:39:56,187:Thread-3]
20:39:59,932:Thread-3]
20:39:59,932:Thread-3]
20:39:59,975:Thread-2]
Manager
20:39:59,976:Thread-9]
tr069.testes.MenuTR069 - Menu Operacoes TR069
tr069.testes.MenuTR069 - 1 - Set Parameter Values
tr069.testes.MenuTR069 - 2 - Get Parameter Values
tr069.testes.MenuTR069 - 3 - Get Parameter Names
tr069.testes.MenuTR069 - 4 - Reboot
tr069.testes.MenuTR069 - 5 - Download
tr069.testes.MenuTR069 - 6 - Factory Reset
tr069.testes.MenuTR069 - 7 - GetRPCMethods
tr069.testes.MenuTR069 - 0 - Terminar Sessao
tr069.testes.MenuTR069 tr069.testes.MenuTR069 - 6
tr069.testes.MenuTR069 - Operacao Factory Reset
tr069.api_tr069.ConnectionManager - Chegou um novo
tr069.api_tr069.HandleRequest - Entrou no Handle
58
23208 INFO [2009-08-20 20:39:59,991:Thread-9] tr069.api_tr069.HandleRequest - Chegou
cwmp:FactoryResetResponse vindo de: 192.168.125.77
23212 DEBUG [2009-08-20 20:39:59,995:Thread-3] tr069.api_tr069.CPE_Entity - FactoryReset Executado
com Sucesso
23218 INFO [2009-08-20 20:40:00,001:Thread-3] tr069.testes.MenuTR069 23218 INFO [2009-08-20 20:40:00,001:Thread-3] tr069.testes.MenuTR069 23219 INFO [2009-08-20 20:40:00,002:Thread-3] tr069.testes.MenuTR069 - Menu Operacoes TR069
23219 INFO [2009-08-20 20:40:00,002:Thread-3] tr069.testes.MenuTR069 - 1 - Set Parameter Values
23220 INFO [2009-08-20 20:40:00,003:Thread-3] tr069.testes.MenuTR069 - 2 - Get Parameter Values
23220 INFO [2009-08-20 20:40:00,003:Thread-3] tr069.testes.MenuTR069 - 3 - Get Parameter Names
23220 INFO [2009-08-20 20:40:00,003:Thread-3] tr069.testes.MenuTR069 - 4 - Reboot
23221 INFO [2009-08-20 20:40:00,004:Thread-3] tr069.testes.MenuTR069 - 5 - Download
23221 INFO [2009-08-20 20:40:00,004:Thread-3] tr069.testes.MenuTR069 - 6 - Factory Reset
23221 INFO [2009-08-20 20:40:00,004:Thread-3] tr069.testes.MenuTR069 - 7 - GetRPCMethods
23222 INFO [2009-08-20 20:40:00,005:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
23222 INFO [2009-08-20 20:40:00,005:Thread-3] tr069.testes.MenuTR069 25363 INFO [2009-08-20 20:40:02,146:Thread-3] tr069.testes.MenuTR069 - 0
25363 INFO [2009-08-20 20:40:02,146:Thread-3] tr069.testes.MenuTR069 - Terminar Sessao
25376 DEBUG [2009-08-20 20:40:02,159:Thread-3] tr069.api_tr069.SessionManager - Removeu pedido
25377 INFO [2009-08-20 20:40:02,160:Thread-3] tr069.api_tr069.SessionManager - Existem 0 Pedidos
para atender
25381 INFO [2009-08-20 20:40:02,164:Thread-3] tr069.api_tr069.SessionManager - Sessao foi Terminada
Relativamente ao teste anterior a única diferença foi o facto de o utilizador optar pela
operação de Factory Reset. Novamente o equipamento só repõe as configurações de
fabrico quando a sessão TR-069 é terminada.
5.3 Download
18480 INFO [2009-08-19 17:45:12,710:Thread-3]
18481 INFO [2009-08-19 17:45:12,711:Thread-3]
18482 INFO [2009-08-19 17:45:12,712:Thread-3]
18484 INFO [2009-08-19 17:45:12,714:Thread-3]
18485 INFO [2009-08-19 17:45:12,715:Thread-3]
18486 INFO [2009-08-19 17:45:12,716:Thread-3]
18487 INFO [2009-08-19 17:45:12,717:Thread-3]
18488 INFO [2009-08-19 17:45:12,718:Thread-3]
18489 INFO [2009-08-19 17:45:12,719:Thread-3]
18490 INFO [2009-08-19 17:45:12,720:Thread-3]
20605 INFO [2009-08-19 17:45:14,835:Thread-3]
20610 INFO [2009-08-19 17:45:14,840:Thread-3]
20611 INFO [2009-08-19 17:45:14,841:Thread-3]
20612 INFO [2009-08-19 17:45:14,842:Thread-3]
20614 INFO [2009-08-19 17:45:14,844:Thread-3]
20615 INFO [2009-08-19 17:45:14,845:Thread-3]
21783 INFO [2009-08-19 17:45:16,013:Thread-3]
21785 INFO [2009-08-19 17:45:16,015:Thread-3]
21786 INFO [2009-08-19 17:45:16,016:Thread-3]
34389 INFO [2009-08-19 17:45:28,619:Thread-3]
http://192.168.89.45:80/ZZOHAA62F5.bin
34391 INFO [2009-08-19 17:45:28,621:Thread-3]
38616 INFO [2009-08-19 17:45:32,846:Thread-3]
38617 INFO [2009-08-19 17:45:32,847:Thread-3]
41044 INFO [2009-08-19 17:45:35,274:Thread-3]
41045 INFO [2009-08-19 17:45:35,275:Thread-3]
56411 INFO [2009-08-19 17:45:50,641:Thread-3]
56414 INFO [2009-08-19 17:45:50,644:Thread-3]
67754 INFO [2009-08-19 17:46:01,984:Thread-3]
67756 INFO [2009-08-19 17:46:01,986:Thread-3]
70572 INFO [2009-08-19 17:46:04,802:Thread-3]
70776 INFO [2009-08-19 17:46:05,006:Thread-2]
Post HTTP ao Connection Manager
70779 INFO [2009-08-19 17:46:05,009:Thread-9]
Request
70795 INFO [2009-08-19 17:46:05,025:Thread-9]
DownloadResponse vindo de: 192.168.125.78
70796 DEBUG [2009-08-19 17:46:05,026:Thread-3]
Sucesso
70808 INFO [2009-08-19 17:46:05,038:Thread-3]
nem Aplicado
70809 INFO [2009-08-19 17:46:05,039:Thread-3]
70809 INFO [2009-08-19 17:46:05,039:Thread-3]
70809 INFO [2009-08-19 17:46:05,039:Thread-3]
70809 INFO [2009-08-19 17:46:05,039:Thread-3]
70810 INFO [2009-08-19 17:46:05,040:Thread-3]
70810 INFO [2009-08-19 17:46:05,040:Thread-3]
70810 INFO [2009-08-19 17:46:05,040:Thread-3]
70811 INFO [2009-08-19 17:46:05,041:Thread-3]
70811 INFO [2009-08-19 17:46:05,041:Thread-3]
70811 INFO [2009-08-19 17:46:05,041:Thread-3]
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
-
Menu Operacoes TR069
1 - Set Parameter Values
2 - Get Parameter Values
3 - Get Parameter Names
4 - Reboot
5 - Download
6 - Factory Reset
7 - GetRPCMethods
0 - Terminar Sessao
5
Operacaoo Download
Escolha o tipo de Download
1 - Firmware Upgrade Image
2 - Web Content
3 - Vendor Configuration File
1
Introduza os seguintes dados:
URL
tr069.testes.MenuTR069 - Username
tr069.testes.MenuTR069 - tr069
tr069.testes.MenuTR069 - Password
tr069.testes.MenuTR069 - ola
tr069.testes.MenuTR069 - Tamanho do ficheiro
tr069.testes.MenuTR069 - 32000000
tr069.testes.MenuTR069 - Nome do ficheiro
tr069.testes.MenuTR069 - ZZOHAA62F5.bin
tr069.testes.MenuTR069 - Tempo de Atraso
tr069.testes.MenuTR069 - 0
tr069.api_tr069.ConnectionManager - Chegou um novo
tr069.api_tr069.HandleRequest - Entrou no Handle
tr069.api_tr069.HandleRequest - Chegou
tr069.api_tr069.CPE_Entity - Download Executado com
tr069.testes.MenuTR069 - Download ainda nao Terminado
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
tr069.testes.MenuTR069
59
-
Menu Operacoes TR069
1 - Set Parameter Values
2 - Get Parameter Values
3 - Get Parameter Names
4 - Reboot
5 - Download
6 - Factory Reset
7 - GetRPCMethods
70811 INFO [2009-08-19 17:46:05,041:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
70812 INFO [2009-08-19 17:46:05,042:Thread-3] tr069.testes.MenuTR069 74311 INFO [2009-08-19 17:46:08,541:Thread-3] tr069.testes.MenuTR069 - 0
74313 INFO [2009-08-19 17:46:08,543:Thread-3] tr069.testes.MenuTR069 - Terminar Sessao
74317 DEBUG [2009-08-19 17:46:08,547:Thread-3] tr069.api_tr069.SessionManager - Removeu pedido
74318 INFO [2009-08-19 17:46:08,548:Thread-3] tr069.api_tr069.SessionManager - Existem 0 Pedidos
para atender
74323 INFO [2009-08-19 17:46:08,553:Thread-3] tr069.api_tr069.SessionManager - Sessao foi Terminada
94422 INFO [2009-08-19 17:46:28,652:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
98032 INFO [2009-08-19 17:46:32,262:Thread-11] tr069.api_tr069.HandleRequest - Chegou Inform vindo
de: 192.168.125.78
98034 INFO [2009-08-19 17:46:32,264:Thread-11] tr069.api_tr069.CA - CPE conhecido
98037 INFO [2009-08-19 17:46:32,267:Thread-11] tr069.api_tr069.Cadastro - Manufacturer: THOMSON
98037 INFO [2009-08-19 17:46:32,267:Thread-11] tr069.api_tr069.Cadastro - OUI: 00147F
98039 INFO [2009-08-19 17:46:32,269:Thread-11] tr069.api_tr069.Cadastro - ProductClass: SpeedTouch
780
98040 INFO [2009-08-19 17:46:32,270:Thread-11] tr069.api_tr069.Cadastro - SerialNumber: CP0610JT7YB
98041 INFO [2009-08-19 17:46:32,271:Thread-11] tr069.api_tr069.EventManager - EVENTO: TRANSFER
COMPLETE, A sessao foi estabelecida para indicar que determinado download ou upload foi finalizado
correcta ou incorrectamente
Neste teste foi testado o método de download. Aqui o utilizador escolheu a opção de
download, e introduziu os parâmetros necessários para a invocação do método e enviou
a mensagem de Download ao CPE (Thread 3). De seguida o ConnectionManager
detecta a chegada da mensagem de DownloadResponse (Thread 9) indicando que o
Download ainda não foi feito nem aplicado.
Após o término da sessão, o CPE envia uma nova mensagem de Inform com o evento
de TransferComplete (Thread 11) indicando o estado actual do respectivo pedido de
Download.
5.4 Várias Sessões Activas
9394 INFO [2009-08-20 15:56:59,590:Thread-4] tr069.testes.Utilizador - Start new utilizador
9398 INFO [2009-08-20 15:56:59,594:Thread-4] tr069.api_tr069.CpeFactory - Start CpeFactory
9400 INFO [2009-08-20 15:56:59,596:Thread-4] tr069.api_tr069.CpeFactory - Entrou no Cpe Factory
9413 INFO [2009-08-20 15:56:59,609:Thread-4] tr069.api_tr069.SessionManager - Start Session Manager
9423 INFO [2009-08-20 15:56:59,619:Thread-4] tr069.api_tr069.SessionManager - Registou pedido de
Sessao para o CPE com IP: 192.168.125.80
9415 INFO [2009-08-20 15:56:59,611:Thread-3] tr069.testes.Utilizador - Start new utilizador
9582 INFO [2009-08-20 15:56:59,778:Thread-5] tr069.api_tr069.SessionManagerWorker - Start Session
Manager Worker
9684 INFO [2009-08-20 15:56:59,880:Thread-3] tr069.api_tr069.CpeFactory - Entrou no Cpe Factory
9690 INFO [2009-08-20 15:56:59,886:Thread-3] tr069.api_tr069.SessionManager - Registou pedido de
Sessao para o CPE com IP: 192.168.125.78
12167 INFO [2009-08-20 15:57:02,363:Thread-6] tr069.api_tr069.HandleConnectionRequest - Entrou no
Handler Connection Request
12168 DEBUG [2009-08-20 15:57:02,364:Thread-6] tr069.api_tr069.HandleConnectionRequest - Vai atender
pedido:::192.168.125.80
12180 INFO [2009-08-20 15:57:02,376:Thread-6] tr069.api_tr069.RequestClient - Entrou no
RequestClient
25942 DEBUG [2009-08-20 15:57:16,138:Thread-7] commons.httpclient.HttpConnection - Open connection to
192.168.125.78:51005
25950 DEBUG [2009-08-20 15:57:16,146:Thread-6] commons.httpclient.HttpConnection - Open connection to
192.168.125.80:51005
Request
34266 INFO [2009-08-20 15:57:24,462:Thread-9] tr069.api_tr069.HandleRequest - Chegou Inform vindo
de: 192.168.125.80
35504 INFO [2009-08-20 15:57:25,700:Thread-12] tr069.api_tr069.HandleRequest - Chegou
cwmp:GetRPCMethodsResponse vindo de: 192.168.125.80
35505 DEBUG [2009-08-20 15:57:25,701:Thread-4] tr069.api_tr069.CPE_Entity - GetRPCMethods Executado
com Sucesso
35512 INFO [2009-08-20 15:57:25,708:Thread-4] tr069.api_tr069.CPE_Entity - Metodos Suportados pelo
CPE:
35513 INFO [2009-08-20 15:57:25,709:Thread-4] tr069.api_tr069.CPE_Entity - GetRPCMethods
35513 INFO [2009-08-20 15:57:25,709:Thread-4] tr069.api_tr069.CPE_Entity - GetParameterNames
35514 INFO [2009-08-20 15:57:25,710:Thread-4] tr069.api_tr069.CPE_Entity - GetParameterValues
35514 INFO [2009-08-20 15:57:25,710:Thread-4] tr069.api_tr069.CPE_Entity - SetParameterValues
35514 INFO [2009-08-20 15:57:25,710:Thread-4] tr069.api_tr069.CPE_Entity - AddObject
35515 INFO [2009-08-20 15:57:25,711:Thread-4] tr069.api_tr069.CPE_Entity - DeleteObject
35515 INFO [2009-08-20 15:57:25,711:Thread-4] tr069.api_tr069.CPE_Entity - Download
60
35515 INFO [2009-08-20 15:57:25,711:Thread-4] tr069.api_tr069.CPE_Entity - Reboot
35515 INFO [2009-08-20 15:57:25,711:Thread-4] tr069.api_tr069.CPE_Entity - FactoryReset
35520 INFO [2009-08-20 15:57:25,716:Thread-12] tr069.api_tr069.HandleRequest - Thread Morreu
38442 INFO [2009-08-20 15:57:28,638:Thread-10] tr069.api_tr069.HandleRequest - Chegou Inform vindo
de: 192.168.125.78
38574 INFO [2009-08-20 15:57:28,770:Thread-13] tr069.api_tr069.HandleRequest - Chegou
cwmp:SetParameterValuesResponse vindo de: 192.168.125.80
38582 DEBUG [2009-08-20 15:57:28,778:Thread-4] tr069.api_tr069.CPE_Entity - SetParameterValues
Executado com Sucesso
38588 INFO [2009-08-20 15:57:28,784:Thread-4] tr069.api_tr069.CPE_Entity - Todas as alteracoes foram
validadas e aplicadas
38592 DEBUG [2009-08-20 15:57:28,788:Thread-4] tr069.api_tr069.SessionManager - Removeu pedido
38592 INFO [2009-08-20 15:57:28,788:Thread-4] tr069.api_tr069.SessionManager - Existem 1 Pedidos
para atender
38595 INFO [2009-08-20 15:57:28,791:Thread-4] tr069.api_tr069.SessionManager - Sessao foi Terminada
38595 INFO [2009-08-20 15:57:28,791:Thread-4] tr069.testes.Utilizador - Morreu Thread Utilizador
39034 INFO [2009-08-20 15:57:29,230:Thread-16] tr069.api_tr069.HandleRequest - Chegou
cwmp:GetRPCMethodsResponse vindo de: 192.168.125.78
39036 INFO [2009-08-20 15:57:29,232:Thread-16] tr069.api_tr069.HandleRequest - Thread Morreu
39040 DEBUG [2009-08-20 15:57:29,236:Thread-3] tr069.api_tr069.CPE_Entity - GetRPCMethods Executado
com Sucesso
39044 INFO [2009-08-20 15:57:29,240:Thread-3] tr069.api_tr069.CPE_Entity - Metodos Suportados pelo
CPE:
39045 INFO [2009-08-20 15:57:29,241:Thread-3] tr069.api_tr069.CPE_Entity - GetRPCMethods
39047 INFO [2009-08-20 15:57:29,243:Thread-3] tr069.api_tr069.CPE_Entity - GetParameterNames
39048 INFO [2009-08-20 15:57:29,244:Thread-3] tr069.api_tr069.CPE_Entity - GetParameterValues
39049 INFO [2009-08-20 15:57:29,245:Thread-3] tr069.api_tr069.CPE_Entity - SetParameterValues
39051 INFO [2009-08-20 15:57:29,247:Thread-3] tr069.api_tr069.CPE_Entity - AddObject
39052 INFO [2009-08-20 15:57:29,248:Thread-3] tr069.api_tr069.CPE_Entity - DeleteObject
39053 INFO [2009-08-20 15:57:29,249:Thread-3] tr069.api_tr069.CPE_Entity - Download
39054 INFO [2009-08-20 15:57:29,250:Thread-3] tr069.api_tr069.CPE_Entity - Reboot
39056 INFO [2009-08-20 15:57:29,252:Thread-3] tr069.api_tr069.CPE_Entity - FactoryReset
39267 INFO [2009-08-20 15:57:29,463:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
39270 INFO [2009-08-20 15:57:29,466:Thread-17] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
39274 INFO [2009-08-20 15:57:29,470:Thread-17] tr069.api_tr069.HandleRequest - Chegou
cwmp:GetParameterValuesResponse vindo de: 192.168.125.78
39279 DEBUG [2009-08-20 15:57:29,475:Thread-3] tr069.api_tr069.CPE_Entity - GetParameterValues
Executado com Sucesso
39284 DEBUG [2009-08-20 15:57:29,480:Thread-3] tr069.api_tr069.CPE_Entity - 1
39284 INFO [2009-08-20 15:57:29,480:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.LANDevice.1.Hosts.HostNumberOfEntries
Valor = 29
39430 INFO [2009-08-20 15:57:29,626:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
39433 INFO [2009-08-20 15:57:29,629:Thread-18] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
39528 INFO [2009-08-20 15:57:29,724:Thread-18] tr069.api_tr069.HandleRequest - Chegou
cwmp:GetParameterNamesResponse vindo de: 192.168.125.78
39529 DEBUG [2009-08-20 15:57:29,725:Thread-3] tr069.api_tr069.CPE_Entity - GetParameterNames
Executado com Sucesso
39539 INFO [2009-08-20 15:57:29,735:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.DeviceSummary
Premite ser Alterado = false
39539 INFO [2009-08-20 15:57:29,735:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.LANDeviceNumberOfEntries
Premite ser Alterado = false
39540 INFO [2009-08-20 15:57:29,736:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.WANDeviceNumberOfEntries
Premite ser Alterado = false
39540 INFO [2009-08-20 15:57:29,736:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.LANDevice.
Premite ser Alterado = false
39540 INFO [2009-08-20 15:57:29,736:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.WANDevice.
Premite ser Alterado = false
39540 INFO [2009-08-20 15:57:29,736:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.DeviceConfig.
Premite ser Alterado = false
39541 INFO [2009-08-20 15:57:29,737:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.Layer2Bridging.
Premite ser Alterado = false
39541 INFO [2009-08-20 15:57:29,737:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.Layer3Forwarding.
Premite ser Alterado = false
39541 INFO [2009-08-20 15:57:29,737:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.ManagementServer.
Premite ser Alterado = false
39541 INFO [2009-08-20 15:57:29,737:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.X_000E50_Firewall.
Premite ser Alterado = false
39542 INFO [2009-08-20 15:57:29,738:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.DeviceInfo.
Premite ser Alterado = false
39542 INFO [2009-08-20 15:57:29,738:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.Time.
Premite ser Alterado = false
39542 INFO [2009-08-20 15:57:29,738:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.Services.
Premite ser Alterado = false
39543 INFO [2009-08-20 15:57:29,739:Thread-3] tr069.api_tr069.CPE_Entity - Parametro =
InternetGatewayDevice.UserInterface.
Premite ser Alterado = false
39543 DEBUG [2009-08-20 15:57:29,739:Thread-3] tr069.api_tr069.SessionManager - Removeu pedido
39543 INFO [2009-08-20 15:57:29,739:Thread-3] tr069.api_tr069.SessionManager - Existem 0 Pedidos
para atender
39544 INFO [2009-08-20 15:57:29,740:Thread-3] tr069.api_tr069.SessionManager - Sessao foi Terminada
61
Neste teste pretendeu-se verificar o bom funcionamento da API com mais do que uma
sessão TR069 activa simultaneamente. Como podemos observar no relatório temos duas
Threads Utilizador (Thread 3 e Thread 4) que realizam dois pedidos para entidades de
CPE distintas. Temos também dois pedidos de conecção distintos feitos pelos Threads
RequestClient (Thread 6 e Thread 7).
Ao acompanhar a Thread 4, verificamos que após a criação e entrega da entidade CPE,
foram invocadas as operações de GetRPCMethods, SetParameterValues e foi terminada
a sessão.
Simultaneamente a Thread 3 também invocava noutro CPE as operações de
GetRPCMethods e GetParameterNames e foi também terminada a sessão.
De notar que a operação GetParameterNames necessita de bastantes recursos de
processamento para descascar a grande quantidade de informação de interesse do
documento XML recebido na resposta ao método, podendo tornar-se num processo
lento o que poderá também provocar falhas no funcionamento da API caso ela esteja a
lidar com sessões simultâneas. Neste caso foi indicado para se visualizar unicamente os
nomes dos parâmetros filhos da raiz da hierarquia de parâmetros TR-069.
5.5 Configuração de Serviço
16240 INFO [2009-08-19 18:08:26,982:Thread-3] tr069.testes.MenuTR069 - Menu Operacoes TR069
16241 INFO [2009-08-19 18:08:26,983:Thread-3] tr069.testes.MenuTR069 - 1 - Set Parameter Values
16243 INFO [2009-08-19 18:08:26,985:Thread-3] tr069.testes.MenuTR069 - 2 - Get Parameter Values
16244 INFO [2009-08-19 18:08:26,986:Thread-3] tr069.testes.MenuTR069 - 3 - Get Parameter Names
16245 INFO [2009-08-19 18:08:26,987:Thread-3] tr069.testes.MenuTR069 - 4 - Reboot
16246 INFO [2009-08-19 18:08:26,988:Thread-3] tr069.testes.MenuTR069 - 5 - Download
16248 INFO [2009-08-19 18:08:26,990:Thread-3] tr069.testes.MenuTR069 - 6 - Factory Reset
16249 INFO [2009-08-19 18:08:26,991:Thread-3] tr069.testes.MenuTR069 - 7 - GetRPCMethods
16349 INFO [2009-08-19 18:08:27,091:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
16351 INFO [2009-08-19 18:08:27,093:Thread-3] tr069.testes.MenuTR069 18184 INFO [2009-08-19 18:08:28,926:Thread-3] tr069.testes.MenuTR069 - 1
18186 INFO [2009-08-19 18:08:28,928:Thread-3] tr069.testes.MenuTR069 - Operacao SetParameterValues
18187 INFO [2009-08-19 18:08:28,929:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar parametro para
alterar
18188 INFO [2009-08-19 18:08:28,930:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para alterar
19072 INFO [2009-08-19 18:08:29,814:Thread-3] tr069.testes.MenuTR069 - 1
19074 INFO [2009-08-19 18:08:29,816:Thread-3] tr069.testes.MenuTR069 - Introduza o nome completo do
parametro
29281 INFO [2009-08-19 18:08:40,023:Thread-3] tr069.testes.MenuTR069 InternetGatewayDevice.LANDevice.1.WLANConfiguration.1.Enable
29283 INFO [2009-08-19 18:08:40,025:Thread-3] tr069.testes.MenuTR069 - Introduza o valor do
parametro
31468 INFO [2009-08-19 18:08:42,210:Thread-3] tr069.testes.MenuTR069 - 1
31470 INFO [2009-08-19 18:08:42,212:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar parametro para
alterar
31471 INFO [2009-08-19 18:08:42,213:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para alterar
33991 INFO [2009-08-19 18:08:44,733:Thread-3] tr069.testes.MenuTR069 - 0
34142 INFO [2009-08-19 18:08:44,884:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
34145 INFO [2009-08-19 18:08:44,887:Thread-9] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
34150 INFO [2009-08-19 18:08:44,892:Thread-9] tr069.api_tr069.HandleRequest - Chegou
SetParameterValuesResponse vindo de: 192.168.125.80
34164 DEBUG [2009-08-19 18:08:44,906:Thread-3] tr069.api_tr069.CPE_Entity - SetParameterValues
Executado com Sucesso
34171 INFO [2009-08-19 18:08:44,913:Thread-3] tr069.testes.MenuTR069 - Todas as alteracoes foram
validadas e aplicadas
62
Neste teste o Utilizador (Thread 3) optou realizar a operação de SetParameterValues
para activar o serviço de wireless do CPE.
5.6 Recolha de Informação e detecção de erros na
comunicação
23394 INFO [2009-08-19 18:49:31,064:Thread-3] tr069.testes.MenuTR069 - Menu Operacoes TR069
23396 INFO [2009-08-19 18:49:31,066:Thread-3] tr069.testes.MenuTR069 - 1 - Set Parameter Values
23397 INFO [2009-08-19 18:49:31,067:Thread-3] tr069.testes.MenuTR069 - 2 - Get Parameter Values
23398 INFO [2009-08-19 18:49:31,068:Thread-3] tr069.testes.MenuTR069 - 3 - Get Parameter Names
23399 INFO [2009-08-19 18:49:31,069:Thread-3] tr069.testes.MenuTR069 - 4 - Reboot
23400 INFO [2009-08-19 18:49:31,070:Thread-3] tr069.testes.MenuTR069 - 5 - Download
23401 INFO [2009-08-19 18:49:31,071:Thread-3] tr069.testes.MenuTR069 - 6 - Factory Reset
23402 INFO [2009-08-19 18:49:31,072:Thread-3] tr069.testes.MenuTR069 - 7 - GetRPCMethods
23403 INFO [2009-08-19 18:49:31,073:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
23404 INFO [2009-08-19 18:49:31,074:Thread-3] tr069.testes.MenuTR069 24855 INFO [2009-08-19 18:49:32,525:Thread-3] tr069.testes.MenuTR069 - 2
24857 INFO [2009-08-19 18:49:32,527:Thread-3] tr069.testes.MenuTR069 - Operacao GetParameterValues
24858 INFO [2009-08-19 18:49:32,528:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
24859 INFO [2009-08-19 18:49:32,529:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
27379 INFO [2009-08-19 18:49:35,049:Thread-3] tr069.testes.MenuTR069 - 1
27381 INFO [2009-08-19 18:49:35,051:Thread-3] tr069.testes.MenuTR069 - Introduza nome completo do
Parametro
30094 INFO [2009-08-19 18:49:37,764:Thread-3] tr069.testes.MenuTR069 InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.1.Status
30096 INFO [2009-08-19 18:49:37,766:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
30097 INFO [2009-08-19 18:49:37,767:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
33793 INFO [2009-08-19 18:49:41,463:Thread-3] tr069.testes.MenuTR069 - 1
33793 INFO [2009-08-19 18:49:41,463:Thread-3] tr069.testes.MenuTR069 - Introduza nome completo do
Parametro
45331 INFO [2009-08-19 18:49:53,001:Thread-3] tr069.testes.MenuTR069 InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.2.Status
45332 INFO [2009-08-19 18:49:53,002:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
45333 INFO [2009-08-19 18:49:53,003:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
48525 INFO [2009-08-19 18:49:56,195:Thread-3] tr069.testes.MenuTR069 - 1
48527 INFO [2009-08-19 18:49:56,197:Thread-3] tr069.testes.MenuTR069 - Introduza nome completo do
Parametro
58153 INFO [2009-08-19 18:50:05,823:Thread-3] tr069.testes.MenuTR069 InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.3.Status
58156 INFO [2009-08-19 18:50:05,826:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
58157 INFO [2009-08-19 18:50:05,827:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
59418 INFO [2009-08-19 18:50:07,088:Thread-3] tr069.testes.MenuTR069 - 1
59419 INFO [2009-08-19 18:50:07,089:Thread-3] tr069.testes.MenuTR069 - Introduza nome completo do
Parametro
74385 INFO [2009-08-19 18:50:22,055:Thread-3] tr069.testes.MenuTR069 InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.4.Status
74386 INFO [2009-08-19 18:50:22,056:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
74387 INFO [2009-08-19 18:50:22,057:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
76612 INFO [2009-08-19 18:50:24,282:Thread-3] tr069.testes.MenuTR069 - 0
76824 INFO [2009-08-19 18:50:24,494:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
76828 INFO [2009-08-19 18:50:24,498:Thread-9] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
76848 INFO [2009-08-19 18:50:24,518:Thread-9] tr069.api_tr069.HandleRequest - Chegou
cwmp:GetParameterValuesResponse vindo de: 192.168.125.78
76850 DEBUG [2009-08-19 18:50:24,520:Thread-3] tr069.api_tr069.CPE_Entity - GetParameterValues
Executado com Sucesso
76856 DEBUG [2009-08-19 18:50:24,526:Thread-3] tr069.api_tr069.CPE_Entity - 4
76858 INFO [2009-08-19 18:50:24,528:Thread-3] tr069.testes.MenuTR069 - Parametro =
InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.1.Status
Valor = 1
63
76858 INFO [2009-08-19 18:50:24,528:Thread-3] tr069.testes.MenuTR069 - Parametro =
InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.2.Status
Valor = 1
76858 INFO [2009-08-19 18:50:24,528:Thread-3] tr069.testes.MenuTR069 - Parametro =
InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.3.Status
Valor = 1
76858 INFO [2009-08-19 18:50:24,528:Thread-3] tr069.testes.MenuTR069 - Parametro =
InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.4.Status
Valor = 1
76859 INFO [2009-08-19 18:50:24,529:Thread-3] tr069.testes.MenuTR069 76859 INFO [2009-08-19 18:50:24,529:Thread-3] tr069.testes.MenuTR069 76859 INFO [2009-08-19 18:50:24,529:Thread-3] tr069.testes.MenuTR069 - Menu Operacoes TR069
76860 INFO [2009-08-19 18:50:24,530:Thread-3] tr069.testes.MenuTR069 - 1 - Set Parameter Values
76860 INFO [2009-08-19 18:50:24,530:Thread-3] tr069.testes.MenuTR069 - 2 - Get Parameter Values
76860 INFO [2009-08-19 18:50:24,530:Thread-3] tr069.testes.MenuTR069 - 3 - Get Parameter Names
76861 INFO [2009-08-19 18:50:24,531:Thread-3] tr069.testes.MenuTR069 - 4 - Reboot
76861 INFO [2009-08-19 18:50:24,531:Thread-3] tr069.testes.MenuTR069 - 5 - Download
76861 INFO [2009-08-19 18:50:24,531:Thread-3] tr069.testes.MenuTR069 - 6 - Factory Reset
76862 INFO [2009-08-19 18:50:24,532:Thread-3] tr069.testes.MenuTR069 - 7 - GetRPCMethods
76862 INFO [2009-08-19 18:50:24,532:Thread-3] tr069.testes.MenuTR069 - 0 - Terminar Sessao
76862 INFO [2009-08-19 18:50:24,532:Thread-3] tr069.testes.MenuTR069 87242 INFO [2009-08-19 18:50:34,912:Thread-3] tr069.testes.MenuTR069 - 2
87242 INFO [2009-08-19 18:50:34,912:Thread-3] tr069.testes.MenuTR069 - Operacao GetParameterValues
87243 INFO [2009-08-19 18:50:34,913:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
87243 INFO [2009-08-19 18:50:34,913:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
91068 INFO [2009-08-19 18:50:38,738:Thread-3] tr069.testes.MenuTR069 - 1
91069 INFO [2009-08-19 18:50:38,739:Thread-3] tr069.testes.MenuTR069 - Introduza nome completo do
Parametro
100987 INFO [2009-08-19 18:50:48,657:Thread-3] tr069.testes.MenuTR069 InternetGatewayDevice.LANDevice.1.LANEthernetInterfaceConfig.1.Sta
100989 INFO [2009-08-19 18:50:48,659:Thread-3] tr069.testes.MenuTR069 - 1 - Adicionar Parametro a
Visualizar
100990 INFO [2009-08-19 18:50:48,660:Thread-3] tr069.testes.MenuTR069 - 0 - Nao adicionar mais
parametros para visualizar
102397 INFO [2009-08-19 18:50:50,067:Thread-3] tr069.testes.MenuTR069 - 0
102578 INFO [2009-08-19 18:50:50,248:Thread-2] tr069.api_tr069.ConnectionManager - Chegou um novo
Post HTTP ao Connection Manager
102580 INFO [2009-08-19 18:50:50,250:Thread-10] tr069.api_tr069.HandleRequest - Entrou no Handle
Request
102585 INFO [2009-08-19 18:50:50,255:Thread-10] tr069.api_tr069.HandleRequest - Chegou soapenv:Fault
vindo de: 192.168.125.78
102590 DEBUG [2009-08-19 18:50:50,260:Thread-3] tr069.api_tr069.CPE_Entity - Erro no
GetParameterValues
102599 INFO [2009-08-19 18:50:50,269:Thread-3] tr069.api_tr069.CPE_Entity - Falha no: Client
102600 INFO [2009-08-19 18:50:50,270:Thread-3] tr069.api_tr069.CPE_Entity - Falha do Tipo: CWMP
fault
102606 ERROR [2009-08-19 18:50:50,276:Thread-3] tr069.api_tr069.TR069Exception - Codigo da Falha:9005
102608 ERROR [2009-08-19 18:50:50,278:Thread-3] tr069.api_tr069.TR069Exception - Falha :Invalid
parameter name
102614 FATAL [2009-08-19 18:50:50,284:Thread-3] tr069.api_tr069.CPE_Entity - Erro!!!!!
Neste teste pretendia-se testar o correcto funcionamento da operação de
GetParameterValues e a detecção de falhas enviadas pelos CPE. Para isso o Utilizador
invocou duas vezes a operação de GetParameterValues no entanto na segunda vez
introduziu incorrectamente o nome do parâmetro que pretende visualizar.
Como podemos observar no relatório de teste, na primeira invocação o operador
introduz os nomes dos quatro parâmetros que correspondem ao estado das quatro
interfaces Ethernet do CPE. O CPE responde indicando que as quatro se encontram
activas.
Na segunda invocação o operador introduz incorrectamente o nome do parâmetro que
pretende conhecer, e o CPE já não responde com um GetParameterValuesResponse mas
com uma mensagem Fault indicando o respectivo tipo de falha, que neste caso foi
“Invalid Parameter Name”.
64
6
Conclusões e Trabalhos Futuros
Com a realização deste projecto, conseguimos criar uma solução de gestão baseada num
protocolo que se tem tornado padrão na gestão remota de equipamentos de home
network - o CPE WAN Management Protocol (TR-069).
Após uma fase inicial de consolidação de conhecimentos foi dado início à criação do
desenho e esboço do módulo de gestão.
Durante esta concepção teórica foram definidos os requisitos; casos de utilização;
funcionamento interno; arquitectura global e diagramas de classes e de fluxo referentes
ao funcionamento da API_TR069.
Após a conclusão desta análise teórica, demos início à construção e implementação da
API.
Verificamos que o trabalho realizado na concepção teórica do módulo, não só permitia
uma simples forma de descrever o funcionamento de toda a API mas também muito útil
para a sua implementação.
De notar que alguns pormenores da concepção foram adicionados outros alterados
durante a implementação.
Uma vez concluída a sua implementação, passou-se a uma fase de testes com o intuito
de detecção e correcção de eventuais anomalias. Inicialmente a API_TR069 foi testada
65
com um único utilizador e um único equipamento, isto é, havendo uma única sessão
activa.
Nesta primeira fase de testes pretendíamos garantir o bom funcionamento dos métodos
que a API_TR069 teria de ser capaz de invocar nos CPE bem como os métodos que os
CPE pudessem vir a invocar no ACS. De salientar ainda a grande utilidade que a
ferramenta de software Wireshark [22] nos deu durante esta fase, permitindo através de
capturas na rede perceber ao pormenor como é feita a comunicação entre o CPE e o
ACS, não só durante o estabelecimento e término das sessões mas também nas
invocações dos diferentes métodos. No documento “AnexoCapturas” podem ser vistas
algumas capturas que ajudam a perceber o conteúdo e o fluxo desta comunicação.
Uma vez concluída esta primeira fase de testes e respectiva correcção de anomalias,
procedemos a uma segunda fase de testes, na qual pretendíamos testar o nosso módulo
de gestão com vários utilizadores e CPE, criando-se assim um ambiente de gestão com
múltiplas sessões activas.
Esta fase previa-se ser complexa, uma vez que teria de ser adicionada à API_TR069 um
mecanismo na qual fosse capaz de relacionar as sessões activas com as respectivas
entidades que as pediam.
Após o uso de algumas técnicas que não satisfaziam o funcionamento esperado, foi
finalmente encontrada a solução ideal para a dificuldade que faltava transpor.
Uma vez concluídos estes testes, foram criados os já referenciados relatórios de teste e a
documentação de java docs do projecto desenvolvido.
Esta API_TR069 apresenta-se com um funcionamento bastante robusto, respeita o que
foi delineado na sua concepção teórica e comportar-se como um ACS num ambiente de
gestão de equipamentos TR-069 tal como era pretendido. Trata-se de um bom passo
para o desenvolvimento de uma solução final, que será adequada ao apoio e suporte a
tarefas de configuração dos equipamentos locais do cliente e que permitirá certamente
uma melhoria significativa na qualidade do serviço prestado.
No que diz respeito a trabalhos futuros relativamente a este projecto, podemos citar os
seguintes:
•
•
•
Integração da API_TR069 no Network Activator.
Integração da API_TR069 noutros sistemas da PT Inovação.
Uma vez integrado realizar testes de carga.
Aperfeiçoar e optimizar esta API de forma a poder se tornar numa clara ferramenta de
suporte ao cliente.
66
Bibliografia
[1] Badra B. - Network Working Group (2009), “NETCONF Over Transport Layer
Security (TLS)”, ultima consulta em Abril 2009
[2] Bernstein J., Spets T., Bouchat C. - BroadBand Forum(2005), “Applying TR-069 to
Remote Management of Home Networking Devices”, ultima consulta em Janeiro 2009
[3]Bernstein J., Stark B. (2005), “Internet Gateway Device Version 1.1 Data Model for
TR-069”, ultima consulta em Fevereiro 2009
[4]BroadBand Forum, ultima consulta em Agosto 2009, http://www.broadbandforum.org
[5] Broadband Forum (2007), “CPE WAN Management Protocol v1.1”, ultima consulta
em Dezembro 2008
[6] BroadBand Forum, Technical Reports, ultima consulta em Abril 2009
http://www.broadband-forum.org/technical/trlist.php
[7] BroadBand Forum, Modelo de Dados para Equipamentos TR-069 (TR-106), última
consulta
em
Fevereiro
2009,
http://www.broadbandforum.org/technical/releaseprogram.php
[8] BroadBand Forum, Modelo de Dados para CPE VoIP (TR-104), ultima consulta em
Fevereiro 2009, http://www.broadband-forum.org/technical/releaseprogram.php
[9] BroadBand Forum, The Big Picture DSL Home Technical WG, ultima consulta em
Fevereiro 2009, http://i.cmpnet.com/eetimes.de/2007/11/Bild2.jpg
67
[10] Case J. - Network Working Group (1990), “RFC 1157 – Simple Network
Management Protocol”, ultima consulta em Novembro 2008
[11] Crawford S. (2002), “O que Há de Melhor no UPnP do Windows XP?”, ultima
consulta em Abril 2009.
[12] Enns R. - Network Working Group (2006), “RFC 4741 – Network Configuration
Protocol”, ultima consulta em Janeiro 2009
[13]
Frases
Famosas
(2005),
ultima
consulta
http://www.frasesfamosas.com.br/de/max-frisch.html
em
Abril
2009,
[14] Goddard T. - Network Working Group (2006), “Using the Network Configuration
Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)”, ultima
consulta em Janeiro 2009
[15] Gouveia L. (1997), “Comunicação de dados – normas”, ultima consulta em Abril
2009
[16] Home Gateway Initiative,
http://www.homegatewayinitiative.org
ultima
consulta
em
Fevereiro
2009,
[17] Iijima T., Atarashi Y., Kimura H., Kitani M. - Network Working Group (2008),
“Experience of implementing NETCONF over SOAP”, ultima consulta em Janeiro 2009
[18] INTEL,
Digital Home Vision, ultima consulta em Fevereiro 2009,
http://images.google.pt/imgres?imgurl=http://cachewww.intel.com/cd/00/00/27/29/272984_272984.jpg&imgrefurl=http://www.intel.com/c
d/corporate/icsc/apac/eng/tech_innovation/272771.htm&usg=__ip3uCtiMVX_smSzCx
V6YEk1-nuU=&h=389&w=500&sz=147&hl=ptPT&start=13&tbnid=vLIKZJwPiLGjaM:&tbnh=101&tbnw=130&prev=/images%3Fq
%3DUPnP%26gbv%3D2%26ndsp%3D18%26hl%3Dpt-PT%26sa%3DN
68
[19] Internet Engineering Task Force, ultima consulta em Fevereiro 2009,
http://www.ietf.org
[20] JUDE/Community, ultima consulta em 2009, http://jude.change-vision.com/judeweb/product/community.html
[21] Kirksey H. (2005), “Standards-based Device Management”, ultima consulta em
Abril 2009
[22] Kurose J., Ross K. (2007), “Wireshark Lab: Getting Started”, ultima consulta em
Janeiro 2009
[23] Lear E. - Network Working Group (2006), “Using the NETCONF Protocol over
the Blocks Extensible Exchange Protocol (BEEP) – RFC 4744”, ultima consulta em
Novembro 2008
[24] McLaughlin B., Pollice G., West D. (2007), Head First
& Design, ultima consulta em Abril 2009
Object-Oriented Analysis
[25] NetBeans, ultima consulta em Março 2009, http://www.netbeans.org/
[26] NetConf Central (2008), Operações NetConf, ultima consulta em Janeiro 2009,
http://www.netconfcentral.org/rpclist
[27] Ogielski A. (1998), “TCP Tutorial”, ultima consulta em Março 2009
[28] PT Inovação (2009), “Network Activator”, ultima consulta em Agosto 2009
[29] Rose M. - Network Working Group (2001), “The Blocks Extensible Exchange
Protocol Core – RFC 3080”, ultima consulta em Dezembro 2008
69
[30] Royon Y., Parrend P., Frénot S., Papastefanos S., Abdelnur H., Poel D. (2007),
“Multi-service, Multi-protocol Management for Residential Gateways”, ultima consulta
em Dezembro 2008
[31] Stark B.- BroadBand Forum (2004), “LAN-Side DSL CPE Configuration”, ultima
consulta em Janeiro 2009
[32] Stephenson N. (1999), In the beginning ...was the command line, ultima consulta
em Fevereiro 2009
[33] SUN (2009), ”The Java Tutorials”, ultima consulta em Março 2009,
http://java.sun.com/docs/books/tutorial/
[34] UPnP Forum, ultima consulta em Janeiro 2009, http://www.upnp-ic.org/home
[35] UPnP Forum (2008), “UPnP Device Architecture 1.0”, ultima consulta em Janeiro
2009
[36] UPnP Forum (2006), “UPnP Forum Releases Enhanced AV Specifications Taking
Home Network to the Next Level”, ultima consulta em Janeiro 2009
[37]
UPnP
Standards,
ultima
consulta
http://www.upnp.org/standardizeddcps/default.asp
em
Abril
2009,
[38] Wasserman M., ThingMagic, Goddard T. - Network Working Group (2006),
“Using the NETCONF Configuration Protocol over Secure Shell (SSH)”, ultima
consulta em Novembro 2008
[39] Wikimedia Commons (2006), “SNMP-Managementkonsole.PNG”, ultima consulta
em
Fevereiro
2009,
http://images.google.pt/imgres?imgurl=http://upload.wikimedia.org/wikipedia/common
s/f/fb/SNMPManagementkonsole.PNG&imgrefurl=http://commons.wikimedia.org/wiki/File:SNMPManagementkonsole.PNG&usg=__yTDn92J2z7szkMfKSeinT9fE_Iw=&h=273&w=30
70
0&sz=7&hl=ptPT&start=3&tbnid=iYnDRKxxC37swM:&tbnh=106&tbnw=116&prev=/images%3Fq
%3DSNMP%26gbv%3D2%26hl%3Dpt-PT%26sa%3DG
[40] Wikipedia, Command Line Interface, ultima consulta em Outubro 2008,
http://en.wikipedia.org/wiki/Command-line_interface
[41] Wikipédia (2008), Gerência de Redes, última consulta em Abril 2009,
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_redes
[42] Wikipédia, Next Generation Network, ultima consulta em Agosto 2009,
http://pt.wikipedia.org/wiki/Next_Generation_Networking
[43] Wikipedia (2009), Unified Modeling Language, ultima consulta em Fevereiro
2009, http://en.wikipedia.org/wiki/Unified_Modeling_Language
[44]
Wikipédia,
Modelo
OSI,
ultima
http://pt.wikipedia.org/wiki/Modelo_OSI
consulta
em
Abril
2009,
[45] W3schools, HTML Tutorial, ultima
http://www.w3schools.com/html/default.asp
consulta
em
Março
2009,
[46] W3schools, Schema Tutorial, ultima
http://www.w3schools.com/schema/default.asp
consulta
em
Março
2009,
[47] W3schools, SOAP Tutorial, ultima
http://www.w3schools.com/soap/default.asp
consulta
em
Março
2009,
[48] W3schools, TCP/IP Tutorial, ultima
http://www.w3schools.com/tcpip/default.asp
consulta
em
Março
2009,
[49] W3schools, Web Services Tutorial, ultima consulta em Abril
http://www.w3schools.com/webservices/default.asp
71
2009,
[50] W3schools, XML Tutorial, ultima
http://www.w3schools.com/xml/default.asp
72
consulta
em
Março
2009,