Direction Based Routing Algorithms in VANETs
Abhay Deep Seth
Department of Computer Science & Engineering, SVCE, Indore (M.P.)
abhayseth64@gmail.com
Abstract: - The Networks of vehicles moving on the road are considered as Vehicular Ad Hoc Networks (VANETs).
The relative speed of the vehicles may be up to 300 km/hr and the number of nodes is very high. In Vehicular Ad
Hoc Networks (VANETs) the nodes movement is bounded to road topology. In VANET the link breakage can be
avoided with the help of the mobility pattern knowledge for neighbor nodes. In this paper, routing algorithms for
VANETs are used in presence of IEEE802.11p as infrastructure. To limit the flooding between the number of nodes,
roads are divided into small segments with help of fixed infrastructure, which is known as Road Side Units (RSUs).
The routing algorithm is used for Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I) communication. In
this paper, the performance is evaluated over two parameters i.e. routing overhead and jitter for V2V and V2I
communication when the vehicles are moving with constant or variable speed bidirectional in highway scenario.
Keywords: - IEEE802.11p, RSUs, Routing Overhead, Jitter, VANETs, Vehicle to Vehicle (V2V), and Vehicle to
Infrastructure (V2I).
1. INTRODUCTION
Vehicular Ad hoc Networks (VANETs) are
ad hoc networks which can operate without
any
infrastructure
or
centralized
management. In such a case, the network
organization is carried out by the nodes
themselves. Every node is capable to work
as a sender, destination or as a forwarding
node. Nodes in VANETs can achieve very
high speeds. This motion of the nodes
produces frequent changes in network
topology, so that the design of routing
protocols able to adapt to the dynamic
environment is a really challenging task
(Figure 1).
Figure 1: VANET [1]
A VANET can be considered as a particular
type of MANET (Mobile Ad hoc Network).
However, the main difference is the speed in
nodes. This factor may produce quick
changes in the network topology and thus
turn out to short link lifetimes. In addition,
vehicle's devices hardly have limitations
regarding energy supply and can have a high
processing power. By the end of 2010, the
standard IEEE 802.11p is released, and it
will contribute to improve communication
among vehicles and also between vehicles
and RSU (Road Side Units). The range of
802.11p is about 1 km. Also, vehicles are
envisioned to carry multiple types of
wireless transceivers to be able to
communicate across more than one wireless
data links; vehicles will be equipped with an
OBU (On-Board Unit) which will manage
the communication between different
technologies (e.g. Wi-Max, satellite).
Besides, vehicles will easily get Internet
connectivity through the closest available
AP (Access Point) along the roadside.
Vehicular ad hoc networks (VANETs)
enable vehicles to communicate with each
other but require efficient routing protocols
for its success. It requires the roadside units
(RSUs) to efficiently and reliably route
packets in MANETs. The system will be
operated by using vehicles to carry and
forward messages from a source node to a
nearby RSU and, if needed, route these
messages through the RSU network and,
finally send them from a RSU to the
destination node. The communication
between the nodes must be done in a
scenario like highway using the Dynamic
Source Routing (DSR) and Ad Hoc OnDemand Distance Vector (AODV) routing
algorithms with the help of RSUs for the
nodes which are very far away from each
other in an efficient way.
In this paper, evaluation for the performance
of the V2V and V2I communication over
two parameters i.e. routing overheads and
jitter while the vehicles are moving with
constant or variable speed bidirectional in
highway scenario.
NS3 is an open sourced discrete-event
network simulator which targets primarily
for research and educational use. NS3 is
licensed under the GNU GPLv2 license, and
is available for research and development.
NS3 is designed to replace the current
popular NS2. However, NS3 is not an
updated version of NS2 since that NS3 is a
new simulator and it is not backwardcompatible with NS2. The basic idea of NS3
comes from several different network
simulators including NS2, YANS and
GTNetS. The major difference lying
between NS3 and NS2 includes:
(1) Different software core: The core of
NS3 is written in C++ and with Python
scripting interface (compared with OTcl in
NS2). Several advanced C++ design patterns
are also used.
(2) Attention to realism: Protocol entities
are designed to be closer to real computers.
(3) Software integration: Support the
incorporation
of
more
open-source
networking software and reduce, the need to
rewrite models for simulation;
(4) Support for virtualization: Lightweight
virtual machines are used.
The structure of the paper is as follows. In
Section II, we discuss the related work. In
Section III, we make an overview of DSR
and AODV algorithms. In Section IV, we
describe the simulation scenarios. In Section
V, we discuss the Results. Finally,
conclusions are given in Section VI.
2. RELATED WORK
According to [2], the protocol comprises of
two main mechanisms of “Route Discovery”
and “Route Maintenance”, which work
together to allow nodes to discover and
maintain routes to arbitrary destinations in
ad hoc networks. The authors further stated
that the protocol operates entirely on
demand, allowing the routing packet
overhead of DSR to scale automatically only
what is needed to react to changes in the
routes currently in use. The protocol allows
multiple routes to any destination and at the
same time allowing each packet sender to
select and control the routes used in routing
its packets.
Jerome Haerri et.al [3] evaluated the
performance of AODV and OLSR for
VANET in city environment, in their study
all the characteristics are handled through
the Vehicle Mobility Model. Their study
showed that OLSR has better performance
than AODV in the VANET, as the
performance parameters that they have used
less overhead on the network as compared to
OLSR.
Performance analyses of traditional ad-hoc
routing protocols like AODV, DSDV and
DSR for the highway scenarios have been
presented in [4], and the authors proposed
that these routing protocols are not suitable
for VANET. Their simulation results
showed that these conventional routing
protocols of MANET increase the routing
load on network, and decrease the packet
delivery ratio and end to end delay.
O. Abedi et.al enhanced traditional MANET
routing protocol AODV to improve route
stability and less overhead of network and
makes it suitable for VANET, they named it
as PAODV and DAODV [5,6]. Their study
showed that more appropriate routes can be
found with and without mobility prediction.
In their study, they selected fewer routes to
overcome routing overhead on network and
this effect overcomes the link breakage as
compared to AODV.
In Roadside aided routing Inter-Vehicle
Communications (IVC) and Roadside-toVehicle
Communications
(RVC)
in
vehicular networks based on IEEE 802.11
are emerging technologies for future
Intelligent Transportation Systems (ITS).
The representation of a new efficient routing
approach, called RAR (Roadside-Aided
Routing) that is the first one to exploit the
unique characteristics of vehicular networks.
A novel affiliation method is proposed to
affiliate a vehicle to several Roadside Units
based on road constraints. This scheme
allows (a) agent advertisement to be
broadcast in one hop (instead of multi-hop),
(b) routing to be done in single phase,
comparing to two phases, (c) to eliminate
the use of hierarchical addressing which is
commonly used in single-phase schemes.
Simulation results of ns-2 show that RAR
approach can provide a high packet delivery
rate in vehicular networks with a low and
constant overhead. The efficient routing
approaches in the emerging vehicular
networks. The unique road constraints and
deployment of vehicular networks are
different from the default assumptions of
general networks. Exploiting those unique
characteristics, we affiliate each vehicle to a
sector, which is a closed area bounded and
managed by several RSUs.
3. OVERVIEW OF DSR AND AODV
ALGORITHMS
3.1 ADHOC ON-DEMAND
VECTOR (AODV)
DISTANCE
AODV is an improvement of the
Destination-Sequenced Distance Vector
routing protocol (DSDV). DSDV has its
efficiency in creating smaller ad-hoc
networks. Since it requires periodic
advertisement and global dissemination of
connectivity information for correct
operation, it leads to frequent system-wide
broadcasts. Therefore the size of DSDV adhoc networks is strongly limited. When
using DSDV, every mobile node also needs
to maintain a complete list of routes for
each destination within the mobile network.
The advantage of AODV is that it tries to
minimize the number of required broadcasts.
It creates the routes on an on-demand basis,
as opposed to maintain a complete list of
routes for each destination. Therefore, the
authors of AODV classify it as a pure ondemand route acquisition system [7].
3.1.1 Path Discovery Process
When trying to send a message to a
destination node without knowing an active
route to it, the sending node will initiate a
path discovery process. A route request
message (RREQ) is broadcasted to all
neighbors, which continue to broadcast the
message to their neighbors and so on. The
forwarding process is continued until the
destination node is reached or until a
intermediate node knows a route to the
destination that is new enough. To ensure
loop-free and most recent route information,
every node maintains two counters:
sequence number and broadcast_id. The
broadcast_id and the address of the source
node uniquely identify a RREQ message.
broadcast_id is incremented for every
RREQ the source node initiates. An
intermediate node can receive multiple
copies of the same route request broadcast
from various neighbors. In this case – if a
node has already received a RREQ with the
same source address and broadcast_id – it
will discard the packet without broadcasting
it furthermore. When an intermediate node
forwards the RREQ message, it records the
address of the neighbor from which it
received the first copy of the broadcast
packet. This way, the reverse path from all
nodes back to the source is being built
automatically. The RREQ packet contains
two sequence numbers: the source sequence
number and the last destination sequence
number known to the source. The source
sequence number is used to maintain
“freshness” information about the reverse
route to the source while the destination
sequence number specifies what actuality a
route to the destination must have before it
is accepted by the source. [7]
When the route request broadcast reaches
the destination or an intermediate node with
a fresh enough route, the node responds by
sending a unicast route reply packet (RREP)
back to the node from which it received the
RREQ. So actually the packet is sent back
reverse the path built during broadcast
forwarding. A route is considered fresh
enough, if the intermediate node’s route to
the destination node has a destination
sequence number which is equal or greater
than the one contained in the RREQ packet.
As the RREP is sent back to the source,
every intermediate node along this path adds
a forward route entry to its routing table.
The forward route is set active for some time
indicated by a route timer entry. The default
value is 3000 milliseconds, as referred in the
AODV RFC [8]. If the route is no longer
used, it will be deleted after the specified
amount of time. Since the RREP packet is
always sent back the reverse path
established by the routing request, AODV
only supports symmetric links.
Figure 2: AODV Path Discovery Process. [7]
3.1.2 Maintaining Routes
If the source node moves, it is able to send a
new RREQ packet to find a new route to the
destination. If an intermediate node along
the forward path moves, its upstream
neighbor notices the move and sends a link
failure notification message to each of its
active upstream neighbors to inform them of
the erasure of that part of the route (see
Figure 3). The link failure notification is
forwarded as long as the source node is not
reached. After having learned about the
failure, the source node may reinitiate the
route discovery protocol. Optionally a
mobile node may perform local connectivity
maintenance by periodically broadcasting
hello messages.
Figure 3: AODV Route Maintenance by using Link
Failure [7]
3.2 Dynamic Source Routing (DSR) Protocol
One of the most widely referred routing
algorithms is the DSR protocol. DSR, as
with most other reactive routing protocols,
has two basic mechanisms for its operation,
namely; route discovery and route
maintenance.
Route discovery contains both route request
RREQ and route reply RREP messages. In
route discovery phase, when a node wishes
to send a message, it first broadcasts an
RREQ packet to its neighbors. Every node
within the broadcast range adds their node
ID to the RREQ packet and rebroadcasts.
Eventually, one of the broadcast messages
will reach either the destination or a node
that has a recent route to the destination.
Since each node maintains a route cache,
which is a buffer for discovered routes by a
node, it first checks its cache for a route that
matches the requested destination before
rebroadcasting
the
RREQ
packet.
Maintaining a route cache in every node
reduces the overhead generated by a route
discovery phase. If a route is found in the
route cache, then the node will return an
RREP message to the source node rather
than forwarding the RREQ message further
in the network. The first packet that reaches
the destination node will have a complete
route. DSR assumes that the path obtained is
the shortest since it takes into consideration
the first packet to arrive at the destination
node. An RREP packet is sent to the source
that contains the complete route from itself
to the destination. Thus, the source node
knows its route to the destination node and
can initiate routing of data packets. The
source node caches this route in its route
cache. Figure 4, shows a diagrammatic
depiction of the route discovery phase. In
the figure, there are four nodes; A, B, C and
D where nodes A and D are the source and
destination nodes respectively. When A
wants to send data packets (DP), it first
checks its route cache whether it has a direct
route to D. If it does not find a route to D, it
then broadcasts an RREQ message to its
neighbors. When B receives the RREQ
message, it stores the route AB and also
checks if it has a route to D in its route
cache. If it finds a route to D, it sends an
RREP message to A which in turn initiates
the sending of the data packet to D via the
discovered route. If B does not find a route
to D in its cache, it rebroadcasts the RREQ
message to its neighbors. The process
continues until the RREQ message reaches
D, assuming no intermediate node has a
route to D. When the RREQ message gets to
D, it stores routes AB, BC, and CD in its
cache and forwards an RREP message to A
which on reception of the message
commences the sending of data packet
through the discovered route.
Figure 4: Route Discovery Mechanism in DSR [9]
In route maintenance phase, two types of
packets are used, namely; route error
(RERR), and acknowledgements (ACK).
DSR ensures the validity of the existing
routes based on the ACK received from the
neighboring nodes that data packets have
been transmitted to the next hop successfully.
Acknowledgement packets also include
passive acknowledgements as the node
overhears the next hop neighbor forwarding
the packet en route to the destination. An
RERR packet is generated when a node
encounters an obstruction in transmission,
implying that a node has failed to receive an
ACK message. This RERR packet is sent to
the source node in order for it to re-initiate a
new route discovery phase if an alternative
route to the destination cannot be found.
Upon receiving the RERR message, nodes
remove the route entries that use the broken
link from their route caches. An example
route maintenance mechanism is shown in
figure 5. In the figure, when C does not
receive an ACK message from the
destination node, D, it senses an obstruction
along route CD and sends an RERR
message to the source node, A, which seeks
for an alternative route to forward data
packets to D, or rather embarks on a fresh
route discovery process if there are no
alternatives.
Figure 5: Route Maintenance Mechanism in DSR [9]
One distinguishing characteristic of DSR
from other on-demand routing protocols is
the fact that DSR’s cache entries need not
have lifetimes. Once a route is placed in the
route cache, it can remain there until it fails.
However, timeouts, capacity limits and
cache replacement policies have been shown
to improve DSR’s performance. These will
be discussed in details later in this chapter.
Furthermore, DSR nodes have the option of
promiscuous listening, whereby nodes can
receive and process data and control packets
that are not addressed, at the MAC layer, to
themselves. Through promiscuous listening,
nodes can utilize the source routes carried in
both DSR control messages and data packets
to gratuitously learn routing information for
other network destinations. To reduce the
overhead of carrying source routes in data
packets, DSR also allows flow state to be
established in intermediate nodes. This flow
state
effectively
allows
hop-by-hop
forwarding with the same source-based
route control as provided by the source
route. Another distinguishing feature of
DSR is that it does not require any periodic
beaconing (or HELLO message exchanges)
therefore nodes can enter in sleep mode to
conserve their power. This also serves a
considerable amount of bandwidth in the
network.
4. SIMULATION DESCRIPTION AND
DESIGN
The ns-3 simulator is developed and
distributed completely in the C++
programming language, because it better
facilitated the inclusion of C-based
implementation code. The ns-3 also is
architected similar to Linux computers, with
internal interface and application interfaces
such as network to device driver and
sockets. Users of ns-3 are free to write their
simulation scripts as either C++ main ()
programs or Python programs. The ns-3
low-level API is oriented towards the
power-user but more accessible helper APIs
are overlaid on top of the low-level API.
forward the packet to its neighboring nodes.
In such a way, source and destined vehicle
will communicate with each other.
4.1 Simulation Scenarios
4.1.2
In this simulation there are vehicles which
are in the communication range of their
neighboring vehicles but not in the range of
the vehicle next to the neighbor’s vehicle.
The communication has to be performed
between the end vehicles of the scenario.
The routing protocol DSR and AODV is
applied for routing the packets between the
vehicles. All the vehicles in the simulation
having the Wi-Fi facility for sending the
packets to the nodes which are within its
communication range and they are also
assigned the IP addresses with the MAC
addresses and they are in the ad hoc mode.
4.1.1
Vehicle to Vehicle (V2V) Scenario
Figure 6:- V2V Scenario
In V2V Scenario, the nodes are treated as
vehicles. All the nodes are with Wi-Fi
facility and ad hoc mode i.e. in ad hoc
network. Here, the nodes are within the
range of their neighboring nodes. So, nodes
are arranged in such a way in Scenario1.
The distance between the nodes horizontally
and vertically is 800 meters and 25 meters
respectively. The communication range of
each node is 1000 meters.
Here, the end vehicles moving in opposite
directions are the source and destined
vehicles. During communication the source
vehicle will forward the packet to its
neighboring nodes which in return will
Vehicle to Infrastructure (V2I) Scenario
Figure 7:- V2I Scenario
The nodes in red color are vehicles and the
nodes with blue color are fixed
infrastructure called RSUs. Here also the
nodes will communicate with their
neighboring
nodes.
Any
vehicle
communicating with the vehicle moving in
the opposite direction will communicate
through RSUs only. The distance between
the RSUs is 990 meters and vertical distance
between RSUs and vehicle is 25 meters. The
distance between the vehicles horizontally is
800 meters. The communication range of
each node is 1000 meters.
The parameters Jitter and Routing
Overheads are calculated through the Awk
script from the trace file generated after the
simulation. The graph is prepared through
the generated results of the Awk script. Such
Awk script is needed because a research
simulation may generate a trace file with
thousands of lines, becoming difficult to
analyze manually. Due to this, Awk script
can be handy in case someone needs a
metric that is required.
5
RESULTS
6 CONCLUSIONS
This simulation is carried out using NS-3.15
simulator and parameters values are
calculated through Gawk Script. When the
vehicles move with either constant or
different speeds, the DSR works fine in V2I
scenario because the routing overhead is less
in comparison to the V2V scenario. The
AODV works well in V2V scenario as the
number of routing overhead is less than V2I
scenario. The DSR routing algorithms
perform well in V2V over the parameter
jitter because its value is very less than V2I
and AODV performs well under V2I
scenario over the same parameter as its
value is less in V2I. It has also been
observed that AODV has better performance
than DSR in VANET.
5.1 When Vehicles are moving with Constant
Speed
AODV
V2I
V2V
DSR
0
50
100
Graph 1:- Routing Overheads of both Routing
Algorithms in both Scenarios
V2I
AODV
V2V
DSR
0
2000 4000 6000 8000
Graph 2:- Jitter of both Routing Algorithms in both
Scenarios.
5.2 When Vehicles are moving Variable Speed
REFERENCES
[1] Yanlin Peng, Zakhia Abichar and J. Morris Chang,
“Roadside-Aided Routing (RAR) in Vehicular
Networks,” IEEE Communication Society in 2006.
AODV
V2I
[2]
V2V
DSR
0
50
100
150
J.A.G. Garrido, Routing in Wireless Mobile Ad
Hoc Networks: Adaptive Cache Mechanism for
Dynamic Source Routing, Saarbrucken: VDM,
2008.
Graph3:- Routing Overheads of both Routing
Algorithms in both Scenarios
[3]
Y. Ding, C. Wang, and L. Xiao, “A static-node
assisted adaptive routing protocol in vehicular
networks,” in Proc. VANET, New York, Sep.
2007, pp. 59–68.
[4]
C. Lochert, H. Hartenstein, J. Tian, H. Fuyler, D.
Hermann, and M. Mauve, “A routing strategy for
vehicular ad hoc networks in city environments,”
in Proc. IEEE Intell. Veh. Symp, Jun. 2003, pp.
156–161.
AODV
V2I
V2V
DSR
0
2000
4000
Graph 4:- Jitter of both Routing Algorithms in both
Scenarios.
[5] C. Lochert, M. Mauve, H. Fuyler, and H.
Hartenstein, “Geographic routing in city
scenarios,” SIGMOBILE, vol. 9, no. 1, pp. 69–72,
Jan. 2005.
[6] J. Zhao and G. Cao, “VADD: Vehicle-assisted data
delivery in vehicular ad hoc networks,” IEEE
Trans. Veh. Technol., vol. 57, no. 3, pp. 1910–
1922, May 2008.
[7] C. E. Perkins and E. M. Royer, “Ad-hoc on demand
distance vector routing,” in Proceedings of the
2nd IEEE Workshop on Mobile Computing
Systems and Applications (WMCSA’99), vol. 3,
New Orleans, LA, USA, February 1999, pp. 90–
100.
[8] C. Perkins, E. Belding-Royer, and S.Das, “RFC
3561: Ad hoc on-demand distance vector
(AODV) routing,” July 2003, category:
experimental.
[9] D. Johnson, D. Maltz and Y. Hu. “The Dynamic
Source Routing Protocol (DSR) for Mobile AdHoc
Networks for IPv4”, IETF RFC 4728.accessed
April 2007.
Author
Abhay Deep Seth received Bachelor of Engineering
degree in Computer Sceience and Engineering from
RGPV University, India in 2011. He has completed
Master of Engineering from SGSITS, Indore, India in
2014. He is currently working as Asst. Prof. in
Swami Vivekanand College of Engineering Indore.
His research interests include Computer Networks,
Ad-hoc Networks and Theory of Computation.