Encaminhamento em VANET
As redes veiculares podem ser definidas como redes ad-hoc. No entanto, devido ao facto de os n´os da rede serem ve´ıculos, estas apresentam uma mobilidade muito superior `as redes ad- hoc tradicionais. Devido a esta mobilidade, os protocolos de encaminhamento desenvolvidos para MANETs podem n˜ao apresentar o mesmo desempenho em VANETs. Deste modo torna- se necess´ario perceber se os protocolos de encaminhamento dispon´ıveis se conseguem adaptar a esta mobilidade, e quais as configura¸c˜oes necess´arias para tal.
Os trˆes protocolos de encaminhamento estudados s˜ao protocolos proativos, isto ´e, s˜ao permanentemente trocadas mensagens de controlo que estabelecem todas as rotas poss´ıveis. Como em redes veiculares o tempo de liga¸c˜ao entre ve´ıculos ser´a reduzido, torna-se importante perceber qual o impacto que tempo entre envio de pacotes de controlo de topologia tem sobre a dete¸c˜ao de um novo n´o na rede e sobre o tempo de rea¸c˜ao `a quebra de uma liga¸c˜ao. Assim, efetuaram-se testes variando o tempo de envio de mensagens de controlo e mediram-se os respetivos tempos de rea¸c˜ao `a presen¸ca de um novo n´o na rede e `a quebra de uma liga¸c˜ao. Deste modo, ´e poss´ıvel verificar qual o intervalo entre envio de pacotes de topologia apresenta melhor tempo de rea¸c˜ao, em fun¸c˜ao do overhead introduzido na rede. ´E tamb´em poss´ıvel efetuar uma compara¸c˜ao entre os protocolos utilizados, de modo a verificar qual se adapta melhor `a elevada mobilidade das redes veiculares.
Para se efetuar o teste de verifica¸c˜ao do tempo necess´ario `a descoberta de um novo n´o na rede utilizaram-se duas placas com equipamento semelhante ao descrito na sec¸c˜ao anterior. Na primeira placa colocou-se o protocolo de encaminhamento sempre em funcionamento, enquanto na outra foi introduzido um fluxo de pacotes ICMP com um intervalo de 1 ms (desta forma ´e poss´ıvel ter uma precis˜ao ao milissegundo) destinado `a primeira e iniciou- se uma captura de pacotes, recorrendo ao programa Tshark [84]. De seguida iniciou-se o protocolo de encaminhamento na placa onde foi iniciado o fluxo de dados, e mediu-se a diferen¸ca entre o primeiro pacote ICMP entregue com sucesso e o primeiro pacote de controlo de topologia enviado, sendo poss´ıvel verificar qual o tempo necess´ario para que um n´o seja
reconhecido na rede.
Figura 3.1: Tempo necess´ario para descoberta de um novo n´o na rede em fun¸c˜ao do intervalo entre envio de pacotes de HELLO
A Figura 3.1 mostra os resultados obtidos a partir do teste descrito anteriormente. O pri- meiro facto facilmente observ´avel ´e a grande diferen¸ca entre o protocolo OLSR e os restantes. Mesmo com o envio de mensagens HELLO a cada 200 ms, verifica-se que o tempo de dete¸c˜ao de um novo n´o na rede n˜ao baixa significativamente, mantendo-se sempre em valores de apro- ximadamente oito segundos. Outro aspeto observ´avel na figura ´e a grande diferen¸ca entre os resultados obtidos quando utilizadas as defini¸c˜oes default em cada protocolo. ´E poss´ıvel verificar que, para o protocolo BABEL, o tempo de descoberta de um novo n´o ´e bastante elevado, pois este na sua configura¸c˜ao default envia pacotes de controlo de topologia a cada quatro segundos. Esta defini¸c˜ao, como se pode observar pela figura, leva a um tempo de descoberta de um novo n´o na rede bastante elevado, o que faz com que esta defini¸c˜ao n˜ao seja adequada a redes veiculares. No entanto, quando utilizados os intervalos semelhantes aos outros protocolos, nota-se que este apresenta um desempenho superior, ainda que quando comparado com o B.A.T.M.A.N. a diferen¸ca seja bastante reduzida. Por fim, pode-se ainda concluir que o intervalo que apresenta melhor rela¸c˜ao entre o tempo de descoberta de um novo n´o na rede em fun¸c˜ao do overhead introduzido ´e o intervalo de 500 ms; uma vez que utilizando o intervalo de 200 ms, o overhead ´e mais do que duplicado, o que leva a uma utiliza¸c˜ao pouco eficiente dos recursos dispon´ıveis.
De forma a ser poss´ıvel obter o tempo necess´ario para que os protocolos em estudo detetem uma quebra de liga¸c˜ao numa rota, utilizaram-se quatro placas semelhantes `as utilizadas an-
Destino Fonte wlan1 20.0.0.40 wlan1 20.0.0.41 wlan1 20.0.0.42 wlan2 30.0.0.41 wlan2 30.0.0.42 wlan2 30.0.0.43
Figura 3.2: Esquematiza¸c˜ao da testbed utilizada para determinar o tempo de rea¸c˜ao `a quebra de uma rota
teriormente, criando-se assim uma rede conforme esquematizado na Figura 3.2. Deste modo, existem duas rotas poss´ıveis entre a fonte e o destino. Quando uma das rotas ´e quebrada, o protocolo ´e obrigado a alterar a rota. Para medir o tempo necess´ario para o protocolo se aperceber da quebra da rota, introduziu-se um fluxo de dados utilizando o protocolo de transporte User Datagram Protocol (UDP), para que n˜ao existam retransmiss˜oes e se possa perceber qual o tempo efetivo de rea¸c˜ao `a quebra da rota. Depois de introduzido este fluxo de dados, mediu-se o tempo em que n˜ao houve a rece¸c˜ao de dados, recorrendo `a ferramenta Tshark.
Na Figura 3.3 podem-se observar os tempos de rea¸c˜ao `a quebra de uma rota em fun¸c˜ao do intervalo entre o envio de pacotes de controlo de topologia, para os v´arios protocolos de enca- minhamento em estudo. Analisando esta figura, verifica-se que o protocolo OLSR apresenta tempos de descoberta de quebra de rota muito elevados, e que estes n˜ao s˜ao influenciados pela altera¸c˜ao do intervalo entre o envio de pacotes TC. Tal como verificado no teste anterior, neste tamb´em se pode perceber que o protocolo OLSR ´e muito lento a aperceber-se de altera¸c˜oes na topologia da rede, o que faz com que este n˜ao seja muito adequado para as redes veiculares. Quanto aos restantes protocolos, ´e poss´ıvel verificar que ao contr´ario do teste anterior, em que o comportamento era semelhante, neste teste o protocolo BABEL mostra um desempe- nho bastante superior. Mesmo quando utilizado o intervalo de envio de pacotes de controlo de topologia de 500 ms, este apresenta um desempenho superior ao protocolo B.A.T.M.A.N.,
Figura 3.3: Tempo necess´ario para descoberta da quebra de uma rota em fun¸c˜ao do intervalo entre envio de pacotes de controlo de topologia
quando este se encontra configurado com um intervalo de 200 ms. Tamb´em, ao contr´ario do teste anterior, verifica-se uma grande diferen¸ca nos resultados obtidos utilizando o intervalo de 200 ms em rela¸c˜ao aos obtidos com o intervalo de 500 ms, isto em ambos os protocolos. Apesar destes factos, ´e necess´ario ter em conta o grande aumento no overhead introduzido na rede, sendo para esse feito necess´ario realizar testes com um grande n´umero de n´os na rede para perceber at´e que ponto este aumento do overhead se iria refletir no desempenho da rede.