Le service MIH (Media Independant Handover)

problématique :

Depuis quelques années déjà, les terminaux informatiques deviennent moins encombrants et par conséquent plus mobiles. Par ailleurs les possibilités de se connecter à l’Internet se multiplient. Il s’en suit une mobilité induite par l’utilisation de plusieurs technologies d’accès (Ethernet, WiFi, GPRS,…) sur un même terminal dans la même journée. Les études sont actuellement conduites par les constructeurs et les opérateurs pour fournir des infrastructures mobiles utilisant de nouvelles technologies radio, WiFi et WiMax notamment, ont pour objet d’offrir la continuité des services en cours de déplacement, comme le permet le GSM dans le cas de la téléphonie mobile. Cela nécessite que les applications ne soient pas interrompues lors des épisodes de mobilité. Enfin, les sociétés de transport désirant offrir un service de connexion à leurs clients en déplacement et les fabricants de véhicules, qui interconnectent de plus en plus d’équipements à bord, envisagent la question de la mobilité d’un réseau entier et non plus uniquement celle d’équipements isolés. Le premier problème est élégamment résolu par le mécanisme d’auto configuration d’IPv6, en effet, dès que le terminal a réussi à construire une adresse IPv6 globale, il est capable de communiquer avec toute autre station sur l’Internet.

Mobile IPv6 (MIPv6) modifie très peu ces mécanismes. Il ne requiert que de nouvelles directives de configuration permettant d’accélérer le processus. Le délai d’acquisition d’une adresse globale routable est en effet critique dans les situations de mobilité. Le second problème est résolu pour les postes IP fixes par le DNS qui établit la relation entre un nom logique connu de tous et une adresse IP (Nommage). Dans le contexte de la mobilité, la fréquence d’attribution d’une nouvelle adresse est incompatible avec la mise à jour du DNS distribué. D’autres mécanismes ont été proposés. Le troisième problème est plus difficile à résoudre. Il a pour origine la dualité des fonctions d’une adresse IPv6. Cette dernière identifie de manière unique sur l’Internet un terminal, ou pour être plus précis une interface réseau d’un terminal. Elle permet aussi de localiser un noeud dans la topologie de l’Internet. Ainsi chaque fois qu’un noeud se déplace, ce dernier doit changer d’adresse pour que la nouvelle adresse corresponde à sa nouvelle localisation (fonction de localisation). Malheureusement son identification change aussi ce qui pose des problèmes aux couches supérieures.

En effet, TCP utilise le quintuplé : Adresse IPv6 source, Adresse IPv6 destination, Port source, Port destination et numéro de protocole pour identifier une connexion. Lorsqu’un de ces éléments change, il ne s’agit plus pour lui de la même session et les communications en cours sont interrompues. Dès 1998, l’IETF a standardisé une solution de mobilité IP pour IPv4 [RFC 3344]. Les contraintes liées à la modification d’un protocole très largement déployé ont limité le travail à la modification du comportement du mobile lui-même (sans implication du correspondant pour qui la mobilité devait être transparente) et à l’ajout de nouvelles entités dans le réseau. IPv6 offrait l’opportunité du déploiement d’un nouveau protocole intégrant dès l’origine la mobilité. Les correspondants peuvent ainsi être mis à contribution pour des traitements liés à la mobilité. De plus la conception plus moderne d’IPv6 permet d’alléger les mécanismes d’encapsulation et de profiter des mécanismes d’auto configuration. Des désaccords concernant la sécurisation de Mobile IPv6 (c.f. Les risques induits par la mobilité et leur limitation) et les différentes optimisations possibles, ont rendu la standardisation de Mobile IPv6 longue et laborieuse, les RFCs n’ayant été publiés qu’en juin 2004. La gestion de la mobilité dans IPv6 est maintenant définie dans le RFC 3775 pour ses aspects fonctionnels. Le RFC 3776 traite pour sa part des aspects liés à la sécurité de la signalisation de la mobilité.

Smooth Handover : Le MN change le routeur d’accès (AR) à un autre AR. Ce changement d’AR est considéré comme un Handover. Lors de Handover et avant, le HA reçoit la nouvelle CoA de MR, en lui envoyant des paquets où certains d’eux sont probablement perdus [14]. Le smooth Handover est une technique qui réduit le nombre de pertes de paquets IP, en moment de Handover. Pour réduire ces pertes, il fait appel à un mécanisme de sauvegarde dans PAR. Le PAR effectue une copie de tous les paquets qu’il transmet au mobile avant, pendant et après la déconnexion. [13] Nous partons du principe qu’il n’existe pas des chevauchements entre deux éléments AR, ce qui signifie que le MN est toujours à l’intérieur de la cellule d’au moins une AR. Cependant, il peut y avoir des chevauchements entre les cellules adjacentes qui couvrent les ARs, ce qui signifie que le MN pourrait recevoir des agents advertisements de plusieurs ARs. Les solutions différentes sur lesquelles AR à utiliser .la solution est basée sur la force du signal et qu’il y a un certain chevauchement entre les cellules de AR adjacentes. Comme le MN commence à se déplacer, il remarque que les signaux reçus par le MN sont en train de s’affaiblir. [14] Le MN commence alors à chercher un autre AR. Quand il reçoit un agent avertissements de NAR, (l’étape initiale de Handover), le MN envoie le Registration Request à NAR qui la transmet au HA. Si le MN obtient son nouvelle localisation et son NCoA, le NAR demande à PAR d’envoyer les paquets mémorisés au MN à cette NCoA, le NAR doit informer le PAR au moyen du message binding update. Le PAR répond par le message Binding Ack (BAck) au NAR. [14] Le NAR établit un tunnel IP avec le PAR et ce dernier indique la présence de MN. A cet instant, le PAR transmet au mobile, et à travers le tunnel, tous les paquets précédemment sauvegardés. Le NAR décapsule alors ces paquets et les transmet au MN. Les paquets dupliqués et sauvegardés lors de la déconnexion sont récupérés localement. [13]. Lorsque le HA reçoit la demande d’enregistrement, il traite la requête puis envoie le registration reply à NAR qui le transmet au MN. Le Registration reply contient les informations indiquant si la demande a été acceptée ou rejetée. [14].

Handover sans coutures ou Seamless Handover :

Le Seamless Handover est une extension du Fast Handover, dont l’objectif est la réduction du protocole de signalisation i.e. la quantité de message de signalisation. En fait, le Seamless Handover permet également d’obtenir un temps de latence de Handover similaire à celle du retard de Handover L2 (l’ordre de plusieurs dizaines de millisecondes), donc de réduire le temps d’interruption des communications entre le MN et ses correspondants. Celui-ci permet de Minimiser la perte de paquets. Le mécanisme de Seamless Handover ajout une nouvelle entité dénommée decision engine (DE). Comme dans la hiérarchique, il introduit une entité appelée MAP (Mobility Anchor Point) qui découpe le réseau global en différents domaines pour gérer la mobilité [15]. La Decision engine (DE) contrôle la procédure de Handover dans son domaine de réseau, et prendre les décisions de Handover. Lorsque les noeuds mobiles peuvent déplacer au domaine de réseau, la DE poursuit ces noeuds mobiles afin d’identifier les modes de déplacement. Cela peut se faire par le biais de messages périodiques des routeurs d’accès. Pour minimiser les pertes des paquets, on utilise le processus SPS (Synchronized-Packet-Simulcast) qui permet de transmettre les paquets en même temps au routeur d’accès précèdent et au routeur d’accès potentiel où le noeud mobile se déplace [15]. Le Seamless Handover commence lorsque le noeud mobile veut passer à un nouveau réseau, il recevra des messages beacon advertisement du nouveau routeur d’accès. Au début de Handover, le MN envoie un message RtSolPr à PAR.

A la réception du message RtSolPr, le PAR transmit le message HI à tous les NARs potentiels avec lesquels le MN lui demande dans le message RtSolPr. Ce message contient la nouvelle adresse NCoA et l’ancienne adresse PCoA. Tous les NARs répondent par un message Hack qui indique l’acceptation ou la récusation de NCoA. Dans le cas où le NAR accepte la nouvelle CoA, le PAR établit un tunnel temporaire à la NCoA. Dans l’autre cas, le PAR établit un tunnel des paquets à NAR, qui transmet temporairement au MN. En réponse de RtSolPr, le MN reçoit un message PrRtAdv de PAR [15]. Le MN envoie un message CTS à DE quand il reçoit un message beacon advertisement d’un nouveau routeur d’accès. Le message CTS contient des informations sur la puissance du signal du nouveau routeur d’accès. Cette information sera utilisée pour la localisation, les NARs transmettent un message CLS à chaque seconde jusqu’à ce qu’il reçoit un message HD de DE. Le message CLS indique le nombre de noeuds mobiles qui ont été connectés au routeur d’accès et leurs adresses IP. Le DE analyse le message CLS et le message CTS afin de suivre le mouvement de noeud mobile pour un courte période (moins de trois second), puis le DE donne la décision et envoie un message HD à tous les NARs participants. Ensuite, le PAR envoie un message HN avec le PrRtAdv au MN indiquant exactement par quel NAR, le MN devrait passer [16].

Conclusion générale

La problématique de notre projet d’étude se rapporte à la définition d’une architecture logicielle capable de faciliter la mobilité d’un réseau entier et de supporter le changement de leur point d’attachement entre les réseaux hétérogènes (le handover vertical). Dans notre travail, nous avons présenté le principe de la mobilité des réseaux, leurs applications leur problématique et leur prise en charge dans IPv6. La mobilité des réseaux a ouvert une brèche dans la gestion habituelle de la mobilité et mis à jour de nouveaux problèmes qui nécessiteront de plus amples travaux de recherche. En effet, le besoin de déplacer des réseaux est perçu depuis un certain temps, mais aucun travail significatif ne leur avait été consacré avant les premiers travaux introduits à l’IETF qui ont comblé ce manque. Les problèmes qui leurs sont propres n’ayant pas été abordés, donc suffisamment bien détaillés, les premières discussions à l’IETF ont eu pour résultat une certaine prise de conscience, assez faible dans un premier temps, mais grandissante depuis, dans les rangs de la communauté, qui a abouti avec la création du groupe de travail NEMO. Le support des réseaux mobiles est à présent un sujet qui intéresse de nombreux industriels, allant des fournisseurs d’équipement réseau ou d’électronique grand public jusqu’aux fabricants d’automobiles, en passant par les opérateurs de téléphone et de transport public.

Le support de la mobilité des réseaux permet de développer l’idée d’un Internet omniprésent, à tout instant, à tout endroit, avec n’importe qui. Les applications multimédia seront les premières à bénéficier de ce type d’environnement. En effet, la mobilité des réseaux rend en pratique possible la mobilité de tout équipement, ce qui implique aussi que toute application doit être en mesure de fonctionner dans un environnement mobile. Ceci nécessitera des mécanismes de changement d’interface et de routeur mobile, et la prise en considération d’un certain nombre de paramètres, en particulier le changement de qualité de service, de bande passante, de règles d’usage (pare-feu) en fonction des technologies accessibles à un instant donné et du réseau d’accès. La gestion de la mobilité des réseaux mobiles doit faire face à de nombreuses contraintes. L’étude que nous venons de mener se caractérise essentiellement par l’utilisation d’un simulateur (logiciel NS-2) pour évaluer et analyser les performances du handover et la gestion de la mobilité d’un réseau entier en implémentant le module MIH (module développé par IEEE 802.21) et MIPv6 (module de la gestion de mobilité) au lieu d’utiliser le package Mobiwan réservé spécialement au réseau NEMO. En perspective, nous conseillons d’interconnecter plusieurs réseaux hétérogènes et utiliser plusieurs routeurs mobiles (avec lesquels s’attachent d’autres terminaux) supportant ces différentes technologies afin d’étudier la gestion de la mobilité. On pourrait aussi illustrer l’effet de la charge des routeurs mobiles sur les performances du handover vertical entre ces différents réseaux.