Vous êtes sur la page 1sur 187

Université de REIMS CHAMPAGNE-ARDENNE

Ecole Doctorale Sciences, Technologies, Santé (ED STS)

THÈSE
Pour obtenir le grade de
Docteur de l’Université de Reims Champagne-Ardenne
Discipline :
Génie Informatique, Automatique et Traitement du Signal

Par :
Marwane Ayaida

Contributions aux Communications Intra-Véhicule


et Inter-Véhicules

Soutenue le, 10 Décembre 2012

Jury :

Rapporteurs : Véronique Vèque Professeur à l’Université Paris -Sud


François Spies Professeur à l’Université de Franche-Comté
Sidi Mohammed Senouci Professeur à l’Université de Bourgogne
Examinateurs : Olivier H. Roux Professeur à l’École Centrale de Nantes
André-Luc Beylot Professeur à l’ENSEEIHT
Abdallah Shami Professeur à University of Western Ontario, Ontario, Canada
Directeur de Thèse : Lissan-eddine Afilal Professeur à l’Université de Reims Champagne-Ardenne
Co-Directeur de Thèse : Hacène Fouchal Professeur à l’Université de Reims Champagne-Ardenne
Invité Jean-Marc Blosseville Chercheur à l’IFSTTAR

N° attribué par la bibliothèque


| | |R|E|I| | | | | |
©
À mes Parents et mon Épouse,
sans lesquels rien n'aurait été possible.

Cette thèse est aussi dédicacé à toute ma


famille qui ont toujours été là pour moi.

To my Parents and my Wife, without


whom nothing would have been possible.

This thesis is also dedicated to all my


family who have always been there with me.
Résumé

Les véhicules modernes sont équipés de périphériques permettant d'automatiser des


tâches (changement de vitesse de transmission, régulation de vitesse, etc.) ou de
fournir des services à l'utilisateur (aide à la conduite, détection d'obstacles, etc.).
Les communications entre les véhicules permettent d'élargir ces services grâce à
la collaboration de plusieurs véhicules (prévention des accidents, gestion du trac
routier, etc.). La multiplication de ces périphériques, de leurs interfaces et protocoles
rend l'échange de données plus complexe. Par ailleurs, la communication inter-
véhicules est plus contraignante à cause de la haute mobilité des véhicules.
Dans cette thèse, nous proposons la conception d'un canal de communication
Connect to All (C2A) qui permet d'assurer l'interopérabilité entre les périphéri-
ques embarqués dans un véhicule. En eet, il détecte la connexion à chaud d'un
équipement, le reconnaît et lui permet d'échanger des données avec les autres pé-
riphériques connectés. La conception du canal commence par la modélisation de ce
canal en utilisant deux techniques diérentes (l'outil de modélisation et de vérica-
tion UPPAAL et le Langage de Description et de Spécication (LDS)). La vérica-
tion des modèles proposés a pour but de valider le fonctionnement. Ensuite, nous
détaillons une implémentation réelle du canal sur une carte embarquée qui vise à
démontrer la faisabilité du concept d'interopérabilité de C2A.
Nous avons aussi étudié les eets de la mobilité dans la communication inter-
véhiculaires grâce à une approche hybride mixant le routage et un service de lo-
calisation. Cette approche ore un mécanisme qui permet de réduire les coûts de
la localisation des véhicules tout en augmentant les performances de routage. En
plus, nous comparons deux applications de cette approche : Hybrid Routing and
Grid Location Service (HRGLS) et Hybrid Routing and Hierarchical Location Service
(HRHLS) avec des approches originelles pour démontrer la valeur ajoutée. Cette ap-
proche est enrichie avec un algorithme de prédiction de mobilité. Ce dernier permet
de mieux cerner le déplacement des véhicules en les estimant. De même, l'approche
hybride avec prédiction de mobilité Predictive Hybrid Routing and Hierarchical Lo-
cation Service (PHRHLS) est comparée à HRHLS et l'approche orginelle an de
révéler les bénéces de la prédiction de mobilité.
Mots-clés  Communication; Modèles Formels; Protocoles de Routage; Réseaux
sans Fil; Services de Localisation; Simulation; Standards; Systèmes de Transport
Intelligents; Systèmes Embarqués; VANETs; Vérication.
Abstract

Modern vehicles are equipped with various devices that aim to automate tasks (shift
transmission, cruise control, etc.) or to provide services to the user (driver assistance,
obstacle detection, etc.). Communications between vehicles help to expand these
services through the collaboration of several vehicles (accident prevention, trac
management, etc.). The proliferation of these devices, their interfaces and protocols
makes the data exchange more complex. In addition, inter-vehicle communication
is more restrictive because of the vehicles'high mobility.
In this work, we propose the design of a communication channel Connect to
All (C2A) that ensures the interoperability between embedded devices in a vehicle.
In fact, it detects the equipment connection, recognizes it and allows it to exchange
data with other devices. The channel design starts by the modelling step using
two dierent techniques (the model checker tool UPPAAL and the Specication and
Description Language (SDL). Then, we validate the designed models. We also detail
a concrete implementation of the channel on an embedded chip that aims to show
the C2A interoperability concept feasibility.
We also studied the mobility eects in the inter-vehicular communication through
a hybrid approach mixing routing and location-based service. This approach pro-
vides a mechanism to reduce vehicle-tracking costs while increasing routing perfor-
mances. Moreover, we compare two applications of this approach: Hybrid Routing
and Grid Location Service (HRGLS) and Hybrid Routing and Hierarchical Location
Service (HRHLS) with classical approaches to prove the added value. Then, this
approach is improved with a mobility prediction algorithm. The latter allows a
better understanding of the vehicle movements by estimating them. Similarly, the
hybrid approach with mobility prediction Predictive Hybrid Routing and Hierarchi-
cal Location Service (PHRHLS) is compared with the basic approach and HRHLS
in order to show the mobility prediction advantages.
Keywords  Communication; Embedded Systems; Formal Models; Intelligent
Transportation Systems; Location-based Services; Model Verication; Routing Pro-
tocols; Simulation; Standards; VANETs; Wireless Networks.
Acknowledgements

I would like to express my sincere gratitude to my advisor Professor Lissan-eddine


Alal who gave me the opportunity to work on this motivating topic. I would also
like to thank him for his constant support during my Doctoral Thesis.
I am also thankful to my co-advisor Professor Hacène Fouchal for his constant
availability and help when I was at lost. I would like to express to him my deep
gratitude for his enlightening advices.
I am grateful to Prof. Véronique Vèque, Prof. François Spies and Prof. Sidi
Mohammed Senouci for having agreed to review my thesis. I would like also to
express my deep gratitude to the members of my Doctoral Jury, Prof. Olivier H.
Roux, Prof. André-Luc Beylot, Dr. Abdallah Shami and Mr. Jean-Marc Blosseville,
for having agreed to evaluate my work.
I would also like to thank Dr. Yacine Ghamri-Doudane, for our fruitful collaboration
on Vehicular Ad-hoc Networks.
Many thanks to my colleagues Haytem El Mehraz, for his help when working on
the interoperability modelling, and Mohtadi Barhoumi, for his support in the NS-2
simulation developments and suggestions on this manuscript.
Also, many thanks to all colleagues, sta members, among them Prof. Janan Zay-
toon, Prof. Noureddine Manamanni, Prof. Bernard Riera, Dr. Nadhir Messai, Dr.
Said Moughamir, Fabien Bradmetz, Kheira Slah-Ould Omar, Ida Lenclume, Sylvie
Kokil, Bruno Grouiez, Romuald Ledru, and many others at the CReSTIC Lab for
the nice time I had during the last three years.
My special gratitude goes to my beloved mother Rachida, my father Hedi, my dear
and sweet wife Wafa, my brother and my sisters for their constant love, support and
encouragement.
Lastly, I oer my regards to all of those who supported me during all my study.
Please, enjoy your reading !

Marwane Ayaida
Contents

Résumé v

Abstract vii

Acknowledgements ix

Contents xiv

List of Tables xiv

List of Figures xv
1 IntroductionVersion Française 1
1.1 Motivations et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 IntroductionEnglish Version 7
2.1 Motivations and objectives . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

I Intra-Vehicular Communication 11
3 Interoperability Issues 15
3.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Standards and Interoperability Weakness . . . . . . . . . . . . . . . . 18
4 C2A : Connect to All System 21
4.1 The C2A Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 UPPAAL Tool Model Verication . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Introduction to UPPAAL . . . . . . . . . . . . . . . . . . . . 26
4.2.2 The UPPAAL Verication . . . . . . . . . . . . . . . . . . . . 28
xii Contents

4.3 SDL Model Verication . . . . . . . . . . . . . . . . . . . . . . . . . 35


4.3.1 Introduction to SDL . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 The SDL Verication . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 UPPAAL and SDL Model Verication Comparison . . . . . . . . . . 39
4.5 Application for Embedded Devices in Vehicles . . . . . . . . . . . . . 39
5 Conclusion of Part I 45

6 Résumé Partie I : Communication Intra-Véhicule 47


6.1 Généralités sur l'interopérabilité . . . . . . . . . . . . . . . . . . . . . 48
6.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1.2 Dénitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 C2A : Le Canal Intelligent pour l'Interopérabilité . . . . . . . . . . . 50
6.2.1 Modélisation du Canal C2A . . . . . . . . . . . . . . . . . . . 53
6.2.2 L'implémentation du Système C2A . . . . . . . . . . . . . . . 57

II Inter-Vehicular Communication (V2V) 61


7 VANETs Overview 65
7.1 Related Works on Routing Protocols . . . . . . . . . . . . . . . . . . 66
7.1.1 Topology-based Routing Protocols . . . . . . . . . . . . . . . 66
7.1.2 Geographic Routing Protocols . . . . . . . . . . . . . . . . . . 67
7.2 Location-based Services . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Mobility Prediction in VANETs Routing Protocols . . . . . . . . . . 72
8 Location-based Services Comparison 75
8.1 Scalability Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.1.1 Scalability Denition and Framework Presentation . . . . . . 75
8.1.2 Evaluation of Location Metrics for HLS . . . . . . . . . . . . 77
8.2 Experimental Comparison . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2.1 Working Environment for Experimentations . . . . . . . . . . 81
8.2.2 Experimentation Results . . . . . . . . . . . . . . . . . . . . . 81
9 Joint Routing and Location-based Service in VANETs: New Ap-
proaches 87
9.1 Working Environment for Experimentations . . . . . . . . . . . . . . 88
9.2 Simple Hybrid Approach . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.2.1 Scalability Study for the Hybrid Approach . . . . . . . . . . . 92
9.2.2 Location Information Freshness Impact . . . . . . . . . . . . 94
9.2.3 Hybrid Routing and Hierarchical Location Service (HRHLS) . 96
9.2.4 Hybrid Routing and Grid Location Service (HRGLS) . . . . . 100
9.3 Hybrid Approach with Mobility Prediction . . . . . . . . . . . . . . . 105
9.3.1 PHRHLS Approach Description . . . . . . . . . . . . . . . . . 106
9.3.2 HLS, HRHLS and PHRHLS Experimental Comparison . . . . 107
Contents xiii

10 Conclusion of Part II 111

11 Résumé Partie II : Communication Inter-Véhicules 113


11.1 Comparaison des Services de Localisation . . . . . . . . . . . . . . . 118
11.1.1 Etude de Mise à l'échelle . . . . . . . . . . . . . . . . . . . . . 118
11.1.2 Comparaison Expérimentale . . . . . . . . . . . . . . . . . . . 119
11.2 Routage et Localisation Conjoints dans les Réseaux VANETs : Nou-
velles Approches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.2.1 L'Approche Hybride Simple . . . . . . . . . . . . . . . . . . . 121
11.2.2 L'Approche Hybride avec Prédiction de Mobilité . . . . . . . 124
12 Conclusion and Future Work 129
12.1 Outlook of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13 Conclusion et Travaux Futures 133
13.1 Travaux de Thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.2 Travaux Futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
A C2A Project Outline 139
A.1 C2A Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A.1.1 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A.1.2 Project Results . . . . . . . . . . . . . . . . . . . . . . . . . . 140
A.1.3 Added Value of C2A . . . . . . . . . . . . . . . . . . . . . . . 140
A.2 Project Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
A.3 Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
B NS-2 Simulations Procedure Descriptions 143
B.1 Hardware Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 143
B.1.1 Hardware Developing Environment . . . . . . . . . . . . . . . 143
B.1.2 Hardware Execution Environment . . . . . . . . . . . . . . . 143
B.2 Software Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 144
B.2.1 Generation of Vehicles Movement . . . . . . . . . . . . . . . . 144
B.2.2 Generation of Network Trac . . . . . . . . . . . . . . . . . . 147
B.2.3 NS-2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 149
B.2.4 Traces Evaluations . . . . . . . . . . . . . . . . . . . . . . . . 150
B.2.5 NS-2 Execution in the ROMEO Supercomputer . . . . . . . . 151

List of Abbreviations 156


Index 157
xiv Contents

List of Publications 159


Bibliography 161

Biography 169
List of Tables

4.1 UPPAAL Properties Verication . . . . . . . . . . . . . . . . . . . . 34


4.2 Comparison of UPPAAL and SDL Modelling Techniques . . . . . . . 40
6.1 Comparaison des méthodes UPPAAL et LDS . . . . . . . . . . . . . 58
7.1 Routing Protocols Summary . . . . . . . . . . . . . . . . . . . . . . . 68
8.1 Scalability Parameters Notications . . . . . . . . . . . . . . . . . . . 76
8.2 Numerical Parameters Values . . . . . . . . . . . . . . . . . . . . . . 80
8.3 NS-2 Scalability Simulation Parameters . . . . . . . . . . . . . . . . 82
9.1 NS-2 Hybrid approach Simulation Parameters . . . . . . . . . . . . . 89
9.2 Scalability Study Summary . . . . . . . . . . . . . . . . . . . . . . . 94
11.1 Résumé des Protocoles de Routage . . . . . . . . . . . . . . . . . . . 116
11.2 Résumé de l'Etude de Scalabilité . . . . . . . . . . . . . . . . . . . . 122
A.1 C2A Factsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.1 Hardware Developing Environment . . . . . . . . . . . . . . . . . . . 144
B.2 Hardware Execution Environment . . . . . . . . . . . . . . . . . . . . 145
List of Figures

3.1 C2A Channel Representation . . . . . . . . . . . . . . . . . . . . . . 16


3.2 Interoperability Levels . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 C2A Interoperability Architecture . . . . . . . . . . . . . . . . . . . . 22
4.2 C2A Interoperability Model . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 UPPAAL on Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Queries in UPPAAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Automaton modelling Device IN . . . . . . . . . . . . . . . . . . . . 29
4.6 Automaton modelling Device OUT . . . . . . . . . . . . . . . . . . . 30
4.7 Automaton modelling Device INOUT . . . . . . . . . . . . . . . . . . 30
4.8 Automaton modelling process Initialization . . . . . . . . . . . . . . 31
4.9 Automaton modelling process Identication . . . . . . . . . . . . . . 31
4.10 Automaton modelling process Update PeriphTable . . . . . . . . . . 32
4.11 Automaton modelling process Update Signals . . . . . . . . . . . . . 32
4.12 Automaton modelling process Data Loader . . . . . . . . . . . . . . 33
4.13 Automaton modelling process Data Management . . . . . . . . . . . 33
4.14 Example of SDL system . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.15 Example of SDL actions and states . . . . . . . . . . . . . . . . . . . 36
4.16 Cinderella SDL Tool on screen . . . . . . . . . . . . . . . . . . . . . 36
4.17 C2A SDL model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.18 C2A SDL model zoom . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.19 C2A SDL Identication process model . . . . . . . . . . . . . . . . . 38
4.20 MSC Example in SDL . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.21 C2A Embedded Application . . . . . . . . . . . . . . . . . . . . . . . 41
4.22 C2A Conguration Interface . . . . . . . . . . . . . . . . . . . . . . . 42
6.1 Schéma du tunnel C2A . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Niveaux d'interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3 Modélisation du tunnel C2A . . . . . . . . . . . . . . . . . . . . . . . 52
6.4 Machine d'états d'un périphérique de communication . . . . . . . . . 53
6.5 Machine d'états du processus Identication . . . . . . . . . . . . . . 54
6.6 Modélisation LDS du processus Identication . . . . . . . . . . . . . 56
6.7 Exemple d'un MSC dans LDS . . . . . . . . . . . . . . . . . . . . . . 57
6.8 Fonctionnement du démonstrateur C2A . . . . . . . . . . . . . . . . 59
6.9 IEEE 802.11 WLAN market size . . . . . . . . . . . . . . . . . . . . 63
6.10 VANETs Classication . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1 Routing Protocols Taxonomy . . . . . . . . . . . . . . . . . . . . . . 66
7.2 DSR Discovery Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3 Location-based Services Taxonomy . . . . . . . . . . . . . . . . . . . 69
xviii List of Figures

7.4 Hierarchical Network Partition . . . . . . . . . . . . . . . . . . . . . 71


8.1 Simulation Road Topology . . . . . . . . . . . . . . . . . . . . . . . . 81
8.2 Query Success Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.3 Location-based Service Overhead . . . . . . . . . . . . . . . . . . . . 83
8.4 Request Travel Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.5 Query Success Ratio GLS Vs. HLS . . . . . . . . . . . . . . . . . . . 85
9.1 Example of HLS and GPSR Combination . . . . . . . . . . . . . . . 90
9.2 Location Information Freshness Impact on Requests . . . . . . . . . 94
9.3 Location Information Freshness Impact on Overhead . . . . . . . . . 95
9.4 Location Information Freshness Impact on PDR . . . . . . . . . . . . 95
9.5 Location Information Freshness Impact on Latency . . . . . . . . . . 96
9.6 HLS Vs. HRHLS Requests . . . . . . . . . . . . . . . . . . . . . . . . 97
9.7 HLS Vs. HRHLS Bandwidth Consumption . . . . . . . . . . . . . . . 98
9.8 HLS Vs. HRHLS Routing Performances . . . . . . . . . . . . . . . . 99
9.9 GLS/HLS Vs. HRGLS/HRHLS Location Cache Statistics . . . . . . 101
9.10 GLS/HLS Vs. HRGLS/HRHLS Location Packets Statistics . . . . . 102
9.11 GLS/HLS Vs. HRGLS/HRHLS Location Overhead . . . . . . . . . . 103
9.12 GLS/HLS Vs. HRGLS/HRHLS Location Eciency . . . . . . . . . . 104
9.13 GLS/HLS Vs. HRGLS/HRHLS Routing Eciency . . . . . . . . . . 105
9.14 Example of HLS and GPSR Combination with Mobility Prediction . 106
9.15 HLS Vs. HRHLS/PHRHLS Requests . . . . . . . . . . . . . . . . . . 108
9.16 HLS Vs. HRHLS/PHRHLS Bandwidth Consumption . . . . . . . . . 108
9.17 HLS Vs. HRHLS/PHRHLS PDR . . . . . . . . . . . . . . . . . . . . 109
9.18 HLS Vs. HRHLS/PHRHLS Latency . . . . . . . . . . . . . . . . . . 109
11.1 Phase de Découverte dans DSR . . . . . . . . . . . . . . . . . . . . . 115
11.2 Partition Hiérarchique du Réseau . . . . . . . . . . . . . . . . . . . . 117
11.3 Evaluation des Services de Localisation . . . . . . . . . . . . . . . . . 120
11.4 Statistiques de la Localisation pour GLS/HLS et HRGLS/HRHLS :
Bande passante MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.5 Statistiques de la Localisation pour GLS/HLS et HRGLS/HRHLS :
Taux de Requêtes Répondues (TRR) . . . . . . . . . . . . . . . . . . 124
11.6 Statistiques du Routage pour GLS/HLS et HRGLS/HRHLS . . . . . 125
11.7 Statistiques du Routage pour HLS et HRHLS/PHRHLS . . . . . . . 126
B.1 C4R: Citymob for Roadmaps Tool . . . . . . . . . . . . . . . . . . . 146
B.2 SUMO: Simulation of Urban MObility Tool . . . . . . . . . . . . . . 146
B.3 NAM: Network ANimator Tool . . . . . . . . . . . . . . . . . . . . . 151
Chapter 1

IntroductionVersion Française

Contents
1.1 Motivations et objectifs . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Depuis l'âge des temps, communiquer et se faire comprendre était une tâche très
importante pour l'homme. Ce dernier a mis en place des moyens plus ou moins
avancés an de transmettre la parole et surtout les informations d'un endroit à un
autre. Ces moyens allaient des plus primitifs comme la parole ou le langage des signes
pour les courtes distances, aux tambours ou signaux de fumée pour les moyennes
distances et aux pigeons voyageurs ou courriers postaux pour les longues distances.
Depuis, les premières Technologies de l'Information et de la Communication (TIC),
telles que le Télégraphe (1794) ou le Téléphone (1876), ont fait leur apparition. Ces
technologies ont permis d'accélérer le transfert de l'information et elles ont été un
élément crucial dans l'avancée technologique qui a suivie. Ensuite, ces technolo-
gies ont vu l'émérgence de nouveaux types de communications tels que l'Internet
(1965) et les Réseaux sans Fils (la Téléphonie Mobile 1976). Ces derniers ont per-
mis l'automatisation de l'échange et le transfert en temps réel vers des destinations
lointaines. Toutes ces avancées ont permis de faire rentrer les TIC dans nos vies de
tout les jours. Elles ont inuencé nos habitudes dans les sociétés modernes, jusqu'à
modier notre façon de nous déplacer. En eet, les Systèmes de Transport Intel-
ligents (STI) désignent les applications des nouvelles technologies de l'information
et de la communication au domaine des transports. Ces systèmes visent à faire du
véhicule de transport un moyen de transport sûr, confortable et plus respectueux
pour l'environnement. Leurs applications sont diverses : le télépéage, la gestion du
trac routier, l'aide à la conduite, la gestion des ottes, etc.

1.1 Motivations et objectifs


Le véhicule dans les STI est considéré comme un ensemble d'éléments intercon-
nectés. Ces éléments peuvent être des capteurs embarqués pour la mesure de la
température, la vitesse, la distance entre les véhicules, etc. Ils peuvent être aussi,
des microcontrôleurs ou même des microprocesseurs capables de traiter les informa-
tions issues des capteurs et ainsi permettre au véhicule de réagir aux évènements
2 Chapter 1. IntroductionVersion Française

inattendus. Il existe aussi des systèmes de géolocalisation pour l'aide à la naviga-


tion ou le suivi de ottes. Tous ces équipements sont embarqués dans un véhicule et
doivent communiquer et échanger des données an de garantir la sécurité des pas-
sagers ainsi que l'ecacité et la uidité du trac routier. De plus, on se dirige vers
un nouveau concept coopératif global dans les STI avec les Véhicules Connectés, où
les véhicules ne sont plus envisagés comme simples consommateurs des télécommu-
nications mais aussi comme participants autant que des noeuds mobiles du réseau.
En eet, les véhicules du future seraient équipés de modules de communications sans
l (3G, LTE, 802.11p, etc.) an d'intéragir avec l'infrastructure routière (feux de
circulation, panneaux électroniques de signalisation, bornes de bord de routes, etc.)
ou d'être reliés entre eux. Ce concept permet d'accroître la sécurité en réduisant le
nombre d'accidents à travers une gestion coopérative de la mobilité. L'intéraction
Véhicule-Infrastructure permet aussi une adaptation en temps réel du trac routier
en fonction du débit de circulation des voitures an de réduire la congestion du trac
dans les villes aux heures de surcharge. Ce qui ferait gagner du temps de parcours
et donc des économies de carburant et surtout d'émission de gaz à eet de serre.
De plus, le voyage serait plus agréable car le passager serait capable de rester en
contact avec l'extérieur et de se connecter à Internet dans son véhicule.
Ce travail de thèse vise à faciliter et organiser la communication au sein du
véhicule entre les diérents équipements embarqués. En outre, il a pour but de
maîtriser les eets de la mobilité sur la communication entre les véhicules.

1.2 Challenges
Les périphériques embarqués dans le véhicule remplissent diverses fonctions telles
que le suivi de l'état du véhicule, sa position, l'état du conducteur, l'état des
marchandises, etc. Tous ces équipements communiquent et échangent ces infor-
mations via divers médias et protocoles comme le Controller Area Network (CAN)
/ Fleet Management System (FMS), Universal Serial Bus (USB), 3G, etc. Ces pro-
tocoles ne sont pas toujours compatibles et on a besoin souvent de développer des
ponts (transceivers) entre protocoles an que ces périphériques puissent communi-
quer et échanger des informations. Cette communication même si elle n'est pas
obligatoire favoriserait la création de nouveaux services à l'utilisateur (chaueur,
gérant de parc de véhicules, mécanicien réparateur automobiles, policier, douanier,
etc.). Elle permettrait aussi une rationalisation des ressources matérielles et logi-
cielles grâce à la réutilisation de l'éxistant.
En ce qui concerne les Communications Inter-Véhiculaires, ceux-ci ont connu
un réel essor ces dix dernières années auprès des scientiques, des gouvernements
et des indistruels de l'automobile. Cet engouement a donné un nombre incalculabe
de travaux de recherches dans ce domaine [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]. Le
plus grand challenge de ces réseaux est la haute mobilité des n÷uds, en particulier
dans les Communications Véhicule à Véhicule (V2V). En eet, chaque n÷ud cor-
respond à un véhicule en mouvement. Ce mouvement peut se faire à très haute
1.3. Contributions 3

vitesse avec des changements de directions imprévisibles. Par conséquent, des liens
entre véhicules peuvent se former et être rompus rapidement. Ceci engendre des
changements de topologie constants et incessants. Devant ces caractéristiques très
spéciques, les protocoles de routage distribués classiques comme les Protocoles de
Routage Topologiques ont très vite montré leurs limites. Puisqu'ils sont basés sur la
topologie du réseau, celle ci doit être construite en continu au grès des déplacements
des véhicules. Ainsi, les Protocoles de Routage Géographiques ont été préférés car ils
s'adaptent mieux aux réseaux à larges échelles dynamiques. Le routage des données
est basé sur la position géographique du n÷ud destination dans le réseau. Ainsi,
le paquet de donnée est transmis de proche en proche jusqu'à atteindre la position
de la destination, cette approche est appelée l'Approche Gloutonne. Le principal in-
convénient de ces protocoles est qu'ils ont besoin d'avoir à disposition la localisation
exacte d'un autre n÷ud à tout moment. Ces positions sont indiquées et maintenues
par les Services de Localisation. Ces services sont responsables de la sauvegarde
des positions des autres n÷uds et surtout permettent de savoir où se trouve un
n÷ud particulier s'il y a besoin de lui envoyer des paquets de données. Malgré
que les Protocoles de Routage Géographiques avec les Services de Localisation soient
plus ecaces que les Protocoles de Routage Topologiques, ils restent néanmoins très
sensibles à la mobilité et leurs performances sont aectées par cette dernière.

1.3 Contributions
Notre principale contribution dans la Communication Intra-Véhiculaire est d'avoir
proposer un canal intelligent pour la communication et l'intéropérabilité. Ce canal,
nommé Connect to All (C2A), permet de détecter les périphériques dès leurs
connexions. Une fois la connexion détectée, C2A tente de reconnaître le type
d'équipement dont il s'agit. Ensuite, il lui permet de communiquer et d'échanger
des informations en provenance des autres périphériques aux quelles ils n'avaient pas
accès auparavant. Ce mécanisme permet au système C2A de proposer des services
innovants et d'interconnecter des équipements qui n'ont pas été conçus pour intéra-
gir. A la suite de chaque nouvelle connexion, le système s'adapte an de prendre en
charge le périphérique connecté et il propose automatiquement à l'utilisateur des ser-
vices associés. Ces derniers peuvent être paramétré à distance par l'utilisateur avec
une clé USB ou une connexion avec une tablette tactile Bluetooth. Ainsi, l'utilisateur
peut proter au maximum de l'interaction entre les diérents équipements.
Le canal C2A est ensuite modélisé avant d'être devéloppé. Ceci a pour but
de prendre en compte toutes les possibilités et surtout de vérier que le modèle
C2A garantisse l'intéropérabilité de bout-en-bout. Ce modèle a été testé et vérié à
l'aide de deux techniques complémentaires. La première technique consiste à utiliser
l'outil UPPAAL qui est un environnement intégré de modélisation et de vérication
des systèmes temps réel modélisés sous forme machine d'états nis. Il a permis de
vérier la bonne synchronisation entre les diérents processus grâce à la vérication
formelle des propriétés. Plusieurs propriétés critiques ont été vériées et validées.
4 Chapter 1. IntroductionVersion Française

La deuxième technique a eu recours au Langage de Description et de Spécication


(LDS) qui est un langage de description standard. Il permet de vérier le bon
fonctionnement des systèmes. Ces systèmes sont modélisés de manière formelle,
c'est-à-dire de manière complète et non ambiguë. Ces vérications ont permis de
conrmer la validité de notre concept et de lancer l'étape de développement. Un
démostrateur C2A a ainsi vu le jour. Ce démonstrateur prenant en charge un
nombre limité de périphériques (Clé USB, module Global Positioning System (GPS),
module General Packet Radio Service (GPRS), Simulateur de trames CAN / FMS),
a démontré que le concept C2A pouvait assurer une intéropérabilité complète entre
ces périphériques.
Pour la Communication Inter-Véhiculaire, nos contributions sont multiples. Tout
d'abord, on a proposé une classication des principaux Protocoles de Routage Topolo-
giques et Géographiques ainsi que des Services de Localisation. De plus, on a présenté
une comparaison des Services de Localisation. Cette comparaison est basée sur une
étude théorique de la scalabilité (mise à l'échelle) des coûts de la localisation. De
plus, une comparaison expérimentale basée sur les coûts et les performances de la
localisation conrme les résultats de l'étude théorique. Ce résultat est le fait que
les services hiérarchiques sont les plus performants, et plus précisémment le service
Hierarchical Location Service (HLS) est le plus robuste et le plus rapide. Ensuite,
on s'est interéssé à l'eet de la mobilité sur les performances du routage et de la
localisation. En eet, la mobilité aecte particulièrement ces performances, et les
experimentations conduites nous ont conrmées cela. En se basant sur les compara-
isons théorique et expérimentale des Services de Localisation, nous avons proposé
deux approches combinées entre le routage et la localisation qui soient peu sen-
sibles à la mobilité. Ces derniers sont appelées Hybrid Routing and Hierarchical
Location Service (HRHLS) et Hybrid Routing and Grid Location Service (HRGLS).
Ces approches ont démontré que combiner le routage et la localisation ne permet-
tait pas seulement de réduire le coût de la localisation, mais aussi d'améliorer les
performances du routage. Finalement, l'approche Predictive Hybrid Routing and
Hierarchical Location Service (PHRHLS) est présentée. Cette approche ajoute à
la combinaison un mécanisme de prédiction de mobilité. Cette dernière si elle est
prédite, ses eets peuvent être contrôlés et gérés. Ceci a été prouvé grâce à des
comparaisons réalisées à l'aide de simulations.

1.4 Plan de la thèse


La thèse se décompose principalement en deux parties. La première partie se con-
centre sur la Communication Intra-Véhiculaire. Le premier chapitre de cette partie
présente le contexte de notre travail sur l'interopérabilité. De plus, il donne les
diérentes dénitions de l'interopérabilité ainsi que de ses quatre niveaux. Le deux-
ième chapitre décrit le modèle du système C2A. Il détaille aussi les méthodes de
vérication du modèle UPPAAL et LDS et l'implémentation du démonstrateur C2A.
La seconde partie s'intéresse à la Communication Inter-Véhiculaire. Le premier
1.4. Plan de la thèse 5

chapitre présente une vision générale des réseaux véhiculaires. Il propose une classi-
cation des protocoles de routage avec ou sans prédiction de mobilité ainsi que des
services de localisation. Le deuxième chapitre présente une comparaison théorique
et expérimentale des services de localisation. Le dernier chapitre met en évidence
l'approche hybride simple qui combine le routage et la localisation. Il démontre
que cette approche permet de réduire le coût de la localisation tout en améliorant
les performances du routage. Il introduit aussi l'approche hybride avec prédiction
de mobilité. Il révèle enn que cette dernière permet d'améliorer encore plus les
performances du réseau.
Chapter 2

IntroductionEnglish Version

Contents
2.1 Motivations and objectives . . . . . . . . . . . . . . . . . . . . 7
2.2 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

For centuries, establishing communication was a very important task for hu-
man beings. They used more or less advanced communication ways to transmit
information from one place to another, such as speech or signed language for short
distances, drums or smoke signals for medium distances and carrier-pigeons or postal
mails for long distances. Then, rst Information and Communication Technologies
(ICT) such as Telegraph (1794) or Telephone (1876) have been introduced. These
technologies have accelerated the information transfer and they were a crucial el-
ement in the technological progress that followed. Afterwards, ICT have seen the
emergence of new types of communications such as Internet (1965) and Wireless
Networks (Mobile phone 1976). This helped automating the real-time exchange of
data. All these advances have led to changes of our everyday life. They inuenced
our habits in modern societies. They even changed the way we move. Indeed, Intel-
ligent Transport Systems (ITS) denote the use new ICT in the transportation area.
These systems are designed to make vehicles safe, comfortable and environmentally
friendly means of transportation. Their applications are various: electronic toll,
road trac management, driving assistance, eet management, etc.

2.1 Motivations and objectives


In ITS, a vehicle is seen as a set of interconnected elements. These elements may
be, for example, sensors to measure the temperature, the speed, the distance be-
tween vehicles and so on. They could be also microcontrollers or microprocessors
that are able to treat information from sensors and allow the vehicle to react to
unexpected events. Besides, there are tracking devices for the navigation assistance
and the eet monitoring. All these facilities are embedded in a vehicle to communi-
cate and to exchange data in order to ensure passenger safety and trac eciency
and uidity. Nowadays, we are moving towards a new global cooperative concept
in ITS with the Connected Vehicles idea, where vehicles are no longer considered as
8 Chapter 2. IntroductionEnglish Version

simple consumers of telecommunications but also as participants as mobile nodes in


the network. Indeed, future vehicles will be equipped with wireless communications
modules (3G, LTE, 802.11p, etc.) to interact with the road infrastructure (trac
lights, electronic signs, roadside units, etc.) or to be interconnected. This concept
aims to increase safety by reducing the number of accidents through cooperative
mobility management. The interaction Vehicle-Infrastructure also enables real-time
adaptation of road trac based on the trac ow in order to reduce trac conges-
tion in cities at rush hours. This would save travel time and thus fuel consumption
and gas emissions. Moreover, the trip would be more pleasant for the passenger that
would be able to keep in touch with the outside world and to connect to Internet in
his vehicle.
This research study aims to facilitate and to organize communication within
the vehicle between embedded devices. Moreover, it focuses on the mobility eects
control in the communications between vehicles.

2.2 Challenges
Embedded devices in vehicle perform various tasks such as monitoring the vehicle's
status, its location, the driver's status, the carried goods status, etc. All these
devices communicate and share information via various media and protocols such
as Controller Area Network (CAN), Fleet Management System (FMS), Universal
Serial Bus (USB), 3G, etc. These protocols are not always compatible and we
often need to develop bridges (transceivers) between protocols so that devices can
communicate and exchange data. This communication, even if it is not mandatory,
encourages the creation of new services to users (driver, eet manager, car repair
mechanic, police, customs, etc.). It would also allow a rationalization of hardware
and software resources through the reuse of the existing technologies.
Inter-Vehicular Communications have experienced real interests last years among
scientists, governments and automotive manufacturers. This enthusiasm has given
a huge number of research works in this eld [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12].
The greatest challenge of such networks is the high mobility of nodes, especially
in Vehicle-to-Vehicle Communications (V2V). In fact, each node is a moving ve-
hicle. This movement may be at a very high speed with unpredictable direction
changes. Therefore, links between vehicles can be formed and broken quickly, which
generates constant topology changes. Given these very specic features, classic dis-
tributed routing protocols such as Topology-based Routing Protocols have quickly
shown their limits. They are based on the network topology, which must be built
continuously. Thus, Geographic Routing Protocols are more suitable for large-scale
dynamic networks. Data routing is based on the destination node geographical po-
sition in the network. The data packet is transmitted gradually until reaching the
destination position; this approach is called Greedy Forwarding Approach. The
main drawback of these protocols is that a node needs to know the exact location
of another node at any time before routing data. These positions are identied and
2.3. Contributions 9

maintained by the Location-based Service. These services are responsible for storing
the positions of other nodes and especially used to nd out where a specic node,
if it needs to send data packets. Despite that Geographic Routing Protocols with
Location Services are more ecient than Topology-based Routing Protocols, they
are still very sensitive to the mobility and their performances are aected by this
issue.

2.3 Contributions
Our main contribution in Intra-Vehicular Communications is to propose a smart
channel for communication and interoperability. This channel, called Connect to
All (C2A), detects device connections. Once the connection is detected, C2A
attempts to recognize the plugged equipment. Then, it can communicate and ex-
change data from other devices and it access to a lot of vehicle information. This
mechanism allows the C2A system to propose innovative services and to intercon-
nect devices that have not been designed to interact. After each new connection, the
system adapts itself to support the connected device and it automatically suggests
services for users. The user can customize remotely these services via a USB drive
connection or a Bluetooth touchpad. Thus, the user can take full advantage of the
interaction between dierent devices.
The C2A channel is then modelled before being developed. This targets to
consider all possibilities and to verify that the C2A model ensures the end-to-end
interoperability. The model has been tested and veried using two complementary
techniques. The rst technique used the UPPAAL tool, which is an integrated envi-
ronment for modelling and verication of real-time systems, modelled by nite state
machines. It performs the formal properties verication of the synchronization be-
tween processes. Thus, several critical properties have been checked and validated.
The second technique used the Specication and Description Language (SDL), which
is a standard description language that checks the correct functioning of systems.
These systems are modelled in a formal way, i.e. complete and unambiguous. These
verications were able to conrm the validity of our concept and initiate the devel-
opment phase. A concrete C2A channel was developed. This rst attempt supports
a limited number of devices (USB drive, Global Positioning System (GPS) module,
General Packet Radio Service (GPRS) module, CAN / FMS frames simulator). It
has shown that the C2A concept could ensure full interoperability between these
devices.
In Inter-Vehicular Communications, our contributions are numerous. First of
all, we propose a classication of the main Topology-based and Geographic Routing
Protocols and Location-based Services . In addition, we presented a comparison of
well-known Location-based Services. This comparison is based on a theoretical scal-
ability study among localization cost. Besides, an experimental comparison based
on the localization costs and performances conrms the results of this theoretical
study. The results prove that the hierarchical location services are more ecient, and
10 Chapter 2. IntroductionEnglish Version

precisely the Hierarchical Location Service (HLS) is the most robust and the fastest
service between all of compared location-based services. Then, we focused on the
mobility eect on routing and localization performances. We conducted experimen-
tations which have conrmed that the mobility aects the network performances.
Based on the theoretical and experimental comparisons of location-based services,
we proposed two combined approaches between routing and localization that are
less sensitive to mobility. They are called Hybrid Routing and Hierarchical Loca-
tion Service (HRHLS) and Hybrid Routing and Grid Location Service (HRGLS).
These approaches have shown that combining routing and localization do not only
reduce the localization cost, but also improves routing performances. Finally, the
approach Predictive Hybrid Routing and Hierarchical Location Service (PHRHLS)
is presented. This approach adds to the combination a mobility prediction mecha-
nism. If the mobility is predicted, its eects can be controlled and managed. This
issue has been conrmed through experimentations with the Network Simulator 2
(NS-2).

2.4 Thesis Outline


The thesis is split into two main parts. The rst part focuses on Intra-Vehicular
Communications. The rst chapter of this part presents the context of our work
on the interoperability. Besides, it provides dierent denitions to the interoper-
ability and denes its four levels. The second chapter describes the C2A system
models. It also details formal modelling using the tools UPPAAL and SDL and the
implementation of the C2A application.
The second part is interested in Inter-Vehicular Communications. The rst
chapter presents an overview of vehicular networks. It proposes a classication
of routing protocols with and without mobility prediction and for location-based
services. The second chapter presents a theoretical and experimental comparison of
some location-based services. The last chapter highlights the simple hybrid approach
that combines routing and localization. It shows that this approach can reduce
the localization cost and improve routing performances. It nally introduces the
hybrid approach with mobility prediction. It also reveals that this last approach
can improve even more the network performances.
Part I

Intra-Vehicular Communication
13

Nowadays, communication technologies in the transportation area are growing


quickly. Many devices are embedded on vehicles in order to control the engine
(Controller Area Network (CAN), Sensors, etc.), to catch positions (Global Posi-
tioning System (GPS) module, General Packet Radio Service (GPRS) module, etc.)
and to entertain users (Wi-Fi, Video games, etc.). To be more powerful, each de-
vice focuses on its core functionality and handles a part of the vehicle information
(Position, Wheel pressure, Speed, Fuel Level, etc.). Thus, devices require to com-
municate and to exchange data in order to meet user needs which become more
and more strict. This communication is complex due to the divergence between
protocols and interfaces used by peripherals. Consequently, it is hard to satisfy end-
to-end interoperability even when using a standard. Most standards specify only
the way to share data and do not handle neither the semantic nor the processing
issues. Generally, data pass through bridges or ad-hoc transceivers.
In order to reduce the allocated resources (hardware and software), we suggest to
manage this communication into a single smart channel. This channel will be able
to identify a device when connected. In addition, the channel will allow devices to
communicate and exchange information in order to build new and ecient services
for end-users. These services will be launched automatically after the connection of
a new device. Then, the user may customize its services online.
Chapter 3

Interoperability Issues

Contents
3.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Level 1: Machine Level Interoperability . . . . . . . . . . . . 17
Level 2: Syntactic Interoperability . . . . . . . . . . . . . . . 17
Level 3: Semantic Interoperability . . . . . . . . . . . . . . . 17
Level 4: Organizational Interoperability . . . . . . . . . . . . 18
3.3 Standards and Interoperability Weakness . . . . . . . . . . . 18

3.1 Context
The communication technologies in the eld of transportation are in continuous
progress. Several devices are embedded in vehicles for information transmission
(CAN bus, Sensors, etc.), for eet management (GPS module, GPRS module, Global
System for Mobile (GSM) module, etc.) or for safety (voice control of on-board com-
puter, embedded cameras in the cabin, etc.). Many devices need to communicate
and exchange data. This communication becomes very complex because of the dif-
ferences between the protocols and interfaces used. To reduce the waste of resources
(hardware and software) and optimize communication, the Connect to All (C2A)
project (Connect to All: European project, Interreg IV-A, cross-border cooperation
"France-Walloon", www.c2a-project.eu) suggests to manage this communication in
a single smart channel. This channel must be able to recognize a device under con-
nection. It should also allow it to communicate and exchange information based
on a list of services (eet management, information access card driver, etc.). This
project aims to organize communication between embedded devices and to ensure
better ow of information within and outside the transport vehicle. The system
should provide to eet managers how to use relevant information to create new
services. For more details on the C2A Project, please refer to Appendix A.
This system based on the patent [13] led in the C2A project, should allow
the detection and recognition of devices and the exchange between devices, oer
automatically new services to users and make available to third party application
developers the information on the driver status, the vehicle and the goods carried
(Figure 3.1).
3.2. Denitions 17

"Over the years, our industry has tried many approaches to come to grips
with the heterogeneity of software. But the solution that has proven
consistently eective and the one that yields the greatest success for
developers today is a strong commitment to interoperability. That
means letting dierent kinds of applications and systems do what they
do best, while agreeing on a common 'contract' for how disparate systems
can communicate to exchange data with one another."
The Institute of Electrical and Electronics Engineers (IEEE) has four dierent
denitions for this term [14] :
• Denition 1: The ability of two or more systems or elements to exchange
information and to use the information that has been exchanged (software).
• Denition 2: The capability for units of equipment to work together to achieve
useful functions.
• Denition 3: The capability, promoted but not guaranteed by joint confor-
mance with a given set of standards, that enables heterogeneous equipment,
generally built by various vendors, to work together in a network environment.
• Denition 4: The ability of two or more systems or components to exchange
information in a heterogeneous network and use that information.
Interoperability is not only the ability of two heterogeneous systems to exchange
data, but also the understanding of what is being exchanged and the capability of
interaction and joint execution of tasks [15].
We classify interoperability according to [16, 17, 15, 18] into four levels as shown
in Figure 3.2.
Level 1: Machine Level Interoperability
It is the basic and lowest level of interoperability. It includes the denition of
interfaces and protocols like in TCP/IP.
Level 2: Syntactic Interoperability
It denes the format and structure of exchanged data. Software systems imple-
mented using various high-level programming languages must know the parameters
to use and their order. This level, with the previous one, concerns the way of sharing
data.
Level 3: Semantic Interoperability
The semantic level describes the signicance of exchanged data. Heterogeneous
systems must have agreements and rules between each other to guarantee that all
of them have the same meaning of data that have being exchanged.
3.3. Standards and Interoperability Weakness 19

level needs human interpretation of shared data and the forth level needs human
interaction to ensure that data is used according to agreement. Moreover, it is too
dicult to develop a language rich enough to cover a specic domain targeted by
a standard. Standards also neglect some aspects when systems interoperate. As
an example, we can talk about QoS (Quality of Services) which describes features
of running systems (response time, security, performance, availability, etc.). Few
standards require a threshold time response in communication between systems
which may lead to incompatibility and prevent the interoperability.
In addition, standards are specications and requirements. Thus, they are use-
less until the transformation into nal products or services. This transformation may
lead to communication troubles. Standards are useful when they are well adopted.
However, like any other technology, they have a life cycle and will become obsolete,
by evolving to a non backward-compatible version or by using alternative stan-
dards. Some standards become widely used because they were the rst (de facto )
standards and not necessarily the best ones. Unfortunately, organizations cannot
economically explain migrating to better standards and are often blocked into such
standards. There are also non-ecient standards (under-specied, over-specied,
unstable, etc.). The standards may be incompatible sometimes because mutually
exclusive or competing. A well-known example of incompatible and competing stan-
dards is HD-DVD and Blu-Ray.
Moreover, the estimated cost of interoperability mainstreaming when building
systems is 40% higher compared to similar non-interoperable systems [20]. This
extra cost does not promote the interoperability and it inhibits the wish to interface
with other devices on the market. Rather, sub-systems focus on their core business
while ignoring other sub-systems in the surrounding environment.
To solve this issue, Plug and Play (PnP) and more precisely Universal Plug and
Play (UPnP)3 [21] could be used. These specications are used in many areas and
provide useful mechanisms. However, this paradigm is only designed for devices
with predened functionalities (e.g. they must have an IP connection that is not
always the case in embedded devices). For other kind of devices, a new concept
should be dened.
Another solution was to use The Common Object Request Broker Architecture
(CORBA), which is a standard dened by the Object Management Group (OMG)4
[22] that enables software components written in multiple computer languages and
running on multiple computers to work together (i.e., it supports multiple plat-
forms). However, the CORBA specication dened programming interfaces, espe-
cially on the server side, and left completely unspecied what protocol should be
used to communicate between Object Request Broker (ORB) produced by dierent
vendors. Even with the Internet Inter-ORB Protocol (IIOP) and the poa, they are
not able to ensure the twin goals of interoperability and portability of the CORBA
standard. This is due to the fact that every vendor adds extensions to the basic
3
http://www.upnp.org/
4
http://www.omg.org/
20 Chapter 3. Interoperability Issues

CORBA standards, extensions that can cause interoperability problems when IIOP
is used to connect various ORB. Indeed, this standard aims to guarantee only the
software interoperability and leave untreated the hardware part.
In this work, we will focus on ensuring the software and hardware interoperability
between involved devices instead of dening the behavior of each device.
Chapter 4

C2A : Connect to All System

Contents
4.1 The C2A Model . . . . . . . . . . . . . . . . . . . . . . . . . . 23
The Devices Simulators . . . . . . . . . . . . . . . . . . . . . 24
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Identication . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Update Peripherals Table . . . . . . . . . . . . . . . . . . . . 24
Update Available Signals . . . . . . . . . . . . . . . . . . . . 25
Data Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Data Management . . . . . . . . . . . . . . . . . . . . . . . . 25
Conguration of the System . . . . . . . . . . . . . . . . . . . 25
4.2 UPPAAL Tool Model Verication . . . . . . . . . . . . . . . 26
4.2.1 Introduction to UPPAAL . . . . . . . . . . . . . . . . . . . . 26
Denition of Network Timed Automata . . . . . . . . . . . . 26
The Query Language . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 The UPPAAL Verication . . . . . . . . . . . . . . . . . . . . 28
Device IN Model . . . . . . . . . . . . . . . . . . . . . . . . . 29
Device OUT Model . . . . . . . . . . . . . . . . . . . . . . . . 29
Device INOUT Model . . . . . . . . . . . . . . . . . . . . . . 29
Initialization Process Model . . . . . . . . . . . . . . . . . . . 30
Process Identication Model . . . . . . . . . . . . . . . . . . . 31
Process Update PerphTable Model . . . . . . . . . . . . . . . 31
Process Update Signals Model . . . . . . . . . . . . . . . . . 32
Process Data Loader Model . . . . . . . . . . . . . . . . . . . 32
Process Data Management Model . . . . . . . . . . . . . . . . 32
Simulation & Verication . . . . . . . . . . . . . . . . . . . . 33
4.3 SDL Model Verication . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1 Introduction to SDL . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 The SDL Verication . . . . . . . . . . . . . . . . . . . . . . 38
4.4 UPPAAL and SDL Model Verication Comparison . . . . . 39
4.5 Application for Embedded Devices in Vehicles . . . . . . . . 39
24 Chapter 4. C2A : Connect to All System

The Devices Simulators


In the overview that we have done in [23], we notice that there are three kinds of
devices:
• Provider Device: it broadcasts continuously its data to the system (for exam-
ple: GPS receiver).
• Consumer Device: it waits for data from the system since its connection (for
example: USB Flash Memory).
• Communication Device: it is able to send and receive data. It works as a
bridge linking C2A to external facilities (like: Bluetooth interface).
Initialization
The Initialization process is the kernel of the C2A channel. It is responsible of the
detection and the synchronization of the rest of the processes.
It scans continuously the connectors to detect the connection of peripherals. If it
detects a new connection, it sends Device_Detected event to Identication process
and waits for the Composition_Devices event from Update Available Signals process.
When it receives it, the service could be launched (by the event Start_Services ) and
the system has all the information needed about this service (connected peripherals,
used ports, transmission speeds, available signals etc.).
Identication
This process aims to recognize the device after its connection's detection by Initial-
ization process.
After receiving Device_Detected event, Identication process opens the port
recently used with dierent transmission speeds (Baud rates). Then, it tests the
received data. If the data are meaningful, it compares them with data in its database
to deduce the peripheral. Else, the user must inject a new device conguration le
for this unknown device.
Once this step is nished, Identication process sends Device_Connected event
to Update Peripherals Table process.
Update Peripherals Table
Update Peripherals Table process's mission is to maintain the list of connected de-
vices up to date depending on the connection and disconnections. When receiv-
ing Device_Connected event, the device connected/disconnected is added/removed
to/from the Peripherals Table. Afterwards, it sends Request_Conguration event
to Update Available Signals process and waits for its response Cong event.
After the reception of the conguration (list of available and activated signals),
Update Peripherals Table process has all information needed by Initialization pro-
cess. These information are carried to this last by Composition_Devices event.
4.1. The C2A Model 25

Update Available Signals


The Update Available Signals process maintains the list of signals available from
the connected devices and the way to parse packets in order to obtain these useful
signals.
Update Available Signals process receives Request_Conguration event with the
new connected device. It updates the list by adding the signals provided by the
recently connected peripherals. Then, it sends this list in Cong event to Update
Peripherals Table process.

Data Loader
Data Loader process manages dedicated software used to communicate with periph-
erals. When it receives Services_Start event from Initialization process, it activates
software that parse data and store the useful signals in the Signal Table. Data
Management process uses this table after sending Data_Loaded event.

Data Management
The last process is Data Management process. This process uses the signals to build
a service. When the data are ready to be processed, Data Management process
receives Data_Loaded. It runs the default applications or the customized ones by
the user over these signals. We will see later what we mean exactly by customizing.
The result of the processing step is switched out to consumer or communication
devices. Finally, This process sends Services_Stop in order to reset other processes
when the service nishes and to wait for the next service.
Conguration of the System
The conguration is a planned change of the system behavior by the user. This last
could interfere in two cases:
In this case, the system is unable to recognize or to launch

Case1 :
communication with the peripheral. The chosen solution then




is to provide a conguration le well formatted to teach





the system how to recognize and to communicate with the



unknown device.
The other case is the system customization. The user can




 Case2 :
activate or disable services or signals only by modifying




and sending a conguration le of the system.


The conguration is possible only via known, in advance, devices for obvious
safety issues.
To verify the validity of our model,we implement it using two dierent methods
in order to compare the benets of each one. These complimentary methods are
26 Chapter 4. C2A : Connect to All System

detailed in the two next sections.

4.2 UPPAAL Tool Model Verication


Before the smart channel C2A design step, we will start to build a model to C2A.
Then, we will check the validity of the model using the UPPAAL tool box which is
a well-known model checker [24].
4.2.1 Introduction to UPPAAL
UPPAAL is an integrated tool environment for modelling, validation and verication
of real-time systems (real time controllers, communication protocols, multimedia ap-
plications, etc.) modelled as networks of timed automata. It was named UPPAAL
with UPP standing to Uppsala University in Sweden and AAL for Aalborg Uni-
versity in Denmark which develop it. The rst version was proposed in 1995. It
consists of a graphical description tool, a simulator and a model checker (Figure
4.3). It serves as a modelling or a design language to describe a system behav-
ior as networks of automata extended with clocks and data variables. It has been
used for the simulation of the system and checks if there is any error on the sys-
tem. Properties -to be veried- can be specied using a subset of Computation Tree
Logic (CTL) formalism. We used UPPAAL version 4.1.3 freely available from the
website: http://www.uppaal.org/.

Figure 4.3: UPPAAL on screen : The UPPAAL graphical description tool

Denition of Network Timed Automata


A Timed Automaton is a nite-state machine extended with clock variables. Clock
variables evaluate to real numbers and all of them progress synchronously. A sys-
tem is modelled as a parallel composition of timed automata. An automaton may
4.2. UPPAAL Tool Model Verication 27

perform a transition separately or synchronizes with another automaton (channel


synchronization).
More precisely, a Timed Automaton is a tuple (L, l0 , C, A, E, I), where :
• L is a set of locations

• l0 ∈ L is the initial location

• C is the set of clocks

• A is the set of actions (e.g. press!), co-actions (e.g. press?) and internal
τ -actions

• E ∈ L × A × B(C)1 × 2C × L is a set of edges between locations with an action,


a guard and a set of clocks to be reset
• I : L −→ B(C) assigns invariants to locations

A Network of Timed Automata over a common set of clocks and actions consists
of n Timed Automata (Li , li0 , C, A, Ei , li ), with 1 ≤ i ≤ n.
The Query Language
UPPAAL uses a simplied version of CTL as its query language. The query language
consists of state formulae and path formulae. A state formula describes individual
states. It could be written as expressions (x>3, i==2, x<=3, i==5, etc.), location
(porcess.location) or deadlock (there are no enabled transitions). For path formulae
we use four symbols : E (exists a path), A (for all paths), [] (all states in a path)
and <> (some states in a path). The following combinations are supported : A[],
A<>, E<>, E[]. A path formula quanties over paths of the model. Let p and q
two states formulae. The properties that can be veried are (Figure 4.4):
(a) E<> p - "p Reachable" : it is possible to reach a state in which p is satised
(p is true in -at least- one reachable state).
(b) A[] p - "Invariantly p" : p holds invariantly (P is true in all reachable states).
(c) A<> p - "inevitably p" : p will be inevitable become true : the automaton
is guaranteed to eventually reach a state in which p is true (P is true in some
states of all paths).
(d) E[] p - "Potentially Always p" : p is potentially always true (There exists a
path in which p is true in all states).
(e) q 99K p - "q leads p" : q will inevitably leads to p (p is true in -at least- one
reachable state in all paths from q).
1
Boolean guards B(C) are dened as follows : B(C) = true k false k x ./ c k x − y ./ c k
B(C) ∧ B(C ) k B(C) ∨ B(C) k ¬B(C) where : x, y ∈ C , c ∈ N , and ./∈ {<, ≤, =, ≥, >}.
28 Chapter 4. C2A : Connect to All System

Figure 4.4: Queries in UPPAAL

4.2.2 The UPPAAL Verication

In this section, we will present the timed automata network of the model and the
synchronization events between them. The peripheral-devices, when plugged to
C2A, drive dierent types of data (Speed, Driver's State, Fuel Level, Time, Posi-
tion, etc), denoted as Signals. Every Signal has a dened value at any time, xed
by a peripheral or by the system. All signals describe the vehicle status. The
model is described in section 4.1. The groups of peripherals are modelled by three
processes. The C2A channel is divided into six processes (Initialization process,
Identication process, Update PerphTable, Signals Update, Data Loader process,
Data Management process).

C2A Identies the group of devices connected. Then, it catches the signals
provided by the rst and/or the third group. After data processing, it dispatches
them to the second and/or the third groups. The signals conguration is saved on
the system and can be changed by some peripherals known as Conguration devices.
Therefore, the user can customize services by choosing signals and the processing
results outputs. In this study, we choose to model only four signals (Time, latitude,
longitude and number of satellites provided by a GPS receiver) and two services
(data logging in a Hard Disk and sending data via GPRS connection). As a lot of
peripherals in transportation use a serial protocol (USB, RS232, etc.) or may have an
interface with a transceiver, we choose to model the connection of such peripherals.
Thus, every device connects to a serial port of the system and communicates with
a unique Baud Rate.


4.2. UPPAAL Tool Model Verication 33

Figure 4.12: Automaton modelling process Data Loader

To end the service, a broadcast event Services_Stop is sent to reset all processes
and to prepare the next service.

Figure 4.13: Automaton modelling process Data Management

Simulation & Verication


The simulation aims to check whether the system works as expected. We choose to
instantiate an USB Drive as a conguration device, a GPS module as Device IN, a
Hard Disk (HD) as a Device OUT, a GPRS module as a Device INOUT and C2A
processes. The declaration is described as bellow:
// Place template instantiations here.
USB = DeviceIN(1,1,1);
GPS = DeviceIN(0,2,2);
HD = DeviceOUT();
GPRS = DeviceINOUT(3,2);
P_Initialization = Initialization();
P_Identification = Identification();
P_Update_PeriphTable = Update_PeriphTable();
34 Chapter 4. C2A : Connect to All System

N◦ Properties Comments Critical


1 A[] not deadlock System is deadlock free Yes
P_Identication.Scan_Result > The system identies
2 P_Identication.Baudrate_Tested the right Baud Rate Yes
== Baudrate_Dev of the device
P_Identication.Scan_Result > The system identies
3 P_Identication.Port_Tested the right Port Yes
== Port_Dev of the device
A<> ((USB.Send_Conguration and The system takes the
4 P_Signals_Update.Cong_Sent) input conguration and No
imply Conf == Conf_IN) not the stored one
A<> (USB.Send_Conguration The input conguration
5 imply is catched in less No
P_Signals_Update.tempo <= 3) than 3 time units
A<> (P_Initialization.Detection The connected
6 imply device will Yes
P_Identication.Scan_Result) be identied
A<> (GPRS.Send_Data All data sent
7 imply by GPRS module Yes
P_Data_Loader.Data_Acquisition ) will be received
A<> (GPS.Send_Data All data sent
8 imply by GPS module Yes
P_Data_Loader.Data_Acquisition ) will be received

Table 4.1: UPPAAL Properties Verication

P_Signals_Update = Signals_Update();
P_Signals_Default = Signals_Default();
P_Data_Loader = Data_Loader();
P_Data_Management = Data_Management();

// List one or more processes to be composed into a system.


system USB,GPS,HD,GPRS,P_Initialization,P_Identification,
P_Update_PeriphTable,P_Signals_Update,P_Data_Loader,P_Data_Management;

We checked that the system works properly using step by step simulations and
random simulations. We also veried the critical properties of the system. Some of
these properties are described in Table 4.1.
We observe that the simulations and the properties verication conrm the va-
lidity of the proposed model (over 20 millions of transitions tested). UPPAAL allows
us to verify properties but suers from several limits. One limit is that the events
used for nite-state machines synchronization are exclusively binary channels and
can not carry useful data. Another limit is that the proposed model can not be




40 Chapter 4. C2A : Connect to All System

UPPAAL SDL
Properties verication Standardized description
Exhaustive tests Remote call for external functions
Advantages

Detection failures Dening new variable types


Random simulations Verication using MSC
Formal parameters Dynamic instantiation
Simplicity of the tool Automatic generation code
Binary channel synchronization No formal verication
Drawbacks

Complexity increases rapidly Complexity of the tool


Lack of readability Low level description
No code generation Diculties in code reuse
Greedy verication algorithm Generated code debugging
Table 4.2: Comparison of the two modelling techniques

GPRS module and an USB drive as a conguration device. The application is


represented by Figure 4.21.
The software application is based on embedded Linux distribution which is de-
signed and optimized to t embedded constraints such as memory (18 Mo from 128
Mo available on the Flash Memory). The software functionality and the channel
processes are also shown on Figure 4.21. The detection and the recognition of con-
nected devices is managed by the Initialization process and Identication process
depending on the protocol used by the peripheral:
• USB: The Linux kernel was congured to send a socket if it detects a connec-
tion on the USB bus. Then, the process identies the connected device.
• RS232: A thread scans the RS232 bus continuously using all available ports
with dierent Baud rates. If it receives valid data, then a new peripheral is
being connected.
After identifying the device, the Update PeriphTable will update the table of
connected peripherals. Then, the process Signals Update decides which service to
launch and the signals managed depending on connected devices. If there is not a
conguration device listed on the table, the process will give a default conguration.
Else, the system check the security parameters of the USB drive (Serial Number,
Vendor ID, Product ID, Vol ID, etc. which are unique features of this USB drive).
The conguration is stored in an XML (Extensible Markup Language) le in the
USB drive. This le contains information about the user (rst name, last name, date
of birth and phone number), the company (name, class, address and IP address of
the server), the needed services (data logging known as Transfer or Short Message
Service (SMS) notication known as Notication ) and managed signals (speed, posi-
tion, etc.). To make easier the modication of the Extensible Markup Language le
by an end-user, a user-friendly interface was developed shown by Figure 4.22. This
4.5. Application for Embedded Devices in Vehicles 41

Figure 4.21: The hardware and software of the channel C2A application

interface allows the user to input system parameters and generate a well formatted
Extensible Markup Language le which can be used by the system.
A simple example of the Extensible Markup Language le is described below.
This example allows the system conguration for notifying each 60 seconds the
accelerator position to a specied phone number.
<?xml version="1.0" encoding="ISO-8859-1"?>
<Configuration_File>
<Identification>
<User First_Name = "Demo" Last_Name= "C2A"
42 Chapter 4. C2A : Connect to All System

Figure 4.22: The C2A application conguration interface

Date_of_Birth="01/09/2008"
Telephone ="+33699999999">
</User>
<Job Company="CReSTIC" User_Class="1" Adress="FRANCE"
IP_Serveur= "172.20.11.143">
</Job>
</Identification>
<Services>
<transfer TMode="ALL" ID_Device= "993f129-8beb">
</transfer>
<Notification NMode="SELECT" Frequency ="60">
</Notification>
<LoadingData Select="FALSE">
</LoadingData>
<Signals>
<EngSpeed Select="FALSE"> Vitesse du moteur
</EngSpeed>
<AccelPos Select="TRUE"> Position accélérateur
</AccelPos>
</Signals>
</Services>
</Configuration_File>

After the conguration step, Data Loader process loads frames provided by
connected peripherals, it parses them to obtain useful data organized into classes
depending on the chosen conguration. Finally, Data Management process performs
the appropriate processing (conversion, thresholding, etc.) on these data and then
save them into USB drive or sends them via SMS to a mobile phone, if the USB
4.5. Application for Embedded Devices in Vehicles 43

drive or the GPRS module are connected.


This application based on the model proposed and supporting a limited number
of typical devices was presented to industrialists at a seminar organized within the
project committee. It has to prove the feasibility of the C2A concept with a few
devices. It has been proved that these devices can interact and exchange data. Thus,
the system can automatically propose new services to the end-user while leaving the
choice to customize later.
Chapter 5

Conclusion of Part I

The Intra-Vehicular Communication is very hard to fulll today, because there are
a lot of embedded devices in vehicles. The interoperability between these devices is
required to achieve services expected from drivers, such as driving assistance, eet
management, freight monitoring, etc. Therefore, the interoperability here includes
not only the data exchange, but also the understanding of what is being shared and
to act on these data to provide the needed services. The C2A channel presented in
this part aims to ensure the end-to-end interoperability over the four interoperability
levels identied. This channel detects automatically a device's plug and recognize
it directly. Then, it allows it to communicate and to exchange meaningful data.
The C2A channel is designed and modelled. The model is tested and veried using
two techniques. The rst one was carried out using the integrated tool environment
for modelling, validation and verication of real-time systems UPPAAL. Several
critical communication properties have been checked with the formal query language
verication. The second method uses the SDL language. It veries that the system
works as expected. Finally, we proposed a real implementation of the C2A concept
in an embedded platform. This application shows that the interoperability concept
behind C2A can be achieved between some peripherals, that have not been designed
to interoperate. This application is now extended to manage several other embedded
devices.
Chapter 6

Résumé Partie I : Communication


Intra-Véhicule

Contents
6.1 Généralités sur l'interopérabilité . . . . . . . . . . . . . . . . 48
6.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1.2 Dénitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 C2A : Le Canal Intelligent pour l'Interopérabilité . . . . . . 50
6.2.1 Modélisation du Canal C2A . . . . . . . . . . . . . . . . . . . 53
Modélisation UPPAAL . . . . . . . . . . . . . . . . . . . . . . 53
Modélisation LDS . . . . . . . . . . . . . . . . . . . . . . . . 55
Comparaison des Méthodes de Vérication UPPAAL et LDS 56
6.2.2 L'implémentation du Système C2A . . . . . . . . . . . . . . . 57

Le secteur du transport et de la logistique a connu un développement important


avec les nouvelles technologies de l'information et de la communication durant les
dernières années. Ainsi, au sein de l'habitacle d'un véhicule de transport routier,
les équipements embarqués sont de plus en plus nombreux et variés. En plus des
périphériques imposés par la loi comme le tachygraphe numérique, nous trouvons
des systèmes de communication radio, de localisation, et une variété d'outils et
d'équipements utilisés par les opérateurs qui interviennent sur ces véhicules. Ces
outils et accessoires permettent d'automatiser des processus, d'améliorer la sécurité
et d'accélérer la circulation de l'information. Cependant, cette multiplicité est loin
d'être exploitée de manière optimale : les équipements ne communiquent souvent
qu'avec un alter ego via des interfaces matérielles et logicielles dédiées. Cela a pour
conséquence une redondance de fonctionnalités, de services, et une sous utilisation
des ressources matérielles et logicielles déployées.
Pour une communication performante et sûre, ces systèmes doivent être compati-
bles pour satisfaire une interopérabilité signicative de bout-en-bout. En échangeant
des données, ils doivent aussi les interpréter et les traiter d'une façon transparente
et commune. S'il existe aujourd'hui des standards, ils restent insusants [19].
Pour répondre à cette problématique, la solution envisagée dans le cadre du pro-
jet C2A est de centraliser cette communication dans un canal intelligent et évolutif,
capable de reconnaître les périphériques connectés ou déconnectés en cours de fonc-
tionnement et de s'adapter pour orir automatiquement des services à l'utilisateur.
48 Chapter 6. Résumé Partie I : Communication Intra-Véhicule

Il s'agit de tirer prot de la communication entre les périphériques et des interactions


mutuelles pour optimiser les services existants et en orir d'autres.

6.1 Généralités sur l'interopérabilité


6.1.1 Contexte
Les technologies de la communication dans le domaine du transport sont en progrès
continu. Plusieurs appareils sont embarqués dans le véhicule pour la transmission
des informations (Bus CAN, capteurs, etc.), la gestion de otte (module GPS, mod-
ule GPRS, module GSM, etc.), ou la sécurité (commande vocale de l'ordinateur de
bord, caméras embarqués dans la cabine, etc.). Ces diérents périphériques ont be-
soin de communiquer et d'échanger des données. Cette communication est de plus
en plus complexe à cause de la diérence entre les protocoles et des interfaces util-
isés. Pour réduire le gaspillage des ressources (matérielles et logicielles) et optimiser
la communication, le projet C2A (Connect to All : projet européen Interreg IV-A
de coopération transfrontalière "France- Wallonie" : www.c2a-project.eu) propose
de centraliser la communication dans un seul et unique canal intelligent. Ce canal
doit être capable de reconnaitre un appareil dès sa connexion, et surtout, de lui per-
mettre de communiquer et d'échanger des informations en se basant sur une liste de
services (gestion de ottes, accès aux informations de la carte conducteur, etc.). Ce
projet a pour but d'optimiser la communication entre les périphériques embarqués
et d'assurer une meilleure circulation de l'information à l'intérieur et à l'extérieur
du véhicule du transport. Le système devrait fournir aux gestionnaires de ottes les
moyens d'utiliser une information pertinente pour créer de nouveaux services.
Ce système basé sur un brevet [13] déposé dans le cadre du projet C2A, doit
donc permettre la détection et la reconnaissance des périphériques ainsi que les
échanges entre les appareils, an de proposer automatiquement de nouveaux ser-
vices à l'utilisateur et mettre à disposition des développeurs d'applications tiers les
informations sur l'état du conducteur, du véhicule et des marchandises (Figure 6.1).

6.1.2 Dénitions
Pour permettre aux périphériques hétérogènes embarqués dans un véhicule de trans-
port d'échanger des données, il faut assurer la compatibilité matérielle et logicielle
entre les diérents systèmes. Pour éviter qu'un acteur devienne dominant ou impose
un standard particulier, il est nécessaire de mettre en place un standard ouvert pour
permettre aux diérents systèmes d'être interopérables sans dépendre d'un acteur
particulier. Le concept de l'interopérabilité peut prendre diérentes interpréta-
tions en fonction du domaine et du contexte. La IEEE propose quatre dénitions
diérentes relatives à ce terme [14] :
• Dénition 1 : La capacité de deux ou plusieurs systèmes ou éléments d'échanger
des informations et à utiliser ce qui a été échangé.


6.2. C2A : Le Canal Intelligent pour l'Interopérabilité 51

Ces périphériques communiquent grâce à divers médias et protocoles. Ils doivent


échanger des informations utiles sur l'état du conducteur, du véhicule et de la
marchandise. Les limites des protocoles existants empêchent l'interopérabilité sig-
nicative de bout-en-bout.
Trois catégories d'informations intéressent les transporteurs :
• L état du conducteur et sa sécurité : Ces informations concernent l'identica-
tion du conducteur, le temps de conduite et d'activités. Les données sont issues
ou transmises de/par des périphériques comme le chronotachygraphe, le télé-
phone GSM, le détecteur de fumée, l'éthylotest anti-démarrage, les dispositifs
de surveillance (caméra, capteurs, etc.).
• L'état du véhicule et son environnement : Les données comme la vitesse, la
position, l'état des roues et du moteur sont échangées par des périphériques
comme l'ordinateur de bord, le Bus CAN / FMS 1 ou les systèmes de géolo-
calisation et navigation tels qu'un module GPS, ou un module GPRS, etc.
• L'état de la marchandise : Pour surveiller l'état de la marchandise transportée,
il existe des appareils de pesage embarqués, des capteurs (de choc, de vibration,
de température, etc.), des systèmes d'identication des marchandises entrantes
et sortantes (lecteur de code-barres, système RFID), etc.
Tous ces périphériques communiquent en général de manière ad-hoc. Pour des
raisons de performance, chaque fabricant se focalise sur son c÷ur de métier an
de concevoir des équipements ecaces qui ne traitent que les informations qui sont
nécessaires au service proposé. Le besoin d'optimisation et d'ecacité a donné
naissance à un nouveau challenge technologique. Il s'agit de proposer de nouveaux
services en ouvrant les canaux de communication et/ou en y intégrant de nouveaux
systèmes d'une manière automatique et transparente. En eet, les protocoles qui ont
été mis en place an de répondre à ce besoin, sont ecaces dans l'établissement des
communications entre certains périphériques standards, mais ils restent insusants
pour satisfaire l'interopérabilité de bout-en-bout [19, 15, 18]. En eet, le coût estimé
de la prise en compte systématique de l'interopérabilité est 40% plus élevé par
rapport aux systèmes similaires non interopérables [20].
Pour satisfaire les quatre niveaux d'interopérabilité, nous proposons la concep-
tion d'un canal de communication et de traitement intelligent capable d'assurer une
communication adaptable entre les périphériques. Avant l'implémentation et pour
valider le fonctionnement de notre système, une modélisation formelle est proposée
par la Figure 6.3. Trois familles de périphériques embarqués ont été identiées, ils
peuvent être classé suivant le sens du transfert des données (sans tenir compte des
données de conguration) en trois catégories :
1. Equipements fournisseurs de données : Il s'agit de périphériques qui envoient
des données. Ils sont généralement en mode lecture seule. Ces périphériques
1
Disponible dans : http://www.fms-standard.com/.


6.2. C2A : Le Canal Intelligent pour l'Interopérabilité 55

• Le canal identie le bon port et Baud Rate du périphérique connecté.


• Tout périphérique connecté doit être obligatoirement reconnu.
Modélisation LDS
LDS signie Langage de Spécication et de Description [25]. Langage de Descrip-
tion et de Spécication (LDS) est pris en charge et standardisé par l'Union In-
ternationale des Télécommunications (UIT-T). Il utilise des machines à états nis
ou FSM et leurs extensions pour les spécications des protocoles de communica-
tions. Il représente graphiquement la structure et le comportement des protocoles.
Il est principalement axé sur les processus. Un système modélisé est constitué d'un
ensemble de processus de communication. Chacun peut être créé et détruit dy-
namiquement. Chaque processus communique à travers l'envoi et la réception de
signaux. Le comportement des processus est déni par des automates nis étendue.
Un signal entrant déclenche une transition d'état.
Au cours d'une transition d'état, les actions suivantes peuvent être exécutées:
• Aectation des valeurs aux variables locales.
• Les décisions (branches).
• Envoi des signaux.
• Création d'instances de processus.
• Interruption (une instance de processus peut prendre n que lui-même).
L'outil utilisé pour créer, modier, analyser et simuler le modèle LDS est Cin-
derella SDL version 1.4 2 . En outre, l'outil incorpore un plugin Cinderella Slipper
version 1.0 qui traduit automatiquement le modèle créé vers un exécutable en lan-
gage C. Le code généré peut être simulé par le noyau et le code de simulation
disponibles avec l'outil. Par ailleurs, Cinderella SDL peut exécuter, lors de la simu-
lation des modèles, des procédures externes en C par exemple dénies dans un chier
DLL. Cela, nous a permis de simuler des procédures pas nécessairement disponibles
dans Cinderella SDL. Nous avons utilisé cette façon de faire an de lire directement
les ports séries au lieu de les simuler.
Un exemple de modélisation en LDS est le modèle du processus Identication
illustré par la Figure 6.6. Ce processus permet de vérier si le périphérique con-
necté est déjà connu par le système grâce à la procédure IdentifyFrame. Pour ce
faire, il envoie une demande à Device_In via Data_Loader pour ouvrir les ports
séries disponibles en utilisant l'un des taux de transmission gurant dans le tableau
baudrates.
Contrairement à UPPAAL, qui prend en charge la vérication formelle des pro-
priétés, LDS utilise l'analyse fonctionnelle grâce à la simulation incrémentalle. En
2
Cet outil est disponible sur le site: http://www.cinderella.dk/

58 Chapter 6. Résumé Partie I : Communication Intra-Véhicule

UPPAAL LDS
Vérication des propriétés Description standardisée
Tests exhaustifs Appels distant pour fonctions
Avantages

Détection des défaillances Dénition de nouveaux types de variables


Simulations aléatoires Vérication en utilisant les MSC
Paramètres formels Instanciation dynamique
Simplicité de l'outil Génération automatique de code
Synchronisation binaires Aucune vérication formelle
Inconvénients

Complexité augmente rapidement Prise en main de l'outil


Manque de lisibilité Description de bas niveau
Pas de génération de code Dicultés dans la réutilisation du code
Algorithme de vérication lourd Débogage du code généré
Table 6.1: Comparaison des méthodes de modélisation UPPAAL et LDS

 un module GPS dont les informations communiquées sont formatées au


format NMEA6 .
• Un périphérique de la famille d'équipements 2 : une clé USB.
• Un périphérique de la famille d'équipements 3 : un module GSM / GPRS.
La partie logicielle a été développée sous une distribution Linux embarqué qui a
été optimisée pour minimiser l'empreinte mémoire (18 Mo/ 128Mo disponible) an
de respecter les contraintes de l'embarqué. Le fonctionnement du démonstrateur est
illustré par la Figure 6.8.
La détection d'une nouvelle connexion est traitée par les processus Initialisation
et Identication suivant le protocole série utilisé :
• USB : Le noyau a été conguré de telle sorte à générer des signaux lors d'une
connexion ou déconnexion USB et à associer automatiquement un pilote pour
la lecture des données séries.
• RS232 : Un processus scanne en continu le bus RS232 au niveau de tous les
ports et à des Baud Rate diérents avant de tester les données reçues. Si ces
dernières sont des caractères valides, il conclut à une nouvelle connexion. Puis,
il identie le périphérique à l'aide des caractères reçus.
Après la reconnaissance du périphérique connecté, ce dernier est rajouté à la
table des périphériques encore disponibles dans Update PeriphTable. Puis, Signals
Update prend la main pour fournir les informations nécessaires au lancement du
service approprié. Ces informations dépendent des périphériques connectés et de la
présence d'un appareil de conguration prédéni à l'avance. Ici, nous avons choisi
6
http://www.nmea.org
60 Chapter 6. Résumé Partie I : Communication Intra-Véhicule

Language bien formaté et utilisable par le démonstrateur.


Après l'étape de la conguration, Data Loader charge les données utiles, il les
scinde avant de les organiser dans des structures suivant la conguration retenue.
Pour nir, Data Management eectue les traitements appropriés (conversion, seuil-
lage, etc.) sur ces données et il les archive sur la clé USB ou il les envoie par SMS
à un mobile, à condition que la clé USB et le module GPRS soient connectés.
Ce démonstrateur basé sur la modélisation proposée et prenant en charge un
nombre limité de périphériques représentatifs a été présenté lors d'un séminaire
organisé dans le cadre du comité du pilotage du projet C2A. Il a permis de prouver
la faisabilité du canal C2A sur un nombre réduit de périphériques. Il a été démontré
que ces périphériques peuvent interagir et échanger des données. Ainsi, le système
est capable de proposer automatiquement des nouveaux services à l'utilisateur tout
en lui laissant le choix de les personnaliser par la suite.
Part II

Inter-Vehicular Communication
(V2V)


Chapter 7

VANETs Overview

Contents
7.1 Related Works on Routing Protocols . . . . . . . . . . . . . 66
7.1.1 Topology-based Routing Protocols . . . . . . . . . . . . . . . 66
7.1.2 Geographic Routing Protocols . . . . . . . . . . . . . . . . . 67
7.2 Location-based Services . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Mobility Prediction in VANETs Routing Protocols . . . . . 72

The major feature of VANETs is the high mobility of nodes, which are composed
of fast moving vehicles [34]. More precisely, the characteristics of such networks are:
• Highly dynamic nodes: for example, for two nodes moving in opposite direction
at 100 Km/h, with a transmission range of 250 m, the link between them will
remain available 18 s at maximum.
• Frequent disconnections: the immediate consequences of the high mobility are
topology changes and link disconnections.
• Unlimited power: VANETs do not suer from lack of electrical and computing
powers, because each node is a vehicle equipped with a battery and embedded
processors.
• Constrained mobility: the mobility is constrained by roads, junctions, high-
ways, speed limits, road trac, road signs and trac lights.
• On-board sensors interactions: VANETs may take advantage from the interac-
tion with embedded sensors like a Global Positioning System (GPS) module,
Tachograph, Accelerometer, module General Packet Radio Service (GPRS),
etc.
These characteristics require specic routing protocols that consider the topology
changes and frequent links breaking. The next section describes the routing proto-
cols designed for VANETs. Figure 7.1 presents a taxonomy of the most popular of
these routing protocols.
68 Chapter 7. VANETs Overview

Routing Class Topology Trac DTN Metrics


Protocols Awareness Awareness Used
FSR Topo(Pro) No No No Table
DSR Topo(Act) No No No Topology
TORA Topo(Act) No No No Topology
AODV Topo(Act) No No No Topology
LAR Geo No No No Static Distance
GPSR Geo No No No Static Distance
GSR Geo Yes No No Static Distance
A-STAR Geo Yes Yes No Stat Dist/Trac
GyTAR Geo Yes Yes No Dynamic Dist/Traf
GeoDTN Geo Yes Yes Yes Dyn Dist/Traf/Path
+Nav Direction/Density
Table 7.1: Routing Protocols Summary

path routing. To send messages from one intersection to another, it uses the greedy
forwarding approach.
Like GSR, Anchor-based Street and Trac Aware Routing (A-STAR) [42] is
anchor-based. However, it reects the streets features. A connectivity rate is as-
signed to the roads depending on its capacity and the number of bus crossing it.
This metric is used in addition to traditional metrics (distance, hops, latency) when
making routing decisions.
improved Greedy Trac Aware Routing (GyTAR) [43] was designed as a geo-
graphical routing protocol adapted to urban environments and managing the trac
conditions. A sender selects dynamically an intersection (depending on the streets
connectivity) through which a packet must be forwarded to reach the destination
node. Between intersections, an improved greedy approach to forward packets is
used. This latter is based on the neighbors' speeds and directions.
Geographic and Delay Tolerant Network with Navigation Assistance (GeoDTN
+Nav) [44] switches between Delay Tolerant Network (DTN) and non DTN mode
depending on the roads connectivity. In DTN mode and for a sparse network, the
vehicle uses the carry-and-forward scheme. The packet will be stored until nding
a possible forwarder. The main disadvantage of this protocol is that performances
are aected (high latencies) in a sparse network. This is due to the fact that the
protocol tries constantly to switch between the DTN and non DTN mode when
forwarding packets.
Table 7.1 summarizes a part of routing protocols used for VANETs. The ge-
ographic routing protocol used in this study for the combination is the GPSR.
However, the work is compatible with other geographic routing protocols.
7.2. Location-based Services 69

7.2 Location-based Services


Geographic Routing Protocols use location information when they need to route
packets. Obviously, location information are maintained by Location-based Services
provided by network nodes in a distributed way. Routing and location services are
very related but are considered separately in the literature. The Location-based
Services (in the context of VANETs) is a distributed service without infrastructure
in general. It has to answer to a location query such as: "Where is the node X?".
Location Service

Flooding-based Rendez-vous-based

Proactive Reactive Quorum-based Hierarchical

DREAM RLS Quorum GLS HLS


Figure 7.3: Location-based services Taxonomy

The location-based services can be classied according to Figure 7.3 into two
classes: Flooding-based and Rendez-vous-based location services. The rst class is
composed of reactive and proactive services. In the proactive ooding-based location
services, every node oods its geographic information through the whole network
periodically. Thus, all nodes are able to update their location tables. An example of
proactive ooding-based location service is the Distance Routing Eect Algorithm
for Mobility (DREAM) [45]. Behind DREAM there are two ideas, the rst one is: if a
node is far away, it appears as moving slower than a neighbor having the same speed.
Therefore, the update frequency is reduced when the distance to the node increases.
The second idea is: a node with a high mobility sends more update location packets.
As a result, there are less packets than a simple ooding scheme without aecting
the network performances. For the second group (i.e. the Reactive ooding-based
location service ), the location response is sent after receiving a location request.
This avoids the overhead of useless location information. However, it adds high
latencies not suitable in VANETs. An example is Reactive Location Service (RLS)
[46].
In the second class (i.e. the Rendez-vous-based location services ), all nodes agree
on an unique mapping of a node to other specic nodes. The geographic information
are disseminated through some elected nodes called the location servers. Thus, the
location-based service consists of two components:
1. Location Updates: A node has to recruit location servers and, then, needs to
70 Chapter 7. VANETs Overview

update its location through theses servers. The location servers are responsible
of storing the geographic data of those nodes.
2. Location Requests: A node, seeking the location information of another node,
broadcasts a location request. The location servers will reply as soon as they
receive this request.
There are two major approaches for the Rendez-vous-based location services. In
the Quorum-based approach [47], the location update is sent to a group of nodes
(update quorum). The location query is sent to another group (query quorum).
These two groups have not to be disjoint. The challenge is then to choose how to
generate the query system as discussed in [47].
The second approach is the Hierarchical approach. The network is divided into
several levels. At each level, a node recruits location servers. The location query is
forwarded up and down in the hierarchy. This limits the the number of forwarded
packets and avoids ooding. Two major hierarchical examples are discussed here,
the Grid Location Service (GLS) [48] and the hls [49].
An example of location updates and queries in GLS is represented by Figure
7.4.(a). GLS subdivides the region into four squares which are split into four smaller
squares and so on. The four smallest squares are called the order-1 level in the
hierarchy. This hierarchy is the same for all the nodes. Figure 7.4.(a) shows a three
levels hierarchy. At each square in any level, a node selects a location server with
the smallest ID greater than the node's ID (if it exists). In our example, the node
B with ID 17 chooses the nodes with IDs 23 and 63 at the order-1; the nodes with
IDs 26, 31 and 43 at order-2; and the nodes with IDs 19, 20 and 37 at order-3; as
location servers. Knowing its location servers, a node shares its location information
through location update messages. When the node 90, for example, needs to send
data to the node B, it broadcasts a location query to the order-1 if the targeted node
is not in the same square. The location is forwarded in the next order to the node
with the smallest ID greater than the targeted node's ID (i.e. 17) until reaching a
location server (in our example the node 37), which replies with a location response
packet indicating location information received from the last update.
HLS also split the network into regions, which are subdivided in hexagonal cells.
Neighboring regions are grouped into region levels. This partition is xed and known
by all the participating nodes. An example of the network partition in three region
levels is shown on Figure 7.4.(b). The cell dimensions must be less than the range
transmission. Thus, a node may be able to broadcast a message to all nodes into
the same cell. Unlike GLS, a hashing function depending not only on the ID but
also on the current position of the node is used to choose the responsible cell (the
cell where a node must select its location servers) at each region level. There are
two dierent update methods:
• The direct method: to update its location information, a node frequently
sends packets to the responsible cell at the rst level. A responsible cell may
contain more than one location server. This is the case only for neighboring

72 Chapter 7. VANETs Overview

same region level, a location server may send directly a location reply. If they are
not in the same region level, the location server forwards the request packet to A's
responsible cell in the lower level and so on until reaching the rst level responsible
cell. The latter generates a reply packet and sends it in unicast mode to the node B.
Knowing the position of the node A, B will be able to send data using any geographic
routing protocol.

7.3 Mobility Prediction in VANETs Routing Protocols


It is fairly intuitive to consider the mobility prediction when working on VANETs.
In fact, if the high mobility is predicted and estimated, its eects such as the frequent
disconnections and the network topology changing can be controlled.
An example of routing protocol which uses the mobility prediction is Movement-
based Routing Algorithm (MORA) [50]. It uses the position and the direction of the
neighbors and the destination to choose the next best hop. In fact, it measures the
Fi function (7.1) for each neighbor i, where x is the distance between node i and
the destination and α is the angle between the source-node i direction and the line
perpendicular to the source-destination direction.
|α|
Fi (x, α) = sin (
3
α
) exp (−|x|) + cos ( ) exp (−x2 )
3
(7.1)
Therefore, the maximum of Fi is reached when x is minimal and the α = ± π2 ,
which occurs when the node i is going through or from source to destination. The
next hop is chosen for the maximal Fi metric. This allows each node to take advan-
tage not only of the position, but also of the neighbors' direction, and it will choose
robust links.
Another predicting algorithm is Movement Prediction-based Routing (MOPR)
[51]. For each path, it estimates the future intermediate nodes positions using the
old positions, directions and speeds. Then, it checks the stability of intermediate
nodes. A node is called stable, if and only if its mobility is not likely to break the link
during all the transmission. Then, the choice of the next hop is made between stable
nodes. The node chosen has its velocity (V) similar to the source and destination
(Vi is between VS and VD ). The same choice is made on the direction. Thus,
the estimation of future positions aims to reduce links breaks by predicting them in
advance. Also, MOPR detects unstable intermediate nodes and elects from multiple
routes the most stable one.
MOPR was adapted to GPSR routing protocol in MOPR-GPSR [52], because
MOPR chooses between multiple paths and GPSR does not store paths and forwards
as it receives packets. Therefore, MOPR-GPSR computes the future position of
each neighbor and estimates its link lifetime. It selects the closest neighbor to the
destination within the transmission range during the whole communication.
The next routing protocol is Velocity-Heading based Routing Protocol (VHRP)
[53]. VHRP routes packets to nodes within the same group. There are four groups
(north, south, east, west). If a node has to forward packet to a node with dierent
7.3. Mobility Prediction in VANETs Routing Protocols 73

group, a penalty is added to the metric stored in the packet header. The route
selection is based on the smallest number of hops and lowest metric.
Finally, the Location Prediction Based Routing (LPBR), proposed in [54], is a
reactive topology-based routing protocol using mobility prediction. Its aim is to
reduce the route discovery phase overhead. During the discovery phase, each node
transmits the location requests by adding its Location Update Vector (LUV). The
LUV includes the coordinates, the velocity and the angle of movement of the mobile
node. The destination collects all these LUV. In case of link breaks, the destination
does not send a new request, but it uses the intermediate nodes LUV to compute
their future positions. Then it builds a new topology. If there is at least one available
route to the destination, it returns again packets using this route.
All this protocols use mobility prediction when choosing the next best hop or
in case of disconnections. However, in our study we intend to use the mobility
prediction to reduce the localization overhead and when routing packets to enhance
network performances.
As far as we know, there is no protocol in the literature which considers on one
hand routing and on the other hand location service. Most of geographic routing
protocols assume that they know the geographical positions from location-based ser-
vices without considering, neither the location overhead, nor the latency induced.
Whereas, location-based services give the geographical information without address-
ing routing issues.
Chapter 8

Location-based Services
Comparison

Contents
8.1 Scalability Study . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.1.1 Scalability Denition and Framework Presentation . . . . . . 75
8.1.2 Evaluation of Location Metrics for HLS . . . . . . . . . . . . 77
Location Maintenance Cost . . . . . . . . . . . . . . . . . . . 77
Location Query Cost . . . . . . . . . . . . . . . . . . . . . . . 78
Storage Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Example of Numerical Application . . . . . . . . . . . . . . . 79
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2 Experimental Comparison . . . . . . . . . . . . . . . . . . . . 80
8.2.1 Working Environment for Experimentations . . . . . . . . . . 81
8.2.2 Experimentation Results . . . . . . . . . . . . . . . . . . . . . 81
Query Success Ratio (QSR) Comparison . . . . . . . . . . . . 81
Location Overhead Comparison . . . . . . . . . . . . . . . . . 82
Request Travel Time (RTT) Comparison . . . . . . . . . . . 83
Query Success Ratio (QSR) Scalability Comparison . . . . . 84
Location-based Service Comparison Conclusion . . . . . . . . 84

One pertinent performance criterion in the Location-based Service is the network


scalability. The next section details our contribution about the scalability perfor-
mances study of both GLS and HLS. Specically, what happens if the number of
nodes N increases? The study will focus on three qualitative metrics: the location
maintenance cost, the location query cost and the storage cost. Also, we compared
using simulations, three location-based services RLS, GLS and HLS, based on lo-
calization performances.

8.1 Scalability Study


8.1.1 Scalability Denition and Framework Presentation
Denition In our study, a system is called scalable according to a metric (location
maintenance cost, location query cost or storage cost), if and only if the order of
the metric grows smaller than the order of the system's parameter (N here).
76 Chapter 8. Location-based Services Comparison

Parameters Signicance
A Network area
H Maximum level
k Number of level i − 1 squares at level i (perfect square)
rt Range transmission
R Side length of level−0 smaller squares
N Number of nodes
γ Network vehicles density
δ Distance threshold in location update
υ Node speed
z Average progress in each forwarding hop
d Average distance traveled by a node
di Distance traveled at level i
ρi Boundary crossing rate for level i square
c Random distance within a square
ni Number of forwarding hops at a level i
Pi Probability of querying a node at level i
Cm Location maintenance cost
Cq Location query cost
Cs Storage cost
Table 8.1: The scalability parameters notications

In order to analyze the scalability, we use the framework presented in [55]. The
notations are summarized in Table 8.1. Two assumptions are considered:
• The network area grows linearly with the number of nodes (A ∝ N ). As a
direct consequence, the node density (γ ) remains constant.
• The probability of initiating a packet between any two pairs of nodes is con-
stant.
The main conclusion of authors in [55], who evaluated the complexity of the
location maintenance, the location query and the storage costs for GLS is:

E(Cm ) = O(υ N )

(8.1)
E(Cq ) = O( N ) (8.2)
E(Cs ) = O(log N ) (8.3)
In the next part, we propose an evaluation these metrics for HLS. This will allow
us to better compare GLS and HLS salabilities [56]. GLS and HLS share the same
network partition for a more ecient comparison. In fact, each level i is split into
k squares level i − 1.
8.1. Scalability Study 77

8.1.2 Evaluation of Location Metrics for HLS


Location Maintenance Cost
Denition The location maintenance cost is dened as the number of packets for-
warded by each node per second to update the location information within the
location servers:
H
(8.4)
X
E(Cm ) = ρi E(ni )
i=0

Theorem 8.1.1 (Location Maintenance Cost)


The upper bound of the Location Maintenance Cost in HLS can be expressed as:

E(Cm ) = O(υ log N) (8.5)
Proof Each node has the same probability to move over all the directions. This
is due to the fact that the node's density (γ ) is xed and the vehicles are moving
randomly. Since each level i square is divided into k levels i−1 squares, the boundary
crossing rate at level i is k times smaller than it is at level i − 1. Which gives:

1
ρi = ρi−1
k
ρi =
1
ki
ρ0 , ∀ i, 1 ≤ i ≤ H and k ≥ 4 (8.6)
Also, the boundary crossing rate of the level−0 square is estimated as the ratio
of the speed by d, the average distance traveled by a node in a circle with R as a
radius, given by:
R π/2
R cos θdθ
d = 0
π/2
=
2R
π
(8.7)
This gives ρi :
ρi =
1 υπ
k i 2R
, ∀ i, 0 ≤ i ≤ H and k ≥ 4 (8.8)
The average number of forwarding hops at level i, E(ni ), is dened as the ratio of
E(di ) (the average distance traveled by a packet at level i) by z (the average progress
performed by a packet at level i). This latter is constant because it depends only
on the radio transmission and the network density γ . E(ni ) is thus obtained by:

E(ni ) =
E(di )
z
(8.9)
E(di ) = k i Rc, ∀ i, 0 ≤ i ≤ H and k ≥ 4 (8.10)
78 Chapter 8. Location-based Services Comparison

The constant c represents the average distance between two random points in a
square of side 1 estimated in [57] as:
Z 1Z 1Z 1Z 1p
c = (x1 − x2 )2 + (y1 − y2 )2 dx1 dx2 dy1 dy2
0 0 0 0
√ √ √
2 + 5 2 ln( 2 + 1) + 2 2 √
c ≈ 2
√ 30
c ≈ 0, 36869 2 ≈ 0, 5214 (8.11)
From equations (8.4), (8.8) and (8.9), we obtain:

υπcH
E(Cm ) =
2z
E(Cm ) = O(υH) (8.12)
However, the network is shared on kH squares of side R, then:
A = k H R2 (8.13)
H can be computed:

log( RA2 )
H =
log k

A
log( )
H = √R
log( k)

H = O(log A) (8.14)
Combining the equations (8.21), (8.14) and considering A ∝ N (the density γ is
xed), we obtain the upper bound of the location maintenance cost.
Location Query Cost
Denition The location query cost is the number of packets forwarded by each
node in a second when asking for location information. It depends on whether the
request is satised in the same level i or not:
H
(8.15)
X
E(Cq ) = Pi E(ni )
i=0

Theorem 8.1.2 (Location Query Cost)


The upper bound of the Location Query Cost in HLS can be expressed as:

E(Cq ) = O( N ) (8.16)
8.1. Scalability Study 79

Proof As mentioned above, the trac pattern used is uniform which means:

k−1
Pi =
k H−i
, ∀ i, 1 ≤ i ≤ H and k ≥ 4 (8.17)
1
P0 =
kH
From the equations (8.9), (8.15) and (8.17) the location query cost can be esti-
mated:

Rc (k − 1)k 2 2H
E(Cq ) = [1 + (k − 1)], k ≥ 4
zk H (k 2 − 1)
(k − 1)Rck H
E(Cq ) ≈
z
, k≥4 (8.18)
Combining (8.14) and (8.18) gives the expected result of the upper bound of the
location query cost.
Storage Cost
Denition The storage cost is the number of location information records in a
location server.
Theorem 8.1.3 (Storage Cost)
The upper bound of the Storage Cost in HLS can be expressed as:

E(Cs ) = O(log N ) (8.19)


Proof Since the network density γ is constant, the distribution of the location
servers must be uniform. Therefore, the storage cost could be deduced directly:
E(Cs ) = H + 1 (8.20)
Finally, with (8.14) and (8.20), we obtain the expected upper bound.
Example of Numerical Application
Let's consider a realistic example of the Location Maintenance Cost estimations for
GLS and HLS. In [55], the Location Maintenance Cost in GLS is estimated as:

H
υ X (2c2 + c3 ) · 2i · R √ √
E(Cm ) = · , with c2 ≈ 5 and c3 ≈ 2 2
δ z
i=1
υ (2c2 + c3 ) · R
E(Cm ) = 2 · ·
δ z
· (2H − 1) (8.21)
80 Chapter 8. Location-based Services Comparison

Parameters Numerical Values Comments


A 2 km2 Area used
H 3 Maximum level as in Figure 7.4.(a)
k 4 Number of squares as in Figure 7.4.(a)
rt 250 m Range transmission from IEEE 802.11p [32]
R 177 m Side length = √r 2 for transmission
t

N 100 Veh Number of nodes


γ 50 V eh/km 2 Network vehicles density = NA
δ 250 m Distance threshold in location update = rt
υ 50 km/h = 13.89 m/s Vehicle limitation speed in town
z 5m Average progress = rγ t

c 0.5214 Random distance within a square


Table 8.2: The numerical parameters values

Table 8.2 summarizes the numerical values. In addition, the justication of these
choices is discussed in the same table.
Using these values, we evaluate the Location Maintenance Cost estimations in
both GLS and HLS. These estimations are:
• in GLS: E(Cm ) = 2 · υδ · (2c +c
2
z
)·R
3
· (2H − 1) = 719 488 Packets/s

• in HLS: E(Cm ) = υπcH2z = 24 588 Packets/s

The numerical application shows that HLS has very fewer location updates than
GLS. √This conrms that HLS should √ have a lower location updates upper bound
(υ log N ) than the one in GLS (υ N ).

Discussion
By comparing (8.1) with (8.5), (8.2) with (8.16) and (8.3) with (8.19), we conclude
that HLS scales better especially for the location maintenance cost as shown by pre-
vious numerical applications. This is due to the dierence in the update mechanism.
In GLS, all location servers store the node's position. However in HLS, the location
servers at a level i stores the responsible cell's position at the level i-1 which has
to be updated less frequently. Those qualitative metrics conrm that HLS scales
better than GLS. The next subsection arises the question whether HLS has better
performances than RLS and GLS.

8.2 Experimental Comparison


Since the proactive ooding-based location service is not ecient (lack of scalability
and risks of congestion), we choose to compare a reactive service, RLS, and two
hierarchical services, GLS and HLS.
km2
√ √
O(υ N ) O(υ log N)


O( N ) O(log N )
Chapter 9

Joint Routing and Location-based


Service in VANETs: New
Approaches

Contents
9.1 Working Environment for Experimentations . . . . . . . . . 88
9.2 Simple Hybrid Approach . . . . . . . . . . . . . . . . . . . . . 89
9.2.1 Scalability Study for the Hybrid Approach . . . . . . . . . . 92
9.2.2 Location Information Freshness Impact . . . . . . . . . . . . 94
Location Information Freshness Impact on Location Overhead 94
Location Information Freshness Impact on Routing Perfor-
mances . . . . . . . . . . . . . . . . . . . . . . . . . 95
Location Information Freshness Impact Study Conclusion . . 96
9.2.3 Hybrid Routing and Hierarchical Location Service (HRHLS) 96
HLS and HRHLS Location Overhead Comparison . . . . . . 97
HLS and HRHLS Routing Performances Comparison . . . . . 97
HLS and HRHLS Comparison Conclusion . . . . . . . . . . . 99
9.2.4 Hybrid Routing and Grid Location Service (HRGLS) . . . . . 100
Location Statistics Results . . . . . . . . . . . . . . . . . . . 100
Location Overhead Results . . . . . . . . . . . . . . . . . . . 101
Location Eciency Results . . . . . . . . . . . . . . . . . . . 102
Routing Eciency Results . . . . . . . . . . . . . . . . . . . . 103
GLS, HLS, HRGLS and HRGLS Approaches Comparison Con-
clusion . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3 Hybrid Approach with Mobility Prediction . . . . . . . . . . 105
9.3.1 PHRHLS Approach Description . . . . . . . . . . . . . . . . . 106
9.3.2 HLS, HRHLS and PHRHLS Experimental Comparison . . . . 107
Location Overhead Comparison . . . . . . . . . . . . . . . . . 107
Routing Performances Comparison . . . . . . . . . . . . . . . 108
HLS, HRHLS and PHRHLS Approaches Comparison Conclusion109
Chapter 9. Joint Routing and Location-based Service in VANETs:
88 New Approaches

Usual Topology-based Routing Protocols have limited performances in VANETs.


Geographic Routing Protocols were designed to provide better performances for
VANETs. The main principle adopted by these protocols is that each node has
to care about its actual geographic position (oftenly achieved by a GPS module)
and the position of the node to reach. With these protocols, the paradigm position-
to-position is used. The Location-based Service is required to maintain the desti-
nation position up-to-date. Therefore, the combination of location-based services
with geographic routing protocols is quite natural in order to guarantee interesting
location and routing performances. Thus, any research work on geographic routing
should absolutely consider the existence of a Location-based Service . However, in
the literature, this preliminary step is often considered ideal and its impact on the
performances of the whole location and routing process is not considered.
In this section, we present our Joint Routing and Location-based Service ap-
proaches. These approaches mix localization and routing issues. There aim is to
reduce localization overhead and enhance routing performances. The rst subsec-
tion presents the working environment for experimental comparison between the
approach which uses the location-based service and the geographic routing proto-
col separately, and the hybrid proposed approaches. The two following subsections
describe a simple hybrid approach and a hybrid approach with mobility prediction,
and detail experimentations results.

9.1 Working Environment for Experimentations


As for location-based service comparison in Section 8.2, simulations are performed
using the NS-2 2.33. The geographic routing protocol used is the GPSR [40]. The
same area as in Section 8.2 was used. The MAC layer used is the same IEEE 802.11p
implementation. The parameters used in the simulation are summarized in Table
9.1. The simulations were run 10 times and the results are averaged over these
simulations.
For each experimentation, a node initiates 4 Constant Bit Rate (CBR) tracs
of 20 packets with a size of 128 bytes to 4 random destination nodes with a second
of interval between each send. The CBR trac simulates for example an audio or
a video streaming. It may be used in security applications for example, such as
viewing the video stream from a camera located on a bus by a police or a security
agent vehicles. Also, this trac could be used in entertainment applications to
connect to the Internet or to play online video games. For more details on the NS-2
simulations procedure, please refer to Appendix B.
In the two next sections, we present the hybrid approach and we detail the NS-2
simulation results. We compare GLS and HLS working separately with GPSR, the
combination of GLS or HLS with GPSR (HRGLS / HRHLS), and the combination
of HLS and GPSR with mobility prediction (PHRHLS). The comparison is based
on the location overhead (the number of sent location requests, the location band-
9.2. Simple Hybrid Approach 89

Parameters Value
Channel type Channel/WirelessChannel
Propagation model Propagation/TwoRayGround
Network interface Phy/WirelessPhyExt
MAC layer 802.11p
Interface queue type Queue/DropTail/PriQueue
Link layer LL
Antenna model Antenna/OmniAntenna
Interface queue length 512 packets
Ad-hoc routing protocol GPSR
Location-based service GLS or HLSHLS
Area 2x2 km2
Number of nodes 20, 40, 60, 80, 100 and 120
Simulation time 300 s
GPSR beacon interval 0,5 s
CBR trac 4 x 20 packets / node
CBR packet size 128 B
CBR send interval 1s
Table 9.1: The NS-2 simulation parameters of the combination approach

width consumed, etc.) and the network performances (the packet delivery ratio, the
average latency, etc.).

9.2 Simple Hybrid Approach


In order to reduce the localization overhead and enhance routing performances,
we combine the location-based services GLS and HLS with the geographic routing
protocol GPSR denoted Hybrid Routing and Grid Location Service (HRGLS) and
Hybrid Routing and Hierarchical Location Service (HRHLS). Then, we compare the
overhead generated by the location-based service (number of sent location requests,
location consumed bandwidth, etc.) with and without combination. Also, we com-
pare the routing performances (packet delivery ratio, latency, number of hops, etc.).
The combination of HLS with GPSR is presented in [58]. Although, here we present
the combination of HLS and GLS, both with GPSR. These combinations are eval-
uated through realistic experimentations. Besides, the same metrics as in Section
8.1 are estimated for the hybrid approaches (HRGLS and HRHLS). This subsection
describes these combinations and the next ones detail the simulation results.
Basically, the location-based service GLS or HLS, is run separately with the
routing protocol GPSR. That means, if a node needs to send data to another one,
GPSR asks the location-based service whether it has a fresh information about the
destination's location or not. If so, GPSR uses this position to forward packets in


9.2. Simple Hybrid Approach 91

the querying of destination's position, it looks into the local cache memory of the
current node and updates the packet information with the destination's position. If
the location information are not fresh enough, the old position is used to forward
data as soon as possible.

Algorithm 1 Location-based Service (HRGLS or HRHLS)


1: cacheT hreshold ← LocationCacheM axAge;
2: Struct P os{
3: int ts; . Time Stamp
4: int id; . Node ID
5: double x, y, z; . Position
6: }P os
7: enum f reshness {N oP osition = 0, F resh = 1, N onF resh = 2};
8: procedure Poslookup(packetT oSend)
9: if (! Location information) then
10: f reshness ← N oP osition;
11: P repareP acket(packetT osend);
12: else
13: if (Destination Location age < cacheThreshold) then
14: f reshness ← F resh;
15: P repareP acket(packetT oSend);
16: else
17: f reshness ← N onF resh;
18: P repareP acket(packetT osend);
19: end if
20: end if
21: end procedure . End of Poslookup

The GPSREmit procedure (dened in the line 1 of the Algorithm 2) in the


geographic routing protocol GPSR manages the creation and sending of new packets,
it veries at rst, whether the sender has fresh or non-fresh information about the
destination position and then starts the routing of packets. If it has any location
information, the function starts a new position query and inserts the packet into a
buer while the query is taking place.
The forwardPacket function (dened in the line 16 of the Algorithm 2) handles
the forwarding of packets, it is called whenever a packet reaches an intermediate
node, it veries whether this node has a more fresh position of the target and
possibly updates the packet information with it. Otherwise, if the intermediate
node is in the same region than the old position, a new query is launched to retrieve
the new exact position of the target.
Chapter 9. Joint Routing and Location-based Service in VANETs:
92 New Approaches
Algorithm 2 Geographic Routing Protocol GPSR
1: procedure GPSREmit(packetT oSend)
2: P repareP acket(packetT oSend);
3: P oslookup(packetT oSend);
4: if (freshness == Fresh) then
5: F orwardP acket(packetT oSend);
6: else
7: if (freshness == NonFresh) then
8: P repareP acket(packetT osend);
9: F orwardP acket(packetT oSend);
10: else
11: LaunchP ositionQuery(destination);
12: StickT oBuf f er(packetT oSend);
13: end if
14: end if
15: end procedure . End of GPSREmit
16: procedure forwardPacket(packetT oSend)
17: if (freshness == Fresh) then
18: ChooseN extBestHop(packetT oSend);
19: F orwardN extHop(packetT oSend);
20: else
21: if (Current Node freshness == Fresh) then
22: U pdateP acketDestination(packetT oSend);
23: ChooseN extBestHop(packetT oSend);
24: F orwardN extHop(packetT oSend);
25: else
26: if (Current Node Region == Destination Node Region) then
27: LaunchP ositionQuery(destination);
28: StickT oBuf f er(packetT oSend);
29: else
30: ChooseN extBestHop(packetT oSend);
31: F orwardN extHop(packetT oSend);
32: end if
33: end if
34: end if
35: end procedure . End of forwardPacket

9.2.1 Scalability Study for the Hybrid Approach


To better understand the dierence between the hybrid and the original approaches,
two types of trac pattern can be identied: the localized trac pattern which
characterizes the hybrid approach and the uniform trac pattern used in the section
8.1 which qualies the original approach. In fact, in the original approach, a node
9.2. Simple Hybrid Approach 93

can query another node, anytime, anywhere in the hierarchy. Whereas in the hybrid
approach, the query is run only at the rst level region at the nearest to the old
position. Therefore, we can consider that the trac pattern is almost local in the
hybrid approach (i.e. HRGLS and HRHLS).
Denition In order to compare both approaches, we dene a localized trac pat-
tern as follows:

H
1 X
Pi = Pi−1 , ∀ i, 0 ≤ i ≤ H, k ≥ 4, with Pi = 1 :
k
i=0

Pi =
1
·
k i+1 1 −
1
1 , ∀ i, 0 ≤ i ≤ H, k ≥ 4 (9.1)
kH+1

Theorem 9.2.1 (Location Query Cost in Hybrid Approach)


The upper bound of the Location Query Cost in Hybrid scheme (HRGLS and
HRHLS) can be expressed as:

E(Cq ) = O(log N ) (9.2)


Proof The localized trac is used to compute the location query cost:

Rc H +1
E(Cq ) = · 1 , k ≥4
zk 1 − kH+1

E(Cq ) ≈
Rc
zk
· (H + 1), k ≥ 4 (9.3)
Using (8.14), the equation (9.3) can lead directly to the result of the upper bound
of the location query cost in Hybrid approach (HRGLS or HRHLS).
We use the same numerical values dened in Section 8.1.2 to evaluate the Loca-
tion Query Cost in both HLS and HRHLS:

in HLS: E(Cq ) ≈ (k−1)Rck Packets/s


H
• z = 3 524

• in HRHLS: E(Cq ) ≈ Rc
zk · (H + 1) = 19 Packets/s

Since the hybrid approach does not interfere on the maintenance and the storage
process, the Location Maintenance Cost and the Storage Cost remain unchanged
between the original approaches (GLS and HLS) and the hybrid ones. Table 9.2
summarizes the scalability study about GLS, HLS, the hybrid GLS and the hybrid
HLS approaches (HRGLS and HRHLS). It conrms with the numerical application
above that the hybrid approach reduces the query cost by decreasing the number of
sent request packets.
√ √ √ √
O(υ N ) O(υ log N ) O(υ N ) O(υ log N )
√ √
O( N ) O( N ) O(log N ) O(log N )
O(log N ) O(log N ) O(log N ) O(log N )
Chapter 9. Joint Routing and Location-based Service in VANETs:
100 New Approaches
9.2.4 Hybrid Routing and Grid Location Service (HRGLS)
As HLS is rather ecient (PDR generally above 90%), HRHLS improves its per-
formances. This is why we are interested in applying the hybrid approach to GLS
which has poor performances that can be improved. This leads to the Hybrid Rout-
ing and Grid Location Service (HRGLS) approach. Several experimentations have
been conducted to prove these enhancements. The simulation results are divided
into four topics:
• Location Statistics: This includes all statistics we were able to extract from
the simulations concerning the location such as the location cache access, the
cache average age, the number of sent requests and sent updates (Figures 9.9
and 9.10).
• Location Overhead: The overhead is represented as the location bandwidth
consumed within the MAC and routing layers in order to send location up-
dates, forward the location requests and reply by location responses (Figure
9.11).
• Location Eciency: The location eciency is estimated by the Query Success
Ratio (QSR) and the Request Travel Time (RTT), which are both dened in
Section 8.2 (Figure 9.12).
• Routing Eciency: The routing eciency is evaluated by the Packet Delivery
Rate (PDR) and the average CBR packets latency (Figure 9.13).

Location Statistics Results


Figure 9.9.(a) shows the number of access to the location cache memory. It conrms
that the hybrid approaches HRGLS and HRHLS use aggressive location cache poli-
cies compared to the original GLS and HLS schemes. Hence, the hybrid approach
uses the old position even if it is not fresh. HRGLS uses the cache memory 3 times
more than GLS, and HRHLS 2 times more than HLS in average. As a direct conse-
quence, the average age of the location cache entries used increases strongly between
the original and the hybrid schemes, which is depicted in Figure 9.9.(b). The aver-
age age for all the simulations increases from 0.17s in GLS to 5.4s in HRGLS. Also,
this same value increases from 1.4s in HLS to 5.58s in HRHLS.
In addition to the old cache entries used, HRGLS and HRHLS decreases heavily
the number of sent requests as shown in Figure 9.10.(a). In average, there are a
tenth of sent and forwarded location requests in HRGLS than in GLS. Also, there
are less than half of location requests in HRHLS than in HLS. This is due to the
hybrid approach which launches the location requests as late as possible. Therefore,
there are less requests launched and forwarded. This dierence in the location query
cost conrms the results of the scalability study presented in Section 9.2.1 which
anticipate
√ a lower upper bound for hybrid approaches (log N ) than for the original
ones ( N ).
P os VxVy Vz
9.3. Hybrid Approach with Mobility Prediction 107

Algorithm 3 Location-based Service (PHRHLS)


1: cacheT hreshold ← LocationCacheM axAge;
2: Struct P os{
3: int ts; . Time Stamp
4: int id; . Node ID
5: double x, y, z; . Position
6: double V x, V y, V z; . Velocity
7: }P os
8: enum f reshness {N oP osition = 0, F resh = 1, N onF resh = 2};
9: procedure Poslookup(packetT oSend)
10: if (! Location information) then
11: f reshness ← N oP osition;
12: P repareP acket(packetT osend);
13: else
14: if (Destination Location age < cacheThreshold) then
15: f reshness ← F resh;
16: P repareP acket(packetT oSend);
17: else
18: f reshness ← N onF resh;
19: P os position ← packetT osend.P os;
20: position ← P redictP os(position);
21: P repareP acket(packetT osend);
22: end if
23: end if
24: end procedure . End of Poslookup
25: procedure PredictPos(position)
26: double now = Scheduler :: instance.clock(); . Current Time
27: double P redictInterval = now − position.ts;
28: P os positionP redected ← position;
29: positionP redected.x ← position.x + position.V x ∗ P redictInterval;
30: positionP redected.y ← position.y + position.V y ∗ P redictInterval;
31: return positionPredected;
32: end procedure . End of PredictPos

9.3.2 HLS, HRHLS and PHRHLS Experimental Comparison


Location Overhead Comparison
The rst result of these experimentations is the number of sent location requests
shown in Figure 9.15. The number of location requests is reduced in HRHLS and
PHRHLS due to the aggressive location cache memory policies. There are, for
example, 78% less location requests in HRHLS and 82% in PHRHLS compared to
HLS with 100 nodes. This is due the fact that in HRHLS and PHRHLS a request
is launched closer to the destination and the packet is sent even if the location
XTP2red = XT1 +
VX ∗ [T2 − T1 ]
Chapter 10

Conclusion of Part II

V2V are a subset of VANETs. Vehicles exchange data in unicast or broadcast mode
using multi-hop communications. Vehicles are moving fast, and hence the network
topology changes frequently, which causes links breakages. The repair of these links
is costly, especially in Topology-based Routing Protocols , where the discovery phase
needs to be launched continuously. Geographic Routing Protocols avoid ooding
by routing packets based on the destination position. Therefore, they need fresh
geographic information about the destination. These information are updated by
Location-based Services . These latter are responsible of maintaining fresh locations
and replying to location requests. In this part, we present taxonomies of Topology-
based Routing Protocols , Geographic Routing Protocols , Location-based Services and
Routing Protocols with Mobility Prediction in VANETs. Moreover, a Joint Routing
and Location-based Service approaches are presented and are evaluated through the
NS-2 2.33. The rst approach is the combination of a Location-based Service with
a Geographic Routing Protocol . Two implementations of this approach introduced
were HRGLS (GLS+GPSR) and HRHLS (HLS+GPSR). These two combinations
are compared to the original approaches. They reduce signicantly on one hand the
localization overhead and increase on the other hand routing performances. The
second approach is based on the former approach extended with mobility prediction
algorithm. This latter, based on extrapolation using velocities, enhanced again rout-
ing performances by improving the packets delivery and the latency. We estimated
also the complexity of the Location Maintenance Cost, the Location Query Cost
and the Location Storage Cost in the original approaches (GLS and HLS) and the
simple hybrid approaches (HRGLS and HRHLS). We have undertaken experimen-
tations which conrm the result of this scalability study, that HLS is more scalable
than GLS for the Location Maintenance Cost and that the hybrid approaches have
a lower Location Query Cost than the original ones.
Chapter 11

Résumé Partie II :
Communication Inter-Véhicules

Contents
11.1 Comparaison des Services de Localisation . . . . . . . . . . . 118
11.1.1 Etude de Mise à l'échelle . . . . . . . . . . . . . . . . . . . . 118
11.1.2 Comparaison Expérimentale . . . . . . . . . . . . . . . . . . . 119
11.2 Routage et Localisation Conjoints dans les Réseaux VANETs
: Nouvelles Approches . . . . . . . . . . . . . . . . . . . . . . 121
11.2.1 L'Approche Hybride Simple . . . . . . . . . . . . . . . . . . . 121
Description de L'Approche Hybride Simple . . . . . . . . . . 121
Comparaison Expérimentale de l'Approche Originelle et L'Approche
Hybride Simple . . . . . . . . . . . . . . . . . . . . . 123
Comparaison du Coût de La Localisation : . . . 123
Comparaison des Performances de La Localisa-
tion : . . . . . . . . . . . . . . . . . . . . . 123
Comparaison des Performances du Routage : . 123
Conclusion sur La Comparaison Expérimentale
de l'Approche Originelle et L'Approche
Hybride Simple : . . . . . . . . . . . . . 124
11.2.2 L'Approche Hybride avec Prédiction de Mobilité . . . . . . . 124
Description de L'Approche Hybride avec Prédiction de Mobilité124
Comparaison Expérimentale de l'Approche Originelle, L'Approche
Hybride Simple et L'Approche Hybride avec Prédic-
tion de Mobilité . . . . . . . . . . . . . . . . . . . . 126

La première partie vise à améliorer la Communication Inter-Véhiculaire. En


eet, le canal C2A a été conçu pour faciliter le ux d'informations entre les systèmes
embarqués dans le véhicule. Maintenant, que se passe-t-il si de nombreux véhicules
ont besoin de communiquer et d'échanger des données entre eux? Ces informations
échangées peuvent être critiques pour éviter les collisions ou les accidents (alerte
véhicule en panne, alerte verglas, alertes de collisions, etc.). Elles peuvent être
également liées aux Systèmes de Transport Intelligents (STI) comme Green Light
Optimized Speed Advisory (GLOSA) [30] pour la gestion des feux de circulation,
gestion du trac routier, déviations en cas de bouchons, etc. Enn, elles peuvent
114 Chapter 11. Résumé Partie II : Communication Inter-Véhicules

concerner le confort et les applications de divertissement telles que la navigation


Internet, les jeux vidéo en ligne, l'éco-conduite, etc. Ainsi, les Communications
Inter-Véhiculaires sont devenues une nécessité pour la sécurité, les applications de
divertissement ou de STI. Ceci est dû à la maturité des technologies sans l, ainsi
qu'à l'importance croissante du véhicule dans notre vie, qui est considéré aujourd'hui
comme le troisième lieu de vivre après la maison et le bureau. Dans cette partie,
nous nous sommes interessés principalement à la Communication Inter-Véhiculaire,
communément appelé VANETs ou (Réseaux Véhiculaires Ad-hoc). Les VANETs
sont un cas particulier des MANETs ou Réseaux Mobiles Ad-hoc. Les MANETs
sont des réseaux mobiles et sans l auto-organisés. Il existe trois types de VANETs
:
• Communications Véhicules à Infrastructures (V2I) [12] : Les véhicules ne peu-
vent pas communiquer directement. Ils ont besoin de passer par une infras-
tructure (3G, LTE, etc) qui sert d'intermédiaire. Ces véhicules sont identiés
par des adresses IP par exemple.
• Communications Véhicule à Véhicule (V2V) [31] : Chaque véhicule est con-
scient des autres véhicules voisins autour de lui à travers l'échange de messages
HELLO. Il peut envoyer des alertes en temps réel si un incident ou un événe-
ment inattendu s'est produit, dans le but d'éviter les accidents et les collisions
en utilisant des communications multi-sauts. L'une des technologies les plus
prometteuses à ce jour pour ces types de communications est la technologie
IEEE 802.11p [32].

• Communications Hybrides V2I et V2V [33] : Les véhicules peuvent choisir


entre l'envoi de paquets directement aux voisins proches et l'envoi des paquets
aux véhicules qui ne sont pas dans la portée radio, via l'infrastructure.
Dans notre étude, nous nous sommes interessés aux Communications Véhicule
à Véhicule (V2V). Nous supposons que tous les véhicules participants sont équipés
d'un canal C2A avec une extension qui gère une antenne IEEE 802.11p. Les Commu-
nications Véhicules à Infrastructures (V2I) seront pris en compte dans les travaux
futurs.
La principale caractéristique des réseaux VANETs est la haute mobilité des
n÷uds, qui sont composées de véhicules roulant à grande vitesse. Plus précisément,
les diérentes caractéristiques de ces types de réseaux sont les suivantes :
• N÷uds hautement dynamiques : Par exemple, pour deux n÷uds roulant en
sens inverse à 100 Km/h, avec une portée de transmission de 250 m, la con-
nection entre eux restera active que pour une durée maximale de 18s.
• Déconnexions fréquentes : La conséquence immédiate de la haute mobilité est
le changement de la topologie et donc des déconnexions continues.


116 Chapter 11. Résumé Partie II : Communication Inter-Véhicules

Protocoles Classe Topologie Trac RTD Metriques


de Routage du Proto des Rues Routier Utilisées
FSR Topo(Pro) Non Non Non Table Routage
DSR Topo(React) Non Non Non Topologie
TORA Topo(React) Non Non Non Topologie
AODV Topo(React) Non Non Non Topologie
LAR Géo Non Non Non Distance Statique
GPSR Géo Non Non Non Distance Statique
GSR Géo Oui Non Non Distance Statique
A-STAR Géo Oui Oui Non Dist/Trac Stat
GyTAR Géo Oui Oui Non Dist/Traf Dynamique
GeoDTN Géo Oui Oui Oui Dist/Traf/Chemin
+Nav Direction/Densité Dyn
Table 11.1: Résumé des Protocoles de Routage

de mise à l'échelle. Cela est dû à la haute mobilité, ce qui engendre des liens courts et
interrompus. C'est pourquoi les Protocoles de Routage Géographique ont été pensés
an de traiter ces problématiques.
Par exemple, GPSR [40] est un Protocole de Routage Géographique réactif qui
transmet les paquets au voisin le plus proche du n÷ud cible jusqu'à atteindre la des-
tination (approche Gloutonne ou Greedy Forwarding ). Par conséquent, il s'adapte
mieux que les Protocoles de Routage Topologiques aux réseaux à larges échelles dy-
namiques, mais il ne prend pas compte ni de la topologie urbaine des rues comme
dans GSR [41], ni du trac routier comme dans A-STAR [42] ou GyTAR [43]. Il
n'est pas adapté non plus aux réseaux éparses comme dans les Réseaux Tolérants
aux Délais (RTD) tel que GeoDTN +Nav [44].
La Table 11.1 résume les principaux protocoles de routage utilisés dans les
réseaux VANETs. Le protocole de routage géographique utilisé dans cette étude
est le protocole GPSR. Cependant, ce travail reste compatible avec les autres Pro-
tocoles de Routage Géographique.
Les Protocoles de Routage Géographique utilisent les informations de localisation
des n÷uds quand ils ont besoin d'acheminer des paquets. Cependant, ces informa-
tions sont maintenues par des services distribués connus sous le nom de Services de
Localisation. Par conséquent, les Protocoles de Routage Géographique et les Services
de Localisation sont très liés, mais généralement ils sont considérés séparément dans
la littérature. Les Services de Localisation (dans le contexte des réseaux VANETs)
sont des services distribués sans infrastructure. Il ont pour but de répondre à des
requêtes de localisation telles que: "Où est le n÷ud X?".
Il existe principalement deux types de Services de Localisation : les services
basés sur l'inondtation du réseau et ceux qui sont basés sur la hiérarchie du réseau.
Un exemple parmi les Services de Localisation basé sur l'innondation est le RLS [46].
118 Chapter 11. Résumé Partie II : Communication Inter-Véhicules

positions auprès de ces serveurs. Quand un autre n÷ud a besoin de cette position,
il envoie une requête vers ces serveurs qui réponderont après l'avoir reçue. La dif-
férence remarquable entre GLS et HLS illsutrée par la Figure 11.2, se fait au niveau
de la mise à jour. Dans GLS, chaque n÷ud envoie une mise à jour périodique de
sa position vers tous les serveurs de localisation à tous les niveaux. Alors que dans
HLS, cette mis à jour se fait qu'au premier niveau et que seule la mise à jour de la
position de la cellue résponsable (la cellule où l'élection des serveurs de localisation
doit se faire) est envoyée du niveau i vers la cellule responsable du niveau i + 1.
Cette étude, tout d'abord, présente une comparaison des Services de Localisation
les plus connus. Cette comparaison montre que les Services de Localisation Hiérar-
chiques permettent d'améliorer les performances de localisation à moindre coût.
Pour cette raison, nous proposons deux combinaisons appelées HRGLS et HRHLS
entre Greedy Perimeter Stateless Routing (GPSR) comme protocole de routage géo-
graphique et Grid Location Service (GLS) ou HLS comme service de localisation.
Plusieurs expérimentations ont été eectuées sur le simulateur réseau NS-2. Ces
expérimentations montrent que les combinaisons ecaces entre les protocoles de
routage géographiques et les services de localisation permettent d'améliorer les per-
formances du réseau tout en réduisant les coûts de localisation. Pour améliorer
encore plus les performances de routage, nous avons intégré à HRHLS un Algo-
rithme de Prédiction de Mobilité dans une approche appellée, PHRHLS. D'autres
simulations ont été réalisées an de montrer les avantages de la prédiction de la
mobilité.

11.1 Comparaison des Services de Localisation


11.1.1 Etude de Mise à l'échelle
An de réaliser cette comparaison, on a eu recours au cadre théorique dénit dans
[55]. On suppose aussi que la densité des n÷uds reste constante. De plus, le trac
utilisé est un trac uniforme dans le quel chaque n÷ud a la même probabilité
d'envoyer une requête de localisation vers n'importe quel autre n÷ud du réseau.
Le but de cette comparaison est d'évaluer les conjonctures assymptotiques des Coût
de la Maintenance de Localisation, Coût des Requêtes de Localisation et Coût de la
Sauvegarde de Localisation, dans GLS et HLS en fonction du nombre de n÷uds (N ).
Les auteurs de [55] ont évalué ces métriques pour GLS et leur conclusion est :


E(Cm ) = O(v N )

(11.1)
E(Cq ) = O( N ) (11.2)
E(Cs ) = O(log N ) (11.3)
Alors que, notre évaluation pour HLS de ces mêmes paramètres a donné le
résultat suivant :
11.1. Comparaison des Services de Localisation 119


E(Cm ) = O(v log N )

(11.4)
E(Cq ) = O( N ) (11.5)
E(Cs ) = O(log N ) (11.6)
En comparant (11.1) avec (11.4), ainsi que (11.2) avec (11.5) et pour nir (11.3)
avec (11.6), on conclut que GLS et HLS sont tout les deux extensibles (scalables)
en fonction des ces trois critères évalués. Toutefois, HLS s'adapte mieux que GLS
aux larges réseaux surtout pour les coûts de maintenance de localisation. Ceci est
dû à la diérence dans le mécanisme de mise à jour. Dans GLS, tous les serveurs
de localisation maintiennent à jour la position du n÷ud. Cependant dans HLS, ces
même serveurs stockent au niveau i la position de la cellule responsable du niveau i−
1 qui doit être mis à jour moins régulièrement. Ces mesures qualitatives conrment
que HLS évolue mieux que GLS. Dans la section suivante, les performances de RLS,
GLS ainsi que HLS sont évaluées.
11.1.2 Comparaison Expérimentale
Les simulations ont été réalisées à l'aide du Simulateur NS-2 2.33 1 . Le protocole de
routage géographique utilisé est Greedy Perimeter Stateless Routing (GPSR) [40].
La région choisie est une surface de 2x2 km2 extraite d'une vraie carte représentant
une partie de la ville de Reims. Cette zone est extraite du site Web Open Street
Map 2 . La couche MAC utilisée est l'implémentation NS-2 du IEEE 802.11p 3 . La
simulation a été lancée 10 fois et les résultats sont calculés sur la moyenne pour plus
de précisions.
Nous avons étudié le coût induit par les services de localisation en ce qui concerne
les requêtes, la mis à jour et les réponses. La coût est mesuré par le nombre de
paquets envoyés et transmis au cours des mises à jour de localisation, des requêtes
et des réponses (Figure 11.3.(a)). RLS n'utilise pas le mécanisme de mise à jour,
mais les requêtes inondent sur tout le réseau. Cela crée un trac important qui
surcharge le réseau. Par conséquent, RLS est le plus coûteux entre les trois services
comparés. GLS a un mécanisme de maintenance beaucoup plus coûteux que celui
de HLS (+326% de paquets de mis à jour envoyés dans GLS par rapport à HLS).
Cela est dû au fait que la mise à jour de localisation dans GLS est globale pour
tous les serveurs dans le réseau. Cependant, elle est principalement locale dans HLS
à la cellule responsable du premier niveau. Cela conrme les résultats de l'étude
de l'extensibilité dans la section 11.1.1. En eet,
√ la borne supérieure du coût √ de la
maintenance de localisation dans GLS est O(v N ), alors qu'elle est de O(v log N )
pour HLS. Par conséquent, nous nous attendions à avoir plus de mises à jour dans
GLS que dans HLS, ce qui est le cas dans la Figure 11.3.(a). Donc, HLS réduit cette
surcharge de 70% par rapport à RLS et de 56% par rapport à GLS en moyenne.
1
Disponible sur : http://nsnam.isi.edu/nsnam/
2
Disponible sur : http://openstreetmap.fr/
3
Disponible sur : http://dsn.tm.uni-karlsruhe.de/english/Overhaul_NS-2.php/
11.2. Routage et Localisation Conjoints dans les Réseaux VANETs :
Nouvelles Approches 121
11% pour HLS, lorsque le nombre de n÷uds augmente de 50 à 400 n÷uds, alors
qu'il diminue de 23% pour GLS. Cela conrme le résultat de l'étude de la mise à
l'échelle théorique présentée dans la section 11.1.1, qui est le fait que HLS est plus
extensible que GLS.
On conclut donc que le mécanisme basé sur la hiérarchie dans les services de
localisation est mieux adapté que le mécanisme d'inondation aux larges réseaux
dynamiques. En plus de son extensibilité, HLS est plus rapide et plus performant
que GLS.

11.2 Routage et Localisation Conjoints dans les Réseaux


VANETs : Nouvelles Approches
11.2.1 L'Approche Hybride Simple
An de réduire les coûts de localisation et d'améliorer les performances du routage,
nous avons combiné les services de localisation GLS et HLS avec le protocole de
routage géographique GPSR, cela a donné deux approches notées Hybrid Routing
and Grid Location Service (HRGLS) et Hybrid Routing and Hierarchical Location
Service (HRHLS). Ensuite, nous avons comparé ces services de localisation (nombre
de requêtes de localisation envoyées, la bande passante consommée pour la localisa-
tion, etc.) avec et sans combinaison. De plus, nous avons comparé les performances
du routage (taux de livraison de paquets, la latence, nombre de sauts, etc.). Ces com-
binaisons sont évaluées par des expérimentations réalistes. Par ailleurs, les mêmes
mesures que dans la section 11.1.1 sont estimées ici pour les approches hybrides
(HRGLS et HRHLS).
Description de L'Approche Hybride Simple
Fondamentalement, les services de localisation GLS ou HLS, sont gérés séparément
du protocole du routage (i.e. GPSR). Cela signie que, si un n÷ud doit envoyer
des données à un autre n÷ud du réseau, GPSR demande au service de localisation
s'il possède une information fraîche sur l'emplacement de la destination. Si c'est
le cas, GPSR utilise cette position pour transmettre les paquets à la destination.
Autrement, le service de localisation lance une demande de localisation pour trouver
la nouvelle position de la destination. Lorsque la réponse de localisation est reçue, le
service de localisation informe GPSR, qui sera en mesure de transmettre les données
vers le n÷ud destination en utilisant la position reçue. Par opposition, l'approche
proposée repose essentiellement sur deux règles:
• L'ancienne position d'un n÷ud est utilisée pour envoyer les données même si
elle n'est pas assez fraîche: Si un n÷ud a une ancienne position de la destina-
tion, cette position est utilisée pour transmettre les données dès que possible.
• En s'approchant de l'ancienne position de la destination, une requête de lo-
calisation locale est envoyée pour récupérer la nouvelle position exacte.
122 Chapter 11. Résumé Partie II : Communication Inter-Véhicules

Coûts GLS

HLS√ HRGLS

HRHLS √
Maintenance O(v√ N ) O(v log

N ) O(v N ) O(v log N )
Requête O( N ) O( N ) O(log N ) O(log N )
Sauvegarde O(log N ) O(log N ) O(log N ) O(log N )

Table 11.2: Résumé de l'Etude de Scalabilité

An de mieux comprendre la diérence entre les approches hybrides et les ap-
proches orginelles, deux types de modèles de trac de requêtes peuvent être identi-
és: le premier modèle de est le trac localisé qui caractérise l'approche hybride et
le deuxième modèle de trac est le trac uniforme utilisé dans la section 11.1.1 qui
caractérise l'approche orginelle . En eet, dans l'approche orginelle, un n÷ud peut
interroger un autre n÷ud sur sa position, n'importe quand, n'importe où dans la
hiérarchie. Alors que dans l'approche hybride, la requête est exécutée uniquement
à l'arrivée dans la région de premier niveau au plus près de l'ancienne position.
Par conséquent, on peut considérer que le modèle de trac localisé dans l'approche
hybride (i.e. HRGLS et HRHLS).
A l'aide de ces tracs, on évalue les diérentes métriques pour HRGLS et
HRHLS. Le résultat est résumé dans la Table 11.2. Cette Table démontre que
l'approche hybride simple permet de diminuer le nombre de requêtes par rapport à
l'approche orginelle. En eet, la borne supérieure
√ du Coût des Requêtes de Local-
isation pour les approches hybrides est de N , alors qu'elle est de log N pour les
approches orginelles.
Avant de détailler les simulations des approches hybrides, nous nous sommes
intéressés aux paramètres de simulation à considérer. Probablement, le paramètre
le plus crucial et important à étudier est l'Age Maximal des Informations de Local-
isation dans le Cache (AMILC). Ce paramètre dénit la limite d'âge au cours de
laquelle les informations de localisation sont considérées comme fraîches et peuvent
être utilisées lors de l'acheminement des paquets. Au-delà, une demande de local-
isation est lancée pour connaître une position plus fraîche de la destination. En
d'autres termes, il dénit la fraîcheur de la position sauvegardée dans la mémoire
cache. Dans ce contexte, nous avons réalisé des expérimentations dans lesquels nous
avons fait varier l'AMILC. La conclusion à ces expérimentations est que cette valeur
ne devrait pas être supérieure à 12s, sinon il n'y a pas de diérences remarquables
entre les approches orginelles et hybrides car toutes les données utilisées seraient
assez anciennes. Par conséquent, l'AMILC a été xé à 8 s dans tout le reste des
expérimentations. Ce choix n'est pas seulement expérimentale, mais il est aussi
réaliste. En fait, 9 s susent pour un véhicule roulant à 100 km/h, pour faire 250
m, et donc quitter la portée de transmission (xée à 250 m).
11.2. Routage et Localisation Conjoints dans les Réseaux VANETs :
Nouvelles Approches 127
sont réduites en utilisant le mécanisme de prédiction de mobilité dans PHRHLS par
rapport à HRHLS, parce que l'estimation de la position future limite la distance
parcourue quand un paquet est réacheminé vers la position exacte après le lancement
d'une requête de localisation, au plus près de la destination.
En conséquence, la prédiction de mobilité n'a pas beaucoup d'incidence sur le
coût de la localisation, mais elle permet d'améliorer les performances du routage (le
TPD et la latence). Cela est dû au fait que les paquets sont transmis directement
vers la nouvelle position estimée. Cette estimation est calculée en utilisant une sim-
ple méthode d'extrapolation, mais qui s'avère susante dans notre cas d'utilisation.
Plusieurs autres modèles plus complexes de prédiction de mobilité (modèles stochas-
tiques, modèles basés sur l'historique, etc.) seront pris en compte dans les futurs
travaux.
Chapter 12

Conclusion and Future Work

Contents
12.1 Outlook of the Work . . . . . . . . . . . . . . . . . . . . . . . 129
12.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Communications within vehicles and inter-vehicular communications are chal-


lenging issues of modern transportation. In fact, the number of embedded devices
in vehicles is increasing continuously. These devices need to communicate and ex-
change data related to the status of the vehicle, the driver and the cargo. They are
not always compatible. Therefore, organizing and formalizing this communication
becomes a necessity due to the divergence of embedded devices.
In addition, Inter-Vehicular Communications are emerging. This is due to the
growing interest of the scientic community, governments and manufacturers for
such networks over the past years. This interest is mainly due to the ability of
these networks to replace conventional networks with infrastructure in case of a
natural disaster for example. Also, these networks are intended to enhance road
safety and improve the road trac eciency through cooperative mobility. Such
mobility is the biggest challenge for these networks, because vehicles move at a high
speed. This induces continuous network topology changes and short duration links.
These specic characteristics should be managed when data are forwarded between
vehicles.

12.1 Outlook of the Work


In this thesis, we were interested in Intra-Vehicle and Inter-Vehicle Communica-
tions. For Intra-vehicle communications, we have identied several embedded de-
vices. They were classied according to their functions and the data transfer direc-
tion. Communication between peripherals becomes increasingly complex. This is
due to the multiplication of interfaces, protocols and standards that are not always
compatible. To make services more customizable, they need to exchange informa-
tion. This exchange must be organized and not visible to the user who can take full
advantage from services (eet management, goods tracking, self-diagnostics, etc.)
through the end-to-end interoperability. We have also presented several interop-
erability interpretations. These interpretations converge in the idea that interop-
erability needs to ensure the way of data exchanging and to use shared data for
130 Chapter 12. Conclusion and Future Work

cooperative processing. Depending on the required degree of interaction, four levels


of interoperability are dened: the Machine level denes interfaces, the Syntactic
level species the exchanged data format, the Semantic level states that dierent
data must have the same meaning everywhere and the Organizational level describes
data processing.
In addition, we have presented a middleware architecture called Connect to
All (C2A), dened in layers, and able to satisfy the end-to-end interoperability. It
has been modelled as a set of several processes. These processes are synchronized via
event signals. The proposed model has been validated using two verication tech-
niques. The rst technique uses the model checker embedded into UPPAAL toolbox.
This tool is an integrated environment for modelling, validation and verication of
real-time communicating systems, modelled as extended nite state machines. Sev-
eral critical properties have thus been checked and validated. The second technique
is based on Specication and Description Language (SDL). This language is intended
to describe the system components behaviour in transitions between dierent states.
We have checked that the model operates as expected. Several scenarios have been
successfully achieved.
A concrete implementation of the validated model has been presented. This ap-
plication was carried out on a platform running over an embedded Linux optimized
in a memory footprint. This application supports a limited number of embedded
devices (Global Positioning System (GPS) module, General Packet Radio Service
(GPRS) module, Universal Serial Bus (USB) drive and Controller Area Network
(CAN) / Fleet Management System (FMS) simulator). It helped proving the fea-
sibility of the interoperability concept. Thus, these devices are recognized when
connected, and the system adapts its response behaviour according to new items.
Therefore, this system is open, ecient and scalable.
Inter-Vehicular Communications remain, despite all of the technological barriers,
very promising. The most important of these challenges is the managing of the high-
imposed mobility by vehicles in such networks. Routing protocols must consider
these features in order to be more powerful. Geographic routing protocols scale
better than the topology-based routing protocols. In fact, topology-based routing
protocols suer from a heavy discovery and maintenance phases, while geographic
routing protocols use the Greedy Forwarding Approach to transmit data gradually
closer and closer until reaching the destination. The destination position is provided
by distributed services called location-based services.
In this work, we present taxonomies of topology-based and geographic routing
protocols. We also detail some examples of routing protocols that use the mobility
prediction in inter-vehicular networks. Moreover, two comparisons of location-based
services have been investigated in this work. The rst one is based on scalability
properties. The second comparison uses experiments to evaluate on one hand the
extra localization cost and on the other hand the localization performances. The
results of these comparisons show that the Hierarchical Location Service (HLS) is
faster and more robust than the Grid Location Service (GLS) and the Reactive
Location Service (RLS).
12.2. Future Work 131

In the literature, geographic routing protocols are generally studied separately


from location-based services, even if they are linked in practice. We propose to
mix them in hybrid approaches. The simple hybrid approach consists of combining
geographic routing protocols and location-based services in order to address the
routing and localization issues simultaneously, and then to nd the best compromise
between the localization cost and routing performances. Data packets are forwarded
straight to the last known position of the destination, instead of launching requests
far away from destination and wait until replies travel the whole network. Once
we approach this position, a request is initiated close to the destination. When
the exact position is received, the routing protocol is notied and the packet can be
rerouted to this new position. Therefore, this mechanism avoids ooding the network
with location requests and responses and hence it reduces the network congestion.
Packets are transmitted as soon as possible, which reduces the end-to-end latency.
This simple approach has been applied to GLS and Hierarchical Location Service
(HLS) that provide Hybrid Routing and Grid Location Service (HRGLS) and Hybrid
Routing and Hierarchical Location Service (HRHLS). These hybrid services were
compared to those tted originally (i.e. GLS and HLS). The comparison has shown
that the hybrid approach has not only reduced the localization cost, but has also
increased the localization and routing performances.
The hybrid approach with mobility prediction is based on the simple hybrid
approach extended with an algorithm for estimating future positions that uses extra
information such as the speed and the direction of vehicles. The mobility eects can
be overcome with this prediction. The data packet is forwarded to the new estimated
position and no longer to the old position. This approach reduces the distance over
which the packet is rerouted. Several simulations have shown that this approach
has not aected the localization cost, but has increased the packet delivery rate and
has reduced latency.

12.2 Future Work


Based on the results we obtained in this work, signicant new research orientations
could be envisioned. The C2A application middleware should be improved. This
application must support more devices with various functions. Work is underway to
expand this list to involve an RFID reader, a webcam, an accelerometer, a Bluetooth
interface, etc. The core of the application remains unchanged, but it is enhanced
with other features. In addition, for more ease of use, we plan to add the possibility
of a remote conguration via a touch-pad equipped with a Bluetooth interface or a
web interface. Thus, the system is easier to use and to congure.
A rst improvement of the proposed simple hybrid approaches for routing and
localization (i.e. HRGLS and HRHLS) would be to return an acknowledgment
with an updated destination position straight to the source, when a data packet is
received. If the source has used an older position, it will then be updated with a
more accurate one when sending data to the same destination. For a better overhead
132 Chapter 12. Conclusion and Future Work

control, a single acknowledgment will be sent at the rst reception. Then, the return
of a new acknowledgment depends on the time interval between the receptions of
two packets. If this time is greater than the Location Cache Maximum Age (LCMA),
an acknowledgment will be transmitted.
The hybrid approach with mobility prediction is currently being applied to GLS,
as it was done for HLS within this thesis. This approach called Predictive Hybrid
Routing and Grid Location Service (PHRGLS) will be compared to HRGLS and GLS
in experiments similar to those performed to compare Predictive Hybrid Routing
and Hierarchical Location Service (PHRHLS), HRHLS and HLS.
The new position estimation procedure used in the hybrid approach with mo-
bility prediction is based on an extrapolation of the current node position using the
velocity and the movement angle. Several other mobility prediction models could
be considered. Among these models we can mention: Deterministic models (rst
order, second order, etc.), Stochastic models (based on the validity probability of
a deterministic prediction, based on Kalman lters, Markov models, etc.), models
based on History or models based on Neural Networks. A comparative study of these
prediction models will be performed. Based on this comparison, one of these models
will be integrated into the simple hybrid approach to compare the localization and
routing performances.
Besides, a more global comparison of various location-based services combined
with other geographic routing protocols (Geographic Source Routing (GSR), im-
proved Greedy Trac Aware Routing (GyTAR), etc.) and topology-based routing
protocols (Dynamic Source Routing (DSR), Ad hoc On Demand Distance Vector
(AODV), Temporally Ordered Routing Algorithm (TORA), etc.) will be considered.
This comparison will highlight the advantages and drawbacks of location-based ser-
vices and routing protocols in more realistic urban and highway scenarios based on
the localization and routing overhead and performances.
Finally, real experimentations are planned. A scenario including three vehicles
equipped with Institute of Electrical and Electronics Engineers (IEEE) 802.11p com-
munication modules and a Roadside Unit will be used in these experimentations.
The routing protocol Greedy Perimeter Stateless Routing (GPSR), location-based
services (i.e. HLS, GLS, HRHLS, HRGLS, PHRHLS and PHRGLS) will be im-
plemented on these routers. The purpose of these experiments is to evaluate the
performances of these services in a real trac. Then, we will expand the number of
participating vehicles to compare the scalability of these location-based services.
Chapter 13

Conclusion et Travaux Futures

Contents
13.1 Travaux de Thèse . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.2 Travaux Futures . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Les communications au sein du véhicule ainsi que les communications inter véhic-
ulaires sont des problématiques du transport moderne. En eet, il existe de plus
en plus d'équipements embarqués dans les véhicules. Ces périphériques ont besoin
de communiquer et d'échanger des données correspondant à l'état du véhicule, du
chaueur ou de la marchandise transportée. Ces périphériques ne sont pas tou-
jours compatibles. Alors, organiser et formaliser cette communication devient une
nécessité du fait de la divergence des périphériques embarqués.
De plus, les communications inter-véhiculaires sont en pleine émergence. Ceci
est dû à l'intérêt croissant par la communauté scientique, les gouvernements et
les industriels pour ce type de réseaux durant ces dernières années. Cet intérêt
revient principalement à la capacité de ces réseaux à remplacer des réseaux classiques
avec des infrastructures en cas de catastrophe naturelle par exemple. Aussi, ces
réseaux ont pour but de renforcer la sécurité routière et d'améliorer l'ecacité du
trac routier grâce à la mobilité coopérative. Cette mobilité constitue le plus grand
challenge dans ces réseaux. En eet, les véhicules se déplacent à haute vitesse. Ce
qui induit un changement continu de la topologie de ces réseaux et des liens de
courte durée. Ces caractéristiques spéciques doivent être prises en compte quand
les données sont transmises entre les véhicules.

13.1 Travaux de Thèse


Dans ces travaux de thèse, on s'est intéressé aux communications Intra-Véhicule
et Inter-Véhicules. En ce qui concerne les communications Intra-Véhicule, nous
avons identié plusieurs équipements embarqués. Ces derniers ont été classés suivant
leurs fonctions ainsi que le sens de transfert des données qui transitent via ces
équipements. La communication entre les diérents périphériques devient de plus
en plus complexe. Ceci est dû à la multiplication des interfaces, des protocoles
ainsi que des standards qui ne sont pas toujours compatibles. An de rendre des
services de plus en plus personnalisés à l'utilisateur, ils ont ainsi besoin d'échanger
des informations utiles. Cet échange doit être organisé et transparent à l'utilisateur
134 Chapter 13. Conclusion et Travaux Futures

qui pourrait proter pleinement des services complets (gestion de ottes, suivi de
marchandise, auto-diagnostique, etc.) grâce à l'interopérabilité de bout-en-bout.
Nous avons aussi présenté les diérentes interprétations relatives à l'interopérabilité.
Ces interprétations se rejoignent dans la nécessité de garantir le moyen d'échanger
des données et de les utiliser à des ns de traitements collaboratifs. Suivant le
degré d'interaction souhaité, quatre niveaux de l'interopérabilité sont dénis : le
niveau Machine dénit les interfaces, le niveau Syntaxique précise le format des
données échangées, le niveau Sémantique indique que les diérentes données doivent
avoir la même signication partout et le niveau Organisationnel décrit les diérents
traitements qui peuvent être appliqués à une donnée.
De plus, nous avons présenté une architecture logicielle, notée Connect to All
(C2A), capable de satisfaire l'interopérabilité de bout-en-bout. Cette architecture
est dénie en étages. Nous avons proposé une modélisation de cette dernière sous
forme plusieurs processus. Ces processus sont synchronisés à l'aide de signaux évène-
mentiels. Le modèle proposé a été validé à l'aide de deux techniques de vérication.
La première technique est une méthode de vérication formelle qui utilise l'outil UP-
PAAL. Cet outil est un environnement intégré pour la modélisation, la validation
et la vérication des systèmes de communication temps-réel, modélisés sous forme
de machine à états nis étendue. Plusieurs propriétés critiques ont pu ainsi être
vériées et validées. La deuxième technique est basée sur Langage de Description et
de Spécication (LDS). Ce langage a pour but de décrire le comportement des com-
posants d'un système en transitions entre diérentes états. Nous avons pu vérié le
fonctionnement du modèle. Plusieurs tests ont été réalisés avec succès.
Une implémentation d'une réelle application du modèle validé a été suggérée.
Cette application a été réalisée sur une plateforme embarqué basée sur un Linux
embarqué optimisé en empreinte mémoire. Cette application gère un nombre lim-
ité de périphériques embarqués (module Global Positioning System (GPS), module
General Packet Radio Service (GPRS), Clé Universal Serial Bus (USB) et simulateur
Controller Area Network (CAN) / Fleet Management System (FMS)). Elle a per-
mis de prouver la faisabilité du concept d'interopérabilité. Ainsi, ces périphériques
sont reconnus dès la connexion à chaud et le système s'adapte suite à ses nouveaux
éléments. Le système peut-être aussi personnalisé à posteriori par l'utilisateur. Ce
système est donc ouvert, performant et évolutif.
Les communications Inter-Véhicules restent, malgré tous les verrous technologi-
ques, très prometteuses. Le plus important de ces challenges reste la maîtrise de
la haute mobilité imposée par les véhicules qui composent de tels réseaux. Les
protocoles de routage doivent prendre en compte ces caractéristiques an d'être
performants. Les protocoles de routage géographiques sont ainsi mieux adaptés
que ceux topologiques grâce à leur meilleure mise à l'échelle. En eet, les proto-
coles de routage topologiques sourent d'une phase de découverte et de mainte-
nance des chemins assez lourdes, alors que les protocoles de routage géographiques
utilisent l'approche gloutonne pour transmettre les données graduellement de proche
en proche jusqu'à atteindre la destination. Pour cela, ces protocoles nécessitent la
position géographique de la destination. Cette dernière est obtenue grâce à des
13.1. Travaux de Thèse 135

services distribués appelés services de localisation.


Dans ces travaux, nous avons présenté une taxinomie des protocoles de routage
topologiques ainsi que géographiques qui sont utilisés dans les réseaux Inter-Véhicu-
laires. De plus, une classication des services de localisation est proposée. Nous
avons détaillé aussi quelques exemples de routage utilisant la prédiction de mobilité
dans les réseaux Inter-Véhiculaires.
En plus, Deux comparaisons des principaux services de localisation ont été
étudiées dans ces travaux. La première est basée sur les propriétés d'extensibilité.
La deuxième comparaison a recours à des expérimentations an d'évaluer d'un côté
le surcoût lié à la localisation et de l'autre côté les performances de la localisation.
Le résultat de ces comparaisons prouve que le service Hierarchical Location Service
(HLS) est plus rapide et plus robuste que les services Grid Location Service (GLS)
et Reactive Location Service (RLS).
Dans la littérature, les protocoles de routage géographiques sont généralement
étudiés séparément des services de localisation même s'ils sont liés en pratique.
Alors, nous avons proposé de les mixer dans des approches hybrides. L'approche
hybride simple consiste à fusionner les protocoles de routage géographiques et les
services de localisation an de prendre en compte les problématiques de routage et
de localisation simultanément, et par la suite de trouver le meilleur compromis entre
le coût de la localisation et les performances du routage. Ainsi, au lieu de lancer des
requêtes loin de la destination et attendre que les réponses traversent tout le réseau,
les paquets de données sont transmis directement vers la dernière position connue de
la destination. Une fois que l'on s'approche de cette position, une requête est initiée
au plus près de la destination. Quand la position exacte est reçue, le protocole de
routage est notié et le paquet peut être dérouter vers la nouvelle position. Par
conséquent, on évite l'inondation du réseau avec des requêtes et des réponses de
localisation et donc la congestion du réseau. Les paquets sont transmis au plus tôt
ce qui réduit les latences de bout-en-bout. Cette approche simple a été appliquée
à GLS et Hierarchical Location Service (HLS) pour donner Hybrid Routing and
Grid Location Service (Hybrid Routing and Grid Location Service (HRGLS)) et
Hybrid Routing and Hierarchical Location Service (HRHLS). Ces services hybrides
ont été comparés à ceux d'origine (GLS et HLS). La comparaison a démontré que
l'approche hybride ne permettait pas que de réduire les coûts de la localisation, mais
elle permettait aussi d'augmenter les performances de localisation et de routage.
Quant à l'approche hybride avec prédiction de mobilité, elle est basée sur l'appro-
che hybride simple avec comme extension un algorithme d'estimation des positions
futures d'un n÷ud grâce à des informations supplémentaires telles que la vitesse et la
direction. Les eets de la mobilité peuvent ainsi être maîtrisés avec cette prédiction.
En eet, le paquet de donnée est envoyé à la nouvelle position estimée et non plus
à l'ancienne position. Ceci permet de réduire la distance sur laquelle le paquet est
dérouté. Plusieurs simulations ont prouvé que l'approche hybride avec prédiction de
mobilité n'aectait pas les coûts de la localisation, mais elle permettait d'augmenter
le taux des paquets délivrés et de réduire les latences.
136 Chapter 13. Conclusion et Travaux Futures

13.2 Travaux Futures


Suite aux travaux eectués dans cette thèse, plusieurs pistes d'améliorations peu-
vent être envisagées. Premièrement, l'implémentation du système C2A doit-être
améliorée. En eet, cette application doit prendre en charge encore plus de pé-
riphériques avec des fonctions diverses. Des travaux sont en cours an d'élargir cette
liste qui comporterait en plus un lecteur RFID, une Webcam, un accéléromètre, une
interface Bluetooth, etc. Le noyau de l'application reste le même, mais il est enrichi
avec d'autres fonctions. De plus, pour une meilleure facilité d'utilisation, nous avons
prévu de rajouter la possibilité d'une conguration à distance via une tablette tactile
munie d'une interface Bluetooth ou une interface Web accessible depuis l'extérieur.
Ainsi, le système est plus évolué et plus simple à congurer.
Concernant les approches hybrides simples pour le routage et la localisation
proposées (HRGLS et HRHLS), une première piste d'amélioration serait de renvoyer
un acquittement vers la source une fois qu'un paquet de données est reçu. En eet,
lorsqu'une destination reçoit un paquet elle enverrait un acquittement contenant une
mis à jour de sa position directement à la source. Donc, si la source a utilisé une
ancienne position, elle aura ensuite une position plus exacte pour le renvoi d'autres
données vers la même destination. Pour moins de gaspillage, un seul acquittement
sera envoyé lors d'une première réception. Puis, le renvoi d'un nouvel acquittement
sera conditionné par la durée qui sépare la réception de deux paquets de données.
Si cette durée est supérieure à l'Age Maximal des Informations de Localisation dans
le Cache (AMILC), un renvoi sera eectué.
Actuellement, l'approche hybride avec prédiction de mobilité est en train d'être
appliquée à GLS comme cela a été fait pour HLS dans le cadre de cette thèse.
Cette approche dénommée Predictive Hybrid Routing and Grid Location Service
(PHRGLS), sera comparée à HRGLS et GLS dans des expérimentations similaires à
celles réalisées pour comparer Predictive Hybrid Routing and Hierarchical Location
Service (PHRHLS), HRHLS et HLS.
L'estimation de la position utilisée dans l'approche hybride avec prédiction de
mobilité est basée sur une extrapolation de la position actuelle en utilisant la vitesse
et l'angle du mouvement du n÷ud. Plusieurs autres modèles de prédiction de mo-
bilité peuvent être considérés. Parmi ces modèles on peut citer les modèles déter-
ministes (premier ordre ou second ordre), les modèles stochastiques (basés sur la
probabilité de validité d'une prédiction déterministe ou sur les ltres de Kalman
ou sur les modèles Markoviens), les modèles basés sur l'historique ou les modèles
basés sur des réseaux de neurones. Une étude comparative des diérents modèles
de prédiction sera réalisée. A la lumière du résultat de cette comparaison, un des
modèles sera intégré à l'approche hybride simple an de comparer les performances
de la localisation et du routage.
En outre, une comparaison plus globale des diérents services de localisation pro-
posés combinés à d'autres protocoles de routage géographiques (Geographic Source
Routing (GSR), improved Greedy Trac Aware Routing (GyTAR), etc.) ainsi
que des protocoles de routage topologiques (Dynamic Source Routing (DSR), Ad
13.2. Travaux Futures 137

hoc On Demand Distance Vector (AODV), Temporally Ordered Routing Algorithm


(TORA), etc.) est envisagée. Cette comparaison devrait mettre en relief les avan-
tages et les inconvénients des services de localisation et des protocoles de routage
dans des scénarios urbains et interurbains plus réalistes par rapport aux ressources
nécessaires ainsi que les performances relatives à la localisation et au routage.
Finalement, des expérimentations réelles sont envisagées. En eet, un scénario,
incluant trois véhicules équipés de modules de communication Institute of Electrical
and Electronics Engineers (IEEE) 802.11p avec une borne de bord de route, sera
utilisé lors dans ces expérimentations. Le protocole de routage Greedy Perimeter
Stateless Routing (GPSR), les services de localisation HLS, GLS, HRGLS, HRHLS,
PHRHLS et PHRGLS seront implémentés sur ces routeurs. Le but est d'évaluer
les performances de ces diérents services dans des situations réelles de circulation.
Ensuite, on élargira le nombre de véhicules participant pour comparer la meilleure
mise à l'échelle de ces diérents services de localisation.
Appendix A

C2A Project Outline

Contents
A.1 C2A Project Overview . . . . . . . . . . . . . . . . . . . . . . 139
A.1.1 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A.1.2 Project Results . . . . . . . . . . . . . . . . . . . . . . . . . . 140
A.1.3 Added Value of C2A . . . . . . . . . . . . . . . . . . . . . . . 140
A.2 Project Partners . . . . . . . . . . . . . . . . . . . . . . . . . . 141
A.3 Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

A.1 C2A Project Overview


Approved with a budget of 1,175 Ke, Connect to All (C2A) project aims to design,
develop and implement an intelligent interconnection system between embedded
hybrid equipments in the transport vehicles. The project goal is to optimize and
extend embedded resources usage which will allow for the composition of new inno-
vative services. C2A is a CBC project (Cross Border Cooperation between France
and Wallonia) of the European Interreg IV-A program. The Factsheet of the C2A
project is presented on Table A.1.

A.1.1 Project Goals


Various embedded equipments are becoming more and more numerous inside trans-
port vehicles. Apart from mandatory devices such as the digital tachograph, dif-
ferent other equipments are available such as radio communication systems (Global

Project Name Connect To All (C2A)


Website http://www.c2a-project.eu
Projet type Interreg IV-A France-Wallonie-Vlaanderen
Budget 1,175 Ke
Duration from 01/09/2008 to 31/12/2012
Table A.1: C2A Factsheet
140 Appendix A. C2A Project Outline

System for Mobile (GSM) / General Packet Radio Service (GPRS) module), locali-
sation devices (Global Positioning System (GPS) module), and a variety of miscel-
laneous tools and equipments for specic needs (data loggers, PC tablet, cameras,
mobile phones, On-board computers, etc.). However, in practice there is a sub op-
timal and reduced exploitation of theses technologies due to selective and closed
hardware and software interfaces. Usually equipments have very limited sharing of
their hardware resources (communication interfaces, embedded sensors, etc.) with
each others. This results in services duplication, void redundancy of system features
and sub-optimal utilization of available hardware and software resources.
To address this problem and allow rationalization of investments, C2A project
aims to develop a generic technology for interoperability (intelligent communicating
bus ) allowing communication and resource sharing between embedded devices in the
vehicle.
A.1.2 Project Results
Two Proof-Of-Concept prototypes were developed in 2010. A second generation
demonstrator was implemented in 2011/2012 and showed at the International Trans-
port Fair SITL in Paris in march 2012. The demonstrator illustrates the hot plug of
peripherals and the seamless activation of application services based on the available
data. Several application scenarios for C2A were illustrated with the demonstrator
such as goods transport, emergency transport and school transportation manage-
ment.
For the later for example, the following peripherals were connected to the C2A
box: a GPS module for localization, a RFID tag reader and a GSM / GPRS modem
providing internet connectivity. Each pupil has its own tag. All events (getting in
or out of the school bus) are registered, tagged with GPS position and time stamp
and uploaded to a remote server. On the remote server the availability of real time
information about busses and pupils allows the development of valuable services
such as:
• Conguring and monitoring that all pupils who are intended to take the bus
at a bus station have really took it
• Generating real time alerts (towards driver, parents or school) when a pupil
is missing or doesn't leave the bus at the pre-congured stop
• Developing statistics on the school buses lling rates, usage and itineraries
allowing to plan optimizations
The current C2A platform is highly exible and allows the development of cus-
tomized services depending on the user needs.
A.1.3 Added Value of C2A
C2A is a technological innovation which will enable optimized use of existing equip-
ments inside transport vehicles. The Information and Communication Technologies
A.2. Project Partners 141

(ICT) companies can develop new features and services by interfacing their solutions
to the C2A system and accessing an extended data set. They could also implement
their own services on top of C2A architecture or even integrate the C2A building
blocks into their own solutions. Companies and operators of transport and logistics
eld can deploy these new services and benet from a exible system well tailored
to their needs but also easily adaptable and extensible.

A.2 Project Partners


The C2A project was initiated between:
• Subsidized partners:
 CReSTIC - University of Reims Champagne-Ardenne - Reims
 CETIC - Centre d'Excellence en Technologies de l'Information et de la
Communication - Charleroi
 Carinna - Agence de soutien à la recherche et l'innovation en Champagne-
Ardenne - Reims
 INFOPOLE - Cluster TIC - Namur
• Associated partners:
 Monnier Borsu Sotradel - Charleville Mézières
 Docledge - Isnes
 Smolinfo - Purnode
 Le Forem - Oce Wallon de la Formation professionnelle et de l'Emploi
Charleroi
 Gunnebo - Bazancourt
 NeXXtep Technologies - Reims

A.3 Contacts
For more (general or technical) details on the project you may contact:
• Lissan Alal - University of Reims Champagne-Ardenne / CReSTIC - Project
Coordinator
 Mail : lissan.alal@univ-reims.fr
 Tel : +33-3-26-91-32-48
• Lot Guedria - CETIC
 Mail : lot.guedria@cetic.be
142 Appendix A. C2A Project Outline

 Tel : +32-71-490-732
• Fréderic Jourdain / Michel Black - INFOPOLE Cluster TIC
 Mail : infopole@infopole.be
 Tel : +32-81-72-51-45
• Amina Belkhir - CARINNA
 Mail : amina.belkhir@carinna.fr
 Tel : +33-3-25-71-84-59
Appendix B

NS-2 Simulations Procedure


Descriptions

Contents
B.1 Hardware Environment . . . . . . . . . . . . . . . . . . . . . . 143
B.1.1 Hardware Developing Environment . . . . . . . . . . . . . . . 143
B.1.2 Hardware Execution Environment . . . . . . . . . . . . . . . 143
B.2 Software Environment . . . . . . . . . . . . . . . . . . . . . . 144
B.2.1 Generation of Vehicles Movement . . . . . . . . . . . . . . . . 144
Producing a concrete map of the city of Reims . . . . . . . . 145
Creating Mobility Pattern . . . . . . . . . . . . . . . . . . . . 145
B.2.2 Generation of Network Trac . . . . . . . . . . . . . . . . . . 147
Launching Test Queries . . . . . . . . . . . . . . . . . . . . . 147
Sending CBR Packets . . . . . . . . . . . . . . . . . . . . . . 148
B.2.3 NS-2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 149
B.2.4 Traces Evaluations . . . . . . . . . . . . . . . . . . . . . . . . 150
B.2.5 NS-2 Execution in the ROMEO Supercomputer . . . . . . . . 151

This Appendix describes the required steps to achieve simulations over the Net-
work Simulator 2 (NS-2).

B.1 Hardware Environment


B.1.1 Hardware Developing Environment
To implement our hybrid approach we used an Ubuntu distribution. This distribu-
tion runs as a virtual machine over a Macintosh machine described in Table B.1.
B.1.2 Hardware Execution Environment
The developed code was executed in the supercomputer ROMEO. The ROMEO
Computing Center is a High Performance Computing (HPC) platform hosted by
the "Université de Reims Champagne-Ardenne" which has been supported by the
"Région Champagne-Ardenne" since 2002. Its hardware specications are:
144 Appendix B. NS-2 Simulations Procedure Descriptions

• Linux cluster with 100 Itanium cores (commissioned in 2006). This machine
has 8 nodes with up to 32 cores and 128 GB RAM each.
• Linux/Windows cluster (commissioned in 2010 by Bull SAS in partnership
with Microsoft Corp.) This machine has 42 servers with a total of 500 cores:
 36 nodes with 12 cores and 24 GB RAM
 one node with 32 cores and 64 GB RAM
 one node with two Fermi GPUs (NVIDIA Tesla C2050)
 one node with a powerful GPU allowing remote modeling and visualiza-
tion of simulations results
 15 TB secure storage space
 Linux/Windows job scheduler
 energy ecient air conditioning system (free-cooling)

Hardware Description
Machine Type iMac
Processor 3,06 GHz Intel Core i3
Graphic board ATI Radeon HD 4670 256 MB
OS OS X Lion 10.7.4 (11E53)
Hard disk 500 Go
RAM 4 Go
Screen resolution 21,5 in (1920 x 1080)
Integrated Development Qt Creator 1.3.1
Environment (IDE) based on Qt 4.6.2
Table B.1: Hardware Developing Environment

More precisely, we executed our NS-2 code over the Clovis Machine. Its features
are described in Table B.2. This machine is controlled via secure ssh connection.

B.2 Software Environment


B.2.1 Generation of Vehicles Movement
The vehicles movement was generated using the Citymob for Roadmaps (C4R) tool1
[60] developed at the Networking Research Group (GRC) of to the Technical Univer-
sity of Valencia (UPV). C4R is a mobility generator for Vehicular Ad-hoc NETworks
(VANETs). It allows simulating trac in dierent locations using real maps. It uses
Simulation of Urban MObility (SUMO) tool2 [61, 62] to create mobility traces based
on real maps extracted from OpenStreetMap Plateform3 . This tool can generate
1
Available on: http://www.grc.upv.es/Software/c4r.html/
2
Available on: http://sumo.sourceforge.net/
3
Available on: http://openstreetmap.fr/
B.2. Software Environment 145

Hardware Description
Machine Name Clovis
URL Address clovis.univ-reims.fr
Installation Date August 2010
Computing Power 6 TFlops
Energy Consumption 27 KW
42 nodes with 12 cores Westmere / 24 GB DDR3
42 nodes with 12 cores Westmere / 24 GB DDR3
Computing nodes 1 node with 32 cores Nehalem / 64 GB DDR3
1 node with 32 cores Westmere / 24GB DDR3
2 Fermi C2050 GPU
Interconnection network Inniband network QDR of 40 Gb/s
Data A disk array provides 24 TB of raw data
Administrative node
Linux login node
Service nodes Windows login node
Storage management node
Visualization node
Free-Cooling
Two air conditioning units circuit are used
for cooling with cold water at 14
Table B.2: Hardware Execution Environment

random routes or create routes dened by users. In addition, it is possible to add


attraction points. This software creates movement trace les and allows visualizing
these movements. We should notice that the generated traces are compatible with
NS-2 (i.e. vehicles movement les can be exported to TCL format).
Producing a concrete map of the city of Reims
The extracted map is shown in Figure B.1. We followed these two steps to extract
this map:
• In the rst step, we need to specify to the C4R tool the SUMO installation path
and the OpenStreetMap API URL (such as "http://api.openstreetmap.org/api/
0.6/map?bbox=").
• In the second step, we select the map using the OpenStreetMap API. The size
of the downloaded map should not be bigger than 2 km2 . The map is then
translated to a compatible format for SUMO.
Creating Mobility Pattern
On the map, we have added randomly 100 vehicles and we have dened the rate of
the located vehicles in the downtown area. We have setup the departure time of the
146 Appendix B. NS-2 Simulations Procedure Descriptions

Figure B.1: C4R: Citymob for Roadmaps tool

vehicles monument in the simulation. Then, the trace is generated in NS-2 format
by dening the end simulation time. Many dierent traces can be generated at once.
These traces could be visualized over the map loaded in SUMO as the Figure B.2
shows.

Figure B.2: SUMO: Simulation of Urban MObility tool

A part of a TCL mobility vehicle le example is described below. First, the
B.2. Software Environment 147

original position of each node is dened using the set function. It is used to randomly
specify three axis coordinates. Then, at each second the setdest function is called
to change these coordinates. The pattern of the function is:
"$ns_ at T ”$node_(N ) setdest X Y V ”", where T is the time, N is the node ID,
X and Y are coordinates and V is the velocity used.

#
# This file was parsed with Citymob for Roadmaps (C4R) version 1.0
#
#Node 0 = random_undefined_0_0
$node_(0) set X_ 431.3
$node_(0) set Y_ 189.88
$node_(0) set Z_ 0.0
.
.
.
#Path $node_(0) = random_undefined_0_0
$ns_ at 0.0 "$node_(0) setdest 432.9296736 191.07355098206 2.019999999"
.
.
.
$ns_ at 79.0 "$node_(99) setdest 93.94257816 425.0953076 0.0"

B.2.2 Generation of Network Trac


The network trac is generated using the "./trafgen " executable4 . It allows creating
dierent kinds of network traces. The usage of this executable is as follow:
./trafgen -n <nodes> -a <active nodes>
-t <simulation time> -c <connections>
-m <mode: 0-query 1-cbr(old) 2-cbr(new)
3-tcp(ftp) 4-ping 5-ping(memopt)>
[-w <startup-wait time>]
[-i <inverted timescale [1/0]>]
[-r <send rate>] [-s <pkt size>]
[-p <packets>] [-o <tcp window>]

Launching Test Queries


A test query is a node looking for the location of another one. If the node has a
fresh position, the location cache is used. Otherwise, a location request is sent to
catch a new position. An example using the "./trafgen " executable to generate test
queries can be obtained by executing this command:
4
Available on: http://www.cn.uni-duesseldorf.de/alumni/kiess/software/hls-ns2-
patch/scen_trafgen.tar.gz/
148 Appendix B. NS-2 Simulations Procedure Descriptions

"./traf gen − n 100 − a 100 − t 105 − c 4 − m 0 − w 15 > QueriesT ests.tcl".


The output le "QueriesT ests.tcl" will be as follow:
#
# nodes: 100, max conn: 4, send rate: 0.100000, seed: 1, active nodes: 100
#

$ns_ at 15.157052578469 "[$node_(65) set ragent_] test-query 5"


$ns_ at 15.161809181396 "[$node_(51) set ragent_] test-query 86"
.
.
.
$ns_ at 97.842091824604 "[$node_(26) set ragent_] test-query 12"
$ns_ at 97.924068041390 "[$node_(33) set ragent_] test-query 80"

In this example, each vehicle (among the 100 ones) launches test queries for 4
other nodes. The test-query function works like the setdest one. This means that it
is used as follow:
"$ns_ at T ”[$node_(S) set ragent_] test − query D”", where T is the time,S
is the source of the test query and D is the destination node. For example, the
rst command means that the node 65 launches a test query at 15.157052578469s
to retrieve the position of the node 5.
Sending CBR Packets
The Constant Bit Rate (CBR) trac can be generated using this command:
"./traf gen −n 100 −a 100 −t 100 −c 4 −m 2 −w 2 −i 1 −r 1 −s 128 −p 100 >
CBRT raf f ic.tcl".
The output le "CBRT raf f ic.tcl" appears like:
#
# nodes: 100, max conn: 4, send rate: 1.000000, seed: 1, active nodes: 100
#

#
# 99.986179128699 7 -> 37
#
set udp_(143) [new Agent/UDP]
$ns_ attach-agent $node_(7) $udp_(143)
set null_(143) [new Agent/Null]
$ns_ attach-agent $node_(37) $null_(143)
set cbr_(143) [new Application/Traffic/CBR]
$cbr_(143) set packetSize_ 128
$cbr_(143) set interval_ 1.000000
$cbr_(143) set random_ 0
B.2. Software Environment 149

$cbr_(143) set maxpkts_ 100


$cbr_(143) attach-agent $udp_(143)
$ns_ connect $udp_(143) $null_(143)
$ns_ at 99.9861791286985806 "$cbr_(143) start"

In this example, the node 7 launches an UDP agent 143 responsible of sending
CBR packets to the node 37 at 99.986179128699 s. The packets sized 128 Bytes
are sent every second for 100 times. This trac aims to simulate audio or video
streaming or an Internet connection via an infrastructure.
B.2.3 NS-2 Execution
The execution of the NS-2 simulation is done with the run.tcl script5 provided with
the HLS patch. This script can be used with these options:
Usage: ns run.tcl -out tracefile

NS Options:
-nn [number of nodes]
-stop [simulation duration in secs]
-x / -y [dimension in meters]
-adhocRouting [routing protocol to use]
-use_gk [radius for gridkeeper usage]
-zip [(0/1) should tracefiles be zipped on-the-fly]
-cc [alpha for congestion control ((MAC802_11 only)]
-ifqlen [max packets in interface queue]

File Options:
-cp [traffic pattern]
-sc [scenario file]
-nam [nam tracefile]
-on_off [wake/sleep pattern]
-lt [load trace file (MAC802_11 only)]
-pingLog [log file for ping statistics (Ping Traffic only)]

MAC Options:
-rr [radio range in meters]
-bw [link/dataRate bandwidth in bits/sec]
-bs [basicRate bandwidth in bits/sec]

GPSR Options:
-bint [beacon interval (and beacon expiry)]
-use_planar [(0/1) planarize graph]
5
Available on: http://www.cn.uni-duesseldorf.de/alumni/kiess/software/hls-ns2-patch/
150 Appendix B. NS-2 Simulations Procedure Descriptions

-use_peri [(0/1) use perimeter mode]


-use_mac [(0/1) use mac callback]
-verbose [(0/1) be verbose]
-use_beacon [(0/1) use beacons at all (disable beacons with 0)]
-use_reactive [(0/1) use reactive beaconing]
-locs [locservice to use (0-Omni/1-RLS/2-GLS/3-HLS)]
-use_loop [(0/1) use loop detection]

-ed [topology file (edges)]


-ve [topology file (verteces)]

An example of this command could be:


ns run.tcl -out hls_trace.tr -nam hls_namtrace.nam
-sc Movement.tcl -cp CBRTraffic.tcl -nn 100 -locs 3
-use_peri 1 -x 2000 -y 2000 -mac_emu 0 -stop 300 -zip 0

B.2.4 Traces Evaluations


There are two generated les in the NS-2 simulations: the output trace "hls_trace.tr "
and the trace "hls_namtrace.nam ". The nam trace is used with the Network AN-
imator (NAM) tool (Figure B.3) provided with NS-2 to visualize the simulation.
The execution of this tool is launched by:
nam hls_namtrace.nam &

The script evaluate.pl 6 , provided with the HLS patch, extracts from the output
le "hls_trace.tr " a lot of localization statistics. It can be used like follow:
./evaluate.pl -f hls_trace.tr > hls_results.txt

The script computes the number of location queries, cache lookups, sent requests,
received replies, dropped requests, dropped replies, handovers, etc. It also gives
a lot of packet delivery statics such as the number of sent, forwarded, received or
dropped packets. Besides, it estimates the consumed bandwidths by the routing and
MAC layers. The script has been extended to evaluate more routing performances
parameters like the Packet Delivery Rate (PDR), the average end-to-end latency
and the average number of hops for CBR packets.
The line below is extracted from the NS-2 output le "hls_trace.tr ". The rst
letter of the line species the packet type (s: for sent, r: for received, f: for forwarded,
and D: for dropped). So, the packet in this example is a sent one. The second eld
represents the event date. The third one is the node where the event occured.
Then, the fourth eld describes the layer (here in this example: the application
layer AGT). The fth one is a ag to dene the drop reason (here the packet is non
6
Available on: http://www.cn.uni-duesseldorf.de/alumni/kiess/software/hls-ns2-patch/
B.2. Software Environment 151

Figure B.3: NAM: Network ANimator tool

dropped). The packet ID follows and it is 540 here. The protocol used is the CBR
one. The packet size is 128 B. Then the four numbers between brackets are relied to
Media Access Control (MAC) addresses (the packet duration in MAC layer header,
the MAC address of the destination, the MAC address of the source and the MAC
type of the packet body). The other ones are the source node ip and the source port
number (1:0), the destination node ip (-1 means broadcast) and the destination port
number (45:0), the ip header ttl (32) and the ip of the next hop (0 means node 0 or
broadcast).
s 5.000341235 _1_ AGT --- 540 cbr 128 [0 0 0 0] ------- [1:0 45:0 32 0]

Therefore, this line structure is used to compute the number of sent and received
packets, and hence the PDR. Moreover, the average end-to-end latency and the
average number of hops are calculated in the same way.
B.2.5 NS-2 Execution in the ROMEO Supercomputer
When executing the NS-2 code in the Clovis Machine, the rst action to do is to
connect to this distant machine via ssh connection. Then, the developed code is
copied in the Clovis Machine. We have also to specify the NS-2 variables and to
format the job to execute for example "Exec.sh ". We are now able to submit the
formatted job "Exec.sh " using qsub command.
ssh ayaida@clovis.univ-reims.fr
scp -r /Source/ ayaida@clovis.univ-reims.fr:/home/ayaida/...
152 Appendix B. NS-2 Simulations Procedure Descriptions

source /apps/ns2/ns2.33_vars.sh
qsub Exec.sh

An example of formatted job "Exec.sh " is described in Algorithm 4. This al-


gorithms is executed one time on the Clovis Machine. It allow us to increase the
number of nodes up to 400 nodes. Also, we were able to repeat the simulations 10
times and the results are averaged over all these simulations to have more accurate
results. In addition, the qstat command is used to follow the submitted job and in
progress ones in the Clovis Machine.
Algorithm 4 Example of Formatted Job "Exec.sh"
1: #!/bin/bash
2: Dening of needed resources
3: Sending Mail when job nished
4: echo "Simulations Start"
5: Setup Variables
6: for i < 10 do ## Number of Simulations
7: for j in 20 40 50 60 80 100 120 do ## Number of Nodes
8: echo "Start of HLS Simulation $i with $j nodes"
9: Executing ./trafgen to generate new Mobility Pattern
10: Running ns with HLS + GPSR
11: HLS Trace Evaluation
12: echo "Start of HRHLS Simulation $i with $j nodes"
13: Running ns with HRHLS + GPSR
14: HRHLS Trace Evaluation
15: echo "Start of PHRHLS Simulation $i with $j nodes"
16: Running ns with PHRHLS + GPSR
17: PHRHLS Trace Evaluation
18: Removing the Mobility Pattern
19: end for
20: Removing all traces
21: i++
22: end for
23: echo "End of Simulations"
List of Abbreviations

A-STAR Anchor-based Street and Trac Aware Routing. 68, 116


AMILC Age Maximal des Informations de Localisation dans le Cache. 122, 136
AODV Ad hoc On Demand Distance Vector. 67, 132, 136

C2A Connect to All. v, vii, 3, 4, 9, 10, 15, 22, 24, 26, 28, 30, 31, 33, 37, 39, 43, 45,
47, 48, 52, 60, 63, 64, 113, 114, 130, 131, 134, 136, 139141
C4R Citymob for Roadmaps. 144, 145
CAN Controller Area Network. 2, 4, 8, 9, 13, 15, 16, 48, 51, 52, 130, 134
CBR Constant Bit Rate. 88, 95, 98, 100, 103, 109, 148, 150, 151
CORBA Common Object Request Broker Architecture. 19, 20
CTL Computation Tree Logic. 26, 27

DREAM Distance Routing Eect Algorithm for Mobility. 69


DSR Dynamic Source Routing. 66, 67, 115, 132, 136
DTN Delay Tolerant Network. 68

Extensible Markup Language XML. 40, 41, 59


FMS Fleet Management System. 2, 4, 8, 9, 16, 40, 51, 52, 57, 130, 134
FSM Finite State Machines. 35, 55
FSR Fisheye State Routing. 66

GeoDTN +Nav Geographic and Delay Tolerant Network with Navigation Assis-
tance. 68, 116
GLOSA Green Light Optimized Speed Advisory. 63
GLS Grid Location Service. 64, 70, 75, 76, 7981, 8385, 88, 89, 93, 94, 100104,
111, 117124, 130132, 135137
GPRS General Packet Radio Service. 4, 9, 13, 15, 16, 28, 33, 40, 43, 48, 5052,
54, 58, 60, 65, 115, 130, 134, 140
GPS Global Positioning System. 4, 9, 13, 15, 16, 22, 24, 28, 29, 40, 48, 5052, 58,
65, 88, 115, 130, 134, 140
154 List of Abbreviations

GPSR Greedy Perimeter Stateless Routing. 64, 67, 68, 72, 81, 84, 8891, 103, 106,
111, 116, 118, 119, 121, 123, 132, 137
GSM Global System for Mobile. 15, 48, 51, 52, 58, 139, 140
GSR Geographic Source Routing. 67, 68, 116, 132, 136
GyTAR improved Greedy Trac Aware Routing. 68, 116, 132, 136

HD Hard Disk. 33
HLS Hierarchical Location Service. 4, 10, 64, 70, 7581, 8385, 8890, 93104,
106109, 111, 118, 119, 121124, 126, 131, 132, 135137
HRGLS Hybrid Routing and Grid Location Service. v, vii, 4, 10, 64, 8890, 93,
94, 100106, 111, 118, 121124, 126, 131, 132, 135137
HRHLS Hybrid Routing and Hierarchical Location Service. v, vii, 4, 10, 64, 8890,
93109, 111, 118, 121124, 126, 127, 131, 132, 135137
ICT Information and Communication Technologies. 7, 140
IEEE Institute of Electrical and Electronics Engineers. 17, 48, 63, 64, 81, 88, 114,
119, 132, 137
IIOP Internet Inter-ORB Protocol. 19, 20
ITS Intelligent Transport Systems. 7, 63

LAR Location-Aided Routing. 67


LCMA Location Cache Maximum Age. 9496, 132
LDS Langage de Description et de Spécication. vii, 4, 55, 56, 58, 134
LPBR Location Prediction Based Routing. 73
LUV Location Update Vector. 73

MAC Media Access Control. 81, 88, 97, 100, 101, 108, 119, 123, 151
MANETs Mobile Ad-hoc NETworks. 63, 66, 114, 115
MOPR Movement Prediction-based Routing. 72
MORA Movement-based Routing Algorithm. 72
MSC Message Sequence Chart. 38, 56

NAM Network ANimator. 150


List of Abbreviations 155

NS-2 Network Simulator 2. 10, 64, 81, 88, 111, 118, 119, 143146, 149151
OMG Object Management Group. 19
ORB Object Request Broker. 19, 20
PDR Packet Delivery Rate. 95, 97, 99, 100, 103, 105, 108, 109, 150, 151
PHRGLS Predictive Hybrid Routing and Grid Location Service. 132, 136, 137
PHRHLS Predictive Hybrid Routing and Hierarchical Location Service. v, vii, 4,
10, 64, 88, 105109, 118, 124, 126, 127, 132, 136, 137
PnP Plug and Play. 19

QSR Query Success Ratio. 81, 84, 100, 102, 104, 120
RLS Reactive Location Service. 69, 75, 8083, 116, 119, 130, 135
RTD Réseaux Tolérants aux Délais. 116
RTT Request Travel Time. 83, 84, 100, 102, 104

SDL Specication and Description Language. v, 9, 10, 35, 38, 40, 45, 130
SMS Short Message Service. 41, 43, 54, 59, 60
STI Systèmes de Transport Intelligents. 1, 2, 113, 114
SUMO Simulation of Urban MObility. 144146

TICTechnologies de l'Information et de la Communication. 1


TORA Temporally Ordered Routing Algorithm. 67, 132, 137
TPD Taux de Paquets Délivrés. 124, 126, 127
TRR Taux de Requêtes Réussites. 120, 123

UPnP Universal Plug and Play. 19


USB Universal Serial Bus. 24, 8, 9, 2224, 28, 32, 33, 3941, 43, 52, 5760, 130,
134
V2IVehicle to Infrastructure Communications. 63, 64
V2V Vehicle-to-Vehicle Communications. 8, 63, 64, 111
V2X Hybrid V2I and V2V Communications. 63
156 List of Abbreviations

VANETs Vehicular Ad-hoc NETworks. 6366, 68, 69, 72, 88, 105, 111, 114116,
144
VHRP Velocity-Heading based Routing Protocol. 72

WLAN Wireless Local Area Network. 63


Index

Connect to All, 21 VANETs, 65


Model, 23 Geographic Routing Protocols, 8, 9,
Application, 39 64, 6769, 72, 73, 81, 88, 89, 91,
SDL Verication, 38 103, 111, 130132
UPPAAL and SDL Comparison, 39 A-STAR, 68
UPPAAL Verication, 28 GeoDTN+Nav, 68
Project, 15 GPSR, 64, 67, 68, 72, 81, 84, 88
System, 22 91, 103, 106, 111, 116, 118, 119,
121, 123, 132, 137
Inter-Vehicular Communication, 63 GSR, 67
Hybrid V2I and V2V Communica- GyTAR, 68
tions, 63 LAR, 67
Vehicle to Infrastructure Communi- Location-based Services, 9, 10, 64,
cations, 63 69, 73, 75, 8284, 8890, 96, 97,
Vehicle-to-Vehicle Communications, 99, 101, 103, 111, 130132
63 Comparison, 75
Characteristics, 65 DREAM, 69
Interopérabilité, 47, 48, 50, 51 GLS, 64, 70, 75, 76, 7981, 8385,
Niveaux Interopérabilité, 50 88, 89, 93, 100104, 111, 117
Niveau Machine, 50 121, 123, 124, 130132, 135137
Niveau Organisationnel, 50 HLS, 4, 10, 64, 70, 7581, 8385,
Niveau Sémantique, 50 8890, 93104, 106109, 111, 118,
Niveau Syntaxique, 50 119, 121, 123, 124, 126, 131, 132,
Interoperability, 16 135137
IEEE Denitions, 17 HRHLS, v, vii, 4, 10, 64, 8890,
Interoperability Levels, 17 93109, 111, 118, 121124, 126,
Machine Level, 17 127, 131, 132, 135137
Organizational Level, 18 PHRGLS, 132, 136, 137
Semantic Level, 17 PHRHLS, v, vii, 4, 10, 64, 88, 105
Syntactic Level, 17 109, 118, 124, 126, 127, 132, 136,
137
SDL, 35 Quorum, 70
Introduction, 35 RLS, 69, 75, 8083, 116, 119, 130,
135
UPPAAL, 26 Mobility Prediction, 72
Introduction, 26 Routing Protocols, 66
Network Timed Automata, 26 Topology-based Routing Protocols, 8,
Query Language, 27 9, 66, 67, 73, 88, 111, 130, 132
158 Index

AODV, 67
DSR, 66
FSR, 66
TORA, 67
List of Publications

M. Ayaida, M. Barhoumi, H. Fouchal, L. Alal and Y. Ghamri-Doudane.


HHLS: A Hybrid Routing Technique for VANETs. In: the IEEE Globecom
2012 - Ad Hoc and Sensor Networking Symposium (GC12 AHSN), December
2012, Anaheim, CA, USA.

M. Ayaida, H. Fouchal, L. Alal and Y. Ghamri-Doudane. A Comparison of


Reactive, Grid and Hierarchical Location-based Services for VANETs. In: the
IEEE 76th Vehicular Technology Conference (VTC2012-Fall), 3-6 September
2012, Quebec City, Canada.

M. Ayaida, M. Barhoumi, H. Fouchal, L. Alal and Y. Ghamri-Doudane.


Impact of Location Data Freshness on Routing in VANETs. In: the IEEE
third International Conference on Wireless Communications in Unusual and
Conned Areas (ICWCUCA), 28-30 August, 2012, Clermont-ferrand, France.

M. Ayaida, H. El Mehraz, L. Alal, and H. Fouchal. Communication In-


teroperability Model for Embedded Devices. In: IEEE GLOBECOM 2011 -
Ad-hoc and Sensor Networking Symposium (GC'11 - AHSN), December 5-9
2011, Houston, Texas, USA.

M. Ayaida, L. Alal, H. Fouchal, and H. El Mehraz. Improving the Link


Lifetime in VANETs. In: 11th IEEE International Workshop on Wireless
Local Networks (WLN 2011) in The 37th IEEE Conference on Local Computer
Networks (LCN), October 4-7, 2011, Hilton Hotel, Bonn, Germany, page 917-
924.
M. Ayaida, H. El Mehraz, H. Fouchal, and L. Alal. Modeling Interoperabil-
ity Channel using UPPAAL. In 11th International Conference on Innovative
Internet Community Systems, Berlin, Germany, June, 15-17, 2011.

M. Ayaida, H. El Mehraz, L. Alal, and H. Fouchal. Interoperability Modeling


Methods for Embedded Devices in Vehicles. In : IEEE Logistics (LOGISTI-
QUA), 2011 4th International Conference on logistics, Hammamet, Tunisia,
pp.445-451, May 31 2011-June 3 2011.
M. Ayaida, H. El Mehraz, L. Alal, and H. Fouchal. Interoperability Model for
Embedded Devices on Vehicles. In 11th international Conference on Sciences
and Techniques of Automatic control and computer engineering, Monastir,
Tunisia, December, 19-21, 2010.

M. Ayaida, L. Alal, and H. Fouchal. Developpement d un dispositif de com-


munication et d interconnexion d elements hybrides embarques sur un vehicule,
pour la securisation du transport. In ResCom 2010, June 2010.
Bibliography

[1] R. Bishop, Survey of intelligent vehicle applications worldwide, in Proc. IEEE


Intelligent Vehicles Symposium. Dearborn, MI, USA, 2000. (Cited on pages 2
and 8.)
[2] A. Girard, S. J., and K. Hedrick, An overview of emerging results in networked
multi-vehicle systems, Orlando, US, 2001 2001. (Cited on pages 2 and 8.)
[3] S. Tsugawa, Inter-vehicle communications and their applications to intelligent
vehicles: An overview, in Proceedings of IEEE Intelligent Vehicle Symposium,
vol. 2, 2002, pp. 56469. (Cited on pages 2 and 8.)
[4] J. Luo and J.-P. Hubaux, A survey of research in inter-vehicle
communications, Embedded Security in Cars, pp. 111122, 2006. [Online].
Available: http://dx.doi.org/10.1007/3-540-28428-1_7 (Cited on pages 2
and 8.)
[5] J. Chennikara-Varghese, W. Chen, O. Altintas, and S. Cai, Survey of Routing
Protocols for Inter-Vehicle Communications, in Mobile and Ubiquitous
Systems - Workshops, 2006. 3rd Annual International Conference on, 2006, pp.
15. [Online]. Available: http://dx.doi.org/10.1109/MOBIQW.2006.361764
(Cited on pages 2 and 8.)
[6] F. Li and Y. Wang, Routing in vehicular ad hoc networks: A survey,
IEEE Vehicular Technology Magazine, vol. 2, no. 2, pp. 1222, 2007. [Online].
Available: http://dx.doi.org/10.1109/MVT.2007.912927 (Cited on pages 2
and 8.)
[7] M. Sichitiu and M. Kihl, Inter-vehicle communication systems: a survey,
IEEE Communications Surveys & Tutorials, vol. 10, no. 2, pp. 88105, Jul.
2008. [Online]. Available: http://dx.doi.org/10.1109/COMST.2008.4564481
(Cited on pages 2 and 8.)
[8] Y. Toor, P. Muhlethaler, and A. Laouiti, Vehicle Ad Hoc networks:
applications and related technical issues, Communications Surveys &
Tutorials, IEEE, vol. 10, no. 3, pp. 7488, 2008. [Online]. Available:
http://dx.doi.org/10.1109/COMST.2008.4625806 (Cited on pages 2 and 8.)
[9] H. Hartenstein and K. P. Laberteaux, A tutorial survey on vehicular ad
hoc networks, Communications Magazine, IEEE, vol. 46, no. 6, Jun. 2008.
[Online]. Available: http://dx.doi.org/10.1109/MCOM.2008.4539481 (Cited
on pages 2 and 8.)
[10] T. L. Willke, P. Tientrakool, and N. F. Maxemchuk, A survey of inter-vehicle
communication protocols and their applications, Communications Surveys
162 Bibliography

& Tutorials, vol. 11, no. 2, pp. 320, Jun. 2009. [Online]. Available:
http://dx.doi.org/10.1109/SURV.2009.090202 (Cited on pages 2 and 8.)
[11] P. Papadimitratos, A. La Fortelle, K. Evenssen, R. Brignolo, and S. Cosenza,
Vehicular communication systems: Enabling technologies, applications, and
future outlook on intelligent transportation, Communications Magazine,
IEEE, vol. 47, no. 11, pp. 8495, Nov. 2009. [Online]. Available:
http://dx.doi.org/10.1109/MCOM.2009.5307471 (Cited on pages 2 and 8.)
[12] G. Karagiannis, O. Altintas, E. Ekici, G. Heijenk, B. Jarupan, K. Lin, and
T. Weil, Vehicular networking: A survey and tutorial on requirements, archi-
tectures, challenges, standards and solutions, Communications Surveys Tuto-
rials, IEEE, vol. 13, no. 4, pp. 584 616, quarter 2011. (Cited on pages 2, 8,
63 and 114.)
[13] L. Alal, P. Lacroix, N. Manamani, S. Moughamir, and J. Zaytoon, Dispositf
d'interoperabilite et de communication entre plusieurs appareils et procede de
fonctionnement de ce dispositif, French Patent Nationally : FR0 806 113, In-
ternationally : PCT-FR-2009 001 259, Novembre 6, 2008. (Cited on pages 15
and 48.)
[14] IEEE Standards Information Network. IEEE 100, The Authoritative Dictio-
nary of IEEE Standards Terms Std. Seventh Edition, 2000. (Cited on pages 17
and 48.)
[15] P. Young, N. Chaki, V. Berzins, and Luqi, Evaluation of middleware architec-
tures in achieving system interoperability, Rapid System Prototyping, IEEE
International Workshop on, vol. 0, p. 108, 2003. (Cited on pages 17 and 51.)

[16] A. Tolk and J. A. Muguira, The levels of conceptual interoperability model


(lcim), in Proceedings IEEE Fall Simulation Interoperability Workshop. IEEE
CS Press, 2003. (Cited on page 17.)
[17] G. Athanasopoulos, A. Tsalgatidou, and M. Pantazoglou, Interoperability
among heterogeneous services, Services Computing, IEEE International Con-
ference on, vol. 0, pp. 174181, 2006. (Cited on page 17.)

[18] T. Perumal, A. R. Ramli, C. Y. Leong, S. Mansor, and K. Samsudin, Inter-


operability among heterogeneous systems in smart home environment, Signal-
Image Technologies and Internet-Based System, International IEEE Conference
on, vol. 0, pp. 177186, 2008. (Cited on pages 17 and 51.)

[19] G. A. Lewis, E. Morris, S. Simanta, and L. Wrage, Why standards are not
enough to guarantee end-to-end interoperability, in ICCBSS '08: Proceedings
of the Seventh International Conference on Composition-Based Software Sys-
tems (ICCBSS 2008). Washington, DC, USA: IEEE Computer Society, 2008,
pp. 164173. (Cited on pages 18, 47 and 51.)
Bibliography 163

[20] E. Morris, System of Systems Interoperability (SOSI): Final Report, ser.


Technical report. Carnegie Mellon University, Software Engineering Institute,
2004. [Online]. Available: http://books.google.fr/books?id=LcLvtgAACAAJ
(Cited on pages 19 and 51.)
[21] B. Miller, T. Nixon, C. Tai, and M. Wood, Home networking with universal
plug and play, Communications Magazine, IEEE, vol. 39, no. 12, pp. 104 109,
Dec. 2001. (Cited on page 19.)
[22] M. Henning, The rise and fall of corba, ACM Queue (Association
for Computing Machinery), pp. 2834, June 2006. [Online]. Available:
http://delivery.acm.org/10.1145/1150000/1142044/p28-henning.pdf (Cited on
page 19.)
[23] M. Ayaida, H. El Mehraz, L. Alal, and H. Fouchal, Interoperability model
for embedded devices on vehicles, in 11th international Conference on Sci-
ences and Techniques of Automatic control and computer engineering, Monas-
tir, Tunisia, Dec. 2010. (Cited on page 24.)
[24] G. Behrmann, R. David, and K. G. Larsen, A tutorial on uppaal, in Interna-
tional School on Formal Methods for the Design of Computer, Communication,
and Software Systems, SFM-RT 2004. Revised Lectures, ser. Lecture Notes in
Computer Science, M. Bernardo and F. Corradini, Eds., vol. 3185. Springer
Verlag, 2004, pp. 200237, freely available at http://www.uppaal.com/. (Cited
on pages 26 and 53.)
[25] ITU-T, ITU-T Rec. Z.100  Formal description techniques (FDT) 
Specication and Description Language (SDL), 2002. [Online]. Available:
www.sdl-forum.org (Cited on pages 35 and 55.)
[26] M. Ayaida, H. El Mehraz, L. Alal, and H. Fouchal, Communication interop-
erability model for embedded devices, in IEEE GLOBECOM 2011 - Ad-hoc
and Sensor Networking Symposium (GC'11 - AHSN), Houston, Texas, USA,
Dec. 2011. (Cited on page 39.)
[27] M. Ayaida, L. Alal, and H. Fouchal, Développement d'un dispositif de com-
munication et d'interconnexion d'éléments hybrides embarqués sur un véhicule,
pour la sécurisation du transport, in ResCom 2010, Giens, France, Jun. 2010.
(Cited on page 50.)
[28] M. Ayaida, H. E. Mehraz, L. Alal, and H. Fouchal, Modeling interoperability
channel using uppaal, in 11th International Conference on Innovative Inter-
net Community Services (IICS'11), Berlin, Germany, Jun. 2011, pp. 182192.
(Cited on page 53.)
[29] M. Ayaida, H. El Mehraz, L. Alal, and H. Fouchal, Interoperability modeling
methods for embedded devices in vehicles, in 4th International Conference on
164 Bibliography

Logistics (LOGISTIQUA'11), Hammamet, Tunisia, Jun. 2011, pp. 445 451.


(Cited on page 57.)
[30] K. Katsaros, R. Kernchen, M. Dianati, and D. Rieck, Performance study of
a green light optimized speed advisory (glosa) application using an integrated
cooperative its simulation platform, in IWCMC'11, 2011, pp. 918923. (Cited
on pages 63 and 113.)
[31] I. Jawhar, N. Mohamed, and L. Zhang, Inter-vehicular communication sys-
tems, protocols and middleware, in Networking, Architecture and Storage
(NAS), 2010 IEEE Fifth International Conference on, july 2010, pp. 282 287.
(Cited on pages 63 and 114.)
[32] Ieee standard for information technology local and metropolitan area
networks specic requirements part 11: Wireless lan medium access control
(mac) and physical layer (phy) specications amendment 6: Wireless access
in vehicular environments, IEEE Std 802.11p-2010 (Amendment to IEEE Std
802.11-2007 as amended by IEEE Std 802.11k-2008, IEEE Std 802.11r-2008,
IEEE Std 802.11y-2008, IEEE Std 802.11n-2009, and IEEE Std 802.11w-2009),
pp. 1 51, 15 2010. (Cited on pages 63, 80 and 114.)
[33] A. M. Vegni and T. D. Little, Hybrid vehicular communications
based on v2v-v2i protocol switching, International Journal of Vehicle
Information and Communication Systems, vol. 2, no. 3-4/2011, pp. 213231,
Dec. 2011. [Online]. Available: http://inderscience.metapress.com/content/
q015477276702553/ (Cited on pages 63 and 114.)
[34] M. Ayaida, L. Alal, H. Fouchal, and H. El Mehraz, Improving the link lifetime
in VANETs, in IEEE 36th Conference on Local Computer Networks (LCN'11)
- 11th IEEE International Workshop on Wireless Local Networks (WLN'11),
Bonn, Germany, Oct. 2011, pp. 917924. (Cited on page 65.)
[35] G. Pei, M. Gerla, and T.-W. Chen, Fisheye state routing: a routing scheme
for ad hoc wireless networks, in Communications, 2000. ICC 2000. 2000 IEEE
International Conference on, vol. 1, 2000, pp. 70 74 vol.1. (Cited on page 66.)

[36] D. B. Johnson and D. A. Maltz, Dynamic source routing in ad hoc wireless


networks, in Mobile Computing. Kluwer Academic Publishers, 1996, pp. 153
181. (Cited on pages 66 and 115.)
[37] V. D. Park and M. S. Corson, A highly adaptive distributed routing algorithm
for mobile wireless networks, 1997. (Cited on page 67.)
[38] C. E. Perkins and E. M. Royer, Ad-hoc on-demand distance vector routing, in
IN PROCEEDINGS OF THE 2ND IEEE WORKSHOP ON MOBILE COM-
PUTING SYSTEMS AND APPLICATIONS, 1997, pp. 90100. (Cited on
page 67.)
Bibliography 165

[39] Y.-B. Ko and N. H. Vaidya, Location-aided routing (lar) in mobile ad hoc


networks, Wirel. Netw., vol. 6, no. 4, pp. 307321, Jul. 2000. [Online].
Available: http://dx.doi.org/10.1023/A:1019106118419 (Cited on page 67.)
[40] B. Karp and H. T. Kung, Gpsr: greedy perimeter stateless routing for wireless
networks, in Proceedings of the 6th annual international conference on Mobile
computing and networking (MobiCom'00), New York, NY, USA, 2000, pp. 243
254. (Cited on pages 67, 81, 88, 116 and 119.)
[41] C. Lochert, H. Hartenstein, J. Tian, H. Fuessler, D. Hermann, and M. Mauve,
A routing strategy for vehicular ad hoc networks in city environments, in In
Proceedings of the IEEE Intelligent Vehicles Symposium, 2003, pp. 156161.
(Cited on pages 67 and 116.)
[42] B.-C. Seet, G. Liu, B.-S. Lee, C.-H. Foh, K.-J. Wong, and K.-K. Lee,
A-STAR: A Mobile Ad Hoc Routing Strategy for Metropolis Vehicular
ommunications, 2004. [Online]. Available: http://dx.doi.org/10.1007/b97826
(Cited on pages 68 and 116.)
[43] M. Jerbi, S.-M. Senouci, R. Meraihi, and Y. Ghamri-Doudane, An improved
vehicular ad hoc routing protocol for city environments, in Communications,
2007. ICC '07. IEEE International Conference on, june 2007, pp. 3972 3979.
(Cited on pages 68 and 116.)
[44] P.-C. Cheng, J.-T. Weng, L.-C. Tung, K. C. Lee, M. Gerla, and J. Hårri,
Geodtn+nav: A hybrid geographic and dtn routing with navigation assistance
in urban vehicular networks, 5 2010. (Cited on pages 68 and 116.)
[45] S. Basagni, I. Chlamtac, V. R. Syrotiuk, and B. A. Woodward, A distance
routing eect algorithm for mobility (dream), in Proceedings of the 4th an-
nual ACM/IEEE international conference on Mobile computing and networking
(MobiCom'98), New York, NY, USA, 1998, pp. 7684. (Cited on page 69.)

[46] M. Kasemann, H. Hartenstein, and M. Mauve, A reactive location service


for mobile ad hoc networks, Department of Computer Science University of
Mannheim Tech Rep TR02014, pp. 121133, 2002. (Cited on pages 69 and 116.)

[47] Z. J. Haas and B. Liang, Ad hoc mobility management with uniform quorum
systems, IEEE/ACM Transactions on Networking, vol. 7, pp. 228240, April
1999. (Cited on page 70.)
[48] J. Li, J. Jannotti, D. S. J. De Couto, D. R. Karger, and R. Morris, A scalable
location service for geographic ad hoc routing, in Proceedings of the 6th annual
international conference on Mobile computing and networking (MobiCom'00),
New York, NY, USA, 2000, pp. 120130. (Cited on pages 70 and 117.)
166 Bibliography

[49] W. Kiess, H. Fussler, J. Widmer, and M. Mauve, Hierarchical location ser-


vice for mobile ad-hoc networks, SIGMOBILE Mob. Comput. Commun. Rev.,
vol. 8, pp. 4758, October 2004. (Cited on pages 70 and 117.)
[50] F. Granelli, G. Boato, and D. Kliazovich, MORA: a movement-based rout-
ing algorithm for vehicle ad hoc networks, in IEEE Workshop on Automotive
Networking and Applications (AutoNet'2006), San Francisco, U.S.A, December
2006. (Cited on page 72.)
[51] H. Menouar, M. Lenardi, and F. Filali, A movement prediction-based routing
protocol for vehicle-to-vehicle communications, in V2VCOM 2005, 1st Inter-
national Vehicle-to-Vehicle Communications Workshop, co-located with MobiQ-
uitous 2005, July 21, 2005, San Diego, USA, San Diego, USA, 07 2005. (Cited
on page 72.)
[52] H. Menouar, M. Lenardi, and F. Filali, Movement prediction-based routing
(MOPR) concept for position-based routing in vehicular networks, in Vehicular
Technology Conference, 2007. VTC-2007 Fall. 2007 IEEE 66th, 30 2007-oct. 3
2007, pp. 2101 2105. (Cited on page 72.)
[53] T. Taleb, M. Ochi, A. Jamalipour, N. Kato, and Y. Nemoto, An ecient
vehicle-heading based routing protocol for VANET networks, in Wireless Com-
munications and Networking Conference, 2006. WCNC 2006. IEEE, vol. 4, april
2006, pp. 2199 2204. (Cited on page 72.)
[54] N. Meghanathan, Location prediction based routing protocol for mobile ad
hoc networks, in Global Telecommunications Conference, 2008. IEEE GLOBE-
COM 2008. IEEE, 30 2008-dec. 4 2008, pp. 1 5. (Cited on page 73.)

[55] Y. Yu, G.-H. Lu, and Z.-L. Zhang, Enhancing location service scalability with
high-grade, in IEEE International Conference on Mobile Ad-hoc and Sensor
Systems (MASS'04), oct. 2004, pp. 164  173. (Cited on pages 76, 79 and 118.)

[56] M. Ayaida, H. Fouchal, L. Alal, and Y. Ghamri-Doudane, A comparison of


reactive, grid and hierarchical location-based services for VANETs, in IEEE
76th Vehicular Technology Conference (VTC2012-Fall), Quebec, QC, Canada,
Sep. 2012. (Cited on page 76.)
[57] S. R. Dunbar, The average distance between points in geometric gures, The
College Mathematics Journal, vol. 28, no. 3, pp. 187197, May 1997. (Cited on
page 78.)
[58] M. Ayaida, M. Barhoumi, H. Fouchal, Y. Ghamri-Doudane, and L. Alal,
HHLS: a hybrid routing technique for VANETs, in IEEE GLOBECOM 2012
- Ad-hoc and Sensor Networking Symposium (GC'12 - AHSN), Anaheim, CA,
USA, Dec. 2012. (Cited on page 89.)
Bibliography 167

[59] M. Ayaida, M. Barhoumi, H. Fouchal, Y. Ghamri-Doudane, and L. Alal, Im-


pact of location data freshness on routing in VANETs, in IEEE third Interna-
tional Conference on Wireless Communications in Unusual and Conned Areas
(ICWCUCA'12), Clermont-ferrand, France, Aug. 2012. (Cited on page 94.)

[60] F. J. Martinez, J. C. Cano, C. T. Calafate, and P. Manzoni, CityMob:


A Mobility Model Pattern Generator for VANETs, in Communications
Workshops, 2008. ICC Workshops '08. IEEE International Conference on, 2008,
pp. 370374. [Online]. Available: http://dx.doi.org/10.1109/ICCW.2008.76
(Cited on page 144.)
[61] M. Behrisch, L. Bieker, J. Erdmann, and D. Krajzewicz, Sumo - simulation
of urban mobility: An overview, in SIMUL 2011, The Third International
Conference on Advances in System Simulation, Barcelona, Spain, October 2011,
pp. 6368. (Cited on page 144.)
[62] S. Joerer, C. Sommer, and F. Dressler, Towards Reproducibility and Compara-
bility of IVC Simulation Studies - A Literature Survey, IEEE Communications
Magazine, 2012, to appear. (Cited on page 144.)
Biography

Marwane Ayaida studied at E.N.S.E.A (High National


School in Electronics and their Applications) in Cergy-
Pontoise France, where he took his Engineering Diploma in
Electronics of Embedded Systems in 2009. The same year
he got his Master Degree in Electronics of Autonomous
Systems at the University of Cergy-Pontoise in France.
Currently, Marwane is a PhD student at the University
of Reims Champagne-Ardennes in France. His research
interests are on the interoperability modelling for embedded systems in the eld
of transportation. Also, his work focuses on Vehicular Communications (Vehicle-
to-Vehicle Communications (V2V) and Vehicle to Infrastructure Communications
(V2I)). Specically, he studies the routing protocols in Vehicular Ad-hoc Networks
(VANETs).

Marwane Ayaida a étudié à l'E.N.S.E.A (École Nationale


Supérieure de l'Électronique et de ses Applications) à Cergy-
Pontoise en France, où il a eu son diplôme d'ingénieur en
Électronique des Systèmes Embarqués en 2009. La même
année, il a obtenu son Master en Électronique des Systèmes
Autonomes à l'Université de Cergy-Pontoise en France.
Actuellement, Marwane est un étudiant en doctorat à l'Uni-
versité de Reims Champagne-Ardenne en France. Ses recher-
ches portent sur la modélisation de l'interopérabilité pour les systèmes embarqués
dans le domaine des transports. De plus, son travail est axé sur les communications
véhiculaires (V2V et V2I). Plus précisément, il étudie les protocoles de routage dans
les réseaux ad-hoc véhiculaires (VANETs).