implementations of the dtm, dadcq and slab vanet …33508/datastream... · vii implementation of...
TRANSCRIPT
IMPLEMENTATIONS OF THE DTM, DADCQ AND SLAB VANET BROADCAST
PROTOCOLS FOR THE NS-3 SIMULATOR
by
Ahmed M. Alwakeel
A Thesis Submitted to the Faculty of
The College of Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Science
Florida Atlantic University
Boca Raton, FL
May 2016
ii
Copyright 2016 by Ahmed Alwakeel
iv
ACKNOWLEDGEMENTS
I would like to express sincere gratitude to the committee members for all of their
guidance and support through the process of working on this thesis, and special
thanks to my advisor professor Imad for his persistence, patience and
encouragement during my journey to get this degree. finally, I wish to thank all
Tcore lab members for all of their support.
v
ABSTRACT
Author: Ahmed M. Alwakeel
Title: Implementations Of The DTM, DADCQ And SLAB VANET
Broadcast Protocols For The Ns-3 Simulator
Institution: Florida Atlantic University
Thesis Advisor: Dr. Imad Mahgoub
Degree: Master of Science
Year: 2016
This work presents the implementations of three adaptive broadcast protocols for
vehicular ad hoc networks (VANET) using the Network Simulator 3 (Ns-3).
Performing real life tests for VANET protocols is very costly and risky, so
simulation becomes a viable alternative technique. Ns-3 is one of the most
advanced open source network simulators. Yet Ns-3 lacks implementations of
broadcast protocols for VANET. We first implement the Distance to Mean (DTM)
protocol, which uses the distance to mean to determine if a node should
rebroadcast or not. We then implement the Distribution-Adaptive Distance with
Channel Quality (DADCQ) protocol, which uses node distribution, channel quality
and distance to determine if a node should favor rebroadcasting. The third
protocol, Statistical Location-Assisted Broadcast protocol (SLAB), is an
improvement of DADCQ which automates the threshold function design using
vi
machine learning. Our NS-3 implementations of the three protocols have been
validated against their JiST/SWANS implementations.
To my loving parents & Raheeq
vii
IMPLEMENTATION OF THE DTM, DADCQ AND SLAB VANET BROADCAST
PROTOCOLS FOR THE NS-3 SIMULATOR
CHAPTER 1 INTRODUCTION ............................................................................. 1
Introduction .............................................................................................. 1
Wave Ieee802.11p Standard ................................................................... 1
Wireless Broadcast.................................................................................. 3
Problem Statement .................................................................................. 6
Contribution ............................................................................................. 7
Organization ............................................................................................ 7
CHAPTER 2 VANET BROADCAST PROTOCOLS SURVEY .............................. 9
Introduction .............................................................................................. 9
Requirements Of Broadcast Protocol .................................................... 10
Broadcast Protocol Evaluation Metrics .................................................. 11
Broadcast Protocol Classification .......................................................... 12
2.4.1 Statistical Broadcast Protocols ....................................................... 13
2.4.2 Topology Broadcast Protocols ........................................................ 17
CHAPTER 3 NETWORK SIMULATION TOOLS AND TRAFFIC
SIMULATION TOOLS FOR VANET ................................................................... 22
Introduction ............................................................................................ 22
Vanet Simulation Challenges ................................................................ 22
Mobility Modeling ................................................................................... 24
Traffic Simulators .................................................................................. 26
Network Simulators ............................................................................... 31
3.5.1 Opnet .............................................................................................. 32
3.5.2 Qualnet ........................................................................................... 33
3.5.3 Omnet++ ......................................................................................... 34
Integrated Vanet Simulation Tools ........................................................ 37
viii
Conclusion .................................................................................................... 42
CHAPTER 4 NETWOR SIMULATOR NS-3........................................................ 43
CHAPTER 5 IMPLEMENTATION OF DISTANCE TO MEAN
PROTOCOL ON NS3 ......................................................................................... 49
Introduction ............................................................................................ 49
Protocol Details ..................................................................................... 49
Implementation Details .......................................................................... 52
Conclusion ............................................................................................. 63
CHAPTER 6 IMPLEMENTATION OF DISTRIBUTION-ADAPTIVE
DISTANCE WITH CHANNEL QUALITY (DADCQ) PROTOC ............................ 64
Introduction ............................................................................................ 64
Dadcq Protocol Details .......................................................................... 64
Implementation Details .......................................................................... 67
Conclusion ............................................................................................. 79
CHAPTER 7 IMPLEMENTATION OF STATISTICAL LOCATION
ASSISTED BROADCAST PROTOCOL FOR VANET ON NS3 .......................... 80
Introduction ............................................................................................ 80
Implementation ...................................................................................... 87
Conclusion ............................................................................................. 95
CHAPTER 8 Evaluation, VERIFICATION AND validation OF
THE PROTOCOLS ............................................................................................. 97
Evaluation .............................................................................................. 97
Validation ............................................................................................. 105
Verification ........................................................................................... 107
Conclusion ........................................................................................... 108
CHAPTER 9 CONCLUSION and future work ................................................... 109
Conclusion ........................................................................................... 109
Future Work ......................................................................................... 110
ix
LIST OF TABLES
Table 1 Qualitative comparison of broadcast protocols [19] ............................... 5
Table 2 Broadcast protocol metrics .................................................................. 12
Table 3 Implementations of broadcast protocol on simulators [19] ................... 21
Table 4 overview of mobility models in VANET simulation [20] ........................ 25
Table 5 Traffic Simulators Compare ................................................................. 31
Table 6 comparison different integrated simulators [26] ................................... 42
Table 7 comparing Ns2 and Ns3 ...................................................................... 45
Table 8 comparing different network simulators ............................................... 48
Table 9 Input Weights for MLB function ............................................................ 85
Table 10 Simulation Parameters ........................................................................ 99
Table 11 SLAB reachability results for the Ns-3 and JiST/SWANS
Implementations ................................................................................ 106
Table 12 SLAB broadcasts per covered node results for the Ns-3 and
JiST/SWANS Implementations .......................................................... 106
x
LIST OF FIGURES
Figure 1 Wave Architecture ................................................................................ 2
Figure 2 VANET Simulation components ......................................................... 27
Figure 3 Road Topology Examples .................................................................. 29
Figure 4 OPNET GUI ........................................................................................ 33
Figure 5 QUALNET GUI [31] ............................................................................ 34
Figure 6 OMNET++ Architecture ...................................................................... 36
Figure 7 OMNET++ GUI ................................................................................... 37
Figure 8 Trans architecture............................................................................... 38
Figure 9 MOVE GUI ......................................................................................... 39
Figure 10 MOVE Architecture ............................................................................. 40
Figure 11 CAVENET architecture [29] ................................................................ 41
Figure 12 Ns3 Architecture ................................................................................. 46
Figure 13 Ns3 Models ........................................................................................ 47
Figure 14 DTM General Activity Diagram ........................................................... 51
Figure 15 Urban road topology used to simulate DTM ....................................... 53
Figure 16 Extracting trace file from SUMO to Ns3 .............................................. 53
Figure 17 Activity Diagram for setting the environment ...................................... 57
Figure 18 ReceivingPacket() Activity Diagram.................................................... 58
Figure 19 Receiving hello message .................................................................... 60
xi
Figure 20 Activity Diagram for receiving a warning message ............................. 61
Figure 21 DADCQ protocol activity Diagram ...................................................... 67
Figure 22 Urban road topology used to simulate DADCQ .................................. 68
Figure 23 Highway road topology used to simulate DADCQ .............................. 68
Figure 24 Generating trace file for Ns3 using SUMO ......................................... 69
Figure 25 DADCQ activity Diagram .................................................................... 70
Figure 26 General Activity Diagram for SLAB protocol ....................................... 82
Figure 27 SLAB activity diagram ........................................................................ 86
Figure 28 Urban road topology used to simulate SLAB ...................................... 87
Figure 29 Urban road topology used to simulate SLAB ...................................... 88
Figure 30 steps to extract trace file from sumo ................................................... 88
Figure 31 Creating Simulation environment for SLAB activity Diagram .............. 91
Figure 32 Receive Message function+ ............................................................... 93
Figure 33 Rebroadcasted messages Vs Received Messages in SLAB
DADCQ and DTM in highway scenario ............................................. 100
Figure 34 Rebroadcasted messages Vs Received Messages in SLAB
DADCQ and DTM in Urban scenario ................................................ 101
Figure 35 Bytes Sent per covered node Highway Scenario ............................. 102
Figure 36 Bytes Sent per covered node urban Scenario .................................. 103
Figure 37 Reachability in Highway Scenario .................................................... 104
Figure 38 Reachability in Urban Scenario ........................................................ 105
Figure 39 NetAnime animation for SLAB protocol ............................................ 107
1
CHAPTER 1 INTRODUCTION
INTRODUCTION
VANET is an emerging technology that has many important safety and none
safety applications. Many safety applications require efficient methods to
disseminate warning messages. Broadcasting can be considered as the most
suitable method to transmit warning messages among various nodes in the
network [2]. The different environments in VANET such as urban and highway
environments can create different challenges for the design of the broadcast
protocol. This work aims to implement and deliver three Broadcast protocols for
Ns-3.
WAVE IEEE802.11P STANDARD
Since Vehicular ad hoc networks have a lot of unique features that distinguish
them from MANET. Using regular WIFI or even cellular wireless networking will
not be suitable in VANET. So there is a need for appropriate communication
standard, (IEEE 802.11p) A new standard was introduced in 2006 which is IEEE
802.11p that defines the medium access control layer (MAC) as well as the
physical layer (PHY) that can deal with the fast movement of vehicles and
change of the topology of the network. Wireless access in Vehicular Environment
(WAVE) has its unique architecture to serve the need of creating secure high
2
performance communication links between vehicular nodes. This structure
consist of five main parts [6] which are:
1. IEEE 802.11p WAVE this one is a remedy of the high standard in MANET
IEEE 802.11 with some specific modifications to serve VANET needs.
2. 1609.1 this layer takes care of applications and optional recommendations
for the application layer this part of the standard is also known as a resource
manager.
3. 1609.2 this layer takes care of the security of communication as well
securing services and applications during packets exchange.
4. 1609.3 this layer takes care of networking services in VANET
communications and it covers communication stacks.
5. 1609.4 this layer includes multi-channel operations and arrange multiple
channel communication priorities.
Figure 1 Wave Architecture
3
WIRELESS BROADCAST
A wireless broadcasting can be defined as the process of sending data from one
node in the network to all the other nodes in the network. Since VANET are highly
mobile system having a static function to decide if a node should rebroadcast a
packet or not will not lead to real results instead adaptive protocols are suggested
to have better results. After receiving the message, every node should use an
appropriate algorithm to decide whether to favor rebroadcasting the message or
not. Rebroadcasting every received packet will create broadcasting storm problem
[3]. Moreover, a collision between messages may happen. Please note that due to
the difference between MANET and VANET. Using famous MANET networking
protocol such as AODV and OLSR is not efficient in VANET for several reasons
including the way the nodes are distributed in VANET. In VANET distribution of
different nodes is highly variable making the topology of the network change
continuously. The density of Vehicular network also will vary depending on the
area. The number of vehicles in an urban area is expected to be much less than
the number of vehicles on a highway. Even the distribution pattern for a set of
nodes in the network could usually vary for example, in urban areas nodes are
uniformly distributed on the other hand in highways nodes will be divided into the
one-dimensional path. Moreover, In MANET most routing protocols are based on
intensive use of flooding [26] in reactive routing flood is used in most cases for the
source to Figure a route toward the intended destination. Finally, in most MANET
protocols nodes in the network are used to build a routing table that defines road
toward different nodes in VANET, and since nodes are always on the move this is
4
not the case, and one neighbor to a node may become outside that node
transmission radius. A particular broadcast protocol should be able to adapt to
different scenario and function well in various situations. A dedicated short range
is used based on 802.11p IEEE standard that allows a transmission range up to
1000 meter with the radius of 200~250 meter. In VANET broadcasting is typically
used in two type of applications which are safety applications such as accident
avoidance Collective (AAC). In this kind of applications whenever an accident
accuses a message will be generated and disseminated as fast as possible across
the network to inform other vehicles about this accident for the sake of taking an
action regard this. Protocols that support this type of application are commonly
designed with two goals which are having high reliability in the network with
reducing the latency as much as possible. Another type of application use
broadcast protocol in VANET is traffic data dissemination where some delay and
lower reliability are accepted comparing to safety-related applications. On the other
hand, this application requires the data to be disseminated to vast areas so
flooding is a critical problem because it will consume a lot of data especially that
the number of
Nodes in the network could be very high. Broadcast protocol will be either a multi-
hop protocol or a single hop protocol multi-hop protocol Serve safety applications
while single hop is used to help traffic information Dissemination [19] Table 1
compare single hop protocol to multi-hop protocol as well it's general Characteristic
and its advantages and disadvantages.
5
Table 1 Qualitative comparison of broadcast protocols [19]
next section discusses the problem statement to be solved by this work.
Broadcasting
Type
General characteristics Advantages Disadvantages
Single-hop Packets are
disseminated
by ways of
periodic
beacons
No packet
flooding
Reduce
redundancy by
varying period
for broadcast in
every node
Rely on high
mobility to
spread info in
the network
Good for
application
that require
packet
presidency
Can avoid
broadcasting
storm
problem.
Messages are
distribution
through the
network may
be slow
Not suitable
for delay
sensitive
application
May require
large space
Multi-hop Packets are
disseminated
by smart
flooding
Packets can
be
disseminated
quickly
Needs an
algorithm to
avoid
broadcasting
6
PROBLEM STATEMENT
Data dissemination between vehicles is a challenging task in VANET. performing
real life tests for new technologies for VANET is both expensive and may involve
safety issues for that reason to test new contributions for VANET a simulation
tool is used. There are several tools available to implement VANET applications
and communication. Ns3 is considered to be a very great platform to perform
VANET scenarios for several reasons including but not limited to:
Ns3 is fully open source tool with very high scalability to meet researchers’
need.
The tool is fully supported by a strong team of researchers with every new
version to be released every three months that includes new contributions.
Ns3 fully support 802.11p which is IEEE WAVE standard for VANET
systems.
The tool is flexible and can integrate with many third party tools such as
SUMO traffic simulator and NetAnim visualization tool.
The tool supports the latest technologies such as distributed cloud
systems and LTE technology.
The preceding reasons make Ns-3 a great platform to simulate VANETs. A huge
drawback of NS-3 is its lack of support for VANET. No module provides the
simplest broadcasting for VANET, which is the main method vehicles use to
exchange messages between each other in VANET. This makes implementing
7
any VANET on Ns3 hard task due to the lack of broadcast protocol modules in
Ns-3. This work aims at delivering Ns3 implementation for three different
broadcast protocols for VANET. The protocols to be implemented are Distance to
mean protocol (DTM), distribution adaptive distance with channel quality protocol
(DADCQ) and statistical location assisted protocol (SLAB).
CONTRIBUTION
Developing a new module for Ns-3 for DTM broadcast protocol for VANET
for Urban scenario and highway scenario.
Designing a new module for Ns-3 for DADCQ broadcast protocol for
VANET for Urban scenario and highway scenario
Designing a new module for Ns-3 for SLAB broadcast protocol for VANET
for Urban scenario and highway scenario
Survey of different available broadcast protocols and VANET simulation
tools.
ORGANIZATION
The rest of this thesis is organized as follows Chapter 2 covers literature review
of different wireless broadcast protocols including broadcast protocols
requirements, broadcasting evaluation metrics and different classifications of
various broadcast protocols for VANET. Chapter 3 includes an overview of
various network simulators discussing their advantages and disadvantages in
8
addition to giving an overview of traffic simulation tools. Chapter 4 includes Ns3
details. Chapter 5 covers Distance to mean broadcast protocol design and
implementation. Chapter 6 covers DADCQ development and implementation.
Chapter 7 covers SLAB development and implementation. Chapter 8 covers
Evaluation, validation and verification of DTM, DADCQ and SLAB. Chapter 9
concludes this thesis
9
CHAPTER 2 VANET BROADCAST PROTOCOLS SURVEY
INTRODUCTION
In this chapter we survey different broadcast protocols for Vehicular Ad Hoc
Networks (VANET). In VANET, two types of communications are performed
which are Vehicle-to-infrastructure (V2I) communication and Vehicle-to-Vehicle
communication (V2V). V2I communication is used to provide real-time
information on traffic condition, weather, and advertisement services. V2V
communication is used to provide information regarding traffic condition including
accidents safety messages and potential hazard on the road. Dissemination of
security messages is considered one of the most important applications of
Vehicular ad hoc networks. Since safety messages can contain crucial
information that may include information of traffic risk delivering it should be done
smoothly to all the vehicles in the system. To deliver a message to many nodes
in the network, a broadcast protocol is used. But one could argue why not to
rebroadcast any message received by any node in the network as soon as it’s
received and achieve 100% reachability rate. Sending every received message
will lead to “Broadcasting storm problem” which result in high redundant, high
bandwidth consumption rate and collision between sent packets. Even with this
method, a study suggests that sending every message as soon as it is received
10
could only provide 61% coverage [4]. For the preceding reasons several smart
broadcast protocols proposed. There are many classifications of broadcast
protocols some researchers divided broadcast protocols into three classifications
[4],] while others divided broadcast protocols into six different classifications [2].
Also, some others classified broadcast protocols into two different classifications
[5] which are the classification to be used in this literature review since. Before
going with that, the main requirements for having a good broadcast protocol is
discussed in section two of this chapter. Followed by evaluation metrics for
broadcast protocols.
REQUIREMENTS OF BROADCAST PROTOCOL
There are several requirements that a broadcast protocol should have to be
considered a good broadcast protocol. Please note that there may be some
tradeoff between different requirements to achieve different goals [6]. The first
requirement for a good broadcast protocol is the ability to deal with the scalability
of the network. Unlike MANET VANET network could be Dense at one point then
sparse on another point so the protocol should be able to operate correctly under
a different condition. Efficiency is another requirement in broadcast protocols.
Since broadcast protocols are used to distribute safety messages the delay is
critical, so a good broadcast protocol should disseminate safety message without
delay. Another important requirement for a good broadcast protocol is the ability
to deal with different traffic conditions.
11
BROADCAST PROTOCOL EVALUATION METRICS
Giving an assessment of networking protocol is not an easy task due to the
complexity and variety of inputs and conditions for each protocol. However, there
are several metrics that can be used in almost any broadcast protocol. The first
metric to be evaluated is Reachability. Reachability cares for the coverage of the
broadcasting of specific packet. A suggested simple way to measure the
reachability is by having the fraction of nodes in VANET network that received
the message to the total number of nodes in the network as illustrated in
equation 1.
𝑅𝑒𝑎𝑐ℎ𝑎𝑏𝑖𝑙𝑖𝑡𝑦 =𝑁 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑
𝑁 𝑡𝑜𝑡𝑎𝑙 (1)
Where N received is the total number of nodes that received the packet and N
total is the total number of nodes in the network. Another key performance metric
for the broadcast protocol is redundancy, which takes care of calculating the
number of duplicated packets. Another metric that can be used to evaluate a
broadcast protocol is the failure rate. A broadcast protocol should be designed
carefully to deal with the number of nodes in the network. A lot of collisions could
happen since many nodes rebroadcast a packet at the same time. Table 2 gives
a set of important metrics with the function to calculate it for broadcast protocol.
The next section of this chapter will go over different classification of broadcast
protocols in details with giving examples of each type of this classifications as
well its advantages and disadvantages in different scenarios.
12
Table 2 Broadcast protocol metrics
BROADCAST PROTOCOL CLASSIFICATION
In this section, a literature review will cover broadcast protocols mainly broadcast
protocols can be classified into two classifications which are statistical broadcast
protocols and location broadcast protocols. Various researchers suggest different
classifications of broadcast protocols. Some researchers indicate that a broadcast
Metric
Name
Mathematical function to calculate it Description
Forward
node ratio
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑛𝑜𝑑𝑒𝑠 𝑓𝑜𝑟𝑤𝑎𝑟𝑑𝑖𝑛𝑔
𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑛𝑜𝑑𝑒𝑠 𝑖𝑛 𝑡ℎ𝑒 𝑛𝑒𝑡𝑜𝑤𝑘𝑟
This metric takes care of
calculating the proportion
of nodes in the network
that actually
rebroadcasted the packet
Broadcast
overhead
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑢𝑝𝑙𝑖𝑐𝑎𝑡𝑒 𝑝𝑎𝑐𝑘𝑒𝑡 𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑁𝑒𝑖𝑔ℎ𝑏𝑜𝑢𝑟𝑠
This metric take care of
calculating the number of
duplicated packets in
defined area of the
network
Collision
ratio
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑐𝑜𝑙𝑙𝑖𝑠𝑖𝑜𝑛 𝑝𝑎𝑐𝑘𝑒𝑡𝑠
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑒𝑑 𝑝𝑎𝑐𝑘𝑒𝑡𝑠
This metric measure the
rate of collisions between
packets in the network
Redundancy
rate
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑢𝑝𝑙𝑖𝑐𝑎𝑡𝑒 𝑝𝑎𝑐𝑘𝑒𝑡𝑠
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑜𝑢𝑟𝑐𝑒 𝑝𝑎𝑐𝑘𝑒𝑡
This metric takes care of
calculating number of
duplicate packets by one
node
13
protocol should be categorized as statically based protocols and topology based
protocols where a prior knowledge of external variables is present in each node
that’s make the node decide whether or not to rebroadcasts. While topological
based broadcasting relays on the topology changes in the network to decide
whether or not a node should favor rebroadcasting of a packet. Other researchers
suggest that a broadcast protocol could be either flooding protocol or selective
flooding protocol [2]. The next subsections will go over each of The two main
classifications explain it briefly and give one or more examples of it.
2.4.1 STATISTICAL BROADCAST PROTOCOLS
statistical broadcast protocols have a unique feature allowing each node to decide
individually if it should rebroadcast a received packet or not this is done by
comparing a locally calculate value to a threshold value and take a decision based
on the result of the two values. Each vehicle maintains a table that contains a list
of all neighbor vehicles with some information about them. This table gets
periodical updates through beacon messages from the nodes in its transmission
radius. Each node in the network sends periodic beacons known as hello
messages to all the other nodes in its transmission radius. The content of each
hello message varies from one broadcast protocol to another. The nodes will
include the information in the header of its packet as well every other information
needed by the protocol and forward it periodically to the rest of nodes. The
information stored in the table is used later by the node to preform the needed
calculation by the protocol in the direction of determining whether or not a node
14
should rebroadcast a packet. designing a good threshold value is the key to having
an efficient and effective protocol. If the value of the threshold is very aggressive,
the protocol well definitely has low reachability comparing to other protocols. If the
value of the threshold is too conservative, the protocol will suffer from collisions
and overhead. Please note that designing an optimal threshold function is very
hard to be done analytically so normally a high-level simulation is used in order to
create optimal threshold function. Several factors can define threshold value
depending on the design of the protocol this includes and not limited to node
density in the network, channel quality of the network, medium rate of error in the
network, Spatial distribution of nodes in the network, velocity of nodes and the
direction of nodes in the road. Since topology, as mentioned in the introduction,
keep changing continuously in VANET, we can conclude that there is no one
threshold value that can work in every single situation and under any condition.
For that reason, normally during the design phase of the protocol, the designer
determines the goal of this protocol. Whether its utilization of bandwidth or dealing
effectively with high density on this wise. Statistically based broadcast protocol
compare different variables to the threshold value according to different methods.
One of the most popular techniques to do so is called stochastic flooding. In this
method, each and every nod in the network will have a predetermined probability
in order for it to allow retransmission of received packet. This value could be fixed,
and also it could be dynamic. In either case, the node will determine a random
value between 0 and 1 which is normally called P-value and then use this value to
compare it to the threshold value in order to take a design of rebroadcasting or not.
15
Through different experiments and simulations, a good value to be set to achieve
good reachability is a value between 0.6 and 0.8 [16]. The problem with this
method is poor performance under different network configurations. The closer the
value get to one the more the protocol will have flooding in rebroadcasting a
message. Some statistically based broadcast protocol used graph theory in order
to calculate fixed value for P with the help of getting the field size as well the
number of nodes in that field. Some other protocols that use fixed retransmit
probability use different variable other than field size and number of nodes to
determine the value of P such as channel quality. On the other hand, Dynamic
retransmission probability is more flexible and can adjust more to the changes in
the network. making these protocols give better performance in term of bandwidth
consumption as well reachability. Some of the dynamic retransmission protocol
depend heavily on the count of neighbor’s N where P will be counted based on
fixed maximum number of neighbors if the number P=Nmax that means enough
nodes in the network received the message so it won’t broadcast the packet. in
case P<Nmax the value will be compared to a threshold value that is calculated
using threshold function to determine whether or not to rebroadcast a packet.
Some Dynamic Statistical based broadcast protocols use a different key to
calculate P. which is the number of received message in one node this method is
called Message count. This method set the retransmit value to a maximum value.
Whenever a node receives a message, the node will automatically decrease this
value by predefined value by the designer of the protocol. If this number became
equal or less than zero than the node won’t rebroadcast this message. If the
16
number became equal to or more than 0.5, the message would be rebroadcasted
to the neighbors. This method achieves fair reachability, and it reduces the
chances of having a broadcasting storm problem in the network. Another method
that are some Statistical based broadcast protocols use and rely on are based on
the nearest neighbor distance. Here the value of retransmitting is set high as long
as the distance from the node which receives the broadcast packet is high. And is
set to low when the distance is short by using this method a protocol could achieve
high reliability and avoid broadcasting storm problem since when the distance is a
short low number of messages will be exchanged between the nodes which will
avoid the collision and bandwidth consumption. Another method that some
Statistical based broadcast protocol uses to determine to whether or not a node
should favor rebroadcasting is called the counter method. Simply all nodes have
the value P set to zero whenever a node receives a message this value will be
increased by one. Then this value will be compared to the threshold value to make
a decision on broadcasting. An example of Statistical based broadcast protocol is
reception estimation alarm routing [17] (REAR) which make use of the wireless
channel to determine broadcasting or not in a node. Only vehicles in the same
direction of the holder vehicle will forward the message in this protocol. Another
broadcast protocol that uses message counting method in order to determine to
whether or not to rebroadcast is optimistic adaptive probabilistic broadcast [18].
This protocol compares the number of nodes in two hops and uses the density of
the network in order to calculate rebroadcasting probability. The more neighbors
around a vehicle, the larger the calculated value will be set to avoid flooding of the
17
network by sending a message continuously. Another examples of statistically
based broadcast protocols are DTM protocol, DADCQ protocol and SLAB protocol.
2.4.2 TOPOLOGY BROADCAST PROTOCOLS
Topological broadcast protocol is considered another major classification of
broadcast protocols. Topological broadcasting relies heavily on information about
each and every neighbor to the node to make a decision on which node should
favor rebroadcasting. Normally topological based protocols are 2-hop protocols
(require information about the neighbors and also some information about the
neighbors of neighbors). Topological protocols lay under two categories which are
self-pruning and dominant-pruning. In self-pruning protocols node normally
decides on their own whether a node should rebroadcast a received packet or not.
On the other hand, on Dominant pruning nodes select which of their neighbors
should favor rebroadcasting of a packet. An example of topological base broadcast
protocol is density-aware reliable broadcasting in vehicular ad hoc networks [10]
(DECA) this protocol goal is to achieve high reliability in term of received packets
from other nodes in the network with decreasing overhead of the networks as low
as possible without actually affecting reliability. An advantage of this broadcast
protocol that it doesn’t require the vehicles to be equipped with global positioning
system (GPS). Instead of that this protocol uses store and forward techniques in
spite of collecting information of the local density so a node could make a decision
of rebroadcasting a packet or not. When a node receives a packet, a full
information about all the neighbors is sent with hello message. The node uses this
18
information to select a neighbor with the highest density of the set of neighbor so
that neighbor will rebroadcast the message next. This protocol takes advantage of
the fact that vehicles on traffic normally travel in groups, so it selects one node with
the highest density to forward the packet. This broadcast protocol was presented
in 2010 and was simulated using simulation tool Ns2. Another topology based
broadcast protocol is Distribute Vehicular Broadcast [10] (DV-CAST) this protocol
is designed with a goal of dealing with extreme scenarios such as very low traffic
or very heavy traffic for example during rush hours of the day. Yet this protocol is
aimed toward highways only and it have very low performance in urban areas
comparing to other broadcast protocols. Some other topological based protocols
divide the map into small regions and select a specific geographic region to
propagate the message to it. A very famous protocol that relies on this method is
Urban Multihop Broadcast [11] (UMB) this protocol goal is to reduce broadcasting
storm problem as possible with having high reliability comparing to other similar
protocols. Yet this protocol relies on having repeaters at the intersections of urban
areas in order to repeat the packet to other regions. The idea of this protocol is
simple yet efficient. The region is divided into several sections based on the
transmission range for the node. A node will rebroadcast a packet if it’s in the
furthest non-empty section of the region this protocol was developed on 2004 and
tested on MATLAB to measure its performance comparing to pure flooding the
protocol shows significant performance with high reliability. An extended version
of UMB was developed as an enhancement. The newer version is called Ad-hoc
Multi-hop Broadcast [12] (AMB) this protocol drop the need of repeaters at every
19
intersection which was the biggest drawback of UMB. Instead when a vehicle stops
by an intersection it will perform the task of the repeaters and preform new
directional broadcast using ad-hoc algorithms. This broadcast protocol was
proposed on 2006 and was tested using MATLAB in order to compare its
performance to pure flooding as well to its forerunner UMB. Through testing AMB,
protocol shows great performance in term of packet delivery and reliability with
having the big advantage of eliminating repeaters at each intersection in urban
areas. Some other topological protocols take advantage of the fact that vehicles in
real traffic normally travel in a group and make every vehicle in the network belongs
to one or more cluster. This method of dividing the nodes into clusters is widely
used in MANET. Tests prove that developing a broadcast protocol for VANET
despite the fact that VANET topology change continuously unlike MANET topology
gave excellent performance results comparing to simple flooding protocols. Every
cluster will have one node selected to be cluster head which will ensure that the
packet is delivered to all the other nodes in this cluster. Some protocols extend the
concept of having a node to be cluster head even further by selecting more than
one cluster head to ensure higher reliability, but that come with a price which is
increasing bandwidth conception in addition to rising the probability of having a
collision between the packets. An example of such protocol is Selective Reliable
Broadcast Protocol [13] (SRB) this broadcast protocol pick one node to be cluster
head within a specific cluster. The distance between vehicles is calculated and if
its lower than statically defined value then the sender and receiver are considered
belonging to the same cluster. If the defined value is higher than the distance the
20
two nodes are considered belonging to two different clusters the next step and
after defining a few clusters the node will select furthers node inside each group to
be cluster head which will do the rebroadcasting process. This protocol was
proposed in 2012 with the aim of having a mechanism to detect clusters of nodes
automatically. The protocol was simulated using network simulation tool Ns-2 with
having traffic simulated using a simulation of urban mobility tool (SUMO). The
protocol shows significant improvement in term of minimizing broadcasting storm
problem. Another broadcast protocol that uses similar techniques is Cluster-Based
Efficient Broadcast [14] (CBE-B) this broadcast protocol is designed to work on the
highway. The way this protocol is designed doesn’t make it give good performance
in urban areas. This protocol has two main phases the first phase take care of
doing a setup for the network to prepare nodes to receive packets. The second
phase is steady state phase. During the first phase which is setup phase, the nodes
will do a setup by creating two front clusters in addition to creating two rear clusters.
The nodes will exchange hello messages with a special header added to Hello
messages that contain information needed to do the setup and create the clusters.
The information includes the speed the location and the current direction of the
vehicle. After the vehicles are divided into clusters, the steady phase starts to elect
a new cluster head for that cluster. This process is done through four steps. First,
the vehicle that’s farthest from the cluster head will be elected as the next cluster
head. Second the vehicle that has the fastest speed is elected as a cluster head.
Third the slowest vehicle will be elected as a cluster head for the rear cluster. Forth
the vehicle that receives messages fewer than the rest of nodes will be elected as
21
a cluster head. This broadcast protocol was proposed on 2013 and was
implemented on network simulation tool Ns2. Table 3 shows different broadcast
protocol and the simulation tool used to implement it.
Table 3 Implementations of broadcast protocol on simulators [19]
Next chapter covers network simulation tools and traffic simulation tool
Protocol
name
Communication
characteristic
Traffic characteristic Simulator
Name
UMB Location based Arterial road Ns-2
ODAM Highway Ns-2
LDMA Statistical based Highway / Urban Groovenet
BBR Location based Arterial road OPNET
PAB Location based Highway Ns-2
OAPB Statistical based Arterial road Ns-2
22
CHAPTER 3 NETWORK SIMULATION TOOLS AND TRAFFIC SIMULATION
TOOLS FOR VANET
INTRODUCTION
According to the United States Department of transportation in 2013 there was
30,057 fatal motor crashes in which 32,791 lives were lost. With the successful
implementation of VANET, a lot of lives could be saved yet; this technology will
not be effective and save lives unless it's intensely tested, which raises the
question of how to test such technology. Testing VANET technology in real life in
the field could be both costly and dangerous. In fact, one of the hardest
challenges that face VANET is testing it and deploying it in the real world. For
that reason, simulation tools are used to verify different VANET technology
before an attempt to deploy it in the reality. Simulation of VANETS is more
challenging than simulation of Mobile Ad Hoc Network (MANET) due to the high
mobility and dynamic topology of VANET along with road obstacles. To deal with
the movement of nodes in VANET a traffic simulator needs to be integrated with
network simulator. The next section covers VANET simulation challenges.
VANET SIMULATION CHALLENGES
VANETS have special characteristics that makes’ it unique than other ad hoc
networks. For the sake of creating realistic VANET simulation, the tool needs to
23
be able to deal with a huge number of nodes such as 300 or 400 nodes all
moving together and communicating with each other. Having an accurate and a
realistic streets topologies that can manage different densities and restriction on
lanes and speeds is another challenge that faces simulation in VANET. Another
challenge that steps between having a realistic simulation in VANET is obstacles
and different vehicles characteristics. In reality, wireless signals that are sent
from one vehicle to another will face many obstacles before it reaches to its
destination. When the signal pass through different environments such as
buildings the signal could get disrupted. Different vehicles have different
characteristics a simulation have to represent such characteristics to increase
realism. An example of such characteristic is pre-defined paths for specific type
of vehicles such as trucks or busses. Having realistic acceleration and
deceleration also increase the simulation realism after all no vehicle in real life go
from 0 to 60 in fraction of second or vice versa which bring the topic of having
human driving patterns. In VANET simulators vehicles movement should mimic
human driving patterns and how human normally response to jam and obstacles
in the road having idol driving pattern make the simulator unrealistic comparing to
real world. Another factor that should be taken into account is time patterns. In
reality traffic density change during different times of the day. During rush hours
a lot of vehicles occupied small area while at midnight an area may have very
low number of vehicles if none at all. Simulation should emulate this fact in order
to have realistic results. The next section in this chapter covers different mobility
modeling scheme and why it’s important in VANET simulation.
24
MOBILITY MODELING
Different mobility scenarios for vehicles on the road raises the need for mobility
models. Several tools managed to create real world traces to be used in the
network simulation tools. Table 4 shows overview of different mobility models
and its advantages and disadvantages [20] Random node movement in VANET
simulators are one of the early developed mobility models. In this model, all
nodes move randomly with no restriction at all. This model is good to test
different conditions such as having high density in one place and low density in
another yet, sometimes random mobility model fails to reach steady state If all
nodes move in unrealistic way with none stop at all or if all nodes stop for long
period of time. An advance model with more complexity added to it is real world
mobility traces models. Real world mobility model is based on real life traces of
real maps. The position and movement of vehicles in this model emulate real
world movement of vehicles. The advantage of this model is increasing of realism
in the simulation yet this model is limited due to limitation in the scenarios that
could be loaded into the simulator [19]. The final mobility model that could be
used in VANET simulation to simulate mobility of vehicles in the network is the
artificial mobility traces. This type of mobility traces land somewhere between the
two previously discussed models. Unlike random mobility movement this type of
traces has a degree of realism if compared to random traces yet it’s flexible and
changeable unlike real life mobility trace in order to create specific condition that
could serve for simulation purpose.
25
Table 4 overview of mobility models in VANET simulation [20]
In general, there are several characteristics that need to be included in the
mobility model in order to consider it a realistic mobility model [26] these
characteristics are:
defined number of lanes as well their directions. This parameter could
affect the operation of communication protocol in the network by affecting
the connectivity of the network.
Obstacles also is a key factor that affect the mobility model and wireless
communication in VANET.
Mobility
Model Class
Integrated Framework Support Advantages Disadvantag
es
Random
Movement
Virtually All Straightforward,
Readily Available.
Imprecise,
potentially
unstable
Real World
Traces
GlomoSim,
WualNet,Opnet,Omnet++ QualNet ,
Ns-2 ,Ns-3 , JiST/SWANS
Most realistic node
movement,
Reusable traces
Costly and
time
consuming,
no free
parametrizati
on
Artificial
Mobility
Traces
GlomoSim,
WualNet,Opnet,Omnet++ QualNet ,
Ns-2 ,Ns-3 , JiST/SWANS
Realistic node
Movement, Free
Parametrization,
Re-usable Trace
No feedback
on drive
26
Different traffic conditions. Having one static traffic condition doesn’t
reflect real life traffic instead traffic density should vary including having
extreme cases.
Drivers behavior should also vary from one vehicle to another to reflect
driving behavior in reality. In real life, drivers interact with the road and
different static obstacles like the end of road and dynamic obstacles such
as neighboring vehicles accordingly mobility model should reflect similar
behavior.
TRAFFIC SIMULATORS
Normally network simulation tools simulate communication between nodes
but not mobility of the nodes. For that reason, network simulators on their
own can’t be used to evaluate and test Vehicular ad hoc networks. Instead
traffic simulation tools are integrated with network simulators to represent the
movement of nodes. Figure 2 shows the construction of Vehicular ad hoc
network simulation environment.
27
Network simulator part of the environment takes care of evaluating routing
protocols communication. The second part of the environment which is traffic
simulator takes care of traffic and mobility model generation. Having such
environment creates a new challenge which is the ability to integrate traffic
simulator into network simulator. Not all network simulators have the capability
and scalability to integrate external tools. For that reason, there is a limitation on
the number of simulation tools available to use effectively to simulate vehicular
ad hoc networks. Groovesim [21] is one of the first tools created in order to
evaluate performance of VANET based on traffic flow of the network. This tool is
codded using C++ it also creates graphical structure with the help of MATLAB.
This simulator managed to create small VANET networks yet it doesn’t support
enough flexibility to be integrated with any famous network simulation tool. More
advanced tool that could be used for VANET simulation is Cooperative Vehicles
and Infrastructure Systems [5] (CVIS) this is a tool designed specially to increase
road safety by allowing vehicles to vehicle communication as well Vehicle to
infrastructure communicating. This tool has many features to help in simulate
VANET such as the ability to integrate artificial and local maps with the
simulation, yet this tool is limited and can’t be integrated with different network
simulation tools such as Glomosim, Omnet++ and Ns3. A good simulation tool
that could be integrated with different network simulators is VANETMobiSim
which is a JAVA based extension of the CANU mobility simulation environment
(CANUMOBISIM) [22] this tool is very advance and has the capability of
Figure 2 VANET Simulation components
28
capturing vehicular motion in microscopic level that cover all the aspects of
vehicular traffic such as road topology, speed limitation in roads, number of lanes
and traffic signals. Moreover, this tool has different add-ons that increase the
traffic behavior even further such as Over Taking model (MOBIL) [22] which
manage lane changes and vehicle acceleration and deceleration. This tool
architecture consist of two main objects which are as named by the developers
the universe and the Node [23]. The universe takes care of modeling static
objects in the simulation environment while the node takes care of modeling
movable objects in the simulation environment. An advantage for this simulation
tool is its support to wide definitions of road topology for the user to select from.
Having different selection of road topology is a key factor for a successful
simulation. VaneMobiSim [23] supports the following methods to define road
topology for the network:
User defined graph. In this method the user will define any graph manually
by creating vertices and their interconnection edges in order to create a
road topology later.
Geographic Data Files (GDF) simply user could import GDF map into the
simulator this method is good because it reflects real street maps yet it
has a drawback of having to pay for every GDF file in order to use it in the
simulation.
Tiger Maps, in this method user could use a map extracted directly from
TIGER Database [23]. TIGER maps emulate real life GPS map yet it lacks
29
deep details such the one GDF maps provide to users. On the other hand,
TIGER maps are free to use.
Clustered Voronoi Graph is another method to create road topology for
VanetMobSim. In this method a random road topology is created based on
a set of non-formally distributed points. The road is created by connecting
this points later. Figure 3 shows example of the maps that VanetMobiSim
generates
After creating the road topology and give it the necessary properties. File that
represent this environment can be extracted from VanetMobiSim to
be used by network simulation tools that support integration of external files and
applications. Such as Ns-2 , Ns-3 , GloMoSim and QualNet. Another advance
Traffic simulator that could be used in order to create traffic simulation is SUMO
(Simulation of Urban Mobility). Which is an open source traffic simulation
package. SUMO is codded using C++ and it contains GUI which makes using it
easy for novice users. First open source version was released to the public in
2002. The flexibility and set of options that SUMO provides to the user is huge.
This include controlling properties of the road such as having multi lane streets,
Figure 3 Road Topology Examples
30
giving respect to specific traffic rules such as right of way and stop signs. Please
note that SUMO is not a single application but rather Sumo is a suite of
application that help preforming simulation of traffic. In SUMO users could take
one of two approaches in order to generate road traffic networks. The first
approach is by using an application that SUMO provide called NetGen. The
second approach is using a tool called NetConvert which can be used to read
common maps formats such as TIGER maps and Open Street Map (OSM) then
convert it to a map that SUMO can parse. NetConvert is very strong tool that can
also read less known maps formats such as RoboCup networks and OpenDrive
Maps. SUMO is a microscopic traffic simulator which mean that each and every
vehicle in SUMO is defined individually with specific properties such as name
color speed and driving behavior. SUMO also has a feature called realistic
randomization trips which allow user after defining road topology and creating
vehicles to give this vehicles random trips so it could move randomly around the
loaded road topology. One of the most popular SUMO suits application is V2X
which allow sumo to extract traffic files into an extension that network simulators
such as Ns3 and Omnet++ can understand. Another advantage that SUMO has
over other traffic simulators is its support to very large Table 5 compare different
traffic simulation tools. [25]
31
Table 5 Traffic Simulators Compare
traffic networks with huge number of nodes that can get up to 5000 vehicles.
Please note that even though SUMO can support this number of nodes not all
network simulators does support such numbers.
NETWORK SIMULATORS
This section will go in details over different network simulators. There are many
network simulators with different features yet not every network simulator could
be used to simulate VANET scenarios due to the special features that VANET
has. Network simulators generally are divided into commercial simulators and
open source simulators. The first has the feature of having great support by the
Feature VANETMOBISIM MOVE SUMO CityMob
Portability Yes Yes Yes Yes
Examples Yes Yes Yes No
Microscopic traffic
model
Yes Yes Yes Yes
Import of other
formats
No Yes Yes No
User Defined Maps No Yes Yes No
Ease of setup Easy Easy Moderate Moderate
Integration with
Ns2
Yes No Yes No
Integration with
Omnet++
Yes No Yes Yes
32
product provider as well good documentation for the simulator while the later has
an advantage of flexibility yet, it normally lacks good documentation as well
continues updates. An example of commercial simulators is OPNET and
QUALNET. An example of open source simulators that could be used with
VANET is Ns2, OMNET++, JIST/SWANS and NS3. The next subsection will go
over OPNET in details.
3.5.1 OPNET
Optimized Network Engineering Tool (OPNET) is one of the famous simulators
for research purpose. its flexible and could be used to study communication
between networks as well different protocols and network application
communication. An advantage for OPNET is its easy and simple graphical user
interface that users could use to build networks topology and conFigure it. Three
main functions OPNET provide to users which are modeling network simulating
network and analysis of network components. Support of 802.11p protocol
started in OPNET 16.0 allowing users to simulate VANET scenario with the help
of traffic simulators SUMO to generate traces. OPNET support both C and C++
in order to create detailed network scenario in it. Figure 4 shows VANET
33
simulation in OPNET graphical user interface an implementation of VANET on
OPNET was made in [30].
Figure 4 OPNET GUI
3.5.2 QUALNET
Quality Networking (QUALNET) is another commercial network simulator that
could be used to simulate VANET network. The biggest advantage this simulator
has over all other simulators is its high network scalability that could cover cities
or even countries according to QUALNET documentation this tool can easy
support up to 10,0000 nodes in a single network. This simulator can execute any
type of network implementations 5 to 10 times faster than other simulation tools
[31]. Like most commercial simulation tools QUALNET comes with easy to use
graphical user interface. When it comes to simulating VANET with QUALNET
integrated simulator MOVE is needed in order to extract mobility model to be
used for the vehicles in QUALNET. Like most commercial simulation tool
QUALNET is not an open source simulator so it doesn’t support complex
34
Figure 5 QUALNET GUI [31]
scenarios with deep details for VANET which make this tool bad choice to
implement new complex protocols for VANET for example. On the other hand,
this tool is good to implement simple protocols for VANET and flooding
communication between nodes in vehicular ad hoc network. Figure 5 shows an
example of VANET scenario on QUALNET as well QUALNET GUI [31].
3.5.3 OMNET++
Objective Modular Network Testbed in C++ (OMNET++) is another well-known
network simulator. OMNET++ is considered a discrete even simulation
environment which mean all events in the simulator to be trigger during a specific
35
period of the simulation life time. OMNET++ is open source simulator with very
flexible architecture so there are a lot of contribution for this environment that
capture the latest technologies such as VANET which make this tool a good tool
to simulate complex VANET scenarios. OMNET++ support deep details that
comes handy when user try to implement new technology related to VANET such
as taking control of different layers of the network as well giving properties to
different nodes in the network. For VANET implementation OMNET++ integrate
simulation of urban mobility (SUMO) in order to take care of mobility models for
the vehicles in the network. OMNET++ is a combination of a set of models that
user integrate in the implementation to achieve the simulation goal some
important models are available in OMNET++ that give it advantage over other
simulation tools such as 802.11p which is necessary to implement vehicular
network. This set of models are stored in Network Description (NED) files which
is to be called by the user when needed. OMNET++ provides a GUI for the user
based on Eclipse to implement the simulation. Another advantage that
OMNET++ has is its availability on MAC OS, Windows OS, and Linux. Figure 6
shows the architecture of OMNET++ where SIM is the main simulation kernel
class library which is linked to all the other libraries that
combined create OMNET++. And ENVIR is a library that contain all codes that
are common to the user interface. CMDENV and TKENV are the main
components for user interface.
36
Another advantage that OMNET++ has is parallel distributed simulation. Allowing
large models to be partitioned into several logical processes to be simulated
independently on several processors in order to simulate complex scenarios.
This flexibility allows users to extend the network which comes very handy when
user try to simulate VANET. Another advantage that OMNET++ has is its
portability which mean the simulator doesn’t need complex installation instead all
the packages could be moved from one machine to another without troubles.
Figure 7 shows the interface of OMNET++ which look very similar to eclipse IDE.
Figure 6 OMNET++ Architecture
37
INTEGRATED VANET SIMULATION TOOLS
Integrated VANET simulator are simulator that are created specifically to serve
vehicular ad hoc network with having traffic simulation support integrated in it.
These simulators are good for simple simulation of VANET since it supports all
the required components of building vehicular network yet, normally such tools
lack flexibility and extension. Moreover, most of such tools are commercial tools
and not open source tools which make it not the best target to be used for
researching purpose. Due to its limitation new complex protocols can’t be tested
with these tools. An example of such tools is Traffic and Network Simulation
Environment [27] (TRANS). Trans is a tool built based on SUMO open source
traffic simulator and Ns-2 open source Network Simulator. An advantage that
TRANS has over other integrated simulators is that it’s actually open source tool
unlike most other integrated simulators. TRANS main goal is to try to achieve
Figure 7 OMNET++ GUI
38
simulation results as close to the real world as possible by having predefined
environments of network. TRANS architecture contain two main models of
Operation each of these models address specific need in the simulation
Environment. The first model is called network-centric this part of the simulation
environment takes care of the communication aspect of the network with respect
to mobility models. The second mode is called application-centric which is used
to evaluate different applications for VANET. Figure 8 [27] shows how these
models work in TRANS architecture.
Another integrated simulator is that integrate both traffic simulators and network
simulators together in one tool is Mobility Model Generator for Vehicular
Networks (MOVE) [28] which is a java based application that is built based on
SUMO traffic simulator. MOVE has a huge advantage which is having simple
graphical user interface as showsn in Figure 9. Move also support custom maps
generated by the user in order to use it in the simulation yet it lack support for
good random topology generation. MOVE does generate random topology but in
Figure 8 Trans architecture
39
that topology the vehicles are only restricted to move in the grid which is a huge
drawback.
From network simulator point of view MOVE support Ns-2 and Qualnet
simulators and please note that MOVE inherit the entire network simulator
environment without providing any ease of use interface for the network side
unlike traffic side. Figure 10 [28] shows the architecture of Move and how
different components of MOVE interact with each other.
Figure 9 MOVE GUI
40
Another big disadvantage in MOVE is the lack of support for big numbers of
nodes in the network which is going to be obstacle when coming to simulating
highway scenarios as well there is no support for multiple radio interference
which is required in largest networks. On the other hand, move takes micro
mobility into consideration allowing the user to define vehicles movements’
patterns for each and every vehicle individually with high rate of flexibility which
increase the realism in the simulation as mentioned in previous chapter. The final
integrated simulator that this section will go over before going over network
simulators is Cellular automaton based vehicular network (CAVENET). This
simulator is a lightweight integrated simulator that includes some simple mobility
models for vehicular traffic in order to help building simulation of VANET. This
tool isn’t open source which lead to have limited ability when it comes to
simulating different scenarios. CAVENET is based on MATLAB with having
Figure 10 MOVE Architecture
41
mobility modules side simulated using MATLAB and network simulation side
simulated using NS2. Figure 11 shows the architecture of CAVENET.
Figure 11 CAVENET architecture [29]
This section covered some integrated simulators that could be used to
simulate VANET scenarios. Through this overview it was clear that these
integrated simulators that combine both Network Simulators and Traffic
simulators are meant to simulate simple scenarios and are not efficient
when it comes to simulating complex protocols for VANET. Table 6 [26]
shows different integrated simulators.
42
Table 6 comparison different integrated simulators [26]
CONCLUSION
This chapter covered different challenges that face simulation of vehicular ad hoc
network. The first step to achieve a good simulation is to have a good road
topology and mobility model. Mobility models are discussed in this chapter. Three
main mobility models are discussed which are random movement of vehicles,
Real world traces and artificial movement traces. An example of different traffic
simulators is also discussed with their advantages and disadvantages and how
different simulators traffic deal with different road. Different integrated simulator
was given such as MOVE and TRANS also this chapter covers why these
simulators are good for implementing simple vehicular ad hoc network but it
won’t serve the user efficiently when it comes to simulating complex scenarios.
The next chapter of this thesis covers NS3 network simulator which is the tool
used to implement the protocols
Simulator GrooveNet Swans++ TranNS CAVENET NCTUns
Language C C SUMO MATLAB Java
Modular Yes Yes Yes Yes Yes
Mobility Simulator
GrooveNet JiST/SWANS Sumo MATLAB Integrated
Network simulator
Supports multiple models
SWANS Ns2 Ns2 Integrated
Mobility model
Many Many Limited Many Limited
43
CHAPTER 4 NETWOR SIMULATOR NS-3
NS3 is one of the most famous open source network simulators available to
simulate VANET. Ns3 is mostly used for research purpose and is extension of its
predecessor Ns2. Before going over NS3 an overview is given of Ns2 and please
note that Ns3 is not just a newer version of Ns2. It’s a whole new simulator
written from scratch. Which means any implementations for Ns2 are not
backward compatible with Ns3. Ns2 was first developed as an open source
network simulator in 1989 due to its flexibility and extendibility a lot of
researchers start to use it to implement new technologies. Just like OMNET++
Ns2 is portable simulator which mean it can be moved from one machine to
another and work on different machines without complex installation. On the
other hand, a drawback for NS2 is that Ns2 doesn’t support all Operating
systems. Network Simulators NS is considered an even-driven simulator which
mean the user will define set of events that will be triggered one after another
when the simulator run. The biggest obstacle that faces Ns2 users is the lack of
clear guidelines for beginner to understand the architecture of Ns2 in depth. Ns2
is consists of a set of modules that works together in order to implement
simulation scenario. The number of official modules given by Ns2 are limited and
can’t be extended to the degree needed by new technologies. Moreover, creating
new modules for Ns-2 require deep knowledge of queuing theory and modeling
44
techniques which is intense task. For that reasons, a new version was developed
and released to the public in June 2008. Table 7 shows the different between the
two simulators in different areas. Since Ns3 is built from scratch the architecture
of Ns3 is totally different than the one in Ns2 Figure 12 [33] shows the
architecture of Ns3. Ns3 network layer contain all the creation and modification of
the main devices for the network this include several classes such as node class,
net device class and packet/socket class. On the other hand, core layer is where
all the control of events happens. In that layer the simulator creates and schedule
events for the simulator to be triggered later. Just like OMNET++ Ns3 the source
code is all organized inside the src directory this directory contains all the
modules that could be needed in order to implement specific simulation scenario.
In fact, Ns3 can be considered as a set of libraries that can be combined together
to work with each other in order to preform specific simulation with the help of
some external libraries that user creates.
45
Table 7 comparing Ns2 and Ns3
Area of
compression
Ns2 Ns3
Programming
Languages
Ns2 is originally implemented using
combination of TCL scripts and C++ which
infect introduced overhead because of TCL
scripts when simulation large networks
Ns3 is implemented
using C++ new modules
to be integrated with
Ns3 could be written
whether in C++ or
Python with good
performance no matter
how big the network is.
Memory
Management
Ns2 use basic C++ Memory management
functions.
Automatic deallocation
of objects is supported
with the use of reference
counting.
Performance The total computation time required to run a
simulation is 3 to 5 times longer in Ns2
compared to Ns3 due to the overhead of
interfering oTcl with C++.
Ns3 performance better
in terms of memory
management as well
Ns3 prevent unneeded
parameters from being
stored in the memory of
the simulation.
Simulation Output Ns2 has a packet called NAM that can
implement the simulation visually
NS3 doesn’t have any
visual package with it
but simulation
46
Figure 12 Ns3 Architecture
An example of these models is LTE model, WAVE model which includes
(802.11p) the standard for vehicular networks. These models could be edited by
the user to achieve specific need. Please note that Ns3 is built on these models
so they are highly dependent on each other making changes to the core models
may lead for Ns3 to break or not to work as expected. With more than 91 model
written by researchers, Ns3 became the number one network simulator to be
built by the help of research community. There are several important modules
already built in Ns3 that help in a lot of researches related to different areas in
systems networks. Ns3 simulation tool supports both Ip and none-Ip based
networks most of the researchers lay under the first type but Ns3 still support the
second. Figure 13 shows different models that Ns3 support. Every three months
a new version is released that include reviewed community contribution in it. In
47
fact, Ns3 provide a command That helps users in creating new model by just
naming the model.
Ns3 will take care of creating the skeleton for the model and include all the files
needed to implement it. Unlike many other simulators Ns3 takes care of deep
details such as defining net devices of the network, giving net devices specific
features and properties such as Ip address. Such features in addition to allowing
users to define each and every part of the network in details increase the realism
of the simulation. On the other hand, it also increases the complexity of dealing
with Ns3. According to some survey [26] that discussed current status of network
simulators Ns3 is picked as the hardest simulator in terms of use between all the
other simulators. Since simulation relies a lot on random, one study found that
most simulators consume around 35% ~ to 50% of CPU power only on
generating random numbers to be used as inputs for the simulation [26]. For that
Figure 13 Ns3 Models
48
reason Ns3 created a new class called NS3::RANDOMVARIABLE that takes
care of generating smart random variables with avoiding replication. These
numbers could be used with the simulation without actually consuming huge
amount of CPU power. To simulate Vehicular network in Ns3 mobility models are
needed. Ns3 can work together with SUMO in order to integrate vehicle
movement into the simulation as a trace file. Also MOVE files could be integrated
with Ns3 using middleware package called ns::mobilityhelper to include it in the
simulation. Table 8 compares different network simulators.
Table 8 comparing different network simulators
The next chapter covers Implementation of Distance to Mean protocol.
Ns2 Ns3 GlomoSim Omnet++ Qualn
et
802.11p Support Yes Yes No Yes No
Probability YES YES YES YES YES
Open source Yes Yes Yes Yes No
GUI No Yes Yes Yes Yes
Parallel processing NO YES NO YES NO
Ease of use Hard Moderate Easy Moderate Easy
Examples Yes Yes Yes Yes Yes
Scalability Poor Very high Poor Very high high
Programming
language
C++ C++/python C C++ C++
49
CHAPTER 5 IMPLEMENTATION OF DISTANCE TO MEAN PROTOCOL ON
NS3
INTRODUCTION
In this chapter an overview of Distance to Mean adaptive broadcast protocol is
given in details in addition to the steps used in Ns3 to implement it.
PROTOCOL DETAILS
Distance to mean broadcast protocol is designed to serve safety application and
deliver the messages with high reachability and better performance than pure
flooding of the network. This protocol relay on several factors in order to calculate
threshold function for the protocol to determine whether a node should favor
rebroadcasting of a packet or not. An advantage of this protocol is its adaptability
to the number of neighbors in specific area. If the number of neighbors is large this
mean most of the nodes probably received the packet. Another factor that is used
in this protocol rely on the distance to mean variable between neighbors. Distance
to mean can be defined as the distance from a single node to the spatial mean of
the nodes from which it received a packet. Distance to mean protocol can easily
estimate the covered area by set of nodes based on the distance between the
node and the spatial distribution of the other set of nodes in the network.
Calculating the distance to mean variable for a set of point is not a hard task. This
50
can be done simply using few steps. The first step is to calculate the spatial
distribution for the set of nodes this can be done easily using equation 2
(𝑥, 𝑦) = (1
𝑛∑ 𝑥𝑖𝑛
𝑖=1 ,1
𝑛 ∑ 𝑦𝑖𝑛
𝑖=1 ) (2)
if the distance to mean value is small this mean this probably mean that the node
received the message from nearby neighbor assuming that the transmission
radius for all nodes are 250~ meter. Regularly the distance to mean value will be
large when nodes of the network are clustered away from the node that received
the packet. Every node should include its own location with hello message
beaconing in order for the receiving node to be able to calculate distance to
mean of the nodes. The next step is to calculate the actual distance between the
node and the spatial distribution in order to determine Value of 𝑀 which can be
calculated simply using equation (3):
𝑀 =1
𝑟 √(𝑥 − 𝑥)2 + (𝑦 − �̅�)2 (3)
Where r is the transmission radius for the node. Note that if the value of M is small
this probably mean that all the neighbors in this case its preferred not to
rebroadcast because most nodes probably already received this message. Finally,
the node will compare the value of M with the threshold function Value Mc to
determine whether a node should rebroadcast a packet or not. The design of Mc
function was done automatically using automotive version of MTAB in the original
paper that described this protocol [34]. Threshold value Mc can be calculated using
equation (4):
51
𝑓(𝑁) = 0.87 − 0.8𝑒−0.12𝑁 (4)
Where N is the number of neighbors for this node. So to conclude these are the
steps that distance to mean protocol take to determine whether or not a packet
should be rebroadcasted:
Nodes exchange hello messages that include the ID of the node and their
location
When a message is received the node will calculate the value distance
between itself and the spatial distribution of its neighbors.
The node will compare the value of Mc to M if M>Mc the node will
rebroadcast the message. Else the node will drop the message.
Figure 14 DTM General Activity Diagram
52
The next section of this chapter will go over the implementation of this protocol
on simulation tool Ns3.
IMPLEMENTATION DETAILS
As mentioned in previous chapters to implement a vehicular ad hoc network
simulation traffic simulator is needed alongside network simulator. SUMO was
used in order to generate trace files to be used to simulate vehicular movements.
Version 0.24 was used to generate these files. Two scenarios were implemented
the first was an urban scenario and the second was a highway scenario. To
implement each scenario, the following steps were taken. First a definition of the
nodes file took place using XML language which is the language used in SUMO
in order to define properties of traffic network. This file defined the properties of
the nodes in the network such as the node location when the simulation starts
the id of the node etc. the next step was to define the actual road network this
also was done using XML language a special file was created that define the
number of lanes and the maximum speed for the lines and all the properties of
the lanes of the road network. To simulate urban scenario Manhattan grid like
road topology was created. The topology looked similar to the one in Figure 15.
53
Next step was to create third XML file that took care of defining the trips the
vehicles take on this road map by defining a starting point for the vehicles and
destination. Please note that this step is necessary in SUMO in order to create
traffic simulator but when this trace exported to Ns3 a randomization function
was used in order to make all vehicles move randomly in every run of the
simulation. After creating all these file, a middleware tool called TraceExpertor
that SUMO provide was used in order to create one trace file which Ns3 can read
using Ns3 mobility helper class. Figure 16 illustrate these steps.
nod.xml file
topolgy.xml file
flow.xml file
TraceExporter
final result is a .tcl file
that Ns3 can read
Figure 16 Extracting trace file from SUMO to Ns3
Figure 15 Urban road topology used to simulate DTM
54
Next an entire new model was created in Ns3 and called DTM. The official files
skeleton of Ns3 models were used with two main files the first takes care of the
actual simulation of the protocol and the second which is called DTMPacket
takes care of defining the packet headers that are used in hello messages for this
protocol. A main class was created which is called DTMProtocol with functions
inside this class that define the steps of the simulation. Since Ns3 is district even
simulator during the implementation the function NS_log was very handy to keep
track of the current event. This function is a function Ns3 provides that keep a log
of every event happens during the life time of the simulation and either print it on
the command line or keep it in external text file. The reset of this chapter will go
over the steps preformed in each function with a pseudo code of it. As mentioned
earlier in this thesis Ns3 is very detailed simulator that care for the smallest
details of the network. Clearly the first step was to create vehicles that define the
network and give them some properties this step was done in the function
CreateNodes() the following is the pseudocode for this function:
CreateNodes()
Create nodes (number of defined nodes in the simulation)
Create an object for the trace file .tcl called ns
Install ns on all the nodes
That function took care of creating the nodes (vehicles) and installed the trace file
which was exported from sumo on all the nodes so now each node is expected to
move according to the scenario created earlier in SUMO traffic simulator. The
55
next step is to create a net device and install it on each and every node this net
device will have the following properties:
having a transmission radius of 250~ meter.
Use WIFI 802.11p standard for the vehicles to communicate wirelessly
with each other.
A function called CreateDevice() take care of this task the following is the
pseudocode for this function:
CreateDevice()
Create wifiphy layer
Set transmission radius to 250~ meter
Create default wifichannel
Set datalink type
Set MacHelper
Set wifi using wifi802.11P Helper
Set Remotestation Manager
Install all of the above on the devices install()
Test the netdevice using Ns_Log
So now we have nodes that will move in the road topology with net devices
installed in each node according to our requirements. The next step is to tell the
56
simulator how nodes should communicate with each other please note that the
function createDevice() make a call to another function which is
InternetStackHelper() . in order to give the devices ipv4 with the set base of
(10.1.1.0 , 255.255.255.0). the next step is to give the simulation duration this
duration is actually the life time of the simulator in this implementation hello
messages are set to be sent periodically every 15 seconds but this can be
changed easily. The next step is to allow all the nodes to listen to the broadcast
message this is very important because it will tell the simulator that a
broadcasting message is expected from the nodes around.
For n = n , n<number of nodes , n+1
Allow broadcast for node number(n)
Connect node number (n) with the remote
Now the nodes are all set in the simulator they will listen to broadcast messages
and move around the defined network topology. A function call will take place in
0.00001 of the simulation life time that will trigger it at second 1 every node in the
network will send a hello message using the function GenerateHello(). And this
will continue every 15 seconds of the simulator life time. Figure 17 is an activity
diagram that explain the previous functions flow.
57
The next step in the simulation is to let vehicles exchange hello messages. Yet
Ns3 doesn’t has any function that do this automatically so hello messages have
to be designed manually with a specific header according to the user needs.
Since this require serialization and deserialization of data this is done in separate
file called DTMPacket. The following is the pseudocode for the function
createHello()
GenerateHello()
Create new packet
Store X position on the packet
Store Y position on the packet
Figure 17 Activity Diagram for setting the environment
58
Store current speed on the packet
Store the type of message on the packet
Verify all headers before calling send function
Store info in Ns log function
Schedule simulator send function to be triggered on the time
After the message is sent and as mentioned before any node in the transmission
area will listen to this message if that happen a function called ReceivePacket()
will be triggered automatically by the simulator. This function deal with both hello
messages and warning messages. According to the header that define the type
of message
Figure 18 ReceivingPacket() Activity Diagram
59
The following is the pseudocode for ReceivePakcet() function:
ReceivePacket()
Open header for received packet
If the packet is hello message extract the sender info
Store the info in the receiver neighbor table
Update number of neighbors
If the packet is a warning message
Check if the message sent before if yes drop the message if not
Start Back Off timer if a message received reset the timer
If no message received
Calculate Distance to mean value
Calculate Mc Value
Rebroadcast if M>Mc
Keep log of every event in Ns Log
When the node receives a packet the first step the nodes will do is extracting the
header of the message in order to know what type of message the node just
received the node will act according to the type of message if the message is a
hello message the node will extract the location of the sender and the ID of the
60
sender and update its neighbors table. Figure 19 shows activity diagram of how
node treat received hello message.
When the node receives warning message the node will first check if this message
already received or not during this interval. This checking is done via comparing
the message sequence identifier. If the message has been received during this
interval the node will automatically drop it without rebroadcasting it and Ns_log will
be updated with this action. If the message hasn’t been rebroadcasted a few
function will be triggered such as CalculateSpacialDistributin() which will take care
of calculating the spatial distribution for the set of neighbors for this node after
calculating the spatial distribution it will trigger Ns_log function. Another two
function will be triggered which are CalculateM() value and calculatethreshold().
The first one will calculate the value of M based on the DTM value as explained
earlier in this chapter. And calculate threshold function will calculate the threshold
value based on the number of neighbors for that node. After having all the values
Figure 19 Receiving hello message
61
needed the protocol will compare threshold value to Distance to mean DTM value
if M>Mc the protocol will rebroadcast the message if not the message will be
dropped and the Ns_log will be updated in either case. Figure 20 shows this
process in activity diagram.
Figure 20 Activity Diagram for receiving a warning message
62
The following is the pseudocode for the function CalculateSpatialDistribution()
and CalculateDTMValue()
CalculateSpatialDistribution()
Check which nodes are neighbors for the node calling the function
Calculate spatial Distribution for neighbors using equation (1)
Store the spatial Distribution value
Trigger Ns_log to keep log of the simulation.
CalculateDTMValue()
Get the Value calculated in CalculateSpatialDistribution()
Get the distance between current node and spatialDistribution() using equation
(2)
Trigger Ns_log to keep track of the events.
CalculateThresholdValueMc()
Get the number of neighbors for the node that called this function
Calculate value Mc using equation 3
Trigger Ns_log to keep track of the events.
Finally, the node will do compression between M value and MC value and
rebroadcast the message if M>Mc a few notes on the simulation is all nodes will
63
exchange hello messages for two intervals before the first warning message is
generated. The hello messages will be generated every 15 seconds. The node
that will generate the first warning message in the simulation life time will be
selected randomly in every run. All nodes will have random movement and
random speeds and random destination in each run to increase realism of the
simulation. The next section of this chapter will go over a conclusion of the
implementation of DTM protocol on Ns3.
CONCLUSION
This chapter covers Distance to mean (DTM) broadcast protocol for vehicular ad
hoc. An explanation of how Ns3 is integrated with SUMO in order to perform this
simulation is covered as well. The main functions that construct this protocol
were described with UML activity diagrams to describe the flow of the functions.
The next chapter of this thesis will go over the implementation of DADCQ
broadcast protocol
64
CHAPTER 6 IMPLEMENTATION OF DISTRIBUTION-ADAPTIVE DISTANCE
WITH CHANNEL QUALITY (DADCQ) PROTOC
INTRODUCTION
In this chapter implementation of Distribution-Adaptive Distance with Channel
Quality (DADCQ) protocol on Ns3 is covered.
DADCQ PROTOCOL DETAILS
DADCQ protocol is more advanced than DTM protocol since its threshold
function contains more variables than DTM protocol. This protocol threshold
function is dynamic and rely on three main parts which are number of neighbors
for a node which can be calculated easily using hello messages, the quadrat
value for the set of neighbors and finally the channel quality for the network. First
of all, like most broadcast protocol this protocol requires all nodes in the network
to exchange period hello messages in order to exchange information and gain
knowledge about neighbors for the node. After receiving the packet, the node is
required to calculate to values which are M and Mc then and after the back off
timer expires the node will decide whether or not a node should favor
rebroadcasting of received message. Just like DTM broadcast protocol the node
will get distance to mean value for its neighbors this is done simply by calculating
the spatial distribution for the neighbors using equation 5
65
(𝑥, 𝑦) = (1
𝑛∑ 𝑥𝑖𝑛
𝑖=1 ,1
𝑛 ∑ 𝑦𝑖𝑛
𝑖=1 ) (5)
After getting the spatial distribution the distance between the node and the
spatial distribution will be calculated in order to get the distance to mean value M.
after getting the distance to mean value this value will be compared to Mc value
this value is calculated based on three inputs which are Alpha, Beta and Dmax to
get these numbers the number of neighbors for the nod, the channel quality and
the quadrat value /////////To calculate Alpha value can be calculated based on
equation 6 where N is the number of neighbors for the node.
𝛼 = −0.200(2(𝑄−1)
0.125𝑁+ 1)−1 (6)
The value of Beta can be found using equation 7 where Q is the Quadrat value
and K is the channel Quality and finally N is the number of neighbors for this
node.
𝛽 = 6.25𝑒−0.1 𝐾 (2(𝑄−1)
0.125𝑁+ 1)−1 (7)
Finally, to get the Value of Dmax equation 8 could be used.
𝐷𝑚𝑎𝑥 = 0.75 − 0.237𝑒−0.1𝑘 (8)
Finally, Beta, Alpha and Dmax are used as input to the threshold function Mc. the
threshold function can be calculated easily using the equation 9.
66
𝑀𝑐 = 𝐷𝑚𝑎𝑥 − 𝛽𝑒𝛼𝑁 (9)
After having the Value Mc, it will be compared to the value M to decide whether
or not a node should favor rebroadcasting of a packet. Figure 21 shows the
activity diagram for DADCQ. This protocol is designed to have good reachability
and to reduce the number of rebroadcasted packets per node in the network.
Please note that this protocol need to calculate the values beta alpha and Dmax
first before being able to calculate the threshold function to make a decision or
rebroadcasting the next section of this chapter will go over the implementation of
this protocol on Ns3 as well a brief explanation of the design of the road topology
used to be integrated with Ns3 since it was explained in details in the previous
chapter.
67
IMPLEMENTATION DETAILS
Just like DTM protocol to implement this protocol both Ns3 and SUMO need to
work together to make the implementation of this protocol possible. As explained
in previous chapter SUMO will take care of generating road topology to be used
in the simulation by creating trace file that Ns3 can read Version 0.24 of SUMO
was used to generate these files. Two scenarios were implemented the first was
an urban scenario base on Manhattan city grid as in Figure 22 and the second
was a highway scenario as in Figure 23.
Figure 21 DADCQ protocol activity Diagram
68
Figure 23 Highway road topology used to simulate DADCQ
After creating the required road topology and give the nodes all the required
properties the file created in SUMO will be integrated with Ns3 using middleware
toll TraceExporter in order for Ns3 to read this file as suggested in Figure 24.
Figure 22 Urban road topology used to simulate DADCQ
69
On Ns3 side a new model called DADCQ was created following the official Ns3
skeleton suggested by Ns3 developers. Two main files created which are
DADCQ file that takes care of the actual steps to simulate the protocol. The
second file is called DADCQpacket which take care of creating the packets that
DADCQ use with the required defined headers that’s include the node ID the
sequence of the message and finally the location for the sender. A Main class
that’s called DADCQ was created that includes all the main functions needed in
order to make DADCQ preform to its requirements. A function called
CalculateAlpha() is designed in order to get the value of alpha based on equation
4. Another function called CalculateBeta() is also designed to get the value of
Beta according to equation 5 and another function is called calculateDmax() is
designed to get the value of Dmax based of equation 6. finally a special function
called calculateMc() is designed to calculate the threshold value based on
equation 7 for the node in order to compare it later with M value which is the
distance to mean value. Finally based on either M or Mc is larger the node will
Figure 24 Generating trace file for Ns3 using SUMO
70
decide whether or not it should rebroadcast received packet. Just as in distance
to mean protocol during the implementation the function NS_log was very handy
to keep track of the current event. Figure 25 shows UML activity diagram of how
DADCQ protocol function.
The reset of this chapter will go over the steps preformed in each function with a
pseudo code of it. As mentioned earlier in this thesis Ns3 is very detailed
Figure 25 DADCQ activity Diagram
71
simulator that care for the smallest details of the network. Clearly the first step
was to create vehicles that define the network and give them some properties
this step was done in the function createNodes() which look very similar to the
one defined for DTM protocol. This is the pseudocode for CreateNodes()
function:
CreateNodes()
Create nodes (number of defined nodes in the simulation)
Create an object for the trace file .tcl called ns
Install ns on all the nodes
That function took care of creating the nodes (vehicles) and installed the trace file
which was exported from sumo on all the nodes so now each node is expected to
move according to the scenario created earlier in SUMO traffic simulator. The
next step is to create a net device and install it on each and every node this net
device will have the following properties:
Having a transmission radius of 250~ meter.
Use WIFI 802.11p standard for the vehicles to communicate wirelessly
with each other.
The pseudocode for CreateDevice() function is shown below
CreateDevice()
Create wifiphy layer
72
Set transmission radius to 250~ meter
Create default wifichannel
Set datalink type
Set MacHelper
Set wifi using wifi802.11P Helper
Set Remotestation Manager
Install all of the above on the devices install()
Test the netdevice using Ns_Log
So now we have nodes that will move in the road topology with net devices
installed on each node according to the define requirements. The next step is to
tell the simulator how nodes should communicate with each other. createDevice()
function will make a call to another function which is InternetStackHelper() . in
order to give the devices ipv4 with the set base of (10.1.1.0 , 255.255.255.0). the
next step is to give the simulation life time duration. Hello messages are set to be
sent periodically every 15 seconds but this can be changed easily. The next step
is to allow all the nodes to listen to the broadcast message this is very important
because it will tell the simulator that a broadcasting message is expected from
the nodes around.
For n = n , n<number of nodes , n+1
Allow broadcast for node number(n)
73
Connect node number (n) with the remote
Now the nodes are all set in the simulator they will listen to broadcast messages
and move around the defined network topology. A function call will take place in
0.00001 of the simulation life time that will trigger it at second 1 every node in the
network will send a hello message using the function GenerateHello(). And this
will continue every 15 seconds of the simulator life time. The following is
pseudocode for function GenerateHello()
GenerateHello()
Create new packet
Store X position on the packet
Store Y position on the packet
Store current speed on the packet
Store the type of message on the packet
Verify all headers before calling send function
Store info in Ns log function
Schedule simulator send function to be triggered on the time
After receiving the first wave of hello messages and each node create a
neighbors table with information about its own neighbors. the node
ReceivePacket() will be called every time a packet is received. This node will at
first open the header of the received packet to determine what type of messages
74
it received. If the message is a hello message, the node will update its neighbors
table according to the received message. If the packet is a warning message it
will at first check if this packet has been rebroadcasted before or not. If not the
protocol will start to take the steps to decide whether or not a node should favor
rebroadcasting of received packet. First the protocol need to calculate the spatial
distribution for the set of nodes this is done in CalculateSpatialDistribution()
function. Pseudocode for this function is showsn below:
CalculateSpatialDistribution()
Check which nodes are neighbors for the node calling the function
Calculate spatial Distribution for neighbors using equation (1)
Store the spatial Distribution value
Trigger Ns_log to keep log of the simulation.
After having the spatial distribution ready the node should calculate DTM value
and store it as M value to be compared later with Mc value. To calculate M a
function call will be made to the function CalculateDTMValue() in order to
calculate the DTM value and get M value ready.
CalculateDTMValue()
Get the Value calculated in CalculateSpatialDistribution()
Get the distance between current node and spatialDistribution() using equation
(2)
75
Store Value M in the node
Trigger Ns_log to keep track of the events.
The first part of compression is ready and now the node needs to calculate Mc
value in order to compare it to M value after the backofftimer expires. To do so a
several functions are called before finally calling CalculateMc() function. Yet
these functions which are ClaculateAlpha(),CalculateBeta and CalculateDmax()
need the quadrat value as an input next to the number of neighbors and the
channel quality value. Channel quality value is static as suggested by the
developer of this protocol in [35]. To calculate the quadrat value Q a call is made
for the function CalculateQValue()
CalculateQValue()
Get The node location
For n <30
Create 30 random point in transmission radius of the node
If the random point is within 50 meter of the node increase nm
Calculate Q based on equation 4
Trigger Ns_log to keep track of the events.
After having the quadrat value ready the simulator will start trigger the following
functions to calculate threshold value in order CalculateAlpha(),CalculateBeta()
76
and finally CalculateDmax(). The following is a pseudocode for these four
functions:
CalculateAlpha()
Get the Quadrat Value for the node that called the function
Get the number of neighbors for the node that called the function
Calculate Alpha based on equation 4
Store value of Alpha in the node memory
Trigger Ns_log to keep track of the events.
CalculateBeta()
Get the Quadrat Value for the node called the function
Get the number of neighbors for the node called the function
Calculate Beta based on equation 5
Store value of Beta in the node memory
Trigger Ns_log to keep track of the events.
CalculateDmax()
Calculate Dmax based on Equation 6
Store Dmax Value in the node memory
77
Trigger Ns_log to keep track of the events.
Now all the component that the node needs in order to calculate the threshold
value Mc is available in hand to calculate the threshold value the node will make
a call to a function called CalculateMc() value that takes Alpha value, Beta Value
and Dmax value as inputs.
CalculateMc()
Get the number of neighbors for the node called the function
Get Alpha Value for the node that called the function
Get Beta Value for the node that called the function
Get Dmax Value for the node that called the function
Calculate threshold value based on equation 7
Store threshold value in the node memory
Trigger Ns_log to keep track of the events.
Now that the threshold function is there the node can compare between the two
value and decide whether or not it should rebroadcast. This is done in
ReceivePacket() function. Following is the pseudocode for this function:
ReceivePacket()
Open header for received packet
If the packet is hello message extract the sender info
78
Store the info in the receiver neighbor table
Update neighbor’s info
If the packet is a warning message
Check if the message sent before if yes drop the message if not
Start Back Off timer if a message received reset the timer
If no message received
Calculate spatial distribution
Calculate Distance to mean value M
Calculate Quadrat Value
Calculate Alpha Value
Calculate Beta Value
Calculate Dmax Value
Caluclate Mc Value
Rebroadcast if M>Mc
Keep log of every event in Ns Log
That was how nodes deal with packets in order to rebroadcast it according to
DADCQ protocol. The node that will generate the first warning message in the
simulation life time will be selected randomly in every run. All nodes will have
random movement and random speeds and random destination in each run to
79
increase realism of the simulation. The next section of this chapter will go over a
conclusion of the implementation of DADCQ protocol on Ns3.
CONCLUSION
In this chapter an overview was given that covered Distribution-Adaptive
Distance with Channel Quality (DADCQ) that includes what type of protocols this
one is and what goals DADCQ try to achieve. To implement this protocol on Ns3
road topology was needed and was implemented on SUMO traffic simulator and
finally was transferred into trace file using middleware tool TraceExpertor in order
for Ns3 to be able to read it. Two scenarios were implemented for this protocol
which are urban scenario and highway scenario. This chapter covered also the
main functions this protocol uses to calculate threshold function in order to use it
to decide whether or not it should favor rebroadcasting of a packet. The next
chapter covers the implementation of SLAB protocol.
80
CHAPTER 7 IMPLEMENTATION OF STATISTICAL LOCATION ASSISTED
BROADCAST PROTOCOL FOR VANET ON NS3
INTRODUCTION
In this chapter an overview of statistical location assisted broadcast adaptive
broadcast protocol (SLAB) is given in addition to the steps used in Ns3 to
implement it. Like Distance to mean this broadcast protocol adapts to the
changes in the network, in fact, this protocol is an improvement of DADCQ
protocol which automates the threshold function design using machine learning
techniques. As most of VANET broadcast protocol, SLAB is designed to serve
safety application and deliver the messages with high reachability and better
performance than pure flooding of the network. This protocol shares a lot of
characteristics with distance to mean protocol such as using the number of
neighbors in order to determine a good threshold function and make a use of
spatial distribution for a set of vehicles that are neighbors to the vehicle that will
send the packet on the other hand this protocol share the use of Quadrat value
and channel quality with DADCQ protocol. In short this protocol is an advanced
version of DADCQ with more complexity added to it. This protocol relies on
several dynamic factors in order to calculate threshold function such as channel
quality and quadrat value. Moreover, this protocol uses machine learning
81
functions which is MLP function in order to create a threshold function to
rebroadcast the packet. An advantage of this protocol is its adaptability to the
number of neighbors in particular area. If the number of neighbors is large this
means most of the nodes probably received the packet so the protocol won’t
send the packet to avoid flooding and losing of bandwidth. Just like most
broadcast protocol this protocol let the nodes of the network exchange hello
messages periodically for a specific node to collect information about its
neighbors. When a node receives a packet, it will check first in this protocol
whether or not this packet has been received before if yes the node will drop
this packet automatically without rebroadcasting it to its neighbors. If this packet
is new the node will perform the protocol steps in order to decide whether or not
to rebroadcast this packet. Figure 26 shows general UML activity diagram for this
protocol. Value of M is calculated just like in Distance to mean protocol simply
every node will include its own location in hello message beside its ID. The node
will calculate the
82
spatial distribution to its neighbors first using equation 2
(𝑥, 𝑦) = (1
𝑛∑ 𝑥𝑖𝑛
𝑖=1 ,1
𝑛 ∑ 𝑦𝑖𝑛
𝑖=1 ) (2)
After having the spatial distribution value. The node will calculate the distance
between itself and the spatial distribution value in order to calculate the value of
M this can be calculated easily using equation 3. Where r is the transmission
radius for the node.
𝑀 =1
𝑟 √(𝑥 − 𝑥)2 + (𝑦 − �̅�)2 (3)
After having the distance to mean value ready SLAB compare this value to its
threshold function value. The key factor for successful broadcast protocol is
having a good threshold function if this value is set too high reachability of the
Figure 26 General Activity Diagram for SLAB protocol
83
network will decay if the value set too low most of the nodes will send the packet
which normally lead to flooding. The more the threshold function can adapt to the
changes in the network the better the protocol will perform in general. In SLAB
the threshold function relay on three main components which are the number of
neighbors for the node N, the quadrat static value for the node Q and finally the
channel quality for the node K. the first input which is the number of neighbors for
a specific node can be calculated easily based on the hello message the node
receives from its neighbors. the quadrat value aims to measure how evenly the
neighbors of a specific vehicle are distributed in the road topology. In statistics
quadrat value can be defined as the ratios of a set of points to its mean. In SLAB
calculating quadrat value include some complexity and use of method called
static sampling. To do so a 30 sampling is used as suggested by the developer
of this protocol [35].
First the node that try to rebroadcast the message will generate thirty
random point within the node transmission area.
If the node itself and its neighbors are within r/5 of this random point
where r stand for transmission radius increment the frequency array by
one.
After thirty run calculate the total value for the array and get the quadrat
value which can be calculated using equation 10
𝑄 =𝑉[𝑛]
𝐸[𝑛] (10)
84
If the distribution of vehicles is uniformaly random the value of Q is expected to
be close to one. Yet if the value of Q is less than one that mean the nodes are
more evenly spaced. If the value exceed one that means the nodes are clustred.
The third components that this protocol use as an input to the threshold function
is the channel quality K. dynamically this protocol takes the worst case of K and
the best case of K in order to measure a channel quality as suggested by the
developer of the protocol according to the developer of this protocol finding the
value of K dynamically is intense task [35] yet according to other protocols that
use channel quality K the channel quality value are almost never less than 5 just
as in [36] and [37] Meanwhile its almost never higher than 13 so and assuming
that vehicles equipped with VANET capability any vehicle will probably be
equipped advanced mapping and navigation system it is possible to use static
value for K based on the different geographical locations as suggested by the
actual developer of the protocol [35] . In SLAB, the protocol aims to use the best
available channel for the nodes to transmit packets in order to have the best
possible reachability. After having the quadrat value, the channel quality and the
number of neighbors’ value, SLAB protocol will use these values as an input in a
Multi-layer perceptron (MLP) function since this machine learning function
capable of approximate any function into arbitrary accuracy. SLAB use MLP
function with m input variable and n hidden perceptron as in equation 11.
85
Since MLP function need solutions as an inputs as well the developer of this
protocol suggest to use the weight in table 9 as an inputs:
(11)
Table 9 Input Weights for MLB function
PERCEPTRON WEIGHTS
HIDDEN 1 (W1) 0.164, 0.394, -0.193, 2.689
HIDDEN 2 (W2) -0.587, 2.074, -0.311, -0.416
OUTPUT (V ( 2.784, -1.538, -2.961
After using the weights and K, Q, N values we will finally get the threshold value
for the node Mc finally the protocol will compare between Mc and M and
rebroadcast the packet if and only if M value is bigger than the threshold function
value Mc. Figure 27 shows UML activity diagram that shows the steps the
protocol takes in order to decide whether or not a node should favor
rebroadcasting a packet.
86
The next section of this chapter will go over the implementation of this broadcast
protocol using network simulation tool Ns3.
Figure 27 SLAB activity diagram
87
IMPLEMENTATION
To Implement SLAB broadcast protocol for VANET a new model for Ns3 has
been created following the official skeleton of models suggested by Ns3
development team. Since SLAB share some characteristics with Distance to
mean protocol the steps to build the environment for this protocol is very similar
to the one taken in developing Distance to mean and DADCQ protocols in
chapter four and five. SUMO was used in order to generate trace files to be used
to simulate vehicular movements. Version 0.24 was used to generate these files.
Two scenarios were implemented the first was an urban scenario as in Figure 28
and the second was a highway scenario as in Figure 29.
Figure 28 Urban road topology used to simulate SLAB
88
Figure 29 Urban road topology used to simulate SLAB
After creating the road topology for the network the same steps were taken in
order to create a trace file that network simulation tool Ns3 can handle. Figure 30
shows these steps.
In Ns3 there are two main files were created one file is called SLAB which takes
care of telling Ns3 how SLAB works. The other file is called SLABPacket which
takes care of defining the packet headers that are used in Hello messages for
this protocol. A primary class was created which is called SLABProtocol with
functions inside this class that define the steps of the simulation. Just as in
distance to mean and DADCQ protocol during the implementation the function
NS_log was very handy to keep track of the current event. The rest of this
chapter will go over the steps performed in each function with a pseudo code of
it. As mentioned earlier in this thesis Ns3 is a very detailed simulator that cares
for the smallest details of the network. Clearly the first step was to create
vehicles that define the network and give them some properties this step was
Figure 30 steps to extract trace file from sumo
89
done in the function createNodes() which look very similar to the one defined for
DTM protocol. The following is the pseudocode for the function:
CreateNodes()
Create nodes (number of defined nodes in the simulation)
Create an object for the trace file .tcl called ns
Install ns on all the nodes
That function took care of creating the nodes (vehicles) and installed the trace file
which was exported from sumo on all the nodes so now each node is expected to
move according to the scenario created earlier in SUMO traffic simulator. The
next step is to create a net device and install it on each and every node this net
device will have the following properties:
having a transmission radius of 250~ meter.
Use WIFI 802.11p standard for the vehicles to communicate wirelessly
with each other.
Below is the pseudocode for CreateDevice() function:
CreateDevice()
Create wifiphy layer
Set transmission radius to 250~ meter
Create default wifichannel
Set datalink type
90
Set MacHelper
Set wifi using wifi802.11P Helper
Set Remotestation Manager
Install all of the above on the devices install()
Test the netdevice using Ns_Log
So now we have nodes that will move in the road topology with net devices
installed on each node according to our requirements. The next step is to tell the
simulator how nodes should communicate with each other please note that the
function createDevice() make a call to another function which is
InternetStackHelper() . in order to give the devices ipv4 with the set base of
(10.1.1.0 , 255.255.255.0). the next step is to give the simulation duration this
duration is actually the life time of the simulator in this implementation hello
messages are set to be sent periodically every 15 seconds but this can be
changed easily. The next step is to allow all the nodes to listen to the broadcast
message this is very important because it will tell the simulator that a
broadcasting message is expected from the nodes around.
For n = n , n<number of nodes , n+1
Allow broadcast for node number(n)
Connect node number (n) with the remote
Now the nodes are all set in the simulator they will listen to broadcast messages
and move around the defined network topology. A function call will take place in
91
0.00001 of the simulation life time that will trigger it at second 1 every node in the
network will send a hello message using the function GenerateHello(). And this
will continue every 15 seconds of the simulator life time. Figure 31 is the UML
activity diagram that explain the previous functions flow.
Generate Hello takes care of creating hello packets for the simulation and install
the header that was created in SLABHEADER file, so it’s ready to be sent
whenever the simulator call for it. Following the pseudocode for GenerateHello()
GenerateHello()
Create new packet
Store X position on the packet
Figure 31 Creating Simulation environment for SLAB activity Diagram
92
Store Y position on the packet
Store current speed on the packet
Store the type of message on the packet
Verify all headers before calling send function
Store info in Ns logs function
Schedule simulator sends function to be triggered at the time
After the first wave of hello messages is sent all the vehicles in the transmission
radius will listen to it each vehicle will exchange hello messages with their
neighbors. After receiving a hello message notification, the node will call
ReceivePAcket() function to deal with the packet it just received. The first thing
the node will do after receiving a packet is to open the header of the packets and
look for the Massege_type_header this will tell the node what type of message
the node just received. In this simulation, there is only two type of messages
which are a hello message and accident warning message. The nodes will treat
each type of message in a different way. If its hello message, the node will open
the rest of headers and update its neighbors table with the number of neighbors
and the location and ID of each neighbor. Figure 32 shows an overview of
ReceiveMessage() function.
93
The following is the pseudocode for ReceivePAcket()
ReceivePacket()
Open header for received packet
If the packet is hello message extract the sender info
Store the info in the receiver neighbor table
Update neighbor’s info
If the packet is a warning message
Check if the message sent before if yes drop the message if not
Start Back Off timer if a message received reset the timer
If no message received
Figure 32 Receive Message function+
94
Calculate spatial distribution
Calculate Distance to mean value M
Calculate Quadrat Value
Caluclate Mc MLP Value
Rebroadcast if M>Mc
Keep log of every event in Ns Log
Whenever a warning message is received, the simulator will check automatically
if this message has been sent before or not based on the sequence number of
messages.
The protocol will use the same method explained earlier in chapter four in order
to calculate the value of M to get the distance to mean value which will be
compared to the Mc value. Mc value is calculated based on three inputs to MLP
function as explained earlier in this chapter in ClaculateMc() function. The values
are Quadrat Value, which are calculated in CalculateQ(). The other value is the
channel Quality K which is a static value, and the third value is the number of
neighbors of this node N. all these values are used as an input to the MLB
function in addition to the weights defined in Table 8. Following is the
pseudocode for CalculateQ() function:
CalculateQ()
Generate 30 random point that fall in the node transmission area
95
Check if the point is within 250/5 meter of the node and its neighbors
If yes increment the array n
Calculate Q based on the Variance n over Mean n
Store Q value to the node
Keep log of every event in Ns Log
CalculateMc()
Get the Q value for the node called the function
Get the N value for the node called the function
Calculate Mc using MLB function with Q,N,K as an input in addition to the
weights
Keep log of every event in Ns_Log
Finally, after getting the value of Mc and M the protocol will compare the two
value and the node will rebroadcast a message if and only the value of M > Mc.
the next section will give a conclusion of this chapter.
CONCLUSION
In this chapter an overview of statistical location assisted broadcast adaptive
broadcast protocol (SLAB) is given. The threshold function components are
explained in details including the weights this protocol uses. Moreover, an
overview of the steps used to implement the road topology is given briefly in this
chapter since this protocol shares the same environment with DTM and DADCQ
96
protocols. An explanation of the steps taken to implement this protocol in network
simulation tool Ns3 is given as well. The next chapter of this thesis covers
evaluation, verification and validation of the three implemented protocols
97
CHAPTER 8 EVALUATION, VERIFICATION AND VALIDATION OF THE
PROTOCOLS
In this thesis, three broadcast protocols, DTM, DADCQ and SLAB are
implemented on network simulator Ns3. To validate our Ns3 implementations of
the three protocols, we first evaluate their performance in terms of reachability,
rebroadcasts per covered node and bytes sent per covered node. These metrics
are explained as follows:
Reachability: Average fraction of nodes that receive source messages.
Rebroadcasts per covered node: Number of retransmissions to a number
of nodes that receive the message ratio.
Bytes sent per covered node: Total number of bytes sent to a number of
nodes that receive the message ratio.
We then validate our NS-3 implementations of the three protocols against
their JiST/SWANS.
EVALUATION
This section covers evaluation of the three protocols implemented in this thesis.
The simulation is implemented for a different number of nodes to test the
98
performance of the different protocols under different network densities. The
simulation starts with two waves of hello messages exchanged between all the
nodes and after that, a random node will be picked to deliver an accident warning
message to its neighbors. Each node that receives the message will implement
the protocol to decide whether or not it should rebroadcast the received warning
message to its neighbors as explained in earlier chapters of this thesis. Different
mobility scenarios are generated using SUMO and used with each protocol. A
total of five-run are done for each particular number of neighbors, and the
average is taken to get the result. Each vehicle will have random speed through
the lifetime of the simulator that varies between 40 to 100 km/h. A number of
neighbors for this simulation vary starting from 20 nodes and ending up with 400
nodes. With each number implemented for each protocol five times. DADCQ and
SLAB protocols use channel quality as an input for threshold function channel
quality used is the same one as suggested by the actual developer of the two
protocols in [35]. Hello, messages are sent periodically every 15 seconds
between the nodes of the network before the start of every hello message wave
all nodes will flush its memory to keep accurate and most recent data about its
neighbors. This simulation is done on Ns3 version 3.21 using C++. Different road
topologies were created on SUMO traffic simulator version 0.24. Table 10 shows
the simulation parameters utilized for the three broadcast protocol for vehicular
ad hoc network.
99
Table 10 Simulation Parameters
Parameter Value
Number of Neighbors 20,40,80,120,250,400
Duration 1800 seconds
Packet Size 500 bytes
Max Speed 100km/h for highway
60km/h for Urban
Hello Message interval 15 seconds
Mac/Phy protocol IEEE 802.11p
Transmission Range 250~ Meters
Layer 3 Addressing IPv4
Figure 33 shows a plot for the number of rebroadcasted messages vs the
number of received messages in each and every node in the network for highway
scenario. It’s clear that SLAB broadcast protocol outperform both DADCQ and
DTM protocols this come as no surprise since SLAB is the most advanced
protocol between the three as well the most adaptive one to network change
when compared to DADCQ and DTM protocols since it uses machine learning to
compute threshold function for a node to decide whether or not this node should
favor rebroadcasting. When the number of nodes is less than 150 both DADCQ
and DTM have close performance to each other’s when the number of node
increase DADCQ outperform DTM however, SLAB keep giving good
performance comparing the other two under any density as showed in the graph.
The performance of both SLAB and DTM become steady after a density of 200
nodes when compared to DADCQ that get close to DTM performance as the
number of nodes in the network increase. It’s important to have high reachability
100
in VANET broadcast protocol especially when the protocol is dealing with safety
messages, yet bandwidth in the network could be limited so having every node
rebroadcasting the packet will increase bandwidth consumption which is the
problem this thesis discussed in earlier chapters called “Broadcasting Storm”.
Figure 33 Rebroadcasted messages Vs Received Messages in SLAB DADCQ and DTM in highway scenario
Figure 34 shows the same metric but for urban scenario it’s clear that the three
protocols performed better in highway than urban after all three protocols are
designed to serve highway first. Just as in highway scenario in urban scenario
SLAB outperform both DADCQ and DTM in most cases the different become
clear between the three protocols when the number of nodes in the network
increase.
101
Figure 34 Rebroadcasted messages Vs Received Messages in SLAB DADCQ and DTM in Urban scenario
Figure 35 shows the number of transmitted bytes in the network between nodes
for highway scenario. This include the bytes for both hello messages and
warning messages since the simulation of Ns3 depend on high randomization of
speed and driving behaviors between vehicles this lead to having the number of
transmitted bytes vary in each run its noted that when the number of nodes
increased in the network DADCQ outperformed DTM and SLAB while when the
density of the network was high comparing to having low density in the network
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
50 100 150 200 250 300 350 400
Reb
road
cast
Per
Co
vere
d N
od
e
DADCQ
SLAB
DTM
Number of nodes
102
In general the three protocols have close results when it coming to bandwidth
consumptions in the network. In Figure 36 the same metric is showed but for
urban
scenario again in highway scenario the protocols perform better than in urban
scenario. The denser the network, the more bytes transmitted between nodes. In
general, in urban scenario DADCQ outperform both SLAB and DTM protocols
especially when the number of nodes is high in the network. When the number of
nodes is low SLAB outperform DADCQ and DTM protocols.
Figure 35 Bytes Sent per covered node Highway Scenario
103
Finally, in Figure 37 a plot represents reachability for the three broadcast
protocols in highway scenario all the three protocols have similar reachability
when it comes to low density in the network. As the density of the network
increase SLAB starts to outperform both DADCQ and DTM protocols
scientifically delivering the message to a high number of nodes, However, the
three protocols have over .95 reachability under every density in the network
which is a good rate of reachability for Vehicular ad hoc network.
Figure 36 Bytes Sent per covered node urban Scenario
104
In Figure 38 the same metric compares the three protocols but in urban scenario
instead of highway scenario. Generally, SLAB protocol outperform both DADCQ
and DTM in term of reachability. Under low density, the three protocols have
close performance the denser the network get, the more SLAB perform better in
the network compared to the two other protocols. The three protocols perform
better in highway scenario when compared to their performance in an urban
scenario.
Figure 37 Reachability in Highway Scenario
105
Figure 38 Reachability in Urban Scenario
VALIDATION
We validate our Ns-3 implementations of the three protocols against their
JiST/SWANS Implementations in [34] and [35]. Even though we tried to emulate
the same environment as in [34] and [35], there are still a few differences
between the two environments in terms of traffic inputs and mobility traces. Table
11 compares SLAB reachability results for the Ns-3 and JiST/SWANS
Implementations. Table 12 compares SLAB rebroadcasts per covered node
results for the Ns-3 and JiST/SWANS Implementations.
106
Table 11 SLAB reachability results for the Ns-3 and JiST/SWANS Implementations
Table 12 SLAB broadcasts per covered node results for the Ns-3 and JiST/SWANS Implementations
Number of
Nodes
JiST/SWANS Urban
scenario
Ns-3
Urban
scenario
JiST/SWANS
Highway
scenario
Ns-3
Highway
scenario
200 0.8 0.9 0.95 0.95
250 081 0.87 0.95 0.96
300 0.8 0.81 0.96 0.96
350 0.84 0.85 0.96 0.97
400 0.88 0.82 0.96 0.96
Number of
Nodes
JiST/SWANS
Urban scenario
Ns-3
Urban
scenario
JiST/SWANS
Highway
scenario
Ns-3
Highway
scenario
200 0.31 0.45 0.38 0.45
250 0.30 0.41 0.35 0.48
300 0.33 0.55 0.37 0.55
350 0.38 0.546 0.42 0.61
400 0.41 0.61 0.41 0.64
107
VERIFICATION
To verify our implementation, we use NS_log, an Ns-3 function, which keeps
a log of simulation events. After each implemented step in the simulation, a
critical review of each line in the log is done to ensure that the function
performs to its specification. Moreover, manual calculation was used to verify
the correctness of the simulated mathematical functions. Finally, NetAnim, an
animation tool is used to provide animation for the simulation. The animation
helps to verify that the nodes move correctly and send packets correctly to all
the neighbors within their transmission range. As seen in Figure 39.
Figure 39 NetAnime animation for SLAB protocol
108
CONCLUSION
We ran our implementations of the three protocols on Ns-3 simulator tool with the
help of SUMO traffic simulator to generate road topology for the network. SLAB
Outperforms both DADCQ and DTM regarding reachability and the number of
rebroadcasted messages compared to the number of received messages in
every wave. Having a low number of rebroadcasted messages per node is
imperative in vehicular ad hoc network due to the limitation of bandwidth in
VANET. Having very low reachability will miss the goal of delivering safety
messages to many nodes in the network. The higher the density is for the three
protocols, the higher the reachability rate becomes which is expected because
more nodes will deliver the message to their neighbors which means more nodes
will receive the warning message. The next chapter will give a conclusion for this
thesis
109
CHAPTER 9 CONCLUSION AND FUTURE WORK
CONCLUSION
Vehicular Ad-hoc Network is a new technology that aims to increase the safety of
vehicles as well as introduce more comfort and entertainment options for
vehicles users’. Data dissemination in VANETS is a challenging problem for
several reasons including the limited bandwidth in the network, the fast
movement of nodes in the network and the continued change in the topology of
the network. Efficient broadcasting methods are needed to support most safety
and none-safety applications. Simulation is a viable technique for the design and
implementation of VANET broadcast protocols. Ns-3 is one of the most advanced
network simulation tools that can be used to simulate VANET. Ns-3 lacks any
implementation of broadcast protocols for VANET. In this thesis, three broadcast
protocols are implemented on Ns-3. The first protocol Distance to Mean (DTM)
uses the distance to mean method to decide if a node should favor
rebroadcasting of a received messages or not. The second protocol Distribution-
Adaptive Distance with Channel Quality (DADCQ) uses node distribution,
channel quality and distance to decide if a node should favor rebroadcasting of a
received message or not. The third protocol statistical Location-Assisted protocol
is an improvement of DADCQ which automates the threshold function decision
110
process using machine learning techniques. In this thesis we also survey
different broadcast protocols for VANET as well as different network simulators
and traffic simulators. Our Ns-3 implementations of the three protocols have
been validated against their JiST/SWANS implementations.
FUTURE WORK
This work has presented the implementation of DTM, DADCQ and SLAB
protocols on Ns3 simulation tool. For future work more broadcasting protocols
will be implemented on Ns-3.
111
BIBLIOGRAPHY
[1] United States Department of Transportation
[2] Si-Ho Cha Department of Multimedia Science, Chungwoon University A
Survey of Broadcast Protocols for Vehicular Adhoc Networks International
Journal of Innovation and Applied Studies ISSN 2028-9324 Vol. 3 No. 3 July
2013, pp. 829-846
[3] Sze-Yao Ni, Yu-Chee Tseng, Yuh-Shyan Chen, and Jang-Ping Sheu , The
Broadcast Storm Problem in a Mobile Ad Hoc Network Wireless Networks -
Selected Papers from Mobicom'99 Volume 8 Issue 2/3, March-May 2002
[4] Tasneem Bano, Jyoti Singhai Department of Computer Science And
Engineering, MANIT, Bhopal, India Probabilistic Broadcast protocol In AD HOC
Network And Its Advancement International Journal of Computer Science &
Engineering Survey (IJCSES) Vol.1, No.2, November 2010
[5] Rakesh Kumar, Mayank Dave Department of IT, M. M. University, Mullana,
Haryana, India A Comparative Study of Various Routing Protocols in VANET
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 1,
July 2011
112
[6] Jothi K R,Ebenezer Jeyakumar A A Survey on Broadcast protocols in vanets
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 1,
July 2011
[7] Fei Ye, Student Member, IEEE, Sumit Roy, Fellow, IEEE, Haobing Wang,
Student Member, IEEE Efficient Data Dissemination in Vehicular Ad Hoc
Networks.
[8] Sukdea Yu1) and Gihwan Cho2) 1) Dept. Of Computer Statistic & Information,
Chonbuk National University, Jeonju, South Korea A Selective Flooding Method
for Propagating Emergency Messages in Vehicle Safety Communications
[9] B. Bako, M. Weber, “Efficient information dissemination in vanets,” Advances
in Vehicular Networking
[10] ozan k. Tonguz and nawaporn wisitpongphan, carnegie mellon university fan
bai, general motors corporation dv-cast: a distributed vehicular broadcast
protocol for vehicular ad hoc networks
[11] Gokhan ¨ Korkmaz Eylem Ekici Department of Electrical and Computer
Engineering 2015 Neil Avenue, 205 Dreese Lab. Columbus, OH Urban Multi-
Hop Broadcast Protocol for Inter-Vehicle Communication Systems
[12]G. Korkmaz, E. Ekici, F. Ozguner, “An efficient fully ad-hoc multi-hop
broadcast protocol for inter-vehicular communication systems,” in Proc. Of the
IEEE International Conference on Communications (ICC '06), vol. 1, pp. 423-428,
Istanbul, Turkey, Jun. 2006.
113
[13] A. M. Vegni, A. Stramacci, E. Natalizio, “SRB: a selective reliable broadcast
protocol for safety applications in VANET,” in Proc. Of International Conference
on Selected Topics in Mobile & Wireless Networking
[14] A. D. Ghodrati, “Reduces broadcast storm using clustering in vantes,”
International Research Journal of Applied and Basic Sciences, vol. 7, no. 13, pp.
979-987, 2013
[15]P. Akkhara, Y. Sekiya, Y. Wakahara, “Efficient alarm messaging by multi-
channel cut-through rebroadcasting based on inter-vehicle communication,”
IAENG International Journal of Computer Science, vol. 36, no. 2, May 2009.
[16]iidavis,J.S.andj.P.M.G.Linnartz. Vehicletovehiclerfpropagationmeasurements.
In Signals, Systems and Computers, 1994. 1994 Conference Record of the
twentyeighth Asilomar Conference on, volume 1, pages 470 –474 vol.1, oct.
1994.
[17]H. Jiang, H. Guo, L. Chen, “Reliable and efficient alarm message routing in
VANET,” in Proc. Of the 28th International Conference on Distributed Computing
Systems Workshops (ICDCSW '08), pp. 186-191, Washington DC, USA. 2008.
Article (crossref Link)
[18] H. Alshaer, E. Horlait, “An optimized adaptive broadcast scheme for inter-
vehicle communication,” in Proc. Of the IEEE 61st Vehicular Technology
Conference (VTC 2005), vol. 5, pp 2840-2844, Jun. 2005.
114
[19] Sooksan Panichpapiboon, Member, IEEE, and Wasan Pattara-atikom,
Member, IEEE A Review of Information Dissemination Protocols for Vehicular
Ad Hoc Networks
[20] Christoph Sommer Student Member, IEEE and Falko Dressler Senior
Member, IEEE Computer Networks and Communication Systems Dept. Of
Computer Sciences University of Erlangen-Nuremberg, Germany Progressing
Toward Realistic Mobility Models in VANET Simulations
[21] R. Manaram, D. S. Weller, D. D. Stancil, R. Rajkumar, and J. S. Parikh,
“groovesim: A topography-accurate simulator for geographic routing in vehicular
networks,” in Proceedings of the 2nd ACM International Workshop on Vehicular
Ad Hoc Networks, Cologne, Germany
[22] CANU Documentations
[23] Jérôme Härri University of Karlsruhe, Institute of Telematics 76131
Karlsruhe, Germany Vehicular Mobility Simulation with vanetmobisim
[24] Michael Behrisch, Laura Bieker, Jakob Erdmann, Daniel Krajzewicz Institute
of Transportation Systems German Aerospace Center Rutherfordstr. 2, 12489
Berlin, Germany SUMO – Simulation of Urban mobility An Overview. The Third
International Conference on Advances in System Simulation.
[25] Syed A. Hussain and A. Saeed Department of Computer Science,
COMSATS Institute of Information Technology, Lahore, Pakistan An Analysis of
115
Simulators for Vehicular Ad hoc Networks. World Applied Sciences Journal 23
(8): 1044-1048, 2013
[26] Evjola Spaho, Leonard Barolli, Gjergji Mino, Fatos Xhafa and Vladi Kolici
VANET Simulators: A Survey on Mobility and Routing Protocols. Broadband and
Wireless Computing, Communication and Applications (BWCCA), 2011
International Conference
[27] Michał Piorkowski, Maxim Raya, Ada Lezama Lugo, Panos Papadimitratos,
Matthias ´ Grossglauser, and Jean-Pierre Hubaux trans: Realistic Joint Traffic
and Network Simulator for vanets. ACM SIGMOBILE Mobile Computing and
Communications Volume 12 Issue 1, January 2008
[28] Alpana Dahiya1, Ajit Noonia2, Banta Singh Jangra3, Jaibir4 1Department of
Computer Science & Engineering, MVJ College of Engg. Vehicular Ad hoc
Networks (VANETS): Simulation and Simulators. ITS Telecommunications, 2008.
ITST 2008. 8th International Conference
[29] Evjola Spahoa, Leonard Barollib, Gjergji Minoa, Fatos Xhafac, Vladi Kolicid
and Rozeta Mihod Implementation of CAVENET and its usage for performance
evaluation of AODV, OLSR and DYMO protocols in vehicular networks. Network-
Based Information Systems (nbis), 2010 13th International Conference
[30] Florent Kaisser, Christophe Gransart, Marion Berbineau Simulations of
VANET Scenarios with OPNET and SUMO.
Nets4Cars/Nets4Trains'12 Proceedings of the 4th international conference on
Communication Technologies for Vehicles
116
[31] Narendra Mohan Mittal1, Savita Choudhary2 1,2M-Tech. Student & MVN
University, Palwal, Haryana, India; Comparative Study of Simulators for
Vehicular Ad-hoc Networks (vanets). WIRELESS COMMUNICATIONS AND
MOBILE COMPUTING Book 2009
[32] Omnet++ User Manuel
[33] Ns3 manuel
[34] Michael Slavik m Imad Mahgoub , Mohammed M. Alwakeel Analysis and
evaluation of distance to mean broadcast method for VANET. Journal of King
Saud University - Computer and Information Sciences Volume 28, Issue 2,
Pages 147-246 (April 2016)
[35] Michael Slavik, Imad Mahgoub Department of Computer and Electrical
Engineering and Computer Science Florida Atlantic University Applying Machine
Learning to the Design of Multi-Hop Broadcast Protocols for VANET. Wireless
Communications and Mobile Computing Conference (IWCMC), 2011 7th
International
[36] iidavis,J.S.andj.P.M.G.Linnartz.
Vehicletovehiclerfpropagationmeasurements. In Signals, Systems and
Computers, 1994. 1994 Conference Record of the twentyeighth Asilomar
Conference on, volume 1, pages 470 –474 vol.1, oct. 1994.
[37] A.Domazetovic,L.J.Greenstein,N.B.Mandayam,andi.Seskar.
Propagationmodels forshort-
117
rangewirelesschannelswithpredictablepathgeometries. Communications, IEEE
Transactions on, 53(7):1123 – 1126, jul. 2005.