PROJECTE FINAL DE CARRERA
PERFORMANCE EVALUATION OF GEOGRAPHIC
AND TOPOLOGICAL ROUTING PROTOCOLS
FOR VEHICULAR AD-HOC NETWORKS
Estudis: Enginyeria de Telecomunicació
Autor: David Marín Sánchez
Directora: Mónica Aguilar Igartua
Co-director: Ahmad Mohamad Mezher
Data: Maig 2012
AGRADECIMIENTOS
Agradecimientos
Con estas líneas quiero hacer llegar a Mónica y Ahmad mi especial agradecimiento por toda la
ayuda recibida, por su interés y por su dedicación. Sin ellos nada de esto habría sido posible.
Una mención especial a mis padres que me inculcaron el valor del esfuerzo. También recordar
a mis hermanos. Su ejemplo es la brújula que me guía. Gracias por estar siempre a mi lado.
3
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
INDEX
INDEX OF FIGURES AND TABLES ......................................................................................... 10
FIGURES........................................................................................................................... 10
GLOSSARY OF ACRONYMS ................................................................................................. 18
ABSTRACT ......................................................................................................................... 22
RESUMEN .......................................................................................................................... 24
RESUM .............................................................................................................................. 26
1.
INTRODUCTION AND GOALS ....................................................................................... 28
2.
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS ........................................... 30
2.1.
Introducing MANETs (Mobile Ad hoc NETworks) ................................................ 31
2.2.
Challenges in MANETs ......................................................................................... 32
2.2.1.
Scalability Weakness ........................................................................................... 32
2.2.2.
Routing ................................................................................................................ 32
2.2.3.
Security ................................................................................................................ 33
2.2.4.
Quality of Service (QoS) ....................................................................................... 33
2.2.5.
Energy-constrained operations ........................................................................... 34
2.2.6.
Interoperation ..................................................................................................... 34
2.3.
Applications of MANETs ...................................................................................... 34
2.3.1.
Community Networking ...................................................................................... 35
2.3.2.
Crisis-management applications ......................................................................... 35
2.3.3.
Personal Area Networking................................................................................... 35
2.3.4.
Military battlefield applications .......................................................................... 35
2.4.
Wireless Sensor Networks (WSN) ........................................................................ 35
2.4.1.
Properties ............................................................................................................ 36
2.4.2.
Current deployments and applications ............................................................... 37
2.4.2.1.
Remote Ecological Micro-Sensor Network ............................................................................ 37
2.4.2.2.
Environment Observation and Forecasting System............................................................... 38
2.4.2.3.
Disaster Relief Management ................................................................................................. 38
2.4.2.4.
Health care monitoring ......................................................................................................... 38
2.4.2.5.
DARPA Efforts towards Wireless Sensor Networks ............................................................... 39
2.5.
4
Introducing VANETs (Vehicular Ah-hoc NETworks) ............................................. 39
INDEX
2.5.1.
Properties ............................................................................................................ 41
2.5.2.
State of the art in VANETs ................................................................................... 42
2.5.2.1.
VANETs Applications.............................................................................................................. 42
2.5.2.1.1.
Safety-related Applications ............................................................................................... 42
2.5.2.1.2.
Comfort Applications ......................................................................................................... 43
2.5.2.1.3.
Applications for Administration ......................................................................................... 44
2.5.2.2.
Challenges in VANETs ............................................................................................................ 44
2.5.2.2.1.
Routing .............................................................................................................................. 44
2.5.2.2.2.
Security .............................................................................................................................. 45
2.5.2.2.3.
Quality of Service (QoS) ..................................................................................................... 45
2.5.2.2.4.
Power Management .......................................................................................................... 46
2.5.2.3.
3.
Current projects and activities in VANETs ............................................................................. 46
2.5.2.3.1.
Standardization process and research projects initiatives in VANETs ............................... 46
2.5.2.3.2.
Vehicular Mobility Models ................................................................................................. 49
2.5.2.3.3.
Other research areas in VANETs ........................................................................................ 51
2.6.
Vehicular Traffic Models in VANETs .................................................................... 52
2.6.1.
Freeway model .................................................................................................... 53
2.6.2.
Manhattan model ............................................................................................... 53
2.6.3.
City Section Mobility (CSM) ................................................................................. 53
2.6.4.
Stop Sign Model (SSM) ........................................................................................ 54
2.6.5.
Traffic Sign Model (TSM) ..................................................................................... 54
2.6.6.
STRAW (Street Random Waypoint) ..................................................................... 54
2.6.7.
MOVE (MObility model generator for VEhicular network) ................................. 55
2.6.8.
BonnMotion ......................................................................................................... 56
2.6.9.
VanetMobiSim ..................................................................................................... 56
2.6.10.
SUMO (Simulation of Urban Mobility) ................................................................ 57
2.6.11.
FreeSim ................................................................................................................ 57
2.6.12.
CityMob ............................................................................................................... 58
WIRELESS ACCESS FOR VEHICULAR ENVIRONMENT ..................................................... 60
3.1.
Introduction ......................................................................................................... 60
3.2.
Wireless Access For Vehicular Environment (WAVE) .......................................... 62
3.2.1.
Architecture Overview ......................................................................................... 62
3.2.2.
IEEE 802.11p ........................................................................................................ 63
3.2.2.1.
PHY layer for IEEE 802.11p .................................................................................................... 63
5
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
3.2.2.2.
4.
5.
MAC layer for IEEE 802.11p ................................................................................................... 65
PROPAGATION MODELS FOR VEHICULAR ENVIRONMENTS.......................................... 67
4.1.
Large-Scale Fading Models: Two-Ray ground model .......................................... 67
4.2.
Small-Scale Fading Models .................................................................................. 68
4.2.1.
Rayleigh model .................................................................................................... 68
4.2.2.
Rician model ........................................................................................................ 69
ROUTING PROTOCOLS FOR VANETS ............................................................................ 71
5.1.
Classification of routing protocols for VANETs .................................................... 71
5.1.1.
Proactive Routing Protocols ................................................................................ 72
5.1.2.
Reactive Routing Protocols.................................................................................. 73
5.1.2.1.
Reactive Source routing protocols......................................................................................... 73
5.1.2.2.
Reactive Hop-by-hop routing protocols ................................................................................ 73
5.1.3.
Hybrid Routing Protocols ..................................................................................... 73
5.2.
Topological Routing Protocols ............................................................................. 74
5.2.1.
DSR ...................................................................................................................... 74
5.2.2.
AODV ................................................................................................................... 74
5.2.2.1.
Route discovery mechanisms ................................................................................................ 74
5.2.2.2.
Route maintenance mechanisms .......................................................................................... 76
5.2.2.3.
Comparative: AODV vs DSR ................................................................................................... 77
5.1.
Geographical Routing Protocols .......................................................................... 78
5.1.1.
GPSR .................................................................................................................... 78
5.1.1.1.
5.1.1.1.1.
Greedy Forwarding ............................................................................................................ 81
5.1.1.1.2.
Perimeter Forwarding........................................................................................................ 82
5.1.1.1.
5.1.2.
5.1.2.1.
5.1.3.
6.
6
GPSR Routing Algorithm ........................................................................................................ 80
GPSR Improvements .............................................................................................................. 85
GOSR .................................................................................................................... 85
GOSR Routing Algorithm ....................................................................................................... 86
GSR Challenges .................................................................................................... 87
SIMULATION TOOLS ................................................................................................... 88
6.1.
VMware Player .................................................................................................... 88
6.2.
Ubuntu ................................................................................................................. 89
6.3.
VanetMobiSim ..................................................................................................... 90
6.4.
NS2 ...................................................................................................................... 91
6.5.
AWK ..................................................................................................................... 91
INDEX
6.6.
7.
8.
9.
GNU Octave ......................................................................................................... 92
SIMULATION PROCESS................................................................................................ 93
7.1.
Introduction ......................................................................................................... 93
7.2.
Simulation files .................................................................................................... 94
DESCRIPTION OF THE SIMULATIONS ........................................................................... 98
8.1.
Scenarios ............................................................................................................. 98
8.2.
Parameters of the simulations .......................................................................... 100
8.3.
Evaluated metrics .............................................................................................. 101
8.3.1.
Packet Delivery Ratio (PDR)............................................................................... 101
8.3.1.
Packet Loss Ratio (PLR)...................................................................................... 102
8.3.2.
Average End-to-end delay (E2E) ........................................................................ 102
8.3.3.
Data throughput................................................................................................ 102
SIMULATION RESULTS .............................................................................................. 103
9.1.
General evaluation of urban scenario ............................................................... 104
9.1.1.
Performance evaluation as a function of node density ..................................... 104
9.1.1.1.
Transmission range of 100m ............................................................................................... 105
9.1.1.1.1.
Average Packet Delivery Ratio ......................................................................................... 105
9.1.1.1.1.
Average Packet Loss Ratio ............................................................................................... 106
9.1.1.1.2.
Average End-to-end Delay ............................................................................................... 107
9.1.1.2.
Transmission range of 150m ............................................................................................... 108
9.1.1.2.1.
Average Packet Delivery Ratio ......................................................................................... 108
9.1.1.2.2.
Average Packet Loss Ratio ............................................................................................... 109
9.1.1.2.3.
Average End-to-end Delay ............................................................................................... 110
9.1.1.3.
Transmission range of 200m ............................................................................................... 111
9.1.1.3.1.
Average Packet Delivery Ratio ......................................................................................... 111
9.1.1.3.1.
Average Packet Loss Ratio ............................................................................................... 112
9.1.1.3.2.
Average End-to-end Delay ............................................................................................... 113
9.1.1.4.
Transmission range of 250m ............................................................................................... 114
9.1.1.4.1.
Average Packet Delivery Ratio ......................................................................................... 114
9.1.1.4.1.
Average Packet Loss Ratio ............................................................................................... 115
9.1.1.4.2.
Average End-to-end Delay ............................................................................................... 116
9.1.2.
Performance evaluation as a function of node speed ....................................... 117
9.1.2.1.
Transmission range of 100m ............................................................................................... 117
9.1.2.1.1.
Average Packet Delivery Ratio ......................................................................................... 117
9.1.2.1.1.
Average Packet Loss Ratio ............................................................................................... 118
7
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.2.1.2.
9.1.2.2.
Transmission range of 150m ............................................................................................... 120
9.1.2.2.1.
Average Packet Delivery Ratio ......................................................................................... 120
9.1.2.2.1.
Average Packet Loss Ratio ............................................................................................... 121
9.1.2.2.2.
Average End-to-end Delay ............................................................................................... 122
9.1.2.3.
Transmission range of 200m ............................................................................................... 123
9.1.2.3.1.
Average Packet Delivery Ratio ......................................................................................... 123
9.1.2.3.2.
Average Packet Loss Ratio ............................................................................................... 124
9.1.2.3.3.
Average End-to-end Delay ............................................................................................... 125
9.1.2.4.
Transmission range of 250m ............................................................................................... 126
9.1.2.4.1.
Average Packet Delivery Ratio ......................................................................................... 126
9.1.2.4.1.
Average Packet Loss Ratio ............................................................................................... 127
9.1.2.4.2.
Average End-to-end Delay ............................................................................................... 128
9.1.3.
Performance evaluation as a function of transmission range .......................... 129
9.1.3.1.
Node Density of 20 nodes/km2............................................................................................ 129
9.1.3.1.1.
Average Packet Delivery Ratio ......................................................................................... 129
9.1.3.1.1.
Average Packet Loss Ratio ............................................................................................... 130
9.1.3.1.2.
Average End-to-end Delay ............................................................................................... 131
9.1.3.2.
Node Density of 25 nodes/km2............................................................................................ 132
9.1.3.2.1.
Average Packet Delivery Ratio ......................................................................................... 132
9.1.3.2.1.
Average Packet Loss Ratio ............................................................................................... 133
9.1.3.2.2.
Average End-to-end Delay ............................................................................................... 134
9.1.3.3.
Node Density of 30 nodes/km2............................................................................................ 135
9.1.3.3.1.
Average Packet Delivery Ratio ......................................................................................... 135
9.1.3.3.1.
Average Packet Loss Ratio ............................................................................................... 136
9.1.3.3.2.
Average End-to-end Delay ............................................................................................... 137
9.1.3.4.
Node Density of 35 nodes/km2............................................................................................ 138
9.1.3.4.1.
Average Packet Delivery Ratio ......................................................................................... 138
9.1.3.4.1.
Average Packet Loss Ratio ............................................................................................... 139
9.1.3.4.2.
Average End-to-end Delay ............................................................................................... 140
9.1.3.5.
Node Density of 40 nodes/km2............................................................................................ 141
9.1.3.5.1.
Average Packet Delivery Ratio ......................................................................................... 141
9.1.3.5.1.
Average Packet Loss Ratio ............................................................................................... 142
9.1.3.5.2.
Average End-to-end Delay ............................................................................................... 143
9.1.3.6.
8
Average End-to-end Delay ............................................................................................... 119
Node Density of 45 nodes/km2............................................................................................ 144
9.1.3.6.1.
Average Packet Delivery Ratio ......................................................................................... 144
9.1.3.6.1.
Average Packet Loss Ratio ............................................................................................... 145
9.1.3.6.2.
Average End-to-end Delay ............................................................................................... 146
INDEX
9.2.
Evaluation of Data Throughput over time......................................................... 147
9.2.1.1.
Node Density of 20 nodes/km2............................................................................................ 147
9.2.1.2.
Node Density of 25 nodes/km2............................................................................................ 148
9.2.1.3.
Node Density of 30 nodes/km2............................................................................................ 149
9.2.1.4.
Node Density of 35 nodes/km2............................................................................................ 150
9.2.1.5.
Node Density of 40 nodes/km2............................................................................................ 151
9.2.1.6.
Node Density of 45 nodes/km2............................................................................................ 152
9.3.
Evaluation of other propagation models .......................................................... 153
9.3.1.
Average Packet Delivery Ratio .......................................................................... 154
9.3.1.
Average Packet Loss Ratio................................................................................. 155
9.3.2.
Average End-to-end Delay................................................................................. 156
10. CONCLUSIONS AND FUTURE WORK .......................................................................... 157
10.1.
Conclusions ........................................................................................................ 157
10.2.
Future works ...................................................................................................... 158
11. ANNEX: HOW TO DO THE SIMULATIONS .................................................................. 160
11.1.
How to install VMware Player ........................................................................... 160
11.2.
How to install Ubuntu........................................................................................ 160
11.3.
How to install VanetMobiSim-1.1 ..................................................................... 161
11.4.
How to install NS2.27 ........................................................................................ 163
11.5.
How to install GPSR on NS2-27.......................................................................... 183
11.6.
How to install AWK............................................................................................ 184
11.7.
How to install GNU Octave ................................................................................ 184
11.8.
Simulation Process............................................................................................. 185
11.8.1.
VanetMobiSim Configuration file ...................................................................... 222
11.8.1.1.
General specifications ......................................................................................................... 223
11.8.2.
NS2 configuration file ........................................................................................ 225
11.8.3.
AWK script ......................................................................................................... 227
11.9.
CONFIDENCE INTERVALS ................................................................................... 228
REFERENCES AND BIBLIOGRAPHY..................................................................................... 230
9
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
INDEX OF FIGURES AND TABLES
Figures
Fig. 2-1 Architecture of a WSN .................................................................................................... 36
Fig. 2-2 Monitoring volcanic eruptions with a WSN [39] ............................................................. 38
Fig. 2-3 Wireless Vehicular Networks ......................................................................................... 40
Fig. 2-4 Application domains [66] ................................................................................................ 41
Fig. 2-5 Architecture on VANETs communication [13] ................................................................ 48
Fig. 2-6 Screenshot of STRAW with the enhanced visualization tool ......................................... 55
Fig. 2-7 Screenshot of MOVE ..................................................................................................... 56
Fig. 2-8 Screenshot of VanetMobiSim ........................................................................................ 57
Fig. 2-9 Screenshot of SUMO ..................................................................................................... 57
Fig. 3-1 WAVE architecture overview ......................................................................................... 62
Fig. 3-2 US distribution of DSRC spectrum ................................................................................. 64
Fig. 3-4 Default parameter settings for IEEE 802.11p queues ................................................... 66
Fig. 4-1 Small-scale fading distribution: (a) Rician (b) Rayleigh ............................................... 69
10
INDEX OF TABLES AND FIGURES
Fig. 5-1 Classification of routing protocols for MANETs and VANETs........................................ 72
Fig. 5-2 RREQ packet format ...................................................................................................... 75
Fig. 5-3 RREP packet format ...................................................................................................... 75
Fig. 5-4 Route discovering mechanism, a) Source node initiates path discovering sendig RREQ
message b) Node A broadcasts RREQ message to its neighbor nodes
c) Destiny
node unicasts a RREP message to node C in order to reach source node ............................... 76
Fig. 5-5 Data packet forwarding path .......................................................................................... 79
Fig. 5-6 GPSR Flowchart ............................................................................................................ 80
Fig. 5-7 Greedy Forwarding example. Y is x's closest neighbor to D. ........................................ 81
Fig. 5-8 Greedy Forwarding failure. w and y are farther from D than x ....................................... 82
Fig. 5-9 Node x's void with respect to destination D ................................................................... 82
Fig. 5-10 The right-hand rule. x revives a packet from y, and forwards it to z ............................ 83
Fig. 5-11 The RNG graph. For edge (u,v) to be included, the shaded lune must contain no
witness w ..................................................................................................................................... 84
Fig. 5-12 The GG graph. For edge (u,v) to be included, the shaded circle must contain no
witness w ..................................................................................................................................... 85
Fig. 7-1 VANET simulator based on coupling VanetMobiSim and NS2 [60] .............................. 94
Fig. 7-2 Colour code Simulation files .......................................................................................... 94
Fig. 7-3 Simulation process part 1............................................................................................... 95
Fig. 7-4 Simulation process part 2............................................................................................... 96
Fig. 7-5 Simulation process part 3............................................................................................... 97
Fig. 8-1 Scenarios a) Manhattan grid b) Urban random distribution c) Urban TIGER/Line
d) Highway TIGER/Line ............................................................................................................... 99
The full list of configuration files with the parameters of the simulation is showed in Annex. ... 101
Figure 9-1 Average Packet Delivery Ratio for transmission range of 100 m as a function of node
density ....................................................................................................................................... 105
Figure 9-2 Average Packet Loss Ratio for transmission range of 100 m as a function of node
density ....................................................................................................................................... 106
Figure 9-3 Average End-to-end Delay for transmission range of 100 m as a function of node
density ....................................................................................................................................... 107
Figure 9-4 Average Packet Delivery Ratio for transmission range of 150 m as a function of node
density ....................................................................................................................................... 108
Figure 9-5 Average Packet Loss Ratio for transmission range of 150 m as a function of node
density ....................................................................................................................................... 109
11
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Figure 9-4 Average End-to-end Delay for transmission range of 150 m as a function of node
density ....................................................................................................................................... 110
Figure 9-7 Average Packet Delivery Ratio for transmission range of 200 m as a function of node
desity ......................................................................................................................................... 111
Figure 9-8 Average Packet Loss Ratio for transmission range of 200 m as a function of node
density ....................................................................................................................................... 112
Figure 9-9 Average End-to-end Delay for transmission range of 200 m as a function of node
density ....................................................................................................................................... 113
Figure 9-10 Average Packet Delivery Ratio for transmission range of 250 m as a function of
node density .............................................................................................................................. 114
Figure 9-11 Average Packet Loss Ratio for transmission range of 250 m as a function of node
density ....................................................................................................................................... 115
Figure 9-12 Average End-to-end Delay for transmission range of 250 m as a function of node
density ....................................................................................................................................... 116
Figure 9-13 Average Packet Delivery Ratio for transmission range of 100 m as a function of
node speed ................................................................................................................................ 117
Figure 9-11 Average Packet Loss Ratio for transmission range of 100 m as a function of node
speed ......................................................................................................................................... 118
Figure 9-15 Average End-to-end Delay for transmission range of 100 m as a function of node
speed ......................................................................................................................................... 119
Figure 9-16 Average Packet Delivery Ratio for transmission range of 150 m as a function of
node speed ................................................................................................................................ 120
Figure 9-17 Average Packet Loss Ratio for transmission range of 150 m as a function of node
speed ......................................................................................................................................... 121
Figure 9-18 Average End-to-end Delay for transmission range of 150 m as a function of node
speed ......................................................................................................................................... 122
Figure 9-19 Average Packet Delivery Ratio for transmission range of 200 m as a function of
node speed ................................................................................................................................ 123
Figure 9-20 Average Packet Loss Ratio for transmission range of 200 m as a function of node
speed ......................................................................................................................................... 124
Figure 9-21 Average End-to-end Delay for transmission range of 200 m as a function of node
speed ......................................................................................................................................... 125
Figure 9-22 Average Packet Delivery Ratio for transmission range of 250 m as a function of
node speed ................................................................................................................................ 126
Figure 9-23 Average Packet Loss Ratio for transmission range of 250 m as a function of node
speed ......................................................................................................................................... 127
Figure 9-24 Average End-to-end Delay for transmission range of 250 m as a function of node
speed ......................................................................................................................................... 128
12
INDEX OF TABLES AND FIGURES
Figure 9-25 Average Packet Delivery Ratio for node density of 20 nodes/km 2 as a function of
transmission range .................................................................................................................... 129
Figure 9-26 Average Packet Loss Ratio for node density of 20 nodes/km 2 as a function of
transmission range .................................................................................................................... 130
Figure 9-27 Average End-to-end Delay for node density of 20 nodes/km 2 as a function of
transmission range .................................................................................................................... 131
Figure 9-28 Average Packet Delivery Ratio for node density of 25 nodes/km 2 as a function of
transmission range .................................................................................................................... 132
Figure 9-29 Average Packet Loss Ratio for node density of 25 nodes/km 2 as a function of
transmission range .................................................................................................................... 133
Figure 9-30 Average End-to-end Delay for node density of 25 nodes/km 2 as a function of
transmission range .................................................................................................................... 134
Figure 9-31 Average Packet Delivery Ratio for node density of 30 nodes/km 2 as a function of
transmission range .................................................................................................................... 135
Figure 9-32 Average Packet Loss Ratio for node density of 30 nodes/km 2 as a function of
transmission range .................................................................................................................... 136
Figure 9-33 Average End-to-end Delay for node density of 30 nodes/km 2 as a function of
transmission range .................................................................................................................... 137
Figure 9-34 Average Packet Delivery Ratio for node density of 35 nodes/km 2 as a function of
transmission range .................................................................................................................... 138
Figure 9-35 Average Packet Loss Ratio for node density of 35 nodes/km 2 as a function of
transmission range .................................................................................................................... 139
Figure 9-36 Average End-to-end Delay for node density of 35 nodes/km 2 as a function of
transmission range .................................................................................................................... 140
Figure 9-37 Average Packet Delivery Ratio for node density of 40 nodes/km 2 as a function of
transmission range .................................................................................................................... 141
Figure 9-38 Average Packet Loss Ratio for node density of 40 nodes/km 2 as a function of
transmission range .................................................................................................................... 142
Figure 9-39 Average End-to-end Delay for node density of 40 nodes/km 2 as a function of
transmission range .................................................................................................................... 143
Figure 9-40 Average Packet Delivery Ratio for node density of 45 nodes/km 2 as a function of
transmission range .................................................................................................................... 144
Figure 9-41 Average Packet Loss Ratio for node density of 45 nodes/km 2 as a function of
transmission range .................................................................................................................... 145
Figure 9-42 Average End-to-end Delay for node density of 45 nodes/km 2 as a function of
transmission range .................................................................................................................... 146
Figure 9-43 Average Packet Delivery Ratio for node density of 20 nodes/km 2 over time ........ 147
Figure 9-44 Average Packet Delivery Ratio for node density of 25 nodes/km 2 over time ........ 148
13
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Figure 9-45 Average Packet Delivery Ratio for node density of 30 nodes/km 2 over time ........ 149
Figure 9-46 Average Packet Delivery Ratio for node density of 35 nodes/km 2 over time ........ 150
Figure 9-47 Average Packet Delivery Ratio for node density of 40 nodes/km 2 over time ........ 151
Figure 9-48 Average Packet Delivery Ratio for node density of 45 nodes/km 2 over time ........ 152
Table 9-49 Average Packet Delivery Ratio for Rayleigh and Ricean model as a function of node
density ....................................................................................................................................... 154
Table 9-50 Average Packet Loss Ratio for Rayleigh and Ricean model as a function of node
density ....................................................................................................................................... 155
Table 9-51 Average End-to-end Delay for Rayleigh model as a function of node density ....... 156
Fig. 11-1 Terminal message after executing ant patch ............................................................. 162
Fig. 11-2 Terminal message after executing ant all .................................................................. 162
Fig. 11-3 VanetMobiSim XML file .............................................................................................. 222
Fig. 11-4 VanetMobiSim shell launching ................................................................................... 224
Fig. 11-5 NS2 script - DEFINE OPTIONS ................................................................................. 225
Fig. 11-6 NS2 script - MAIN PROGRAM ................................................................................... 226
Fig. 11-7 NS2 shell launching ................................................................................................... 226
Fig. 11-8 AWK script ................................................................................................................. 227
Fig. 11-9 AWK shell launching .................................................................................................. 227
Fig. 11-10 Example of confident interval ................................................................................... 228
Tables
Table 2-1 Comparison of Vehicular Traffic Models ..................................................................... 58
Table 3-1 Comparison of the used IEEE 802.11 standards for VANET environment ................ 61
Table 3-2 Comparison of the PHY layer implementation in IEEE 802.11a and IEEE 802.11p .. 65
Table 5-1 Comparative AODV vs DSR ....................................................................................... 77
Table 8-1 Scenario features overview ....................................................................................... 100
Table 8-2 Simulation features overview .................................................................................... 101
Table 9-1 Average Packet Delivery ratio for transmission range of 100 m as a function of node
density ....................................................................................................................................... 105
Table 9-2 Average Packet Loss Ratio for transmission range of 100 m as a function of node
density ....................................................................................................................................... 106
14
INDEX OF TABLES AND FIGURES
Table 9-3 Average End-to-end Delay for transmission range of 100 m as a function of node
density ....................................................................................................................................... 107
Table 9-3 Average Packet Delivery Ratio for transmission range of 150 m as a function of node
density ....................................................................................................................................... 108
Table 9-4 Average Packet Loss Ratio for transmission range of 150 m as a function of node
density ....................................................................................................................................... 109
Table 9-6 Average End-to-end Delay for transmission range of 150 m as a function of node
density ....................................................................................................................................... 110
Table 9-7 Average Packet Delivery Ratio for transmission range of 200 m as a function of node
density ....................................................................................................................................... 111
Table 9-8 Average Packet Loss Ratio for transmission range of 200 m as a function of node
density ....................................................................................................................................... 112
Table 9-9 Average End-to-end Delay for transmission range of 200 m as a function of node
density ....................................................................................................................................... 113
Table 9-10 Average Packet Delivery Ratio for transmission range of 250 m as a function of
node density .............................................................................................................................. 114
Table 9-11 Average Packet Loss Ratio for transmission range of 250 m as a function of node
density ....................................................................................................................................... 115
Table 9-12 Average End-to-end Delay for transmission range of 250 m as a function of node
density ....................................................................................................................................... 116
Table 9-13 Average Packet Delivery Ratio for transmission range of 100 m as a function of
node speed ................................................................................................................................ 117
Table 9-14 Average Packet Loss Ratio for transmission range of 100 m as a function of node
speed ......................................................................................................................................... 118
Table 9-15 Average End-to-end Delay for transmission range of 100 m as a function of node
speed ......................................................................................................................................... 119
Table 9-16 Average Packet Delivery Ratio for transmission range of 150 m as a function of
node speed ................................................................................................................................ 120
Table 9-17 Average Packet Loss Ratio for transmission range of 150 m as a function of node
speed ......................................................................................................................................... 121
Table 9-18 Average End-to-end Delay for transmission range of 150 m as a function of node
speed ......................................................................................................................................... 122
Table 9-19 Average Packet Delivery Ratio for transmission range of 200 m as a function of
node speed ................................................................................................................................ 123
Table 9-20 Average Packet Loss Ratio for transmission range of 200 m as a function of node
speed ......................................................................................................................................... 124
Table 9-21 Average End-to-end Delay for transmission range of 200 m as a function of node
speed ......................................................................................................................................... 125
15
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Table 9-22 Average Packet Delivery Ratio for transmission range of 250 m as a function of
node speed ................................................................................................................................ 126
Table 9-23 Average Packet Loss Ratio for transmission range of 250 m as a function of node
speed ......................................................................................................................................... 127
Table 9-24 Average End-to-end Delay for transmission range of 250 m as a function of node
speed ......................................................................................................................................... 128
Table 9-25 Average Packet Delivery Ratio for node density of 20 nodes/km 2 as a function of
transmission range .................................................................................................................... 129
Table 9-26 Average Packet Loss Ratio for node density of 20 nodes/km 2 as a function of
transmission range .................................................................................................................... 130
Table 9-27 Average End-to-end Delay for node density of 20 nodes/km 2 as a function of
transmission range .................................................................................................................... 131
Table 9-28 Average Packet Delivery Ratio for node density of 25 nodes/km 2 as a function of
transmission range .................................................................................................................... 132
Table 9-29 Average Packet Loss Ratio for node density of 25 nodes/km 2 as a function of
transmission range .................................................................................................................... 133
Table 9-30 Average End-to-end Delay for node density of 25 nodes/km 2 as a function of
transmission range .................................................................................................................... 134
Table 9-31 Average Packet Delivery Ratio for node density of 30 nodes/km 2 as a function of
transmission range .................................................................................................................... 135
Table 9-32 Average Packet Loss Ratio for node density of 30 nodes/km 2 as a function of
transmission range .................................................................................................................... 136
Table 9-33 Average End-to-end Delay for node density of 30 nodes/km 2 as a function of
transmission range .................................................................................................................... 137
Table 9-34 Average Packet Delivery Ratio for node density of 35 nodes/km 2 as a function of
transmission range .................................................................................................................... 138
Table 9-35 Average Packet Loss Ratio for node density of 35 nodes/km2 as a function of
transmission range .................................................................................................................... 139
Table 9-36 Average End-to-end Delay for node density of 35 nodes/km 2 as a function of
transmission range .................................................................................................................... 140
Table 9-37 Average Packet Delivery Ratio for node density of 40 nodes/km 2 as a function of
transmission range .................................................................................................................... 141
Table 9-38 Average Packet Loss Ratio for node density of 40 nodes/km 2 as a function of
transmission range .................................................................................................................... 142
Table 9-39 Average End-to-end Delay for node density of 40 nodes/km 2 as a function of
transmission range .................................................................................................................... 143
Table 9-40 Average Packet Delivery Ratio for node density of 45 nodes/km2 as a function of
transmission range .................................................................................................................... 144
16
INDEX OF TABLES AND FIGURES
Table 9-41 Average Packet Loss Ratio for node density of 45 nodes/km 2 as a function of
transmission range .................................................................................................................... 145
Table 9-42 Average End-to-end Delay for node density of 45 nodes/km 2 as a function of
transmission range .................................................................................................................... 146
Table 9-43 Average Packet Delivery Ratio for node density of 20 nodes/km 2 over time ......... 147
Table 9-44 Average Packet Delivery Ratio for node density of 25 nodes/km 2 over time ......... 148
Table 9-45 Average Packet Delivery Ratio for node density of 30 nodes/km 2 over time ......... 149
Table 9-46 Average Packet Delivery Ratio for node density of 35 nodes/km 2 over time ......... 150
Table 9-47 Average Packet Delivery Ratio for node density of 40 nodes/km 2 over time ......... 151
Table 9-48 Average Packet Delivery Ratio for node density of 45 nodes/km 2 over time ......... 152
Table 9-49 Average Packet Delivery Ratio for Rayleigh and Ricean model as a function of node
density ....................................................................................................................................... 154
Table 9-50 Average Packet Loss Ratio for Rayleigh and Ricean model as a function of node
density ....................................................................................................................................... 155
Table 9-51 Average End-to-end Delay for Rayleigh and Ricean model as a function of node
density ....................................................................................................................................... 156
17
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
GLOSSARY OF ACRONYMS
ACK
ACKnowledgment
ADAS
Advanced Driver Assistance Services
ADV
Adaptative Distance Vector
AIFS
Arbitration Interframe Space
AODV
Ad-hoc On-demand Distance Vector
AWK
Aho Weinberg Brian
BSS
Basis Service Set
BPSK
Binary Phase-Shift Keying
CALM
Communication Architecture for Land Mobile environment
CANUMOBISIM
Communications in Ad Hoc Networks for Ubiquitous computing Mobility
Simulator
CBR
Constant Bit Rate
CCH
Control Channel
CW
Contention Window
DARPA
Defense Advanced Research Projects Agency
DCF
Distributed Coordination Function
DNT
Delay Tolerant Network
DSDV
Dynamic Destination-Sequenced Distance-Vector
18
GLOSSARY OF ACRONYMS
DSR
Dynamic Source Routing
DSSS
Direct-Sequence Spread Spectrum
DSRC
Dedicated Short-Range Communications
E2E
End-to-End
ECC
Electronic Communications Committee
EDCA
Enhanced Distributed Channel Access
EIRP
Equivalent Isotropically Radiated Power
FCC
Federal Communication Commission
GDF
Geographic Data Files
GOSR
Geographical Opportunistic Source Routing
GPSR
Greedy Perimeter Stateless Routing
GSM
Global System for Mobile communications
GSR
Geographical Source Routing
GTS
Global System of Telematics
GUI
Graphical User Interface
IEEE
Institute of Electrical and Electronic Engineers
IDM
Intelligent Driving Model
IDM_IM
Intelligent Driving Model with Intersection Management
IDM_LC
Intelligent Driving Model with Lane Changing
IMM
Integrated Mobility Model
IP
Internet Protocol
ISM
Industrial Scientific Medial
ISO
International Organization for Standardization
ITS
Intelligent transportation system
LAGAD
Location-Aided Gateway Advertisement and Discovery
LAN
Local Area Network
LOS
Line of Sight
MAC
Medium Access Control
MANET
Mobile Ad hoc NETwork
MLME
MAC Layer Management Entity
MOVE
MObility model generator for VEhicular networks
NCTUns
National Chiao Tung University Network Simulator
NS2
Network Simulator
OBU
On Board Unit
19
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
OFDM
Orthogonal Frequency-Division multiplexing
OLSR
Optimized Link State Routing
OTCL
Object-oriented Tool Command Language
PAN
Personal Area Network
PDA
Personal Digital Assistant
PDF
Probability Density Function
PLME
Physical Layer Management Entity
POI
Point Of Interest
QAM
Quadreture Amplitude Modulation
QoS
Quality of Service
QPSK
Quadrature Phase-Shift Keying
RDPR
Received Data Packet Ratio
RERR
Router Error
RREP
Route Reply
RREQ
Route Request
RSE
Road Side Equipment
RSU
RoadSide Unit
SCH
Service Channel
SIFT
Simple Forwarding over Trajectory
SUMO
Simulation of Urban Mobility
TCL
Tool Command Language
TCP
Transfer Control Protocol
TIGER
Topologically Integrated Geographic Encoding and Referencing
TTL
Time To Live
UDP
User Datagram Protocol
UMTS
Universal Mobile Telecommunication System
V2V
Vehicle to Vehicle
VANET
Vehicular Ad-hoc NETwork
VANETMOBISIM Vehicular Ad-hoc NETwork Mobility Simulator
VINT
Virtual InterNetwork Testbed
WAVE
Wireless Access for Vehicular Environment
WBSS
WAVE Basis Service Set
WLAN
Wireless Local Area Network
WSN
Wireless Sensor Network
20
GLOSSARY OF ACRONYMS
XML
eXtensible Markup Language
ZRP
Zone Routing Protocol
21
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
ABSTRACT
VANETs (Vehicular Ad-hoc Networks) are an emerging new technology which integrates the
capabilities of new generation wireless networks to vehicles. It includes a variety of
applications such as co-operative traffic monitoring, control of traffic flows, blind crossing,
prevention of collisions, nearby information services, and real-time detour routes
computation. Another important application for VANETs is providing Internet connectivity to
vehicular nodes while on the move, so that passengers can download music, send emails, book
a restaurant or play games. Because of the high nodes mobility and unreliable channel
conditions, VANETs have unique characteristics which pose many challenging research issues.
This work is mainly focused on a key networking problem: routing protocol for VANETs. The
main requirement of routing protocols is to achieve minimal communication time with
minimum consumption of network resources. Many routing protocols have been developed
for MANETs (Mobile Ad-hoc Networks), such as AODV (Ad-hoc On demand Distance Vector)
[65] and DSR (Dynamic Source Routing) [45]. However, VANETs differ from MANETs by their
highly dynamic topology. A number of studies have been done to simulate and compare the
performance of those routing protocols in various traffic conditions in VANETs. Simulation
results showed that MANET routing protocols suffer from poor performances because of the
characteristics of fast vehicle's movement, dynamic information exchange and relative high
speed of mobile nodes.
22
ABSTRACT
This text aims to continue the work of Roger Calzada in his final degree thesis [98]. In that
thesis, AODV was the routing protocol used during the simulation process to evaluate its
performance over VANETs. The conclusion of the thesis was that AODV is not the best routing
protocol to handle high mobility of nodes and short duration of routes. He proposed as future
work the evaluation of existing routing protocol which considers car position, trajectories or
speeds gathered via GPS (Global Positioning System) that could lead to better results.
To consider the vehicle network, people can intuitively think to use the geographical position
information to decide the route. Most position based routing algorithms base forwarding
decision on location information. GSR (Geographical Source Routing) [92] is a promising
routing technique for VANETs and recently several routing protocols have been proposed
based on it. For example, GPSR (Greedy Perimeter Stateless Routing) [90] is one of the best
known position-based protocols in literature.
Basically, our project is divided in two parts: First, we make a state of the art related to the
VANETs in order to find the most appropriate and recommended mobility generator and
network simulator reported in literature. We also include at the end of this part the
description of GPSR routing protocol. Second, from the research done in the previous part, we
use VanetMobiSim [80] as a mobility generator due to its variety models that could be tested;
and NS2 [93] as a network simulator for being one of the most used by many authors and also
due to its compatibility with VanetMobiSim. Using these tools, VanetMobiSim and NS2, we
carry out a performance evaluation of two routing protocols (AODV and GPSR) over VANETs.
We give different values to parameters such as the number of nodes, speed, transmission
range and different propagation models. Finally, we analyse and discuss the benefits of GPSR
compared to AODV in vehicular scenarios.
23
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
RESUMEN
VANETs (Vehicular Ad-hoc Networks) son una emergente nueva tecnología que integra las
capacidades de la nueva generación de redes wireless con los vehículos. Incluye una gran
variedad de aplicaciones tales como la monitorización cooperativa del trafico, el control del
transito, la asistencia en cruces ciegos, la prevención de colisiones, la búsqueda de información
de servicios cercanos y el cálculo en tiempo real de rutas entre otras muchas. Otra aplicación
importante para VANETs es la de proveer de conexión a Internet a los vehículos mientras se
mueven, de manera que el pasajero puede descargar música, enviar emails, reservar un
restaurante o jugar a videojuegos. Debido a la alta movilidad de los nodos y a las poco fiables
condiciones del canal, las redes VANET tienen unas características únicas que plantean muchas
cuestiones que son un reto para la investigación.
Este trabajo esta principalmente centrado en la clave del diseño e implementación de redes: El
protocolo de enrutado para VANETs. El requerimiento principal para un protocolo de enrutado
es lograr establecer una comunicación en el mínimo tiempo posible con el mínimo consumo de
recursos de la red. Muchos protocolos de enrutado se han desarrollado para MANETs (Mobile
Ad-hoc Networks), tales como ADV (Ad-hoc On demand Distance Vector) [65] y DSR (Dynamic
Source Routing) [45]. Sin embargo, las redes VANET difieren de las MANET en el alto
dinamismo de su topología. En un gran número de estudios se han simulado y comparado las
prestaciones de estos protocolos de enrutado en diferentes condiciones de tráfico para
VANETs. Los resultados de las simulaciones han mostrado que los protocolos de enrutado
propios de MANET sufren de pobres prestaciones debido a las características de alta velocidad
24
ABSTRACT
de movimiento y dinamismo en el intercambio de información provocado por la alta velocidad
de los nodos móviles.
Este texto pretende continuar con el trabajo iniciado por Roger Calzada en su proyecto final de
carrera [98]. En este trabajo, AODV fue el protocolo de enrutado utilizado durante el proceso
de simulación para evaluar las prestaciones sobre VANETs. La conclusión a la que se llegó fue
que AODV no era el mejor protocolo de enrutado para manejar la alta movilidad de los nodos y
la corta duración de las rutas. Él propuso como trabajo futuro la evaluación de otros
protocolos de enrutado existentes que tienen en cuenta la posición de los vehículos, las
trayectorias y sus velocidades vía GPS (Global Positioning System) que podrían conducir a unos
mejores resultados.
Al considerar las redes de vehículos, la gente puede pensar de forma intuitiva en el uso de la
información de la posición geográfica para decidir la ruta. La mayoría de los algoritmos de
enrutado basados en la posición basan su decisión de renvío en la localización del vehículo.
GSR (Geographical Source Routing) [92] es una prometedora técnica de enrutado para VANETs
y recientemente se han propuesto muchos protocolos de enrutado basados en ella. Por
ejemplo, GPSR (Greedy Perimeter Statless Routing) [90] es uno de los mas conocidos
protocolos basados en la posición de la literatura.
Nuestro proyecto se divide básicamente en dos partes: Una primera parte donde hacemos un
resumen del estado actual de las redes VANET con el objetivo de encontrar el más apropiado y
recomendado generado de patrones de movilidad y simulador de red del que se informa en la
literatura. También incluimos al final de este apartado la descripción del protocolo de
enrutado GPSR. En la segunda parte, como consecuencia de la investigación de la primera
parte, usamos VanetMobisim [80] como generador de patrones de movimiento debido a la
gran variedad de modelos que se pueden utilizar; y NS2 como simulador de red por ser uno de
los mas utilizados por muchos autores y también debido a su compatibilidad con
VanetMobisim. Usando estas herramientas, VanetMobisim y NS2, llevamos a cabo una
evaluación de las prestaciones de dos protocolos de enrutado (AODV y GPSR) sobre VANETs.
Para ello variamos los valores de diferentes parámetros tales como el número de nodos, la
velocidad, el rango de transmisión y el modelo de propagación. Finalmente, Analizamos y
examinamos los beneficios de GPSR comparado con AODV en escenarios de vehículos.
25
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
RESUM
VANETs (Vehicular Ad-hoc Networks) son una emergent i nova tecnologia que integra les
capacitats de la nova generació de xarxes wireless amb els vehicles. Inclou una gran varietat
d’aplicacions com poden ser la monitorització cooperativa del tràfic, el control del transit,
l’assistència en encreuaments cecs, la prevenció de col·lisions, la recerca d’informació de
serveis propers y el càlcul en temps real de rutes entre moltes altres. Una altra aplicació
important per a VANETs es la de proveir de connexió a Internet als nodes vehiculars mentre es
mouen, de forma que el passatger pot descarregar musica, enviar emails, o jugar a videojocs.
Degut a l’alta mobilitat dels nodes i a les poc fiables condicions del canal, les xarxes VANET
tenen unes característiques úniques que plantegen moltes qüestions que son un repte per a la
recerca.
Aquest treball esta principalment centrat en la clau del disseny i implementació de les xarxes:
El protocol d’encaminament per a VANETs. El requeriment principal per a un protocol
d’encaminament es aconseguir establir una comunicació en el mínim temps possible amb el
mínim consum de recursos de la xarxa. Molts protocols d’encaminament s’han desenvolupat
per MANETs (Mobile Ad-hoc Networks), com ara AODV (Ad-hoc On demand Distance Vector)
[65] i DSR (Dynamic Source Routing) [45]. No obstant això, les xarxes VANET difereixen de les
MANET en l’alt dinamisme de la seva topologia. En un gran nombre d’estudis s’han simulat i
comparat les prestacions d’aquests protocols d’encaminament en diferents condicions de
tràfic per VANETs. Els resultats de les simulacions han mostrat que els protocols
d’encaminament propis de MANET pateixen de pobres prestacions degut a les característiques
26
ABSTRACT
de alta velocitat de moviment y dinamisme en l’intercanvi d’informació provocat per l’alta
velocitat dels nodes mòbils.
Aquest text pretén continuar el treball iniciat per Roger Calzada en el seu projecte final de
carrera [98]. En aquest treball, AODV va ser el protocol d’encaminament utilitzat durant el
procés de simulació per avaluar les prestacions sobre VANETs. La conclusió del projecte va ser
que AODV no era el millor protocol d’encaminament per gestionar l’elevada mobilitat dels
nodes i la curta duració de les rutes. Ell va proposar com a treball futur l’avaluació d’altres
protocols d’encaminament existents que tenen en compte la posició dels vehicles, les
trajectòries i les seves velocitats via GPS (Global Positioning System) que podrien conduir a uns
millors resultats.
Al considerar les xarxes de vehicles, la gent pot pensar de forma intuïtiva en la utilització de la
informació de la posició geogràfica per decidir la ruta. La majoria dels algoritmes
d’encaminament basats en la posició basen la decisió de reenviament en la localització del
vehicle. GSR (Geographical Source Routing) [92] es una prometedora tècnica d’encaminament
per VANETs i recentment s’han proposat molts protocols d’encaminament basats en ella. Per
exemple, GPSR (Greedy Perimeter Statless Routing) [90] es un dels més coneguts protocols
basats en la posició de la literatura.
El nostre projecte es divideix bàsicament en dos parts: Una primera part on fem un resum de
l’estat actual de les xarxes VANET amb l’objectiu de trobar el mes apropiat y recomanat
generador de patrons de mobilitat i simulador de xarxa del que s’informa a la literatura. També
incloem al final d’aquesta part la descripció del protocol d’encaminament GPSR. En la segona
part, com a conseqüència de la recerca de la primera part, utilitzem, VanetMobisim [80] com a
generador de patrons de moviment degut a la gran varietat de models que es poden utilitzar; y
NS2 com a simulador de xarxa per ser un dels mes utilitzats per molts autors i també per la
seva compatibilitat amb VanetMobisim. Utilitzant aquestes eines, VanetMobisim i NS2, portem
a terme una avaluació de les prestacions de dos protocols d’encaminament (AODV i GPSR)
sobre VANETs. Per això variem els valors de diferents paràmetres com ara el numero de nodes,
la velocitat, el rang de transmissió y el model de propagació. Finalment, analitzem i examinem
els beneficis de GPSR comparat amb AODV en escenaris de vehicles.
27
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
1. INTRODUCTION AND GOALS
Due to vehicle traffic accidents, the estimated number of deaths is about 1.2 million people
yearly worldwide and of injuries are about forty times of the previous number, without
forgetting the traffic congestion that makes a huge waste of time and fuel. With the
developments in wireless communications technology, the concept of VANETs (Vehicular Ad
hoc Network) has taken the attention all over the world. Such network is expected to be one
of the most valuable technology for improving efficiency and safety of the future
transportations. Thus, several on-going research projects supported by industry, governments
and academia, have established standards for VANETs.
In the recent years, many new projects have been proposed trying to evaluate vehicular
networks. The ideal evaluations for any network (e.g. VANETs) development and evaluation
related to protocols and applications is to implement it in a real experiment. However, this
solution has many drawbacks, such as the required expensive investment that could cost
implementing such experiment. An alternative evaluation that could achieve similar results as
in the real experiment is the use of simulation tools. A vehicular traffic generator and a
network simulator must be coupled in order to generate complete and realistic simulations of
VANETs. In this project, we have decided to use VanetMobiSim [80] as a mobility generator,
which has a wide variety of driver behaviour models and almost realistic road layouts. The
network simulator used is NS2 [93], a discrete network simulator with total compatibility with
VanetMobiSim, that already includes the protocol stuck needed in VANETs.
28
INTRODUCTION AND GOALS
With this two simulators, we will carry out a performance evaluation of urban scenarios using
VANETs in terms of received packet rate, average number of hops, average end-to-end delay
and data throughput using different simulation settings and scenarios.
The project consists of 11 chapters. Chapter 2 introduces the concept of MANET (Mobile Adhoc networks), VANET (Vehicular Ad-hoc Network) and the most known mobility generators
and traffic generators used in vehicular networks. Chapter 3 describes the WAVE (Wireless
Access for Vehicular Environments), a new set of standards which has been developed for
vehicular environment. In Chapter 4 different propagation models are described for urban
environment. Chapter 5 summarizes the different routing protocols available in ad hoc
networks emphasizing in AODV (Ad-hoc On demand Distance Vector) [65] and GPSR (Greedy
Perimeter Stateless Routing) [90], the used routing protocols in this project. Chapter 6 includes
an overview of the simulation tools used in the project. Chapter 7 summarizes the simulation
process. Chapter 8 includes a description of the simulations settings. Chapter 9 summarizes
the results obtained after a whole simulation process. Chapter 10 outlines the main
conclusions and gives a proposal for future lines of work. Finally, Chapter 11 includes several
annexes which are expected to be complementary to the previous chapters.
29
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
2. INTRODUCTION TO MOBILE AND
VEHICULAR NETWORKS
Over recent years, the considerable mobile services sector growth around the world was
certainly the major phenomenon in the telecommunications field. Wireless technology is
capable of reaching virtually every location on the surface of the earth. With such success of
mobile communication demand it is hardly surprising that wireless technology has led to the
development of new multimedia services and to evolution in user requirements in terms of
throughput and universal mobility throughout different systems. Mobile communications are
already applied to the realm of personal and business computing, making that people living
habits and working ways evolve [48].
Generally there are two distinct approaches for enabling wireless mobile units to communicate
each other:
Infrastructured or centralized networks: Wireless mobile networks have traditionally been
based on the cellular concept, where all the devices are connected to a central node which is
the acting agent for all communications, and relied on good infrastructure support. Typical
examples of this kind of wireless networks are GSM, UMTS, WLAN, etc.
Infrastructureless: As to infrastructureless approach, the mobile wireless network is
commonly known as a mobile ad hoc networks or MANETs. A MANET is a collection of wireless
nodes that can dynamically be set up anywhere and anytime without using a pre-existing
network infrastructure. It is an autonomous system in which mobile host connected by
wireless links are free to move randomly and often act as routers at the same time.
30
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
The design of network protocols for MANETs is a complex and wide area of research with
many challenges. Hence, during the last few years, mobile ad hoc networks have become a
very popular field of study within the research community.
In the next section a more detailed description of MANETs is presented, including its main
features, challenges and an introduction of two well-known applications: WSNs and VANETs.
Their properties and current deployments are also discussed.
2.1. Introducing MANETs (Mobile Ad hoc NETworks)
A MANET is a collection of wireless devices than can dynamically form a network with a very
simple deployment capability, paving the way for new applications which have not been able
to emerge until now and offers solutions in multiple environments that have no infrastructure.
These devices or nodes can move in a random way and are capable to self-organize themselves
arbitrarily, collaborating in order to communications succeed. Examples of devices are laptops,
PDAs, mobile phones, handhelds and wearable computers. The most outstanding features of
MANETS are detailed below:
Dynamic network topology
The dynamically network topology is undoubtedly the element characterizing in MANETs.
Since the nodes are mobile, the network topology may change rapidly and unpredictably and
the connectivity among the terminal may vary with time. MANETs should adapt to the traffic
and propagation conditions as well as the mobility patterns of the mobile networks nodes.
Autonomous terminals and self-organization
In MANETs, each mobile terminal is an autonomous node, which may function as both a host
and a router and are responsible for dynamically discovering other nodes to communicate or
handle the network configuration e.g. addressing, and position location issues.
Distributed operation
Since there is no background network for the central control of the network operations, the
control management of the network is distributed among the devices. The nodes involved in a
MANET should collaborate each other and act as a relay as needed, to implement routing and
security functions.
Multi-hop routing
As delivering data packets from a source to its destination out of the direct wireless
transmission range, the packets should be forwarded via one or more intermediate node.
Fluctuating link-capacity
31
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
The nature of high bit-error rates of wireless connections might be more critical in a MANET.
The radio transmission rate is vulnerable to noise, fading, multiple access and interference
conditions, and has less bandwidth than wired networks.
Light-weight terminal
In most cases, the MANET nodes are mobile devices with limited processing capability, small
memory size and low power storage. Such devices need optimized algorithms to execute
computing and communicating functions.
Scalability
Sometimes the number of devices which set up the network can increase until dozens or
hundreds. Since there is no a central element which is in charge of network management,
adding or rejecting nodes into the topology is a simple process.
2.2. Challenges in MANETs
Regardless of MANETs capabilities, possibilities and characteristics have risen a quickly
spreading, that benefits lead to several challenges as well, which must be studied carefully.
Researching in the area of mobile ad hoc networking is receiving more attention from
academia, industry, and government during the last few years. Almost every aspect of the
network has been explored in some level of detail although no ultimate resolution to any of
the problems is found yet and there are already many open issues for research and significant
contributions.
2.2.1. Scalability Weakness
The number of network nodes can be large and finding route to a destination also requires
frequent exchange of routing control information among the nodes. Thus, the amount of
update traffic can be substantial, and it is even higher when nodes with increased mobility are
present.
2.2.2. Routing
Routing in ad hoc networks, which is quite different from traditional IP routing, is a particularly
complex problem because of many factors including topology, selection of routers, locations of
request initiator, resource limitations and unreliability of wireless links. A node at least needs
to know the reachability information to its neighbors for determinate a packet route, while the
network topology can change quite often in a MANET. Thus, routes may change while in use
and become no longer valid in a very short time [67].
Since the arrival of ad hoc network concepts, many proposals have been studied, simulated
and evaluated. The same proposals have led to variations, specializations to given
32
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
environments and optimizations. Ad hoc routing proposals can be classified into two main
categories: proactive and reactive routing. Proactive or table-driven protocols are directly
inspired by routing protocols deployed in the Internet and consist of maintaining a routing
table for sending data to any node in the network. Instead, ad hoc reactive routing algorithms
research the vital information of a route between two nodes when a request for this route is
expressed by the higher protocol layers. The protocol of this class attempt to keep the routes
used and only those as up to date as possible in order to minimize the use of control messages
to a minimum to save bandwidth. We can add other generally hybrid proposals to these two
families, which includes both features. These categories are presented in more detailed in
Chapter 4.
2.2.3. Security
Research on security in addition to routing challenges has become a primary concern to mobile
ad hoc networks. Historically, network security has adopted a centralized, largely protective
paradigm to satisfy aforementioned requirements. This is effective because the privileges of
every node in the network are managed by dedicated machines, e.g. authentication servers.
Membership in such a network allows individual nodes to operate in an open fashion because
it is simplicity guaranteed that any malicious user from outside world will not be allowed
access. Although these solutions have been considered very early in the evolution of ad hoc
networks, attempts to adapt similar client-server solutions to a decentralized environment
have largely been ineffective.
Attempts to secure ad hoc networks must be ad hoc: they must establish security without
reference to centralized. Instead, security paradigms should be carried out by the cooperation
of all available nodes in the network.
An implementation of an inefficient authentication protocol in ad hoc networks may lead to a
vulnerability increase and network will be compromised. Attacks from malicious nodes could
range from message replay, passive eavesdropping to injecting erroneous messages or liable
information into routing tables in order to make network congestion and denials of service by
forwarding traffic to a black hole. Hence, security solutions need to consider malicious attacks
not only from outside but also from within the network. So, key management and
authentication procedure are issues that must be carefully considered.
2.2.4. Quality of Service (QoS)
As a wired network, the flows generated by applications supported by mobile ad hoc networks
have diverse characteristics such as type and the volume of exchanged information, duration
of interaction to name a few examples. These flows also have different QoS requirements:
bandwidth requirements for video on demand or end-to-end requirements for voice over IP
services. That is why uniform packet processing is not appropriate, and QoS support which
considers the different QoS requirements is vital.
33
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
In MANETs, the dynamic networks environment with continuous topology changes and the
limited resources raise that problem of QoS support at different levels [48].
2.2.5. Energy-constrained operations
Some or all of the nodes in an ad hoc network may rely on batteries or other exhaustible
means for their energy. Therefore, energy conservative networks are becoming extremely
popular within the ad hoc networking research.
The goals can be achieved either by developing better batteries, or by focusing on the devices’
networks interface, which is often the single largest consumer of power.
Energy efficiency at the network interface can be improved by developing
transmission/reception technologies on the physical layer, but especially with specific
networking algorithms. Nevertheless, energy conservation is currently being addressed in
every layer of the protocol stack.
Much research has been carried out yet, however, there are still much more work to be done
[48].
2.2.6. Interoperation
The self-organization of ad hoc networks is a challenge when two independently formed
networks come physically close to each other. This is an unexplored research topic that has
implications on all levels on the system design. The issue of joining two networks is not trivial:
the networks may be using different synchronization, or even different MAC, routing or
security protocols.
Another important issue comes into picture when we talk about all wireless networks. One of
the most important aims of recent research on all wireless networks is to provide seamless
integration of all types of networks. The issue raises questions on how the ad hoc network
could be designed so that they are compatible with, for instance, wireless LANs, 3G and 4G
cellular networks [67].
2.3. Applications of MANETs
With the increase of portable devices as well as progress in wireless communication, ad hoc
networking is gaining importance with the number of widespread applications. Ad hoc
networking can be applied anywhere where there is little or no communication infrastructure
or the existing infrastructure is expensive or inconvenient to use. Ad hoc networking allows the
devices to maintain connections to the network as well as easily adding and removing devices
to and from the network. The set of applications for MANETs is diverse, some well-known are
[67]:
34
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
2.3.1. Community Networking
For some business scenarios, the need for collaborative computing might be more important
outside office environments than inside a building. After all, it is the case where people do
need to have outside meetings to cooperate and exchange information on a given project. It is
also an interesting solution for neighborhood scenarios, stadiums, museums or airports.
2.3.2. Crisis-management applications
That includes emergency or rescue operations, as a result of natural disasters where the entire
communications infrastructure is in disarray or inoperative (Tsunamis, hurricanes). Restoring
communications quickly is essential. By using ad hoc networks, an infrastructure could be set
up in hours instead of days/week required for wire-line communications.
2.3.3. Personal Area Networking
A personal area network (PAN) is a short-range, localized network where nodes are usually
associated with a given person. Bluetooth is an example of a technology aimed at supporting
PANs by eliminating the need of wires between devices such as printers, cell phones and PDAs
or laptop computers so on.
2.3.4. Military battlefield applications
MANETs networking was created for military purposes. Ad hoc networking would allow the
military to take advantage of commonplace network technology to maintain an information
network between the soldiers, vehicles, and military information head quarters.
Besides of these applications, two fields of study have become very interesting within the
research community: wireless sensor networks and vehicular ad hoc networks. VANETs are
introduced in section 2.3 whereas the special features and advantages of WSN are detailed
below.
2.4. Wireless Sensor Networks (WSN)
In recent years, advances in wireless networking, micro-fabrication and integration and
embedded microprocessors have enabled a new technological vision possible: wireless sensor
networks. WSN consist of a large number of sensor nodes which collect data and interoperate
each other to carry out functions involving some kind of tracking, monitoring or controlling. A
sensor node is basically a device that converts a sensed attributed (such as temperature or
vibrations) into a form understandable by the users. It consist of a transducer to sense a given
physical quantity with a predefined precision, an embedded processor for local processing,
small memory unit for storage and a wireless transceiver to transmit or receive data.
WSNs, which are considered as a special case of a MANET with reduced or no mobility, are
expected to find increasing deployment in coming years, as they enable reliable monitoring
and analysis of unknown and untested environments.
35
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Development of wireless sensor networks was motivated by military applications such as
battlefield surveillance and is now used in a variety of physical phenomena of interest:
monitoring pedestrian or vehicular traffic in human-aware environments, report wildlife
habitat conditions for environmental conservation, detect forest fires to aid rapid emergency
response and monitoring industrial process or healthcare applications [89].
Fig. 2-1 Architecture of a WSN
2.4.1. Properties
The advancement in technology has made it possible to have a network of hundreds or even
thousands of extremely small devices equipped with programmable computing and sensing
and wireless communications capability, enhancing the reliability and the coverage area. Some
of the features and challenges of WSN are as follows.
Easy of deployment
These wireless sensors can be deployed (dropped from a plane or placed in a factory) at the
site of interest without any prior organization, thus reducing the installation cost and time, and
also increasing the flexibility of deployment.
Fault tolerant
With macro-sensors, the failure of one node makes that area completely unmonitored until it
is replaced. With wireless sensors, failure of one node does not affect the networks operation
substantially as there are other adjacent nodes collecting similar data. At most, the accuracy of
data collected may be somewhat reduced.
Networking and security implementation
Sensor nodes have limited computing power and therefore may not be able to run
sophisticated network protocols or authentications and encryption algorithms contrary to ad
hoc networks, leading to light weighted and simple versions of routing protocols and security
36
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
implementations. Besides, two operational modes or states are defined for each node,
awakened mode and slept mode, if the node must be active or not active, so the protocols and
algorithm implementations must take into account this limitation too.
Data centric
In traditional networks, data is requested from a specific node. WSN are data centric, data is
requested based on certain attributes. An attribute-based address is composed of a set of
attribute-value pair query. For instance, if the query is something like temperature >35º, then
only those device sensing temperature >35º need to respond and report their readings and
other sensor can remain in the slept state. Once a event of interest is detected, the system
should be able to configure itself so as to obtain high quality results [67].
Mobility
Since these wireless sensors are equipped with battery, they can possess limited mobility.
Thus, if a region becomes unmonitored we can have the nodes rearrange themselves.
Energy conservation
Sensor nodes can use up their limited energy supply carrying out computations and
transmitting information in a wireless environment. As such, energy-conserving forms of
communication and computation are crucial as the node lifetime shows a strong dependence
on the battery lifetime.
2.4.2. Current deployments and applications
Judging by the interest shown by military, academia, and the media, dozen applications do
exist for sensor networks such as weather monitoring, security and tactical surveillance,
detecting ambient conditions or domotic and healthy applications. A brief description of some
of them is presented below:
2.4.2.1.
Remote Ecological Micro-Sensor Network
PODS [9] is a research project undertaken at the University of Hawaii that has built a wireless
network of environmental sensors to investigate species of plants will grow in one area. They
deployed camouflaged sensor nodes in the Hawaii Volcanoes National Park, where two types
of sensor data are collected: weather data are collected every ten minutes and image data are
collected once per hour. Users employ the Internet to access the data from a server in
University of Hawaii at Manoa.
37
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 2-2 Monitoring volcanic eruptions with a WSN [39]
2.4.2.2.
Environment Observation and Forecasting System
The environment Observation and Forecasting System (EOFS) is a distributed system that
spans large geographic areas and monitors, models and forecast physical processes such as
environmental pollution or flooding. CORIE [26] is a prototype of EOFS for the Columbia River
(Oregon, USA) which integrates a real-time sensor network, a data management system and
advanced numerical models. Approximately thirteen stationary sensor nodes fixed to a pier
are deployed across the Columbia River estuary, while one mobile sensor station drifts offshore. The stationary are powered by a power grid, while the mobile station uses solar panel
to harness solar energy. Sensor data are transmitted via wireless links towards on-shore
master stations which, in turns, forward the data to a centralized server where it serves as
input to a computationally physical environment model used to guide forecasting.
2.4.2.3.
Disaster Relief Management
Novel sensor network architecture has been proposed in [17] that could be useful for major
disasters including earthquakes, storms, floods, fires and terrorist attacks. The sensor nodes
are deployed randomly at homes, offices, and other places prior to the disaster and data
collecting nodes communicate with database server for a given sub are which are linked to a
central database for continuous update. Based on the statistical data form Izmit earthquake in
1999, various performance curves are obtained to indicate required average number of active
sensor nodes to detect a disaster, probability of the disaster to be within the sensing range,
total number of transmitted packets and the number of sensor nodes failed due to energy
depletion.
2.4.2.4.
Health care monitoring
An example of such application is the artificial retina developed within the Smart Sensors and
Integrated Microsystems (SSIM) project [74], where a retina prosthesis chip consisting of one
38
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
hundred microsensors are built and implanted within the human eye allowing patients with no
vision or limited vision to see at an acceptable level. Wireless communication is required to
suit the need for feedback control, image identification and validation.
2.4.2.5.
DARPA Efforts towards Wireless Sensor Networks
The Defense Advanced Research Projects Agency (DARPA) has identified networked micro
sensors technology as a key application for the future. There are many interesting projects and
experiments going under the DARPA SensIT (Sensor Information Technology) program which
aims to develop the software for distributed micro-sensors.
Vehicle type identification is important for defense applications and an experiment was
performed for two weeks by placing sensor boards in the Marine Corps Air Ground Combat
Center in Twenty-nine Palms (California) for collecting acoustic data [30]. To detect presence
of a vehicle, the sensor board is equipped with acoustic, seismic and passive Infra-Red sensors
under program control and local processing is done to do local classification and storage.
2.5. Introducing VANETs (Vehicular Ah-hoc NETworks)
Traditional traffic management systems are based on centralized infrastructures where
cameras and sensors implemented along the road collect information on density and traffic
state and transmit this data to a central unit to process it and make appropriate decisions. This
type of system is very costly in terms of deployment and is characterized by a long reaction
time for processing and information transfer in a context where information transmission
delay is vital and is extremely important this type of system. However, with the rapid
development of wireless communication technologies a new decentralized architecture based
on vehicle-to-vehicle communications (V2V) has created a very real interest these last few
years for car manufacturers, the R&D community and telecom operators. Thus, a new concept
was born: a vehicular ad hoc network (VANET), which is no more than a specific application of
traditional mobile ad hoc networks (MANET).
Vehicular Ad hoc NETworks (VANETs) have recently emerged as a platform to support
intelligent inter-vehicle communication to improve traffic safety. The road-constrained
characteristics of these networks and the high mobility of the vehicles, their unbounded power
source, and the emergence of roadside wireless infrastructures make VANETs a challenging
and promising research topic.
39
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 2-3 Wireless Vehicular Networks
VANET’s aim to provide our cars and roads with capabilities to make road more secure and to
make our time on the road more enjoyable, enabling communications among nearby vehicles
(car to car communication) as well as between vehicles and nearby fixed equipment (car to
infrastructure communication). The following variety of applications is a typical example of an
intelligent transportation system (ITS):
40

Safety, in which a warning message will be broadcasted from a vehicle to its
neighborhood notifying about some event such as car collision or road surface
conditions in order to decrease traffic accidents rate and enhance traffic flow control.
It refers to applications or systems that increase the protection of the people in the
vehicle as well as the vehicle itself

Resource efficiency, referring to increase traffic fluency with data such as enhanced
route guidance or parking spot locator services. Better efficiency results in less
congestion and lower fuel consumption, helping to minimize environmental and
economic impact.

Infotainment and Advanced Driver Assistance Services (ADAS), combining
information and entertainment and offering multimedia and Internet connectivity
facilities for passengers.
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
Fig. 2-4 Application domains [66]
The huge potential of car-to-car connectivity is fundamentally due to the constant growth of
automotive market and the increasing demand for the car safety. Some issues relating to
architecture, routing, security, performance or QoS should be investigated. It is necessary to
put special attention to ensure interoperability through the standardization of protocols and
interfaces in order to allow the communication between vehicles from different
manufacturers.
2.5.1. Properties
As previously mentioned, a VANET represents a specific aspect of MANETs. Nevertheless,
research works studied and carried out in the field of MANETs cannot be applied directly in the
context of vehicular networks because of the characteristics of VANET making the application
of MANET protocols and architectures inappropriate. In the following, the main properties and
constraints related to the environment of vehicular ad hoc networks are presented below.
Processing, energy and communications capacity
Contrary to the context of mobile ad hoc networks where energy constraint represents one of
the main challenges, vehicles in a VANET have no limit in terms of energy, have large
processing capability and allow supporting several communications interfaces.
Environment and mobility model
Environments considered in ad hoc networks are often limited to open spaces or indoors.
Vehicle movements are connected to road infrastructures, on highways, or within a
metropolitan area. The constraints imposed by this type of environments, such as radio
obstacles because of buildings, and multipath and fading effects, considerably affect the
mobility model and radio transmission quality.
Type of information and diffusion
41
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Since one of the key VANETs applications is prevention and road safety, the types of
communications will focus on message broadcast from a source to several receivers.
Nevertheless, the vehicles concerned by such diffusion depend on their location and their
degree of implication in the event. In such situations, communications are mainly
unidirectional.
Network topology and connectivity
Contrary to ad hoc networks, VANETs are characterized by very high mobility because of car
speed. Thus, an element can quickly join or leave the network in a very short time, which
makes topology changes frequently. Solutions must then consider this constraint where
connectivity is one of the key parameter. In addition, properties inherent to VANETs, especially
in terms of size, raise scaling problems and a complete revision of existing solutions is
required.
Security
Data sensitivity transmitted over a VANET demonstrates a high need for security. In fact, the
importance of security in this context is vital because of the critical consequences resulting
from a violation or attack. In addition, with a highly dynamic environment characterized by
almost instant arrivals and departures of cars, the deployment of a security solution must cope
with specific configurations and constraints.
2.5.2. State of the art in VANETs
2.5.2.1.
VANETs Applications
A VANET communication platform allows an enormous variety of applications aimed at
administration, companies, drivers and people in the vehicle. These services will help and
support topics as important as security driving, safety-related, traffic and fleet control as well
as entertainment applications. Generally, from the connectivity point of view they could be
divided into four groups: car-to-car traffic, car-to home, car-to-infrastructure and routing
based applications.
2.5.2.1.1. Safety-related Applications
Safety-related applications are the most important kind of applications for VANETs due to its
main objective: decrease of injuries and deaths due to vehicle accidents. In this context, the
European Commission is making an important effort to investigate, develop and implement
these services in order to come into effect as soon as possible.
Cooperative collision avoidance
This service is about helping driving by detecting possible obstacles in the road. One such
application would be emergency notifications. In case of an accident or sudden hard breaking,
a notification is sent to the following cars. This information could also be propagated by cars
42
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
driving in the opposite direction and, thereby, conveyed to the vehicles that might run into the
accident.
For a correct display of this service, it would be necessary a little installation in users’
equipment which sends information about his/her position, trajectory or speed to the
neighbours. Also, another system in the vehicle permanently listens to rely information from
the rest of vehicles and infrastructure.
Cooperative driver assistance system
This service exploits the exchange of sensor data or other status information among cars. The
basic idea is to broaden the range of perception of the driver beyond his/her field of vision and
further to assist the driver with autonomous assistance applications. By transmitting this data
to cars following on the same road, drivers get information about hazards, obstacles or traffic
flow ahead, resulting in more efficient and safe driving. Sensors could detect a danger and
warn drivers with a brief description or even the driver could detect it and, through a vocal
interface, describe the danger of the situation to the rest of users.
Information could be sent to every user in the network to inform, for example, that a traffic
jam has started in a certain point of the road where we are driving. On the other side, it could
be necessary a geocast message if, for example, we detect an oil puddle in one exit road; is
necessary to send the information only for those vehicles that will take that exit.
eCall
eCall [31] is a project of the European Commission intended to bring rapid assistance to drivers
involved in a collision anywhere in the European Union. In case of crash, an eCall-equipped
vehicle automatically calls the nearest emergency centre. Even if no passenger is able to speak,
e.g. due to injuries, a “Minimum Set of Data” is sent, which includes the exact location of the
crash site. Shortly after the accident, emergency services therefore know that there has been
an accident, and where exactly. eCall cuts emergency services' response time. It goes down to
50% in the countryside and 60% in built-up areas. Annually, the quicker response will save
around 2.500 lives in the European Union. The severity of injuries could be considerably
reduced in 15% of cases. Drivers could also make an eCall by pushing a button in the vehicle.
Witness of an accident can report it and automatically give the precise location.
2.5.2.1.2. Comfort Applications
The general aim of these applications is to improve passenger comfort and traffic efficiency.
That could include nearest POI (Points of Interest) localization, current traffic or weather
information and interactive communication. All kinds of applications, which may run on top of
TCP/IP stack, might be applied here (online games or instant messaging). Another application
is reception of data from commercial vehicles and roadside infrastructure about their
businesses (’wireless advertising’), information about gas stations or enterprises which can set
43
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
up stationary gateways to transmit marketing data to potential customers passing by, online
help in case of breakdown, etc.
Furthermore, these services could be integrated with electronic payments, toll paying systems,
etc. An important feature of comfort or commercial applications is that they should not
interfere with safety applications. In this context traffic prioritizing and use of separate
physical channels is a viable solution.
Optimum route calculation with real-time traffic data
This service could be used from the vehicle or from another point with an Internet connexion.
The fact that, in the long term, all vehicles will be equipped with this system will make datataking and data-publishing easier. This data, conveniently analyzed, will inform about the state
of the road, prevent traffic jams, etc.
2.5.2.1.3. Applications for Administration
Vehicle identification
This service will provide a safe and fast way of information provision from vehicles without the
need of stopping them. It will be necessary an appropriate legislation to allow that each
vehicle stores the necessary information in an electronic format and its automatic transmission
if it is required by an authorized device.
Vehicle identification service will help police in different ways: it would be possible to check if
a vehicle and his/her driver have the necessary documentation or, if an infraction is detected,
its report would be automatically processed, etc.
2.5.2.2.
Challenges in VANETs
When deploying of a vehicular network system, several issues have to be resolved. VANET
characteristics  rapid topology changes, frequent fragmentation, variable and highly dynamic
scale and network density, etc.  are opening some brand new lines of investigation and
challenges for the scientific community.
In what follows, we briefly mention some issues related to VANETs that need to be addressed.
2.5.2.2.1. Routing
In vehicular networks, mobility is constant. This fact causes extremely fast changes in network
topology and involves the need to reconfigure the routing tables of each node. Frequent
network partitioning in VANETs requires a different approach, e.g. the 'carry and forward' idea
[19], where, if there is no a direct route, a packet is carried by a node until it could be
forwarded to a node being closer to the destination, or the Delay Tolerant Networking.
Delay Tolerant Networking (DTN) is an approach to computer network architecture that wants
to address the technical questions in heterogeneous networks, such as mobile networks, that
44
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
could lack continuous network connectivity. The Delay Tolerant Network Research Group
(DTNRG) [32] has defined an architecture based on a store and forward paradigm to
interconnect networks, even without end-to end connectivity. Each DTN node may store
packets and, when appropriate, forward them towards the destination through intermediate
nodes.
2.5.2.2.2. Security
Security is an issue that needs to be carefully addressed and assessed in the design of the
vehicular communication system. In a wired network, user has to access to physical wire if
s/he wants to access the network's information. However, wireless communications are weak
from this point of view, because they use air as the transmission medium. This problem gets
worse in vehicular networks due to the non-existence of infrastructure that provides security
services centralization like user authentication or packet ciphering. The issue to be addressed
includes trust  vehicles must be able to trust the messages they receive, resiliency and
efficiency e.g. real-time message authentication.
Privacy is also considered a major issue. Anonymity must be preserved making impossible
tracking a vehicle for non-trusted parties. Not taking into account privacy could result in a
multiple lawsuits after the network is deployed.
IEEE 802.11p dynamically assigns MAC addresses, along with a mechanism to duplicate MAC
address discovery, thus vehicles and drivers would not be traceable for the MAC address.
As we can read in the online magazine DailyTech [25], Daimler-Chrysler is putting the finishing
touches on a new system, Wireless Local Danger Warning (Willwarn), that uses on-board ABS
(Antilock Brake System), ESP (Electronic Stability Control), EBD (Electronic Brake Distribution)
and GPS (Global Positioning System) systems to monitor hazardous road conditions or broken
down vehicles. The information collected is then displayed to the driver so that proper
precautions can be taken to avoid or safely navigate problem areas on the road. The Willwarn
system is based on IEEE 802.11a/p and made use of the communication platform developed in
the German Network on Wheels (NOW) project [61].
2.5.2.2.3. Quality of Service (QoS)
Quality of Service in wired networks is provided by different types of resources reservation
mechanisms. However, executing these mechanisms is very complex due to the special
features of VANET, such as high mobility nodes and large-scale node population. Nowadays,
there exist some proposals; nevertheless, the majority of them are theoretical, simulated or
implemented with fewer nodes.
Tarng et al. [79] proposed a method based on the stability from the radio propagation: signal
strength and path loss; Sun et al. [77] proposed a grid based protocol. The digital map is preset with a grid. A routing path is selected based on the traffic features, such as the
intersection, the number of vehicles, and roads, in a grid. Recently, Yan et al. [88] proposed a
45
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
routing selection and maintenance based on the mobility of vehicles. The main ideas are to
select and maintain one routing path and one backup routing paths based on the mobility of
vehicles (relative speed and direction). They reduce delay and response time in QoS terms
because the retransmission caused by routing breakage is reduced and they improve the
throughput in QoS terms.
2.5.2.2.4. Power Management
Power management in VANET is not concerned about energy efficiency, but rather about the
transmission power – when too high, the on-going transmission could disrupt another
transmission at a distant node due to interferences –. Thus the denser the network is, the
lesser transmission power should be used. Several algorithms could be employed here, e.g. in
[14] the power is adjusted to keep the number of neighbours within the maximum and
minimum threshold. On the other hand, [51] concentrates on improving the 1-hop broadcast
coverage by transmission power adjustments.
2.5.2.3.
Current projects and activities in VANETs
2.5.2.3.1. Standardization process and research projects initiatives in
VANETs
This section briefly explains the main progress and purposes of the standardization process
and research projects initiatives. It is foreseen that these solutions will finally converge, leading
to a common, worldwide VANET platform.
In Europe, several projects are held, joining partners from the industry, governmental agencies
and academia. Within the Framework Programme 6 of the European Union, four integrated
projects were started in areas that touch the field of VANET: COOPERS, CVIS, SAFESPOT and
PReVENT:
46

The project Co-operative Systems for Intelligent Road Safety (COOPERS, 2006–10)
[23] focuses on innovative telematics applications for cooperative traffic management.
From a communication perspective, it therefore primarily addresses vehicle-toroadside communications and makes use of CALM (Communication Architecture for
Land Mobile environment) standards like the CALM infrared communication interface.
CALM is the ISO TC 204 (ITS) Working Group 16 (Communication) on ‘Continuous Air
interface for Long and Medium distance’. CALM aims to support continuous
communications for vehicles by making use of various media and communication
interfaces.

The project Co-operative Vehicle-Infrastructure Systems (CVIS, 2006–10) [24] is a
major European research and development project financed by the European
Commission aiming to design, develop and test the technologies needed to allow cars
to communicate with each other and with the nearby roadside infrastructure. Based
on such real-time road and traffic information and although there are no ultimate
results because of the project is still in progress, many novel applications have been
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
produced as well as four new services: COMM, allowing car-2-X coomunications,
POMA, providing positioning system, COMO, providing monitoring services and FOAM,
linking vehicles to infrastructure. The consequence will be increased road safety and
efficiency, and reduced environmental impact. The CVIS main challenges are:
o
To create an unified technical solution allowing all vehicles and infrastructure
elements to communicate with each other.
o
To enable a wide range of potential cooperative services to run on an open
application framework in the vehicle and roadside equipment.
o
To define and validate an open architecture and system concept for a number
of cooperative system applications, and develop common core components to
support cooperation models in real-life applications and services for drivers,
operators, industry and other key stakeholders.

The project SAFESPOT (2006–10) [72] aims to design cooperative systems for road
safety based on vehicle-to-vehicle and vehicle-to-infrastructure communication.

The project PReVENT (2006–08) [68] addressed to development of preventive safety
applications and technologies. Within the PReVENT Integrated Project, the subproject
Willwarn, wich we have mentioned before, focused on the topic of vehicle-to-vehicle
and vehicle-to-infrastructure commu-nication.
The Car2Car Communication Consortium [16] is a non-profit organization initiated by
European six vehicle manufacturers (General Motors, Ford Motor, Honda, Toyota, BMW and
Mercedes-Benz) in 2004, pushing for further increase of road traffic safety. Its mission it to
create an open European industry standard for Car2Car communication systems based on
wireless LAN components and guarantee European-wide inter-vehicle operability. That
includes proposing of realistic deployment strategies and business models to speed-up the
market penetration.
The Car2Car consortium has established its objective of improving road safety and efficiently
managing traffic using inter-vehicular systems. The Car2Car consortium together with IEEE
have developed IEEE 802.11p standard, which defines enhancements to 802.11 required to
support Intelligent Transportations Systems (ITS) applications. Car2Car main missions were as
follows:

The creation of an open European standard for V2V communications based on wireless
LAN components.

Developing V2V system prototype demonstrator for road safety applications.

Promoting tre allocations of a free exclusive band for Car2Car applications in Europe.

Developing deployment strategies and economic models for market penetration.
47
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
The FleetNet (Internet on the road) project [33] is a German project introduced by a
consortium of six manufactures (DaimlerChrysler AG, FHI FOKUS, NEC Europe Ltd., Robert
Bosch GmbH, Siemens AG, and Temic Speech Dialog Systems GmbH) and the universities of
Braunschweig, Hamburg-Harburg and Hannover. FleetNet’s objective was to develop a
communications platform for vehicle networks, to implement a demonstrator, and to
standardize the proposed solutions in order to ensure better security and comfort for driver
and passengers. The FleetNet architecture is based on a routing mechanism based on a system
of location and navigation, and also considers vehicle to infrastructure communications in
order to provide Internet access service.
Fig. 2-5 Architecture on VANETs communication [13]
The NOW (Network on Wheels) project [61] is a German project from the Federal education
and research government, founded by automobile manufacturers, telecommunications
operators and academia. NOW is the successor of FleetNet Project and supports and strongly
cooperates with the Car2Car consortium. One of NOW’s main objectives is the implementation
of communication protocols and data security algorithms in vehicular network. Considering
the wireless 802.11 technologies and location-based routing in a V2V or vehicle to
infrastructure communication context, the goal is to implement a system of reference and to
contribute to the standardization of such a solution in Europe in collaboration with the Car2Car
consortium.
GST (Global System of Telematics) [36] is an EU-funded Integrated Project that is creating an
open and standardized end-to-end architecture for automotive telematics services.
Participants were major car manufacturer and major Telecom players, altogether around 60
48
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
companies. The purpose of GST is to create an environment in which innovative telematics
services can be developed and delivered cost-effectively and hence to increase the range of
economic telematics services available to manufacturers and consumers. GST has introduced
seven service-oriented sub-projects that seek to contribute to achieving the main targets:
rescue, safety, payment, safety channel or extended floating car data.
In Japan, a standard for vehicle-to-infrastructure communication was published in 2001 and
denoted as ‘Dedicated Short-Range Communication System’ (ARIB 2001). The specified system
operates in the 5.8 GHz frequency band, is based on time division multiple access and targets a
range of about 30 m. The primary use of the system was seen in electronic toll collection but
the system was generalized to support various other services. In 2008, more than 20 million
on-board units for electronic toll collection were deployed in Japan. Based on the success on
this 5.8 GHz DSRC system and on infrared- based vehicle-to-infrastructure communication,
various ITS projects and activities are currently joining forces to demonstrate and enhance
vehicle-to-infrastructure and vehicle-to-vehicle communication under the umbrella of Japan’s
national ITS Safety 2010 initiative.
In the USA, there are several industry/government projects on-going. Vehicle Infrastructure
Integration (VII), which has been rebranded as IntelliDrive [41], has recently completed a large
proof of concept demonstration. The majority of this testing environment was implemented in
Detroit. This system comprised 55 Road Side Equipment (RSE) stations within 45 square miles
and employed 27 vehicles. Seven applications were developed and tested:

In-Vehicle Signage: RSEs trigger displays of advisory messages within the vehicle.

Probe Data Collection: Vehicles provide historical data on their location/state and
share with the RSE, which is then centrally compiled and analyzed.

Electronic Payments – Tolling.

Electronic Payments – Parking.

Traveler Information / Off-Board Navigation.

Heartbeat: RSEs collect periodic status messages from vehicles including vehicle
speed and location.

Traffic Signal Indication: Broadcasts traffic light state.
Integrated Vehicle-Based Safety Systems (IVBSS) project [42] explores human-machine
interface issues when several safety applications, with potentially overlapping or contradictory
advisories, are operated simultaneously. The Cooperative Intersection Collision Avoidance
System (CICAS) project [22], had three components: a Violation Warning project
(demonstrated in Michigan), a Stop Sign Assist project (demonstrated in Minnesota), and a
Signalized Left Turn Assist project (demonstrated in California).
2.5.2.3.2. Vehicular Mobility Models
Due to the prohibitive cost of deploying and implementing such a system in real world, most
research in VANET relies on simulations for evaluation. A key component for VANET
49
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
simulations is a realistic vehicular mobility model. Mobility models represent real world
scenarios for vehicular ad hoc networks and play a vital role in the performance evaluation of
routing protocols. More research focus is now on the development of realistic mobility models
for VANETs. A number of mobility models have been presented and their impact on the
performance on the routing protocols has been tested. To get accurate results, the model
should be as realistic as possible, and involve road maps with all the constraints and facilities
related to the vehicular movement. Below, we present some new mobility models specifically
proposed for VANETS:
The Integrated Mobility Model (IMM) [3] is an integration of Manhattan mobility model,
freeway mobility model, stop sign model, traffic signs model and some other characteristics
like stationary nodes. The advantage of IMM is that it provides a more detailed scenario for
the simulation of VANETs by representing both the rural and urban area which is clear from
the simulation results. After simulate with three different routing protocols (AODV, DSR and
OLSR) and compare results, they obtained that OLSR and AODV performs better than DSR in a
more stressed urban scenario. The future dimensions of this work are that they will add more
realistic parameters to IMM and will enhance it for VANETs simulations for more
comprehensive results. The code, available at [3], has been developed by M. Alam, M. Sher
and S. A. Husain at the University of Islamabad, Pakistan.
MEtropolitan TAxis (META) [40] is a mobility model, proposed in the Shanghai Jiao Tong
University, in collaboration with the State University of New York at Buffalo, that can be used
to generate synthetics trace for the movement of taxis in an urban area. In order to
characterize the regularity of taxi movement, the authors designed three model parameters:
turn probability, road section speed and travel pattern. Through different validation results,
they show that META has a good approximation to a real scenario which in turn shows the
effectiveness of these parameters. Based on the validation, synthetic traces can be generated;
they are similar to the reality using such parameters. Since these parameters are easier to be
obtained than the real trace, the META model can be used to replace the high cost real trace
on some extent in other VANET researches.
MObility model generator for VEhicular networks (MOVE) [50] is a tool that allows users to
rapidly generate realistic mobility models for VANET simulations. The output of MOVE is a
realistic mobility model and can be immediately used by popular network simulators. The
authors warn that if simple mobility models are used for evaluation of VANET, the results
might not be as close to reality as expected, so they show that the details of a mobility model
such as the existence of traffic lights, driver route choice and car overtaking behaviour can
have a significant impact on the simulation results.
Bonnmotion is a Java software, available at [11], which creates and analyses mobility
scenarios. It is developed within the Communication Systems group at the Institute of
Computer Science 4 of the University of Bonn, Germany, where it serves as a tool for the
investigation of mobile ad hoc network characteristics. The scenarios can also be exported
for the network simulators NS2, GloMoSim/QualNet, COOJA, MiXiM, ONE and NCTUns, using a
50
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
conversion script developed in the UPC (Polytechnic University of Catalonia) by Guillermo Diaz.
Several mobility models are supported (Random Waypoint, Random Walk, Gauss-Markov,
Manhattan Grid, etc.).
CityMob [55] is a mobility pattern generator for VANETs, designed to be used with the NS2
simulator developed in the Polytechnic University of Valencia. CityMob can generate traces for
VANETs scenarios using three different mobility models: Simple, Manhattan, and Downtown.
2.5.2.3.3. Other research areas in VANETs
Apart from mobility models, VANET research covers other areas, as transportation systems,
routing protocols and new infrastructures.
Intelligent transportation systems (ITSs) [2] cover different technologies as wireless
communications, sensor networks, voice and data communication, real-time driving-assistant
systems, etc. The interconnection of different networks, even in the case of the Internet, is one
of the main difficulties that is delaying the wide spread of vehicular networks. Location-Aided
Gateway Advertisement and Discovery (LAGAD) [2] is a scalable hybrid adaptive protocol that
aims to reduce congestion on single channels through a channel diversity mechanism that uses
multiple channels and multiple interfaces for the propagation of gateway requests and replies.
Bypass-AODV (Bypass Ad hoc On-demand Distance Vector) [4] is a new optimization of the
AODV routing protocol for mobile ad-hoc networks proposed as a local recovery mechanism to
enhance its performance. It uses a specific strategy of cross-layer MAC-notification to identify
mobility-related packet loss, and then setup up a bypass between the node at which the route
failure occurred and this node’s previous successor via an alternative node. Simulation results
show that Bypass-AODV is insensitive to any random mobility model used and has a clear
performance improvement compared to AODV. It has a comparable performance under group
mobility model compared to AODV. Currently, Bypass-AODV is not suitable for VANET
applications because the movement of vehicles is constrained by the layouts of the roads. As a
future work, Bypass-AODV needs more improvement in order to handle VANET applications.
With the help of VANETs, vehicles on the road can form wireless ad hoc mesh networks
(VMeshs) [52]. These meshes can help to retain certain transient information in a specific
region for a period of time, by cooperatively passing the information among themselves
without any infrastructure help. Nevertheless, there is a VANET storage problem. Studies show
that the transmission range has high impact on the storage lifetime for one-way highway
traffic, and the size of the region in which we want the information stored has high impact for
two-way highway traffic.
A new two-tier architecture called Mobile Infrastructure Based VANET (MI-VANET) [53] has
been recently proposed. In this architecture, the buses constitute a mobile backbone for data
delivery while the low tier is composed of ordinary cars and passengers. MI-VANET will not
only bring the benefit that ordinary cars do not have to forward packets for other nodes, but
also improve the network connectivity. They are currently working and studying to
51
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
demonstrate that MI-VANET with MIRT performs much better than GPSR and VANET MIRT in
terms of packet delivery ratio and throughput.
2.6. Vehicular Traffic Models in VANETs
Transportation and traffic research area classifies traffic models according to the granularity
with which traffic flows are examined. Macroscopic models model traffic at a large scale,
treating traffic like a liquid applying hydrodynamic flow theory to vehicle behavior. The
simulation in a macroscopic model takes place on a section-by-section basis rather than by
tracking individual vehicles. However, they do not have the ability to analyze transportation
improvements in as much details as the microscopic models.
Mesoscopic models combine the properties of both microscopic and macroscopic simulation
models. As in microscopic models, the mesosocopic models unit of traffic flow is the individual
vehicle. However, their movements follow the approach of the macroscopic model and are
governed by the average speed on the travel link, so movements do not consider individual
dynamic vehicle speed and volume relationships.
Microscopic simulations, which model the behavior of single vehicles and the interactions
between them, are the most appropriate mobility models for simulating VANETs.
Transportation and traffic science has developed a number of microsimulation models, each
taking a dedicated approach ranging from coarse to fine grain.
When dealing with vehicular mobility modeling, some authors have distinguished between
macro-mobility and micro-mobility. For macro-mobility they refer to all the macroscopic
aspects which influence vehicular traffic, for example: the road topology, constrained car
movements, the per-road speed limits. Micro-mobility refers instead to the drivers' individual
behavior when interacting with other drivers or with the road infrastructure, for instance,
traveling speed under different traffic conditions, acceleration, deceleration and overtaking
criteria. For a trustworthy VANET simulation that both macro-mobility and micro-mobility
descriptions are jointly considered when modeling vehicular movements.
There are some models proposed in the general MANET context usable in VANET. The criteria
of applicability considered are the employment of road maps, and limiting the nodes
movements into the roads instead of moving in a wide area. The considered parameters differ
from a model to another. For instance, some models use traffic control mechanisms at
intersections, and some others just assume continuous movement at these points. Some
assume roads to be a single-lane, but some others support multi-lanes roads. Some define the
security distance, while others just ignore this parameter. In the following is going to be
described the main features of the most spread vehicular traffic models.
In the following, the main features of the most spread vehicular traffic models are described.
52
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
2.6.1. Freeway model
Freeway [7] is a generated-map-based model, defined in the simulation area, represented by a
generated map, includes many freeways, each side of which is composed of many lanes. No
urban roads, thus no intersections are considered in this model. At the beginning of the
simulation the nodes are randomly placed on the lanes, and they move using history-based
speeds, where the speed of each vehicle smoothly changes following a random acceleration. In
addition to the realism related to the acceleration and the history-based speed, the model
defines a security distance that should be maintained between two subsequent vehicles in a
lane. If the distance between two vehicles is less than this required distance, the second one
decelerates to enable the forward vehicle moving away. The change of lanes is not allowed in
this model. The vehicle moves on the lane it is placed in until reaching the simulation area
limit, and then it is placed again randomly in another position and repeats the process.
2.6.2. Manhattan model
Manhattan model [7] is also a generated-map-based model introduced to simulate an urban
environment. Before starting a simulation a map with vertical and horizontal roads are
generated. Each road latter includes two lanes, allowing the movement in the two directions
(north/south for the vertical roads and east/west for the horizontal ones). At the beginning of
a simulation, vehicles are randomly put on the roads. Afterwards, they move continuously
according to history-based speeds (exactly like Freeway). When reaching a crossroads, the
vehicle randomly chooses a direction to follow. That is, continuing straight forward, turning
left or turning right. The probability of each decision is set by the authors respectively to 0.5,
0.25 and 0.25. The security distance is also used in this model and nodes follow the same
strategy as in the freeway model to maintain this distance. But contrary to the previous model,
a vehicle can change a lane at a crossroads. Nonetheless, there is no control mechanism at
these points (crossroads), where nodes continue their movements without stopping.
2.6.3. City Section Mobility (CSM)
CSM [27] can be viewed as a hybrid model between Random Waypoint Model (RWP), in which
mobile nodes move randomly and freely without restrictions, and Manhattan as it introduces
the principle of RWP, especially the pause-time and random selection destination, within a
generated-map-based urban area. At each step of the vehicle's movement a random point is
selected from the generated road map, towards which it moves following the shortest path.
After reaching that destination, it remains there for a pause-time, and then repeats the
process. The speed of nodes is constrained by the security distance, along with the maximum
speed limit of the road.
53
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
2.6.4. Stop Sign Model (SSM)
Contrary to the previous models, SSM [54] integrates a traffic control mechanism. In every
crossroads, a stop signal is set, which obliges vehicles to slow down and make a pause there.
This model is based on real maps of the TIGER/Lines database [5], but all roads are assigned a
single lane in each direction. A vehicle should never overtake its successor (like in all the
models presented before) and should tune its speed to keep the security distance. If many
vehicles arrive at an intersection at the same time, they make a queue, and each one waits for
its successor to traverse the crossroads. This results in gathering of nodes, and hugely affects
the network connectivity as well as the mobility (average speeds). According to the authors,
the problem with this model is the unrealistic disposition of the spot signals, since it is
impossible to find a region with spot signals at each intersection, therefore, they improved
SSM and they proposed TSM.
2.6.5. Traffic Sign Model (TSM)
In TSM model [54], stop signals are replaced by traffic lights. A vehicle stops at crossroads if it
encounters a red stoplight; otherwise it continues its movement. When the first vehicle
reaches the intersection, the light is randomly turned red with probability p (thus turned green
with probability 1-p). If it turns red, then it remains so for a random delay (pause-time) forcing
the vehicle to stop, as well as the ones behind it. After the delay, it turns red, and then the
nodes traverse the crossroads one after the other until the queue is empty. When the next
vehicle arrives at the crossroads the process is repeated.
2.6.6. STRAW (Street Random Waypoint)
STRAW [20] is also a model using real maps of TIGER/Line [54]. Like the other models, except
freeway, roads include one lane in each direction and it is divided into segments. The model is
basically composed of three modules: intra-segment mobility manager, inter-segment mobility
manager, and finally the rout management and execution module. At the beginning of the
simulation the nodes are placed randomly one behind the other, they move using the car
following and try to accelerate until reaching the maximum speed of the segment. The first
module manages this movement until reaching an intersection. The security distance is
maintained, but the overtaking is not allowed. At crossroads the vehicles always slow down,
even when they change a segment and turn without a full stop, which is realistic. The second
module defines the traffic control mechanism including both stop signals and traffic lights,
which are put on crossroads according to the class of the intersected roads. In addition to this
usual control form, the module makes sure that the next segment to take contains enough
available space before moving the vehicle towards it. If it is fully busy, the vehicle waits at the
crossroads (at the end of the first segment). The last module selects the routes to be taken by
each vehicle during the simulation. In the first one the direction is randomly selected at each
intersection, for example, when reaching an intersection, the vehicle randomly decides
whether to continue straight forward or to turn and change the road. On the other hand in the
54
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
second approach a destination is selected toward which the vehicle moves using the shortest
path.
Fig. 2-6 Screenshot of STRAW with the enhanced visualization tool
2.6.7. MOVE (MObility model generator for VEhicular network)
MOVE [46] is a VANETs mobility model that uses the compiler SUMO [76], which is a realistic
vehicular traffics simulation model. SUMO is an open source application implemented with
java that integrates many realistic parameters such as realistic accelerations; the usage of real
maps reflecting several types of roads (with multiple lanes), and traffic lights defining priorities
between vehicles. Basically, MOVE is composed of two components; the road map editor and
the vehicle movement editor. The former serves to manually and randomly generate a road
map, either from TIGER/Line [5] files or Google earth files, whereas the latter allows specifying
the properties of each vehicle like the maximum speed, the acceleration, the probability of
turning at crossroads and the path to take. The information collected by the two editors is sent
to the SUMO compiler.
55
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 2-7 Screenshot of MOVE
2.6.8. BonnMotion
BonnMotion tool [11] implements several random mobility models, plus the Manhattan
model. While the important tool includes the Car Following Model which is a basic car-to-car
inter-distance control schema, the BonnMotion does not consider any micro-mobility. When
related to the framework, we can easily see that the structure of both tools is definitely too
simple to represent realistic motions, as they only model basic motion constraints and hardly
no micro-mobility.
2.6.9. VanetMobiSim
VanetMobiSim [37] is an extension of the CANU Mobility Simulation Environment
(CanuMobiSim) [15], which focuses on vehicular mobility, and features realistic automotive
motion models at both macroscopic and microscopic levels. At the macroscopic level,
VanetMobiSim can import maps from TIGER/Line database, or randomly generate them.
VanetMobiSim adds support for multi-lane roads, separate directional flows, differentiated
speed constraints and traffic signs at intersections. At the microscopic level, it manages lane
changes and vehicle accelerations and decelerations, providing realistic car-to-car and car-toinfrastructure interactions. VanetMobiSim is the mobility generator used in this project.
Further description for VanetMobiSim is presented in Chapter 6.
56
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
Fig. 2-8 Screenshot of VanetMobiSim
2.6.10. SUMO (Simulation of Urban Mobility)
SUMO [47] is an open source, highly portable, microscopic road traffic simulation package
designed to handle large road networks. Its main features include collision free vehicle
movement, different vehicle types, single-vehicle routing, multi-lane streets with lane
changing, junction-based right-of-way rules, hierarchy of junction types, an openGL graphical
user interface (GUI), and dynamic routing. SUMO can manage large environments, i.e., 10 000
streets. SUMO can simulate traffic in different locations of the globe. However, since SUMO is
a pure traffic generator, its generated traces cannot be directly used by the available network
simulators, which is a serious shortcoming.
Fig. 2-9 Screenshot of SUMO
2.6.11. FreeSim
FreeSim [34] is a fully customizable macroscopic and microscopic free-flow traffic simulator
that allows for multiple freeway systems to be easily represented and loaded into the
simulator as a graph data structure with edge weights determined by the current speeds.
57
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Traffic and graph algorithms can be created and executed for the entire network or for
individual vehicles or nodes, and the traffic data used by the simulator can be user generated
or be converted from real-time data gathered by a transportation organization. Vehicles in
FreeSim can communicate with the system monitoring the traffic on the freeways, which
makes FreeSim ideal for Intelligent Transportation System (ITS) simulation. FreeSim is licensed
under the GNU General Public License, and the source code is available freely for download.
2.6.12. CityMob
CityMob [55] is a NS2 compatible mobility model generator proposed for use in VANETs.
Citymob implements three different mobility models: (a) Simple Model (SM), (b) Manhattan
Model (MM), and (c) realistic Downtown Model (DM).
Last models are programs witch includes the models explained at the beginning of the chapter.
To summarize all the information there is a table witch shows the main characteristics of the
last seven models, which are the most used.
VanetMobiSim
SUMO
MOVE
STRAW
Freesim
Real
X
X
X
X
X
User-defined
X
X
X
Random
X
X
X
CityMob
Maps
Manhattan
X
Mobility
Random Waypoint
X
X
X
STRAW
X
X
Manhattan
X
X
X
X
X
Downtown
X
Traffic Models
Multilane roads
X
X
X
X
X
Lane changing
X
X
X
X
X
Overtaking criteria
X
Colision free movement
X
X
X
Different vehicles type
X
X
X
X
X
Traces
ns-2 trace support
X
NCTUns trace support
Import different formats
X
X
X
X
Table 2-1 Comparison of Vehicular Traffic Models
58
INTRODUCTION TO MOBILE AND VEHICULAR NETWORKS
As it can be seen none of these seven models have NCTUns compatibility but some have NS2
trace support, which it is the most usual compatibility with all VANET simulators.
59
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
3. WIRELESS ACCESS FOR VEHICULAR
ENVIRONMENT
3.1. Introduction
Vehicular Ad-hoc Network (VANET) is a special type of Intelligent Transportation System (ITS)
which is a specialization of mobile ad-hoc networks focused on vehicular environments. These
networks have no fixed infrastructure and rely on the network nodes to provide networks
functionality. In last years much effort is being carried out in order to research this network
paradigm.
Because of the nature of vehicular environment, VANET communications must face additional
challenges that are not present in other mobile communication technologies. There are two
major challenges: speed and loss of Line Of Sight (LOS). Mobile nodes are vehicles moving in
predefined road which depends on the road structure and traffic regulation at high speeds,
which in relative measures are well above 120Km/h. For example, when two vehicles moving
in opposite directions in a highway communicate with one another, the communication
module may face relative speed of 240Km/h. On the other hand, some situations result in nonLOS. The lack of LOS produces degradation in the quality of the communications, which could
lead to burst errors or even to complete loss of the communication. Moreover, in urban
scenarios, the buildings surrounding the roads produce signal reflections that harm the
communication quality because they result in burst errors that may lead to packet losses.
60
WIRELESS ACCESS FOR VEHICULAR ENVIRONMENT
Although most of the essential features of the MANET are in VANET with some behavioral
changes so that the routing protocols and IEEE standards used in MANET are also applied in
VANET environment, it is known that IEEE 802.11 standard is not well suited for VANET
environment and new technologies are being standardized for vehicular communications. An
IEEE working group has developed a new set of standards which is designed for VANET: the
Wireless Access in Vehicular Network (WAVE) whose outstanding component is the IEEE
802.11p amendment [71].
However, while new vehicular networking concepts are developed, other mobile and wireless
technologies shall be used for VANET communications. A widespread example of these
technologies is IEEE 802.11b, which is commonly known as belonging to the WIFI family of
standards. Although IEEE 802.11b was initially designed for low-mobility indoor wireless
scenarios, nowadays it is one of the most commonly used technologies for the
experimentation of VANET communications [35]. 802.11b has been selected because has
shown a more stable communications in initial test performed compared with 802.11g that
showed higher transmission rates but also lower ranges [86]. Although 802.11a is similar in
someway to the 802.11p, we considered that due to 802.11a works in the 5GHz IMS band, in
non-LOS scenarios its performance would be worse because of its lower penetration rate. The
most remarkable features of IEEE 802.11 standards used for experimentation of VANET is
shown in Table.3-1.
Parameter
802.11b
1-2-5.5-11
Mbps
802.11a
6-9-12-18-2436-48-52 Mbps
802.11p
3-4.5-6-9-1218-24-27 Mbps
Allocated
spectrum
2.4-2.4835 Ghz
ISM band
5.125-5.850
Ghz ISM band
5.850-5.925
Ghz DSRC
band
Modulation
encoding
DSSS
OFDM
OFDM
Modulation mode
BPSK-QPSK
BPSK-QPSK
16QAM64QAM
BPSK-QPSK
16QAM64QAM
Communication
range
< 150m
< 100m
< 1000m
Transmission
power for mobile
(maximum)
760 mW (US) 2
W EIRP (EU)
100mW
100mW
Suitable for
mobility
Low
Low
High
Available data rate
Table 3-1 Comparison of the used IEEE 802.11 standards for VANET environment
61
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
3.2. Wireless
(WAVE)
Access
For
Vehicular
Environment
In 1999, the U.S. Federal Communication Commision (FCC) allocated in the USA a 75MHz
spectrum in the 5.9GHz (5.855 – 5.925) band. This band was called Dedicated Short Range
Communication (DSRC) band and its use was exclusively for vehicle-to-vehicle and vehicle-toinfrastructure communication purposes. In the following years Government, industry and
academia carried out efforts to develop and deploy communications systems and protocols
operating in the DSRC band, known as Wireless Access for Vehicular Environment (WAVE)
systems. To simplify interoperability between different automobile manufacturers for WAVEbased ITS applications, the IEEE decide to standardize the entire protocol suite.
Today WAVE is a set of standards and protocols which goal is to facilitate the provision of
wireless access in vehicular environment, whose primary goal is develop applications in order
to achieve public safety and trafic flow improvement. This set comprehends the IEEE 802.11p
and IEEE 1609.1-4 standards.
3.2.1. Architecture Overview
WAVE provides a communication protocol suite optimized for the vehicular environment
developed by IEEE, employing both customized and general-purpose elements. The
components of the system, as defined in the standards, are:
Fig. 3-1 WAVE architecture overview
62
WIRELESS ACCESS FOR VEHICULAR ENVIRONMENT

An MAC and PHY layer derived from IEEE 802.11, adressed in IEEE 802.11p. The
802.11p MAC layer is designed to be PHY independent so that both MAC and PHY
layers conceptually include management entities (MLME and PLME) for this purpose.

A multi-channel operation layer in IEEE 1609.4, where the enhancements to 802.11p
MAC to support WAVE are specified.

A new transport/network layer protocol, IEEE 1609.3, where services, operating at the
network and transport layers, in support of wireless connectivity are specified. This
includes the management of the WAVE BSS (WBSS). The standard call them WAVE
networking services, which can be functionally divided in data-plane services, whose
function is to carry trafic, and management-plane services, whose functions are
system configuration and maintenance.

Security issues specified in IEEE 1609.2, where the security services for WAVE
networking stack are defined. These services provide confidentiality, authenticity,
integrity and anonymity.

An application protocol called IEEE 1609.1, which deals with resource management,
e.g. describing key components of WAVE system architecture and defining data flows,
command message and data sotrage formats.
3.2.2. IEEE 802.11p
The 802.11p amendment modifies the IEEE 802.11 standard to add support for wireless local
area networks (WLANs) in a vehicular environment [82]. The main enhancements are:

Short latency

Ranges from 1 meter up to 1000 meters

WAVE devices installed in vehicles operating at speeds up to 200 km/h

Extreme multipath environments with many reflections and Doppler shift

Nature of the automotive applications to be supported (e.g. reliable broadcast)
IEEE 802.11p is intended to make the minimum necessary changes to IEEE 802.11a PHY layer
so that WAVE devices can communicate effectively among vehicular environments. In the
following, PHY and MAC layer of IEEE 802.11p are discussed.
3.2.2.1.
PHY layer for IEEE 802.11p
As aforementioned, the IEEE 802.11p standard is designed to operate in the DSRC band, unlike
IEEE 802.11a which operates in 5GHz ISM band. The DSRC spectrum allocation is shown in Fig.
3-3. In USA the spectrum is structured into seven 10MHz channels. The central one is the
Control Channel (CCH) and is restricted to safety-critical communications only. The first and
the last channel are reserved for special uses. As an option two adjacent service channels may
be used as one 20 MHz channel. The rest are services channels (SCH) available for both safety
and non-safety usage and a 5MHz guard band. This distribution is shown in Fig. 3-2.
63
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 3-2 US distribution of DSRC spectrum
The allocation of dedicated spectrum in Europe has been more difficult, due to the multiple
parts involved. The Electronic Communications Committee (ECC) reserved in 2008 five
channels of 10MHz. These channels are places in the frequency band between 5,875 and
5,925. This band is not exactly the same as in the US, however ECC recommends to use the
spectrum between 5,855 - 5,875 for non-secure ITS applications.
Fig. 3-3 DSRC spectrum allocation worldwide
The PHY layer of 802.11p takes almost the same signal processing and specifications from the
802.11a [85]. It is based on orthogonal frequency division multiplexing (OFDM), with some
minor changes to fit the high-speed vehicular environment. The IEEE 802.11p together with
the IEEE 1609.4 standard is designed for 10 MHz wide channels instead of 20 MHz as it is in the
original 802.11a in order to increase the tolerance for multipath propagation. Due to this, the
transfer rates will be halved in IEEE 802.11p compared to IEEE 802.11a, implying transfer rates
of 3, 4.5, 6, 9, 12, 18, 24, and 27 Mbps. On the one hand this reduces the effects of Doppler
spread by having a smaller frequency bandwidth; on the other hand the doubled guard
interval reduces inter-symbol interference caused by multipath propagation.
Another two differences compared to the original IEEE 802.11 are presented below. Firstly,
there is no difference between the nodes in the network, that is, all nodes are peers including
the roadside units. There exists no access point functionality in IEEE 802.11p even though the
64
WIRELESS ACCESS FOR VEHICULAR ENVIRONMENT
vehicular network will contain roadside units at certain spots. And secondly, in order to
support larger communication range in vehicular environments, four classes of maximum
allowable Effective Isotropic Radiated Power (EIRP) up to 44.8 dBm (30W) are defined in IEEE
802.11p. The largest value is reserved for use by approaching emergency vehicles. A typical
value for safety relevant messages is 33 dBm.
In summary, the main system parameters of the IEEE 802.11a and IEEE 802.11p are shown in
Table. 3-2 to underline the differences between the two standards.
Parameter
802.11a
802.11p
Channel bandwidth
20 Mhz
10 Mhz
Chip duration
50 ns
100 ns
Number of fft points
64
64
Number of sub carriers
52 + DC
52 + DC
Number of data sub carriers
52
52
Number of pilot sub carriers
4
4
OFDM sympol period (80
chips)
4 us
8 us
Cyclic prefix (16 chips)
0.8 us
1.6 us
FFT Symbol period (64 chips)
3.2 us
6.4 us
Coding scheme
½ industry convolutional
½
Available data rate
6-9-12-18-24-36-48-52
Mbps
3-4.5-6-9-12-18-24-27
Mbps
Table 3-2 Comparison of the PHY layer implementation in IEEE 802.11a and IEEE 802.11p
3.2.2.2.
MAC layer for IEEE 802.11p
The MAC method of the standard IEEE 802.11p is enhanced distributed channel access (EDCA)
from the QoS amendment IEEE 802.11e as MAC method, which is an enhanced version of the
basic distributed coordination function (DCF) found in IEEE 802.11 and based on CSMA/CA,
meaning that the node or station starts by listening to the channel, and if it is free for a time
period called an arbitration interframe space (AIFS), the sender can start transmitting directly.
If the channel is busy or becomes occupied during the AIFS, the station must perform a
backoff, that is, the node has to defer its access according to a randomized time period [10].
In 802.11p, QoS is obtained by putting the data traffic within each node into four different
priority queues. These queues have different AIFS and backoff parameters, that is, the higher
priority, the shorter AIFS. The backoff procedure in IEEE 802.11 works as follows:

draw an integer from a uniform distribution [0, CW] , where CW refers to the current
contention window

multiply this integer with the slot time derived from the PHY layer in use, and set this
as the backoff value

decrease the backoff value only when the channel is free
65
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS

upon reaching a backoff value of 0, send immediately.
The MAC protocol of 802.11 is a stop-and-wait protocol and therefore the sender awaits an
acknowledgment (ACK). If no ACK is received due to e.g., the transmitted packet never reaches
the recipient, the packet being incorrect at reception, or the ACK being lost or corrupted, a
backoff procedure is invoked before a retransmission is allowed. For every attempt to send a
specific packet, the size of the CW will be doubled from its initial value (CWstart) until a
maximum value (CWend) is reached. This is due to the fact that during high utilization periods,
it is convenient to spread the nodes that want to send in time. After a successful transmission
or when the packet had to be thrown away because the maximum number of channel access
attempts was reached, the contention window will be set to its initial value again. In 802.11p
different QoS classes are obtained by prioritizing the data traffic within each node. There are
four different priority levels implying that each station maintains four queues. These queues
have different AIFS and different backoff parameters, e.g., the higher priority, the shorter AIFS.
In a broadcast situation, i.e., when packets destined for all nodes are transmitted, none of the
receiving nodes will send ACKs in response. Therefore, a sender never knows if anyone has
received the transmitted packet correctly, and it will perform at most one backoff (which
occurs when a busy channel is sensed at the initial channel access attempt). Hence, at most
one backoff decrement will take place for broadcasted packets [reference]. In Fig. 3-4 default
parameter settings for the different queues in IEEE 802.11p are found together with the CW
setting.
Fig. 3-4 Default parameter settings for IEEE 802.11p queues
66
PROPAGATION MODELS FOR VEHICULAR ENVIRONMENTS
4. PROPAGATION MODELS FOR VEHICULAR
ENVIRONMENTS
Radio propagation is usually attributed to three mechanisms: reflection, diffraction and
scattering. If a line of sight (LOS) exists between the transmitter and receiver (T-R), then
reflection will dominate. On the other hand, in an obstructed scenario, diffraction and
scattering will be the main cause of interference. Due to these characteristics, the channel
varies rapidly with time and the user's location, phenomena known as fading.
There are two types of fading: large-scale and small-scale fading. Large-scale fading correlates
to shadowing while small-scale fading correlates to multi-path propagation delays. In the
following, an overview of both fading types is presented.
4.1. Large-Scale Fading Models: Two-Ray ground model
Large-scale propagation models describe attenuation of transmitted signal over large T-R
distances. A well known model is the Free Space model [56], which describes power transfer
between transmitter and receiver over free space. Free Space model only takes into account
LOS waves from the transmitter.
A more accurate model called Two-Ray ground model considers waves reflected from ground
in addition to LOS waves. The Two-Ray ground model provides a more accurate model
compared to Free Space Model since waves naturally reflect off surrounding objects. Given the
67
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
distance between the transmitter and the receiver, d, the expression for the Two-Ray ground
model is as follows:
ht 2hr 2
Pr (d )  Pt Gt Gr
d4
(5.1)
where Pt is the transmitted power, Gt and Gr (both having dimensionless quantities) are the
antenna gains of the transmitter and receiver respectively and ht and hr are the heights (in
meter) of the transmitter and receiver from the ground respectively.
4.2. Small-Scale Fading Models
The previous models do no describe the rapid fluctuations of the received signal due to
multipath fading. In obstructed environment signals fade faster due to reflection, refraction
and scattering resulting in the transmitted signal taking multiple paths to the receiver. Each
separate path is attenuated depending on the passage taken. The combination of directed and
out-of-phase reflected waves at the receiver yields attenuated signals, phenomena known as
the aforementioned multipath fading. The relative speed between the transmitter node and
the received node or the surrounding objects causes fading too. The main multipath fading
effects are:

Rapid changes in signal strength over a small area or time interval

Random frequency modulation due to varying Doppler shifts on different multipath
signals

Time dispersion or echoes caused by multipath propagation delays
The most popular small-scale fading models, Rayleigh model and Rician model, are descripted
below.
4.2.1. Rayleigh model
A common model used to describe small-scale fading is the Rayleigh distribution. The Rayleigh
probability density function (PDF) is given by:
 r2 
r
,
Pr (r ) 
exp  
 2 2 
2

r 0
(5.2)

where  is the Rayleigh parameter or the root mean square (RMS) of the received voltage
signal before envelope detection [70].
68
PROPAGATION MODELS FOR VEHICULAR ENVIRONMENTS
The main limitation of the Rayleigh model is that it assumes that all transmitted signal arriving
at the receiver are attenuated equally.
As mentioned, the Rayleigh model describes the reception of N multi-path waves at the
receiver having equal power. Given large N, it can be shown that through the central limit
theorem that the in-phase and quadrature components of the signal tend to be Gaussian of
zero-mean. Thus, the received signal r (t ) can be modeled using the following equation:
r (t )  x(t )2  y(t )2
(5.3)
where x (t ) and y (t ) are Gaussian random variable.
Fig. 4-1 Small-scale fading distribution: (a) Rician (b) Rayleigh
4.2.2. Rician model
The Rician model is similar to Rayleigh model, except that in Rician model one of the path,
typically a LOS signal, is much stronger than the others. The Rice probability density function
(PDF) of the received signal envelope, R (t ) is given by

2  K  1 r
K  1 r 2   K  K  1 


Pr (r ) 
exp  K 
I 2
r

 0








(5.4)
r  0, K  0;   0
where I n (·) is the nth-order modified Bessel function of the first kind [1]. The parameter K is
the ratio of the power received via the LOS path to the power contribution of the non-LOS
paths, and is a measure of fading whose estimate is importany in link budget calculations
69
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
(notice that Rician model derives in Rayleigh model considering K=0, that is, the dominant LOS
compoment fades away).  is the power in the direct path, and acts as a scaling factor to the
distribution.
Both Rayleigh and Rician propagation models are commonly used to describe MANET and
VANET environments [78]. Fading with the Rayleigh distribution is for highly mobile conditions
with NLOS between nodes, while latter is suitable where there is a direct LOS path between
transmitter and receiver.
70
ROUTING PROTOCOLS FOR VANETS
5. ROUTING PROTOCOLS FOR VANETS
Generally, routing protocols implemented for wired networks are not suitable for MANETs
since they are based on periodic route updating mechanisms which increases overhead and
cannot efficiently handle topology changes. Routing in MANETs and VANETs is complex since
mobility causes frequent topology changes and requires more robust and flexible mechanism
to search for routes and maintain them. When the network nodes move, the established paths
may break and the routing protocols must dynamically search for other feasible routes. With a
changing topology, even maintaining connectivity is very difficult. Therefore, routing protocols
for MANETs and VANETs must deal with the following premises:

Distributed operation, since is the basis of MANETs and VANETs

Signaling reduction, allowing conserving battery capacity and enhancing network
efficiency

Keeping the routes loop free, in order to avoid packets flowing indefinitely on the
network and network congestion

Reduced processing time, aiming to save node's resources

Management of asymmetric links, caused by different power levels among mobile
nodes and other factors such as terrain conditions
5.1. Classification of routing protocols for VANETs
Many protocols have been proposed for MANETs and VANETs. These protocols can be divided
into three categories: proactive, reactive and hybrid. Proactive methods, also called table-
71
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
driven methods, maintain routes to all nodes, including nodes to which no packets are sent.
Such methods react to topology changes, even if no traffic is affected by the changes. Reactive
methods, also called on-demand methods, are based on demand for data transmission. Routes
between hosts are determinate only when they are explicitly needed to forward packets. They
can significantly reduce routing overhead when traffic is lightweight and the topology changes
decrease dramatically, since they do not need to update route information periodically and do
not need to find and maintain routes on which there is no traffic. Hybrid methods combine
proactive and reactive methods to find efficient routes, without much control overhead.
Fig. 5-1 Classification of routing protocols for MANETs and VANETs
5.1.1. Proactive Routing Protocols
As stated earlier, proactive routing protocols maintain routes to all destinations, regardless of
whether or not these routes are needed. In order to maintain correct route information, a
node must periodically send control messages. Therefore, proactive routing protocols may
waste bandwidth since control messages are sent out unnecessarily when there is no data
traffic. The main advantage of this category of protocols is that hosts can quickly obtain route
information and quickly establish a session. Several proactive routing protocols have been
implemented depending on the kind of route information stored on node's tables as well as
the used updating method. The most representative are DSDV (Destination-Sequenced
Distance Vector) [8], ADV (Adaptive Distance Vector) [12] and GPSR (Greedy Perimeter
Stateless Routing) [90].
72
ROUTING PROTOCOLS FOR VANETS
5.1.2. Reactive Routing Protocols
Reactive routing protocols can dramatically reduce routing overhead because they do not
need to search and maintain routes on which there is no data traffic at the expense of
increasing end-to-end delay. This property is very appealing in the resource-limited
environment. Depending on how the routing method is implemented, reactive routing
protocols can be divided in source routing protocols and hop-by-hop or point-to-point
protocols.
5.1.2.1.
Reactive Source routing protocols
In source routing protocols every data packet carries the whole path information in its header.
Before a source node sends data packets, it must know the total path to the destination, that
is, all addresses of nodes which compose the path from source to destination. There is no need
that intermediate nodes update its routing tables, since them only forward data packets
according to the header information. However it entails scalability problems since as the
number of hops increases, the path information every data packet must carry become major
and it may waste bandwidth. Moreover, the path is established from the source node so that a
bad adaptation to quickly topology changes will be performed.
The most representative source routing protocol is DSR (Dynamic Source Routing) [45].
5.1.2.2.
Reactive Hop-by-hop routing protocols
Hop-by-hop routing protocols try to improve performance by keeping the routing information
in each node. Every data packet does not include the whole path information any more. On
the contrary they only include the address of the following node where data packet must be
forwarded to get the destination as well as the destination address. Every intermediate node
must look up its own routing table to forward the data packets to its destination, so that the
route is calculated hop by hop. Hop-by-hop routing protocols save bandwidth and performs
well in a large network since a data packet does not carry the whole path information.
However, intermediate nodes must update their routing tables.
The most representative hop-by-hop routing protocol is AODV (Ad hoc On-demand Distance
Vector) [65].
5.1.3. Hybrid Routing Protocols
Hybrid routing protocols combine the proactive and reactive routing approaches. They divide
the network into routing zones, so that it will be used proactive routing schemes for intrazones routing issues and reactive routing schemes for inter-zones routing issues.
The most representative hybrid routing protocol is ZRP (Zone Routing Protocol) [73].
73
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
5.2. Topological Routing Protocols
This section shows two routing protocols based on the topology of the network, DSR and
AODV.
5.2.1. DSR
Dynamic Source Routing (DSR) [45] protocol gets its name from the concept of source route,
where the source node includes list of all intermediate nodes in the packet itself, whenever it
desires to send the packet to a destination node. In case there is no route available in the
cache, the source node initiates a Route Discovery procedure. Each route discovery may
discover multiple routes and all routes are cached at the source node. The source assigns a
unique request id and broadcasts the packet, which is received by intermediate node and in
turn it is re-broadcasted by this node, after appending its own identity to the node list. The
process goes on, till the packet is received by the destination. Thus the source accumulates all
the ids of the intermediate nodes.
Since the destination may receive multiple packets from different routes for the same request
id, the destination replies back to all the received packets. The Route Reply packets are sent
back by the destination to the source by reversing the received node list accumulated in the
Route Request Packet. The reversed node list forms the ‘source route’ for the route reply
packet.
Typically an intermediate node may not receive an acknowledgement from neighbouring node,
triggering a route error packet go flow back to the source, informing source and also all the
intermediate nodes of the link failure. In such a case all nodes, including source, will remove
the route entry from their respective route cache.
5.2.2. AODV
Ad hoc On-demand Distance Vector (AODV) routing protocol was motivated by the limited
bandwidth that is available in the media that are used for wireless communications. Unlike
DSR routing protocol, AODV determines a route to a destination only when a node wants to
send a packet to a destination. Routes are maintained as long as they are needed by the
source [75].
5.2.2.1.
Route discovery mechanisms
Route discovery process starts when a source node does not have routing information for a
node to be communicated with. When a source node has to communicate with another
destination node, it initiates path discovery by flooding a route request packet (RREQ)
throughout the networks. The RREQ contains the fields shown in Fig.4-2.
74
ROUTING PROTOCOLS FOR VANETS
Fig. 5-2 RREQ packet format
The request ID is incremented each time the source node sends a new RREQ, so the pair
(source address, request ID) identifies a RREQ uniquely. On receiving a RREQ message each
node checks the source address and the request ID. An intermediated node could receive
several RREQ from different neighbours. However, if the node has already received a RREQ
with the same pair of parameter the new RREQ packet will be discarded.
Source and destination sequence number prevent to use non-updated routes. Destiny
sequence number identifies the most recent known route to reach this destiny. Source
sequence number identifies the known route when RREP is transmitted from source. Thus,
non-updates routes will never be considered.
As RREQ travels from node to node, it automatically sets up the reverse path from all these
nodes back to the source. Each node that receives this packet records the address of the node
from which it was received. This is called Reverse Path Setup. The nodes maintain this
information for enough time for the RREQ to traverse the network and produce a reply to the
sender and time depends on network size.
Every node which receives a RREQ checks if there is an entry for the desired destination in its
routing table. If an entry is found and the destination sequence number is greater than that in
the RREQ, this node unicasts a Route Reply Packet (RREP) to the neighbour node from which
the RREQ was received. Otherwise, if the destination sequence number is lower than that in
the RREQ or there is no entry for the desired destination in its routing table, the node
rebroadcasts the RREQ to its neighbours. RREP message format is shown in Fig. 4-3.
Fig. 5-3 RREP packet format
Once the RREP is generated, it travels back to the source, based on the reverse path. As the
RREP travels back to source, each node along this path sets a forward pointer to the node from
where it is receiving the RREP and records the latest destination sequence number to the
request destination. This is called Forward Path Setup.
If an intermediate node receives another RREP after propagating the first RREP towards
source, it checks for destination sequence number of new RREP. The intermediate node
updates routing information and propagates new RREP only if the destination sequence
75
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
number is greater or the new sequence number is same and hop count is lower. Otherwise, it
just skips the new RREP. This ensures that algorithm is lopp-free and only the most effective
route is used.
Fig. 5-4 Route discovering mechanism, a) Source node initiates path discovering sendig RREQ
message b) Node A broadcasts RREQ message to its neighbor nodes
c) Destiny node
unicasts a RREP message to node C in order to reach source node
5.2.2.2.
Route maintenance mechanisms
Each node can get to know its neighbourhood by using local broadcasts, so-called hello
messages. Nodes neighbours are all the nodes that it can directly communicate with. Although
AODV is a reactive protocol it uses these periodic hello messages to inform the neighbours that
the link is still alive. The Hello messages will never be forwarded because they are broadcasted
with TTL = 1. When a node receives a hello message it refreshes the corresponding lifetime of
the neighbour information in the routing table.
If a node has received no messages from some outgoing node for an extended period of time,
then that node is presumed to be no longer reachable. Whenever a node determines one of its
next hops to be unreachable, it removes all affected route entries, and generates a Route Error
message (RERR). This RERR message contains a list of all destinations that have become
unreachable as a result of the broken link. The node sends the RERR to each of its precursors.
These precursors update their routing tables, and in turn forward the RERR to their precursors,
and so on, until the source node is reached.
When the source node receives the link failure notification message, it will re-initiate a route
discovery for the destination if a route is still needed. A new destination sequence number is
used to prevent routing loops formed by the entangling of obsoleted and new established
paths.
76
ROUTING PROTOCOLS FOR VANETS
To prevent RERR message loops, a node only forwards a RERR message if at least one route has
been removed.
5.2.2.3.
Comparative: AODV vs DSR
The following section is dedicated to illustrate existing similarities and differences between the
two most representative reactive routing protocols, AODV and DSR, as well as their advantages
and disadvantages. Table 4-1 shows a complete comparative between the features of both
protocols.
Features
DSR
AODV
Mechanism
Reactive source routing
Reactive hop-by-hop routing
Multiple routes for each destiny
Single route for each destiny
Each packet includes all path
information
Each packet only includes source and
destiny address
Only source node must update its
route table and stores all available
routes
All nodes must update their route
tables and stores only the newest
route
Routes
Discovering mechanism built on request messages
Discovering
procedure
Generates more loads of data
packets since all existing routes
are stored
Generates less loads of data packets
since there is only one stored route for
each destiny
Discovery mechanism only starts when a source node has data to transmit
Link failures are reported to source
node
Link failures are reported to the
precursor node
Source node is concerned about
how new/old routes are
A sequence number is required to
distinguish how new/old routes are
Only source node takes part in
routing path decision
All nodes take part in routing path
decision
Obsolet routes are still available
Only the newest route is available
Route
management
Better end-to-end delay and
Better end-to-end delay and latency in
latency in lightweight traffic and low heavyweight traffic and high mobility
mobility scenarios
scenarios
Performance
specifications
Higher overhead but low signalign
traffic
Lower overhead but higher signaling
traffic
Simetric links are not required
Simetric links are required
Table 5-1 Comparative AODV vs DSR
77
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
5.1. Geographical Routing Protocols
This section explains the routing protocols based on geographical location of the nodes,
especially the Geographical Source Routing protocols.
Many routing protocols have been developed for Mobile Ad-hoc Networks (MANETs), and
some of them can be applied directly to VANETs, such as AODV (Ad-hoc On demand Distance
Vector) and DSR (Dynamic Source Routing). However, VANET differs from MANET by its highly
dynamic topology.
A number of studies have been done to simulate and compare the performance of routing
protocols in various traffic conditions in VANETs, the simulation results showed that they
suffer from poor performances because of the characteristics of fast vehicle's movement,
dynamic information exchange and relative high speed of mobile nodes.
To consider the vehicle network, people can intuitively think to use the geographical position
information to decide the route. Most position based routing algorithms base forwarding
decision on location information. Geographical source routing (GSR) is a promising routing
technique for VANETs and recently several routing protocols have been proposed based on it.
For example, greedy routing always forwards the packet to the vehicle that geographically
closest to the destination. GPSR (Greedy Perimeter Stateless Routing) [90] is one of the best
known position-based protocols in literature. It combines the greedy routing with the
perimeter routing where greedy fails.
This protocols assumed that each vehicle is equipped with both a positioning device and, in
special cases, an electronic map. A location service is assumed to support geographic routing.
All nodes maintain a neighbour list, containing the neighbours’ location information.
5.1.1. GPSR
Greedy Perimeter Stateless Routing (GPSR) is a routing protocol for wireless datagram
networks that uses the positions of routers and a packet’s destination to make packet
forwarding decisions. GPSR makes greedy forwarding decisions using only information about a
router’s immediate neighbours in the network topology. When a packet reaches a region
where greedy forwarding is impossible, the algorithm recovers by routing around the
perimeter of the region. Under mobility’s frequent topology changes, GPSR can use local
topology information to find correct new routes quickly.
In networks comprised entirely of wireless stations, communication between source and
destination nodes may require traversal of multiple hops, as radio ranges are finite. A
community of ad-hoc network researchers has proposed, implemented, and measured a
variety of routing algorithms for such networks. The observation that topology changes more
rapidly on a mobile, wireless network than on wired networks, where the use of Distance
78
ROUTING PROTOCOLS FOR VANETS
Vector (DV), Link State (LS), and Path Vector routing algorithms is well-established. Traditional
shortest-path (DV and LS) algorithms require state proportional to the number of reachable
destinations at each router. On-demand ad-hoc routing algorithms require state at least
proportional to the number of destinations a node forwards packets toward, and often more,
as in the case in DSR, in which a node aggressively caches all source routes it overhears to
reduce the propagation scope of other nodes flooded route requests.
The following sections shows that geographic routing allows routers to be nearly stateless, and
requires propagation of topology information for only a single hop: each node need only know
its neighbors positions.
The self-describing nature of position is the key to geography’s usefulness in routing. The
position of a packet’s destination and positions of the candidate next hops are sufficient to
make correct forwarding decisions, without any other topological information.
GPSR assumes that all wireless routers know their own positions, either from a GPS device, or
through other means. GPSR assumes that packet sources can determine the locations of
packet destinations, to mark packets they originate with their destination’s location. Thus,
GPSR protocols assumes a location registration and lookup service that maps node addresses
to locations.
Greedy Perimeter Stateless Routing algorithm consists of two methods for forwarding packets:
greedy forwarding, which is used wherever possible, and perimeter forwarding, which is used
in the regions greedy forwarding cannot be.
Fig. 5-5 Data packet forwarding path
79
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
5.1.1.1.
GPSR Routing Algorithm
To greedy Perimeter Stateless Routing (GPSR), the so-called Greedy refers to that the packets
are optimal for each hop and the forwarding nodes look for a target node from the nearest
neighbours forwarding. Perimeter refers to the travel strategy.
Because of the presence of the hole, the forwarding nodes will not find even closer node to
the target than its own neighbour nodes, until the greedy strategy can be used again. No state
is the advantage of network nodes. It is no needs to save routing information and simply
saving the neighbour table is enough. As mentioned above GPSR is a geographic-based routing
algorithm. Before the packets are generated, the event source nodes, which collect the data,
must obtain the position information of destination node firstly.
Before intermediate nodes forward data, the location of the next hop neighbour should be
known. Neighbour node location is informed by sending broadcast packets, and the location of
the destination node, called sink, use the default location service system. Traditionally GPSR
routing algorithm can be described as Figure 2 [91].
Fig. 5-6 GPSR Flowchart
Fist, start-up node conducts HELLO and Complanation operations to get the neighbour node
location information. If the next hop node is the target node, the packets is sent directly and
the algorithm ends. Otherwise, greedy forwarding strategy is used.
If the holes do not appear in the network, the node chooses the closest neighbour to forward
the packet based on the location of the destination node, until it reaches the destination node.
When there is a hole in the network, the greedy algorithm cannot be operated correctly
because the next-hop node forwarding packets is more close to the source than the sink. In
this case perimeter forwarding strategy is used.
80
ROUTING PROTOCOLS FOR VANETS
5.1.1.1.1. Greedy Forwarding
Packets are marked by the source with their destination location. As a result, a forwarding
node can make a locally optimal, greedy choice in choosing a packet’s next hop. The locally
optimal choice of next hop is the neighbour geographically closest to the packet’s destination.
Forwarding in this regime follows successively closer geographic hops, until the destination is
reached. An example of greedy next hop choice appears in the next figure.
Fig. 5-7 Greedy Forwarding example. Y is x's closest neighbor to D.
Here, x receives a packet destined for D. x’s radio range is denoted by the dotted circle about
x, and the arc with radius equal to the distance between y and D is shown as the dashed arc
about D. x forwards the packet to y, as the distance between y and D is less than that between
D and any of x’s other neighbours. This greedy forwarding process repeats, until the packet
reaches D.
A simple beaconing algorithm provides all nodes with their neighbours’ positions: periodically,
each node transmits a beacon to the broadcast MAC address, containing only its own identifier
(IP address) and position.
Greedy forwarding’s great advantage is its reliance only on knowledge of the forwarding
node’s immediate neighbours. The state required is negligible and dependent on the density of
nodes in the wireless network, not the total number of destinations in the network.
On networks where multi-hop routing is useful, the number of neighbours within a node’s
radio range must be substantially less than the total number of nodes in the network. The
position a node associates with a neighbour becomes less current between beacons as that
neighbour moves.
This beaconing mechanism does represent pro-active routing protocol traffic, avoided by DSR
and AODV. To minimize the cost of beaconing, GPSR piggybacks the local sending node’s
position on all data packets it forwards, and runs all nodes network interfaces in promiscuous
mode, so that each station receives a copy of all packets for all stations within radio range.
At a small cost in bytes, this scheme allows all packets to serve as beacons. This optimization
reduces beacon traffic in regions of the network actively forwarding data packets. In fact,
81
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
GPSR’s beacon mechanism is fully reactive due to that nodes solicit beacons with a broadcast
“neighbour request” only when they have data traffic to forward.
The power of greedy forwarding to route using only neighbour nodes positions comes with
one attendant drawback: there are topologies in which the only route to a destination requires
a packet move temporarily farther in geometric distance from the destination. A simple
example of such a topology is shown in following figure.
Fig. 5-8 Greedy Forwarding failure. w and y are farther from D than x
Here, x is closer to D than its neighbours w and y. Again, the dashed arc about D has a radius
equal to the distance between x and D. Although two paths, (x → y → z → D) and (x → w → v
→ D), exist to D, x will not choose to forward to w or y using greedy forwarding. x is a local
maximum in its proximity to D. Some other mechanism must be used to forward packets in
these situations.
5.1.1.1.2. Perimeter Forwarding
In the previous figure the region is empty of neighbours. This empty region is showed in the
next figure.
Fig. 5-9 Node x's void with respect to destination D
From node x’s perspective, the shaded region without nodes is defined as void. x seeks to
forward a packet to destination D beyond the edge of this void. Intuitively, x seeks to route
82
ROUTING PROTOCOLS FOR VANETS
around the void; if a path to D exists from x, it doesn’t include nodes located within the void
(or x would have forwarded to them greedily). The long-known right-hand rule for traversing a
graph is depicted in the following figure.
Fig. 5-10 The right-hand rule. x revives a packet from y, and forwards it to z
This rule states that when arriving at node x from node y, the next edge traversed is the next
one sequentially counter clockwise about x from edge. It is known that the right-hand rule
traverses the interior of a closed polygonal region (a face) in clockwise edge order.
In this case, the triangle bounded by the edges between nodes x, y, and z, in the order (y → x
→ z → y). The rule traverses an exterior region, in this case, the region outside the same
triangle, in counter clockwise edge order.
In Figure 5-9, traversing the cycle (x → w → v → D) by the right-hand rule amounts to
navigating around the pictured void. However, the algorithm does not always find routes when
they exist.
While the previous algorithm finds the vast majority of routes (over 99.5% of the routes), it is
unacceptable for a routing algorithm persistently to fail to find a route to a reachable node in a
static, unchanging network topology.
There are alternative methods. A set of nodes with radios, where all radios have identical,
circular radio range r, can be seen as a graph: each node is a vertex, and edge (n, m) exists
between nodes n and m if the distance between n and m, d(n, m), is less or equal to r. It is
assumed that the nodes in the network have negligible difference in altitude, so that they can
be considered roughly in a plane.
The Relative Neighbourhood Graph (RNG) and Gabriel Graph (GG) are two planar graphs longknown in varied disciplines. Removing edges from the graph to reduce it to the RNG or GG
must not disconnect the graph; this would amount to partitioning the network. Given a
collection of vertices with known positions, the RNG is defined as follows:
83
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
An edge (u, v) exists between vertices u and v if the distance between them, d(u, v), is less
than or equal to the distance between every other vertex w, and whichever of u and v is
farther from w.
In equational form:
The following figure depicts the rule for constructing the RNG.
Fig. 5-11 The RNG graph. For edge (u,v) to be included, the shaded lune must contain no witness w
The shaded region, the lune between u and v, must be empty of any witness node w for (u, v)
to be included in the RNG. The boundary of the lune is the intersection of the circles about u
and v of radius d(u, v). Note that it is impossible disconnect the graph. (u, v) is only eliminated
from the graph when there exists a w within range of both u and v. Thus, eliminating an edge
requires an alternate path through a witness exist. Each connected component in an
unobstructed radio network will not be disconnected by removing edges not in the RNG.
Under the previously described beaconing mechanism, through which all nodes know their
immediate neighbours, if u and v can reach one another, they must both know all nodes with
the lune.
The GG is defined as follows: An edge (u, v) exists between vertices u and v if no other vertex
w is present within the circle whose diameter is uv.
In equational form:
The next figure depicts the GG graph membership criterion.
84
ROUTING PROTOCOLS FOR VANETS
Fig. 5-12 The GG graph. For edge (u,v) to be included, the shaded circle must contain no witness w
Eliminating edges in the GG cannot disconnect a connected unit graph, for the same reason as
was the case for the RNG. It has been shown in the literature that the RNG is a subset of the
GG. This is consistent with the smaller shaded region searched for a witness in the GG, as
compared with in the RNG.
The application of these techniques before perimeter forwarding makes it possible to find all
the routes.
5.1.1.1.
GPSR Improvements
The routing protocol performances can be improved by eMap additional information. The
improvement is important when there are many geographical obstacles or topology voids.
First, a graph is extracted from the e-map and is weighted based on both static information
(like lengths of road segments) and dynamic information (like vehicular traffic). Junctions,
terminals of roads and the positions of the source and destination nodes are represented as
vertexes and road segment between junctions are mapped as edges. Each edge is coupled with
a weight, whose value is proportional to the length of the road segment.
Once the graph is ready, the Dijkstra algorithm is applied to find a shortest path from the
source to the destination. Note that it is only considered the length of road segment when
computing the weights of edges. However, it is possible extend this model to incorporate
dynamic vehicular traffic information into the graph.
The second step is greedy forwarding. Typically the neighbour which is closest to the next
junction in a greedy fashion is designated as the next hop.
An evolution of GPSR based on eMaps and opportunistic routing concept it is explained below.
5.1.2. GOSR
As it seen above Geographical source routing is a promising routing technique for VANETs, due
to its adaptability for network dynamics and ability to handle topology holes.
85
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
In traditional geographical source routing algorithms a best-known neighbour, typically the
neighbour closest to the destination in a greedy fashion, is designated as the next hop. This
approach may cause two drawbacks: (1) the designated neighbour might not receive the
packet correctly and (2) non-neighbour nodes are never given opportunities to do forwarding.
Due to the broadcast nature of wireless media, non-neighbour nodes can overhear the
transmission and may offer better forwarding progress than the designated neighbour. The
above two factors both degrades the end-to-end delivery ratio. This section introduce the
concept of opportunistic routing to geographical source routing.
A routing protocol, named Geographical Opportunistic Source Routing (GOSR) allows nonneighbour nodes as well as the best known neighbour to become a forwarder [92]. The
notification cost of opportunistic routing is minimized by enforcing a scope from which
candidate forwarders are selected. Defer timers are adopted to avoid conflicts caused by
simultaneous transmissions by nodes in the designated scope. Opportunistic routing is a
routing technique which takes advantage of the broadcast nature of wireless media to achieve
better progress at each forwarding node.
There are several challenges for introducing opportunistic routing into dynamic networks such
as VANETs. First, due to the large scale nature of VANETs, global information like the delivery
ratio matrix between all pairs of nodes is not available. Existing opportunistic routing
protocols, which are developed for wireless mesh networks, all require this type of global
information to produce priorities for candidate forwarders. Second, the routing protocol
should be able to support generic data traffic. Finally, the routing protocol should be able to
effectively minimize the notification cost, which we will explain in detail later.
5.1.2.1.
GOSR Routing Algorithm
The GOSR protocol composes of two parts, namely geographical source route selection and
geographical opportunistic forwarding. Geographical source routes are computed in an ondemand fashion. Once a geographical source route is selected by the source node, GOSR
enters the geographical opportunistic forwarding phase.
On receiving a packet, the node checks whether it is within the designated scope by using the
last hop position and the scope information in the packet. If yes, it compares itself with the
best-known neighbour. If it is closer to the next junction than the best-known neighbour, it
becomes a candidate. Since there might be multiple candidates, we use defer timers to avoid
simultaneous transmissions. The defer time is computed using the formula:
86
ROUTING PROTOCOLS FOR VANETS
Where max_defer_time is a predefined value. Dsn is the distance between the last hop and the
best-known neighbour and Dcn is the distance between the current node and the best-known
neighbour. With this formula, the defer time of the best-known neighbour is max_defer_time
and the defer time of the node at margin of the scope is 0. In this way the best forwarding
opportunities are given higher priorities.
GOSR protocol for VANETs is simple but powerful routing algorithm combining GSR and
opportunistic routing. But GOSR still present poor performances in urban scenarios due to
obstacles such as buildings and trees. Moreover GOSR do not always find the optimal route,
especially in denser scenarios.
5.1.3. GSR Challenges
GPSR is a routing algorithm that uses geography to achieve small per-node routing state, small
routing protocol message complexity, and extremely robust packet delivery on densely
deployed wireless networks.
GOSR protocol for VANETs is simple but powerful routing algorithm combining GSR and
opportunistic routing.
Nevertheless GPSR and GOSR also suffer several from several problems in the city scenarios.
Firstly, greedy forwarding if often restricted because direct communications between vehicles
not exist due to obstacles such as buildings and trees. Secondly, if apply first the perimeter
forwarding and then return greedy, the routing performance will degrade. For example,
packets need to travel a longer path with higher delays. Thirdly the greedy part of GPSR and
GOSR can't always find the most optimal route to the destination, especially in the denser
scenario.
87
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
6. SIMULATION TOOLS
The following tools take part in the VANET simulation described in the current document:
VMware Player, Ubuntu, VanetMobiSim, NS2, AWK and GNU Octave. All three are open source
applications and are descripted in more detail below.
People who have experience with NS2 will know how difficult it is to install this tool.
Each version suffers from different problems according to the operating system used. Some
versions do not even work with some operative Systems. The absence of installation guides
makes this a difficult task. Therefore we strongly recommends to the person that want to
use the version of NS2 used in this work to use Ubuntu 32 bits for do the simulations, because
all the guides showed in this text are tested with this Operative System.
6.1. VMware Player
VMware Player [100] is a free version of the well-known virtualization software VMware.
This is a simple tool to have several operating systems on one machine. Is not necessary for do
the simulations but is very useful for the people that have not installed Ubuntu 32 bits.
An explanation of how to install VMware player is shown in annex
88
SIMULATION TOOLS
6.2. Ubuntu
Ubuntu [101] is a computer operating system based on the Debian Linux distribution and
distributed as free and open source software. Ubuntu is sponsored by the UK-based
company Canonical Ltd., owned by South African entrepreneur Mark Shuttleworth. Canonical
generates revenue by selling technical support and services related to Ubuntu, while the
operating system itself is entirely free of charge. The Ubuntu project is committed to the
principles of free software development.
Ubuntu is composed of many software packages, the vast majority of which are distributed
under a free software license. The only exceptions are some proprietary hardware
drivers. Ubuntu focuses on usability, security and stability. The Ubiquity installer allows
Ubuntu to be installed to the hard disk from within the Live CD environment, without the need
for restarting the computer prior to installation.
As a security feature, the sudo tool is used to assign temporary privileges for performing
administrative tasks, allowing the root account to remain locked, and preventing
inexperienced users from inadvertently making catastrophic system changes or opening
security holes.
Ubuntu Desktop includes a graphical desktop environment. In versions prior to 11.04 the
default GUI was GNOME Panel but it was dropped in favor of Unity, a graphical interface
Canonical first developed for the Ubuntu Netbook Edition.
Ubuntu comes installed with a wide range of software that includes LibreOffice (OpenOffice in
versions prior to 11.04), Firefox, Mozilla Thunderbird (Evolution in versions prior to
11.10), Empathy (Pidgin in versions before 9.10), Transmission, GIMP (in versions prior to
10.04), and several lightweight games (such as Sudoku and chess). Additional software that is
not installed by default can be downloaded and installed using the Ubuntu Software Center or
the package manager Synaptic, which come pre-installed in versions prior to 11.10. Ubuntu
allows networking ports to be closed using its firewall, with customized port selection
available. End-users can install Gufw (GUI for Uncomplicated Firewall) and keep it enabled.
GNOME (the former default desktop) offers support for more than 46 languages. Ubuntu can
also run many programs designed for Microsoft Windows (such as Microsoft Office),
through Wine or using a Virtual Machine (such as VMware Workstation or VirtualBox).
Ubuntu, unlike Debian, compiles their packages using gcc features such as PIE and Buffer
overflow protection to harden their software. These extra features greatly increase security at
the performance expense of 1% in 32 bit and 0.01% in 64 bit.
A short installation guide of Ubuntu 10.04 (32 bits) is showed in the annex.
89
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
6.3. VanetMobiSim
The Vehicular Ad Hoc Network Mobility Simulator (VanetMobiSim) is a set of extensions to
CanuMobiSim, a framework for user mobility modeling used by the CANU (Communications in
Ad Hoc Networks for Ubiquitous Computing) Research group [15], University of Stuttgart. The
framework includes a number of mobility models, as well as parsers for geographic data
sources in various formats, and a visualization module. The framework is based on the concept
of pluggable modules so that it is easily extensible.
The set of extensions provided by VanetMobiSim consists mainly on the two following:
A vehicular spatial model, composed of spatial elements (such as traffic lights or multi-lane
roads), their attributes and the relationships linking these spatial elements in order to describe
vehicular areas. The spatial model is created from topological data obtained in four different
ways:

User-defined – The user defines a set of vertices and edges composing the backbone of
the vehicular spatial model.

Random – The backbone is randomly generated using the Voronoi tesseletions.

Geographic Data Files (GDF) – Backbone data is obtained from GDF files.

TIGER/Line Files – Similar to previous one, but based on the TIGER/line files from the
US Census Bureau [18].
A set of vehicular-oriented mobility models, whose main compoments are the support of a
microscopic level mobility models:

Intelligent Driving Model with Intersection Management (IDM_IM), describing
perfectly car-to-car and intersection managements.

Intelligent Driving Model with Lane Changing (IDM_LC), an overtaking model is also
included, which interacts with IDM_IM to manage lanes changes and vehicle
accelerations and decelerations.
VanetMobiSim offers so many possibilities and features to create realistic scenarios. Besides
that, simulation scenarios for VanetMobiSim are defined in XML format using tags, making
scenario configuration easier and in a more handy way. Definitely, VanetMobiSim is quite
more appropiate in order to generate scenarios for VANETs than other MANETs mobility
pattern generators such as CityMob [21] and Bonnmotion [11].
A complete guide for install VanetMobisim is showed in the annex
90
SIMULATION TOOLS
6.4. NS2
The Network Simulator 2 (also popularly called NS2) is a discrete event network simulator
targeted at networking research. NS provides a packet level simulation over a lot of protocols,
supporting several transport protocols, several forms of multicast, wired networking, several
ad-hoc routing protocols and propagation models, data broadcasting, satellite and so on [63].
Also, NS2 has the possibility of using mobile nodes. The mobility of these nodes may be
specified either directly in the simulation file or by using a mobility trace file. In our case, the
trace file is generated by VanetMobiSim. Nearly all mobility pattern simulator (including the
aforementioned VanetMobiSim, CityMob and Bonnmotion) are implemented in order to
produce mobility trace files absolutely compatible with NS2 contrary to others network
simulator such as NCTUns [59], so that a whole simulation running both VanetMobiSim and
NS2 together can be carried out with total ease. Hence it is heavily used in ad hoc networking
research and has become popular in research due to its open source model and online
documentation. The last released version of this network simulator is NS2.34 (from Jun 17
2009).
NS began as a variant of the REAL network simulator in 1989 and has evolved substancially
over the past few years. In 1995 NS development was supported by DARPA through the VINT
[81], a collaborative project at LBNL (Lawrence Berkeley National Laboratory), Xerox PARC
(Xerox Palo Alto Research Center), UCB (University of California, Berkeley), and USC/ISINS
(University of Southern California’s Information Sciences Institute).
NS was built in C++ and provides a simulation interface through OTcl, an object-oriented
dialect of Tcl (Tool Command Language). The user describes a network topology by writing
OTcl scripts, and then the main NS program simulates that topology with specified parameters.
Moreover, NS2 is easily extensible since the simulation kernel source code is available, which
allows to implement new routing protocols, propagation models and so on, and use them in
our simulations.
In this work we used GPSR module of NS2.27. A complete guide to installing this version of NS2
can be found in [99]. Also this guide and the GPSR module installation guide are showed in the
annex.
6.5. AWK
The AWK utility is a data extraction and reporting tool that uses a data-driven scripting
language for the purpose of producing formatted reports. In other words, AWK is an excellent
filter and files of text processor. It was created at Bell Labs in 1970s, and its name is derived
from the family names of its authors – Alfred Aho, Peter Weinberger and Brian Kernighan.
A file is treated as a sequence of records, and by default each line is a record. Each line is
broken up into a sequence of fields, so we can think of the first word in a line as the first field,
the second word as the second field, and so on. AWK reads the input a line at a time. Then a
91
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
line is scanned for each pattern in the program, and for each pattern that matches, the
associated action is executed.
AWK is easier to use than most conventional programming languages. It can be considered to
be a pseudo-C interpretor, as it understands the same arithmetic operators as C. AWK also has
string manipulation functions, so it can search for particular strings and modify the output.
The Linux shell instruction to install AWK is showed in the annex.
6.6. GNU Octave
GNU Octave [97] is a high-level language, primarily intended for numerical computations. It
provides a convenient command-line interface (CLI) for solving linear and nonlinear problems
numerically, and for performing other numerical experiments using a language that is mostly
compatible with MATLAB. It may also be used as a batch-oriented language. As part of
the GNU Project, it is free software under the terms of the GNU General Public License (GPL).
We use this application for calculate the mean and the standart desviation of the simulation
results. It is not essential use this tool for the simulations but it is very useful.
To install GNU Octave on Ubuntu see the annex.
92
SIMULATION PROCESS
7. SIMULATION PROCESS
7.1. Introduction
In Fig. 6-8 the VANET simulation scheme is shown. After defining a mobility scenario in a XML
file, launching the VanetMobiSim framework is necessary in order to produce a node mobility
trace file in NS2 format (node identifier, time, position, speed). This file must be incorporate to
the communications definition file, implemented in Tcl language. After running NS2 a trace file
which logs all routing events during simulation is generated. Eventually, AWK tool is needed to
filter that events trace file extracting all significant data, allowing an evaluation of the scenario.
Furthermore, many scripts are designed to automate the simulation process and make it
easier. A step-by-step simulation review is presented showed in Annex.
93
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 7-1 VANET simulator based on coupling VanetMobiSim and NS2 [60]
7.2. Simulation files
For simplify the simulation process we have designed a significative number of scripts in
addition to the configuration files necessary to do the simulations. The files structure is
explained below.
In the next figures we can see different symbols. The meaning of each of these symbols is
shown in the following figure. It is only necessary modify the configuration files and the
modifiable scripts to do the simulation.
Fig. 7-2 Colour code Simulation files
94
SIMULATION PROCESS
The next figure shows the first part of the simulation process.
Fig. 7-3 Simulation process part 1
The directory (1) contains all necessary files to do the simulations with fixed routing protocol,
scenario, propagation model, and transmission range. The directory structure and some scripts
are different if the simulation is as a function of node density or node speed.
The file (2) named “clean” is a script for clean all the previous simulation trace and output files.
If we don’t execute this script the results obtained are the mean of new simulations and the
previous simulations. This is useful if you want to perform several simulations at different
times.
The file (3) named “start” is a script where we indicate the number of simulations for
each number of nodes (or average speed of each node) and the sleeping time between
each simulation. This script runs the script (4). This script named “exe” is an auxiliary script
used for monitoring the simulation time. This script executes the script (5).
The file (5) named “remotesimulation.sh” is a script that call “exe” scripts (7) located in other
directories (6). This directory contains the different configuration files for each number of
nodes (or each average node speed). In our simulations we have 6 directories (60, 75, 90, 105,
120, 135 nodes or 27.5, 32.5, 37.5, 42.5, 47.5, 52.5 km/h average node speed).
95
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 7-4 Simulation process part 2
The file (8) named “simulation.sh” is a script that executes a loop. This loop is executed so
times how indicate the start script (3). For each turn of the loop the script runs VanetMobisim
using (9) as a configuration file. We should modify this file named “scenario.xml” to define the
scenario settings. VanetMobisim generates a trace (10) necessary to execute NS2. Then (8)
executes the NS2.
The file (11) named “cbr.tcl” is a TCL script that indicates the features of the data packets
source. The file (12) named “simulation.tcl” is a TCL script necessary to make the NS2
simulation. This script contain all the simulation characteristics such as routing protocol,
number of nodes, simulation time, propagation model, transmission power etc.
NS2 generate a trace file (13). Then the script (8) executes awk filter (14). As a result we obtain
an output file (15) named “output.txt”. This process is executed in the loop several time and
the results are saved in the file (15). When the loop ends (8) runs (16) an Octave script. This
script calculates the mean and the uncertainty of the results obtained in the simulations.
Finally the trace file (17) named “result.txt” is generated.
96
SIMULATION PROCESS
Fig. 7-5 Simulation process part 3
At last (5) copy the trace file (17) for each number of nodes (or each average node speed) to
the directory (1) generating the file (18) named “result_N.txt” where N is the number of nodes
(or the average node speed) of the simulation.
All the scripts used are showed in the annex.
97
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
8. DESCRIPTION OF THE SIMULATIONS
This section aims to present the scenarios and network features used to implement
the simulations. As many empirical works, an initial configuration was firstly proposed and
gradually was fitted using trial and error method in order to adjust to VANET environments as
accurate as possible.
8.1. Scenarios
During simulation process four scenarios have been implemented in order to use all the
possibilities VanetMobiSim [80] offers. These scenarios are:

Manhattan grid scenario

Urban scenario with random street configuration

Real urban scenario extracted from TIGER/Line [18] maps

Real highway scenario extracted from TIGER/Line maps
A picture of each scenario is shown in Fig.7- 1.
The scenario chosen is based on the scenario described in the Paper [96].
In the urban with random street configuration scenario a 3000x1000 m² dimension has been
selected, including 6 traffic lights. In addition, the scenarios have been configured with singlelane as well as multi-lane lanes and differentiate two traffic flows. Regarding nodes, several
speeds have been selected as well as level of congestion. In addition, node's motion is
enhanced with Intelligent Driving Model (IDM), which incorporates intersection management
and lane changing.
98
DESCRIPTION OF THE SIMULATIONS
Fig. 8-1 Scenarios a) Manhattan grid
b) Urban random distribution
Highway TIGER/Line
c) Urban TIGER/Line
d)
Urban Random
Dimensions (m2)
3000x1000
Node Density (nodes/km2)
20 / 25 / 30 / 35 / 40 / 45
Traffic lights
6 with step=20ms
Lane Configuration
Differentiate two flows
Node Speed Range (km/h)
30 to 50
Mobility Pattern
Random Waypoint Mobility with obstacle Avoidance
[44]
99
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Intelligent Driving Model (IDM) with intersection
management and lane changing
Driving Model
Table 8-1 Scenario features overview
8.2. Parameters of the simulations
In this section the common used values as well as network configuration of the simulations in
NS2 are presented.

Simulation time is set to 1000 seconds. Nodes motion and transmission starts at t=0s.

Density of nodes has been set to 20, 25, 30, 35, 40 and 45 nodes/km2. In all
simulations there are only one source node and one destination node.

Each simulation has been carried out with 5, or 10 in some case, different seeds to
obtain more accurate results.

Three propagation models have been selected. Two-Ray Ground model, Ricean and
Rayleigh models. In the used version of NS2 (NS2.27) only the Two-Ray Ground is
implemented. However many propagation models are available as ns2 extensions.
Ricean and Rayleigh model extension is downloadable from [69].

Omni-directional antennas are selected with height (h) of 1,5m.

Receive threshold is set to RXthresh = 3.652e-10 W.

Sensing Threshold is set to CSthresh = 1.559e-11 W.

Transmission range (TR) is set to 100, 150, 200 and 250 meters. This parameter is
modified by changing the transmission power (Pt) according to the following
expression: TR = h · (Pt / RXthresh) 0.25

Transmission power is defined as Pt = RXthresh · (TR / h) 4

Sensing range is defined as SR = (RXthresh / CSthresh) 0.25 · TR = 2.2 · TR

IEEE 802.11 has been selected as MAC protocols.

The queue selected is PriQueue (Queue/DropTail/PriQueue) which gives priority to
routing packets. The queue size is set to 50 packets.

Source Traffic is configured as a CBR/UDP agent with a packet length of 32 bytes.

Finally, AODV, GPSR and DSR are the routing protocol used in the simulations.
The selected simulation values for each scenario are shown in Table.7-3.
Urban Random
Simulation time
100
1000 sec
DESCRIPTION OF THE SIMULATIONS
Node Density (nodes/km2)
20 / 25 / 30 / 35 / 40 / 45
Traffic Agent
CBR / UDP
Packet Lenght
32 bytes
Queue
PriQueue with size of 50 packets
Antenna
Omni-directional with height of 1,5m
MAC Protocol
IEEE 802.11
Propagation Model
TwoRayGround
Ricean
Rayleigh
Transmission Range
100 / 150 / 200 / 250
Routing Protocol
AODV / GPSR / DSR
Number of seeds
5 / 10
Table 8-2 Simulation features overview
The full list of configuration files with the parameters of the simulation is showed in Annex.
8.3. Evaluated metrics
In order to analyze the performance of vehicular ad hoc networks, extracting some
information from the simulations is required. As stated in Chapter 6, an AWK filter must be
implemented so that some metrics from traces files generated during simulation process can
be studied. The AWK filter file that we have designed is showed in the Annex. Our AWK filter
has been designed to extract the following metrics:
8.3.1. Packet Delivery Ratio (PDR)
It considers the percentage of data packets received by destination node relative to data
packets sent by source node. In order to calculate this metric, it must defined two counters:
CS and CR . The first one should be increased for every packet sent by source node. The latter
should be increased for every packet successfylly received by destination node. Eventually, the
data packet received ratio is defined by
𝑃𝐷𝑅 =
#𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑_𝑝𝑎𝑐𝑘𝑒𝑡𝑠
#𝑠𝑒𝑛𝑡_𝑝𝑎𝑐𝑘𝑒𝑡𝑠
(7.1)
101
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
8.3.1. Packet Loss Ratio (PLR)
It considers the percentage of data packets lost (data packets not received in the destination
node) relative to data packets sent by the source.
There is a direct relationship between Packet Loss Ratio and Packet Delivery Ratio. Packet Loss
Ratio is defined below
𝑃𝐿𝑅 =
#𝑙𝑜𝑠𝑡_𝑝𝑎𝑐𝑘𝑒𝑡𝑠
= 1 − 𝑃𝐷𝑅
#𝑠𝑒𝑛𝑡_𝑝𝑎𝑐𝑘𝑒𝑡𝑠
(7.2)
8.3.2. Average End-to-end delay (E2E)
It considers the time which a packet needs to go through the network from source node to
destination node. Once a packet with an ID i is sent by source node, the current time is stored
in the position i of an array (send_array[i]). If the packet with ID i is received by destination
node, the current time is stored in a second array (received_array[i]). The average end-to-end
delay is calculated by
𝐸2𝐸 =
∑𝑗∈𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑_𝑝𝑎𝑐𝑘𝑒𝑡𝑠(𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑_𝑎𝑟𝑟𝑎𝑦[𝑗] − 𝑠𝑒𝑛𝑑_𝑎𝑟𝑟𝑎𝑦[𝑗])
#𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑_𝑝𝑎𝑐𝑘𝑒𝑡𝑠
(7.3)
8.3.3. Data throughput
It considers the ratio between the total bandwidths measured in bps that source node is able
to inject to the network and reach destination node. Additionally, it is simple to
estimate the data throughput from the received data packet ratio and the number of bits sent
by the source.
Data throughput is defined as stated below:
𝑇𝐻𝑅𝑂𝑈𝐺𝐻𝑃𝑈𝑇[𝑡] =
#𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑_𝑏𝑖𝑡𝑠[𝑡]
[𝑏𝑝𝑠]
𝑡
𝑇𝐻𝑅𝑂𝑈𝐺𝐻𝑃𝑈𝑇[𝑡] = 𝑃𝐷𝑅 ×
102
#𝑠𝑒𝑛𝑑_𝑏𝑖𝑡𝑠[𝑡]
[𝑏𝑝𝑠]
𝑡
(7.4)
(7.5)
SIMULATION RESULTS
9. SIMULATION RESULTS
This chapter has the aim of analysing the results obtained from simulations run with NS2. The
chapter is structured as follows:
Firstly, the urban scenario with random street distribution is evaluated studying the global
metrics and showing how the system performance is affected by configured parameters as
node's density, node’s speed or transmission range. In fact, it is not the transmission range the
parameter configured, indeed is the transmission power the parameter that is configured. But
if you know the propagation model (for this evaluation, the selected propagation model is Two
Ray Ground) it is simple to estimate the transmission range (see chapter 8). Two Ray Ground is
obviously not a realistic model for urban environments, but is useful to compare routing
protocols. AODV (Ad-hoc On demand Distance Vector) [65], DSR (Dynamic Source Routing) [45]
and GPSR (Greedy Perimeter Stateless Routing) [90] protocols are compared. Afterwards,
different propagation models are studied. The objective is to evaluate how the communication
features of our urban scenario are affected by each of these propagation models and
comparing the results to what was described in Chapter 5.
Over 500 simulations have been run in order to carry out the following evaluation, without
considering another few hundred simulations used to test the implemented scenarios and
networks. We estimate the total estimated simulation time around 300 hours.
Finally, we must mention that all values in the following graphics are represented with its
confidence interval of 95% (see Annex)
103
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1. General evaluation of urban scenario
As mentioned before, a complete evaluation of our urban scenario is presented. The
simulation consists on a communication between two nodes: node with ID 0 sends CBR traffic
over UDP to node with ID 1.
In real environment many different nodes establish a communication with each other. Due to
the nature of radio communications, by increasing the number of sources the performance of
communication reduces. This is important especially for high sensing ranges because, for the
same node density, is more probable that the medium be busy due to other transmission. The
sensing range is proportional to the transmission power (like the transmission range). So the
transmission power should be small and also the transmission range. Eventually, four different
transmission ranges are considered from 100 meters to 250 meters.
The direct transmission of the packet is only possible if transmitter node and receiver node are
nearest than transmission range value. This transmission range corresponds to a sensing range
of 2.2 · Transmission range. It means that no further communication is possible within a radius
of sensing range value with respect to the transmission node.
The propagation model is Two Ray Ground. AODV and GPSR are compared. The evaluation is
carried out considering IEEE 802.11 MAC protocol.
Therefore the propagation model chosen and that the communication is only between 2 nodes
do the results of the simulation not very realistic. But the objective of the evaluation is
especially to compare different routing protocols. To achieve this goal it was sufficient with
this. Looking at the results you must always bear in mind that in a real scenario the
performance would be worse due to higher loss packet ratio and higher end-to-end delay,
induced for multipath propagation, shadowing, fading and packet collisions caused for multiple
transmissions (see Chapter 4).
We make 5 simulations for each number of nodes or each average node speed except for
transmission range of 250 meters. In this case we make 10 simulations to obtain more
accurate results.
9.1.1. Performance evaluation as a function of node density
In the following simulations the density of nodes increases from 20 nodes/km2 to 45
nodes/km2 and the speed of the nodes varies randomly between 30km/h and 50km/h.
104
SIMULATION RESULTS
9.1.1.1.
Transmission range of 100m
The first transmission range evaluated is 100 meters. This transmission range corresponds to a
sensing range of 220 meters.
9.1.1.1.1. Average Packet Delivery Ratio
The first evaluated metric is the average packet delivery ratio. The following table shows the
results of the simulation for each number of nodes.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Delivery Ratio
0,16394
0,14294
0,26706
0,211
0,12732
0,21968
0,092758 0,07932 0,098834 0,156546 0,083718
0,1859
Confidence Interval (95%)
Average Packet Delivery Ratio
0,039201 0,07901
0,04703
0,10698
0,075976 0,05746
Confidence Interval (95%)
0,029224 0,06478
0,03085
0,063531 0,035854 0,02047
Table 9-1 Average Packet Delivery ratio for transmission range of 100 m as a function of node
density
In the next graph we can see the same results of the previous table.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-1 Average Packet Delivery Ratio for transmission range of 100 m as a function of node
density
The average packet delivery ratio has an irregular trend. We can see that AODV outperforms
GPSR for any node density but for a small range. The results do not improve with the node
density. Anyway the performance is really poor for this transmission range.
105
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
The maximum value of average packet delivery ratio for AODV is around 26% and for GPSR is
approximately 11%. And the minimum value is higher than 14% for AODV and about 4% for
GPSR.
9.1.1.1.1. Average Packet Loss Ratio
The average packet loss ratio is a metric that provides the same information as average packet
delivery ratio. Thereefore, the same conclusions can be obtained. The average packet loss ratio
for each number of nodes is showed in the following table.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Loss Ratio
0,83606
0,85706
0,73294
0,789
0,87268
0,78032
Confidence Interval (95%)
0,092758 0,07932 0,098834 0,156546 0,083718
0,1859
Average Packet Loss Ratio
0,960799 0,92099
0,95297
0,89302
Confidence Interval (95%)
0,029224 0,06478
0,03085
0,063531 0,035854 0,02047
0,924024 0,94254
Table 9-2 Average Packet Loss Ratio for transmission range of 100 m as a function of node density
The previous data is represented in the figure shown below.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-2 Average Packet Loss Ratio for transmission range of 100 m as a function of node
density
It is verified that the transmission range of 100 meters is clearly insufficient because losses are
huge. With this transmission range few routes can be established.
106
SIMULATION RESULTS
9.1.1.1.2. Average End-to-end Delay
The next metric evaluated is the average end-to-end delay. The following table shows the
results for each number of nodes.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average End-to-end Delay (ms)
2481,3
4003,4
1738,8
3185
4154
4542,6
Confidence Interval (95%)
1161,68
2316,8
591,16
2192,6
3298,8
3988,4
Average End-to-end Delay (ms)
2,1721
2,5189
2,6183
2,7783
2,2511
2,1401
Confidence Interval (95%)
0,065258 0,45835 0,904932
1,00399
0,168744 0,03733
Table 9-3 Average End-to-end Delay for transmission range of 100 m as a function of node density
The following graph represents the values of the previous table.
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-3 Average End-to-end Delay for transmission range of 100 m as a function of node density
In contrast to results of average packet delivery ratio there is a large difference between AODV
and GPSR. GPSR outperforms AODV with a large difference. In some cases the average end-toend delay is more than 2000 times higher for AODV than GPSR. The difference is so big that we
must represent the graph with a logarithmic scale.
The highest average end-to-end delay for AODV is higher than 4,5 seconds. The maximum
value for GPSR is lower than 0,003 seconds. The minimum value for AODV is about 1,7 seconds
and for GPSR is around 0,002 seconds. GPSR presents a constant tendency and AODV has an
increasing tendency.
The results obtained for GPSR are really good but the results for AODV are awful. For real time
communications (e.g. voice or video streaming) 4 seconds of delay are unacceptable. In these
conditions AODV cannot be used for this type of communications.
107
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.1.2.
Transmission range of 150m
The next transmission range evaluated is of 150 meters. It is corresponding to a sensing range
of 330 meters.
9.1.1.2.1. Average Packet Delivery Ratio
As in the previous section the first feature evaluated is the average packet delivery ratio. The
results of the simulations are present in the following table.
AODV
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Delivery Ratio
0,27038
0,17432
0,34234
0,28503
0,42751
0,29432
Confidence Interval (95%)
0,164062 0,09779 0,142096 0,171214 0,195828 0,04895
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,036572 0,09148
0,24147
0,10895
0,12765
0,27052
0,016746 0,05519 0,133558 0,099625 0,063898 0,14122
Table 9-3 Average Packet Delivery Ratio for transmission range of 150 m as a function of node
density
The following graph shows the results of de above table.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-4 Average Packet Delivery Ratio for transmission range of 150 m as a function of node
density
It is possible to see a little improvement with respect the transmission range of 100 meters
presented in the previous section. This improvement is especially significant for high node
densities. It is caused because for higher node density is easier established a route.
108
SIMULATION RESULTS
GPSR continues to present lower results than AODV. Also the results are still poor. The
maximum average packet delivery ratio for GPSR is around 27% and for AODV is less than 43%.
The less value for AODV is around 17% and for GPSR is less than 4%.
AODV has an increasing trend with ups and downs with respect the node density. GPSR has a
increasing tendency from 20 nodes/km2 to 30 nodes/km and then presents a decreasing trend
form 30 nodes/km to 40 nodes/km2 with a final increase in the highest node densities.
For node density of 45 nodes/km2 the results are similar for GPSR and AODV.
9.1.1.2.2. Average Packet Loss Ratio
The average packet loss ratio for each number of nodes is showed in the following table.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Loss Ratio
0,72962
0,82568
0,65766
0,71497
0,57249
0,70568
Confidence Interval (95%)
0,164062 0,09779 0,142096 0,171214 0,195828 0,04895
Average Packet Loss Ratio
0,963428 0,90852
Confidence Interval (95%)
0,016746 0,05519 0,133558 0,099625 0,063898 0,14122
0,75853
0,89105
0,87235
0,72948
Table 9-4 Average Packet Loss Ratio for transmission range of 150 m as a function of node density
The next graph represents the values of the previous table.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-5 Average Packet Loss Ratio for transmission range of 150 m as a function of node
density
Although the results improve with respect the range of 100 meters, losses remain high. It is
verified that if the transmission range grows it is more probable cover some node.
109
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.1.2.3. Average End-to-end Delay
The results of the average end-to-end delay are shown below.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average End-to-end Delay (ms)
1700,2
1908
1838,2
2027
1549,5
1935,9
Confidence Interval (95%)
1085,36
1622,8
951,84
925,24
599,44
666,74
Average End-to-end Delay (ms)
2,1132
2,6741
2,5334
2,2241
4,8555
3,6419
Confidence Interval (95%)
0,044674 1,04746 0,707952 0,210739 1,472274 1,33797
Table 9-6 Average End-to-end Delay for transmission range of 150 m as a function of node density
The next figure represents the results of the table.
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-4 Average End-to-end Delay for transmission range of 150 m as a function of node density
In terms of average end-to-end delay the results are similar to the results for transmission
range of 100m. Although the average end-to-end delay for AODV is reduced with respect the
results of the previous section. Now AODV presents nearly 1000 times higher average end-toend delay compared to GPSR.
GPSR and AODV have a constant trend. The maximum value for GPSR is less than 0.005
seconds and for AODV is around 2 seconds. The minimum value for AODV is higher than 1,.5
seconds and for GPSR is about 0,002 seconds.
Although AODV has better results still 2 seconds of delay is too large for real time
communications.
110
SIMULATION RESULTS
9.1.1.3.
Transmission range of 200m
The next transmission range chosen is 200 meters. The sensing range is 440m.
9.1.1.3.1. Average Packet Delivery Ratio
The results of the average packet delivery ratio are shown in the following table.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Delivery Ratio
0,4724
0,62489
0,66706
0,80562
0,70089
0,67457
Confidence Interval (95%)
0,24526
0,15604 0,130472 0,081454
0,09152
0,09337
Average Packet Delivery Ratio
0,12372
0,2152
0,47023
0,30742
Confidence Interval (95%)
0,05959
0,07619 0,184224 0,159942 0,184003 0,18924
0,28246
0,35163
Table 9-7 Average Packet Delivery Ratio for transmission range of 200 m as a function of node
density
The next graph represents the values of the above table.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
20
25
30
35
40
45
Node Density (nodes/km2)
Figure 9-7 Average Packet Delivery Ratio for transmission range of 200 m as a function of node
desity
For this transmission range the differences between GPSR and AODV are bigger. The graph for
AODV presents an increasing trend until density is of 35 nodes/km2. Then the graph decreases.
GPSR also has an increasing tendency until node density of 40 nodes/km2. After the graph
decreases.
The higher value for AODV is around 80% and for GPSR is about 47%. The minimum value for
AODV is higher than 47% and for GPSR is around 12%.
111
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
AODV has an acceptably good results but GPSR has still poor performance in terms of average
packet delivery ratio. The tendency of GPSR is very similar to the results shown in [96]. In the
simulations of this paper the maximum of average packet delivery ratio is like in the graph
showed above.
9.1.1.3.1. Average Packet Loss Ratio
The table shown below contains the average packet loss ratio for each node density.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Loss Ratio
0,5276
0,37511
0,33294
0,19438
0,29911
0,32543
Confidence Interval (95%)
0,24526
0,15604 0,130472 0,081454
0,09152
0,09337
Average Packet Loss Ratio
0,87628
0,7848
0,52977
0,69258
Confidence Interval (95%)
0,05959
0,07619 0,184224 0,159942 0,184003 0,18924
0,71754
0,64837
Table 9-8 Average Packet Loss Ratio for transmission range of 200 m as a function of node density
The next graph represents the data of above table.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-8 Average Packet Loss Ratio for transmission range of 200 m as a function of node
density
As seen for average packet delivery ratio the results improve with respect to transmission
range of 150 meters. But, unlike previous transmission ranges, the average packet loss ratio
grows for high node densities because higher transmission range implies more nodes in the
neighbour location table. This incurs a high volume of control overhead. Hence, many
transmission errors occurs.
112
SIMULATION RESULTS
9.1.1.3.2. Average End-to-end Delay
The results in terms of average end-to-end delay are shown in the next table.
AODV
GPSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average End-to-end Delay (ms)
645,75
529,92
693,78
446,91
476,04
831,8
Confidence Interval (95%)
443,86
256,74
316,24
209,88
170,418
496,42
Average End-to-end Delay (ms)
2,3462
2,3225
3,1492
2,5454
3,081
3,397
Confidence Interval (95%)
0,278673 0,25302 1,366669 0,485296 0,814478 0,99335
Table 9-9 Average End-to-end Delay for transmission range of 200 m as a function of node density
The following figure shows the results of the previous table in a graph.
Average End-to-end Delay
Average End to End Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-9 Average End-to-end Delay for transmission range of 200 m as a function of node density
In this case the average end-to-end delay for AODV is reduced to less than half with respect to
the transmission range of 150 meters, but the results for AODV are so large compared to
GPSR.
The trend is constant, with randomly variations, for the two protocols. The maximum value for
AODV is about 0,832 seconds and for GPSR is less than 0,0034 seconds. The less value for
AODV is around 0,45 seconds and for GPSR is about 0,002 seconds.
113
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.1.4.
Transmission range of 250m
Finally this section shows the results for transmission range of 250 meters. The transmission
range is 550 meters.
This case corresponds exactly to the scenario described in the paper [96]. In that paper the
authors chose make 10 simulations for each number of nodes. For this reason we have decided
make 10 simulations for each number of nodes. So we can compare more accurately the
results obtained with the results exposed in the paper. We have also added the results of the
simulations with DSR routing protocol.
9.1.1.4.1. Average Packet Delivery Ratio
The average packet delivery ratio for each number of nodes is shown in the next table.
AODV
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Delivery Ratio
0,74542
0,76082
0,76105
0,72842
0,8249
0,73568
Confidence Interval (95%)
0,070846 0,10992 0,109142 0,066748 0,067282
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
DSR
0,26274
0,27875
0,31794
0,39779
0,48283
0,055
0,40242
0,113866 0,16283 0,118901 0,190173 0,180679 0,17478
Average Packet Delivery Ratio
0,68224
0,73998
0,59312
0,6839
0,73426
0,77488
Confidence Interval (95%)
0,2323
0,20758
0,23786
0,20314
0,24884
0,15286
Table 9-10 Average Packet Delivery Ratio for transmission range of 250 m as a function of node
density
The values of the previous table are represented in the next graph.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
DSR
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-10 Average Packet Delivery Ratio for transmission range of 250 m as a function of node
density
114
SIMULATION RESULTS
The average packet delivery ratio for GPSR is practically the same as for transmission range of
200 meters. Only the values are better for low densities. The trend is less abrupt.
For AODV the tendency is constant with a little decreases for node density of 35 nodes/km2
followed by little increases for node density of 40 nodes/km2.
We can see that DSR also outperforms GPSR in terms of average packet delivery ratio, but DSR
is not better than AODV.
9.1.1.4.1. Average Packet Loss Ratio
The following table shows the average packet loss ratio for each node density.
AODV
GPSR
DSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Loss Ratio
0,25458
0,23918
0,23895
0,27158
0,1751
0,26432
Confidence Interval (95%)
0,070846 0,10992 0,109142 0,066748 0,067282
Average Packet Loss Ratio
0,73726
Confidence Interval (95%)
0,113866 0,16283 0,118901 0,190173 0,180679 0,17478
Average Packet Loss Ratio
0,31776
0,26002
0,40688
0,3161
0,26574
0,22512
Confidence Interval (95%)
0,2323
0,20758
0,23786
0,20314
0,24884
0,15286
0,72125
0,68206
0,60221
0,51717
0,055
0,59758
Table 9-11 Average Packet Loss Ratio for transmission range of 250 m as a function of node
density
The next graph represents the values of the above table.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
DSR
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-11 Average Packet Loss Ratio for transmission range of 250 m as a function of node
density
115
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
As seen for average packet delivery ratio the results improve with respect to transmission
range of 200 meters. Like in previously section the average packet loss ratio grows for high
node densities. The reason is the same, higher transmission range implies more nodes in the
neighbour location table. As a result many transmission errors occurs due to high volume of
control overhead.
9.1.1.4.2. Average End-to-end Delay
At last the next table shows the average end-to-end delay for each number of nodes.
AODV
GPSR
DSR
Node Density (nodes/km2)
20
25
30
35
40
45
Average End-to-end Delay (ms)
565,98
543,25
512,23
586,75
296,89
419,7
Confidence Interval (95%)
218,66
329,3
296,76
349,86
123,42
134,91
Average End-to-end Delay (ms)
2,5432
2,9715
2,8684
4,2933
3,3428
4,4596
Confidence Interval (95%)
0,451172 0,90136 0,616048 1,942517 0,654424 1,89169
Average End-to-end Delay (ms)
4745
4114,1
7001,8
5546,4
3636,7
4571,3
Confidence Interval (95%)
4031,4
3966,6
4288,2
4174,4
2996,6
3748
Table 9-12 Average End-to-end Delay for transmission range of 250 m as a function of node density
The following graph represents the results of the previous table.
Average End-to-end Delay
Average End-to-end Delay (s)
100
10
1
AODV
0.1
GPSR
DSR
0.01
0.001
20
25
30
Node Density
35
40
45
(nodes/km2)
Figure 9-12 Average End-to-end Delay for transmission range of 250 m as a function of node
density
The average end-to-end delay for AODV is not significantly reduced with respect the
transmission range of 200 meters. As we noted previously GPSR does not change compared
with the average end-to-end delay for others transmission ranges. Although GPSR seems to
have an increasing trend with the node density and AODV seems to have a decreasing
tendency.
116
SIMULATION RESULTS
AODV has a maximum value of average end-to-end delay less than 0,57 seconds and GPSR has
a higher value around 0,005 seconds. The less value is nearly 0.3 seconds for AODV and 0.002
seconds for GPSR.
In terms of average end-to-end delay DSR is worse than AODV and GPSR.
9.1.2. Performance evaluation as a function of node speed
In the following simulations the number of nodes is fixed to 100 nodes (33.33 nodes/km2) and
the average node speed increases from 27.5 km/h to 52.5 km/h.
9.1.2.1.
Transmission range of 100m
9.1.2.1.1. Average Packet Delivery Ratio
The next table shows the average packet delivery ratio for each average node speed.
AODV
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Delivery Ratio
0,23161
0,15388
0,15137
0,19154
0,15219
0,2641
Confidence Interval (95%)
0,11584
0,11403
0,11739
0,114767 0,083737 0,11258
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,052567 0,05501 0,084424
0,04994
0,045347 0,06498
0,050497 0,03884 0,045937 0,021468 0,022795 0,03862
Table 9-13 Average Packet Delivery Ratio for transmission range of 100 m as a function of node
speed
Below it is possible to see a graph that represents the values of the above table.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-13 Average Packet Delivery Ratio for transmission range of 100 m as a function of node
speed
117
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
There is not an appreciable change of the average delivery ratio for this range of average node
speed. Also, as we have seen for the performance evaluation as a function of node density,
that AODV outperforms GPSR.
9.1.2.1.1. Average Packet Loss Ratio
As stated previously the average packet loss ratio shows the same information that average
packet delivery ratio but from another perspective. The table shown below contains the
average packet loss ratio for each average node speed.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Loss Ratio
0,76839
0,84612
0,84863
0,80846
0,84781
0,7359
Confidence Interval (95%)
0,11584
0,11403
0,11739
0,114767 0,083737 0,11258
Average Packet Loss Ratio
0,947433 0,94499 0,915576
Confidence Interval (95%)
0,050497 0,03884 0,045937 0,021468 0,022795 0,03862
0,95006
0,954653 0,93502
Table 9-14 Average Packet Loss Ratio for transmission range of 100 m as a function of node speed
The following figure represents the data of the previous table.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-11 Average Packet Loss Ratio for transmission range of 100 m as a function of node
speed
As for the analysis as function of node density we can see that transmission range of 100
meters is not sufficient because the losses are so large.
118
SIMULATION RESULTS
9.1.2.1.2. Average End-to-end Delay
The next table shows the average end-to-end delay for different average node speed.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average End-to-end Delay (ms)
3216
2198,6
5074,6
2564
2389,7
1613,5
Confidence Interval (95%)
2051,532 1080,04 2462,152 1306,575 601,8964 720,476
Average End-to-end Delay (ms)
Confidence Interval (95%)
2,6682
2,1567
2,1752
3,0267
2,1644
3,0832
1,040133 0,03191 0,046381 1,226215 0,037518 1,22355
Table 9-15 Average End-to-end Delay for transmission range of 100 m as a function of node speed
The figure shown below represents the values of the above table in a graph.
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-15 Average End-to-end Delay for transmission range of 100 m as a function of node speed
It seems that for AODV the average end-to-end delay decreases for highest average node
speed and GPSR remains constant.
119
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.2.2.
Transmission range of 150m
9.1.2.2.1. Average Packet Delivery Ratio
The next table shows the average packet delivery ratio for different average node speed.
AODV
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Delivery Ratio
0,41409
0,35359
0,44496
0,3586
0,45173
0,49217
0,094854 0,13657 0,158838 0,144234
0,05764
0,23381
0,19521
0,14374
0,11629
Confidence Interval (95%)
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,05312
0,13094
0,15803
0,071599 0,01819 0,102383 0,080897 0,054541 0,06369
Table 9-16 Average Packet Delivery Ratio for transmission range of 150 m as a function of node
speed
We can see the previous values represented in the following graph.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-16 Average Packet Delivery Ratio for transmission range of 150 m as a function of node
speed
The graph does not appear to follow any trend. Values remain constant within a few random
variations
120
SIMULATION RESULTS
9.1.2.2.1. Average Packet Loss Ratio
In the following table it is possible to see the average packet loss ratio for each average node
speed.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Loss Ratio
0,58591
0,64641
0,55504
0,6414
0,54827
0,50783
Confidence Interval (95%)
0,094854 0,13657 0,158838 0,144234
0,05764
0,23381
Average Packet Loss RAtio
0,80479
0,85626
0,88371
Confidence Interval (95%)
0,071599 0,01819 0,102383 0,080897 0,054541 0,06369
0,94688
0,86906
0,84197
Table 9-17 Average Packet Loss Ratio for transmission range of 150 m as a function of node speed
The next graph represents the data of the previous table.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-17 Average Packet Loss Ratio for transmission range of 150 m as a function of node
speed
For transmission range of 150 meters more routes can be established and the losses are lower
than for transmission range of 100 meters.
121
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.2.2.2. Average End-to-end Delay
The average end-to-end delay for different average node speed is shown in the next table.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average End-to-end Delay (ms)
1272,2
1428,8
1405,1
1544,5
851,89
731,36
Confidence Interval (95%)
360,4048 605,816 956,8132 801,2872 343,3528 367,049
Average End-to-end Delay (ms)
Confidence Interval (95%)
2,3162
2,9305
2,312
3,2716
2,6519
0,214208 1,56945 0,276282 1,256223 0,423399
2,7627
0,2225
Table 9-18 Average End-to-end Delay for transmission range of 150 m as a function of node speed
The following graph represents the values of the above table.
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-18 Average End-to-end Delay for transmission range of 150 m as a function of node speed
In terms of average end-to-end delay AODV presents lowest values for highest speeds.
However GPSR remains constant.
122
SIMULATION RESULTS
9.1.2.3.
Transmission range of 200m
9.1.2.3.1. Average Packet Delivery Ratio
The results of the average end-to-end delay are shown below.
AODV
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Delivery Ratio
0,63168
0,61133
0,65013
0,54536
0,4874
0,59594
0,127786 0,16069 0,117892 0,119948
0,21068
0,17701
0,24115
0,26271
0,15072
Confidence Interval (95%)
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,22585
0,26445
0,26865
0,147018 0,14007 0,110881 0,124165 0,091246 0,15194
Table 9-19 Average Packet Delivery Ratio for transmission range of 200 m as a function of node
speed
The next figure represents the results of the table.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-19 Average Packet Delivery Ratio for transmission range of 200 m as a function of node
speed
As in previous cases, the graphs shows that the average packet delivery ratio has a constant
trend with a few randomly variations.
123
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.2.3.2. Average Packet Loss Ratio
The results in terms of average packet loss ratio are shown in the next table.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Loss Ratio
0,36832
0,38867
0,34987
0,45464
0,5126
0,40406
Confidence Interval (95%)
0,127786 0,16069 0,117892 0,119948
0,21068
0,17701
Average Packet Loss Ratio
0,75885
0,73729
0,84928
Confidence Interval (95%)
0,147018 0,14007 0,110881 0,124165 0,091246 0,15194
0,77415
0,73555
0,73135
Table 9-20 Average Packet Loss Ratio for transmission range of 200 m as a function of node speed
We can see the previous values represented in the graph shown below.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-20 Average Packet Loss Ratio for transmission range of 200 m as a function of node
speed
Following the same progression as in previous cases for this transmission range more routes
can be established and as a result the losses are lower.
124
SIMULATION RESULTS
9.1.2.3.3. Average End-to-end Delay
The average end-to-end delay for each average node speed is shown below.
AODV
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average End-to-end Delay (ms)
720,6
864,24
821,77
912,16
1621,2
1399,7
Confidence Interval (95%)
Average End-to-end Delay (ms)
GPSR
Confidence Interval (95%)
498,9376 705,404 283,8276 332,8276 1210,555 905,108
3,4659
2,8648
2,6234
4,3701
2,7947
1,438601 0,84437 0,632492 1,854905 0,878825 1,83956
Table 9-21 Average End-to-end Delay for transmission range of 200 m as a function of node speed
The following figure is a graph that represents the values of the above table.
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
27.5
32.5
37.5
3,8058
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-21 Average End-to-end Delay for transmission range of 200 m as a function of node speed
Unlike in previous cases the average end-to-end delay increases when the average node speed
grows.
125
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.2.4.
Transmission range of 250m
In this case also have been performed 10 simulations for each average node speed. The reason
is already explained above.
9.1.2.4.1. Average Packet Delivery Ratio
As in previous cases first we can see the average packet delivery ratio for different average
node speed in the next table.
AODV
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Delivery Ratio
0,72753
0,68648
0,73791
0,82593
0,79826
0,77118
0,109744 0,10995
0,09773
0,068876 0,082922 0,07491
0,56322
0,44583
0,51021
Confidence Interval (95%)
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,47895
0,47342
0,3717
0,191717 0,18511 0,158511 0,150626 0,186265 0,20364
Table 9-22 Average Packet Delivery Ratio for transmission range of 250 m as a function of node
speed
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-22 Average Packet Delivery Ratio for transmission range of 250 m as a function of node
speed
For transmission range of 250 meters seems that the average packet delivery ratio has an
increasing trend for AODV and decreasing trend for GPSR.
126
SIMULATION RESULTS
9.1.2.4.1. Average Packet Loss Ratio
The average packet loss ratio for each average node speed is shown in the next table.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average Packet Loss Ratio
0,27247
0,31352
0,26209
0,17407
0,20174
0,22882
Confidence Interval (95%)
0,109744 0,10995
0,09773
0,068876 0,082922 0,07491
Average Packet Loss Ratio
0,43678
0,55417
0,48979
Confidence Interval (95%)
0,191717 0,18511 0,158511 0,150626 0,186265 0,20364
0,52105
0,52658
0,6283
Table 9-23 Average Packet Loss Ratio for transmission range of 250 m as a function of node speed
The values of the above table are represented in the following graph.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-23 Average Packet Loss Ratio for transmission range of 250 m as a function of node
speed
The maximum average packet loss ratio for AODV is around 32% and for GPSR is higher than
55%. The minimum value is higher than 17% for AODV and less than 44%for GPSR.
127
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.2.4.2. Average End-to-end Delay
Finally it is possible to see the average end-to-end delay for different average node speed in
the table shown below.
AODV
GPSR
Average Node Speed (km/h)
27,5
32,5
37,5
42,5
47,5
52,5
Average End-to-end Delay (ms)
687,98
744,82
566,96
402,91
376,15
404,2
Confidence Interval (95%)
338,9624 432,729 255,7016 246,8228 213,1304 244,549
Average End-to-end Delay (ms)
Confidence Interval (95%)
4,6333
4,8432
2,9799
1,428762 1,80063 0,524065
3,8819
1,54301
5,1607
3,1062
2,127188 0,88859
Table 9-24 Average End-to-end Delay for transmission range of 250 m as a function of node speed
The following graph represents the values of the previous table.
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
27.5
32.5
37.5
42.5
47.5
52.5
Average Node Speed (km/h)
Figure 9-24 Average End-to-end Delay for transmission range of 250 m as a function of node speed
Now The average end-to-end deal has a decreasing trend with respect the average node
speed. This suggests that the influence of the random nature of the simulations is higher than
the effect of the change of the transmission range parameter, because for a transmission
range of 200 meters the trend was different.
128
SIMULATION RESULTS
9.1.3. Performance evaluation as a function of transmission range
This part of the text presents the same results of the previous evaluations but as a function of
transmission range. Then be verified that the average packet delivery ratio increases with
transmission range generally because if transmission range grows the probability of cover
some nodes also grows. This makes it easier to establish a route. This increasing trend is
especially significant when transmission range passes 150 to 200 meters.
In terms of average end-to-end delay AODV has a decreasing trend. As in average packet
delivery ratio analysis the decrease is especially significant when transmission range passes
150 to 200 meters. GPSR instead presents a constant tendency.
The graphics and tables with all data for each node density are shown below.
9.1.3.1.
Node Density of 20 nodes/km2
9.1.3.1.1. Average Packet Delivery Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Delivery Ratio
0,16394
0,27038
0,4724
0,74542
Confidence Interval (95%)
0,092758 0,16406
0,24526
0,070846
Average Packet Delivery Ratio
0,039201 0,03657
0,12372
0,26274
Confidence Interval (95%)
0,029224 0,01675
0,05959
0,113866
Table 9-25 Average Packet Delivery Ratio for node density of 20 nodes/km2 as a function of
transmission range
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-25 Average Packet Delivery Ratio for node density of 20 nodes/km 2 as a function of
transmission range
129
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
As discussed in previous sections, for the same node density is more probable that a route can
be established if the transmission radius is larger. As a result the average packet delivery ratio
as a function of transmission range has an increasing trend.
9.1.3.1.1. Average Packet Loss Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Loss Ratio
0,83606
0,72962
0,5276
0,25458
Confidence Interval (95%)
0,092758 0,16406
0,24526
0,070846
Average Packet Loss Ratio
0,960799 0,96343
0,87628
0,73726
Confidence Interval (95%)
0,029224 0,01675
0,05959
0,113866
Table 9-26 Average Packet Loss Ratio for node density of 20 nodes/km 2 as a function of
transmission range
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-26 Average Packet Loss Ratio for node density of 20 nodes/km 2 as a function of
transmission range
For AODV the maximum average packet loss ratio is around 83% and for GPSR is high than
96%. The minimum average packet loss ratio is less than 26% for AODV and around 74% for
GPSR.
130
SIMULATION RESULTS
9.1.3.1.2. Average End-to-end Delay
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average End-to-end Delay (ms)
2481,3
1700,2
645,75
565,98
Confidence Interval (95%)
1161,68
1085,36
443,86
218,66
Average End-to-end Delay (ms)
2,1721
2,1132
2,3462
2,5432
Confidence Interval (95%)
0,065258 0,04467 0,278673 0,451172
Table 9-27 Average End-to-end Delay for node density of 20 nodes/km2 as a function of
transmission range
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
100
150
200
250
Transmission Range (m)
Figure 9-27 Average End-to-end Delay for node density of 20 nodes/km2 as a function of
transmission range
For AODV if the transmission range grows more nodes are covered and the hops of the
transmission decreases. This means that the delay decrease when transmission range grows.
131
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.2.
Node Density of 25 nodes/km2
9.1.3.2.1. Average Packet Delivery Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Delivery Ratio
0,14294
0,17432
0,62489
0,76082
Confidence Interval (95%)
0,07932
0,09779
0,15604
0,10992
Average Packet Delivery Ratio
0,07901
0,09148
0,2152
0,27875
Confidence Interval (95%)
0,06478
0,05519
0,07619
0,16283
Table 9-28 Average Packet Delivery Ratio for node density of 25 nodes/km 2 as a function of
transmission range
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-28 Average Packet Delivery Ratio for node density of 25 nodes/km 2 as a function of
transmission range
As for the previous case the average packet delivery ratio has an increasing tendency. In this
case the gap is especially significant when the transmission range passes from 150 meters to
200 meters.
132
SIMULATION RESULTS
9.1.3.2.1. Average Packet Loss Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Loss Ratio
0,85706
0,82568
0,37511
0,23918
Confidence Interval (95%)
0,07932
0,09779
0,15604
0,10992
Average Packet Loss Ratio
0,92099
0,90852
0,7848
0,72125
Confidence Interval (95%)
0,06478
0,05519
0,07619
0,16283
Table 9-29 Average Packet Loss Ratio for node density of 25 nodes/km 2 as a function of
transmission range
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-29 Average Packet Loss Ratio for node density of 25 nodes/km 2 as a function of
transmission range
The maximum packet loss ratio for AODV is higher than 85% and the minimum is less than
24%. For GPSR the maximum packet loss ratio is around 92% and the minimum is higher than
72%.
133
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.2.2. Average End-to-end Delay
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average End-to-end Delay (ms)
4003,4
1908
529,92
543,25
Confidence Interval (95%)
2316,8
1622,8
256,74
329,3
Average End-to-end Delay (ms)
2,5189
2,6741
2,3225
2,9715
0,45835 1,04746
0,25302
0,90136
Confidence Interval (95%)
Table 9-30 Average End-to-end Delay for node density of 25 nodes/km2 as a function of
transmission range
Average End-to-end Delay
Average End-to-End Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
100
150
200
250
Transmission Range (m)
Figure 9-30 Average End-to-end Delay for node density of 25 nodes/km2 as a function of
transmission range
The average end-to-end delay has the same trend that in the previous cases. For AODV has a
decreasing trend and for GPSR remains constant.
134
SIMULATION RESULTS
9.1.3.3.
Node Density of 30 nodes/km2
9.1.3.3.1. Average Packet Delivery Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Delivery Ratio
0,26706
0,34234
0,66706
0,76105
Confidence Interval (95%)
0,098834
0,1421
0,130472 0,109142
Average Packet Delivery Ratio
0,10698
0,24147
0,28246
Confidence Interval (95%)
0,31794
0,063531 0,13356 0,184224 0,118901
Table 9-31 Average Packet Delivery Ratio for node density of 30 nodes/km2 as a function of
transmission range
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-31 Average Packet Delivery Ratio for node density of 30 nodes/km 2 as a function of
transmission range
In this graph we can see that the results are so similar as for node density of 25 nodes/km2.
135
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.3.1. Average Packet Loss Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Loss Ratio
0,73294
0,65766
0,33294
0,23895
Confidence Interval (95%)
0,098834
0,1421
0,130472 0,109142
Average Packet Loss Ratio
0,89302
0,75853
0,71754
Confidence Interval (95%)
0,063531 0,13356 0,184224 0,118901
0,68206
Table 9-32 Average Packet Loss Ratio for node density of 30 nodes/km 2 as a function of
transmission range
Average Packet Loss Ratio
1
0.9
Average Losses
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-32 Average Packet Loss Ratio for node density of 30 nodes/km 2 as a function of
transmission range
For AODV the maximum packet loss ratio is higher than 73% and for GPSR is less than 90%. The
minimum packet loss ratio for AODV is less than 24% and for GPSR is around 68%.
136
SIMULATION RESULTS
9.1.3.3.2. Average End-to-end Delay
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average End-to-end Delay (ms)
1738,8
1838,2
693,78
512,23
Confidence Interval (95%)
591,16
951,84
316,24
296,76
Average End-to-end Delay (ms)
2,6183
5,5334
3,1492
2,8684
Confidence Interval (95%)
0,904932 0,70795 1,366669 0,616048
Table 9-33 Average End-to-end Delay for node density of 30 nodes/km2 as a function of
transmission range
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
100
150
200
250
Transmission Range (m)
Figure 9-33 Average End-to-end Delay for node density of 30 nodes/km2 as a function of
transmission range
The behaviour in this case is the same that in the cases that we have seen. Only we can
appreciate unusual value for transmission range of 150 meters for GPSR, because it is greater
than we expected it.
137
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.4.
Node Density of 35 nodes/km2
9.1.3.4.1. Average Packet Delivery Ratio
AODV
Transmission Range (m)
100
150
200
250
Average Packet Delivery Ratio
0,2115
0,28503
0,80562
0,72842
Confidence Interval (95%)
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,156546 0,17121 0,081454 0,066748
0,10698
0,10895
0,35163
0,39779
0,063531 0,09963 0,159942 0,190173
Table 9-34 Average Packet Delivery Ratio for node density of 35 nodes/km2 as a function of
transmission range
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-34 Average Packet Delivery Ratio for node density of 35 nodes/km 2 as a function of
transmission range
AODV has an increasing trend from 100 meters to 200 meters and decreasing trend from 200
meters to 250 meters. This behaviour is probably caused for the random nature of the
simulations rather than consequence of change in node density.
138
SIMULATION RESULTS
9.1.3.4.1. Average Packet Loss Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Loss Ratio
0,7885
0,71497
0,19438
0,27158
Confidence Interval (95%)
0,156546 0,17121 0,081454 0,066748
Average Packet Loss Ratio
0,89302
Confidence Interval (95%)
0,063531 0,09963 0,159942 0,190173
0,89105
0,64837
0,60221
Table 9-35 Average Packet Loss Ratio for node density of 35 nodes/km 2 as a function of
transmission range
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-35 Average Packet Loss Ratio for node density of 35 nodes/km 2 as a function of
transmission range
The maximum average packet loss ratio for AODV is higher than 78% and the minimum is
around 27%. For GPSR the maximum is higher than 89% and the minimum is around 60%.
139
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.4.2. Average End-to-end Delay
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average End-to-end Delay (ms)
3185
2027
446,91
586,75
Confidence Interval (95%)
2292,6
925,24
209,88
349,86
Average End-to-end Delay (ms)
2,7783
2,2241
2,5454
4,2933
Confidence Interval (95%)
1,00399
0,21074 0,485296 1,942517
Table 9-36 Average End-to-end Delay for node density of 35 nodes/km2 as a function of
transmission range
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
100
150
200
250
Transmission Range (m)
Figure 9-36 Average End-to-end Delay for node density of 35 nodes/km2 as a function of
transmission range
The average end-to-end delay has the same trend that in previous case but with a little
increase for higher transmission range.
140
SIMULATION RESULTS
9.1.3.5.
Node Density of 40 nodes/km2
9.1.3.5.1. Average Packet Delivery Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Delivery Ratio
0,12732
0,42751
0,70089
0,8249
Confidence Interval (95%)
0,083718 0,19583
0,09152
0,067282
Average Packet Delivery Ratio
0,075976 0,12765
0,47023
0,48283
0,035854
0,184003 0,180679
Confidence Interval (95%)
0,0639
Table 9-37 Average Packet Delivery Ratio for node density of 40 nodes/km2 as a function of
transmission range
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-37 Average Packet Delivery Ratio for node density of 40 nodes/km 2 as a function of
transmission range
In this case, for GPSR, the graph saturates for transmission ranges between 200 and 250
meters. For AODV the graph has the typically increasing tendency.
141
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.5.1. Average Packet Loss Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Loss Ratio
0,87268
0,57249
0,29911
0,1751
Confidence Interval (95%)
0,083718 0,19583
0,09152
0,067282
Average Packet Loss Ratio
0,924024 0,87235
0,52977
0,51717
Confidence Interval (95%)
0,035854
0,184003 0,180679
0,0639
Table 9-38 Average Packet Loss Ratio for node density of 40 nodes/km 2 as a function of
transmission range
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-38 Average Packet Loss Ratio for node density of 40 nodes/km2 as a function of
transmission range
The maximum average packet loss ratio is around 87% for AODV and higher than 92% for
GPSR. The minimum value is less than 18% for AODV and less than 52% for GPSR.
142
SIMULATION RESULTS
9.1.3.5.2. Average End-to-end Delay
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average End-to-end Delay (ms)
4154
1549,5
476,04
296,89
Confidence Interval (95%)
3298,8
599,44
170,418
123,42
Average End-to-end Delay (ms)
2,2511
4,8555
3,081
3,3428
Confidence Interval (95%)
0,168744 1,47227 0,814478 0,654424
Table 9-39 Average End-to-end Delay for node density of 40 nodes/km2 as a function of
transmission range
Average-End-to-end Delay
Average End-to-End Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
100
150
200
250
Transmission Range (m)
Figure 9-39 Average End-to-end Delay for node density of 40 nodes/km2 as a function of
transmission range
For AODV the end-to-end delay have the trend yet seen and for GPSR is similar to the other
cases with a little difference for transmission range of 150 meters where the end-to-end delay
increase.
143
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.6.
Node Density of 45 nodes/km2
9.1.3.6.1. Average Packet Delivery Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Delivery Ratio
0,21968
0,29432
0,67457
0,73568
Confidence Interval (95%)
0,1859
0,04895
0,09337
0,055
Average Packet Delivery Ratio
0,05746
0,27052
0,30742
0,40242
Confidence Interval (95%)
0,02047
0,14122
0,18924
0,17478
Table 9-40 Average Packet Delivery Ratio for node density of 45 nodes/km2 as a function of
transmission range
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-40 Average Packet Delivery Ratio for node density of 45 nodes/km2 as a function of
transmission range
As it is possible to see in the above graph the average packet delivery ratio for AODV and GPSR
are very similar when transmission range is 150 meters. For the rest the graph has the same
trend that in previous case.
144
SIMULATION RESULTS
9.1.3.6.1. Average Packet Loss Ratio
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average Packet Loss Ratio
0,78032
0,70568
0,32543
0,26432
Confidence Interval (95%)
0,1859
0,04895
0,09337
0,055
Average Packet Loss Ratio
0,94254
0,72948
0,69258
0,59758
Confidence Interval (95%)
0,02047
0,14122
0,18924
0,17478
Table 9-41 Average Packet Loss Ratio for node density of 45 nodes/km 2 as a function of
transmission range
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
100
150
200
250
Transmission Range (m)
Figure 9-41 Average Packet Loss Ratio for node density of 45 nodes/km 2 as a function of
transmission range
For AODV the maximum average packet loss ratio is around 78% and the minimum is higher
than 26%. For GPSR the maximum average packet loss ratio is higher than 94% and the
minimum is less than 60%.
145
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.1.3.6.2. Average End-to-end Delay
AODV
GPSR
Transmission Range (m)
100
150
200
250
Average End-to-end Delay (ms)
4542,6
1935,9
831,8
419,7
Confidence Interval (95%)
3988,4
666,74
496,42
134,91
Average End-to-end Delay (ms)
2,1401
3,6419
3,397
4,4596
Confidence Interval (95%)
0,03733
1,33797
0,99335
1,89169
Table 9-42 Average End-to-end Delay for node density of 45 nodes/km2 as a function of
transmission range
Average End-to-end Delay
Average End-to-end Delay (s)
10
1
0.1
AODV
GPSR
0.01
0.001
100
150
200
250
Transmission Range (m)
Figure 9-42 Average End-to-end Delay for node density of 45 nodes/km2 as a function of
transmission range
For AODV the trend is clearly decreasing and for GPSR it seems that has an soft increasing
trend.
146
SIMULATION RESULTS
9.2. Evaluation of Data Throughput over time
This section uses the results of the simulations for a transmission range of 250 meters to
evaluate the data throughput over time. We can see in the following graphs that the data
throughput remains constant in the course of the simulation. This is an essential feature of a
good routing protocol. Otherwise it would mean that the protocol is not working properly.
The graphics and tables with all data for each node density are shown below.
9.2.1.1.
AODV
GPSR
Node Density of 20 nodes/km2
Time (s)
200
400
600
800
1000
Average Packet Delivery Ratio
0,718463
0,73598
0,785863
0,70628
0,74542
Confidence Interval (95%)
0,095763
0,11246
0,123458
0,07453
0,070846
Average Packet Delivery Ratio
0,27457
0,23317
0,26274
0,28274
0,26274
Confidence Interval (95%)
0,120786
0,11073
0,12472
0,14786
0,113866
Table 9-43 Average Packet Delivery Ratio for node density of 20
nodes/km2
over time
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
200
400
600
800
1000
Time (s)
Figure 9-43 Average Packet Delivery Ratio for node density of 20 nodes/km 2 over time
We can see as throughput is constant over time with small random variations. The average
packet delivery ratio takes values close to the mean in all the time samples. This means that
the protocols are working properly because are establishing routes during the simulation.
147
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.2.1.2.
AODV
GPSR
Node Density of 25 nodes/km2
Time (s)
200
400
600
800
1000
Average Packet Delivery Ratio
0,68763
0,76368
0,749346
0,7846
0,76082
Confidence Interval (95%)
0,116738
0,08766
0,106789 0,111347
0,10992
Average Packet Delivery Ratio
0,30634
0,28893
0,269876
0,23356
0,27875
Confidence Interval (95%)
0,094876
0,10468
0,124678 0,142387
0,16283
Table 9-44 Average Packet Delivery Ratio for node density of 25 nodes/km2 over time
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
200
400
600
800
1000
Time (s)
Figure 9-44 Average Packet Delivery Ratio for node density of 25 nodes/km2 over time
The throughput over time has the same trend as the previous case but, as seen in previous
sections, like the node density is increased then the average packet delivery ratio also grows.
This is especially significant for GPSR.
148
SIMULATION RESULTS
9.2.1.3.
AODV
Node Density of 30 nodes/km2
Time (s)
200
400
600
800
1000
Average Packet Delivery Ratio
0,787863
0,69685
0,721236
0,75436
0,76105
Confidence Interval (95%)
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,094362 0,132658 0,123473 0,096543 0,109142
0,347653 0,304678 0,356789 0,324679
0,31794
0,098764 0,123469 0,106789 0,110684 0,118901
Table 9-45 Average Packet Delivery Ratio for node density of 30 nodes/km2 over time
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
200
400
600
800
1000
Time (s)
Figure 9-45 Average Packet Delivery Ratio for node density of 30 nodes/km2 over time
For node density of 30 nodes/km2 the behaviour is the same than for previous node densities.
149
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.2.1.4.
AODV
Node Density of 35 nodes/km2
Time (s)
200
400
Average Packet Delivery Ratio
0,678764
0,76469
Confidence Interval (95%)
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
600
800
0,736987 0,776497
1000
0,72842
0,084769 0,104359 0,094876 0,086748 0,066748
0,36756
0,31256
0,39041
0,37321
0,39779
0,115483 0,090146
0,12458
0,153482 0,190173
Table 9-46 Average Packet Delivery Ratio for node density of 35 nodes/km2 over time
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
200
400
600
800
1000
Time (s)
Figure 9-46 Average Packet Delivery Ratio for node density of 35 nodes/km 2 over time
It is verified that the behaviour is the expected.
150
SIMULATION RESULTS
9.2.1.5.
AODV
Node Density of 40 nodes/km2
Time (s)
200
Average Packet Delivery Ratio
0,77893
0,694879 0,798634
Confidence Interval (95%)
0,168753
0,12648
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
400
600
800
1000
0,75648
0,8249
0,086439 0,084679 0,067282
0,387645 0,416781 0,484873 0,429483
0,162439
0,12468
0,48283
0,164876 0,176492 0,180679
Table 9-47 Average Packet Delivery Ratio for node density of 40 nodes/km2 over time
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
200
400
600
800
1000
Time (s)
Figure 9-47 Average Packet Delivery Ratio for node density of 40 nodes/km 2 over time
The data throughput over time has the expected behaviour.
151
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.2.1.6.
AODV
Node Density of 45 nodes/km2
Time (s)
200
400
600
800
1000
Average Packet Delivery Ratio
0,744876
0,68546
0,738762
0,74528
0,73568
Confidence Interval (95%)
0,11467
0,10346
0,09543
0,08764
0,055
0,379463 0,416437
0,40214
0,413468
0,40242
0,11346
0,13465
0,164734
0,17478
Average Packet Delivery Ratio
GPSR
Confidence Interval (95%)
0,10346
Table 9-48 Average Packet Delivery Ratio for node density of 45 nodes/km2 over time
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
AODV
0.4
GPSR
0.3
0.2
0.1
0
200
400
600
800
1000
Time (s)
Figure 9-48 Average Packet Delivery Ratio for node density of 45 nodes/km 2 over time
In this case the trend is more constant than in previous cases. Also for node density of
nodes/km2 the average packet delivery ratio is less than for node density of 40 nodes/km 2. The
reason is the same as explained in previous sections. Higher transmission range implies more
nodes in the neighbour location table and this incurs a high volume of control overhead. As a
result many transmission errors occurs.
152
SIMULATION RESULTS
9.3. Evaluation of other propagation models
As mentioned above Two Ray Ground is not a realistic propagation model for VANETs
evaluation in an urban environment. This propagation model has not considered the
shadowing and fading effects. These effects are present in urban environments and can
seriously worsen the performance of the radio communications.
That is why in this section we present the evaluation of communication for two propagation
models more realistic, Rayleigh and Ricean, presented in chapter 4. Rayleigh model is more
pessimistic than Ricean model. The protocol chosen to show degradation of the
communication is AODV. The Transmission range used in the simulations is 250 meters. The
corresponding sensing range is 550 meters.
For evaluate the propagation models we make 5 different simulations for each node density.
153
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.3.1. Average Packet Delivery Ratio
The average packet delivery ratio for Rayleigh and Ricean model is shown in the following
table.
Rayleigh
Ricean
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Delivery Ratio
0,52421
0,4329
0,60035
0,55179
0,54058
0,47082
Confidence Interval (95%)
0,21212
0,1094
0,090442 0,119534 0,109148
0,2359
Average Packet Delivery Ratio
0,61802
0,59776
0,66008
0,6052
0,73542
0,70365
0,109286 0,23962
0,23384
0,128898
0,2192
0,09153
Confidence Interval (95%)
Table 9-49 Average Packet Delivery Ratio for Rayleigh and Ricean model as a function of node
density
The values of the previous table are represented below.
Average Packet Delivery Ratio
Average Packet Delivery Ratio
1
0.9
0.8
0.7
0.6
0.5
Rayleigh
0.4
Ricean
0.3
0.2
0.1
0
20
25
30
35
40
45
Node Density (nodes/km2)
Table 9-49 Average Packet Delivery Ratio for Rayleigh and Ricean model as a function of node
density
For Rayleigh model the average packet delivery ratio is not much worse than for Two Ray
Ground model. The average for each number of nodes is around 52% and for Two Ray Ground
model it was about 76%. Although is significant reduction the results are acceptably good
considering that Rayleigh is a pessimistic model.
For Ricean model it is possible to see that the average packet delivery ratio is not as bad as
Rayleigh model. The results are more similar to Two Ray Ground model. For Ricean model the
mean of average packet delivery ratio for each number of nodes is about 65%. Whereas for
Two Ray Ground model the mean of average packet delivery ratio is around 76%.
154
SIMULATION RESULTS
9.3.1. Average Packet Loss Ratio
The next table shows the average packet loss ratio for each node density.
Rayleigh
Ricean
Node Density (nodes/km2)
20
25
30
35
40
45
Average Packet Loss Ratio
0,47579
0,5671
0,39965
0,44821
0,45942
0,52918
Confidence Interval (95%)
0,21212
0,1094
0,090442 0,119534 0,109148
0,2359
Average PAcket Loss Ratio
0,38198
0,40224
0,33992
0,3948
0,26458
0,29635
Confidence Interval (95%)
0,109286 0,23962
0,23384
0,128898
0,2192
0,09153
Table 9-50 Average Packet Loss Ratio for Rayleigh and Ricean model as a function of node density
The following graph represents the values of the previous table.
Average Packet Loss Ratio
1
Average Packet Loss Ratio
0.9
0.8
0.7
0.6
0.5
Rayleigh
0.4
Ricean
0.3
0.2
0.1
0
20
25
30
Node Density
35
40
45
(nodes/km2)
Table 9-50 Average Packet Loss Ratio for Rayleigh and Ricean model as a function of node density
The average packet loss ratio is higher for Rayleigh model than for Ricean model because
Rayleigh assumes the reception of multiple signals with equal power and Ricean considers that
the power of the different received signals are increasingly lower. As a result the Ricean model
has a lower error rate.
155
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
9.3.2. Average End-to-end Delay
The next table shows the average end-to-end delay for Rayleigh propagation model.
Raileigh
Ricean
Node Density (nodes/km2)
20
25
30
35
40
45
Average End-to-end Delay (ms)
625,03
1002,7
976,04
1061,7
741,83
1064,7
Confidence Interval (95%)
143,8
412,82
661,9
365,16
371,12
627,26
Average End-to-end Delay (ms)
517,31
431,39
657,43
709,18
705,27
666,35
Confidence Interval (95%)
143,8
348,58
428,32
447,74
533,62
185,636
Table 9-51 Average End-to-end Delay for Rayleigh and Ricean model as a function of node density
The following figure shows a graph that represents the results.
Average End-to-end Delay
Average End-to-end Delay (s)
1.8
1.6
1.4
1.2
1
0.8
Raileigh
0.6
Ricean
0.4
0.2
0
20
25
30
35
40
45
Node Density (nodes/km2)
Table 9-51 Average End-to-end Delay for Rayleigh model as a function of node density
For Rayleigh model the average end-to-end delay also gets worse compared with Two Ray
Ground model. The average for each number of nodes is about 0.91 seconds for Rayleigh
model and around 0.53 seconds for Two Ray Ground model.
In terms of average end-to-end delay the values for Ricean model are also more similar to Two
Ray Ground model. For Ricean model the mean for each number of nodes is 0.62 seconds. For
Two Ray Ground model is around 0.53 seconds.
156
CONCLUSIONS AND FUTURE WORK
10. CONCLUSIONS AND FUTURE WORK
10.1. Conclusions
GPSR (Greedy Perimeter Stateless Routing) [90] is one of the best known position-based
protocols in the research literature about VANETs (Vehicular Ad-hoc Networks). It is argued
that geographic routing achieves better results than topology-based routing such as AODV (Adhoc On demand Distance Vector) [65] and DSR (Dynamic Source Routing) [45] in a highway
scenario because there are fewer obstacles compared to city conditions and is fairly suited to
network requirements. However, as we have seen in the previous chapter, when applied to
city scenarios for VANETs, GPSR suffers from several problems. Firstly, in city scenarios, greedy
forwarding is often restricted because direct communications between nodes may not exist
due to obstacles such as buildings and trees. Secondly, if apply first the planarized graph to
build the routing topology and then run greedy, the routing performance may degrade.
Thirdly, mobility can also induce routing loops. And finally, sometimes packets may get
forwarded to the wrong direction leading higher delays or even network partitions. This
drawbacks of GPSR in urban scenarios have been studied in some research works, such as [96].
Considering the analysis as a function of node density we can say that for transmission ranges
of 200 and 250 meters the behaviour of GPSR is similar to that of AODV. At traffic densities
higher than 40 nodes/km2 the packet delivery ratio decreases. This behaviour results from the
network connectivity in the VANET. At low traffic density of 20 nodes/km2, in many cases it
157
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
may not be possible to establish a communication path from source to destination due to the
lack of relaying nodes. At higher traffic densities, the connectivity in the network is significantly
better and thus more packets are delivered to their destination node. Moreover, in GPSR the
delivery packet ratio declines again because more and more vehicles have to exchange
location packets to maintain their neighbours’ locations table. This incurs a high volume of
control overhead. Hence, many transmission errors occurs as well as traffic congestion
resulting in lower delivery ratio and increase in the number of dropped packets.
AODV outperforms GPSR in terms of packet delivery ratio, especially at traffic densities higher
than 40 nodes/km2. In contrast, GPSR presents a lower end-to-end delay. This is very useful for
real time communications (like voice or video streaming). GPSR, as proactive protocol, has a
faster processing at intermediate nodes. When a packet arrives at node, it can immediately be
forwarded. In reactive protocols, a packet retransmission will be delayed by a timeout period
depending on the protocol policy in calculating this timeout values. Also, GPSR establishes a
timeout that when it is exceeded the packet is dropped. In this way is priorized the small endto-end delay over the packet delivery ratio.
Regarding the analysis as a function of node speed we can conclude that the effect of the node
speed in the selected speed range is quite negligible. This is probably caused because the
range chosen (30 to 50 km/h), although suitable for an urban environment, is small to notice
significant difference in for a general analysis.
Taking into account the evaluation as a function of transmission range we can say that for
AODV all the evaluated metrics improve as the transmission range grows. This is especially
significant when the transmission range changed from 150 to 200 meters. For GPSR the
average packet delivery ratio also improves, but not the average end-to-end delay that
remains constant.
As a conclusion, we can say that GPSR has better results in terms of end-to-end delay than
AODV and DSR. This makes GPSR much better than AODV and DSR for specific applications
(e.g. voice, video streaming). Instead, AODV and DSR are unsuitable for vehicular
environments because they have a very poor results in terms of end-to-end delay. But GPRS is
not performing better than AODV and DSR in terms of packet delivery ratio. As a result, we can
say that GPSR is not the definitive protocol for VANETs for urban environments and it is
necessary to continue working on new routing protocol with better performances.
10.2. Future works
As we said before AODV, DSR and even GPSR are not the best routing protocols for urban
scenarios. A proposal as a future work could be the evaluation of other newer existing
proposals routing protocols with better performances on VANETs. For example the routing
protocol named SIFT (Simple Forwarding over Trajectory) [96]. In SIFT, forwarding decision is
shifted to the receiver. Each node that receives the packet takes the decision whether to
forward it or not based only on its own position, the transmitter position and the packet
158
CONCLUSIONS AND FUTURE WORK
trajectory. This greatly reduces control overhead and energy consumption. Once received a
packet, each node sets a timer according to its position with respect to the packet trajectory
and the transmitter. If a copy of the packet, forwarded by another node, is received before the
timer expires, the timer is stopped and the packet is deleted from the forwarding queue.
Otherwise, the packet is passed to the Medium Access Control (MAC) layer for transmission
when the timer expires. Therefore, the node with the minimum timeout value will forward the
packet. It will be the node in the best position since it is far from the last node and close to the
packet trajectory. Packets include into the header the trajectory and the coordinates of the
last node that forwarded the packet. The original source identifier, a sequence number, and a
hop count are included as well. SIFT delivers data packets to their destination only if the
trajectory is not interrupted. This situation may occur in a low density network or due to issues
related to signal propagation.
Urban random street distribution of VanetMobisim was the mobility model used during the
simulations. A proposal could be using other mobility models as Manhattan and make
simulations in other environments such as rural or highway.
Two Ray Ground was the propagation model most used in the simulations. A proposal could be
use other propagation models more realistic as Ricean or Rayleigh for new performance
evaluations under more realistic scenarios.
Finally, the communication established in the simulations was only between one source and
one destination. A proposal could be to make simulations more realistic with more source and
destination nodes.
159
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
11. ANNEX: HOW TO DO THE SIMULATIONS
In this section an installation guide of different simulation tools is presented and a step by step
review of the simulation process is described in order to illustrate how to use every tool
properly.
11.1. How to install VMware Player
First download VMware player from [100]. You need to register in the web page. You should
only run the installation file to install the application.
11.2. How to install Ubuntu
You should dowload the software from [101]. Remember that the version used in this work is
Ubuntu 10.04 (32 bits). If you want to install Ubuntu in a free partition of your system Hard
Disk you only need to insert the Live CD and restart your computer.
If you want use VMware Player to install Ubuntu in a virtual machine you should follow the
next steps.
1)
2)
3)
4)
160
Run VMware Player
Select “Create a New Virtual Machine”
Mark the flag “Installer disk image file”
Click on Browse and select the Ubuntu image file.
ANNEX: HOW TO DO THE SIMULATIONS
5) Continue with the New Virtual Machine wizard steps and at last click on finish.
6) The installation of Ubuntu starts as Live CD method.
11.3. How to install VanetMobiSim-1.1
The first step is downloading the source code of VanetMobiSim-1.1 from [80] and expand it in
a base directory of your choice
unzip ~/Descargas/VanetMobiSim-1.1.zip -d ~/VanetMobiSim
The previous command unzips the source code of VanetMobiSim-1.1 downloaded to the
Downloads Folder to a directory called VanetMobiSim in our personal directory. The following
subdirectories and files will be created after extraction.
/ jar
build.xml
VanetMobiSim-src.jar
VanetMobiSim-samples.jar
mypackages.lst
READ_ME
In the next step you must download the source code of CanuMobiSim v1.3.4 from [15] and
expand it in the same directory.
unzip ~/Descargas/CanuMobiSim_1_3_4_src.zip -d ~/VanetMobiSim
You should get a subdirectoy named /src so that at this time, your current directory should
contains.
/ jar
/src
build.xml
VanetMobiSim-src.jar
VanetMobiSim-samples.jar
mypackages.lst
READ_ME
At this point, VanetMobiSim requires the presence of Sun JVM, a virtual machine capable of
executing Java bytecode, as well as Apache Ant, a tool whose mission is to build Java
applications. The following command will install the open-ource Java Development Kid (JDK)
v.6.
sudo apt-get install openjdk-6-source
For installing Apache Ant v1.7 the following command must be type.
sudo apt-get install ant1.7
The next step requires going to the VanetMobiSim directory and launch ant.
161
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
cd ~/VanetMobiSim
ant patch
Ant will patch the /src directory with VanetMobiSim source files. The message appeared in the
terminal after patching is shown in Fig. 6-1.
Fig. 11-1 Terminal message after executing ant patch
Eventyally you must type the following command in order to build the simulator and create
the javadocs.
ant all
The message appeared in the terminal after building is shown in Fig. 6-2. The binary .jar file of
VanetMobiSim will be place in the /jar subdirectory. Now VanetMobiSim is available to use.
Fig. 11-2 Terminal message after executing ant all
162
ANNEX: HOW TO DO THE SIMULATIONS
11.4. How to install NS2.27
Installation guide of NS-2.27 on Linux 32 bits (by David Marín Sánchez) [99]
This guide has been tested with NS-2.27 on Ubuntu 10.04 (32 bits)
Step 1) Dowload NS-2.27 from [93]
Step 2) Dowload ns227-gcc34.patch from [94]
Step 3) Install the necessary libraries:
sudo apt-get install build-essential
sudo apt-get install libX11-dev
sudo apt-get install xorg-dev
Step 4) Unpack tar.gz NS-2.27 file:
cd <ns-allinone-2.27.tar.gz_path>
tar -xvf ns-allinone-2.27.tar.gz
mv ns-allinone-2.27 /usr/src
cd /usr/src
Step 5) Apply ns227-gcc34.patch:
cd /usr/src
patch -p0 < <ns227-gcc34.patch_path>/ns227-gcc34.patch
Step 5) Install NS-2.27:
cd /usr/src/ns-allinone-2.27
./install
Step 6) Solve the errors that appear in the installation process (you should replace the lines
with a "-" for the lines with a "+" of the respective files) and repeat step 5:
Error 1:
checking system version (for dynamic loading)... ./configure: 1: Syntax error:
Unterminated quoted string
tcl8.3.2 configuration failed! Exiting ...
Patch file: ns-allinone-2.27/tcl8.4.5/unix/configure
-
system=MP-RAS-`awk '{print }' /etc/.relid'`
163
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
+
system=MP-RAS-`awk '{print }' /etc/.relid`
Error 2:
checking system version (for dynamic loading)... ./configure: 1: Syntax error:
Unterminated quoted string
tk8.3.2 configuration failed! Exiting ...
patch file: ns-allinone-2.27/tk8.4.5/unix/configure
-
system=MP-RAS-`awk '{print }' /etc/.relid'`
+
system=MP-RAS-`awk '{print }' /etc/.relid`
Error 3:
checking system version (for dynamic loading)... ./configure: 1: Syntax error:
Unterminated quoted string
otcl-1.8 configuration failed! Exiting ...
Patch file: ns-allinone-2.27/otcl-1.8/configure
-
system=MP-RAS-`awk '{print $3}' /etc/.relid'`
+
system=MP-RAS-`awk '{print $3}' /etc/.relid`
Error 4:
otcl.o: In function `OTclDispatch':
/usr/src/ns-allinone-2.27/otcl-1.8/otcl.c:493: undefined reference to
`__stack_chk_fail_local'
otcl.o: In function `Otcl_Init':
/usr/src/ns-allinone-2.27/otcl-1.8/otcl.c:2281: undefined reference to
`__stack_chk_fail_local'
ld: libotcl.so: hidden symbol `__stack_chk_fail_local' isn't defined
ld: final link failed: Nonrepresentable section on output
make: *** [libotcl.so] Error 1
otcl-1.8 make failed! Exiting ...
Patch file: ns-allinone-2.27/otcl-1.8/configure
Linux*)
SHLIB_CFLAGS="-fpic"
164
ANNEX: HOW TO DO THE SIMULATIONS
-
SHLIB_LD="ld -shared"
+
SHLIB_LD="gcc -shared"
SHLIB_SUFFIX=".so"
DL_LIBS="-ldl"
SHLD_FLAGS=""
Error 5:
27/include -I/usr/src/ns-allinone-2.27/include -o Tcl.o Tcl.cc
Tcl.cc: In member function ‘void Tcl::eval(char*)’:
Tcl.cc:180: warning: deprecated conversion from string constant to ‘char*’
Tcl.cc: In member function ‘int TclObject::traceVar(const char*, TclObject*)’:
Tcl.cc:419: warning: deprecated conversion from string constant to ‘char*’
Tcl.cc: In static member function ‘static int TclClass::create_shadow(void*, Tcl_Interp*, int,
const char**)’:
Tcl.cc:507: warning: deprecated conversion from string constant to ‘char*’
Tcl.cc:509: warning: deprecated conversion from string constant to ‘char*’
Tcl.cc: In static member function ‘static int TclClass::dispatch_instvar(void*, Tcl_Interp*,
int, const char**)’:
Tcl.cc:564: error: invalid conversion from ‘const char*’ to ‘char*’
Tcl.cc:569: warning: deprecated conversion from string constant to ‘char*’
Tcl.cc: In member function ‘virtual void TclClass::bind()’:
Tcl.cc:601: warning: deprecated conversion from string constant to ‘char*’
Tcl.cc:603: warning: deprecated conversion from string constant to ‘char*’
make: *** [Tcl.o] Error 1
tclcl-1.15 make failed! Exiting ...
Patch file: ns-allinone-2.27/tclcl-1.15/Tcl.cc
if (need_parse) {
-
char *p = strchr(localName, '(');
+
char* p = const_cast <char*> (strchr(localName, '('));
if (p)
165
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
*p = 0;
};
Error 6:
./sctp/sctp.h:632: error: extra qualification ‘SctpAgent::’ on member ‘DumpSendBuffer’
trace/trace.cc:185: warning: deprecated conversion from string constant to ‘char*’
trace/trace.cc:185: warning: deprecated conversion from string constant to ‘char*’
trace/trace.cc:185: warning: deprecated conversion from string constant to ‘char*’
trace/trace.cc:185: warning: deprecated conversion from string constant to ‘char*’
trace/trace.cc:185: warning: deprecated conversion from string constant to ‘char*’
make: *** [trace/trace.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/sctp/sctp.h
/* debugging functions
*/
- void SctpAgent::DumpSendBuffer();
+ void DumpSendBuffer();
/* sctp association state variable
*/
Error 7:
In file included from ./trace/cmu-trace.h:43,
from src_rtg/sragent.cc:53:
./mobile/god.h: At global scope:
./mobile/god.h:88: error: extra qualification ‘vector::’ on member ‘operator=’
./mobile/god.h:93: error: extra qualification ‘vector::’ on member ‘operator+=’
./mobile/god.h:98: error: extra qualification ‘vector::’ on member ‘operator==’
./mobile/god.h:101: error: extra qualification ‘vector::’ on member ‘operator!=’
make: *** [src_rtg/sragent.o] Error 1
166
ANNEX: HOW TO DO THE SIMULATIONS
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/mobile/god.h
return sqrt(X*X + Y*Y + Z*Z);
}
-
inline void vector::operator=(const vector a) {
+
inline void operator=(const vector a) {
X = a.X;
Y = a.Y;
Z = a.Z;
}
-
inline void vector::operator+=(const vector a) {
+
inline void operator+=(const vector a) {
X += a.X;
Y += a.Y;
Z += a.Z;
}
-
inline int vector::operator==(const vector a) {
+
inline int operator==(const vector a) {
return (X == a.X && Y == a.Y && Z == a.Z);
}
-
inline int vector::operator!=(const vector a) {
+
inline int operator!=(const vector a) {
return (X != a.X || Y != a.Y || Z != a.Z);
}
inline vector operator-(const vector a) {
Error 8:
queue/red.cc: In member function ‘virtual void REDQueue::trace(TracedVar*)’:
167
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
queue/red.cc:807: error: invalid conversion from ‘const char*’ to ‘char*’
queue/red.cc:808: error: invalid conversion from ‘const char*’ to ‘char*’
queue/red.cc:809: error: invalid conversion from ‘const char*’ to ‘char*’
queue/red.cc:810: error: invalid conversion from ‘const char*’ to ‘char*’
make: *** [queue/red.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/red.cc
REDQueue::trace(TracedVar* v)
{
-
char wrk[500], *p;
+
char wrk[500];
+
char* p;
-
if (((p = strstr(v->name(), "ave")) == NULL) &&
-
((p = strstr(v->name(), "prob")) == NULL) &&
-
((p = strstr(v->name(), "curq")) == NULL) &&
-
((p = strstr(v->name(), "cur_max_p"))==NULL) ) {
+
if (((p = const_cast <char*> (strstr(v->name(), "ave"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "prob"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "curq"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "cur_max_p")))==NULL) ) {
fprintf(stderr, "RED:unknown trace var %s\n",
v->name());
return;
}
Error 9:
queue/cbq.cc:112: error: ISO C++ forbids declaration of ‘CBQueue’ with no type
queue/cbq.cc:112: error: expected ‘;’ before ‘*’ token
queue/cbq.cc: In member function ‘virtual int CBQueue::insert_class(CBQClass*)’:
168
ANNEX: HOW TO DO THE SIMULATIONS
queue/cbq.cc:488: error: ‘class CBQClass’ has no member named ‘cbq_’
queue/cbq.cc: In constructor ‘CBQClass::CBQClass()’:
queue/cbq.cc:805: error: class ‘CBQClass’ does not have any field named ‘cbq_’
queue/cbq.cc: In member function ‘virtual void CBQClass::recv(Packet*, Handler*)’:
queue/cbq.cc:850: error: ‘cbq_’ was not declared in this scope
queue/cbq.cc:856: error: ‘cbq_’ was not declared in this scope
queue/cbq.cc: In member function ‘void CBQClass::update(Packet*, double)’:
queue/cbq.cc:873: error: ‘cbq_’ was not declared in this scope
queue/cbq.cc: In member function ‘int CBQClass::desc_with_demand()’:
queue/cbq.cc:928: error: ‘cbq_’ was not declared in this scope
queue/cbq.cc: In member function ‘void CBQClass::newallot(double)’:
queue/cbq.cc:975: error: ‘cbq_’ was not declared in this scope
queue/cbq.cc: In member function ‘virtual int CBQClass::command(int, const char*
const*)’:
queue/cbq.cc:1002: error: ‘cbq_’ was not declared in this scope
make: *** [queue/cbq.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/cbq.cc
+
class CBQueue;
class CBQClass : public Connector {
Error 10:
./tora/tora_neighbor.h: At global scope:
./tora/tora_neighbor.h:72: error: ISO C++ forbids declaration of ‘toraAgent’ with no type
./tora/tora_neighbor.h:72: error: expected ‘;’ before ‘*’ token
tora/tora.cc: In member function ‘void toraAgent::rt_resolve(Packet*)’:
tora/tora.cc:238: warning: deprecated conversion from string constant to ‘char*’
tora/tora.cc: In member function ‘void toraAgent::recvTORA(Packet*)’:
tora/tora.cc:343: warning: reading through null pointer (argument 3)
169
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
tora/tora.cc: In member function ‘void toraAgent::recvUPD(Packet*)’:
tora/tora.cc:462: warning: deprecated conversion from string constant to ‘char*’
tora/tora.cc: In member function ‘void toraAgent::recvCLR(Packet*)’:
tora/tora.cc:648: warning: deprecated conversion from string constant to ‘char*’
make: *** [tora/tora.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/tora/tora_neighbor.h
#define __tora_neighbor_h__
+class toraAgent;
enum LinkStatus {
Error 11:
dsr/dsragent.cc: In member function ‘void DSRAgent::dropSendBuff(SRPacket&)’:
dsr/dsragent.cc:206: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void
DSRAgent::stickPacketInSendBuffer(SRPacket&)’:
dsr/dsragent.cc:222: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘virtual int DSRAgent::command(int, const char*
const*)’:
dsr/dsragent.cc:431: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:435: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:439: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:443: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘virtual void DSRAgent::recv(Packet*, Handler*)’:
dsr/dsragent.cc:591: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::handlePktWithoutSR(SRPacket&,
bool)’:
dsr/dsragent.cc:666: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:675: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::handleFlowForwarding(SRPacket&,
int)’:
170
ANNEX: HOW TO DO THE SIMULATIONS
dsr/dsragent.cc:787: error: ‘XmitFlowFailureCallback’ was not declared in this scope
dsr/dsragent.cc:803: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:811: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::handleForwarding(SRPacket&)’:
dsr/dsragent.cc:916: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::handleRouteRequest(SRPacket&)’:
dsr/dsragent.cc:967: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1030: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1041: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1056: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘bool DSRAgent::replyFromRouteCache(SRPacket&)’:
dsr/dsragent.cc:1154: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1197: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void
DSRAgent::sendOutPacketWithRoute(SRPacket&, bool, Time)’:
dsr/dsragent.cc:1237: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1341: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1344: error: ‘XmitFailureCallback’ was not declared in this scope
dsr/dsragent.cc:1345: error: ‘XmitFlowFailureCallback’ was not declared in this scope
dsr/dsragent.cc:1362: error: ‘XmitFailureCallback’ was not declared in this scope
dsr/dsragent.cc: In member function ‘void DSRAgent::getRouteForPacket(SRPacket&,
bool)’:
dsr/dsragent.cc:1519: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::sendOutRtReq(SRPacket&, int)’:
dsr/dsragent.cc:1567: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void
DSRAgent::returnSrcRouteToRequestor(SRPacket&)’:
dsr/dsragent.cc:1617: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::acceptRouteReply(SRPacket&)’:
171
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
dsr/dsragent.cc:1674: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1699: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1736: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void
DSRAgent::processUnknownFlowError(SRPacket&, bool)’:
dsr/dsragent.cc:1777: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void
DSRAgent::processBrokenRouteError(SRPacket&)’:
dsr/dsragent.cc:1846: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:1876: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘virtual void DSRAgent::tap(const Packet*)’:
dsr/dsragent.cc:2012: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2021: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2038: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::sendRouteShortening(SRPacket&,
int, int)’:
dsr/dsragent.cc:2127: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2177: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::undeliverablePkt(Packet*, int)’:
dsr/dsragent.cc:2346: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2358: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2380: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2393: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::sendUnknownFlow(SRPacket&,
bool, u_int16_t)’:
dsr/dsragent.cc:2444: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2460: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2470: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc: In member function ‘void DSRAgent::xmitFailed(Packet*, const char*)’:
dsr/dsragent.cc:2576: warning: deprecated conversion from string constant to ‘char*’
172
ANNEX: HOW TO DO THE SIMULATIONS
dsr/dsragent.cc:2584: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2608: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2680: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2696: warning: deprecated conversion from string constant to ‘char*’
dsr/dsragent.cc:2715: warning: deprecated conversion from string constant to ‘char*’
make: *** [dsr/dsragent.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/dsr/dsragent.cc
+
void XmitFlowFailureCallback(Packet *pkt, void *data);
+
void XmitFailureCallback(Packet *pkt, void *data);
/*====================================================================
=======
SendBuf management and helpers
Error 12:
diffusion/diffusion.cc: At global scope:
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc:63: warning: deprecated conversion from string constant to ‘char*’
diffusion/diffusion.cc: In member function ‘void DiffusionAgent::MACprepare(Packet*,
nsaddr_t, int, bool)’:
diffusion/diffusion.cc:404: error: ‘XmitFailedCallback’ was not declared in this scope
make: *** [diffusion/diffusion.o] Error 1
173
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/diffusion/diffusion.cc
#include "routing_table.h"
+
void XmitFailedCallback(Packet *pkt, void *data);
char *MsgStr[]= {"", "INTEREST", "DATA", "DATA_READY", "DATA_REQUEST",
Error 13:
diffusion/omni_mcast.cc: In member function ‘void
OmniMcastAgent::MACprepare(Packet*, nsaddr_t, unsigned int, bool)’:
diffusion/omni_mcast.cc:367: error: ‘OmniMcastXmitFailedCallback’ was not declared in
this scope
make: *** [diffusion/omni_mcast.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/diffusion/omni_mcast.cc
#include "god.h"
+
void OmniMcastXmitFailedCallback(Packet *pkt, void *data);
static class OmniMcastClass : public TclClass {
Error 14:
queue/rio.cc: In member function ‘virtual void RIOQueue::trace(TracedVar*)’:
queue/rio.cc:556: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rio.cc:557: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rio.cc:558: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rio.cc:559: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rio.cc:560: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rio.cc:561: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rio.cc:562: error: invalid conversion from ‘const char*’ to ‘char*’
make: *** [queue/rio.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/rio.cc
RIOQueue::trace(TracedVar* v)
174
ANNEX: HOW TO DO THE SIMULATIONS
{
-
char wrk[500], *p;
+
char wrk[500];
+
char* p;
-
if (((p = strstr(v->name(), "ave")) == NULL) &&
-
((p = strstr(v->name(), "in_ave")) == NULL) &&
-
((p = strstr(v->name(), "out_ave")) == NULL) &&
-
((p = strstr(v->name(), "prob")) == NULL) &&
-
((p = strstr(v->name(), "in_prob")) == NULL) &&
-
((p = strstr(v->name(), "out_prob")) == NULL) &&
-
((p = strstr(v->name(), "curq")) == NULL)) {
+
if (((p = const_cast <char*> (strstr(v->name(), "ave"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "in_ave"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "out_ave"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "prob"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "in_prob"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "out_prob"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "curq"))) == NULL)) {
fprintf(stderr, "RIO:unknown trace var %s\n",
v->name());
return;
}
Error 15:
tcp/tcp-sack-rh.cc: At global scope:
tcp/tcp-sack-rh.cc:68: error: extra qualification ‘SackRHTcpAgent::’ on member ‘newack’
make: *** [tcp/tcp-sack-rh.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/tcp/tcp-sack-rh.cc
175
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
-
virtual void SackRHTcpAgent::newack(Packet* pkt);
+
virtual void newack(Packet* pkt);
Error 16:
queue/pi.cc: In member function ‘virtual void PIQueue::trace(TracedVar*)’:
queue/pi.cc:316: error: invalid conversion from ‘const char*’ to ‘char*’
queue/pi.cc:317: error: invalid conversion from ‘const char*’ to ‘char*’
make: *** [queue/pi.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/pi.cc
void PIQueue::trace(TracedVar* v)
{
-
char wrk[500], *p;
+
char wrk[500];
+
char* p;
-
if (((p = strstr(v->name(), "prob")) == NULL) &&
-
((p = strstr(v->name(), "curq")) == NULL)) {
+
if (((p = const_cast <char*> (strstr(v->name(), "prob"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "curq"))) == NULL)) {
fprintf(stderr, "PI:unknown trace var %s\n", v->name());
return;
}
Error 17:
queue/vq.cc: In member function ‘virtual void Vq::trace(TracedVar*)’:
queue/vq.cc:333: error: invalid conversion from ‘const char*’ to ‘char*’
make: *** [queue/vq.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/vq.cc
void Vq::trace(TracedVar* v)
176
ANNEX: HOW TO DO THE SIMULATIONS
{
-
char wrk[500], *p;
+
char wrk[500];
+
char* p;
-
if ((p = strstr(v->name(), "curq")) == NULL) {
+
if ((p = const_cast <char*> (strstr(v->name(), "curq"))) == NULL) {
fprintf(stderr, "Vq:unknown trace var %s\n", v->name());
return;
}
Error 18:
queue/rem.cc: In member function ‘virtual void REMQueue::trace(TracedVar*)’:
queue/rem.cc:336: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rem.cc:337: error: invalid conversion from ‘const char*’ to ‘char*’
queue/rem.cc:338: error: invalid conversion from ‘const char*’ to ‘char*’
make: *** [queue/rem.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/rem.cc
REMQueue::trace(TracedVar* v)
{
-
char wrk[500], *p;
+
char wrk[500];
+
char* p;
-
if (((p = strstr(v->name(), "ave")) == NULL) &&
-
((p = strstr(v->name(), "prob")) == NULL) &&
-
((p = strstr(v->name(), "curq")) == NULL)) {
+
if (((p = const_cast <char*> (strstr(v->name(), "ave"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "prob"))) == NULL) &&
+
((p = const_cast <char*> (strstr(v->name(), "curq"))) == NULL)) {
177
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
fprintf(stderr, "REM:unknown trace var %s\n",
v->name());
return;
}
Error 19:
queue/gk.cc: In member function ‘virtual void GK::trace(TracedVar*)’:
queue/gk.cc:207: error: invalid conversion from ‘const char*’ to ‘char*’
make: *** [queue/gk.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/queue/gk.cc
void GK::trace(TracedVar* v)
{
-
char wrk[500], *p;
+
char wrk[500];
+
char* p;
-
if ((p = strstr(v->name(), "curq")) == NULL) {
+
if ((p = const_cast <char*> (strstr(v->name(), "curq"))) == NULL) {
fprintf(stderr, "Vq:unknown trace var %s\n", v->name());
return;
}
Error 20:
pgm/pgm-agent.cc: At global scope:
pgm/pgm-agent.cc:278: error: extra qualification ‘PgmAgent::’ on member ‘trace_event’
pgm/pgm-agent.cc: In member function ‘void PgmAgent::handle_rdata(Packet*)’:
pgm/pgm-agent.cc:578: warning: deprecated conversion from string constant to ‘char*’
pgm/pgm-agent.cc: In member function ‘void PgmAgent::handle_nak(Packet*)’:
pgm/pgm-agent.cc:727: warning: deprecated conversion from string constant to ‘char*’
pgm/pgm-agent.cc: In member function ‘void PgmAgent::handle_ncf(Packet*)’:
178
ANNEX: HOW TO DO THE SIMULATIONS
pgm/pgm-agent.cc:824: warning: deprecated conversion from string constant to ‘char*’
make: *** [pgm/pgm-agent.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/pgm/pgm-agent.cc
-
void PgmAgent::trace_event(char *evType, double evTime);
+
void trace_event(char *evType, double evTime);
Error 21:
pgm/pgm-sender.cc: At global scope:
pgm/pgm-sender.cc:160: error: extra qualification ‘PgmSender::’ on member ‘trace_event’
pgm/pgm-sender.cc: In member function ‘virtual void PgmSender::handle_nak(Packet*)’:
pgm/pgm-sender.cc:472: warning: deprecated conversion from string constant to ‘char*’
pgm/pgm-sender.cc: In member function ‘virtual void
PgmSender::send_rdata(RdataItem*)’:
pgm/pgm-sender.cc:619: warning: deprecated conversion from string constant to ‘char*’
make: *** [pgm/pgm-sender.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/pgm/pgm-sender.cc
-
void PgmSender::trace_event(char *evType, nsaddr_t daddr, double evTime);
+
void trace_event(char *evType, nsaddr_t daddr, double evTime);
Error 22:
pgm/pgm-receiver.cc: At global scope:
pgm/pgm-receiver.cc:157: error: extra qualification ‘PgmReceiver::’ on member
‘trace_event’
pgm/pgm-receiver.cc: In member function ‘void PgmReceiver::generate_Nak(int)’:
pgm/pgm-receiver.cc:589: warning: deprecated conversion from string constant to ‘char*’
make: *** [pgm/pgm-receiver.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/pgm/pgm-receiver.cc
-
void PgmReceiver::trace_event(char *evType, double evTime);
179
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
+
void trace_event(char *evType, double evTime);
Error 23:
./diffusion3/filter_core/filter_core.hh: At global scope:
./diffusion3/filter_core/filter_core.hh:111: error: expected ‘)’ before ‘*’ token
make: *** [diffusion3/ns/diffagent.o] Error 1
Ns make failed!
Patch file: ns-allinone-2.27/ns-2.27/diffusion3/filter_core/filter_core.hh
class NeighborEntry;
+
class DiffRoutingAgent;
typedef list<NeighborEntry *> NeighborList;
Error 24:
node.h:226: error: extra qualification ‘Node::’ on member ‘getTclScriptLabel’
node.h: In member function ‘virtual char* BoxNode::style()’:
node.h:280: warning: deprecated conversion from string constant to ‘char*’
node.h: In member function ‘virtual char* CircleNode::style()’:
node.h:291: warning: deprecated conversion from string constant to ‘char*’
node.h: In member function ‘virtual char* HexagonNode::style()’:
node.h:302: warning: deprecated conversion from string constant to ‘char*’
node.h: In member function ‘virtual char* VirtualNode::style()’:
node.h:318: warning: deprecated conversion from string constant to ‘char*’
make: *** [netview.o] Error 1
Patch file: ns-allinone-2.27/nam-1.10/node.h
-
char * Node::getTclScriptLabel();
+
char * getTclScriptLabel();
Error 25:
netgraph.h:71: error: extra qualification ‘NetGraph::’ on member ‘render’
make: *** [graphview.o] Error 1
Patch file: ns-allinone-2.27/nam-1.10/netgraph.h
180
ANNEX: HOW TO DO THE SIMULATIONS
-
virtual void NetGraph::render(GraphView* view);
+
virtual void render(GraphView* view);
Error 26:
In file included from setdest.cc:57:
setdest.h:26: error: extra qualification ‘vector::’ on member ‘operator=’
setdest.h:31: error: extra qualification ‘vector::’ on member ‘operator+=’
setdest.h:36: error: extra qualification ‘vector::’ on member ‘operator==’
setdest.h:39: error: extra qualification ‘vector::’ on member ‘operator!=’
make[1]: *** [setdest.o] Error 1
Patch file: ns-allinone-2.27/ns-2.27/indep-utils/cmu-scen-gen/setdest/setdest.h
class vector {
public:
vector(double x = 0.0, double y = 0.0, double z = 0.0) {
X = x; Y = y; Z = z;
}
double length() {
return sqrt(X*X + Y*Y + Z*Z);
}
-
inline void vector::operator=(const vector a) {
+
inline void operator=(const vector a) {
X = a.X;
Y = a.Y;
Z = a.Z;
}
-
inline void vector::operator+=(const vector a) {
+
inline void operator+=(const vector a) {
X += a.X;
Y += a.Y;
181
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Z += a.Z;
}
-
inline int vector::operator==(const vector a) {
+
inline int operator==(const vector a) {
return (X == a.X && Y == a.Y && Z == a.Z);
}
-
inline int vector::operator!=(const vector a) {
+
inline int operator!=(const vector a) {
return (X != a.X || Y != a.Y || Z != a.Z);
}
inline vector operator-(const vector a) {
return vector(X-a.X, Y-a.Y, Z-a.Z);
}
Step 7) Modify bashrc file (gedit ~/.bashrc) adding the following lines:
# LD_LIBRARY_PATH
OTCL_LIB=/usr/src/ns-allinone-2.27/otcl-1.8
NS2_LIB=/usr/src/ns-allinone-2.27/lib
#X11_LIB=/usr/X11R6/lib
USR_LOCAL_LIB=/usr/local/lib
#AEJ_LIB=/home/ahmad/arcgis/ArcExplorer/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB:
#$USR_LOCAL:$AEJ_LIB
# TCL_LIBRARY
TCL_LIB=/usr/src/ns-allinone-2.27/tcl8.4.5/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB
# PATH
XGRAPH=/usr/src/ns-allinone-2.27/bin:/usr/src/ns-allinone-
182
ANNEX: HOW TO DO THE SIMULATIONS
2.27/tcl8.4.5/unix:/usr/src/ns-allinone-2.27/tk8.4.5/unix
NS=/usr/src/ns-allinone-2.27/ns-2.27/
NAM=/usr/src/ns-allinone-2.27/nam-1.10/
export PATH=$PATH
PATH=$PATH:$XGRAPH:$NS:$NAM
Step 8) Apply changes of bashrc file:
source ~/.bashrc
Step 9) Validate the installation (this process may take several minutes)
cd /usr/src/ns-allinone-2.27/ns-2.27
./validate
11.5. How to install GPSR on NS2-27
Step 1) Dowload GPSR code from [95]
Step 2) Create a directory called "gpsr" in ns2/ns-2.27/ and put all the below files in it.
gpsr_packet.h: definition of packets of different type used by this implementation
gpsr_neighbor.h: definition of the neighbour list of each node used by this gpsr
implementation
gpsr_neighbor.cc: the implementation of the neighbour list class
gpsr.h: the definition of functions of GPSR routing agent
gpsr.cc: the implementation of the GPSR routing agent
gpsr_sinklist.h: definition used for scenarios with multiple sinks
gpsr_sinklist.cc: implementation of gpsr_sinklist.cc
gpsr.tcl: the node and agent creation functions used by simulation configuration in wirelessgpsr.tcl
gpsr_test: the files used for the test (scenario, traffic, movement)
Step 3) The below files should replace the original files of ns2
packet.h: file in ns2/common (Or you just need to add one more packet type as "PT_GPSR")
183
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
cmu-trace.cc: file in ns2/trace (Or you just need to tell the trace "PT_GPSR" is recognized)
priqueue.cc: file in ns2/queue (Or you just need to tell the queue "PT_GPSR" should be
enqueued through enquenHighpriority the same as PT_DSR, PT_DSDV, etc.)
ns-packet.tcl: file in ns2/tcl/lib (be careful for this file, you just need to add one more entry in
the foreach prot {} function : GPSR. You don't really need this file to be replaced if you use
another version of ns2 than ns2.26)
Step 4) In the Makefile, you need to replace line “$(OBJ_STL)” in ns2/ns-2.2x/Makefile.in as:
$(OBJ_STL) \
gpsr/gpsr_neighbor.o \
gpsr/gpsr_sinklist.o \
gpsr/gpsr.o
11.6. How to install AWK
For installing AWK, you must type the following command
sudo apt-get install gawk
And now awk is available to use
11.7. How to install GNU Octave
Installing GNU Octave on Ubuntu it is so easy. You only should search GNU Octave on Ubuntu
Software Center and select install.
184
ANNEX: HOW TO DO THE SIMULATIONS
11.8. Simulation Process
Directory (1) for simulations in function of node density
Directory (1) for simulations in function of node speed
Script (2) “clean” for simulations in function of node density
rm result_60.txt 2> /dev/null
rm result_75.txt 2> /dev/null
185
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
rm result_90.txt 2> /dev/null
rm result_105.txt 2> /dev/null
rm result_120.txt 2> /dev/null
rm result_135.txt 2> /dev/null
cd *_60
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_75
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_90
rm estimates_DT.txt 2> /dev/null
186
ANNEX: HOW TO DO THE SIMULATIONS
rm estimates_ETET.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_105
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_120
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
187
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_135
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
188
ANNEX: HOW TO DO THE SIMULATIONS
Script (2) “clean” for simulations in function of node speed
rm result_25~30.txt 2> /dev/null
rm result_30~35.txt 2> /dev/null
rm result_35~40.txt 2> /dev/null
rm result_40~45.txt 2> /dev/null
rm result_45~50.txt 2> /dev/null
rm result_50~55.txt 2> /dev/null
cd *_25~30
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm estimates_NH.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_30~35
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm estimates_NH.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
189
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_35~40
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm estimates_NH.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_40~45
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm estimates_NH.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_45~50
190
ANNEX: HOW TO DO THE SIMULATIONS
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm estimates_NH.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
cd *_50~55
rm estimates_DT.txt 2> /dev/null
rm estimates_ETET.txt 2> /dev/null
rm estimates_NH.txt 2> /dev/null
rm output.txt 2> /dev/null
rm result.txt 2> /dev/null
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
cd ..
191
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Script (3) “start” for simulations in function of node density
#1 -> number of simulations for N = 60 nodes
#2 -> number of simulations for N = 75 nodes
#3 -> number of simulations for N = 90 nodes
#4 -> number of simulations for N = 105 nodes
#5 -> number of simulations for N = 120 nodes
#6 -> number of simulations for N = 135 nodes
#7 -> sleep time between simulations in seconds
./exe 5 5 5 5 5 5 0
In this example we are going to run 5 simulations for each number of nodes without sleep time
between simulations.
Script (3) “start” for simulations in function of node speed
#1 -> number of simulations for V = 25~30 km/h
#2 -> number of simulations for V = 30~35 km/h
#3 -> number of simulations for V = 35~40 km/h
#4 -> number of simulations for V = 40~45 km/h
#5 -> number of simulations for V = 45~50 km/h
#6 -> number of simulations for V = 50~55 km/h
#7 -> sleep time between simulations in seconds
./exe 5 5 5 5 5 5 30
In this example we are going to run 5 simulations for each range of node speed with 30
seconds of sleep time between simulations.
Script (4) and (7) “exe”
time ./*.sh $1 $2 $3 $4 $5 $6 $7
192
ANNEX: HOW TO DO THE SIMULATIONS
Script (5) “remotesimulation.sh” for simulations in function of node density
rm result_60.txt 2> /dev/null
rm result_75.txt 2> /dev/null
rm result_90.txt 2> /dev/null
rm result_105.txt 2> /dev/null
rm result_120.txt 2> /dev/null
rm result_135.txt 2> /dev/null
echo "Simulation 60 nodes"
cd *_60
./exe $1 $7
cp result.txt ../result_60.txt
cd ..
echo "Simulation 90 nodes"
cd *_90
./exe $3 $7
cp result.txt ../result_90.txt
cd ..
echo "Simulation 120 nodes"
cd *_120
./exe $5 $7
cp result.txt ../result_120.txt
cd ..
echo "Simulation 135 nodes"
cd *_135
./exe $6 $7
cp result.txt ../result_135.txt
cd ..
echo "Simulation 105 nodes"
193
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
cd *_105
./exe $4 $7
cp result.txt ../result_105.txt
cd ..
echo "Simulation 75 nodes"
cd *_75
./exe $2 $7
cp result.txt ../result_75.txt
cd ..
echo "Results"
echo
"=================================================================="
echo "Simulation 60 nodes"
cat result_60.txt
echo
"=================================================================="
echo "Simulation 75 nodes"
cat result_75.txt
echo
"=================================================================="
echo "Simulation 90 nodes"
cat result_90.txt
echo
"=================================================================="
echo "Simulation 105 nodes"
cat result_105.txt
echo
"=================================================================="
echo "Simulation 120 nodes"
cat result_120.txt
194
ANNEX: HOW TO DO THE SIMULATIONS
echo
"=================================================================="
echo "Simulation 135 nodes"
cat result_135.txt
echo
"=================================================================="
195
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Script (5) “remotesimulation.sh” for simulations in function of node speed
rm result_25~30.txt 2> /devl/null
rm result_30~35.txt 2> /devl/null
rm result_35~40.txt 2> /devl/null
rm result_40~45.txt 2> /devl/null
rm result_45~50.txt 2> /devl/null
rm result_50~55.txt 2> /devl/null
echo "Simulation 25~30 km/h"
cd *_25~30
./exe $1 $7
cp result.txt ../result_25~30.txt
cd ..
echo "Simulation 30~35 km/h"
cd *_30~35
./exe $2 $7
cp result.txt ../result_30~35.txt
cd ..
echo "Simulation 35~40 km/h"
cd *_35~40
./exe $3 $7
cp result.txt ../result_35~40.txt
cd ..
echo "Simulation 40~45 km/h"
cd *_40~45
./exe $4 $7
cp result.txt ../result_40~45.txt
cd ..
echo "Simulation 45~50 km/h"
196
ANNEX: HOW TO DO THE SIMULATIONS
cd *_45~50
./exe $5 $7
cp result.txt ../result_45~50.txt
cd ..
echo "Simulation 50~55 km/h"
cd *_50~55
./exe $6 $7
cp result.txt ../result_50~55.txt
cd ..
echo "Resultados Globales"
echo
"=================================================================="
echo "Simulation 25~30 km/h"
cat result_25~30.txt
echo
"=================================================================="
echo "Simulation 30~35 km/h"
cat result_30~35.txt
echo
"=================================================================="
echo "Simulation 35~40 km/h"
cat result_35~40.txt
echo
"=================================================================="
echo "Simulation 40~45 km/h"
cat result_40~45.txt
echo
"=================================================================="
echo "Simulation 45~50 km/h"
cat result_45~50.txt
197
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
echo
"=================================================================="
echo "Simulation 50~55 km/h"
cat result_50~55.txt
echo
"=================================================================="
Direcotry (6)
198
ANNEX: HOW TO DO THE SIMULATIONS
Script (8) “simulation.sh”
VANET="/usr/src/VanetMobiSim"
START=`date`
rm result.txt 2> /dev/null
n=$1
i=1
while [ $i -le $n ]
do
echo "Running Vanet Mobisim ($i/$n)..."
java -jar $VANET/jar/VanetMobiSim.jar scenario.xml
echo "Running NS2 ($i/$n)..."
ns simulation.tcl
echo "Running awk filter..."
awk -f filter.awk trace.tr
rm scenario.ns_movements 2> /dev/null
rm trace.tr 2> /dev/null
rm sinklist.tr 2> /dev/null
rm nam.out.tr 2> /dev/null
rm gpsrnb_trace.tr 2> /dev/null
echo "Simulation sleeping..."
sleep $2
i=`expr $i + 1`
done
cat output.txt | grep "Data throughput" | awk '{ print $3 }' >> estimates_DT.txt
cat output.txt | grep "end-to-end time" | awk '{ print $5 }' >> estimates_ETET.txt
echo "Results obtained"
octave process.m | grep "=" >> result.txt
rm estimates_DT.txt 2> /dev/null
199
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
rm estimates_ETET.txt 2> /dev/null
END=`date`
echo "Inicio: $START"
echo "Final: $END"
200
ANNEX: HOW TO DO THE SIMULATIONS
Configuration file (9) “scenario.xml”
<?xml version="1.0"?>
<!-- Cars in a City Center using the SpaceGraph Traffic Light. -->
<universe>
<dimx>3000.0</dimx>
<dimy>1000.0</dimy>
<!-- <seed>18</seed>-->
<extension class="de.uni_stuttgart.informatik.canu.mobisim.extensions.NSOutput"
output="scenario.ns_movements"/>
<extension class="de.uni_stuttgart.informatik.canu.mobisim.simulations.TimeSimulation"
param="1000.0"/>
<extension name="NewSpatialModel"
class="de.uni_stuttgart.informatik.canu.spatialmodel.core.SpatialModel"
traffic_light="NewTrafficLight" min_x="0" max_x="3000" min_y="0" max_y="1000">
<max_traffic_lights>6</max_traffic_lights>
<reflect_directions>true</reflect_directions>
<number_lane full="false" max="4" dir="true">2</number_lane>
</extension>
<extension name="NewTrafficLight"
class="eurecom.spatialmodel.extensions.TrafficLight" spatial_model="NewSpatialModel"
step="10000"/>
<extension class="eurecom.spacegraph.SpaceGraph" spatial_model="NewSpatialModel"
traffic_light ="NewTrafficLight" cluster="true">
<clusters density="0.000004">
<cluster id="downtown">
<density>0.0002</density>
<ratio>0.1</ratio>
</cluster>
<cluster id="residential">
<density>0.00005</density>
<ratio>0.4</ratio>
</cluster>
<cluster id="suburban">
<density>0.00001</density>
<ratio>0.5</ratio>
</cluster>
</clusters>
</extension>
<extension name="PosGen"
class="de.uni_stuttgart.informatik.canu.tripmodel.generators.RandomInitialPositionGener
ator" spatial_model="NewSpatialModel"/>
<extension name="TripGen"
class="de.uni_stuttgart.informatik.canu.tripmodel.generators.RandomTripGenerator"
spatial_model="NewSpatialModel">
<reflect_directions>true</reflect_directions>
<minstay>5.0</minstay> <maxstay>30.0</maxstay>
201
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
</extension>
<nodegroup n="60">
<extension class="polito.uomm.IDM_IM" spatial_model="NewSpatialModel"
initposgenerator="PosGen" tripgenerator="TripGen">
<minspeed>8.33</minspeed>
<maxspeed>13.89</maxspeed>
<step>0.1</step>
<b>0.5</b>
</extension>
</nodegroup>
<extension class="de.uni_stuttgart.informatik.canu.mobisimadd.extensions.GUI"
spatial_model="NewSpatialModel">
<width>640</width>
<height>480</height>
<step>1</step>
</extension>
<!-<extension
class="de.uni_stuttgart.informatik.canu.spatialmodel.extensions.DumpSpatialModel"
spatial_model="NewSpatialModel" output="dumped_graph.fig"/>
-->
</universe>
202
ANNEX: HOW TO DO THE SIMULATIONS
Configuration file (11) “cbr.tcl” for simulations with AODV routing protocol
set null_(1) [new Agent/Null]
$ns_ attach-agent $node_(1) $null_(1)
set udp_(1) [new Agent/UDP]
$ns_ attach-agent $node_(0) $udp_(1)
set cbr_(1) [new Application/Traffic/CBR]
$cbr_(1) set packetSize_ 32
$cbr_(1) set interval_ 2.0
$cbr_(1) set random_ 1
# $cbr_(1) set maxpkts_ 100
$cbr_(1) attach-agent $udp_(1)
$ns_ connect $udp_(1) $null_(1)
$ns_ at 0.0 "$cbr_(1) start"
$ns_ at 999.0 "$cbr_(1) stop"
203
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Configuration file (11) “cbr.tcl” for simulations with GPSR routing protocol
for {set i 0} {$i < $opt(nn)} {incr i} {
$ns_ at 0.00002 "$ragent_($i) turnon"
$ns_ at 0.02 "$ragent_($i) neighborlist"
# $ns_ at 30.0 "$ragent_($i) turnoff"
}
$ns_ at 11.0 "$ragent_(0) startSink 10.0"
$ns_ at 11.5 "$ragent_(1) startSink 10.0"
# GPSR routing agent dumps
$ns_ at 25.0 "$ragent_(2) sinklist"
set null_(1) [new Agent/Null]
$ns_ attach-agent $node_(1) $null_(1)
set udp_(1) [new Agent/UDP]
$ns_ attach-agent $node_(0) $udp_(1)
set cbr_(1) [new Application/Traffic/CBR]
$cbr_(1) set packetSize_ 32
$cbr_(1) set interval_ 2.0
$cbr_(1) set random_ 1
# $cbr_(1) set maxpkts_ 100
$cbr_(1) attach-agent $udp_(1)
$ns_ connect $udp_(1) $null_(1)
$ns_ at 0.0 "$cbr_(1) start"
$ns_ at 999.0 "$cbr_(1) stop"
204
ANNEX: HOW TO DO THE SIMULATIONS
Configuration file (12) “simulation.tcl” for simulations with AODV routing protocol
set val(chan)
Channel/WirelessChannel
#set val(prop)
Propagation/TwoRayGround
set val(netif)
Phy/WirelessPhy
set val(mac)
Mac/802_11
set val(ifq)
set val(ll)
set val(ant)
Queue/DropTail/PriQueue
LL
Antenna/OmniAntenna
set val(x)
3001 ;# X dimension of the topography
set val(y)
1001 ;# Y dimension of the topography
set val(ifqlen)
50
set val(seed)
0.0
;# max packet in ifq
set val(adhocRouting) AODV
set val(nn)
60
;# how many nodes are simulated
set val(cp)
"cbr.tcl"
set val(sc)
"scenario.ns_movements"
set val(stop)
1000
set val(prop)
Propagation/Ricean
set val(RiceanK)
;# simulation time
0
set val(RiceanMaxVel) 13.89
;# Rayleigh and Ricean
;# Ricean K factor
;# Ricean Propagation MaxVelocity Parameter
# Ricean Propagation: Maximum ID of nodes (Total number of nodes) used to
# compute pairwise table offsets.
set val(RiceMaxNodeID) [expr {$val(nn)-1}]
set val(RiceDataFile) rice_table.txt
;
;# Ricean Propagation Data File
205
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
# Main Program
# Initialize Global Variables
LL set mindelay_
50us
LL set delay_
25us
LL set bandwidth_
0
Agent/Null set sport_
0
Agent/Null set dport_
0
Agent/CBR set sport_
0
Agent/CBR set dport_
0
Agent/TCPSink set sport_
0
Agent/TCPSink set dport_
0
Agent/TCP set sport_
0
Agent/TCP set dport_
0
Agent/TCP set packetSize_
1460
;# not used
Queue/DropTail/PriQueue set Prefer_Routing_Protocols 1
# unity gain, omni-directional antennas
# set up the antennas to be centered in the node and 1.5 meters above it
Antenna/OmniAntenna set X_ 0
Antenna/OmniAntenna set Y_ 0
Antenna/OmniAntenna set Z_ 1.5
Antenna/OmniAntenna set Gt_ 1.0
Antenna/OmniAntenna set Gr_ 1.0
# Initialize the SharedMedia interface with parameters to make
# it work like the 914MHz Lucent WaveLAN DSSS radio interface
Phy/WirelessPhy set CPThresh_ 10.0
Phy/WirelessPhy set CSThresh_ 1.559e-11
Phy/WirelessPhy set RXThresh_ 3.652e-10
206
ANNEX: HOW TO DO THE SIMULATIONS
Phy/WirelessPhy set Rb_ 2*1e6
Phy/WirelessPhy set freq_ 914e+6
Phy/WirelessPhy set L_ 1.0
# The transimssion radio range
#Phy/WirelessPhy set Pt_ 6.9872e-4 ;# ?m
#Phy/WirelessPhy set Pt_ 8.5872e-4 ;# 40m
#Phy/WirelessPhy set Pt_ 1.33826e-3 ;# 50m
#Phy/WirelessPhy set Pt_ 7.214e-3
;# 100m
Phy/WirelessPhy set Pt_ 0.03652
;# 150m
#Phy/WirelessPhy set Pt_ 0.1154
;# 200m
#Phy/WirelessPhy set Pt_ 0.2818
;# 250m
# create simulator instance
set ns_
[new Simulator]
# setup topography object
set topo
[new Topography]
# create trace object for ns and nam
set tracefd
[open trace.tr w]
set namtrace [open nam.out.tr w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
# define topology
$topo load_flatgrid $val(x) $val(y)
# Create God
set god_ [create-god $val(nn)]
# define how node should be created
#global node setting
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
207
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-coverage val(coverage) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF
# Set propagation settings
if { $val(prop) == "Propagation/Ricean"} {
set prop_inst [$ns_ set propInstance_]
#$prop_inst MaxVelocity 2.5;
#$prop_inst RiceanK
6;
#$prop_inst LoadRiceFile "rice_table.txt";
$prop_inst MaxVelocity $val(RiceanMaxVel);
$prop_inst RiceanK
$val(RiceanK);
$prop_inst LoadRiceFile $val(RiceDataFile);
$prop_inst RiceMaxNodeID $val(RiceMaxNodeID);
}
# Create the specified number of nodes [$val(nn)] and "attach" them
# to the channel.
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0
208
;# disable random motion
ANNEX: HOW TO DO THE SIMULATIONS
}
# Define node movement model
puts "Loading connection pattern..."
source $val(cp)
# Define traffic model
puts "Loading scenario file..."
source $val(sc)
# Define node initial position in nam
for {set i 0} {$i < $val(nn)} {incr i} {
# 20 defines the node size in nam, must adjust it according to your scenario
# The function must be called after mobility model is defined
$ns_ initial_node_pos $node_($i) 20
}
# Tell nodes when the simulation ends
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $val(stop).0 "$node_($i) reset";
}
$ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
puts $tracefd "M 0.0 nn $val(nn) x $val(x) y $val(y) rp $val(adhocRouting)"
puts $tracefd "M 0.0 sc $val(sc) cp $val(cp) seed $val(seed)"
puts $tracefd "M 0.0 prop $val(prop) ant $val(ant)"
puts "Starting Simulation..."
$ns_ run
209
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Configuration file (12) “simulation.tcl” for simulations with GPSR routing protocol
set opt(chan)
Channel/WirelessChannel
#set opt(prop)
Propagation/TwoRayGround
set opt(netif)
Phy/WirelessPhy
set opt(mac)
Mac/802_11
set opt(ifq)
Queue/DropTail/PriQueue
set opt(ll)
LL
set opt(ant)
;# for dsdv
Antenna/OmniAntenna
set opt(cp)
"./cbr.tcl"
set opt(sc)
"./scenario.ns_movements"
set opt(x)
3001
;# X dimension of the topography
set opt(y)
1001
;# Y dimension of the topography
set opt(nn)
60
;# number of nodes
set opt(stop)
1000
;# simulation time
set opt(ifqlen)
50
;# max packet in ifq
set opt(seed)
0.0
set opt(tr)
trace.tr ;# trace file
set opt(nam)
nam.out.tr
set opt(rp)
gpsr
;# routing protocol script (dsr or dsdv)
set opt(lm)
"off"
;# log movement
set opt(prop)
set opt(RiceanK)
Propagation/Ricean
0
set opt(RiceanMaxVel) 13.89
;# Rayleigh and Ricean
;# Ricean K factor
;# Ricean Propagation MaxVelocity Parameter
# Ricean Propagation: Maximum ID of nodes (Total number of nodes) used to
# compute pairwise table offsets.
set opt(RiceMaxNodeID) [expr {$opt(nn)-1}]
set opt(RiceDataFile) rice_table.txt
# Agent/GPSR setting
210
;
;# Ricean Propagation Data File
ANNEX: HOW TO DO THE SIMULATIONS
Agent/GPSR set sink 5;
Agent/GPSR set sinkX 1000;
Agent/GPSR set sinkY 0;
Agent/GPSR set APs 11;
Agent/GPSR set stableperiod 150; #if density <= 40 stableperiod = 150 sec.
Agent/GPSR set planar_type_ 1 ;#1=GG planarize, 0=RNG planarize
Agent/GPSR set hello_period_ 1 ;#Hello message period .2
Agent/GPSR set query_period_ 1.105;#Beacon period 1.105
Agent/GPSR set max_defer_time 0.01; # 0.010
Agent/GPSR set RadioRange 250;
LL set mindelay_
50us
LL set delay_
25us
LL set bandwidth_
0
Agent/Null set sport_
0
Agent/Null set dport_
0
Agent/CBR set sport_
0
Agent/CBR set dport_
0
Agent/TCPSink set sport_
0
Agent/TCPSink set dport_
0
Agent/TCP set sport_
0
Agent/TCP set dport_
0
Agent/TCP set packetSize_
1460
;# not used
Queue/DropTail/PriQueue set Prefer_Routing_Protocols 1
# unity gain, omni-directional antennas
# set up the antennas to be centered in the node and 1.5 meters above it
Antenna/OmniAntenna set X_ 0
Antenna/OmniAntenna set Y_ 0
Antenna/OmniAntenna set Z_ 1.5
211
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Antenna/OmniAntenna set Gt_ 1.0
Antenna/OmniAntenna set Gr_ 1.0
# Initialize the SharedMedia interface with parameters to make
# it work like the 914MHz Lucent WaveLAN DSSS radio interface
Phy/WirelessPhy set CPThresh_ 10.0
Phy/WirelessPhy set CSThresh_ 1.559e-11
Phy/WirelessPhy set RXThresh_ 3.652e-10
Phy/WirelessPhy set Rb_ 2*1e6
Phy/WirelessPhy set freq_ 914e+6
Phy/WirelessPhy set L_ 1.0
# The transimssion radio range
#Phy/WirelessPhy set Pt_ 6.9872e-4 ;# ?m
#Phy/WirelessPhy set Pt_ 8.5872e-4 ;# 40m
#Phy/WirelessPhy set Pt_ 1.33826e-3 ;# 50m
#Phy/WirelessPhy set Pt_ 7.214e-3
;# 100m
Phy/WirelessPhy set Pt_ 0.03652
;# 150m
#Phy/WirelessPhy set Pt_ 0.1154
;# 200m
#Phy/WirelessPhy set Pt_ 0.2818
;# 250m
proc usage { argv0 } {
puts "Usage: $argv0"
puts "\tmandatory arguments:"
puts "\t\t\[-x MAXX\] \[-y MAXY\]"
puts "\toptional arguments:"
puts "\t\t\[-cp conn pattern\] \[-sc scenario\] \[-nn nodes\]"
puts "\t\t\[-seed seed\] \[-stop sec\] \[-tr tracefile\]\n"
}
proc getopt {argc argv} {
global opt
212
ANNEX: HOW TO DO THE SIMULATIONS
lappend optlist cp nn seed sc stop tr x y
for {set i 0} {$i < $argc} {incr i} {
set arg [lindex $argv $i]
if {[string range $arg 0 0] != "-"} continue
set name [string range $arg 1 end]
set opt($name) [lindex $argv [expr $i+1]]
}
}
proc log-movement {} {
global logtimer ns_ ns
set ns $ns_
source /usr/src/ns-allinone-2.27/ns-2.27/tcl/mobility/timer.tcl
Class LogTimer -superclass Timer
LogTimer instproc timeout {} {
global opt node_;
for {set i 0} {$i < $opt(nn)} {incr i} {
$node_($i) log-movement
}
$self sched 0.1
}
set logtimer [new LogTimer]
$logtimer sched 0.1
}
source /usr/src/ns-allinone-2.27/ns-2.27/tcl/lib/ns-bsnode.tcl
source /usr/src/ns-allinone-2.27/ns-2.27/tcl/mobility/com.tcl
# do the get opt again incase the routing protocol file added some more
# options to look for
213
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
getopt $argc $argv
if { $opt(x) == 0 || $opt(y) == 0 } {
usage $argv0
exit 1
}
if {$opt(seed) > 0} {
puts "Seeding Random number generator with $opt(seed)\n"
ns-random $opt(seed)
}
# Initialize Global Variables
set ns_
[new Simulator]
#$ns_ use-scheduler Heap
remove-all-packet-headers
add-packet-header GPSR
#add-packet-header ARP LL MAC CBR IP
set chan
[new $opt(chan)]
set prop
[new $opt(prop)]
set topo
[new Topography]
GPSR
set tracefd [open $opt(tr) w]
$ns_ trace-all $tracefd
set namfile [open $opt(nam) w]
$ns_ namtrace-all $namfile
$topo load_flatgrid $opt(x) $opt(y)
$prop topography $topo
# Create God
set god_ [create-god $opt(nn)]
# Create the specified number of nodes $opt(nn) and "attach" them
# the channel.
214
ANNEX: HOW TO DO THE SIMULATIONS
# Each routing protocol script is expected to have defined a proc
# create-mobile-node that builds a mobile node and inserts it into the
# array global $node_($i)
$ns_ node-config -adhocRouting gpsr \
-llType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace OFF
# Set propagation settings
if { $opt(prop) == "Propagation/Ricean"} {
set prop_inst [$ns_ set propInstance_]
#$prop_inst MaxVelocity 2.5;
#$prop_inst RiceanK
6;
#$prop_inst LoadRiceFile "rice_table.txt";
$prop_inst MaxVelocity $opt(RiceanMaxVel);
$prop_inst RiceanK
$opt(RiceanK);
$prop_inst LoadRiceFile $opt(RiceDataFile);
$prop_inst RiceMaxNodeID $opt(RiceMaxNodeID);
}
215
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
source /usr/src/ns-allinone-2.27/ns-2.27/gpsr/gpsr.tcl
for {set i 0} {$i < $opt(nn) } {incr i} {
gpsr-create-mobile-node $i
}
#
# Define traffic model
#
puts "Loading scenario file..."
source $opt(sc)
puts "Loading connection pattern..."
source $opt(cp)
# Tell all the nodes when the simulation ends
for {set i 0} {$i < $opt(nn) } {incr i} {
$ns_ at $opt(stop).000000001 "$node_($i) reset";
}
$ns_ at $opt(stop).00000001 "puts \"NS EXITING...\" ; $ns_ halt"
#puts $tracefd "M 0.0 nn $opt(nn) x $opt(x) y $opt(y) rp $opt(rp)"
#puts $tracefd "M 0.0 sc $opt(sc) cp $opt(cp) seed $opt(seed)"
#puts $tracefd "M 0.0 prop $opt(prop) ant $opt(ant)"
puts "Starting Simulation..."
proc finish {} {
global ns_ tracefd namfile
$ns_ flush-trace
close $tracefd
close $namfile
exit 0
}
#$ns_ at $opt(stop) "finish"
216
ANNEX: HOW TO DO THE SIMULATIONS
#$ns_ at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt"
$ns_ run
217
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Awk filter (14) “filter.awk”
BEGIN {
output="output.txt"
# Variables definition
sent=0
received=0
high=0
total=0
count=1
}
{
# set variables to the columns of trace file
action=$1
time=$2
node=$3
prot=$4
drop=$5
id=$6
type=$7
bytes=$8
# Send packets
if (action == "s")
{
if (type == "cbr" && prot == "AGT")
{
sent++
start[id]=time
}
218
ANNEX: HOW TO DO THE SIMULATIONS
}
# Recived Packets
if (action == "r")
{
if (node == "_1_" && prot == "AGT" && type == "cbr")
{
received++
end[id]=time
if (id > high)
{
high = id
}
}
}
}
END {
# End-to-end average time
for (n = 0; n < high; n++)
{
inicio = start[n]
final = end[n]
if (inicio < final)
{
total = total + (final-inicio)
count++
}
}
219
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
# Formatting the output.
if (received/sent > 0.01){
printf("==========================================================
===\n") >> output
printf("Data throughput: %f\n", received/sent) >> output
printf("Average end-to-end time (ms): %f\n", (total*1000)/count) >>
output
printf("==========================================================
===\n\n") >> output
}
close(output)
}
220
ANNEX: HOW TO DO THE SIMULATIONS
Octave script (16) “process.m”
DT = load "estimates_DT.txt";
ETET = load "estimates_ETET.txt";
Simulations = length(DT)
Data_throughput = mean(DT)
u_Data_throughput = std(DT)/Simulations^0.5
End_to_end_time = mean(ETET)
u_End_to_end_time = std(ETET)/Simulations^0.5
Output file (17) “result.txt” and (18) “result_N.txt”
Simulations = 5
Data_throughput = 0.16394
u_Data_throughput = 0.046379
End_to_end_time = 2481.3
u_End_to_end_time = 580.84
221
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
11.8.1. VanetMobiSim Configuration file
In this first section a scenario must be defined in a XML file. The scenario proposed defines 10
nodes, a simulation area of 200x200 meters, a simulation time of 400 seconds and a Random
spatial model:
Fig. 11-3 VanetMobiSim XML file
All fields and specifications are descripted below:
222
ANNEX: HOW TO DO THE SIMULATIONS
11.8.1.1.
General specifications
Area dimensions, seed, simulation time and output trace file are included in this section. With
<dimx> tag and <dimy> tag the x-dimension and y-dimension of the simulation area in meters
can be specified (notice they only can be used in scenarios with rectangular-bounded
simulation areas). With the <seed> tag the random number generation used by VanetMobiSim
can be specified.
An instance of global extension is added using the <extension> tag and with <name> tag the
name of the class to be instantiated is defined. With an instance of class
de.uni_stuttgart.informatik.canu.mobisim.extensions.NSOutput a trace file with NS2 format
can be defined. Time simulation can be also be defined with an instance of class de.uni_
stuttgart.informatik.canu.mobisim.simulations.TimeSimulation.

Spatial environment
A
spatial
environment
is
added
with
an
instance
of
de.uni_stuttgart.informatik.canu.spatialmodel.core.SpatialModel. The spatial environment
extension adds support for multilane or multiflow roads and traffic lights at intersections. The
XML file proposed includes comments (in <!-- -->) clarifying the use of different tags.

Traffic lights
Support for traffic lights at intersections can be added using an instance of the
eurecom.spatialmodel.extensions.TrafficLight extension, allowing definition of the time
interval between traffic light changes in ms.

Space Graph
As mentioned in Chapter 6, the spatial model can be created from four different ways. The
proposed XML file has been implemented with the Random option, also known as Space
Graph. A Space Graph is added with an instance of eurecom.spacegraph.SpaceGraph
extension. This creates a random graph built by applying a Voronoi tessellation to a set of
randomly distributed points (obstacles).It is possible to define areas or clusters with different
obstacles densities, creating a non-homogeneous graph. The characteristics of the clustering
are specified using the <cluster> tag. In the proposed scenario the clustering density value is
0,0001clusters/m2, which means that the simulation area of 40.000m2 is divided in 4 clusters.
Then two kinds of areas have been defined in the proposed scenario: a downtown area with a
density value of 0,003 obstacles/m2 and a suburban area with a density value of 0,001
obstacles/m2. The <ratio> tag specifies the percentage of the kind of cluster in the simulation
area, the <speed> tag specifies the maximum speed in m/s allowed on the road segments
created with this culuster type and the <density> tag specifies the density of obstacles in the
cluster in obstacles/m2.
223
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS

Initial position and trip generator
A random generation of the initial position of nodes and their trip model during the simulation
can
be
defined
with
an
instance
of
de.uni.stuttgart_informatik.canu.tripmodel.generators.RandomInitialPositionGenerator
and
de.uni_stuttgart.informatik.canu.tripmodel.generators.RandomTripGenerator
extensions
respectively.

Node Definition
Multiple nodes are added to the simulation using the <nodegroup> tag. To simulate node’s
motion using the IDM_LC an instance of polito.uomm.IDM_LC extension is used. Vehicles
moving according to the IDM_LC model support smart intersection management: they slow
down and stop at intersections, or act according to traffic lights, if present. Also, vehicles are
able to change lane and perform overtakings in presence of multi-lane roads.
Although in the proposed scenario only include a few specifications such as acceleration or
maximum or minimum speed, the VanetMobiSim User’s Guide [80] includes an extensive list of
features than can be configure.

GUI definition
During simulation a GUI appears displaying the Spatial Model and its elements such as roads
and
nodes
motion.
With
an
instance
of
de.uni_stuttgart.informatik.canu.mobisimadd.extensions.GUI extension, GUI’s width and
height can be select. Moreover a frame of the Spatial Model can be saved to an output file in
.fig
format
with
an
instance
of
the
de.uni_suttgart.informatik.canu.spatialmodel.extensions.DumpSpatialModel extension.
For further descriptions of any tag or specification, the VanetMobiSim User’s Guide is available
[80].
Once the scenario XML file is configured, the next step will be run VanetMobiSim. To launch
the framework, it must change to the directory with framework’s files and type:
Fig. 11-4 VanetMobiSim shell launching
When simulation ends, a file named test_trace has been created. It contains the mobility
traces for NS2 simulation.
224
ANNEX: HOW TO DO THE SIMULATIONS
11.8.2. NS2 configuration file
In this second section communications and network configuration must be described. As
mentioned before, the file/script must be defined using Tcl programming language. The
proposal is the following:
Fig. 11-5 NS2 script - DEFINE OPTIONS
The Tcl script is divided in two sections: DEFINE OPTIONS SECTION and MAIN PROGRAM.
General simulation specifications such as simulation time and area or number of nodes are
defined in the DEFINE OPTIONS SECTION as well as some network and channel features.
Moreover the path of the scenario file generated by VanetMobiSim is added in this section
too. In the script proposed the path selected is test_trace because it is found on the same
directory of the script proposed. If not, it would be necessary to consider the corresponding
path /directory_1/…/directory_n/test_trace. Later on, in the MAIN PROGRAM, the scenario file
will be loaded with the command source $val(sc).
225
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
Fig. 11-6 NS2 script - MAIN PROGRAM
The MAIN PROGRAM includes creation of the simulator instance and trace objects, the nodes
settings and the traffic configuration. The proposed network consists on a UDP communication
between two nodes: node #0 generates CBR traffic and sent it to node #7. The other eight
nodes work as a relay and the mobility model is load from the test_trace file, generated by
VanetMobiSim.
The performance is the following: the simulation starts and after 400 seconds, NS2 stops the
communication and closes the out.tr file, which logs all routing events during the simulation.
Once the Tcl script is configured, the next step will be run NS2. To launch the framework, it
must invoke the simulator. When simulation ends, the ouput out.tr file has been created.
Fig. 11-7 NS2 shell launching
226
ANNEX: HOW TO DO THE SIMULATIONS
11.8.3. AWK script
In this last section it describes how to filter the out.tr output file from NS2 to exctact significant
data from the simulation. The proposed awk/filter file is the following:
Fig. 11-8 AWK script
With this simple awk file, data about transmitted bytes, received bytes and packet loss will be
obtained and saved to output.txt file. To launch AWK, it must type
Fig. 11-9 AWK shell launching
After running AWK, the output.txt file contains the following:
Transmitted packets: 397;
Transmitted bytes: 203264;
Received packets: 396;
Received bytes: 210672;
Data throughput: 0.997481;
Packet loss: 1;
227
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
11.9. CONFIDENCE INTERVALS
In statistics, a confidence interval (CI) is a particular kind of interval estimate of a population
parameter and is used to indicate the reliability of an estimate. It is an observed interval (i.e it
is calculated from the observations), in principle different from sample to sample, that
frequently includes the parameter of interest, if the experiment is repeated. How frequently
the observed interval contains the parameter is determined by the confidence
level or confidence coefficient.
A confidence interval with a particular confidence level is intended to give the assurance that,
if the statistical model is correct, then taken over all the data that might have been obtained,
the procedure for constructing the interval would deliver a confidence interval that included
the true value of the parameter the proportion of the time set by the confidence level. More
specifically, the meaning of the term "confidence level" is that, if confidence intervals are
constructed across many separate data analyses of repeated (and possibly different)
experiments, the proportion of such intervals that contain the true value of the parameter will
approximately match the confidence level; this is guaranteed by the reasoning underlying the
construction of confidence intervals.
A confidence interval does not predict that the true value of the parameter has a particular
probability of being in the confidence interval given the data actually obtained. (An interval
intended to have such a property, called a credible interval, can be estimated
using Bayesian methods; but such methods bring with them their own distinct strengths and
weaknesses).
Interval estimates can be contrasted with point estimates. A point estimate is a single value
given as the estimate of a population parameter that is of interest, for example the mean of
some quantity. An interval estimate specifies instead a range within which the parameter is
estimated to lie. Confidence intervals are commonly reported in tables or graphs along with
point estimates of the same parameters, to show the reliability of the estimates.
Fig. 11-10 Example of confident interval
228
ANNEX: HOW TO DO THE SIMULATIONS
For example, a confidence interval can be used to describe how reliable survey results are. In a
poll of election voting-intentions, the result might be that 40% of respondents intend to vote
for a certain party. A 90% confidence interval for the proportion in the whole population
having the same intention on the survey date might be 38% to 42%. From the same data one
may calculate a 95% confidence interval, which might in this case be 36% to 44%. A major
factor determining the length of a confidence interval is the size of the sample used in the
estimation procedure, for example the number of people taking part in a survey.
In the bar chart, the tops ends of the bars indicate observation means and the red line
segments represent the confidence intervals surrounding them.
Confidence is defined as 1 -  (1 minus the significance level). Thus, when we construct a 95%
confidence interval, we are saying that we are 95% certain that the true population mean is
covered by the interval - consequently, of course, we have a 5% chance of being wrong. Any
statistic that can be evaluated in a test of significance ("hypothesis testing") can be used in
constructing a confidence interval. When constructing a confidence interval two limits,
"Upper" and "Lower", are always computed. The upper and lower boundaries for the
confidence interval for the t-statistic given above are:
(𝑋 − 𝑍𝛼 ∙
2
𝜎
√𝑛
, 𝑋 + 𝑍𝛼 ∙
2
𝜎
√𝑛
)
(10.1)
Where X is the mean and  is the variance of the n samples. Examples z for different %
2
confident interval are:
z  90%   1, 645
2
z  95%   1,96
2
z  99%   2,58
2
229
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
REFERENCES AND BIBLIOGRAPHY
[1] A.Abdi, M.Kaveh, G.Giannakis, « On the Estimation of the K Parameter for the Rice Fading
Distribution » IEEE COMMUNICATIONS LETTERS, VOL.5, NO.3 MARCH 2001
[2] K. Abrougui, A. Boukerche, et. al, “Location-Aided Gateway Advertisement and Discovery
Protocols for VANETs”.
[3] M. Alam, M. Sher, S. A. Husain, "Integrated Mobility Model (IMM) for VANETs Simulation
and Its Impact".
[4] Alshanyour, U. Baroudi, “Random and Realistic Mobility Models Impact on the
Performance of Bypass-AODV Routing Protocol”.
[5] D. B. J. Amit Kumar Saha, “Modeling mobility for vehicular ad-hoc networks”
[6] http://www.gnu.org/software/gawk/manual/gawk.html
[7] F. Bai, N. Sadagopan, and A. Helmy, “Important: a framework to systematically analyze the
impact of mobility on performance of routing protocols for ad hoc networks”
[8] P. Bhagwat, C.E. Perkins, "Highly Dynamic Destination-Sequenced Distance-Vector Routing
(DSDV) for Mobile Computers”, Sigcomm (1994)
[9] E. Biagioni, K. Bridges and B.J.S Chee, "PODS: A remote ecological Micro sensor network",
(EURASIP Journal on Wireless Communications and Networking archive Volume 2005 Issue
5 - October 2005)
[10] Katrin Bilstrup, Elisabeth Uhlemann, Erik G. Ström, Urban Bilstrup, «Evaluation of the IEEE
802.11p MAC method for Vehicle-to-Vehicle Communication», Centre for Research on
Embedded Systems Halmstad University (SWEDEN) , Vehicular Technology Conference,
2008. VTC 2008-Fall. IEEE 68th
[11] Bonnmotion Mobility Scenario Generator
bonn.de/wg/cs/applications/bonnmotion/
(Bonn
Universität)
http://net.cs.uni-
[12] R.V. Boppana, P. Konduru, "An Adaptive Distance Vector Routing Algorithm for Mobile Ad
Hoc Network”, Proceedings of the Twentieth Annual Joint Conference of the IEEE
Computer and communications Societes, pp.1753-1762, Oct. 2001
[13] BUET – Bangladesh University of Engineering and Technology, http://www.buet.ac.bd/
[14] G. Caizzone, P. Giacomazzi, L. Musumeci, G. Verticale, “A Power Control Algorithm with
High Channel Availability for Vehicular Ad-Hoc Networks”.
[15] CANU
Research
Group
stuttgart.de/mobisim/
(Stuttgart
University)
http://canu.informatik.uni-
[16] Car2Car Communication Consortium, official webpage: http://www.car-to-car.org
230
REFERENCES AND BIBLIOGRAPHY
[17] E. Cayirci and T. Coplu, “SENDROM: sensor networks for disaster relief operations
management” (Journal Wireless Network Volume 13 Issue 3 - 2007)
[18] U.S. Census Bureau, http://www.census.gov/geo/www/tiger/
[19] W.Chen, S.Cai, "Ad Hoc Peer-to-Peer Network Architecture for Vehicle Safety
Communications", IEEE Communications Magazine, pp 100-107, April 2005.
[20] D. R. Choffnes and F. E. Bustamante, “An integrated mobility and traffic model for
vehicular wireless networks”
[21] CityMob Generador de Patrones de
http://www.grc.upv.es/Software/citymob.html
Movimiento
(Universidad
Valencia)
[22] Cooperative Intersection Collision Avoidance System (CICAS), official webpage:
http://www.its.dot.gov/cicas/
[23] Coopers (Co-operative System
http://www.coopers-ip.eu/
for Intelligent Road Safety), official webpage:
[24] CVIS
(Cooperative
Vehicle-Infrastructure
http://www.cvisproject.org/
Systems),
official
webpage:
[25] http://www.dailytech.com/article.aspx?newsid=5257
[26] T. Dang, S. Frolov, N. Bulusu, A. Baptista “Near Optimal Sensor Selection in the COlumbia
RIvEr (CORIE) Observation Network for Data Assimilation Using Genetic Algorithms”
(DCOSS'07 Proceedings of the 3rd IEEE international conference on Distributed computing
in sensor system – Berlin 2007)
[27] V. Davies, "Evaluating mobility models within an ad hoc network"
[28] D. Djenouri, W. Soualhi, E. Nekka, “Mobility models in vehicular ad hoc networks: the
overtaking impact”.
[29] http://www.dtnrg.org/wiki
[30] M.F. Durate and Y.H. Hu, “Vehicle classification in Distributed Sensor Networks” (Journal of
Parallel and Distributed Computing Volume 64 Issue 7 – Orlando July 2004)
[31] http://ec.europa.eu/information_society/activities/esafety/ecall/index_en.htm
[32] http://www.estinet.com/products.php
[33] FleetNet Project – Internet on the road, http://www.et2.tu-harburg.de/fleetnet
[34] FreeSim, 2008. Available at: http://www.freewaysimulator.com/
[35] V. González, A. Los Santos, C. Pinart, F. Milagro «Experimental demonstration of the
viability of EEE 802.11b based inter-vehicle communications», Telefónica I+D’s Networked
Vehicles Division (SPAIN), TRIDENTCOM 2008 in Belgium – International Conference on
Testbeds and Research Infrastructures for the Development of Networks and Communities
[36] Project GST, http://www.gstforum.org
231
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
[37] Haerri J, Fiore M, Fethi F, Bonnet C. VanetMobiSim: generating realistic mobility patterns
for VANETs. Institut Eurécom and Politecnico Di Torino, 2006.
[38] H. Hartenstein,
Technologies”.
K.
Laberteaux,
“Vehicular
Applications
and
Inter-Networking
[39] Harvard Sensor Network Lab, http://fiji.eecs.harvard.edu/Volcano
[40] H. Huang, Y. Zhu, X. Li, M. Li, M. Wu, "META: a Mobility Model of MEtropolitan TAxis
Extracted from GPS Traces".
[41] IntelliDrive, official webpage: http://www.intellidriveusa.org/
[42] Integrated
Vehicle-Based
http://www.its.dot.gov/ivbss/
Safety
Systems
(IVBSS),
official
webpage:
[43] J. Jakubiak, Y. Koucheryavy, "State of the art and research challenges for VANETs",
Consumer Communications and Networking Conference, 2008, Jan 10-12. 2008, pp: 912916.
[44] P. Johanson, T. Larsson, N. Hedman, B. Mielczarek, M. Degermark, “Scenario-based
Performance Analysis of Routing Protocols for Mobile Ad-hoc Networks” Proceedings of
ACM/IEEE MOBICOM'99, Seattle, WA, August 1999, pp.195-206
[45] D. Johnson, Y. Hu, D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad
Hoc Networks for IPv4", RFC4728, February 2007
[46] F. K. Karnadi, Z. H. Mo, and K. chan Lan, “Rapid generation of realistic mobility models for
vanet”
[47] Krajzewicz D, Rossel C. Simulation of Urban Mobility (SUMO).
[48] H. Labiod “Wireless Ad Hoc and Sensor Networks” (John Wiley & Sons -2008)
[49] A. Lagar Carvilla “MANET extensions to NS2” Department of Computer Science University
of Toronto. Code available at http://lagarcavilla.org/software.html
[50] K. Lan, C. Chou, "Realistic Mobility Models for Vehicular Ad hoc Network (VANET)
Simulations".
[51] X. Li, T. Nguyen, R. Martin, “Using Adaptive Range Controls to Maximize 1-Hop Broadcast
Coverage in Dense Wireless Networks”.
[52] Liu, et. al, “Assessing the VANET’s Local Information Storage Capability under Different
Traffic Mobility”.
[53] J. Luo, et. al, “MI-VANET: A New Mobile Infrastructure Based VANET Architecture for
Urban Environment”.
[54] A. Mahajan, N. Potnis, K. Gopalan, and A.-I. A. Wang, “Urban mobility models for vanets”
[55] F. J. Martinez, J.-C. Cano, C. T. Calafate, and P. Manzoni, "Citymob: a mobility model
pattern generator for VANETs". IEEE Vehicular Networks and Applications Workshop (VehiMobi, held with ICC). Beijing, may, 2008
232
REFERENCES AND BIBLIOGRAPHY
[56] A. Mitra « Lecture Notes on Mobile Communication. A Curriculum Development Cell
Project QIP », Department of Electronics and Communication Engineering (Indian Institute
of Technology Guwahati) – November 2009
[57] Muñoz C., Aguilar M., “Diseño e implementación de un servidor de vídeo adaptativo en
simulador de redes ad-hoc” Proyecto final de carrera, UPC, 2009.
[58] Navarro D., Llàrio X., et. al, “Performance evaluation of vehicular ad-hoc networks over
high speed environments using NCTUns” Proyecto final de carrera, UPC, 2010.
[59] NCTUns (National Chiao Tung University, TAIWAN) http://nsl.csie.nctu.edu.tw/nctuns.html
[60] Networking and Emerging Optimization, http://www.neo.lcc.uma.es/
[61] Network On Weels (NOW), official webpage: http://www.network-on-wheels.de/
[62] NS-2.34 source code http://sourceforge.net/projects/nsnam/
[63] NS-2 DARPA Project http://nsnam.isi.edu/nsnam/index.php/User_Information
[64] E.I. Pas, “Recent Advances in Activity-based Travel Demand Modeling” Proceedings of
Activity-based Travel Forecasting Conference, June 2-5 1996
[65] C. Perkins, E. Belding-Royer, E. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing",
RFC3561, July 2003
[66] R.Popescu, I.Radusch, R.A.Rigani “Vehicular-2-X Communications: State-of-the-Art and
Research in Mobile Vehicular Ad hoc Networks” (Springer – 2010)
[67] D. Prakash, C. de Morais “Ad Hoc & Sensor Networks” (World Scientific – 2006)
[68] PReVENT, official webpage: http://www.prevent-ip.org/
[69] R.J. Punnoose, P.V. Nikitin, D.D. Stancil, « Efficient Simulation of ricean fading within a
packet
simulator »
September
2000.
Code
available
at
http://www.ece.cmu.edu/wireless/downloads/ns2 ricean dist.tgz.
[70] N.N.Qadri, M.Fleury, M.Altaf, M.Ghanbari « Multi-source video streaming in a wireless
vehicular ad hoc network » COMSATS Institute of Information Technology, Park Road,
Islamabad (Pakistan) – IET Communications 2009 Vol.4, Issue 11, Pages 1300-1311
[71] B. Ramakrishnan, Dr. R. S. Rajesh, R. S. Shaji, «Performance Analysis of 802.11 and 802.11p
in Cluster Based Simple Highway Model» (IJCSIT) International Journal of Computer
Science and Information Technologies, Vol. 1 (5) , 2010, 420-426
[72] SAFESPOT, official webpage: http://www.safespot-eu.org/
[73] P. Sattesh Kumar, S. Ramachandram, "The Performance Evaluation of Genetic Zone
Routing Protocol for MANETs", TENCON 2008 – 2008 IEEE Region 10 Conference
[74] L. Schwiebert, S.K.S. Gupta and J. Weinmann, “Research challenges in Wireless Networks
of biomedical sensors” (Research challenges in Wireless Networks of biomedical sensors –
2001)
233
PERFORMANCE EVALUATION OF GEOGRAPHIC AND TOPOLOGICAL ROUTING PROTOCOLS FOR VEHICULAR AD-HOC NETWORKS
[75] G.Sklyarenko, "AODV Routing Protocol", Seminar Technische Informatik, Institut fur – Freie
Universitat Berlin, July 2006
[76] SUMO "Simulation of Urban Mobility. http://sumo.sourceforge.net/”
[77] W. Sun, H. Yamaguchi, and K. Yukimasa, “Gvgrid: A qos routing protocol for vehicular ad
hoc networks”.
[78] M.Takai, J.Martin, R.Bagrodia « Effects of Wireless Physical Layer Modeling in Mobile Ad
Hoc Networks » UCLA Computer Science Department - MobiHoc '01 Proceedings of the
2nd ACM international symposium on Mobile ad hoc networking & computing, NY (USA),
2001
[79] J. Tarng, B. Chuang, and F. Wu, “A novel stability-based routing protocol for mobile adhoc,” IEICE Transactions on Communications, vol. E90-B, no. 4, pp. 876–884, April, 2007.
[80] VanetMobiSim (Politecnico di Torino) http://vanet.eurecom.fr/
[81] VINT (Virtual InterNetwork Testbed) Project http://www.isi.edu/nsnam/vint/
[82] Yi Wang, Akram Ahmed, Bhaskar Krishnamachari, Konstantinos Psounis, «IEEE 802.11p
Performance Evaluation and Protocol Enhancement» Proceedings of the 2008 IEEE
International Conference on Vehicular Electronics and Safety Columbus, OH, USA.
September 22-24, 2008
[83] Shie-Yuan Wang; Chih-Che Lin, "NCTUns 5.0: A Network Simulator for IEEE 802.11(p) and
1609 Wireless Vehicular Network Researches," Vehicular Technology Conference, 2008.
VTC 2008-Fall. IEEE 68th, pp.1-2, 21-24 Sept.
[84] S.Y. Wang, C. L. Chou, et. Al, “The Protocol Developer Manual for the NCTUns 6.0 Network
Simulator and Emulator”,
[85] Wei-Yen Lin, Mei-Wen Li, Kun-chan Lan, Chung-Hsien Hsu, «A comparison of 802.11a and
802.11p for V-to-I communication: a measurement study», Computer Science and
Information Engineering of Taiwan. 7th International ICST Conference on Heterogeneous
Networking for Quality, Reliability, Security and Robustness (International workshop on
DSRC 2010), Houston, Texas, USA November 17-19, 2010
[86] M. Wellens, B.Westphal and P. Mähönen, «Performance Evaluation of IEEE 802.11-based
WLANs in Vehicular Scenario», Department of Wireless Networks, RWTH Aachen
University. Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th,
Page(s):1167 – 1171
[87] http://www.vmware.com/
[88] G.Yan, D.B. Rawat, B.B. Bista, “Provisioning Vehicular Ad hoc Networks with Quality of
Service”
[89] F. Zhao, L.J. Guibas “Wireless Sensor Networks” (Morgan Kaufmann – 2004)
[90] Brad Karp and H. T. Kung. GPSR: Greedy Perimeter Stateless Routing for wireless Networks.
MobiCom 2000
234
REFERENCES AND BIBLIOGRAPHY
[91] Cheng Fenhua and Jim Min. Improved GPSR Routing Algorithmand Its Performance
Analysis
[92] Zhong-Yi LIU, Jin-Guo ZHOU, Tong ZHAO and Wei YAN. An Opportunistic Approach to
Enhance the Geographical Source Routing Protocol for Vehicular Ad-hoc Networks
[93] ftp://ftp.isi.edu/nsnam/ns-allinone-2.27.tar.gz
[94] http://sertel.upc.es/~maguilar/ns2_code_victor/ns227-gcc34.patch
[95] http://www.cs.binghamton.edu/~kliu/research/ns2code/
[96] Nedal Ababneh, Houda Labiod and Nadia Boukhatem. Evaluation of Routing Protocols for
VANETs in Urban Environments.
[97] http://www.gnu.org/software/octave/
[98] https://sertel.upc.edu/~maguilar/ficheros/Memoria%20Roger.docx
[99] https://sertel.upc.edu/~maguilar/ficheros/InstallationGuideNS2_David.txt
[100] http://www.vmware.com/products/player/overview.html
[101] http://www.ubuntu.com/
[102] Monica Aguilar Igartua, Luis J. de la Cruz Llopis, Victor Carrascal Frias, Emilio Sanvicente
Gargallo. A game-theoretic multipath routing for video-streaming services over Mobile Ad
Hoc Networks.
[103] David B. Johnson David A. Maltz Josh Broch. DSR: The Dynamic Source Routing Protocol for
Multi-Hop Wireless Ad Hoc Networks.
235