ATUADORES SEM FIO
4.3.1 Ad Hoc On-Demand Distance Vector (AODV)
O AODV ´e um algoritmo de roteamento reativo que utiliza a t´ecnica de vetor de distˆancias, sendo especificado na IETF (For¸ca Tarefa de Engenharia da Internet) como experimental pelo c´odigo RFC 3561 (PERKINS; BELDING-ROYER; DAS, 2003). Este protocolo permite que um dispositivo obtenha rotas para novos destinos e n˜ao exige que estas rotas sejam mantidas (a menos que exista tr´afego intenso de dados entre os n´os).
O protocolo AODV ´e baseado nos algoritmos DSDV e DSR (ZHANG; PENG; SHAO, 2011). Esse protocolo utiliza a descoberta e manuten¸c˜ao de rotas semelhante ao DSR. No entanto, no DSR o pacote cont´em a informa¸c˜ao de toda a rota e no pacote do AODV somente o endere¸co do n´o de destino ´e informado. Ainda, o AODV faz uso do roteamento distribu´ıdo, da numera¸c˜ao sequenciada de rotas e do mecanismo de mensagens de atividade do DSDV. Por´em, ao inv´es de manter a informa¸c˜ao completa da topologia da rede em cada n´o, a informa¸c˜ao de caminhos ´e mantida de forma distribu´ıda entre cada um dos n´os que fazem parte de um caminho.
No protocolo AODV os n´os devem iniciar o procedimento de descoberta de rota sempre que desejarem enviar dados a um determinado destino que n˜ao consta em sua tabela de rotas. Em um primeiro momento uma mensagem de descobrimento de rota (RREQ - Route Request ) ´e enviada por broadcast a todos os n´os vizinhos. Qualquer dispositivo que receber esta solicita¸c˜ao de rota tamb´em deve propag´a-la, enviando outra mensagem de descobrimento de rota (PERKINS; ROYER, 1999). Este processo ´e exemplificado na figura 4.2.
Figura 4.2 - Processo de descoberta de rota do protocolo AODV
Eventualmente, um dispositivo que receber esta solicita¸c˜ao ´e capaz de se comunicar com o n´o de destino (por exemplo, se o n´o de destino est´a em sua tabela de vizinhos ou o n´o ´e o pr´oprio destino). Quando isto ocorrer, este n´o deve enviar uma mensagem de resposta de rota (RREP - Route Reply) para o n´o que lhe enviou a mensagem RREQ.
CAP´ITULO 4. ROTEAMENTO EM REDES DE SENSORES E ATUADORES SEM
FIO 60
Esta mensagem de resposta de rota ir´a se propagar de volta pelo caminho formado at´e atingir o n´o que a solicitou originalmente, como apresentado na figura 4.3. Todos os n´os que participam desta rota ir˜ao consequentemente possuir a rota para este determinado destino (PERKINS; ROYER, 1999).
Figura 4.3 - Propaga¸c˜ao de mensagens RREP do protocolo AODV atrav´es do caminho encontrado
A mensagem RREP tamb´em cont´em o custo da rota C(P ), representado pela equa¸c˜ao 4.1 (medida relacionada a qualidade da rota), que ´e dado pelo somat´orio dos custos de enlace individuais C(l). Na sua forma mais simples o custo de um enlace individual ´e um salto, ou seja, 1. Portanto, neste caso, C(P ) nada mais ´e do que o somat´orio de saltos do n´o que solicitou a rota at´e o destino. Este mecanismo permite ao n´o solicitante selecionar o caminho de menor custo para o destino, caso v´arias rotas sejam geradas a partir da solicita¸c˜ao. Nas tabelas 4.1 e 4.2 apresenta-se os campos das mensagens RREQ e RREP do AODV originalmente especificados na RFC 3561.
C(P ) =
L−1
X
i=1
C(Di, Di+1) (4.1)
Tabela 4.1 -Conte´udo de mensagem RREQ do protocolo AODV
Campo Tamanho (bytes)
Tipo de pacote, campo de op¸c˜oes e custo da rota em saltos 4 Identificador de requisi¸c˜ao de rota 4
Endere¸co IP do n´o de destino 4
N´umero de sequˆencia do n´o de destino 4 Endere¸co IP do n´o que originou o pedido 4 N´umero de sequˆencia do n´o que originou o pedido 4
Fonte: Perkins, Belding-Royer e Das (2003)
CAP´ITULO 4. ROTEAMENTO EM REDES DE SENSORES E ATUADORES SEM
FIO 61
• Campo de op¸c˜oes - define o tipo de pacote, a quantidade de saltos do n´o que originou o pacote at´e o n´o que esta com o pacote atualmente e outras configura¸c˜oes do protocolo;
• Identificador de requisi¸c˜ao de rota - identificador do pedido de rota;
• Endere¸co IP do destino - representa o endere¸co IP do destino desejado para o comando de requisi¸c˜ao de rota;
• N´umero de sequˆencia do destino - determina o ´ultimo n´umero de sequˆencia recebido pelo n´o que originou o pacote para qualquer rota atrav´es do destino; • Endere¸co IP do n´o que originou o pedido - representa o endere¸co IP do n´o
que requisitou a rota;
• N´umero de sequˆencia do n´o que originou o pedido - determina o n´umero de sequˆencia atual para ser utilizado na tabela de rotas para o autor do pedido da rota.
Tabela 4.2 -Conte´udo de mensagem RREP do protocolo AODV
Campo Tamanho (bytes)
Tipo de pacote, campo de op¸c˜oes e custo da rota em saltos 4
Endere¸co IP do n´o de destino 4
N´umero de sequˆencia de destino 4 Endere¸co IP do n´o que originou o pedido 4
Tempo de vida da rota 4
Fonte: Perkins, Belding-Royer e Das (2003).
No pacote RREP o tempo de vida ´e o tempo, em milissegundos, para o qual os n´os que receberem essa resposta de rota ir˜ao consider´a-la v´alida. O AODV possui ainda duas mensagens para a manuten¸c˜ao de rede, a mensagem de erro de rota (RERR - Route Error ) e a mensagem de reconhecimento de resposta de rota (RREP-ACK - Route Reply Acknowledgment ). A mensagem RERR ´e enviada sempre que a perda de um enlace deixar um ou mais destinos fora de alcance. J´a a mensagem RREP-ACK deve ser enviada em resposta a uma mensagem RREP sempre que um bit espec´ıfico do campo de op¸c˜oes esteja setado nessa mensagem. Esse procedimento ´e tipicamente realizado quando existe a possibilidade de enlaces unidirecionais (assim´etricos) e/ou colis˜oes prejudicarem a descoberta da rota.
Com o surgimento do padr˜ao IEEE 802.15.4TM (que define as camadas f´ısica e de
CAP´ITULO 4. ROTEAMENTO EM REDES DE SENSORES E ATUADORES SEM
FIO 62
como um protocolo reativo eficiente, o protocolo ZigBee (ZIGBEE ALLIANCE, 2004) foi desenvolvido. Este protocolo surgiu como poss´ıvel padr˜ao para redes de sensores e atuadores, implementando uma vers˜ao modificada de AODV, onde o custo de um enlace individual C(l) ´e definido pela equa¸c˜ao 4.2.
C(l) = min 7, arredondamento 1 pl4 (4.2) Onde o valor pl ´e a probabilidade de entrega do pacote atrav´es do enlace l, entre os
n´os Di e Di+1. Nas tabelas 4.3 e 4.4 apresenta-se os campos das mensagens RREQ e
RREP do AODV modificado implementado em redes ZigBee (ZIGBEE ALLIANCE, 2006). Estas mensagens s˜ao otimizadas para serem integradas ao padr˜ao IEEE 802.15.4TM .
Tabela 4.3 -Conte´udo de mensagem RREQ do protocolo AODV modificado utilizado pelo ZigBee
Campo Tamanho (bytes)
Campo de op¸c˜oes 1
Identificador de requisi¸c˜ao de rota 1
Endere¸co do destino 2
Custo da rota 1
Endere¸co IEEE do destino 0/8
Fonte: ZigBee Alliance (2006).
Na mensagem RREQ o campo de endere¸co do n´o que origina o pedido ´e informado na carga da camada MAC. A fun¸c˜ao dos outros campos ´e apresentada a seguir:
• Campo de op¸c˜oes - define se a requisi¸c˜ao de rota ´e espec´ıfica para um grupo de n´os (multicast ) ou se ´e no formato padr˜ao broadcast. Ainda, se o endere¸co IEEE 802.15.4TM estendido ser´a utilizado, bem como outras op¸c˜oes de rota;
• Identificador de requisi¸c˜ao de rota - identifica um determinado pedido de rota; • Endere¸co do destino - representa o endere¸co MAC reduzido do destino desejado
para o comando de requisi¸c˜ao de rota;
• Custo da rota - ´e utilizado para acumular o custo de rota enquanto o comando de requisi¸c˜ao de rota move-se atrav´es da rede;
• Endere¸co IEEE de destino - representa o endere¸co do destino desejado para o comando de requisi¸c˜ao de rota, utilizando o endere¸co IEEE 802.15.4TM estendido
CAP´ITULO 4. ROTEAMENTO EM REDES DE SENSORES E ATUADORES SEM
FIO 63
Tabela 4.4 -Conte´udo de mensagem RREP do protocolo AODV modificado utilizado pelo ZigBee
Campo Tamanho (bytes)
Campo de op¸c˜oes 1
Identificador de requisi¸c˜ao de rota 1 Endere¸co do n´o que originou o pedido 2 Endere¸co do n´o que respondeu o pedido 2
Custo da rota 1
Endere¸co IEEE do n´o que originou o pedido 0/8 Endere¸co IEEE do n´o que respondeu o pedido 0/8
Fonte: ZigBee Alliance (2006).
No comando RREP os campos de endere¸co sofrem uma pequena altera¸c˜ao. O endere¸co do n´o que originou a rota cont´em o endere¸co MAC reduzido (16 bits) do n´o que iniciou o comando RREQ. J´a o endere¸co do n´o que respondeu o pedido deve sempre conter o endere¸co MAC reduzido contido no campo “Endere¸co do destino” no comando RREQ. Visivelmente as especifica¸c˜oes do protocolo ZigBee buscaram reduzir a sobrecarga dos pacotes de controle do AODV, tornando vi´avel sua utiliza¸c˜ao em conjunto com r´adios compat´ıveis com o padr˜ao IEEE 802.15.4TM.
Apesar dessas melhorias, as limita¸c˜oes do AODV recaem novamente nos altos custos envolvendo mensagens de controle e ocupa¸c˜ao de mem´oria de dados quando consideramos sua aplica¸c˜ao a redes em malha. No caso das rotas expirarem rapidamente, evitando o uso excessivo de mem´oria, novos procedimentos de descoberta de rotas devem ser executados. A execu¸c˜ao constante destes procedimentos sobrecarrega a rede com mensagens de controle. J´a no caso das rotas serem mantidas por mais tempo, o consumo de mem´oria aumenta na medida em que novas rotas v˜ao sendo criadas. A mem´oria de dados necess´aria para armazenar a rota de milhares de n´os facilmente atingiria valores de dezenas de quilobytes (deve-se lembrar que todo n´o que participa de uma rota a mant´em armazenada).