Rapport Final de Projet

LAYOUNI Majid MASTER 1 WESLEM Wahid
MAZOT Raphael 2009/2010 TRAN Alexandre

Cahier des Charges Projet VANET 1/63
Rapport de Projet Final
Projet VANET


Sommaire

Table des Figures. 3
INTRODUCTION.... 4

1) Prsentation 5
1.1) Rappel du 1 semestre... 5
1.2) Prsentation du second semestre. 5
1.3) Utilit Cas de figure. 6
1.4) Etat de lart des exprimentations.. 8
1.5) Objectifs de notre tude 9
1.6) Les Scnarios.. 9
1.7) La mobilit 12

2) Partie technique . 13
2.1) DYMO et NEMO .. 13
2.1.1) DYMO 13
2.1.2) NEMO ... 17
2.1.3) Mise en place de DYMO . 18
2.2) Algorithme Cluster VANET .... 19
2.3) Dveloppement et implmentation dun protocole personnalis dans ns2 25

3) Bilan .... 30
3.1 Organisation . 30
3.1.1) Diagramme de Gantt. 30
3.1.2) Rpartition des tches. 31
3.1.3) Approche du projet 32
3.2) Bilan Gnral.. 32

CONCLUSION. 33
GLOSSAIRE.. 34
ANNEXES.. 36


Table des Figures

Figure 1 : Application des rseaux de vhicules
Figure 2 : Scnario de croisement
Figure 3 : Scnario de passing
Figure 4 : scnario 3 vhicules
Figure 6 : Scnario hybride 2 vhicules
Figure 7 : Structure de la trameRREQ
Figure 8 : Structure de la trame RERR
Figure 9: Simple exemple de connexion Internet
Figure 10 : Schma de propagation des informations inter-cluster
Figure 11: structure du paquet envoy
Figure 12 : Schma de communication avec message Hello
Figure 13 : Schma de communication vers un 3 noeud
Figure 14 : Diagramme prvisionnel


Introduction

Aujourdhui, malgr la crise et la baisse de la consommation, la voiture reste le moyen
de transport le plus utilis. Cependant, ce moyen de transport reste aussi le plus dangereux
avec plus de 4000 morts pour lanne 2009 sur le territoire franais.

Pour contribuer amliorer la scurit des usagers sur la route, les constructeurs
automobiles travaillent et investissent des budgets colossaux dans la recherche et le
dveloppement de la scurit des vhicules. Un de ces systmes correspond la
communication entre les vhicules qui permettrait de diffuser des messages afin de prvenir
dun danger quelconque.

Le projet VANET, pour Vehicule Ad hoc NETwork, consiste modliser cette
communication entre les vhicules dans un rseau routier afin de voir les rsultats que cela
pourrait produire si cet outil tait incorpor dans nos voitures de demain. Ce projet est donc
vraiment concret

1) Prsentation

1.1) Rappel du 1 semestre

Durant le 1 semestre, nous avons tudi les rseaux ad hoc et plus particulirement
ceux ddis aux vhicules (VANET *1*).
Afin dtudier plus amplement le fonctionnement dans un environnement routier,
nous avons mis en place des simulations de communications de vhicules. Pour cela, nous
avons utilis un ensemble de logiciels permettant de modliser un flux de vhicules en
dplacement (SUMO *2* et MOVE*3*). MOVE permet de gnrer des fichiers qui seront par
la suite utiliss dans la simulation des rseaux sans fil laide du logiciel NS2.
Cest ainsi que nous avons utilis des simulations de vhicules sur autoroute et une
reprsentant un carrefour.
De plus, le protocole implment par M. BENSLIMANE, nomm IVG *4*, a t
intgr au sein du logiciel de simulation NS2.

Dans un souci dvolutivit, nous nous sommes galement penchs sur la mise en
place dun rseau V2I, cest--dire un rseau de vhicules qui serait capable de se connecter
des bornes WIFI, des stations de base mobiles ou autres points daccs.
Ceci a pour but de pouvoir connecter un cluster *5* de vhicules un rseau Internet
afin de pouvoir transmettre des informations sur un accident qui aurait pu avoir lieu plus loin
sur une route, par exemple.

Nous avons donc continu dans cette voie pour le second semestre.

1.2) Prsentation du 2 semestre

Durant la 2 partie de lanne, nous avons tudi et effectu de nombreuses
recherches quant limplmentation et la production dun nouveau protocole de
communications intgrant la fonctionnalit V2I.
Effectivement, durant la 1 partie de lanne, nous avons vu le protocole IVG, mais ce
dernier utilise seulement le rseau V2V, cest--dire un rseau entre vhicules seulement.

Dans un premier temps, nos recherches ont t dirige vers les protocoles DYMO et
NEMO. Puis, nous nous sommes rendu compte que NEMO tait un protocole que lon ne
pouvait pas implmenter au sein de NS2.
Cest pourquoi, notre choix sest tourn vers DYMO, dont on peut utiliser les sources
du code pour lutiliser dans NS2 ou le compiler directement sous Linux.

De plus, nous nous sommes galement renseigns sur la cration dun nouveau
protocole en nous penchant davantage dans les paramtres techniques dune communication
V2I.
Aprs de nombreuses recherches et la lecture de documentations en anglais, nous
avons pu dterminer la conception de notre algorithme.

1.3) Utilit - Cas de figures

1.3.1) Petit rappel :

Les principaux avantages de l'utilisation de communications inter-vhicules V2V/V2I
dans un systme de transport sont les suivants:
Augmentation de la scurit routire et la fiabilit du systme de transport.
Plus grande efficacit du trafic, gestion du trafic routier et de contrle.
Cots d'exploitation rduits.
Meilleure mobilit pour les personnes handicapes ou ges.
Systme cologique et service potentiellement rentable.

Toutefois, quand il s'agit de mettre en uvre ce type darchitecture dans des vhicules
spcifiques, des contraintes vont tre imposes par la conception des vhicules propres, lis
certains paramtres (vitesse, direction, par exemple) ou des composants de systme (par
exemple le systme de positionnement utilis).

Le systme de communication inter-vhicules a pour objet de raliser l'amlioration
de la scurit et l'efficacit dans les transports. Il implique le dploiement de deux systmes
de communication : vhicules vhicules(V2V) et vhicules infrastructure(V2I). Cette
structure facilitera l'amlioration importante du flux d'information obtenu par des vhicules
en mouvement et de ses qualits et fiabilits. Par consquent, cela renforce l'efficacit et la
scurit du trafic sur urbains, interurbains et les routes rurales.
Pour tablir la communication entre les vhicules, un rseau dynamique sans fil a t cr
comme un Vehicular Ad-hoc Network (VANET). Tous les vhicules impliqus ont t quips
de matriel spcialis embarqu. Les communications V2V et V2I sont bases sur les
technologies 802.11p. Cependant, la communication V2I nous impose d'utiliser un nud de
relais statique quand deux vhicules veulent communiquer entre eux si elles sont hors de
porte ou l'utilisation d'une unit de visualisation statique.

1.3.2) Evolutivit du projet

1.3.2.1) Les applications

Les rseaux collaboratifs *6* sont en train de se dvelopper, en particulier avec les
rseaux pairs--pairs (ou ad hoc *7*).
On peut imaginer une chane de radio ou de tlvision distribue o chaque vhicule va
partager les musiques et vidos qu'il a en sa possession pour construire un programme de
diffusion continu. Les cartes collaboratives et les petites annonces peuvent tre des services
distribues base de rseaux ad hoc. Un serveur relai peut permettre la navigation sur
Internet mme dans des zones sans connexion Internet. Un systme de distribution de
publicits et d'informations pratiques (concerts, restaurants, ) peut tre mise en place
l'entre des villes.

1.3.2.2) Les Hotspots *8*

Aujourdhui, les hotspots (zone wifi accs Internet) sont de plus en plus dvelopps
dans les villes. En voiture, on peut imaginer acheter de la musique et de la vido, au niveau
dune station essence, dune gare ou mme en pleine autoroute (en passant d'une voiture
une autre jusqu'au point d'accs le plus proche). Les passagers dans la voiture pourront ainsi
jouer en rseaux, ou encore mme naviguer sur Internet.

1.3.2.3) Gestion des espaces libres dans les parkings

Voici divers applications qui pourraient utiliser les communications inter-vhicules,
tel que pour prvenir dune panne dun usager, de travaux sur la route, dun risque de
collision et grer les places libres dans les parkings.
Ce service permet de rassembler des informations sur la disponibilit de l'espace de
stationnement dans les parkings et de coordonner entre automobilistes afin de les guider aux
espaces libres (cf. figure 1 c).

Figure 1: Application des rseaux de vhicules

1.4) Etat de lart des exprimentations

Les expriences des rseaux de vhicules ont plusieurs fois t prsentes dans la
littrature et nous allons rsumer quelques articles.
Dans [HULL06 A measurement study of vehicular internet access using in situ Wi-
Fi networks ], les auteurs prsentent les rsultats d'une tude de mesure sur un ensemble
de points d'accs ouverts dploys actuellement dans le secteur mtropolitain de Boston. Ils
mesurent le temps de connexion et la bande passante en tlchargeant avec neuf voitures se
dplaant en essayant de se connecter sur les diffrents points d'accs.

[GASS06 Measurements of In-Motion 802.11 Networking ] dmontre la faisabilit
d'utiliser directement la norme IEEE 802.11b *9* des rseaux sans fil pour une voiture se
dplaant. Ils mesurent la performance d'un client en mouvement connect un point
d'accs seul dans le dsert de Californie, o il n'y a aucun obstacle et aucune interfrence
radio et aucun autre vhicule. Cet environnement leur permet de mesurer la performance
dans un milieu contrl.
[OTT04 Drive-thru internet: IEEE 802.11b for automobile users ] tudie le
comportement des connexions rseaux sur un canal IEEE 802.11b partir d'une voiture se
dplaant. Cette tude dcrit des mesures TCP et UDP entre une voiture en mouvement avec
une antenne externe et un point d'accs. Le but tait de comprendre l'impact de la vitesse de
la voiture, le taux de transmission et l'influence de la taille des paquets.
[BUCC05 Performance Evaluation of H.264 Video Streaming over Inter-Vehicular
802.11 Ad Hoc Networks ] expose quelques rsultats exprimentaux utilisant une
application multimdia dans un rseau ad hoc inter-vhicules. Deux vhicules quips de la
norme IEEE 802.11b ont test dans uniquement deux environnements diffrents (urbain et
autoroute). Les auteurs concluent les rsultats suivants : (i) le rapport Signal/Bruit
(SNR) *10* est plus important dans une autoroute que dans une zone urbaine, (ii) la liaison
est plus fiable dans une autoroute que dans une ville et (iii) la transmission optimale varie
selon le scnario, puisqu'il est meilleur d'utiliser de gros paquets sur des autoroutes et utiliser
une grande fragmentation avec de petits paquets dans des zones urbaines.

Les mmes rsultats sont obtenus dans [HUI01] quant au SNR et au bruit. De plus,
les auteurs donnent quelques autres rsultats tels que le RTT *11*, le dbit TCP *12* et
UDP *13*, etc. Ils utilisent 3 vhicules ainsi quun chemin statique. De leur point de vue, le
dploiement d'applications multimdia est difficile.
Dans [SING02], les auteurs ont mesur la qualit du lien sur autoroute, dans des
environnements urbains et des banlieues. Les rsultats de l'tude ont montr que la banlieue
est la plus favorable pour la communication inter-vhicule.

Le but des expriences dans [HULL06, GASS06, OTT04] est de comprendre les
performances en termes de temps de connexion et de taux de perte quand une station mobile
se connecte des points d'accs. Tandis que les expriences dans [BUCC05, HUI01, SING02]
testent des conditions d'environnements diffrentes. Ces expriences ne considrent pas tous
les scnarios que nous trouvons dans notre vie quotidienne ainsi que les effets de certains
facteurs sur les mtriques de performance. Leur objectif principal est d'avoir une vue globale
de la connectivit entre seulement deux vhicules en changeant des conditions
d'environnement de conduite.
1.5) OBJECTIFS DE NOTRE ETUDE

Nos objectifs sont donc, terme, de pouvoir comparer lefficacit dun protocole dj
implment, que nous devons intgrer dans un logiciel de simulation, et un protocole que
nous allons nous mme coder en prenant en compte de nombreux paramtres.

Les mtriques souhaites avec notre tude sont :
- Qualit du signal sous forme de RSSI *14* (Received Signal Strength Indication)
pour chaque trame misse sur chaque noeud
- Mesure du bruit
- Distance entre vhicules
- Vitesse et direction des vhicules
- Taux de perte
- Dbit mesur
- Quantit de donnes reues
- Dure de connexion
- Gigue *15*
- Temps d'aller retour (Round-Trip delay Time)

1.6) Les Scnarios
1.6.1) LES SCENARIOS SIMPLES A DEUX VEHICULES

Afin de pouvoir mettre en place un algorithme ou tudier les rsultats de
limplmentation dun autre, nous devons dfinir les cas possibles lors dune communication
entre vhicules. Cest pourquoi, nous avons dfini diffrents scnarios qui vont pouvoir nous
permettre davoir une vision plus globale de la conception du protocole.

Le premier scnario est le croisement de deux vhicules comme dans la figure 2.

Figure 2 : Scnario de croisement

Le scnario de passing consiste immobiliser une voiture au milieu d'un segment
de route et une autre le parcourir (cf. Figure 3). Cela correspond une situation d'un
croisement avec une voiture arrt au feu rouge et l'autre passant au feu vert.


Figure 3 : Scnario de passing

Le scnario d'acclration permet de voir l'influence de l'acclration sur la
communication. Pour cela, les deux voitures sont l'une cot de l'autre et l'une acclre
jusqu'au bout du segment de route.

1.6.2) Les Scnarios plus de deux vhicules

Ces expriences sont indites car elles montrent la capacit des rseaux multi-sauts
dans un rseau de vhicules.
Le scnario du simple saut permet de voir l'influence d'un passage par un nud
intermdiaire (cf. Figure 4). Le but tant ici d'augmenter les distances entre metteur et
rcepteur en utilisant un nud relai.


Le problme de ce scnario est de forcer le passage par le vhicule relai. La solution
est dcrite dans la partie "Formation du cluster". Cette exprience a t faite avec des
vhicules immobiles, puis en mouvement avec diffrentes vitesses.

Enfin, un scnario de chaine de 6 vhicules (cf. Figure 5) permet d'tudier les
comportements de la communication en utilisant 4 relais. Le choix des relais est fix au
dpart par l'affectation de routes statiques, c'est--dire sans un protocole de routage
dynamique de type OLSR *16* ou AODV *17*.


1.6.3) Scnarios I2V

Les scnarios de vhicule infrastructure sont importants car dans une phase de
dploiement, les infrastructures permettent de proposer des services tous les vhicules
malgr un faible taux de pntration.

Le scnario que nous avons imagin se compose d'une borne statique situe sur un
pont alors qu'une voiture circule sur une voie express passant en dessous. Diffrentes vitesses
doivent tre testes pour tenir compte dun maximum de situations. La borne est configure
en tant qu'mettrice continue de donnes avec le dbit maximum.

Le vhicule est configur comme ne connaissant pas le canal d'utilisation de la borne,
ainsi il doit le dcouvrir par une mthode de recherche. Le but est de se rapprocher d'une
condition relle de dcouverte avec l'tablissement d'un dialogue d'authentification et
d'association avant le transfert de donnes.

1.6.4) Scnarios hybrides

Nous avons imagin un scnario hybride dans le but d'tendre la couverture d'une
borne mettrice. Pour cela, la borne est situe sur un pont alors que deux vhicules se suivent
et sont spars d'une distance permettant la communication entre elle. D'abord, la borne se
connecte directement sur la premire voiture et lui envoi les donnes (cf. Figure 6). Lors que
celle-ci devient hors d'atteinte, un basculement de route s'effectue et les donnes vont alors
tre relayes par le second vhicule.

Figure 6 : Scnario hybride 2 vhicules

Cependant, ce changement de destinataire n'est pas trivial car il doit prendre en
compte la qualit du signal, le taux de perte, la distance, Ainsi pour viter la complexit et
les problmes d'une telle solution, un basculement manuel serait prfrable. La station
rceptrice va ainsi indiquer la borne de changer de chemin et de relayer les informations
par le second vhicule.

Un autre problme est de trouver comment basculer d'un mode envoi direct un
mode envoi avec relai. La solution utilise est de vrifier tout instant les stations associes
la borne. Si le vhicule rcepteur est associ alors les donnes lui sont envoyes directement
sinon elles sont envoyes au vhicule relai. Pour indiquer le changement, le vhicule
rcepteur va envoyer une d-association la borne qui va ainsi envoyer les informations au
relai (voir Formation cluster ).

1.7) La Mobilit

La mobilit est trs importante dans la simulation de rseaux de vhicules. En effet,
c'est elle qui va dterminer si deux pairs sont proches et peuvent communiquer et une des
spcificits des rseaux de vhicules est que le dplacement des vhicules est caractris par
les infrastructures (routes, feux tricolores, carrefour, ). La prise en compte des
dpassements, des bouchons est trs importante pour la reprsentation de la ralit.

Afin de dfinir un modle de mobilit adquat pour les rseaux de vhicules, on distingue les
environnements suivants :
- Autoroute : environnement ouvert caractris par une grande vitesse de
dplacement (avec des limites : vitesse min et vitesse max), avec des dpassements de
vhicules, et une densit de nuds fonction de l'heure de la journe;
- Ville : vitesse modre avec une probabilit d'intersection plus grande. Il existe des
endroits d'arrt aux feux, une grande densit de voitures, et l'existence de certaines
routes plus frquentes que d'autres (routes principales, endroit commercial ou
touristique par exemple);
- Rase campagne : caractris par des vitesses moins importantes avec une densit de
voitures plus faible.

Certains protocoles ne prennent pas en compte lasymtrie de la communication
dans les rseaux ad hoc sans fils. Exemple un nud A peut communiquer avec le nud B
mais linverse, il arrive que le nud B ne puisse pas atteindre le nud A cause
dinterfrences. De plus, cause de la distance, le nud le plus loign est aussi le nud avec
lequel la communication est la moins fiable et la plus facilement rompue.
Enfin, elle suppose que chaque vhicule dispose d'un moyen de go-localisation *18*.
Nous proposons dutiliser la qualit du signal du message reu pour calculer le dlai dattente
afin de saffranchir de certains problmes de ces protocoles.

Pour les mcanismes proactifs *19*, nous proposons dutiliser les informations de
vitesse du nud et de densit pour calculer la priode dmission de message Hello .
Plus un nud se dplace rapidement, plus sa priode dmission est diminue. Cela permet
dtablir plus rapidement une connexion pour les nuds rapides. De mme, plus la densit
des nuds (nombre de messages Hello reus) est importante, plus la frquence
dmission est faible. Cela vite la congestion dans des cas de haute densit de vhicules (ex :
bouchons, parking).

La fragmentation du rseau est un phnomne trs rpandu dans les rseaux de
vhicules. Ainsi, toute solution devra prsente un mcanisme permettant la gestion de ce
partitionnement tel que le store and forward ou lutilisation dinfrastructure.


2) Partie technique
2.1) DYMO et NEMO
2.1.1) DYMO *20*
DYMO gre un large ventail de modles de mobilit, en dterminant de manire
dynamique des itinraires la demande. DYMO gre galement une grande varit de
modles de trafic.
DYMO est applicable aux dispositifs de mmoire limite, depuis l'tat de routage
minimale est maintenue dans chaque routeur DYMO. Seules les informations de routage lis
des sources actives et les destinations est maintenu, contrairement d'autres protocoles de
routage plus proactifs qui ncessitent des informations de routage tous les routeurs dans la
rgion de routage soit maintenue.
2.1.1.1) Dcouverte de route:
Le routeur Dymo crateur initialise la dissmination d'une requte de route (RREQ)
travers le rseau afin de trouver le routeur DYMO cible. Pendant ce processus de
dissmination de saut--saut, chaque routeur intermdiaire dymo enregistre la route du
crateur.
Quand le routeur dymo cible reoit le RREP, il rpond avec un Route Reply (RREP)
en envoyant un saut saut vers le crateur.
Chaque routeur dymo intermdiaire qui reoit le RREP crer une route jusqu' la
cible, et, ensuite, le RRE est unicast saut saut vers le crateur.
Quand le routeur dymo crateur reoit le RREP, les routes ont t tablies entre le
crateur et la cible dans les deux directions.
2.1.1.2) Maintenance de route
2 oprations:
pour prserver la route en utilisation, les routeurs tendent la dure de vie de la route
en transmettant un paquet.
Dans le but de ragir aux changements dans la topologie du rseau, les routeurs
DYMO surveillent les liens sur lesquels le trafic reste fluide.
Quand un paquet de donnes est reu pour l'expdition et un itinraire pour la
destination n'est pas connue ou que la route est cass, alors le routeur DYMO de la source du
paquet est notifie.
Une erreur d'itinraire (RERR) est envoy vers la source de paquets pour indiquer la route
actuelle vers une destination particulire est invalide ou manquante.
Lorsque routeur DYMO source reoit le RERR, il supprime l'itinraire. Si la source DYMO
routeur reoit un paquet plus tard, pour transmission la mme destination, elle aura besoin
pour effectuer la dcouverte de la route pour cette destination.

2.1.1.3) Route Table Entry (les diffrents champs):
Address route (IP)
Prefix route (netmask)
Sequence Num route
Next Hop Adresse => adresse IP du prochain routeur DYMO.
Route.NextHopInterface => interface utilise pour envoyer les paquets
Route broken => un flag indiquant si la route est rompu.
Route Dist => mtrique indiquant la distance avant d'atteindre la route (optionnel)

Exemple IPv4 RREQ

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
IP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.SourceAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.DestinationAddress = LL-MANET-ROUTERS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = MANET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ-type |R|C|N|1|1|0|1|0| msg-size=23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit |
+-+-+-+-+-+-+-+-+
Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=2 | Rsv |0|0|0|1|0| HeadLength=3 | Head :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Head (cont) | Target.Tail | Orig.Tail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tlv-block-size=6 |DYMOSeqNum-type|Rsv|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=2 | Orig.SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7 : Structure de la trameRREQ


Exemple IPv4 RERR

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
IP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.SourceAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.DestinationAddress = LL-MANET-ROUTERS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP.TTL/HopLimit = 255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port = MANET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RERR-type |R|C|N|1|1|0|1|0| msg-size=15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-hoplimit |
+-+-+-+-+-+-+-+-+
Message TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-tlv-block-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number Addrs=1 | Rsv |0|0|0|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable.Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Body - Address Block TLV Block
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-blk-size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 : Structure de la trame RERR
Le relay sur Internet se compose d'un rseau de routeurs MANET connects Internet via un
seul routeur DYMO Internet (IDR). L'Internet peut tre connect via des routeurs DYMO
multiples, mais un tel comportement n'est pas spcifi dans ce document.

L'IDR est charg de rpondre aux RREQs pour les routeurs DYMO au nom du TargetNodes
sur l'Internet, ainsi que la livraison des paquets destinations sur l'Internet.


/--------------------------\
/ Internet \
\ /
\------------+---------------/
|
Routable & |
Topologically | A.B.C.X/24
Correct |
Prefix |
+-----+-----+
| Internet |
/------| DYMO |-------\
/ | Router | \
/ | A.B.C.1 | \
| +-----------+ |
| DYMO Region |
| |
| +--------------+ |
| | DYMO Router | |
| | A.B.C.2 | |
| +--------------+ |
| +--------------+ |
| | DYMO Router | |
| | A.B.C.3 | |
\ +--------------+ /
\ /
\---------------------------/

Figure 9 : Simple exemple de connexion Internet
Les routeurs DYMO qui souhaitent tre joignable partir de nuds dans l'internet ont des
adresses IP au sein de l'IDR routables et topologiquement une correrction de prefix. L'IDR
est responsable pour le routage et le transfert des paquets reus de l'Internet et destins pour
les nuds de l'intrieur de son MANET et vis versa.

Lorsque le routeur DYMO l'intrieur du MANET veut envoyer des paquets un noeud sur
l'Internet, il dlivre simplement une RREQ pour ces adresses IP de destination, en utilisant la
dcouverte Route Normale DYMO. L'IDR est charg de rpondre correctement aux RREQ au
nom des destinations Internet, et de maintenir leur numro de squence associ (s).

2.1.2) NEMO
2.1.2.1) Description:

La complexit est centralise sur un quipement ddi : le routeur mobile. Ainsi, chaque
mouvement (lorsque le rseau mobile se dplace d'un rseau d'accs vers un autre) est
transparent pour l'ensemble des htes IPv6 du rseau mobile. Un hte IPv6 standard peut
ainsi bnficier d'une connectivit permanente au sein d'un rseau mobile sans avoir
toutefois besoin de protocoles additionnels.
NEMO BS, coupl avec certaines extensions, gre notamment la mobilit des rseaux IPv6, la
continuit des flux, les quipements multi-interfaces. Plusieurs quipes de recherche travaille
sur de nombreuses amliorations de ce protocole :
Configuration initiale automatique
o Autoconfiguration des routeurs mobiles au dmarrage
o Dcouvertes de services sur le rseau mobile
Multi-domiciliation
o Partage de charge
o Distribution des flux
o Tolrance la panne
o Applications utilisateurs adaptatives
o Gestion de routeurs mobiles multiples
2.1.2.2) Gestion de la mobilit

NEMO permet d'tre toujours joignable par l'intermdiaire de son adresse principale tout
comme les clients associs dans le rseau mobile. Cette adresse principale est associe une
adresse temporaire auprs d'un quipement appel agent mre. Cette adresse temporaire
reprsente la position relle du routeur mobile dans la topologie d'Internet et est mise--jour
chaque dplacement du rseau mobile vers un nouveau rseau d'accs.
L'ensemble des flux destination du rseau mobile passent toujours par l'agent mre, qui
peut donc assurer la continuit des flux tout au long des dplacements du rseau mobile.

2.1.2.3) Multi-domiciliation

Le routeur mobile dispose de plusieurs interface rseau lui permettant de se connecter en
parallle a plusieurs rseaux d'accs IPv6. Son adresse principale est alors associe
plusieurs adresses IPv6 temporaires (une par interface) grce au protocole Multiple Care-
of Addresses registration (MCoA). Plusieurs chemins concurrents peuvent ainsi tre
maintenus entre le routeur mobile et son agent mre.
Les flux de l'Internet destination du rseau mobile ou inversement font l'objet d'une
dcision de routage respectivement sur l'agent mre ou le routeur mobile. Ces dcisions sont
prises en fonction de prfrences ou politiques de routages prsentes sur chacune de ces
entits.
Les flux peuvent ainsi tre partags entre diffrent chemins selon leur protocol et/ou port. Le
routeur mobile et l'agent mre peuvent galement plus facilement faire face une panne ou
une dconnexion de l'un des rseaux d'accs en redirigeant les flux vers les interfaces
disponibles.
Les chercheurs travaillent galement la gestion de routeurs mobiles multiples au sein d'un
mme rseau mobile. Ils sintressent notamment aux mcanismes de redondance des
routeurs mobiles tout en tendant la mise en uvre du partage de charge et de tolrance aux
fautes dans ce contexte.

2.1.3) Mise en place de DYMO

Aprs nos recherches sur les protocoles DYMO et NEMO, nous nous sommes rendu
compte que NEMO ntait pas trs utilis et notamment dans le logiciel de simulation NS2.
Cest pourquoi, notre choix sest tourn vers DYMO, qui grce aux sources disponibles sur le
site http://masimum.dif.um.es/ nous permet de limplmenter au sein de NS2 ou de le
compiler directement sur une distribution Linux.

Cependant, aprs de nombreuses tentatives sur de nombreuses versions de NS2 (2.27
2.28 2.29 2.33 2.34), une erreur se produisait chaque fois lorsque nous appliquions
le patch ncessaire qui permet de modifier les fichiers en fonction du protocole.

Depuis le dbut du projet, nous avons utilis Ubuntu comme distribution Linux.
Cependant, de nombreux problmes sont apparus avec cette distribution. Ce nest quen
essayant sur une distribution Fedora 10 avec une version de NS2 en 2.29 que nous avons
russi faire fonctionner le protocole DYMO. Nous avons ainsi appliqu le patch v3
correspondant cette version de NS2.29.

Aprs de nombreuses heures essayer et installer diverses versions de NS2 sur
diverses distributions de Linux que nous sommes parvenus obtenir des rsultats de
simulation.
Vous trouverez en annexes comment intgrer DYMO dans NS2 plus prcisment,
ainsi que comment crer un fichier tcl pour pouvoir exploiter des rsultats.

2.2) Algorithme cluster VANET

2.2.1) Initialisation
Figure 10 : Schma de propagation des informations inter-cluster
Au dbut, aucun cluster nest form. Chaque nud nappartient donc aucun cluster.
Pour mettre en place le cluster, chaque nud va envoyer un message Hello priodiquement.
Envoie en broadcast message Hello (type =dcouverte voisinage, TTL, @ source, @ dest)
Si aucune rponse une fois le TTL coul et disposedune antenne double interface :
le nud se dclare CH.
Sil ne dispose pas dantenne double interface il va retenter de se
connecter un cluster
Sinon phase : Election du CH

2.2.2) Connaissance du voisinage :
Tous les nuds vont donc envoyer un message Hello leur voisin, en modifiant la table de
routage contenue dans le message.

Figure 11: structure du paquet envoy
Au dbut des changes, les nuds ne possdent aucune information sur leur voisinage, et LS
est vide. A la rception du premier message HELLO d'un nud inconnu B (tape 1), chaque
nud A, porte radio de B, dtecte un lien asymtrique avec ce voisin et l'annonce par la
suite dans Figure 12 -Dcouverte de voisinage par les nuds OLSR ses messages HELLO.

De mme, si B est porte radio de A, il reoit les messages HELLO de ce dernier et il dduit
que le nud A est un voisin symtrique (tape 2). Dans les messages HELLO envoys, les
liens peuvent tre dclars comme asymtriques, symtriques ou MPR (Multi Point Relay).
Les messages HELLO reus permettent chaque nud de mmoriser une base d'information
sur le voisinage deux sauts.

Figure 12 : Schma de communication avec message Hello

Par exemple, dans la figure 13, lorsque A reoit le message HELLO de B, il va dtecter
que ce dernier est un voisin symtrique de C, et ainsi dduire que C est un voisin deux
sauts. Puisque C n'est pas le voisin de A, ce dernier doit choisir son voisin B comme MPR
pour pouvoir atteindre C, et doit dclarer B avec un statut MPR dans HELLO (tape1). A la
rception des nouveaux messages HELLO de A, le nud B va dduire qu'il a t choisi
comme MPR par A et doit donc l'ajouter dans son ensemble de slecteurs MPR (tape 2), et
gnrer un message TC annonant tre le MPR de A (tape 3).

Le message TC porte les informations de topologie du rseau complet, c'est dire la
vision globale. Chaque nud maintient dans un ensemble nomm TopologySet (TS) les
informations sur les points de destination dans le rseau. Un nud qui a t slectionn
comme MPR met priodiquement des messages TC annonant la liste de ses voisins
symtriques qui l'ont choisi comme MPR. Ce message TC n'est retransmis que par les nuds
qu'il a choisi lui-mme comme MPR (Figure 13).
Les messages TC sont diffuss dans le rseau entier et permettent le calcul de la table de
routage.

Figure 13 : Schma de communication vers un 3 noeud

2.2.3) Election du CH :
Une fois la connaissance du rseau effectue, on va pouvoir dterminer le CH
qui va diriger lensemble du convoi.
Pour cela, on va lancer une trame de calcul de la longueur du convoi (calcul
en sauts)


Cet algorithme va donc nous permettre de dterminer les vhicules Relay se trouvant au
centre du convoi.
Une fois ces nuds dtermins, on va ensuite comparer leurs caractristiques dans un
nouveau paquet, et le vhicule va passer en tat candidat au CH.

2.2.4) Algorithme dlection du CH
On vrifie tout dabord si le vhicule a 2 interfaces :
Si non, il ne se considre plus comme candidat
Si oui, envoi dun message High Profile avec les paramtres suivants :
o Direction (en fonction du GPS)
o Signal de la BTS (SNR)
o Position/Distance avec les nuds (en fonction du GPS)
o Vitesse moyenne du convoi
Ces paramtres sont classs par ordre de priorit afin que les liens soient maintenus le plus
longtemps possible.
Ensuite, nous avons choisit de classer les CH candidates dans des tableaux en fonction
des paramtres vu prcdemment. Ainsi nous avons un tableau o les CHc (CHcandidates)
vont tre classs par distance, un autre o ils seront classs par Rapport Signal sur Bruit avec
la BTS et un autre en fonction de la vitesse.
Dans un premier temps, lalgorithme consiste vrifier si le CHc possde bien 2
interfaces et est donc capable de communiquer avec une BTS. Puis, nous vrifions que les
vhicules se dirigent bien dans la mme direction, car si ce nest pas le cas, ce CHc ne sera
donc pas pris en compte pout la suite de llection.
Nous avons donc un tableau contenant les CHc classs du plus petit cart de vitesse
avec la moyenne de vitesse du cluster au plus grand cart. Ainsi, si la moyenne de vitesse du
cluster est 115 Km/h (autoroute), un CHc qui serait une vitesse de 120 Km/h (5 Km/h
dcart avec le cluster) se situerait devant un CHc qui roulerait 130 Km/h (15 Km/h dcart
avec le cluster).
Un second tableau contenant les CHc classs en fonction de leur SNR (Rapport
Signal/Bruit) du plus grand au plus petit est ainsi cr. Les CHc ayant les meilleurs SNR se
situeront donc dans la partie haute du tableau.
Un dernier tableau contenant la distance moyenne avec ses voisins class par ordre
croissant regroupera ainsi les CHc.

Ces tableaux vont donc tre classs. Ensuite, nous allons rcuprer lindice de
positionnement dun CHc dans chacun des tableaux et ajouter ainsi lindice de classement de
la vitesse, du SNR et de la distance. Nous allons ensuite choisir le CHc qui possde la plus
petite valeur une fois ces indices ajouts.
En effet, le CHc possdant la plus petite valeur de la somme des indices va tre celui qui
possde en moyenne le plus grand SNR, le plus petit cart de vitesse avec le cluster et la plus
petite distance moyenne avec ses voisins.
Nous avons galement pens au fait que ce vhicule pouvait avoir un SNR trop faible pour
pouvoir communiquer avec la BTS parfaitement. Cest pour cela nous avons dfini un seuil
minimum pour ne pas lire un CH qui ne pourrait pas dialoguer avec la BTS.

Cet algorithme intervient aprs celui qui permet de dterminer la longueur du convoi
et ainsi de savoir quels sont les vhicules se trouvant au centre du convoi, qui seront dsign
CHc. Vu que plusieurs vont tre dans ce cas prcis, il est ncessaire de les dpartager en
fonction de ces paramtres.
De plus, tant donn que deux nuds voisins partagent globalement les mmes
conditions de trafic local, le fait de calculer les conditions de trafic au niveau de chaque nud
mobile implique une redondance qui se traduit non seulement au niveau du calcul mais
galement au niveau de la diffusion de ces conditions de trafic. En effet, deux nuds voisins
vont fournir globalement les mmes informations sur les conditions de trafic.
Cet algorithme ainsi que son implmentation en C sont en annexes.
2.3) Dveloppement et Implmentation dun protocole
personnalis dans NS2
2.3.1) Gnralits
Tcl est un langage de commande comme le shell UNIX mais qui sert contrler les
applications. Son nom signifie Tool Command Language. Tcl offre des structures de
programmation telles que les boucles, les procdures ou les notions de variables. Il y a deux
principales faons de se servir de Tcl: comme un langage autonome interprt ou comme une
interface applicative d'un programme classique crit en C ou C++. En pratique, l'interprteur
Tcl se prsente sous la forme d'une bibliothque de procdures C qui peut tre facilement
incorpore dans une application. Cette application peut alors utiliser les fonctions standards
du langage Tcl mais galement ajouter des commandes l'interprteur.

Construire une application avec un interprteur Tcl revient inclure une bibliothque
Tcl qui dfinit les commandes de bases de Tcl dans l'application. Comme nous l'avons dit,
l'interprteur effectue l'analyse syntaxique et appelle la fonction C correspondant la
commande Tcl. Ajouter une commande Tcl consiste tablir un lien entre un mot et une
fonction C. Le mot sera le nom de la commande Tcl. La fonction C est dfinie dans le code
source de l'application. Au dmarrage, l'application procde dans son main() aux
initialisations ncessaires et passe la main l'interprteur. L'application passe en mode
interactif: chaque commande tape par l'utilisateur, la fonction C correspondante est
appele afin de raliser la commande demande.

Voici un exemple de fichier Tcl prsentant un scnario de base :

# cration d'un simulateur
set ns [new Simulator]
# cration du fichier de trace utilis par le visualisateur
# et indication ns de l'utiliser
set nf [open out.nam w]
$ns namtrace-all $nf
# lorsque la simulation sera termine, cette procdure est appele
# pour lancer automatiquement le visualisateur
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
# cration de deux noeuds
UPMC - LIP6 Manuel NS
Rseaux et Performances
Le Mercredi 15 Septembre 1999 - 9 -
set n0 [$ns node]
set n1 [$ns node]
# cration d'une ligne de communication full duplex
# entre les noeuds n0 et n1
$ns duplex-link $n0 $n1 1Mb 10ms DropTail
# cration d'un agent gnrateur de paquets vitesse constante
# paquets de 500 octets, gnrs toutes les 5 ms
# implantation de cet agent dans le noeud n0
set cbr0 [new Agent/CBR]
$ns attach-agent $n0 $cbr0
$cbr0 set packetSize_ 500
$cbr0 set interval_ 0.005
# cration d'un agent vide, destin recevoir les paquets
# il est implant dans n1
set null0 [new Agent/Null]
$ns attach-agent $n1 $null0
# le trafic issus de l'agent cbr0 est envoy
# vers null0
$ns connect $cbr0 $null0
# scnario de dbut et de fin de gnration des paquets par cbr0
$ns at 0.5 "$cbr0 start"
$ns at 4.5 "$cbr0 stop"
# la simulation va durer 5 secondes de temps simul
$ns at 5.0 "finish"
# dbut de la simulation
$ns

Lors dune simulation, les rsultats sont consigns dans un fichier de trace que loutil
de visualisation nam va permettre de traiter. Dans notre programme, loutil de visualisation
est appel directement la fin de la simulation. Deux lments intressants sont proposs
la visualisation : un dessin de la topologie du rseau tudi, et une visualisation dynamique
du droulement du programme dans le temps.

Nous verrons plus loin comment accder dautres informations partir de cette
interface.

2.3.2) Paramtres prendre en compte

Dans notre simulation, nous pouvons forcer le simulateur recalculer des routes avec
les instructions suivantes :

$ns rtmodel-at 1.0 down $n(1) $n(2)
$ns rtmodel-at 2.0 up $n(1) $n(2)

2.3.3) Modifications apporter pour russir lintgration
2.3.3.1) Principe de base
NS est un simulateur vnements discrets orient objet. Il est crit en C++ avec une
interface textuelle (ou shell) qui utilise le langage OTcl (Object Tool Command Langage).
L'OTcl est une extension objet au langage de commande Tcl. Le langage C++ sert dcrire le
fonctionnement interne des composants de la simulation. Pour reprendre la terminologie
objet, il sert dfinir les classes. Quant au langage OTcl, il fournit un moyen flexible et
puissant de contrle de la simulation comme le dclenchement d'vnements, la
configuration du rseau, la collecte de statistiques, etc. L'application NS se compose de deux
lments fonctionnels: un interprteur et un moteur de simulation. Au moyen de
l'interprteur l'utilisateur est capable de crer le modle de simulation ce qui revient
assembler les diffrents composants ncessaires l'tude. Les composants du modle de
simulation sont appels objets ou encore instances de classe. Le moteur de simulation
effectue les calculs applicables au modle pralablement construit par l'utilisateur via
l'interprteur. NS bnficie de toutes les possibilits qu'offrent les techniques objets comme
l'hritage, le polymorphisme, la surcharge, etc. L'hritage permet d'laborer des
arborescences de classes. Le modle de simulation est construit partir d'une arborescence
de classes qui en fait se ddouble:

- une dfinie en OTcl dite arborescence interprte. Elle est utilise par l'interprteur et
estvisible par l'utilisateur.
- une dfinie en C++ que l'on nommera compile. Elle forme l'arborescence utilise par
lemoteur de simulation (que l'on appellera par la suite simulateur). C'est l'ombre de
l'arborescence interprte.

Les deux arborescences sont trs proches l'une de l'autre. Du point de vue de l'utilisateur,
il y a une correspondance univoque entre une classe d'une arborescence et une classe de
l'autre arborescence.

Le croquis ci-dessus montre la dualit des classes qui peut exister dans NS.

Le principe gnral de la cration des objets du modle de simulation est le suivant:
l'utilisateur cre un nouvel objet via l'interprteur OTcl. Le nouvel objet interprt est clon
en un objet compil correspondant dans le simulateur.
En ralit toutes les classes ne sont pas dans les deux arborescences de NS. On peut avoir
des classes qui ne sont que dans l'interprteur: elles servent faire par exemple des
assemblages (ou agrgations de classes) pour faciliter la manipulation. On parlera de classe
OTcl dans la suite de ce document pour faire rfrence ce type de classe. On peut avoir des
classes qui sont purement dans le simulateur: elles ne sont pas visibles de l'utilisateur et
servent au fonctionnement interne d'un composant comme par exemple certaines structures
de donnes.

2.3.3.2) Arborescence des classes compiles

Le croquis ci-dessous reprsente l'arborescence de classes utilise par le simulateur.
Les classes visibles au niveau de l'interprteur comportent une dclaration dans la classe
TclClass. Nous y reviendrons lorsque nous tudierons la cration des objets. Nous verrons
galement l'objectif des diffrentes classes. Le nom des classes correspond celui utilis
dans le code source.


2.3.3.4) Arborescence des fichiers

Voici une schmatisation de larborescence des fichiers dans NS :

La distribution de NS comprend principalement 3 rpertoires:

- ns-2, l'application NS. Ce repertoire contient l'ensemble des fichiers .h et .cc de NS.
- nam-1, l'outil de visualisation des rsultats de la simulation: l'animateur rseau.
- tclcl, sources du code assurant la liaison entre l'interprteur et le simulateur. Citons l'un des
principaux fichiers: tcl-object.tcl.

Dans le rpertoire ns-2, on trouve les rpertoires:

- tcl pour tous les codes interprts.
- bin pour les utilitaires et les excutables pour la ralisation du binaire ns-2
- lib pour la bibliothque de libg++
- gen pour les sources gnres lors de la ralisation du binaire ns-2 par le makefile.
- test_output pour les rsultats des simulations.
- tous les fichiers .h et .cc des classes C++ du simulateur.

Le rpertoire tcl contient les rpertoires:

- lib pour les mthodes OTcl des classes de l'arborescence interprte. Dans ce rpertoire, les
fichiers ns_lib.tcl et ns_default.tcl ont un rle particulier. Le premier est interprt
automatiquement au lancement de NS. Il contient l'ensemble du code interprt de NS via la
commande Tcl "source" (lecture d'un fichier) des diffrents fichiers OTcl. Les valeurs par
dfaut affectes aux objets sont dclares dans le second. Les autres fichiers de ce rpertoire
sont l'API OTcl de NS. Ils ont un nom prfix par ns_.
- ex pour les scripts de simulation donns titre d'exemple.
- test, il recense l'ensemble des scripts des suites de tests pour la validation du simulateur. On
peut galement prendre le contenu de ce rpertoire comme des exemples. Les autres
rpertoires contiennent les codes interprts des contributions.

Pour un utilisateur qui souhaite crire seulement des scripts, l'impression des commandes
disponibles de l'interprteur constitue une bon complment la documentation existante.
Quelle que soit l'tude mener, les principaux fichiers sont:

ns-lib.tcl, ns-node.tcl, ns-link.tcl, ns-agent.tcl, ns-default.tcl, nspacket.tcl

Pour l'utilisateur qui souhaite faire des dveloppements de composants NS, les fichiers
importants sont:

connector.{h,cc}, classifier.{h,cc}, packet.{h,cc}, timer-handler.{h,cc},queue.{h,cc},
agent.{h,cc}, udp.{h,cc}, app.{h,cc}, trafgen.{h,cc}, trace.{h,cc}

Vous trouverez en annexes la procdure pour implmenter un nouveau protocole dans
ns2.29.

3) Bilan
3.1) Organisation
3.1.1) Diagramme de Gantt

Figure 14 : Diagramme prvisionnel :

Le diagramme prvisionnel prcdent na pas pu tre tenu en raison de nombreux
problmes lis aux versions de logiciels.
Dans un premier temps, nous avions pris de lavance sur notre planning vu que nous
navions pas dautres cours simultanment. Cependant, par la suite, tous les cours sont
arrivs en mme temps et il nous a donc t difficile de garder cette avance avec les horaires
que nous avions et les rendus effectuer dans chaque matire.
De plus, nous avons quelque peu modifi les groupes de travail au cours du semestre.
Tout ceci est expliqu dans le paragraphe suivant.

3.1.2) Rpartition des tches
Au cours de ce semestre, nous nous sommes diviss en 2 groupes afin de pouvoir
travailler plus efficacement et ainsi avancer plus vite.
Dans un premier temps, nous avons tous travaill sur le document que M. Benslimane
nous avait fournit en dbut de semestre afin de bien comprendre le fonctionnement des
rseaux V2I et ainsi pouvoir implmenter notre propre algorithme.
Par la suite, nous nous sommes rpartis en 2 groupes, Raphal et Wahid qui se sont
occup de DYMO et NEMO, et Majid Alexandre qui se sont concentr sur la comprhension
de documentations dans le but de crer un nouvel algorithme.
Vu que Wahid et Raphal ont eu de nombreux problmes quant- limplmentation
du protocole DYMO au sein de NS2. De plus, Raphal a envoy un mail au crateur du
protocole afin de comprendre lorigine du problme et ainsi le corriger pour nous permettre
davancer. Mais aucune rponse na t fournie par cette personne.
Cest pourquoi, les groupes ont t modifis par la suite : Alexandre sest occup de
faire fonctionner DYMO quand le reste du groupe sest vraiment centralis sur le codage du
protocole.
Cependant, malgr nos multiples tentatives et les nombreuses versions essayes pour
faire fonctionner le protocole DYMO, aucune na fonctionne. Ce nest que vers la fin du
semestre que nous Alexandre et Wahid ont voulu tester sur une distribution Fedora, vu que
sur Ubuntu cela ne donnait rien. Pendant ce temps, Majid et Raphal se sont occup de
rdiger le rapport de projet.
Notre quipe de projet a donc su sadapter en fonction du travail et des problmes que
nous avons rencontr afin davancer le plus efficacement possible.

3.1.3) Approches du projet
Dans un premier temps, nous avons suivi les avances effectues par les groupes
prcdents afin de reproduire leurs travaux tels que linstallation de SUMO, MOVE et NS2
sur une distribution Ubuntu et ainsi pouvoir implmenter IVG dans NS2.
Au niveau de DYMO, nous avons suivi les instructions mises disposition sur le site et
pourtant malgr cela, des erreurs ont suivi alors que le protocole t cens tre compatible
avec notre version de NS2 lui-mme install sur une distribution Ubuntu.
Ayant eu beaucoup de problmes du a des incompatibilits au niveau des versions de
distributions et des logiciels que nous avons utilis, nous aurions du essayer plus rapidement
de changer de distribution Linux pour une Fedora. Nous ne pensions pas quune distribution
telle quUbuntu, aussi utilise, puisse nous poser autant de problmes.

3.2) Bilan Gnral
Au niveau du bilan gnral du projet, nous avons ainsi pu nous familiariser avec des
logiciels de simulation de rseau routier tel que SUMO et MOVE, mais aussi le logiciel de
simulations NS2.
Nous avons galement eu loccasion de nous familiariser plus largement avec les
recherches internet et les nombreuses documentations anglophones sur le sujet. Cela nous a
ensuite servi pour dvelopper notre propre algorithme de communication inter-vhicule
utilisant galement un rseau V2I.
Nous avons ainsi pu nous rendre compte quel point la cration et limplmentation
dun protocole ncessite du temps et de prendre en compte un grand nombre de paramtres
qui sont tous trs important pour le fonctionnement de lalgorithme.
Ceci tant, ce projet, sur lequel nous avons pass beaucoup de temps, nous a permis
de participer llaboration dun mcanisme qui sera probablement en srie sur nos
vhicules dans une dizaine danne.


CONCLUSION

Cette tude nous a permis de mieux connatre le monde de la recherche. Ce projet de
recherche mle la fois la recherche et l'ingnierie avec la perspective d'applications pour des
oprateurs de tlcommunication ce qui nous a permis de montrer nos capacits en tant
qu'ingnieur mais aussi en tant que chercheur.

Le domaine des rseaux de vhicules a un norme potentiel de dveloppement et
permettra une avance technologique importante dans les transports. Ce futur rseau et cette
tude nous donne envie de continuer dans ce domaine pour y apporter notre contribution.

GLOSSAIRE

*1* VANET: Vehicular Ad-Hoc Network.
*2* SUMO: Simulation of Urban Mobility.
*3* MOVE: MObility model generator for VEhicular
networks.

*4* IVG: Inter-Vehicle Geocast. IVG (Inter-Vehicle
Geocast) est une nouvelle mthode de
diffusion qui gnralise les mthodes
prcdentes (TRADE et DDT) et permet de
surmonter les problmes de fragmentation
du rseau, de fiabilit et de calcul de voisins.
Des relais dynamiques sont introduits pour
rediffuser priodiquement les messages
d'alerte. Ces relais sont dsigns en fonction
de la distance relative au vhicule source.
Une comparaison avec les mthodes TRADE
et DDT a t ralise en utilisant un modle
analytique et des simulations, et a montr
les amliorations apportes, et ce
indpendamment de l'environnement (rural
ou urbain).

*5* Cluster: ensemble de vhicule formant un groupe
/ convoie Durant une priode.
*6* Rseaux collaboratifs: partage de ressources (vidos,
musiques, ) entre vhicules.

*7* Rseau ad hoc : rseau sans infrastructure, Chaque
entit (node) communique directement
avec sa voisine.
*8* Hotspot: zone wifi accs Internet.
*9* IEEE 802.11b: transmission de donnes des dbits
allant jusqu' 11 Mbits/s sur la bande de
frquences des 2,4 GHz.

*10* SNR: rapport signal sur bruit dsignant la
qualit de la transmission d'une
information par rapport aux parasites.

*11* RTT : Round Trip Time : est un facteur
important. RTT peut tre utilise pour
trouver le meilleur itinraire possible.
*12* TCP : Transmission Control Protocol
(littralement, protocole de contrle de
transmissions ) abrg TCP, est un
protocole de transport fiable, en mode
connect.
*13* UDP : User Datagram Protocol (UDP, en
franais protocole de datagramme
utilisateur) est un des principaux
GLOSSAIRE
protocoles de tlcommunication utiliss
par Internet.
*14* RSSI : Received Signal Strength Indication
sortie d'un systme de rception d'un
signal sans fil (classiquement un signal
radio). Son utilit est de fournir un
signal li l'intensit du signal reu.
*15* Gigue : C'est la variation de dlai, c'est la
constante qui permet de prserver la
synchronisation entre l'metteur et le
rcepteur.
*16* OLSR : Optimized Link State Routing
Protocol est un protocole de routage
destin aux rseaux mobiles.
*17* AODV : Ad hoc On Demand Distance Vector
protocole de routage destin aux
rseaux mobiles (en mode ad-hoc). Il est
la fois capable de routage Unicast et
Multicast.. Lorsqu'un nud source
demande une route, il cre les routes la
vole et les maintient tant que la source
en a besoin. Pour les groupes multicast,
AODV construit une arborescence.
*18* Go localisation : Procd permettant de positionner un
objet (une personne, une information, ...)
sur un plan ou une carte l'aide de ses
coordonnes gographiques.
Cette opration est ralise l'aide d'un
terminal capable d'tre localis (grce
un rcepteur GPS ou d'autres
techniques) et de publier (en temps rel
ou de faon diffre) ses coordonnes
gographiques (latitude/longitude).

*19* Protocole PROACTIF :

Protocole REACTIF :
Protocole qui construit les tables de
routage avant que la demande en soit
effectue. Il identifie en fait chaque
instant la topologie du rseau.
Protocole qui construit une table de routage
lorsqu'un nud en effectue la demande. Il ne
connait pas la topologie du rseau, il
dtermine le chemin prendre pour accder
un nud du rseau lorsqu'on lui demande.

*20*DYMO : Le protocole de routage DYMO est le
successeur du protocole de routage (AODV).
Il est, toutefois, lgrement plus facile
mettre en uvre et visant apporter des
amliorations venir.
ANNNEXES

Table des Annexes :

Annexes 1 : Installation de DYMOUM

Annexes 2 : Algorithme dlection du CH

Annexe 3 : Code lection CH en C

Annexe 4 : Procdure dimplmentation dun nouveau protocole dans NS2.29

Annexe 5 : Cration dun fichier tcl de simulation
Annexe 1 : Installation de DYMOUM

Il existe un patch DYMO pour chaque version de NS2. Ce patch implmente le protocole
DYMO dans NS2, il nexiste actuellement aucun patch pour la version NS3.

Six patch existent pour le protocole DYMO :

Les versions de NS2.27, NS2.28, NS2.29.2 ne se compile pas car ces versions sont obsoltes
pour notre systme Fedora.
Patch :
- dymoum_ns-2.27_v0.1.patch

Le patch ne sapplique pas pour la version de NS2.33.
Patch :
- dymoum-0.3_ported_to_ns-2.33.patch

Erreur de NS2.34 pendant la compilation
Patch :

Le patch pour la version de NS2.29.3 fonctionne, la compilation, la configuration,
linstallation et le test se passe sans problme.
Patch :

La version 2.29.3 de NS est la seule qui fonctionne

Installation

On installe tout dabord les parquets de dpendances :
# yum install autoconf
# yum install automake
# yum install gcc-c++
# yum install libX11-devel
# yum install xorg-x11-proto-devel
# yum install libXt-devel
# yum install libXmu-devel

Il faut tlcharger et dcompresser la distribution NS2.29.3 allinone .
http://sourceforge.net/projects/nsnam/

Tlcharger le patch du protocole DYMO, dymoum-0.3.tgz .
http://sourceforge.net/projects/dymoum/

Il faut copier le fichier dymoum-0.3.tgz dans le dossier ns-allinone-2.29.3/ns-
2.29/

Ouvrir un terminal en root puis taper ces commandes :
# cd ns-allinone-2.29.3/ns-2.29/

# tar zxvf dymoum-0.3.tgz
dymoum-0.3/
dymoum-0.3/ns/
dymoum-0.3/ns/CVS/

dymoum-0.3/dymo_um.kdevelop.filelist
dymoum-0.3/dymo_generic.c
dymoum-0.3/dymo_generic.h

# ln -s ./dymoum-0.3 ./dymoum

# patch -p1 < dymoum/dymoum_ns-2.29_v0.3.patch
patching file common/packet.h
patching file Makefile.in
patching file queue/priqueue.cc
patching file tcl/lib/ns-agent.tcl
patching file tcl/lib/ns-default.tcl
patching file tcl/lib/ns-lib.tcl
patching file tcl/lib/ns-mobilenode.tcl
patching file tcl/lib/ns-packet.tcl
patching file trace/cmu-trace.cc
patching file trace/cmu-trace.h

Si linstallation na pas t faite:
# cd ..
# ./install

# gedit ~/.bashrc
Rajouter ces lignes la fin du fichier .bashrc et modifier la destination
/home/vanet/Bureau/ par rapport votre chemin.
# LD_LIBRARY_PATH
OTCL_LIB=/home/vanet/Bureau/ns-allinone-2.29.3/otcl-1.11
NS2_LIB=/home/vanet/Bureau/ns-allinone-2.29.3/lib
X11_LIB=/usr/X11R6/lib
USR_LOCAL_LIB=/usr/local/lib
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY
TCL_LIB=/home/vanet/Bureau/ns-allinone-2.29.3/tcl8.4.11/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH
XGRAPH=/home/vanet/Bureau/ns-allinone-2.29.3/bin:/home/vanet/Bureau/ns-allinone-
2.29.3/tcl8.4.11/unix:/home/vanet/Bureau/ns-allinone-2.29.3/tk8.4.11/unix
NS=/home/vanet/Bureau/ns-allinone-2.29.3/ns-2.29/
NAM=/home/vanet/Bureau/ns-allinone-2.29.3/nam-1.11/
PATH=$PATH:$XGRAPH:$NS:$NAM

Pour prendre en compte les modifications effectu.
# source ~/.bashrc

On reconfigure NS
# cd ns-2.29
# ./configure
Continuing with default options...
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu

config.status: creating indep-utils/cmu-scen-gen/setdest/Makefile
config.status: creating autoconf.h
config.status: autoconf.h is unchanged

# make distclean
autoconf.h gnuc.h os-proto.h tcl/lib/ns-autoconf.tcl; \
mv .configure .configure- ;\
echo "Moved .configure to .configure-"
mv: ne peut valuer `.configure': Aucun fichier ou dossier de ce type
Moved .configure to .configure-

# ./configure
# make

Test

# cd dymoum/ns/test/
# ns test_3n_m.tcl

Lorsquon effectue un test dun fichier du protocole DYMO, il gnre la fin du test deux
fichiers, un fichier trace rcapitulant les messages tests et un fichier nam pour sa visualisation.

Annexe 2 : Algorithme Election CH :

Si InterfacesCHc[i]==2 ; //Vrification des 2 interfaces
{
Tant Que (direction[i] == directionCHc[i]) {
Tableau_Meme_Direction[i]=directionCHc[i] ; } //Comparaison de la
direction du nud avec les
candidats
NombreCHc= Longueur(Tableau_Meme_Direction[i]) ;
//Algo de tri par ordre dcroissant des SNR reu de la BTS :
Entiers j ;
TableauSNR[j]=SNRCHc[p] ;
Pour (j=1 ;j<= NombreChc ; j++ ) // Tant que lon na pas compar
tous les CHc
{
Entier x = TableauSNR[j] ; //Comparaison de la nouvelle
entre
Entier i =j-1 ;
Tant Que( i >= 0 && TableauSNR[i]>x)
{
TableauSNR[i+1]= TableauSNR[i] ;
i = i 1 ;
}
TableauSNR[i+1]= x ;
}

//Le tableauSNR contient par ordre dcroissant SNR des CHc

// Algo de tri par ordre dcroissant de la position
Entiers j ;
TableauPos[j]=PositionCHc[p] ;
tous les CHc
{
Entier x = TableauPos[j] ; //Comparaison de la nouvelle
entre
Entier i =j-1 ;
Tant Que( i >= 0 && TableauPos[i]>x)
{
TableauPos[i+1]= TableauPos[i] ;
i = i 1 ;
}
TableauPos[i+1]= x ;
}

// Algo de tri par ordre dcroissant de la vitesse
Entiers j ;
TableauVit[j]=VitesseCHc[p] ;
tous les CHc
{
Entier x = TableauVit[j] ; //Comparaison de la nouvelle
entre
Entier i =j-1 ;
Tant Que( i >= 0 && TableauVit[i]>x)
{
TableauVit[i+1]= TableauVit[i] ;
i = i 1 ;
}
TableauVit[i+1]= x ;
}

//Comparaison de lensemble des tableaux en fonction des positions :

MoyenneMax = 1000; // initialisation a 1000 car on est sr qu'un
cluster // n'ateindra pas ce nombre;
Pour (k=0 ; k<NombreChc ; k++)
{
Si (CHc[k].SNR > SeuilSNR) // Vrifie que le seuil SNR est acceptable
{
Entier Moyenne= CHc[k].calculePositionTabSNR() +
CHc[k].calculePositionTabPos()+ CHc[k].calculePositionTabVit() ;
Si (Moyenne <= MoyenneMax) // inversion signe exemple: si Moyenne = 6
alors // Moyenne < MoyenneMax
{
MoyenneMax= Moyenne ; // inversion
CH= CHc[i] ; //Le CHc ayant la meilleur moyenne de
position //devient CH
}
}
Si (Ch= null) // Si malgr le test prcdent, aucun CH nest dcid
(SNR trop //faible), il faut quand mme lire un CH.
{
//On refait le test prcdent sans la condition du seuil SNR
Entier Moyenne= CHc[k].calculePositionTabSNR() +
CHc[k].calculePositionTabPos()+ CHc[k].calculePositionTabVit() ;
Si (Moyenne <= MoyenneMax) // inversion signe exemple: si Moyenne = 6
alors // Moyenne < MoyenneMax
{
MoyenneMax= Moyenne ;
CH= CHc[i] ;
}
}
}

// On vrifie que le Chc ayant le meilleur SNR est galement dans une distance
acceptable et une vitesse moyenne proche de celle du convoi.

Annexe 3 : Codes Election CH en C :

Fichier fonction.h :

#ifndef __FONCTION_H__
#define __FONCTION_H__

/* Importation des biliothques */
#include <stdio.h>
#include <stdlib.h>

/* Declaration des variables */
#define vitesseConvoi 115
#define directionConvoi 1
#define distanceConvoi 15
#define seuilSNR 45

/* Declaration de la structure CHc */
struct CHc {
char* name;
int interfaces;
int vitesse;
int direction;
int distance;
int SNR;
int CH;
};

/* Declaration des fonctions */
void classementSNR(int *);
void classementVitesse(int *);
void classementDistance(int *);
void electionCH(struct CHc *);
void afficheInfosCHc(struct CHc);
struct CHc initialisation(struct CHc);
void afficheInfo(struct CHc *);

#endif

Fichier fonction.c :

#include "fonction.h"

/* Classement du SNR du plus grand au plus petit */

void classementSNR(int * tab)
{
int i;
int j;
int temp;
for(i=0; i<5; i++){
for(j=0;j<5;j++){
if(tab[i]>tab[j]){

temp=tab[j];
tab[j]=tab[i];
tab[i]=temp;
}
}
}
}

/* Classement de la diffrence de vitesse par rapport au convoi du plus petit au plus grand */

void classementVitesse(int * tab)
{
int i;
int j;
int temp;
for(i=0; i<5; i++){
for(j=0;j<5;j++){
if(tab[i]<tab[j]){

temp=tab[j];
tab[j]=tab[i];
tab[i]=temp;
}
}
}
}

/* Classement de la diffrence de distance par rapport au convoi du plus petit au plus
grand*/

void classementDistance(int * tab)
{
int i;
int j;
int temp;
for(i=0; i<5; i++){
for(j=0;j<5;j++){
if(tab[i]<tab[j]){

temp=tab[j];
tab[j]=tab[i];
tab[i]=temp;
}
}
}
}

/* Retourne le ponteur du paramtre du CH dans le tableau */
int retournePointeurSNR(int * tabSNR, struct CHc chc)
{
int i;
int taille=sizeof(tabSNR);
for (i = 0; i < taille; i++)
{
if (chc.SNR == tabSNR[i])
{
return i;
}
}
}

int retournePointeurVitesse(int * tabVitesse, struct CHc chc)
{
int i;
int taille=sizeof(tabVitesse);
{
if ((chc.vitesse-vitesseConvoi) == tabVitesse[i])
{
return i;
}
}
}

int retournePointeurDistance(int * tabDistance, struct CHc chc)
{
int i;
int taille=sizeof(tabDistance);
{
if (chc.distance == tabDistance[i])
{
return i;
}
}
}

/* Fonction qui fait appel aux prcdentes pour lir le CH */
void electionCH(struct CHc * tab)
{
int j;
int tailleTab= sizeof(tab);
int tabVitesse[tailleTab];
int tabSNR[tailleTab];
int tabDistance[tailleTab];
for(j=0;j<tailleTab;j++)
{
tabSNR[j]=tab[j].SNR;
tabVitesse[j]=(tab[j].vitesse-vitesseConvoi); // On met dans le tableau des vitesse
l'cart relatif la moyenne du convoi
tabDistance[j]=tab[j].distance;
}

int i;
/* Dfinition d'un nombre correspondant au maximum des moyennes de classement =>
le CHc le mieux place
dans les tableaux aurra une valeur forcment infrieure a cette valeur */
int MoyenneMax=100;

/* On fait appel aux mthodes de classement des 3 tableaux de paramtres */
classementVitesse(tabVitesse);
classementDistance(tabDistance);
classementSNR(tabSNR);
for(i=0;i<tailleTab;i++){
/* Vrification de la double interface */
if (tab[i].interfaces == 2)
{
/* On vrifie que les CHc vont dans le meme direction (s'ils ont le meme signe pour
le paramtre direction) */
if ((tab[i].direction>0 && directionConvoi>0) || (tab[i].direction<0 &&
directionConvoi<0))
{

int iSNR = retournePointeurSNR(tabSNR, tab[i]);
int iDistance = retournePointeurDistance(tabDistance,tab[i]);
int iVitesse= retournePointeurVitesse(tabVitesse, tab[i]);
int Moyenne = iSNR + iVitesse + iDistance;
if (Moyenne<=MoyenneMax)
{
MoyenneMax=Moyenne;
tab[i].CH= 1;
if(tab[i-1].CH==1)
{
tab[i-1].CH=0;
}
}
}
}
}
int m;
for( m=0; m<tailleTab; m++)
{
if(tab[m].CH==1)
{
printf("Le CHc qui a ete elu CH est : %s \n", tab[m].name);
system("pause");
}
}
system("pause");
}

void afficheInfo(struct CHc * tab){

int i;
int tailleTab=sizeof(tab);
for(i=0;i<=tailleTab;i++)
{
printf("Le CHc de nom %s a les paramtres suivants: \n", tab[i].name);
printf("Rapport Signal/Bruit (en dB): %d \n", tab[i].SNR);
printf("Vitesse (en km/h): %d \n", tab[i].vitesse);
printf("Distance (en m): %d \n \n", tab[i].distance);
if(tab[i].CH==1)
{
printf("Le CHc de nom %s est galement le CH du cluster \n
\n",tab[i].name);
}
system("pause");
}

}

Fichier Main.c :

#include <stdio.h>
#include <stdlib.h>
#include "fonction.h"

int main(int argc, char *argv[])
{
/* Declaration des CH Candidate */
struct CHc CH1;
// CH1= initialisation(CH1);
CH1.vitesse= 120;
CH1.distance= 15;
CH1.name= "CH@12.5";
CH1.interfaces = 1;
CH1.direction = 15;
CH1.SNR= 0;
CH1.CH = 0;

struct CHc CH2;
CH2.vitesse= 115;
CH2.distance= 20;
CH2.interfaces = 2;
CH2.direction = 18;
CH2.SNR= 75;
CH2.CH = 0;

struct CHc CH3;
CH3.vitesse= 130;
CH3.distance= 12;
CH3.interfaces = 2;
CH3.direction = 12;
CH3.SNR= 53;
CH3.CH = 0;

struct CHc CH4;
CH4.vitesse= 115;
CH4.distance= 10;
CH4.interfaces = 2;
CH4.direction = 9;
CH4.SNR= 60;
CH4.CH = 0;

struct CHc CH5;
CH5.vitesse= 120;
CH5.distance= 15;
CH5.interfaces = 2;
CH5.direction = -10;
CH5.SNR= 5;
CH5.CH = 0;

/* On met les CHc dans un tableau */
struct CHc tab[5];
tab[0]=CH1;
tab[1]=CH2;
tab[2]=CH3;
tab[3]=CH4;
tab[4]=CH5;

/* Appel la fonction d'election du CH */
electionCH(tab);
afficheInfo(tab);

}

Annexe 4 : Procdure d'implmentation d'un
nouveau protocole dans ns 2.29

Nous allons montrer comment un nouveau protocole s'insre dans NS. Le protocole
"ping" consiste ce qu'un noeud mette un paquet vers un autre noeud. Le noeud de
destination rflchit le paquet la source. Le temps de transfert aller- retour est
ensuite calcul. Pour ajouter un protocole, il faut localiser sa place dans l'architecture
de TCP/IP. Si c'est un protocole au dessus de IP, la classe agent est recommande. La
classe Agent met en place l'interface pour gnrer et manipuler un paquet IP. Si c'est
un protocole de transmission, il peut tre intressant de driver la classe LinkDelay
pour utiliser le mcanisme de blocage lorsqu'il y a un paquet en transit,

Le protocole "ping" utilise IP, ce sera donc une classe drive de la classe Agent. Il
convient
maintenant d'crire le code C++ de ce composant. Dans le fichier d'en-tte 'ping.h', il
faut dclarer la structure de l'unit de donnes de protocole. Dans la terminologie NS,
on parlerait ( tort) de paquet ping. La dclaration du paquet ping consiste dfinir
un en-tte de paquet qui sera ajout par le PacketHeaderManager aux en-ttes que
comportera un paquet de NS (voir Paquet et en-tte).

struct hdr_ping {
char ret;
double send_time;
};

Le champ ret prend la valeur 0 quand le paquet est mis par la source et 1 quand il est
rflchi par la destination. Ce champ sert distinguer un paquet mis d'un paquet
rflchi. Le champ send_time est l'estampille temporelle. Il contient l'instant
d'mission du paquet (en heure simule) et servira au calcul du temps de transfert
aller et retour.


La classe PingAgent est dfinie comme une sous-classe de Agent. class PingAgent :

public Agent {
public:
PingAgent();
int command(int argc, const char*const* argv);
void recv(Packet*, Handler*);
protected:
int off_ping_;
};

La classe PingAgent comporte un constructeur et deux fonctions qui sont redfinies
(command() et recv()). La variable off_ping_ sert accder l'en-tte du protocole
ping (struct hdr_ping) contenu dans un paquet NS. Elle indique la localisation de l'en-
tte hdr_ping dans la zone des enttes du paquet NS. La variable off_ping_ d'un
PingAgent est initialise en tant un attribut li avec l'attribut off_ping_ d'un
SplitObject. Le SplitObject est la classe racine d'un objet de l'interprteur.
Un objet PingAgent dans l'interprteur hrite des attributs de la classe SplitObject. La
valeur de l'attribut off_ping_ du SplitObject est calcule dans l'interprteur la
cration du simulateur (new Simulator) par la fonction ns-
packet.tcl:create_packetformat{}.
Le constructeur PingAgent tablit les liaisons entre les attributs de l'objet de
l'interprteur et celui du simulateur.

PingAgent::PingAgent() : Agent(PT_PING)
{
bind("packetSize_", &size_);
bind("off_ping_", &off_ping_);
}
Le constructeur de PingAgent appelle le constructeur de Agent avec comme argument
le type du paquet (PT_PING). Cette information sera mise dans le paquet et sert
principalement identifier un protocole dans les traces. La valeur du littral
PT_PING est dfinie dans le fichier packet.h sous la forme d'une constante numrique
au moyen d'un #define:

#define PT_SRM 16
#define PT_PING 17
#define PT_NTYPE 18 // Fin de liste

Dans le mme fichier, il faut editer "PT-NAMES" pour inclure le nom sous lequel
apparatra les traces pour ce protocole. A la 17ime position, ajouter la chane "Ping".
L'attribut size_ est hrit de la classe Agent. Il indique la taille d'un paquet et servira
calculer le
temps de transmission du paquet. La taille indique la longueur des donnes et des en-
ttes (au moins
IP). L'initialisation de la taille est effectue via l'interprteur. Dans le fichier
tcl/lib/nsdefault.tcl, il faut ajouter une ligne pour l'initialisation de la taille du paquet.
Tous les objets de la classe Agent/Ping (nom de notre agent dans l'interprteur)
auront l'attribut packetSize_ initialis la valeur 64 qui pour l'objet clon dans le
simulateur aura le nom d'attribut size_.Agent/Ping set packetSize_ 64
La classe PingAgent redfinit command(). Cette fonction est appele quand une
commande Tcl pour un objet de la classe Agent/Ping n'a pas t localise dans
l'interprteur. Cette fonction est un moyen bien pratique pour ajouter des
commandes Tcl l'interprteur dont le code est crit en C++.

int PingAgent::command(int argc, const char*const* argv)
{
if (argc == 2) {
if (strcmp(argv[1], "send") == 0) {
// Create a new packet
Packet* pkt = allocpkt();
// Access the Ping header for the new packet:
hdr_ping* hdr = (hdr_ping*)pkt->access(off_ping_);
// Set the 'ret' field to 0, so the receiving node knows
// that it has to generate an echo packet
hdr->ret = 0;
// Store the current time in the 'send_time' field
hdr->send_time = Scheduler::instance().clock();
// Send the packet
send(pkt, 0);
// return TCL_OK, so the calling function knows that the
// command has been processed
return (TCL_OK);
}
}
// If the command hasn't been processed by PingAgent()::command,
// call the command() function for the base class
return (Agent::command(argc, argv));
}

PingAgent::command() dfinit la nouvelle commande Tcl "send". L'envoi consiste
prparer un paquet et l'envoyer par l'instruction send(pkt, 0). Cette ligne appelle la
fonction
Connector::send{target_->recv(p,h);}. Rappelons qu'un agent est driv d'un connector.
La target de l'agent est le point d'entre du noeud o est attach l'agent. C'est souvent
le classifieur
d'adresses. La variable target_ est initialise lors de l'attachement de l'agent un
noeud
(Simulator attach-agent{}).
La dernire fonction dfinir pour un PingAgent est celle de la rception d'un paquet.
Elle est appele par le port classifier du noeud. Lorsque cet objet reoit un paquet, il
dtermine quel agent remettre le paquet et appelle recv() de cet agent.

void PingAgent::recv(Packet* pkt, Handler*)
{
// Access the IP header for the received packet:
hdr_ip* hdrip = (hdr_ip*)pkt->access(off_ip_);
// Access the Ping header for the received packet:
hdr_ping* hdr = (hdr_ping*)pkt->access(off_ping_);
// Is the 'ret' field = 0 (i.e. the receiving node is being pinged)?
if (hdr->ret == 0) {
// Send an 'echo'. First save the old packet's send_time
double stime = hdr->send_time;
// Discard the packet
Packet::free(pkt);
// Create a new packet (Agent::allocpkt)
Packet* pktret = allocpkt();
// Access the Ping header for the new packet:
hdr_ping* hdrret = (hdr_ping*)pktret->access(off_ping_);
// Set the 'ret' field to 1, so the receiver won't send another echo
hdrret->ret = 1;
// Set the send_time field to the correct value
hdrret->send_time = stime;
// Send the packet
send(pktret, 0);
} else {
/* A packet was received. Use tcl.eval to call the Tcl interpreter with the ping results.
Note: In the Tcl code, a procedure 'Agent/Ping recv {from rtt}'
has to be defined which allows the user to react to the ping result. */
char out[100];
// Prepare the output to the Tcl interpreter. Calculate the round
// trip time
sprintf(out, "%s recv %d %3.1f", name(),
hdrip->src_ >> Address::instance().NodeShift_[1],
(Scheduler::instance().clock()-hdr->send_time) * 1000);
Tcl& tcl = Tcl::instance();
tcl.eval(out);
// Discard the packet
Packet::free(pkt);
}
}
A noter que l'attribut off_ip_ est dfini et gr par la classe Agent. Lorsque le paquet
rflchi arrive la source, le rsultat est affich par l'interprteur au moyen de
l'instance procdure recv{} de Agent/Ping appele partir du code C++. L'appel d'une
commande de l'interprteur est effectu par la fonction Tcl::eval(), l'argument est la
commande Tcl faire valuer.
Pour terminer l'criture du code C++ de l'agent ping, il faut dfinir la liaison entre les
objets du simulateur et ceux de l'interprteur. A la cration d'un objet dans
l'interprteur, un objet quivalent est cre dans le simulateur. Tout d'abord, nous
allons effectuer la liaison pour l'en-tte du paquet ping. Bien que dans notre exemple,
nous n'accdons pas depuis l'interprteur aux champs de l'entte du paquet ping,
nous devons effectuer la liaison avec l'interprteur pour le calcul de localisation
(offset) de l'en-tte ping dans la zone mmoire des en-ttes du paquet. Ce calcul est
effectu par l'interprteur l'aide du PacketHeaderManager.

static class PingHeaderClass : public PacketHeaderClass {
public:
PingHeaderClass() : PacketHeaderClass("PacketHeader/Ping",
sizeof(hdr_ping)) {}
} class_pinghdr;


La liaison pour le paquet ping est dfinie par la variable statique class_pinghdr de la
classe
PingHeaderClass. La classe de cette variable est drive de la classe
PacketHeaderClass qui constitue la racine pour l'enregistrement de tous les en-ttes
de paquets. Le constructeur PacketHeaderClass() comporte deux arguments:

- le nom de la classe OTcl pour l'en-tte. Le nom est toujours prfix par
"PacketHeader/" qui
est la classe racine OTcl.
la taille de l'en-tte.

static class PingClass : public TclClass {
public:
PingClass() : TclClass("Agent/Ping") {}
TclObject* create(int, const char*const*) {
return (new PingAgent());
}
} class_ping;

L'enregistrement de la classe Agent/Ping dans l'interprteur est effectu par le
constructeur PingClass de l'objet static class_ping qui est construit au dmarrage de
l'application NS. Une instance Agent/Ping est cre partir de l'interprteur par la
commande: new Agent/Ping. Cette commande appelle via create_shadow() la mthode
PingClass::create() pour la cration d'un PingAgent dans le simulateur. Nous avons
ainsi la cration de deux objets Agent/Ping: un pour l'interprteur et son clone
PingAgent pour le simulateur. Le code complet de ping est fourni en annexe de ce
document.

Enfin pour utiliser l'en-tte hdr_ping dans un paquet NS, il faut indiquer au
PacketHeaderManager d'initialiser l'attribut off_ping_. Dans le fichier tcl/lib/ns-
packet.tcl, il faut ajouter la liste des protocoles la ligne : { Ping off_ping_ }. Le
protocole ("Ping") doit avoir le mme nom et la mme syntaxe que le suffixe du nom
du paquet OTcl ("PacketHeader/Ping").

Pour la compilation de ping, il faut ajouter "ping.o" la variable OBJ_CC du
makefile. Ensuite vous pouvez compiler NS simplement en tapant "make". Une fois,
l'excutable NS prt, il ne reste plus qu' tester le protocole ping par ce petit script :

#Define a 'recv' function for the class 'Agent/Ping'. This function will be
# called by PingAgent::recv() function.
Agent/Ping instproc recv {from rtt} {
$self instvar node_
puts "node [$node_ id] received ping answer from \
$from with round-trip-time $rtt ms."
}
#Create a simulator object
set ns [new Simulator]
#Open a trace file
set nf [open out.nam w]
$ns namtrace-all $nf
#Define a 'finish' procedure
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
#Create three nodes
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
#Connect the nodes with two links
#Create two ping agents and attach them to the nodes n0 and n2
set p0 [new Agent/Ping]
$ns attach-agent $n0 $p0
set p1 [new Agent/Ping]
$ns attach-agent $n2 $p1
#Connect the two agents
$ns connect $p0 $p1
#Schedule events
$ns at 0.2 "$p0 send"
$ns at 1.0 "finish"
#Run the simulation
$ns run
Annexe 5 : Cration dun fichier tcl de simulation

Nous allons crer un fichier .tcl pour simuler des nuds dans un environnement de
simulation.

# ======================================================================
# dfinir les paramtres
# ======================================================================
set opt(chan) Channel/WirelessChannel ;# type de canal
set opt(prop) Propagation/TwoRayGround ;# modle radio diffusion
set opt(netif) Phy/WirelessPhy ;# type d'interface rseau
set opt(mac) Mac/802_11 ;# type MAC
set opt(ifq) Queue/DropTail/PriQueue ;# interface de type file
d'attente
set opt(ll) LL ;# type de couche liaison
set opt(ant) Antenna/OmniAntenna ;# modle d'antenne
set opt(ifqlen) 50 ;# paquets taille max dans
la file d'attente (ifq)
set opt(nn) 50 ;# nombre de noeud mobile
set opt(adhocRouting) DYMOUM ;# protocole de routage
set opt(cp) "" ;# connection pattern
file - fichier: schma de connexions
set opt(sc) "cbr-50-10-4-512" ;# fichier: dplacement des
noeuds

set opt(x) 670 ;# coordonne X de la
topologie
set opt(y) 670 ;# coordonne Y de la
topologie
set opt(seed) 0.0 ;# gnrer un nombre
alatoire (seed = 0) - seed for random number gen.
set opt(stop) 900 ;# dfinir le temps pour
l'arrt de la simulation

set opt(cbr-start) 50.0
#==========================================================================

#
# check for random seed
#
if {$opt(seed) > 0} {
puts "Seeding Random number generator with $opt(seed)\n"
ns-random $opt(seed)
}

#
# cration d'une instance du simulateur
#
set ns_ [new Simulator]

#
# controle du comportement de DYMOUM de tous les agents
#
Agent/DYMOUM set debug_ true ;# affiche les messages de dbogage sur
l'cran
Agent/DYMOUM set no_path_acc_ true ;# activer la sauvegarde des routes dans
la table de routage
Agent/DYMOUM set reissue_rreq_ false ;# essaie de dcouvrir des routes
quand il choue la 1re fois
Agent/DYMOUM set s_bit_ false ;# paramtre le S-bit de l'en tte de
DYMO
Agent/DYMOUM set hello_ival_ 1 ;# Spcifie l'intervalle entre les
messages HELLO, si la valeur est 0 la surveillance des voisins est
effectue par les informations de la couche liaison.

#
# fichiers de traces contenant les rsultats
#
set tracefd [open test_2n_m.tr w]
set namtrace [open test_2n_m.nam w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $opt(x) $opt(y)

#
# Cration d'un objet topology
#
set topo [new Topography]

#
# Les limites du monde en dfinissant les coordonns X et Y
#
$topo load_flatgrid $opt(x) $opt(y)

#
# cration d'un objet God (General Operations Director)
# il s'agit d'un objet utilis pour stocker les informations globales
propos de l'environnement
#
set god_ [create-god $opt(nn)]

#
# configuration des noeuds mobiles
#
$ns_ node-config -adhocRouting $opt(adhocRouting) \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topoInstance $topo \
-wiredRouting OFF \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace OFF

#
# cration des noeuds mobiles
#
for {set i 0} {$i < $opt(nn)} {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 1 ;# active les mouvements alatoires (0
dsactive)
}

#
# configuration du traffic entre les noeuds (UDP)
#
set udp [new Agent/UDP]
set null [new Agent/Null]
$ns_ attach-agent $node_(0) $udp
$ns_ attach-agent $node_(1) $null
$ns_ connect $udp $null
set cbr [new Application/Traffic/CBR]
$cbr set packetSize_ 512
$cbr set rate_ 20Kb
$cbr attach-agent $udp
$ns_ at $opt(cbr-start) "$cbr start"

#
# sauvegarde dans le fichier de "trace" la table de routage
# et autre structure de donn interne sur chaque noeud
#$ns_ at 15.0 "[$node_(0) agent 255] print_rtable"

#
# connexion de modle et de noeud de circulation
# source connection-pattern and node-movement scripts
#
if { $opt(cp) == "" } {
puts "*** NOTE: pas de schema de connexion dfinis."
set opt(cp) "none"
} else {
puts "Chargement du schema..."
source $opt(cp)
}
if { $opt(sc) == "" } {
puts "*** NOTE: pas de fichier scenario definit."
set opt(sc) "none"
} else {
puts "Chargement du fichier scenario..."
source $opt(sc)
puts "Chargement complte..."
}

#
# dfinit les positions initial des noeuds dans nam
#
for {set i 0} {$i < $opt(nn)} {incr i} {
$ns_ initial_node_pos $node_($i) 20
}

#
# Dfinit l'instant ou la simulation se termine et on indique aux noeuds
de faire un reset
# sur leurs valeurs
#
for {set i 0} {$i < $opt(nn) } {incr i} {
$ns_ at $opt(stop).0 "$node_($i) reset";
}

$ns_ at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
$ns_ at $opt(stop).0001 "stop"

proc stop {} {
global ns_ tracefd namtrace
$ns_ flush-trace
close $tracefd
close $namtrace
}

#
# dmarrer la simulation
#
puts "Starting Simulation..."

$ns_ run

Ce fichier tcl appelle un autre fichier contenant le scnario des nuds, les positions, ces
dplacements dans le temps.
Exemple de scnario :

# On dfinit 2 nuds avec ces positions X, Y, Z :
#$node_(0) set X_ 5.0
#$node_(0) set Y_ 2.0
#$node_(0) set Z_ 0.0
#$node_(1) set X_ 390.0
#$node_(1) set Y_ 385.0
#$node_(1) set Z_ 0.0

# Produire les mouvements
# le noeud 1 commence se dplacer vers le noeud 0
#
#$ns_ at 10.0 "$node_(0) setdest 20.0 18.0 1.0"

# le noeud 1 commence s'loigner du noeud 0

Il ne reste plus qu lancer le test avec la commande :
# nam fichier.tcl

A la fin de la simulation, 2 fichiers seront gnrs, 1 fichier trace rcapitulant la simulation tcl
et 1 fichier nam pour la visualisation du scnario.

On observe les mouvements des nuds sous nam et la diffusion des paquets :
# nam fichier.nam


Rapport Final de Projet

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Final de Projet

Transféré par

Droits d'auteur :

Formats disponibles

LAYOUNI Majid MASTER 1 WESLEM Wahid

MAZOT Raphael 2009/2010 TRAN Alexandre

Vous aimerez peut-être aussi