Soutenance mémoire
Interaction entre réseau Ad Hoc et réseau mobile .
Généralités sur le NEMO
Dans le domaine des transports intelligents communicants comme dans beaucoup d’autres, le développement très rapide des technologies de communication sans fil ouvre des perspectives nouvelles. Il est maintenant envisageable de déployer, dans les véhicules, des applications impliquant des communications avec d’autres véhicules ou avec l’infrastructure en profitant des capacités de communication environnantes. Ces dernières peuvent être déployées pour un usage spécifique mais disposer de capacité inutilisée pouvant être réaffectée de manière temporaire ou permanente à d’autres usages. Cela permet de réduire les coûts de déploiement des nouveaux services dans la mesure où les technologies utilisées sont déjà déployées. Il faut pour cela que les équipements embarqués soient opportunistes en profitant séquentiellement ou simultanément de ce qu’on pourrait appeler la « diversité technologique ».
L’ISO a débuté en 2003 la standardisation de CALM qui définit l’architecture protocolaire des équipements embarqués dans les véhicules. Le choix d’IPv6 et de Mobile IPv6 (tous les deux sont définis à l’IETF), a été fait pour la communication entre le véhicule et l’Internet. Cela permet de supporter le grand nombre potentiel d’équipements communicants. Le protocole NEMO permet quant à lui de supporter les changements d’attachement dans le réseau IP et de cacher cette mobilité aux éléments embarqués. Ces protocoles sont par nature capables de supporter les attachements multiples à l’Internet en utilisant une ou plusieurs interfaces de communication. Pourtant, la gestion des différentes interfaces et des réseaux d’accès d’attachement est un problème déjà difficile sur les terminaux mobiles qui se complique lorsque le nombre d’entités impliquées augmente comme dans le cas des réseaux mobiles (véhicule).
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é.
L’architecture de NEMO
Le réseau NEMO, de l’IETF est dérivé de Mobile IP pour gérer la mobilité des réseaux IP. Un sous-réseau comporte des noeuds mobiles. Ce sous-réseau est associé à un réseau mère et peut changer de réseau en changeant de point d’accès. Un des objectifs est de ne pas imposer des modifications aux noeuds mobiles. Les nouvelles entités sont introduites : Home Network ou réseau mère : c’est le réseau auquel est attaché initialement un MR. Home Agent (HA) ou agent mère : un routeur d’accès particulier situé dans le réseau mère qui participe à la gestion de la mobilité du réseau mobile. Foreign Network ou réseau visité : n’importe quel réseau autre que le réseau mère auquel le réseau mobile est connecté. Le routeur d’accès (RA): situe dans le réseau visité qui fournit au MNN de réseau mobile un service de routage des paquets qui lui sont destinés par le HA Correspondant Node (CN) ou noeud correspondant : est un terminal en communication avec le MNN.
Un CN peut être fixe ou mobile. [6] Mobile Network Nodes (MNN) : est un noeud mobile qui fait partie du réseau mobile. Le routeur mobile (MR) : est l’entité la plus importante de NEMO. Le changement de point d’accès ne provoque pas de changement d’adresse IP du MNN. La gestion de la mobilité est déléguée au MR. [3]. Le MR admet au minimum deux interfaces : une interface interne (Ingress Interface, IIF) et une interface externe (Egress Interface, EIF). L’interface IIF est configurée avec une adresse IP prise du préfixe MNP, tandis que l’interface EIF est configurée avec l’adresse HoA lorsque le réseau NEMO (plus précisément le MR) est attaché au réseau mère (Home Network), c’est l’adresse mère unique par laquelle il est accessible quand il est lié au réseau mère. Lorsque le MR est attaché à un réseau visité, l’interface EIF sera configurée avec une adresse temporaire CoA.
Opérations du protocole NEMO Support Basique (NEMO BS)
Le protocole de routage le plus utilisable dans le réseau NEMO c’est le protocole NEMO BS qui possède les mêmes opérations conduites par MIPv6. Quand le MR s’éloigne du réseau mère et s’attache à un nouveau routeur d’accès, il acquiert une adresse temporaire CoA. Il envoie immédiatement un binding update (BU) à son HA. Quand le HA reçoit cette mise à jour, il crée dans son binding cache une entrée indiquant la nouvelle adresse CoA de l’actuel point d’attachement du MR. [6] Le MR peut à tout moment agir soit comme un noeud mobile ou comme un routeur mobile. Si le MR vise à agir en tant que routeur mobile et à fournir la connectivité aux noeuds dans le réseau mobile NEMO, il indique ceci au HA en plaçant le Flag R à la valeur 1 dans le message BU. Il inclut également les informations sur le préfixe du réseau mobile de sorte que le HA peut expédier les paquets destinés aux MNNs du réseau mobile NEMO. [6] Quand le HA reçoit le message binding update du MR, il répond par un message binding Ack (BAck) avec un Flag R=1. Tous les messages de signalisation entre le MR et le HA en particulier les BU/BAck doivent être protégés par IPsec.
Une fois le processus de mise à jour est terminé, un tunnel IP-in-IP [8] bidirectionnel est établi entre le HA et le MR. Ce tunnel peut être protégé par IPsec ou non. Le tunnel bidirectionnel est créé entre le MR et son HA en fusionnant deux tunnels bidirectionnels. Le tunnel du MR vers le HA a comme point d’entrée du tunnel, l’adresse CoA du MR et l’adresse du HA comme point de sortie du tunnel. Le tunnel du HA vers le MR a comme point d’entrée, l’adresse du HA et comme point de sortie, l’adresse CoA du MR. Tout le trafic IPv6 depuis et vers le réseau mobile NEMO transite par ce tunnel bidirectionnel. Quand un noeud correspondant CN envoie un paquet de données à un noeud MNN dans le réseau mobile NEMO, ce paquet est reçu par le HA qui l’achemine au MR par ce tunnel. L’envoi du paquet dans le tunnel est fait en employant l’encapsulation IPv6-dans-IPv6, arrivant au routeur mobile, il le dé-encapsule et le transmet au noeud MNN. Pour le trafic lancé par le réseau mobile, le MR emploie la direction inverse du tunnel, mais avant ; il doit s’assurer que le trafic provient bien d’un des noeuds du réseau mobile si non, il rejette le paquet.
|
Table des matières
Introduction générale
Chapitre1 : Généralité sur NEMO
1.Introduction
2. problématique
3 .Définition
4 .Les applications
4.1. Les réseaux de capteurs
4.2. Les réseaux d’accès à Internet
4.3. Les réseaux personnels
5. Caractéristiques
5.1. Taille .
5.2. Hétérogénéité des MNNs
5.3. Mobilité enchaînée
5.4. Hétérogénéité des réseaux d’accès
5.6. Interaction entre réseau Ad Hoc et réseau mobile
5.7. Fréquence distincte de changement du point d’ancrage
5.8. Variation dynamique de débit
6 .L’architecture de NEMO
7. fonctionnalité
8. Les avantages et Les inconvénients
9. Conclusion
Chapitre2 : Gestion de mobilité
1. Introduction
2. Type de mobilité.
2.1. Micro-mobilité
2.2. Macro-mobilité
3. Définition de Handover
4. Les raisons pour exécuter un Handover
4.1. Qualité signal
4.2. Le trafic
5. Les différentes phases du Handover
5.1. Phase de découverte
5.2. Phase de décision
5.3. Phase d’exécution du Handover
6. Type de Handover
6.1. Hard Handover
6.2. Soft Handover
6.3.Fast Handover
6.4.Smooth Handover
6.5. Handover sans coutures ou Seamless Handover
7. Les paramètres de qualités de service
7.1. Le délai
7.2. La gigue
7.3. Le taux de perte de paquet
7.4. Le débit
8. Analyse du délai du Handover NEMO
8.1. Délai du Handover L2
8.2. Délai du Handover L3
8.3 .Evaluation numérique
9. Conclusion
Chapitre3 : simulation & résultats
III. 1. Introduction
III. 2. Présentation de logiciel
III. 2.1. Définition de NS2
III. 2.2. Composants
III. 2.3. Organisation du simulateur
III. 2.4. Architecture du réseau
III. 2.5. Création d’un scénario
III. 2.6. Les modules nécessaires pour la simulation
III. 2.6.1. Module de découverte voisin
III. 2.6.2. Le service MIH (Media Independant Handover) .
III. 2.6.2.1. Présentation du standard IEEE802.21
III. 2.6.3. La gestion de mobilité MIPv6
III. 2.7. Paramétrage et configuration du réseau
III. 2.7.1. Les paramètres de simulation
III. 2.7.2. Les paramètres de réseau Wifi
III. 2.7.3. Configuration du point d’accès
III. 2.7.4. Paramètres du réseau WiMAX
III. 2.7.5. Configuration de la station de base (WiMAX1)
III. 2.7.6. Configuration de la station de base (WiMAX2)
III. 3. Simulations
III. 3.1.La topologie de réseau sous NS2
III. 3.2. débit
III. 3.3. Nombre des paquets perdus
III. 3.4. délai de transmission
III.4. Conclusion
Conclusion générale
Télécharger le rapport complet
