Exploiting Vehicular Networks for Data Collection in Smart

Exploiting Vehicular Networks for DataCollection 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 Informatica

Departamento de Computacion

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 mas 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.

1https://www.zigbee.org2http://www.arduino.cc3http://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.

4http://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

1http://www.ietf.org/rfc/rfc3626.txt2Internet 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.

3As the reader could already realise, the word vehicle and node is used interchangeably when talkingabout vehicular networks.

4Figure 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:

METD = EsitmatedtimetoNP + EstimatedtimefromNPtoDest

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 NPa, NPb and NPc. 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

5Being P() the probability function, calculating each P(case*) only requires the encounter table, thathas the probability that a node X encounters a node Y. Then following with the example computingP(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 = α ∗ CWC + (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:

m ∗ EVBEVB+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

6WIFI 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.

7Percentage of the time that the radio transceiver is on in order to detect that another node is tryingto transfer some data.

8http://en.wikipedia.org/wiki/CSMA/CA9http://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 time1 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

1period of time in where two nodes are able to communicate because they are in a range that lets itsradio 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 ofOSI 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 Encounterprotocol.

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.

2https://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.

1Red boxes represent logic structures, green ones represent files, the blue ones represent functions orprocedures 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 scenariogeneration.

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 trafficsimulator.

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.

2https://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 detaileddescription 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 detailedexplanation 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 networksimulator.

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:

Frequency =troundTrip

#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:

troundTrip =#EdgesroundTrip ∗ edgeSize

maxSpeed ∗ µ

Where :

• #EdgesroundTrip 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 weredelivered 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 forthe packets.

Figure 5.4: Static Coverage Map. Shows the distribution of the sensors (red) and theaccess 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 rangecoverage 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 packetdelivery time for the second simulation.

Figure 5.17: Distribution of packetdelivery 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 firstsimulation.

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 secondsimulation.

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 thirdsimulation.

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.

1http://en.wikipedia.org/wiki/Rennes2http://www.data.rennesmetropole.fr/3http://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.

4http://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.

5http://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 ACK.

• 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.

Documents

Exploiting Vehicular Networks for Data Collection in Smart