Modelagem do framework utilizando Redes de Petri

Um modelo em Redes Petri foi desenvolvido com o objetivo de observar os eventos ocorridos durante a transmissão das mensagens de seguran¸ca. Trata-se de um modelo sim- plificado que representa um dos nós da rede veicular, de forma que se possa acompanhar as etapas do funcionamento do framework. A modelagem simplificada não representa to- das as fun¸cões previstas nem os modelos necessários para a dissemina¸cão das mensagens no meio sem fio. No entanto, permite observar a gera¸cão dos beacons e das mensagens

de alerta, a conten¸c˜ao pelo acesso ao meio, o tratamento das mensagens recebidas e a atualiza¸c˜ao dos valores dos flags.

O modelo, apresentado na Figura 17, foi desenvolvido com a ferramenta CPN To- ols (CPNTOOLS, 2013). Essa ferramenta possibilita a edi¸cão, simula¸cão e análise de Redes de Petri Coloridas. Com a utiliza¸cão de Redes de Petri, fichas representam os recursos existentes em determinados lugares como, por exemplo, as mensagens enviadas e recebidas, os valores de potência e do tamanho da janela de conten¸cão e o tempo necessário para o envio das mensagens. Transi¸cões fazem com que fichas sejam levadas de um lugar a outro de acordo com o que é representado pelos arcos de entrada, que ligam lugares a transi¸cões, e pelos arcos de sa´ıda, que ligam transi¸cões a lugares. O disparo de uma transi¸cão depende da existência de fichas nos lugares de entrada e das condi¸cões impostas pela fun¸cão de guarda da transi¸cão.

Veiculo Veic (1,0.0,0.0,10.0,400.0,15) Broadcast Fusion1 MSG Fusion1 Mensagens MSG FLAGS_V FLAGS (1,1,1) Mensagens Recebidas LM [] Tempo ltempo [] A STT 1`0 B STT 1`0 CWi CW 1`15 Pt PWR 400 CW CW 1`1 Meio Fusion 2 BUSY 1`0 Fusion 2 FLAGS_L FLAGS (1,1,1) Nova_CW INT 1 Tempo1 INT 0 Tempo2 INT 0 Tempo3 INTt 0 Tempo0 INT ₀ Tempo4 INTt 0 Tempo5 INT 0 Transmitir @+1 [cw=0 andalso ncw=0] Receber [rrec(m,v) andalso intTime()-tempo>1]

Beacon @+100 Alerta

@+500 [status=1]

Atualiza flags vizinhos [lmsg<>[] andalso intTime()-tempo > 1000] Backoff @+1 [cw>0] [cw=0 andalso ncw=1] Adapta @+10 Descarta [intTime()-tempo>2]

Atualiza flags locais [tt<>[] andalso intTime()-tempo > 1000] Atualiza @+10 m at(m,lmsg) gera_alerta(v,f) f atf(lmsg) status v m lista_tempo(m,tt) gera_beacon(v,f) tt m lmsg v rrepas(m,v) status lmsg [] cwi discrete(1,cwi) cw conta(n,cw) n cw m fv cw adp_cw(fl,fv) pt adp_pt(fl,fv) v m 1 0 cw atfl(tt,v) f tt v f f m 1 ncw [] tempo intTime() tempo intTime() ncw 0 cwi pt v atveic(v,pt,cwi) tempo 1 n intTime() tempo tempo fl tempo intTime()

Figura 17: Modelo utilizando Redes de Petri

Na figura podemos observar, ao centro, um lugar denominado “Veiculo”, que mantém as informa¸cões do nó simulado: identificador, coordenadas X e Y, velocidade, alcance de transmissão e tamanho da janela de conten¸cão. Periodicamente, a posi¸cão do ve´ıculo é atualizada de acordo com sua velocidade. Isso é realizado pela transi¸cão “Atualiza” e pela fun¸cão “atveic(v,pt,cwi)”, que utiliza também os valores de potência e do tamanho da janela de conten¸cão.

A transi¸cão “Beacon” é utilizada para gerar, de forma periódica, as mensagens de seguran¸ca a partir das informa¸cões dos ve´ıculos. Com uma frequência menor, a transi¸cão “Alerta” gera as mensagens relacionadas a eventos, como acidentes. Devido a isso, a fun¸cão de guarda dessa transi¸cão só permite o seu disparo quando “status” tem o valor “1”, indicando a ocorrência de um evento relacionado àquele nó. Ambas as transi¸cões

geram informa¸cões prontas para serem enviadas, que ficarão no lugar “Mensagens”. A partir do valor da janela de conten¸cão gerado, um temporizador de backoff é decre- mentado sempre que o meio estiver livre. Quando esse tempo chegar a zero, a mensagem é transmitida. Nesse momento, o lugar “Tempo” armazena o valor decorrido entre o momento em que a mensagem estava pronta para o envio e o momento em que foi enviada. Observe-se que, por ocasião do envio da mensagem, o lugar “Broadcast” é ocupado pela mensagem e o lugar “Meio” passa a indicar que o meio não está livre. Como se tratam de lugares de fusão, esses valores são observados por todos os nós. Dessa forma, todos devem ser capazes de detectar a mensagem, assim como perceber que o meio está ocupado.

Na simula¸cão, cada nó pode receber a mensagem desde que as condi¸cões da guarda da transi¸cão “Receber” sejam satisfeitas. Essas condi¸cões verificam se a mensagem não foi enviada pelo próprio nó e se o alcance do sinal está além da distância até o nó que a enviou. Após essa etapa, a mensagem é removida do meio, que estará livre para que outro envio possa ser realizado. A mensagem recebida é armazenada e pode ser reenviada após verifica¸cão pela fun¸cão “rrepas(m,v)”, que submete a mensagem às condi¸cões para seu reenvio.

A partir das mensagens recebidas, periodicamente os valores dos flags dos vizinhos são atualizados, através da transi¸cão “Atualiza flags vizinhos” e da fun¸cão “atf(lmsg)”. Essa fun¸cão observa os valores indicados pela maioria dos vizinhos nas fichas depositadas no lugar “Mensagens recebidas”. Uma transi¸cão semelhante utiliza a fun¸cão chamada “atfl(tt,v)” para atualizar os flags locais periodicamente de acordo com o tempo que as últimas mensagens levaram para ser transmitidas e com as informa¸cões do ve´ıculo, para estimar a densidade. A partir da determina¸cão dos flags, a transi¸cão “Adapta” é responsável por realizar a adapta¸cão através da varia¸cão dos valores de potência e do tamanho da janela de conten¸cão (respectivamente, nos lugares “Pt” e “CWi”).

Como apenas um nó é representado, é necessário replicar o modelo para que se ob- tenham os outros nós para a simula¸cão. Apesar da simplifica¸cão, é poss´ıvel observar a sequência de eventos que levam à atua¸cão do framework. Dessa forma, o modelo desenvolvido constitui-se numa ferramenta que permite verificar os estados e eventos ocorridos durante a dissemina¸cão das mensagens de seguran¸ca.

4.5 Resumo

Neste cap´ıtulo apresentamos o framework para a gerência da dissemina¸cão adaptativa de mensagens de seguran¸ca. Composto de três módulos (deteçcão, preven¸cão e adapta¸cão), o framework tem como objetivo atuar nas etapas da dissemina¸cão de mensagens, contro- lando a forma como a adapta¸cão é realizada. Isso é poss´ıvel através da utiliza¸cão de três flags, relacionados a conectividade, congestionamento e densidade.

O módulo de deteçcão tem a fun¸cão de verificar as condi¸cões de rede e de tráfego e determinar o valor dos flags. O módulo de preven¸cão evita que situa¸cões adversas

comprometam o desempenho da entrega. Enquanto que o m´odulo de adapta¸c˜ao realiza os ajustes determinados de acordo com os valores dos flags.

Além disso, um dos componentes do módulo de adapta¸cão tem como objetivo verificar as informa¸cões repassadas pelos vizinhos, para coordenar a forma como a adapta¸cão é realizada. Assim, a decisão sobre a adapta¸cão é tomada a partir dos valores determinados localmente e das informa¸cões recebidas dos ve´ıculos vizinhos. Dessa forma, evita-se que um ajuste local venha a comprometer os outros nós da rede.

Cap´ıtulo 5

ESTUDO DE CASO I

Neste cap´ıtulo instanciamos o framework proposto para verifica¸cão de sua aplica¸cão em um cenário de uma zona urbana, com varia¸cão da densidade de ve´ıculos. Para fins de com- para¸cão, utilizamos outros mecanismos de dissemina¸cão das mensagens de seguran¸ca. Em seguida, analisamos os resultados, levando em conta métricas importantes para aplica¸cões de seguran¸ca em redes veiculares.

5.1 Ambiente de simula¸c˜ao

Para a realiza¸cão dos experimentos dos estudos de caso, utilizamos dois simuladores, um para a simula¸cão do ambiente de rede e outro para a gera¸cão da mobilidade dos ve´ıculos. Além disso, para gerar os mapas das regiões simuladas, utilizamos a fun¸cão de exporta¸cão de mapas reais da plataforma Openstreetmap (OPENSTREETMAP, 2013). A seguir, descrevemos como os cenários utilizados nas simula¸cões foram gerados.

Gera¸c˜ao da mobilidade dos ve´ıculos

Após a exporta¸cão do mapa da região desejada, o arquivo foi levado à ferramenta SUMO (Simulation of Urban MObility), versão 2.22 (SUMO, 2013). A ferramenta permite que sejam gerados vários deslocamentos de ve´ıculos de forma aleatória ou organizando-os em fluxos que percorrem determinadas vias, no sentido indicado pelos mapas. Isso possibilitou a gera¸cão da movimenta¸cão dos ve´ıculos nas densidades planejadas para as simula¸cões. Foi poss´ıvel também simular a ocorrência de um acidente em cada simula¸cão, o que, na ferramenta SUMO, é feito com a parada dos ve´ıculos acidentados na posi¸cão da via escolhida e durante o tempo desejado.

A sa´ıda da ferramenta é um arquivo com registros (traces) da movimenta¸cão dos ve´ıculos. Através de comandos dispon´ıveis na própria ferramenta, é poss´ıvel converter o arquivo de movimenta¸cão para o formato utilizado na ferramenta responsável pelo tráfego de rede. Neste caso, o arquivo foi convertido para o formato apresentado na Figura 18, que mostra, a cada instante, as posi¸cões de destino no deslocamento de cada ve´ıculo e a sua velocidade. Por exemplo, a primeira linha indica que, aos 32.2 s, o nó 4 se desloca para a posi¸cão com coordenadas 1675.29, 1805.15 com velocidade de 21.77 m/s.

Figura 18: Trecho do arquivo com a movimenta¸c˜ao dos ve´ıculos

Simula¸c˜ao do ambiente de rede

Para essa etapa foi utilizado o Network Simulator (ns-2), em sua versão 2.35 (NS-2, 2012). A partir do arquivo gerado na etapa anterior, os ve´ıculos passam a constituir os nós da rede. Para cada um deles, é necessário criar um agente associado à aplica¸cão que será utilizada. Nos estudos de caso, as aplica¸cões foram: envio de beacons e envio de mensagens de alerta. A seguir, é preciso programar cada um desses agentes para enviar dados de acordo com a aplica¸cão. Para isso, foram utilizados scripts que geravam o envio de beacons por cada um dos ve´ıculos dez vezes por segundo e o envio de mensagens de alerta pelos ve´ıculos envolvidos no acidente simulado com a frequência de duas vezes por segundo.

Apesar de a ferramenta possibilitar a utiliza¸cão de anima¸cões para visualizar o com- portamento dos nós, exibindo sua movimenta¸cão e o tráfego de dados, essa funcionalidade não foi utilizada. Para a análise, utilizamos os arquivos de sa´ıda com registros (traces) do simulador, que permitem verificar cada evento ocorrido e extrair informa¸cões, como a perda de alguma mensagem, o tempo da ocorrência e em qual camada o evento ocorreu. Essas informa¸cões são analisadas em seguida para a obten¸cão dos resultados. Um exemplo desse arquivo de sa´ıda é apresentado na Figura 19. Para exemplificar, o registro marcado na figura indica:

• r: Tipo de evento (recep¸c˜ao)

• 21.230314304: tempo de ocorrˆencia do evento • 99: identificador do n´o

• 21225: identificador da mensagem • safety: tipo da mensagem

• 200: tamanho da mensagem em bytes • 0 ffffffff 3 0: informa¸c˜oes da camada MAC • 3:21 -1:21 32 0: informa¸c˜oes da camada de rede

• safety 1 21225 21.228838: informa¸c˜oes da camada de aplica¸c˜ao

Figura 19: Arquivo de sa´ıda do simulador de rede

Na configura¸cão dos parâmetros do simulador, o modelo de camada MAC escolhido foi o 802.11Ext, indicado para a simula¸cão do padrão IEEE 802.11p, utilizado em redes veiculares (CHEN et al., 2007). O modelo de propaga¸cão utilizado é o Nakagami, considerado mais adequado para representar os efeitos de propaga¸cão no ambiente de redes veiculares (SINGH, 2012). À exce¸cão do que for citado na descri¸cão dos cenários de simula¸cão, os parâmetros utilizados foram os valores padrão do simulador.

Para implementar a proposta apresentada, foi necessário programar uma nova classe, responsável pelo envio das mensagens de alerta. Essa nova classe foi programada para identificar se a mensagem era um beacon ou um alerta, montar o cabe¸calho da mensagem de acordo com o formato proposto apresentado na Se¸cão 4.1 e tratar as mensagens recebidas. Além disso, foram criadas tabelas para a manipula¸cão dos flags e de outras informa¸cões, como o tempo de acesso. Altera¸cões nas classes existentes foram necessárias para realizar a adapta¸cão da potência e do tamanho da janela de conten¸cão, de forma que os valores dos flags pudessem ser consultados antes do envio das mensagens.

No documento Um Framework para a gerência da disseminação adaptativa de mensagens de segurança em redes veiculares (páginas 54-61)