Chmicha Abdelfatah

Franc Thomas
Garcia Damien

RAPPORT- Projet M1
Simulation de communication VANET

Centre d'Enseignement et de Recherche en Informatique – 2015-2016

 SOMMAIRE

1. Brève présentation …...............................................3

1.1 Rappel sur VANET …..........................................................3
1.2 Rappel de l'objectif …..........................................................4
1.3 Rappel des algorithmes …...................................................4
1.4 Rappel d'OMNeT++ ….......................................................11
1.5 Google Earth ….................................................................11

2. Exigences …...........................................................11
2.1. Exigences fonctionnelles …..............................................11
2.2. Non fonctionnelles …........................................................12

3. Réalisation …..........................................................12
3.1. ChannelController.cc …....................................................13
3.2. MobileNode.cc …..............................................................16
3.3. Fichiers ned et ini ….........................................................17
3.4. Compiler le programme …................................................18
3.5. Calculs des points pour les déplacements des véhicules 18

4. Organisation ….......................................................19
4.1. Les Intervenants …...........................................................19
4.2. Problèmes rencontrés …..................................................19

5. Annexe …................................................................20

2/20
1. Brève présentation
1.1. Rappel sur VANET
Le fait d’avoir du matériel permettant d'émettre et de recevoir dans
les véhicules, forment un réseau VANET ou autrement dit un réseau
Ad Hoc.
Les réseaux Ad Hoc sont des réseaux dans lesquels l’information
transite d’équipement en équipement sans passer par un point
d'accès. Il n’y a pas donc d’infrastructure (serveurs, routeurs etc).
Dans le cas du réseau VANET , les composants du réseau sont
exclusivement des véhicules. Ils communiquent entre eux directement
sans quelconque intermédiaire.

Avoir un tel réseau permettrait d’augmenter la sécurité routière.

Notamment grâce aux alertes pouvant être envoyées lorsqu’un
véhicule rencontre un problème technique. Par exemple, si sur une
voie rapide ou une autoroute, le pneu d’un véhicule éclate, il devient
alors un danger pour les autres véhicules. Le véhicule va alors leur
envoyer un message d’alerte pour avertir les autres véhicules du
problème rencontré et les automobilistes pourront ainsi adapter leur
conduite et éviter tout accident.

3/20
 Deux problèmes se présentent :
-l'optimisation de la puissance.
-Les délais de transmission.

Des algorithmes ont été créés pour faire face à ces problèmes.
Comme les algorithmes BIP et Dijkstra.

1.2. Rappel de l’objectif

Ce projet a déjà fait l’objet de recherches les années précédentes.
Les étudiants avaient pour objectifs d'améliorer ces algorithmes
Notre travail consiste à simuler différentes situations de trafic routier
afin d’observer et de comparer les performances des deux algorithmes
implémentés à travers Google Earth.

1.3. Rappel des algorithmes

1.3.1. L'algorithme BIP
L'algorithme BIP (Broadcast Incremental Power) permet de lier tous
les nœuds d'une topologie en minimisant la puissance utilisée. A
chaque étape de l'algorithme, le puissance d'émission est augmentée
jusqu'à ce qu'un nœud non atteint au préalable le soit.
Par conséquent un même nœud pourra utiliser une puissance bien
plus grande que les autres, ce n'est donc pas la puissance de chaque
nœud qui est minimisée mais la puissance totale.

Imaginons une configuration de nœud telle que l’image qui suit où le

nœud 1 va vouloir atteindre tous les nœuds:

4/20
 Illustration 1: Etape 0 BIP
Illustration 2: Etape 1 BIP

Le nœud 1 atteint le nœud le plus proche: le nœud 4

Illustration 3: Etape 2 BIP

Ensuite, si on prend en compte les 2 nœuds atteints 1 et 4, le nœud

le plus proche par rapport à 1 ou à 4 est le nœud 2.

5/20
 Illustration 4: Etape 3 BIP

Sur les 3 nœuds atteints, le plus proche de l’un d’eux est le nœud 3
qui est le plus proche de 1.

Illustration 5: Etape 4 BIP

Le dernier restant, le nœud (le nœud 5) est atteint depuis le nœud 3

car c’est depuis ce nœud que la puissance nécessaire est la plus
faible.

On note “P” la puissance d’émission totale, “C(noeud1,noeud2)” la

puissance d’émission nécessaire au “noeud1” pour atteindre le

6/20
 “noeud2”, et “a” l’indice correspondant à l’environnement (2<a<4 où 2
est le milieu rural et 4 le milieu urbain).

La puissance totale P est calculée comme suit:

P=max(C(1,2)^a,C(1,4)^a,C(1,3)^a)+max(C(3,5)^a)
P=C(1,3)^a)+(C(3,5)^a)

1.3.2. L'algorithme Dijkstra

L'algorithme Dijkstra permet de trouver le plus court chemin
séparant 2 nœuds distants. Pour cela, à partir du nœud qui veut
atteindre le nœud de destination, il permet de définir les éventuels
nœuds intermédiaires entre la source et la destination (en terme de
distances), en explorant toutes les possibilités offertes par la topologie.

Imaginons une configuration de nœuds telle que:

Illustration 6: Etape 0 Dijkstra

Nous cherchons à connaître le plus court chemin reliant A à D.

7/20
 Illustration 7: Etape 1 Dijkstra

Les “poids” des routes reliant A à B et A à C sont connus.

Illustration 8: Etape 2 Dijkstra

Le chemin le plus court pour avancer dans la topologie est le

chemin menant au nœud C.

8/20
 Illustration 9: Etape 3 Dijkstra

Nous regardons, à présent, les routes en partant de C. Ainsi, nous

pouvons identifier que le nœud D peut être relié à A avec un coût de 8.
Nous continuons le parcours (afin de trouver un chemin plus court). Le
nœud B peut être relié à A en passant par le nœud C, ce qui est plus
court que le lien direct (coût: 3).

Illustration 10: Etape 4 Dijkstra

Le nœud D peut être atteint depuis B, avec un coût total de 5,

inférieur à celui de la route établie auparavant.

9/20
 Illustration 11: Etape 5 Dijkstra

Le chemin le plus court pour atteindre le nœud D est donc: A-C-B-D.

10/20
 1.4. Rappel d’OMNeT ++
OMNeT++ est un environnement de développement intégré (IDE)
qui utilise le langage C++. OMNeT++ sert principalement à modéliser,
simuler des systèmes de communication sans fils et filaire. Il est
composé de modules
qui contiennent des algorithmes relatifs au type de réseau
implémenté.

1.5. Google Earth

Il existe un exemple de communication inter-véhiculaire fourni
avec le logiciel OMNeT++. Il met en communication 10 véhicules qui
circulent dans un petit périmètre situé en plein milieu d’un désert.
OMNeT++ possède un fichier de type KML. Une fois lancé, ce
fichier génère un lien http en local dans lequel se trouve les
informations nécessaires pour afficher le déplacement des véhicules
sur Google Earth.
Google Earth apporte un plan “réel” à notre simulation, puisque
nous prenons en compte les routes déjà existantes dans la réalité.
Dans notre cas, nous avons choisi 2 routes différentes :
– La N7
– La A7

2. Exigences
2.1. Exigences Fonctionnelles
Nous devions implémenter 2 algorithmes (BIP et Dijkstra), de
manière à voir comment chacun de ces algorithmes allait se comporter
dans la simulation.

Nous devions mettre en place un système pour représenter les liens

entre les véhicules en temps réel, de manière à voir quel véhicule
communique directement avec quel autre véhicule.

L'affichage visuel des zones de couverture de chaque véhicule en

temps réel, en fonction de leur puissance d'émission était aussi à
implémenter. Ainsi, une zone coloré devait s'afficher autour de chaque
véhicule.

11/20
 Enfin, un arbre de diffusion devait être créé et afficher en temps
réel, afin d'afficher pour chaque véhicule avec quel(s) véhicule(s) il
communique et avec quelle puissance d'émission.

2.2. Non fonctionnelles

La simulation de la communication VANET devait prendre place
dans un environnement réaliste. Nous avions choisi d'utiliser un
exemple sur Google Earth, mais nous devions le modifier afin que des
véhicules se déplacent le long d'une route. Voici les quelques
éléments que nous devions mettre en place concernant cet aspect du
projet:

● Trajectoire des véhicules définie (déplacement des véhicules sur

la route)
● Différents scénarios de trafic : urbain (trafic dense, vitesse faible,
etc...) et autoroute (vitesse élevée, distances inter-véhicules plus
grandes, etc...)
● Voir les véhicules dans un lieu où il y a des routes

3. Réalisation

Dans l'exemple se trouve deux fichiers principaux pour notre projet.

Le fichier ChannelController.cc et le fichier MobileNode.cc programmé
en C++.
Dans le premier nous avons placé l'algorithme BIP et modifié le
code pour que le programme s'en serve et calcule les distances.
Dans le second nous avons placé les points de la route ainsi que les
points où doit passer chaque véhicule. Nous avons aussi modifié le
code pour que les véhicules suivent ces points et non suivre un
déplacement aléatoire.

12/20
 Illustration 12: Fichiers importants pour le projet

3.1. ChannelController.cc

Une seule fonction nous intéresse dans ce fichier, c'est la fonction

getKmlFragment. C'est ici que les liens entre les véhicules sont créés
et enregistrés pour Google Earth.
Dans la version originale une variable connections est créée puis
vérifie pour chaque paire de véhicules, grâce à une double boucle for,
s'ils sont assez proches pour faire une connexion.
Nous avons donc récupéré les lignes qui permetent de connecter
deux véhicules ensemble pour nous en servir après le lancement de
l'algorithme BIP.

13/20
 Mais avant toute chose, il faut calculer les distances entre tous les
véhicules pour créer la matrice des distances. Pour cela, nous avons
utilisé un simple calcul pour mesurer la distance entre deux points sur
un graphique:

AB =√ (x b− x a ) ²+( y b− y a )²

Ensuite, nous avons créé l'algorithme BIP et l'avons placé dans une
nouvelle fonction. Cette fonction a dû étre déclarée dans le fichier
ChannelController.h .

Fonctionnement de BIP:

Pour la création de l'algorithme nous l'avons pensé ainsi.

Il va en premier lieu partir d'un point et rechercher le point le plus
proche avec une matrice des distances. Lorsqu'il est trouvé il est alors
ajouté à la liste des points connectés et il est possible de chercher les
points les plus proches avec ce point-là aussi.
Mais avant cela, il soustrait la distance entre les deux points aux
distances entre le premier point et tous les autres. L'algorithme
préférera augmenter sensiblement la puissance d'un point pour en
atteindre un autre qu'augmenter considérablement la puissance d'un
autre point même s'il est plus proche.

14/20
 Prenons l'exemple suivant

Illustration 13: Exemple de BIP

Tout part du point0. Le point0 se connecte au point1, puis au point2.

Ensuite le point1 se connecte au point3.
Avec les puissances visibles il est plus facile de voir qu'en
augmentant un peu la puissance du point1 on atteint le point4 avec
moins d'efforts que si on augmentait la puissance du point0.

Pour éviter que le point0 ne se connecte au point3 après la

connexion au point2 par exemple, les distances sont préalablement
élevées au carré (ou plus). Cela simule le coût plus élevé pour couvrir
une distance plus grande.

15/20
 Pseudo-code de la fonction BIP:

Tant que les points ne sont pas tous connectés

| Pour i allant de 0 au nombre total de points
| | Si le n°i est connecté
| | | Pour j allant de 0 au nombre total de points
| | | | Si la distance entre le point n°i et le point n°j est supérieure à 0
| | | | et est la plus petite
| | | | | Si les 2 points ne sont pas deja connectés
| | | | | | On enregistre la connexion
| | | | | | voitureA = i, voitureB=j
|
| Ajout du nouveau point connecté dans la liste des points connectés
| Change la taille de la puissance émise par la distance entre les deux points
|
| Pour i allant de 0 au nombre total de point
| | Les cellules n°i de la ligne et de la colonne de la voitureA = La distance entre
| | le point n°i et la voitureA MOINS la distance entre la voitureA et la voitureB
| | (Avec le nécessaire pour mettre les distances élevées à la bonne puissance)
| |
| | Si ces cellules sont inférieures à 0
| | | Ces cellules = 0

3.2. MobileNode.cc

Dans ce fichier se trouve la fonction handleMessage. À l'intérieur de

celle-ci est actualisé la position du MobileNode (le véhicule). Le point
où sera placé le véhicule à la sortie de cette fonction est donné grâce
au changement aléatoire (avec limite) de l'orientation du véhicule et
d'un petit déplacement dans cette direction.
Grâce à cette technique les véhicules n'ont pas besoin d'avoir
d'identifiant. Nous avons dû en créer pour que les véhicules sachent
quels points ils doivent suivre. Nous avons donc créé une variable de
classe static que l'on incrémente dans le constructeur et on l'attribut à
une variable de classe id .

Nous avons créé trois tableaux, un pour les coordonnées x, un pour

les coordonnées y des points où les véhicules doivent passer et un
pour les points où le MobileNode doit passer.
C'est pour ce dernier tableau que l'identifiant est utile.

16/20
 Après avoir défini les points, il faut attribuer les coordonnées aux
véhicules. La fonction handleMessage est lancée en boucle lorsque la
simulation est lancée. Il n'y a pas de moyen de savoir combien de fois
elle a été lancée. Nous avons donc créé une variable de classe qui
sera incrémenté à chaque passage dans la fonction.
En sachant combien de fois la fonction a été lancée, on sait que le
véhicule doit être placé sur un point précis.

La simulation ne fonctionne pas sur Google Earth si elle n'est pas

lancée en mode Express. Donc pour que ce ne soit pas trop rapide
nous avons aussi mis en place un multiplicateur que l'on peut modifier
comme nous voulons pour accélérer ou ralentir la simulation.

Pour ne pas surcharger la simulation l'affichage des puissances

d'émissions est désactivé avant qu'il y est une simulation d'incident sur
la route. Cette action nécessite aussi une déclaration de variable de
classe car le passage où on peut activer ou non l'affichage se trouve
dans une autre fonction.

Pour faciliter le paramétrage et éviter de compiler le programme

pour certains changements de paramètres, il y a aussi quelques
fichiers utiles.

3.3. Fichiers ned et ini

Grâce à ces fichiers il est possible de déclarer des paramètres que

l'on va pouvoir utiliser partout dans le programme avec une ligne
comme celle-ci:

int uneVariable = simulation.getSystemModule()->par("NomDuParametre");

La déclaration se fait dans GoogleEarthNet.ned pour les paramètres

généraux et dans MobileNode.ned pour les paramètres spécifiques
aux véhicules.
Dans ces fichiers se trouve une catégorie parameters il suffit de
déclarer une variable avec le même nom que le paramètre.

17/20
 Dans le fichier omnetpp.ini on attribue les valeurs aux paramètres
comme cela:

**.NomDuParametre = uneValeur

3.4. Compiler le programme

Pour compiler le programme il ne suffit pas de cliquer sur build dans

l'IDE d'OMNeT++, il faut utiliser la console d'OMNeT++ qui permet
normalement à installer le logiciel. Lorsque l'on lance la commande
make qui effectue l'installation cela lance également les makefiles de
tous les projets.
Il faut compiler ainsi lorsque l'on modifie les fichiers écrits en C++.

3.5. Calculs des points pour les déplacements des

véhicules
Afin de gérer les déplacements des véhicules sur Google Earth,
nous avons choisi de les faire suivre une succession de points dont les
coordonnées ont été calculées à partir de 2 images de Google Earth,
pour 2 scénarios différents: sur un rond-point et sur l’autoroute.
Pour cela, nous avons imprimé les 2 images et calculé leurs
coordonnées à partir d’un point d’origine. Ci-dessous, on peut voir les
2 situations choisies: à gauche, le rond-point, et à droite, l’autoroute.
Les croix représentent les points dont nous avons calculé les
coordonnées (ici juste la situation “autoroute”).
Le point à gauche nous a servi d’origine, et grâce à l’échelle (en bas
à droite), nous avons mesuré à l’aide d’une règle les distances en
centimètres, sur l’axe des x et l’axe des y, séparant chaque nouveau
point de l’origine. Ensuite grâce à un simple produit en croix avec
l’échelle, nous avons converti cette distance de centimètres à mètres.

Exemple en annexe 1

18/20
4. Organisation
4.1. Les Intervenants
Responsables :
- Huet Stéphane
- Jabaian Bassam

Tuteur :
- Zhou Fen

Étudiants :
- Chmicha Abdelfatah : Recherches sur OMNeT++
- Franc Thomas : Recherches algorithmes
- Garcia Damien : Analyse du code source

4.2. Problèmes rencontrés

Tout d’abord, OMNet ++ est un nouveau logiciel pour nous. Il
possède une interface différente par rapport aux logiciels connus tout
au long de notre cursus. Mais aussi le mode de fonctionnement et
l'utilité des différents fichiers qui le composent. Il nous a fallu une
certaine période pour se familiariser avec ce nouvel environnement.

Le langage dans lequel sont codés les fichiers de l’exemple sur

lequel nous nous sommes basés est le C++. Ce langage est difficile à
maîtriser et engendre beaucoup de difficultés (rigueur nécessaire,
pointeurs, etc…), alors que nous sommes davantage habitués à
travailler en JAVA par exemple. Cela a compliqué la tâche lors de
l’implémentation des différentes composantes.

L’algorithme BIP s’est révélé difficile à implémenter. En effet, BIP

étant un algorithme plutôt conséquent, nous nous sommes confrontés
à un grand nombre de difficultés et d’erreurs, ce qui nous a fait perdre
beaucoup de temps.

Les différentes difficultés et contretemps que nous avons

rencontrés, nous ont fait perdre du temps et fait prendre du retard sur
nos prévisions. L’implémentation de l’algorithme Dijkstra n’a finalement
pas pu être effectuée.

19/20
 Nous sommes conscients qu’il était important dans notre projet mais
les autres problématiques (déplacement des véhicules, zones de
couverture des véhicules, etc…) représentant également une grande
charge de travail, nous n’avions plus le temps nécessaire pour
implémenter Dijkstra.

5. Annexe

Annexe 1: Calculs des points

20/20