Implementação e Monitorização de uma Rede de Sensores Móveis para 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úri Presidente: Prof. Paulo Jorge Pires Ferreira Orientador: Vogais: Prof. João Pedro Castilho Pereira Santos Gomes 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 communications, 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 preocupado 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 mobilidade 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 funcionamento 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 Atmosfé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 5 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 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. 3.6 Opções de visualização das amostras no website . . . . . . . 25 . . . . . . . . . . . . . . . . . . . . . 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 protocolo 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 ensaios realizados a 20 km/h e 40 km/h com um tamanho médio de amostras. xii . . . . . . C-3 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 1 Introdução Contents 1.1 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 preocupado 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, localizados 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, gerando 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 Service (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 transportes 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 (incluindo 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 é apresentado 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 capí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 2 Estado de Arte Contents 2.1 2.2 2.3 2.4 2.5 2.6 M2M . . . . . . . . . . . . . . . . . . . . Global Positioning System (GPS) . . . General Packet Radio Service (GPRS) IEEE 802.11 . . . . . . . . . . . . . . . . Vehicular ad-hoc network (VANET) . . Monitorização Atmosférica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7 8 10 13 19 5 Neste capitulo são apresentados conceitos, tecnologias e protocolos que estão diretamente relacionados 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 Positioning 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 implementaçõ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 descoberta 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 humana, 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 interveniente 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 algumas utilizações de M2M, estando alguns já concluídos e outros em versão draft (versão em desenvolvimento), 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 conhecida 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 proliferar 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 automó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, causando erros na localização. Atualmente estão a ser desenvolvidos outros sistemas de navegação 1 Selective Availability : degradação do sinal GPS http://www.pnt.gov/public/sa/ de uso da tecnologia GPS: http://www.gps.gov/applications 2 Exemplos 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 ID Mensagem Hora UTC Estado Latitude Indicador N/S Longitude Indicador E/W Velocidade Ângulo em relação ao chão Data Checksum Exemplo $GPRMC 151230.487 A 3723.2475 N 12158.3416 W 0.13 309.62 120211 *10 Descrição Mensagem RMC do sistema GPS hhmmss.sss A = Dados válidos | V = Dados inválidos ddmm.mmmm N = Norte | S = Sul ddmm.mmmm E = Este | W = Oeste Velocidade em nós ddmmaa - 12 de Fevereiro de 2011 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 3 Sistema en.htm de navegação global europeu, Galileo: http://ec.europa.eu/enterprise/policies/satnav/galileo/index_ de navegação global chinês, Compass: http://www.beidou.gov.cn/index.html de navegação global russo, Glonass: http://new.glonass-iac.ru/en/ 6 Sistema de navegação regional indiano, IRNSS: http://www.india-defence.com/reports-1894 7 Dados do mercado de telecomunicações do GSM World: http://www.gsmworld.com/newsroom/market-data/market_ 4 Sistema 5 Sistema 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 CS-1 CS-2 CS-3 CS-4 1 Slot 9.05 13.4 15.6 21.4 2 Slot 18.2 26.8 31.2 42.8 3 Slot 27.15 40.2 46.8 64.2 4 Slot 36.2 53.6 62.4 85.6 5 Slot 45.25 67 78 107 6 Slot 54.3 80.4 93.6 128.4 7 Slot 63.35 93.8 109.2 149.8 8 Slot 72.4 107.2 124.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 adicionaram 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 capacidade 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 di9 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 atribuiçã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 facilmente 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 cabos 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 suscetibilidade 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ção Apresentação Sessão Transporte Rede Ligaçã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, nomeadamente 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 comunicaçã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ância 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 foi 8 Linha 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]. Adicionalmente, 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 mesmas 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 desvanecimento. 2.4.6 802.11 - Conclusões Ao longo dos anos o IEEE foi lançando emendas à norma original 802.11 para, sobretudo, oferecer maiores débitos. De forma a sumarizar as normas apresentadas anteriormente, estão representadas na tabela 2.4 algumas característica que as permitem comparar. Norma Débito (Mb/s) Throughput (Mb/s) Alcance em linha de vista (m) 802.11b 11 6 802.11a 54 32 802.11g 54 22 802.11p 27 12 100 50 100 1000 Vantagens Custo Desvantagens Interferência Interferência e Velocidade Custo e Alcance Custo e Velocidade Maior interferência Mobilidade e alcance 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 adhoc 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 investigaçã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, entre 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 tecnologias como 802.11p que permitem um elevado alcance e é adequada às condições de elevada 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 equipamentos, 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 investigação. O estudo destas redes tem sido também focado na criação de novos protocolos de encaminhamento, 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 Vector (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 movimentaçã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 descoberta 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 chegaram 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 infraestrutura 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, escolhendo 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 informaçã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 mensagem 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 protocolo 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 encaminhamento planos (todos os nós têm o mesmo tipo de comportamento), algoritmos de encaminhamento 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 Routing (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 coordenador 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, haveria O(N M ) 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 energia 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 mensagem 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 University (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 descentralizado 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 considerados 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 dos 9 Website 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 deterioraçã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 Exponent (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 comunicaçã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 (devido 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 valores registados com comunicação em linha de vista e a cinzento escuro sem linha de vista [1] 18 2.6 2.6.1 Monitorização Atmosférica Projeto QualAr As estações de monitorização de gases atmosféricos mais comuns são as estações fixas, contentores 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 Portugal (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 recolhidos, 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 gases 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, nomeadamente 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 sistema 10 Website 11 Website do projeto QualAr: http://www.qualar.org/ 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 percursos, 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 central 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 recolhidas, 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 Complex 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. 12 Website 20 do projeto MASON: http://sensor.ee.tsinghua.edu.cn/dyn_show.php?dyn_id=9 3 Arquitetura Contents 3.1 Arquitetura Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Arquitetura Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Modelo de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 25 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 atmosfé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 interligaçã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 componentes, 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 remotamente. 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. Disponibiliza 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 estas 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 estaçõ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, referenciar 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, O3 , NO2 , temperatura, humidade; A Marca temporal (timestamp) vem no formato AAAA-MM-DD HH:MM:SS e é obtida através da informação recolhida por GPS. A existência da marca temporal é essencial de forma a identificar temporalmente 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 decimais. 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, O3 , NO2 , temperatura e humidade correspondem 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 atmosfé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 aproximadamente 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, é possí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, temperatura, 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 servidor 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 é possí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 e a informação relativa à monitorização passiva. • Monitorização - Questiona a estação em causa para que esta devolva informações dos parâmetros 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 funcionamento 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 website 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 mobilidade 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. Posteriormente é 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 funcionalidade 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, parametrizar a periodicidade da recolha de amostras. A partir do website URBISNET é possível especificar 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 necessidade 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 central 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 requisitos 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 conetividade 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 endereç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 tecnologia 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 servidor 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 monitorizaçã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 armazenado 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 equacionar 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 conectividade 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 comunicar 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çamento 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 protocolo 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 (també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 fatores. 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 probabilidades 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 disseminaçã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 folhas 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 propagada 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 gateways), 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 simples, 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, estando 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, descartase 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 4 Implementação Contents 4.1 Servidor (CS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Gateway (GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Estação Móvel (MS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 50 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 capí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 funcionalidades 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 disponibilizar 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 relevo, 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 operativos 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 Language), 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 tabela 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 duplicadas, 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 timestamp (c) station_ID (c) lat lng co2_out co o3 no2 temperature humidity Descrição Identificação temporal da amostra recolhida Identificação da estação origem Latitude da posição onde foi recolhida a amostra Longitude da posição onde foi recolhida a amostra Valor CO2 , dióxido de carbono Valor CO, monóxido de carbono Valor O3 , ozono Valor NO2 , dióxido de azoto Valor de temperatura 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 station_ID (c) ip_addr timestamp Descrição Identificação da estação Endereço IP da estação da ligação GPRS 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 relativamente às mensagens periódicas (”I’m alive”) que enviam para o servidor. Atributos gw_id (c) last_alive alive_interval ip_ address Descrição Identificação do gateway Identificação temporal da receção da última mensagem ”I’m alive” Intervalo temporal entre mensagens ”I’m alive” (minutos) 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 servidor 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 disponibilidade 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 comunicação foi assegurada usando ligações Secure Shell Protocol (SSH) e SSH File Transfer Protocol (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, oferecendo 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. 1 Website 2 Website PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html 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 visuais e propriedades dos mesmos. O exemplo anterior da definição da tabela em HTML é complementado 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ísticas function 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 amostra function 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 mapa marker_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'; $username = 'ist157697'; $password = 'XXXXXXX'; $dbname = 'ist157697'; // // localização // utilizador // palavra chave nome da base de dados // Ligação à base de dados MSQL mysql_connect($hostname, $username, $password) or DIE('Connection to host is failed, perhaps the service is down!'); // Seleccionar a base de dados mysql_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 dados mysql_close(); // exemplo de processamento do resultado dado pela base de dados while($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 central. 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ção fputs ($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 suporte 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 configuraçã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 gateways (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 servidor 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.0 User-Agent: Urbisnet_Station Host: web.ist.utl.pt Accept: */* Content-Type: application/x-www-form-urlencoded Content-Length: 99 MS_SAMPLES=2012-4-4 11: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. Processador Memória Disco Rígido LAN Wi-Fi Vídeo Dimensões Preço EeeBox EB1007 Processador Intel Atom D410 1.66 GHz 1GB DDR2 800 MHz SATA 2.5"de 160 GB 10/100/1000Mbps WLAN 802.11b/g/n @2.4GHz Saída VGA 223mm x 178mm x 27mm 200e WL-500g Premium v2 Broadcom BCM5354 240 MHz 32 MB 8 MB (flash) 4x 10/100Mbps 802.11b/g @2.4GHz 206mm x 185mm x 35mm 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ísticas 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 3 Website 4 Website do equipamento Asus EeeBox EB1007: http://pt.asus.com/Eee/EeeBox_PC/EeeBox_PC_EB1007 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 amostras 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 mensagens 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:1 BCAST_INTERVAL:500 TYPE_STATION:GW IP_ADDRESS:192.168.253.1 WEBHOST:web.ist.utl.pt UPLOADWEBADDRESS:/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 funcionamento 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 estaçõ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/bash sudo service network-manager stop #eth0 sudo ip link set eth0 down sudo ip link set eth0 up sudo dhclient eth0 #wlan0 sudo ip link set wlan0 down iwconfig wlan0 mode ad-hoc iwconfig wlan0 channel 11 iwconfig wlan0 essid Urbisnet iwconfig wlan0 key EEAACC2211 sudo ip link set wlan0 up ifconfig 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 funcionalidade base de recolha de amostras atmosféricas. A sua implementação a nível de software e configuraçã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 equipamento 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 apresentados na secção 3.1.1, na Arquitetura Geral deste documento. O protótipo inclui um sistema embebido 5 Website 54 do software Eclipse: http://www.eclipse.org C10/3 AarLogic da RoundSolutions 6 (representado na figura 4.9) que inclui um processador ARM integrado 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 Memória RAM Memória ROM Extensão Memória GPS Cartão SIM GSM/GPRS Sistema Operativo Conectores Atmel AT91SAM9260 ARM9 200 MIPS 180MHz (módulo GE863-PRO3) 64 MB 4 MB Cartões SD ou MMC AarLogic GPS 3M (SiRF 3/LP) Suporte para cartão SIM Integrado no módulo GE863-PRO3 Linux 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 comunicaçõ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. 6 Website 7 Website da RoundSolutions: http://www.roundsolutions.com 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 funcionalidades 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 funcionamento 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 comandos 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=1234 OK 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 rule state=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; } 8 Lista 58 de comandos AT disponibilizada pela Telit: www.telit.com/module/infopool/download.php?id=542 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 = h ddmm.mmmm i 100 ddmm.mmmm − + h ddmm.mmmm 100 60 i × 100 (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 ) = haversin(∆lat ) + cos(lat1 ) × cos(lat2 ) × haversin(∆lng ) R δ haversin(δ) = sin2 ( ) 2 √ −1 d = R × haversin (h) = 2R × arcsin( h) (4.2) (4.3) (4.4) A fórmula de cálculo da distância entre dois pontos em coordenadas de graus decimais (apresentada 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.4squashfs.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; 9 Fórmulas 60 de conversão para coordenadas UTM: http://www.uwgb.edu/dutchs/UsefulData/UTMFormulas.htm 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].1 option '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-Hoc config '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 desempenha. 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 comunicaçã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 funcionamento 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 conflitos); – 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 especificados); – 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 verificaçõ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 guardadas 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 5 Avaliação Contents 5.1 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Testes de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 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 monitorizaçã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 funciona70 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 mobilidade, 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 comunicaçã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 enviada 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: 23/2/2012-15:52:35|->Connect_GW: 192.168.1.2,OK.RTT=208ms 23/2/2012-15:52:43|->Connect_GW: 23/2/2012-15:52:43|->Connect_GW: 192.168.1.2,OK.RTT=7ms 23/2/2012-15:52:51|->Connect_GW: 23/2/2012-15:52:51|->Connect_GW: 192.168.1.2,OK.RTT=8ms Sent message to gateway "192.168.253.1" with 575 bytes Received response from gateway "192.168.253.1": Sent message to gateway "192.168.253.1" with 96 bytes Received response from gateway "192.168.253.1": Sent message to gateway "192.168.253.1" with 96 bytes Received response from gateway "192.168.253.1": As amostras enviadas pela estação móvel (8 no total) estão descritas de seguida: 2012-2-23 2012-2-23 2012-2-23 2012-2-23 2012-2-23 2012-2-23 2012-2-23 2012-2-23 15:51:12,1,38.741077,-9.301159,0.927734,1.706543,0.239258,2.011108,9.87,44.88; 15:51:43,1,38.740807,-9.302377,0.724487,1.691895,0.242310,2.002563,9.62,44.89; 15:51:52,1,38.740429,-9.303460,0.724487,1.694336,0.242920,2.002563,9.62,44.89; 15:52:2,1,38.739773,-9.304350,0.728760,1.703491,0.243530,2.002563,9.71,44.90; 15:52:24,1,38.738895,-9.304689,0.756836,1.721191,0.240479,2.014771,9.79,44.92; 15:52:34,1,38.738094,-9.304096,0.758667,1.723633,0.239868,2.015381,9.71,44.94; 15:52:43,1,38.737141,-9.303741,0.732422,1.709595,0.244751,2.011108,9.83,44.95; 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 envolvendo 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 realizaçã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 constante 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 Dados small medium large medium Velocidade 20 km/h 20 km/h 20 km/h 40 km/h RTT médio entre estações (MS1 e MS2) 440.8 ms 586.75 ms 1083.8 ms 744 ms RTT médio entre estação MS2 e gateway 380.6 ms 338.75 ms 847.4 ms N/A % de sucesso dos ensaios 83% 67% 83% 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 esperado, 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 revelouse 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 comunicaçã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 satisfató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 6 Conclusões e Trabalho Futuro Contents 6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 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 recolha 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 influenciaram 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 apresentadas 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 estaçõ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 propostos, 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 trabalho 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 URBISNET; • 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, 1st ed. Fundamentals of Global Positioning System Receivers: A Software Approach, 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 vehicular 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. 82 IEEE, 2006, pp. 166–172. A Parâ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 sample_mode sampling_time distance_samples number_of_samples_to_send station_ID APN PIN server_IP_address server_mask web_host upload_Web_Address data_mode Descrição Comanda o modo de captura de amostras. Pode ser temporal (de ’x’ em ’x’ segundos) em que o valor de ’x’ é configurável pelo parâmetro "sampling_time". Em alternativa pode ser uma distância (de ’y’ em ’y’ metros) em que o valor de ’y’ é configurável pelo parâmetro "distance_samples". Valor em segundos entre a captura de novas amostras (quando a captura de amostras está no modo temporal). Valor em metros entre a captura de novas amostras (quando a captura de amostras está no modo distância). Número de amostras que são enviadas de cada vez quando a estação móvel está a comunicar por GPRS. Número de identificação da estação. Endereço do APN a usar nas configurações GPRS da estação. Código PIN do cartão SIM usado pela estação. Endereço IP do servidor central. Máscara de rede do endereço IP do servidor. Endereço web do servidor para o qual são enviadas as amostras e dados da estação. Endereço da página web para a qual são enviadas as amostras e dados da estação. Modo de comunicação entre a estação e o servidor central para envio das amostras. No modo ”GPRS” envia as amostras directamente, enquanto no modo ”ADHOC” estas são passadas a um gateway. Tabela A.1: Parâmetros da estação móvel passíveis de configuração e monitorização no website URBISNET. Parâmetro last_sample_sent_GPRS last_GPS_info GPRS_data_sent GPRS_data_received number_samples_saved program_version Descrição Data e coordenadas GPS da última transmissão de amostras via GPRS. Data e coordenadas GPS dos últimos dados GPS válidos. Quantidade de dados enviados por GPRS (em bytes). Quantidade de dados recebidos por GPRS (em bytes). Número de amostras guardadas por enviar. 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 URBISNET. A-2 B Protocolo 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 C Resultados 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 identificados como ”ERRO” a transmissão dos dados da estação MS2 para MS1 falhou. Ficheiro de dados baixa (5 amostras) média (20 amostras) superior (40 amostras) média (20 amostras) Velocidade 20 km/h 20 km/h 20 km/h 40 km/h 1 96 1315 1634 751 2 1029 ERRO 582 407 Ensaio 3 4 1026 29 344 354 799 652 946 1321 5 ERRO ERRO 1752 344 6 24 334 ERRO 695 Média 440.8 586.75 1083.8 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 intervalo 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 com diferentes tamanhos de amostras. O gráfico da figura C.2 compara os valores de RTT registados na tabela C.1 com a mesma dimensã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 40 km/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. Ficheiro de dados baixa (10 amostras) média (40 amostras) superior (80 amostras) média (40 amostras) Velocidade 20 km/h 20 km/h 20 km/h 40 km/h 1 1266 332 429 N/A 2 258 ERRO 1250 N/A Ensaio 3 4 222 82 347 301 781 867 N/A N/A 5 ERRO ERRO 910 N/A 6 75 375 ERRO N/A Média 380.6 338.75 847.4 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 Ficheiro de dados baixa (5 amostras) média (20 amostras) superior (40 amostras) média (20 amostras) Velocidade 20 km/h 20 km/h 20 km/h 40 km/h 1 4 9 13 7 2 3 8 13 8 Ensaio 3 4 3 3 8 7 13 15 7 7 5 4 7 13 8 6 3 8 13 7 Média 3.3 7.8 13.3 7.3 Tabela C.3: Tabela dos tempos de processamento (em ms) na estação MS2. C-4