Memoire Online - Greedy perimeter stateless routing sur omnet++

TABLEAU 6.1. CONFIGURATION DE L'ORDINATEUR DE DÉVELOPPEMENT........................44

Depuis quelques années, le besoin d'être connecté est devenu fondamental pour l'homme. Ce besoin pose de plus en plus de défis pour la technologie moderne l'obligeant à plus d'innovation et de créativité. Ainsi, de nouvelles technologies sont apparues comme les réseaux sans fil, et les réseaux Ad Hoc.

Ces réseaux se sont vite répandus depuis les lieux de travail aux domiciles en passant par les aires de distraction. Ainsi, l'introduction de ces réseaux dans les voitures est devenue une chose indispensable; d'où l'apparition des réseaux Ad Hoc véhiculaires ou VANet (Vehicular Ad Hoc Networks). Les VANet visent à déployer la communication et l'échange d'informations entre les usagers de la route.

Plusieurs groupements industriels ont lancé des projets diverses pour le déploiement et la promotion des VANet dont le Car 2 Car Consortium qui est un consortium de grandes sociétés automobiles et informatiques.

Dans les réseaux de mobiles, la topologie a un caractère relativement éphémère dû à la mobilité des noeuds. Pour cette raison, les protocoles de routage les plus étudiés pour ce type de réseaux sont les protocoles de routage géographiques car ils permettent d'éviter la surcharge d'informations échangées entre les noeuds qui chercheraient à obtenir la topologie du réseau ou des tables de routage.

Le GPSR (Greedy Perimeter Stateless Routing) est un protocole de routage géographique qui garantit un passage à l'échelle car seules les informations locales sont stockées et utilisées, donc vise à optimiser le routage d'informations entre les véhicules.

Ce protocole étant dans l'état expérimental, une simulation s'impose. Ainsi, ses performances seront évaluées dans un cadre proche du contexte réel permettant son amélioration et la facilitation de son implémentation réelle.

C'est dans ce cadre que s'inscrit notre projet. Nous sommes amenés à simuler le protocole pour permettre une meilleure évaluation de ses performances.

Notre travail se scinde en deux parties essentielles. La première est l'étude théorique qui portera sur les technologies utilisées, le principe du routage Car 2 Car et la description du protocole GPSR. La deuxième partie consiste à simuler ce protocole sur le simulateur OMNet++.

Chapitre 1: Etat de l'art

Introduction:

L'apparition des réseaux VANet a rendu possible la communication entre les voitures répandant ainsi l'échange d'information. Ce chapitre débute par la description des technologies utilisées dans les réseaux véhiculaires. Il introduit la notion du v2v et il finit par présenter quelques applications de ces réseaux.

1. Technologies des réseaux véhiculaires:

Les réseaux véhiculaires offrent une alternative intéressante aux réseaux cellulaires vus leur faible coût et le débit élevé qu'ils offrent. Ils se basent sur les technologies sans fils.

1.1. WiFi:

C'est une technologie qui vise à offrir un accès au Web sans fil et à haut débit. Le WiFi permet d'affiner le maillage Internet, de rendre l'accès à internet plus confortable et particulièrement de préparer une bonne infrastructure pour les réseaux véhiculaires. En fait, les réseaux WiFi permettent de faire communiquer des équipements compatibles en se basant des normes et des protocoles communs qui se manifeste à travers des bornes d'accès publiques appelées Hot Spots qui se trouvent un peu partout: restaurants, aéroports, facultés, etc...

La norme 802.11 s'attache à définir les couches basses du modèle OSI pour une liaison sans fil utilisant des ondes électromagnétiques, c'est-à-dire :

· la couche liaison de données, constitué de deux sous-couches : le contrôle de la liaison logique (Logical Link Control, ou LLC) et le contrôle d'accès au support (Media Access Control, ou MAC)

1.2. Réseaux Ad Hoc:

Les réseaux ad hoc en latin : « qui va vers ce vers quoi il doit aller », c'est-à-dire « formé dans un but précis », sont des réseaux sans fil capables de s'organiser sans infrastructure définie préalablement.

Chaque entité (ou node) communique directement avec sa voisine dans la zone de couverture comme l'indique le figure 1.1. Pour communiquer avec d'autres entités, il lui est nécessaire de faire passer ses données par d'autres qui se chargeront de les acheminer. Pour cela, il est d'abord primordial que les entités se situent les unes par rapport aux autres, et soient capables de construire des routes entre elles : c'est le rôle du protocole de routage.

Ainsi, le fonctionnement d'un réseau Ad-hoc le différencie notablement d'un réseau comme le réseau GSM, les réseaux Wifi avec des points d'accès : là où une ou plusieurs stations de base sont nécessaires à la plupart des communications entre les différents noeuds du réseau (mode Infrastructure), les réseaux Ad-hoc s'organisent d'eux-mêmes et chaque entité peut jouer différents rôles.

L'utilisation la plus simple et la plus courante des réseaux Ad-hoc est faite par les réseaux sans fil Wifi en permettant une mise en place rapide d'une connexion réseau entre deux ordinateurs.

Les réseaux ad hoc mobiles, sont connus sous le nom de MANet (pour Mobile Ad-hoc Networks).

Un réseau MANET permet de mettre en oeuvre des noeuds de communication de grande mobilité, de grande réactivité et qui se déploient rapidement. Ce réseau est interconnecté avec différents types réseaux reposant sur une technologie IP et employant des protocoles de routage tant dans la famille des réactifs (AODV, DSR) que des proactifs (OLSR, TBRPF), ou bien encore des hybrides (ZRP).

1.3. Réseaux VANet:

Vehicular Ad-Hoc Network (réseau Ad-Hoc de véhicules), ou VANet, est une forme de Mobile Ad-hoc Network (réseau mobile Ad-Hoc), pour fournir des communications au sein d'un groupe de véhicules à portée les uns des autres et entre les véhicules et les équipements fixes à portée, usuellement appelés équipements de la route.

Plutôt que de se déplacer au hasard, les véhicules tendent à se déplacer d'une façon organisée. Les interactions avec les équipements de la route peuvent de même être caractérisées de manière assez exacte. Et finalement, la plupart des véhicules sont limités dans leur gamme de mouvement, par exemple en étant contraint de suivre une route pavée.

L'idée, déjà évoquée auparavant, est de permettre aux voitures de communiquer entre elles. Sous les initiales C se cache donc un système d'échange d'informations qui va permettre de meilleures réactions dans des situations comme des bouchons, des routes gelées, enneigées, des accidents de la route etc ...

De cette manière, tous les futurs véhicules équipés du système Car2Car seront capables de communiquer entre eux, quelle que soit leur marque, afin de véhiculer des informations importantes. Les relais sont tout simplement les véhicules qui acheminent l'information de l'un à l'autre sans avoir à passer par un maillage d'émetteurs et récepteurs externes pour couvrir le territoire. L'exemple introductif donné par Car2Car est simple. Imaginez qu'un accident arrive sur la route que vous prenez, quelques kilomètres devant vous. Les véhicules accidentés vont envoyer un signal aux voitures arrivant sur le lieu de l'accident. Ces dernières vont reproduire l'information vers les voitures derrières elles et ainsi de suite. De cette manière, les automobilistes pourront être prévenus quasiment en temps réel des accidents de la circulation et ils pourront modifier leur itinéraire en conséquence. Cet exemple peut être appliqué à d'autres cas de figure qui ne concernent pas forcément un accident mais d'autres aléas du trafic. On peut imaginer que Car2Car pourra également concerner un problème sur un véhicule en panne ou accidenté seul dans un endroit inaccessible. L'information sera alors transmise de voiture en voiture jusqu'au point de surveillance central de l'état de la circulation et du trafic jusqu'aux premiers secours. Car2Car est basé sur la norme WiFi 802.11.

A côté des applications sur la conduite et le trafic, Car2Car sera particulièrement bien adapté à d'autres émissions et réceptions d'informations en temps réel. Car2Car annonce déjà qu'à travers cette norme, il sera possible de récupérer de la musique depuis son PC installé dans sa maison vers sa voiture et vice versa. Le figure 1.3 illustre la communication entre deux voitures pour gérer le trafic.

Parmi les nouvelles technologies sans fil utilisés par les conducteurs et les passagers, à courte portée de la communication sans fil basé sur IEEE 802.11 qui a reçu une attention considérable dans le monde entier.

Grâce à son faible coût, sa disponibilité et son déploiement à grande échelle, il est attendu que les futures voitures seront équipées de dispositifs de bord d'unités offrant des interfaces sans fil IEEE 802.11 et les antennes.
La technologie sans fil permet une répartition intégrale des véhicules de communication dans un réseau basé sur l'auto-organisation et d'auto-coordination des noeuds du réseau ad hoc. La combinaison de la technologie courte-portée de la communication sans fil et des réseaux ad hoc, facilite la communication voiture - infrastructure regroupés sous CAR-2-I, et elle est considérée comme une pierre angulaire pour l'avenir des systèmes de transport intelligents (ITS).

Un objectif majeur de la CAR-2-I est l'amélioration de la sécurité de la route la réduction durable de décès dus aux accidents de la route. En outre, la communication CAR-2-I permet aux d'améliorer l'efficacité du trafic et l'infotainment, où les fréquences dédié sera alloué pour la sécurité et l'efficacité de la circulation pour la fréquence considérée.

C' est pourquoi une grande gamme de possibilités est offerte , pour un intérêt commun et public, de la part des gouvernements, et du monde industriel pour standardiser et déployer la technologies CAR-2-X technologies de la communication existe.

Ø Transfert de données (musique MP3, fichiers en provenance du bureau ou de la maison)

Conclusion:

Nous avons présentés dans ce chapitre les technologies sur laquelle se base les réseaux VANet, les différents modes de routage de l'information et quelques applications de ces réseaux. Dans le chapitre suivant nous traiterons le protocole GPSR dans le cadre du routage C et ses différentes fonctionnalités.

Chapitre 2: Le protocole GPSR

Introduction:

Dans les réseaux de mobiles s'interconnectant sans hiérarchie tels que les réseaux ad hoc, la topologie a un caractère relativement éphémère dû à la mobilité des noeuds. Pour cette raison, les protocoles de routage les plus étudiés pour ce type de réseaux sont les protocoles de routage géographiques car ils permettent d'éviter la surcharge d'informations échangées entre les noeuds qui chercheraient à obtenir la topologie du réseau ou des tables de routage.

Ces protocoles de routage géographique se basent sur le fait que tous les noeuds connaissent leur position, par exemple, grâce à un équipement GPS (Global Positioning System) ou encore par un système de positionnement distribué.

Il existe plusieurs protocoles qui définissent différentes manières d'obtenir la position d'un noeud : ce sont les protocoles de localisation. Parmi les principaux, on peut citer SLURP, SLALOM, HGRID, GLS. Une fois la position obtenue, il reste à acheminer le message. Pour ce faire, plusieurs protocoles de routage géographique sont à l'étude : GEAR, DREAM, GPSR.

Nous avons choisi de nous baser sur GPSR. Ce dernier est un protocole de routage géographique qui garantit un passage à l'échelle car seules les informations locales sont stockées et utilisées.

Lorsque GPSR se trouve face à une zone de vide, il passe du mode greedy au mode perimeter. Ce faisant, il va choisir le prochain saut par rapport à la règle de la main droite . Ce choix a un caractère arbitraire et ne tient pas compte de la possibilité qu'il y ait plus d'opportunités d'acheminement d'un côté ou d'un autre.

GPSR (Greedy Perimeter Stateless Routing) est un protocole de routage réactif et efficace qui a été conçu et adapté pour les réseaux ad hoc mobiles et les réseaux de capteurs. Son modèle de fonctionnement suppose que tous les noeuds se trouvent au niveau d'un même plan. Du fait de la mobilité des noeuds, certains algorithmes de routage qui se basent sur la topologie du réseau, ou lance une phase de découverte de routes pour acheminer des données ne sont pas adaptés à GPSR. De ce fait, il utilise la position géographique des noeuds pour l'acheminement des paquets de données ou de contrôle.

Dans un réseau mobile, les noeuds sont susceptibles de se déplacer. Il faut ainsi un mécanisme permettant à chaque noeud se savoir la position de ses voisins. Afin de signaler leur présence et leur localisation, les noeuds inondent le réseau en envoyant un paquet de signalement (messages « beacon») contenant la position et un identifiant (par exemple, son adresse IP). Nous proposons d'utiliser les messages « beacon » de contrôle pour renseigner les noeuds voisins sur les directions que peuvent assumer un noeud.

L'échange périodique de ces paquets de contrôle permet aux noeuds de construire leur table de position. La période d'émission des messages « beacon » dépend du taux de mobilité dans le réseau ainsi que de la portée radio des noeuds. En effet, lorsqu'un noeud ne reçoit pas de message « beacon » d'un voisin après un temps T, il considère que le voisin en question n'est plus dans sa zone de couverture et l'efface de sa table de position. Il faut donc adapter le temps d'émission des paquets de contrôle. Un des avantages du BP (Beaconing Protocol) est que chaque noeud n'a besoin que des informations sur ses voisins directs, ce qui nécessite peu de mémoire.

Alternativement, le protocole GPSR permet au noeud d'encapsuler sur quelques bits leur position dans les paquets de données qu'il envoie. Dans ce cas, toutes les interfaces des noeuds doivent être en mode promiscuité afin de recevoir les paquets s'ils se trouvent dans la zone de couverture de l'émetteur.

L'acheminement des paquets par GPSR se fait selon deux modes suivant la densité du réseau : le « Greedy Forwarding » et le « Perimeter Forwarding » (appelés respectivement GF et PF dans la suite).

Le GF construit un chemin parcourant les noeuds de la source à la destination où chaque noeud qui reçoit un paquet l'achemine en faisant un saut vers le noeud intermédiaire le plus proche de la destination dans sa zone de couverture. La figure 2.1 montre un exemple de ce mode d'acheminement.

Cet algorithme d'acheminement offre un taux de réussite assez proche des réseaux filaires dans le cas où la mobilité de la destination n'est très forte. Lorsqu'un paquet de données atteint une région où le GF échoue, alors le PF est utilisé.

Cet algorithme utilise la règle de la main droite qui est définie comme suit : Lorsqu'un paquet arrive à un noeud x du noeud y, le chemin à suivre est le prochain qui se trouve dans le sens inverse des aiguilles d'une montre en partant de x et par rapport au segment [xy] tout en évitant les « crossing links » (route déjà parcourue). La figure 2.3 montre un exemple plus précis de ce mode.

Pour augmenter le taux de réussite d'acheminement des paquets, GPSR utilise les deux algorithmes en fonction de la densité locale du réseau. Chaque noeud construit un graphe du réseau lui permettant de diminuer les possibilités de routage. Ce graphe, le Gabriel Graph (GG) permet de représenter le réseau avec moins de noeuds pour éviter les « crossing links ». Le GG est un ensemble de noeuds {Wi, Wi+1, ...Wi+n} tel qu'il existe aucun noeud dans la portion de disque de rayon d(Wi, Wi+1) à portée des deux noeuds concernés, avec Wi+1 étant noeud le plus éloigné dans la zone de couverture de Wi.

Figure 2.4 : Pour que {u,v} ° GG, il faut qu'il n'existe aucun noeud dans le disque.

Ces éliminations n'introduisent pas de déconnexions dans le cas de réseaux uniformes.

Ce protocole détermine la route à suivre en minimisant les distances entre les noeuds et la destination (c'est le mode Greedy Forwarding), mais un second mécanisme est mis en oeuvre en cas de blocage (c'est le mode Perimeter). Dans ce cas, le noeud n'ayant pas de voisin plus proche (en distance) que lui de la destination passe le relais à ses voisins qui eux peuvent avoir un voisin plus proche de la destination (en distance). Sur la Figure 2.5, le noeud B utilise le mode Perimeter car il n'a pas de voisin plus proche en distance de la destination finale G, ce qui permet de trouver une route passant par le noeud C qui, lui, peut à nouveau utiliser le mode Greedy Forwarding ayant un voisin plus proche de G (en l'occurrence D).

Conclusion:

Tout au long de ce chapitre, nous avons vu le fonctionnement général du protocole GPSR. Nous avons aussi détaillé les composantes principales du protocole. Nous allons voir dans le chapitre suivant le principe de simulation, les différents simulateurs disponibles et le simulateur choisi.

Introduction:

Dans une simulation d'événement discret, le travail d'un système est présenté par le déroulement chronologique de séquences d'événement. Chaque événement se produit à un instant bien déterminé et marque un changement d'état dans le système.

Une simulation d'événement discret a pour but de visualiser l'état du système à n'importe quel instant donnée.

De telles simulations obéissent à une logique de conception qui permet de valoriser certain aspect du système, comme par exemple dans notre cas, l'efficacité du protocole à échanger les données entre noeuds mobiles.

Pour cela on présente le processus de simulation que nous avons adopté pour l'élaboration de notre projet.

1. Les simulateurs:

Les besoins croissants de tester les nouvelles technologies et les nouveaux protocoles avant leur déploiement a conduit à la prolifération des simulateurs. On peut les classer en deux types: les logiciels libres et gratuits tels que OMNet++, J-Sim et NS2... et les logiciels commerciaux tels que OPNET et NetRule...

1.1.1. Présentation:

NS2 est un outil de simulation de réseaux de données. Il est bâti autour d'un langage de programmation appelé Tcl dont il est une extension. Du point de vue de l'utilisateur, la mise en oeuvre de ce simulateur se fait via une étape de programmation qui décrit la topologie du réseau et le comportement de ses composants, puis vient l'étape de simulation proprement dite et enfin l'interprétation des résultats. Cette dernière étape peut être prise en charge par un outil annexe, appelé nam qui permet une visualisation et une analyse des éléments simulés.

NS2 est en réalité un programme relativement complexe écrit en C++ et interfacé via Tcl. Pour modifier le comportement d'objets existants, il est donc nécessaire de modifier le code C++ qui en réalise l'implantation.

TCL (Tool Command Language) est un langage de commandes qui sert à contrôler les applications. C'est essentiellement un langage de scripts offrant des structures de programmation telles que les boucles, les procédures ou les notions de variables.

Application	Web, FTP, Telnet, générateur de trafic(CBR, ..)
Transport	TCP, UDP, RTP, SRM
Routage	Statique, dynamique (vecteur distance) et routage multipoint (DVMRP, PIM)
Gestion des files d'attente	RED, Drop Tail, Token bucket
Discipline de service	CBQ, SFQ, DRR, Fair queueing
Système de transmission	CSMA/CD, CSMA/CA, lien point à point

1.1.3. Modèles de mobilité:

NS-2 implémente deux modèles de mobilités :

Ce modèle génère un mouvement aléatoire du noeud de façon que le noeud choisie sa prochaine destination d'une manière aléatoire en se déplaçant avec une vitesse aléatoire constante.

C'est un mouvement généré par un scénario qui consiste à ce que l'utilisateur donne une destination bien précise et une vitesse de déplacement constante.

1.1.4. Structure d'un noeud mobile dans NS2:

1.2. Le simulateur OMNet++:

1.2.1. Présentation:

Dans ce projet, nous allons réaliser nos expérimentations à l'aide d'OMNET++ qui est un simulateur à évènements discrets orienté objet, basé sur C++. Il a été conçu pour simuler les systèmes réseaux de communication, les systèmes multi processeurs, et d'autres systèmes distribués. OMNET++ est un projet open source dont le développement a commencé en 1992 par Andras Vargas à l'université de Budapest.

Actuellement, Ce simulateur est utilisé par des dizaines d'université pour la validation de nouveaux matériels et logiciels, ainsi que pour l'analyse de performance et l'évaluation de protocoles de communication.

L'avantage de OMNET ++ est sa facilité d'apprentissage, d'intégration de nouveaux modules et la modification de ceux déjà implémentés. Nous introduisons dans la suite l'architecture du simulateur OMNET++ et les librairies Mobility Framework et INET.

L'architecture d'OMNET++ est hiérarchique composé de modules. Un module peut être soit module simple ou bien un module composé. Les feuilles de cette architecture sont les modules simples qui représentent les classes C++. Pour chaque module simple correspond un fichier .cc et un fichier .h. Un module composé est composé de simples modules ou d'autres modules composés connectés entre eux. Les paramètres, les sous modules et les ports de chaque module sont spécifiés dans un fichier .ned.

La communication entre les différents modules se fait à travers les échanges de messages. Les messages peuvent représenter des paquets, des trames d'un réseau informatique, des clients dans une file d'attente ou bien d'autres types d'entités en attente d'un service. Les messages sont envoyés et reçus à travers des ports qui représentent les interfaces d'entrer et de sortie pour chaque module.

La conception d'un réseau se fait dans un fichier .ned et les différents paramètres de chaque module sont spécifiés dans un fichier de configuration (.ini). OMNET++ génère à la fin de chaque simulation deux nouveaux fichiers omnet.vec et omnet.sca qui permettent de tracer les courbes et calculer des statistiques.

1.2.3. Composants:

Application :	FTP, Telnet, générateur de trafic (IPTrfGen..), Ethernet, Ping App, UDPApp, TCPApp
Transport :	TCP, UDP, RTP
Réseau :	IPv4, IPv6, ARP, OSPF, LDP, MPLS, ICMP, TED...
Liaison :	Mgmt, MAC, Radio
Node :	Ad Hoc, Wireless, MPLS...

1.2.5. Frameworks:

1.2.5.1. Mobility Framework:

La librairie MF est une extension du simulateur OMNeT++. Elle a été développée par une équipe de chercheurs à l'université de Berlin. Sa dernière version a été proposée par Marc Loebbers en Octobre 2003. Cette librairie est destinée à soutenir les réseaux sans fil et mobiles au sein de simulations OMNeT++. En effet, elle permet une bonne manipulation des noeuds mobiles et la gestion des connexions dynamiques pour avoir un modèle de mobilité de réseau sans fils qui fournie des résultats le plus proche possible du monde réel. En outre, MF prévoit des modules de base qui peuvent être utilisés pour former de nouveaux modules. Avec ce concept, un programmeur peut facilement développer ses propres protocoles avec l'interface nécessaire.

Aujourd'hui, il y'a un développement d'une bibliothèque de protocoles normalisés pour la MF (802,11, AODV, ...), dont l'objectif est de disposer d'une bibliothèque riche de ces protocoles afin de permettre facilement Plug-and-Play des simulations de différents types de protocoles largement utilisés.

La base pour toutes les classes des modules de la couche physique est ChannelAccess qui est à son tour dérivée de BasicModule. La seule fonctionnalité que fournit ChannelAccess est la connectivité au Channel (i.e. aux autres noeuds). La fonction sendToChannel () doit être utilisée pour passer des messages au Channel. Elle enverra le message pour chaque gate connecté du module de l'hôte.

Il existe deux versions de PhyLayer. La première version est appelée P2PPhyLayer, elle assume les connections point à point entres les hôtes. C'est la plus simple couche physique que l'on puisse utiliser. Pour la seconde version, elle est appelé Nic80211 dont les fonctionnalités de la couche physique ont étés divisées en 3 modules simples qui sont Decider80211a, SnrEcal80211a et Mac80211a.. Les calculs de SNR ont été laissées séparés du Decider à cause des bits errors. Ce concept rend la création modules Decider qui utilisent le même SnrEval module plus facile, et vis versa.

On peut par exemple définir un module Decider qui compare les calculs de SNR avec un qui utilise le forward error correction et les deux modules peuvent utiliser le même SnrEval module.

La classe Mac80211a est une implémentation de la norme IEEE 802.11a. Nous nous sommes basés sur [Std00] pour extraire les différents paramètres comme le calcul de la durée de transmission packetDuration(), la taille la fenêtre de contention et les durées des périodes ST, SIFS, DIFS, EIFS.

Le module SnrEval simule un délai de transmission pour tous les messages reçus et calcule les informations SNR. Le BasicSnrEval ne tient pas compte des retards de propagation. Les SNR informations sont stockées dans un SnrList. Chaque entrée SnrList contient un timestamp et un SNR de la valeur de ce timestamp. HandleLowerMsg () est subdivisé en handleLowerMsgStart () et handleLowerMsgEnd (). En outre, nous avons défini un bufferMsg (). Juste après, un message est reçu handleLowerMsgStart (). En outre, le rapport signal / bruit de tous les renseignements d'autres messages dans le tampon de réception devrait être mis à jour si vous le souhaitez. Ensuite, le message est tamponné (fonction bufferMsg ()) pour simuler un délai de transmission. Entre temps, il y a d'autres messages qui peuvent arriver mais ils interférent avec la mémoire tampon du message, et par conséquent, il en résulte de nouvelles entrées SnrList supplémentaires pour indiquer un changement de SNR pour ce message.

Une fois la transmission est achevée (c'est-à-dire le message est complètement reçu), handleLowerMsgEnd () est appelé juste avant que le message soit transmis au Decider module. Ici, le message devrait être supprimé du tampon de réception et de la SnrList contenant les informations SNR calculés, ainsi les valeurs devraient être passée en argument à la sendUp (). La fonction sendUp() est celle qui assure la transmission du paquet vers la couche supérieure .

Nous croyons que notre concept permet à tous ces différents modèles, sans être trop complexe, mais en même temps d'être assez sophistiqués pour soutenir également des modèles complexes.

Le module Decider ne traite que les messages provenant de la chaîne (c'est-à-dire à partir de
la couche inférieure). Les messages provenant des couches supérieures, ayant contourné le module Decider, sont directement remis au module SnrEval. Les décisions concernant la perte ou les erreurs sur les bits messages ne doivent être faites au sujet de messages provenant de la chaîne. En conséquence, il n'est pas nécessaire de traiter les messages provenant de couches superficielles du module Decider.

Quand vous évaluez la performance d'un protocole, vous avez besoin de renseignements sur le contrôle interne les changements d'état de votre protocole, peut-être même à partir de protocoles que vous utilisez. Vous pouvez suivre ces changements, en utilisant par exemple vecteur de fichiers dans votre protocole et supprimer ces moniteurs une fois que vous l'avez fait. Une autre façon est d'utiliser un tableau noir. L'état des changements sont publiés sur lui, et les moniteurs de souscrire ces valeurs. Cela permet à d'autres chercheurs d'exploiter votre protocole d'évaluation de la performance, tout en imposant presque aucun moment de l'exécution de la peine lorsque l'information n'est pas nécessaire. Peut-être même plus important encore, le tableau noir vous permet d'échanger des informations entre les couches, sans passer des pointeurs vers les modules autour. Il existe plusieurs méthodes permettant à l'abonné d'utiliser le tableau noir, parmi ces méthodes, on peut citer le BasicModule : qui fournit tout le nécessaire pour interagir avec le tableau noir. Il est dérivé de ImNotifiable qui est une classe de base virtuelle pure qui permet d'informer le tableau de votre module de changements.

Cette section décrit l'architecture de la mobilité utilisée dans la MF. Il ya deux questions à examiner concernant une architecture de mobilité dans un cadre de simulation. La première question est de savoir où traiter les d'informations sur la mobilité et la deuxième est comment gérer les mouvements des hôtes. Où et comment gérer dynamiquement les connexions de manière efficace est la deuxième décision à prendre. Nous avons décidé de gérer la mobilité d'une manière distribuée localement dans chaque module hôte. La gestion de la connexion est gérée par un contrôleur central. La composante de base de l'architecture de la MF est le module ChannelControl avec un hôte MobilityModule. ChannelControl s'occupe de tous les paramètres liés à la connexion alors que les MobilityModules ont deux tâches principales: la première tâche est de gérer les mouvements de l'Hôte qui peut être fait en utilisant différents modèles de la mobilité (comme le Manhattan Mobilité ou le mouvement brownien), alors que le second rôle des MobilityModules est de communiquer pour contrôler l'évolution de l'hôte au ChannelControl. Dans l'étape qui suit le ChannelControl met à jour toutes les connexions pour ces hôtes.

Le module ChannelControl est chargé d'établir des canaux de communication entre les modules d'accueil (qui sont à distance de communication) ainsi que de rompre ces liens une fois qu'ils perdent la connectivité à nouveau. La perte de la connectivité peut être due à la mobilité (c'est-à-dire les hôtes se déplacent trop loin) ou en raison d'un changement dans la transmission de puissance ou d'un hôte. Nous avons décidé de garder le concept de liens entre les modules d'accueil, par opposition au passage de message direct, en effet les voies de communication sont une source importante de déboggage des informations.

Malheureusement, dans OMNeT + + les liens entre les différents modules ont besoin d'au moins deux gates objets pour chaque module, un appelé IN et un autre appelé OUT sur la porte (et pour chaque sous module). Pour notre MF, le nombre minimal de portes de lien est six vu que le module Nic est intégré dans le module hôte et est elle-même subdivisée en un SnrEval et un module Decider Mac. Une approche de mémoire plus efficace est de créer dynamiquement des portes. Les gates ne sont pas attribués à l'initialisation du réseau, mais créés dynamiquement sur demande. Chaque module possède deux hôtes listes un pour free-in-gate et un pour le free-out-gate. Une fois le module ChannelControl veut établir un lien entre deux hotes, il regarde d'abord le gate dans la listes d'Hôtes pour savoir si les portes sont disponibles, si il n'existe aucune porte libre un nouveau est créé immédiatement. Lors de rupture de lien ChannelControl à la connexion on ajoute les portes nouvellement libéré à la porte de la liste correspondante. Avec cette approche, nous réduisons la mémoire nécessaire sans augmenter les frais généraux de calcul. Dans les simulations de réseau sans fil, non seulement le fait de savoir si deux hôtes sont connectés (c'est-à-dire de communiquer les uns avec les autres) est important, mais aussi le fait de savoir que les deux machines peuvent interférer les uns avec les autres.

1.2.5.2 INET:

INET est une librairie open source pour la simulation des réseaux informatiques dans l'environnement OMNeT++. Elle contient IPv4, IPv6, TCP, UDP, des protocoles implémentés, et plusieurs modèles d'application. Elle comprend également un modèle avec MPLS RSVP-TE et de signalisation LDP. La couche liaison sont des modèles de PPP, Ethernet et 802.11.Le routage statique peut être configuré à l'aide du réseau auto configurateur, ou on peut utiliser le protocole de routage mise en oeuvre.

INET prend en charge les simulations des réseaux sans fil et mobiles, ainsi les réseaux ad-hoc. Récemment les modèles MPLS, RSVP-TE et LDP sont révisés et réécrit, sans oublier le routage dynamique (RIP et OSPFv2).

Dans ce paragraphe, nous allons présenter une étude de l'existant de la librairie INET et plus précisément l'implémentation des couches PHY, MAC, IP, RTP, UDP et TCP dans INET.

La couche physique est la partie essentielle d'un noeud sans fil. Il est responsable de l'envoi et la réception de message, détection de collision, et calcul d'erreur sur les bits. La couche physique est divisée en trois parties, qui sont décrites en détail dans les sous-sections suivantes :

· PhyLayer fournit les interfaces de la couche MAC et de la couche physique des autres noeuds.

· AnalogueModels sont responsables pour la simulation de l'atténuation d'un signal reçu.

· le Decider est responsable de l'évaluation et de démodulation des messages reçus.

A ce qui concerne notre projet, on a besoin la couche physique IEEE 802.11b qui est déjà implémentée dans OMNET++ dés 2006.

La couche MAC IEEE 802.11b est implémentée dans la librairie INET, elle supporte le mécanisme RTS/CTS. Il n'y a que l'algorithme DCF implémenté, le PCF n'est pas implémenté. Le débit de transmission physique est constant pendant la simulation.

Le simulateur OMNET++ contient deux classes de bases pour former la couche MAC :

· EyesMACLayer fournie un ensemble de fonction dont l'importante est de renvoyer les informations concernant la couche MAC d'un noeud.

Dans notre cas la couche MAC IEEE 802.11b est implémentée dans la librairie INET en utilisant RTS/CTS. Il n'y a que l'algorithme DCF implémenté, le PCF n'est pas implémenté. Le débit de transmission physique est constant pendant la simulation. Aucun des algorithmes d'adaptation du débit de transmission physique n'est implémenté. Les paquets multipoints au niveau MAC sont envoyés de la même manière que les paquets broadcast. Le filtrage de ces paquets se fait au niveau IP.

L'Internet Protocol (IPSuite) fournit des IPv4, TCP et UDP dans les modèles de simulations
OMNeT + +. D'abord, il a été développé par plusieurs personnes à l'Université de Karlsruhe. À la fin de l'année 2003, l'auteur de OMNeT + +, Andras Varga, a repris l'entretien de l'ensemble IPsuite. Il a également créé plus de documentation pour le paquet, ce qui rend plus facile à utiliser et faire des ajustements pour le modèle. Dans le même temps, un modèle l'IPv6 a été créé. Mais le routage IP est de implémenté de manière statique. Alors, l'utilisateur doit configurer les adresses IP et les adresses de groupes multicast dans les tables de routages avant la simulation. C'est au niveau IP que se passe le filtrage des paquets multicast.

Le routage multipoint au niveau IP est déjà implémenté mais de manière statique. C'est à dire que l'utilisateur doit configurer les adresses IP et les adresses de groupes multicast dans les tables de routages avant la simulation. C'est au niveau IP que se passe le filtrage des paquets multicast.

La couche RTP présente le niveau transport, elle n'est pas encore intégrée dans la librairie INET. Dans la version 20061020, il y a une implémentation de la couche RTP réalisé par Matthias Opptiz et ajouté par Andras Vargas mais elle n'est pas encore intégrée. Le problème de cette implémentation est qu'elle a été faite dans une ancienne version de l'année 2001 et que l'architecture globale de la librairie INET a changé.

La couche UDP est implémentée dans la librairie INET. Elle présente le niveau transport et elle est très utilisable dans la simulation car son implémentation est simple et elle est rapide par rapport aux autres couches de même niveau.

Dans la librairie INET, cette couche est une couche de transport comme UDP et RTP et elle est implémentée à l'aide des sockets.

Elle présente la couche supérieure. De nombreuses applications sont implémentées dans la librairie INET comme Ethernet, TCPApp, PingApp, UDPApp.

2. Le choix du simulateur adéquat:

2.1. Besoins généraux:

Pour pouvoir choisir le meilleur simulateur, il faut spécifier nos besoins. Nous devons disposer de:

Module ARP:

Ce module du noyau implémente le protocole de résolution d'adresse ARP. Il sert à la conversion entre les adresses matérielles de niveau 2 et les adresses du protocole IPv4 sur les réseaux connectés en direct. L'utilisateur n'a normalement pas d'interactions avec ce module sauf pour le configurer. En fait ce module fournit des services aux autres protocoles du noyau.

Le module ARP maintient un cache des correspondances entre les adresses matérielles et les adresses logiques. Le cache a une taille limitée, ainsi les entrées anciennes et utilisées moins fréquemment sont récupérées. Les entrées qui sont marquées comme permanentes ne sont jamais effacées.

Ce module permet de fournir l'adressage MAC et encapsuler les paquets en trames 802.11.

Il est composé de 3 modules simples qui sont Decider80211a, SnrEcal80211a et Mac80211a. Comme le montre la figure 3.4, ce module possède deux interfaces de sortie avec la couche IP et avec le canal.

Module de mobilité:

Ce module fournit un modèle de mobilité qui permet de faire déplacer les noeuds.

Simulateur	OMNeT++	NS-2
Flexibilité	OMNeT++ est un simulateur flexible et générique, il peut simuler n'importe quel type de réseau. Par exemple, il peut être utilisé pour simuler les files d'attente, les systèmes multiprocesseurs, les architectures de matérielles (routeurs, les commutateurs optiques, les serveurs etc.). Plusieurs modèlent sont utilisables pour les différents domaines (INET Fw, Mobility Fw, OverSim, NesCT, MACSimulator, etc.)	NS-2 a été conçu comme un (TCP/IP) simulateur de réseau, et il est difficile de simuler les choses autre que paquet-commutant les réseaux et les protocoles.
Mobilité	OMNeT++ fournit plusieurs modes de mobilités comme le Random Waypoint Mobility Model, le Linear Mobility Model, le Constant Speed Mobility Model, le Basic Mobility Model, etc.	NS-2 ne fournit que le Random Waypoint Mobility Model et le Trajectory Based Mobility Model, ce qui rend difficile de présenter une mobilité linéaire.
La gestion de modèle	Le OMNeT++ noyau de simulation est une bibliothèque de classe, c'est à dire, les modèles dans OMNET++ sont indépendants du noyau de simulation. Les chercheurs ont écrit leurs composants (les modules simples) contre noyau de simulation API du simulateur.	Dans les NS-2, la limite entre le coeur de la simulation et les modèles sont barbouillés d'encre, sans un clair API.
Support pour Les Modèles Hiérarchiques	La structure hiérarchique dans OMNET++ facilite la complexité des méthodes.	Dans NS-2, les modèles sont plats, la création d'un sous réseau ou l'exécution d'un protocole complexe (composition de plusieurs unités indépendantes) n'est pas possible.
Support de traçage	OMNeT++ peut montrer les transmissions de paquets pendant une simulation.	Pas de traçage.
Documentation	La documentation est très bonne et contient tous ce qu'on a besoin pour la simulation (définitions, méthodes, modules, implémentations, etc).	Bonne documentation.
Habileté à courir les grands réseaux	OMNeT++ peuvent simuler une grande topologie de réseaux.	Les NS-2 ont beaucoup de problèmes dans la simulation des grandes topologies de réseaux.

Après une comparaison approfondie entre les deux simulateurs, nous constatons que NS2 ne peut pas supporter plusieurs noeuds dans la simulation ce qui dessert nos besoins d'implémentation.
C'est pour cette raison que nous optons pour le simulateur OMNet++.

Dans ce chapitre, nous avons comparé entre différents simulateurs et nous avons choisi celui qui est le plus apte à nous satisfaire. Le chapitre suivant présentera une spécification de notre projet avec une analyse des besoins à l'aide de diagrammes de cas d'utilisation.

Chapitre 4 : Analyse & Spécification

Introduction:

Après avoir présenté les notions de base nécessaires pour comprendre les fonctionnalités de notre projet, nous commençons ce chapitre avec une présentation de la problématique de notre projet. Ensuite, nous allons énoncer les spécifications de celui-ci en exposant les besoins fonctionnels et non fonctionnels du travail à réaliser. Enfin, nous enchaînons par la description des diagrammes de cas d'utilisation.

1. La problématique

Le but de ce projet est de simuler le protocole GPSR afin d'évaluer ses performances et pouvoir les comparer à celles d'autres protocoles. Cette simulation se déroulera sur le simulateur OMNet++. Ce protocole de routage permet d'acheminer l'information d'un véhicule à un autre tout en suivant l'évolution du réseau.

2. Besoins fonctionnels:

Notre travail consiste à implémenter les différentes parties du protocole GPSR et les connecter à la couche applicative qui se trouve en dessus. Nous allons d'abord donner une description générale de ces besoins.

2.1. Description générale:

Ø Implémentation d'un module représentant un noeud mobile qui:

*se déplace selon un modèle de mobilité précis

*contient une couche réseau implémentée selon le protocole GPSR

*contient une couche applicative qui utilise la couche précédemment citée

Ø Simulation de l'échange de paquets entre les différents noeuds mobiles suivant des scénarios réalistes

2.2. Cas d'utilisation:

Le but de cette partie est de décrire les requis fonctionnels du programme selon le formalisme UML.

2.2.1. Cas d'utilisation du simulateur:

l Implémenter les noeuds :
* Modifier la structure de noeuds déjà existants dans OMNet++ pour y intégrer une couche réseau implémentée selon le GPSR.

l Définir une topologie :
*Regrouper les noeuds dans un réseau selon une topologie bien donnée grâce aux fichiers .NED de OMNet++

l Définir un modèle de mobilité:
*Choisir l'un des modèles de mobilité offert par la librairie INET.

l Créer un scénario:
*regrouper les éléments suivants pour créer un scénario plausible et voir l'échange des données.

l Simuler un protocole:
*Utiliser le scénario créé pour simuler un protocole.

l Évaluer les performances:
*Recueillir les données fournies par la simulation et les comparer avec ceux d'autres protocoles.

· La couche applicative du noeud n1 communique avec une application du noeud n2.

· La couche applicative du noeud n1 transmet des informations à la couche applicative du noeud n2 en passant par sa propre couche réseau.

· La couche applicative du noeud n2 reçoit les informations qui sont passées par sa couche réseau sous forme de paquet.

· La couche réseau du noeud n1 route le paquet en Greedy Mode tout en le passant à sa couche inférieure.

· La couche inférieure du noeud n2 reçoit le paquet et le passe à sa couche réseau.

· La couche réseau du noeud n2 route le paquet en Perimeter Mode et le supprime.

· La couche inférieure du noeud n3 passe le paquet à sa couche réseau qui le délivre à sa couche applicative.

Conclusion

Tout le long de ce chapitre, nous avons listé les besoins fonctionnels et non fonctionnels de notre projet accompagnés de diagrammes des cas d'utilisations. Nous allons détailler dans le chapitre suivant la conception de notre application à travers a les diagrammes de séquences, les diagrammes d'état transition ainsi que les diagrammes de classes.

Chapitre 5: Conception

Introduction:

Dans ce chapitre, nous allons présenter les diagrammes de séquences qui décrivent les services du protocole GPSR et surtout les services de la couche réseau. De plus, nous allons présenter les différentes classes utiles pour la partie implémentation.

Diagramme d'interaction qui représente les objets participant à une interaction particulière et les messages qu'ils échangent organisé en séquences horaires. Axé sur ce que fait un système et non sur la manière dont il le fait, un diagramme de séquence définit la Logique d'une instance particulière d'un CAS d'utilisation. En général, dans un diagramme de séquence, la Dimension verticale représente les heures (de haut en bas) et la Dimension horizontale représente les différents objets.

Figure 5.1. : Diagramme de séquences : Le scénario de simulation

1.2. Diagramme de séquences : Traitement lors de réception d'un beacon

Figure 5.2. : Diagramme de séquences : Traitement lors de réception d'un beacon

Lors de la réception du paquet beacon, une mise à jour de la table de routage sera effectuée, Ces mises à jour régulières permettent de communiquer les modifications de topologie .Si le temps est dépassé et le noeud réceptrice ne reçoit pas le beacon du noeud enregistré dans la table de routage alors ce dernier sera supprimé.
1.3. Diagramme de séquences : émission d'un message à partir de la couche Application

Figure 5.3. : Diagramme de séquences : émission d'un message à partir de la couche Application

Ce diagramme explique les étapes à franchir pour envoyer un message de données à partir du noeud local vers une autre destinataire.

En premier temps, la couche application crée le message, à ce qui concerne les données à transmettre et le noeud destinataire .Puis l'interface supérieur passe le message au Greedy mode pour déterminer s'il y a une possibilité pour le transférer au plus proche voisin. Après un calcule de distance séparant le noeud local avec l'ensemble de ses voisins deux cas s'opposent :

ü Un transfert possible avec le Greedy mode (il ya un voisin plus proche que les autres)

ü Il n y a pas un voisin a l'apporté qui le plus proche voisin alors on doit passer au Perimeter mode.

A ce qui concerne le premier cas on termine par encapsuler le message dans interface inferieure et puis son envoi.

Dans le deuxième cas, il se déroule l'algorithme du perimeter mode .En effet, le module Perimetre mode consulte la liste des voisins du table de routage et en utilisant la règle de la main droite détermine le noeud prochain .Puis, il se déroule l'encapsulation et l'envoi.

1.4. Diagramme de séquence : le traitement d'un paquet de données lors de la réception

Figure 5.4. : Diagramme de séquences : le traitement d'un paquet de données lors de la réception

Ce diagramme de séquence décrit l'ensemble des traitements effectués lors de la réception d'un paquet de données. Après la décapsulation du paquet, l'interface inferieur identifie le type de message reçu.

Ø Si c'est un Greedy-mode message, il va être passé au Greedy-Mode. Après, une comparaison entre l'adresse de la destination et l'adresse du noeud locale deux cas possibles. Si le noeud locale est la destination, le message va être repassé à l'interface supérieur puis à la couche application. Sinon ,on va appliquer l'algorithme du Greedy-MODE en déterminant le plus proche voisin dont on va lui transmettre le message ,en se basant sur la liste de voisin du Table du Routage. Dans le cas ou on ne peut pas déterminer le plus proche voisin, on passe à l'algorithme du Perimetre-MODE.

Si c'est un Perimetre-mode message, on fera le même traitement si le message atteint la destination, sinon il y'aura d'abord, un essai d'envoi en utilisant le Greedy-Mode. Dans le cas ou on ne peut pas transmettre ce message avec l'algorithme du Greedy-Mode, le message va être retransmis au noeud voisin en utilisant la règle de la main droite.

Comme l'indique le figure 5.5, à l'arrivé d'un paquet de donnée le Greedy-Mode vérifie si le noeud local est la destination ou bien non. Si c'est la destination, le paquet passera à la réception. Sinon le Greedy-Mode va effectuer un relaie de ce paquet. Alors, il détermine le plus proche voisin qui devrait être unique. Dans le cas d'un échec, il passera au Perimetre-Mode décrit par le diagramme d'état de la figure 5.6. En effet, Perimetre-Mode applique la règle de la main droite pour retransmettre le message. D'ailleurs, l'algorithme de la main droite détermine le noeud adéquate en utilisant un calcule d'angle ayant comme sommet le noeud locale, comme première arrête celle formé par le noeud local et le noeud destination et comme deuxième arrête le noeud locale et le noeud voisin.

· BasicLayer: c'est une classe offerte par la Mobility FrameWork. Elle offre une abtraction simple permettant de développer une couche réseau ou une couche MAC. Elle offre les fonctionnalités de bases dont ont besoin les couches réseaux et MAC comme le handlemessage() et le handleselfmessage() nécessaires aux traitements des paquets.

· GPSRnetwLayer: c'est une classe qui hérite de BasicLayer. Elle correspond au module simple GPSRnetwLayer et constitue la couche réseau du noeud. Cette couche a été implémentée selon la spécification du protocole GPSR. Parmi les paramètres de cette classe on peut citer le headerlength qui spécifie la longueur de l'entête du paquet et le mynetwaddr qui est l'adresse réseau du noeud.

· BasicAppLayer: c'est une classe offerte par la Mobility FrameWork. Elle est la classe générique dont héritent toutes les couches applicatives développées sous la Mobility FrameWork.

· ApplicationLayer: c'est une classe héritée à partir de la BasicAppLayer. C'est une couche applicative qui se contente d'envoyer des messages qui seront encapsulés et routés par la GPSRnetwLayer.

· Cmessage: c'est une classe offerte par OMNet++. Elle représente des messages, des paquets et même des évènements. La plupart des messages et paquets implémentés dans OMNet++ héritent de cette classe.

· GPSRPKT: c'est une classe qui hérite de cmessage. Elle représente le paquet utilisé par GPSRnetwLayer avec ses spécificités.

Conclusion

Au cours de ce chapitre, nous avons abordé la partie conceptuelle en définissant les différents modules applicatifs ainsi que les différentes classes associées. En plus, nous avons détaillé les fonctionnalités de chaque classe. Dans le prochain chapitre, nous décrivons la réalisation et les différentes configurations pour notre solution.

Chapitre 6: Réalisation

Introduction:

Après avoir terminé l'étape de la conception nous passons à la dernière phase qui est la réalisation. Donc, dans ce chapitre-qui est le dernier chapitre de notre rapport- nous allons présenter les environnements matériels et logiciels. Ensuite, nous décrirons la simulation et les étapes de son déroulement.

1. Environnement de travail:

Nous allons détailler les outils utilisés dans la réalisation de notre simulation.

1.1. Environnement matériel:

La simulation a été réalisée sur un ordinateur Toshiba Satellite dont la configuration est:

1.2. Environnement logiciel:

Notre simulation a été réalisée dans l'environnement logiciel suivant:

D'abord il faut télécharger la version adéquate d'OMNet++ à partir du site www.omnetpp.org.

Double clic sur le programme d'installation omnetpp-3.3.exe, cette fenêtre va apparaître :

Après l'installation un nouveau dossier sera créé avec le nom omnetpp-3.3. Ensuite, il faut ajouter le chemin d'installation C:\OMNeT++\bin au variable d'environnement

1. Télécharger le Mobility Framework (mobility-fw2.0p3.zip) code source code et décompresser l'archive dans C:\

2. modifier le variable OMNETPP_ROOT dans mkmk.cmd pour pointer sur le chemin d'installation OMNeT++, dans notre cas C:\.

2. Simulation:

2.1. Envoi de l'information:

2.1.1. Création du message et envoi vers la couche réseau:

La couche applicative va créer un message de type DATA et ajouter l'adresse destination dans le champ nécessaire puis l'émettre vers la couche réseau comme l'indique le figure 6.2.

Pour mettre à jour la table de routage la couche GPSRNetwLayer est responsable d'envoi et de recevoir des messages beacons vers et à partir des noeuds voisins, le beacon est envoyé à la couche inférieure puis délivré vers noeuds voisins.

Dans cette figure le noeud 2 a intercepté un paquet de type beacon, les informations colorés avec le bleu indique l'identité et l'adresse source du noeud voisin .

Le figure 6.6 montre la réception du paquet de donné provenant d'un autre noeud par La couche GPSRNetwLayer qui se charge de router le message reçu selon l'algorithme GPSR ou bien le délivrer vers la couche applicative.

Au niveau du couche réseau si l'adresse destination du paquet GPSRPkt est égale à l'adresse du noeud locale alors le paquet est décapsulé et devient de type cMessage comme dans la figure 6.7 et renvoyé vers la couche applicative.

Pour envoyer un paquet du noeud(1) vers le noeud(8), le paquet est délivrer vers le voisin le plus proche de la destination parmi ses 3 voisins indiqués dans le figure 6.8 par des liaisons bidirectionnelles, ce voisin est donc le noeud(2).

De même maniere le voisin le plus proche de la destination parmi ses 3 voisins indiqués dans le figure 6.9 par des liaisons bidirectionnelles(en éliminant le noeud(1) source du paquet) , ce voisin est donc le noeud(5).

Dans un premier temps le routage se fait dans la figure 6.10 en mode greedy du noeud(0) vers noeud(2), ce dernier utilise le mode Perimeter car il n'a pas de voisin plus proche en distance de la destination finale (4), ce qui permet de trouver une route passant par le noeud (2) qui, lui, peut à nouveau utiliser le mode Greedy Forwarding.

4. Difficultés rencontrées:

Lors de la réalisation, nous avons rencontré plusieurs difficultés. D'abord l'installation du simulateur OMNet++ et de la Mobility Framework et leur intégration avec Visual Studio. Le passage par des consoles et l'intégration des bibliothèques quasi individuellement rend cette tâche difficile. Ensuite, il faut compiler chaque fichier C++ séparément ce qui peut se révéler fastidieux.
Enfin, la compilation de la simulation elle même nécessite des changements au niveau de plusieurs fichiers.

Conclusion:

Dans ce chapitre, nous avons présenté les résultats de notre projet. Nous avons détaillé les environnements matériels et logiciels. Puis, nous avons décrit le déroulement de la simulation. Enfin nous avons présenté les contraintes rencontrées.

Conclusion

La nécessité grandissante d'échanger des informations entre les véhicules rend indispensable la création de protocoles de routage qui spécifiques et leur amélioration. Pour répondre à ce besoin, a été créé le protocole GPSR. Ce protocole offre plusieurs avantages qui sont la reconnaissance des voisins, le choix du chemin le plus court en passant par des minima locaux et l'adaptation aux changements de topologie dus à la mobilité des noeuds.

Cependant, si la mobilité est lente ou inexistante le taux de transfert du protocole devient moins performant que celui d'autres protocoles comme L'OSPF. Il peut aussi parfois faire entrer le paquet dans une boucle lors du passage au Perimeter Mode. Ainsi, chaque noeud passe le paquet par la règle de la main droite à un de ses voisins et le recevant ensuite d'un autre voisin.

Toutefois, ces problèmes ne constituent pas une atteinte sérieuse à l'efficacité du GPSR dans un contexte de mobilité normale. Malgré cela des amélioration ont été développées comme le OGPSR(Optimised GPSR).

Le déploiement du protocole GPSR trouve certaines difficultés dues principalement au manque de tests sur simulateurs et la non disponibilité de bandes de fréquences allouées spécifiquement aux communication Car 2 Car.

Notre travail qui consiste à simuler ce protocole sur le simulateur OMNet++ nous a permis de programmer en C++ et en langage NED, d'étudier le fonctionnement et le comportement du protocole GPSR dans un environnement proche de la réalité et de le simuler suivant quelques scénarios.

http://itpp.sourceforge.net/ version 3.10.5, 21 Mars, Avril et Mai 2009. http://www.omnetpp.org/doc/INET/neddoc/, Mars, Avril et Mai 2009 http://www.commentcamarche.net, Mars, Avril et Mai 2009

Karp, B. and Kung, H.T., Greedy Perimeter Stateless Routing for Wireless Networks, in

Proceedings of the Sixth Annual ACM/IEEE International Conference on Mobile Computing and

Karp, B., Geographic Routing for Wireless Networks, Ph.D. Dissertation, Harvard