Protocolo de Encaminhamento Route Alternating Multipath AODV (RAM-AODV) Justimiano Andrade Alves Dissertação para obtenção do Grau de Mestre em Engenharia electrotécnica e de computadores Júri: Presidente: Professor Nuno Cavaco Gomes Horta Orientador: Professor António Manuel Raminhos Cordeiro Grilo Co-orientador: Professor Paulo Rogerio Barreiros d'Almeida Pereira Vogal: Professor Carlos Manuel Ribeiro Almeida Abril 2012
113
Embed
Route Alternating Multipath AODV (RAM-AODV)E7%E3o.pdfProtocolo de Encaminhamento Route Alternating Multipath AODV (RAM-AODV) Justimiano Andrade Alves Dissertação para obtenção
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Protocolo de Encaminhamento
Route Alternating Multipath AODV (RAM-AODV)
Justimiano Andrade Alves
Dissertação para obtenção do Grau de Mestre em
Engenharia electrotécnica e de computadores
Júri:
Presidente: Professor Nuno Cavaco Gomes Horta
Orientador: Professor António Manuel Raminhos Cordeiro Grilo
Co-orientador: Professor Paulo Rogerio Barreiros d'Almeida Pereira
Vogal: Professor Carlos Manuel Ribeiro Almeida
Abril 2012
I
II
Resumo
As redes móveis ad-hoc (Mobile Ad-hoc Networks - MANET) e a proliferação de dispositivos portáteis com
capacidade de comunicação sem fios têm incentivado a investigação na área dos protocolos de
encaminhamento. Devido à liberdade de movimento dos nós, à sua configuração imprevisível, às
limitações de autonomia dos dispositivos e da largura de banda da rede, as falhas de comunicação podem
tornar-se comuns neste tipo de redes.
De modo a ultrapassar estas limitações, e com os objectivos de determinar vários percursos, minimizar a
sobrecarga da rede e maximizar a largura de banda, neste trabalho implementou-se um protocolo Route
Alternating Multipath AODV (RAM-AODV) com encaminhamento multi-percurso. O protocolo
implementado possibilita a descoberta de múltiplos percursos entre os nós de origem e de destino, como
também permite especificar o número de percursos parcialmente disjuntos a serem descobertos, o que
permite reduzir significativamente a sobrecarga da rede. À semelhança do protocolo Ad-hoc On-Demand
Distance Vector (AODV), no protocolo RAM-AODV é feita monitorização local dos vizinhos e são
descartados pedidos redundantes Route Request (RREQ) nos nós intermédios. Para comparar o
desempenho do protocolo desenvolvido com o protocolo AODV foram realizadas várias simulações para
diferentes cenários, onde o protocolo implementado mostrou ter um melhor desempenho do que o
protocolo AODV. Os resultados obtidos mostram-nos que o protocolo desenvolvido é eficiente na redução
do número de pacotes perdidos, no tempo de atraso na comunicação e na utilização da largura de banda.
Em todos os cenários em que o protocolo foi testado, revelou ser mais eficiente do que o protocolo AODV.
III
IV
Abstract
The Mobile Ad-hoc Networks (MANET) and the proliferation of the portable devices capable of wireless
communication have encouraged the research in the area of communication protocols. Due to the freedom
of movement of the nodes, the undefined network’s configuration, the limitations of the devices’
autonomy and of the network’s bandwidth, the communication failures are very common in these
scenarios.
In order to overcome these limitations, as well as with the goals of determining various routes and
minimizing overhead and maximizing the network’s bandwidth, an RAM-AODV protocol (Route
Alternating Multipath AODV - RAM-AODV) with multi-path routing functionality was implemented in this
thesis project. The implemented protocol enables the discovery of multiple paths between the origin and
the destination nodes, but also offers the possibility of specifying the number of partially disjoint paths to
be discovered, which significantly reduces the network’s overhead. The similarities of the developed
protocol with the Ad-hoc On-Demand Distance Vector (AODV) protocol are the local monitoring and the
discarding of the duplicated Route Requests (RREQ) at the intermediate nodes. In order to compare the
performance of the developed protocol with the AODV protocol, several simulations for different
scenarios were performed, where the implemented protocol showed to have better performance than
AODV protocol. The results show us that the developed protocol is effective in reducing of number of the
lost packets and the delivery delay, while improving the bandwidth usage. In all the scenarios in which the
RAM-AODV was tested it showed to have a much better performance than the AODV.
Apêndice A ...................................................................................................................................................... 74
viii
Lista figuras
Figura 1-1: Rede MANET com 5 nós [Fonte: [1]] ....................................................................................................................... 2
Figura 1-2: Rede MANET com 7 Interfaces. [Fonte: [1]] ......................................................................................................... 3
Figura 1-3: MANET: Assimetria entre as interfaces. [Fonte: [1]] ........................................................................................ 4
Figura 2-1: Categoria dos protocolos de encaminhamento para as redes MANET. ................................................. 11
Figura 2-2: Arquitectura do protocolo ZRP. [Fonte: [11]] .................................................................................................. 18
Figura 2-3: Zona de encaminhamento do nó S. [Fonte: [12]] ............................................................................................ 18
Figura 2-4: Zona de encaminhamento do nó. [Fonte: [12]] ................................................................................................ 19
Figura 2-5:Zona de encaminhamento do nó T. [Fonte: [12]] ............................................................................................. 19
Figura 2-6:Processo de descoberta de rotas – AOMDV. ....................................................................................................... 23
Figura 2-7:Processo de definição do percurso inverso – protocolo OAOMDV. .......................................................... 24
Figura 2-8: Formato do pacote RREQ do OAOMDV. ............................................................................................................... 25
Figura 2-9: Formato da mensagem RREP_ACK do protocolo OAOMDV ........................................................................ 26
Figura 2-10:Processo de definição de percurso directo - protocolo OAOMDV. ......................................................... 26
Figura 2-11:Processo de definição do percurso omitido - protocolo OAOMDV. ....................................................... 27
Figura 2-12:Processo de cálculo de nós disjuntos MP-AOMDV. ....................................................................................... 29
Figura 2-13:O algoritmo Dijkstra de multi-percuros. [fonte: [15]] ................................................................................. 33
Figura 2-14: Algoritmo Dijkstra com fp (c) = fe (c) = 2c. Na primeira figura foram calculados 3 percursos e
na segunda figura foram calculadas 10 percursos [fonte: [15]]. .......................................................................... 33
Figura 2-15: processo de descoberta de rota pelo nó F. ....................................................................................................... 34
Figura 3-1:Formato do pacote Route Request – RREQ. ......................................................................................................... 39
Figura 3-2:Formato do pacote Route Reply – RREP. ............................................................................................................... 39
Figura 3-3:Formato do pacote Route Error - RRER. ............................................................................................................... 39
Figura 3-4: Formato do pacote Route Reply Acknowledgement - RREP_ACK. ............................................................. 40
Figura 3-5: Formato da tabela de encaminhamento. ............................................................................................................. 40
Figura 3-6:Formato da entrada da tabela de encaminhamento. ...................................................................................... 41
Figura 3-7:Formato da lista de próximos saltos. ..................................................................................................................... 41
Figura 3-8:Formato da tabela de vizinhos processados. ...................................................................................................... 42
Figura 3-9:Formato da tabela de RREQ Pendentes. ............................................................................................................... 42
Figura 3-10:Tabela de Contador de percurso para o nó de destino. ............................................................................... 43
Figura 3-11:Fluxograma do algoritmo implementado no nó de destino para processar o pacote RREQ. ..... 45
Figura 3-12: Processo de descoberta de rota do protocolo RAM-AODV. ...................................................................... 47
Figura 4-1: Exemplo de uma topologia estática lógica e genérica da rede. ................................................................. 53
Figura 4-2: Valores médios do atraso extremo-a-extremo em redes estáticas, com número de nós variável.
Figura 4-9: Valores médios do débito em redes estáticas, com intervalo de envio de pacotes variável. ....... 60
Figura 4-10: Valores médios do atraso extremo-a-extremo em redes dinâmicas, com velocidade de
movimento dos nós variável. ................................................................................................................................................ 63
Figura 4-11: Valores médios do jitter em redes dinâmicas, com velocidade de movimento dos nós variável.
Figura 4-12: Valores de taxa média de pacotes recebidos em redes dinâmicas, com velocidade de
movimento dos nós variável. ................................................................................................................................................ 64
Figura 4-13: Valores médios do débito em redes dinâmicas, com velocidade de movimento dos nós
Tabela 2-1: Entrada da tabela de encaminhamento do protocolo OAOMDV. ............................................................. 25
Tabela 2-2: Estrutura da Lista de percursos do protocolo OAOMDV. ............................................................................ 25
Tabela 4-1: Definição dos parâmetros constantes para os dois cenários. .................................................................... 49
Tabela 4-2: Atributos e valores por omissão. ............................................................................................................................ 50
Tabela 4-3: Definição dos parâmetros para o teste 1. ........................................................................................................... 53
Tabela 4-4:Definição dos parâmetros para o cenário da mobilidade............................................................................. 62
Este protocolo é uma extensão do protocolo AODV para realizar o encaminhamento multi-percurso. Ao
contrário do AODV, cada pacote RREQ é considerado pelo nó de destino. Consequentemente, múltiplos
percursos podem ser descobertos num só pedido de descoberta. A entrada da tabela de encaminhamento
contém uma lista de endereços IP de nós para próximos saltos e os respectivos valores de hop-count. O
AOMDV utiliza apenas as mensagens informativas do protocolo AODV, limitando deste modo a sobrecarga
da rede durante o processo de descoberta dos vários percursos. As únicas fontes de sobrecarga em relação
ao protocolo AODV, são as mensagens RREPs e RRERs extra para descoberta e manutenção dos vários
percursos, juntamente com alguns campos suplementares no encaminhamento dos pacotes de controlo
(RREQs, RREPs e RRERs).
De modo a garantir que os vários percursos calculados estão actualizados, consistentes com a informação
actual da rede e sem ciclos, o AOMDV mantém um número de sequência das mensagens mais recentes
recebidas do nó de destino. O AOMDV mantém o mesmo número de sequência para todos os percursos
descobertos para o mesmo destino. Quando é recebida uma mensagem de anúncio de percurso com um
número de sequência mais recente, todos os percursos mantidos para o número de sequência anterior são
eliminados. A entrada da tabela é actualizada com o percurso referente ao número de sequência mais
recente.
Para o cálculo de percursos sem ciclos, são impostas duas regras para as mensagens de anúncio e
aceitação de percurso, com o número de sequência igual ao número de sequência da entrada da tabela de
encaminhamento:
Regra do anúncio de percurso: nunca anunciar um percurso menor do que já foi anunciado.
Regra da aceitação de percurso: nunca aceitar um percurso maior do que já foi anunciado.
O protocolo AOMDV mantém vários caminhos com o mesmo número de sequência utilizando o conceito
de advertised-hop-count. Cada nó mantém uma variável chamada advertised-hop-count para cada destino.
Esta variável representa o número máximo de saltos para um determinado nó de destino, permitido pelos
nós e permanece inalterável para o mesmo número de sequência. No entanto, quando um Route Response
23
(RREP) é recebido com um número de sequência mais recente, a lista dos endereços IP dos próximos
saltos e o advertised-hop-count são actualizados [5].
Para além de manter vários percursos sem ciclos, o AOMDV visa encontrar percursos alternativos
disjuntos. Os percursos alternativos disjuntos (percursos com ligações disjuntas) revelam-se mais
tolerantes as falhas da rede quando comparados com os percursos alternativos sobrepostos. O mecanismo
proposto para garantir percursos alternativos disjuntos requer a actualização da informação do último e
do próximo salto para todos os percursos. O último salto de um caminho a partir de um nó de origem P
para um nó de destino D refere-se ao nó precedendo imediatamente o nó D neste percurso. O próximo
salto refere-se ao nó vizinho do nó P, para qual é transmitido o pacote RREQ. Para um percurso com
apenas um salto, o próximo salto é o nó D e o último salto é o nó P. Sendo assim, considera-se que dois
percursos do nó de origem P para o nó de destino D são percursos disjuntos, se possuírem a unicidade no
próximo e último salto. No entanto, para obter percursos com os nós disjuntos, a condição da unicidade no
próximo e no último salto não é suficiente. Como se pode ver na rede da Figura 2-6, apesar de existir
unicidade no próximo e no último salto nos percursos (S-A-I-X-D) e (S-B-I-Y-D), estes percursos não são
percursos com os nós disjuntos (possuem nó I em comum). Neste exemplo, para garantir percursos com
os nós disjuntos deve-se introduzir uma restrição adicional. Esta restrição implica que cada nó intermédio
deve fazer parte apenas de um percurso.
S
B
A
D
X
I
Y
RREQ
RREQRREQ
RREQ
RREQ RREQ
RREQ
RREQ
Pacote descartado.
Pacote não descartado.
Figura 2-6:Processo de descoberta de rotas – AOMDV.
O processo de descoberta de percurso é iniciado pelo nó de origem, quando este pretende enviar dados
para o nó de destino e não possui nenhum percurso disponível. O nó de origem gera o pacote RREQ e
envia-o em broadcast para a rede. Quando um nó intermédio recebe o pacote RREQ, se não tiver nenhum
percurso disponível para o nó destino, retransmite o pacote. No caso de o nó intermédio ter percurso
disponível para o nó de destino, gera o pacote RREP e responde para o nó de origem pelo percurso
inverso. O nó intermédio pode responder a vários pacotes RREQ, consoante o número de percursos
diferentes que tiver disponíveis para o nó de destino. Para cada pacote RREQ o nó intermédio responde
com o pacote RREP diferente, e quando enviar todos os percursos disponíveis e voltar a receber o pacote
RREQ, este é descartado. O nó de destino, quando recebe o pacote RREQ responde com o pacote RREP pelo
24
percurso inverso para o nó de origem. Considerando a rede da Figura 2-6, temos como o nó de origem o
nó S e o nó de destino o nó D. O nó S envia o pacote RREQ para a rede à procura do nó de destino D.
Admitindo que a cópia do pacote RREQ via o nó A chega primeiro ao nó I, como é o primeiro pacote RREQ
que ele recebe e uma vez que ainda não tem nenhum percurso para o nó de destino, retransmite o pacote
para rede. De seguida, o nó I vai receber a cópia RREQ via o nó B. Com base na informação do <ID RREQ, IP
SOURCE>, o nó I conclui que o pacote RREQ é uma duplicação, portanto, é descartado. O nó destino D
quando recebe o pacote via nó X, responde com o pacote RREP. Pouco tempo depois recebe a cópia via nó
Y, este apenas garante unicidade no último salto (nó Y é o ultimo salto, que é diferente do nó X). O próximo
salto é o nó A, que é igual à cópia do RREQ via o nó X, portanto, a cópia via nó Y é descartada pelo nó de
destino D. No final do processo temos determinados dois percursos no sentido directo (nó de origem para
o nó de destino), (S-A-I-X-D) e (S-B-I-Y-D). No sentido inverso é formado apenas um percurso (D-X-I-A-S). O
percurso (D-Y-I-B-S) não foi formado, uma vez que o seu percurso directo não verifica a condição de
unicidade no próximo salto. Este fenómeno é designado como problema de “route cutoff” e constitui uma
desvantagem do protocolo AOMDV.
2.2.3 Optimized AOMDV routing protocol (OAOMDV)
Este protocolo foi desenvolvido para resolver o problema de “route cutoff” do protocolo AOMDV. Quando
existe mais do que um nó intermédio comum nas ligações disjuntas entre o nó de origem e o nó de destino,
torna-se difícil determinar todos os percursos inversos5 existentes entre eles. Para minimizar a frequência
com que é feito o pedido de descoberta de percurso, é muito vantajoso descobrir todos os percursos
directos6 e inversos disjuntos existentes entre os nós de origem e de destino.
Se houver dois percursos disjuntos com um ou mais nós intermédios em comum entre o nó de origem e o
nó de destino, pode-se formar então dois percursos directos disjuntos e dois percursos inversos disjuntos.
Considerando a rede representada na Figura 2-7, é possível determinar dois percursos directos (S-A-C-E-
D) e (S-B-C-F-D) e dois percursos inversos (D-E-C-A-S) e (D-F-C-B-A) [3].
S
A
B
C D
E
F
RREQ
RREQRREQ(B)
RREQ(A) RREQ(A)
RREQ(A)
RREQ(A)
RREQ(A)
Detectação do RREQ
Caminho inverso
Figura 2-7:Processo de definição do percurso inverso – protocolo OAOMDV.
5 Percurso inverso – é um percurso definido desde o nó de destino até ao nó de origem. 6 Percurso directo – é um percurso definido desde o nó de origem até ao nó de destino.
25
Para que isto seja possível, o protocolo OAOMDV implementa um mecanismo de funcionamento diferente
do protocolo AOMDV. O pacote RREQ é utilizado para determinar o percurso inverso, o pacote RREP é
utilizado para determinar o percurso directo e o pacote Route Reply Acknowledgement (RREP_ACK) é
utilizado para resolver o problema de “route cutoff”. O processo de descoberta do percurso directo inicia-
se quando um nó de origem tiver que enviar dados para um determinado nó de destino e não tiver
percurso disponível. O nó de origem envia o pacote RREQ em broadcast para rede. Quando um nó vizinho
do nó de origem receber o pacote RREQ guarda o seu endereço IP no campo “Last hop” do pacote RREQ,
para poder identificar os percursos disjuntos inversos, e de seguida retransmite o pacote para a rede.
TYPE
ACK
Last Hop
Hop Count
Destination IP Address
Destination Sequence Number
Originator IP Address
Lifetime
Figura 2-8: Formato do pacote RREQ do OAOMDV.
Os nós intermédios quando recebem o pacote RREQ, se tiverem um percurso disponível para o nó de
destino, geram um pacote RREP e encaminham-o para o nó de origem. Caso os nós intermédios não
tenham nenhum percurso disponível para o nó de destino, então processam o pacote RREQ. Se for o
primeiro pacote RREQ recebido do nó origem, então actualizam a entrada da sua tabela de
encaminhamento com as informações do pacote RREQ e depois transmitem-no para rede. A Tabela 2-1 e a
Tabela 2-2 ilustram alguns dos campos da entrada da tabela de encaminhamento e da lista de percursos,
que são actualizadas com informações do pacote RREQ.
Tabela 2-1: Entrada da tabela de encaminhamento do protocolo OAOMDV.
Destination
Sequence Number
Advertised hop count
Route List
Tabela 2-2: Estrutura da Lista de percursos do protocolo OAOMDV.
Hop_count1
Next_Hop1
Last_Hop1
Expiration_timeout1
Hop_count2
Hop_count2
Last_Hop1
Expiration_timeout2
Caso não seja o primeiro pacote RREQ, então este é processado consoante a informação disponível nos
campos “Last hop” e “hop-count”. O nó intermédio apenas aceita RREQ com diferentes valores de “Last
hop” e com “hop-count” inferior ao advertisid-hop-count mantido na entrada da tabela de encaminhamento
para o destino do RREQ. O nó de destino quando recebe o pacote RREQ pela primeira vez, actualiza a
26
entrada da sua tabela de encaminhamento e gera o pacote RREP para enviar para o nó de origem. Para
salvaguardar a situação de “route cutoff”, o valor do campo “Last hop” do pacote RREQ é copiado para o
campo ACK do pacote RREP. O percurso directo é definido à medida que o nó de destino envia o pacote
RREP para o nó de origem. O vizinho do nó de destino quando recebe o pacote RREP, adiciona o seu
próprio endereço no campo “Last hop” para poder identificar múltiplos percursos disjuntos directos para
o nó de destino. Quando o nó de origem receber o pacote RREP, ficam definidos os percursos directos e
inversos. Para resolver o problema de “route cutoff” ou do percurso omitido, este protocolo criou um novo
pacote de encaminhamento designado por Route Reply Acknowledgement (RREP_ACK).
A Figura 2-9 mostra os campos do pacote RREP_ACK. O campo “LAST RPHOP” contém o endereço IP do nó
vizinho do nó de origem e o campo “LAST FPHOP” contêm o endereço IP do nó vizinho do nó de destino.
TYEPE ORIGINATOR SEQUENCE NUMBERORIGINATOR IP ADDRESSDESTINATIO IP ADDRESSLAST FPHOPLAST RPHOP
Figura 2-9: Formato da mensagem RREP_ACK do protocolo OAOMDV
Para ilustrar melhor como o protocolo resolve o problema do “route cutoff”, considera-se o exemplo da
rede da Figura 2-10. Assumindo que o nó S é o nó de origem e o nó D é o nó de destino e o pacote RREQ
com o “Last hop” X é designado por RREQ (X). O nó S irá fazer o broadcast do pacote RREQ para a rede.
Quando o nó A e B recebem o pacote RREQ, estes adicionam os seus próprios endereços no campo “Last
hop” dos seus respectivos pacotes. O nó A faz broadcast do RREQ (A) e nó B faz broadcast de RREQ (B).
Depois de o nó C receber o RREQ (A) e RREQ (B), são formadas duas ligações disjuntas inversas (C-A-S) e
(C-B-S). O nó C irá enviar em broadcast o RREQ (A) caso não tenha nenhum percurso disponível para o nó
de destino, caso contrário responde com o pacote RREP para o nó S. Quando o nó E e F recebem o pacote
RREQ (A), estes formam respectivamente os caminhos inversos (E-C-A-S) e (F-C-A-S). Por último o nó de
destino D recebe sucessivamente RREQ (A) de E e F. Se D receber primeiro RREQ (A) de E, é definido o
percurso inverso (D-E-C-A-S). Quando ele recebe o segundo RREQ (A) de F, na qual tem o mesmo “Last
hop” não é formado o percurso inverso (D-F-C-A-S).
S
A
B
C D
E
F
RREP (E)
RREP (E)
RREP (E)
RREP (E)
RREP (F)
RREP (F)
RREP (F)
RREP (F)
Direção do RREQ
Percurso directo
Figura 2-10:Processo de definição de percurso directo - protocolo OAOMDV.
27
O nó de destino D responde para E com o pacote RREP, depois de ter copiado o “Last hop” do RREQ (A)
para dentro do campo “ACK” do pacote RREP (ACK =A). Quando o nó E receber o RREP, irá adicionar o seu
endereço no campo “Last hop” do pacote RREP para identificar o percurso disjunto no sentido directo de
transmissão. É formado o percurso directo (E-D) e o nó E retransmite o RREP (E) para o próximo “next-
hop”. Como o caminho inverso (D-E-C-A-S) via E já esta bem definido, então o”next-hop1” é o nó C. O nó C
irá formar o percurso (C-E-D) e transmitir o pacote RREP (E) para seus próximos nós (“next-hop1 = A” ou
next-hop2=”B”). Por último quando o nó origem S receber RREP (E), será formado o percurso directo (S-A-
C-E-D). O nó D irá receber RREQ (A) do nó F pouco tempo depois e responde para F com um RREP. O
campo ACK do pacote RREP é definido com o valor do “Last hop” do pacote RREQ (A). O Nó F conhece o
percurso para o nó de origem S gerado pelo pacote RREQ durante o processo de descoberta, portanto,
considera como o “next-hop1” o nó C. Quando o nó C receber o RREP (F), define-se o percurso directo (C-F-
D) e depois procura o próximo salto para de origem S. O Nó C tem duas ligações disjuntas no percurso
inverso (C-A-S) e (C-B-S) uma das quais já tinha sido utilizado para transmitir o RREP (E).
Consequentemente, irá transmitir o pacote para o percurso via o nó B. Finalmente um outro percurso
directo (S-B-C-F-D) irá ser considerado pelo nó de origem S, uma vez que o “Last hop” de RREP (F) é
diferente de RREP (E).
S
A
B
C D
E
F
Direção do RREQ
Percurso directo
Percurso inverso
RREP_ACK
RREP_ACK
RREP_ACK
RREP_ACK
Figura 2-11:Processo de definição do percurso omitido - protocolo OAOMDV.
Na Figura 2-11, quando o nó origem S receber o primeiro pacote RREP (E) do seu vizinho A, ele irá
comparar o salto anterior do pacote RREP (E) com o valor do campo “ACK” do pacote RREP (E). Como o
salto anterior e o valor do campo “ACK” é o mesmo igual ao nó A, então o caminho inverso (D-E-C-A-S) ao
longo do caminho directo (S-A-C-E-D) foi determinado com sucesso. Quando o nó origem S receber o
segundo RREP (F), conclui que eles são de nós diferentes, o salto anterior é o nó B e o do campo “ACK” do
pacote RREP (F) é o nó A. Isto significa que o caminho inverso ao longo do caminho directo (S-B-C-F-D)
definido por RREP (F) está escondido. O nó origem S irá gerar um RREP_ACK para o destino D ao longo do
caminho directo para formar o caminho inverso. O campo “Last rphop” é o nó B e o “Last fphop” é o nó F.
Quando o nó B receber o RREP_ACK, um caminho inverso (B-S) irá ser definido. Quando nó C receber o
RREP_ACK, um caminho inverso (C-B-S) irá ser definido. Por último o caminho inverso (D-F-C-B-S) irá ser
28
definido pelo destino D. O RREP_ACK não é só para definir o caminho omitido, mas também confirma a
O protocolo Mobility Prediction Ad-hoc on-demand multipath distance vector (MP-AOMDV) é uma extensão
do protocolo AOMDV. O protocolo faz a predição da mobilidade com base na estabilidade geral dos
percursos, baseando na intensidade relativa do sinal das ligações ao longo destes percursos. Com base
nessas predições os vários caminhos são classificados com diferentes prioridades, de modo a ser utilizado
sempre o melhor caminho para o envio de dados. É utilizado como métrica a intensidade do sinal das suas
ligações em vez da contagem de saltos, uma vez que este é insuficiente para determinar a qualidade e
estabilidade de um percurso. Uma ligação com intensidade de sinal muito fraco, mesmo que tenha um
baixo número de salto, pode levar a perdas de muitos pacotes. Estudos realizados mostram que a métrica
da intensidade do sinal é mais eficiente do que a métrica de contagem de número de saltos [4]. Tendo em
consideração a característica dinâmica das redes MANET e a mobilidade dos terminais que provoca falhas
constantes na comunicação, foram proposta duas versões do protocolo MP-AOMDV:
Node-Disjoint MP-AOMDV
Link-Disjoint MP-AOMDV
O nó disjunto é uma versão mais restrita do que a versão de ligação disjunta, portanto, o número de
percursos alternativos descoberto é menor em relação à versão com ligações disjuntas. Uma vez que os
nós disjuntos determinam percursos completamente independentes, a falha de um percurso não tem
qualquer impacto sobre os restantes. Em alguns cenários, a versão com ligações disjuntas revela-se mais
útil do que a versão com os nós disjuntos, uma vez que determina um maior número de percursos
alternativos. A seguir explica-se cada uma das versões [4]:
Node - Disjoint MP-AOMDV
O propósito para determinar percursos alternativos entre o nó de origem e o nó de destino, é para que
quando o percurso principal falhar devido ao movimento do nó, um dos percursos alternativos possa ser
escolhido como próximo percurso principal para enviar pacotes, sem dar inicio a um novo processo de
descoberta de percursos. Uma forma de aumentar a probabilidade de os percursos alternativos serem
válidos depois de o percurso principal falhar é garantir que eles não têm nenhum nó e nem ligação em
comum. Para que isto seja possível, o protocolo MP-AOMDV implementou um mecanismo que calcula
vários percursos alternativos com os nós disjuntos. O pacote RREQ foi modificado de modo a transportar o
endereço IP do nó imediatamente a seguir ao nó de origem, para qual foi transmitido o pacote RREQ. O nó
destino usa esta informação para poder responder apenas a RREQs vindos de diferentes nós vizinhos do
nó de origem. Uma vez que cada nó intermédio envia apenas o primeiro pacote RREQ para o destino, cada
RREQ viaja ao longo de um percurso único desde nó de origem até o nó de destino. Desta forma, quando o
29
nó de destino responder com o RREP aos vizinhos diferentes do nó de origem, estes RREP chegam ao nó
de origem através de percursos de nós disjuntos. Para assegurar que os vários percursos alternativos
estão consistentes com as mudanças da topologia da rede, o nó de origem envia periodicamente uma
mensagem de actualização, designada por heartbeat para o nó de destino ao longo dos percursos
alternativos. Como o pacote heartbeat se propaga através dos percursos alternativos, cada nó ao longo do
percurso actualiza o pacote com a métrica mobility prediction (MP). O MP é uma medida relativa da
intensidade do sinal, com o qual um determinado nó recebe um pacote do seu vizinho e é dado por:
,
Onde é a potência do sinal do nó A que é recebido no nó B e é potência mínima com o qual o sinal
deve ser recebido para que a transmissão seja considerada como válida. O nó de origem inicializa o MP da
mensagem heartbeat com o valor 1 e encaminha-o para o nó de destino através dos percursos
descobertos. Os nós intermédios multiplicam o seu MP pelo valor contido em heartbeat. O nó destino
envia em unicast para a origem o pacote heartbeat depois de ter inicializado a 1. Com este procedimento,
todos os nós obtêm a informação sobre a qualidade da ligação bidireccional.
Os pacotes RREQs e RREPs foram modificados de forma a transportar o valor do MP durante o processo
de descoberta. O nó de origem determina vários percursos, e ordena-os numa lista de prioridade por
ordem decrescente do valor de MP. O percurso que possui maior valor de MP é considerado como
percurso principal. Quando a intensidade do sinal do percurso principal diminuir antes de o percurso
falhar, é alterado para um percurso alternativo com maior estabilidade. Poucos pacotes são perdidos e o
atraso da comunicação é minimizado.
Para a prevenção da oscilação na mudança de percurso entre principal e o alternativo é adoptado um
mecanismo, em que nó de origem altera o seu percurso principal para um percurso alternativo, se a
diferença entre a estabilidade do percurso alternativo em relação ao percurso principal for maior do que
um valor limiar de estabilidade pré-definido.
S
B
A
D
F
E
G
C H
RREQ (0.2)
RREQ (0.15)
RREQ (0.05)
RREQ (0.15)
RREQ (0.2)
RREQ (0.1)
RREQ (0.2)
RREQ (0.2)
RREQ (0.05)
RREQ (0.1)
RREQ (0.15)
Pacote descartado
Pacote transmitido
Figura 2-12:Processo de cálculo de nós disjuntos MP-AOMDV.
30
Consideremos a rede da Figura 2-12 para ilustrar o funcionamento da versão de nós disjuntos do
protocolo MP-AOMDV. O nó S é o nó de origem e o nó D é o nó de destino. O nó S inicia o processo de
descoberta enviando o pacote RREQ para rede. O nó A e B retransmitem o RREQ para o nó E. Neste
exemplo, vamos assumir que o nó E, recebe primeiro o RREQ do nó A e depois recebe do nó B. O nó E
retransmite o RREQ recebido do nó A para suas ligações de saída e descarta o pacote RREQ recebida do nó
B. O nó G e F retransmite o RREQ para o nó de destino D. Semelhantemente, o nó C envia o RREQ para o nó
de destino via nó H. O nó D envia o pacote RREP para o nó F e H e descarta o RREQ via nó G, uma vez que o
RREQ de G foi originado pelo mesmo vizinho que originou o RREQ via nó F. O nó destino apenas aceita
RREQ com diferentes nós vizinhos do nó de origem. Neste exemplo foram determinados pelo nó de origem
dois percursos de nós disjuntos para o nó de destino (S-C-H-D) e (S-A-E-F-D).
Link-Disjoint MP-AOMDV
Nesta versão é permitido que os percursos tenham nós em comum, mas as ligações devem ser únicas. Uma
vez que tem menos limitações do que a versão nós disjuntos, consegue-se obter mais percursos
alternativos. Para calcular os percursos com ligações disjuntas, esta versão baseia-se numa versão do
AOMDV modificada. Deste modo, cada nó apenas retransmite o primeiro RREQ para o nó de destino
durante o processo de descoberta. No entanto mantém uma lista de próximos saltos para cada RREQ
originado por vizinhos diferentes do nó origem. Tal como em node-disjoint MP-AOMDV, o RREQ contém
um campo indicando o primeiro vizinho do nó de origem através do qual o RREQ foi enviado. O nó destino
envia RREPs para cada nó antecessor único através do qual recebeu o RREQ. Quando um nó intermédio
receber o RREP, retransmite-o para o next-hop guardado no topo da sua fila de “next-hop” e depois remove
este nó da fila. Este esquema de retransmissão é repetido pelos restantes nós intermédios. Quando a fila
next-hop ficar vazia, todos os RREP recebidos são descartados. Quando temos um número de ligações
desiguais upstream e downstream, o excesso de ligações não utilizadas no encaminhamento expira por
timeout. Cada nó intermédio mantém um mapeamento de um para um entre os vizinhos de upstream7 e
downstream8. Como o nó de destino envia RREP para seus diferentes nós vizinhos, e os RREPs são
transmitidos pelos diferentes “next-hop” pelos nós intermédios, todos os percursos obtidos pelo nó de
origem são ligações disjuntas. Para a manutenção dos percursos alternativos, assim como no caso de node-
disjoint MP-AOMDV, a mensagem heartbeat é enviada periodicamente ao longo dos percursos alternativos.
Cada nó usa o mapeamento entre os nós upstream e downstream para encaminhar as mensagens
heartbeat. A mensagem de heartbeat acumula a informação da intensidade do sinal em ambos os sentidos:
para o destino e para o nó de origem. Este valor acumulado de MP é utilizado pelos nós intermédios,
origem e o nó de destino para ordenar seus respectivos percursos alternativos em ordem decrescente do
valor de MP.
Para ilustrar o exemplo de cálculo de percursos com ligação disjunta, considera-se a rede da Figura 2-12.
Tal como no caso de percurso de nós disjuntos, o nó E recebe primeiro o RREQ do nó A e depois recebe do
7 Upstream - é a ligação com o sentido directo da comunicação, ou seja, do nó de origem para o nó de destino. 8 Downstream - é a ligação com o sentido inverso da comunicação, ou seja, do nó de destino para o nó de origem.
31
nó B. O nó E transmite o RREQ recebido do nó A para as suas ligações de saída. O RREQ recebido do nó B
não é retransmitido, mas é inserido na lista de “next-hop” para o nó de origem. O nó destino recebe o RREQ
dos nós G, F e H. O nó destino envia RREP para cada um dos vizinhos distintos. O nó E recebe o RREP dos
nós F e G, depois encaminha o RREP do nó F para o nó A, e o do nó G para o nó B. O nó E procede desta
forma devido ao mapeamento entre a lista de “next-hop” e da lista de “previous-hop” criadas durante o
processo de descoberta. Da mesma forma um RREP é encaminhado através do percurso (D-H-C-S). O nó de
origem obtém três percursos com ligações disjuntas para o destino D e são (S-C-H-D), (S-A-E-F-D) e (S-B-E-
G-D).
2.2.5 New Multipath Node-Disjoint routing based on AODV protocol (NMN –
AODV)
Este protocolo resulta de algumas alterações que foram realizadas ao protocolo AODV para poder
determinar vários percursos. O protocolo NMN-AODV utiliza múltiplos percursos de nós disjuntos para
minimizar o atraso da comunicação extremo-a-extremo e balancear a carga pela rede. Através de três
pacotes de controlo determina dois percursos de nós disjuntos entre o nó de origem e o nó de destino. Da
mesma forma, assim como o protocolo MP-AODV, foi adicionado um nova flag F de 1 bit aos pacotes RREQ
e RREP. Quando o nó intermédio recebe o pacote RREQ, guarda o ID RREQ do nó origem e o valor da flag
“F” na tabela de encaminhamento. No protocolo AODV, quando um nó receber o pacote verifica o par
<SOURCE IP, RREQ ID> do pacote RREQ e compara com a informação contida na tabela de
encaminhamento para decidir se retransmite o pacote ou não. O protocolo NMN-AODV faz o
processamento do pacote RREQ e distingue o percurso principal do percurso alternativo com base no
valor da flag F.
Inicia-se o processo de descoberta de percursos quando um determinado nó pretende transmitir dados
para o nó de destino e não possui percursos disponíveis na tabela de encaminhamento. Envia-se para a
rede em broadcast o pacote RREQ, com a flag F inicializado com o valor zero, para poder calcular o
percurso principal. Os nós intermédios, quando receberem o pacote RREQ com a flag F igual a zero, fazem
o procedimento igual ao do protocolo AODV convencional.
Quando o nó de destino receber o pacote RREQ (F=0), responde com o pacote RREP (F=0) para o nó de
origem, e depois de passar o tempo de NET_TRAVERSAL_TIME milissegundos envia o RREQ (F=1). Para
poder definir o percurso alternativo do percurso principal, é definida a flag D, de modo a garantir que o
pacote RREQ será recebido pelo nó destino pretendido. Quando o nó de origem receber o RREP (F=0), o
percurso principal é formado e inicia-se a transmissão. Quando receber o pacote RREQ (F=1), o percurso
alternativo é formado e inicia-se a transmissão com “piggybacking” RREP (F=1) neste caminho alternativo
e simultaneamente enviando dados no percurso principal. O nó de destino, quando receber o pacote RREP
(F=1) descarta-o. Quando um nó intermédio receber o pacote RREQ (F=1), compara <SOURCE IP,
Destination IP> do pacote RREQ com o par <Destination IP, SOURCE IP> contido na sua tabela de
encaminhamento. Caso seja igual, tratando-se de um nó que pertence ao percurso principal, o pacote é
32
descartado, caso contrário o pacote é encaminhando segundo o procedimento do protocolo AODV
convencional [14].
2.2.6 Multipath Optimized Link State Routing Protocol (MP-OLSR)
O protocolo MP-OLSR resulta da alteração ao protocolo clássico OLSR para o cálculo de vários percursos
entre o nó de origem e o nó de destino. Assim como o OLSR clássico, o MP-OLSR envia as mensagens de
hello e TC periodicamente para estar ciente das mudanças de topologia da rede. No entanto, o MP-OLSR
não mantém sempre a tabela de encaminhamento: ele só calcula os percursos quando um nó precisa
enviar pacotes. O funcionamento do protocolo MP-OLSR baseia-se em dois mecanismos essenciais de
funcionamento: Monitorização da topologia (Topology Sensing) e cálculo de rotas (routes computation)
[15].
A monitorização da topologia faz com que os nós obtenham a informação sobre a topologia da rede, o que
inclui a monitorização da ligação (link sensing), detecção de vizinhos (neighbor detection) e descoberta de
topologia (topology discovery). A descoberta de topologia beneficia dos MPRs tal como no OLSR [ver 2.1.4],
para minimizar a inundação dos pacotes de broadcast na rede através da redução de retransmissão de
pacotes duplicados na mesma região. Para o cálculo dos percursos utiliza-se o Multipath Dijkstra
Algorithm (MDA) para preencher os múltiplos percursos com base nas informações obtidas a partir da
monitorização da topologia. Uma das várias alterações que foram realizados ao OLSR para o
encaminhamento multi-percurso, é que as mensagens de TC não incluem apenas as ligações entre o nó
local e o MRP, mas contêm também as ligações para todos os vizinhos, de maneira que cada nó possa ter
mais informação sobre a topologia da rede, podendo deste modo construir facilmente múltiplos percursos
disjuntos. Para efeitos de simulação, ele apresenta um bom desempenho quando se tem uma carga baixa.
Mas em cenário em que há carga elevada, ele vai causar mais congestionamento, porque este método irá
aumentar o tamanho da mensagem de TC. No entanto, com a mensagem que combina o mecanismo em
OLSRv2 este problema pode ser aliviado [16].
33
Figura 2-13:O algoritmo Dijkstra de multi-percuros. [fonte: [15]]
Contrariamente do OLSR clássico, os percursos não são actualizados cada vez que um determinado nó
recebe uma mensagem nova de encaminhamento. Eles são actualizados através do envio das mensagens
On-demand, a fim de evitar o cálculo dos vários percursos para cada destino possível. Quando um
determinado nó tiver que enviar pacotes, inicia-se o procedimento de cálculo de percursos como se
descreve no algorítmico seguinte: O princípio geral do algoritmo é, numa etapa i, procurar o caminho Pi
mais curto para o nó de destino d. Em seguida aumentar o custo da aresta de Pi e das arestas apontado
para Pi, a fim de evitar que os próximos passos utilizem caminhos idênticos. O fp é usado para aumentar o
custo das arestas que pertencem ao caminho antecessor ao Pi (ou arestas que pertencem a caminho
oposto a Pi). Isto incentiva os caminhos futuros a usarem arestas diferentes, para atingir os mesmos
vértices (nós). O fe é utilizado para aumentar o custo das arestas que unem caminhos a vértices (nós) do
percurso anterior a Pi. Pode-se escolher diferentes valores de fe e fp para obter percursos com ligações
disjuntas ou percursos com os nós disjuntos conforme o necessário. A Figura 2-14 ilustra o número de
percursos diferentes calculados pelo algoritmo Dijkstra num cenário de 300 nós.
Figura 2-14: Algoritmo Dijkstra com fp (c) = fe (c) = 2c. Na primeira figura foram calculados 3 percursos e
na segunda figura foram calculadas 10 percursos [fonte: [15]].
34
Quanto ao processo de descoberta de percurso, no OLSR clássico é utilizado o encaminhamento salto-a-
salto, o que significa que quando um pacote chega a um nó intermédio, o protocolo verifica a tabela de
encaminhamento do nó local, e em seguida encaminha o pacote para o próximo salto (nó). Em contraste,
no MP-OLSR os nós intermédios ajudam o nó de origem a manter um bom controlo dos pacotes que serão
encaminhados nos múltiplos percursos. A curto prazo, o encaminhamento de origem puro pode causar
dois problemas: Em primeiro lugar, a informação no nó de origem pode não ser suficientemente actual,
pois precisa de tempo para inundar as mensagens de controlo de topologia para toda rede. O que significa
que quando o nó determina o percurso, pode utilizar ligações que já não existem ou estão obsoletas. Em
segundo lugar, mesmo quando a informação no nó de origem está actualizada, a topologia da rede pode
alterar-se durante o encaminhamento do pacote. Ambos os problemas causam falha de encaminhamento
de pacotes.
Para resolver o problema, cada nó intermédio antes de encaminhar o pacote para o próximo nó de acordo
com o percurso enviado pelo nó de origem, verifica primeiro se próximo nó é um dos seus vizinhos. Em
caso afirmativo, o pacote é transmitido. Caso contrário, é possível que o próximo nó se tenha
movimentado para fora do intervalo de transmissão, portanto, o nó intermédio recalcula o percurso e
envia o pacote através de um novo percurso. Na Figura o nó de origem A possui dois percursos para o nó
de destino D, (A-B-C-D e A-E-F-G-D). Quando é enviado um pacote via o nó E, este antes de o encaminhar
para o próximo nó indicado no percurso mantido pelo nó de origem, verifica primeiro se é o seu vizinho.
Neste exemplo o nó E encaminha o pacote para o nó F, uma vez que é seu vizinho. O nó F quando recebe o
pacote, com base no percurso mantido pelo nó de origem, vai verificar se o nó G é seu vizinho, mas como
este esta fora da sua zona de cobertura conclui que não é seu vizinho. O nó F recalcula o percurso e envia o
pacote para o destino D via o nó H.
A
B C
E F
D
H
G
Figura 2-15: processo de descoberta de rota pelo nó F.
2.2.7 Considerações finais e conclusão
Neste subcapítulo [2.2], foram estudados alguns dos principais protocolos com encaminhamento multi-
percurso, utilizados nas redes MANET. Estes protocolos resultaram de alterações, realizadas aos
protocolos de encaminhamento com percurso único. Os protocolos MP-OLSR, MOLSR e QOLSR são
protocolos pró-activos com encaminhamento multi-percurso e têm como protocolo de base o protocolo
OLSR. O protocolo MOLSR determina múltiplos percursos, apesar de utilizar um percurso em cada
momento, tendo como vantagem a ausência do problema de acoplamento de percursos (percursos
sobrepostos) [1]. O protocolo QOLSR procura percursos que consigam satisfazer um conjunto de
requisitos de largura de banda e de latência [17]. Estes protocolos possuem o núcleo de funcionamento
35
comum, que permite descobrir a topologia da rede. As desvantagens dos protocolos pró-activos resultam
do elevado custo de distribuição dos anúncios. Mesmo quando se utilizam mecanismos (por exemplo,
recorrendo a multipoint relays) para mitigar estes custos, uma vez que todos os nós necessitam de
difundir anúncios, estes protocolos incorrem em elevados custos de sinalização, em particular nas redes
densas. Uma outra desvantagem destes protocolos consiste no encaminhamento realizado com base nos
percursos armazenados no nó de origem. No presente trabalho apenas foi abordado o protocolo MP-OLSR,
dado que este é o que melhor resolve os problemas mencionados. O protocolo MP-OLSR determina vários
percursos que podem ser disjuntos em termos de nós ou de ligação, de acordo com várias funções de
custos. Embora o MP-OLSR realize o encaminhamento com base nos percursos armazenados no nó de
origem, ele proporciona uma melhoria neste procedimento, uma vez que os nós intermédios fazem
confirmação do percurso mantido pelo nó de origem, antes de encaminhar os pacotes para o nó de
destino.
Foram abordados também neste trabalho vários protocolos reactivos com encaminhamento multi-
percurso mais utilizados nas redes MANET. Dado que o protocolo implementado neste trabalho é um
protocolo reactivo com encaminhamento multi-percurso, deu-se mais ênfase a estes tipos de protocolos.
Os protocolos AOMDV e NMN-AODV tiveram como base o protocolo AODV, enquanto que o protocolo
OAOMDV e MP-AOMDV resultaram de algumas melhorias implementadas ao protocolo AOMDV. Estes
protocolos foram desenvolvidos para calcular vários percursos entre os nós de origem e de destino,
diferenciam-se um dos outros no modo de funcionamento. Alguns determinam os vários percursos a custo
da introdução de novas mensagens de sinalização, o que se verifica para o caso do protocolo OAOMDV
(RREP_ACK) e MP-AOMDV (heartbeat). O protocolo NMN-AODV e o AOMDV apenas introduzem novos
campos adicionais para poderem determinar os vários percursos. O protocolo MP-AOMDV apresenta
algumas características particulares, dado que utiliza como métrica para calcular os vários percursos a
intensidade do sinal, enquanto que os outros protocolos utilizam como métrica o valor de hop-count.
Alguns estudos demonstram que a métrica da intensidade do sinal é melhor, uma vez que o hop-count não
concede nenhuma informação sobre a qualidade de ligação dos percursos. O MP-AOMDV considera um
determinado percurso como óptimo, se a soma da intensidade das suas ligações for maior do que os
restantes. A intensidade do sinal é dimensionada com base na potência do sinal recebida de um
determinado nó. O MP-AOMDV faz a manutenção dos percursos alternativos extremo-a-extremo, através
do envio periódico da mensagem heartbeat desde o nó de origem até o nó de destino.
Os outros protocolos mencionados fazem a manutenção dos vários percursos alternativos através da
monitorização das ligações locais entre os nós vizinhos. Os nós que fazem parte do percurso activo enviam
entre si periodicamente a mensagem hello. Este procedimento é mais eficaz do que a manutenção
extremo-a-extremo, uma vez que quando houver uma falha de ligação é detectada de imediato. A
manutenção extremo-a-extremo é desvantajosa, uma vez que a informação sobre a qualidade do percurso
quando é recebida pelo nó de destino/origem, pode suceder que o mesmo percurso já esteja inválido.
36
Existem outros protocolos com encaminhamento multi-percurso interessantes que neste trabalho não
foram abordados, uma vez que não se enquadram dentro do âmbito deste trabalho. Como exemplo,
podemos mencionar a seguinte lista:
Multipath and MPR based AODV routing protocol (MMDV), [18];
O pacote RREP_ACK também não foi alterado. É utilizado por um determinado nó quando receber um
pacote RREP que carece de uma confirmação. Então o nó receptor do pacote RREP envia o pacote
RREP_ACK, para confirmar a recepção do pacote RREP. Na Figura 3-4 estão ilustrados os campos do
pacote RREP_ACK.
TYPE
Reserved
Figura 3-4: Formato do pacote Route Reply Acknowledgement - RREP_ACK.
3.2 Estuturas de dados
Várias estruturas de dados foram utilizadas para armazenar as informações processadas pelo protocolo,
entre as quais se destacam:
Tabela de encaminhamento
Tabela de vizinhos processados
Tabela de RREQ pendentes
Lista de próximos saltos
Tabela de contador de percurso (ver subsecção 3.3)
Todos os nós da rede possuem uma tabela de encaminhamento, e esta por sua vez pode ter ou não varias
entradas, consoante o número de pedidos (de percursos) recebidos para diferentes nós de destinos. A
título ilustrativo, considera-se um exemplo em que um determinado nó possui três percursos para
diferentes nós de destino (D1,D2 e D3). Neste caso a sua tabela de encaminhamento deve ter três entradas,
tal como ilustrado na Figura 3-5. Se um determinado nó possuir vários percursos para o mesmo nó de
destino, então a sua tabela de encaminhamento será composta por uma entrada referente ao nó de destino
e uma lista de próximos saltos.
Destination D1
Routing Table Entry 1
Destination D2
Routing Table Entry 2
Destination D3
Routing Table Entry 3
Figura 3-5: Formato da tabela de encaminhamento.
A Figura 3-6 ilustra os principais campos das entradas da tabela de encaminhamento.
41
NetDevice Ipv4InterfaceAddress Destination Sequence Number Source LNHRounteCountLive time Max Num Routes
Figura 3-6:Formato da entrada da tabela de encaminhamento.
Na Figura 3-7 está ilustrado o formato da lista de próximos saltos. Neste exemplo foi considerado uma
lista com três endereços de próximos saltos. O número de elementos da lista é limitado pelo valor do
campo Max Num Routes do pacote RREQ.
Hop Count 1Next Hop 1 Flag Status 1
Hop Count 2Next Hop 2 Flag Status 2
Hop Count nNext Hop n Flag Status n
Figura 3-7:Formato da lista de próximos saltos.
Os campos da lista de próximos saltos do exemplo ilustrado na Figura 3-7, são interpretados do seguinte
modo:
Next Hop: é o endereço IP do próximo salto.
Flag Status: é uma flag que indica o estado do percurso. Temos dois tipos de estados para
classificar um determinado percurso. A flag VALID significa que o percurso pode ser utilizado
para enviar dados. A flag INVALID significa que o percurso não pode ser utilizado para enviar
dados.
Hop Count: é o número de saltos a percorrer até chegar ao nó de destino.
A tabela de vizinhos processados consiste num mapeamento entre os endereços IP dos nós de origem e
estruturas de dados do tipo RREQData. Para cada RREQ recebido do nó de origem com diferentes vizinhos
a dois saltos do nó de destino, é estabelecido um mapeamento na tabela de vizinhos processados entre o
endereço IP do nó de origem com o RREQData. A Figura 3-8 ilustra um exemplo de uma tabela de vizinhos
processados referente ao nó de origem (Source 1), em que foram processados três RREQ com diferentes
nós vizinhos do nó que enviou o pacote RREQ para o nó de destino. Para o segundo nó de origem (Source
2), também foram processados três RREQ com diferentes nós vizinhos a dois saltos do nó de destino. O
índice n é dimensionado pelo valor do campo Max Num Routes da entrada da tabela de encaminhamento.
42
IP neighbor two hop 1
ID RREQ 1
IP neighbor two hop 2
ID RREQ 1
IP neighbor two hop n
ID RREQ 1
IP neighbor two hop 1
ID RREQ 2
IP neighbor two hop 2
ID RREQ 2
IP neighbor two hop n
ID RREQ 2
Source 1
Source 2
Figura 3-8:Formato da tabela de vizinhos processados.
A tabela de RREQ pendentes consiste também num mapeamento entre os endereços IP dos nós de origem
e as estruturas de dados do tipo RREQData. Para cada endereço IP do nó de origem apenas existe uma
entrada na tabela de RREQ pendentes. Isto deve-se ao facto de que os nós intermédios apenas processam
o primeiro RREQ e os restantes são descartados.
No exemplo da Figura 3-9 os campos da tabela têm o seguinte significado:
IP key Source: endereço IP do nó de origem que enviou o pacote RREQ.
IP next-previous: endereço IP do nó a partir do qual foi recebido o pacote RREQ. É para este
endereço IP que é enviado o pacote RREP para o nó de origem.
ID RREQ: identificador de cada pedido de aquisição de percurso.
IP Key Source 1
IP next – previous 1
ID RREQ 1
IP Key Source 2
IP next-previous 2
ID RREQ 2
IP Key Source 3
IP next – previous 3
ID RREQ 3
Figura 3-9:Formato da tabela de RREQ Pendentes.
3.3 Gestão de múltiplos percursos
A gestão do número de percursos a calcular entre os nós de origem e de destino durante o processo de
descoberta, tem impacto sobre a carga rede. Ao definir um número limitado de percursos a calcular,
diminui-se o número de pacotes de sinalização enviados para a rede, maximizando deste modo o tempo de
vida das baterias dos dispositivos, largura de banda e minimizando a sobrecarga da rede. Neste protocolo,
é definido um parâmetro que determina o número máximo de percursos entre o nó de origem e o nó de
43
destino e este é configurado manualmente pelo administrador da rede. Para assegurar que os dados são
enviados de forma balanceada pelos vários percursos determinados durante o processo de aquisição, o
protocolo dispõe de uma tabela de contador de percursos para variar a escolha de percurso para enviar os
pacotes. Esta tabela de contador de percursos é utilizada pelo nó de origem de forma a escolher percursos
diferentes para enviar dados para o nó de destino.
Destination D1
Counter Route For Destination D1
Destination D2
Counter Route For Destination D2
Destination D3
Counter Route For Destination D3
Figura 3-10:Tabela de Contador de percurso para o nó de destino.
Cada nó possui uma tabela de contador de percursos com zero ou mais entradas, consoante o número de
nós de destino para os quais o nó envia pacotes. Inicialmente o contador de percursos é inicializado a zero,
portanto, são enviados dados para o nó de destino, utilizando o endereço IP no início da lista de próximos
saltos. Depois de enviar o pacote, o contador de percurso é incrementado. Quando o valor de contador de
percursos for maior ou igual ao número de percursos na lista de próximos saltos, este é reinicializado a
zero. Para o exemplo da Figura 3-10, o nó possui uma tabela de contador de percurso com três entradas
para três nós de destino diferentes (D1,D2 e D3).
3.4 Manutenção dos percursos
Para a manutenção dos percursos alternativos, o protocolo utiliza dois mecanismos de manutenção:
Envio periódico da mensagem hello.
Envio da mensagem RREP_ACK.
O primeiro mecanismo consiste no envio periódico da mensagem hello. Esta mensagem só pode ser
enviada pelos nós vizinhos que fazem parte dos percursos activos, com o objectivo de actualizar o tempo
de vida e a validade das ligações locais. Como esta mensagem é enviada de forma periódica, se não for
recebida durante um período de tempo configurado, admite-se que houve uma quebra da ligação. Segue-
se então o procedimento de manutenção de percursos, em que é enviada a mensagem RRER para todos os
nós afectados. Os nós ao receberem a mensagem RRER, eliminam o percurso afectado na lista de próximos
saltos. Se este era o último percurso para enviar dados ao nó de destino, então elimina-se a entrada da
tabela de encaminhamento para o nó de destino em causa. O segundo mecanismo consiste em enviar o
pacote RREP solicitando a confirmação de que o pacote foi recebido. O tempo que o nó fica a espera da
confirmação do pacote RREP é pré-configurado e é limitado. Se não for recebida nenhuma confirmação,
44
então admite-se que houve uma quebra de ligação. Inicia-se o processo de manutenção dos percursos com
o envio da mensagem de erro para os nós que ficaram afectados.
3.5 O funcionamento do protocolo RAM-AODV
3.5.1 Processamento do RREQ
Quando o nó de origem tem que enviar dados para o nó de destino, este consulta a sua tabela de
encaminhamento, e se não tiver percursos disponíveis, inicia o processo de descoberta. O nó de origem
envia o pacote RREQ em broadcast para a rede. Quando os nós intermédios receberem o pacote RREQ,
com base nas informações <IP Originator, ID RREQ> verificam se o pacote recebido é novo ou se é uma
duplicação. Se o pacote for uma duplicação, é descartado, caso contrário é processado da seguinte forma:
incrementa-se o valor do “hop-count” e actualiza-se a entrada da tabela de encaminhamento com as
informações do pacote RREQ de forma a criar o percurso inverso em direcção do nó de origem. É registado
na tabela de RREQ pendentes o endereço IP do nó vizinho do qual foi recebido o RREQ e o identificador
único (RREQ ID) associado a cada aquisição de percurso [ver a secção 3.2]. Estas informações são
guardadas apenas para diferentes pacotes RREQ do nó de origem. Por último, o nó intermédio insere no
pacote RREQ o endereço IP do nó vizinho que lhe enviou o pacote RREQ e retransmite-o em broadcast
para a rede. O nó de destino responde a um número limitado de pacotes RREQ com diferentes vizinhos a
dois saltos. O número máximo de respostas é definido manualmente pelo administrador da rede. Depois
de atingir esse número máximo de respostas, todos os pacotes RREQ recebidos do mesmo nó de origem
são descartados. Quando o nó de destino receber o pacote RREQ, decide se irá responder ou não a este
pedido com base na informação guardada na tabela de vizinhos processados e no número de pacotes
RREQ que já foram respondidos. Se o endereço IP do vizinho a dois saltos do nó de destino contido no
pacote RREQ não estiver na tabela de vizinhos processados e o número de RREQ que já foram respondidos
for inferior ao número máximo permitido, então o nó de destino responde com o pacote RREP. Se o
vizinho a dois saltos for o nó de origem, o nó de destino responde-lhe mesmo que esteja na tabela de
vizinhos processados, desde que não seja atingido o número máximo de respostas. Não satisfazendo estas
condições, o pacote RREQ é sempre descartado pelo nó de destino. Depois de enviar o pacote RREP, o nó
destino incrementa o número de respostas e insere o vizinho do pacote RREQ na tabela de vizinhos
processados. A Figura 3-11 mostra os procedimentos realizados pelo nó de destino no processamento do
pacote RREQ.
45
INICIO
KeySrc = rreq.GetOrigem()IDRreq = rreq.GetID()
IPN = rreq.GetNeighbor()NR = RT.GetNR()
FIM
Bool result ;result = lookupNP(KeySrc ,RREQData)
NR = NR +1TVP.insert(KsySrc,RREQData)
Send RREP
Result = IsNodeOringin(IPN)
Result
TRUEFALSE
Key Src IP do nó de origem
NR Número de Rotas
IPN Endereço IP do vizinho
TVP Tabela de vizinhos processados
Estrutura de dados com dois campos
{IDRreq ,IPN}
RREQData
NR < NMR
NMR Number Maxim Route
result
TRUE
TRUE
FALSE
FALSE
TRUE
FALSE
FALSE
TRUE
Figura 3-11:Fluxograma do algoritmo implementado no nó de destino para processar o pacote RREQ.
3.5.2 Processamento do pacote RREP
O pacote RREP é gerado para responder ao pedido de aquisição de percurso inicializado pelo nó de
origem. Quando um nó intermédio receber o pacote RREP, incrementa o valor de “hop-count”, em seguida
verifica se existe ou não uma entrada na sua tabela de encaminhamento referente ao nó de destino
indicado no pacote RREP. Se não existir, uma nova entrada é criada e inserida na tabela de
encaminhamento. Caso contrário, esta é actualizada consoante os seguintes critérios:
Se o número de sequência da entrada da tabela de encaminhamento for inválido ou inferior ao
número de sequência contido no pacote RREP, toda a informação da entrada da tabela de
encaminhamento é substituída pela informação nova contida no pacote RREP.
Se o número de sequência à entrada da tabela de encaminhamento for igual ao número de
sequência contido no pacote RREP, mas o pacote RREP for recebido de um vizinho diferente, é
46
adicionado o endereço IP deste vizinho na lista de próximos saltos. Caso o pacote RREP seja
recebido de um vizinho que já consta na lista de próximos saltos, então a lista só é alterada caso o
valor de “hop-count” contido no pacote seja inferior ao valor contido na lista ou se o estado do
percurso da lista for diferente de VALID.
Depois de fazer as actualizações, com base no endereço IP do nó de origem, o nó intermédio consulta a
tabela de RREQ pendentes para descobrir o endereço IP do “next-hop” para enviar o pacote RREP. De
seguida, o pedido de aquisição de percurso para o respectivo nó de origem é eliminado da lista de RREQ
pendentes. Quando o nó de origem receber o pacote RREP, é efectuado o mesmo procedimento dos nós
intermédios. O nó de origem começa a enviar os dados para o nó de destino, mesmo sem ter recebido
todos os pacotes RREP.
3.5.3 Ilustração do funcionamento do protocolo através de um cenário.
Para ilustrar o funcionamento do protocolo, considera-se a rede da Figura 3-12.O nó S é o nó de origem e o
nó D é o nó de destino. O pacote RREQ (X, Y) é o pacote enviado pelo nó Y e proveniente do nó vizinho X. O
número máximo de percursos diferentes que podem ser determinados neste exemplo é quatro. O
processo de aquisição de percurso é iniciado pelo nó S, portanto este envia o pacote RREQ (S, S) em
broadcast para rede. Como se pode verificar o indicador do vizinho a dois saltos corresponde ao nó S, uma
vez que o nó S é o primeiro a enviar o pacote. De seguida o pacote é recebido pelo nó A, B e C, portanto, são
formados os seguintes percursos inversos: (A-S), (B-S) e (C-S). O nó A envia o pacote RREQ (S, A) e o nó B
envia o pacote RREQ (S, B) e o nó C envia RREQ (S, C) para rede. Para o percurso via o nó E, não é
descartado nenhum pacote RREQ. O nó E envia a seguinte cópia RREQ (A, E), e seguindo este
procedimento o nó destino vai receber o pacote RREQ (E, K). O nó B envia para o nó F RREQ (S, B), e o nó F
por sua vez, regista o pedido do nó B na tabela de RREQ pendentes e retransmite o pacote RREQ (B, F)
para a rede. Pouco tempo depois o nó F recebe a cópia do RREQ do nó C, mas este é descartado. Quando os
nós J e G receberem o RREQ do nó F, estes retransmitem para a rede as suas respectivas cópias RREQ (F, J)
e RREQ (F, G). Os nós H e I irão fazer o mesmo procedimento quando receberem o pacote RREQ (F, G).
De acordo com a sequência com que foram enviados os pacotes, o RREQ (E, K) é o primeiro a ser recebido
pelo nó de destino. O nó de destino insere o nó E na tabela de vizinhos processados, incrementa o
contador de número de percursos e depois responde com o pacote RREP para o nó K. Pouco tempo depois,
o nó de destino recebe o RREQ (F, J) do nó J. Como o contador de rotas é inferior ao número máximo de
percursos e o vizinho do nó J ainda não foi processado, o nó destino efectua o mesmo procedimento.
Depois o nó de destino vai receber o RREQ (G, I) e responde com o pacote RREP. Por último o nó destino
irá receber o pacote RREQ (G, H), mas este pacote é descartado porque o vizinho G já tinha sido processado
e inserido na tabela de vizinhos processados. É importante ter em consideração que a regra de não
responder a pacotes com mesmo vizinho a dois saltos só é válida se o vizinho for diferente do nó de
origem.
47
Quando os nós intermédios recebem o pacote RREP, encaminham-no para o nó de origem com base no
endereço IP guardado na tabela de RREQ pendentes. Quando o nó K receber o RREP do nó de destino, com
base na tabela de RREQ pendente encaminha-o para o nó E. Seguindo este procedimento o pacote é
encaminhado até ao nó S, e fica assim definido o primeiro percurso (S-A-E-K-D). Quando o nó J receber o
pacote RREP do nó de destino, encaminha este pacote para o nó F. O nó F, com base na informação
guardada na tabela de RREQ pendentes, envia o RREP para o nó B, e depois o nó B encaminha o pacote
para o nó de origem, e é formado o segundo percurso (S-B-F-J-D). Quando o nó I receber o pacote,
encaminha-o para o nó G e este por sua vez encaminha-o para o nó F. O nó F conclui que não tem nenhum
pedido pendente na tabela de RREQ pendentes, portanto não encaminha o pacote para o nó de origem,
mas é formado o percurso (F-G-I-D). Assim, no final do processo de descoberta, o nó de origem S pode
enviar os pacotes para o nó de destino D através dos seguintes percursos: (S-A-E-K-D), (S-B-F-J-D) e (S-B-F-
G-I-D).
S
GC
JFB D
KEA
I
H
RREQ (S,S)
RREQ(S,A) RREQ(A,E)
RREQ (E,K)
RRESQ(S,S) RREQ(S,B)
RREQ(S,S) RREQ(S,C)
RREQ(B,F) RREQ(F,J)
RREQ(F,G)
RREQ(G,I)
RREQ(F,G)
RREQ(G,H
)
RREQ(B,F)
Pacotes descartados
Pacotes transmitidos
Number Maxim Route = 4
Figura 3-12: Processo de descoberta de rota do protocolo RAM-AODV.
48
4 Resultados de Simulação
Neste capítulo são apresentados e analisados os resultados dos testes efetuados para verificar o
desempenho do protocolo RAM-AODV. Para implementação e simulação do protocolo, neste trabalho foi
utilizado o simulador Network Simulator (NS-3 versão 3.10). O NS-3 é um simulador de rede que foi
desenvolvido para fins académicos e de investigação. Este simulador é uma nova alternativa ao popular
Network Simulator 2 (NS-2) [23] . É um software open-source, distribuído sob a licença GNU GPLv2,
disponibilizado gratuitamente para investigação e desenvolvimento. O NS-3 é desenvolvido utilizando a
linguagem C++ e com interface opcional em Python. O simulador possui uma extensa documentação
relativa à sua Application Programming Interface (API). O NS-3 está disponível para várias versões dos
sistemas operativos Linux, Mac OS X e Windows (neste através da utilização da ferramenta Cygwin) [6].
O NS-3 suporta scripts escritos em linguagens C++ e Python. Neste trabalho optou-se por escrever os
scripts em linguagem C++. Para obter os resultados do desempenho do protocolo desenvolvido, foram
implementados dois cenários:
Cenário 1 – rede estática.
Cenário 2 – rede dinâmica.
Para cada um destes cenários foram realizados vários testes e determinados os parâmetros indicadores da
qualidade de serviço (QoS).
4.1 Método de recolha de dados
O procedimento de avaliação do desempenho do protocolo foi dividido em três fases. A primeira fase
consiste na implementação do cenário para testar o desempenho do protocolo, em que são definidos:
Parâmetros da simulação;
Características do meio de comunicação;
Configuração da topologia da rede9;
Instalação do protocolo desenvolvido nos dispositivos e das aplicações para testar o protocolo [ver
Apêndice A]
A definição dos parâmetros de simulação e das características do meio da comunicação consiste na
escolha dos seguintes parâmetros:
Modelo de propagação;
9 A topologia é a forma como os dispositivos (nós) estão interligados na rede.
49
Protocolo de transporte;
Tempo de simulação;
Distância entre os nós;
Escolha do nó emissor e do nó receptor;
Tamanho dos pacotes em bytes;
Número máximo de pacotes a serem enviados;
Intervalo de envio dos pacotes;
Número de nós da rede;
Definição ou não de qualidade de serviços (QoS) para a tecnologia sem-fios;
Tecnologia sem-fios utilizada.
A seguir são apresentados os parâmetros considerados mais relevantes e que são constantes para os
dois cenários (topologias estática e dinâmica).
Tabela 4-1: Definição dos parâmetros constantes para os dois cenários.
Parâmetros Valores
Tempo de simulação 100s
Protocolo de transporte Protocolo UDP
Tecnologia IEEE 802.11b
Modelo de propagação Valores por omissão do NS-3
Distância entre os nós 20m
Número de nós na horizontal 10
Tamanho dos pacotes 256 Bytes
Número de pacotes enviados em cada simulação 500
Os valores por omissão de propagações utilizadas pelo NS-3 são:
ConstantSpeedPropagationDelayModel: define uma velocidade de propagação constante, sendo o
valor inicial por omissão igual à velocidade da luz ( .
LogDistancePropagationLossModel: define que as perdas de propagação são baseadas no modelo
do logaritmo da distância definido por:
50
Onde os significados dos parâmetros e os seus respectivos valores por omissão são:
n: coeficiente de atenuação que caracteriza o meio de propagação (n=3);
: distância de referência (m), o valor por omissão é 1m;
: atenuação de referência (dB), sendo o valor inicial 46.6777dB (obtido pela equação de Friis
usando a distância de 1m à frequência 5.15 GHz);
: distância (m);
: perdas de propagação (dB);
Para além dos parâmetros que foram definidos para testar o desempenho do protocolo, há também que
definir um conjunto de atributos que são utilizados pelo protocolo de encaminhamento para o cálculo dos
varios percursos. A Tabela 4-2 apresenta todos os atributos que foram utilizados pelo protocolo RAM-
AODV e o protocolo AODV durante o processo de descoberta de percursos.
Tabela 4-2: Atributos e valores por omissão.
Atributos Valores Definição
RreqRetries 2 O número máximo de retransmissões de RREQ com TTL =
NetDiameter para descobrir um percurso.
NetDiameter 35 O NetDiameter mede o número máximo de saltos possíveis entre dois
nós na rede.
RreqRateLimit 10 O número máximo de RREQ por segundo.
ActiveRouteTimeout 1s Período de tempo durante o qual o percurso é considerado válido.
NodeTraversalTime
(NodeTT)
40ms NodeTraversalTime é uma estimativa conservadora do tempo médio
da travessia de um salto dos pacotes e deve incluir os atrasos de fila,
tempos de processamento de interrupção e os tempos de
transferência.
NetTraversalTime NTT Estimativa do tempo médio efectivo da travessia.
PathDiscoveryTime (2) * NTT Estimativa do tempo máximo necessário para encontrar um percurso
na rede.
MyRouteTimeout
(MRT)
MRT Valor do tempo de vida do percurso definido no campo do pacote
RREP gerado pelo presente nó.
HelloInterval 1s Cada HelloInterval o nó verifica se ele enviou uma transmissão dentro
do último HelloInterval. Se não tem, ele pode transmitir uma
51
mensagem Hello.
AllowedHelloLoss 2 Número de mensagens de Hello que pode ser perdido para uma
ligação válida.
DeletePeriod
(DT)
DP DeletePeriod indica um limite superior sobre o tempo que o nó A pode
considerar o vizinho B como um proximo salto activo para o nó de
destino D, enquanto o nó B possui rotas validas para o nó de destino
D.
NextHopWait 10ms *
NodeTT
Periodo de tempo de espera do RREP_ACK de um nó vizinho.
BlackListTimeout
(BLT)
BLT Tempo para o qual o nó é colocado na lista negra.
MaxQueueLen 64 O número máximo de pacotes que é permitido ao protocolo de
encaminhamento guarda no buffer.
MaxQueueTime 30s O período máximo de tempo que é permitido para um protocolo de
encaminhamento gaurdar um pacote no buffer.
NTT= (2*NetDiameter) * NodeTraversalTime.
MRT=2* max (PathDiscoveryTime, ActiveRouteTimeout).
DP =5 * max (ActiveRouteTimeout, HelloInterval)
BLT= (RreqRetries) * NetTraversalTime
NodeTT = NodeTraversalTime
Na segunda fase, define-se o número total de simulações por cada cenário, são escolhidas as métricas de
avaliação do desempenho do protocolo e é determinada a forma de variação dos parâmetros que
influenciam os resultados. Devido à aleatoriedade das simulações, optou-se por simular cada cenário
cinquenta vezes de modo a determinar o comportamento médio. O único parâmetro que é alterado
durante as várias simulações para o mesmo cenário é o valor do seed, os outros parâmetros permanecem
constante. As métricas que foram utilizadas para avaliar o desempenho do protocolo são as seguintes:
Atraso da comunicação extremo-a-extremo - neste atraso inclui todos os possíveis atrasos na
transmissão de dados. Inclui atrasos causados pelo buffer durante o processo de aquisição de
percursos, atrasos de filas-de-espera10 nas interfaces da rede, os atrasos de transmissão11 e de
retransmissão do MAC e os tempos de propagação12.
10 Atraso filas-de-espera - é o tempo que o pacote fica a espera nas filas-de-espera de um equipamento para ser transmitido a rede.
52
Jitter - numa rede Ad-hoc pode se entender a variação de atraso (Jitter), como sendo a variação
no tempo e na sequência de entrega de informações (ex.: pacotes) devido a variação de atraso na
rede. A rede e seus equipamentos impõem um atraso à informação e este atraso é variável devido
a uma séries de factores, a saber:
Tempo de processamento diferentes nos nós intermédios
Maior ou menor atraso nas filas-de-espera;
Taxa de pacotes recebidos – corresponde a uma fração de pacotes recebidos pelo nó de destino
do conjunto de pacotes que foram enviados pelo nó de origem.
Débito - o débito é o número de bits recebidos pelo nó de destino durante a simulação,
contabilizando os dados que são transmitidos efectivamente por unidade de tempo.
Tempo de simulação é o tempo total simulado, i.e., tendo como referência o relógio interno do
simulador.
Durante a simulação, para cada cenário é determinado o valor médio das métricas mencionadas acima.
A terceira fase consiste no processamento e análise de resultados.
4.2 Cenário 1 - Topologia estática da rede.
Neste cenário, pretende-se avaliar o desempenho do protocolo considerando uma topologia de rede
estática com forma de uma matriz de m linhas por n colunas. A variável m corresponde ao número de
linhas e por conseguinte ao número de nós na vertical, e a variável n corresponde ao número de colunas
(largura) e por conseguinte o número de nós na horizontal. Nesta topologia, os dispositivos não são
móveis, sendo assim, uma topologia estática. Um exemplo deste tipo de topologia está apresentado na
Figura 4-1.
11 Atraso de transmissão – corresponde ao tempo que o equipamento, como router, interface de rede etc., leva para transmitir um pacote para uma ligação. 12 Tempo de propagação - refere-se ao tempo que um sinal leva a percorrer o meio que está sendo utilizado.
53
No 3n
No 2n
No 3n-1
No n+3 No 2n-1
No 2 No 3 No 4 No n-1
No nNo n+2No n+1
No 2n+1 No 2n+2 No 2n+3
No 3n+1 No 3n+2 No 3n+3No 4n-1
No 1
No (m-1)n No (m-1)n+1 No (m-1)n+2 No (m-1)n+3 No (m-1)n +(n-1)
Figura 4-1: Exemplo de uma topologia estática lógica e genérica da rede.
Neste cenário foram realizados dois testes diferentes, para avaliar o desempenho do protocolo.
4.2.1 Teste de variação da densidade de rede
A variação da densidade da rede consiste em aumentar o número de nós por unidade de área. Este teste
foi realizado para o estudo do desempenho do protocolo RAM-AODV em comparação com o protocolo
AODV, ao variar o número de nós da rede. Para cada parametrização, foram realizadas cinquenta
simulações variando o valor de seed13. Calcula-se o valor médio sobre os valores obtidos, de modo a
garantir uma maior precisão nos resultados.
Para este teste, para além dos parâmetros definidos na Tabela 4-1, são definidos outros parâmetros que
são específicos. Optou-se por considerar 40 como o número de nós inicial e 80 como o número máximo de
nós da rede. A simulação foi realizada incrementando o número de nós em 10 unidades e fixando os
outros parâmetros da rede indicados na Tabela 4-3. O nó de origem, assim como está indicado na Tabela
4-3, corresponde ao primeiro nó da rede estática (primeira linha e primeira coluna da matriz). O nó de
destino por conseguinte é o último nó da rede (última linha e última coluna da matriz), a posição deste
acompanha o aumento do número de nós da rede.
Tabela 4-3: Definição dos parâmetros para o teste 1.
Parâmetros Valores
Número mínimo de nós 40
Número máximo de nós 80
Variação do número de nós 10
13 Seed - valor definido para gerar a sequência de números pseudo-aleatórios da simulação. É importante que cada simulação seja realizada com um valor diferente de seed.
54
Intervalo de envio dos pacotes 0.001s
Max Num Router 1,2,3,4
Nó de origem Nó 0
Nó de destino Nó {39, 49,59,69 e 79}
Os gráficos apresentados nesta secção permitem-nos analisar o desempenho do protocolo RAM-AODV,
quando for utilizado para realizar o encaminhamento com percurso único e o encaminhamento multi-
percurso. Para avaliar o desempenho do protocolo quando for realizado o encaminhamento multi-
percurso, foram realizadas três simulações com diferentes números de percursos (1, 2, 3 e 4 percursos).
Toda a abordagem feita ao desempenho do protocolo RAM-AODV, tem como referência os resultados do
protocolo AODV. O desempenho do protocolo RAM-AODV é considerado como sendo bom, se for melhor
do que o desempenho obtido pelo protocolo AODV, nas mesmas condições. Com o objectivo de determinar
o número óptimo de percursos (parâmetro Max Num Router) e de mostrar as vantagens de utilizar o
protocolo RAM-AODV em alternativa ao protocolo AODV, foi realizada nesta secção uma análise detalhada
dos vários gráficos que a seguir estão apresentados.
Figura 4-2: Valores médios do atraso extremo-a-extremo em redes estáticas, com número de nós variável.
O gráfico da Figura 4-2 permite-nos estudar o desempenho do protocolo RAM-AODV e do protocolo AODV,
ao comparar os seus respectivos valores médios de atraso. Para uma rede composta por 40, 50 e 60 nós,
obtêm-se menor atraso quando se realiza o encaminhamento com percurso único, utilizando o protocolo
RAM-AODV. Contudo o protocolo RAM-AODV (1 percurso), não foi considerado como a melhor solução,
uma vez que ao analisar o gráfico da Figura 4-4, para estes mesmos números de nós, só se consegue obter,
quando muito, uma taxa média de pacotes recebidos menor do que 20%. Para o protocolo RAM-AODV (2,3
e 4 percursos) nestas mesmas condições consegue-se obter uma taxa média de pacotes recebidos maior
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
40 50 60 70 80
Atr
aso
[s]
Variação de número de nós da rede
RAM-AODV (1 percurso) RAM-AODV (2 percursos)
RAM-AODV (3 percursos) RAM-AODV (4 percursos)
AODV
55
do que 80%. O protocolo AODV nestas mesmas condições teve uma taxa média de pacotes recebidos
aproximadamente de 40%. Para uma rede composta por 70 e 80 nós os resultados evidenciam o protocolo
RAM-AODV com mais de um percurso como sendo a melhor solução, não havendo vantagem em utilizar
mais do que 2 percursos.
Figura 4-3: Valores médios do jitter em redes estáticas, com número de nós variável.
O gráfico da Figura 4-3 apresenta o desempenho do protocolo AODV e RAM-AODV através do cálculo do
jitter. O comportamento do gráfico da Figura 4-3 é justificado com base nos valores do gráfico da Figura
4-2. Ao fazer a comparação entre os dois gráficos, conclui-se que os resultados estão coerentes. Foi
concluído a partir do gráfico do atraso [Figura 4-2], que o melhor desempenho é concebido pelo protocolo
RAM-AODV, ao realizar o encaminhamento multi-percurso com 2, 3 e 4 percursos. No entanto, não foi
possível concluir com clareza qual é o número óptimo de percursos. Ao analisar o gráfico do jitter [Figura
4-3], conclui-se que o melhor desempenho é obtido quando se realiza o encaminhamento multi-percurso,
utilizando o protocolo RAM-AODV com 2 percursos. Esta conclusão mantem-se inalterável,
independentemente do número de nós utilizados. O gráfico da Figura 4-4, mostra que o protocolo RAM-
AODV com 2 percursos obteve-se uma taxa média de pacotes recebidos sempre superior a 80%, enquanto
que para 3 e 4 percursos a partir de 60 nós, a taxa média de pacotes recebidos começa a diminuir. Ao fazer
uma análise comparativa entre o protocolo AODV e o protocolo RAM-AODV com base nos gráficos,
conclui-se que o protocolo RAM-AODV apresenta melhor desempenho.
Uma outra conclusão interessante que o gráfico do jitter realça, resulta do facto do protocolo RAM-AODV
com 1 percurso apresentar um comportamento completamente diferente do protocolo AODV. A partir do
gráfico da Figura 4-4 e o gráfico da Figura 4-5, chega-se à mesma conclusão.
0
0,005
0,01
0,015
0,02
0,025
0,03
0,035
0,04
0,045
40 50 60 70 80
Jitt
er[
s]
Variação de números de nós da rede
RAM-AODV (1 percurso) RAM-AODV (2 percursos)
RAM-AODV (3 percursos) RAM-AODV (4 percursos)
AODV
56
Figura 4-4: Valores de taxa média dos pacotes recebidos em redes estáticas, com número de nós variável.
Esperava-se que o protocolo RAM-AODV com 1 percurso tivesse um desempenho semelhante ou igual ao
protocolo AODV. No protocolo AODV foi permitido aos nós intermédios participarem no processo de
aquisição de percursos, permitindo-lhes responder a pacotes RREQ quando possuem percursos válidos
para o nó de destino. No protocolo RAM-AODV, apenas os nós de destino podem responder aos pacotes
RREQ, sendo que os nós intermédios estão limitados a encaminhar apenas o pacote RREQ. Esta
funcionalidade extra dos nós intermédios no protocolo AODV acelera o processo de aquisição de
percursos e diminui o número de pacotes descartados, contribuindo deste modo para uma melhoria do
desempenho do protocolo AODV. Para uma rede composta por 40, 50 e 60 nós o protocolo AODV
apresentou melhor desempenho do que o protocolo RAM-AODV com 1 percurso. A partir de uma rede
com 60 nós, o desempenho do protocolo AODV começa a diminuir significativamente, enquanto que para
o protocolo RAM-AODV houve uma melhoria no desempenho. Uma das causas da descida do desempenho
do protocolo AODV, está relacionada directamente com o congestionamento da rede, provocado pelas
mensagens de sinalização. Na medida em que aumenta o número de nós, aumenta também o número de
pacotes RREP enviados pelos nós intermédios, em virtude da resposta das mensagens broadcast RREQ.
Aumenta-se também o número de mensagens de hello enviados pelos nós que fazem parte de percursos
activos. Isto tudo contribui para o aumento da sobrecarga e do congestionamento da rede, resultando em
aumento de colisões entre pacotes e, consequentemente, do números de pacotes descartados pela rede.
0
10
20
30
40
50
60
70
80
90
100
40 50 60 70 80
Ta
xa
s d
e p
aco
tes
rece
bid
os
[%]
Variação do número de nós da rede
RAM-AODV (1 percurso) RAM-AODV (2 percursos)
RAM-AODV (3 percursos) RAM-AODV (4 percursos)
AODV
57
Figura 4-5: Valores médios do débito em redes estáticas, com número de nós variável.
De acordo com toda a análise feita sobre os resultados obtidos nesta secção, obtêm-se as seguintes
conclusões:
O encaminhamento multi-percurso realizado pelo protocolo RAM-AODV é mais eficiente e obtém-
se melhor desempenho do que o encaminhamento com percurso único realizado pelo protocolo
AODV.
Conclui-se também que para as redes densas (neste cenário rede composta por 70 e 80 nós) o
desempenho do encaminhamento multi-percurso diminui quando aumenta o número de
percursos entre o nó de origem e o nó de destino. Como se pode ver no gráfico da Figura 4-4 e da
Figura 4-5, a partir de 70 nós, o débito e a taxa média de pacotes recebidos começa a diminuir
para o RAM-AODV com 3 e 4 percursos. Uma das causas pelas quais o desempenho do protocolo
diminui quando aumenta o número de percursos entre o nó de origem e de destino, está
directamente relacionado com congestionamento provocado pelo aumento das mensagens de
sinalização. Por outro lado, quando aumenta o número de percursos entre o nó de origem e de
destino, passa-se a verificar interferência entre os percursos. A interferência entre os percursos,
designado por acoplamento de percursos, tem um impacto negativo nas comunicações e diminui
o desempenho.
Por último, conclui-se que permitir aos nós intermédios responder os pedidos de aquisição de
percursos, quando estes possuem percursos válidos para o nó de destino é vantajoso para redes
não muito densas (menos de 70 nós), tal como foi verificado nesta secção.
0
20
40
60
80
100
120
40 50 60 70 80
Dé
bit
o[k
bp
s]
Variação de número de nós da rede RAM-AODV(1 perucurso) RAM-AODV(2 perucursos)
RAM-AODV(3 perucursos) RAM-AODV(4 perucursos)
AODV
58
4.2.2 Teste de variação do intervalo de envio dos pacotes
Nesta secção é apresentado o desempenho dos dois protocolos ao variar o intervalo de envio dos pacotes.
Para realizar este teste foram definidos alguns parâmetros adicionais, que são específicos para este teste,
para além dos parâmetros da Tabela 4-1. Começa-se por considerar 80 como o número de nós da rede, o
número máximo de percursos (Max Num Router) utilizado pelo protocolo RAM-AODV para realizar o
encaminhamento multi-percurso é 2. Foi escolhido este valor, tendo em consideração os resultados
obtidos na secção 4.2.1. Foram realizadas várias simulações com diferentes valores de intervalos de envio
de pacotes, no entanto, apenas três valores foram considerados para construção do gráfico. Para
intervalos inferiores a 1e-04 s [AODV (0.66kbps), RAM-AODV (17.29kbps)], a taxa média de pacotes
recebidos e débito do protocolo AODV são praticamente nulos [Figura 4-8 e Figura 4-9]. Para intervalos
inferiores a 1e-05 s [AODV (3.42kbps), RAM-AODV (6.5kbps)] a taxa média de pacotes recebidos e débito
são praticamente nulos para o protocolo RAM-AODV. Por isso, foram considerados apenas estes três
intervalos, uma vez que, para intervalos inferiores a 1e-05 s, não é possível tirar qualquer conclusão sobre
o desempenho dos dois protocolos. Segundo o gráfico da Figura 4-6,para o intervalo 0.001s, ambos os
protocolos tiverem o mesmo atraso. Contudo, ao analisar o gráfico apresentado na Figura 4-8 e o gráfico
ilustrado na Figura 4-9, verifica-se que para esse valor de atraso, a taxa média de pacotes recebidos pelo
protocolo AODV é inferior a 20%, enquanto que para o protocolo RAM-AODV é mais de 80%. Conclui-se
então, que o protocolo RAM-AODV teve melhor desempenho do que o protocolo AODV, para este intervalo
de transmissão. Para os intervalos inferiores à 1e-04 s, o protocolo AODV teve um valor de atraso
constante, aproximadamente 0.8s, dando entender que o protocolo tem um comportamento estável para
intervalos inferiores a 1e-04 s. No entanto, de acordo com o gráfico da Figura 4-8, a taxa média de pacotes
recebidos pelo protocolo AODV foi nula, portanto, é razoável que o atraso mantivesse constante para
intervalos inferiores a 1e-04 s.
Figura 4-6: Valores médios do atraso extremo-a-extremo em redes estáticas, com intervalo de envio de
pacotes variável.
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
0,001 0,0001 1,00E-05
Atr
aso
[s]
Variação do intervalo de envio dos pacotes
RAM-AODV (2 Percursos) AODV
59
Figura 4-7: Valores médios do jitter em redes estáticas, com o intervalo de envio de pacotes variável.
O gráfico da Figura 4-7 apresenta o valor médio do jitter dos dois protocolos em ao variar o intervalo de
envio dos pacotes. Diminuir o intervalo de envio dos pacotes, significa aumentar o ritmo com o qual os
pacotes são enviados para a rede. Isto provoca o aumento do tráfego na rede e por conseguinte o
congestionamento e o aumento do número de pacotes descartados. Para o intervalo igual a 0.001s, o
protocolo RAM-AODV teve uma taxa média de pacotes recebidos superior a 80%, enquanto que para o
intervalo 0.0001s teve uma taxa média apenas de 20%. O valor do jitter diminuiu com a diminuição do
intervalo de envio dos pacotes, dado que diminuiu também o número de pacotes recebidos. Por outro
lado, se o valor do intervalo do envio dos pacotes for muito pequeno, como por exemplo 1.00E-05,
rapidamente a rede entra em saturação devido ao congestionamento. Apenas uma pequena quantidade de
pacotes é que se consegue fazer chegar ao nó de destino. Os resultados de atrasos e de jitter deixam de ser
de confiança estatisticamente, pois baseia-se em poucos pacotes recebidos. Ao comparar o gráfico do
atraso da Figura 4-6 com o gráfico do jitter da Figura 4-7, conclui-se que o jitter pode ser ignorado em
relação ao atraso, pois a diferença de ordens de grandeza permite utilizar um buffer para eliminar o jitter.
Para o intervalo de envio de pacotes igual 0.001s tem-se aproximadamente 0.714% do jitter para o
protocolo AODV e para o protocolo RAM-AODV (2 percursos) teve-se 0.428% do jitter, portanto, o jitter é
er()); 433) std::map<FlowId, FlowMonitor::FlowStats> stats = monitor->GetFlowStats(); 434) 435) for (std::map<FlowId, FlowMonitor::FlowStats>::const_iterator i = stats.begin(); i != stat