Berri Lio

Exploiting Vehicular Networks for Data
Collection in Smart Cities
by
Pablo Daniel Berrilio
An Engineering Thesis submitted to:
Facultad de Ingenierı́a
Universidad de Buenos Aires
Fulfillment of the requirement of the degree of
Ingeniero en Informática
Departamento de Computación
Facultad de Ingenierı́a - Universidad de Buenos Aires
March 2014
Co-directed engineering thesis between the Universidad de Buenos Aires and

TELECOM BRETAGNE within the framework of an internship agreement:
Prof. Adriana Echeverrı́a, Universidad de Buenos Aires, Argentina.
Prof. Jean Marie Bonnin, TELECOM Bretagne University of Rennes, France.
“No existen temas serios, ni la muerte, la tortura, la enfermedad, el hambre o la miseria.
Existen hombres serios que no saben reı́rse de si mismos, se toman en serio a si mismos
y cometen cosas (...) Sonreir es lo más serio que uno puede hacer.”
Like many of the things nowadays, adapted from an unknown person from the
Internet. Probably stolen from another one.
Abstract
With the arrival of Smart Cities new possibilities in terms of applications are emerging
and those possibilities demands new needs of infrastructure. This thesis is part of the
project called DC4LED (Data Collection for Low Energy Devices) that address the
problematic of how data generated by sensors all around the Smart City can reach
the Internet. To accomplish that, a network conformed of vehicles, sensors and static
infrastructure is proposed. In this thesis the focus is on the routing part of the project,
so an analysis of the routing requirements of the proposed network is presented along
with the development of a simulation platform in order to evaluate its performance.
Acknowledgements
I want to first thank all my family for all the support for all these years that have made
me prioritize my education over many other things. Then, I would like to thank my
professors and specially my mates that have made this long journey really pleasant and
enjoyable.
Regarding this current work i would like to mention my two tutors. I would like to thank
the current director of the Informatics Engineer career in the UBA Adriana Echeverrı́a
and the professor Jean Marie Bonnin director of the Network Department of Telecom
Bretagne University in Rennes, France for their support and guidance through all the
development of this thesis.
iv
Contents
Abstract iii
Acknowledgements iv
List of Figures viii
1 Introduction 1
2 State of the Art 3

2.1 Intelligent Transport System . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Addressing and Routing . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Manets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Vanets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Delay Tolerant Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 Vehicular Delay Tolerant Networks . . . . . . . . . . . . . . . . . . 15
2.5 VANETs vs VDTNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Security in Vehicular Networks . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Existing Vehicular Routing Protocols . . . . . . . . . . . . . . . . . . . . . 18
2.7.1 Epidemic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.2 Spread and Wait (S&W) . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.3 MoVe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.4 Anchor-based Street and Traffic Aware Routing . . . . . . . . . . . 21
2.7.5 GeOpps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.6 MaxProp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.7 Encounter Base Routing . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 Data Mules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 The WiFi Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9.1 IEEE 802.11p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.9.2 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Proposal: A Data Collection Infrastructure 34

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Nodes Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
v
Contents vi
3.2.1 Fixed Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1.1 Access Points . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Moving Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Encounter Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.1 Importance of the Encounter and Neighbour Concept . . . . . . . 38
3.4.2 Encounter Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.2.1 Neighbour Status and Encounter Table . . . . . . . . . . 40
3.4.2.2 Passive Encounter Protocol . . . . . . . . . . . . . . . . . 41
3.5 Routing Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.1 A Simple Routing Protocol . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Implementation of the Protocols . . . . . . . . . . . . . . . . . . . . . . . 47
4 Simulation Platform 48
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Selection of tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Sumo: a Traffic Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.1 Simulator Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Building the Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1 Scenario Description . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.2 Generating the scenario . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.3 Generating the Map . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.4 Generating Sensors and Access Points . . . . . . . . . . . . . . . . 56
4.4.5 Generating Cars and Buses Routes . . . . . . . . . . . . . . . . . . 56
4.5 Network Simulator: ns3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.1 Technical Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.2 The Encounter Protocol Implementation . . . . . . . . . . . . . . . 61
4.5.2.1 Stack Protocol . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.2.2 Protocol Class Structure . . . . . . . . . . . . . . . . . . 63
4.5.3 Implementation of the Simple Vanet Protocol . . . . . . . . . . . 65
4.6 Integration of ns3 with SUMO . . . . . . . . . . . . . . . . . . . . . . . . 67
4.6.1 Exporting Cars and Buses traces for the ns3 . . . . . . . . . . . . 67
4.6.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6.2.1 Re-using Nodes . . . . . . . . . . . . . . . . . . . . . . . 69
4.6.2.2 Repositioning of nodes . . . . . . . . . . . . . . . . . . . 71
4.7 A Simple Vanet Application . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Simulation Results and Analysis 75

5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3 Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.3.1 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3.2 Detailed Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4 Results and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6 Conclusion and Perspectives 106

Contents vii
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3 Perspective and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3.1 Simulation Improvements . . . . . . . . . . . . . . . . . . . . . . . 107
6.3.2 Improvements to the Simple Vanet Routing Protocol . . . . . . . . 110
6.3.3 Future Work on DC4LED . . . . . . . . . . . . . . . . . . . . . . . 111
A Tutorial: Installing the Vanet Platform 112
B Data Dictionary of Platform Classes 118

B.1 Encounter Protocol Classes, from figure 4.6 . . . . . . . . . . . . . . . . . 118
B.2 Simple Vanet Protocol Classes, from figure 4.7 . . . . . . . . . . . . . . . 120
Bibliography 123
List of Figures
2.1 Types of Vehicular Applications . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Spread and Wait Propagation. . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Motion Vector Routing Decision . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Motion Vector vs GPSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 GeOpps Nearest Point Mechanism . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Encounter Protocol Neighbour Discovery . . . . . . . . . . . . . . . . . . . 41
3.3 Encounter Protocol Neighbour States . . . . . . . . . . . . . . . . . . . . . 42
3.4 Simple Vanet Protocol Data Flow . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 Tools integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Grid Generation for Sumo . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Map Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 APs and Sensor Process Generation . . . . . . . . . . . . . . . . . . . . . 57
4.5 Bus and Car Routes Generation . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 Encounter Protocol Class Diagram . . . . . . . . . . . . . . . . . . . . . . 64
4.7 Simple Vanet Protocol Class Diagram . . . . . . . . . . . . . . . . . . . . 65
4.8 Bus and Car Traces Generation . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1 Packets Pie Chart (Small) . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2 Packets Delivery Time (Small) . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Packets Delivery Time CDF (Small) . . . . . . . . . . . . . . . . . . . . . 90
5.4 Static Coverage Map (Small) . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5 Dynamic Coverage Map (Small) . . . . . . . . . . . . . . . . . . . . . . . . 91
5.6 Packet Delivery Pie Chart (Large Simulation 1) . . . . . . . . . . . . . . . 94
5.9 Static Coverage Map (Large Simulation 1) . . . . . . . . . . . . . . . . . . 97
5.12 Dynamic Coverage Map (Large Simulation 1) . . . . . . . . . . . . . . . . 99
5.15 Packet Delivery Time (Large Simulation 1) . . . . . . . . . . . . . . . . . 102
5.18 CDF Packet Trip/Waiting Time (Large Simulation 1) . . . . . . . . . . . 103
viii
List of Figures ix

Chapter 1
Introduction
Every year, following Moore’s law computers become more and more powerful. The cost
of the hardware, on the other hand decrease, and each time become more accessible for
everyone. This does not only include desktop computers and portable PCs; cell phones
and all other kind of devices are involve. In addition, electronic components are also
getting smaller and smaller. One market that has increased a lot is the one related to
sensor devices. This is because, nowadays there are high-level general purpose solutions
like zigBee 1 , Arduino 2 and Raspberry Pi 3 that do not require a great expertise to be
used. Thereby, the sensor network field have acquired a great impulse also accompanied
with the performance increase of very small batteries that could make small devices to
last months and sometimes years.
This characteristics of the market are making the Internet of Things a real fact. The
Internet of Things is a concept which refers to the possibility of identifying and connecting
every object that people use in their everyday life. Cellphones and portable computers
are today the common examples of connected objects. However, the market is already
talking about smart TVs, smart houses, smart clothes, smart watches, among others
smart objects.
This Internet of Things concept comes hand in hand with the idea of making all those
devices reachable from the Internet. Today, with the arrival of IPv6 and its huge
number of addresses that can uniquely identify every thinkable object in the world,
this concept has become feasible. The idea of this, is to make every connected object
to be coordinated with the rest of them. This leads to a lot of advantages like energy
efficiency, interoperability coordination, remote management of devices and many more.
1
https://www.zigbee.org
2
http://www.arduino.cc
3
http://www.raspberrypi.org
1
Chapter 1. Introduction 2
However, to make this happen there is a fundamental characteristic that all those devices
share: connectivity. In fact, nowadays “making” objects smart is in most cases making
the objects to connect to the Internet. Little by little, connectivity, and thus Internet,
is reaching more places and objects. And vehicles are not the exception.
Many big brands of the car industry, like Renault, Volkswagen and Fiat have create
the car-2-car Communication Consortium (C2C) 4 in order to set a standard for vehicle
communications using the 802.11 standard, also known as WIFI. This opens the market
to a lot new types of applications. Also many new ways of car interactions become
possible.
In this thesis there are gathered the vehicle network field with the wireless sensor network
field. Nowadays, if someone want to connect a group of wireless sensors to the Internet,
he/she will need to design and deploy a sensor network infrastructure and connect it to
the Internet. Doing so, carry on with lot of obstacles that the network designer have to
deal with. For example, sensors have to be in range to connect among them, making
sparse networks really difficult to build. Here it will be presented part of the work of the
DC4LED project that tries to provide connectivity to sparse wireless sensor devices as
a service. The overall idea is that anyone who owns a bunch of sensors does not have to
design and deploy an expensive network infrastructure to make them reach the Internet.
He/She could utilize the network infrastructure given by the DC4LED network which
offers a one way connection (at least for the scope of this work) to the Internet. In the
DC4LED project, vehicles, sensors and access point work together to make information
coming from sensors reach the Internet through access point.
The outline of this thesis is as follows. Chapter 2 presents the state of the art in
terms of routing protocols of sensor networks and vehicular networks. An overview
of some existing vehicular routing protocols is also presented. After that, in chapter
3 it is describe the proposal for the architecture of the DC4LED network along with
its protocol stack. Chapter 4 introduce the platform that was developed in order to
test the proposed DC4LED network architecture. Then, chapter 5 presents the result
of the simulations that were performed with the developed platform among with some
integrated tools that shows those result using graphs auto-generated graphs. Finally,
chapter 6 concludes the report and give some perspectives about the future work on the
DC4LED project and on the simulation platform.
4
http://www.car-to-car.org
Chapter 2
State of the Art
This chapter presents the required background to understand the following chapters of
the thesis. Standard solutions for sensor networks are presented. A particular field
called Mule networks is also described. Then, systems that implies moving nodes like
vehicles are presented along with protocols that come to route packets in this kind of
networks. Finally, some amendments to the WIFI standard are reviewed to see if they
can be used to communicate the devices involved in this mobility environment.
2.1 Intelligent Transport System
Intelligent transport system(ITS) is a term that groups all kind of applications which
involves vehicular communications. With vehicular communications there is a new whole
market available to be exploited. In fact, the last years these field has been targeted of
many researches of many types. However, these vehicular networks are really expensive
to test. The deployment of a small car fleet with wireless devices in order to perform a
test-bed could have a really high cost. And you are just talking about a small group of
vehicles. What if you want to try a vehicular network with a couple of hundred cars?
And for a couple of thousands? That is why almost all works that can be found are
based in simulations. Now, the ITS is a really general term that involves a huge world
of different type of vehicular networks. But, just a few of those networks are more likely
to be tested in a real situation. This mean, not in a simulator.
But first, a classification of the different type of vehicular communication is now presented.
3
Chapter 2. State of the Art 4
2.1.1 Communication
There are two main type of vehicular communications (VC): inter-vehicle communications
(IVC) and roadside-vehicle communication (RVC), depending if the communication
happens just among vehicles or between a vehicle and a road side unit. A road side unit
or RSU in vehicular networks terminology is a fixed device or node that can communicate
to cars. In [19] this classification is presented with more details along with an hybrid
one, that combines IVC and RVC. These types of vehicular communications can also
be classified in terms of the number of nodes participating in the routing decision for
the vehicular network. Thus, it can be one-hop or multi-hop depending if the routing
decision only involves immediate vehicles or if it involves vehicles that are further than
one hope distance, respectively.
Despite of the Internet that is a multi purpose network, the type of vehicular communication
not only define the complexity of the routing protocols that lays above the network
infrastructure but the type of applications that it supports.
But before going into deep of how these vehicular networks work, some examples of
applications are presented to understand the nature of some of the needs and problems
of this field. Because, applications some time limit the type of routing protocol or even
the type of communication that can be used. For example, a platooning application,
that coordinates in real-time the movement of a group of cars typically in a highway can
not work in a RVC network (because of the lack of road side infrastructure ).
2.1.2 Applications
There are already many vehicles with some type of wireless communications. In particular,
there is a really well known: the electronic toll. This application involves a roadside-vehicle
communication, where the vehicle send a signal to the toll, in order to make a payment
to the highway company and raise the tollgate to pass through. This is a very simple
situation; just to nodes are involved in this small network and, thus, not need complexing
routing protocols nor complex infrastructure.
This example that was presented is just a specific communication system that only
works for making cars pass through the toll. And that is it. ITS are intended to be
multi purpose, that is to say, to support many type of applications. So, now we present
a classification of applications for ITS. For this purpose we make a mixture of some of
the types presented in [20] and in [19].
This classification can be seen as a tree, because it has several branches that splits in
others.
First there are the non traffic aware applications. Inside of this category there are
general purpose applications, like the ones you can find when you browse the Internet
(video streaming, file serving, etc). Then, there are the traffic aware applications. Those
applications are all that can help the vehicle to be safely conducted to its destination.
From this last branch, other branches come out like it can be seen in the figure 2.1.
Figure 2.1: A classification for vehicular applications.
The human oriented and the machine oriented. The first are meant to be directly read
and interpreted by the human being behind the wheel while the second is intended to
be use by the smart computer that the car would have. You will understand this last
one soon, when you dive into its categories. But first, from the human oriented branch
there are other categories. The traffic and routing information is what nowadays is
called as a GPS application: it tells what route to take to reach a desire destination.
Then, still under the human oriented category, there are the security applications. Those
applications are meant to avoid accidents. For example, an application of this type will
warn the person who is driving about a particular situation. It can be anything; an oil
split or a car accident, for example. In fact, in work [17] an idea of a collision avoidance
application is presented. It shows how this type off application could safe many people
from one of the most dangerous accident, the multicar chain accident, by rapidly warning
the driver about an accident that just happened ahead.
Then, you can see the security type of applications that come from the machine oriented
branch type. This case is the same as the one under the human oriented but the intended
receiver of the message is the on board cpu of the car. In this case, the person will not
have to act in consequence of the data, but the car itself will do it for him/her. For
example, one thing is that the application fire an alarm that the driver is going faster
than the speed limit and another totally different is that the car do not let the driver
go faster than the speed limit, automatically decreasing the car speed.
Finally, there are the traffic coordination applications. This is the holy grail of the
vehicular applications. These type of applications will let people do other stuff while
travelling by car (even for the driver !). Well, the driver will not be driving, the car itself
will drive. An example of this type of application is the platooning types applications.
This kind of application organize cars in platoons (groups) so that group of cars can
follow a head car, which belongs to that group in a very efficient and organise manner.
This is made by the on-board computer, letting the person who used to drive to be free
and do its own things, decreasing human errors and increasing the safety and comfort
of the passengers.
2.1.3 Addressing and Routing
Addressing is the way that nodes at the network layer in the OSI model are identified.
Typically, in the Internet there is only one type of address: the IP. In vehicular networks
addressing is not straightforward. In fact, there are different protocols that use different
type of addressing methods. In order to understand this topic is easier if it is presented
along with some example of applications.
As some or almost all the nodes of the network are moving the spacial component can
become crucial to the purpose of some applications. For example, you can imagine that
there is a security warning application that warns drivers about accidents or problems
that are ahead in the highway in order to make them go slower to avoid any kind of
accident or inconvenient. To make it simpler, you can make aside the infrastructure of
the network. So now, the warn is emitted by a vehicle that have had the accident or
by another that have found an accident. Then if the routing protocols are using IP for
addressing (or similar), the warn must go throw all instances of this type of application,
look if the current car could be affected by the accident by knowing if they are near the
zone of the accident, and display the warning. This is an inconvenient, because all the
nodes of the network are reach by these warning messages. And, of course, this comes
with a lot of overhead to the network and result noisy to vehicles that are really far
away from the accident.
This is because IP is not aware about nodes spacial distribution. The protocols that make
routes for IP packets counts hopes between nodes, and do not take into account where
the nodes are placed. It is said that IP routes in a fixed addressing mode. Luckily, fixed
modes are no the only way of addressing to route packets in these mobility environments.
Some protocols use geographical addresses for routing. Geographic routing make use of
geolocalisation devices (GPS) to know about the position of nodes, and thus delivering
packets to geographical locations.
Continuing with the example above but this time having a geo-routing protocol that
uses geo-location addresses, the application could route the warning packets to a certain
zone defined in geographical coordinates. In this case, the decision of who are receiving
the packets will not be in the application layer but in the network layer. Thereby the
packets will only reach those nodes that belong to the zone of relevance (ZOR); in other
words, to the nodes that are near the accident that is being warned. This topic about
geo-routing and routing in general will be retaken when talking about VDTNs and when
presenting some vehicular protocols in sections 2.4.1 and 2.7, respectively.
2.2 Sensor Networks
The current bibliography about vehicular networks do not contemplate communication

with sensors. Not moving sensor, nor fixed ones. In section 2.1.1, there was mentioned
a type of communication named RVC, that involve communication with fixed nodes.
When talking about road-side nodes, the intention was not to make reference to nodes
that generates information, but to assist the nodes in communication issues, like routing
or giving Internet access. Thus, works about that do not cover sensor as entities that
generates information that need to be delivered to servers in the Internet; which is the
main objective of the DC4LED project, presented in this work.
Then it turns out mandatory to dig in sensor networks. And, of course, in particular,
wireless sensor networks.
2.2.1 Manets
Mobile Ad-hoc Networks (MANETs) are auto-organize group of nodes that managed to
communicate among them without infrastructure assistance. Common WIFI networks
use base stations to organized communications within the network. This base stations
plays the role of the router. In contrast, in MANETs all the nodes that conforms the
networks could, and many times should, act like a router.
Not only that, MANETs can manage dynamic topologies. This means that nodes can
move and change their physical location in the network, changing the topology of it.
When this happens, routes that packets use to follow could become obsolete. Here is
where routing protocols come into play, in order to adapt the routes to the new topology.
In addition, MANETs need to overcome energy constrains. As many of these type of

networks are run over several nodes that are not wired and use batteries, those nodes
need to make an efficient usage of the energy. Regarding this topic, it will be seen in
more detail when talking about the 802.15.4 in section 2.9.2, but it is needed to take
into account here to understand the why of some decisions about the MANET routing
protocols.
In MANETs any node should be able to reach any other node in the network. So there
are two main approaches or strategies when it comes to generate routes for packets in this
type networks: pro-active and reactive routing protocols. In pro-active protocols routing
information is maintained all the time, whereas in reactive ones, the routing information
is generated on demand. Namely, in on-demand protocols when a node wants to send a
packet it has to wait until a route to the packets destination is generated before sending
it. Along with this classification, there are three major protocols that represents those
strategies:
• Optimized Link State Routing (OLSR) is a standard pro-active protocol.

To create routing tables it floods the network with topology information. This
information comes from every node in the network an needs to reach all nodes of
it, so each node can have the entire topology of the network. This information
is transmitted through TC (topology control) packets using a special flooding
technique. Instead of flooding those TC packet to all neighbours resulting in an
explosion of packets, a node only sends these packets to its multipoint relays (MBR)
that ensures that the topological information would reach to all of the neighbours
of its neighbours (two hop distance neighbour) transmitting less packets and thus
reducing the overhead of the flooding in the network.
In order to select the MBRs, each node sends HELLO packets to all its neighbours
(one hop neighbour) in order to know what are the neighbours of their neighbours
(two hope neighbour), thus knowing how to get to two hope neighbours without
sending packets to all its one hope neighbours. Once each node have the information
of the network topology it constructs its routing table using the Dijkstra algorithm
to calculate the minimum path to every possible destination in the network (taking
into account the amount of hopes between a source and a destination).
One of the problems of this protocols is that it needs to periodically send HELLO
and TC packets in order to maintain the routing tables, even for those routes that
are not used. For more information about these protocol you can read the RFC
3626 1 of the IETF 2 .
• Ad-hoc On-demand Distance Vector (AODV) is a standard reactive protocol.

In this case, routes are made when needed. When a node have a packet to a certain
1
http://www.ietf.org/rfc/rfc3626.txt
2
Internet Engineering Task Force, http://www.ietf.org/
destination, a route request is sent to all of its neighbours. Those neighbours also
forward the route request to its own neighbours. This flooding mechanism keeps
on until one of the nodes, have the desired destination as a neighbour. When that
happens, the node sends back a response saying that the destination is one hope
from it. The packet with the response traverses the route back acknowledging the
route to each node for what it goes through (increasing the distance count in the
packet in one in each visited node). In each step, the current node check if it
already has a route for that destination and if the route being acknowledging has
lesser hops that what it has in its routing table. If the new route has lesser hops
(namely, it is preferable) the current node replaces the older route with it. In this
way, all the nodes end up having the shortest path for that destination node that
was initially sent in the route request.
In this protocol, the routing information is kept at each node that conforms the
route of the packet, and each node only knows, for a certain destination, its next
hope and not all the route. Once the route is established, packets start being sent.
Routes endures in each nodes until the entry table for that route is occupied by
another or a new better route to that destination.
But when a packet is being sent and a link that belongs to the route is broken
(changing the topology of the network) a packet with an error goes back to the
source and start the discovery routing mechanism again. The benefit of this
protocol, compared with the OLSR, is that the first one only creates routes when
needed and not all the time as in the last one which derives in an improvement
in the overhead that comes from making and maintaining routes. However, this
improvement comes with a counterpart: the delay of the route establishment that
a first packet have to wait until the route is built.
• Dynamic Source Routing (DSR) is also an standard reactive protocol like

AODV. In fact, both protocols are really similar. The difference relays on who
keeps the routing information. The DSR is a source routing protocol. This means
that the entire route information from a source to a destination node is kept by the
source and the intermediate nodes for where the packet will pass by to reach its
destination know nothing about the route. As in the AODV, when a packet needs
to be sent a route request is sent. Temporary information while routing discovery
procedure is running is kept in each intermediate node that are involved in this
procedure. But when a route to its destination is found, the information of the
entire route is collected from each of the nodes involved in the discovery mechanism
and sent back to the source node that have made the route request. Then, when
sending packets through the network, each of it is sent along with the entire route
information to reach its destination. This comes with a significant overhear in the
bandwidth, specially when the routes have many hops an the addresses use in the
network are large (like IPv6 ).
These three protocols are not the only ones for MANETs, but they can be considered
as the most representative ones. For example, in the work [14] there are presented some
protocols that are modified versions of the presented protocols. In those protocols they
introduce QoS to the protocols. For example, instead of determining the best routes
based on the number of hops, they use the response delay. In those cases, routes can
be made depending on the responding time of the nodes and reaching a certain delivery
time rather than using the hop count.
However, these presented protocols do not managed well high mobility environments.
That means, this protocols fails trying to route packets when topologies change fast.
2.3 Vanets
Vehicular Ad-hoc Networks (VANETs) is a new kind of technology that tries to integrate
ad-hoc wireless technology to achieve vehicular to vehicular and vehicular to infrastructure
communications. Thereby, some of the MANETs protocols have been directly implemented
in vehicular networks. However, simulations with this type of configurations have yield to
bad results. Especially when those protocols are implemented without any improvement
to the concerned scenarios. Why?
Vehicular environments have several characteristics that differences this ones from MANETs.
To name one, in VANETs nodes do not have the same energy constrains. In fact, in a
vehicle, energy can be considered, in practical terms as unlimited whereas in MANETs,
sensors have limited battery which influence design decisions.
It has been already said that topology in vehicular networks change really fast. But not
only that, those changes are not the ones expected in MANETs. In vehicular scenarios
a vehicle can form a part of a network and in just a ten of seconds disconnect (and
maybe start to take part of another network). As a matter of fact, the frequencies of
this disconnections is really high compare to a MANET.
In addition, different scenarios may need to be handle in VANETs which make this
networks more dynamic than the MANETs. For example, the density of the nodes can
drastically vary depending on where the network takes part. Is not the same if the
network is taking place in the city center than if it is conformed in the suburbs. In
the first case, you will end up having lots of nodes whereas in the other the density of
nodes will considerably be decreased. Besides, network topology would not behave the
same if the vehicles are placed in a grid map than if they are in a highway. In a grid
map, vehicles change its direction constantly, thus experimenting lots of disconnections
compare to the ones that can suffer in a highway where vehicles will tend to go all
together forming platoons.
VANETs and VDTNs (later in section 2.4.1) come to present solutions to this new
scenarios. There is not one answer regarding routing protocols for vehicular networks.
Until now, routing protocols seems to be chosen depending on the ITS application needs,
without the predomination of a single protocol, and thus not a standard solution has
come up to arise among the others.
But now, a classification of routing protocols is presented. Of course there are more
than one classification, but here it is chosen, one similar to what it is presented in paper
[18].
Ad-hoc
First there are the ad-hoc protocols. This group encompasses mostly the routing protocols
similar to the ones presented in the MANET section 2.2.1. In those cases, the primary
characteristic is that the networks are self-organized without the need of a base-station.
As the protocols from MANETs do not came prepared “out of the box” for this networks,
many papers present modifications to those ones. For example, in paper [18], a modification
of the classic AODV MANET routing protocol is presented. One of the main problems
in vehicular networks is that complete routes can last little time comparing to the
route convergence time. To counter this problem the presented routing protocol, called
PRAODVM, collects information of the position and speed of the nodes. Then in order
to select the best route based on the a prediction of the life time of the routes instead of
choosing the shortest path. The life time of the route is calculated as an estimation of
the duration of the links among the nodes that composed the route, using the previous
mentioned position and speed of the nodes (taking into consideration the minimum
distance needed to maintain a link upped). So, the preferable route would be the one
that would last more, having lesser times to recalculate routes, and thus having less time
of convergence (that was one of the initial problems).
Position-base routing
Other type of protocols are the position-base ones. As it has been said in section 2.1.3,
this kind of protocols use GPS coordinates as addresses to route packets. The classic
protocol for this category is the Greedy Perimeter Stateless Routing (GPRS). In this
protocol, each packet has a GPS address to where it has to be delivered (destination).
The operation of the protocol is as follows. Each time a packet reaches a node, the node
looks into its neighbours to one which is the closest to the destination of the packet.
This is possible because each node knows all the rest of the nodes that are in range whit
it and with whom can communicate (only one hop is considered). Then, when it finds
a suitable neighbour, it transmits the packet to the next it and the procedure repeats
until the packet reach its destination (that is why it is call greedy). This procedure is
also repeated for all the packets.
Basically that is the main idea of the protocol. However, some times there is not a
better node or maybe the next node is not the best one because it can leads the packet
to a dead end. In those cases the protocol has some improvements to overcome those
difficulties. But to go deep in the protocol details is not the intention here (for more
information see [18]).
Broadcasting routing
Another type of protocols is the broadcasting routing one. In this type of protocols,
the source node floods the network with the packet it want to deliver. These protocols
assure that the packet will eventually reach the desire node. Despite of what the reader
could infer from this behaviour from these type of protocols, they can perform very
well in networks that have just a few nodes. However, the performance of the protocols
downgrade really fast when the amount of nodes increase.
One of the main characteristics of this protocols is that, while maintaining a low amount
of nodes in the network, the latency or delivery time of packets are the smallest (compare
to other vehicular protocols). Also, the percentage of delivered packets is the highest.
So, that is why this protocols are used as a rule to compare with other protocols.
In general, the focus of this protocol is putted on the mechanism that stops/managed
the flooding so it does not overwhelm the network and on how to communicate to other
nodes that are carrying the packet when the packet has already arrived to its destination.
Another important concept to have in mind when implementing this type of protocols
is the buffer dedicated for the transporting packets. Because of the flooding, packets
reach practically all nodes which leads to a great load not only in the radio link that
permits the transmission of those packets among the vehicles but to the depletion of the
memory that all the packets consumed when being carried. In fact, the memory issue is
not only found in this type of protocols. For example, in a routing protocol that based
its routing decision on the delivery probability of the nodes (that means that each time
that two nodes/vehicles are encountered the one that have the worst metric would send
all the packets to the one that have the best, so the packets would be more likely to be
delivered) the most of the packets will tend to be carried by a minority of nodes, causing
those nodes to run out of memory.
There are several solutions to address this problem and some depends of the protocol
being use. For example a queue can be used so that the first packet that is introduced
in it, and then the one that has travelled the most would be discarded first in order to
make room for a new one. The other way around also makes sense. Some consider that
the further the packet has travelled the more chances to reach destination it has (here
the priority is for the packets that are more likely to be delivered). These are just a few,
but protocols could take advantage of their own characteristics to implement its own
managing politic of their packet buffers.
Statistic routing
Another type of routing protocols is the statistic routing protocol that base its routing
decision taking into consideration passed experiences. The routing decision is one of
the keys when developing a vehicular routing protocol. When a node that is carrying a
packet encounters another node also capable of transporting a packet. Should the first
node continue carrying the packet? Should it give the packet to the other node? And
why not, should the first node transmit a copy of the packet and end up with the two
nodes carrying the same packet?
These are the basic questions that a person with that intention need to answer. Just to
keep the scenario simpler, suppose that in this network only one copy of the packet is
allowed to be carried by the nodes. Then, the answer would be binary, keep with the
packet or hand it (supposing that the encounter is with only one node). Then, there are
many possible answers and it is really difficult to say that one would be better than the
other. This is because, despite cars follows some rules when moving (and then, are some
kind of predictable), the protocol would be making futurology about the next movements
of the vehicles (nodes). And in fact, that is what this type of routing protocols do;x
they predict.
For example, in order to response these binary question, a protocol could take statistics
about the places that the current node has visited. Then, nodes can make “maps” where
it is more likely that nodes will go. Thus, when a vehicle carrying a packet encounters
another vehicle they can compare their “maps” in order to see who is more likely to go
near the packet destination and decide upon.
As the reader can expect, there are many possibilities to make this decision and several
of them could rely in very different characteristics. Not only that, these characteristics
are dependant of the routing protocol and/or the available information that each vehicle
has. Another example. You can imagine that a driver has enter a destination in the GPS
device to know which route he/she need to follow to arrive somewhere. This would be a
very precise and precious information in order to make a routing decision. The routing
module would not only have where the vehicle is going, but what route he/she is taking.
Thereby, there is not need to say the countless of possibilities that the routing decision
can be based on and, of course, the complex mechanisms that can be done mixing them.
Finally, this classification of protocols does not make the categories exclusive. That
means that a protocol can belongs to more than one category. As a matter of fact,
in paper [18] another type of routing protocol called Geocast Routing is considered.
Basically, these type of protocols delivers packets to a ZOR (zone of relevance). And
within the destination ZOR, a flooding technique is applied to reach all the nodes that
belong to it. In this case, this type of routing is half positional-base, half flooding. It
uses geographic coordinates to reach the ZOR and then take advantage of the good
performance that flooding protocols have when they are applied to a small group of
nodes (ZOR are supposed to have sizes of about more or less one kilometre).
2.4 Delay Tolerant Networks
Delay tolerant Networks also called Disruption Tolerant Networks, from now on DTN,
are characterized for the lack of full path from source to destination. The full connected
path can be of course available at one time but this is not the general rule. This lack of
connectivity is associated with the mobility of the nodes that conform the DTN.
In static networks (like the Internet) there are routers that managed to deliver packets
to the correct way to reach its destination. The information to accomplish the routing
decision is static and last as long as there is neither disconnections nor problems with
the nodes (so it can last months). In this type of scenarios, the routers typically have
many links trough where they can forward incoming packets. When a packet arrives,
the router look for the destination in its routing table and forward packets immediately.
If there is not a route for the destination packet, the packet is immediately discarded.
However, this last case do not happen very often because routers always have a default
route. On the other hand, in DTNs when a router receives a packet and do not have
any route to forward the packet, the router stores the packet until the route becomes
available or it come up with another route or until it decide to drop the packet. That
is to say, in DTN architectures, routers have to be much more intelligent because they
do not know if they will be able to deliver the packet to the destination or to another
router that could finally deliver the packet to its destination. Then, many challenges
arise regarding the operation of this type of protocols.
Because storage in routers is limited, in DTNs if there is a new packet that need to be
route but there is not a route available at the moment, the packet need to be saved. But
if there is no room for that new packet int the router, which packet the router should
keep and which should drop? Can the router still accept packets from other nodes? Do
it need to tell others that it has no room for incoming packets? or just keep receiving
packet and drop them following its certain rules until a new route for packets become
available? These are just some of the questions that a DTN routing protocol need to
answer.
Because the nodes can move and links among them can go up and down and new
nodes are connected to them and others leave the vicinity changing the topology of the
network, router nodes need to act fast and take dynamic routing decisions all the time.
But, despite the efforts of smart routers, those protocols can not assure that a packet will
eventually reach its destination, leading some times to a significant amount of packets
loss.
In this type of environments protocols like the ones seen in the sensor networks section
2.2.1 that handle mobility scenarios failed to managed this type of situation because
they need the complete path from the origin to the destination to define a route. So,
most of the time, they end up not converging to any solution.
Generally, protocols that deals with this type of disrupted networks, save packets being
route until new links become available; and the focus of this kind of protocols is always
maximize the delivery rate (as there are many disruptions, many packets are lost or
discarded) while minimizing the delay. The delay is an important aspect of this networks
because a router node can be saving a packet for a long type until a “next node” becomes
available.
However, this field has not grow enough until the appearance of the vehicular networks
where the discussion has reemerged, which is what is presented in the next section.
2.4.1 Vehicular Delay Tolerant Networks
DTNs came up initially to solve very long distance communications, to manage communications
for example between satellites and base station placed on the Earth. In those cases
satellites were going around and some times go beyond the scope and could not transmit
to other “nodes”. Later on, there was noticed that this intermittency in the connections
of that type of networks were also happening in vehicular networks, which has lead to
a new investigation field called Vehicular Delay Tolerant Networks or the short form
VDTNs.
Despite a route that connect the source with the destination of a packet could exist at
a certain point in a large vehicular network, trying to construct and then utilise that
route is practically impossible. A vehicular network in an urban area could have tens
of thousands of nodes, changing the topology of it in just a few seconds whereas the
vehicles moves at speeds of between 20 and 60 km/hs. So, trying to find the optimal or
any path doing source routing it is impractical. In fact, knowing in advance what nodes
the packet will traverse to reach its destination it is also not possible despite knowing
having a lot of time and knowing every position of every node. This is because vehicles
are not deterministic, as they are driven by people. That is why, most of the vehicular
DTN protocols adopt a politic of store and forward, where the routing is made hop by
hop. This means that the routing decisions are made within a few nodes without the
accurate knowledge of the complete network.
For some small vehicular networks this is not entirely true. Some protocols use oracles
as fixed infrastructure to help with the hard task of routing. In those cases, oracles are
considered to be interconnected (“wired”) among them, and each of them has mobile
nodes attached to it. In this way, and for certain cases it is possible to know the entire
network topology when dealing with a packet. The problem with this type of solutions
is that they are expensive because of the installation of those oracles that need to cover
a big part of the area where the network is being deploy and that when the number of
nodes increase the network can not scale because the amount of topology information
becomes very large.
Back to the store and forward style of the protocols, basically this implies that packets
have two ways of being routed. One is when a node decide to pass the packet to another
node and do it. The second is when, having exhausted all the possibilities of passing
the packet to a “better” node, the current node continues carrying the packet until it
finds another new node capable of transporting the packet or until it finds the packet
destination node.
Nevertheless there is not an only solution. In fact, the routing depends of other decisions
that have been adopted to conform the current protocol. A fundamental issue is the
addressing. It is not the same to use geographical address or static address like IP. If a
packet has an IP destination address, the node whose address is the destination of that
packet can and will move in the network making the first routing calculation pointless.
However, if locations addresses are used, the packet needs to go in the direction of
one address and will eventually reach that zone, because the destination is not a moving
object but a geographical fixed place. Of course, the implications of using one or another
type of addressing strongly limits the type of applications and services that the network
can provide.
Now, the main idea of VDTNs has been explained. However many questions arise. It
has been said that packets can be transported until another node is found. But, how
do a router node carrying a packet know if it is better to forward the packet to the new
encountered router node or keep it to deliver itself? or maybe wait for another router
node that can possibly do it better? What if instead of determining if the packet would
get better chances of reaching its destination if it continues with the current node or
with the new encountered node, the current node makes a copy and hands it to the new
node? This last question, also leads to other ones: Can be more than one copy of the
packet in the network, so many router nodes try to deliver the same packet?
Well, those questions find its answer in each of the specific protocols that have been
proposed along the last decade. In fact, some advances of this answers where made in
the VANET section 2.3. But, to have a more complete answer to those questions some
meaningful protocols are briefly presented in one of the following section 2.7.
2.5 VANETs vs VDTNs
Sometimes people refer to VANETs or VDTNs indistinctly and this can generate some
confusion. But, is there a difference between them? To answer this question it is needed
to go back to their definitions. VANETs come from vehicular ad-hoc networks, so,
basically this means that to belong to this group of networks, the main requirement is
the lack of a base station to build the network. On the other hand, DTNs are vehicular
networks where the distinctive characteristic is being tolerant to large delays. Then,
from this, you can say that these type of networks are not mutually exclusive. That is
to mean, for example, that a network can be a VDTN and VANET at the same time.
In fact, most protocols presented here are both VANET and VDTN because they only
use vehicles that are self organized and the vehicles carries the packets until they find a
next node (carry-and-forward DTN style).
As an example, the SPRING (see section 2.6) protocol is a VDTN protocol but not
a VANET one. This is because it uses road side units to enhance the security of the
network, but still uses the idea of carry and forward. However finding an example
where the protocol is a VANET and not a VDTN in a medium to large network is not
easy. This is because of the nature of the problems presented in vehicular networks.
If each time that a node receives a packet and this node do not have a next node to
forward the packet, the amount of packets drops would be really high, ending up with
an unacceptable performance of the network. This is because instead of saving the
packet until a next node appear, the node is discarded. Also, because expecting to
have a complete route to destination in this types of scenarios is also unrealistic, so
recalculating a route after a dropped packet would end up with another discard.
2.6 Security in Vehicular Networks
Despite the security issue is not address in this work, it is good to make a few comments
about it to remind that it is a relevant issue and that it should be tackled in the future.
Firstly, the security aspect in this type of networks is complex. In ad-hoc networks nodes
have some type of authentication and this is possible because the number of nodes is
small and in general the administrator of the network have some kind of control over all
the nodes. However, in a vehicular networks, where all vehicles can connect to it, there
is impossible to have an administrator that have some control over all the vehicles.
Secondly, as a consequence of the structure of vehicular networks and the large amount
of untrusted nodes, attacks are easier. For example, the black hole attack is about a
node advertising the best route for all packets (that can be apply to most all the routing
existing vehicular protocols, as they used some kind of metrics to decide who will keep
carrying the packet). Then, as a consequence of it, all the nodes that have contact
with the node that is performing the attack, would send all their carrying packets to it.
Finally, the attacker would drop all the received packets, drastically downgrading the
performance of the network. As it can be seen this attack is really simple and just a node
is utilize, and making a solution to it is not straightforward. If the reader is interested
in this topic, he/she can start reading the paper [8] where some of the common attacks
are presented along with a protocol called SPRING that address those attacks.
2.7 Existing Vehicular Routing Protocols
This section describes a variety of vehicular routing protocols. This description does not
pretend to be very detailed, because for that purpose there are the original works that
present each protocol. However, the protocols presented here are a selection of the most
meaningful for the person who is writing this work, because each one that is presented
takes advantage of different aspects of this type of networks in order to route packets.
Then at least one of the type of protocols described in previous sections are presented
here.
This section is intended to give to the reader a wide idea of what is going on in the
vehicular networks field, and how the protocols have been evolving among the last years.
2.7.1 Epidemic
Epidemic is one of the first protocols that was developed for vehicular networks. It is
a flooding, one-hop, carry-and-forward style protocol. In Epidemic, on an encounter,
nodes interchanges all the packets that the other node do not have. This makes that
mostly a copied of each packet reach every node in the network. Once that the packet
reach its destination, there is the need for some kind of mechanism in order to purge
the nodes that are still carrying a copy of the packet. This is because the nodes do not
know that the packet has been delivered (except for the one that did deliver the packet).
As there are more than one version of this protocol, there are more than one manner
of solving this problem. One is sending an acknowledge back to the network telling the
nodes that the packet has been delivered and so they can drop the other copies. Of
course, this has it own load over the network. Another approach is to set a timer after
which the copies of the packet will be discarded. This timer, could be estimated having
the statistic of how much time do packets take to reach a destination.
Ideally, if the nodes have unlimited buffer to transport packets and on each encounter
there is also unlimited bandwidth to transmit packets, the Epidemic protocol is the
one that delivers packets with the smallest delay. So Epidemic will perform better in
networks with low load (few packets) since this situation would be the closet of having
unlimited buffer and bandwidth.
2.7.2 Spread and Wait (S&W)
The main problem of the Epidemic (and in general of all the flooding protocols) is the
explosion of packets that are generated around all the networks. When the network
has low load, the Epidemic protocol performs the best in delivery time, but when the
quantity of packets start to increase the flooding mechanism can become counterproductive.
So flooding protocols that have came after Epidemic have tried to limit that explosion
of packets. The Spread and Wait (S&W) made a simple modification in the original
Epidemic control to decrease that explosion. It adds a counter field in packets. When
the packet is first created, the counter is set to N (configured in the protocol) and each
time that the packet is transmitted (and, thus copied) to another node the counter is
divided by 2. When the counter become 0 (it is considered integer division, so 1 divided
by 2 is zero) the node would not transmit any more that packet in further encounters.
(a) S has a packet to D. (b) Spread phase. (c) Wait phase.
Figure 2.2: Spread and Wait Propagation.
Thereby, the protocol it is said that has two phases. The first is called spread, as packet
copies are distributed to several nodes. The second is called the wait phase, because it is
expected that the packet (and its copies) reach its destination by traversing the network
just with the movement of the carrier node. Figure 2.2 shows this behaviour. In the
figure 2.2a there is a node with a packet represented with a red point that want to reach
the green node that represent the packet destination. Figure 2.2b, during spread phase,
shows all the nodes that have copies of that packet that are really close to the source
node. Finally, in figure 2.2c, during wait phase, it is possible to see how all the carrier
nodes have been disperse over the network, and making one node getting close to the
packet destination. As it can be seen, it does not matter that the destination change its
position because carrier nodes are not selected by any reason of geographical position
or moving behaviour and are free to go wherever they want.
2.7.3 MoVe
In section 2.3 the primary idea of the GPSR protocol was explain. It basically looks up
for nodes that are closer to the destination of the packet using geographical localization.
MoVe is also a greedy protocol but instead of using just GPS positioning for making the
routing decision, it adds some kind of route prediction. Despite the prediction is really
basic it can be very advantageous in some cases.
The MoVe protocol use the motion vector to add this predictability. The motion vector
is a property of each moving vehicle. It is a vector that heads to the direction that the
vehicle is following. It is said that is a rudimentary prediction because it is a short term
one (in fact, it depends on how much “history” is taken into account to construct the
motion vector).
In the figure 2.3 there is a simple example of how it works. There are two vehicles (A
and B) that meet at a certain point. Vehicle A is carrying a packet which has to reach
Figure 2.3: Routing decision based on the motion vector of two vehicles A and B.
“Destination”. Besides, node A and B are moving in a particular direction described

by the arrows that are originated in the respective vehicles position represented by the
two black circles. In order to know if the vehicle A has to keep carrying the packet or
handed it to B, they compare the angles that form each of its motion vector with an
imaginary line that goes from the vehicle to the destination. In the figure, A has a δ
angle and B has the γ angle. Because the γ < δ, and thus B would pass closer to the
packet destination, A will handle the packet to B so it continue carrying with the packet.
Of course, this mechanism is repeated each time a vehicle encounter another one, and
for each packet being carried.
Figure 2.4: Case where MoVe performs better than GPSR.
This protocol can have advantages over the GPRS in some particular cases. For example,
in the case that there is a two way street like in figure 2.4 where A is heading to the
packet destination and the other vehicle, B, is heading the opposite direction, MoVe
would end up having the smarter routing decision. In this case, in GPRS, A would
handle the packet to B and B would continue carrying the packet as it is closer to the
packet destination. Whereas in MoVe, A would continue carrying the packet as the
difference of angle is of 180 degrees. And in this case it is clearly that the A is the more
convenient node.
2.7.4 Anchor-based Street and Traffic Aware Routing
The A-Star ([10]) is a position base, “street aware” vehicular routing protocol. This
protocol use traffic information of cities to define routes to be followed by the packets.
This protocol is intended to be deploy in big cities with high density of vehicles. A-Star
is a source routing protocol, because when it sends a packet to a destination it includes

a list of points that the packet should pass by before arriving its destination. To traverse
those points the protocol use a greedy algorithm as the GPSR. The packet is transmitted
to the closest vehicle (in range) to the next point of the packet route list until it reach
its destination. The novelty of the protocol resides in how those points of the routing
list are picked.
When using a vehicle and trying to go faster to some place, the driver choose the route
with lesser traffic, thus avoiding congested streets. This protocols applies this concept to
route packets, but in a contrary sense. For the protocol, the more congestion the better.
The more quantity of vehicles, the more connectivity. The more connectivity, further
and faster the packet can go. This is becaue the packet travels faster when there are a
lot of nodes because the packet travels jumping from vehicle to vehicle getting closer to
its destination, rather than being transported for a unique vehicle (the speed of a radio
transmission is, by far, much more faster than the speed of a car) when there is not a
next node available.
Then, in order to make the packets traverse the street with more vehicles the protocol
use static map information to generate the list of points of the packet. Nowadays, there
is enough information of traffic in online maps; dynamic information. However, the
protocol as it was developed some years ago and because the information has to be
available all the times in the nodes to take decisions, it uses statics information. In fact,
it uses a special mechanism to infer the traffic in each street. It uses the size of the
streets. For the protocol, it considers that the wider the street, the more vehicles can
and will traverse the streets.
2.7.5 GeOpps
The Geographical Opportunistic (GeOpps) routing protocol is a location based, carry

and forward, one-hop protocol. The GeOpps uses GPS coordinates to conform the
destination addresses of the packets. Unlike MoVe and GPSR protocols, the GeOpps
exploits GPS navigation systems. In fact, it assumes that each vehicle/node (3 ) has
defined its own route which it is following.
Thereby, each vehicle knows where it is going. Thus, the mechanism of the protocol to
deliver packets is as follows.
3
As the reader could already realise, the word vehicle and node is used interchangeably when talking
about vehicular networks.
4
Figure obtain from paper [22].
Figure 2.5: Nearest points of three routes for a destination point of packet.4
When a packet is received by a vehicle it calculates the Minimum Estimated Time of

Delivery (METD) for the packet following this equation:
M ET D = EsitmatedtimetoN P + Estimatedtimef romN P toDest
Where Dest is the final destination of the packet and NP is the Nearest Point. The
NP is the point in the current vehicle route (defined in the GPS navigation system)
which is closer to the destination of the packet. The estimated time to reach the NP
is calculated using the average speed of the vehicle (yes, this is another hypothesis that
said that the average speed is available. This is not a really strong one because this kind
of information is already available in nowadays cars), just dividing the distance from the
current position to the nearest point (following the route defined by the GPS navigation
system) by the average speed. The second part of the equation is estimated dividing the
euclidean distance from the NP to the packet destination by the same average speed.
Then the METD is used for making routing decisions. Each time a vehicle encounters
another vehicle it interchange the destination of the packets that they are carrying. For
each destination point, the vehicle that receive that, calculates the METD with its own
route and send it back to the other vehicle. Now the first vehicle that has sent the
destination point to the other vehicle have the METD of its neighbour to compare with
its own METD. Finally, if the announced METD by the other is smaller than its own,
then it transmit the packet to it so that the other continue carrying with the packet.
An example of this is shown in figure 2.5. In the big black point there are three nodes
that have met: node A, B and C. The node B is carrying a packet whose destination is
the point marked with a D. The lines red, black and green are the paths following by the
vehicles A, B and C respectively. The nearest points (NPs) of each node corresponding
with the packet being carried by B are shown in the figure as N Pa , N Pb and N Pc . As
it can be easily see in the picture, the closest NP is the one that correspond with the
node C. Finally, in this case and for this particular packet, the node B that was carrying
it, decides to transmit the packet to C, so it can continue carrying the packet. This
happens, of course, after being calculated the METDs for A, B and C for that packet.
As having a defined route that each vehicle is following is a very restrictive condition,
the protocol says that in case that a vehicle has not that route defined, the packet can
follow a greedy routing decision (such as the one in GPRS) until it arrives a node that
has the followed route information available.
2.7.6 MaxProp
The MaxProp is a flooding vehicular delay tolerant network routing protocol, that based
its forwarding decisions over the historical encounter of the nodes that conform the
network. The developers of the protocol have said that the protocol should correctly
manage the limited resources that these networks have. Those resources are the storage
of each node and the bandwidth available during the encounter of two nodes. Before
explaining how these resources are managed in the protocol, there is the need to explain
an important metric that has been developed along with the protocol. This metric is
called the Delivery Likelihood.
The delivery likelihood of a packet is the probability that a packet has to be delivered
to its destination at the time that it is being carried by a node. This delivery likelihood
is an estimation and is constructed using the historical information about encounters
of all the nodes that the current node knows. Each node in the network, maintains a
table of probability of having an encounter with other nodes. This table is updated
each time the node encounters another node, making the probability of encounter of the
encountered node to increase. Also, each time that that nodes encounters each other,
those nodes, interchange its table. It does not matter that nodes have data without
being updated, because those tables tend to converge and present little differences (the
explanation to that will be later when talking about how the network was tested).
Then, to make the explanation of how the delivery likelihood of a packet is calculated
simpler an example is presented. Supposed you have four moving nodes A, B, C and D
that go around. A wants to send a packet to D, but has never had an encounter with D.
However, A has already encounter B and C. And B and C have encountered another few
times D, and they also know each other. Then the estimated delivery likelihood (EDL)
will be the addition of all the probability of all the possible paths. In this particular
example there are four possible cases:
1. A ⇒ B ⇒ D
2. A ⇒ C ⇒ D
3. A ⇒ B ⇒ C ⇒ D
4. A ⇒ C ⇒ B ⇒ D
So, the EDL of the packet would be the probability of the packet to be delivered following
one of the those cases:
EDL = P (case1) + P (case2) + P (case3) + P (case4) 5
The EDL is used to prioritise packets. How? As it has been said, the bandwidth in each
encounter is a precious resource so each time that two nodes encounter themselves they
interchange as much packets as they can (in fact, copies are sent so original packets are
retained in the transmitter node). Now, following the idea of the developers, because the
amount of packets to transmit is limited, some kind of packet selection is needed. There
is where the EDL comes into play. The carried packets are store in an ordered queue.
The queue have first the packets that have traversed lesser nodes. Each packets have a
hop count that says the amount of times that the packet has been transmitted to another
node for this purpose. The “lesser nodes” is set as a configuration network threshold,
that limit the packets that are placed first in the queue. After that, packets are ordered
by its EDL. The ones that have a greater EDL, and thus have more probability to be
delivered, are first transmitted. The threshold is added to give new packets an “impulse”
into the network.
The ordered queue is not only important for the transmission but also for the storage
management (the other limited resource). As packets are transmitted, the buffers of
each node start to fill up. The mechanism implemented uses the already formed queue.
It drops packets from the other side of the queue where the packets are picked to be
5
Being P() the probability function, calculating each P(case*) only requires the encounter table, that
has the probability that a node X encounters a node Y. Then following with the example computing
P(ABD) would be: P (ABD) = P (AencountersB) ∗ P (BencountersD)
transmitted first. Thereby, packets with lesser probability of being delivered (lesser value
of EDL) are first discarded.
In the paper [11] the developers of the MaxProp protocol show with more detail the
mechanism of it and they explained how the protocol was deployed in a real network
of thirty buses over an urban area of one hundred and fifty square miles. The buses
are used for the community of the town every day so they follow always the same path.
And for that is that it has been said before that the tables of encounter probability tend
to converge. However, as a comment, this do not limit the deploy of the protocol. As
it has been remarked before, people using particular vehicles also follow route patterns
making the algorithm also applicable to cars.
2.7.7 Encounter Base Routing
The Encounter Base Routing (EBR [7] ) is an encounter-statistic, quota-flooding base

protocol. The protocol tries to control the flooding by creating just a controlled amount
of replicas. It also use a store and forward style to route the packets.
The EBR says that the future rate of encounters of a node, can be roughly predicted by
its past data and that nodes that has a large number of encounters have more chances
to encounter the destination of a packet, or to encounter another node that will.
So, the protocol is based on this assumptions and thus have developed a property for each
node that has to be with the history of encounters of the protocol: the EV (encounter
value). The EV is calculated as follows:
EV = α ∗ CW C + (1 − α) ∗ EV
Where CWC is the current window counter, which counts the amount of encounters for
a node in a given period. Each nodes starts counting the encounters with other nodes
until the CWC timer triggers. When that happens, the 2.7.7 is applied to update the
EV, CWC become zero and the timer is set again. As the time pass, the EV reach its
actual value for the network and become stable. The α is a constant between zero and
one, that weights how the EV is updated by the most recent encounters. With values
closer to one, the EV will consider more the recent changes in the encounter history,
whereas the closer values to zero will make the EV more resistant to possible encounters
anomalies during small periods of time.
Now, How is this property used? When a packet is created, it is created with N replicas
of it. This N value is a given constant value for a particular network configuration and
can depend of the size of it. Then a carrier node receives the packet with its replicas.
It transport them until it encounters another vehicle. When that happens, the nodes
interchanges their EV values. Suppose that node A has a EVA of EV and the node B
has EVB and that a packet is being carried by node A along with replicas for a total of
m. Then, A will end up handing to B a number of replicas of the packet as the following
equation:
EVB
m∗ EVB +EVA
The rest of replicas will be continued carried on by A.
For example, suppose that A is carrying 10 packets and has a EV value of 20 whereas B
has an EV value of 80. Then A will handle 8 replicas of the packet to B, and will continue
carrying 2 replicas of the packet. With this example, it is really easy to understand how
the protocol make preference for the nodes that have met more nodes. Thereby, nodes
with greater values of EV will end up carrying more replicas of packets and the packets
will be more likely to be delivered to its destination because those nodes are more likely
to meet that destination node. Another thing to remark is that, as it has been said
before the number of replicas of the packet is constant all the time, thus acting as a
mechanism of flood control.
2.8 Data Mules
Data Mules is a field strongly related with sensor networks. In fact, they belong to a
subgroup of wireless sensor networks. At first, there was a problem to a particular case
of wireless sensor networks (WSNs) that have lead to a new sub field of study, that it is
being presented here. The problem was that the sensors were distributed in a really big
area so there were no contact to form an ad-hoc network among the sensors. A sensor,
may have contact with another sensor of the network, but that was not the general rule.
In this cases, one thing to do is to install more sensors in order to make all sensors
become connected. Sometimes, this is a really expensive and not feasible solution. The
other solution is to use mules.
This field defines two type of nodes. Sensors and mules. Sensors have energy constrains,
use short range radio to communicate with other nodes and are geographically fixed in
the network. On the other hand, mules are energy renewable (that is to say, in practice,
no energy constrains) and they move around in the network. In a mule network, mules
goes around in order to make contact with sensors and collect all the data from them.
After collecting some data, mules nodes will eventually bump into another type of nodes,
called access points, where the mules “discharges” all the data from sensors that have
been collecting. This system can be seen as a one where the sensors are the sources
and the access points are the sinks and the mules get packets from ones to the others.
Needless to say, that this kind of intermittent connectivity do not let transport protocols
like TCP work over this networks. First, the latency of this kind of networks manages
other order of magnitudes that the ones expected by TCP. Moreover, this networks are
consider to be half-way; that is to say, packet only go in one direction: from source to
sink, from sensors to access points. So over this networks, simpler transport protocols
like UDP are generally used. Because this network are not 100 % reliable, they are
intended for application where it does not matter if some data packets are lost.
In general, works related to this field, focus on the energy constrain issues and how
they can increase the ratio of data delivery when minimizing the energy consumption
in the sensor nodes. For example in work [24] a three tier architecture of data mules is
described and simulated. Access points are distributed in a large grid where mules moves
randomly collecting data from them, and delivering the packets to the access points. In
that case, the developers have tried with different size of buffers from the mules and
sensors, density of access points, number of mules, among others. All this alternatives
are always compared among them using what is defined in the paper as the data success
rate that is the percentage of packets generated by the sensors that actually reach an
access points.
The work [9] emphasizes more on energy consumption. It remarks that the largest
amounts of energy from the sensors batteries are consumed using the communication
radio device. So, they recognize that there are three major states in every sensor:
sleeping, discovery and transferring. The discovery phase is when a sensor is trying
to detect if a mule is in range for communication. The transferring is when a mule was
detected and the sensor is sending data to it. And sleeping is when the sensor is not
doing any radio consuming activity.
Mules go around of the networks sending beacons so sensors can hear them and notice
that there is a mule in range. But this is not straightforward. Mules do not stop in
order to collect data from sensors, so the time that the mule is in the range of a sensor
is limited. Not only that, that time during the mule is in range does not mean that
the sensor has it entirely to transmit data to the mule. Before starting to transmit
the data, it must noticed that the mule is in range. That depends on how often the
mules sends the beacons, that is to say, the period or frequency of the beacons. It
also depends on how much time the sensor spends on listening for incoming beacons.
Because, putting the radio device on listening mode is energy consuming (about half of
transmitting), sensors do not listen for beacons all the time. This leads to the definition
of a concept named duty cycle. The duty cycle is the percentage of the time that a
sensor is listening for beacons. Of course, the smaller the duty cycle the more energy
saved, whereas the higher values implies earlier detection of a mule. Thus, the higher
values of duty cycle with small periods of beacons leads to earliest detection of mules,
giving more time to transfer data from the sensor to the mule. However, this could
be really energy consuming, specially for the sensor. So these variables of a possible
data mule networks are a trade-off that must be evaluated for each particular network
considering its purpose, amount of data being generated, etc.
In [9] it could be seen some simulations that varies the beacon period and the duty cycle
simultaneously, getting different amount of time to transfer data. Another interesting
thing about that work is that they also try these things in different “types” of speed for
the mules. One for pedestrian speed (around 3.6 Km/hs) and other for vehicle speeds
(20 and 40 Km/hs). The point, with this last difference of speed is that at higher speed
the time in range of a mule for a sensor is smaller, reducing the capacity of data transfer.
As the intention of this thesis is to deliver data packets from sensors to access points,
it has to bee said that the proposal that is made here can be well fit in this category
of data mules (despite the energy consumption issue do not have a special focus in this
thesis). Also, the topic about energy consumption will be look over again in section
2.9.2, when talking about the WIFI standard for low energy devices in wireless sensor
networks.
2.9 The WiFi Standard
Despite our work does not put too much focus on the low layers of the architecture, it is
worth to review some of them. So, the physical and link layers are, for several reasons,
very important to take into account when designing a network architecture. There
is an obvious need of communication among different nodes that conform a network.
In particular the WIFI standard let devices communicate among them wirelessly. It
provides “recommendations” and rules for layer one and two in the OSI([4]) model
(physical and link layers) in order to make devices “understand” among them. The
WIFI has many advantages. First, it permits a communication among non fixed nodes.
It also lets people create cheaper networks that can grow really fast, because adding new
nodes do not required any new wired expensive and complex installation.
As many devices nowadays, there are more that one radio receiver installed in each of
them, so you can gather more than one type of communication in a single device. This
lets for example a mobile phone to have long and short communications (like G3 and
WIFI) or also different types of WIFI 6 . Then, as in the network that will be presented
in chapter 3 there are more than one type of node and, thus, more than one type of
communication to make nodes interact among them, there is the need to review the
different possibilities. This also leads to the possibility of having different types of
physical and link layers for each type of node.
In the following sections, there is an evaluation of the IEEE 802.11p and 802.15.4
standards to see if they fit the the need of our network. As it was said before, there is no
need to to choose one or another to the entire architecture, but to know if one can solve a
particular part of the architecture and the other can solve another part. Why these two
protocols were chosen and not others? Simple, as the architecture involves vehicles using
radio devices, the 802.11p standard is the preferred one for vehicle communication in high
mobility scenarios. In addition, as the architecture also involves sensors, the 802.15.4 is
the standard that first come up to deal with low energy device communications.
2.9.1 IEEE 802.11p
The IEEE 802.11p([21]) is an amendment to the IEEE 802.11 WIFI standard that defines
the physical and link layer in the OSI model. At the time this document is written the
802.11p has not been totally settled. There are many implementation details that are
left to the choice of developers. Despite of this, it is sure that this standard is going
ahead in vehicular environments.
As there is well known the IEEE 802.11 standard with all its versions permit certain
mobility between the actors that conform the network. Despite of this, neither version
of it (except “p”) consider high mobility scenarios. Moreover, in the wireless standard
there are two main possible architecture: the infrastructure basic service set(BSS) and
the independent basic service set(IBSS). In the BSS there are two kind of nodes defined:
stations and access points. Basically, access points advertise networks and the stations
connect to it. In this case, stations can not communicate between them until they
connect to an access point. On the other hand, in the IBSS, there is not just difference
between stations and access points. Merely, there is no access points, there are only
stations that manage themselves to communicates among them.
Curiously, there is some resemblance between this two types of architecture and the
vehicular to vehicular communication and vehicular to road side unit communication.
In fact, this is not a coincidence, it is just the need of different environments that leads
to different kind of solutions. Despite this, the 802.11p do not define different behaviour
6
WIFI is a group of wireless protocol standards and it has many variants for different needs.
for this two type of services. In it, vehicles and RSUs (road side units) are treated as
equals, and any difference must be made in upper layers. In other words there is no
infrastructure service, there is just an independent service where you can send a message
and if there is any node listening it will get it. But if there is nobody near, the protocol
does nothing about it. That is to say, to be sure of packet deliver there is the need of
implementing something above the standard. Having said that, it is important to remark
that this standard has focused on high mobility scenarios where there are just in the
order of tens of seconds or maybe less time to communicate among actors ( When it says
actors, there is intended to mean vehicles and RSUs, because the standard encompasses
both. As it was said before, it do not make difference between them).
However 802.11p leaves many options open to the users (maybe not final users, but to
developers). In fact, the standard only defines the range of frequency where the protocol
operates and the medium access control layer (MAC), but it says nothing about the flow
and error control (LLC layer [25]). For example, what happens when a message is badly
received? Do packets need to be acknowledge ? if a packet was not received correctly,
do the receiver should ask for a retransmission ? Do nodes wanting to communicate
themselves need to establish a session ? These are just some of the questions that the
802.11p does not answer, and thus have to be resolve in higher layers. However, this has
a purpose. As it has been seen before there are still many protocol going around and
many of them have really different requirements and need that the bottom layers stay
as flexible as possible.
For example, some protocols as SPRING use road side units whereas others that are
just ad-hoc style networks are set without the need of an access point. So, the standard
was left as basic as possible so it can be adapted to the majority of the routing protocols
that are in the market (and for those that will come).
Later, the reader will see how in the next chapter a simple thin layer to control neighbours
was proposed in order to provide some services to the protocols that relays over the
routing layer like neighbour discovery.
2.9.2 IEEE 802.15.4
The IEEE 802.15.4 standard is intended for personal wireless networks. It is also
intended for devices that do not requires to transmit big amounts of data, and thus
can work consuming little energy. Wireless devices consume energy while performing
many tasks. However, the most energy consume tasks that are found in those kind
of devices are the ones related to the radio transceiver. Basically, when the device is
transmitting data or listening for incoming data the device consumes too much energy.
So the focus in this types of technology is often put on reducing the time when the
transceiver is working.
Sometimes it is thought that radio device consumes when they transmit but do not
consumes to much when they are listening to incoming data. That is not true. It is true
that transmitting consumes more than listening. But the relationship is of only more or
less two to one. Having clarify this last point, the protocols that are implemented above
802.15.4 win when they put the radio device in complete sleep mode(radio transceiver
off). In those cases the current consumption pass from tens of mA to a few µA. That
is to say, when they manage to get values of duty cycle 7 close to 0%.
In order to put some concrete numbers to these networks, common devices that use
batteries could last a couple of years depending on its purpose. In addition, the
transmission of those devices can also vary from 40 kbps to 250 kbps depending on
the network configuration and of course having influence in the energy consumption.
The 802.15.4 standard specifies the physical layer and the MAC sub-layer of the link
layer in the OSI model. It defines the bandwidth and the range of frequency where it is
intended to work in. It also defines the CSMA/CA 8 mechanism to access the media.
But that is it. The above layers that defines very important aspects of a network like
topology and routing protocols are not mentioned. These aspects are provided by several
third party solutions like ZigBee ([3]), Contiki ([2]) or 6LoWPAN ([1]), just to name
a few. In particular 6LowPAN is a “compressed” implementation IPv6 for low energy
devices, that permits sensors to have IPv6 addresses and be accessible from everywhere
(that is the idea of the Internet of things 9 ). In fact, nowadays these technologies are
very popular because the cost of those sensors are becoming cheaper and cheaper with
the years, and many ideas and projects are arising. Also, there are a lot of solutions in
the market that produce a competence that is making these king of technologies reach
its edges. For example, Contiki in its last versions presented some modifications to the
802.15.4 standard in the discovery phase that permits lower duty cycle and thus and
improvement int the energy management (presented in paper [13]).
However, neither of those solutions mentioned above have been adopted in vehicular
networks. Despite those solutions are intended for mobile scenarios, that mobility, like
in MANETs, is not compare to the speed or the long interconnections that the vehicular
networks can suffer from.
7
Percentage of the time that the radio transceiver is on in order to detect that another node is trying
to transfer some data.
8
http://en.wikipedia.org/wiki/CSMA/CA
9
http://en.wikipedia.org/wiki/Internet of Things
But, what about the raw 802.15.4 standard ? In [23] and [12] the 802.15.4 was tested
in several scenarios. Some interesting test were made in outdoor and indoor places,
evaluating the performance of the standard in terms of range, throughput and transmission
performance (delivery rate). Also an experiment using bicycles was performed. It turns
out that the protocol is very sensitive to minor changes in speed and can perform really
different depending on those little changes like, for example, the body factor. The studies
has shown that, as the range of frequencies use in the 802.15.4 standard are very sensitive
to water environments (suffer from attenuation), and being the body of a human mostly
composed of water (80%), the transmissions vary substantially depending if the device
is being carried by a corpulent human or a thin one.
Moreover, some test where people were walking (speeds of about 2-3 Km/h) shows that
the 802.15.4 performs practically the same as if the nodes were static. However, the
faster the nodes move and thus go out of range the smaller the contact time leading to a
significance decrease of the amount of data that can be transmitted in each encounter of
the nodes. Then, this can lead to the need of detecting nodes earlier which requires an
increase in the duty cycle, and then an increase of the energy consumption. As always
this becomes a trade-off that the network administrator would have to set according to
its particular needs.
Chapter 3
Proposal: A Data Collection

Infrastructure
3.1 Introduction
The main idea of the DC4LED project is to provide a service to all the people that want
to deploy a relatively low amount of sensors in a vast area, without the need of having to
design the network or care about how the sensors can reach the Internet. The network
is offered as a service, so sensors of any type and for any purpose will share the same
infrastructure. From this point of view, the DC4LED network will provide connectivity
to any person without mattering if the person who want to deploy the sensors deploy
five or a hundred of sensors. Then, the people using the network will share the router
nodes and of course the cost of all the infrastructure.
This will be accomplished using the vehicles of the area. Particular vehicles (cars)
and public service vehicles (buses) will be “transform” in moving nodes. In particular in
moving router nodes that will collect the information from the sensors that are subscribed
to the DC4LED network service. In order to be compatible with the service and to
interact with those router nodes they will have to talk the same protocol that will be
further describe in this chapter.
Then, the chapter goes as follows. First, the infrastructure of nodes is described with
the characteristics and restrictions of each kind of node. Then, a protocol for node
encountering is presented to easily handle the event base nature of the problematic.
Finally, a simple routing protocol is proposed to make the data from sensors reach the
Internet through the router nodes.
34
Chapter 3. Protocol Proposal 35
3.2 Nodes Infrastructure
The network infrastructure of the DC4LED counts with different type of nodes. There
moving nodes like vehicles and there are fixed nodes like sensors and access points (AP).
All these nodes have different capabilities and restrictions. Not only that, different
nodes have different needs and because of that, they will perform a different role in this
network. In the following paragraphs, there will be a classification of the different nodes.
3.2.1 Fixed Nodes
All nodes that are fixed in location belong to these group. Nevertheless, nodes of this
group can have really different needs and characteristics. Sensors and access points are
both fixed to the same location all the time. However as we said earlier, they play
completely different roles in the network.
3.2.1.1 Access Points
Access points (AP) are placed in the geographical area where the network is deployed.
How they are distributed is beyond the scope of this thesis. However, a decision about
this had to be taken. For the first simulations access points have been placed randomly.
Then and last, a better approach was to put them at each end of each bus line. Having
APs placed there, assure that any packet being carried by a bus will eventually reach an
Access Point. Because one of the most important idea of the DC4LED project is to use
most of the already set infrastructure (like using the movement of the automotive fleet)
in order to reduce costs, this decision is related with the fact that in many cities some
bus stops have already some kind of connectivity. This leads us to the first property
of the access point. An access point has high Internet connectivity, so it can deliver
packets to the Internet directly, without any delay. This is because access points are
wired. Derived from that, an access point has also not energy constraints, which gives
us some margin when designing the infrastructure and the communication protocol.
3.2.1.2 Sensors
Sensors are electronic devices that generates specific application data. The sensors can
be placed anywhere because it is a decision of each sensor owner where to place them. Of
course that for each application, sensors will be placed following a particular pattern that
is related with the purpose of the application. Nevertheless, many sensors of different
type of applications are going to use the network service, and it is not possible for this
work to take into consideration all of the placement patterns. Then, here, placing sensors
randomly is an acceptable approximation of how they will be really placed.
As it has been said before, there are different kinds of sensors: temperature sensors, speed
cameras (the ones how takes photographic fines), rain gauge, among others. There are
also two big groups where the examples mentioned can fit: the ones that are wired and
the ones that are not. The sensors which are not wired work with batteries, making
them to have energy constrains that limits the software with which can be equipped. The
wired ones are considered to have unlimited energy and thus can be equipped with more
powerful hardware. In devices with no power constraints, data can reach the internet
using long distance communication like those belonging to the 3G technology family.
However this approach is not possible in devices with low energy, so a different type of
communication will be needed. In the current work the focus will be put on devices with
low energy, and thus without access to long distance communication technologies.
3.2.2 Moving Nodes
The moving nodes are all the vehicles that hang around the geographical area where the
network is deployed, and the network extends to as far as the vehicles can go.
In our work we make an important difference between cars and buses. Despite their
almost equal technical characteristics these vehicles have different behaviours. Buses
follows always the same routes and follow an strict schedule whereas particular cars do
not. Moreover, buses are running almost all day while a regular car goes to a place,
stays for a while and then goes back to the same place (a common person that goes to
work by car), and some times make different trips. However, this work does not try to
investigate and analyse the behaviour of particular cars moving in a city. For now, it is
enough to mention the difference. But in the simulation section we will come back to
this topic and go deeper because these differences will modify the way these vehicles are
going to be model.
3.3 Challenges
Having seen all the nodes and their characteristics, now the challenge is how to make
them interact so the data generated at the sensor could reach the access points to, then,
be forwarded to the Internet. It is clear that the buses and cars will pick up the data
packets from the sensors and they will then handle those packets to the access points.
However there are two main unknowns: how the vehicles will recognize each other and
what they will do in that situations. The first is related to the technical aspect of how,
for example, a router node realize that it is in the presence of a sensor node. The other
has to be with what is the specific behaviour of, for example, a sensor node in the case
that it encounters (and realize that is in the presence of) a router sensor. In this last
case the behaviour is easy, the sensor should give all their data packets to the router
node. However, not all the cases are as simple as this example, and of course, to make
a protocol all the cases have to be detailed.
The first unknown, presented as it was presented does not look problematic. However,
the nodes involved in this network has to deal with a moving environment that make
nodes to appear in range of other for really different period of times. For example, a bus
can cross a car going in the opposite direction making the contact time 1 of those nodes of
a couple of seconds. On the other hand, a bus can pull over to pick up some passengers
or just stop because of a light signal making the available time for data interchange
much longer.
The second unknown, is basically the core of all vehicular routing protocols: the routing
decision. That means, what a router node have to do when it receives a packet from
another node. And again, as the nodes are in a constant moving environment where
the topology of the network change every second the routing protocol has to deal with
the fact that it could be connected to many nodes or none and still deliver the packets
properly.
The first problematic will be addressed in the following section 3.4 while the other will
be addressed in the 3.5 where a routing protocol for the DC4LED network is proposed
and explained.
3.4 Encounter Layer
Having read many papers that try to route packets in a VANET, there was obviously
some implicit ideas and concepts that were repeated in each report and that stay constant
among them. But there was one concept in particular that was in all the routing
protocols. This happens to be what it is called an encounter. Many surveys on routing
protocols present performance information about their routing protocols. But they do
not specify how these routing protocols, and in particular each actor of it, manage to
perform the communication among them. An encounter is an event that occurs when
two nodes meet. In terms of our subject, an encounter is when a node discover that
1
period of time in where two nodes are able to communicate because they are in a range that lets its
radio devices to receive the other node signal
there is another node close enough so they are capable of communicating with each
other. This encounter concept leads to the already mentioned concept of neighbour.
An encounter happens when a node turns into a neighbour of another node becoming
that last node also a neighbour of the first node. To put it simply, two nodes become
neighbours when they encounter each other. This encounter concept applies to moving
nodes and static nodes. That is to say, two vehicle nodes can become neighbours such
as a vehicle node and a access point node (note the difference between the moving node
and the static one, respectively). So, these two concepts apply to all kind of nodes that
have intermittent contact with each other.
3.4.1 Importance of the Encounter and Neighbour Concept
Without being specific, when you have a routing protocol in a VANET the exchange of
routing information and the resultant exchange of packets its trigger by the nodes that
discover each other: an encounter. For example, when a bus run into a sensor or an AP
and the sensor gives packets to the bus or the bus delivers the packets to an AP this
happens because they have realised that they have become close enough to interchange
information. That is to say, they became neighbours. In fact, the encounter is the
principal event that triggers most of the main actions in all routing protocols.
This concept is really important to routing protocols in our work and in others VANETs
routing protocols because it can change the behaviour of them. How can this action or
concept have a great impact in the performance of a routing protocol ? An encounter
could last from some seconds to a few minutes and the amount of information that one
node could transfer to another dependent linearly with the duration of the encounter.
So the longer the encounter last, the more amount of packets can be transmitted. If the
nodes have many packets to deliver and the encounter does not last enough, it could
lead to packet drops and consequently a decrease in the performance of the network.
Hence, the duration of the encounter depends of many things. The nature of the situation
itself, is one of the things that has great impact in the duration. It is not the same
having two buses crossing each other in opposite ways than going in the same way or
being stopped in a red light. The first one can last five seconds whereas the other two
can last more than a minute. Another thing that can vary the duration of the encounter
is the procedure that determines that a new node is near another one, that means the
detection of the encounter. This procedure occurs at a logical link control layer in the
upper sublayer of the second layer of the OSI model (some people may consider that
this logic should be in an upper layer of the OSI model, but this is a discussion in which
we are not interested in participating, and for us this mechanism belongs to that part
of the model).
Unfortunately this kind of procedure is not defined in the IEEE 802.11p standard, which
is the standard that have gained power the last years for vehicular communications. This
standard encompasses the first layer and a part of second layer of the OSI model, but
does not include any specification regarding the logical link control layer (upper sublayer
of layer two).
Figure 3.1: The IEEE 802.11p and the Encounter Protocol covering 1 and 2 layers of
OSI model.
Having said that, an algorithm for detecting and maintaining encounters has to be
developed. Some procedures for this purpose are described in many papers. However,
this is not a simple field because there are different types of these procedures and each
of them complies with different requirements and of course have different constraints.
Regarding this type of procedures the IEEE 802.15.4 standard follows a neighbour
discovery procedure that focus in energy consumption because it is intended for wireless
low energy devices. But, can it be implemented in this case? The 802.15.4 is not
intended to high mobility scenarios, and some studies have shown that this standard is
not proper for medium mobility scenarios (seen in chapter 2).
As it has been said before, the amount of data interchange in each encounter depends of
the duration of itself. So the earlier a node detects when a neighbour is near by, the larger
amount of data can be transfer. However, choosing among different neighbour discovery
procedures will always end up in a trade-off. The ones that consume more energy will
discover neighbours earlier that the one with a lower consumption (remembering the use
of low energy device for which this project is intended). And the other way, the lower
consumption it will generally becomes in a later neighbour discovery.
Finally, in future works it could be possible to easily implement other routing protocol
and add it to the platform developed in this work (see chapter 4) in order to be able to
compare the performance of the routing protocols one against the others. And, as the
idea of encounter is used in all routing protocols, having an encounter interface/protocol
make the implementation of the routing protocols much easier. Therefore, in the next
section, there will be presented a simple encounter protocol/interface to handle these
needs.
3.4.2 Encounter Protocol
The encounter protocol is supposed to be designed and implemented as an easy-to-use

interface between the link layer and the routing layer from the OSI model. With this
kind of interface it would be relatively easy to implement a routing protocol that involves
intermittent connections, and in our particular case vehicular networks. The encounter
protocol is based in events as the nature of an encounter between two vehicles is also
an event. Basically, the Encounter Protocol proposed here will make that when a node
is close to another node, the first node, will be notify of the presence of the other node.
And the second node, will be also notify about the first node. So, both nodes will be
noticed that they have become neighbour.
The new neighbour (node) will be registered and the status of it will be kept as long as
they stay neighbours. That is to say, until the node become no longer reachable because
it has gone away from the radio communication range. During the state of neighbour
in range higher layers can send/receive packets to/from the new neighbour. In the next
section, a more detailed view of the protocol is presented focusing how states and logic
transitions between them are made and the hypothesis taken into account for it.
3.4.2.1 Neighbour Status and Encounter Table
In the encounter protocol each node periodically sends beacons to announce others that
it is in the surroundings. As soon as any node listen to that beacon, the receiving node
triggers its new encounter callback (which is registered by upper layers to perform its
own particular behaviour) and send back a beacon ack. This ack informs the beaconing
node that a new neighbour is in range. From now on, both nodes knows that they have
become neighbours. In figure 3.2 there is the sequence of packet interchange for the
neighbour discovery mechanism for a node encounter.
To keep track of the neighbours every node maintains an encounter table. This table
registers the neighbours on it using its mac addresses. As long as a neighbour is in the
table, it is supposed to be a neighbour in range (meaning, it can be reach if the node send
a packet to it). At the same time, when a new neighbour is registered in the encounter
table, an expiration timer is set to that neighbour. If the timer expires, the neighbour
is removed from the table and not more packets can be receive/send to/from that node
Figure 3.2: Neighbour discovery in the Encounter protocol.
without triggering the new encounter callback (and starting the whole procedure again).
To maintain the neighbours alive in the encounter table, each time a node received a
message from another node, the expiration timer for that node is reset. Because of the
periodical beacons, even though data packets are not sent between the nodes, if the
nodes are in range the aliveness of the neighbours in the encounter table is assure. In
figure 3.3 are shown the states and transitions of the neighbours of a node according to
the mechanism described here.
3.4.2.2 Passive Encounter Protocol
The Encounter protocol is compatible with itself. It means that to make two node
communicate between them there is no need to have a server and client encounter
Figure 3.3: States and their transitions of a neighbour in a node in the Encounter
protocol.
protocol in each one. Installing and configuring the same encounter protocol in two
different nodes assures their communication.
Despite of this, as it has been said before, not all nodes have the same purpose and
restrictions. That is why a Passive Encounter Protocol was also developed for a specific
type of nodes. This version of the protocol is totally compatible with the other regular
version of the Encounter Protocol previously described, but it is not compatible with
itself. This means that one node using the regular Encounter Protocol and other using
the Passive Encounter Protocol can perfectly communicate with each other, but two
nodes using the Passive Encounter Protocol can not. This is one of the drawbacks of
this version of the protocol, and it was intended to be like this because this drawback
brings wit improvements in terms of battery consumption.
The Passive Encounter Protocol has been aim to sensor nodes which have battery. As a
result of this last constraint sensors are not allowed to communicate among them. This is
a strong restriction to this version of the protocol. However, as this protocol is intended
for sparse sensor networks, sensor nodes are rarely in range reducing the possibilities
of interaction among them. Besides, remembering the goal of the DC4LED network
service, nodes do not need to communicate among them, they just need to reach Internet
(probably sending data to some kind of centralized server that regroup the information
from a bunch of sensors). Then, this drawback turns on not being a inconvenient for
the network. In fact, not letting sensors communicate each other could be an advantage
because it would make sensor nodes not to waste energy in communicating among them
as they may not play a routing role in the network (and in fact, this is the case, the only
nodes with the capability of routing are the moving nodes as it will be see in the next
section 3.5).
In terms of behaviour, the difference between Passive Encounter Protocol and the regular
version is that the first one does not send periodic beacons to inform neighbours that
the node itself is near. This is done in purpose in order to make sensor nodes (that use
this Passive Encounter Protocol ) to consume fewer battery.
But, with this change, does it takes enough to be compatible with the regular version?
When a node with the regular version of the protocol is in range of a node with the
passive version, beacons becoming from first node reach the last node. When the passive
node received a beacon, it immediately sends an ack beacon to the regular node. So, in
this case, both nodes are in knowledge of each other. One thing that is compromised
is the liveness of the passive sensor in the encounter table of the node with the regular
version of the protocol. In order to reset the expiration timer, packets from the passive
node to the regular node are needed. The problem is that if the passive node has no
data to send, the expiration timer will be triggered without nodes being out of range.
Also, the passive node will know about its neighbour (because of the regular beaconing)
but the neighbour will not know about the passive node. All this seems to be a great
catastrophe. But it is not that bad. There should be remember the aim of this version.
It is intended to be installed in sensor nodes where the data usually flows from and not
to. Let’s see a typical situation, where a carrier node (using the regular version of the
protocol) encounters a sensor node. Supposed that it has been a while from the last time
the sensor encountered another node, so it could have accumulated some packets. As
long as they realised they are neighbours, the sensor node starts to send all its packets
to the carrier node. As long as the packet transfer occurs, the carrier node has reset the
expiration neighbour timer for each packet received. After that, there is still enough time
to the carrier node to send some routing/control packets to the sensor node, because
this type of information is generally much shorter than data packets. Indeed, there is no
need to make this happen at the end, this kind of information can be interleaved between
the data packets that the sensor send. After that, both nodes have served its purpose.
Having said that, the possible desynchronisation between a passive and a regular node
is a cost that we are willing to pay in order to save battery at the sensor extending its
life.
3.5 Routing Layer
With the Encounter Protocol presented in the last section, nodes are now available to
communicate with their immediate nodes; their neighbour nodes. However, the aim of
the DC4LED is to lead the data flow from sensor nodes to the APs (reaching Internet
through them) and until now, unless a sensor node is near an access point, it can only
communicate with neighbour nodes that will probably not be APs. In other terms, the
protocol presented before is only responsible to establishing communication links among
the nearby nodes.
Therefore, the responsible to guide a data packet from the sensor node across carrier
nodes to reach an AP is another protocol that seats above the Encounter Protocol. In this
part of the chapter it is proposed a simple routing protocol to deal with the problematic
of transporting the data packets to the APs.
3.5.1 A Simple Routing Protocol
The scenario where our nodes live is very changeable. Connections between most of the
nodes are intermittent and often disconnections (produce by the nature of the moving
vehicles) could last a long time. In a regular router, like the one that people have at
home or the ones used to interconnect zones in the big network Internet, each time that
a packet arrive at the router the router looks in its table, for the next node to make
the packet one step closer to its destination. This process is repeated until the packet
reach its destination or the packet is discarded because the router could not find a next
node “closer” to its destination (a dead end). For those kind of routers one possible
case of not finding a route for a particular packet could be because the router had
lost connection with the “next” node. This nodes are prepare, because of the protocol
that they use, that for those cases packets are dropped. But for this type of networks
this behaviour is acceptable because nodes do not suffer from intermittent connections
like our environment. In fact, applying the protocol that Internet use for this moving
scenarios will end up with a packet drop close to 100 %.
Then, our routing protocol need to tolerate this fast connections/disconnections. As

it has been seen in chapter 2 there are the VDTN protocols that handle those moving
environment. In fact, in that chapter there have been seen really complex protocols with
sophisticated routing decisions based on different kind of information. However, in our
case, the intention is to evaluate our proposed network service with a simple routing
protocol.
This protocol has been called Simple Vanet Routing Protocol and it has a few basic
rules to transport packets from the sensor nodes to the APs. This protocol only use
the information of the type of the nodes that were describe in section 3.2. Knowing if
a node is a sensor (produce data), a carrier node (a bus or car) or an AP the protocol
will behave different.
The main flow of a packet being transported from a sensor to an access point is as
follows. An application installed in a sensor generates a data packet. The data packet is
sent to the routing layer. The routing layer tries to send that packet to a carrier node or
AP if there is one nearby. If there is non, then it saves the packet in an internal queue
until a new carrier node or AP is encountered. The case where the sensor encounters
an AP is the simplest. It just send the packet to the AP, who then will immediately
deliver the packet to the Internet (it has to be remember that APs are wired connected
to the Internet). In the case that a carrier node pass by the sensor and they encounter
each other, the sensor hands the packet to the carrier node. The carrier node will save
the packet in an internal queue continuing with its trip. Then when the carrier node,
encounters an AP, it will deliver the packet (and of course, all the data packets that it
has in its internal queue) to the AP. And that is all. One thing to notice is that despite
sensor nodes that are fixed to the ground, carrier nodes have much more possibilities
of encountering an AP. In fact, a sensor node that does not encounters an AP at the
beginning of its “life” will not find an AP for the rest of its existent (except the case
where a new AP is installed near it, but this can take years or never happen).
This basic flow has some small considerations regarding carrier nodes. These considerations
are shown in figure 3.4 where the main three cases of data delivery are represented. In
the first case, the data packet is picked up by a bus, and the bus continue with its trip
until it finds an AP, in which case the bus hands the packet to the AP, finishing the trip
of the packet int this network. In this case, the bus makes its trip without taking into
account interactions with other possible carrier node (at least with what matters to this
particular data packet).
Figure 3.4: 3 different possibilities of data flow with the Simple Vanet Protocol.
In the second case, the data packet is picked up by a particular vehicle, a car. This car,
continue its trip without encountering any other bus node until it finds an AP. Again,
as the first case, the carrier node, in this case the car, hands the data packet to the AP,
finishing this case.
In the last case, again, the packet is picked up by a car. However, during its trip the
car encounters a bus node handing the packet to it. Then the case finish as the first
one. This only happens when a car is carrying a data packet and not when the node
is a bus. This distinction is made because, as it was said before, the only information
to make routing decisions is only base on the type of the node (the four types of nodes
are: sensors, APs, cars, and buses) and in the fact that buses are more reliable than car
nodes as buses have longer trips (public buses goes all day) and because the protocol
assumes that buses will eventually find an AP within a certain period of time. This last
assumption is related with the placement of the AP nodes, that at least are supposed
to be put in some of the stops of the buses (this topic will be re seen in section 4.4).
Summarizing, once a packet is transfer to a bus node, the bus continue its trip until it
find an AP. And when a car is the one that picked the packet, it will deliver the packet
to an AP unless it first encounters a bus, in which case it is that bus that will finally
deliver the packet to an AP. So,Once a carrier node have picked up a data packet
There was mentioned that car and buses are types of access points. In the general case
those types of nodes are also cars and buses respectively. Nevertheless, a car node could
be a motorbike or a bicycle whereas the role of bus node could also be play by for
example a tram. To play one role or other they have just to fit in the characteristics
described in section 3.2. In particular, for bus and car nodes, the relevant difference
between them is the periodicity and predictability of their behaviour (movement).
One question that may arise is if the sensors generate packets addressed to a particular
AP. The answer is no. The only thing that matters to packets is reaching the Internet.
They do not care if they reach it through a particular AP. So packets are addressed to
“any AP” (the first one that appears in the way of the carrier node).
One thing to clarify is the fact that this protocol only works in one direction or way.
The flow of the data packets is from sensor to APs and not the other way, as this last
case is out of the scope of this work.
Here there are detailed, according to the Simple Vanet Routing Protocol, the expected
behaviours of each type of node from their own point of view, depending whom it
encounters:
When a Sensor encounters :

• a bus, it sends all its data packet to the bus.
• a car, it sends all its data packet to the car.
• an access point, it delivers all its data packet to the AP.
• a sensor, it does nothing.
When a Bus encounters :
• a bus, it does nothing.
• a car, it waits for data packets from the car as it were a sensor.
• an access point, it delivers all data packets to the AP.
• a sensor, it waits for data packets from the sensor.
When a Car encounters :
• a bus, it sends all data packets to the bus.
• a car, it does nothing.
• an access point, it sends all data packets to the AP.
When a Access Point encounters :
• a bus, it waits for data packets from the bus.
• a car, it waits for data packets from the car.
• an access point, it does nothing.
3.6 Implementation of the Protocols
Both the Encounter Protocol and the Simple Vanet Routing Protocol were implemented
for the ns3 simulator platform. The code for that implementation can be found in a
public mercurial code repository here 2 . Further information about the implementation
can be found in the next chapter in sections 4.5.2 and 4.5.3.
2
https://bitbucket.org/pablin87/ns3-sumo-vanet-simulation
Chapter 4
Simulation Platform
4.1 Introduction
The protocol have already been presented. Now is time to test it and see how it performs,
not in a real scenario because of the incredible costs that it would carry but in a simulated
one. That is the reason why this simulation platform was developed, to see if in the
technical aspects the DC4LED project is feasible using the Simple Vanet Protocol. The
development of the simulation tool that was done is one of the biggest contributions of
this thesis as a great part of the time was put on it. It lets the user to generate a grid of
roads by where different vehicles can go, configure the protocols that have been presented
in the previous section and run simulations with those parameters. It also comes with a
set of analysis tools that collect the raw output data from the simulation and generates
statistic information about the performance of the protocol during the simulation. Of
course, you can set different types of vehicles and grids to get scenarios with different
characteristics (like dense zones or more rural ones). It also lets you change the density
of access points placed in the generated map to see how the performance change.
In the following sections the reader can see how the platform was developed and where
and how settings can be change to achieve different simulation scenarios. In this chapter
it is also described the steps that have been walked to accomplish the simulations of the
protocols analysed in the document. As this work in terms of simulations aspects covers
network and vehicles movement, there is the need of using a tool that provides both
or to integrate others that manages each specific aspect separately. So in the following
section there area presented the tools that were chosen for the traffic part and for the
network part of the simulation.
48
Chapter 4. Simulation Platform 49
4.2 Selection of tools
As it was hinted before, it was decided to treat the movement part and communication
part of the simulation separately. This permits to use special tools on each of the
aspects involved for this work: the traffic part and the network/communication part.
This election was made because there was not a well-known tool that integrates both
traffic and network parts that were easy to configure and use. Not only that, being able
to treat those part of the simulation separately gives the user bigger flexibility when
trying to adapt the tools to its own needs. So one traffic simulator and one network
simulator were chosen to be integrated and are now presented.
A free open source traffic simulator named SUMO has been chosen in order to generate
the movement of the different nodes of the vehicular network. For the communication
between the vehicles and other nodes of the DC4LED network a free open software
network simulator named ns3 has been chosen and it is in this tool that the Encounter
Protocol and the Simple Routing Protocol have been implemented.
Figure 4.1: In broad terms, how the integration of the tools is made.
Broadly speaking and as it can be seen in figure 4.1, the main process of the whole
simulation follows these steps: first the SUMO framework emulates the movement of
the nodes. But before, the map and the nodes have to be created in order to feed
the traffic simulator. After simulating the movement in SUMO, the output is used as
input of the ns3 simulator, who equips the nodes with communication capabilities (radio
devices) and install the “software” of the protocols that were presented in the previous
chapter. Then, after getting the simulation data from the network simulator output,
the processing of this data is done to correctly present the results. Some scripts for the
analyse of this output is presented in the next chapter.
4.3 Sumo: a Traffic Simulator
SUMO (Simulation of Urban MObility) is a traffic simulator that permits to simulate a

large road networks with a great amount of vehicles on it. It is highly configurable, but
still easy to use. To construct simulations SUMO uses xml files as input. Through these
xml files you can specify the shape of the network road and the vehicles that you want
to go through that roads. For doing so, SUMO counts with several types of input files.
One of the most important is the network file that contains the description of the
streets and highways. These xml files contains nodes that have geographical coordinates
to placed these nodes in a map. The edges are used to make streets or highways by
connecting two nodes. As different roads have different characteristics like speed limits,
quantity of lanes, and, of course, can be single way or both ways, those edges have many
properties that represents those different kind of properties for the roads.
There is also the route file which describes the vehicles with their routes that will
traverse the road network described in the network file. A basic route file can have a car
with a starting time and a set of roads that defines the route. So many (and probably
all) the scenarios can be described with those two files. It is just a matter of making
them more complex (more roads and more vehicles starting at different times and having
different routes).
These are definitions with their own characteristics that you can find in a route file:
• Vehicle types with their respective speed, acceleration, carfollowing model and
size.
• Routes with the roads that it contains.
• Vehicles with their respective routes, when they start to move, when they finish,
behaviour of the driver, etc.
A typical example of a route file can contain some definitions of vehicles types named bus,
car and motorcycle. Then routes from some random road to other random destination
road are created. Finally, some traffic is depicted using those vehicle types and routes.
For example, one possible traffic flow could be:
1. Start at time 120 seconds of the simulation.
2. Be a bus type vehicle following some route defined before.
3. Finish when the final road of the route is reached.
Other type of files that SUMO accepts are the trip and flow files. These kinds of files
are used to easily describes traffic flows. In other words you can specify a type of vehicle,
a starting and ending road and SUMO will automatically create a route between those
roads using the shortest path. You also can specify the frequency of the vehicles to
be created and how many do you want to be created along the simulation. With this
information SUMO will automatically spawn, during simulation, as vehicles as they are
described in the flow or trip file.
In a flow or trip file you can find the following definitions:
• departure time of the first vehicle to be generated.
• start road and end road from which SUMO will construct a valid route, and that
all vehicles specified in this file will follow.
• the periodicity with that vehicles will be created.
• the quantity of vehicles to be created.
• type of vehicle.
In addition, there are other SUMO files that provides other tools to describe the simulation
but there are not relevant for us the above ones are enough. So we are just going to
mention some of them. There is an edges file that let you define different type of
roads. For example you can define a school road with a speed limit of 20 km/h and
another called super highway with a speed limit of 180 km/h. This will let you build
a more complex road network assigning to each road an edge type (edges are the roads
in the network file) defined in this file. This file also let to share road types among
several simulations or to share it with the SUMO community. Finally, it is mention that
there is also a traffic light file that permits you control the duration and phases of the
traffic lights during the simulation. But here, that level of detail to manage the traffic
simulation is out of the scope of this work.
4.3.1 Simulator Output
It has been presented how you can described a road networks and the traffic that will go
through it but nothing has been mentioned about what can you get from SUMO. SUMO
comes with a graphical tool called sumo-gui that let you see in real time the simulation
itself being developed. This is very helpful to verify the construction of road networks
and the generation of vehicles and their routes at a small scale. This can also be applied
at large scale, but for really big cases it can become a bit difficult to analyse what is
happening. That is way SUMO can generate other types of outputs that will help you
identified problems like bottlenecks and other traffic issues. Nevertheless, in this work
the interest is not putted in traffic problems. The idea is just to get the movements of
the different kind of vehicles in order to, then, use this as input of the network simulator.
Luckily, SUMO can export a detailed information of each vehicle at every step of the
simulation (the step of the simulation can be customized). This let you know where are
all the simulated vehicles at each time (specifying two coordinates in the xy plane), with
the precision that it is needed. In fact, there is a particular option in SUMO to generate
an output that was particularly designed to fit the needs of the ns2, the previous version
of the simulator that is being used in this work. And, of course, this output file is also
supported in the ns3 and is the one that is used to integrate this two simulators.
4.4 Building the Scenario
Before talking about the network simulator, it is important to know how the scenario is
created and what tools and methodologies have been used for that purpose.
The general idea to integrate this set of tools is depicted in figure 4.1. There are two
first main steps: the generation of the map and the generation of the movement of
the nodes. Speaking in terms of SUMO, the first step corresponds to the generation
of the road network and the second step to the generation of the different routes of
the vehicles. These both process have to create a file describing the roads and the
vehicles that are going to be the input of SUMO. After that, SUMO will generate a
trace file containing the position of each node at each moment of the simulation. A
small clarification regarding this last phrase: when it is said “at each moment” it means
that the position of each vehicle is given at each simulation step that could be one
second, two seconds or a hundred milliseconds. This is a trade-off. The smaller the time
division (time step), the more the scenario will take to produce the output of simulation.
As the simulation will last in the order of some hours, choosing a time division between
of a half second and hundred milliseconds is enough for the accuracy expected.
4.4.1 Scenario Description
Being SUMO the tool chosen to generate and simulate traffic, there is more than one
way for constructing the scenario. One possibility is to import a piece of map from
the openstreetmap project [6]. This site contains a world map, which is collaborative
constructed by their own users and is available to anyone. It contains not only information
about streets and routes but also about buses lines, buses stops, buildings, pedestrian
paths, bicycle paths, metro and more. In fact, as is an open tool and is based on
agreements between the people that make it, any kind of information can be easily added.
One interesting thing for our project is the fact that many people has charged information
about bus stops and bus paths. In addition to that, many transport companies have
opened their databases to encourage people to make different applications exploiting
their transport data. For example in [5], there is static data about bus lines and metros,
like stops and stations, timetables among other things and a public web interface (api)
who has dynamic information about position of every unit at each time. The reader can
imagine that with all these information put it together a very detailed representation of
real traffic in cities can be achieved. However those tools are not perfect. One problem
of the openstreetmap project[6] is that many times the information is not accurate or
is missing. So, integrity of data must be somehow check (a clipped path of a transport
unit can be difficult to deal in simulation environments).
Despite of all the possibilities opened with all that information, for this work a simpler
way of generating traffic and routes has been chosen. Nevertheless, the approach of
using real information from real cities could be take into account in a future work.
Then the scenario is as follows. The simulation map that was chosen is a simple grid
of n by n blocks. Road side units (access points for our network case) and sensors are
randomly place along the grid. Also the paths of the buses are randomly generated as
those from the particular vehicles, even though the former ones are specially designed
to try to traverse long distances along the city map. Like in a normal city, this is an
expected behaviour of buses as they are a public service and they are supposed to bring
“connectivity” to all the city. In the next sections there will be presented in a more
detailed way how exactly the vehicles and the placement of the other static nodes are
made.
But, is this enough for representing a real city ? The fact is that this work does not
pretend to be really accuracy in terms of streets distribution. Despite of that, there are
a lot of cities, for example in America where the plan of the city is presented as a grid
map. So, this generated grid map can be a good approximation of an American city
downtown, with lots of vehicles and buses going around.
4.4.2 Generating the scenario
To put the ns3 and SUMO simulators together some file process is needed. To accomplish
those processes the language python was selected to be used. The choice of python was
because python has became one of the most popular programming languages and because
it is the favourite of the one who is writing this work. The scripts corresponding for
building the scenario are placed in the sumo folder of the Vanet platform project (which
is the name of the simulation framework that was created). The script that generates the
scenario is called grid generator.py and comes with a configuration file. This setting
file lets you customize the simulation. In the next sections there will be referenced
the different parameters that can be modified and what implications they have in the
scenario.
The platform is located in a public mercurial repository. There is a How-to document in

the appendix A of this thesis that have the path to the repository and the instructions
to compile the platform along with its dependencies. It also has a small paragraph that
indicates how to run a simulation. General aspects of how to configure the platform are
described in the README file that the project contains. Basically, as the simulations
process has two main steps (map generation and movement simulation and network/communication
simulation) there are two configuration files for each one. For the first part, any
configuration file can be used to be passed to the script that runs the map generation
and and run the traffic simulation. In fact, in the folder sumo/scripts/config there
are some example configuration files (in further sections each specific parameter of the
configuration file is explained).
Finally, the configuration of the network/communication part is self-contained in the

script that run that simulation part. That file is in the root folder of the Vanet project
and is called run-vanet.sh and many of the parameters are derived from the ones of
the first part.
4.4.3 Generating the Map
The process for generating the grid map where all the SUMO nodes (that represent
coordinates) are placed for the simulation is quite straightforward. All the blocks have
the same size and the 4 sides of each one are equal. A matrix of nodes that have
coordinates in the xy plane is filled. Each node is equally spaced using the block size.
The size of the entire grid map is also given and it forms a perfect square. The following
parameters can be configured in the config file:
• grid size: size of the blocks that is also the distance between any two streets.
• grid gap: if n is given, then the grid map would be of n by n (nxn).
The algorithm for achieving this SUMO compliant grid map can be seen in the figure
4.2 1 .
Figure 4.2: Generation process of the nxn grid for Sumo traffic Simulator.
After the nodes structure is filled, the edge list is made with those nodes. For each
node and each immediate neighbour of the node (one at the bottom, one at the top
and the two nodes at each side), an edge is created, representing a road. Once the
nodes structure and the edges list are created, they are dumped to two xml SUMO files:
node.nod.xml and edges.edg.xml. Finally, using those two file and with the help
of a SUMO tool named netconverter the network.net.xml file is generated. This
last file, as it has been described in section 4.3, is the one that is taken by SUMO as
input for representing the map where the vehicles will be going. Using the sumo-gui
tool the user can corroborate how the grid map looks like when this process finish. An
example of the output of this tool can be seen in figure 4.3 where a grid map of 5x5 was
generated.
1
Red boxes represent logic structures, green ones represent files, the blue ones represent functions or
procedures and the darker blue ones represent external programs.
Figure 4.3: An example of a grid map of 5x5 with blocks size of 100 meters.
4.4.4 Generating Sensors and Access Points
As it has been said before, sensors are randomly placed in the grid map. In order to do
so, the matrix structure of nodes of the grid map is used. A fixed amount of sensors are
placed in the proximity of the position of the nodes. Random nodes are selected and a
sensor is placed near that node position until the amount of sensors wanted is reached.
The amount of sensor to be placed can be configured in the configuration file modifying
the variable sensor quantity.
The access points are placed in two different ways. Some are placed randomly, following
the same procedure as the sensors. There is another group of sensors that are placed at
each end of each bus line. All the procedure is described in the figure 4.4. After knowing
where the sensors and access points are going to be placed, the structure containing that
information is dumped to a csv file. This file, will be given as input to the ns3 simulator
directly without passing through the SUMO. This happens because access points and
sensors are fixed nodes, and as fixed nodes there is not movement to simulate. In order
to modify the amount of sensors and random access points placed in the map there are
two parameters in the configuration file:
• ap quantity
• sensor quantity
4.4.5 Generating Cars and Buses Routes
It has been said that buses and cars routes moves in the grid map following some kind
of random route. For cars, the movement is generated by using a tool that comes
Figure 4.4: Generation process of the Access Points and Sensors for the scenario
generation.
with SUMO: randomTrip.py. The randomTrip script lets you generate vehicles with
completely random routes given just a road network file (in this case, representing the
grid map). This script tools comes with some settings that permits you to set for
example a minimum distance that the route need to have or also to generate more than
one vehicle for each generated route, among others. The amount of cars generated in
the simulation can be set indirectly by modifying the spawn car period variable in
the configuration file. This variable indicates how often are cars introduced during the
simulation. For example if it is set in 8, cars will be generated at second 0, 8, 16, 24 and
so on until the simulation finish. In figure 4.5 it can be seen that the generation of the
cars.rou.xml representing the movement of the cars is really straightforward, there is
no need of procedures to generate anything.
On the other hand, buses requires more processing. Generally buses do not make small
trips in a city. They tend to traverse the city and make long trips connecting distant
places. Trying somehow to make the buses follow this behaviour a procedure was created.
For making a bus line, first a point (a node speaking in terms of SUMO objects) in one
side of the grid map is chosen randomly. Then, a second point in the opposite side of
the grid map is also randomly chosen. Then, those two points become the ends of the
bus line. There are four sides in a grid map: top, bottom, left and right. Now a correct
path between those two points is needed (it has to be remembered that for specifying
Figure 4.5: Generation process of routes for Cars and Buses for the Sumo traffic
simulator.
a route for a vehicle in SUMO, all the streets(edges in SUMO) for where the vehicle is
going to pass by must be given).
Hopefully, SUMO comes with a tool called duarouter that makes the work easier.
Given two edges (streets), this tool finds one of the shortest paths which connects those
two edges. As the streets can have traffic in one way or two ways, the tool finds a route
that goes from the first edge to the second. In our case, because the grid map is all
made of two way streets the same route to go can be the one to come back.
However, because in many cities the route to go and the route to come back are not
the same and making two different routes for this do not requires to much work, the
duarouter tool is use twice for each bus line: one for the route to go and another for the
route to come back. This is easily accomplish by inverting the order of the edges when
invoking this tool.
The duarouter tool provides a type of file that have been described in section 4.3: the
flow xml file. In this file is where you specify the starting edges and the final edges of the
routes and the tool will search for the shortest path between those two edges (having a
grid map without weights in the streets there is not only one shortest path). As it has
been said there are other parameters that can be specified to each route in this file. The
most important ones are when the vehicles will start to be inserted in the simulation,
when the inserting will finish and how many vehicles of the specified type are going to
be inserted. With those three parameters is easy to specified the time between each
vehicle is created. In other words, the frequency of buses for each line. Finally, giving
the flow xml file to the duarouter will end up with the route xml file for the buses. In
broad terms, the generation of buses can be seen in figure 4.5.
The amount of buses to be created can be easily configure for each simulation in the
configuration file. There are two parameters in this file to accomplish that:
• spawn bus period
• bus lines
The first parameter handles the amount of time between each bus generation. In other
words, the frequency of the bus lines. The second one permits to control the number of
bus lines (a complete round trip) to be created in the simulation.
There are several details about the generation of buses, because over the development
of this work many modification have been made to correct and improve the simulation.
Moreover, because many of these improvements are related to the integration of SUMO
and the ns3 network simulator, it is better to understand before how the ns3 works, what
it have been developed over it and how those two tools were integrated. So, after seeing
how ns3 works, the explanation of these modifications and the integration of those two
tools will be explained more in detail in the section 4.6.
4.5 Network Simulator: ns3
One of the most important aspect when choosing the network simulator was that the
chosen one have support for node mobility. This is an obvious requirement considering
the nature of this work. The ns3 have support for that. Not only that, it can take a direct
output (without modification) of the SUMO simulator. So, the ns3 was chosen. After
some reference about the ns3 simulator during this section, it is going to be explained
how the Encounter Protocol and the Simple Routing Protocol were implemented over
this simulator.
4.5.1 Technical Aspects
The ns3 network simulator is an open source project which is really popular in the
community and is a really flexible one. In addition, it is very well documented with
graphs and each module come with easy examples to start with. The main entity of
the simulator is the node. A node is an object to which you can add different things
organized in a stack fashion way, copying the real device structure that generally follows
the well known OSI model.
Ns3 define the Node as the basic device unit that is capable of communicate among other
nodes that belong to the network. For example, you can add a net device (network
interface) to a node. This net device can be an ethernet net device or a WIFI one,
regarding if you want a wireless connection or a wired one. Continuing with the example
and before adding more things over the net device, you have to assign a channel to that
device. Speaking easily, the channel is the where the transmission occurs. This can be a
wire (like ns3::PointToPointChannel) or the air (like ns3::WIFIChannel). When two or
more nodes shares the same channel they can send and receive messages between them.
Of course, that making them understand and share the channel need some rules and
agreements. Then, you can add to the nodes and in particular to the net device of the
node, the protocol that is going to make it talk the same language with the other nodes.
And here is where there are a lot of protocols of different layers from the OSI model.
In the OSI model the upper the layer the more specificity of it. This means that in the
lower layers protocols for general purposes are found and in the uppermost layers you
will find very specific applications like a messenger or a video player. For example, ns3
comes with many implementations of different protocols like ipv4, ipv6, udp, tcp and
more. It also comes with protocols of the second layer of the OSI stack model like the
ns3::WIFIMac.
As it can be seen all this protocols are standard ones that can be found in any computer
or other any electronic device prepared to be connected to another device. Ns3 let you
implement a protocol at any level of the OSI model. For doing so you only have to
follow the interface that ns3 provides.
Hence, for the case that matters here, the Encounter Protocol and the Simple Vanet
Protocol are added following these rules in order to be correctly install in the ns3 nodes.
The Encounter Protocol has to communicate with the interface of the net device, whereas
the Simple Vanet Protocol has to interact directly with the Encounter Protocol. In other
words, the Simple Vanet Protocol is stacked over Encounter protocol (and this last one
over the net device).
The ns3 project is divided into several modules. Some of them are core modules. These
modules are necessary for every simulation. However, other modules are not, because
they serve to specific features that depends of what you plan to do in your simulation.
Not only that, modules are the way to add functionality to the ns3 platform. So, the new
protocols have been added as the form of a module named vanet to the ns3 platform .
In addition, a new repository was created from the source code of the ns3 platform to
implement and keep track to the new features added. For a quick reference, the source
code that is depicted in this work can be found in 2 . Across the development of this
work there was no need to change any part of the ns3 platform, so adding this module
to newer versions of ns3 should not result in too much work as long as the interface does
not change a lot (at the time of this project the version of the network simulator was
the 3.16).
However, having all these protocols install in a bunch of nodes does not make the network
do “anything”. It is the user applications that make the network do something and
generate data traffic that can be measure. An simple dummy application was developed
for this purpose and is presented in section 4.7.
One downside for the ns3 simulator is that it does not have a concept of duty cycle for
radio devices. This means that a more detailed control of the behaviour of the radio
device is not allow. This have consequences in the performance of the device in terms
that some messages can be received and others not. Also, having a more grained control
of the duty cycle could let save energy from the low energy devices. However, this kind
of control is very complex and it is leave out of the scope of this thesis (maybe for a new
work that focus on improving battery life of sensors).
4.5.2 The Encounter Protocol Implementation
The Encounter Protocol, as it has been said in the proposal section of this work is a thin
layer that can be located between the second layer of the OSI model and the routing layer
(third layer of OSI model). Through events, it lets upper layers know about neighbours,
new nodes that get closer to become neighbours and it gives you an easy interface to
send and received packets from them. Ns3 luckily presents an interface based on events,
so adding this thin layer is not really tedious.
2
https://bitbucket.org/pablin87/ns3-sumo-vanet-simulation
4.5.2.1 Stack Protocol
This Protocol is constructed over the layer one and two specified by the 802.11p standard.
As it has been said before, this standard defines the physical layer and the mac layer
for wireless environments in scenarios of high mobility (for vehicles). As it is not of the
interest of this work to create a new set of rules for the mac layer nor the physical layer,
a suitable one has to be chosen from the ones available in the ns3.
The WIFI standard have a structure where there is an access point (Ap) and there
are other devices named stations which connects to the former one. In the structure
proposed in this work the structure is not the same. What are called in this work access
points are not the same as the WIFI access points. In the WIFI standard that uses Ap
and stations, Ap are strictly needed in order to make two or more devices communicate
among them.
So, can an access points node, as it has been defined in this work, play the role of a WIFI
access points and cars, buses and sensors be WIFI stations? The answer is no, because
as it was designed in the Simple Vanet Protocol, cars and buses could not be available
to communicate to sensors without the need of an access point. So, is there another
option? If buses and cars play the role of WIFI access points it could works, except for
the fact that buses and cars would not exchange packets between them. And this last
one is one of the needs of the Simple Vanet Protocol. If not only access points are WIFI
access points, but also the sensors are WIFI access points there are two problems. One
is that if a sensor is close to an access point it would have to wait for a car or a bus to
pick up its data and automatically deliver it to the access point despite the fact that
they are in range. In other words, communication between access points and sensors
would no occur. It also have the same problem of the previous schema between cars and
buses.
The previous type of WIFI structure is called infrastructure WIFI mode. Luckily, there is
another mode in the WIFI standard called adhoc that do not have the same requirements
as the infrastructure mode. In fact, the adhoc mode does not need for an access point.
It does not require any stations neither. There are just nodes (meaning no distinction
among nodes) and these nodes can communicate among each other without the need
of association to any access point. The problem with adhoc networks is that they
need of upper layers to complete the functionality that was accomplish with one set
on infrastructure mode. For example, when a new node is connected to the network,
there is not an established mechanism to let the others nodes of the network know the
new one. The 802.11p do not define any behaviour for this type of situations, so it is
considered as an adhoc WIFI mode.
Ns3 comes with a class named ns3::WIFIMac that encapsulate the behaviour of the
WIFI mac layer. However, there are more than one class that can be used that inherits
from it. Basically, there are three:
• ns3::APWIFIMac
• ns3::StaWIFIMac
• ns3::AdhocWIFIMac
The ApWIFIMac and the StaWIFIMac correspond to the access point and station agents
of the first infrastructure WIFI mode. The last one correspond to the adhoc WIFI mode,
the one that is used to build on top of it the Encounter Protocol. Despite the protocol
is intended to be used over this type of WIFI mode, it could be also constructed for
example over a wired protocol. However, as the nature of the Encounter Protocol is
extremely related to wireless environments for what the WIFI protocol is intended, it
would be pointless to used it on top of the other kinds of environments.
4.5.2.2 Protocol Class Structure
Here it is described how the protocol has been implemented over the ns3 platform. Four
main classes were added to the vanet module for this protocol.
• EncounterMacServL3Protocol
• EncounterMacTable
• EncounterMacHeader
• PassiveEncounterMacServL3Protocol
The first and last are the protocols itself which are installed to the nodes. The other
two help to this purpose. In the figure 4.6 there is a class diagram showing how this
classes are related.
When the EncounterMacServL3Protocol is added to a node, the setUp method

is called. It register a callback so whenever a packet comes to the network device,
it is forwarded to this class. It also configure the node so it start sending regular
control packets through the network device. These last packets conform the beacons
that announce the presence of the node to possible neighbours. This is easily achieved
thanks to the scheduler system that ns3 has. After that, if an application or upper layer
Figure 4.6: Main classes conforming the Encounter Protocol. For a detailed
description of methods and attributes go to appendix B.1.
want to be noticed that a new neighbour is available it only has to register a callback with
the registerCallbackNewEncounter method. This class handles the task of managing the
beacons and maintain a list of neighbours. If an upper layer want to be noticed when
a packet of data of a specific neighbour has come, it also has to only register a callback
using the registerCallbackRecvPacktFromSender specifying the address of the neighbour.
The EncounterMacServL3Protocol class keeps records of neighbours by using a structure

which is also a class: the EncounterMacTable. This class is basically a dictionary
(std::map in C++) which contains data for every neighbour. The index of this table
is the mac address of each neighbour that must be different for each one. The most
important information kept in that structure is the callback registered for each neighbour
(to be called when a data packet for that neighbour arrives) and the time when the last
beacon has been received from the neighbour. After having passed the expiration time
(parameter of the protocol) without receiving any beacon for that neighbour, the entry
in the table is removed and further attempts to send a packet to that neighbour will end
up having no effect. The timer for erasing a neighbour from the table is not only reset
when a beacon comes, but also when a data packet arrives.
The EncounterMacHeader inherits from the ns3::Header class. It complies with the
ns3 headers mechanism so it make it easy to add and remove packet headers when
packets are send and received respectively. An Encounter Header carries information
such as the type of sender that has sent the packet (carrier, RSU or sensor) and the type
of information that goes in it(data or control).
The last one is the PassiveEncounterMacServL3Protocol which inherits from the

EncounterMacServL3Protocol. In the proposal of the protocol there were two versions
of this protocol. This is the second one intended for low energy devices (sensors).
The difference between this one an the EncounterMacServL3Protocol is that the setUp
method is overwritten in order to not to start the beaconing. This avoid sensors to
noticed they are closed to other sensors, but not to access points, cars and buses. This
is fine because it is known that the Simple Vanet Protocol do not need sensors to see
between each other, so this last fact can result in a battery saving. However, if future
protocol developments above this protocol need sensors to see each other, it only requires
to install the regular EncounterMacServL3Protocol class and set the node type to sensor.
4.5.3 Implementation of the Simple Vanet Protocol
The Simple Vanet Protocol lies over the Encounter Protocol and it has the responsibility
of correctly route the packets over the vehicular network to make the packets reach its
destination. In the proposal section it can be seen that there are several agents that
plays different roles to make this happen. The network can be seen like a big space
where the sensors are the sources and the access points are the think. In this case, the
carriers are the moving nodes that carry the packets produced by sensor to the access
points. These different tasks of the different nodes are translated in different classes that
implement each of these functionalities. Those classes are:
• SimpleVanetProtocolSource
• SimpleVanetProtocolCarrier
• SimpleVanetProtocolRSU
• SimpleVanetProtocolCarrierUntrusted
In the figure 4.7 there is a class diagram describing those classes.
Figure 4.7: Main classes conforming the Simple Vanet Protocol. For a more detailed
explanation of attributes and methods see appendix B.2.
The SimpleVanetProtocolSource is the class that encapsulates the behaviour of a

sensor node. The setUp method register the right callbacks with the Encounter Protocol
and set the node type to sensor. Every time that a packet arrives to this layer ( generated
by upper layers, probably by an application ), the Simple Vanet Protocol (for a sensor)
looks if it has any neighbour to deliver the packet. That is a car, a bus or a RSU
node. If there is non of these types of neighbours, then the enqueueDataPkt method
is called to enqueue the packet. If there are more than one neighbour available, the
method selectCarrierOrRSU will return a RSU if there is any or a carrier with the
lower expiration time. In other words, the carrier that has last sent a packet (beacon or
data).
The SimpleVanetProtocolCarrier are intend to be installed in bus nodes. The setUp

method works similar to the one in the SimpleVanetProtocolSource class but registering
the callback of this version of the protocol. The newEncounter callback for this class
works as a demultiplexer. Regarding the type of sender three different methods can be
called. The newCarrierEncounter, the newSourceEncounter or the newRSUEncounter
methods are called when the current carrier node encounters a carrier, a sensor or a RSU
respectively. In this case, when another carrier is encounter, the corresponding method
register a callback to the new neighbour in order to be prepare to receive packets from
it. If the new carrier is a bus, it will not send any packet. But if it is a car, then
it will try to send all the packets to the current node. In this case all the packets
received are queued to be delivered when it encounters an access point (RSU), unless
it already have one as a neighbour. In this last case, instead of queueing the packets,
it will directly forward the packets to the access point. When the newRSUEncounter
method is called as a consequence of a new access point neighbour, all the packets
which were previously queued are delivered to the access point. When a new sensor
node is discovered the newSourceEncounter method is called producing the registration
of a callback to that specific node. Then when a packet arrives from that neighbour,
the registered callback will be invoke sending it to a neighbour RSU or queueing for a
subsequent RSU encounter.
The SimpleVanetProtocolCarrierUntrusted inherits from SimpleVanetProtocolCarrier

and is intended to be installed in cars. As the cars and buses play almost the same role
in this vanet protocol, most of the functionality remains the same. All except when a
car that has this type of version of the protocol encounters another car or bus. That is
why the newCarrierEncounter method is overwritten in this class. In this case, when a
car encounters a new carrier it checks it the new neighbour is a bus. If it is a bus, then
it send all the queued packets to the bus. If there is another car, then nothing happens.
Finally, the SimpleVanetProtocolRSU has been designed for access point nodes.
An RSU does not carry any packet, neither generates any. It only accept packets to
deliver them to the Internet. Hence, the newEncounter method register a callback to
receive packets from any new neighbour no matter its type (sensor or carrier). As this
is a simulation, when a packet arrives to a RSU node, the packet is printed to the
logging system of ns3. This indicate when the packet with a specific id has arrived to
its destination, and helps to get some statistics about how the network is performing.
But this topic about what information generates the simulation will be seen in further
sections.
4.6 Integration of ns3 with SUMO
There is a tool that make the integration of SUMO and ns3 straightforward. It take the
SUMO output file and transform it to another file easily read by a specific module of
ns3.
However, there are some problems of scalability when simulating large scenarios in ns3.
Having more than three thousands of nodes in a WIFI environment is not feasible. In
this [15] paper there is an analysis and explanation of this problematic. Because all the
nodes share the same channel(air), every packet that is emitted by a node tries to reach
every other node. The channel have to evaluate for every packet which node will receive
it (in term of physical aspects). In order to do that, it use a propagation lost model.
There are several model to do so. But the problem is not the model. The problem is
that the formula of the model have to be calculated each time a packet is emitted in
all the other nodes. And then, because of this, the simulation time strongly depends on
the amount of nodes that take part on it. So, in section 4.6.2 there are explain some
modifications to the integration process in order to reduce the amount of nodes and
other optimization to make a medium-large simulation possible.
4.6.1 Exporting Cars and Buses traces for the ns3
In a regular WIFI simulation where all the devices are confined to a specific place, nodes
are static. The ns3 provides a static mobility model, in which each nodes have three
spacial coordinates: x, y and z. The z coordinate is generally zero as scenarios are rarely
distributed in three dimensions (only 2D). For moving nodes there is another mobility
model that permit nodes to move around the scenario. There is a special mobility
model that takes traces from a trace file. In this trace file, there are described groups
of nodes, containing their initial position, periodical updates to their position and the
final position of them. The output of a SUMO simulation is a xml network state file
that have another format. So, in order to obtain the desired trace file a java tool that
comes with the SUMO suite named traceExporter.jar is used. In figure 4.8 is described
the process of generation those trace files.
Figure 4.8: Generation process of traces for Cars and Buses for NS3 network
simulator.
The route file of cars and buses are simulated separately. Each of them generates a
network state file which are passed to the traceExporter.jar tool. The final files are the
cars.mob.tcl and the buses.mob.tcl which complies with the trace file format accepted
by the ns3 mobility model. The simulation is run separately because it is not possible
to distinguish buses from cars. This is not an issue in our simulation because there is no
intention of seeing how the nodes interact in a very crowded environment (when there
are not too many vehicles in the simulation, there is not too much place to make them
to interact, so the movements will be practically the same), so the differences between
this and simulating cars and buses together are not relevant here. Also generating these
nodes all together in the same simulation would require an extra effort that is not worth
it for the cases that are encompassed here.
The ns3 mobility creates a node for each node defined in the trace file. The ns3 mobility
model for moving nodes save to each node each position time during the simulation.
These position changes are taken from the trace file. This means that the path of
the node is known at the beginning of the simulation. After the nodes are created,
the configuration of each of them takes part. The net devices are installed along with
the stack of the protocol with the corresponding implementation of the Simple Vanet
Protocol according to whether it is a car or a bus.
4.6.2 Improvements
As it has been said before, a large scale simulation (more than one thousand of nodes)
takes too much time (days or weeks) for an hour of simulation. This is not acceptable.
As ns3 is an event base simulator it runs in only one thread. In event base simulator,
parallelism is not a simple task to implement and generally depends of many implementation
details related to the nature of the problem. There is a current project for ns3 parallelism,
but is not really mature. So, parallelizing the ns3 simulation is not an option. Instead,
the focus is putted on the optimization of the simulation, in particular on the nodes
generation. The rule for this case says that the lesser nodes during the simulation,
the lesser time simulation takes. So, in the next sections there are presented a few
improvements following this rule.
4.6.2.1 Re-using Nodes
One idea that was implemented is to re-use nodes. For this case, bus nodes are the
main candidates. The buses are created so there start at one point and end in the last
stop. After that, the bus node remains in that last point doing nothing. This of course
consume memory and cpu because the bus as a communication node is still working. In
other words, the major problem is that it keep sending beacons and receiving packets.
In real life, when a bus reach the last stop, it start the way back. And when it finishes
that trip, it starts over with the same trip. This behaviour of the bus keeps going until
the end of the day. Or not. In many places buses keep going all day long. What happens
is that the frequency of the bus lines varies during the day making some buses to stop,
specially at night.
The implementation described in previous sections in this chapter does not take into
consideration this fact. However, after some analysis a modification was implemented
to reuse the bus nodes. This modification works as follows. First, it creates two buses,
two for each bus line; that is to say, one for each route of the round trip. The two routes
created have in common that the starting edge of one is the ending edge of the other and
vice versa. Of course, they are round trips. And if you erase both start and end edge
of one of them and put them together you have the entire route for the bus line round
trip. So, second, a bus is constructed unifying those two routes. So far, the amount of
buses have decrease to the half and there is only one bus that have the entire round trip
of the bus line. Then, If you repeat this sequence of edges, the bus will make as many
round trips as many times the route is repeated. This is a really important advantage.
Repeating the round trip for a bus infinite times (many times compared to the time of
the simulation), gives a bus that never stop during all the simulation. This also reduce
the number of buses because when a bus finishes its round trip, there is not need to
create another one to maintain the desired frequency. The bus will start over with its
round trip again and again. Moreover, this permits to have some kind of control over
the number of buses that each bus line has.
Finally, after creating the bus for a bus line round trip, the bus has to be repeated in
the bus route file as many times it is needed. In the configuration file, there is a variable
that let the user to set the frequency of buses per line. The frequency of a bus line is
not perfect along all the round trip because the speed of the buses are not constant and
may vary depending on traffic and traffic lights. But if the round trip time is estimated,
then the frequency of the bus lines would be directly related to the number of buses per
line. Not only that, it would also depend directly of the route. So, a route that consist
of more edges (streets) than other one will take more buses to maintain the same desired
frequency. So a simple equation to estimate the amount of buses per line was proposed:
troundT rip
F requency =
#busesxline
Now, the first question was about the number of buses that are needed in the bus route
file to reach the desired frequency (how many times have to be repeated in the file), so
in this formula the real unknown variable is the number of buses per lines (#busesxline ).
However, the round trip time is also unknown. Nevertheless, as it has been said before,
the round trip time (tround−trip ) can be estimated. Despite the changes in the speed of
the buses because of the reasons that it has been mentioned, it is important to have in
mind that bus stops are not take into account in our simulation, so buses do not have to
make long stops to pick up passengers, not affecting, in our case, the round trip time.
A simple estimation for the tround−trip came up following this formula:
#EdgesroundT rip ∗ edgeSize

troundT rip =
maxSpeed ∗ µ
Where :
• #EdgesroundT rip is the number of edges (streets) that conforms the route of the
bus line round trip.
• edgeSize is the size of the edge.

• maxSpeed is the maximum speed of vehicles setted in the configuration file.
• µ is a correction constant for the vehicles speed. This is made because vehicles do
not go all the time at maximum speed. This constant was set to 0.8 after some
estimations made measuring the time that a bus takes to make a round trip in a
simulation.
Finally this procedure will end up saving lots of buses nodes because they keep going on
during all the simulation. The interesting thing about this is that it does not matter the
time the simulation last, 30 minutes or 20 hours, the number of bus nodes will remain
constant. The number of buses created will do depend on the desired frequency, its
round trip time and, of course, on the number of bus lines.
4.6.2.2 Repositioning of nodes
When a simulation in ns3 begins all the nodes which are involved during all the simulation
are placed in the map. It does not matter if the node start going around at the beginning
of the simulation or twenty minutes after; the nodes are placed there, in their initial
positions. Now, this would not be a problem if the simulation would not notice the
presence of this nodes. Unfortunately, this is not the case for the ns3 simulator. In fact,
there is not way of taking a node out of simulation in ns3. So when a car or a bus that
is not immediately going to start moving is placed at the beginning of the simulation,
it makes the simulation takes more time because it receive and sends packets. Not only
they make the simulation slower, but they also interfere in the result of the simulations
as those nodes should not take part of it until a while after.
The problem is with bus and car nodes. For example, imaging having a bus line with
eight buses and those buses were supposed to be created each two minutes. When the
simulation begins all the eight buses are placed in the same point. Then, all this buses
will start beaconing and updating its neighbour mac table. Those cases are the worst,
because there is a bunch of vehicles at the same time in the same place generating lot
of packet traffic. If they were far away from each other the propagation lost model
will discard the packets and nodes would not receive the packets and will not update
their neighbour tables neither interchange packet data which would be translated in less
simulation time. For buses is less worse because, after a while all the buses will be going
around an this problem will go away. But for cars the scenario is not the same. Cars
are also placed all at the beginning. This means that cars that will start to move after
one hour of simulation will be placed there and interact with the other nodes that pass
by or with sensors that are placed near them. The scenario where a car is placed near
a node and far away from a bus route is one of the worst. For example, if there is a
car that will start to move much later near a sensor all the packets generated by that
sensor will be captured by this cars, and could be delivered only when it start to move
or unless a bus pass by (which is not the case because it is not near to a route of a bus
line). Another passing car that is already moving will not also take those packets (for
how the protocol works) becoming this situation in a performance decrease.
So the problem of having all the simulation nodes placed at the beginning of the
simulations not only affect the performance of the simulation in terms of time consuming
but the behaviour of the simulation itself (more delivery time, possible less delivery
performance, among others).
That is why a reposition adjustment was implemented. These modifications are made
in the traces file, in the cars.mob.tcl and in the buses.mob.tcl, before the ns3 simulation
start. In order to understand these adjustments were made, it is first needed to understand
the structure of the file and known how the data is presented. The traces file have three
different type of lines. The first type set a coordinate x, y or z of a given node. Those
type of lines are at the beginning of each trace file and set the initial position (coordinates
x, y and z) for every node. Then there are another type of lines that set, at a particular
time, the position of a specific node. The last type of lines updates the coordinate of
a particular node at a given time. The difference between the last two type of lines is
that the last one make a soft transition from the last position to the new position of the
node that is being updated. In general these type of lines are used for close positions.
The other type, that set a coordinate position make the node automatically appear at
the given time (like a magic transportation).
Hence, a common trace file would have at the beginning the first type of lines, setting
the initial position of all the nodes. Finally, a bunch of update lines would follow those
files generating the smooth movement of the nodes. The set position line type are less
often, and are not generated in general by the tool given by SUMO. However, they are
useful to make the modifications that are intended here.
The idea of theses modifications is, at the beginning of the simulation put the nodes far
away from concerned area, that is to mean out of the grid map, and as the time pass and
is the time of those nodes to get in action put them back to their initial position. Then,
to modify the trace file and make these adjustments a python script was developed. The
script does the following:
1. Copy all the initial positions of all the nodes and save them aside.
2. Modify all these initial positions of all the nodes so all the nodes starts out of the
grid map of the simulation. The grid map takes place between the (0,0), (0,n), (n,0)
and (n,n) coordinates points, where n is the amount of blocks multiplied by the
block size (in other words, the length and width of the grid map). Putting a node
out of this square a distant longer than the minimum range of a communication
makes the node take no part of the simulation. This is made, in this case, by
placing those node in negative positions. But there is something to remark about
this. You can not put all the nodes in a far away point. You have to put the nodes
in different points out of the grid map so they can not communicate among them.
If all the nodes are put together in a same place, it would end up having a worse
situation, in terms of performance. In that case, all the nodes would generate
beacons and all the nodes would receive them and would update their encounter
mac table. All nodes would be neighbours among them, thus increasing even more
the simulation time (because of all the processing that having neighbours required).
So nodes are placed in a negative position like (0, −αR) where R is grater than
the minimum communication distance and α increase in one each time a node is
placed. This will place the first node in (0, −R), the second in (0, −2R) and so on,
avoiding interaction among nodes.
3. Look for each first update line of every node and immediately before that line set
back the position of the node to its initial position, that was saved in the first step
(using the third type of trace line and setting it with a second before the founded
update one). Thereby, this will make every node to be placed in its initial position
one second before it starts to move.
4. Finally, the script removes the vehicles when they stop moving. When a node has
stopped? A node has stopped and will not do anything else after its last update
line. So, in order to remove the vehicle out of the simulation, the script place the
node out of the grid map, like it did in the second step. The reason to take those
vehicles out of the simulation is the same reason why you take out nodes at the
beginning of the simulation: it interferes with the simulation when they should
not suppose to do and making the simulation to take longer.
One thing important to remark is that net devices which are installed in nodes do not
support to turn them off. If the ns3 platform would have a simple call to turn of the
net devices of the nodes, this work have been easier. The script would not have to
move nodes in/out of the scenario. However, it should somehow know when the vehicles
start/stop to move in order to turn on/off the net devices. Probably a similar work to
this one, because in this steps the script makes its way to know when nodes start and
stop moving.
4.7 A Simple Vanet Application
There is the Encounter Mac Layer that provides neighbour discovery and there is the
Simple Vanet Routing Protocol to handle the packets in order to correctly deliver them.
Running a simulation, nodes will start to move and generate beacons. This will generate
nodes to update their encounter mac table. And that is it. No data traffic to measure
will be generated.
Hence, a Simple Vanet Application was created to generate traffic. The ns3 simulator
comes with a type of class named ns3::Application. It gives an easy interface to generate
data traffic. Then, a VanetSimpleApp class that inherits from ns3::Application was
created. It implements the StartApplication and StopApplication to comply with the
ns3::Application interface. Basically, when the StartApplication method is invoked the
VanetSimpleApp called another function that sends a data packet through the routing
protocol and schedules itself to be called again in x seconds. Then when the ns3 scheduler
calls the method and another data packet is sent, the method is reschedule again. This
keeps going until the StopApplication method is called. It simply removes the last
schedule of the method, so the function will not be called again and no data packet will
be generated any more. The x seconds that have been mentioned can be configured. This
parameter can be set in the run-vanet.sh script that have a configuration section on it.
The variable to modify is named interpktgentime. But a more detailed configuration
about the communication part of the simulation will be described in the chapter 5.
Chapter 5
Simulation Results and Analysis
In this chapter there are present simulations using the platform described in the previous
section chapter. First, the scenario of the simulations is described to give the reader an
idea of how it can be reproduced and to understand the scenario where they take place.
Then, as the results of the simulations are given by the platform as raw data, a tool to
easily read those results has been developed and will be presented also in section 5.3.
Finally, with the help of the tool, analysis of the ran simulations is given.
5.1 Description
The simulation platform has been presented. The Encounter protocol for neighbour
management and the Simple Vanet protocol have also been presented in the previous
chapters. Now it would be a good time to remember what that was for. The DC4LED
project is intended to collect data from third party sensors that want to use the service
that it provides. In chapter 2 there were presented many vehicular routing protocols
with their advantages and disadvantages. But a question still remains unanswered. Is
this Simple Vanet protocol enough for the DC4LED service? Is there a really need for a
more complex routing protocol? This can not be a yes/no question. The result can be
that there is no possibility for this protocol or that it needs some modifications or that
it depends of the objective of the applications that would be run over the service. So
one of the most important things that the platform provides is the possibility to detect
what modifications can be done to this protocol in particular and to another vehicular
protocol in general that is or can be implemented over this platform. Not only that,
because the platform was designed to make an approximation of the real scenario, more
complex ones can be developed in the future to reinforce or discard the results here. In
75
Chapter 5. Simulation Results and Analysis 76
chapter 6 it will be given a suggestion of “next steps” in order to follow with what it
has been done in this work.
5.2 Parameters
In this section there are presented the values of the parameters of the simulations. It is
also explained why those values were chosen.
First Simulations
During the development of the platform some simulations were performed in order to
test the platform and see how it behaves. These simulations were not intended to be as
representative as the ones that will be presented in the next subsection. But, because
the time that the simulation consumes is critical (as it will be seen later the simulations
that were run for this work could take a few days), there was the need to understand
how some parameters of the simulation affect it, and to have an approximation of by
how much.
The whole simulation is divided in two parts. One part that is in charge of generating the
movement of the nodes and the map, and another part that handles the communication(network)
among those nodes.
Now, there are presented the values of the parameters for this first small simulation part
along with a description of each one (this parameters are found in the config.ini file in
the folder sumo/script/config under the root of the folder. To see more details about
the platform and its installation see appendix A ):
• grid size = 7
This set the number of blocks at each side of the grid map. So in this case you
will end up having a map of 49 blocks (7x7).
• grid gap = 100
This parameter set the large in meters of each block. The number is taken from
the size that generally the blocks have. This value did not change in any of
the simulation that were performed and variations of it are meaningless to these
simulations.
• sensor quantity = 16
This set the number of sensors that will be randomly placed in the grid map.
• ap quantity = 2
This set the number of access points that will be randomly placed in the grid map.
The reader can remember that other access points are placed at each end of each
bus line, so the total number of access points will be this value plus two times the
values of the bus lines parameter (see further on).
• simulation time = 3600
This set how much time will be simulated. The value is given in seconds.
• simulation time step = 0.1
This modifies the step of the simulation. The value is given in seconds.
• spawn car period = 30
This is the time in seconds that are between each car generation. In other words,
and for this case, every 30 seconds there is a car that appears in the map at a
random location and starts to move to a particular direction (also random, but
forces the vehicle to traverse at least a certain part of the grid map).
• spawn bus period = 120
This parameter indicates the frequency of the bus line. This mean that each x
seconds a bus will pass for each bus stop. Of course the value is approximated
because it is not possible to know exactly how much the round trip of each bus
line last.
• bus lines = 2
This set the number of bus lines that will traverse the grid map.
• min speed = 11
• max speed = 18
These last two parameters represent the maximum and minimum speed of all the
streets in the simulation. These parameters are expressed in meters by second
because it is what the SUMO simulator takes. The first value is equivalent to 40
km/h and the second to 60 km/h. Those two values were taken from the normal
traffic regulations of regular streets. Generally, those two values were constant
along all the simulations that were performed, and they have not too many impact
in the simulations in terms of the aspect that is concerned here.
A simulation that generates the map and the movement of the vehicles (moving nodes)
with this parameters has taken 26 seconds. But, how can those parameters modify
the time that it consumes? And, is the time consume in this part of the simulation
significant?
This part of the simulation can be also divided into another two parts. One that
handles the generation of the maps and nodes, and the other part that handles the
movement simulation itself with SUMO. The first part can be disregarded because it
has been observed that it takes less than 1 % of the simulation time. Hence, some of
the parameters can be excluded of the analysis as they are only involve in this first
simulation part. These are the amount of sensors and access point since they are fixed
nodes and of course they are not simulated by SUMO.
The simulation time is an obvious parameter that when it increase, the simulations last
longer. However, this will matter if the increase of the simulation would be exponentially.
But, in this case the increase is linear. That means that if you maintain all the same
parameters of the last simulation and increase the value from the simulation time to
be the double, then the simulation will take approximately the two times the first
simulation.
Then, there are two types of parameters that remains to analyse: the simulation time step
and the ones that control the amount of cars and buses (bus lines, spawn car period
and the spawn bus period ). For how the SUMO simulator works, these last parameters
are the ones that more influence in the simulation time as the more vehicles, more
interactions the simulator need to analyse.
Despite this could be an interesting analysis, it is not our intention to invest more time
testing the behaviour over those parameters in this part of the simulation because it
does not take too much time compare to the communication part of the simulations.
This conclusion was not reach by a theoretical analysis but by the the tests that have
been ran.
Regarding the second mayor part of the simulation that has to be with the ns3 simulator
there is another file that has to be set in order to run the simulation. The file is the
run-vanet.sh script (placed in the root of the project). In the first part of the script
there are parameters to control the simulation. Those parameters are:
• folder /small scenario 1
This parameter indicates where the files from the first part of the simulation are
located. In other words, the output files that SUMO and the scripts in the previous
section have been generated.
• result folder /simulacion small scenario 1

In the folder indicated by this parameter there will be placed the files generated
by the simulation. This is added just to have the simulations organized.
• simulationtime 3600
This parameter must indicate the how much the simulation last and it has the
same value as the value of the parameter simulation time of the first part of the
simulation. The value must be given in seconds.
• sensorstarttime 15
This parameter indicates in seconds when the application installed in the sensors
will start to generate data packets. This is used to make the network enter in a
stable state, namely when there is a flow of vehicles traversing all the map.
• sensorstoptime 3550
This parameter indicates in seconds when the application installed in the sensors
will stop to generate packets. This is made in order to give the generated packets
that are been carried by a vehicle some time to reach an access point. Note that
the time is absolute regarding the start time of the simulation. So in this case the
sensors will stop to generate packets 50 seconds before the simulation stops.
• wifirange 90
This parameter specifies in meters the minimum range for two nodes to make a
communication. This parameter does not varies too much and have to be with what
it has been discussed in the section 2.9.1 relative to the 802.11p standard. One
thing to remark is that this does not mean that if two nodes are at just one meter
mess than this value, then the communication happens. This only establishes a
minimum range for a communication. There are other factors involved in the
communication that are related with the propagation model configured in the ns3
(for example, the threshold of the receiver). Those parameters were left fixed as
its configuration is complex and out of the scope of this work.
• interpktgentime 30
This parameter in seconds indicates the time between generated packets which are
produced by the application in each sensor. One thing to remark is that a ns3
came with a class called Application that help you to generate packets in order to
simulate traffic over the network being tested. And one of the parameters of that
applications is the frequency of the generated data (been set here).
One thing to remark from these parameters is that they are strongly related with the
ones that were configure in the first simulation part. For example the sensorstarttime
and sensorstoptime directly depends of the duration of whole simulation that is setted
in the simulationtime which is also the same as the value of the simulation time in the
configuration file of the first part of the simulation.
Therefore most of the performance of this second part derives from the parameters of
the first part which are included implicitly in the input files (output files of the first
part, like bus traces, car traces and grid map) and explicitly in the configuration (like
the simulationtime).
The last two parameters (wifirange and interpktgentime) are the only ones that are not
anyhow related with the first part of the simulation. And as the wifirange is always left
with the same value, the only parameter that is really available to be freely change is the
interpktgentime. Changing this last parameter could have different meanings. Having
low values could can make you think about a network with high loads of traffic, whereas
having high values would make you think about a network with low traffic. This happens
because in the first case packets are generated more often and in the second case not.
This part of the simulation has last around 23 minutes (more than one were ran). So,
as it has been said before the communication part of the simulations takes more than
98 % of the whole simulation time.
The parameters of this second part of the simulation are almost all derived from the first
part. So the parameters of that first part has a huge implication in the time consume
by this part. Running several simulations to see how the time varies with the change in
those parameters is really time consuming. So a small non practical analysis was decided
to make instead of determining the behaviour of it in a practical manner, because it is
not the real goal of this work.
Some conclusions of performance are taken from paper [15] to make this analysis. It
describes how the radio devices (WIFI) interact in the model of the ns3. So, when a
node sends a packet throw the air, all the nodes alive in the simulation need to do a
check about proximity. Then the formula of propagation of the waves for every generated
packet is calculated for every node. Then, this make adding a new node really expensive.
Imagine having 2 nodes that generates each one 2 packets during the simulation. Then
for each packet 1 propagation formula is apply to see if it reach the other node. This
means that a total of 4 checks are made. Adding another node that also generates 2
packets make the simulator to do 2 checks for every generated packet. Then if 3 nodes
generates 2 packets each other the total amount of checks is 12. Another node that also
generates 2 packets will make the simulation to do a total of 24. So as the number of
nodes grows, the simulation time grows exponentially.
On the other hand, making the simulation to generate more packets does not make the
time of simulation to grow as faster as adding nodes. Following the same approach that
in the previous example, if there are 2 nodes; one generates 2 packets and the other
3 packets, then the total amount of checks is 5. If another packet is added, then the
amount of checks become 6. This also grows linearly if the cars were 3. For taht case 4,
5 and 6 generated packets will imply an amount of 24, 30 and 36 checks respectively (a
step of 6 in all the cases, where it is easy to see that the grow is linear).
One thing to remark is that the amount of packets generated in each simulation is defined
by the total time of the simulation and by the interpktgentime that represent the period
of the generations of packets. So when modifying this values, the time consuming of
the simulations grows nicely, in other words, linearly. Whereas when increasing the
bus lines, frequency of the buses lines, number of access points, number of sensors and
the frequency of the generated cars the increase in the time of the simulations becomes
exponentially.
Having in mind these limitations about how much time the ns-3 simulator consumes, a
series of large simulations were run to test the proposed protocol in a bigger scene.
Large Simulation
The simulation that has used the biggest scenario and is intended to be the most
representative one was called large simulation. In this case, the map is a square grid
map of 25 blocks for 25 blocks and two hours of movements of vehicles were simulated.
The values for the parameters of the configuration file to generate the map and the
movement of the nodes was the following:
• grid size = 25
In this case the grid map is of 25x25, what gives you a surface of 6, 5km2 . Here,
as it is not wanted to generate a really big map because of simulation constrains,
this amount of blocks can be considered as a part of a medium city, perhaps the
city center, or also a small town.
• grid gap = 100
• sensor quantity = 100
In this case the value does not follow any strict rule. Nevertheless, it would be
very nice in order to make more accurate simulations that this number can be
increased much more. But due to simulations issues this can not be possible, at
least for now.
• ap quantity = 10
In this case, the number was not chosen following any strict rule neither. However,
it is clear that the number of access points have to be less than the number of
sensors. This is pretty much obvious, if there were more access points than sensors,
then you could put an access point near each sensor and you would not have any
routing problem.
• simulation time = 7200
This value is conditioned by the performance of the simulator. The bigger this
number the longer the simulation will last. This is obvious but is not that simple.
When simulating in this platform there are two simulations that occur. The first
generates the map, the bus lines, the cars, access points and sensors and then, the
other part generates the movement of those nodes. Then, the second simulation
that uses the information generated in the first simulation part, occurs in which
the communication part is involved (beaconing generation, data packet generation,
etc). These two simulations have very different times. The first consumes much
lesser time than the second. For example, for this simulation in particular with
this parameters the first simulation has occurred in around 60 minutes, while
the second has consumed around 42 hours. Then two hours of simulation was
considered as a nice time to generate a considerable amount of packets, so that
the simulation can be representative. However, in future works and considering
maybe other protocols it would be nice to have simulations that run several days in
order to make protocols that use statistic data to route packets having stabilized
its routing decisions. One important thing to remark about this parameter is that
the time consumed by the simulators in both simulations increased linearly with
this parameters, as the amount of interactions by simulation step are the same
because the amount of nodes remains constant.
• simulation time step = 0.1
In this case, the 100 milliseconds was maintain from other simulations. But why
100 milliseconds and not 1 minute as it would strongly decrease the simulation
time? This has to be with the speed of the vehicles that are being handle in this
type of vehicular networks and with the communication range among them. If
there is a vehicle moving at 40km2 that means that the car with a step of 100
millisecond and 1 minute will move approximately 1 and 667 meters respectively.
If the range in meters is 90 meters, then having a time-step that gives a 667 meters
step will be wrong as vehicles could enter and leave zones where it would have made
contact with other nodes. Whereas with the step of 1 meter, this case becomes
much more difficult to happen (The error would be approximately of 1 over 90).
• spawn car period = 8
The bigger the scenario the more cars are needed not only to reach all the map
but also to make the simulation more realistic. In this case, more cars means a
lesser spawn time for the cars.
• spawn bus period = 120
Having a bus pass by each 2 minutes is a good frequency for bus lines in a city.
• bus lines = 7
In this case, 7 lines of buses for a city center of 6, 5km2 is a good number of bus
lines traversing that area. This could be seen as, if the lines of the buses have the
same distance among then in term of the street that they are traversing, and there
are 3 lines going from top to bottom and another 4 going from right to left then
there would be a bus every 6 to 8 streets distance, covering an important part of
the city.
• min speed = 11
• max speed = 18
Those two last values were keep from other simulations, and in generally do not
change from one simulation to other.
On thing to remark is that the total of access points that will be placed in the grid map
will be 24 (10 from the ap quantity parameter and 14 for each start/finish of each line,
given by the bus line parameter).
Now there are presented the values of the parameters of the second part of this large
simulation. Some of them are not shown for its irrelevance (like the folders where the
results are placed):
• simulationtime 7200
As it has been said previously this value takes the same as in the first part of the
simulation.
• sensorstarttime 20
• sensorstoptime 7050
These two parameters let the packets be generated when the network is already
stable and also let the last generated packets a margin of two minutes for the
possibility of being picked up by any vehicle and reach an access point before
simulation ends.
• wifirange 90
It is keep equal as in previous simulations.
• interpktgentime 15
Generating 4 packets each minute for each sensor gives a considerable medium
traffic load to the network. This value along with the simulationtime and the
sensor quantity gives a little less than 47.000 packets to be delivered by the
network in 2 hours.
Having settled the two part of the simulations, there were three simulations runs. Again,
here, there is the need to differentiate the two parts of the simulations in order to
understand why there were run more than one simulation.
The first part of the simulation is highly influence by the randomness, whereas the second
is not. In the first part the route generation of the bus lines have a great ingredient
of luck. Not only the bus lines, the sensors, the route of the cars and some access
points are also randomly generated. So you could end up with really different scenarios
having the same initial simulation values. Whereas in the second part, the simulation
will end up always the same, because the movement of the nodes are the same and the
packet generation and communication among nodes will occur at the same time along
different simulations with the same initial scenario. This happens like this because the
movement of the nodes keeps the same, so the encounters among nodes and therefore
its interchange of packets also remain the same.
However it is thought that the main influence to the performance of the implemented
algorithm is given by the route of the bus lines. The bus lines routes are the only ones
that guarantees you that if a sensor is in the path of it, then all the packets that the
sensor generates are going to be correctly delivered. Of course there are more than one
bus line, but the problem lies on that the path of those bus lines can overlap. So, if
many bus lines routes share the same street for a great part of the route they will be
covering the same part of the map, letting others uncovered. So, the more the bus lines
overlap the lesser map is covered.
But, there are still the cars. These vehicles can still go through those parts of the grid
map where the buses do not go, extending the coverage of the network. The problem
with these type of vehicles is that they are considered as not reliable. A car can not
assure that it will reach an access point delivering the packets or encounter a bus to
transmit it all their packets. The movement of the car is not as predictable as the ones
in the buses, so cars can start moving and stop in any part of the map, perhaps where
the is not any bus route. And if the car was holding packets when it stops and no access
point is near, then all those packets are considered as lost. When a car stops, the time
of the stop are often very large (many hours) compare to the stops that a bus can make
in a bus stop to pick up people (tens of seconds), so the packets that were being carried
would be lost. Also, in particular for our simulation implementation, once the car reach
its destination, it is remove from the scene (from the grid map) so it does not interfere
with the other nodes.
So, here two new concepts are arise: the stable part and the unstable part of the network.
The first is extended along the path of the bus lines and near access points, whereas
the other is the remaining part of the map. This last one depends of occasional vehicles
in order to have connectivity whereas the other is considered to be “always” connected.
This is because in the path of the bus lines sooner or later a bus will pass to pick up
the packets of the zone. The problem with the unstable part of the network is that
a maximum delivery time can not be guarantee and also the delivery of the packet is
no guaranteed. Whereas in the stable part, a certain maximum delivery time can be
assured. This last fact has to be with the frequency that the buses traverse its route.
For the part of the stable network covered by the access points the delivery time of the
packet is almost instantaneous. Nevertheless, having a huge number of cars around all
the map like real cities where there are always cars in every street will make the unstable
part of the network at least assure the delivery of the packet (perhaps not in the desired
time).
In the next section there will be presented some tools that helps to analyse the network,
in order to measure the performance of it and detect their weaknesses. After that, the
results of the simulations (large simulations) will be presented.
5.3 Analysis Tools
What is the performance of the implemented network? How long a packet takes to reach
its destination? How are the packets really reaching the access point? Are the cars a
great influence in order to deliver the packets? What is the covered area of the network?
Which percentage of the packets reach the Internet through only access points?
These questions an others are not answered just looking the output file of the simulation.
They required a more advance tool to understand the results of the simulations. So
among with the simulation platform that was presented in the previous section, a number
of tools were developed in order to easily read the results of the simulations. These
tools includes statistics and graphs and it was completely developed under the python
language using the matplotlib [16] library.
To show how to use and understand what information this tool provides one of the small
simulations that were described in the first part of this chapter is used.
To generate the statistics and the graphs there is the need to run the process sim data.py
script. This script need the output of the last part of the simulation. In general, when
a simulation is run a folder is selected to place the result. Then, this folder will end up
containing three types of files:
• animation.xml
This types of files are generated automatically by the ns3 simulator when the option
AnimationInterface is enable. This files contain information about movement
and communication between the nodes and are used as input in the netanim
SUMO tool. The netanim is used to see in a 2D pane the movement of the nodes.
It also displays other type of information like the IP of each node. It is basically a
graphical tool to see the output of ns3. Nevertheless, for long simulations the tools
becomes unusable because it can not support heavy simulations (it become really
slow). But for small simulations and to see if the simulation platform is correctly
creating the nodes and making the movements of the vehicles it is really helpful.
• nodes positions.log
This file has the position of each node at each simulation step. It permits to
produce the coverage maps that will be presented later in this section.
• corrida-sumo ns3.log
This is the main output of the simulation. It contains lot of information about
encounters, packets generation, packets being delivered, when events happens, and
who intervenes in those events. From this file is that almost all the analysis and
graphs are made.
Now there are presented the different types of lines that could be found in this file:
15s 130 -SENSOR-data_generated:pkt_num=0,node_id=130,x=581,y=312
From this first type of log line several information can be extracted. In this
particular case, this line says that a node of type sensor has created a packet
at the time of 15 seconds of the simulation. It also says that the node with id 130
has created the packet with number 0. Nodes and packets have an id and number
that identifies them uniquely. It also says that the sensor that has produced that
packet is placed in the position (581,312) on the grid map. If you rapidly look
for all the lines in the file that refers to that packet (using the packet id with a
searching tool like grep ) you can find something like this:
17.5018s 1 -BUS-data_transporting:pkt_num=0,node_id=130,x=581,y=312
59.0017s 128 -RSU-data_received:pkt_num=0,node_id=130,x=581,y=312
The first type of line indicates that a node of type bus has picked up that packet
at 17.5 seconds of the simulation. It also indicates that the bus has the node id
number 1. The second type of line shows that an access point of id 128 has received
the packet with id 0 at 59 seconds. So the packet was successfully delivered in 44
seconds (from when it was created to when it has reached the access point).
Therefore, there is enough data on those files that can be correctly processed to generate
very valuable information about many aspects of the network. Hence, now, there will
be presented all the statistics and graphs that the process sim data.py generates using
them.
When the script is run, the corrida-sumo ns3.log file (full path) has to be given. Then
it will generate something like this at the output:
Packets generated: 2832 (100%)

Packets delivered: 2448 (86%)
Packets not delivered: 384 (13%)
Average delivery time: 50
Max delivery time: 573
Min delivery time: 0
All sensors: 16
Sensors that at least one time were reach by a carrier or AP 16
Sensors that were not reach by a carrier nor AP 0
The first three lines indicates the total number of packets that were generated (2832),
the ones that where delivered (2448) and the ones that were not (384). It also shows
the percentage. In this case 86% of the packets were delivered and, of course, the 13%
remaining were not. Then, the next three lines gives information about the delivery
time for the packets. It gives the average delivery time for a packet (50 seconds) and
the maximum and minimum delivery time. Finally, the last three lines give an idea of
the coverage of the network. For example in this case, all the sensors were reach at least
by a carrier or they were directly connected to an access point.
5.3.1 Graphs
The process sim data.py script also generates a number of graphs. Those graphs are
generated in the same directory where the output file of the simulation was placed. All
the graphs are exported as png image files. All the graphs that follow are taken from
a small simulation test that was presented at the beginning of the chapter as probe to
explain the graphs. Now the graphs are presented:
Packets Pie Chart
The first graph is generated under the name of carried packets delivered pie chart.png.
Figure 5.1: Example of a Packets Pie Chart. It shows the destiny of each packet.
The figure 5.1 shows what happen with each packet in the simulation. For example,
it can be seen what percentage of packets were delivered and which part not. In this
case 9% of the packets were picked up by a car but those packets were not delivered
(not delivered car). The rest of packets that were not delivered (not delivered
not trans), 4,6%, are because non carrier nor access point has received those packets.
That gives a total of 13,6% of packets not delivered.
The pie chart also shows how the packets were delivered. In this case, 25,9% of packets
(delivered not transp) were directly transmitted from the sensor to the access point,
39,8% (delivered bus) were delivered to an access point just by a bus and 8,9%
(delivered car) were delivered just by a car. Finally 11,8% (delivered car+bus)
were first picked up by a car, then transmitted to a bus to finally be delivered by the
bus to an access point.
In this case, it is possible to see that there was not any packet that was transported
by a bus (not delivered bus) or by a car plus a bus (not delivered car+bus) and not
delivered (0.0%).
Packets Delivery Time
There are two types of graphs that shows the delivery time for the packets from the
simulation.
Figure 5.2: Packets Delivery Time. It shows what percentage of packets were
delivered at what time.
The figure 5.2 shows an histogram of the delivery time for all the packets that have reach
an access point. The x-axe is given in seconds, and all the bars int the y-axe sum up
1, being 1 the total of packets delivered. In this case it is possible to see, for example,
that 35% of the packets were received before the 13 seconds after the generation of the
packet.
The figure 5.3 is the cumulative distribution function (cdf) of the delivery time. In this
figure it is easy to see that mostly all the packets were delivered before 160 seconds after
its creation.
Coverage Maps
There is a static map coverage that gives an idea of the distribution of the static nodes.
Figure 5.3: Packets Delivery Time. It shows the cumulative of the delivery time for
the packets.
Figure 5.4: Static Coverage Map. Shows the distribution of the sensors (red) and the
access points (blue).
So access point and sensors are placed in a grid of the size of the map. The sensors
are the red dots, whereas the access points are the blue ones. This can be appreciated
in figure 5.4. The y and x axes are in meters. There is one thing to remark: the
circle around the access points are the maximum communication range of them. The
radius of that coverage circle is fixed in 90 meters (as the value was always the same
in all the simulations that were ran). In this particular case, it is highly probable that
4 sensors can communicate directly with an access points as 4 red dots are inside the
circle coverage of 3 access points.
On the other hand, this type of map says nothing about the dynamic part of the network.
The cars and buses were supposed to be used to reach those places where the range of
the access point communication does not.
Figure 5.5: Dynamic Coverage Map. For a certain period of time, it shows the range
coverage of all the network.
Then, a new type of graph was implemented to represent the dynamic part of the
network. The graph is called “dynamic map coverage” and is generated as follows.
Instead of taking only one “picture” of the map with the nodes like in the regular map
coverage, the dynamic coverage map overlaps several “photos” of the network in a single
picture during a period of time. In addition, unlike the static coverage map, the dynamic
one also contains the coverage of the moving nodes (that is, the range of the cars and
buses). The dynamic map coverage is set to cover by default one minute of simulations,
so it is possible to see the coverage area of the network during that period of time (this
period of time can be easily changed in the script). The figure 5.5 shows an example
of that type of map. As it can be seen in that figure, there are still the red and blue
dots that represents the sensors and the access points respectively. But in this case, it
is also possible to identified other nodes. The yellow dots represents the cars and the
green ones the buses. One thing to clarify is that despite the dynamic map coverage
contains lots of yellow and green points, they do not mean that there is one of each
for every yellow and green dot. They are the consequences of the overlapping of the
several photos during that minute when the map was done. So consecutive dots of the
same colour would probably belong to the same car or bus. In addition, somehow, these
repetitions of dots, could be used to describe their routes. The scripts takes every node
from the simulation and paint it over the map at each simulation step that belongs to
that minute of the dynamic coverage map. It is like taking a picture and leaving the
shutter open during one minute. In the picture it is possible to see that the buses and
the cars have also a circle that represents its coverage range like the access points, that
gives an idea of the actual coverage of the network.
So you can identified the two parts that were called stable and unstable parts of the
network. The first composed by the blue and green halos and the unstable part that
would be the yellow halos that the cars leave.
5.3.2 Detailed Statistics
Finally, the scripts also generates a more detailed statistics files. The nodes stats.csv
files. These files present a more detailed information about the simulation. They contain
specific information for each node. These files are intended to look for special cases to
see what happen with a specific sensor or with a specific bus, etc. There are four of
them, one for each type of node:
• aps stats.csv
This file contains the position, the amount of packets received and the id of the
access point.
• sensors stats.csv
This file contains information about all the sensors. In the file you can find the
delivery probability, the position, the node id, number of encounter with another
nodes among others.
• cars stats.csv
• bus stats.csv
Those two files have the same information about cars and buses respectively. In
these files you can find, for example the delivery probability, the node id, how many
sensors have encounter and how many packets each carrier node has transported,
among other information.
These type of files, as they give a very detailed information of each vehicle, among with
the log output files are a great help to find possible errors in the routing protocol or to
understand why and how packets are lost or correctly delivered.
5.4 Results and Analysis
Many simulations where ran. However, here there will be presented the three that are
most meaningful for what it is intended to analyse in this work. Those three large
simulations were run using the parameters that were presented in the last section.
The result of those simulations are presented here without making an average of them.
This was made because of how the information is generated in each simulation; there
were not run many simulations because of time constrains (an entire simulations last
approximately two days and a half) and because some of our conclusions need to look
at them separately.
Now, there are presented the results for each simulation.
The pie chart of packets delivery for the first, second and third simulations can be seen
in figure 5.6, 5.7 and 5.8 respectively.
The first simulation is the one that has gotten the best performance of the network.
In that case 86 % of the packets were correctly delivered to an access point. From the
graphic, it is possible to see the importance of the bus network that has delivered almost
70 % of the packets. It is also important to remark the high coverage of the bus line
network that on its own has manage to deliver 45 % of the packets. On the other hand,
if the network would only be conformed by access points the network would only had
delivered 8.1 % of the packets which is unacceptable to any network. In general for
this simulations and for the others that have been run, the percentage of the packets
delivered directly by access point, and thus the percentage of sensors that are under
the coverage of access points is generally around 10 %. Almost 16 % of packet loss
(“not delivered not trans” + “not delivered bus” + “not delivered car” + “not delivered
car+bus”) could be a high number or not regardless of the type of applications that the
sensors are running. However, not having the moving network of vehicles (buses and
cars) would make the network infeasible with a packet loss of almost 92 %.
Figure 5.6: Packet delivery pie chart for the 1st large simulation.
Figure 5.7: Packet delivery pie chart for the 2nd large simulation.
Figure 5.8: Packet delivery pie chart for the 3rd large simulation.
In addition, it is also important to remark that in the three simulations the percentage
of the packets not delivered by buses, “not delivered bus” and “not delivered car+buses”
are zero or close to zero. This is consistent with the placement of the access points in
the end of each bus line, and with the idea that buses are high reliable nodes which
assures the delivery of the packet.
It is wanted to be notice that the cars have contributed to the good statistic of the
network. By its own cars have delivered 6,5 % of the packets. But there is also a 24,2
% of the packets that probably would not been delivered if the cars were not part of
the network. That 24,2 % of packets that were delivered by a bus where the packet was
previously picked up by a car has help with almost a quarter of the harvest of all the
packets. Despite the fact that a car could have pick a packet from a sensor which is in
the bus network coverage, because it has go through that point before a bus does not
downplay the role of the cars. Why ? This last case could not be the general rule as
the network bus integrated by seven bus line could hardly cover most of the grid map
were the simulation has taken part. So cars are not only responsible for that 6,5 % of
packets it has been mentioned earlier, but for more than 30 % of them. This reflects the
reality very well, where bus lines mostly go only through avenues and do not go through
little streets. Those little streets, then are reached by particular vehicles, extending the
coverage of the network to sensors placed near those areas. This enhance the idea of
using other vehicles rather than only buses as they contribute a lot with the coverage of
the network.
On the other hand, there is the second simulation, where despite the increase in the
percentage of packets delivered by the cars and the ones that were right in the cover area
of an access point the percentage of packets delivered by buses have strongly decrease.
However, this strongly decrease has not been compensated as intended. Almost 28 %
of the packets were lost. But, not all is bad about this situation. It is needed to look
closer to this particular case, where the 2 % of the packets were not delivered because
no vehicle neither access point was there to pick them up. This is not bad at all. It
means that 98 % of the map was covered by the network (access points, buses and cars).
The problem here was that 25,1 % of the packets were picked up by cars but those cars
did not manage to reach an access point nor bumped int a bus.
To understand why this case have some upsides there is the need to compare it to the
third case. In the third case almost 40 % of the packets were not delivered. Despite the
fact that the number of packets that were not delivered by cars that have collected them
has decrease to almost the half, the uncovered part of the map was of 25,4 %. That
means no one has reach a quarter of all the sensors of the map. One could say that in
the third case the algorithm have gotten a better performance than in second. Yes that
is true. However the difference between the second and third case is relevant. In third
case there is nothing to do. Although you manage to improve the routing protocol at
the best, you will be always have the limit of 25,4 % of packets not delivered, because
no vehicles nor access point has been able to cover that part of the map. In the second
case, on the other hand the routing protocol can be improved in order to make those
25,1 % cars that have picked up the packets but were not able to correctly delivered
them. And then, the limit would be in 2 % of the packet that were not picked up.
How the protocol can be improved? In chapter 2 there have been seen many different
protocols that can lead you to improve this one presented here, but the analysis of it is
out of scope of this work.
This differences in the performance of the simulations lead to one possible option. As
the protocol is the same for all the simulations the only cause that should have made
the simulations behave real different is the distribution of the nodes in the network.
This not only means the distribution of the access points and sensors in the map, but
the routes of the different buses and cars. So, in order to go deep in this idea there is
the need for more information. Luckily, the analysis tool that was developed with the
framework comes with some other graphics that could help to understand a bit more of
what is happening with these simulations.
Now there are presented the static map coverages of the three simulations. The figures
5.9, 5.10 and 5.11 correspond to the static map coverage of the first, second and third
large simulations respectively.
Figure 5.9: Static map coverage of the network of the first large simulation.
Figure 5.10: Static map coverage of the network of the second large simulation.
Figure 5.11: Static map coverage of the network of the third large simulation.
The red dots along with the blue ones (and its coverage halo radio) represent the static
coverage area of the network. All the packets generated by the sensors, that in the
map are represented as red dots that lies under the blue halos(access points) are rapidly
delivered as the packets travels directly from the sensor to the access point.
One thing to notice from this type of graphics is that when the blue halo of an access
point is darker than the rest, it means that two (or maybe more, depending of the “level”
of darkness ) access points are placed in the same spot. This could happen because bus
lines shares an endpoint or because a random access point was placed just in the same
place as the endpoint of the bus line. In the three maps the distribution of sensors
do not have anything that calls the attention (there is not any sensor crowding in any
particular area) or anything that could have made any difference in the performance
among the three simulations. In fact, the three maps look really similar.
Another thing to notice is the trend of the access points (blue dotes) to be located int
the edges of the map. This has to be with the algorithm that was made to place them
and with the algorithm that generate the bus lines. Bus lines are generated in order
to make them to communicate opposite edges of the maps and access points are placed
one on each end of each bus lines. Thus, the later trend is explained by this fact and is
consistent to what can be appreciated in the three maps presented.
However the information provided by this type of map is insufficient. Those maps only
show the static part of the network. It says nothing about the vehicles nodes that, as
it has been seen in the pie charts, made the greatest contribution regarding delivering
the packets. But, the analysis tool also generates another type of map that let you see
some information about the moving nodes.
Now there are presented the dynamic map coverage of the three simulations that were
generated with the analysis tool. In figure 5.12, 5.13 and 5.14 there are the three
corresponding dynamic map coverage of the first, second and third simulations respectively.
Figure 5.12: Dynamic map coverage of the network of the first large simulation.
The three figures reveals how the distribution of the majority of the nodes was in each
simulation. The yellow halos represent the movement of the cars. However it is not so
relevant to look too much at the movement of the cars as cars goes randomly and change
with the time, and this snapshot only “last” one minute. Thus, it did not represent the
coverage of the cars during all the simulation (taking a snapshot at another time will
probably give another coverage ). In fact, looking at the network coverage provided by
the cars in this type of map does not add too much information. Despite of this, having
the coverage of cars could be useful in the case where one minute of cars moving could
actually represent the real traffic of the whole time. But here, it is not the case as cars
have random routes.
On the other hand, the green halos represent the movement of the buses. Thus, they
also represent the route of the bus lines. If only the green part is taken into account,
then the dynamic stable coverage part of the network is being seen. It means that all the
sensors that are under that part of the green halo have a great chance of being delivered
Figure 5.13: Dynamic map coverage of the network of the second large simulation.
Figure 5.14: Dynamic map coverage of the network of the third large simulation.
by a bus and within a bounded delivery time, that depends on the frequency of the bus
lines.
One thing to notice is the darkness of the green halos that form routes. When the green
halo is darker, it means that more than one bus is going through there. This also happen
with the yellow ones that represent the cars, and is the similar to what happen with
access points (blue ones). If the darkness is concentrated in one particular place it could
also mean that a vehicle was waiting in there because other was passing in the crossing
street. In the three cases presented, this last type of darkness is not observed, and it
is consistent with the low number of vehicles that go around the whole map. What
is relevant for these cases and to the understanding of why the first case has a better
performance than the other two cases is how the green halos cover the map. Then, the
more number of green halos means more coverage. Taking into account the stable part
of the network (without cars) the total coverage is the blue halos plus the green ones.
Or seeing it from another perspective, the uncovered area will be the white places along
with the yellow halos.
Comparing the figure 5.12 corresponding to the first case against the other two figures
5.13 and 5.14, the first have clearly better coverage than the other two. This is consistent
with the results obtained from the pie chart indicating a huge percentage of packets
delivered by the buses. The better coverage of this stable part of the map is not only
reflected by the direct consequence of more packets being pick up by buses but also
contributes to an increase of the chance that a car carrying packets have to bump into a
bus in order to give to the bus the packets being carried by it. This idea is also consistent
with the results given by the pie chart of the first case where a great number of packets
were delivered by a bus that was previously handed to the bus by a car.
Therefore, this leads to one important conclusions of this work. Despite of the routing
protocol being used by the different actors of the network, the performance of the network
will strongly depends of the particularities of the map. That is to say, it will depends
on how vehicles traverse the streets of the map and on where the routes of the bus lines
go through. So if there is an intention of implementing any protocol of this type for a
particular town or area, then a particular simulation will be needed taking into account
the singularities of it to correctly predict the behaviour of the network when deploying
the real one.
As it has been shown before there are other graphics that the analysis tools generates.
The next graphs being presented have to be with the timing. Here there are presented the
packet delivery time graphic of the simulations. Figures 5.15, 5.16 and 5.17 correspond
to that kind of graphs where it is measure the time that packets took to reach an access
point since it had been produced by a sensor for the first, second and third simulation
respectively. This type of graphics let you know the latency of the network.
Figure 5.15: Distribution of packet delivery time for the first simulation.
In the three graphs there is one thing that stands out. The first bar of each of the
graphs ( that represent the packets that were delivered within the first 20 seconds of
their generation ) is bigger than the others. This high amount of packet belonging to that
bar are mostly explain by the packets that have been directly delivered from the sensor
to the access point, without being transported by any vehicle. These packets added to
the ones that were transported by any vehicle for less than 20 seconds correspond to
that bar.
Moreover, the percentage value of this first bar has to be consistent with the values of
the packets that were delivered directly given by the pie charts graphs. To be consistent
the percentage of packets belonging to the first bar must be bigger or equal to the
value that is given by the pie chart. In our three cases, the three values given for the
first, second and third simulation for the first bar by the packet delivery time graphs
are approximately 12 %, 15 % and 18 %; which are consistent (greater than) the values
Figure 5.16: Distribution of packet Figure 5.17: Distribution of packet

delivery time for the second simulation. delivery time for the third simulation.
(a) Trip time (b) Waiting time
Figure 5.18: CDF of packet trip and waiting time for delivered packets for the first
simulation.
given by the pie chart 8.1 %, 11.5 % and 10,7 % for the first, second and third simulation
respectively.
Another important thing to notice from these three graphs is that a greater amount
of delivered packets seems to come together with an improvement in the time that the
packets take to reach an access point. It is easy to noticed comparing the figure 5.15
belonging to the first simulation against the figures 5.16 and 5.17 belonging to the second
and third simulation respectively. This seems reasonable; when having a better coverage
of the map, packets being picked up by cars are lesser as packets are more probably being
picked up by buses that have limited times to deliver packets(because of the frequency
of the bus line).
However, the analysis can go a bit further regarding the delivery time. The delivery
time consist in the period that a packet takes to reach an access point from its creation.
So, the delivery time can be due to two great reason: the packet spends the majority of
its time travelling, being carried by a vehicle or waiting in the sensor to be picked up
by one or both more or less equal. This difference is treated here as waiting time and
trip time. Here packets that are delivered directly are not considered.
Having information about this can be very useful, and not particularly for this simulations
being presented here. For example if the intention is to reduce the delivery time of the
packets and packets are spending most of its time travelling then for this particular
protocol that use buses more access points in the middle of the routes of the buses
can be put so the packet do not have to wait until the bus reach one of its ends to be
delivered. On the other hand if the problem is that packets are waiting too much time
in the sensors to be picked up another type of solution is needed. In the case of our
simulations, without adding more access points it is not possible to significantly decrease
the delivery time. Of course, if the frequency of the buses increases, then the waiting
Figure 5.19: CDF of packet trip and waiting time for delivered packets for the second
simulation.
time could decrease but this is expected to be an external variable. The only things
that could be change are the ones regarding the network like the access points or the
protocol that all the nodes are using. It is important to see that the idea is to reuse the
already fleet of vehicles that goes around the city without modifying its their trips.
However, following with this last idea, increasing the frequency of the buses has its own
limitation. There are still the other sensors that are not in the route of the buses, that
are picked up exclusively by cars. Then, generating more cars will obviously increase
the time of the delivery of the packets and in particular the waiting time. But again,
in real cases where the density of cars is correctly set for a given map, increasing the
amount of cars is not possible. Although varying the number of vehicles could let the
user have an idea of how the network/protocol behave against this changes.
Then, in figures 5.18, 5.19 and 5.20 graphs for the waiting time and trip time for the
first, second and third simulations respectively.
In particular, in the three cases the values are really similar and significant differences
between trip time and waiting time are not appreciate. One thing to remark is the
expectable difference of the first simulation against the other two, as it has been seen
before that the first has a better delivery time that the others which of course must be
reflected in this two kind of graphics.
One thing to remark to these simulations that were run is that, putting aside the packets
that are lost due to communication errors, the more time the simulation last the lesser
packets will not being delivered. This is because, sooner or later a car will pass by a
sensor that was isolated and could not delivered the packets. However this only applies
to this simulations. This is because some of the hypothesis that it has been make here.
For example, if cars and sensors have limited memory to keep the packets (like in real
Figure 5.20: CDF of packet trip and waiting time for delivered packets for the third
simulation.
life) the last assumption will not be true. When a sensor generates packets, it keeps it
until a vehicle pass by to pick up them. But if after a while, no vehicle has passed by,
then the sensor with limited memory will need to drop some packets in order to make
room for the new ones (in fact that depends of the policy that the protocol have, but a
policy based on a queue is considered here where the old packets are discarded).
This also applies to carrier nodes. Buses tend to hold a considerable amount of packets
compared with cars as this last ones transfer packets to buses as soon as they bump into
one. Of course, the memory of the vehicles is greater, and thus can carry more packets,
than the sensor’s ones. But they also carry packets from many sensors, so a policy for
packet holding would also need to be considered.
Finally when a protocol has reach its top percentage of packet delivery is time to consider
the delivery time of the network. And then is when the time graphs become more
important in order to compare different protocols or versions of the same one to see
which one performs better.
Chapter 6
Conclusion and Perspectives
6.1 Summary
In this chapter there are presented the conclusions of the entire thesis. There are also
present the future steps to continue with this work and the future plans that exist for
the DC4LED project. The future work includes improvements to the simulator platform
that is described in chapter 4 and also some suggestions in order to make improvements
to the Simple Vanet Routing protocol.
6.2 Conclusion
The simulations have proved that at least for the Simple Vanet Protocol the performance
(as percentage of packets that have been delivered) is highly dependent of the movements
of the nodes. More in particular for this case where some moving nodes follow a pattern,
the placement of the bus lines along the map could make a big difference. In addition,
for the advantageous case the protocol still have a mediocre performance (85% of packet
delivery). This performance along with the time consuming for a packet to be delivered
discard several applications that can be served by this routing protocol using this network
infrastructure. However, high-latency non-reliable applications could get use of this type
of network, which is still a large amount of applications. And they could choose this
type of network because of the small need of infrastructure that they require. Of course,
nowadays having radio devices in buses and cars is expensive. But this will not be for
much longer as connectivity for cars is a reality. Finally, this work has left a framework
which can be reuse to easily adapt and modify the scenario and the Simple Vanet Protocol
(other protocols could also be implemented with a bit more effort) to see how it would
106
Chapter 6. Conclusion and Perspectives 107
perform. The protocol as it was presented right in chapter 3 can be improve, as it will
be seen further in this chapter.
6.3 Perspective and Future Work
In the following sections there are presented the possible future steps in order to improve
simulations, the protocol that has been presented. In the last one, some comments are
made about the other works that are in progress regarding the DC4LED project.
6.3.1 Simulation Improvements
When talking about the simulation, and in particular the simulation platform that has
been developed there are two main fields where simulation can be improved. First, there
are several improvements that can be made about the generation of the scenario. This
means, improvements in the movements of the vehicles, both cars and buses making
them more realistic and in the map where the vehicles go around. Second, the network
simulation part can be improved. In this part, most improvements would be about speed
performance. As it has been seen in chapter 5 the simulations that were run took about
two to three days to complete.
Now there are presented two ideas of the first type of improvements that can be made
to the generation of the existing grid scenario.
• Better placement of Access Points : Access points are generated following

two rules. Two access points are place at each end of the bus line, for each bus
line. Then, another small percentage is being placed randomly. The problem with
these two rules is that sometimes, this end up placing APs in the edges of the
map, and just a small number of them in the center part of the map. Then for
example, one improvement would be to place some APs in some middle points of
the path of the bus lines making the distribution of the APs more “fair”. Other
times, APs are place really near of each other. This makes the coverage of the
APs to overlap decreasing the total radio coverage of the map. In a real situation
where APs are placed in a real city it would be a plan to maximize that coverage.
Then some algorithm to make a smarter placement of APs could be proposed and
implemented to the platform.
• Better generation of Bus Lines : Bus lines routes are generated using a script
provided by the SUMO traffic simulator. The platform itself generates the points
that the bus line will connect, without intervening how those paths are created.
As the path between those two points are generated by a shortest path algorithm
some times bus routes overlap despite the end points of the lines are different.
Many times this make that some big parts of the grid map become uncovered by
the bus network (the most stable one, comparing to the one formed by cars) and
others become covered by more than one bus line. Usually, in real cities bus lines
try to cover most of the parts of cities so people from any part of the city can easily
reach any other part using the public transport system. So, a better algorithm
could be proposed to mitigate this problem. One could be that instead of just
providing the end points to form a bus lines, you can provide intermediate points
so that the buses must pass by those points, having more control of the routes.
Nevertheless this is just one possibility in where you can test your protocol in a grid
map scenario. Another approach is to use real map cities. In order to do that you
can use openstreetmap [6] which is an open collection of data from cities from all the
world. The main information serve by this project is related to maps. However, people
can contribute to add information of any kind to those maps. In fact, as it is an open
project there is no limit to what type of information you can load to the project. Despite
of that, the community of openstreetmap have developed some rules in order to organize
the information.
The good thing about openstreetmap is that you can download information about entire
cities in an open-free standard type of file called OSM that comes in xml and json format.
Not only that, the SUMO simulator can automatically load OSM files, in order to use
real street information from cities. This is a great advantage as you can test your
protocol and your network knowing how it will behave in terms of space distribution.
One disadvantage is that, as this is an open project, there are some information about
small cities that could not be available or the information could not be really accurate
or missing. But in general, for basic information (like highways, streets and paths) the
information is available even for small cities.
Another improvement that can be done that also come with the use of openstreetmap
is one regarding the generation of bus lines. In some cities there is available information
about bus line routes, bus stops and frequency of them. This means that you know when
(time and day of the week) a bus pass through each of the bus stops. This is a really
precious information that can be parsed and pass to the SUMO simulator. However this
passage is not as the one described above, where the street information can be directly
imported to SUMO. Unluckily, until now, there is no tool that grabs the routes of the
bus lines and its frequencies on each bus stop and generate the corresponding SUMO
route files (see chapter 4) that describes the behaviour of vehicles. But this is a feature
completely feasible. One important thing is that these bus information is very accurate
as is not one of the main information of the openstreetmap. Even more, if you want
to load this type of information to the openstreetmap project, it is not that simple
because not all the companies provide these kind of information. Just because transport
companies do not have it or they do not want to make it public.
For now, if anyone want to make simulations using real transport information, he/she
has to process the information that transport companies provide in the format that each
of them provide. Not only that, those companies could also provide different type of
information. Some could have only the routes while other can also have the frequency
of the services. Not only that, in some cities the transport system is not only in the
hands of one company. For example in the city of Rennes (1 ) you can find an unique
company that is in charge of bicycles, buses and the metro. The same company also
offers publicly the data (routes, frequency and more) of that three services (2 ). Whereas,
for example in the city of Buenos Aires (3 ) there are more than one hundred and fifty
bus lines managed by different small companies. In this last case, one can imagine the
dispersion of the information of the transport system and how the information can be
presented in different ways. So, opposite to map information, there is not a unique way
of how the transport information can come, making the export of this information to a
tool like SUMO more complicated.
Speed Improvements
As it has been seen in chapter 5 simulations can last too much time. The simulations
that were ran using around two hundred of nodes have lasted more or less three days.
This is because the ns3 simulator is not prepared for medium to large scale vehicular
networks. In fact, there are not many network simulators which well support that.
However, it exist some improvements which permit to keep all the benefits of the ns3
simulator while using a large number of nodes in a WIFI network. In paper [15] there is
presented an analysis of the problem of scalability in ns3. They have found that many
pointless of calculation are made due to how the WIFI channel has been modelled in ns3.
As the medium of the WIFI is the air where radio waves propagate, there is only one
medium defined in the simulation. The problem when simulating a very large number of
nodes that are spread in a large scenario is that packets are considered for all the nodes
attached to that channel (medium). Even though those nodes are really far away from
where the packet was originated.
1
http://en.wikipedia.org/wiki/Rennes
2
http://www.data.rennesmetropole.fr/
3
http://en.wikipedia.org/wiki/Buenos Aires
The authors of that work have found that this decrease in performance is because the
WIFI channel (the air) has been modelled as a raw list. So, they have proposed a
geographical concerned structure to supply that list. They have used a quadtree (4 )
which is a spacial aware tree data structure. Using mainly that structure they have
managed to decrease the simulation time one hundred times.
So, it would be great to have that improvement in our platform, so simulations can go
from lasting three days to less than an hour.
6.3.2 Improvements to the Simple Vanet Routing Protocol
As it has been seen the protocol proposed in chapter 3 is really simple. But in the chapter
2 it has been seen many protocols with many different ideas that could improve the
Simple Vanet Routing Protocol. Without changing the addressing of the protocol, the
main improvements that can apply are related to the ones that make use of encounters
statistics.
From the packet delivery pie chart presented in chapter 5 you can infer that in terms of
delivery probability (and not in terms of delivery time) there are mainly two situations
where packets have not been delivered. One part belongs to sensors that were out of
any kind of overage. This means that no vehicle have passed by near the sensor where
the packet was generated in order to deliver it. Not even an access point was close to
that sensor. This case is not able to be improved. At least, not with a modification to
the routing protocol. The other part of packets that have not been delivered belongs
to those that were picked up by a car, but the car could not reach an access point
neither encountered any bus. Those cars just stopped without delivering the packets,
keeping them until the end of the simulation. In this case, the routing protocol could
do something in order to deliver the packet.
Here it is not the intention to give a specific and well done improvement, but to give
some insights. For example, one kind of improvement could be that in case a packet is
picked up by a car, which is considered as an untrusted vehicle, the sensor could save
another copy of the packet to be picked up by another vehicle. Then packets being
picked up by untrusted vehicles would have more chances to be delivered as they are
more than one copy of them in the network.
This last is just a straightforward idea that requires very little modification to the
protocol that could improve a lot the delivery rate.
4
http://en.wikipedia.org/wiki/Quadtree
Another simple improvement that put the focus on the delivery time could be to use
dynamic delivery time statistics in each vehicle so sensors could pass on packets to
vehicles that satisfy its own delivery time needs.
On the other hand, there is another aspect that is not related to the routing protocol that
could and possibly need to be improve in the protocol stack. The IEEE 802.11p as it has
been seen in other sections does not implement any correction to any communications
error that could happen when transmitting. It has been seen that a percentage of packet
in the simulation were transmitted from a sensor, but they have not reach any other
node. This means that an interference or any radio stuff has happen and the protocol
stack has not been able to deal with it. Then, an improvement to the link layer or what
it has been named as Encounter layer proposed in section 3.4.
6.3.3 Future Work on DC4LED
This current work has born along with the idea of the DC4LED project. So, this was
the first work for it. However, at the time that this work was being developed other
works were started that are involved with the DC4LED project. One particular concern
was the security issue, so students have started to worked in that part of the project in
the laboratories of the Network Department (5 ) of the Telecom Bretagne University at
Rennes, France.
At the time of writing this thesis those are all the efforts that are currently being done
for this project. However, the idea is to incorporate more students in order to go deep
in this field as this is a very promising research field.
5
http://departements.telecombretagne.eu/rsm
Appendix A
Tutorial: Installing the Vanet

Platform
112
How to Sumo ns3 Simulator

Requirements

● Mercurial (hg) as repository tool, for getting the ns3 code.
● Java (possibly already installed, just try java in the console).

Sumo

Having Ubuntu 12.04 LTS, Sumo traffic simulator can be easily install from a ppa.
So, add the ppa like this:

$> sudo addaptrepository ppa:sumo/stable
$> sudo aptitude update

Packets to be install are:
● sumo
● sumotools
● sumodoc

At the time of doing this, the sumo version was 0.17.1. There are some problems with versions
greater than 0.18.0. So, you can also manually install a specific version.
To install a specific version you can follow these steps (taken from here
http://alibalador.blogspot.com.ar/2013/03/installingsumowithguionubuntu1204.html):

Install some prerequisites to compile the code (under ubuntu 12.04):

$> sudo aptitude install libgdal1dev proj libxercesc2dev
$> sudo aptget install libfox1.6dev libgl1mesadev libglu1mesadev

Create symbolic link to library:
$> sudo ln s /usr/lib/libgdal1.7.0.so /usr/lib/libgdal.so

Download the source code from http://sourceforge.net/projects/sumo/files/sumo. The extract the
files:
$> tar -xzvf sumo-src-<version>.tar.gz

Move the files to the corresponding installation directory and go to that directory:
$> sudo mv -v sumo-<version> /usr/local/src
$> cd /usr/local/src/sumo-version

Now, configure and compile sumo:
$> ./configure withfoxincludes=/usr/include/fox1.6 \
withgdalincludes=/usr/include/gdal withprojlibraries=/usr \
withgdallibraries=/usr withprojgdal withpython
$> make

Finally, install it:
$> sudo make install

NS3

Here in this tutorial there is mainly follow the installation guide found in this link:
http://www.nsnam.org/wiki/index.php/Installation.
There is a allinone repository to work with ns3 and their frequently used tools. Despite of this,
The allinone repository only contains some scripts to get the code from the real repositories
where ns3 and other tools are really stored.
Then, get that repository:

$> mkdir repo
$> hg clone http://code.nsnam.org/ns-3-allinone

Now that you got the scripts, download the real code:

$> cd ns3allinone
$> ./download.py -n ns-3-dev
This basically download the ns3 code in the folder ns-3-dev, the netanim folder (a tool for
visualization) and the nsc folder. The other last two are tools that ns3 requires.
At the moment of making this tutorial the development version of the ns3 was the 3.16. So,
if you find some problems compiling or making the code work, you can consider downloading
version 3.16.
Because we have modify the code, we use our own repository for the ns3 source code. So
delete the original ns3 folder and get the code from our repository. Finally rename the folder:
$> rm -rf ns-3-dev

$> hg clone https://bitbucket.org/pablin87/ns3-sumo-vanet-simulation
$> mv ns3-sumo-vanet-simulation ns-3-dev

Compilation

Compilation requirements

This project was developed in a Ubuntu 12.04 machine, so compilation requirements are listed
as packets for this debian distribution. For installing this packets in other machines (not debian
based) see the official installation guide from ns3:
http://www.nsnam.org/wiki/index.php/Installation

Just the usual ones to compile C++ code and some others:
● gcc
● g++
● python
● python-dev
● bzr
● gdb
● valgrind

This are not strictly needed, but recommended:

● sqlite sqlite3 libsqlite3-dev
● libgtk2.0-0 libgtk2.0-dev
● libxml2 libxml2-dev
● gsl-bin libgsl0-dev libgsl0ldbl

Others (for document generation ):
● doxygen graphviz imagemagick
● texlive texlive-extra-utils texlive-latex-extra
● python-sphinx dia

Now compile the code.
In the ns3allinone folder run:

$> ./build.py

After it finish building the code you should see all the modules that were compile in the ns3.
Something like this:

Modules built:
antenna aodv applications
bridge buildings configstore
core csma csmalayout
dsdv dsr emu
energy flowmonitor internet
lte mesh mobility
mpi netanim (no Python) network
nixvectorrouting olsr pointtopoint
pointtopointlayout propagation spectrum
stats tapbridge test (no Python)
tools topologyread uan
vanet (no Python) virtualnetdevice wifi
wimax

The red module vanet, it is our module ! So, great ! You have just finished the installation. Now
you can use the programs and the scripts to make some simulations.

As the program to run simulations is part of an example inside the vanet module, examples must
be build. Also to enable the tests is a good idea to see if everything is going ok.
For this, enter the ns3 folder and build them:

$> cd ns3dev
$> ./waf configure enableexamples enabletests
$> ./waf build

Then you can run the test(it will take a while):
$> ./test.py

Python

Python 2.7 is required for running python scripts that generate the sumo scenario and parse the
traces. Also the statistics and graphs are generated by python.

Python Libraries required:
● matplotlib

The python scripts that generates the grid map utilice some sumo tools, so you must specify
where they are installed. Then, the following variables in the config.ini file must be correctly set:

traceexporter_path = '/usr/share/sumo/tools/traceExporter/traceExporter.jar'
randomstrip_path = '/usr/share/sumo/tools/trip/randomTrips.py'

The paths given in this example are just examples. To know where are your files you can do the
following:
$>sudo updatedb
$> locate traceExporter.jar
$> locate randomTrips.py

Running Simulations

To make some simulations, you must first define where your scenario is taking place. That
means, how the vehicles in the vanet move. For this we can use the sumo scripts which are
placed in ns3dev/sumo/scripts folder. The README placed there explains how variables can
be modify to control vehicles behaviour.
After generating the scenario, that means the map where the nodes are placed, the traces of the
vehicles and the position of the access points and sensors, you are ready to simulate the
communication part (using ns3).
In order to do so, you have to configure the runvanetexample.sh file and run it. A detailed
explanation of what parameters you can modify in order to obtain different results is written at the
beginning of the file.

Appendix B
Data Dictionary of Platform

Classes
In this appendix there are describe the most relevant attributes and methods of the
classes from some of the classes that implemented for the simulation platform.
B.1 Encounter Protocol Classes, from figure 4.6
EncounterMacServL3Protocol
Attributes:
• m prot number: 2 bytes code number that identifies the protocol with the lower
layers of the ns3 framework.
• m sender type: this can take 3 values and is used to identify the type of node
where the protocol is installed. Tha values are SND SENSOR, SND CARRIER
and SND ROAD SIDE UNIT that represents the 3 main types of nodes; sensor,
carriers (bus or car) and access points.
• m beaconing time: time between each ”Hello, i am in range” beacon.
Methods:
• sendDataPacket: create a data packet setting the string given as the payload
and send it to the specified mac address.
118
Appendix B. Data Dictionary of Platform Classes 119
• sendBeaconAndReSchecule: send a ”Hello, i am in range” beacon to the

broadcast address and set a timer according to the m beaconing time to call this
function again.
• registerCallbackNewEncounter: register a callback that will be called when a

new neighbour is discovered.
• registerCallbackRecvPktFromSender: After a new neighbour is discovered,

a callback can be set, associated with that neighbour (mac address), to process
specific packets from that node.
• setUp: install the protocol in the net device of the current node and start
beaconing (in other words, configure and “start” the protocol in the node).
• packetReceived: this method is called each time a packet for this protocol
appears in the net device in the current node. It handles all the logic of processing
the packet, updating the mac encounter table and firing up corresponding callbacks.
EncounterMacTable
Methods:
• addEncounterEntry: add an entry for a new neighbour in the table and schedule
an expiration time for that node.
• updateEntry: reset the expiration timer for the given neighbour node.
• getNeighbours: returns a list of all the neighbours that are in range at the
moment.
EncounterMacHeader
Attributes:
• m packet type: this attribute is used to discriminate data packets from beacon
packets. The possible values are : PKT DATA, PKT NEIGBORING and PKT NEIGBORING AC
• m sender type: is used to distinguish the type of node that is sending the packet.
It can have the same values as the m sender type attribute in the EncounterMacServL3Protocol.
PassiveEncounterMacServL3Protocol
Methods:
• setUp: overwrites the setUp method of the EncounterMacServL3Protocol. Unlike

the parent method, it does not start to send beacons (registers the protocol in the
node, and “start” the protocol).
B.2 Simple Vanet Protocol Classes, from figure 4.7
SimpleVanetProtocolCarrier
Attributes:
• m transporting packets: queue where collected packets are store until the
current carrier node finds a AP to deliver them.
Methods:
• setUp: look for a EncounterMacServL3Protocol object in the current node and

register the required callbacks to be call when a new encounter is called. In
addition, set sender type of the encounter protocol to be SND CARRIER and
the extension of the mac header to be CARRIER BUS.
• receivedDataPkt: to be called when a data packet arrives from the underlying

layer, enqueue the packet in the unless m transporting packets queue unless there
is a RSU (AP) node in the encounter table. For that case, just re send the packet
to the AP.
• newCarrierEncounter: called when a new carrier neighbour is encountered

(sender type equals to SND CARRIER), check if the extension header is equal
to CARRIER UNTRUSTED (a car) in order to start to receive data packets from
it.
• newSourceEncounter: register a callback to receive data packets from the

new sensor neighbour encountered. The callback registered calls the method
enqueueDataPkt.
• newRSUEncounter: call the sendAllTransportingPackets method with the address

of the new encountered access point.
• enqueueDataPkt: Save incoming data packet in the internal queue (m transporting packets).
• sendAllTransportingPackets: send all packets stored in the internal queue to

the given address.
SimpleVanetProtocolSource
Attributes:
• m attending packets: internal queue of data packets waiting for a carrier or AP

node.
Methods:
• setUp: look for a EncounterMacServL3Protocol object in the current node and set
the sender type to SND SENSOR. Finally, set the method newEncounterDetected
to be the callback when a new neighbour is detected by the underlying encounter
layer.
• sendData: check if there is an access point or a carrier. If there is one, send the
packet to it (AP, of course, has priority over any carrier node). If there is not,
store the packet into the internal m attending packets queue.
• enqueueData: just enqueue the given data.
• selectCarrierOrRsu: return the address of a RSU node (access point). If there

is not one available, then return the address of a carrier node with less expiration
time (if any).
• newEncounterDetected: check if the new encountered node is of sender type

carrier or RSU (checking a tag in the packet to be SND CARRIER or SND ROAD SIDE UNIT ).
If that is the case, then send all the packets store in its internal queue to the new
node.
SimpleVanetProtocolCarrierUntrusted
Methods:
• newCarrierEncounter: this method is called when a new carrier node is encountered.

When that happens it checks for the extended header to see if it is a CARRIER BUS.
In other words, it checks if the new node is a bus and not a car. If that is the case,
then send all the packets it has in its internal queue to the bus node.
• setUp: overrides the parent setUp method setting the extension tag (in the
packets that the node will send) to be CARRIER UNTRUSTED instead of CARRIER BUS.
SimpleVanetProtocolRSU
Methods:
• setUp: look for a EncounterMacServL3Protocol object in the current node and set
the sender type to SND ROAD SIDE UNIT. Also register the method newEncounter
method to be the callback to be called when the encounter protocol finds a new
neighbour.
• newEncounter: when this function is called, register the method receivedDataPkt

to be called when a data packet from the new node given (this is done using the
mac address) is received. In this case, it does not make any difference regarding
the type of the new node.
• receivedDataPkt: “send” the received packet to the Internet. The quotes is

because, as this is a simulation, the only thing that this method does is to log a
success message indicating the correct delivery of the packet.
Bibliography
[1] http://en.wikipedia.org/wiki/6LoWPAN, https://tools.ietf.org/wg/6lowpan,

November 2012.
[2] http://en.wikipedia.org/wiki/Contiki, November 2012.
[3] http://en.wikipedia.org/wiki/ZigBee, November 2012.
[4] http://http://en.wikipedia.org/wiki/OSI model, November 2012.
[5] http://www.data.rennes-metropole.fr, November 2012.
[6] http://www.openstreetmap.org, November 2012.
[7] INFOCOM 2009 (ed.), Encounter–Based Routing in DTNs, 2009.
[8] INFOCOM 2010 (ed.), SPRING: A Social-based Privacy- preserving Packet

Forwarding Protocol for Vehicular Delay Tolerant Networks, August 2009.
[9] Giuseppe Anastasi, Marco Conti, and Mario Di Francesco, Data Collection in
Sensor Networks with Data Mules: an Integrated Simulation Analysis, 2007.
[10] Genping Liu Bu-Sung Lee Chuan-Heng Foh Kai-Juan Wong Boon-Chong Seet and
Keok-Kee Lee, A-STAR: A Mobile Ad Hoc Routing Strategyfor Metropolis Vehicular
Communications, 2004.
[11] John Burgess, Brian Gallagher, David Jensen, and Brian Neil Levine, MaxProp:
Routing for Vehicle-Based Disruption-Tolerant Networks.
[12] Navraj Chohan and Camilla Fiorese, CycleNet: Empirical Analysis of 802.15.4 in
Mobile Scenarios, July 2008.
[13] Adam Dunkels, The ContikiMAC Radio Duty Cycling Protocol, Tech. report,
December 2011.
[14] Faculty of Computer Science and Information System, Malaysia, A Review of Delay
Aware Routing Protocols in MANET, June 2009.
123
Bibliography 124
[15] Ricardo Fernandes and Michel Ferreira, Scalable VANET Simulations with NS-3,
2012.
[16] J. D. Hunter, Matplotlib: A 2D graphics environment, www.matplotlib.org,

Computing In Science & Engineering 9 (2007), no. 3, 90–95.
[17] IEEE (ed.), Vehicle-to-Vehicle Wireless Communication Protocols for Enhancing

Highway Traffic Safety, January 2006.
[18] IEEE (ed.), Routing in Vehicular Ad Hoc Networks: A Survey, June 2007.
[19] IEEE (ed.), INTER-VEHICLE COMMUNICATION SYSTEMS: A SURVEY,

2008.
[20] IEEE (ed.), A Survey of Inter-Vehicle Communication Protocols and Their

Applications, 2009.
[21] IEEE, Amendment 6: Wireless Access in Vehicular Environments, Tech. report,

IEEE, 2010.
[22] Ilias Leontiadis and Cecilia Mascolo, GeOpps: Geographical Opportunistic Routing
for Vehicular Networks.
[23] Emiliano Miluzzo, Xiao Zheng, Krist´ f Fodor, and Andrew T. Campbell, Radio
Characterization of 802.15.4 and Its Impact on the Design of Mobile Sensor
Networks, 2008.
[24] Rahul C. Shah, Sumit Roy, Sushant Jain, and Waylon Brunette, Data MULEs:
Modeling a Three-tier Architecture for Sparse Sensor Networks, 2003.
[25] William Stallings, Data and Computer Communications, 8 ed., pp. 457–465,
Pearson, 2007.

Berri Lio

Uploaded by

Copyright:

Available Formats

You might also like

Berri Lio

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Berri Lio

Uploaded by

Copyright:

Available Formats

Exploiting Vehicular Networks for Data

Collection in Smart Cities

Pablo Daniel Berrilio

An Engineering Thesis submitted to:

Fulfillment of the requirement of the degree of

Facultad de Ingenierı́a - Universidad de Buenos Aires

Co-directed engineering thesis between the Universidad de Buenos Aires and

List of Figures viii

2 State of the Art 3

3 Proposal: A Data Collection Infrastructure 34

3.2.1 Fixed Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Simulation Results and Analysis 75

6 Conclusion and Perspectives 106

6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A Tutorial: Installing the Vanet Platform 112

B Data Dictionary of Platform Classes 118

2.1 Types of Vehicular Applications . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Tools integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1 Packets Pie Chart (Small) . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.19 CDF Packet Trip/Waiting Time (Large Simulation 2) . . . . . . . . . . . 104

State of the Art

2.1 Intelligent Transport System

Figure 2.1: A classification for vehicular applications.

2.1.3 Addressing and Routing

2.2 Sensor Networks

The current bibliography about vehicular networks do not contemplate communication

In addition, MANETs need to overcome energy constrains. As many of these type of

• Optimized Link State Routing (OLSR) is a standard pro-active protocol.

• Ad-hoc On-demand Distance Vector (AODV) is a standard reactive protocol.

• Dynamic Source Routing (DSR) is also an standard reactive protocol like

2.4 Delay Tolerant Networks

2.4.1 Vehicular Delay Tolerant Networks

2.5 VANETs vs VDTNs

2.6 Security in Vehicular Networks

2.7 Existing Vehicular Routing Protocols

2.7.2 Spread and Wait (S&W)

(a) S has a packet to D. (b) Spread phase. (c) Wait phase.

Figure 2.2: Spread and Wait Propagation.

“Destination”. Besides, node A and B are moving in a particular direction described

Figure 2.4: Case where MoVe performs better than GPSR.

2.7.4 Anchor-based Street and Traffic Aware Routing

is a source routing protocol, because when it sends a packet to a destination it includes

The Geographical Opportunistic (GeOpps) routing protocol is a location based, carry

When a packet is received by a vehicle it calculates the Minimum Estimated Time of

M ET D = EsitmatedtimetoN P + Estimatedtimef romN P toDest

EDL = P (case1) + P (case2) + P (case3) + P (case4) 5

2.7.7 Encounter Base Routing

The Encounter Base Routing (EBR [7] ) is an encounter-statistic, quota-flooding base

The rest of replicas will be continued carried on by A.

2.8 Data Mules

2.9 The WiFi Standard

2.9.1 IEEE 802.11p

2.9.2 IEEE 802.15.4

Proposal: A Data Collection

3.2 Nodes Infrastructure

3.2.1 Fixed Nodes

3.2.1.1 Access Points