Embed Size (px)
Citation preview
Implementação e Monitorizaçãode uma Rede de Sensores Móveispara Medição da Qualidade do Ar
Fábio Ferreira Gameiro
Dissertação para obtenção do grau de Mestre em
Engenharia de Redes de Comunicações
JúriPresidente: Prof. Paulo Jorge Pires FerreiraOrientador: Prof. João Pedro Castilho Pereira Santos GomesVogais: Prof. António Manuel Raminhos Cordeiro Grilo
Prof. Paulo Jorge Coelho Ramalho Oliveira
Maio 2012
Agradecimentos
Começo os agradecimentos por aqueles que me são mais próximos, à minha família e namorada,
que lidaram de perto e à distância com as minhas dificuldades, decisões e vitórias ao longo deste
curso e agradecer o suporte incondicional em todos os aspetos. Um agradecimento especial ao Prof.
João Pedro Gomes, coordenador da minha dissertação e coordenador do projeto URBISNET, pelo
seu apoio e orientação ao longo desta tese. Agradeço também aos restantes, envolvidos no projeto
URBISNET, que diretamente me ajudaram em situações de desenvolvimento e realização de testes
durante o projeto. Um reconhecimento grande ao apoio e palavras de apoio que os meus amigos
sempre me deram durante esta fase. Resta-me ainda pedir desculpa pela minha ausência, por vezes
fisicamente e outras mentalmente aos meus amigos, colegas e família durante a realização desta
dissertação devido ao que ela implica para mim, a conclusão de uma etapa que é o curso superior.
i
Abstract
The monitoring of atmospheric gases, especially polluting and endangering people’s health when
found in high concentrations, has been something that has concerned public health officials and the
citizens themselves more and more. The monitoring is currently, in its vast majority, made by stations
of a fixed nature with few points of data collection. The use of mobile atmospheric monitoring stations
integrated on a network of public buses creates the possibility of monitoring at various points of a
city taking advantage of its mobility. One of the challenges that this type of monitoring arises is the
communication between the atmospheric information gathering stations and the server that stores
that information in a data base. The objectives of this thesis began by creating and implementing
communications between mobile stations and a central server using technologies General Packet
Radio Service (GPRS) and Wi-Fi in order to operate autonomously. In addition to developing com-
munications, it was created a web platform in order to view the samples collected by the stations and
also provide monitor and configure operations remotely. This document presents the state of the art
in areas where this work was developed, especially in vehicular communications. It described the
solutions created in order to meet the objectives of this thesis and also evaluated the functioning and
performance of solutions. The evaluation made to the implemented work proved the correct operation
of its features and a very satisfactory performance by them.
Keywords
Mobile Sensor Network, Vehicular Network, Machine To Machine Communication, Atmospheric
Monitoring
iii
Resumo
A monitorização de gases atmosféricos, especialmente os poluentes e que põem em risco a
saúde das pessoas quando encontrados em elevadas concentrações, tem sido algo que tem pre-
ocupado as autoridades de saúde pública e os próprios cidadãos cada vez mais. A monitorização
atualmente é, na grande maioria, feita por estações de carácter fixo com poucos pontos de recolha
de dados. A utilização de estações móveis de monitorização atmosférica numa rede de autocarros
públicos cria a possibilidade de monitorização em vários pontos de uma cidade aproveitando a mobi-
lidade destes. Um dos desafios deste tipo de monitorização surge nos meios de comunicação entre
as estações de recolha de dados e o servidor que os armazena numa base de dados. Os objetivos
desta tese passaram pela criação e implementação das comunicações entre as estações móveis e
um servidor central usando tecnologias General Packet Radio Service (GPRS) e Wi-Fi de forma a
operarem de forma autónoma. Além de desenvolver as comunicações foi criada uma plataforma web
de forma a visualizar as amostras recolhidas pelas estações e também monitorizar e configurar o
seu estado de forma remota. Neste documento é apresentado o estado de arte em áreas de onde
foi desenvolvido o trabalho, especialmente nas comunicações veiculares. São descritas as soluções
implementadas de forma a cumprir os objetivos desta tese e também avaliado o funcionamento e
desempenho das soluções. A avaliação efetuada ao trabalho desenvolvido provou o correto funcio-
namento das funcionalidades e um desempenho bastante satisfatório das mesmas.
Palavras Chave
Rede de Sensores Móveis, Rede Veicular, Comunicação Máquina a Máquina, Monitorização At-
mosférica
v
Índice
1 Introdução 1
1.1 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Estado de Arte 5
2.1 M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Global Positioning System (GPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 General Packet Radio Service (GPRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Arquitetura 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 IEEE 802.11b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3 IEEE 802.11a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.4 IEEE 802.11g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.5 IEEE 802.11p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.6 802.11 - Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Vehicular ad-hoc network (VANET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Encaminhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1.A Uso de redes de transportes públicos . . . . . . . . . . . . . . . . . . . 15
2.5.1.B Encaminhamento Geocast . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1.C Encaminhamento Hierárquico . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1.D Encaminhamento em Disruption Tolerant Networks (DTNs) . . . . . . . 17
2.5.2 Implementação de redes VANET . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Monitorização Atmosférica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 Projeto QualAr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 Estação Móvel MS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.3 The Copenhagen Wheel Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.4 Projeto MASON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Arquitetura 21
3.1 Arquitetura Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1 Estação Móvel (MS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2 Servidor Central (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
vii
3.1.3 Gateway (GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Arquitetura Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Mapa com dados atmosféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Monitorização da Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2.A Monitorização das MS . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2.B Monitorização dos GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Configuração remota das MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3.A Enviar Ficheiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3.B Reiniciar Estação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3.C Configurar Parâmetros . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Modelo de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Comunicações GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Comunicações Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2.A Nós gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2.B Caraterísticas da rede Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2.C Protocolo de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Implementação 41
4.1 Servidor (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2.A Website URBISNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2.B Interface para as comunicações dirigidas ao CS via GW e MS . . . . . 50
4.2 Gateway (GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1 Equipamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.2 Funcionamento Lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.3 Configuração e desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Estação Móvel (MS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1 Equipamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.2 Configuração e desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.2.A Módulo GE863-PRO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.2.B Comunicações GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.2.C GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.2.D Comunicação Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.3 Funcionamento Lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5 Avaliação 65
5.1 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.1 Monitorização de parâmetros da Estação . . . . . . . . . . . . . . . . . . . . . . 66
5.1.2 Configuração de parâmetros Estação . . . . . . . . . . . . . . . . . . . . . . . . 67
viii
5.1.3 Envio de ficheiro para Estação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Testes de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.1 Recolha de amostras em ambiente móvel . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1.A Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1.B Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1.C Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.2 Desempenho das comunicações Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.2.A Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.2.B Cenário de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.2.C Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6 Conclusões e Trabalho Futuro 77
6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Bibliografia 81
Anexo A Parâmetros de monitorização e configuração das estações móveis A-1
Anexo B Protocolo de comunicação Wi-Fi na estação móvel B-1
Anexo C Resultados do Teste de Desempenho das Comunicações Wi-Fi C-1
ix
Lista de Figuras
2.1 Arquitetura de rede do sistema GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Diagrama exemplo da arquitetura dos modos infraestrutura e ad-hoc . . . . . . . . . . . 11
2.3 Throughput em função da distância entre nós no cenário urbano. . . . . . . . . . . . . . 18
2.4 Estação de monitorização QualAr localizada em São Julião da Barra, Oeiras . . . . . . 19
3.1 Diagrama simples da ligação entre os componentes. . . . . . . . . . . . . . . . . . . . . 22
3.2 Protótipo da estação móvel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Diagrama do hardware da estação de monitorização. . . . . . . . . . . . . . . . . . . . 24
3.4 Diagrama de interação do CS e restantes elementos. . . . . . . . . . . . . . . . . . . . 24
3.5 Diagrama exemplificativo da funcionalidade de encaminhador do gateway. . . . . . . . 25
3.6 Opções de visualização das amostras no website . . . . . . . . . . . . . . . . . . . . . 26
3.7 Visualização dos dados de uma das amostras recolhidas. . . . . . . . . . . . . . . . . . 27
3.8 Tabela de estações móveis no website URBISNET. . . . . . . . . . . . . . . . . . . . . . 28
3.9 Tabela de Gateways no website URBISNET. . . . . . . . . . . . . . . . . . . . . . . . . 28
3.10 Área de configuração das estações MS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Diagrama da operação do modelo de configuração das estações no website URBISNET. 29
3.12 Topologia de rede em estrela das comunicações GPRS . . . . . . . . . . . . . . . . . . 31
3.13 Diagrama da comunicação via GPRS entre estação móvel e servidor central. . . . . . . 32
3.14 Esquema de endereçamento dos nós MS. . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.15 Esquema de endereçamento dos nós GW. . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.16 Exemplo do uso dos parâmetros configuração de disseminação de informação no pro-
tocolo Wi-Fi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.17 Exemplo de uma mensagem enviada em broadcast por um nó gateway. . . . . . . . . . 37
3.18 Diagrama de comunicação entre duas estações móveis. . . . . . . . . . . . . . . . . . . 38
3.19 Diagrama de comunicação entre estação móvel e gateway. . . . . . . . . . . . . . . . . 39
4.1 Interface gráfica do MySQL Query Browser. . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Website URBISNET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Tabela no website URBISNET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Tecnologias usadas na implementação do website URBISNET. . . . . . . . . . . . . . . 47
4.5 Exemplo de interação entre a estrutura implementada num pedido de configuração
(reiniciar). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
xi
4.6 Foto do equipamento usado como gateway, o Asus EeeBox EB1007. . . . . . . . . . . 52
4.7 Diagrama da comunicação entre as estações e o GW no envio de dados. . . . . . . . . 52
4.8 Diagrama de fluxo do funcionamento do gateway. . . . . . . . . . . . . . . . . . . . . . . 53
4.9 Foto do módulo C10/3 AarLogic da RoundSolutions. . . . . . . . . . . . . . . . . . . . . 55
4.10 Ponto de acesso Asus WL-330gE integrado na estação móvel. . . . . . . . . . . . . . . 56
4.11 Foto do kit de desenvolvimento STK-S4 com os módulos C10/3 AarLogic e Ethernet
integrados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.12 Eclipse com plugin Telit para programação dos módulos GE863-PRO. . . . . . . . . . . 57
4.13 Dados enviados pelo recetor Global Positioning System (GPS) para a interface série. . 59
5.1 Esquema de configuração para os testes funcionais. . . . . . . . . . . . . . . . . . . . . 66
5.2 Website URBISNET: pedido de monitorização de parâmetros. . . . . . . . . . . . . . . 67
5.3 Estação móvel: recebe pedido de monitorização e responde via GPRS. . . . . . . . . . 67
5.4 Website URBISNET: resultado do pedido de monitorização de parâmetros. . . . . . . . 68
5.5 Website URBISNET: pedido de configuração de parâmetros. . . . . . . . . . . . . . . . 68
5.6 Website URBISNET: mensagem de espera de contacto com estação móvel. . . . . . . 69
5.7 Estação móvel: recebe pedido de configuração, responde ao servidor e reinicia. . . . . 69
5.8 Website URBISNET: confirmação de sucesso da configuração de parâmetros. . . . . . 69
5.9 Website URBISNET: interface da opção de envio de ficheiro. . . . . . . . . . . . . . . . 70
5.10 Estação móvel: recebe ficheiro enviado pelo website com sucesso. . . . . . . . . . . . 70
5.11 Percurso realizado com a estação móvel neste teste. . . . . . . . . . . . . . . . . . . . . 71
5.12 Amostras recolhidas durante o ensaio, visualizadas no site do Urbisnet. . . . . . . . . . 73
5.13 Ilustração de zona de conectividade entre a estação e o gateway no percurso realizado. 73
5.14 Percurso realizado com as estações móveis MS1 e MS2. . . . . . . . . . . . . . . . . . 75
B.1 Diagrama simplificado do protocolo de comunicação Wi-Fi no nó estação móvel. . . . . B-2
C.1 Gráfico de comparação do RTT medido entre as duas MS nos ensaios realizados a 20
km/h com diferentes tamanhos de amostras. . . . . . . . . . . . . . . . . . . . . . . . . C-2
C.2 Gráfico de comparação do Round-Trip Time (RTT) medido entre as duas MS nos en-
saios realizados a 20 km/h e 40 km/h com um tamanho médio de amostras. . . . . . . C-3
xii
Lista de Tabelas
2.1 Descrição dos campos apresentados numa linha RMC do protocolo NMEA-0183 [3] . . 8
2.2 Débitos binários do GPRS em kbit/s [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Camadas do Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Comparação das características das normas 802.11 apresentadas. . . . . . . . . . . . 13
4.1 Atributos da tabela ”urbisnet_samples” na base de dados. . . . . . . . . . . . . . . . . . 44
4.2 Atributos da tabela ”urbisnet_stations” na base de dados. . . . . . . . . . . . . . . . . . 44
4.3 Atributos da tabela ”urbisnet_gateways” na base de dados. . . . . . . . . . . . . . . . . 44
4.4 Principais especificações do EeeBox EB1007 e router WL-500g Premium v2 . . . . . . 51
4.5 Características do módulo C10/3 AarLogic da RoundSolutions. . . . . . . . . . . . . . . 55
5.1 Tabela resumo dos ensaios de desempenho Wi-Fi. . . . . . . . . . . . . . . . . . . . . . 75
A.1 Parâmetros da estação móvel passíveis de configuração e monitorização no website
URBISNET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
A.2 Parâmetros de estatísticas de funcionamento da estação possíveis de monitorizar no
website URBISNET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
C.1 Tabela com os valores de RTT (em ms) medidos entre as duas MS nos vários ensaios. C-2
C.2 Tabela com os valores de RTT (em ms) medidos entre a estação MS1 e o gateway. . . C-3
C.3 Tabela dos tempos de processamento (em ms) na estação MS2. . . . . . . . . . . . . . C-4
xiii
Lista de Acrónimos
A-STAR Anchor-based Street and Traffic Aware Routing
AODV Ad-hoc On-demand Distance Vector
APN Access Point Name
BSS Basic Service Set
BSSID Basic Service Set Identification
CCK Complementary Code Keying
CSS Cascading Style Sheets
DBPSK Differential Binary Phase Shift Keying
DQPSK Differential Quadrature Phase Shift Keying
DSR Dynamic Source Routing
DSRC Dedicated Short Range Communications
DTN Disruption Tolerant Networks
ETSI European Telecommunications Standards Institute
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GPS Global Positioning System
GPSR Greedy Perimeter Stateless Routing
GSM Global System for Mobile Communications
HLR Home Location Register
HSR Hierarchical State Routing
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
xv
IBSS Independent BSS
IEEE Institute of Electrical and Electronics Engineers
ISM Industrial, Scientific and Medical
M2M Machine to Machine
MAC Medium Access Control
MANET Mobile ad-hoc network
MEO Medium Earth Orbit
NAT Network Address Translation
NMEA National Marine Electronics Association
OFDM Orthogonal Frequency Division Multiplexing
PHP PHP: Hypertext Preprocessor
PLE Path Loss Exponent
QAM Quadrature Amplitude Modulation
RTT Round-Trip Time
SA Selective Availability
SFTP SSH File Transfer Protocol
SGSN Serving GPRS Support Node
SSH Secure Shell Protocol
TDMA Time Division Multiple Access
UTM Universal Transverse Mercator
V2I Vehicle-to-Infrastructure
V2R Vehicle-to-Roadside
V2V Vehicle-to-Vehicle
VANET Vehicular ad-hoc network
WAVE Wireless Access in Vehicular Environments
WLAN Wireless Local Area Network
xvi
1Introdução
Contents1.1 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1
1.1 Motivação e Objetivos
A monitorização de gases atmosféricos, especialmente os poluentes e que põem em risco a
saúde das pessoas quando encontrados em elevadas concentrações, tem sido algo que tem preo-
cupado as autoridades de saúde pública e os próprios cidadãos cada vez mais. Os sistemas mais
comuns de monitorização de gases poluentes são de elevadas dimensões e de carácter estático, lo-
calizados em certos pontos do país, com especial concentração nas cidades devido à aglomeração
de agentes poluentes nestes cenários. Outros módulos, apesar de não serem fixos, continuam a
ter dimensões consideráveis e a sua mobilidade passa pelo transporte a reboque entre localizações
(não funcionando enquanto são transportados). As grandes dimensões e elevados custos de produ-
ção e manutenção são alguns dos principais problemas destas estações. No entanto, os métodos
e instrumentos utilizados nestas estações produzem resultados de grande qualidade e precisão no
que toca à medição das concentrações de gases atmosféricos.
O projeto URBISNET, liderado pelo Instituto de Sistemas e Robótica (ISR) do Instituto Superior
Técnico com o apoio da Fundação para a Ciência e Tecnologia (FCT), tem como principal objetivo
a criação de mapas de concentração de gases poluentes e estimar as características dos campos
de poluição na cidade de Lisboa. Para tal serão usadas estações de reduzidas dimensões e baixo
custo, com capacidade para monitorizar os gases atmosféricos, georeferenciando as amostras e
enviando-as a um servidor central. Estas características fazem deste sistema um meio complementar
à monitorização feita pelas estações fixas/transportáveis existentes. O facto de serem de reduzidas
dimensões e terem um sistema de comunicação que suporta mobilidade são pontos chave para a
instalação destas estações numa rede de transportes públicos, como são os autocarros da Carris na
cidade de Lisboa. Isto permitirá recolher dados atmosféricos durante o percurso dos autocarros, ge-
rando amostras com uma densidade espacial muito superior às existentes, fornecidas por estações
fixas. Por outro lado, a qualidade das medições será inferior quando comparada com as adquiridas
pelas estações fixas.
Esta tese de mestrado realiza-se numa fase intermédia do projeto URBISNET, utilizando no seu
desenvolvimento a própria estação móvel, protótipo desenvolvido na tese de mestrado de David
Quelhas [2]. Foram desenvolvidos módulos de comunicação usando General Packet Radio Ser-
vice (GPRS) e Wi-Fi de forma a ser possível aos dados, recolhidos pelas estações móveis, serem
enviados para um servidor onde são armazenados, tratados e disponibilizados. Além dos dados de
monitorização atmosférica foi dada importância ao desenvolvimento de uma plataforma de gestão
remota das estações móveis, uma vez que o objetivo é colocar as estações em autocarros de trans-
portes públicos da Carris, onde o processo de configuração ou monitorização ”in loco” é uma tarefa
difícil. Os objetivos do trabalho desta tese, de uma forma resumida, incluíram:
• Desenvolvimento e implementação do modelo de funcionamento das estações móveis (in-
cluindo comunicações GPRS);
2
• Armazenamento e disponibilização dos dados adquiridos pelas estações móveis num servidor
central;
• Criação do protocolo de comunicação via Wi-Fi e implementação nos elementos de rede a ele
destinados de forma a minimizar a utilização das comunicações GPRS;
• Criação de uma ferramenta web de gestão remota que permita monitorizar o estado dos nós
da rede;
Com o trabalho desenvolvido nesta tese pretende-se que os dados atmosféricos, recolhidos pelas
estações móveis, sejam entregues ao servidor central para aí serem armazenados e para que sejam
posteriormente, em trabalho a ser desenvolvido também no seio do projeto URBISNET, utilizados na
criação de mapas de poluição.
1.2 Estrutura do Documento
Este documento está estruturado em 6 capítulos descritos de seguida. No capítulo 2 é apre-
sentado o estado de arte em conceitos abordados nesta tese e fundamentos tecnológicos de relevo
no desenvolvimento. O capítulo 3 apresenta a arquitetura das soluções desenvolvidas. O capítulo
4 aborda os temas relacionados com a implementação e desenvolvimento das soluções. No ca-
pítulo 5 são apresentados alguns testes realizados de forma a validar as soluções desenvolvidas.
Finalmente, no capítulo 6 são apresentadas as conclusões deste relativas a este documento e são
também descritas áreas de trabalho futuro relacionado com o desenvolvimento desta tese.
3
4
2Estado de Arte
Contents2.1 M2M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Global Positioning System (GPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 General Packet Radio Service (GPRS) . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Vehicular ad-hoc network (VANET) . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Monitorização Atmosférica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5
Neste capitulo são apresentados conceitos, tecnologias e protocolos que estão diretamente rela-
cionados com o desenvolvimento deste projeto e/ou serviram de base de investigação para o mesmo.
Inicialmente é descrito o conceito de Machine to Machine (M2M), comunicações entre máquinas
sem intervenção humana. De seguida é apresentada a tecnologia de posicionamento Global Po-
sitioning System (GPS) e nas duas secções que se seguem as tecnologias General Packet Radio
Service (GPRS) e IEEE 802.11, utilizadas nas comunicações deste projeto. Ainda neste capítulo
abordam-se as redes veiculares, incluindo protocolos de encaminhamento e exemplos de implemen-
tações de redes veiculares. Finalmente são referidos projetos na área da monitorização atmosférica
que servem de motivação e/ou referência para esta tese.
2.1 M2M
As comunicações M2M são um tópico bastante atual e a prova disso é o facto do European
Telecommunications Standards Institute (ETSI) estar a criar standards nesta área. O ETSI define
M2M como comunicações sem (ou de reduzida) intervenção humana, usando tecnologias com ou
sem fios, combinando eletrónica, telecomunicações e tecnologias de informação de modo a ligar
dispositivos e sistemas remotos [5]. Esta estandardização surge para definir requisitos que podem
ser tidos em conta no desenvolvimento de sistemas M2M e para que haja interoperabilidade entre
redes e serviços, levando ao desenvolvimento de mais aplicações nesta área.
Numa das normas já criadas pelo ETSI para comunicações M2M [6], são especificados requisitos
genéricos do serviço que podem ser implementados nos sistemas M2M. Entre esses requisitos
estão a capacidade dos sistemas M2M permitirem comunicação entre aplicações M2M utilizando
vários meios como SMS, GPRS e acesso IP. Refere-se também que um dispositivo M2M deve ser
capaz de comunicar com outros dispositivos de forma ponto a ponto.
Além dos requisitos de carácter genérico, são apresentados outros requisitos na mesma norma:
• requisitos de gestão de falhas - requisitos ao nível de monitorização do serviço e desco-
berta e recuperação remota de falhas. Monitorização de acordos de nível de serviço (SLA) se
aplicável (especialmente se houver contrato de comunicações móveis com um operador);
• requisitos de gestão de configurações - permitir auto-configuração, sem intervenção hu-
mana, ou alteração das configurações remotamente;
• requisitos de gestão de contabilidade - capacidade de monitorizar o uso dos seus recursos,
nomeadamente as comunicações feitas utilizando redes móveis de operadores;
• requisitos funcionais - requisitos definindo as metodologias de recolha e envio de informação,
baseada em eventos, periódica ou a pedido;
• requisitos de segurança - os requisitos de segurança passam principalmente pela autentica-
ção dos agentes intervenientes na rede M2M, confidencialidade, integridade e privacidade da
informação transferida;
6
• requisitos de nome, numeração e endereçamento - identificar univocamente cada interveni-
ente na rede e conseguir estabelecer comunicação usando endereços apropriados (endereço
IP por exemplo).
O ETSI está também a preparar relatórios técnicos com casos de uso exemplificativos de algu-
mas utilizações de M2M, estando alguns já concluídos e outros em versão draft (versão em desen-
volvimento), como por exemplo o relatório de cenários de medições inteligentes [7] ou de recursos
consumidos como gás, água ou eletricidade em habitações.
2.2 Global Positioning System (GPS)
A navegação terrestre baseada em satélites começou algum tempo antes do aparecimento do
GPS, nomeadamente os sistemas TRANSIT e Timation da Marinha dos Estados Unidos e o projeto
621B da Força Aérea dos Estados Unidos [8]. O desenvolvimento do GPS começou em 1973 e
apenas em 1994 ficou totalmente operacional com um total de 24 satélites em órbita. Pouco tempo
depois, o serviço GPS foi disponibilizado para uso civil (anteriormente apenas usado para efeitos
militares nos Estados Unidos) mas de forma limitada, visto o sinal GPS ter sido propositadamente
degradado para limitar a eficácia da localização. Esta degradação propositada do sinal ficou conhe-
cida como Selective Availability (SA). Apenas em Maio de 2000 foi retirado esse erro 1 tornando o
sistema muito mais exato, possibilitando erros inferiores a 10 metros. Este facto veio ajudar a proli-
ferar o uso de GPS, para fins de localização e acerto de relógios, em várias atividades 2 como por
exemplo na agricultura, aviação, ambiente, lazer, viação, estando também largamente espalhados
pela sociedade quer na eletrónica de consumo, como é o caso dos telemóveis, quer em muitos au-
tomóveis existentes no mercado.
O sistema GPS é constituído por uma constelação de 24 satélites Medium Earth Orbit (MEO)
equipados com relógios de elevada precisão, denominados relógios atómicos, em que a posição
(altitude, longitude e latitude) do elemento a localizar na Terra é calculada por meio do cálculo de
distâncias entre os satélites e esse mesmo elemento, de forma a ser possível fazer a triangulação
da sua posição. Para tal são necessários no mínimo 4 satélites, 3 para inferir a posição física do
elemento à superfície da terra e um quarto para calcular desvios do relógio [8] e tornar a localização
mais precisa. A principal desvantagem do sistema GPS é a necessidade de linha de vista entre os
satélites e o recetor terrestre devido à elevada frequência usada neste sistema, cerca de 1.5 GHz,
tornando-o particularmente sensível à obstrução causada, por exemplo, por edifícios ou vegetação
elevada que podem bloquear completamente o sinal ou criar o fenómeno de multi-caminho, cau-
sando erros na localização. Atualmente estão a ser desenvolvidos outros sistemas de navegação
1Selective Availability : degradação do sinal GPS http://www.pnt.gov/public/sa/2Exemplos de uso da tecnologia GPS: http://www.gps.gov/applications
7
por satélite, quer globais como o europeu Galileo 3, o chinês Compass 4 ou o russo Glonass 5, quer
regionais como por exemplo o sistema da Índia, o IRNSS 6. As principais motivações para estes
sistemas em desenvolvimento são a melhor precisão e cobertura, criando um sistema alternativo ao
sistema Americano GPS para que não haja dependência total do mesmo.
A grande maioria dos recetores GPS disponibilizam a informação numa interface série seguindo
um protocolo definido pela National Marine Electronics Association (NMEA), sendo o mais comum
o NMEA-0183. Este protocolo é caraterizado por debitar, com uma certa periodicidade, mensagens
com várias informações que são possíveis obter através do sistema GPS. Entre as informações
estão dados do recetor, nomeadamente velocidade, latitude, longitude, altitude e também sobre os
satélites GPS (como por exemplo o número de satélites em vista e a qualidade do sinal recebido de
cada um deles).
$GPRMC,151230.487,A,3723.2475,N,12158.3416,W,0.13,309.62,120211, ,*10
Acima está representado uma das linhas de informação fornecidas pelo protocolo NMEA-0183,
trata-se de informação RMC (Recommended Minimum Data). A informação apresentada nessa linha
é explicada na tabela 2.1.
Nome Exemplo DescriçãoID Mensagem $GPRMC Mensagem RMC do sistema GPS
Hora UTC 151230.487 hhmmss.sssEstado A A = Dados válidos | V = Dados inválidosLatitude 3723.2475 ddmm.mmmm
Indicador N/S N N = Norte | S = SulLongitude 12158.3416 ddmm.mmmm
Indicador E/W W E = Este | W = OesteVelocidade 0.13 Velocidade em nós
Ângulo em relação ao chão 309.62Data 120211 ddmmaa - 12 de Fevereiro de 2011
Checksum *10
Tabela 2.1: Descrição dos campos apresentados numa linha RMC do protocolo NMEA-0183 [3]
2.3 General Packet Radio Service (GPRS)
O serviço Global System for Mobile Communications (GSM) é o sistema de comunicações móveis
de segunda geração mais implementado e utilizado mundialmente, com cerca de 3.45 mil milhões de
ligações 7. O GPRS é um serviço criado com o intuito de permitir comutação de pacotes usando a
interface rádio do serviço de comunicação de voz GSM, adaptado aos requisitos típicos do tráfego de
3Sistema de navegação global europeu, Galileo: http://ec.europa.eu/enterprise/policies/satnav/galileo/index_en.htm
4Sistema de navegação global chinês, Compass: http://www.beidou.gov.cn/index.html5Sistema de navegação global russo, Glonass: http://new.glonass-iac.ru/en/6Sistema de navegação regional indiano, IRNSS: http://www.india-defence.com/reports-18947Dados do mercado de telecomunicações do GSM World: http://www.gsmworld.com/newsroom/market-data/market_
data_summary.htm
8
pacotes. Tal como o GSM, o GPRS é baseado também num sistema de Time Division Multiple Access
(TDMA) em que pode usar até 8 slots da trama TDMA para comutação de pacotes. A quantidade
de slots usada pode ser ditada por um valor mínimo caso o operador estipule tal parâmetro e pela
utilização da rede móvel, uma vez que o GPRS utiliza tipicamente apenas os slots desocupados.
O débito conseguido numa ligação GPRS, além de estar associado ao número de slots utilizados,
está também associado à codificação usada. Esta codificação é variável conforme a taxa de erros
no meio e pode ter uma codificação mais robusta que oferece menos débito ou menos robusta mas
que oferece mais débito. As velocidades conseguidas numa ligação GPRS podem ser visualizadas
na tabela 2.2.
Codificação 1 Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8 SlotCS-1 9.05 18.2 27.15 36.2 45.25 54.3 63.35 72.4CS-2 13.4 26.8 40.2 53.6 67 80.4 93.8 107.2CS-3 15.6 31.2 46.8 62.4 78 93.6 109.2 124.8CS-4 21.4 42.8 64.2 85.6 107 128.4 149.8 171.2
Tabela 2.2: Débitos binários do GPRS em kbit/s [4]
Como já referido anteriormente, o GPRS é uma evolução da rede GSM para suportar comutação
de pacotes, e o seu sucesso deve-se, em parte, às poucas alterações que os operadores tiveram de
fazer na sua rede para o implementar em larga escala. Na arquitetura do GSM apenas se adicio-
naram dois novos elementos, o Gateway GPRS Support Node (GGSN) e o Serving GPRS Support
Node (SGSN). O primeiro, o GGSN, é o elemento que interliga a rede GPRS a redes externas de
comutação de pacotes (como por exemplo a Internet) e tem funcionalidades de encaminhamento e
firewall.
O SGSN tem como funções encaminhamento, handover e contabilização de dados para fins de
cobrança ao cliente. Talvez a característica mais importante deste elemento seja o handover e a ca-
pacidade de identificar a mobilidade do terminal GPRS na rede mantendo a sua conectividade quer
ele mude de célula ou de zona controlada por outro SGSN, neste último caso, enviando o contexto
da ligação para o novo SGSN [9].
Figura 2.1: Arquitetura de rede do sistema GPRS
A identificação IP dos terminais GPRS pode ser feita de duas maneiras: atribuição fixa ou di-
9
nâmica de IP [10]. A atribuição fixa de IP envolve que o Home Location Register (HLR), elemento
que funciona como base de dados de informações relacionadas com o cliente da operadora, guarde
também o endereço IP. A segunda solução envolve uma atribuição de IPs dinâmica. Quando a atri-
buição é dinâmica, o GGSN é contactado pelo SGSN utilizando para isso o endereço Access Point
Name (APN) (parâmetro fornecido no estabelecimento de uma ligação GPRS) que identifica o GGSN
a ser usado de forma a devolver um endereço IP para o terminal. O endereço IP poderá ser privado
ou público, dependendo do APN utilizado. No caso do endereço ser público o terminal pode facil-
mente ser endereçado a partir de uma rede externa, podendo ser uma vantagem caso se pretenda
fornecer serviços a partir desse terminal móvel. Caso o endereço seja privado o terminal acede
facilmente a redes externas mas o contrário já é impossível devido à utilização de Network Address
Translation (NAT).
A capacidade de elevada mobilidade numa comunicação sem fios e a elevada cobertura geográfica
por parte dos operadores levou que a tecnologia GPRS fosse amplamente utilizada, como previsto na
altura em que foi apresentada [9], em soluções bastante diversas como por exemplo na localização e
monitorização de frotas, pontos de venda móveis, transmissão de dados de sensores e ligações de
alarmes a centrais.
2.4 IEEE 802.11
As redes locais sem fios, em Inglês Wireless Local Area Network (WLAN), têm um conjunto de
vantagens como a flexibilidade, a capacidade de estabelecer redes ad-hoc, não necessitar de ca-
bos para estabelecer ligação e a sua robustez em casos de catástrofe. Por outro lado, apresentam
algumas desvantagens em relação às redes com fios, como a baixa largura de banda, maior susce-
tibilidade a interferências, limitação de débito e alcance devido a obstáculos físicos. O standard do
Institute of Electrical and Electronics Engineers (IEEE) 802.11, amplamente denominado como Wi-Fi,
é com certeza o mais conhecido e implementado para redes locais sem fios. Este standard, com a
primeira versão final lançada em 1997, veio definir especificações para as duas primeiras camadas
do modelo OSI, a camada Medium Access Control (MAC) (do nível de ligação de dados) e a camada
física. De referir que um dos objetivos ao estabelecer esta norma foi usar espectro livre de licença
para operar, usando por isso frequências a 2.4GHz e 5GHz que pertencem às bandas Industrial,
Scientific and Medical (ISM), que podem ser usadas de forma livre para comunicações.
AplicaçãoApresentação
SessãoTransporte
RedeLigação de Dados
Física
Tabela 2.3: Camadas do Modelo OSI
10
A primeira versão do standard nunca teve muito sucesso, muito por culpa dos baixos débitos
que conseguia alcançar nas primeiras especificações do modelo físico, entre 1 e 2 Mbit/s. Por este
motivo nunca teve grande sucesso comercial e também porque avanços no desenvolvimento de
modelos físicos levaram ao aparecimento de uma emenda a este standard poucos anos depois, a
norma 802.11b.
2.4.1 Arquitetura 802.11
A norma 802.11 especifica dois tipos de arquitetura para as suas redes sem fios quanto ao tipo
de infraestrutura, designadamente o modo com infraestrutura e o modo ad-hoc (sem infraestrutura).
O modo infraestrutura é baseado num ponto central, denominado ponto de acesso (AP), onde os
terminais (STA) estão ligados sem fios. O conjunto formado pelo ponto de acesso e pelos terminais
a si associados é denominado Basic Service Set (BSS). Adicionalmente existe uma arquitetura
independente de pontos de acesso, constituída apenas por terminais que comunicam entre si e
formam uma Independent BSS (IBSS). Esta arquitetura de redes denomina-se ad-hoc.
Figura 2.2: Diagrama exemplo da arquitetura dos modos infraestrutura e ad-hoc
2.4.2 IEEE 802.11b
Em 1999, dois anos depois de ter sido finalizado o standard original 802.11, estava pronta uma
emenda designada 802.11b. A principal alteração foi feita ao nível físico do protocolo, adicionando
uma modulação Complementary Code Keying (CCK) que permite um débito de 5.5 e 11 Mbit/s além
dos 1 e 2 Mbit/s que as modelações Differential Binary Phase Shift Keying (DBPSK) e Differential
Quadrature Phase Shift Keying (DQPSK) permitem, respetivamente. Tal como na norma original, a
norma b opera em diferentes frequências (ou canais) dentro do espectro dos 2.4 GHz. A existência
de canais em frequências diferentes permite fazer um planeamento de cobertura com diferentes
pontos de transmissão, minimizando a interferência entre eles. Segundo a norma existem 13 canais
definidos para território europeu (11 para os Estados Unidos e 14 para o Japão) mas para efeitos
de minimização de interferências, apenas se conseguem criar células com 3 canais não sobrepostos
11
em frequências (totalmente disjuntas). O aumento de débito e a sua conclusão pouco depois do
standard original, fez do 802.11b a norma com maior sucesso comercial dentro da família 802.11,
levando à sua massiva adoção.
2.4.3 IEEE 802.11a
Criada também em 1999, tal como a 802.11b, a norma 802.11a distingue-se bastante desta, no-
meadamente na zona do espectro eletromagnético, uma vez que ocupa a banda dos 5 GHz ao invés
dos 2.4 GHz. A zona do espectro a que opera foi também um entrave quer no desenvolvimento de
equipamentos quer na sua normalização na Europa [4], levando o 802.11b a melhor na altura da
massificação das redes locais sem fios. Por outro lado, a norma 802.11a define uma nova camada
física que permite atingir elevados débitos. Em primeiro lugar utiliza Orthogonal Frequency Division
Multiplexing (OFDM), que consiste em enviar os dados por portadoras diferentes, minimizando assim
o efeito de interferência inter-simbólica a que as comunicações a elevadas frequências estão mais
sujeitas. A outra chave dos elevados débitos são as modulações usadas: BPSK, QPSK e sobretudo
as modelações n-Quadrature Amplitude Modulation (QAM), neste caso com ’n’ igual a 16 e 64. Com
estas modulações, em conjunto com um código de correção de erros, atingem-se débitos até 54
Mbit/s. Apesar das maiores velocidades, devido à maior largura de banda de cada canal, a comu-
nicação entre elementos da rede está limitada a uma distância inferior ao 802.11b, degradando-se
mais rapidamente a comunicação (e respetivos débitos conseguidos) quando se aumenta a distân-
cia ou se introduzem obstáculos físicos entre os elementos intervenientes. No entanto o espectro na
zona dos 5 GHz tem menos equipamentos e tecnologias a operar, o que pode ser uma vantagem
para evitar interferências em locais com elevada concentração de sinais na zona dos 2.4 GHz.
2.4.4 IEEE 802.11g
A norma 802.11g foi concluída em 2003 e é considerada uma evolução da norma 802.11b, uma
vez que opera na mesma banda e permite débitos mais elevados, garantindo compatibilidade direta
e inversa entre equipamentos que implementem essas normas. Para garantir débitos até 54Mbit/s,
à semelhança do 802.11a, utiliza OFDM com código de correção de erros em conjunto com as
modulações apresentadas para o 802.11b. Esta norma conseguiu um sucesso global ao nível do
802.11b, visto ter custos de produção idênticos e melhores débitos. Débitos esses que, apesar
de estarem ao nível do 802.11a, pecam na realidade por ter um débito inferior para o utilizador
(throughput) e, mais uma vez, operando na populada faixa dos 2.4 GHz os equipamentos estão mais
sujeitos a interferências de outros dispositivos.
2.4.5 IEEE 802.11p
De todas as normas 802.11 referidas, a IEEE 802.11p é a mais recente de todas, tendo sido
apenas finalizada em Julho de 2010 8. O objetivo do IEEE ao iniciar os trabalhos nesta norma foi8Linha de tempo dos grupos de trabalho do IEEE 802.11 http://grouper.ieee.org/groups/802/11/Reports/802.11_
Timelines.htm
12
desenvolver alterações ao standard 802.11 para ser usado no espectro das Dedicated Short Range
Communications (DSRC), regulamentado nos Estados Unidos na banda dos 5.9 GHz [11]. Adicio-
nalmente, esta norma é também conhecida por Wireless Access in Vehicular Environments (WAVE),
uma vez que as comunicações no espectro DSRC serão exclusivas para comunicações entre veí-
culos e entre veículos e infraestruturas rodoviárias. Com o objetivo de permitir comunicação entre
veículos, existem alguns constrangimentos a ter em conta como, por exemplo, a elevada mobilidade
dos agentes e o reduzido tempo em que os intervenientes poderão comunicar entre si (por exemplo,
um veiculo em alta velocidade que passa por um elemento localizado na berma da estrada).
As alterações mais significativas feitas nesta norma foram ao nível MAC. Foram simplificados os
processos de adesão a um grupo, ou BSS, de forma a haver menos overhead e tornar o processo
mais rápido. Existe também um identificador de BSS, ou Basic Service Set Identification (BSSID) de
carácter universal para que se possa receber e enviar informação para terminais que estejam perto
mas que não estejam no mesmo grupo BSS.
Do ponto de vista da camada física é bastante parecido ao 802.11a, visto operar perto das mes-
mas frequências e de utilizar OFDM. As principais diferenças residem no número inferior de canais
(7 canais WAVE), na largura de banda de cada (apenas 10 MHz, em contraste com os 20 MHz do
802.11a) e na duração de símbolo que é duplicada para oferecer uma maior resistência ao desvane-
cimento.
2.4.6 802.11 - Conclusões
Ao longo dos anos o IEEE foi lançando emendas à norma original 802.11 para, sobretudo, ofere-
cer maiores débitos. De forma a sumarizar as normas apresentadas anteriormente, estão represen-
tadas na tabela 2.4 algumas característica que as permitem comparar.
Norma 802.11b 802.11a 802.11g 802.11pDébito (Mb/s) 11 54 54 27Throughput (Mb/s) 6 32 22 12Alcance em linha 100 50 100 1000de vista (m)
Vantagens Custo Interferência Custo Mobilidadee Velocidade e Velocidade e alcance
Desvantagens Interferência Custo e Alcance Maior interferência Custo
Tabela 2.4: Comparação das características das normas 802.11 apresentadas.
2.5 Vehicular ad-hoc network (VANET)
As redes designadas Vehicular ad-hoc network (VANET) derivam da terminologia de Mobile ad-
hoc network (MANET), em que os elementos móveis da rede Ad-Hoc são especificados como sendo
veículos [12] e daí a variante da nomenclatura. As VANET distinguem-se das MANET e outras redes
ad-hoc por terem uma topologia altamente dinâmica, maior probabilidade de alguns nós de estarem
desconectados da rede, não haver problemas de fornecimento de energia ou de armazenamento
13
de informação, necessidade de endereçar elementos geograficamente e necessidade de conseguir
baixos valores de atraso no envio de informação. As redes veiculares (VANET) são objeto de in-
vestigação e pesquisa atual dado o crescimento do interesse em dotar os veículos de mecanismos
de comunicação entre si para aumentar a segurança das estradas em todo o mundo. Os principais
elementos de investigação estão centralizados nas tecnologias de comunicação DSRC (como, por
exemplo, o 802.11p já referido), encaminhamento, segurança, privacidade, consumo energético, en-
tre outros [13]. Em termos de comunicações veiculares existem dois paradigmas de comunicação,
distinguindo os intervenientes:
• Vehicle-to-Vehicle (V2V) - Comunicação entre veículos num modelo ad-hoc, recorrendo a tec-
nologias como 802.11p que permitem um elevado alcance e é adequada às condições de ele-
vada mobilidade dos veículos. Comunicação privilegiada para alertar os veículos circundantes
de perigos num curto espaço de tempo;
• Vehicle-to-Infrastructure (V2I) ou Vehicle-to-Roadside (V2R) - Comunicações entre o veiculo
e uma rede com infraestrutura viária fixa. Útil para receber informações relevantes sobre a
envolvente da localização do veículo ou como meio de aumentar a conectividade com veículos.
Este tipo de comunicações viárias ainda não está amplamente disponível e encontra-se em fase
de investigação e desenvolvimento, envolvendo fabricantes automóveis, unidades de investigação
académica e organizações governamentais. Pretende-se que seja devidamente regulamentada visto
que a sua principal função é a segurança viária, daí que a interoperabilidade entre os diversos equi-
pamentos, quer presentes nos veículos quer nas vias, terá de ser assegurada.
2.5.1 Encaminhamento
O encaminhamento em redes veiculares (VANET) tem sido tema de bastante estudo e investi-
gação. O estudo destas redes tem sido também focado na criação de novos protocolos de enca-
minhamento, muitas vezes recorrendo à modificação de protocolos existentes para redes MANET.
A modificação de protocolos direcionados para MANET, como o Ad-hoc On-demand Distance Vec-
tor (AODV) [14] e o Dynamic Source Routing (DSR) [15], deve-se ao facto de ambas partilharem
os mesmos princípios, nomeadamente a auto-organização, auto-gestão, baixa largura de banda e o
facto das transmissões ocorrerem a reduzida distância. Para melhorar a performance de protocolos
destinados a MANET, são levados em conta o posicionamento dos nós e limitações na sua movimen-
tação, tendo em conta em ambiente veicular urbano, para efetuar predições sobre o posicionamento
dos nós e o estado da ligação.
Em [16] é analisada a performance do protocolo AODV em ambiente de auto-estrada com vários
nós distribuídos de forma uniforme pelo percurso. Sendo o AODV um protocolo que funciona na des-
coberta de rotas desde uma origem para um certo destino, apenas quando é necessário comunicar,
assim que é estabelecida uma rota entre esses dois pontos, esta terá um tempo de vida bastante
limitado devido à elevada dinâmica da rede. O artigo referido indica que, em média, uma rota criada
pelo AODV dura apenas 5 segundos, necessitando assim de criar outra rota. São sugeridas duas
14
alterações ao AODV, a PRAODV e a PRAODV-M. A primeira acrescenta parâmetros às mensagens
de pedido (RREQ) e resposta (RREP) de criação de rota, incluindo a velocidade e localização do
nó origem que permite aos nós subsequentes calcularem uma estimativa da duração da rota. No
final o nó origem sabe qual o valor mínimo do tempo de vida estimado das rotas que recebe para o
mesmo destino, e usa a que tem um menor número de saltos (tal como o AODV). No entanto, antes
de se atingir o valor estimado de vida da ligação, é enviado novo pedido de rota de maneira a que
não se tenha de esperar pela perda de pacotes para haver a inicialização do processo de escolha de
nova rota. Já o processo PRAODV-M escolhe a rota que apresenta o maior valor estimado do tempo
de vida. A avaliação dos três protocolos levou à conclusão que o PRAODV-M é o que apresenta
melhores resultados em termos de rácio de entrega de pacotes. No entanto nem sempre consegue
resultados acima do AODV.
2.5.1.A Uso de redes de transportes públicos
A existência de veículos com rotas bem definidas num ambiente citadino, como a rede pública de
autocarros ou elétricos, pode ajudar no encaminhamento de tráfego. Foi a esta conclusão que che-
garam os autores do artigo [17]. Neste artigo foi usado um simulador de redes para criar um cenário
urbano com vários veículos simulando o seu padrão de movimentação. Chegaram à conclusão, que
neste ambiente conseguem apenas 76.15% de rácio de entrega de pacotes. No entanto, adicionado
três autocarros com rotas bem definidas no simulador, conseguiram um aumento de rácio de entrega
de pacotes de 5.7%. Isto levou os autores a afirmarem que a existência de uma rede em modo infra-
estrutura utilizando autocarros públicos iria melhorar a performance de comunicação entre quaisquer
outros veículos geograficamente distantes. Em [18] é proposto um protocolo de encaminhamento
denominado Anchor-based Street and Traffic Aware Routing (A-STAR), baseado no principio descrito
acima. Este protocolo é baseado em posicionamento e em âncoras ao longo do caminho definido
onde os pacotes têm de passar. Estas âncoras podem ser calculadas estaticamente usando mapas
da cidade e de transportes públicos para identificar rotas com maior conectividade. Podem também
ser calculadas dinamicamente, baseando-se para isso nas informações de tráfego veicular, esco-
lhendo rotas com maior densidade de veículos onde a conectividade será superior. Com esta solu-
ção, quer usando calculo estático ou dinâmico, foram obtidos resultados bastante bons em termos de
rácio de entrega de pacotes, chegando a perto de 90% quando a rede tem 500 nós, que é um valor
bastante melhor quando comparado com outras aproximações que não têm em conta informações
de tráfego dentro da cidade, como por exemplo o Greedy Perimeter Stateless Routing (GPSR) [19],
onde para as mesmas condições se consegue apenas um rácio de 70%.
2.5.1.B Encaminhamento Geocast
Existe um conceito de encaminhamento de informação que ganhou bastante importância com as
VANET, o geocast [20]. O geocast é uma vertente do multicast, onde os destinatários são nós geo-
15
graficamente localizados numa determinada região, denominada zona de relevância (em inglês Zone
of Relevance, ZOR). O geocast implica o uso de meios de localização dos nós como por exemplo
o GPS. Este tipo de encaminhamento traz vantagens para aplicações que precisem de enviar infor-
mação que é apenas relevante numa determinada ZOR, como por exemplo um alerta de acidente
ou trabalhos na estrada. Dos algoritmos de encaminhamento do tipo Geocast, os mais simples são
o Simple Flooding e o Location Based Multicast (LBM). O primeiro funciona enviando uma mensa-
gem com uma localização especificada (a ZOR) a todos os nós adjacentes, inundando a rede. Os
recetores da mensagem são os responsáveis por verificar se pertence à ZOR especificada e decidir
se o conteúdo é do seu interesse ou não. É um sistema extremamente simples e robusto mas que
peca pela quantidade de mensagens desnecessárias enviadas para a rede, tornando-o ineficiente. O
LBM por outro lado inunda a rede apenas para nós localizados numa certa zona de encaminhamento
de forma a que o pacote chegue até à ZOR, tornando-o mais eficiente que o Simple Flooding. Um
exemplo de alternativa às técnicas de inundação da rede até chegar à ZOR é a aplicada pelo pro-
tocolo Unicast Routing with Area Delivery (URAD). Este protocolo usa um encaminhamento unicast
baseado no GPSR para encaminhar o pacote até à ZOR. Cada nó que receba o pacote verifica se se
encontra já na ZOR, fazendo broadcast se já estiver nessa zona ou continuando o encaminhamento
unicast até o pacote alcançar um nó nessa zona.
2.5.1.C Encaminhamento Hierárquico
Em termos de encaminhamento, podemos definir três tipos de algoritmos: algoritmos de en-
caminhamento planos (todos os nós têm o mesmo tipo de comportamento), algoritmos de enca-
minhamento assistidos por posição geográfica (o caso do geocast) e finalmente os algoritmos de
encaminhamento hierárquicos (com nós que desempenham diferentes funções). Em [21] é proposto
um protocolo para redes ad-hoc móveis MANET hierárquico, denominado Hierarchical State Rou-
ting (HSR). Os nós neste protocolo são caracterizados com base na sua localização geográfica e
funcionalidade de forma a criar clusters físicos (conjunto de nós que partilham uma região física) e
partições lógicas na rede. Os nós são divididos em 3 tipos lógicos: nós cluster-head, nós gateway e
nós internos. Cada cluster tem de ter pelo menos um nó cluster-head que funciona como coordena-
dor das transmissões dentro do cluster. Cada nó possui um identificador NodeID(endereços MAC)
e ainda uma identificação da hierarquia onde se encontra, Hierachical ID (HID). Esta identificação
hierárquica de cada nó é constituída pelos NodeID dos nós hierarquicamente acima desse nó (e pelo
NodeID do próprio) concatenados. Desta forma é suficiente usar a identificação hierárquica de forma
a entregar um pacote a qualquer nó da rede HSR. Usando este esquema hierárquico, supondo que
cada cluster tem ’N’ nós e que existem ’M’ níveis hierárquicos, num protocolo convencional, have-
ria O(NM ) entradas na sua tabela de encaminhamento. Neste protocolo o número de entradas na
tabela de encaminhamento é substancialmente mais reduzido, apenas O(N ×M).
16
2.5.1.D Encaminhamento em Disruption Tolerant Networks (DTNs)
As Disruption Tolerant Networks (DTN) são redes onde não existe um caminho permanente entre
dois pontos da rede (conectividade intermitente), muitas vezes devido à mobilidade, falhas de ener-
gia ou outros constrangimentos associados aos nós da rede. Esta característica das DTN implica
que os algoritmos de encaminhamento sejam do tipo ”store and forward” (armazena e encaminha)
em que as mensagens recebidas são guardadas para poderem ser encaminhadas para o próximo
nó assim que haja conectividade.
Um dos algoritmos mais conhecidos neste tipo de redes é o encaminhamento epidémico [22], um
algoritmo baseado em inundação de mensagens que faz com que cada mensagem seja ”infetada”
a todos os membros da rede uma vez que partem do principio que não existe nunca conectividade
direta entre a origem e o destino da mensagem. Desta forma maximiza-se a probabilidade da men-
sagem chegar ao destino devido à disseminação da mesma pelos nós da rede.
2.5.2 Implementação de redes VANET
O projeto Drive-In está a ser desenvolvido por várias entidades como a Carnegie Mellon Univer-
sity (CMU) e a Universidade do Porto (UP). Tem como primeiro objetivo desenvolver protocolos para
VANETs explorando o posicionamento dos nós e o contexto da informação de forma a aproveitar as
melhores oportunidades de transmissão e disseminação de informação nos locais de interesse da
rede viária. Sendo um projeto bastante direcionado para a componente de rede viária, o objetivo
seguinte passa por usar os protocolos desenvolvidos para criar um sistema inteligente e descentrali-
zado de encaminhamento de viaturas usando rotas otimizadas.
Para a implementação do projeto foi criado hardware de comunicações, baseado em IEEE 802.11p
e também um simulador de VANETs denominado Divert 2.0 que servirá para testar as várias etapas
do projeto. A implementação do hardware para as comunicações IEEE 802.11p foi uma necessidade
deste projeto uma vez que os equipamentos comerciais eram escassos, o que levava a preços consi-
derados proibitivos. Talvez uma das componentes mais interessantes deste projeto é o uso de cerca
de 450 táxis da cidade do Porto para testes de campo, o maior volume de elementos de teste numa
rede veicular com 802.11p do mundo.
O projeto CARLINK 9, criado por um consórcio de universidades europeias, teve como objetivo
desenvolver um sistema de comunicações sem fios para usar em comunicações entre carros. No
âmbito deste projeto foram conduzidos testes para verificar a fiabilidade das tecnologias 802.11b/g
na transmissão de dados entre 2 veículos quer estando ambos estáticos quer em movimento [23].
Após a realização dos testes concluíram que em situações sem movimento, conseguiam débitos na
ordem dos 0.5 MB/s a uma distância de 20 metros com uma baixa perda de pacotes (abaixo dos9Website do projeto CARLINK: http://carlink.lcc.uma.es/index.html
17
0.3%). Quando a distância foi aumentada para 100 metros, os débitos desceram para cerca de 0.3
MB/s. Num cenário com mobilidade urbana (a 50 Km/h), em que a distância entre veículos não
ultrapassou os 50 metros, foram conseguidos resultados bastante diferentes em várias tentativas.
Isto acontece devido aos fatores externos como o aparecimento de obstáculos (carros e pessoas, por
exemplo). Ainda assim, foram conseguidos valores mínimos de 0.07 MB/s e máximos de 0.65 MB/s
de débitos. A perda de pacotes em alguns casos excedeu os 14%. Com estes dados concluíram
que estas tecnologias permitem débitos razoáveis em casos em que os veículos estejam parados
mesmo que a distâncias elevadas (100 metros). Quando em movimento num cenário urbano, e
devido a fatores externos variáveis, o débito pode ser bastante inferior, não sendo ideal transmitir
grandes quantidades de dados nestas circunstâncias.
No artigo The Impact of Radio Propagation on Inter-vehicle Wireless Communication [1] é
também apresentado um conjunto de testes efetuados em alguns ambientes reais (campo aberto,
sub-urbano e urbano) com tecnologia 802.11b colocada em veículos, de forma a perceber a dete-
rioração do sinal nestes cenários com veículos em movimento. A métrica usada foi uma variante
da perda de percurso (path loss), denominada exponente da perda de percurso ou Path Loss Expo-
nent (PLE). Uma das conclusões a que chegaram foi que em comunicações em linha de vista, nos
três cenários que contemplam, o valor médio de PLE é idêntico em todos mas no cenário urbano,
devido às suas características (edifícios mais perto da estrada, tráfego automóvel superior, etc.), é
aquele onde os valores são menos fiáveis, devido a um desvio padrão superior. Em cenários de co-
municação sem linha de vista, o aumento do PLE é considerável em cenários sub-urbano e urbano
devido ao sinal percorrer uma maior distância (relativamente ao caminho direto) e ser atenuado (de-
vido a reflexões e refrações). Nos testes realizados no cenário urbano, foi ainda medido o throughput
conseguido em função da distância dos nós (apresentado na figura 2.3), com valores máximos na
ordem dos 55 Kb/s. Nesse mesmo gráfico é feita a distinção entre os valores obtidos em linha de
vista e sem linha de vista onde é evidenciado o alcance superior nas comunicações com linha de
vista, como seria de esperar.
Figura 2.3: Throughput em função da distância entre nós no cenário urbano. A cinzento claro são os valoresregistados com comunicação em linha de vista e a cinzento escuro sem linha de vista [1]
18
2.6 Monitorização Atmosférica
2.6.1 Projeto QualAr
As estações de monitorização de gases atmosféricos mais comuns são as estações fixas, con-
tentores de média dimensão localizados em vários pontos do país. O projeto QualAr 10, pertencente
ao Ministério do Ambiente e Ordenamento do Território Português, tem estações dispersas por Por-
tugal (com maior concentração nas grandes cidades) que monitorizam os valores de vários gases
atmosféricos ao longo do tempo. Estas estações, como a representada na figura 2.4, são de grandes
dimensões, ocupando um espaço considerável, causam elevado impacto visual e têm um consumo
energético elevado. Os dados recolhidos por estas estações são também enviados para um servidor
central e disponibilizados no website do projeto. A seu favor têm a fiabilidade dos dados recolhi-
dos, que é bastante superior à que estações de reduzidas dimensões, equipadas com pequenos
sensores, conseguem obter.
Figura 2.4: Estação de monitorização QualAr localizada em São Julião da Barra, Oeiras
2.6.2 Estação Móvel MS1
O desenvolvimento de uma estação móvel, de pequenas dimensões, para monitorização de ga-
ses atmosféricos foi o tópico da tese de mestrado de Vasco Carvalho [24]. O protótipo criado continha
sensores de gases atmosféricos (dióxido e monóxido de carbono, ozono, dióxido de enxofre e dió-
xido de azoto) e temperatura em que os seus valores eram comunicados a um servidor central via
GPRS ou SMS. Os dados eram posteriormente guardados numa base de dados e disponibilizados
via web. A estação estava equipada com GPS, o que permitia georeferencar as amostras e também
estabelecer uma distância mínima entre amostras a enviar para o servidor.
2.6.3 The Copenhagen Wheel Project
A crescente utilização da bicicleta como meio de transporte em grandes cidades europeias, no-
meadamente em Copenhaga, levou à criação de um projeto 11 por parte do MIT de uma roda de
bicicleta capaz de oferecer às pessoas um sistema que as ajudasse nos seus percursos. O sistema10Website do projeto QualAr: http://www.qualar.org/11Website do projeto The Copenhagen Wheel Project: http://senseable.mit.edu/copenhagenwheel/
19
é semelhante ao KERS (Kinetic Energy Recovery System), que permite armazenar em baterias a
energia utilizada nas travagens para ser reutilizada posteriormente, facilitando assim as deslocações
em percursos com desníveis. Mas este sistema não se limitou a ajudar as pessoas nos seus percur-
sos, uma vez que foram instalados diversos sensores como por exemplo de monóxido de carbono
(CO), monóxido e dióxido de azoto (NOx), ruído (dB), humidade relativa e temperatura. Em conjunto
com comunicações Bluetooth e GPRS, é possível monitorizar os dados recolhidos em aparelhos de
eletrónica pessoal (telemóveis, por exemplo) ou envia-los, de forma anónima, para um servidor cen-
tral do projeto de forma a essa informação ser tratada e disponibilizada. A utilidade desta informação
passa não só pela monitorização das concentrações de gases poluentes nos locais onde são recolhi-
das, mas também pela ajuda que fornece no planeamento das políticas ambientais e de transportes
das cidades onde são utilizados.
2.6.4 Projeto MASON
O projeto MASON: Metropolitan Area Sensing and Operation Network 12, desenvolvido pelo Com-
plex Engineered Systems Lab da universidade de Tsinghua na China, teve como objetivo criar uma
rede de sensores de baixo custo monetário e energético, tolerante a falhas nos elementos da rede,
altamente tolerante a atrasos e composta por um elevado número de nós. Os protótipos, com as
características referidas, são facilmente colocados em veículos ou transportados por pessoas de
forma a ter uma rede de nós móveis. A comunicação entre estes nós é oportunista, descentralizada
e baseada num mecanismo de ”guardar, transportar e encaminhar” uma vez que trocam informação
entre si sempre que se encontram numa zona de cobertura comum das suas interfaces rádio. Além
dos nós móveis existem hotspots que servem de nós intermediários entre a rede de nós móveis e
a Internet. Estes elementos servem para que, sempre que um nó entra na zona de cobertura de
um hotspot, toda a informação nele armazenada ser encaminhada para um servidor, via Internet, de
forma a ser processada.
Tal como evidenciado pelos autores, uma rede com estas características pode ser usada para vários
fins, desde infraestrutura para uma rede de comunicações de emergência ou até mesmo um sistema
de monitorização dos níveis de poluição atmosférica.
12Website do projeto MASON: http://sensor.ee.tsinghua.edu.cn/dyn_show.php?dyn_id=9
20
3Arquitetura
Contents3.1 Arquitetura Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Arquitetura Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Modelo de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
21
Neste capitulo é apresentada, primeiramente, a arquitetura geral que mostra a interligação dos
três componentes principais deste projeto: a estação móvel, o gateway e o servidor central. São
explicadas também as suas principais características e funções. Na secção seguinte é apresentada
a arquitetura funcional desenvolvida, nomeadamente as funções de visualização dos dados atmos-
féricos recolhidos e as operações de monitorização e configuração dos nós da rede implementados
numa ferramenta web. Por último, são apresentados os modelos de comunicação implementados ao
nível das tecnologias GPRS e Wi-Fi de forma a ser possível oferecer as funcionalidades pretendidas.
3.1 Arquitetura Geral
Dada a transversalidade do trabalho desenvolvido nesta tese, quer no tipo de componentes que
são utilizados, quer nas comunicações entre eles, pretende-se que esta secção dê uma perspetiva
geral desses mesmos componentes, referindo as suas funções e principais características. A in-
terligação dos componentes é também referida de forma a que se perceba a arquitetura como um
todo.
Na figura 3.1 é apresentada de forma simples como estão ligados os componentes do sistema.
Figura 3.1: Diagrama simples da ligação entre os componentes.
Nesta tese foram desenvolvidas as comunicações e modo de funcionamento dos três compo-
nentes, criando modelos de comunicação que permitem que as amostras recolhidas pelas estações
cheguem até ao servidor central. Devido à característica móvel e de difícil acesso das estações, uma
vez que serão colocadas em veículos, existe a capacidade para as monitorizar e configurar remota-
mente.
As comunicações Wi-Fi entre as estações e gateways surgem devido à necessidade de minimizar a
utilização de comunicações GPRS (pagas) através da rede móvel de um operador. No entanto, as
comunicações via GPRS, não são inteiramente descartadas uma vez que para oferecer serviços de
monitorização e configuração remota é necessário conectividade constante, algo que não consegue
22
ser assegurado numa rede veicular peer-to-peer.
3.1.1 Estação Móvel (MS)
A Estação móvel, também referida como MS, é um equipamento móvel de pequenas dimensões
cuja função principal é a aquisição de dados atmosféricos através de um conjunto de sensores que a
integram, enviando-os para um servidor de forma a serem armazenados. Os sensores incluídos na
estação móvel são de dióxido de carbono (CO2), monóxido de carbono (CO), ozono (O3), dióxido de
azoto (NO2), temperatura e humidade relativa. A estação está igualmente equipada com um recetor
GPS de forma a georeferenciar as amostras recolhidas. Ao nível de comunicações, a estação possui
interfaces Wi-Fi e GPRS que são utilizadas com diferentes propósitos (devidamente explicados mais
em frente na secção 3.3).
O protótipo da estação móvel (ver figura 3.2) foi desenvolvido no âmbito da tese de mestrado em
Eng.a Eletrónica de David Quelhas [2]. A sua arquitetura está representada na figura 3.3.
Figura 3.2: Protótipo da estação móvel.
3.1.2 Servidor Central (CS)
O Servidor Central, também referido como CS, é um elemento que acumula algumas funções
como a receção e armazenamento dos dados atmosféricos enviados pelas estações móveis. Dispo-
nibiliza também uma interface web (website URBISNET) para visualização dos dados armazenados,
assim como ferramentas para monitorização e configuração das estações móveis. Para fornecer es-
tas funcionalidades, o servidor acumula características de um servidor web com uma base de dados.
Em termos de conectividade, este elemento está ligado à Internet de forma a poder interagir com as
estações móveis, gateways e disponibilizar acesso ao website URBISNET através deste meio (como
exemplificado na figura 3.4).
23
Figura 3.3: Diagrama do hardware da estação de monitorização. [2]
Figura 3.4: Diagrama de interação do CS e restantes elementos.
24
3.1.3 Gateway (GW)
O gateway , também referido como GW, serve de ponte de comunicação entre as estações mó-
veis (utilizando Wi-Fi) e o servidor central (através de ligação com fios à Internet). A sua função é
bastante simples mas a sua importância é extrema, dado que sem ele a comunicação entre as es-
tações móveis e o servidor central teria de se realizar exclusivamente via GPRS. Para que possam
servir de intermediários entre as estações móveis, colocadas em autocarros de transportes públicos,
a sua localização ideal será em paragens de autocarros, sendo essa característica aprofundada em
detalhe na secção 3.3.2.A, relativa ao modelo de comunicação Wi-Fi.
Figura 3.5: Diagrama exemplificativo da funcionalidade de encaminhador do gateway.
3.2 Arquitetura Funcional
Do ponto de vista funcional existem três funções principais neste projeto, todas elas acessíveis
através de uma interface web: disponibilização de um mapa com os dados recolhidos pelas estações;
a monitorização dos elementos da rede (MSs e GWs); configuração das estações móveis.
3.2.1 Mapa com dados atmosféricos
O primeiro passo para se conseguir disponibilizar os dados atmosféricos num mapa passa pela
recolha da informação correta na própria estação móvel de forma a ser possível, por exemplo, re-
ferenciar geograficamente os dados. Assim, definiu-se uma estrutura de dados a ser criado pela
estação móvel sempre que adquire valores dos sensores atmosféricos, sendo ela a seguinte:
Marca temporal, identificação da estação, latitude, longitude, CO2, CO, O
3, NO
2,
temperatura, humidade;
A Marca temporal (timestamp) vem no formato AAAA-MM-DD HH:MM:SS e é obtida através da in-
formação recolhida por GPS. A existência da marca temporal é essencial de forma a identificar tem-
poralmente os valores atmosféricos recolhidos, algo fundamental na criação de mapas de poluição.
A identificação da estação corresponde ao número que serve de identificador único atribuído a
cada estação móvel. Desta forma é possível saber, univocamente, que estação produziu os dados.
Os valores de latitude e longitude são obtidos através de GPS e estão no formato de graus deci-
mais. As coordenadas de latitude e longitude são os elementos que permitem posicionar as amostras
25
num mapa do globo terrestre. Os elementos CO2, CO, O
3, NO
2, temperatura e humidade correspon-
dem aos valores recolhidos pelos sensores existentes na estação. A estrutura de dados, enviada
por GPRS ou Wi-Fi (dependendo do modo de funcionamento da estação), chega ao servidor central
onde é processada e armazenada na base de dados.
Um exemplo dos dados recebidos pelo servidor central, de uma recolha de dados dos sensores at-
mosféricos por parte de uma estação móvel, é apresentado de seguida:
2012-2-23 15:52:43,1,38.737141,-9.303741,0.732422,1.709595,0.244751,2.011108,
9.83,44.95;
Os dados acima respeitam a estrutura explicada anteriormente e a sua dimensão é de aproxima-
damente 89 carateres (ou bytes) por cada amostra, podendo variar um pouco dependendo de alguns
parâmetros como a temperatura, o identificador da estação ou a dimensão da marca temporal.
No que respeita à periodicidade da recolha das amostras por parte das estações móveis, é pos-
sível que as mesmas sejam recolhidas com um período de amostragem fixo ou com uma distância
física (percorrida pelo veículo onde a estação está instalada) fixa entre amostras. É possível não só
configurar em qual destes dois modos opera a estação móvel, mas também qual o valor da distância
temporal (em segundos) ou da distância percorrida pela estação (em metros).
No website URBISNET, as amostras recolhidas são apresentadas num mapa, usando de forma
integrada a tecnologia do Google Maps. Na área de visualização do site é possível escolher ver
dados de uma estação em particular (desde que tenha enviado amostras) ou todas, sendo também
possível mostrar dados registados entre duas datas em particular (especificando uma data de inicio
e fim), como representado na figura 3.6.
Figura 3.6: Opções de visualização das amostras no website
26
No mapa surgem as marcações que indicam a localização onde as amostras foram recolhidas.
Selecionando esse marcador é possível obter as informações relativas aos sensores de gases, tem-
peratura, humidade, data e hora da aquisição, e também a estação responsável, como é possível ver
na figura 3.7.
Figura 3.7: Visualização dos dados de uma das amostras recolhidas.
3.2.2 Monitorização da Rede
Tendo uma rede composta por elementos com elevada mobilidade (estações móveis) e outros
fixos mas distribuídos ao longo de uma vasta área da cidade (gateways), é importante que se consiga
aferir sobre o seu estado de forma remota.
3.2.2.A Monitorização das MS
A monitorização das estações móveis é feita de duas formas, uma passiva e outra ativa. A forma
passiva é aquela que leva informações ao servidor sobre o funcionamento da estação sem que este
a requisite. Essa informação chega de duas formas:
• Mensagens com endereço IP da ligação GPRS - Informação enviada e armazenada no servi-
dor sempre que a estação liga a sua interface GPRS, para que o servidor conheça sempre o
endereço IP da estação e possa contacta-la em operações de monitorização ou configuração;
• Amostras com dados atmosféricos - Devido ao identificador temporal destas mensagens é pos-
sível saber, através dos dados armazenados na base de dados, qual foi a amostra mais recente
enviada pela estação.
Cruzando estes dois tipos de informação que chegam ao servidor e estão armazenados na base
de dados é possível saber qual a última vez, conhecida pelo servidor, que a estação esteve ativa (ver
figura 3.8).
A monitorização ativa passa pela capacidade, a partir do website URBISNET, de enviar pedidos
a uma estação em particular. Esses pedidos podem ser de dois tipos:
27
Figura 3.8: Exemplo de tabela criada no website URBISNET com as estações registadas na base de dados ea informação relativa à monitorização passiva.
• Monitorização - Questiona a estação em causa para que esta devolva informações dos parâme-
tros de configuração ou dados informativos sobre o funcionamento da estação, nomeadamente
utilização da ligação GPRS. Os parâmetros estão disponíveis no anexo A;
• Log de Sistema - Capacidade de requisitar à estação as últimas 10 entradas do registo de
funcionamento da mesma;
De realçar que as operações de monitorização ativa, assim como as operações de configuração,
necessitam que a estação esteja ligada, o que significa que é possível que, por mais recente que seja
a informação apresentada na tabela como ”Última actividade registada”, o pedido falhe se a estação
ficou incontactável (por perda de alimentação, por exemplo).
3.2.2.B Monitorização dos GW
Além da monitorização às estações móveis, é possível monitorizar de forma passiva o funciona-
mento dos nós gateway uma vez que enviam mensagens periódicas de ”I’m Alive” para o servidor
central via Internet. A periodicidade destas mensagens é configurável no próprio gateway. No web-
site URBISNET é possível ver, para cada gateway, a data de chegada da última mensagem ”I’m
Alive” assim como a data em que é esperada a próxima mensagem, uma vez que o gateway envia
para o servidor o período em minutos entre mensagens ”I’m Alive”. Caso não receba a mensagem
”I’m Alive” no período esperado, a zona da tabela referente àquele gateway no website fica com uma
coloração vermelha alertando para o facto de não ter recebido a mensagem quando esperado, como
ilustrado na figura 3.9.
Figura 3.9: Alerta para o facto de não ter sido recebida mensagem ”I’m Alive” do gateway 1 quando esperado.
Opta-se por um sistema periódico de mensagens do lado do gateway uma vez que, ao contrário
do que sucede com as estações ligadas via GPRS, não deverá ser necessário minimizar a utilização
28
da rede entre gateway e o servidor.
3.2.3 Configuração remota das MS
Como referido anteriormente, as estações móveis são caraterizadas por terem uma elevada mo-
bilidade e por estarem colocadas em autocarros públicos. Estes fatores dificultam o seu acesso e
fazem com que seja desejável que as operações de manutenção e configuração se possam fazer
de forma remota. Com essa motivação, foi criado, também no website do projeto URBISNET, uma
secção de configuração das estações móveis. Nessa secção é possível selecionar as estações a
configurar e escolher qual o tipo de intervenção a realizar:
Figura 3.10: Área de configuração das estações MS.
• Enviar Ficheiro - Permite enviar, por exemplo, uma nova versão do programa URBISNET para
a estação;
• Reboot / Reiniciar - Reiniciar a estação de forma remota;
• Configurar Parâmetros - Alterar parâmetros de configuração da estação.
Após realizar uma das operações para uma ou mais estações surge uma mensagem de espera
enquanto o servidor contacta as estações e aguarda a confirmação da realização do pedido. Poste-
riormente é apresentada uma tabela que refere se a operação foi bem sucedida (ou não) em cada
uma das estações a que foi dirigido o pedido de configuração.
Figura 3.11: Diagrama da operação do modelo de configuração das estações no website URBISNET.
3.2.3.A Enviar Ficheiro
A funcionalidade de enviar um ficheiro para a estação móvel oferece a possibilidade de fazer uma
atualização à versão do software na estação sem que para isso se tenha de recolher a estação do
autocarro. A partir do site é possível escolher o ficheiro a enviar para a estação, assim como a versão
29
do programa que é enviado, de forma a ser possível identifica-lo posteriormente. O ficheiro precisa
de ser um arquivo comprimido contendo um script de execução (com o nome ”install.sh”) que deve
conter as instruções de instalação e o executável da nova versão do programa. Na verdade, este
sistema de envio de ficheiro é bastante mais flexível, sendo possível não só instalar uma nova versão
do programa, mas também fazer qualquer alteração à configuração da estação, bastando para isso
essas instruções estarem contidas no script que é enviado. De forma a a verificar a integridade dos
dados recebidos, evitando problemas na instalação derivados de erros de transmissão, é calculado
o valor da hash Message-Digest algorithm 5 (MD5) com 128 bits e comparado com o valor enviado
pelo servidor central. Caso não coincidam, os dados recebidos são descartados.
3.2.3.B Reiniciar Estação
A operação de reiniciar as estações é uma função simples que apenas envia à estação uma
informação para reiniciar o sistema, voltando a operar de acordo com as configurações após esse
processo. É uma operação útil quando, através das operações de monitorização, se deteta algo de
errado com o funcionamento da estação e se pretende reiniciar para que volte a um estado correto.
3.2.3.C Configurar Parâmetros
A possibilidade de configurar alguns parâmetros da estação de forma remota é uma funcionali-
dade bastante útil. Os parâmetros de configuração permitem alterar não só configurações da estação
ao nível das ligações GPRS e Wi-Fi mas também do seu próprio funcionamento, por exemplo, para-
metrizar a periodicidade da recolha de amostras. A partir do website URBISNET é possível especi-
ficar novos valores para os parâmetros de configuração e enviar para as estações. Os parâmetros
de configuração são também apresentados sempre que se requisita a informação de monitorização
a uma estação e constam no anexo A.
3.3 Modelo de Comunicação
As comunicações neste projeto desempenham um papel fundamental, uma vez que o sistema de
recolha de dados atmosféricos estará inserido num ambiente de elevada mobilidade, levando a que
um sistema de comunicação fixa ou de recolha de dados ”in-loco” seja inviável. Apesar do principal
objetivo ser o envio das amostras das estações móveis para o servidor central, existe ainda a ne-
cessidade de realizar monitorização e configuração remota das estações, o que leva à necessidade
de ter um meio de comunicação que permita ter conectividade entre as estações e o servidor cen-
tral sempre que possível. Estando a estação móvel equipada com tecnologias GPRS e Wi-Fi foram
criados protocolos de comunicação usando estas duas tecnologias de forma a que fosse possível
às estações enviarem em ambas as modalidades os dados das amostras recolhidas. Apesar de o
objetivo ser minimizar as comunicações via GPRS, foi implementada uma forma de envio direto ao
servidor central das amostras por este meio, uma vez que se cria assim uma forma de redundância
de envio das amostras caso se pretenda uma independência total das comunicações Wi-Fi por algum
30
motivo. As estações móveis estarão sempre configuradas com uma ligação GPRS para que possam
ser oferecidas as operações de monitorização e configuração a partir do servidor central.
3.3.1 Comunicações GPRS
As estações móveis estão equipadas com tecnologia GSM/GPRS, sendo mesmo um dos requi-
sitos iniciais do projeto URBISNET. Este tipo de comunicações permite estabelecer uma ligação de
pacotes à Internet através da rede de um operador móvel. Esta ligação é útil ao projeto pois permite
ter uma elevada conectividade com o servidor central (apesar da elevada mobilidade das estações) e
também oferece uma menor latência quando comparada com a rede Wi-Fi, que possui uma conetivi-
dade bastante esparsa e não permitiria implementar as operações de monitorização e configuração,
conforme especificado nos requisitos do projeto. A comunicação implementada tem uma topologia
em estrela, permitindo que cada estação comunique diretamente com o servidor central e vice-versa.
No entanto, apesar da topologia em estrela, não existe comunicação entre estações móveis.
Figura 3.12: Topologia de rede em estrela das comunicações GPRS
A comunicação bidirecional entre as estações móveis e o servidor central via GPRS serve de
suporte para várias funções base do projeto URBISNET:
No sentido Estação Móvel → Servidor Central, a ligação GPRS é usada para o envio das
amostras recolhidas pelas estações e também do endereço IP da interface GPRS. Apesar de um
dos objetivos ser o do envio das amostras através da ligação Wi-Fi, o envio das amostras por GPRS
foi implementado e as estações podem ser configuradas para enviar os dados a partir desta ligação.
O envio do endereço IP da ligação GPRS acontece sempre que a estação ativa a mesma, de forma
a manter-se contactável pelo servidor central. O envio desta informação surge da necessidade de
implementação da comunicação no sentido inverso, pois o servidor central precisa de conhecer o en-
dereço IP de cada estação de forma a endereça-las para pedidos de monitorização ou configuração.
No entanto é de referir que o ato de enviar o endereço IP da ligação GPRS das estações móveis
implica que esse endereço IP seja público. Uma vez que estas comunicações estão dependentes
31
da implementação da rede GPRS dos operadores móveis, o mesmo se passa com os endereços
IP atribuídos aos dispositivos com ligação GPRS(como já referido na secção 2.3 sobre a tecnolo-
gia GPRS). É possível que operadores diferentes tomem opções diferentes na implementação das
suas redes de dados. Esta possibilidade pode comprometer as comunicações no sentido do servi-
dor central para as estações móveis pois, caso os endereços IP atribuídos às ligações GPRS sejam
endereços privados (apenas com significado dentro da rede do operador móvel), impossibilitam o
endereçamento das estações móveis por parte do servidor central.
Figura 3.13: Diagrama da comunicação via GPRS entre estação móvel e servidor central.
A comunicação no sentido Servidor Central → Estação Móvel suporta os pedidos de monito-
rização e configuração realizados a partir do website URBISNET. Como referido anteriormente, a
concretização destas comunicações apenas é possível pois cada estação móvel envia o endereço
IP da sua ligação GPRS para ser armazenado na base de dados do servidor central. Assim, sempre
que seja necessário enviar um pedido para uma estação móvel, o servidor utiliza o endereço IP ar-
mazenado na sua base de dados para endereçar a estação em questão. Os pedidos são enviados a
partir do servidor central, passando pela Internet e pela rede de dados do operador móvel até chegar
às estações móveis, como ilustrado na figura 3.13. As estações estão programadas para receber os
pedidos do servidor central com a seguinte estrutura base:
MS[ID_ESTAÇÃO]:[TIPO_DE_PEDIDO]
O valor [ID_ESTAÇÃO] é usado para a estação confirmar que o pedido é realmente dirigido a si,
verificando se esse valor é igual ao seu identificador. O [TIPO_DE_PEDIDO] é um valor que identifica
o tipo de pedido enviado pelo servidor central e pode ter os seguintes valores:
1 - Pedido de configuração de parâmetros da estação. Além da estrutura de mensagem apresentada
anteriormente, neste pedido são enviados tuplos com parâmetro e valor a serem alterados na
estação. Exemplo:
MS1:1,sampling_time:40,sample_mode:0;
2 - Pedido de monitorização dos parâmetros da estação e outras informações relevantes. Exemplo:
MS1:2;
3 - Pedido de reinicialização da estação. Exemplo:
MS1:3;
4 - Pedido de envio de ficheiro para a estação móvel. Além da estrutura de mensagem apresentada
anteriormente, neste pedido são enviados o nome do ficheiro, tamanho do ficheiro (em bytes),
32
versão do ficheiro e valor MD5 do ficheiro. Exemplo:
MS1:4,Urbisnet_NEW,40000,1.0,18732FAB238BB22;
5 - Pedido de monitorização do ficheiro de log da estação móvel. Além da estrutura de mensagem
apresentada anteriormente, neste pedido é também enviado o número de linhas do ficheiro que
se pretende receber. Exemplo:
MS1:5,10;
Após o envio dos pedidos, o servidor aguarda sempre resposta por parte das estações móveis,
quer ela seja mesmo necessária (como são os casos dos pedidos de monitorização 1 e 5), quer nos
pedidos em que não se espera informação útil (como os pedidos de configuração 2, 3 e 4), em que
o servidor espera apenas uma confirmação do sucesso ou insucesso da operação.
3.3.2 Comunicações Wi-Fi
A existência de comunicações Wi-Fi nas estações móveis surge como forma de minimizar o uso
das comunicações GPRS, nomeadamente o seu uso para envio dos dados atmosféricos para o
servidor central. No entanto, a existência de uma comunicação entre estações móveis com tecnologia
Wi-Fi, de nada serve se não conseguirem fazer chegar os dados ao servidor central. Uma vez
que diretamente isso é impossível devido à localização física do servidor, surge a necessidade de
existência dos nós gateway para servirem de ponte nessa comunicação, entre os nós móveis e o
servidor central.
3.3.2.A Nós gateway
Fazer com que a informação gerada nas estações móveis chegue ao servidor central, através
da interface Wi-Fi, leva à necessidade de utilizar nós gateway que sirvam de intermediários entre
as estações móveis e o servidor central no envio dos dados das amostras atmosféricas. Estes nós
estavam previstos no inicio do projeto URBISNET, sendo elementos fixos, colocados em paragens de
autocarros com conectividade à Internet. De facto, a sua colocação em paragens de autocarros de
forma a minimizar o número de nós gateway, maximizando a conectividade direta entre autocarros,
fez parte de um estudo realizado pela aluna de doutoramento Sabina Zejnilovic, pertencente ao
projeto URBISNET. Analisando os percursos dos autocarros da Carris e as intersecções nos seus
percursos, concluiu que seriam necessários apenas 6 nós gateway localizados em paragens de
autocarros bem definidas para abranger 73% dos autocarros (57 veículos) diretamente, isto é, a
comunicação entre a estação móvel e o gateway seria direta. Concluiu ainda que os restantes 27%
dos autocarros (21 veículos) intersectam pelo menos um dos autocarros que comunica diretamente
com os gateways durante os seus percursos.
3.3.2.B Caraterísticas da rede Wi-Fi
As comunicações usando a tecnologia Wi-Fi trazem alguns desafios, uma vez que as estações
móveis estarão colocadas em veículos com uma elevada mobilidade, como são os autocarros da
33
Carris. As principais caraterísticas desta rede, algumas idênticas às já identificadas para as redes
veiculares na secção 2.5, são:
• Elevada mobilidade dos nós (estações móveis);
• Conetividade entre nós bastante limitada, apenas existente quando os nós se cruzam no seu
trajeto;
• Rede bastante esparsa;
Os itens apresentadas acima representam um desafio na criação de uma comunicação entre as
estações móveis, levando a que estas comunicações tenham de funcionar em modo ad-hoc (ao
invés de modo infraestrutura) e que seja uma rede oportunista. Como rede oportunista entenda-se
que os nós, devido à baixa conectividade, terão de aproveitar todos os intervalos de tempo em que
têm conetividade para trocar informação.
Por outro lado, existem características da rede, dos seus nós, e da informação que se pretende
trocar nela, que podem ser vistos como oportunidades para aumento da eficiência da comunicação,
por exemplo:
• Mobilidade com rotas periódicas associadas aos percursos dos autocarros;
• Nós gateway colocados de forma a que a maioria dos autocarros tenham conetividade direta
com estes;
• A informação gerada nesta rede tem apenas um destino final, o servidor central;
A mobilidade dos autocarros, com as suas rotas periódicas, permitiu que fosse possível equacio-
nar o posicionamento de gateways em paragens de autocarros de forma a servirem como recetores
da informação gerada pelas estações móveis e enviarem essa informação para o servidor central.
A existência dos nós gateway nesta rede permite que, sempre que uma estação móvel tenha co-
nectividade com estes elementos, possa depositar toda a informação que tenha e assuma que,
subsequentemente, esta será entregue ao servidor central. Tendo os dados gerados pelas estações
móveis um único destino final,torna-se possível omitir esta informação pois todos os nós da rede a
conhecem.
3.3.2.C Protocolo de Comunicação
O protocolo de comunicação usando a interface Wi-Fi da estação foi criado tendo em conta as
características identificadas na secção anterior. Como já referido, a interface Wi-Fi da estação foi
configurada para funcionar em modo ad-hoc uma vez que na rede haverá a necessidade de comuni-
car entre estações móveis, elementos com elevada mobilidade, que impossibilita uma comunicação
em modo infraestrutura.
Além da definição da arquitetura de funcionamento da interface Wi-Fi, foi necessário definir o
endereçamento IP dos nós da rede. O endereçamento em redes ad-hoc pode ser auto-configurável,
34
mas nesta rede esparsa e com elevada mobilidade optou-se pelo endereçamento estático e pré-
configurado de cada nó da rede. Decidiu-se usar um endereçamento privado com prefixo de 16 bits
(identificador de rede) 192.168.0.0 para os nós da rede (estações móveis e gateways). Além da
escolha do bloco de endereçamento para os nós, foram também estabelecidas regras de endereça-
mento consoante o nó da rede, descritas abaixo e ilustradas nas figuras 3.14 (referente às estações
móveis) e 3.15 (referente aos gateways):
• Após os primeiros 16 bits do endereço de IP usados para definir a rede, os seguintes 8 bits
são definidos segundo o identificador da estação móvel. Apenas valores entre 1 e 252 são
permitidos. Assume-se que 252 identificadores para estações são mais do que suficientes,
quer no desenvolvimento, quer na implementação nos autocarros da Carris em Lisboa;
• Ainda no terceiro octeto de bits do endereçamento IP, o valor 253 está reservado apenas para
os gateways, enquanto o valor 254 está reservado para eventuais necessidades futuras;
• No caso das estações móveis, o último octeto será usado apenas com dois valores: o valor ’2’
para endereçar a estação em si e o valor ’1’ para endereçar a ponte Ethernet - Wi-Fi usada na
estação. No caso dos gateways, este último octeto terá o valor do identificador único de cada
gateway.
Figura 3.14: Esquema de endereçamento dos nós MS.
Figura 3.15: Esquema de endereçamento dos nós GW.
Em termos de encaminhamento, é considerado um protocolo de disseminação de informação
num esquema de ”store and forward” (armazena e encaminha). Este modo de encaminhamento
faz com que a informação gerada por cada nó (estação móvel) seja disseminado de modo a que
35
possa alcançar um nó gateway, onde é encaminhada para o servidor central. Protocolos baseados
em tabelas de encaminhamento, como o AODV, foram considerados, mas devido à rede ser bastante
esparsa e dinâmica levava a uma dificuldade muito grande em criar rotas entre os nós de origem e
destino (estações móveis e gateways, respetivamente) e manter essas rotas atualizadas. Um pro-
tocolo hierárquico, com três tipos de nós: estações móveis com e sem conectividade direta com os
gateways e os próprios gateways, foi também considerado. No entanto, o facto de ser uma hierarquia
fixa levou a ser descartada devido às rotas dos autocarros não serem fixas.
A unidade básica de informação trocada entre os nós é uma amostra com dados dos sensores,
como descrito no inicio da secção 3.2.1. A esta informação, denominada payload, junta-se sempre
um cabeçalho composto por: estação origem da informação, número máximo de saltos na rede (tam-
bém denominado TTL) e tamanho em bytes do payload. Esta estrutura é apresentada de seguida:
[ID estação origem]#[TTL]#[tamanho_payload]#[payload]#
Optou-se por ter estes parâmetros em cada amostra a enviar de forma a controlar vários fato-
res. A identificação da estação de origem serve para que na troca de informação entre estações
móveis se evite encaminhar dados para a estação que os criou, pois não existe interesse em que
os receba de novo. O parâmetro TTL serve para que haja um valor máximo de nós para os quais
o payload é reencaminhado de forma a que o tempo de vida dessa mensagem seja limitado. O
tamanho_payload serve para o recetor saber o tamanho da informação payload a guardar.
Além destes parâmetros que acompanham cada amostra enviada pela interface Wi-Fi, existe um
parâmetro interno denominado max_times_sent, associado às amostras, que indica o número má-
ximo de vezes que a amostra é enviada por esta interface para outros nós antes de ser descartada.
Decidiu-se ter um parâmetro que controlasse o número de vezes que uma amostra é enviada para
introduzir um ponto de configuração a ser utilizado em futuros processos de simulação do protocolo.
Este parâmetro será útil para ajudar na disseminação da informação, uma vez que utilizando apenas
o TTL, estaríamos a controlar apenas o número de saltos máximos da amostra na rede e, caso algum
nó que contivesse essa mensagem falhasse, ficaria perdida. Assim, podendo replicar o número de
vezes que a mesma é enviada pelo mesmo nó para outros nós, estamos a aumentar as probabilida-
des dessa informação chegar ao seu destino.
O TTL e o max_times_sent podem ser vistos como dois parâmetros de configuração da disse-
minação da informação na rede. O parâmetro TTL controla a profundidade máxima da informação
na árvore de disseminação, enquanto o parâmetro max_times_sent define o número máximo de fo-
lhas em cada nível da árvore. Na figura 3.16, é possível ver um exemplo em que os parâmetros
max_times_sent e TTL são configurados com o valor ’2’, fazendo com que a informação seja propa-
gada com um máximo de dois saltos na rede (como por exemplo de MS1 para MS2 e de MS2 para
36
MS 4), devido ao valor de TTL, e que no máximo cada nó envie os mesmos dados para outros dois
nós (MS 1 envia para MS 2 e MS 3), devido ao parâmetro max_times_sent.
Figura 3.16: Exemplo do uso dos parâmetros configuração de disseminação de informação no protocolo Wi-Fi.
De forma a desencadear a troca de informação entre dois nós, sempre que estes se aproximam
um do outro é necessário uma forma de os alertar quando ficam ao alcance das interfaces Wi-Fi.
A solução implementada passa pelo envio de mensagens em broadcast para a interface Wi-Fi de
forma a serem capturadas por qualquer nó da rede. Estas mensagens são enviadas periodicamente
(por exemplo de 500 em 500 ms) com dois parâmetros: o tipo de nó e o identificador de nó. O tipo
de nó é uma informação com dois valores possíveis, NODE1 ou GW. Este parâmetro permite que um
nó se identifique como sendo uma estação móvel (NODE1) ou como gateway (GW). O identificador de
nó é o ID associado a cada estação móvel ou gateway, sendo um identificador numérico.
Figura 3.17: Exemplo de uma mensagem enviada em broadcast por um nó gateway.
Graças às mensagens broadcast transmitidas por todos os nós da rede (estações móveis e ga-
teways), existe um mecanismo que permite aos nós perceberem a rede que os rodeia. O passo
seguinte foi a implementação da comunicação entre os nós e as regras dessa comunicação. Devido
à existência de dois tipos de nós, existem regras diferentes, caso a comunicação seja do tipo estação
móvel⇐⇒ estação móvel ou estação móvel =⇒ gateway.
A comunicação estação móvel⇐⇒ estação móvel é inicializada pela estação que apresente o
identificador com valor inferior (em comparação com a estação de quem recebeu a mensagem de
broadcast), fazendo com que a estação com identificador maior aguarde pela informação enviada
pela estação com identificador inferior para poder também enviar a informação que tem armazenada
(figura 3.18). Assim, a estação com identificador inferior, começa por compilar as amostras que tem
37
armazenadas (que sejam originadas numa estação diferente daquela para a qual vai transmitir) e
envia esses dados para a estação com identificador superior. Ao receber estes dados, a estação
com identificador superior, compila igualmente os dados e envia para a estação com identificador
inferior. Após a troca de informação de ambas as estações, cada uma armazena os dados recebidos
com a devida granularidade (amostra a amostra), à exceção de duas situações:
• A amostra recebida tem um valor de TTL igual a 1, ou seja, chegou ao limite de saltos na rede;
• A amostra recebida já estava armazenada na estação recetora (evitando entradas duplicadas);
Figura 3.18: Diagrama de comunicação entre duas estações móveis.
Após a troca de informação e armazenamento da mesma, considera-se que a comunicação entre
as duas estações móveis foi feita com sucesso e cada estação adiciona uma entrada na sua lista
de estações contactadas recentemente, denominada host_list. Essa informação é útil para tentar
evitar que as estações ao cruzarem-se num determinado momento, com uma certa duração, estejam
sempre a iniciar o protocolo de troca de informação depois de o terem feito com sucesso no intervalo
em que estão no alcance uma da outra.
A host_list inclui as seguintes informações:
• Identificador da estação contactada;
• Endereço IP da estação contactada;
• Timestamp de limite de interdição de comunicação com a estação contactada. Esta informação
é calculada na altura de introdução na lista e depende do parâmetro de configuração
COMM_HOST_TIME_INTERVAL que dita o valor em segundos do período de interdição.
No anexo B é disponibilizado um fluxograma do funcionamento do protocolo Wi-Fi num nó estação
móvel.
Na comunicação estação móvel =⇒ gateway o protocolo de comunicação é diferente e mais sim-
ples, uma vez que o gateway apenas recebe os dados das estações móveis. Assim, após o processo
de broadcast da identificação de ambos os nós, é a estação móvel que inicia a comunicação, es-
tando o gateway sempre preparado para receber a informação das estações móveis (figura 3.19).
De referir também que o gateway ignora as mensagens de broadcast das estações móveis, uma vez
38
que não tem interesse em enviar dados e a identificação das estações é irrelevante para iniciar o
processo de comunicação entre ambos. Após a receção da mensagem de broadcast do gateway,
a estação móvel prepara todos os seus dados armazenados e envia para o gateway, aguardando
uma mensagem de confirmação por parte do gateway. Após a confirmação de receção dos dados,
a estação móvel elimina todas essas amostras, uma vez que os dados chegaram nó da rede ad-hoc
final.
Figura 3.19: Diagrama de comunicação entre estação móvel e gateway.
Num protocolo de comunicação baseado em ”armazena e encaminha” como este, é necessário
haver um controlo na quantidade de informação armazenada. Neste protocolo existe um mecanismo
preventivo e um ativo. O mecanismo preventivo consiste na eliminação das amostras que sejam
enviadas por esse nó, pelo menos, um número de vezes igual a max_times_sent. O mecanismo
ativo é acionado na troca de informação quando se atinge o limite da quantidade de informação
armazenada. Assim, caso se receba uma amostra e esse limite seja atingido, é excluída a amostra
atualmente armazenada que tenha sido enviada para outros nós o maior número de vezes. No caso
de todas as amostras armazenadas ainda não terem sido enviadas pelo menos 1 vez, descarta-
se a amostra recebida. Este mecanismo de descarte de mensagens privilegia a integridade das
mensagens locais que tenham sido enviadas menos vezes, o que está conforme com o pretendido
num protocolo de disseminação.
39
40
4Implementação
Contents4.1 Servidor (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Gateway (GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3 Estação Móvel (MS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
41
Neste capítulo são apresentados os diversos aspetos referentes à implementação do sistema,
desde os equipamentos e software utilizados, passando pelas escolhas de implementação. O ca-
pítulo encontra-se dividido pelos componentes implementados (servidor central, gateway e estação
móvel) e aborda as suas configurações e funcionamento lógico, de acordo com os requisitos e funci-
onalidades do projeto URBISNET.
4.1 Servidor (CS)
O Servidor Central tem um papel bastante diversificado neste projeto, acumulando funções de
receção e armazenamento dos dados provenientes das estações móveis, e disponibilização destes
num website em conjunto com operações de monitorização e configuração das estações. Para dis-
ponibilizar estas funções são necessários dois componentes principais: uma base de dados e um
servidor web.
Além da necessidade destes dois componentes no servidor central, foram definidos outros requisitos
para que a comunicação entre o servidor central e os restantes componentes da rede URBISNET
tenha sucesso:
• Uso de software de código aberto e gratuito - Este requisito é imposto no âmbito do projeto
URBISNET;
• Domínio web acessível pela Internet - Uma vez que a comunicação no sentido MS=⇒CS é
feita por pedidos Hypertext Transfer Protocol (HTTP) e é necessário disponibilizar através da
web o site do projeto, é necessário saber qual o URL a endereçar para aceder ao servidor;
• Endereço IP fixo - Devido às estações possuírem firewall no módulo GSM/GPRS para evitar
receber dados indesejados, o endereço IP do servidor é necessário de forma a poder configurar
as estações de forma a aceitarem comunicação vinda do exterior, mas apenas com origem no
CS. É portanto necessário que o endereço IP seja fixo.
Uma vez que o cluster Sigma do Instituto Superior Técnico disponibiliza os serviços de base de
dados e servidor web, respeitando os requisitos acima apresentados, foi o escolhido para ser usado
durante o período de desenvolvimento deste trabalho.
4.1.1 Base de Dados
A base de dados usada é a MySQL, uma base de dados amplamente usada em projetos de re-
levo, de código aberto e gratuita.
No Sigma é disponibilizada uma base de dados MySQL para cada aluno, fornecendo as credenciais
necessárias para gerir a mesma. Para editar a base de dados, com as operações de criação e edição
de tabelas, foi utilizado o MySQL Query Browser, disponibilizado para os principais sistemas operati-
vos e de carácter gratuito. Além da gestão das tabelas permite também fazer queries (ou perguntas)
à base de dados (como exemplificado na figura 4.1), de forma a testar o correto funcionamento das
mesmas antes de implementar, por exemplo, no website URBISNET.
42
Figura 4.1: Interface gráfica do MySQL Query Browser com exemplo de uma query realizada à base de dados.
Para fazer as queries à base de dados, o MySQL usa a linguagem SQL (Strutcured Query Lan-
guage), utilizada na grande maioria das bases de dados relacionais. É uma linguagem bastante
fácil de compreender, uma vez que é declarativa e se baseia em comandos simples como INSERT
para inserir dados, SELECT para selecionar dados, CREATE TABLE para criar uma tabela, entre
outros. De seguida é exemplificada uma query usada para inserir os dados station_ID, ip_addr e
timestamp na tabela ”urbisnet_stations”.
INSERT INTO urbisnet\_stations VALUES (2, '77.54.5.219', '2012-03-14 11:19:47');
A utilização da base de dados na implementação do projeto baseia-se sobretudo em queries
de inserção usando o comando INSERT e operações de procura (usando o comando SELECT), de
forma a encontrar dados pretendidos para o website URBISNET.
Foram criadas, ao longo do desenvolvimento do projeto, três tabelas que contêm os dados das
amostras criadas pelas estações, informação das estações, e informações dos gateways.
As amostras recolhidas pelas estações são guardadas na tabela ”urbisnet_samples” (4.1). Esta ta-
bela possui os dados necessários ao mapeamento temporal e espacial dos dados recolhidos, além
dos dados atmosféricos em si. Os atributos sinalizados com ”(c)” correspondem a chaves da tabela.
Nesta tabela, o timestamp e station_ID são as chaves. Estas chaves permitem filtrar entradas dupli-
cadas, na altura da sua inserção na tabela, uma vez que a base de dados não permite entradas com
atributos chave iguais.
43
Atributos Descriçãotimestamp (c) Identificação temporal da amostra recolhidastation_ID (c) Identificação da estação origemlat Latitude da posição onde foi recolhida a amostralng Longitude da posição onde foi recolhida a amostraco2_out Valor CO2, dióxido de carbonoco Valor CO, monóxido de carbonoo3 Valor O3, ozonono2 Valor NO2, dióxido de azototemperature Valor de temperaturahumidity Valor de humidade
Tabela 4.1: Atributos da tabela ”urbisnet_samples” na base de dados.
A tabela ”urbisnet_stations” (4.2) contém informação relativa ao endereço IP atribuído à estação
através da ligação GPRS, enviado pela estação para que o servidor possa iniciar uma comunicação
com a mesma e efetuar pedidos de monitorização e/ou configuração.
Atributos Descriçãostation_ID (c) Identificação da estaçãoip_addr Endereço IP da estação da ligação GPRStimestamp Identificação temporal do envio do endereço IP
Tabela 4.2: Atributos da tabela ”urbisnet_stations” na base de dados.
Por último, na tabela ”urbisnet_gateways” (4.3), é guardada informação dos gateways relativa-
mente às mensagens periódicas (”I’m alive”) que enviam para o servidor.
Atributos Descriçãogw_id (c) Identificação do gatewaylast_alive Identificação temporal da receção da última mensagem ”I’m alive”alive_interval Intervalo temporal entre mensagens ”I’m alive” (minutos)ip_ address Endereço IP do gateway
Tabela 4.3: Atributos da tabela ”urbisnet_gateways” na base de dados.
4.1.2 Servidor Web
O servidor web Apache HTTP Server, disponibilizado pelo cluster Sigma é amplamente utilizado
como solução para servidores web, tem código aberto e é gratuito. No âmbito deste projeto, o ser-
vidor web permite a disponibilizar o website URBISNET e também ter uma interface para receber,
processar e guardar os dados recebidos das estações e dos gateways via Internet. Optou-se por usar
o servidor web para receber as amostras das estações devido ao facto de oferecer elevada disponi-
bilidade e fiabilidade, quer na sua implementação, quer na comunicação, quando comparado com o
desenvolvimento de uma alternativa para essa comunicação. Outra ferramenta bastante utilizada na
implementação, quer do website URBISNET, quer na interface para as comunicações dirigidas ao CS
via GW e MS, foi a linguagem PHP: Hypertext Preprocessor (PHP), bastante útil para programação
dinâmica na web e acesso à base de dados.
44
Devido à implementação do projeto ter sido realizada no cluster Sigma, existiu a necessidade de
poder transferir dados para o mesmo de forma a implementar, por exemplo, o website. Essa co-
municação foi assegurada usando ligações Secure Shell Protocol (SSH) e SSH File Transfer Pro-
tocol (SFTP), de forma aceder à shell do servidor Sigma e a enviar e editar ficheiros. Para essas
funções foram usados os programas PuTTY1 e WinSCP 2.
4.1.2.A Website URBISNET
O website URBISNET é uma interface web onde é possível visualizar os dados recolhidos, ofe-
recendo ainda a possibilidade de monitorizar e configurar as estações. Está estruturado em 4 áreas
(ou menus) para disponibilizar estas funcionalidades:
• Visualizar - Nesta secção é possível visualizar as amostras localizadas num mapa segundo
as coordenadas onde foram recolhidas. Selecionando o item correspondente à amostra são
apresentados os dados recolhidos pelos sensores. No processo de visualização é possível
selecionar uma estação em particular para apresentar apenas as suas amostras, assim como
selecionar amostras recolhidas durante um determinado período temporal, entre duas datas.
• Monitorizar - Aqui é possível visualizar as estações registadas e a última atividade registada
no servidor por parte delas. É também possível enviar um pedido de monitorização de dados
de configuração das mesmas e também das últimas entradas do Log do seu sistema.
Além das estações é apresentada também a lista dos gateways registados e, a data da última
mensagem ”I’m Alive” recebida, e a data da próxima mensagem ”I’m Alive” (esperada);
• Configurar - Nesta área é possível comunicar com as estações de forma a enviar uma nova
versão de software para a estação, reiniciar a estação, ou configurar parâmetros da estação;
• Consultar Logs - Esta última área do website permite consultar registos das comunicações
recebidas e enviadas pelo servidor para as estações/gateways.
Figura 4.2: Website URBISNET.
1Website PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html2Website WinSCP: http://winscp.net
45
O desenvolvimento do website passou pela utilização de um simples editor de texto para criar
as várias secções e elementos. Em termos de programação web, foram utilizadas as linguagens
Cascading Style Sheets (CSS) e HyperText Markup Language (HTML) para criação da parte visual
do website. O HTML é utilizado na definição da estrutura das páginas (marcação) e nos seus vários
campos, como exemplificado na seguinte tabela:
<table border="0" class="monTable"><tr><th class="monTable"><b>ID da MS</b></th><th class="monTable"><b>Última actividade registada</b></th><th class="monTable"></th><th class="monTable"></th>
</tr><tr><td>1</td><td> 2012-04-04 12:47:19 </td><td><input type="button"value="Monitorizar"onclick="monitStation(1)"/></td><td><input type="button"value="Log Sistema"onclick="logStation(1)"/></td></tr>
</table>
A linguagem CSS tem como intuito separar a formatação (HTML) da apresentação, aspetos visu-
ais e propriedades dos mesmos. O exemplo anterior da definição da tabela em HTML é complemen-
tado pela especificação dos seus atributos visuais em CSS:
table.monTable{
text-align: center;vertical-align: middle;font-family: Verdana, Geneva, Arial, Helvetica, sans-serif ;font-weight: normal;color: #fff;background-color: #666;border: 0px;border-collapse: collapse;border-spacing: 0px;
}table.monTable td{
text-align: center;vertical-align: middle;background-color: #CCC;color: #000;padding: 4px;border: 1px #fff solid;
}
O resultado final, usando o código HTML e CSS apresentado acima, é demonstrado na figura 4.3.
Para implementação da lógica do website foram usadas as linguagens de programação JavaScript
e PHP.
46
Figura 4.3: Tabela no website URBISNET.
Figura 4.4: Tecnologias usadas na implementação do website URBISNET.
A linguagem JavaScript é uma linguagem web baseada em Java que corre do lado do cliente
(normalmente o cliente é o navegador web do utilizador). Neste projeto, a utilização de JavaScript
tem uma especial importância na realização da operação de visualização, uma vez que é utilizado
Google Maps e a interface de programação dessa ferramenta apenas é disponibilizada em JavaScript
pela Google. A implementação da visualização, em termos de interação com o serviço Google Maps,
tem três operações principais: carregamento do mapa no website, criação dos pontos no mapa
que indicam localizações das amostras recolhidas, e por último o carregamento desses dados no
mapa. De seguida são apresentadas duas funções utilizadas na área de visualização, a primeira para
inicializar o mapa e a segunda para criar os pontos no mapa das amostras (em versão simplificada
para este relatório).
var map;var infowindow;//função de inicialização do mapa e suas característicasfunction initialize() {var latlng = new google.maps.LatLng(38.737, -9.303);
infowindow = new google.maps.InfoWindow({content: "void"
});var myOptions = {zoom: 12,center: latlng,mapTypeId: google.maps.MapTypeId.ROADMAP
};map = new google.maps.Map(document.getElementById("map_canvas"),
myOptions);}//função para criar um ponto no mapa com os dados da amostrafunction createMarker(ts, station_id, lat, lng, co2, co , o3 , no2 , temp , hum){
var marker_l;
47
if(lat !=null && lng != null){
var markerOptions = {map: map, position: new google.maps.LatLng(lat,lng), title: "data"};
marker_l = new google.maps.Marker(markerOptions);var contentString = 'Dados a aparecerem na descrição de cada amostra no
mapa.';google.maps.event.addListener(marker_l, 'click', function() {
infowindow.setContent(contentString);infowindow.open(map, marker_l);
});google.maps.event.addListener(map, 'click', function() {
infowindow.close(marker_l);});
}// inserção da amostra no mapamarker_l.setMap(map);
}
O PHP é uma linguagem que corre do lado do servidor (ao contrário do Javascript) e permite
a criação de conteúdos dinâmicos em páginas web. A utilização de PHP no website URBISNET
teve especial importância em duas tarefas: acessos à base de dados MySQL e comunicação com
as estações móveis em situações de monitorização. O acesso à base de dados MySQL envolve
quatro fases: parametrização da ligação, ligação à base de dados, realização da query, e retorno do
resultado da query. Após estas quatro fases de interação com a base de dados, são processados
os resultados retornados, usando PHP. Um exemplo da utilização de PHP para ligação à base de
dados é apresentado de seguida.
<?php//parametros de ligação$hostname = 'db.ist.utl.pt'; // localização$username = 'ist157697'; // utilizador$password = 'XXXXXXX'; // palavra chave$dbname = 'ist157697'; // nome da base de dados
// Ligação à base de dados MSQLmysql_connect($hostname, $username, $password)
or DIE('Connection to host is failed, perhaps the service is down!');// Seleccionar a base de dadosmysql_select_db($dbname) or DIE('Database name is not available!');mysql_set_charset('utf8');
// query MySQL para obter as estações registadas na base de dados$sql="select distinct station_ID from urbisnet_stations;";$result = mysql_query($sql);//fechar ligação com a base de dadosmysql_close();// exemplo de processamento do resultado dado pela base de dadoswhile($row_array = mysql_fetch_array($result)) {
$number = $row_array['station_ID'];echo "Id da estação: $number";
}?>
A comunicação com as estações móveis a partir do website URBISNET permite a realização de
operações de monitorização e de configuração. As operações de monitorização foram realizadas
48
com recurso a funções de sockets em PHP, permitindo estabelecer uma ligação lógica à estação
móvel. A estação móvel aguarda ligações no porto 8080 (por pré-definição) vindas do servidor cen-
tral. De seguida é apresentando um exemplo de envio de uma mensagem de monitorização para
uma estação e receção da resposta, usando PHP.
$port = 8080;$stat_id = 1;// abrir socket para a estação móvel$fp = fsockopen ($station_ip, $port, $errno, $errstr);if (!$fp){
$message = "Erro em criar ligação: $errstr";die($message);
}else{
$message = "MS$stat_id:2";// envio de pedido de monitorização para a estaçãofputs ($fp, $message);// receber os dados de monitorização da estação$result = fread ($fp, 1024);fclose ($fp);
}
Apesar das operações de configuração implementadas no website consistirem numa comunica-
ção idêntica à apresentada acima, foi identificada durante a fase de implementação a necessidade
de poder configurar várias estações em simultâneo. Esta configuração simultânea implica comunicar
com várias estações ao mesmo tempo e não de forma sequencial para evitar longos períodos de
espera entre o inicio da operação e a sua conclusão. Uma vez que a linguagem PHP não oferece su-
porte para threads de forma a criar a comunicação em paralelo para as várias estações, a alternativa
passou por implementar essa lógica em programas feitos em linguagem C, de forma a serem usados
como interface entre o website (e a programação PHP feita no mesmo) e as estações móveis nas
operações de configuração. Foram criadas três aplicações em C, uma para cada operação de con-
figuração (envio de ficheiro, reiniciar estação, configurar parâmetros), que recebem os parâmetros
necessários para realizar essas operações e são invocadas através de PHP. Após a comunicação
com todas as estações é retornado o sucesso (ou insucesso) de cada comunicação ao website, de
forma a ser possível mostrar os resultados ao utilizador. Esta implementação está demonstrada na
figura 4.5.
Figura 4.5: Exemplo de interação entre a estrutura implementada num pedido de configuração (reiniciar).
49
4.1.2.B Interface para as comunicações dirigidas ao CS via GW e MS
Todas as comunicações destinadas ao servidor central são enviadas como pedido HTTP. Os
pedidos HTTP mais comuns são os pedidos GET, utilizados para pedir ao servidor páginas web,
como faz um navegador web para aceder ao website URBISNET, por exemplo. No entanto, quando
o intuito é enviar informação para o servidor, a solução mais comum é a utilização do método POST.
Este método, normalmente usado na submissão de formulários, permite enviar dados no corpo do
pedido HTTP que podem ser interpretados do lado do servidor web. Atualmente existem três tipos
de informação que são enviadas para o servidor central:
• Amostras Atmosféricas - Enviadas pelas estações móveis (em modo GPRS) ou pelos ga-
teways (em modo Wi-Fi);
• Endereço IP da interface GPRS - Enviado pelas estações móveis;
• Mensagens ”I’m Alive” - Enviadas pelos gateways.
Cada um destes tipos de informação é enviado numa mensagem HTTP POST de forma a chegar
ao servidor central. Uma vez que é um pedido HTTP endereçado a uma página web do servi-
dor central, a informação é facilmente processada através de um script em PHP. Esse script tem
como função processar os dados recebidos e comunicar com a base de dados MySQL, de forma
a armazena-los. Abaixo está representado o exemplo de uma mensagem HTTP POST enviada por
uma estação móvel com uma amostra atmosférica.
POST /ist157697/urbisnet/station_comm.php HTTP/1.0User-Agent: Urbisnet_StationHost: web.ist.utl.ptAccept: */*Content-Type: application/x-www-form-urlencodedContent-Length: 99
MS_SAMPLES=2012-4-411:47:11,1,38.736946,-9.303041,2.094727,2.499390,0.763550,2.499390,35.45,23.45;
4.2 Gateway (GW)
O gateway é o elemento da rede que serve de intermediário entre as estações móveis e o servidor
central, recebendo das estações as amostras que estas recolhem, e enviando-as para o servidor
através de uma ligação fixa à Internet. Nesta secção são abordadas a escolha do equipamento para
gateway e as suas características, o funcionamento lógico do gateway e aspetos relativos à sua
configuração e desenvolvimento.
4.2.1 Equipamento
Para servir de gateway foi necessário encontrar um equipamento que preenchesse os seguintes
requisitos:
50
• Reduzidas dimensões;
• Interface Wi-Fi b/g;
• Interface LAN;
• Capacidade de correr sistema operativo Linux;
Foram considerados dois equipamentos bastante distintos para gateway, o mini desktop Asus
EeeBox EB10073 e o router Asus WL-500g Premium v2 4. As principais especificações destes
equipamentos estão representados na tabela 4.4.
EeeBox EB1007 WL-500g Premium v2Processador Processador Intel Atom D410 1.66 GHz Broadcom BCM5354 240 MHzMemória 1GB DDR2 800 MHz 32 MBDisco Rígido SATA 2.5"de 160 GB 8 MB (flash)LAN 10/100/1000Mbps 4x 10/100MbpsWi-Fi WLAN 802.11b/g/n @2.4GHz 802.11b/g @2.4GHzVídeo Saída VGA -Dimensões 223mm x 178mm x 27mm 206mm x 185mm x 35mmPreço 200e 70e
Tabela 4.4: Principais especificações do EeeBox EB1007 e router WL-500g Premium v2
A escolha do equipamento recaiu sobre o desktop EeeBox EB1007, pois apresenta caracterís-
ticas melhores em todos os campos exceto no preço, que não foi considerado fator eliminatório na
escolha durante esta fase de prototipagem do projeto. Além disso, o EeeBox permite a instala-
ção de uma distribuição Linux como o Ubuntu, bastante mais flexível ao nível de desenvolvimento
de aplicações, ao contrário do desenvolvimento em OpenWRT (sistema operativo baseado em Linux
amplamente utilizado em routers) que implicaria a instalação do ambiente de desenvolvimento noutra
plataforma e efetuar aí o desenvolvimento (cross-compiling). Além disso, as capacidades superiores
quer a nível de computação, memória, e capacidade de saída de vídeo foram vistos como fatores
facilitadores de implementação de futuras funcionalidades que possam ser desenvolvidas para os
gateways.
4.2.2 Funcionamento Lógico
O funcionamento lógico do gateway é bastante simples, uma vez que a sua função passa apenas
por encaminhar os dados recebidos das estações móveis para o servidor central. Para concretizar
esse propósito, à semelhança das estações (como foi explicado em maior detalhe na secção 3.3.2.C
relativa ao protocolo Wi-Fi), o gateway faz regularmente um broadcast na sua interface Wi-Fi de uma
mensagem com o seu identificador (número do gateway ) e o tipo de elemento de rede. As estações
que recebam estas mensagens são capazes de saber que estão no alcance de um gateway e que
podem enviar os dados que têm armazenados. Ao receber os dados, o gateway confirma a sua
receção à estação indicando o endereço IP da estação e a mensagem ”OK”, como exemplificado no
3Website do equipamento Asus EeeBox EB1007: http://pt.asus.com/Eee/EeeBox_PC/EeeBox_PC_EB10074Website do equipamento Asus WL-500g Premium v2: http://www.asus.com/Networks/Wireless_Routers/WL500gP_V2
51
Figura 4.6: Foto do equipamento usado como gateway, o Asus EeeBox EB1007.
diagrama da figura 4.7.
Figura 4.7: Diagrama da comunicação entre as estações e o GW no envio de dados.
Os dados recebidos são guardados internamente para serem enviados para o servidor. Sempre
que existem dados armazenados é acionada uma rotina de envio dos mesmos para o servidor, via
HTTP, tal como são enviadas no modo GPRS nas estações móveis.
De forma a ser possível aferir sobre a operacionalidade dos gateways de forma remota, são enviadas
mensagens ”I’m Alive” para o servidor central periodicamente. Estas mensagens, tal como as amos-
tras recebidas das estações, são enviadas via HTTP POST com o formato ID,IMALIVE-INTERVAL,
onde ID é o identificador do gateway e IMALIVE-INTERVAL o intervalo de tempo, em minutos, até ao
envio da próxima mensagem ”I’m Alive”.
Os parâmetros de configuração do gateway passam pela definição da periodicidade das men-
sagens de broadcast (em milissegundos), endereço IP, e tipo de nó (de acordo com o especificado
no protocolo Wi-Fi na secção 3.3.2.C), assim como os dados do servidor central que receberá as
amostras. Esses parâmetros são guardados num ficheiro que é lido pelo programa principal para
assim poder operar corretamente. Um exemplo do conteúdo desse ficheiro é mostrado de seguida.
52
### Urbisnet GW configuration file ###ID:1BCAST_INTERVAL:500TYPE_STATION:GWIP_ADDRESS:192.168.253.1WEBHOST:web.ist.utl.ptUPLOADWEBADDRESS:/ist157697/urbisnet/station_comm.php
Figura 4.8: Diagrama de fluxo do funcionamento do gateway.
4.2.3 Configuração e desenvolvimento
A configuração do gateway começou com a instalação da distribuição Linux Ubuntu 11.10 como
sistema operativo, removendo a inicialização da sua interface gráfica devido à sua inutilidade ao fun-
cionamento do gateway. Devido às características de funcionamento do gateway diferirem de um
simples desktop, alterou-se nas configurações da BIOS (firmware do equipamento), o parâmetro de
inicialização para que o gateway esteja em funcionamento sempre que alimentado por energia, e
não apenas quando pressionado o botão de ligar/desligar. Esta medida é essencial para tornar autó-
nomo o funcionamento do gateway nas paragens de autocarros. Ainda com o objetivo de assegurar
a autonomia de funcionamento, durante a inicialização o gateway corre um script que configura a
sua interface de rede fixa (LAN), configura a sua interface wireless, e lança o programa (denominado
53
urbisnet_gateway) desenvolvido com a lógica de funcionamento do gateway (receber dados das es-
tações móveis e envio para o servidor central). De seguida apresenta-se o shell script (na linguagem
do interpretador bash do sistema operativo) que corre quando o gateway é inicializado.
#!/bin/bashsudo service network-manager stop
#eth0sudo ip link set eth0 downsudo ip link set eth0 upsudo dhclient eth0
#wlan0sudo ip link set wlan0 downiwconfig wlan0 mode ad-hociwconfig wlan0 channel 11iwconfig wlan0 essid Urbisnetiwconfig wlan0 key EEAACC2211sudo ip link set wlan0 upifconfig wlan0 192.168.253.1 netmask 255.255.0.0 broadcast 192.168.255.255
sleep 2
echo "Starting Urbisnet Gateway"cd /urbisnet_GW/./urbisnet_gateway &
Além do desenvolvimento do script de configuração inicial, foi também desenvolvido o programa
urbisnet_gateway, contendo a lógica de funcionamento do gateway. O seu desenvolvimento foi
feito na linguagem C utilizando o ambiente de desenvolvimento Eclipse 5. Este software permite o
desenvolvimento em várias linguagens, incluindo C, e facilita bastante a tarefa de programação, tendo
sido usado também para os programas em C referidos no servidor central e no desenvolvimento do
software da estação móvel.
4.3 Estação Móvel (MS)
A estação móvel é a componente central deste projeto pois nela está concentrada a funcionali-
dade base de recolha de amostras atmosféricas. A sua implementação a nível de software e configu-
ração trouxe alguns desafios, muito devido à quantidade de componentes que envolve (comunicação,
localização e sensores atmosféricos) e a necessidade de programar a estação de forma a oferecer
as funcionalidades apresentadas anteriormente nesta tese. Nesta secção são abordados o equipa-
mento usado na estação móvel e suas características, a configuração e desenvolvimento da estação
móvel, e também o seu funcionamento lógico.
4.3.1 Equipamento
O equipamento usado como estação móvel foi desenvolvido no âmbito da tese de mestrado de
Eng.a Eletrónica de David Quelhas [2] e a sua arquitetura e imagem do protótipo já foram apresenta-
dos na secção 3.1.1, na Arquitetura Geral deste documento. O protótipo inclui um sistema embebido5Website do software Eclipse: http://www.eclipse.org
54
C10/3 AarLogic da RoundSolutions 6 (representado na figura 4.9) que inclui um processador ARM in-
tegrado com o módulo GSM/GPRS (modelo GE863-PRO3 desenvolvido pela Telit 7) , módulo GPS e
interfaces para cartão SIM e cartões de dados SD/MMC. As características em detalhe deste sistema
embebido podem ser consultadas na tabela 4.5.
Processador Atmel AT91SAM9260 ARM9 200 MIPS 180MHz (módulo GE863-PRO3)Memória RAM 64 MBMemória ROM 4 MBExtensão Memória Cartões SD ou MMCGPS AarLogic GPS 3M (SiRF 3/LP)Cartão SIM Suporte para cartão SIMGSM/GPRS Integrado no módulo GE863-PRO3Sistema Operativo LinuxConectores Para antenas GSM/GPRS e GPS
Tabela 4.5: Características do módulo C10/3 AarLogic da RoundSolutions.
Figura 4.9: Foto do módulo C10/3 AarLogic da RoundSolutions.
O módulo C10/3 AarLogic é ligado a uma PCB desenvolvida pelo David que tem integradas uma
porta Ethernet e uma porta série RS-232 e liga também ao conjunto de sensores da estação. As co-
municações Wi-Fi na estação móvel são disponibilizadas por um ponto de acesso Wi-Fi configurado
como ponte entre a interface Ethernet e Wi-Fi. O equipamento usado na estação móvel é um ponto
de acesso Asus WL-330gE (figura 4.10), com uma interface ethernet e interface Wi-Fi 802.11b/g.
Devido ao protótipo da estação ter sido desenvolvido e terminado já depois do inicio desta tese,
foi necessário usar o kit de desenvolvimento STK-S4 da RoundSolutions (figura 4.11). Esta placa de
desenvolvimento permitiu a integração com o módulo C10/3 AarLogic e o facto de disponibilizar uma
interface Ethernet, interface USB e 4 interfaces série RS-232 (de forma a aceder aos módulos GPS,
GSM/GPRS e processador/sistema operativo) foi fundamental na fase inicial da implementação e
configuração da estação móvel.
6Website da RoundSolutions: http://www.roundsolutions.com7Website da Telit: http://www.telit.com
55
Figura 4.10: Ponto de acesso Asus WL-330gE integrado na estação móvel.
Figura 4.11: Foto do kit de desenvolvimento STK-S4 com os módulos C10/3 AarLogic e Ethernet integrados.
4.3.2 Configuração e desenvolvimento
A configuração e desenvolvimento da estação móvel envolveu a configuração individual do mó-
dulo principal (GE863-PRO3) e dos pontos de acesso Asus WL-330gE, a programação do módulo
GE863-PRO3, desenvolvimento das comunicações GPRS e também desenvolvimento das funciona-
lidades relacionadas com os dados GPS.
4.3.2.A Módulo GE863-PRO3
O fabricante do modulo GE863-PRO3, a Telit, disponibiliza um kit de desenvolvimento de software
baseado em Linux, incluindo o ambiente de desenvolvimento Eclipse e um conjunto de ferramentas
integradas (plugins). Este kit permite facilmente compilar código numa máquina diferente e só depois
enviar o ficheiro executável para a estação móvel através do protocolo Telnet pela ligação na interface
de rede (cross-compiling).
Além do ambiente de desenvolvimento para criar aplicações para correr no módulo GE863-PRO3,
a Telit fornece bibliotecas criadas em C com um conjunto de funções para uso nas comunicações
56
Figura 4.12: Eclipse com plugin Telit para programação dos módulos GE863-PRO.
GSM/GPRS e acesso à informação do recetor GPS.
O funcionamento lógico da estação foi implementado em linguagem C (aplicação denominada
Urbisnet_integration), incluindo os modos de comunicação Wi-Fi, GPRS, acesso aos dados do
recetor GPS, acesso aos dados dos sensores atmosféricos, e funcionalidades de envio dos dados
dos sensores e disponibilização das funções de monitorização e configuração. Para a aplicação
Urbisnet_integration funcionar necessita de um ficheiro de configuração (config.txt), contendo
vários parâmetros de configuração da estação e do seu modo de funcionamento. Durante o funciona-
mento da aplicação, dois ficheiros são criados/atualizados: um ficheiro com registos das operações
realizadas pela estação (log.txt) e outro ficheiro (stats.txt) com dados de utilização da ligação
GPRS e do sinal GPS.
Para a estação funcionar de modo autónomo existem um conjunto de scritps a executar sempre
que a estação entra em funcionamento. As funções desses scripts desenvolvidos passam por:
• Configuração interface de rede Ethernet;
• Verificar conectividade com a ponte Wi-Fi;
• Aceitar ligações Telnet;
• Carregar módulos necessários para aceder aos sensores atmosféricos;
• Verificar existência de atualizações recebidas anteriormente (pela funcionalidade de envio de
ficheiros de forma remota para a estação);
• Iniciar o programa principal URBISNET (Urbisnet_integration).
57
4.3.2.B Comunicações GPRS
No caso das comunicações GPRS, a sua implementação começou por testar o módulo GSM/GPRS,
que recebe e envia dados através de uma interface série. Os comandos de interação com este gé-
nero de módulos são conhecidos como comandos Attention (ou simplesmente AT) e a lista de co-
mandos AT aceites pelo módulo é normalmente fornecida pelo fabricante, neste caso a Telit8. Este
tipo de comandos são baseados maioritariamente em queries efetuadas ao módulo, às quais ele
responde. Um exemplo de uma interação com o módulo é apresentado de seguida:
AT+CPIN=1234OK
O comando CPIN é utilizado em funções relacionadas com o PIN do cartão SIM usado, e neste
caso o comando AT+CPIN=1234 é usado para enviar para o módulo o PIN do cartão SIM em uso de
forma a desbloquear a sua utilização (como acontece num terminal móvel). A resposta do módulo
foi OK pelo que o PIN é válido e a utilização do cartão SIM está desbloqueada. Como referido
anteriormente, a Telit disponibiliza uma biblioteca de funções em C para interação com o módulo
GSM/GPRS. No entanto é uma biblioteca algo limitada e apenas com funções relativamente simples,
o que implicou a implementação de mais funções (acedendo à interface série do modulo e usando
comandos AT) de forma a satisfazer as necessidades do desenvolvimento das comunicações GPRS.
Esse processo tornou-se bastante moroso pois implicou a leitura da documentação dos comandos AT
para saber quais os parâmetros usados, os valores válidos desses parâmetros e o tipo de resposta
devolvida pelo módulo, de forma a ser corretamente interpretada. Um exemplo dessa implementação
é a função para permitir ligações via GPRS vindas do servidor central, demonstrada de seguida, onde
os parâmetros são o endereço IP do servidor e a máscara de rede desse endereço.
int allowFRWL(char* IPaddr, char* mask) {char * frwlString = (char*)(malloc (sizeof(char)*70));memset(frwlString, '\0', 70);sprintf(frwlString, "AT#FRWL=1,\"%s\",\"%s\"",IPaddr, mask);GSM_ErrorCode_t state;char * response = (char*)(malloc(MAX_RESPONSE_SIZE));memset(response,'\0', MAX_RESPONSE_SIZE);//clear any frwl rule (DROP is default)GSM_SendATcommand (MODEM_TTY,"AT#FRWL=2", 100, GSM_ABS_TIMEOUT,&response,"OK");memset(response,'\0', MAX_RESPONSE_SIZE);//set firewall rulestate=GSM_SendATcommand (MODEM_TTY,frwlString, 100, GSM_ABS_TIMEOUT,&response,"OK");if (state!=GSM_EXEC_OK){
printf("Failed FRWL command: %s\n", response);free(frwlString);free (response);return -1;
}printf("Successful FRWL command: %s\n", response);free(frwlString);free (response);return 0;
}
8Lista de comandos AT disponibilizada pela Telit: www.telit.com/module/infopool/download.php?id=542
58
4.3.2.C GPS
Como referido no capitulo do Estado de Arte relativo à tecnologia GPS (2.2), o recetor GPS
SiRF encontrado no módulo GE863-PRO3 também segue o protocolo NMEA-0183 através de uma
interface série (ver figura 4.13).
Figura 4.13: Dados enviados pelo recetor GPS para a interface série.
A Telit disponibiliza um daemon denominado gpsd que processa a informação que o recetor GPS
devolve pela porta série segundo o protocolo NMEA-0183 e disponibiliza uma interface acessível
usando uma biblioteca já compilada em C. Disponibiliza ainda uma aplicação, denominada cgps
para testar o deamon gpsd (que foi usada para ver os valores devolvidos pelo recetor), e na qual foi
detetado um problema nos dados apresentados, nomeadamente na data, que era incorreta. Devido
à data ser um fator importante para o desenvolvimento e implementação do projeto (para marcar as
amostras atmosféricas recolhidas), decidiu-se implementar a recolha da informação necessária com
acesso direto à informação dada pelo recetor na interface série, processando o protocolo NMEA-0183
e retirando a localização temporal (hora e data) e espacial (coordenadas longitude e latitude). Devido
às coordenadas virem do recetor num formato com duas componentes (ex: N 3723.516), uma relativa
aos graus e minutos da localização (ex: 3723.516), e a outra relativa à indicação do hemisfério
(ex: Norte), foi convertida essa informação para coordenadas em graus decimais que necessita
apenas de um valor por coordenada (por exemplo: 37.391933), facilitando o seu armazenamento
e processamento, quer local, quer na base de dados do servidor central. Sejam as coordenadas a
converter para graus decimais dadas por ddmm.mmmm, usadas na fórmula (4.1) que representa os
cálculos da conversão.
decimaldegrees =[ddmm.mmmm
100
]+ddmm.mmmm−
[ddmm.mmmm
100
]× 100
60(4.1)
Caso o valor indicativo do hemisfério seja Sul (S) ou Oeste (W) então o valor decimaldegrees é
negativo. A nível de GPS foi ainda implementada uma função que a partir de dois conjuntos de coor-
59
denadas, calcula a distância entre elas. Esta função foi implementada para garantir a possibilidade
da estação móvel poder recolher amostras com uma distância comum entre elas. Para isso foi usada
a fórmula de Haversine [25]. Sejam as coordenadas do último ponto de amostragem (lat1, lng1) e as
coordenadas da posição atual (lat2, lng2). Sejam ∆lat e ∆lng as diferenças dos valores de latitude
e longitude, respetivamente, e seja R o raio da Terra (R = 6371km). A distância d entre os dois
pontos é dada pela fórmula (4.2). A função de Haversine é obtida a partir de (4.3). Finalmente pode
obter-se o valor de d através da função inversa de Haversine ou a função arcsin, como representado
na fórmula (4.4).
haversin(d
R) = haversin(∆lat) + cos(lat1)× cos(lat2)× haversin(∆lng) (4.2)
haversin(δ) = sin2(δ
2) (4.3)
d = R× haversin−1(h) = 2R× arcsin(√h) (4.4)
A fórmula de cálculo da distância entre dois pontos em coordenadas de graus decimais (apresen-
tada acima) é mais complexa em relação à conversão num sistema de coordenadas de dois eixos
cartesianos, como é o caso do sistema de coordenadas Universal Transverse Mercator (UTM). Já
a conversão para UTM 9 era mais complexa do que a conversão para graus decimais, com a des-
vantagem de ter mais componentes por coordenada (2 componentes ao invés de 1, como é o caso
dos graus decimais). Assim, optou-se pela conversão para graus decimais e cálculo de distâncias
usando este sistema.
4.3.2.D Comunicação Wi-Fi
Os pontos de acesso existentes na estação foram configurados de forma a funcionarem como
pontes Wi-Fi, encaminhando as comunicações vindas da interface Ethernet para a interface sem fios
e vice versa. O primeiro passo na sua configuração foi a instalação da distribuição Linux OpenWRT.
Sendo sistema Linux é mais versátil e torna a configuração mais fácil. Os passos de configuração do
Asus WL-330gE estão descritos abaixo:
1. Instalar o sistema operativo OpenWRT;
(a) Colocar o Asus WL-330gE em modo ”restore”;
(b) Colocar IP no PC com 192.168.1.100, netmask 255.255.255.0 e gateway 192.168.1.220;
(c) Ligar o PC ao Asus WL-330gE;
(d) Estando na diretoria a imagem do OpenWRT (neste caso denominada openwrt-brcm-2.4-
squashfs.trx) a instalar, usar um cliente TFTP para instalar o OpenWRT, por exemplo:
tftp.exe -i 192.168.1.220 PUT openwrt-brcm-2.4-squashfs.trx
2. Criar palavra passe para aceder por SSH ao ponto de acesso usando o comando passwd e
introduzindo a palavra passe urbisnetadmin para o utilizador root;9Fórmulas de conversão para coordenadas UTM: http://www.uwgb.edu/dutchs/UsefulData/UTMFormulas.htm
60
3. Editar o ficheiro \etc\config\network para:
config 'switch' 'eth0'option 'enable' '1'
config 'switch_vlan' 'eth0_0'option 'device' 'eth0'option 'vlan' '0'option 'ports' '4 5'
config 'interface' 'loopback'option 'ifname' 'lo'option 'proto' 'static'option 'ipaddr' '127.0.0.1'option 'netmask' '255.0.0.0'
config 'interface' 'lan'option 'type' 'bridge'option 'ifname' 'eth0.0'option 'proto' 'static'option 'ipaddr' '192.168.1.1' # 192.168.[ID_ESTAÇÃO].1option 'netmask' '255.255.0.0'option 'broadcast' '192.168.255.255'
4. Editar o ficheiro \etc\config\wireless para:
config 'wifi-device' 'wl0'option 'type' 'broadcom'option 'channel' '11'option 'txpower' '18'option 'hwmode' '11bg'
# configuração da rede Ad-Hocconfig 'wifi-iface'
option 'device' 'wl0'option 'network' 'lan'option 'mode' 'adhoc'option 'ssid' 'Urbisnet'option 'key' 'urbisnetadhoc'option 'encryption' 'wep'option 'key' '1'option 'key1' 'EEAACC2211'
Com estas configurações os Asus WL-330gE ficam prontos para o funcionamento correto, quando
ligados à interface Ethernet da estação móvel e devidamente alimentados. A partir deste momento é
possível também configurar um computador com os dados da rede Ad-Hoc das estações, (com um
endereço IP diferente dos reservados para as estações indicados na secção 3.3.2.C do Protocolo de
Comunicação Wi-Fi), e a partir daí ligar por Telnet à estação móvel usando o seu IP (p.ex.: telnet
192.168.1.2), ou ao próprio ponto de acesso usando um cliente SSH e o seu endereço IP (p.ex.:
ssh 192.168.1.1). Este tipo de ligação via Wi-Fi facilitou o desenvolvimento, uma vez que deixou de
ser necessário uma ligação por cabo à estação móvel e, quando trabalhando com várias estações
ao mesmo tempo, bastava mudar o endereço IP da estação que se pretendia contactar.
61
4.3.3 Funcionamento Lógico
A estação móvel tem um funcionamento algo complexo devido à quantidade tarefas que de-
sempenha. As tarefas estão maioritariamente relacionadas com a aquisição de dados atmosféricos
como, por exemplo, a leitura dos sensores, leitura de dados GPS para georeferenciar as amostras
e passando também pelas comunicações GPRS e Wi-Fi para envio das mesmas. Além das tarefas
diretamente ligadas com os dados atmosféricos, existem também tarefas que asseguram a comuni-
cação remota por parte do servidor central para operações de monitorização e configuração.
O programa principal da estação (Urbisnet_integration) contém toda a lógica de funciona-
mento da estação e das tarefas descritas anteriormente. Na fase de inicialização, o programa
executa um conjunto de tarefas de configuração e criação de threads que correm em simultâneo
com a restante lógica do programa e são descritos de seguida.
• Leitura dos parâmetros de configuração a partir do ficheiro de configurações (config.txt);
• Leitura/criação dos parâmetros de estatísticas do ficheiro stats.txt;
• Configuração GSM/GPRS:
– Inserir PIN do cartão SIM usado;
– Verificar se existem ligações GPRS prévias e fechá-las caso tal suceda (para evitar confli-
tos);
– Iniciar ligação de dados GPRS ligando ao APN especificado, ficando com um endereço de
IP associado a esta ligação;
– Configurar firewall GPRS para aceitar apenas pedidos vindos do servidor central (a política
base desta firewall é de descartar todos os pedidos exceto vindos de destinos especifica-
dos);
– Configurar socket TCP a ser criado para receber ligações vindas do servidor central;
• Iniciar thread que lê dados do GPS, através da sua interface série, e guardar dados numa
estrutura de dados que pode ser acedida pelo restante programa;
• Iniciar thread que lê dados dos sensores atmosféricos, com uma periodicidade de acordo com
as configurações, e guardar os valores numa lista de amostras, prontas a enviar para o servidor
central;
• Se a estação estiver em modo de comunicação por Wi-Fi, iniciar thread com o protocolo Wi-Fi
(ver secção 3.3.2.C, referente ao protocolo Wi-Fi, para detalhes).
Após executar o conjunto de tarefas iniciais, o programa entra no ciclo principal, fazendo verifi-
cações e executando de forma periódica um conjunto de tarefas que são descritas abaixo.
• Verifica se já enviou endereço IP da interface GPRS para o servidor central. Caso não tenha
enviado, envia.
62
• Verifica se recebeu um pedido vindo do servidor central. Caso tenha recebido:
– Identifica o tipo do pedido e processa-o adequadamente;
– No caso da estação receber algum pedido de configuração de parâmetros ou envio de
ficheiro remoto, no final da operação a estação reinicia, de forma a refletir as configurações
no funcionamento da estação;
• Se estiver em modo de comunicação por GPRS para envio da amostras:
– Verifica se o número de amostras armazenadas tem valor igual ou superior ao parâmetro
de configuração number_of_samples_to_send, que indica o número de amostras enviadas
de cada vez para o servidor. Se sim, envia essas amostras para o servidor central.
• Se estiver em modo de comunicação por Wi-Fi para envio da amostras:
– Verifica se o número de amostras armazenadas tem valor igual ou supera o parâmetro de
configuração max_messages_adhoc_mode que indica o número máximo de amostras guar-
dadas em modo Wi-Fi antes de usar a ligação GPRS para enviar number_of_samples_to_send
amostras para o servidor. Se sim, envia essas amostras para o servidor central.
• De 5 em 5 minutos faz um conjunto de operações de rotina:
– Verifica o estado da ligação GPRS e do socket em escuta de ligações vindas do servidor
central. Caso a ligação GPRS tenha sido interrompida, recupera a ligação. Caso o socket
não esteja em modo de escuta, configura o socket para esse modo.
– Grava configurações (no ficheiro conf.txt);
– Grava estatísticas (no ficheiro stats.txt);
63
64
5Avaliação
Contents5.1 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 Testes de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
65
Este capitulo tem como objetivo apresentar testes realizados às funcionalidades implementadas,
verificando que o seu funcionamento está de acordo com os requisitos e objetivos iniciais do projeto
URBISNET. Além dos testes funcionais, realizados com a estação móvel em posição fixa, foram
realizados testes de campo com a estação móvel acoplada a um veículo de forma a testar o seu
funcionamento neste ambiente e ainda o desempenho das comunicações Wi-Fi entre vários nós.
5.1 Testes Funcionais
Nesta secção descrevem-se testes a algumas das funcionalidades do trabalho implementado,
nomeadamente a monitorização dos parâmetros da estação móvel, configuração de parâmetros,
e envio de um ficheiro para a estação móvel. Todos estes testes são realizados com a seguinte
configuração:
• Estação em posição fixa para facilitar a recolha de dados para inserção neste relatório;
• Estação ligada a um computador por porta série para recolha de informação da mesma;
• Um outro computador com um browser e acesso à Internet de forma a aceder ao website
URBISNET e a partir daí desencadear os processos;
Figura 5.1: Esquema de configuração para os testes funcionais.
Estes testes têm como objetivos:
• Verificar o correto funcionamento global das funcionalidades descritas;
• Verificar o correto funcionamento da estação móvel a desempenhar essas funções;
• Verificar o correto funcionamento do website URBISNET;
• Verificar o correto funcionamento das comunicações via GPRS da estação móvel;
5.1.1 Monitorização de parâmetros da Estação
Para efetuar a monitorização de parâmetros de uma estação foi necessário aceder ao website
URBISNET, ir à secção ”Monitorizar”, verificar a existência da estação móvel com o ID 1 na tabela
de ”Estações Registadas” e seleccionar o botão ”Monitorizar” referente a essa mesma estação. De
66
Figura 5.2: Website URBISNET: pedido de monitorização de parâmetros.
seguida foi apresentada uma informação a indicar que estava a ser estabelecida a comunicação com
a estação móvel 1 (ver figura 5.2).
Após a estação móvel receber o pedido, devolveu ao servidor central a informação de monitori-
zação requerida (figura 5.3).
Figura 5.3: Estação móvel: recebe pedido de monitorização e responde via GPRS.
A informação de monitorização da estação 1 foi, por fim, apresentada no website URBISNET
numa tabela à direita, revelando o sucesso da operação de monitorização (figura 5.4).
5.1.2 Configuração de parâmetros Estação
Para efetuar a configuração de parâmetros de uma estação foi necessário aceder ao website
URBISNET, ir à secção ”Configurar”, verificar a existência da estação móvel com o ID 1 na tabela de
”Estações Registadas”, seleccionar essa estação e seleccionar botão ”Configurar Parâmetros”. Foi
apresentado um conjunto de parâmetros que podem ser configurados. Neste teste foi seleccionado o
valor ”Distância” para o parâmetro sample_mode e o valor de 50 para o parâmetro distance_samples
67
Figura 5.4: Website URBISNET: resultado do pedido de monitorização de parâmetros.
(figura 5.5). Após a introdução destes valores foi selecionado o botão ”Enviar”, sendo apresentada
uma mensagem de seguida indicando que o website estava a tentar comunicar com a estação (figura
5.6).
Figura 5.5: Website URBISNET: pedido de configuração de parâmetros.
Após a estação móvel receber o pedido de configuração, devolveu ao servidor central a informa-
ção que a operação de configuração foi realizada com sucesso e reiniciou-se, para que os novos
valores dos parâmetros pudessem entrar em vigor no funcionamento da estação (figura 5.7).
No website URBISNET foi apresentada uma mensagem de sucesso (figura 5.8) após receber
essa informação (de sucesso) da estação móvel.
68
Figura 5.6: Website URBISNET: mensagem de espera de contacto com estação móvel.
Figura 5.7: Estação móvel: recebe pedido de configuração, responde ao servidor e reinicia.
Figura 5.8: Website URBISNET: confirmação de sucesso da configuração de parâmetros.
5.1.3 Envio de ficheiro para Estação
Para enviar um ficheiro para estação foi necessário aceder ao website URBISNET, ir à secção
”Configurar”, verificar a existência da estação móvel com o ID 1 na tabela de ”Estações Registadas”,
seleccionar essa estação e clicar no botão ”Enviar Ficheiro”. De seguida foi apresentado um quadro
para seleccionar o ficheiro a enviar para a estação e a versão desse ficheiro. Para este teste foi
usado o ficheiro binário do programa Urbisnet_integration e criado um script de instalação do
69
mesmo para formar um ficheiro de arquivo compactado denominado teste.tar.gz a enviar para
a estação (de acordo com o explicado no capitulo da Arquitetura Funcional 3.2.3.A). Este ficheiro
foi selecionado no website, introduzida a versão do ficheiro (1.2) e selecionado o botão de ”Enviar”
(figura 5.9).
Figura 5.9: Website URBISNET: interface da opção de envio de ficheiro.
De seguida apareceu uma mensagem indicando que o website estava a tentar comunicar com a
estação (idêntica à da figura 5.6).
Após a estação móvel receber a totalidade do ficheiro, devolveu ao servidor central a informação
que a operação de receção de ficheiro foi realizada com sucesso (figura 5.10) e reiniciou-se, para
que pudesse instalar a nova versão do programa.
Figura 5.10: Estação móvel: recebe ficheiro enviado pelo website com sucesso.
No website URBISNET foi apresentada uma mensagem de sucesso (idêntica à da figura 5.8)
após receber essa informação (de sucesso) da estação móvel.
5.2 Testes de campo
Nesta secção são descritos dois tipos de testes realizados às estações móveis em ambiente
móvel, que será a sua finalidade. O primeiro teste tem como principal objetivo avaliar o funciona-
70
mento de uma estação em ambiente móvel, com a recolha de amostras e seu envio via Wi-Fi. O
segundo teste tem como objetivo avaliar o funcionamento e desempenho apenas da comunicação
Wi-Fi, envolvendo duas estações móveis em dois veículos.
5.2.1 Recolha de amostras em ambiente móvel
Uma vez que o verdadeiro propósito da estação móvel é estar acoplada a um veículo com mobi-
lidade, foi realizado um teste com essas características.
5.2.1.A Objetivos
Os objetivos deste teste foram:
• Testar a recolha de amostras atmosféricas em movimento;
• Testar comunicação Wi-Fi entre a estação móvel e o gateway ;
• Verificar o correto funcionamento do gateway, enviando as amostras recebidas para o servidor
central;
• Conseguir visualizar as amostras recolhidas no website URBISNET;
5.2.1.B Configuração
O teste foi realizado nas proximidades do edifício do IST-Taguspark devido à necessidade do
gateway ter conectividade física à rede (Internet) para comunicar com o servidor central. Estando
localizado na sala 1.4.32, o gateway foi colocado do lado de fora da janela, ligado à corrente e à
rede, de forma a ter linha de vista com a estrada onde iria passar a estação móvel.
Figura 5.11: Percurso realizado com a estação móvel neste teste.
71
A estação móvel foi colocada em cima do tablier de uma viatura de forma a conseguir adquirir
sinal GPS enquanto realizava o percurso e ao mesmo tempo conseguir ser alimentada pelo conector
do isqueiro do veículo. O percurso realizado está indicado na figura 5.11 a verde, onde a letra ’A’
indica o inicio do percurso e a ’B’ indica o seu final. O posicionamento do gateway é indicado com
’GW’ a vermelho. A estação foi configurada para recolher amostras de 100 em 100 metros ao longo
do percurso e para enviar as enviar por Wi-Fi.
5.2.1.C Resultados
Após a conclusão do teste, foi possível observar no site URBISNET as amostras recolhidas pela
estação ao longo do percurso (figura 5.12), validando desde logo o correto funcionamento da co-
municação entre as estações móveis e o servidor central, passando pelo gateway, assim como a
ferramenta de visualização no website. Comparando a figura figura 5.12 com a figura 5.11, relativa
ao percurso efetuado, é possível ver que existe uma distância considerável (superior a 100 metros
claramente) entre o fim do percurso e a última amostra apresentada no site (o apontador mais abaixo
no mapa). Isto deve-se ao facto de a amostra ter sido registada pela estação mas nunca ter sido en-
viada para o gateway, devido à perda de conectividade com o mesmo. Esta perda de conetividade
parece normal por ter deixado de haver linha de vista na comunicação, uma vez que a estação móvel
estava colocada no interior da viatura na parte da frente, e esta não é a posição ideal (a ideal seria
no topo do carro).
A partir do registo da estação é possível perceber que a estação enviou amostras (com sucesso)
para o gateway por 3 vezes:
23/2/2012-15:52:35|->Connect_GW: Sent message to gateway "192.168.253.1" with 575 bytes23/2/2012-15:52:35|->Connect_GW: Received response from gateway "192.168.253.1":
192.168.1.2,OK.RTT=208ms23/2/2012-15:52:43|->Connect_GW: Sent message to gateway "192.168.253.1" with 96 bytes23/2/2012-15:52:43|->Connect_GW: Received response from gateway "192.168.253.1":
192.168.1.2,OK.RTT=7ms23/2/2012-15:52:51|->Connect_GW: Sent message to gateway "192.168.253.1" with 96 bytes23/2/2012-15:52:51|->Connect_GW: Received response from gateway "192.168.253.1":
192.168.1.2,OK.RTT=8ms
As amostras enviadas pela estação móvel (8 no total) estão descritas de seguida:
2012-2-23 15:51:12,1,38.741077,-9.301159,0.927734,1.706543,0.239258,2.011108,9.87,44.88;2012-2-23 15:51:43,1,38.740807,-9.302377,0.724487,1.691895,0.242310,2.002563,9.62,44.89;2012-2-23 15:51:52,1,38.740429,-9.303460,0.724487,1.694336,0.242920,2.002563,9.62,44.89;2012-2-23 15:52:2,1,38.739773,-9.304350,0.728760,1.703491,0.243530,2.002563,9.71,44.90;2012-2-23 15:52:24,1,38.738895,-9.304689,0.756836,1.721191,0.240479,2.014771,9.79,44.92;2012-2-23 15:52:34,1,38.738094,-9.304096,0.758667,1.723633,0.239868,2.015381,9.71,44.94;2012-2-23 15:52:43,1,38.737141,-9.303741,0.732422,1.709595,0.244751,2.011108,9.83,44.95;2012-2-23 15:52:51,1,38.736412,-9.303034,0.729370,1.699829,0.245972,2.009277,9.83,44.97;
Cruzando a informação do registo da estação, nomeadamente as marcas temporais do envio
de dados, com as marcas temporais das amostras, é possível perceber que da primeira vez foram
enviadas 6 amostras (correspondentes às primeiras do percurso) e das duas vezes seguintes apenas
1 amostra em cada. É possível perceber portanto que houve conectividade entre o gateway e a
72
Figura 5.12: Amostras recolhidas durante o ensaio, visualizadas no site do Urbisnet.
estação imediatamente a seguir à criação da 6a amostra (às 15:52:35) e, pelo menos até ao envio da
última amostra (às 15:52:51). Com estes dados é possível perceber que houve conectividade entre
a estação e o gateway na zona representada a vermelho na figura 5.13. De referir que a distância
aproximada entre o ponto mais distante de conectividade e o gateway é de 140 metros, conseguida
com linha de vista entre ambos, que é considerado um resultado bastante satisfatório.
Figura 5.13: Ilustração de zona de conectividade entre a estação e o gateway no percurso realizado.
73
5.2.2 Desempenho das comunicações Wi-Fi
De forma a avaliar num teste de campo os aspetos de ad-hoc networking baseado em Wi-Fi en-
volvendo pares de estações móveis e gateways, foi criada uma aplicação específica para as estações
móveis, denominada urbisnet_adhoc. Esta inclui apenas a lógica em conjunto com a capacidade
de registar, para cada transmissão de dados, a quantidade de dados enviados e, no caso de ser
o nó estação móvel com o identificador mais baixo, a latência Round-Trip Time (RTT). A latência
RTT foi calculada como a diferença de tempo entre os instantes de envio dos dados da estação com
o identificador menor e da receção (na mesma estação) dos dados provenientes da estação com
identificador superior (incluindo o tempo de processamento realizado pela segunda estação entre a
receção dos dados e o envio). Decidiu-se usar uma aplicação diferente de forma a facilitar a rea-
lização do teste e o uso de quantidades de dados pré-definidas, facilitando também a análise dos
resultados.
O teste consiste na transmissão de dados (amostras atmosféricas) entre duas estações móveis,
colocadas em dois veículos distintos, de forma a trocarem entre si dados quando se encontram no
alcance das suas interfaces Wi-Fi. Além desta troca de dados, num percurso pré-definido, é também
feita a passagem de uma das estações nas proximidades do gateway de forma a transmitir-lhe não
só os dados que tinha na sua posse no inicio, mas também os dados recebidos da outra estação.
5.2.2.A Objetivos
Os objetivos deste teste foram aferir a eficácia (verificar que as mensagens de ambas as estações
chegam ao gateway ) e a eficiência (num teste de campo) do protocolo Wi-Fi implementado. Além
destes objetivos foi também testada a comunicação entre estações moveis, que não aconteceu no
teste de campo anteriormente apresentado.
5.2.2.B Cenário de teste
Neste teste existem 3 componentes, 2 estações móveis (MS1 e MS2) colocadas em veículos
e ainda um gateway (GW) colocado no edifício do IST-Taguspark (tal como no teste de campo de
recolha de amostras 5.2.1). Foi definido um percurso para as estações MS1 e MS2 (a azul e verde,
respetivamente, na figura 5.14) para que ambas as estações iniciem o movimento simultaneamente
em sentidos opostos, se cruzem, e troquem informação. A estação MS1, contendo já a informação
proveniente de MS2, cruza-se depois com o gateway de forma a debitar a informação de ambas
as estações. A estação MS2 nunca transmite dados diretamente para o gateway (pois não fica ao
alcance da sua interface Wi-Fi), de forma a ser possível perceber que a estação MS1 desempenha
corretamente o seu papel de recolha dos dados da estação MS2 e envio para o gateway.
Neste cenário foram realizados ensaios com diferentes configurações e parâmetros. Um dos
parâmetros foi a quantidade de dados transferida entre estações. Existem 3 dimensões de dados:
• Carga Baixa (small) - Corresponde a 5 mensagens de amostras atmosféricas;
• Carga Média (medium) - Corresponde a 20 mensagens de amostras atmosféricas;
74
Figura 5.14: Percurso realizado com as estações móveis MS1 e MS2.
• Carga Superior (large) - Corresponde a 40 mensagens de amostras atmosféricas;
A velocidade dos veículos foi outro dos parâmetros do teste, por isso foram realizados ensaios
com duas velocidades distintas (20 km/h e 40 km/h) que os veículos adotaram, da forma mais cons-
tante possível, nos seus percursos.
Foram realizados ensaios a 20 km/h para cada um dos tipos de carga (igual nas duas estações) e
ainda um teste (com carga média em ambas) a 40 km/h. Cada ensaio foi repetido 6 vezes de forma
a obter resultados com maior significância estatística.
5.2.2.C Resultados
A realização dos vários ensaios permitiu compilar um conjunto de tabelas e gráficos que podem
ser consultados no anexo C. Um resumo dos resultados mais relevantes estão identificados na tabela
5.1.
Ficheiro de Velocidade RTT médio entre RTT médio entre % de sucessoDados estações (MS1 e MS2) estação MS2 e gateway dos ensaiossmall 20 km/h 440.8 ms 380.6 ms 83%
medium 20 km/h 586.75 ms 338.75 ms 67%large 20 km/h 1083.8 ms 847.4 ms 83%
medium 40 km/h 744 ms N/A 100%
Tabela 5.1: Tabela resumo dos ensaios de desempenho Wi-Fi.
A partir da tabela acima representada, podemos concluir que o RTT médio aumenta, como espe-
rado, com a dimensão do bloco de dados enviados. Os valores são satisfatórios tendo em conta que
o protocolo não foi criado para ter um desempenho ótimo de latência, mas sim para oferecer robustez
na disseminação de informação até ao nó gateway. É possível também concluir que a latência subiu
com quando a velocidade duplicou (de 20 para 40 km/h) mas, ainda assim, a 40 km/h obteve-se uma
75
elevada taxa de sucesso que é bastante satisfatória. O teste a 40 km/h foi realizado num local onde
não foi possível instalar o gateway. Em todo o caso, os testes a mais baixa velocidade sugerem que
a ligação entre duas estações em movimento poderá ser mais problemática do que a ligação entre
uma estação e o gateway (fixo). O desempenho da comunicação em função da velocidade revelou-
se assim sólido. Durante os testes foram identificados problemas na comunicação que levaram a
que nem todos os testes tivesse uma taxa de sucesso de 100% na transmissão dos dados. Estes
problemas estão relacionados com a implementação do protocolo de handshake entre nós durante
as transferências de blocos de dados, e serão corrigidos numa futura revisão do sistema de comu-
nicação de forma a melhorar a eficácia. É ainda de referir que, nos dois primeiros testes, a estação
MS1 não estava colocada na viatura de forma a ter linha de vista com os restantes elementos, o
que provavelmente contribuiu para resultados menos satisfatórios. Nos dois testes seguintes isso
foi corrigido, atendendo a que numa configuração realista as estações deverão estar colocadas nas
viaturas de forma a terem linha de vista com todos os elementos que a circundam.
Este teste permitiu fazer ensaios num cenário que se pretendeu ser comparável com o que será
encontrado quando as estações estiverem instaladas nos autocarros da Carris. Permitiu também
concluir sobre a eficiência e eficácia do protocolo de comunicação Wi-Fi, revelando resultados satis-
fatórios e úteis para melhorar este protocolo, nomeadamente:
• A latência média sobe com o aumento do tamanho dos dados enviados entre estações móveis
e com o aumento da velocidade, como esperado;
• Em todos os casos onde a comunicação entre estações (MS1 e MS2) teve sucesso, também
a comunicação entre a estação móvel MS1 e o gateway teve sucesso, transmitindo os seus
dados e os de MS2;
• A implementação da comunicação Wi-Fi pode ser melhorada ao nível da eficácia alterando
os sockets usados de UDP para TCP (ainda que tal possa prejudicar os valores RTT) e/ou
melhorando o protocolo de handshaking usado na transmissão de blocos de dados (gestão de
tramas de acknowledgement).
76
6Conclusões e Trabalho Futuro
Contents6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
77
Neste capítulo são apresentadas as conclusões da realização desta tese e são também propostas
direções de trabalho futuro no âmbito do projeto URBISNET.
6.1 Conclusões
Esta tese descreve a arquitetura de um sistema de comunicações para estações móveis de reco-
lha de dados atmosféricos. Foi um trabalho bastante abrangente que envolveu o domínio de múltiplas
ferramentas, tecnologias e componentes. O presente documento começou por uma visita ao estado
de arte em tecnologias, conceitos e projetos existentes que diretamente ou indiretamente influenci-
aram o desenvolvimento desta tese. São exemplo disso as tecnologias de comunicação sem fios
Wi-Fi e GPRS, comunicações veiculares, e encaminhamento nas mesmas. No capítulo 3 são apre-
sentadas as arquiteturas arquitetura geral, funcional, e de comunicações implementadas de forma
a cumprir os objetivos desta tese, que passavam pelo desenvolvimento de funcionalidade nas es-
tações móveis para recolha de dados atmosféricos, armazenamento e disponibilização dos dados
adquiridos, criação dos protocolos de comunicação (GPRS e Wi-Fi) e finalmente a criação de uma
ferramenta web de gestão remota dos nós da rede. No capítulo 4 foi descrita a implementação da
arquitetura nos três elementos que constituem este trabalho (estações móveis, gateways e servidor
central) dando ênfase ao desenvolvimento e configuração dos mesmos. Por último, no capítulo 5,
foi apresentado um conjunto de testes de forma a validar as funcionalidades implementadas, assim
como as comunicações utilizadas. As soluções implementadas provaram cumprir os objetivos pro-
postos, demonstrando resultados bastante satisfatórios, ainda que se tenham identificado aspetos a
melhorar, nomeadamente o desempenho das comunicações Wi-Fi durante a fase de transferência
de blocos de dados entre nós da rede.
6.2 Trabalho Futuro
Quer devido a questões de tempo ou escolhas de desenvolvimento ou equipamento, existe traba-
lho relacionado com o que foi desenvolvido que pode ser realizado de futuro:
• Transferência da lógica e serviços de servidor central localizado no cluster Sigma do IST para
uma máquina independente, registada com domínio web mais consistente com o projeto UR-
BISNET;
• Melhorar implementação do protocolo Wi-Fi de forma a conseguir uma maior eficácia;
• Simulação do protocolo Wi-Fi implementado num em condições mais próximas do cenário de
aplicação pretendido (rede de autocarros da Carris), usando para isso um simulador de redes
como, por exemplo, o NS-2, de forma a validar de forma mais correta e consistente o protocolo
e a configuração ideal dos seus parâmetros;
• Implementar configuração de forma remota dos nós gateways, tal como acontece com as esta-
ções móveis;
78
• Realização de testes de campo com condições mais realistas e maior duração (para se obterem
melhores estimativas das métricas de desempenho), e também com mais estações móveis.
79
80
Bibliografia
[1] J. S. O. F. E. Bustamante and R. A. Berry, “Down the Block and Around the
Corner – The Impact of Radio Propagation on Inter-vehicle Wireless Communication,”
Communications Magazine, IEEE, June 2009.
[2] D. N. G. da Silva Simão Quelhas, “Mobile station for air quality mapping sensor network,” Master’s
thesis, Instituto Superior Técnico, Nov 2011.
[3] I. SiRF Technology, “NMEA Reference Manual,” 2007.
[4] J. Schiller, Mobile Communications, 2nd ed. Addison Wesley, 2003.
[5] D. Boswarthick, “Machine 2 Machine - When the machines start talking,” February 2010.
[6] ETSI, “TS 102 689 Machine-to-Machine communications (M2M); M2M service requirements,”
ETSI, Tech. Rep., August 2010.
[7] ——, “TR 102 691 Machine-to-Machine communications (M2M); Smart Metering Use Cases,”
ETSI, Tech. Rep., May 2010.
[8] J. B.-Y. Tsui, Fundamentals of Global Positioning System Receivers: A Software Approach,
1st ed. Wiley-Interscience, 2000.
[9] G. Brasche and B. Walke, “Concepts, services, and protocols of the new GSM phase 2+ general
packet radio service,” Communications Magazine, IEEE, vol. 35, aug 1997.
[10] M. Limited, “GPRS Tutorial.”
[11] D. Jiang and L. Delgrossi, “Ieee 802.11p: Towards an international standard for wireless access
in vehicular environments,” in Vehicular Technology Conference, 2008. VTC Spring 2008. IEEE,
may 2008, pp. 2036 –2040.
[12] J. F. Kurose and K. W. Ross, Computer Networking: A Top-Down Approach, 4th ed. USA:
Addison-Wesley Publishing Company, 2007.
[13] J. Jakubiak and Y. Koucheryavy, “State of the art and research challenges for vanets,” in
Consumer Communications and Networking Conference, 2008. CCNC 2008. 5th IEEE, jan.
2008, pp. 912 –916.
81
[14] C. Perkins and E. Royer, “Ad-hoc on-demand distance vector routing,” in wmcsa. Published by
the IEEE Computer Society, 1999, p. 90.
[15] D. Johnson and D. Maltz, “Dynamic source routing in ad hoc wireless networks,” Mobile
computing, pp. 153–181, 1996.
[16] V. Namboodiri, M. Agarwal, and L. Gao, “A study on the feasibility of mobile gateways for vehicu-
lar ad-hoc networks,” in Proceedings of the 1st ACM international workshop on Vehicular ad hoc
networks. ACM, 2004, pp. 66–75.
[17] K. Wong, B. Lee, B. Seet, G. Liu, and L. Zhu, “Busnet: Model and usage of regular traffic patterns
in mobile ad hoc networks for inter-vehicular communications,” in Proc. ICT. Citeseer, 2003.
[18] G. Liu, B. Lee, B. Seet, C. Foh, K. Wong, and K. Lee, “A routing strategy for metropolis vehicular
communications,” in Information Networking. Springer, 2004, pp. 134–143.
[19] B. Karp and H. Kung, “Gpsr: greedy perimeter stateless routing for wireless networks,” in
Proceedings of the 6th annual international conference on Mobile computing and networking.
ACM, 2000, pp. 243–254.
[20] C. Maihofer, “A survey of geocast routing protocols,” Communications Surveys & Tutorials, IEEE,
vol. 6, no. 2, pp. 32–42, 2004.
[21] G. Pei, M. Gerla, X. Hong, and C.-C. Chiang, “A wireless hierarchical routing protocol with
group mobility,” in IEEE Wireless Communications and Networking Conference, WCNC1999,
September 1999, New Orleans, LA, USA, IEEE. IEEE, September 1999.
[22] A. Vahdat, D. Becker et al., “Epidemic routing for partially connected ad hoc networks,” Technical
Report CS-200006, Duke University, Tech. Rep., 2000.
[23] C. consortium, “D2.2.6 - WiFi performance comparison in the CARLINK,” University of Málaga,
Tech. Rep., March 2008.
[24] V. D. F. Carvalho, “Estação móvel para medida da qualidade do ar,” Master’s thesis, Instituto
Superior Técnico, sep 2007.
[25] J. Montavont and T. Noel, “Ieee 802.11 handovers assisted by gps information,” in Wireless and
Mobile Computing, Networking and Communications, 2006.(WiMob’2006). IEEE International
Conference on. IEEE, 2006, pp. 166–172.
82
AParâmetros de monitorização e
configuração das estações móveis
A-1
Os parâmetros de monitorização que é possível obter das estações móveis dividem-se em duas
categorias: parâmetros passíveis de configuração (guardados no ficheiro config.txt na estação)
e os parâmetros de estatísticas de funcionamento da estação (guardados no ficheiro stats.txt na
estação).
Parâmetro Descriçãosample_mode Comanda o modo de captura de amostras. Pode ser temporal
(de ’x’ em ’x’ segundos) em que o valor de ’x’ é configurável peloparâmetro "sampling_time". Em alternativa pode ser uma distân-cia (de ’y’ em ’y’ metros) em que o valor de ’y’ é configurável peloparâmetro "distance_samples".
sampling_time Valor em segundos entre a captura de novas amostras (quandoa captura de amostras está no modo temporal).
distance_samples Valor em metros entre a captura de novas amostras (quando acaptura de amostras está no modo distância).
number_of_samples_to_send Número de amostras que são enviadas de cada vez quando aestação móvel está a comunicar por GPRS.
station_ID Número de identificação da estação.APN Endereço do APN a usar nas configurações GPRS da estação.PIN Código PIN do cartão SIM usado pela estação.server_IP_address Endereço IP do servidor central.server_mask Máscara de rede do endereço IP do servidor.web_host Endereço web do servidor para o qual são enviadas as amostras
e dados da estação.upload_Web_Address Endereço da página web para a qual são enviadas as amostras
e dados da estação.data_mode Modo de comunicação entre a estação e o servidor central para
envio das amostras. No modo ”GPRS” envia as amostras direc-tamente, enquanto no modo ”ADHOC” estas são passadas a umgateway.
Tabela A.1: Parâmetros da estação móvel passíveis de configuração e monitorização no website URBISNET.
Parâmetro Descriçãolast_sample_sent_GPRS Data e coordenadas GPS da última transmissão de amostras via
GPRS.last_GPS_info Data e coordenadas GPS dos últimos dados GPS válidos.GPRS_data_sent Quantidade de dados enviados por GPRS (em bytes).GPRS_data_received Quantidade de dados recebidos por GPRS (em bytes).number_samples_saved Número de amostras guardadas por enviar.program_version Versão do programa a correr na estação.
Tabela A.2: Parâmetros de estatísticas de funcionamento da estação possíveis de monitorizar no website UR-BISNET.
A-2
BProtocolo de comunicação Wi-Fi na
estação móvel
B-1
Figura B.1: Diagrama simplificado do protocolo de comunicação Wi-Fi no nó estação móvel.
B-2
CResultados do Teste de Desempenho
das Comunicações Wi-Fi
C-1
Neste anexo encontram-se as tabelas e gráficos de resultados do teste de campo para avaliação
do desempenho das comunicações Wi-Fi descrito na secção 5.2.2
Na tabela C.1 estão representados os tempos de RTT entre o envio dos dados da estação MS1
para a estação MS2 e retorno dos dados da estação MS2 para a estação MS1. Nos ensaios identifi-
cados como ”ERRO” a transmissão dos dados da estação MS2 para MS1 falhou.
EnsaioFicheiro de dados Velocidade 1 2 3 4 5 6 Médiabaixa (5 amostras) 20 km/h 96 1029 1026 29 ERRO 24 440.8
média (20 amostras) 20 km/h 1315 ERRO 344 354 ERRO 334 586.75superior (40 amostras) 20 km/h 1634 582 799 652 1752 ERRO 1083.8
média (20 amostras) 40 km/h 751 407 946 1321 344 695 744
Tabela C.1: Tabela com os valores de RTT (em ms) medidos entre as duas MS nos vários ensaios.
A figura C.1 mostra os valores de RTT registados na tabela C.1 com diferentes dimensões de
amostras trocadas entre cada MS a uma velocidade de 20 km/h (velocidade aproximada de cada
estação aquando o cruzamento de ambas). Observámos que, apesar de realizados poucos ensaios,
existe uma maioria de valores (3 ou mais) em cada teste que estão compreendidos num curto inter-
valo de tempo, mostrando alguma consistência. Por exemplo, no teste com o o número ”Médio” de
amostras, obtivémos 3 valores que veriaram entre os 340 e 360 ms. Isto leva a crer que os valores
mais elevados registados em cada tipo de teste podem dever-se a fatores externos não controláveis
(como reflexões ou refracções do sinal).
Figura C.1: Gráfico de comparação do RTT medido entre as duas MS nos ensaios realizados a 20 km/h comdiferentes tamanhos de amostras.
O gráfico da figura C.2 compara os valores de RTT registados na tabela C.1 com a mesma di-
mensão de amostras (média, 20 amostras) com diferentes velocidades (velocidade aproximada de
C-2
cada estação aquando do cruzamento de ambas). Mais uma vez, observámos uma consistência na
maioria dos valores obtidos nos dois testes.
Figura C.2: Gráfico de comparação do RTT medido entre as duas MS nos ensaios realizados a 20 km/h e 40km/h com um tamanho médio de amostras.
A tabela C.2 representa os tempos de RTT entre o envio dos dados da estação MS1 para o
gateway (o bloco de dados transferido compreende as amostras de MS1 e as da MS2). Os ensaios
identificados como ”ERRO” devem-se aos erros verificados na transferência de dados entre as duas
MS que têm repercussão no envio para o gateway.
EnsaioFicheiro de dados Velocidade 1 2 3 4 5 6 Médiabaixa (10 amostras) 20 km/h 1266 258 222 82 ERRO 75 380.6média (40 amostras) 20 km/h 332 ERRO 347 301 ERRO 375 338.75
superior (80 amostras) 20 km/h 429 1250 781 867 910 ERRO 847.4média (40 amostras) 40 km/h N/A N/A N/A N/A N/A N/A N/A
Tabela C.2: Tabela com os valores de RTT (em ms) medidos entre a estação MS1 e o gateway.
A tabela C.3 representa os tempos de processamento na estação MS2 entre a receção dos dados
provenientes de MS1 e o envio dos seus próprios dados para essa MS. Estes valores podem ser
deduzidos aos valores da tabela C.1 caso se pretenda obter um valor mais aproximado de RTT,
excluindo o processamento. Estes valores são bastante reduzidos quando comparados com a média
na tabela C.1 (representam menos de 2%), pelo que não são considerados relevantes.
C-3
EnsaioFicheiro de dados Velocidade 1 2 3 4 5 6 Médiabaixa (5 amostras) 20 km/h 4 3 3 3 4 3 3.3
média (20 amostras) 20 km/h 9 8 8 7 7 8 7.8superior (40 amostras) 20 km/h 13 13 13 15 13 13 13.3média (20 amostras) 40 km/h 7 8 7 7 8 7 7.3
Tabela C.3: Tabela dos tempos de processamento (em ms) na estação MS2.
C-4
