De forma a ser poss´ıvel testar o protocolo MIPv6 foi necess´ario recorrer a uma imple- menta¸c˜ao deste em Linux. Existem algumas implementa¸c˜oes deste protocolo para este sis- tema operativo, sendo que a escolha recaiu sobre a implementa¸c˜ao USAGI-patched Mobile IPv6 for Linux [85], j´a que esta ´e uma evolu¸c˜ao de implementa¸c˜oes mais antigas, tendo por- tanto, corre¸c˜oes de bugs e novas funcionalidades, como o suporte para o protocolo NEMO [86]. A vers˜ao utilizada foi a USAGI-patched Mobile IPv6 for Linux (UMIP) 0.4.
4.3.1 Funcionamento
Antes de se poder proceder a uma avalia¸c˜ao do protocolo ´e necess´ario perceber o seu funcionamento, isto ´e, ´e necess´ario proceder a uma an´alise do seu processo de funcionamento tendo em conta a arquitetura que se pretende estudar. Como se pretendem estudar dois tipos de handover : entre redes homog´eneas e entre redes heterog´eneas, torna-se importante perceber o comportamento do protocolo em cada uma destas situa¸c˜oes.
Um aspeto cr´ıtico num protocolo de mobilidade ´e a sua capacidade de detetar o movimento dos MNs, sendo que o protocolo MIPv6 define que esta ´e realizada pelo pr´oprio MN. Assim, durante esta subsec¸c˜ao, a an´alise efetuada ser´a para o UMIP implementado no MN, focando-se no processo de decis˜ao de handover.
4.3.1.1 Funcionamento do UMIP implementado no MN
O UMIP utiliza os pacotes RA enviados pelos diversos routers existentes para fazer a dete¸c˜ao do movimento, tal como o protocolo MIPv6 especifica. Atrav´es da rece¸c˜ao destas mensagens, o MN ter´a acesso a uma s´erie de informa¸c˜oes como: o prefixo da rede `a qual pertence o router que enviou a mensagem; se o MN se encontra na sua HN ou numa FN; o
tempo desde o ultimo RA recebido de forma n˜ao solicitada; e detalhes sobre o seu HA. Depois de recebido o RA, o UMIP come¸ca por verificar se o endere¸co link local da interface de onde a mensagem ´e proveniente ´e v´alido, caso n˜ao seja, este pacote ´e descartado e o programa volta `a sua fase inicial.
Caso passe esta verifica¸c˜ao, o passo seguinte ´e verificar se o router registado na interface que recebeu o RA (default router ) corresponde ao router que enviou o RA. Se os dois routers coincidirem ´e atualizada a informa¸c˜ao referente a este e o programa volta `a fase inicial, caso n˜ao coincidam, a informa¸c˜ao relativa `a interface ´e atualizada, sendo definido o novo router como default router.
O passo seguinte ´e verificar se o MN se encontra ligado `a sua HN, se tal acontecer o MN vai-se permanecer ligado a esta sem ter em conta as outras liga¸c˜oes presentes. Se o MN n˜ao tiver liga¸c˜ao com a sua HN, ´e verificada a existˆencia de liga¸c˜ao em alguma interface do MN. Caso esta exista, ´e dada uma preferˆencia a esta interface e se o RA tiver sido recebido atrav´es de outra ´e automaticamente descartado. Caso o MN n˜ao tenha liga¸c˜ao em nenhuma interface, ou a interface em que est´a ligado corresponde `a interface de que recebeu o RA, ´e invocada a fun¸c˜ao mn get iface para obter a nova interface, seguindo-se a atualiza¸c˜ao do CoA e nova verifica¸c˜ao da igualdade entre a interface atual e a interface determinada. Caso estas interfaces coincidam, o processo de handover ´e ignorado e o programa volta `a fase inicial; caso as interfaces sejam diferentes procede-se `a realiza¸c˜ao do handover.
4.3.2 Limita¸c˜oes e melhorias no UMIP
Tendo em conta o funcionamento do UMIP, no que diz respeito `a forma como este deter- mina a necessidade de ocorrer um handover, percebe-se que este apresenta algumas lacunas, das quais se destacam:
• N˜ao permite a utiliza¸c˜ao de mais de um CoA por interface;
• ´E dada sempre preferˆencia pela HN. Mesmo que existam outras redes com melhor qualidade de liga¸c˜ao, o MN ir´a sempre ligar-se `a sua HN;.
• N˜ao permite a realiza¸c˜ao de handover make-before-break, ou seja, ´e necess´ario perder a liga¸c˜ao com a rede atual para serem consideradas novas redes.
Durante o trabalho desenvolvido ao longo desta Disserta¸c˜ao n˜ao foi efetuada qualquer altera¸c˜ao no UMIP, sendo no entanto utilizada uma vers˜ao modificada por Capela et al. [87], que d´a resposta `as limita¸c˜oes apresentadas. As principais funcionalidades introduzidas s˜ao:
• Capacidade de intervir no processo de escolha da interface para a qual se pretende realizar handover ;
• Foi retirada a preferˆencia pela HN, deste modo esta ´e tratada de forma igual a uma FN; • Capacidade de comunica¸c˜ao com uma entidade externa, atrav´es de um processo de
comunica¸c˜ao ”cliente-servidor”baseado em sockets.
Tendo em conta esta comunica¸c˜ao, foi necess´ario desenvolver um mecanismo capaz de co- municar com o UMIP, indicando-lhe qual a interface para a qual este deve efetuar o handover. Este mecanismo funciona integrado com o gestor de mobilidade desenvolvido e apresentado na Sec¸c˜ao 4.5. Este for¸ca o UMIP a efetuar handover para a interface pretendida.
Cliente (Gestor de mobilidade) Resultado do handover Servidor (UMIP) Efetuar handover para a interface X Verifica a preferência das interfaces Atribuir maior preferência à interface X Existe alguma interface com maior
preferência?
Manter-se na interface atual Não
Efetuar handover para
a interface X Sim
Enviar resultado do
handover
Figura 4.3: Diagrama de funcionamento do mecanismo que permite for¸car o handover para a interface escolhida (adaptado de [87])
Como se pode observar na Figura 4.3, a decis˜ao de desencadear um handover entre redes heterog´eneas come¸ca no Gestor de Mobilidade. Este, depois de determinar que uma inter- face oferece melhor qualidade de liga¸c˜ao `a rede que a interface atual, utiliza o mecanismo desenvolvido para efetuar a comunica¸c˜ao com o UMIP, indicando-lhe para que interface deve realizar o handover. Este, depois de receber a informa¸c˜ao acerca da interface para a qual
deve efetuar handover, utiliza um sistema de preferˆencias, atribuindo a maior preferˆencia `a interface indicada, realizando assim o handover para esta. Depois de conclu´ıdo este processo, o UMIP envia uma mensagem a informar se o handover foi bem-sucedido.