PROTOCOLO DE COMUNICAÇÃO PARA REDES MÓVEIS APLICADO AO TRÂNSITO

Transcrição

1 LUIZ HENRIQUE SANTOS Orientador: Álvaro Rodrigues Pereira Júnior Co-orientador: Saul Emanuel Delabrida Silva PROTOCOLO DE COMUNICAÇÃO PARA REDES MÓVEIS APLICADO AO TRÂNSITO Ouro Preto Dezembro de 2012

2 Universidade Federal de Ouro Preto Instituto de Ciências Exatas Bacharelado em Ciência da Computação PROTOCOLO DE COMUNICAÇÃO PARA REDES MÓVEIS APLICADO AO TRÂNSITO Monografia apresentada ao Curso de Bacharelado em Ciência da Computação da Universidade Federal de Ouro Preto como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. LUIZ HENRIQUE SANTOS Ouro Preto Dezembro de 2012

3 UNIVERSIDADE FEDERAL DE OURO PRETO FOLHA DE APROVAÇÃO Protocolo de comunicação para redes móveis aplicado ao trânsito LUIZ HENRIQUE SANTOS Monografia defendida e aprovada pela banca examinadora constituída por: Dr. Álvaro Rodrigues Pereira Júnior Orientador Universidade Federal de Ouro Preto Msc Saul Emanuel Delabrida Silva Co-orientador Universidade Federal de Ouro Preto Msc. Saul Emanuel Delabrida Silva Universidade Federal de Ouro Preto Dr. Joubert de Castro Lima Universidade Federal de Ouro Preto Ouro Preto, Dezembro de 2012

4 Resumo Obter e analisar informações sobre o trânsito é cada vez mais importante hoje em dia. Para obter essas informações podemos usar dispositivos com capacidade de sensoriamento e transmissão de dados. Um conjunto desses dispositivos formam uma rede móvel. Um tipo específico de rede móvel é a VANET (Veicular Ad Hoc Networks), que é uma rede móvel onde são estabelecidas comunicações intra-carros ou entre os carros e a estrada. Este trabalho consiste em um protocolo de comunicação entre sensores em veículos (carros, ônibus) construindo uma VANET cujo papel é monitorar o trânsito em uma determinada cidade detectando eventos (infrações de transito, congestionamento, possíveis veículos roubados, etc.). O principal objetivo do trabalho é cobrir uma área remota adicional à rede fixa de monitoramento e escoar os dados de eventos o mais rápido possível. Para isso foi proposto um protocolo de comunicação para VANETs que considera tempo de atraso das mensagens, frequentes desconexões, controle de redundância e descarte de mensagens. Foram pesquisados trabalhos relacionados que contivessem protocolos de comunicação aplicados à comunicação móvel com características semelhantes de modo que pudéssemos comparar o protocolo idealizado com os mesmos. Os resultados mostram que o protocolo proposto supera os outros protocolos comparados enviando menos mensagens pela rede, reduzindo o número de hops de cada mensagem até chegar à uma antena e também reduzindo a quantidade de mensagens que são entregues à antena. i

5 Abstract Obtain and analyze traffic information is increasingly important nowadays. To obtain this information we can use devices capable of sensing and data transmission. A set of these devices form a mobile network. A specific type of mobile network is called VANET (Vehicular Ad Hoc Networks), which is a network where mobile communications are established intracars or between cars and road. This work consists of a communication protocol between sensors in vehicles (cars, buses) constructing a VANET whose role is to monitor the traffic in a particular city by detecting events (violations of traffic congestion, possible stolen vehicles, etc..). The main objective is to cover a remote area added to the fixed network monitoring and transmit event data as soon as possible. To this end we propose a communication protocol for VANETs which considers delay time of messages, frequent disconnections, control redundancy and discarding messages. Were researched work related communication protocols about mobile communication with similar characteristics to compare them with the proposed protocol. The results show that the proposed protocol outperforms the other protocols compared sending fewer messages over the network, reducing the number of hops each message until you get to an antenna and also reducing the amount of messages that are delivered to the antenna. ii

6 Dedico este trabalho à todas as pessoas que me apoiaram, incentivaram e me ajudaram a chegar aqui, meus pais, minha familia, meus amigos e todos que contribuiram de alguma forma. Sem essas pessoas essa conquista não seria possível. iii

7 Agradecimentos Agradeço primeiramente a Deus pelo dom da vida que me deu a oportunidade de concluir este trabalho. À minha familia que sempre me incentivou e apoiou, principalmente nos momentos difíceis. Aos meus amigos e colegas de turma pelos conselhos e auxílios nos trabalhos, tornando essa caminhada mais agradável. iv

8 Sumário 1 Introdução Motivação e Justificativa Objetivos Contribuições Background Projeto olhos da cidade Sinalgo Redes veiculares Trabalhos Relacionados 10 4 Implementação dos protocolos History-based protocol Epidemic routing Data-Mule System Context-Aware routing (CAR) Protocolo desenvolvido 28 6 Experimentos 41 7 Conclusões e Trabalhos futuros 45 Referências Bibliográficas 47 v

9 Lista de Figuras 2.1 O cenário de uma rede veicular - Rafael dos S. Alves (2009) Comunicação do protocolo Epidemic routing - Vahdat e Becker (2000) As três camadas do protocolo proposto por Jain (2006) Sequência do protocolo Fluxo de recebimento de dados da RSU Fluxo de recebimento de dados do OBU Fluxo de envio de dados do OBU Gráfico do número médio de mensagens trocadas por OBU para cada configuração de RSU Gráfico do número médio de mensagens recebidas pelas RSU para cada configuração Gráfico do número médio de mensagens descartadas por OBU para cada configuração Gráfico do número médio de hops por mensagem para cada configuração vi

10 Lista de Tabelas 3.1 Tabela comparativa dos protocolos Tabela comparativa dos protocolos vii

11 Lista de Programas 4.1 Código do método handlemessages da classe Antena Código do método handlemessages da classe DummyNode no protocolo History-based Código do método neighborhoodchange da classe DummyNode no protocolo History-based Código do método handlemessages da classe DummyNode no protocolo Epidemic routing Código do método neighborhoodchange da classe DummyNode no protocolo Epidemic routing Código do método neighborhoodchange da classe DummyNode no protocolo Data-Mule-System Código do método handlemessages da classe Mule no protocolo Data-Mule-System Código do método neighborhoodchange da classe Mule no protocolo Data-Mule- System Código do método handlemessages da classe DummyNode no protocolo Context-Aware routing Código do método neighborhoodchange da classe DummyNode no protocolo Context-Aware routing Pseudocódigo do protocolo proposto Código do método handlemessages da classe Antena no protocolo proposto Código do método handlemessages da classe DummyNode no protocolo proposto Código do método init da classe DummyNode no protocolo proposto Código do método neighborhoodchange da classe DummyNode no protocolo proposto

12 Capítulo 1 Introdução A necessidade por informação acerca de localização, dados de tráfico, rotas e outras informações vem se tornando cada vez mais eminente. Uma nova tecnologia que vem ajudando a obter essas informações é a rede móvel. As redes móveis utilizam nós móveis em uma rede para trafegar dados até um destino. Um nó sensor é um dispositivo com capacidade de comunicação, computação, sensoriamento e armazenagem de dados. Esses sensores podem captar vídeo, áudio, etc. As redes veiculares(vanets) são um tipo de rede móvel. Formada por sensores localizados em veículos, uma vanet pode ser apoiada por unidades estáticas para interligação com infraestrutura, que seriam distribuídas ao longo das vias. Os componentes móveis da rede são denominados OBUs(on-board units) e os RSUs são os componentes estáticos da rede. Os OBUs se comunicam com outros OBUs ou com os RSUs. As VANETs possuem outras características como: alta mobilidade, escalabilidade e exigência de qualidade de serviço - Chen et al. (2008). As aplicações de VANETs podem ser divididas em três classes: segurança no trânsito, entretenimento e assistência ao motorista - Nadeem et al. (2006). As aplicações de segurança possuem caráter preventivo e emergencial, onde o principal desafio é divulgar rapidamente as informações para que o condutor tenha tempo para reagir. A classe das aplicações de entretenimento inclui adaptações de aplicações da Internet para VANETs. Por fim, as aplicações de assistência ao motorista envolvem o recebimento de informações que auxiliem o condutor em buscas ou automatizem serviços. São exemplos de aplicações de divulgação de informações turísticas, localização de postos de abastecimento, controle de frotas e cobrança automatizada de pedágio. Existe um projeto chamado Olhos da cidade submetido ao CNPq que consiste em uma rede de RSUs distribuídas em uma vasta região de uma cidade. Essas RSUs seriam distribuídas em pontos estratégicos da cidade como semáforos, cruzamentos, locais de fluxo intenso de veículos. Os dados captados por essas RSUs podem ser tratados por um módulo ou enviados para uma central onde seriam minerados. 2

13 1. Introdução 3 Uma vez que pode ser inviável cobrir toda a área com RSUs, seu custo pode ser elevado e a cobertura feita pela mesma pode ser insuficiente. Para solucionar tal problema propomos um protocolo de comunicação utilizando VANETs para cobrir uma área remota da região. Esses dados são escoados para estações fixas através de OBUs, dando suporte aos RSUs implantados. A princípio pensamos em distribuir os OBUs na frota de táxis da cidade de Belo Horizonte, pois o projeto Olhos da cidade é direcionado a ela. Devido a parceria com a BHTRANS o uso da frota de táxi torna-se uma alternativa viável. Os veículos funcionariam como nós da nossa rede. Eles não tem uma rota definida, percorrem diversos caminhos dentro da cidade, o que se assemelha muito com a movimentação dos nós do protocolo. A cobertura feita por esses táxis dentro da cidade seria bem ampla, pois eles se movimentam por toda a cidade. Antes de implantarmos esse protocolo na frota de táxis de Belo Horizonte decidimos experimentar o protocolo utilizando um simulador de rede de sensores sem fio. Dessa forma é possível detectar e corrigir problemas com mais facilidade. 1.1 Motivação e Justificativa Nesse projeto apresentaremos um protocolo que visa o desenvolvimento de uma inovação tecnológica para comunicação de dados entre OBUs, para melhorar em vários sentidos o trânsito em grandes cidades ou em estradas. Com esse protocolo visamos agilizar a transmissão de dados coletados por esses OBUs para a central mais próxima, dessa forma é possível identificar e solucionar o problema rapidamente. Alguns dos eventos que podem ser escoados pelo protocolo são: furto de veículos, infrações de trânsito, detecção de congestionamento, entre outros. Dado a fase futura de implantação, faz-se necessário avaliar o algoritmo em simulador antes da real implementação. Com a melhora do trânsito a qualidade de vida dos cidadãos tende a melhorar e também a quantidade de acidentes tende a diminuir. A fiscalização no trânsito é muito dependente do ser humano ou de equipamentos caros, de forma que não é possível fiscalizar em escala. A falta de fiscalização é um fator central na desorganização do trânsito e na ocorrência de acidentes de trânsito. Segundo a Associação Nacional de Transportes Públicos (ANTP) o Brasil gasta, por ano, 28 bilhões de reais com acidentes de trânsito, contabilizando desde o socorro às vítimas, o tratamento, e até o afastamento do trabalho. Os protocolos de VANET para resolver o problema de enviar mensagens de um OBU até uma RSU da literatura não se mostram muito eficientes. Os protocolos Epidemic routing, Context aware routing e Hystory based inundam a rede com muitas trocas de mensagens, o que pode extrapolar os recursos disponíveis para armazenamento das mesmas. Isso pode causar perda de mensagens e atraso de sua entrega para o seu destino devido ao grande número de mensagens que devem ser enviadas. O protocolo Data mule system não inunda a rede mas não garante a entrega das mensagens em tempo hábil. Em alguns casos essas mensagens nunca

14 1. Introdução 4 chegam a uma RSU. Portanto desenvolvemos um novo protocolo com o objetivo de reduzir o número de mensagens trocadas na rede e entregar a mensagem para seu destino o mais rápido possível. 1.2 Objetivos O objetivo deste trabalho é desenvolver e experimentar um modelo de comunicação entre OBUs de uma rede que considera: tempo de atraso das mensagens, frequentes desconexões (VANETs), controle de redundância de dados e descarte de mensagens obsoletas. Esse modelo prevê comunicação veículo-veículo(v2v) e veículo-infraestrutura(v2i). O objetivo é cobrir uma área alem da rede de RSUs já implantada e através de comunicações entre OBUs transmitir os dados de eventos coletados para essas RSUs o mais rápido possível Os objetivos específicos são: Propor, desenvolver e implementar um protocolo de comunicação para VANETs aplicado ao trânsito. Implementar protocolos de comunicação similares ao proposto. Comparar a eficiência do protocolo proposto com os demais protocolos. 1.3 Contribuições Através desse projeto geramos um protocolo de comunicação para VANETs aplicado ao trânsito com as seguintes contribuições: Facilitar a identificação e o tratamento de eventos no trânsito como infrações e congestionamento; Controlar o tráfego em determinados trechos de uma cidade; Identificar veículos roubados; Facilitar o monitoramento do trânsito automatizando o processo de fiscalização.

15 1. Introdução 5 O restante deste trabalho está organizado da seguinte forma:no Capitulo 2 são definidos alguns conceitos essenciais para entendimento do trabalho, no Capitulo 3 apresentamos os trabalhos relacionados, no capitulo 4 detalhamos a implementação dos protocolos da literatura implementados. No capitulo 5 explicamos todo o funcionamento do protocolo desenvolvido, inclusive detalhes de implementação. No capitulo 6 detalhamos os experimentos realizados, bem como comparações entre os protocolos implementados. Por fim, no capitulo 7 apresentamos a conclusão do trabalho.

16 Capítulo 2 Background Neste capítulo descrevemos todo material necessário para entendimento do trabalho feito. 2.1 Projeto olhos da cidade Em janeiro de 2010 foi proposto ao CNPq 1 um projeto 2 chamado Olhos da cidade. projeto visava o desenvolvimento de uma inovação tecnológica de aquisição e processamento de imagens de câmeras de vídeo, para melhorar em vários sentidos o trânsito em grandes cidades ou em estadas. O problema identificado nesse projeto é a falta de dados para um controle de tráfego eficiente. O projeto apresenta diversas justificativas para motivar o desenvolvimento de soluções para os problemas. A fiscalização no trânsito é muito dependente do ser humano ou de equipamentos caros, de forma que não é possível Fiscalizar em escala. A falta de Fiscalização é um fator central na desorganização do trânsito e na ocorrência de acidentes. Outro ponto destacado no projeto corresponde à dificuldade dos gerenciadores de tráfego coletarem dados, tomar decisões e melhorar as condições do tráfego. O impacto é a redução da produtividade, qualidade de vida dos cidadãos e aumento da possibilidade de acidentes. Atualmente as companhias de transporte não possuem mecanismos efetivos para coletar dados, tomar decisões e planejar estrategias para melhorar as condições do tráfego. Segundo a Associação Nacional de Transportes Públicos (ANTP) o Brasil gasta, por ano, 28 bilhões de reais com acidentes de trânsito, contabilizando desde o socorro às vítimas, o tratamento, até o afastamento do trabalho. O outro problema apontado está relacionado com a baixa qualidade de vida e de baixa produtividade em função do trânsito mal organizado nas grandes cidades. Uma pesquisa da Datafolha 3 indicou que o trânsito é a maior reclamação do paulistano de 1 CNPq. Conselho Nacional de Desenvolvimento Científico e Tecnológico. Accessed on March A. R. Pereira Jr. Edital MCT/CNPq no 018/2009 Pesquisa, Desenvolvimento e Inovação em Transportes. January O 6

17 2. Background 7 classe média e alta, enquanto que o paulistano de classe mais baixa reclama de problemas mais básicos como buracos nas ruas e iluminação. 2.2 Sinalgo O simulador utilizado para validação dos protocolos foi o Sinalgo 4. O Sinalgo é um framework de simulação para testar e validar algoritmos de rede. A representação do Sinalgo dos dispositivos de rede se assemelha aos dispositivos de hardware reais: Um nó pode enviar uma mensagem para um determinado vizinho ou todos os seus vizinhos, reagir a mensagens recebidas, definir temporizadores para programar ações no futuro, entre outros. Algumas das principais características do Sinalgo: A maioria dos simuladores simula as diferentes camadas da pilha de rede, o Sinalgo centra-se na verificação de algoritmos de redes, abstraindo as camadas mais baixas. A prototipagem do algoritmo em JAVA simplifica a depuração. O Sinalgo oferece um amplo conjunto de condições de rede, além de poder ser usado em aplicações stand-alone autônoma para obter resultados de simulação de algoritmos de rede. Possui extensibilidade para simular vários cenários. Possui alto desempenho, realiza simulações com um numero grande de nós em tempo aceitável. Possui simulação síncrona e assíncrona. É independente de plataforma. Possui suporte de simulações 2D e 3D. Para garantir a extensibilidade, o Sinalgo é divido em vários modelos, são eles: mobilidade, conectividade, distribuição, interferência, confiabilidade e transmissão. 2.3 Redes veiculares Os veículos automotores vêm incorporando diferentes avanços tecnológicos que melhoram a experiência do condutor e dos passageiros. O próximo passo da evolução tecnológica consiste em sistemas de comunicação que possibilitem a interação entre diferentes veículos. O objetivo principal desses sistemas é possibilitar a comunicação de usuários móveis e oferecer as condições necessárias para que aplicações com diferentes requisitos sejam atendidas satisfatoriamente. Segundo Li e Wang (2007) tais aplicações compõem um Sistema Inteligente de Transporte 4

18 2. Background 8 (Intelligent Transportation System - ITS) que opera em um ambiente formado por usuários no trânsito. Exemplos dessas aplicações incluem a monitoração cooperativa do tráfego, o auxílio a cruzamentos sem sinalização e a prevenção de colisões. Os sistemas de comunicação entre veículos formam as chamadas redes veiculares(vanets). Elas são formadas somente por OBUs ou por OBUs e RSUs. As VANETs se diferenciam de outras redes sem-fio principalmente pela natureza dos OBUs, que são compostos por automóveis, caminhões, ônibus etc., com interfaces de comunicação sem-fio, e por RSUs. Os OBUs apresentam alta mobilidade e trajetórias que acompanham os limites das vias públicas de acesso - Rafael dos S. Alves (2009). As VANETs apesar de apresentarem algumas características em comum com as redes móveis, possuem algumas particularidades: Alta Mobilidade. Exigência de qualidade de serviço. Dispositivos se movimentam apenas em cima das vias. Precisam ser escaláveis. Segundo Rafael dos S. Alves (2008) a arquitetura das VANETs define a forma como os nós se organizam e se comunicam. Atualmente, existem três arquiteturas principais: ad hoc puro (Vehicular Adhoc NETwork - VANET), infraestruturada e híbrida. Na arquitetura ad hoc, os OBUs comunicam-se sem qualquer suporte externo ou elemento centralizador. Para tanto, os OBUs funcionam como roteadores e encaminham tráfego através de múltiplos saltos. A arquitetura infraestruturada emprega RSUs distribuídas ao longo das ruas ou estradas. Essas RSUs funcionam como pontos de acesso de redes também em modo infraestruturado. Eles centralizam todo o tráfego da rede, servindo como nós intermediários das comunicações. Na arquitetura híbrida, uma infraestrutura mínima é utilizada para aumentar a conectividade da rede e prover serviços como os de interconexão. Entretanto há também a possibilidade dos OBUs se comunicarem por múltiplos saltos. Nas VANETs, o modo ad hoc é conhecido por V2V (Vehicle-to-Vehicle) Prinz et al. (2008) e o modo infraestruturado tem como sinônimo o termo V2I (Vehicle-to-Infrastructure). Atualmente alguns pesquisadores referem-se às redes veiculares em geral como VANETs, mesmo quando existe infraestrutura - Little e Agarwal (2005). A Figura 2.1 apresenta as diversas arquiteturas das VANETs. Nela os veículos funcionam com OBUs e os postes funcionam com RSUs.

19 2. Background Figura 2.1: O cenário de uma rede veicular - Rafael dos S. Alves (2009). 9

20 Capítulo 3 Trabalhos Relacionados Este capítulo descreve os trabalhos relacionados pesquisados na literatura. O objetivo é usá-los como baseline de comparação com o protocolo proposto. Os protocolos encontrados envolvem comunicação V2V e V2I, que também são realizadas pelo protocolo proposto. O History-based-protocol foi proposto por Luciana Pelusi e Conti (2006) e possui uma abordagem em que cada nó seleciona apenas um dos seus OBUs vizinhos para envio de seus dados. O OBU selecionado é aquele com a maior probabilidade de eventualmente encontrar uma RSU. Para calcular essa probabilidade é atribuído a cada OBU um nível de hierarquia (inicialmente zero) que é incrementado cada vez que ele encontra uma RSU e decrementado após não ter visto uma RSU durante certa quantidade de tempo. Ao enviar dados, o OBU a ser selecionado tende ser aquele com o maior nível de hierarquia. Esse protocolo supera o protocolo de envio direto, no qual cada OBU precisa se comunicar diretamente com uma RSU para enviar dados. Ele também supera os algoritmos de inundações em termos de largura de banda e consumo de energia. Esse protocolo não troca um numero muito grande mensagens, mas o tempo de entrega das mensagens pode chegar a ser elevado, visto que ele só entrega a mensagem para um vizinho. Esse protocolo não atende os objetivos de controle de redundância de dados e descarte de mensagens obsoletas. O protocolo Epidemic routing foi proposto por - Vahdat e Becker (2000) e possui uma abordagem em que as mensagens se difundem na rede de forma semelhante às doenças ou vírus. A infecção de um OBU é dada pela geração da mensagem ou recepção de uma mensagem de outro OBU. O OBU infectado armazena a mensagem em um buffer local, ele é suscetível à infecção quando ainda não recebeu a mensagem e consequentemente torna-se infectado quando recebe uma mensagem de um OBU infectado. A recuperação de um OBU infectado ocorre quando o mesmo envia a mensagem para uma RSU, tornando-se imune à mesma doença, não retransmitindo essa mesma mensagem novamente. No artigo o autor estabeleceu como objetivos maximizar a taxa de entrega de mensagens, minimizar a latência de mensagens, e minimizar o total dos recursos consumido na entrega da mensagem. O algoritmo aproveita uma variante da teoria de algoritmos de epidemia. Esta teoria afirma que, dada troca aleatória 10

21 3. Trabalhos Relacionados 11 de mensagens entre OBUs, todas as mensagens serão vistos por todos os OBUs em uma quantidade limitada de tempo, ou seja, o sistema irá atingir a consistência eventual. Um dos objetivos do Epidemic Routing é maximizar a taxa de entrega de mensagens para uma RSU. O protocolo também deseja minimizar o número de hops da mensagem, visando economizar recursos do sistema (memória, largura de banda de rede, ou energia) consumida na entrega de mensagens. Apesar do autor afirmar que o protocolo minimiza o número de hops, esse número foi bem maior que o contabilizado pelo protocolo proposto. Esse protocolo não atende os objetivos de diminuir o número de mensagens na rede e de entrega rápida da mensagem ao seu destino. O artigo avaliou o protocolo proposto através de vários cenários no simulador Monarch 1. O Monarch é uma extensão do simulador ns 2 que tem suporte a mobilidade e possui a implementação do padrão IEEE Os resultados do artigo mostram que o protocolo é capaz de entregar quase todas as mensagens existentes em cenários onde outros protocolos ad hoc de roteamento não conseguem entrega quaisquer mensagens por causa da conectividade limitado dos OBUs. O autor afirma conseguir entregar 100% das mensagens se cada OBU possuir capacidade de armazenamento de 10-25% do total de mensagens da rede. Na figura 3.1 um nó fonte S deseja transmitir uma mensagem para o destino D, mas não há nenhum caminho disponível em (a). OBUs portadores, C1-C3 são aproveitados para transitivamente entregar a mensagem para o destino D em como mostrado em (b). Figura 3.1: Comunicação do protocolo Epidemic routing - Vahdat e Becker (2000). 1 ftp.monarch.cs.cmu.edu/pub/monarch/wireless-sim/ns-cmu.ps 2

22 3. Trabalhos Relacionados 12 O protocolo Data-Mule-System foi proposto por Jain (2006) e possui uma abordagem centrada na recuperação de dados de redes de sensores sem fios esparsas. Ele consiste em uma arquitetura de três níveis: O nível mais baixo é ocupado pelos nós sensores fixos que coletam dados do ambiente. O nível intermediário consiste de nós móveis (mulas) que se movem em torno de uma área coberta por sensores para coletar seus dados. Essas mulas funcionam com os OBUs e tem o papel de descobrir e se comunicar tanto com sensores com os RSUs, não se comunicando com outros RSUs. O nível superior é constituído por um conjunto de pontos de acesso com fio que recebem os dados das mulas. Os nós do nível superior estão ligados a um armazém de dados central onde os dados recebidos são armazenados e processados. O principal objetivo do artigo foi resolver o problema de energia em rede de sensores. Esse protocolo troca muito poucas mensagens e o tempo de entrega da mensagem parece ser bem grande, visto que as OBUs não comunicam-se entre si,ou seja, há pouca comunicação no protocolo. Os objetivos de controle de redundância de dados e descarte de mensagens obsoletas não são atendidos pelo protocolo. A ideia chave do protocolo é de explorar as OBUs presentes em um cenário da aplicação. Essas entidades são chamadas mulas (Mobile Ubiquitous LAN Extensions), porque eles transportam das OBUs até as RSUs. As mulas são OBUs com um range de comunicação sem fio limitado e podem trocar dados à medida que passam por sensores ou RSUs. Assim as mulas recebem dados de sensores, armazena-os, e posteriormente entregam esses dados para a próxima RSU encontrada. A arquitetura MULE fornece conectividade, adicionando uma camada intermediária de OBUs para a relação existente entre os sensores e RSUs, como mostrado na figura 3.2. Figura 3.2: As três camadas do protocolo proposto por Jain (2006).

23 3. Trabalhos Relacionados 13 O protocolo Context-Aware routing (CAR) foi proposto por Mirco Musolesi (2005) e possui uma abordagem onde cada OBU da rede se encarrega de produzir suas próprias probabilidades de entrega em relação a cada RSU conhecido. Probabilidades de entrega são trocados periodicamente para que cada OBU possa calcular o melhor caminho para cada RSU. Os melhores caminhos são calculados com base no contexto dos OBUs, nível de bateria residual, a taxa de variação da conectividade, a probabilidade de estar dentro do alcance de uma RSU e o grau de mobilidade do OBU são alguns exemplos. Quando o OBU candidato recebe uma mensagem ele a armazena em um buffer local. Ao cruzar com outro OBU, sendo este o OBU de destino, a mensagem será entregue, do contrário, o OBU hospedeiro da mensagem verifica se seu par possui probabilidade maior. Sendo o caso, a mensagem é repassada. O contexto implementado nessa versão do protocolo foi o de número de mensagens trocadas sem ver uma RSU. Quando um OBU encontra com uma RSU sua probabilidade é incrementada. Se esse OBU trocar um número determinado de mensagens sem encontrar com uma RSU sua probabilidade é decrementada. O algoritmo é construído sobre o pressuposto de que a única informação que um OBU tem sobre a sua posição é a informação de conectividade lógica. Mirco Musolesi (2005) supõe que um OBU não tem conhecimento de sua localização geográfica absoluta nem da localização daqueles a quem ele pode entregar a mensagem. Também é considerado que todos os OBUs cooperam para entregar a mensagem. O problema geral do ponto de vista de quem envia uma mensagem é encontrar o OBU vizinho com a maior probabilidade de entrega, tal como calculada utilizando os valores previstos de uma série de atributos de contexto. Em vez de utilizar a informação de contexto disponível, CAR é otimizado usando valores estimados para o contexto, tendo assim valores mais realistas. Os objetivos de controle de redundância de dados e descarte de mensagens obsoletas e entrega da mensagem em tempo hábil ao seu objetivo não são atendidos pelo protocolo. Os parâmetros medidos pelo autor no artigo foram taxa de entrega de mensagens, números de mensagens trocadas, tempo de atraso da mensagem. O numero de mensagens que esse protocolo troca é elevado, e o tempo de entrega pode chegar a ser alto, pois ele só envia a mensagem para o melhor OBU vizinho. Esse não pode não ser o OBU que encontrará mais rapidamente uma RSU. A tabela 3.1 faz uma comparação das características de cada um dos protocolos.

24 3. Trabalhos Relacionados 14 Protocolos History based Epidemic Data Mule Context Aware Caracteristicas protocol routing System routing Menos de 1000 x x mensagens trocadas Menos de 240 mensagens x entregues à antena Possui descarte x de mensagens Menos de 3 hops x x por mensagem Tabela 3.1: Tabela comparativa dos protocolos

25 Capítulo 4 Implementação dos protocolos Neste capítulo descrevemos os detalhes de implementação dos protocolos encontrados na literatura. 4.1 History-based protocol No protocolo History-based-protocol cada OBU seleciona apenas um dos seus OBU vizinhos para envio de seus dados. O OBU selecionado é aquele com a maior probabilidade de eventualmente encontrar uma RSU. Para calcular essa probabilidade é atribuído a cada OBU um nível de hierarquia (inicialmente zero) que é incrementado cada vez que ele encontra uma RSU e decrementado após não ter visto uma RSU durante certa quantidade de tempo. Ao enviar dados, o OBU a ser selecionado tende ser aquele com o maior nível de hierarquia. Foram usadas algumas estruturas de dados para representar as mensagens trafegadas pela rede. Definimos uma classe para representar as mensagens que são trocadas pela rede chamada StringMessage. Nela encapsulamos o texto da mensagem, uma referência para o OBU que enviou a mensagem, o id da mensagem, a quantidade de hops que a mensagem já realizou e o seu número de vidas. Para representarmos a RSU definimos a classe Antena. Nela temos uma estrutura HashMap que contem o id do OBU que enviou a mensagem e uma estrutura LinkedList de StringMessage contendo as mensagens que esse OBU enviou. Dentro dessa classe temos um método chamado handlemessages, esse é o método que realiza o tratamento das mensagens que chegam para a RSU, ele guarda todas as mensagens recebidas em uma lista de mensagens. No simulador são trafegadas dois tipos de mensagens, as de descarte, que servem para informar a um OBU que descarte algumas mensagens de sua lista e mensagens de dados, que são informações de eventos que devem ser entregues a uma RSU. Para a RSU somente interessam mensagens de dados, então se recebermos alguma mensagem de descarte devemos ignorar. Caso a mensagem for de dados adicionamos essa mensagem caso ela não exista em nossa lista de mensagens. 15

26 4. Implementação dos protocolos 16 O programa 4.1 apresenta esse método implementado no simulador: public void handlemessages ( Inbox inbox ) { while ( inbox. hasnext ( ) ) { Message ms = inbox. next ( ) ; //Pega uma mensagem da c a i x a de entrada i f (ms instanceof StringMessage ) { StringMessage m = ( StringMessage )ms ; 10 // Adiciona a mensagem i f (! messages. containskey (m. getnode ( ). ID ) ) { LinkedList <StringMessage> d = new LinkedList <StringMessage >() ; d. add (m) ; 15 // Incrementa o numero de hops m. inchops ( ) ; messages. put (m. getnode ( ). ID, d ) ; else { 20 boolean e x i s t = f a l s e ; // Incrementa o numero de hops m. inchops ( ) ; // o l h a r dentro da l i n k e d l i s t se j a e x i s t e a mensagem 25 for ( StringMessage msg : messages. get (m. getnode ( ). ID ) ) i f ( msg. gettext ( ). e q u a l s I g n o r e C a s e (m. gettext ( ) ) ) { e x i s t = true ; break ; 30 // se não e x i s t e a d i c i o n a i f (! e x i s t ) messages. get (m. getnode ( ). ID ). add (m) ; 35 Programa 4.1: Código do método handlemessages da classe Antena Para representar o OBU definimos a classe DummyNode, nela temos uma estrutura Hash- Map que contem o id do OBU que enviou a mensagem e uma estrutura LinkedList de String- Message contendo as mensagens desse OBU. Conttrolamos a probabilidade que cada OBU tem de receber a mensagem com uma variável inteira, temos também um temporizador para contabilizar o tempo que o OBU fica sem se comunicar com uma RSU. Dentro dessa classe também temos o método handlemessages que trata todas as mensagens

27 4. Implementação dos protocolos 17 recebidas. O primeiro passo é pegar a primeira mensagem da estrutura e transforma-la para o tipo StringMessage, em seguida verificamos se já temos uma cópia dessa mensagem. Se ela não for encontrada adicionamos essa mensagem à lista. O programa 4.2 apresenta esse método implementado no public void handlemessages ( Inbox inbox ) { while ( inbox. hasnext ( ) ) { boolean f l a g = f a l s e ; 5 //Pega uma mensagem da c a i x a de entrada Message m = inbox. next ( ) ; this. nmensagens++; 10 // I n s t a n c i a de s t r i n g m e s s a g e StringMessage ms = ( StringMessage )m; // V e r i f i c a se j a e x i s t e e add i f (! messages. containskey (ms. getnode ( ). ID ) ) { 15 LinkedList <StringMessage> d = new LinkedList <StringMessage >() ; d. add (ms) ; // Incrementar o numero de hops somente a q u i ms. inchops ( ) ; 20 messages. put (ms. getnode ( ). ID, d ) ; else { boolean e x i s t = f a l s e ; 25 // Incrementar o numero de hops somente a q u i ms. inchops ( ) ; // o l h a r dentro da l i n k e d l i s t se j a e x i s t e a mensagem for ( StringMessage msg : messages. get (ms. getnode ( ). ID ) ) 30 i f ( msg. gettext ( ). e q u a l s I g n o r e C a s e (ms. gettext ( ) ) ) { e x i s t = true ; break ; // se não e x i s t e a d i c i o n a 35 i f (! e x i s t ) messages. get (ms. getnode ( ). ID ). add (ms) ; Programa 4.2: History-based Código do método handlemessages da classe DummyNode no protocolo

28 4. Implementação dos protocolos 18 5 O método init é usado para gerar a mensagem que será repassada por cada OBU, esse OBU gera um número de mensagens aleatórias e adiciona essa mensagens em sua lista. No método neighborhoodchange percorremos a lista de todos os OBUs vizinhos verificando se algum deles é uma RSU, em caso afirmativo enviamos todas as mensagens da lista diretamente para essa RSU. Incrementamos também a probabilidade de envio do OBU, já que ele entrou em contato com uma RSU. Se o OBU não encontrou nenhuma RSU percorremos seus vizinhos para verificar qual possui a maior probabilidade de envio. Verificamos também o tempo que o OBU está sem ver uma RSU, se esse tempo for maior que o limite estabelecido sua probabilidade de envio é decrementada. Ao final do algoritmo enviamos todas as mensagens armazenadas para o melhor OBU vizinho selecionado anteriormente. O programa 4.3 apresenta esse método implementado no public void neighborhoodchange ( ) { boolean hasantena=f a l s e ; DummyNode bestnode = this ; //Se algum v i z i n h o f o r uma antena envia d i r e t o for ( Edge e : this. outgoingconnections ) { i f ( e. endnode instanceof Antena ) { hasantena = true ; 10 for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) { //Manda as mensagens d i r e t o pra antena this. send (msg, e. endnode ) ; 15 // A t u a l i z a o contador de tempo this. starttime = System. nanotime ( ) ; // incrementa sua p r o b a b i l i d a d e de envio 20 this. incprobenvio ( ) ; // S e l e c i o n a o melhor v i z i n h o para envio else i f ( ( ( DummyNode) e. endnode ). getprobenvio ( ) > bestnode. getprobenvio ( ) ) bestnode = ( ( DummyNode) e. endnode ) ; 25 //Se f i c a r mto tempo sem ver a antena d e c r e s c e i f ( System. nanotime ( ) this. starttime > this. maxtime) { this. decprobenvio ( ) ; this. starttime = System. nanotime ( ) ; 30 i f (! hasantena ) { for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) {

29 4. Implementação dos protocolos //Manda as mensagens para o melhor nó this. send (msg, bestnode ) ; Programa 4.3: Código do método neighborhoodchange da classe DummyNode no protocolo History-based 4.2 Epidemic routing No protocolo Epidemic routing as mensagens se difundem na rede de forma semelhante às doenças ou vírus. A infecção de um OBU é dada pela geração da mensagem ou recepção de uma mensagem de outro OBU. O OBU infectado armazena a mensagem em um buffer local, ele é suscetível à infecção quando ainda não recebeu a mensagem e consequentemente torna-se infectado quando recebe uma mensagem de um OBU infectado. A recuperação de um OBU infectado é ocorre quando o mesmo envia a mensagem para uma RSU, tornando-se imune à mesma doença, não retransmitindo essa mesma mensagem novamente. Para implementar esse protocolo usamos as mesmas estruturas explicadas anteriormente, usamos também as classes DummyNode para representar os OBU e Antena para representar a RSU. Temos também uma estrutura LinkedList de DiscardMessage para armazenar as mensagens descartadas. A implementação de Antena para esse protocolo é idêntica aos protocolos anteriores. Para representar o OBU temos a classe DummyNode, nela temos uma estrutura HashMap que contem o id do OBU que enviou a mensagem e uma estrutura LinkedList de StringMessage contendo as mensagens que esse OBU enviou. Dentro dessa classe também temos o método handlemessages que trata todas as mensagens recebidas. O primeiro passo é pegar a primeira mensagem da estrutura e transforma-la para o tipo StringMessage, em seguida verificamos se a mensagem esta na lista de descarte, caso ela não esteja verificamos se já temos uma cópia dessa mensagem. Se ela não for encontrada adicionamos essa mensagem na lista. O programa 4.4 apresenta esse método implementado no public void handlemessages ( Inbox inbox ) { while ( inbox. hasnext ( ) ) { boolean f l a g = f a l s e ; 5 //Pega uma mensagem da c a i x a de entrada Message m = inbox. next ( ) ; this. nmensagens++;

30 4. Implementação dos protocolos // I n s t a n c i a de s t r i n g m e s s a g e StringMessage ms = ( StringMessage )m; // V e r i f i c a r se a mensagem r e c e b i d a e s t a na l i s t a de d e s c a t e for ( DiscardMessage d : this. discmsg ) { 15 // Deleta a mensagem i f ( d. g e t I d ( ) == ms. g e t I d ( ) ) { f l a g = true ; break ; 20 //Se eu nunca t i v e e s s a mensagem antes i f (! f l a g ) { // V e r i f i c a se j a e x i s t e e add 25 i f (! messages. containskey (ms. getnode ( ). ID ) ) { LinkedList <StringMessage> d = new LinkedList <StringMessage >() ; d. add (ms) ; // Incrementar o numero de hops somente a q u i 30 ms. inchops ( ) ; messages. put (ms. getnode ( ). ID, d ) ; else { 35 boolean e x i s t = f a l s e ; // Incrementar o numero de hops somente a q u i ms. inchops ( ) ; // o l h a r dentro da l i n k e d l i s t se j a e x i s t e a mensagem 40 for ( StringMessage msg : messages. get (ms. getnode ( ). ID ) ) i f ( msg. gettext ( ). e q u a l s I g n o r e C a s e (ms. gettext ( ) ) ) { e x i s t = true ; break ; 45 // se não e x i s t e a d i c i o n a i f (! e x i s t ) messages. get (ms. getnode ( ). ID ). add (ms) ; 50 Programa 4.4: Código do método handlemessages da classe DummyNode no protocolo Epidemic routing O método init é idêntico ao implementado nos protocolos anteriores. No método neighborhoodchange percorremos a lista de todos os OBU vizinhos verificando se algum deles é uma

31 4. Implementação dos protocolos 21 RSU, logo após fazemos um broadcast de cada mensagem para os OBUs vizinhos. Caso algum desses vizinhos seja uma RSU adicionamos as mensagens na lista de descarte e deletamos a mensagem. O programa 4.5 apresenta esse método implementado no public void neighborhoodchange ( ) { boolean hasantena=f a l s e ; //Se algum v i z i n h o f o r uma antena 5 for ( Edge e : this. outgoingconnections ) i f ( e. endnode instanceof Antena ) { hasantena = true ; break ; 10 for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) { // Envia a mensagem this. broadcast ( msg ) ; 15 //Se encontrou o nó de d e s t i n o add para na l i s t a de d e s c a r t e e apaga i f ( hasantena ) { // a d i c i o n a na l i s t a de mensagens de d e s c a r t e this. discmsg. add (new DiscardMessage ( msg. getnode ( ), msg. g e t I d ( ) ) ) ; 20 // d e l e t a a mensagem da hash this. messages. remove ( msg ) ; //Nro de mensagens d e s c a r t a d a s 25 this. ndescartes++; Programa 4.5: Código do método neighborhoodchange da classe DummyNode no protocolo Epidemic routing 4.3 Data-Mule System O protocolo Data-Mule-System consiste em uma arquitetura de três níveis: O nível mais baixo é ocupado pelos nós sensores fixos que coletam dados do ambiente. O nível intermediário consiste de OBUs (mulas) que se movem em torno de uma área coberta por sensores para coletar seus dados. Essas mulas tem o papel de descobrir e se comunicar tanto com sensores como com os RSUs, não se comunicando com outras mulas. O nível superior é constituído por um conjunto de pontos de acesso com fio (RSUs) que recebem os dados das mulas. Os nós

32 4. Implementação dos protocolos 22 do nível superior estão ligados a um armazém de dados central onde os dados recebidos são armazenados e processados. Para implementar esse protocolo usamos as mesmas estruturas explicadas anteriormente, usamos também as classes DummyNode para representar os nós fixos, a classe Mule para representar os OBUs e Antena para representar a RSU. A implementação de Antena para esse protocolo é idêntica aos protocolos anteriores. Para representar o nó fixo temos a classe DummyNode, nela temos uma estrutura HashMap que contem o id do nó que enviou a mensagem e uma estrutura LinkedList de StringMessage contendo as mensagens que esse nó enviou. Os nós fixos não recebem informação de ninguém, portanto seu método handlemessages é vazio.o método init é idêntico ao implementado nos protocolos anteriores. No método neighborhoodchange percorremos a lista de todos os vizinhos verificando se algum deles é do tipo Mule, em caso afirmativo enviamos todas as mensagens para esse vizinho. O programa 4.6 apresenta esse método implementado no public void neighborhoodchange ( ) { // Envia o dado se o v i z i n h o f o r uma mula for ( Edge e : this. outgoingconnections ) 5 i f ( e. endnode instanceof Mule ) { for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) { System. out. p r i n t l n ( "Mensagem "+i+ " enviada "+" Hops : "+msg. getnhops ( ) + "Mensagem : "+msg. gettext ( ) ) ; 10 //Manda as mensagens para a mula this. send (msg, e. endnode ) ; break ; 15 Programa 4.6: Código do método neighborhoodchange da classe DummyNode no protocolo Data-Mule-System Para representar os OBUs temos a classe Mule, nela temos uma estrutura HashMap que contem o id do nó que enviou a mensagem e uma estrutura LinkedList de StringMessage contendo as mensagens que esse nó enviou. Dentro dessa classe também temos o método handlemessages que trata todas as mensagens recebidas. O primeiro passo é pegar a primeira mensagem da estrutura e transformá-la para o tipo StringMessage, em seguida verificamos se já temos uma cópia dessa mensagem. Se ela não for encontrada adicionamos essa mensagem na lista. O programa 4.7 apresenta esse método implementado no simulador:

33 4. Implementação dos protocolos public void handlemessages ( Inbox inbox ) { while ( inbox. hasnext ( ) ) { boolean f l a g = f a l s e ; 5 //Pega uma mensagem da c a i x a de entrada Message m = inbox. next ( ) ; this. nmensagens++; 10 // I n s t a n c i a de s t r i n g m e s s a g e StringMessage ms = ( StringMessage )m; // V e r i f i c a se j a e x i s t e e add i f (! messages. containskey (ms. getnode ( ). ID ) ) { 15 LinkedList <StringMessage> d = new LinkedList <StringMessage >() ; d. add (ms) ; // Incrementar o numero de hops somente a q u i ms. inchops ( ) ; 20 messages. put (ms. getnode ( ). ID, d ) ; else { boolean e x i s t = f a l s e ; 25 // Incrementar o numero de hops somente a q u i ms. inchops ( ) ; // o l h a r dentro da l i n k e d l i s t se j a e x i s t e a mensagem for ( StringMessage msg : messages. get (ms. getnode ( ). ID ) ) 30 i f ( msg. gettext ( ). e q u a l s I g n o r e C a s e (ms. gettext ( ) ) ) { e x i s t = true ; break ; // se não e x i s t e a d i c i o n a 35 i f (! e x i s t ) messages. get (ms. getnode ( ). ID ). add (ms) ; Programa 4.7: Código do método handlemessages da classe Mule no protocolo Data-Mule- System No método neighborhoodchange percorremos a lista de todos os vizinhos verificando se algum deles é uma RSU, em caso afirmativo enviamos todas as mensagens para esse vizinho. O programa 4.8 apresenta esse método implementado no

34 4. Implementação dos protocolos 24 public void neighborhoodchange ( ) { // Envia o dado se o v i z i n h o f o r uma antena for ( Edge e : this. outgoingconnections ) 5 i f ( e. endnode instanceof Antena ) { for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) { //Manda as mensagens para a antena this. send (msg, e. endnode ) ; 10 break ; Programa 4.8: Código do método neighborhoodchange da classe Mule no protocolo Data- Mule-System 4.4 Context-Aware routing (CAR) No protocolo Context-Aware routing (CAR) cada OBU da rede se encarrega de produzir suas próprias probabilidades de entrega em relação a cada RSU. Probabilidades de entrega são trocados periodicamente para que cada OBU possa calcular o melhor caminho para cada RSU. Os melhores caminhos são calculados com base no contexto dos OBUs, nível de bateria residual, a taxa de variação da conectividade, a probabilidade de estar dentro do alcance do destino e o grau de mobilidade do nó são alguns exemplos. Quando o OBU candidato recebe uma mensagem ele a armazena em um buffer local. Ao cruzar com uma RSU a mensagem será entregue, do contrário, o OBU hospedeiro da mensagem verifica se seu par possui probabilidade maior. Sendo o caso, a mensagem é repassada. O contexto implementado nessa versão do protocolo foi o de número de mensagens trocadas sem ver uma RSU. Quando um OBU encontra com uma RSU sua probabilidade é incrementada. Se esse OBU trocar um número determinado de mensagens sem encontrar com uma RSU sua probabilidade é decrementada. Para implementar esse protocolo usamos as mesmas estruturas explicadas anteriormente, usamos também as classes DummyNode para representar os OBU e Antena para representar a RSU. A implementação de Antena para esse protocolo é idêntica aos protocolos anteriores. Para representar o OBU temos a classe DummyNode, nela temos uma estrutura HashMap que contem o id do OBU que enviou a mensagem e uma estrutura LinkedList de StringMessage contendo as mensagens que esse OBU enviou. Dentro dessa classe também temos o método handlemessages que armazena todas as mensagens recebidas. O primeiro passo é pegar a primeira mensagem da estrutura e transforma-la para o tipo StringMessage, em seguida verificamos se já temos uma cópia dessa mensagem. Se ela não for encontrada adicionamos a mensagem. O programa 4.9 apresenta esse método implementado no simulador:

35 4. Implementação dos protocolos public void handlemessages ( Inbox inbox ) { while ( inbox. hasnext ( ) ) { boolean f l a g = f a l s e ; 5 //Pega uma mensagem da c a i x a de entrada Message m = inbox. next ( ) ; 10 // Incrementa o numero de mensagens this. nmensagens++; // Incrementa as mensagens t r o c a d a s para a t u a l i z a r as p r o b a b i l i d a d e s this. numbermessageschanged++; // I n s t a n c i a de s t r i n g m e s s a g e 15 StringMessage ms = ( StringMessage )m; // V e r i f i c a se j a e x i s t e e add i f (! messages. containskey (ms. getnode ( ). ID ) ) { LinkedList <StringMessage> d = new LinkedList <StringMessage >() ; 20 d. add (ms) ; // Incrementar o numero de hops somente a q u i ms. inchops ( ) ; 25 messages. put (ms. getnode ( ). ID, d ) ; else { boolean e x i s t = f a l s e ; // Incrementar o numero de hops somente a q u i 30 ms. inchops ( ) ; // o l h a r dentro da l i n k e d l i s t se j a e x i s t e a mensagem for ( StringMessage msg : messages. get (ms. getnode ( ). ID ) ) i f ( msg. gettext ( ). e q u a l s I g n o r e C a s e (ms. gettext ( ) ) ) { 35 e x i s t = true ; break ; // se não e x i s t e a d i c i o n a i f (! e x i s t ) 40 messages. get (ms. getnode ( ). ID ). add (ms) ; Programa 4.9: Código do método handlemessages da classe DummyNode no protocolo Context-Aware routing

36 4. Implementação dos protocolos 26 5 No método neighborhoodchange percorremos a lista de todos os OBU vizinhos verificando se algum deles é uma RSU, em caso afirmativo enviamos todas as mensagens diretamente para a RSU e incrementamos a probabilidade de envio do OBU. Caso contrário selecionamos o OBU vizinho com maior probabilidade de envio para encaminharmos as mensagens. Se não encontrarmos nenhuma RSU enviamos todas as mensagens para o melhor OBU vizinho selecionado. Ao final do algoritmos verificamos se o numero de mensagens trocadas sem ver uma RSU é maior que o limite estabelecido, em caso afirmativo decrementamos a probabilidade de envio do OBU. O programa 4.10 apresenta esse método implementado no public void neighborhoodchange ( ) { boolean hasantena=f a l s e ; DummyNode bestnode = this ; //Se algum v i z i n h o f o r uma antena envia d i r e t o for ( Edge e : this. outgoingconnections ) { i f ( e. endnode instanceof Antena ) { hasantena = true ; 10 for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) { //Manda as mensagens d i r e t o pra antena this. send (msg, e. endnode ) ; 15 // Incremente a p r o b a b i l i d a d e this. incprobenvio ( ) ; // incrementa sua p r o b a b i l i d a d e de envio this. incprobenvio ( ) ; 20 // S e l e c i o n a o melhor v i z i n h o para envio else i f ( ( ( DummyNode) e. endnode ). getprobenvio ( ) > bestnode. getprobenvio ( ) ) bestnode = ( ( DummyNode) e. endnode ) ; 25 i f (! hasantena ) { for ( I n t e g e r i : messages. keyset ( ) ) for ( StringMessage msg : messages. get ( i ) ) { //Manda as mensagens para o melhor nó this. send (msg, bestnode ) ; 30 //A cada 10 mensagens t r o c a d a s sem ver a antena decrementa a p r o b a b i l i d a d e i f ( ( this. numbermessageschanged > this. maxmessageschanged ) && (! hasantena ) ) { 35 this. decprobenvio ( ) ; this. numbermessageschanged = 0 ;

37 4. Implementação dos protocolos 27 Programa 4.10: Código do método neighborhoodchange da classe DummyNode no protocolo Context-Aware routing

38 Capítulo 5 Protocolo desenvolvido Neste capítulo descrevemos detalhadamente todo o funcionamento do protocolo desenvolvido neste trabalho. Dada a distribuição de OBUs em veículos, elaboramos um protocolo de comunicação para troca de mensagens entre esse OBUs e desses veículos para as RSUs, que no caso seria a rede de RSUs na cidade. Os OBUs se movimentarão pela cidade monitorando eventos como um carro atravessar em sinal vermelho, detecção de veiculo roubado ou um veiculo estacionado em local proibido. Esses eventos serão processados e transformados em dados textuais. Esses dados serão trocados entre os OBUs até chegarem à uma RSU. O requisitos do protocolo são: entregar os dados o mais rápido possível, não inundar a rede trocando poucas mensagens e evitar a redundância de dados, ou seja, se um OBU receber dados aos quais já possui, esses dados serão descartados. O algoritmo 5.1 apresenta o pseudocódigo do algoritmo: Loop i n f i n i t o { Se a rede for conhecida { Se o d i s p o s i t i v o for uma antena { envia todos os dados para a antena 5 a d i c i o n a o i d de cada mensagem enviado na l i s t a de d e s c a r t a d a s Senão Se o d i s p o s i t i v o for um nó{ Se j a t r o q u e i dados com o nó{ sim j á e n v i e i para a antena dados do nó?{ 10 sim informe ao nó q u a i s dados foram enviados para antena. há novos dados?{ sim 15 e n v i e os dados novos que não estejam o b s o l e t o s não{ troque os dados que não estejam o b s o l e t o s { 28

39 5. Protocolo desenvolvido 29 Para cada dado r e c e b i d o { 20 Se o dado r e c e b i d o j a e x i s t e? d e s c a r t a o dado redundante Senão armazena o dado r e c e b i d o Senão não f a z nada Programa 5.1: Pseudocódigo do protocolo proposto OBU conterá a codificação do pseudocódigo para controlar a troca de mensagens. O funcionamento do protocolo é simples, se um OBU cruzar com um dispositivo conhecido ele verificará se o dispositivo é uma RSU, em caso afirmativo o OBU enviará todos os dados armazenados nele para essa RS. Se o dispositivo encontrado for um OBU que ele não trocou dados ainda ele troca dados com esse OBU, como podemos ver pela Figura 5.1a. Caso o OBU receba dados que já havia recebido antes, esses dados serão descartados para não gerar redundância de informação. Se o OBU encontrar com uma RSU ele transmite seus dados para ela, como podemos ver pela Figura 5.1b. Caso o OBU já tenha enviado os dados de outro OBU para uma RSU e tenha cruzado com esse mesmo OBU novamente ele envia uma mensagem para esse OBU para descarte dos mesmos, como podemos ver pela Figura 5.1c. (a) (b) (c) Figura 5.1: Sequência do protocolo.