Embed Size (px)
Citation preview
Geographic Location and Routing in VehicularNetworks
André Ricardo da Silva Camões
Thesis to obtain the Master of Science Degree in
Communication Networks Engineering
Examination Committee
Chairperson: Prof. Paulo Jorge Pires FerreiraSupervisor: Prof. Teresa Maria Sá Ferreira Vazão Vasques
Member of the Committee: Prof. Luis Filipe Lourenço Bernardo
November 2013
ii
Acknowledgements
Em primeiro lugar gostaria de agradecer a minha orientadora, a Prof. Teresa Vazao, por todo o apoio
que me deu nao so no decorrer desta tese mas tambem ao longo destes anos na faculdade. Guardarei
com muita estima todos os conselhos que me deu e que me formaram nao so como aluno mas tambem
como pessoa.
Em segundo lugar gostaria de agradecer a minha famılia por todo o amor, por todo o suporte e por
tudo o que me ensinaram ao longo da vida. Todas as conquistas que um dia alcancarei se devem a
voces.
Gostaria de dedicar uma palavra especial ao Antonio Fonseca, por ter sempre acreditado em mim
e por me ter apoiado de uma forma incondicional ao longo da minha vida academica e ao longo deste
trabalho.
A todos os meus colegas de faculdade Carlos Simoes, Goncalo Pereira, Joao Rosa, Nadia Pires,
companheiros de muitas lutas, nao tenho palavras para voces. Este trilho percorrido ao vosso lado foi
sem duvida marcante. Muito obrigado por todos os momentos.
Finalmente gostaria de agradecer aos amigos de uma vida, Jorge Serra e Teresa Silva, por todos os
dias continuarem a ensinar-me o que significa a palavra Amizade.
iii
iv
Abstract
Given the constant development in Vehicular Networks, this area has gained increasingly maturity, with
new proposals to address the new challenges brought by this type of networks, in particular questions
concerning about routing processes, different vehicular environments and high node mobility problem-
atic. Associated with this development is the ever growing commitment by automotive manufacturers
to equip their vehicles with communication units, in addition to the already common widespread GPS
devices. It is of interest, then, to develop efforts towards the making of networks that take full advantage
of the features present in this vehicular environment. In this work will be implemented a location service,
that takes advantage of the physical infrastructure presented on the roads.
Keywords: Vehicular Networks, Routing, Location Service
v
vi
Resumo
Dado o constante desenvolvimento das redes veiculares, esta area tem ganho cada vez mais ma-
turidade com novas propostas que respondem a novos desafios gerados por este tipo de redes. Os
principais focos de estudo sao as questoes que envolvem os processos de routing, os diferentes ambi-
entes veiculares e a problematica da elevada mobilidade dos nos. Associado a este desenvolvimento
esta o cada vez mais serio compromisso das construtoras automoveis em equipar os seus veıculos com
unidades de comunicacao, alem dos ja muito difundidos dispositivos GPS. Interessa entao, que sejam
desenvolvidos esforcos de forma a serem criadas redes que facam uso de todo o potencial presente no
ambiente veicular. Neste trabalho sera implementado um servico de localizacao, capaz de tirar partido
da infraestrutura fısica presente nas estradas.
Palavras Chave: Redes Veiculares, Routing, Servico de Localizacao
vii
viii
Contents
Acknowledgements iii
Abstract v
Resumo vii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
List of Acronyms xvii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectives and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 State of the Art 3
2.1 Routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Taxonomy of Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Topology-based group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Position-based group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4 Epidemic Protocols group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.5 Comparison and Discussion of the Routing Protocols . . . . . . . . . . . . . . . . 6
2.2 Position-based routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Greedy Perimeter Stateless Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Greedy Perimeter Coordination Routing . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Greedy Perimeter Stateless Routing with Lifetime . . . . . . . . . . . . . . . . . . . 8
2.2.4 Improved Greedy Traffic Aware Routing . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Anchor-Based Street and Traffic Aware Routing . . . . . . . . . . . . . . . . . . . . 9
2.2.6 Comparison and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Taxonomy of Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ix
2.3.2 Reactive Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Grid Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Hierarchical Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5 Comparison and Discussion of the Location Services . . . . . . . . . . . . . . . . 14
2.4 Location techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Global Positioning System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Map Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3 Dead Reckoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.4 Cellular Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.5 Image and Video Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.6 Localization Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.7 Ad-hoc Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.8 Discussion of the Location Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Discussion and Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Architecture 18
3.1 Characterization of Vehicular Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 Urban Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Highway Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 Analysis and comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 SILOS General Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Components Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 OBU Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 RSU Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 SILOS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1 Registry Entry Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.2 Position Query Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.3 Remove Entry Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Implementation 31
4.1 Implementations Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Simulator Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Network Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 NS-3 overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 Network Node Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 SILOS Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 GPSR with GOD Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
x
4.4.2 GPSR with SILOS Location Service . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.3 MessageHeaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Functional tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5.1 V2V Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5.2 V2I Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.3 I2I Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Evaluation 44
5.1 Evaluation Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.1 Location Service Protocol Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.2 Routing Protocol Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Evaluation Tests and Analysis of the Results . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.1 Location Service tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.2 Routing Protocols tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Conclusion 53
6.1 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Final Remarks and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A Appendix 55
Bibliography 59
xi
xii
List of Figures
2.1 Taxonomy of Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Epidemic routing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Greedy forwarding example. Node A wants to send a packet to node D . . . . . . . . . . 7
2.4 Local maximum situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Local maximum situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Taxonomy of Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 A Grid Location Service example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 HLS cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 HLS network partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Representation of an Urban Communication Network Infrastructure . . . . . . . . . . . . . 19
3.2 Representation of a Highway Communication Network Infrastructure . . . . . . . . . . . . 20
3.3 VANET Complete Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 SILOS Conceptual Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 OBU Operation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 RSU Operation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 Diagram of the SILOS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Unidirectional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 NS-3 Basic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 VANET Node Architecture Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Initial Implementation Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 SILOS Implementation Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Example of .log file recreating a V2V communication between 2 OBUs . . . . . . . . . . . 40
4.7 Example of .log file recreating a location query sended from an OBU . . . . . . . . . . . . 41
4.8 Example of .log file representing the reception of a location query by RSU . . . . . . . . . 41
4.9 Example of .log file demonstrating the reception of a location reply from an OBU . . . . . 42
4.10 Example of .log file demonstrating the communication between RSU’s . . . . . . . . . . . 42
5.1 Mobility Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Location Service Overhead versus Distance . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Time to obtain a position versus Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
xiii
5.4 Location Accuracy versus Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Packet Delivery Rate vs Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 Routing Overhead vs Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 Throughput vs Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.1 GetPosition method from GODLocationService . . . . . . . . . . . . . . . . . . . . . . . . 55
xiv
List of Tables
3.1 VANET Scenarios comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
xv
xvi
List of Acronyms
IEEE Institute of Electrical and Electronics Engineers
SMTP Simple Mail Transfer Protocol
GPSR Greedy Perimeter Stateless Routing
AODV Ad-hoc On-demand Distance Vector
DSR Dynamic Source Routing
TORA Temporally-Ordered Routing Algorithm
FSR Fisheye State Routing
OLSR Optimized Link State Routing
TBRPF Topology dissemination Based on Reverse-path Forwarding
RSU RoadSide Unit
OBU On-board Unit
ZRP Zone Routing Protocol
CCU Communication Control Unit
ETC Eletronic Toll Collection
VMS Variable Message Sign
PDR Packet Delivery Rate
GPS Global Positioning System
MANET Mobile Ad-hoc Network
VANET Vehicular Ad-hoc Network
V2I Vehicle-to-Infrastructure
I2I Infrastructure-to-Infrastructure
V2V Vehicle-to-Vehicle
xvii
DSRC Dedicated Short Range Communications
IP Internet Protocol
TCP Transport Control Protocol
UDP User Datagram Protocol
WAVE Wireless Access in Vehicular Environments
A-STAR Anchor-based Street and Traffic Aware Routing
GPSR-L Greedy Perimeter Stateless Routing with Lifetime
GyTAR Greedy Traffic Aware Routing
SUMO Simulation of Urban MObility
MOVE Mobility Model Generator for Vehicular Networks
NS-3 Network Simulator 3
GLS Grid Location Service
HLS Hierarchical Location Service
RLS Reactive Location Service
DREAM Distance Routing Effect Algorithm for Mobility
GPCR Greedy Perimeter Coordinator Routing
TOA Time to Arrival
ETSI European Telecommunications Standards Institute
SAEIP Sistema de Apoio a Exploracao e de Informacao ao Publico
TETRA Terrestrial Trunked Radio
EDR Event Data Recorder
CCTV Closed-Circuit TV
AoA Angle-of-Arrival
ToA Time-of-Arrival
xviii
1Introduction
1.1 Motivation
The evolution in communication systems lead to an emergent research area - vehicular ad-hoc networks
(VANETs) - where the major goal is to improve road safety by extending the communication range and
disseminate relevant information to remote areas. A VANET may be considered a sub-set of mobile ad-
hoc networks (MANETs), with specific characteristics associated with node properties, road environment
and vehicle’s dynamics. Such networks also has a very specific purpose as intended better experience
of drivers and passengers through the provision of Vehicle to Vehicle communications (V2V) and Vehicle
to Infrastructure (V2I).
This new area lead to the development of specific applications, leveraging the low cost of wireless
technology that is widespread. Typically these applications aims to increase road safety and transporta-
tion efficiency, as well as to reduce the impact of transportation on the environment [1]. These features
enable new opportunities that are financially exploited by investors which see in this area a great source
of profit and profitability of the infrastructure. It is notorious that effort by consortia which have been
created to stimulate the growth of this area, including the automotive industry, the road operators, tolling
agencies and other service providers [2].
There are specific requirements of this new environment, such as the different application priorities,
the nodes’ mobility properties and the lack of guaranteed connectivity, that lead to the design of new
protocols. Among them, routing of information and node’s location are quite challenging issues due to
the network dynamics. Different performance studies have shown that position-based routing are more
adequate for VANETs than other solutions, although they rely on a ”God” location service to asses this
[3].
1
1.2 Objectives and Contributions
This thesis aims to propose a new location service that uses the infrastructure and takes into account
context information to determine the nodes’ position. With this location service it is possible, then, to
assess wether position-based routing coupled with a simple location service that takes advantage of
the physical world conditions provides a better performance than a traditional topology-based routing
protocol.
To achieve this goal, this thesis proposal mainly presents the state-of-the art of two related topics:
routing protocols that have been proposed for VANETs, ranging from adaptation of traditional solutions
to the ones that have been specifically designed for VANET; location services that are targeted to be
used with position-based routing protocols. Based on their analysis a simple location service, usable in
both highway and urban environment is proposed.
In the case of highway environment, it is intended a solution that takes advantage of the infrastructure
present in the field, such as, the Road Side Units (RSU) at entrances and exits of highways, the present
CCTV poles and the fiber backbone that that interconnects them.
In the case of urban environment the target of the study will be the applicability of location service
for managing a fleet of vehicles. For this, it is presumed that RSUs will be used in specific locations and
will be known in advance the route of each vehicle.
1.3 Document Structure
This document describes the research and work developed and it is organized as follows:
• Chapter 1 presents the motivation and the main objectives and contributions expected in this work.
• Chapter 2 describes the previous work in the field concerning routing protocols, location services
and location techniques for the VANET environment.
• Chapter 3 describes the scenarios contextualization, the requirements analysis and the architec-
ture of the proposed solution.
• Chapter 4 describes the implementation strategies, the technologies chosen and how was imple-
mented the proposed solution.
• Chapter 5 describes the evaluation tests performed in order to validate the objectives of this work.
• Chapter 6 summarizes the work developed and future work.
2
2State of the Art
Due to the mobility pattern, nodes’ properties and physical environment VANETs have been considered
a different sub-set of ad-hoc networks, in which most of the existing solutions do not fit well or are not
adequate for all the different uses that can be envisioned. Due to the high mobility of the nodes there is
an high probability of network partitions and end-to-end connectivity is not guaranteed [1]. Hence, there
is a significant research effort in the adaptation of traditional routing solutions or design of new ones to
cope with this challenges. Improving connectivity time using the minimal network resources is the most
important requirement that the new routing proposals must address, as stated in [4].
We start our research in section 2.1 by describing different routing approaches, considering three
main classes of protocols and describing the most suited to this mobile environment in section 2.2.
Position-based routing relies on the use of a location service to identify the nodes’ positions. In
section 2.3 this topic is addressed. Since the vehicles require techniques to obtain its position, section
2.4 is addressed. In section 2.5 it is presented a general discussion about all the themes previously
mentioned.
2.1 Routing protocols
In order to deal with the dynamic nature of mobile nodes it is being made a necessary effort, by the
scientific community, to rethink the routing protocols in order to provide viable solutions for VANETs.
This section addresses the universe of routing protocols for vehicular environments.
Firstly, in section 2.1.1 will be presented a taxonomy for routing protocols. Then in sections 2.1.2,
2.1.3 and 2.2 will be described the different approaches of the different routing protocols.
In section 2.1.5 a comparison of these approaches will be made in order to realize wich of these is a
better solution to deal with the challenges brought by VANETs.
3
2.1.1 Taxonomy of Routing Protocols
The VANETs routing protocols present the taxonomy described in figure 2.1. These protocols can be
mainly divided into three categories: Topology-based protocols, Position-based protocols and Epidemic-
based protocols. In the following sections we will detail each of these categories. On this taxonomy it is
also provided some examples of protocols that follow the approach described above.
Figure 2.1: Taxonomy of Routing Protocols
2.1.2 Topology-based group
The class of topology-based protocols is characterized by using the link information that exist in the
network to perform packet forwarding [5]. These can be divided into three sub-classes: Proactive,
Reactive and Hybrid.
The Proactive approach, also named as Table-driven, refers to protocols that compute and mantain
routing information about all available paths in the background, regardless of communication requests,
even if no data traffic is exchanged. This routing information is maintained constantly updated in a table,
through the exchange of control information amongst the network nodes.
In [6] the authors report that the advantages of using this kind of protocols is based on the fact that
as no route discovery process is done there is low latency, for real-time applications. As a disadvantage,
exists the occupation of a significant portion of the available bandwith with unused paths. Examples
of such protocols are: Fisheye State Routing (FSR) [7], Optimized Link State Routing (OLSR) [8] and
Topology dissemination Based on Reverse-path Forwardinf (TBRPF) [9]
When using the Reactive approach routes to a given destination are determined when they are
needed, this approach is also called On-demand. This operation mode, also referenced in [6], presents
as great advantage the fact of not requiring the periodic flooding the network, being done only when it
is needed. The fact of being beaconless saves bandwidth. However for route finding, latency is high
and the excessive flood in the network may cause disruption of nodes communication. Examples of this
approach are Ad-hoc On-demand Distance Vector (AODV) [10], Dynamic Source Routing (DSR) [11]
4
and Temporally-Ordered Routing Algorithm (TORA) [12].
The hybrid approach arises from the strategy of trying to use the best properties of both approaches
above. For such there are protocols such as Zone Routing Protocol (ZRP) [13], which divides the
network topology into different zones. In this way, routing within a zone is done in a proactive way, and
in reactive way between zones. The use of zones is beneficial since in an ad-hoc network, most of the
traffic is direct to nearby nodes. In this way, according to what is mentioned in [14], the protocol yields
no initial delay for routing among nodes from the same zone and increase system scalability, benefiting
from the best of both approaches. Although there are studies indicating that ZRP performs better than
proactive or reactive protocol [15], the cost of this protocol is increased complexity and in the cases
where ZRP performs slightly better than the pure protocol components, one can speculate whether the
cost of added complexity outweigh the performance improvement. In these studies is also referred that
position-based protocols outperforms the ZRP.
In spite of their differences, the three approaches above rely on the existence of a path that is built
using the nodes that best fit the communication needs between a source and a destination node, at the
setup time. However, in a VANET, since connection information is constantly changing, the best path
is also constantly changing and one can not rely on any existent path to continue linked [5]. There-
fore, Proactive approach will require a huge overhead to maintain the routes, whilst Reactive approach
introduces delay in the route discovery and maintenance processes.
2.1.3 Position-based group
This class of protocols use the geographic position as the most important variable to make the decision
of the next forwarding hop, being this information and the position of the nodes in the neighborhood
contained within the packet.
The position information of the nodes present in the vicinity is extremely useful because with this
information and with the calculation of distance to the destination node and with the knowledge of the
physical constraints of vehicular networks it is possible to take more efficient routing decisions
Thus there is no establishment and maintenance of a route between a certain origin and destiny, as
happens in Topology-based routing algorithms. This property is important given the overhead required
for maintaining the routing tables updated in highly mobile scenarios [16].
In order to use position-based routing protocols, vehicles needs to determine its own position, making
use of techniques explained in the section 2.4 and a location service responsible for determining the
position of the destination node. More information about this class of protocols will be given in section
2.2.
2.1.4 Epidemic Protocols group
A given characteristic of vehicular networks is that a connected path between the source node and
destination node may not always exist. Based on this premiss, it is important to analyse the techniques
that allow to deal with this problematic. For this purpose, the resort to protocols such as epidemic
5
protocols present a solution to ensure the delivery of information, since it even allows the communication
between clusters of nodes.
Figure 2.2: Epidemic routing example
In figure 2.2 , the basic principle of how this class of protocols functions is checked: Assuming that
S wants to send a message to D, the first action to be taken into account is to perform a flooding of
the network with this message, which will be stored in buffers by nodes C1 and C2. These nodes start
to assign themselves as carriers. Assuming that there is a mobility scheme for the nodes, which is a
valid assumption for vehicular networks, there will be a time when one of these carriers will be on the
cluster of the destination node. When this happens, the message will be propagated. In [17], it is verified
that this transitivity in the sending of messages ensures a high probability that the message eventually
reaches its destination.
2.1.5 Comparison and Discussion of the Routing Protocols
As we can depicted in figure 2.1, there are three major options that can be taken in the process of routing
information in a vehicular environment: Topology-based, Position-based and Epidemic Protocols.
However, due to the advantages and disadvantages introduced by each one of them, it is necessary
to study the option that will provide a better solution. Since the epidemic routing is extremely inefficient,
and their techniques are only used to solve problems arising from possible sparsity of the vehicular
network, will be targeted for comparison the two other options. It is verified in many studies [18] [19] [20],
that position-based routing algorithms presents a better solution since those offer better performance in
terms of packet delivery ratio, throughput and end-to-end delay in the different vehicular traffic scenarios.
This is due the adaptability of position-based algorithms when selecting the next hop if an intermediate
node, previously used becomes unavailable, such as the lowest amount of overhead and the absence
of maintenance of routing tables, which causes the reduction in the available bandwidth.
2.2 Position-based routing protocols
Next, a study will be presented with the existing alternatives regarding position-based routing proto-
cols. The following protocols will be described: Greedy Perimeter Stateless Routing (GPSR), Greedy
6
Perimeter Coordination Routing (GPCR), Greedy Perimeter Stateless Routing with Lifetime (GPSR-L),
Improved Greedy Traffic Aware Routing (GyTAR) and Anchor-Based Street and Traffic Aware Routing
(A-STAR).
2.2.1 Greedy Perimeter Stateless Routing
Although this protocol is the most simple amongst the described, it represent the cornerstone in the
evolution of the routing protocols in vehicular networks. The fundamental idea of this protocol is to use
a greedy forwarding strategy [21], in which packets are forwarded to the neighbour node that is closest
to the destination node.
Figure 2.3: Greedy forwarding example. Node A wants to send a packet to node D
Figure 2.3 depicts this strategy in the most simple case. In this example, the node A wants to transmit
a packet to node D. For this, it forwards the packet to the neighbour that is closest to the destiny, node
B. The process is repeated until the destination node is in the neighborhood of a node that receives the
packet (node D is a neighbour of node C).
However, in certain cases there is no other node closest to the destination than the node that just
received the packet. Under this circunstance, a Local Maximum occurred and the node must use another
strategy to forward the packet. GPSR decides the next hop using the right hand rule
Figure 2.4: Local maximum situation
7
As stated in figure 2.4, this rule states that when the arriving node A from node B the next edge
traversed is the next one sequentially counterclockwise about A from edge (A,B). The greedy forwarding
is recovered again when the forwarding node is closer than the one that began all the process.
2.2.2 Greedy Perimeter Coordination Routing
To address the impact of urban environments, amongst them the blockage of the radio signal on the
obstacles present in intersections, it was proposed the GPCR [22]. The main ideia behind the GPCR
is based on using the present vehicles in the middle of the intersections as special nodes, named as
coordinators, with the function of forwarding the packages in an efficient way. In figure 2.5 is shown an
example of how the next hop is selected on a street with this notion of coordinators: Node A receives a
packet from node B. Because A is located on a street and not on a junction it should forward the packet
along this street. Firstly the qualified neighbors of A are determined. Then it is checked wheter at least
one of them is a coordinator. As in this example there are three coordinator nodes and one of these
coordinators nodes is choosen randomly and the packet will be forwarded to this coordinator. Once the
package has arrived to the coordinator, greedy forwarding strategy will be used again like GPSR. GPCR
uses a greedy forwarding strategy and recovery with the choice of the right hand rule, differing only in
architectural terms with this notion of coordinator nodes restricting the packet forwarding.
Figure 2.5: Local maximum situation
2.2.3 Greedy Perimeter Stateless Routing with Lifetime
Regarding GPSR-L [23], there is a GPSR improvement to deal with situations in which due to a low
signal quality or an intense mobility scenery, a given node selects a neighbor that no longer exists when
in reality it remains present in its coverage area. To solve those problems the concept of lifetime was
introduced. The lifetime represents the quantity of time that a certain node exist and is calculated using
the difference of distances between the nodes computed with the information of two consecutive Hello
Messages. Disassociating the Hello timer with the lifetime, a node only disappears when two premisses
are fulfilled: the node has expired the time that should receive the message and expire its lifetime. So, it
8
is possible to perceive that the best nodes to choose are those that have a longer lifetime, performing a
more efficient forwarding.
2.2.4 Improved Greedy Traffic Aware Routing
Unlike the protocols aforementioned, the Improved Greedy Traffic Aware Routing [24] uses as key help
a physical infrastructure in a way to maintain the connectivity between the nodes. For such, access
points are placed at intersections that bridge the problems that came from the urban environments.
Therefore, we can reduce the overhead of control messages, the end-to-end delay be smaller and with
a low packet lost ratio. Relatively to the forwarding strategy, the packets are forwarded in a greedy way
between intersections.
In each intersection it is calculated from a score the next better crossing, having in attention the traffic
density, given by the Road Side Units, and the distance until the next crossing. The fact of depending
on the Road Side Units became less attractive than the previous due to financial costs in building the
infrastructure that support the same in the field.
2.2.5 Anchor-Based Street and Traffic Aware Routing
The routing scheme from the A-STAR was drawn to deal with intervehicular communication systems in
urban scenarios. This scheme results in a fusion of two concepts which are the Anchor-based Routing
and the Spatial Aware Routing. The Anchor based routing is based in the inclusion of vectors routes,
compose by anchors (fixed geographic points) in which the nodes should use in the data packages.
The Spatial aware routing consist in the idea of including the data in the spatial information, such as
maps or descriptions, in order to make routing decisions that are aware of the existing obstacles in the
scenario. This fusion of concepts coupled with the use of the number of buses that pass a given bus line
as the metric for calculating the weight from the Dijkstra algorithm selection path, and using a greedy
forwarding policy along these anchors, leads to this protocol with more satisfactory results compared
with protocols such as GPSR, when the scenario relates to an urban area.
2.2.6 Comparison and Discussion
Amongst the protocols described, it was verified that both GyTAR and A-STAR require an infrastructure
to operate. This represents a weakness which reduces the scope for this type of networks.
The GPCR requires an election of a coordinator node, to solve the problem associated with inter-
sections in an urban environment. In highway, this requirement will lead to entrances and exits being
considered as intersections and allied to the speed of vehicles in this environment, this protocol will
probably have a lot of packet drop and congestion near intersections.
The choice lies between the two more generic protocols: GPSR and GPSR-L.
Given that the main focus of this work resides on the development of a location service, the most
simple and generic routing protocol of the two was chosen. Thus, GPSR presents itself as the best
candidate for implementation in the scope of this work.
9
2.3 Location Services
In the following section, the theme of location services will be discussed. Firstly, these services will be
categorized within a taxonomy. Then, some examples on these types of services will be presented,
finalizing with a comparison of the several advantages and disadvantages between them.
2.3.1 Taxonomy of Location Services
As can be seen in figure 2.6, in the first instance we can divide them into flooding-based, consisting
on an approach where a flood in the network whenever it is necessary find a destination node and
Rendezvous-based, where all the nodes (potential senders or receivers) in the network agree upon a
mapping that maps each nodes unique identifier to one or more other nodes in the network. These
mapped-nodes are the location services for that node and they will be the rendezvous nodes where
periodical location updates will be stored and location queries will be looked up.
Figure 2.6: Taxonomy of Location Services
The flooding-based approach can be divided into two different modes of operation. In an proactive
mode each destination node periodically floods its location to other nodes in the network, each of wich
maintains a location table recording the most recent locations of other nodes. On the other hand, in a
reactive mode, there is a flood scoped query in the network in search of the destination node only if a
node cannot find the recent location of it.
In the rendezvous approach, it can be made from the use of a quorum-based mechanism or a
hashing-based mechanism. In the first mechanism referred, each location update of a node is sent to
an explicit defined subset (update quorum) of available nodes, and a location query for that node is
sent to a pottentially different subset (query quorum). These two subsets are designed such that their
intersection is non-empty, and thus the query will be satisfied by some node in the update quorum. In
the hashing-based mechanism, location servers are chosen via a hashing function, either in the node
10
identifier space or in the location space. This mechanism can be done in a flat way or in a hierarchical
way depending on whether a hierarchy of recursively defined subareas are used or not.
Next will be described three location services, one reactive and the other two hierarchical. The proac-
tive location services were left out of this work due to its significant bandwith occupation with overhead
of useless information and the fact that they have serious problems of scalability, and the quorum-based
location services since maintain quorums is difficult when the clusters are always breaking due to node
mobility.
2.3.2 Reactive Location Service
The Reactive Location Service (RLS) [25] is a location service flooding-based of reactive nature, it just
makes inquires position of another node in an on-demand fashion. In RLS, when one node needs the
location of another node, and if it does not have this information in the location table for not knowing
or simply because the information has been expired, sends a location request packet to the nodes in
its neighborhood, asking for that location information, limited to a certain time-out period. This location
request packet contains the full route that the location reply packet should be able to transverse in its
header.
This situation can happen in one of two cases: or nodes have the knowledge in its neighborhood or
they do not have. If its neighborhood is aware, this information is returned from the nodes that have the
information on their location tables. If they do not know, it is triggered a flood mechanism throughout
the network by interrogating the geographic position of the target node until it reaches the destination or
until the TTL expires.
If this information is known for some node in the network, is answered with a location reply packet
via the reverse source route obtained in the location request packet. Otherwise, RLS assumes that has
been reached a state of unreachability which may be due to a network partitioning, being the node in a
different unreachable network partition, an inactive state of the node, if it does not exist or is temporarily
deactivated, or else the node be located at a distance so high which is not possible in a maximum TTL
to reach the destination node.
2.3.3 Grid Location Service
The Grid Location Service (GLS)[26] consists in a location service that provides the position of a certain
node, constructed in order to have a number of location services distributed throughout the network.
This network is represented in a form of hierarchical grids with squares of increasing size, represented
by orders. The smaller squares represent order-1 squares. Four squares order-1, represents one order-
2 square, four order-2 squares represent one order-3 square and so on. This scheme of squares is
represented by color scheme described in figure 2.7
In GLS, there are 3 main activities: location server selection, location query request and location
server update. The location server selection phase is triggered whenever a certain node intends to
distribute its location information, composed by node ID. This ID is assigned in an unique way and
11
randomly to each node, by applying a strong hash function to the nodes unique name. A node chooses
its location servers by selecting a set of nodes with IDs close to its own ID. In order to clarify the mode
of operation of this phase, it is shown an example in figure 2.7.
Figure 2.7: A Grid Location Service example
In this example, taken from [27], B (ID 17) determines which nodes will be its location servers by
selecting nodes with IDs closest to its own. A node is defined as closest to B when it has the least ID
greater than B. For example, consider the grid to the left of Bs grid. No ID exists that is greater than 17.
Since the ID space is considered to be circular (i.e wraps around), 2 is defined as closer to 17 than 7. B
selects three location servers for each level of grid order square. For example, in figure 2.7, B selects
one location server from each order-1 square (e.g 2, 23 and 63) that, along with its own order-1 square,
will make an order-2 square (e.g 26, 31 and 43) that, along with its own order-2 square, will make an
order-3 square. Each of the chosen location servers have the least ID greater than B in that square.
The location query request phase is triggered whenever it is necessary to perform a query to find
one location server. For this to happen is taken the following decision rule: The location query request
is forwarded, using geographic forwarding, to a node whose ID is the least greater than equal to the ID
of the destination within the order-2 square. The same algorihm is applied until it reaches a location
server for the destination. Once more to a completely understand the operating mode figure 2.7 is used
as example. If A wants to reach B, A sends a location query to node with ID 21.
Since no node with IDs between 17 and 21 exists in A’s order-2 square, node 21 forwards the query
packet using the same algorithm to the node in the next order square in the grid hierarchy, which is ID 20
in this example. Since node 20 is a location server for B in that grid order square , it knows Bs location
and is able to forward the query packet directly to B. Since the query packet contains As location, B
responds by sending its current location to A using geographic forwarding.
12
2.3.4 Hierarchical Location Service
The Hierarchical Location Service (HLS)[28] is a location-based service of the same origin as the GLS,
being similar in some ways. The HLS covers the entire area network via a scheme of hierarchy of
regions. These regions can be sub-divided, giving the name of cell to the lower sub-network partition.
In figure 2.8 it can be verified this allocation of levels of hierarchies. This allocation however follows
two basic principles: Regions of higher level n are constructed from aggregating regions of lower level
n-1 and regions of the same hierarchical level n can never overlap.
Figure 2.8: HLS cells
For the HLS operation mode, to each node is assigned a cell responsible for each hierarchical level
from the criterion of a hash function that takes as input the data node ID, the hierarchy level and the
node position. If a node is moving, it will perform the update in their responsible cells with their position
information.
This update can be done in two different methods: For the direct method, the node updates the
responsible cells for the first level of its position information that can contain more than one location
server. If instead of the direct method was used the indirect method, in order to reduce traffic, responsible
cells N-1 sends the location information to the cells of higher level N. In this way, we see that there is
only one local traffic congestion at the first level, not replicated to the other levels because only a few
multi-hop long distance packets are sent to the top levels.
When at some point another node needs to communicate with this, uses the hash function to de-
termine the potential cells that can be responsible for target node. It then performs a query phase, by
hierarchical order of the cells. There is a response from the node when both are in the same hierarchical
area.
In order to exemplify this operation mode is presented figure 2.9. As we can see, first-level updates
are performed locally, being the remaining updates to level n+1 cells your sole responsability. The
request phase is done to the responsible cells from which respond directly to the node which triggered
the entire process.
13
Figure 2.9: HLS network partition
2.3.5 Comparison and Discussion of the Location Services
As mentioned in previous sections, existing protocols for location services fall into two categories:
flooding-based and rendezvous-based. Although they are two alternatives for the vehicular universe,
in [29] the authors binding that the flooding-based protocols are not suitable since that in its proactively
mode it introduced much overhead of useless location information. If the reactive mode is used, it is
introduced latency, not suitable in VANETs. From a scalability point of view, in addition to the above
arguments, the authors in [30] reinforce that this option is not suitable since this kind of protocols scale
poorly with the network size. Therefore, the choice of an option for location service protocol falls in
rendezvous-based paradigm, since it provides a more scalable solution.
The rendezvous paradigm offers two different approaches: Quorum-based and Hierarchical-based.
From a comparative viewpoint, authors in [31] argue that the quorum-based protocols are unsuitable for
large size VANET, due to lack of network expandability, caused by the trade-off between the number of
quorums and the robustness of the location service.
Therefore, the most efficient solution falls into the hierarchical-based location service. Despite be
referenced as the best alternative, still presents some drawbacks because if mobility is high, location
update/lookup failure is increased [31].
Within the range of those services were highlighted GLS and HLS. From the study conducted by the
authors in [29], it is verified that the HLS has a better performance both in the metric of Query Success
Rate, but also incurs in less overhead and in the metric of Request Travel Time.
However, all of this location services do not explore the existing conditions on the vehicular environ-
ment, in particular the characteristics of the physical infrastructure. Taking advantage of it could reduce
the complexity of the location service and offer a service with low overhead and rapid to answer to
location requests.
14
2.4 Location techniques
In order for the routing protocols previously described to work, it is necessary to know the position of
vehicles involved in this process. For this it is necessary to use techniques which allow to obtain the
position of the own node, as it is necessary to use systems that enable a global knowledge of the node’s
position along the network, making vehicles tracking and responding efficiently to location queries made
by the nodes.
In the following subsections will be analyzed both techniques for obtaining the position of the node,
as existing location services, followed by the relevant comparison between them.
So that location services can be implemented, it is necessary to use techniques that can compute
the nodes position in the veicular network. For this it is of interest to analyze the whole range of existing
techniques, described in [32].
2.4.1 Global Positioning System
The Global Positioning System(GPS) is composed of 24 satellites that operate in Earth’s orbit. Each
sattelite circles the Earth at a height of 20.200km and makes two complete rotations every day. The
orbits have been defined in such a way that each region of the earth can ”see” at least four satellites in
the sky. It is the most used technique location with regard to know the current position of a given node.
For this technique it is necessary to install a GPS receiver in order to receive the information sent by
the satellites (at least four), estimating the distance constantly going from receiver to the satellites using
a technique called Time to Arrival (TOA). Therefore, it is then possible to compute the position of the
node using trilateration. Despite being the technique that best expresses the position of a vehicle, its
characteristics lead to many unwanted problems such as not being able to always be available or may
not be robust enough for certain critical VANET applications. The error associated with the location from
10 to 30 meters also not contribute to such applications.To bridge these flaws there is an effort of two
parts: On one hand to improve the GPS using Differential GPS (DGPS) which consists of installing GPS
receivers at known fixed positions and which fix the position error of GPS receivers of vehicles and on
the other hand combining with spatial information given by other techniques.
2.4.2 Map Matching
Although it is not a by itself technique, the recent advances made by the Geographic Information Sys-
tems that concern all the data collection procedures and data storage, make this technique valuable
when it is used in conjunction with others, due to its high precision geographic information. An example
of this wraps itself with the fusion of this technique and the use of a GPS, restricting the vehicles to roads
and diminishing the errors arising from de GPS data.
15
2.4.3 Dead Reckoning
The Dead Reckoning consists mainly in using the last known position acquired from the GPS in a more
frequent manner or from specific tracking systems for that particular scenario (parking lots, road cross-
ing, amongst others) and to estimate the position in which the vehicle is found through information like
direction, speed, acceleration, distance, time, and others. This technique can only be used during small
periods of time when the GPS information is not available due to the fact that Dead Reckoing accumu-
lates errors very fast along time and distance. Being this said it is only used as a backup technique.
Examples of its use can be found when for example we go through a tunnel and there is an obstruction
of the GPS signal.
2.4.4 Cellular Localization
In the matter of the location, it consists on using the existing cellular infrastructure as a way of locating
the vehicles, just like a mobile phone. For this, are used techniques like the Received Signal Strength
Indicator (RSSI), where the strength of the signal is analyzed to determine the distance between the
mobile device and the base station. Besides the RSSI, we can also use techniques like the Time of
Arrival (ToA), which is based on the amount of time that the signal of a device takes to reach the base
station, and the Time Difference of Arrival (TDoA), which is based on the difference of time that the signal
takes to reach multiple base stations. These already stated techniques use concepts of trilateration and
multilateration where tree or more signals are analyzed to determine the position of the mobile device.
There are alternatives to this techniques like the Angle of Arrival (AoA), where the angle in which the
signal reaches the base station is analyzed. For that it is necessary the use of directional antennas
or arrays of directional antennas by the base stations and the analysis of tree different signals in order
to compute the the signals origin position. The cellular location, dispute being less accurate than the
GPS’s (errors between 90 and 250 meters) and vulnerable to factors like environmental, number of base
stations, amongst others; is extremely useful when used as an information source by other techniques.
2.4.5 Image and Video Processing
The Image and Video processing, is one of the other possible techniques that can be used when it
comes to localization. This technique uses as its information source video surveillance systems from
high-ways and parking lots. It is typically not used by itself, but as a data source that contributes with
other techniques, because its great strength relates to the estimation of physical parameters of the
vehicle and not as a locating system itself.
2.4.6 Localization Services
Despite the GPS being the best technique to identify a vehicle’s position, in certain cases like tunnels
or parking garages it is ineffective. To bridge that flaw, communication infrastructures are sometimes
16
installed to provide location services restricted to that environment in order to keep the vehicle’s tracking.
As examples of this kind of location services we have WI-FI, RADAR and Ultra-Wideband.
2.4.7 Ad-hoc Localization
The location in ad-hoc networks consists on building relative position maps from the node position
through the analysis of the distances and exchange of information in a multi-hop communication style.
This way, despite the vehicle’s location is not certain, it has a relative notion that suits these kind of
networks. When more details are needed, a GPS hybrid schematic is used though only a few nodes
need that kind of detailed information.
All these techniques tend to have an associated type of data fusion, that allows to merge the different
techniques, leading to relatively precise locations about the position of vehicles on the roads.
2.4.8 Discussion of the Location Techniques
The position-based routing protocols require that vehicles come equipped with mechanisms to obtain
the location of the vehicle. Typically the most widely used mechanism is GPS. However the GPS can
be erroneous and are unavailable in a number of situations and it is important to the study of other
complementary techniques to assist in obtaining the position.
For this to be possible, as described by the authors in [32], the future localization systems will need to
use data fusion models in order to compute accurate positions based on the higher number of relatively
inaccurate positions estimations.
2.5 Discussion and Comparison
According to the characteristics listed in 2.1.3, it can be noted that the position-based protocols repre-
sent the most appropriate choice for the vehicular environment amongst these, in section 2.1.5 some of
these protocols have been described. Since it is not good pratice to use different protocols for different
scenarios and since GPSR is the most generic protocol, as was mentioned in 2.2.6, it is a good candi-
date for the implementation of a routing protocol. Regarding the location service, it was demonstrated
in the previous sections that the various solutions arise problems not acceptable for a VANET environ-
ment because they do not take advantage of the existing conditions of the physical world, such as the
infrastructure. Thus, developing a location service that takes advantage of this infrastructure will offer a
better solution. This will lower the overhead, provide better scalability and improve performance. To test
this improvement in scalability and compare it with other solutions there is a need to test the solution in
simulation environment.
17
3Architecture
This chapter describes the vehicular network architecture and service location protocol that supports
this work. Following a top-down approach, the vehicular context is characterized in section 3.1; then, in
section 3.2 location service requirements are presented; After this, section 3.3 overviews the proposed
location service and a more detailed description can be found in section 3.4 and section 3.5; a complete
application example is described in section 3.6 and, lastly, in section 3.7, there is a synthesis of all points
addressed in the chapter.
3.1 Characterization of Vehicular Context
Before the development of a location service that takes advantage of the vehicular environment, it mat-
ters to survey the physical characteristics that can be exploited.
There are two major VANETs scenarios - urban and highway - that lead to different challenges when
concerning the design of services and protocols, specially targeted for these networks.
The urban environment is characterized by having many roads, streets and avenues, with many
junctions, intersections and roundabouts. This means that each vehicle has many option to follow and
it is not easy to predict the path that will be used to a destination. Vehicle speed is usually low in
town and villages, limited to 50 km/h or even lower depending on the country’s legislation. Vehicular
traffic has a daily pattern, with a dense network of vehicles at rush hours and sparse networks in less
used periods of the day. There are also a significant number of fixed devices, located at traffic lights
and bus stops, that, if properly equipped, may be part of the data network. Given the high number
of crossovers, buildings, obstacles and vehicles, the signal propagation will be affected by phenomena
such as blocking, shadowing, reflection and multi-path propagation, causing significant packet loss[33].
All these environmental factors contribute to what is a challenging communication scenario.
For the highway environment, it can be said that it is simpler if we compare the mobility and obstacles,
18
the mobility options are limited and the quantity of obstacles is reduced. The challenging factor in
highways resides, essentially, in the variation of the speed and the speed that vehicles can reach.
Therefore, it is possible to draw the following metrics presented in table 3.1.
Group Property Urban HighwayScenario Obstacle Many Few
Mobility Pattern Amount of options Many Few
Mobility PropertiesSpeed Low High
Speed Variance High LowNode density High Low
Table 3.1: VANET Scenarios comparison
3.1.1 Urban Environment
On the urban environment, several communication infrastructures are already deployed, either to sup-
port public mobile operators or to support private services, such as the ones provided by fleet transporta-
tion companies that need to monitorize their vehicles in order to optimise resources, improve services
offered to their costumers and reduce operating costs.
Fleet transportation system infrastructure is typically composed of embedded terminals inside the
vehicles that are connected to a set of Base Stations spread throughout the ground using TETRA tech-
nology [34]. This technology is an ETSI standard for radio networks with shared resources that requires
less BSS to provide the same coverage as GSM, transmits faster and offers several different encryption
modes, group calls, device authentication, amongst other features. These BSS are connected to the
CORE network of the company that manages the operation, so that they can be remotely controlled and
monitored.
Figure 3.1: Representation of an Urban Communication Network Infrastructure
Additionally, this CORE Network can be interconnected with a Network Operator in order to use
their mobile network services to reach the information terminals. An example of the usage of this entire
19
system is SAEIP, implemented by TECMIC in the context of the management of Carris’ company fleet.
3.1.2 Highway Environment
Regarding the highway environment, there is an advanced communications infrastructure used by au-
tomatic toll systems and monitoring systems to identify hazardous situations, detecting accidents and
providing road users with useful informations about road traffic conditions. This infrastructure is typically
composed of a fibber optic backbone that interconnects different components, such as video surveil-
lance cameras, sensors, Electronic Toll Collection (ETC), Variable Message Sign (VMS) and emergency
systems (SOS). All this information is gathered and centralized at an Operations Coordination Center
(OCC), which performs management tasks on all highways. Additionally, there is the growing incorpo-
ration of RSUs to the infrastructure. These infrastructure points are the equivalent of access points in
traditional ad-hoc networks and are placed at precise spaced distance through out the road in order to
provide the infrastructure support for network setup and communications (either I2I or V2I). The Por-
tuguese highway ”A5” is an perfect example of an infrastructure identical to the one that was described
[35].
Regarding the vehicles, manufacturers are making increasingly larger efforts to ensure that vehicles
have Embedded On-Board Units (OBU) in order to enable communication either with other vehicles or
with infrastructure’s devices. These OBUs consist, typically, of an Event Data Recorder (EDR), a Global
Positioning System (GPS), forward and backward radars, computing facility and a short range wireless
interface [36].
Figure 3.2: Representation of a Highway Communication Network Infrastructure
20
3.1.3 Analysis and comparison
All these elements described above lead to the conception of a VANET physical infrastructure, either for
highway or urban scenarios, such as the one exemplified on figure 3.3.
The proposed network is an infrastructured VANET, where vehicles equipped with OBUs, communi-
cate with Road Side Units (RSUs), placed at strategic places, namely the ones that are currently used
by existing systems, such as highway entrances and exits, CCTV poles, and traffic lights or bus stops,
in a city.
((a)) Highway VANET Architecture ((b)) Urban VANET Architecture
Figure 3.3: VANET Complete Architecture
3.2 Requirements Analysis
The vehicular architecture described above was idealized with the idea of a location service that max-
imizes the features present in the vehicular scenario. Thus, these are the following requirements that
must be taken into consideration.
• Simplicity - The location service must be as simple as possible in order to allow a fast adaptation
to the environment’s dynamics without using a significant amount of resources or realizing complex
operations.
• Accuracy - Since the position is a key feature for position-based routing protocols, an accurate
prediction scheme must be used in order to cope with the vehicles mobility. Hence, context and
historical information might be used to improve the accuracy of prediction.
• Performance - The location service must have a good performance, meaning that both overhead
and latency of location discovery must be small.
The design of a simple location service is a key issue for its dissemination and usage. Generic loca-
tion services are usually complex, as they do not take into account the physical infrastructure to properly
support the service. RSUs may keep information of the position of vehicles in the neighbourhood and
communicate this information upon request.
The accuracy requirement can be obtained using the context information delegated by vehicles to
infrastructure. In this way, there is a widespread knowledge by location service about the vehicle’s
position, being possible to relate them to the environment context information, including their operational
21
characteristics such as the existence of curves, speed bumps, intersections or other things that might
affect the prediction of the vehicles position.
In terms of performance, the lowest load on the network and the faster vehicular communication
given the need for less hops from increased range RSUs are the fundamental characteristics leading to
the improvement of routing protocol as well the location service itself.
In addition to these requirements, is also considered important the security requirement, being guar-
anteed the properties of confidentiality, authenticity and integrity on the exchange of messages with the
location service. However, in the context of this thesis, it was relegated to future work.
3.3 SILOS General Overview
Figure 3.13 depicts a general overview of the physical infrastructure used to support the SImple LOcation
Service (SILOS).
In general, this location service is characterized by the use of the physical infrastructure present in
the vehicular environment, in order to assist in the process of obtaining the vehicles positions.
Hence, vehicles equipped with OBUs are aware of the presence of a physical communications in-
frastructure which records their positions whenever they are within range of an RSU. Thus, whenever
there is a need to get the position of a destination node, vehicles can simple obtain it by the triggering of
a location request to the infrastructure, which will respond with a prediction of the node’s location, based
on the context information delegated by the vehicles.
Figure 3.4: SILOS Conceptual Overview
Each OBU is the main responsible for:
• Generate and receive location requests from RSUs, whenever there is data to sent to an unknown
destination.
• Forward location requests through the vehicular network, extending the coverage range of the
network.
As secondary responsibilities, it is required from each OBU to:
• Periodically send its position and speed, in order to always be known in its neighbourihood.
22
• Perform its registration in the closest RSU, so that it can answer to location requests.
From RSUs, the same have the primary responsibility of:
• Maintaining the information about the vehicles position updated.
• Periodically send its position to OBUs so that they can perceive in which RSU it is allocated.
• Removing outdated records.
As secondary responsibilities, RSUs need to:
• Locate all OBUs that are in it’s area range or those that have been and have not yet moved to
another, within a certain temporal limit.
• Respond to location requests from OBUs that are assigned to them.
• Respond to location requests from the others RSUs about location information from assigned
OBUs.
• Forward location requests to other RSUs if the request is not intended to itself.
3.4 Components Architecture
SILOS depends on the behavior of both OBUs and RSUs. The next section describes the functional
architecture of both of these components.
3.4.1 OBU Functional Architecture
Figure 3.5 depicts the functional architecture of an OBU, where the main functions are grouped ac-
cording to the Internet protocol stack. As stated in the figure, SILOS works at the network layer, in
cooperation with a location-based routing protocol, such as GPSR.
At the top level, application layer, a set of vehicular applications will be provided, comprising safety,
comfort or convenience data, which is encapsulated and transmited through the use of a transport layer
protocol. For the majority of cases, messages are encapsulated in UDP datagrams, as UDP is more
suitable for vehicular reality [37]
The network layer comprises location management, data forwarding and routing. The first one is
performed by Location Service Module and the others two by the GPSR routing protocol.
The Location Service Module generates Location requests, upon reception of a packet to an unknown
destination (e.g. without a valid entry at the Neighbor Table); receives Location replies, containing the
answer to a previous request; and updates a node’s location whenever it receives a Location update
message. Request messages are sent to the nearest RSU, which delegates the answer to the RSU
responsible for that particular destination node. As soon as the location reply is received, communication
is then able to proceed. Whenever a reply or update is received from an RSU, the corresponding entry
at the Position table is updated.
23
Figure 3.5: OBU Operation Model
3.4.2 RSU Functional Architecture
Regarding the RSUs, they have a functional architecture similar to figure 3.6. As can be seen, the main
difference is related to the fact that, in our architecture RSUs acts only as routers, as they are not used
to support applications.
Figure 3.6: RSU Operation Model
The main difference lies on the functionalities that are needed at the Location Service Module, to
implement the RSU -side of the SILOS protocol, namely: the OBU registration and position prediction,
the reception and answer to incoming location requests; the delegation of location replies to other RSUs,
when the request is out of scope of the current RSU.
24
3.5 SILOS Protocol
As it was already described, the main components comprising SILOS will be given, in this section, a
more detailed description about how they interconnect with each other. To this end, each of the phases
will be described.
SILOS protocol mainly consists in three of different phases: The RegistryEntry Phase, responsible
for the delegation of vehicle’s information to the infrastructure; the PositionQuery Phase, responsible
for obtaining the vehicles’s position and the RemoveEntry Phase, responsible for deletion of outdated
location records.
In Algorithm 1 and 2 presents respectively how these stages are interconnected whether is an OBU
or a RSU.
Algorithm 1 SILOS overview: RSU1: function WAITFOREVENT(event)2: if event == Recv L2(packet) then3: theader ← packet.RemoveHeader()4: IP ← packet.RemoveID()5: Position← packet.RemovePosition()6: Speed← packet.RemoveSpeed()7: IPquery ← packet.RemoveQuery()8: if (theader == ”Hello” —— theader == ”LocationUpdate”) then9: RegistryEntry(IP, Position, theader)
10: else if theader == ”LocationQuery” then11: PositionQuery(IP, Position, IPquery, Speed)12: end if13: else if event == timeout then14: RemoveEntry(timer)15: end if16: end function
Algorithm 2 SILOS overview: OBU1: function WAITFOREVENT(event)2: if event == Recv L2(packet) then3: theader ← packet.RemoveHeader()4: IP ← packet.RemoveID()5: Position← packet.RemovePosition()6: PredictedPosition← packet.RemoveReplyPosition()7: if theader == ”Hello” —— theader == ”LocationUpdate” then8: RegistryEntry(IP, Position, theader)9: else if theader == ”LocationReply” then
10: PositionQuery(IP, PredictedPosition)11: end if12: else if event == timeout then13: RemoveEntry(timer)14: end if15: end function
25
3.5.1 Registry Entry Phase
In the RegistryEntry phase, nodes first announce their presence to their neighbourhood with routing
periodic Hello messages with the following fields: Node IP and Position. The mechanism that triggers
this messages is described in Algorithm 3.
Algorithm 3 Position-based routing: OBU Hello Message generation1: function HELLOTIMEEXPIRE(socket)2: if timeout.expire() then3: SendHello()4: end if5: end function
Whenever a RSU or a OBU receive one of these Hello messages, it updates its Neighbors and
Location Tables with this information. If this message is received by a RSU, an additional Location Hello
message will be sent, advertising itself and indicating its position and querying the vehicles’ speed. Once
the OBU receives this message, it will identify the sender as a RSU and record the RSU’s identification
and position. From this moment on, the vehicle knows which RSU is responsible for the location requests
and what its position is. From now on, the OBU is able to communicate with the RSU, either to send its
own information or to query about others.
The next step consists on returning a message informing about the OBU more updated position and
current speed, as requested. Once the RSU receives this information, it may predict the path and, when
questioned about the position of the vehicle, reply with a more accurate prediction of its position. From
this moment on, this RSU has full knowledge of the node and it is ready to answer location requests.
As vehicle move, it becomes out of the coverage range of the RSU where it initially registered. Hence,
if an handover occur, OBU information is deleted at the old RSU and registered at the new one so that
only one RSU has its current position, avoiding wrong duplication about OBU’s information.
The pseudo-code representation of registration phase of both OBUs and RSU are depicted next, in
Algorithms 4 and 5.
Algorithm 4 SILOS Registry entry phase: RSU1: function REGISTRYENTRY(IP, Position, theader, Speed)2: if theader == ”Hello” then3: locationService→ AddEntry(IP, Position, T imer)4: neighborsTable.AddEntry(IP, Position)5: locationService→ SendLocationHello(IP, Position)6: elsetheader == ”LocationUpdate”7: locationService→ UpdateEntry(IP, Position, Speed, T imer)8: end if9: end function
26
Algorithm 5 SILOS Registry entry phase: OBU1: function REGISTRYENTRY(IP,Position, theader)2: if theader == ”Hello” then3: locationService→ AddEntry(IP, Position)4: neighborsTable.AddEntry(IP, Position)5: else if theader == ”LocationHello” then6: myRSU ← IP7: mypositionRSU ← Position8: locationService→ SendLocationUpdate(myID,myPosition,mySpeed)9: end if
10: end function
3.5.2 Position Query Phase
The PositionQuery phase will be triggered whenever a vehicle needs to know the location of a destination
node. For that, it first queries its own location service module about its knowledge about the desired
position.
If the position is valid, it will be returned, otherwise a location query message is sent to the nearest
RSU by the location service module.
When the RSU receives this query, two situations can occur: or the RSU has knowledge about the
request position, or it has not. If it has the vehicle’s position, a location request is sent immediately
containing a prediction of its position. This prediction is based on a combination between the last known
position of the vehicle allied to the speed provided in that temporal instant, given by the following formula:
PredictedPosition(ti) = Position(T ) + ((ti − T ) ∗ Speed)
where, T = Instant of time of the last measurement
When there are cases when an invalid position is returned by the Location Service, packets are stored
and tagged in a RequestQueue which is periodically reviewed to check if any packet has information to
answer the pending requests. Additionally, it is triggered by a RSU a request to adjacent RSUs about
their knowledge of the node. If they contain no knowledge about it, this process is repeated from their
adjacent until ot reaches one with knowledge of the desired position.
When the RSU finally receives this information, after it calculates its prediction with this data, it
will send it to the requesting OBU with a location reply message. This position is then stored in its
LocationTable and when it wants to communicate, it already has all the position information about the
destination node.
Algorithm 6 elucidates the processing of location query messages from the RSU. It is clear that the
three situations described above may result from this process.
With regard to algorithm 7, it is described how its process of prediction based on information present
in the Location Table is formed.
In the algorithm 8 it is illustrated the processing done whenever a reply message is received by an
OBU.
27
Algorithm 6 SILOS Position Entry Phase: RSU1: function POSITIONQUERY(IP , Position, IPquery)2: PredictedPosition← (LocationService→ Predict(IPquery))3: if PredictedPosition == invalidPosition then4: LocationService→ RSUSearch(IPquery)5: else6: LocationService→ SendReply(IP, PredictedPosition)7: end if8: end function
Algorithm 7 Prediction Calculation Pseudo-Code from RSU1: function PREDICT(IPquery)2: oldpos← LocationTable.GetPosition()3: if oldpos == InvalidPosition then4: return InvalidPosition5: else6: oldtime← LocationTable.GetT ime()7: newTime← Simulator.GetT ime()8: deltaT ime← newTime− oldT ime9: speed← LocationTable.GetSpeed()
10: predictPosition← oldpos+ (deltaT ime ∗ speed)11: return predictPosition12: end if13: end function
Algorithm 8 SILOS Position Entry Phase: OBU1: function POSITIONQUERY(IP , Position)2: LocationService→ AddEntry(IP, Position)3: end function
3.5.3 Remove Entry Phase
The RemoveEntry phase will always take place when the lifetime of the location table entry expires. If
this happens, the whole process of obtaining the position of a destination node is again executed. This
phenomena takes place due to the great mobility of the nodes, which lose their positions and validity
very quickly.
3.6 Application Scenario
In order to illustrate the behaviour of the SILOS Protocol, an application scenario will be presented on
Figure 3.16. In this scenario, 2 OBUs in different instant times and 3 RSUs spread out sequentially
through out the highway are identifiable.
In the first instance, we can easily verify the management process mentioned earlier. Like so, the
vehicle sends periodical Hello messages, which originate requests from the RSUs to the OBUs. The
OBUs responds to the messages with context informations. These informations are only present in one
RSU’s table, avoiding the duplication of information.
In the second instance, the position obtaining process by the vehicle 2 from the vehicle 1 is pre-
sented. For this to happen, it reaches out to the RSU within reach. Given that this RSU does not has
28
the information because the vehicle moved away, it enquires the adjacent RSUs in order to obtain the
required position (in this case, the vehicle 2’s position).
When the RSU gathers this knowledge, it sends the position back to the vehicle, making possible to
establish a connection between both vehicles.
Figure 3.7: Diagram of the SILOS Protocol
29
3.7 Synthesis
In this chapter it was described the architecture that supports the SILOS location service proposed in
this thesis.
For this purpose, the vehicular context was first analysed considering both urban and highway sce-
narios. Based on this analysis, three important requirements of the location service have been identified:
simplicity, accuracy and performance. In order to satisfy these requirements a new location service was
proposed that uses the fixed infrastructure to provide context-awareness and create a simpler solution
with a fairly performance.
The chapter comprises a description of both RSU and OBU functionalities and components, as well
as the location service protocol specification. For this, a detailed algorithm presentation containing the
three phases of the protocol have been presented.
A final example has been presented, describing a complete application use case.
30
4Implementation
This chapter will address the main decisions adopted in what concerns the implementation of the pro-
posed location service (SILOS). First it will be given a description of the possible implementation strate-
gies that could be adopted in section 4.1. Then in section 4.2 , it will be indicated which of the strategies
was chosen and the reason for its choice. In sections 4.3 models will be presented and implemented
and then in section 4.4 will be described how they were implemented. In Section 4.5 functional tests
were performed in order to assess the operation of the protocol. Finally, in Section 4.6, a brief summary
of this chapter will be presented.
4.1 Implementations Strategies
In order to demonstrate and evaluate the behaviour of the algorithms and protocols, we can use three
implementation methodologies: experimentation in the real world, emulation and simulation.
By experimentation in a real environment, through the use of test-beds, tests are performed on re-
alistic conditions, covering all effects that occur on the network, not being taken wrong or inaccurate
assumptions about external influences. It is actually the best way to prove that an algorithm or protocol
works as expected, however its limited scalability, its high costs of deployment and the lack of repro-
ducibility of the test scenarios in a controlled environment leads to the adoption of other solutions that
mitigate these problems.
In emulation, there is a coupling between real hardware and software components used in deploy-
ment with simulations that run on controlled laboratory conditions. The adoption of this technique has
advantages in terms of greater realism compared to pure simulation environment and the possibility of
repeated testing in a controlled environment. Despite these advantages, it remains an approach condi-
tioned by technical scalability bounds and high costs associated with the deployment of hardware and
software.
In a simulation environment, realism is only ”simulated”, being all algorithms and influencing factors
31
modelled and examined in an artificial software environment with a high degree of abstraction. Despite
the lack of realism, the major advantages lies in the possibility of analysing the scalability of the proposed
solutions, the possibility of changing the environment and scenarios and the non existence of costs
associated with the solution.
In the conception of the proposed location service, the simulation environment was chosen given the
inability to use the resources of the physical vehicular infrastructure, the possibility of testing the solution
scalability and because it is wise to test the location service, taking full control of the test environment,
before deploying it on the field.
4.2 Simulator Selection
In order to support the investigation of vehicular networks, it is necessary to use simulation tools with the
purpose of overcoming the high economic costs required to implement such networks in the real world
for testing purposes. Typically the simulation software resides in two different categories: Vehicular
mobility generators and Network simulators.
The mobility generators are used to increase the realism in movement patterns of VANET simu-
lations. For this, they generate realistic vehicular mobility traces that are used as input for network
simulators. As input for the same simulators, were given values such as road model and scenario pa-
rameters and as output the mobility profiles and location of each vehicle at every instant during the entire
simulation time were received.
In these generators there are two aspects to take into consideration: macro- and micro-mobility. The
first tends to increase the realism of the simulation taking into account the macroscopic characteristics
which influence the vehicular traffic such as its density, flow and average velocity. In the second case
each vehicle is represented as a distinct entity and takes into consideration characteristics such as
acceleration, braking and changing lane [38] [39].
Regarding the relationship with network simulators, mobility generators can be coupled in a uni or
bi-directionally way, the latter also called VANET Simulators [40].
In the first case, the traffic trace is generated before launching a network simulation. The second case
consists of two inter-dependent processes - road traffic and network simulation -, working concurrently
[35].
Although bi-directional generators are effectively better since the times of simulation associated are
lower, they do not provide us with the granularity needed to see the disaggregation between traffic and
network [41]
Therefore, only unidirectionally coupled simulators are targets of study. As an example of this type
of simulators: Vanet Mobility Simulator (VanetMobiSim)[42], Mobility Model Generator for Vehicular Net-
works (MOVE)[43] and Street Random Waypoint (STRAW) 1.
In order to integrate the ability to communicate between vehicles, network simulators are used. With
1http://www.aqualab.cs.northwestern.edu/projects/144-straw-street-random-waypoint-vehicular-mobility-model-for-network-simulations-e-g-car-networks
32
Figure 4.1: Unidirectional Simulation
these, it is possible to predict the behaviour of the vehicular network using the previously generated
mobility trace files.
The most relevant open-source networks simulators free of charge are NS-2, NS-3 , GloMoSim and
SWANS [41]. NS-2 is a popular discrete-event network simulator that uses OTcl and C++ programming
languages. Since it allows the modification of the source code in order to better fit the needs and
support node mobility, it is a suitable simulator for vehicular networks. In its latest version (NS-3), we
can find a simulator more driven for research and education and which exceeds some vulnerabilities of
its predecessor. Therefore it is increasingly taken as a reference with regard to network simulators.
GloMoSim, is a scalable network simulator for wireless and wired networks, coded in PARSEC, a C-
based parallel simulation language for wireless networks. There is a commercial version of this simulator
called QualNet 2.
SWANS is a scalable wireless network simulator built on top of the Java in Simulation Time (JiST)
platform [44], a general-purpose discrete event simulation engine. SWANS contains independent soft-
ware components that can be composed to form a complete wireless or sensor network. Its capabilities
are similar to NS-2 and GloMoSim, but SWANS is able to simulate much broader networks.
Based in the study made by authors in [40], the best options relating to mobility and network simula-
tors were determined.
Regarding to the mobility simulators, amongst the three previously described (VanetMobiSim, MOVE
and STRAW), MOVE represents the most simple to configure and use.
Regarding the network simulators, the choice lies between the NS-2, NS-3, GloMoSim and SWANS.
Since SWANS and GloMoSim are complex to setup, and there is not an implementation of GPSR pro-
tocol in these simulators, this leaves both NS-2 and NS-3. As NS-3 solves the scalability problems from
NS-2 and the 802.11p norm in later this simulator development, this makes it the best candidate for the
work developed for this thesis.
4.3 Network Simulation Model
4.3.1 NS-3 overview
NS-3 is a discrete-event network simulator with the primary goal to assist the research and education
in the area of communication networks. It is a free-software, publicly available under the GNU GPLv2
license for research, development, and use.
In order to represent simulation scenarios, NS-3 provides abstractions of real-world concepts, like
computing nodes with applications to generate traffic, net devices and channels.
2http://web.scalable-networks.com/content/qualnet
33
It consists mainly in a C++ Library that provides a set of simulation models, implemented in C++
objects and wrapped through Python.
In terms of abstractions, provides five key abstractions, which are described below and characterized
in Figure 4.2.
Figure 4.2: NS-3 Basic Model
• Node - Consists in the abstraction of a basic computing device. It is represented by the NS-3 class
Node that provides methods for managing the representations of computing devices in simulation.
• Application - This abstraction, implemented by the class Application, simulates the generation
and consumption of packages that are run on a node. Conceptually, has zero or more sockets
associated in order to communicate to a set of network stacks.
• Channel - Represents the abstraction of a communication channel. It is implemented by the class
Channel that provides methods to manage the connection between NetDevices.
• NetDevices - Consists in the abstraction that represents the network card associated with the
node, allowing the node to communicate with others in the simulation. It is implemented by the
class NetDevice that provides methods for managing connections to Node and Channel objects.
• Topology Helpers - Starting with the process of connecting several nodes in the simulation many
operations are needed. Since the creation of the device: the attribution of a MAC address, the
device installation on each node, the configuration of its protocol stack, the channel connection of
the device, amongst other operations. Thus, this abstraction which combine all these operations
in a most convenient and easy to use model was created.
34
Users typically interact with the NS-3 writing in C++ or Python applications which instantiates a set
of simulation models that configure the desired scenario simulation.
In addition to the simulation itself, NS-3 provides several features, including the existence of call-
backs, trace sources and .xml mobility outputs. Callbacks enable the function calls execution at a
scheduled simulation time. The trace sources allow to retrieve data for evaluation metrics analysis.
Concerning the mobility outputs, can be interpreted by tools such as NetAnim 3, which gives a graphical
output to the data.
4.3.2 Network Node Simulation Model
Concerning the Network Node Simulation Model, all nodes should present an architecture similar to
figure 4.3. Although the RSUs do not use the transport and application layer, as described in Chapter 3,
they are ready to run applications in case they are used with this purpose in a future work .
Figure 4.3: VANET Node Architecture Model
Application Layer
NS-3 provides a set of applications to use within simulations. In the context of this work were used
the UDPClientApplication and UDPServerApplication. These two applications enable the transmission
between two nodes unidirectionally from a client to a server. These applications were chosen because
they clearly validate the location service operation in study.
Transport Layer
In the transport layer, UDP protocol was used over the TCP Protocol. This choice is due to the
recommendation to avoid reliable approaches to the vehicular environment [45].
Network Layer
3http://www.nsnam.org/wiki/index.php/NetAnim/
35
Regarding the network layer, where most of this work is focused, the GPSR Protocol was used. Par-
allel to the routing protocol, the location service proposed by this work, SILOS, responsible for providing
the required positions by the GPSR was implemented.
MAC Access Layer
Concerning the Mac Access layer and posterior Physical layer, this is where the most relevant lim-
itations take place regarding the representation of the desired simulation scenario. This is due to lack
of support of 802.11p WAVE Protocols by the NS-3. However, despite being important in faithful repre-
sentation of the vehicular scenario, it is not important concerning the validation of the location service
protocol. Therefore, it was used the standard 802.11 MAC.
Physical Layer
Although NS-3 does not entirely support the WAVE System, in terms of 802.11p PHY it is supported
due to its minor modifications to the IEEE 802.11a, although only one channel be used, the CCH (chan-
nel 180 for the European 5.9 Ghz frequency band [46])
Regarding the radio propagation models, instead of using simplistic models such as Free Space
Propagation Model [3], that hardly corresponds to a realistic behaviour [47], more complex models were
used. In this way, it was used a combination of the Nakagami probabilistic model in order to model
Multi-Path Fading, combined with the Two Ray Ground Reflection Model, representing the exponential
decay of signal power over distance.
This choice comes from performed real-world measurements [48] [49] that, based on empirical data,
shows that this combination is suitable to the representation of the radio propagation in VANETs.
4.4 SILOS Implementation
This section will describe the details concerning the implementation of the SILOS Protocol on NS-3. As
mentioned above, the protocol was implemented in C++ and the classes are shown in Figure 4.21.
4.4.1 GPSR with GOD Location Service
Before explaining the implementation of SILOS, it matters to survey the initial situation in order to be
perceived the required effort to implement this location service on NS-3. Figure 4.4 shows the GPSR
implemented in this simulator, from the work done by the authors in [3]. As it can be seen, there is
the presence of a GOD Location Service that interacts with GPSR, when it is necessary to obtain the
location of a node. This GOD Location Service, only implements the method GetPosition() used to know
the position of the node. In order to accomplish that, this method directly accesses a container where all
nodes are hosted on the Simulator, iterates over them in search of the desired node and when it finds
it, accesses the object associated with the node and extracts its position from the query to its Mobility
Model class. This method is better described in Appendix A.
This operation, although is possible in the simulator, is completely impractical in the real world, being
only the GOD Location Service a software cheating and not a Location Service itself.
36
Figure 4.4: Initial Implementation Class Diagram
So, all studies that use GPSR on the NS-3 are falling short of reality since they do not contemplate
any computational effort and time necessary for obtaining positions, associated with the location service
process.
Like so, SILOS comes to mitigate this flaw by introducing this location service effort and then making
it possible to do more reliable studies about the feasibility of position-based routing protocols with a
coupled location service.
4.4.2 GPSR with SILOS Location Service
SILOS contains the following classes:
• SILOS LocationService, where the SILOS behaviour is implemented
• Location Table, aggregating a set of LocationEntrys and methods for managing this data
• MessageHeaders, where control messages are implemented
The Class SILOS LocationService was implemented from scratch and contains all the methods that
give concrete expression to the behaviour previously described in Chapter 3. The only feature that was
not possible to implement was the communication between RSUs through the infrastructure. This hap-
pens because the GPSR implementation does not support multiple interfaces. Because of that, one so-
lution that overcomes this problem had to be thought of. Thus, the only available interface was reserved
to the vehicular communication and for the infrastructure communication was used an identical solution
to the omniscient location service where the abstraction layer is broken and the computational object
representing the RSU was directly accessed. Despite not accurately representing the whole process
37
Figure 4.5: SILOS Implementation Class Diagram
of obtaining the vehicle’s position, when RSUs need to inquire other RSUs, this time was considered
negligible since it is much smaller than the V2I communication time.
Concerning the class LocationTable it is conceptually very similar to the PositionTable despite the
differences between LocationEntrys and PositionEntrys.
Regarding MessageHeaders, they are more detailed in the Section 4.4.3. A choice was made to
create location services messages completely separate from routing messages in order to make their
impact visible in the general solution. A possible optimization resides in its aggregation in such a way
that control message overhead were the lowest as possible.
Additionally, in the routing protocol was performed an optimization on the Purge method in the Po-
sitionTable erasing not only outdated entries but also entries whose positions covered more than their
pre-defined area range, either it is an OBU or a RSU. This optimization has brought real improvements
in the process of forwarding, making the method more complete by invalidating the choice of invalid
neighbours.
38
Despite being beyond the scope of this work, it was also implemented the RLS location protocol in
the NS-3 Simulator. This was done due to the need to compare SILOS with another location service in
addition to omniscient location service, although RLS typically be used for MANETs and not for VANETs.
Thus, it is possible to draw further conclusions on the feasibility of SILOS.
4.4.3 MessageHeaders
Bellow are presented all the message formats inherent to the proposed location service.
Location Hello Message - This message is 20 Bytes long and contains the identification of the
sender RSU and its position. This message is created whenever the RSU receives a GPSR Hello
Message. Ii is implemented by the class ns3::gpsr::LocHelloHeader.
Location Update Message - This message is 24 Bytes long and contains the identification of the
sender OBU, its position and speed.This message is created in the process of receiving a Location Hello
message by any RSU. It is implemented by the class ns3::gpsr::LocUpdateHeader.
Location Query Message - This message is 12 Bytes long and is composed by the vehicle identifica-
tion, by the identification of the RSU responsible for answering the location queries and the identification
of the OBU that is intended to know the position. It is implemented by the class ns3::gpsr::LocQueryHeader.
Location Reply Message - This message is 24 Bytes long and is composed by the identification of
the RSU that sent the message, the OBU that triggered the query and position which it was interrogated.
It is implemented by the classns3::gpsr::LocReplyHeader.
4.5 Functional tests
In order to demonstrate the developed implementation on the simulator, it was elaborated a set of func-
tional tests according to the specification of the proposed location service.
These tests validate the existence of three types of communication in this work. Therefore, a scenario
of V2V, V2I and I2I communication was tested.
With this purpose, it was created a scenario with 3 RSUs and 17 OBUs. These OBUs have a mobility
model associated according to the Car Following Model. In the following subsections these tests are
analysed by the extracted log files, in order to elucidate the behaviour in these different communication
scenarios.
4.5.1 V2V Communication
Regarding V2V communication, to examine its behaviour it was used the scenario above described with
a established UDP connection between nodes 11 and 7, being the first the client with the assigned IP
10.0.0.12 and the second the server with the assigned IP 10.0.0.8.
In Figure 4.6, it is possible to check the behaviour on the initial phase of communication between
peers. Firstly, it was performed a location query to the local Location Table by the GetPosition() method,
being returned the position of the destination node.
39
Figure 4.6: Example of .log file recreating a V2V communication between 2 OBUs
With this information it is possible to calculate the best neighbour to forward the information to, having
chosen the node with the assigned IP 10.0.0.10, because it is a neighbour that is closer to the destination
node position. This receives and forwards the information to its neighbour node 7, which is the intended
destination.
4.5.2 V2I Communication
To validate the communication between the vehicle and infrastructure, it was created a scenario where
the vehicle performs a location request to the infrastructure and the same responds with the desired
position. At this stage, three fundamental phases are described: the phase of sending a location query,
the reception phase of location query by a RSU and the subsquent location response and reception
phase of the location response by the OBU.
Figure 4.7, represents the first phase. At this stage it is verified that the first operation is the location
query by the method GetPosition() to the Local Location Table in order to verify if the same has the
desired position.
Since, in this test, the Location Table does not have this knowledge, it is added an invalid position
to the Location Table and triggered a location request to the RSU with the assigned IP 10.0.0.3, by the
SendQuery method().
The second phase is characterized by the reception of location queries by the RSU and its sub-
sequent response. In figure 4.24 it can be verified the reception of the message by the RSU with IP
10.0.0.3, the invocation of the ReceiveQuery Method that processes the request and the sending of the
40
Figure 4.7: Example of .log file recreating a location query sended from an OBU
response message by the SendReply() method.
Figure 4.8: Example of .log file representing the reception of a location query by RSU
The last phase consists in the reception of the location response from RSU with the desired position
by the vehicle that has triggered the process.
This behaviour is described in the figure 4.9.
It is noted that, after the reception of the response, there is the amendment of the invalid node’s
position with the assigned IP 10.0.0.8, to the predicted position given by the location service.
4.5.3 I2I Communication
In order to validate I2I communication, it was created a test scenario where one location request was
made to a RSU and the same was unaware about the required position.
In this situation it is triggered a I2I communication through the location query to the other RSUs.
Although this communication does not take place through the communication interface but through
41
Figure 4.9: Example of .log file demonstrating the reception of a location reply from an OBU
software cheating, as described in section 4.4.1, it is still possible to verify its behaviour in Figure 4.10.
Thus, there is a query of the position of the node with IP 10.0.0.10 to the RSU with the IP 10.0.0.2.
As RSU does not have this desired position in its Location Table, it asks the adjacent RSUs about
informations regarding the desired position.
The RSU with IP 10.0.0.3, knowing that position returns the information and, so, the RSU can already
reply this position to OBU by the SendReply() method.
Figure 4.10: Example of .log file demonstrating the communication between RSU’s
42
4.6 Synthesis
After presenting the architecture that supports the SILOS protocol in the previous chapter, in this chapter
the implementation was described. In order to understand the implementation options, a study of the
advantages and disadvantages in the test-bed, emulation and simulation environment was realized.
Once the simulation environment was chosen, the Network Simulation Model was defined, being the
implementation details of each of the layers of the TCP / IP model described extensively.
Then followed the description of the SILOS protocol implementation, specifying its class diagram,
elucidating about the classes implemented and the changes that are necessary to make since the im-
plementation of the basic GPSR module in NS-3.
Finally, implementation details of the messages inherent to the location service were described.
43
5Evaluation
This chapter will demonstrate several tests performed in order to evaluate the developed solution. Thus,
in section 5.1, the objectives that this evaluation is intended to reach will be defined. In section 5.2, the
metrics that will be used in the testing methodology will be detailed. And Section 5.3, the developed
tests will be demonstrated and analysed. In section 5.4, a final conclusion about the evaluation will be
carried out.
5.1 Evaluation Goals
The main objective of this thesis is to evaluate if position-based routing protocols coupled with a simple
location service that takes advantage of the physical infrastructure presented in the vehicular environ-
ment can provide a better performance than a traditional topology-based protocols.
Thus, two types of tests were made: tests concerning the efficiency of the location service protocol
and tests evaluating the general performance of a position-based protocol couples with this proposed
location service.
In order to evaluate SILOS, it was made a comparison with the Reactive Location Service (RLS).
The main reasons that lead to this choice were the similarities that this protocol shares regarding its
reactivity in the process of obtaining position. And since there is no location service implemented in the
NS-3 simulator, this was the easiest to implement.
Regarding the comparison between routing protocols, GPSR protocol coupled with SILOS was
mainly compared with AODV. AODV was chosen since it is one of the most known topology-based
protocols. The comparison with GPSR coupled with GOD comes in order to observe the impact that the
location service has in the performance of position-based routing protocols.
44
5.2 Evaluation Metrics
Several metrics were used in this work in order to validate the evaluation goals, describe above.
5.2.1 Location Service Protocol Metrics
In order to measure the feasibility of the location service, Location Service Overhead, Location Accuracy
Error and Time to obtain position metrics were used.
Location Service Overhead is defined by the percentage of the increased number of messages
required for the location service operation. In this overhead, is contemplated only the location service
messages being excluded the additional overhead required for the routing protocol.
LocationOverhead(%) = LocationMessagesLocationMessages+RoutingMessages+DataMessages
(5.1)
Regarding the Location Accuracy Error, it is defined by the average error length from the current position and
the predicted position.
LocationAccuracy(m) =∑NLocQueries
i=1 (CurrentPositioni −PredictedPositioni)
TotalLocationQuerys(5.2)
The Time to obtain the position metric is defined by the average time between the location service query and its
corresponding reply.
T imeObtainPosition(ms) =∑NLocQueries
i=1 (TimeLocationQueryi −TimeLocationReplyi)
TotalLocationQuerys(5.3)
5.2.2 Routing Protocol Metrics
Concerning the network performance of routing protocols, Packet Delivery Ratio and Average End-to-End Delay
were used.
Packet Delivery Ratio is defined by the ratio of the total messages received in relation to the number of messages
sent, through the whole simulation time.
PacketDeliveryRate(%) = TotalNumberPacketsTxTotalNumberPacketsRx
(5.4)
Throughput is defined by the delivery rate of data bits per second between two nodes and it is given by the
following formula:
Throughput(kbps) = NumberPacketsRx∗DataPacketLenghtTotalT imeSimulation
(5.5)
Routing overhead is given by the percentage of messages over the network that do not correspond to data
messages.
RoutingOverhead(%) = TotalMessages−DataMessagesTotalMessages
(5.6)
45
5.3 Evaluation Tests and Analysis of the Results
This section will present the results and analysis of the simulations performed with the metrics described earlier.
As mentioned before, tests are organized in two parts in order to evaluate both the viability of the service and the
location service coupled routing protocols’ performance.
For that, a simulation configuration suitable for all tests was created and is depicted on table x.
Parameter ValueSimulator NS-3.12SimulationTime 100sNumber of Nodes 20 nodesNode Spacing 100 mTransmission Rate 8192 bpsTransmission OBU Range 300mTransmission RSU Range 1000mPacket Size 512BHello Rate 1pkt/sLocation Entry LifeTime 5sPosition Entry LifeTime 5sPropagation Loss Model Two Ray Ground + Nakagami
Table 5.1: Simulation Parameters
In what concerns the mobility simulation, a scenario was developed in which nodes representing the RSUs were
placed on specific fixed coordinates and the vehicles were programmed according to a Car Following Model. This
mobility simulation is described on Figure 5.27. On this model, all the vehicles depart from a fixed position, one
after the other, leaving a 100 meter gap between them.
Figure 5.1: Mobility Simulation
Speed wise, the vehicles start from 0 m/s and accelerate until they reach 33 m/s, which matches the high-
way speed limit. This speed is constant throughout the simulation. In order to be able to guarantee the statistical
significance of the data, all simulations were repeated 10 times and then the results’ average value was calculated.
46
5.3.1 Location Service tests
In the following sections, metrics concerning the Location Service Overhead, Time to Obtain Position and Locatin
Accuracy will be tested in order to evaluate the performance of the proposed location service.
5.3.1.1 Location Service Overhead
Concerning the location service overhead required for the location nodes process, two distinctive behaviours are
identifiable between SILOS and RLS. As can be observed in the figure 5.2, RLS, in a situation of reduced multi-hop
transmission, achieves a low overhead due to the smaller number of messages exchanged through the network.
For a situation in which the number of hops increases, this value starts to rise almost exponentially, congesting the
network. This congestion is harmful to the routing information, lowering the packet’s delivery.
Regarding SILOS, given that the procedure of registration and discovery is always the same, regardless the
number of nodes in the network and the distance between them, there is a constant overhead rate. This enables
higher rates of package delivery in the most demanding situations, especially when the destination node is relatively
far.
Figure 5.2: Location Service Overhead versus Distance
47
5.3.1.2 Time to obtain position
Figure 5.3 show us a comparison about the time it takes to obtain a position, between SILOS and RLS protocol.
Both were tested, with the common routing protocol GPSR. As can be seen, RLS has a progressive increase of the
time it takes to obtain a position as the distance increases, while SILOS remains constant regardless of distance.
This progressive increase is explained by the time lost during multi-hop forwarding, required for the message to
travel between the transmitter-receiver pair.
In SILOS, this message does not has to travel the nodes between this pair, but instead, just reach the RSU
incumbent for the service. This RSU will respond directly in single hop given the range from RSUs antennas,
improving the overall position obtaining time.
Figure 5.3: Time to obtain a position versus Distance
5.3.1.3 Location Accuracy
Regarding the precision of the node location, figure 5.4 shows an elevated amount of errors associated with the RLS
in relation to the ILS. This happens due to the way RLS discovers the node’s position, reaching out to the neighbour
nodes when the emitting node does not have the required position and repeating this same process through out
all the neighbour nodes until the position is known. This modus operandi makes RLS naturally weaker when the
destination node is further from the emitting node.
The SILOS delegates the discovery process to the infrastructure, benefiting from its global node information.
For this level of precision, the prediction scheme is also fundamental.
48
Figure 5.4: Location Accuracy versus Distance
5.3.2 Routing Protocols tests
In the following sections, a more complete comparison between position-based and topology-based protocols will
be made, since previous comparisons do not address the complexity introduced by the location service. With this
purpose, metrics concerning Packet Delivery Rate, Throughput and Routing Overhead will be tested.
5.3.2.1 Packet Delivery Rate
In terms of Packet Delivery Rate, a more wider comparison between AODV and GPSR coupled various location
services was taken under consideration. As a result it is possible to analyse the impact that the location service
leads in the subsequent packet routing.
Based on figure 5.31, the first conclusion that can be taken is the lack of viability of the topology-based protocols
in dynamic multi-hop scenarios in contrast with position-based protocols. Another conclusion that can be taken is
the impact that the choice of location service has in the subsequent routing of packets.
Based on the behaviour of RLS, the higher the distance to the destination,the more broadcast queries are made,
making the whole process of obtaining position very difficult; this clearly has an impact on the routing process.
SILOS coupled with GPSR is able to provide an acceptable delivery rate, almost reaching the limit that is
provided by GPSR coupled with GOD Location Service.
49
Figure 5.5: Packet Delivery Rate vs Distance
5.3.2.2 Routing Overhead
In what concerns the Routing Overhead metrics, the same contemplated the routing process introduced overhead
as it did the location service’s. This way, it is verifiable the real overhead needed for the position-based protocols
operationalization. As can be observed in figure 5.32, the GPSR with SILOS coupled overhead values are constant
because the routing overhead is the same regardless of distance. This consists in the periodic Hello send-outs and
the location’s overhead is, almost fully, the required overhead for the location management.
The AODV protocol’s overhead is much higher given the unawareness of the destination’s node position. Due to
this situation, there are control packets which circulate the network even if the destination node is in front or behind
itself. This is harmful to the overhead values and, consequently, to the band width usage.
50
Figure 5.6: Routing Overhead vs Distance
5.3.2.3 Throughput
Even though the Packet Delivery Rate’s metrics express in a clear way the level of packet delivery, it matters to
figure out through a band width point of view, how much the volume of packets transfer per second is.
As it can be seen in figure 5.33, as the distance increases, the AODV protocol’s throughput diminishes thanks
to the overhead routing values but, mostly, to a destination vehicle agnostic forwarding. The GPSR with SILOS
coupled offers a reasonable overhead value, a more efficient forwarding which contributes to a higher throughput
value.
Figure 5.7: Throughput vs Distance
51
5.4 Synthesis
On this chapter it was described the evaluation done in order to validate either the proposed location service not
only has representative results of an efective performance improvement compared to actual location services to
MANET’s, as well if coupled with a position-based routing protocol, can have values close to the threshold defined
by the coupling of the same routing protocol with a omniscient location service.
The obtained results show that the proposed location service is a real improvement for the vehicular reality. The
key feature resides on the efficient context information usage, either the vehicle’s information or the environment’s
scenario, providing a simple, precise and good performance location service.
52
6Conclusion
6.1 Synthesis
This thesis main objective was to assess if a position-based routing protocol coupled with a location service that
takes advantage of the vehicular environment’s knowledge would provide a better performance than a traditional
topology-based protocol.
With this in mind, SILOS was developed. It consists in a location service that takes advantage of the RSUs
deployed on the ground to monitor the position of the circulating OBUs. Derived from that global knowledge, it is
possible to answer to location requests from OBus in order for them to communicate.
In this sense, this work start by addressing the state of art of the existing routing protocols, location services
and location techniques used to compute the vehicles’ position. In relation to the routing protocols, a taxonomy was
presented and all the options analysed, as for the traditional topology-based protocols as for the position based
protocols. In this analysis were depicted the main reasons that make location based protocols the best solution for
the vehicular reality. The subject of the location services comes up with the necessity of location based protocols
to know the position of the destination nodes as a way to better calculate the use of neighbour nodes in the routing
process. With this in mind, an analysis to the mobile network location services was made. This analysis was used as
an input for the conception of a simpler and a better environment suited location service. As a result of the deviation
between the real position and the one gathered by the location service is always present, due to the mobility scenario
and the delay in communication timings, the techniques used by the vehicles to obtain their position we’re analysed
and a prediction scheme, very similar to the dead reckoning as a way to diminish the phenomena and increase the
location service’s precision, was idealised.
In chapter 3, the architecture that served as a base to the proposed solution was presented. Thus, first a context
characterization was carried out due to the goal being the development of a environment aware location service.
Then, an analysis of the system requirements was presented. After this, SILOS architecture was depicted, starting
by a general overview, identifying the main components and the way they relate, and a detailed description about
the functional architectures of which one. Based on this knowledge, the SILOS protocol was explained, identifying
in a clear way each of the phases. In the end, an application scenario that exemplifies all the location management
process was presented.
53
In chapter 4, all the implementation developed for this work was depicted. As this implementation might had
occurred in several different environments, first were identified all the viable alternatives and analysed all the ad-
vantages and disadvantages for which one. Having chosen the simulation environment, the simulator was depicted
and the used network simulation was defined. After, the main implementations were set out, starting from a GPSR
protocol with an omniscient location service. Lastly, the functional ran were established with the intent of protocol
validation within the simulation environment.
Finally, in chapter 5 were performed tests as a way to assess the initial objective’s fulfilment. Therefore, the
tests were divided in two groups: location service viability evaluation tests and GSPR SILOS coupled protocol
performance’s validation.
6.2 Final Remarks and Future Work
In this work took place the implementation of a location service that takes advantage of the physical constraints of
the vehicular environment, such as the deployed communication infrastructure in order to operationalize a position-
based protocol. With this implementation, tests were performed in order to evaluate their feasibility within the
vehicular environment.
The gathered results allow to verify that the simpler location services solutions, which take advantage of the
context information over the exclusive use of vehicle topology, better fit higher mobility scenarios. Regarding SILOS,
this results allow to verify that the use of the infrastructure allows for quicker response times and more precise
answers. For this level of precision, the prediction scheme used proved itself fundamental for this improvement.
With future work in mind, it would be interesting to test the location service with more demanding scenarios such
as the urban scenario, using mobility models such as the Manhattan Model which represents a more challenging
scenario. For the highway scenario that was used, the insertion of additional obstacles, including the highway’s ac-
tual geometry (e.g., hills, bridges, curves and so forth) would make the mobility simulation more reliable, enhancing
the quality of the tests developed hereafter.
Another interesting effort would be to promote efforts regarding the scalability solution tests, using not only more
vehicles (upcharging the network) but more RSUs in order to also test the communication between them. For this
to happen, there must be an effort to alter the routing protocol for it to operate multiple interfaces. Lastly, it matters
to mention the security requirement that even though it was not targeted in this work, is of extreme importance in a
real environment deployment.
54
AAppendix
Figure A.1: GetPosition method from GODLocationService
55
56
Bibliography
[1] Toor, Y., Muhlethaler, P., Laouiti, A.: ”Vehicle Ad Hoc networks: applications and related technical issues”.
Communications Surveys Tutorials, IEEE pp.74–88, 2008.
[2] Hartenstein, H., Laberteaux, K.: ”A tutorial survey on vehicular ad hoc networks”. Communications Magazine,
IEEE pp. 164–171, 2008.
[3] Fonseca, A., Camoes, A., Vazao, T.: ”Geographical routing implementation in NS3”. Proceedings of the Fifth
International Conference on Simulation Tools and Techniques, 2012.
[4] Li, F., Wang, Y.: ”Routing in vehicular ad hoc networks: A survey”. Vehicular Technology Magazine, IEEE pp.
12–22, 2007.
[5] Lee, K.C., Lee, U., Gerla, M.: ”Survey of routing protocols in vehicular ad hoc networks, journal=Advances in
Vehicular Ad-Hoc Networks: Developments and Challenges, IGI Global, 2009.
[6] Paul, B., Ibrahim, M., Abu Naser Bikas, M.: ”VANET Routing Protocols: Pros and Cons”. International Journal
of Computer Applications pp. 28–34, 2011.
[7] Pei, G., Gerla, M., wei Chen, T.: ”Fisheye State Routing: A Routing Scheme for Ad Hoc Wireless Networks”.
pp. 70–74, 2000.
[8] Jacquet, P., Muhlethaler, P., Clausen, T., Laouiti, A., Qayyum, A., Viennot, L.: ”Optimized link state routing
protocol for ad hoc networks”. pp. 62–68, 2001.
[9] Ogier, R., Templin, F., Lewis, M.: ”Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)”,
2004.
[10] Perkins, C., Royer, E.: ”Ad-hoc on-demand distance vector routing”. pp. 90–100, 1999.
[11] Johnson, D.B., Maltz, D.A.: ”DSR : The Dynamic Source Routing Protocol for Multi-Hop Wireless Ad Hoc
Networks”. pp. 1–25, 1994.
[12] Corson, M.S.: ”Temporally-ordered routing algorithm (tora) version 1 specification”, 2000.
[13] Thongpook, T., Thumthawatworn, T.: ”Adaptative zone routing technique for wireless ad hoc network”, 2002.
In: ITC-CSCC :International Technical Conference on Circuits Systems, Computers and Communications. pp.
1839–1842
[14] Taleb, T., Sakhaee, E., Member, S., Jamalipour, A.: ”A Stable Routing Protocol to Support ITS Services in
VANET Networks”. pp. 3337–3347, 2007.
[15] Beijar, N.: ”Zone Routing Protocol (ZRP)”, 2002.
[16] Fußler, H., Uler, H.F., Hartenstein, H., Mauve, M., Kasemann, M., Vollmer, D., Asemann, M.M.M.K.: ”Location-
Based Routing for Vehicular Ad-Hoc Networks”, 2002.
57
[17] Vahdat, A., Becker, D., et al.: ”Epidemic routing for partially connected ad hoc networks”, 2000.
[18] Braga, R.B.: ”Understanding Geographic Routing in Vehicular Ad Hoc Networks”. pp. 17–22, 2011.
[19] Raw, R.A.M.S., Das, S.: ”Performance Comparison of Position-based Routing Protocols in Vehicle-to- Vehicle
( V2V ) Communication”. pp. 435–444, 2011.
[20] Husain, A., Shringar Raw, R.: ”Performance Comparison Of Topology And Position Based Routing Protocols In
Vehicular Network Environments”. International Journal of Wireless & Mobile Networks (August) pp. 289–303,
2011.
[21] Karp, B., Kung, H.T.: GPSR: Greedy Perimeter Stateless Routing for Wireless Networks. pp. 243–254, 2000.
[22] Lochert, C.: ”Geographic Routing in City Scenarios MobiCom 2004 Poster Abstract”. pp. 1–4, 2004.
[23] Rao, S.A., Boussedjra, M., Mouzna, J., Madrillet, T.: ”GPSR-L: Greedy Perimeter Stateless Routing with
Lifetime for VANETS”, 2008.
[24] Jerbi, M., Senouci, S.M., Meraihi, R., Ghamri-Doudane, Y.: ”An Improved Vehicular Ad Hoc Routing Protocol
for City Environments”. 2007 IEEE International Conference on Communications (June) pp. 3972–3979, 2007.
[25] Michael, K.: ”A Reactive Location Service for Mobile Ad Hoc Networks”, 2002.
[26] Li, J., Jannotti, J., De Couto, D.S.J., Karger, D.R., Morris, R.: ”A scalable location service for geographic ad
hoc routing”. Proceedings of the 6th annual international conference on Mobile computing and networking -
MobiCom ’00 pp. 120–130, 2000.
[27] Li, J., Jannotti, J., De Couto, D.S.J., Karger, D.R., Morris, R.: ”A Scalable Location Service for Geographic Ad
Hoc Routing”. pp. 120–130, 2000.
[28] Kieß, W., Fu, H., Widmer, J., Mauve, M.: Hierarchical location service for mobile ad-hoc networks. SIGMOBILE
Mob. Comput. Commun. Rev. (October) pp. 47–58, 2004.
[29] Ayaida, M., Fouchal, H., Afilal, L., Ghamri-doudane, Y.: ”A Comparison of Reactive , Grid and Hierarchical
Location-based Services for VANETs”, 2012.
[30] Das, S.M., Hu, Y.C., Lafayette, W.: ”Performance Comparison of Scalable Location Services for Geographic
Ad Hoc Routing”, 2005.
[31] Woo, H., Lee, M.: ”Vehicle Location Service Scheme using the Vehicle Trajectory for VANETs”. pp. 1256–1261,
2012.
[32] Boukerche, A., a.B.F. Oliveira, H., Nakamura, E.F., a.F. Loureiro, A.: ”Vehicular Ad Hoc Networks: A New
Challenge for Localization-Based Systems”. Computer Communications (July) pp. 2838–2849, 2008.
[33] Jochen, S.: ”Mobile Communications”, 2003. 2nd edn. Addison-Wesley Longman Publishing Co., Boston
[34] Bakaric, S., Borzic, M., Bratkovic, D., Grga, V.: Tetra (terrestrial trunked radio) - technical features and applica-
tion of professional communication technologies in mobile digital radio networks for special purpose services.
pp. 307–310, 2005.
[35] Jardim, J.F.: ”A Vehicular Ad Hoc Network Architecture with Geographical Routing Proposal”, Master’s thesis,
Instituto Superior Tecnico, 2012.
[36] Fukang, S., Qiansheng, F., Hao, M.: ”Research of OBU in ETC Based on ARM”. pp. 1–4, 2008.
[37] Rubinstein, M., Ben Abdesslem, F., Dias de Amorim, M., Cavalcanti, S., Dos Santos Alves, R., Costa, L.,
Duarte, O., Campista, M.: ” Measuring the capacity of in-car to in-car vehicular networks”. Communications
Magazine, IEEE pp. 128–136, 2009.
58
[38] Movahedi, Z., Langar, R., Pujolle, G.: A comprehensive overview of vehicular ad hoc network evaluation
alternatives. pp. 1–5, 2010.
[39] Alba, E., Luna, S., Toutouh, J.: Accuracy and efficiency in simulating vanets. pp. 568–578, 2008.
[40] Martinez, F.J., Toh, C.K., Cano, J.c., Calafate, C.T., Manzoni, P.: ”A survey and comparative study of simulators
for vehicular ad hoc networks ( VANETs )”, 2009.
[41] Lopes, A.F.R.: ”Realistic VANET Simulations”, Masters Thesis, Instituto Superior Tecnico, TagusPark, 2011.
[42] Harri, J., Filali, F., Bonnet, C., Fiore, M.: ”VanetMobiSim: generating realistic mobility patterns for VANETs”.
In: Proceedings of the 3rd international workshop on Vehicular ad hoc networks. VANET ’06, New York, NY,
USA, ACM pp. 96–97, 2006.
[43] Karnadi, F.K., Mo, Z.H., Lan, K.c.: ”Rapid Generation of Realistic Mobility Models for VANET”. 2007 IEEE
Wireless Communications and Networking Conference pp. 2506–2511, 2007.
[44] Barr, R., Haas, Z.J., van Renesse, R.: ”JIST: an efficient approach to simulation using virtual machines:
Research Articles”. Softw. Pract. Exper. pp. 539–576, 2005.
[45] Dalal, K., Chaudhary, P., Dahiya, D.P.: Article: Performance Evaluation of TCP and UDP Protocols in VANET
Scenarios using NCTUns-6.0 Simulation Tool. International Journal of Computer Applications (December
2011) pp. 6–9, 2011 Published by Foundation of Computer Science, New York, USA.
[46] F.Martelli, M., P.Santi: ”Measuring IEEE 802.11p Performance for Active Safety Applications in Cooperative
Vehicular Systems”, 2011. Vehicular Tecnhology Conference (VTC Spring)
[47] M.Boban, T.T.V.Vinhoza: ”Modeling and Simulation of Vehicular Networks: Towards Realistic and Efficient
Models”, 2011.
[48] J.Yin, G.Holland, T.F., H.Krishnan: ”DSRC Channel Fading Analysis from Empirical Measurement”, pp.1-5,
2006.
[49] V.Taliwal, D.Jiang, H.C., R.Sengpupta: ”Empirical Determination of Channel Characteristics for DSRC Vehicle-
to-vehicle Communication”. Proceedings of the 1st ACM international Workshop on Vehicular ad hoc Networks,
ser..VANET 04, New York, 2004.
59
60
61
