International Journal of Scientific & Engineering Research, Volume 6, Issue 4, April-2015 29

ISSN 2229-5518

Direction Based Routing in Vehicular Ad-hoc

Netwoks

Saikat Roychowdhury, Sauvik Bal, Prof. Kaushik Banerjee

Abstract— Vehicular networks are one of the most researched topics in computer science and networks in the present time. Most vehicles are equipped with global positioning system (GPS) these days. Vehicular ad-hoc network (VANET) has become an active area of research and development because of the advances in communication technologies. Soon we can expect all vehicles to be fitted with small range wireless devices. The main issues in VANETS are routing related. A lot of VANET researches have focused on areas like routing, broadcasting, quality of service and security. In this paper we introduce an ad-hoc routing method based on direction of the vehicle. Each vehicle and roadside unit (RSU) can work as a router in the vehicular network. As a vehicle moves fast along one of the two lanes in a road, it would be much efficient if routing is done based on the direction of the vehicle. It can cause much less data loss and less overhead for route establishment. We use the RSUs to determine whether the sender and participating nodes along the route are heading in the same direction or not. For communication between vehicles heading in different directions, we use the backbone network and the RSUs.

Index Terms— VANET, Ad hoc routing, Backbone network, Broadcasting, GPS, Roadside Units, Route establishment,

—————————— ——————————

1 INTRODUCTION

vehicular Ad hoc network (VANET)s are one of the most researched topics in communication and networking today because of its possible usage to increase rod safety, driver as- sistance and many more. VANET applications are envisioned to provide the following applications in future:
• Vehicle collision warning
• Security distance warning
• Driver assistance
• Cooperative driving
• Exchange of road information
• Internet access
• Map location
• Automatic parking
• Driverless vehicles
• Nearby parking and gas station information
The communication in vehicular ad hoc networks consists
of two modes of communications, namely Vehicle to roadside
communication (v2r) and vehicle to vehicle (v2v) communica-
tion. Each vehicle in a VANET is fitted with wireless commu-
nication devices (on-board units or OBUs). Each OBU has a specific IP address which may be related to their registration numbers so that other cars on the road may know their ad- dress. For vehicle to roadside communication, fixed road side
units (RSUs) are installed at a certain distance. Each RSU also has a unique IP address which may be stated on it for enabling the cars to know the address. The distance may range from
100 meters to a few Kilo meters depending on the communica- tion range of the RSUs.

————————————————

Saikat Roychowdhury is currently pursuing M.Tech in computer science & engineering in Institute of Engineering & Management, Kolkata, India. E- mail: saikat.rc18@gmail.com

Sauvik Bal is currently pursuing M.Tech in computer science & engineering in

Institute of Engineering & Management, Kolkata, India. E-mail:

sauvikbal@gmail.com

Prof.Kaushik Banerjee is currently working as Faculty member, Computer

Science & Engineering, Institute of Engineering & Management, Kolkata, In- dia. E-mail: kaushik.saltlake@gmail.com

Both cars and RSUs may work as a router or sender/receiver of data. The RSUs may be connected to a backbone network for proper monitoring of the traffic and maintaining the net- work. Vehicle to roadside communications take place between the vehicle and the fixed RSUs. In our proposed routing
Fig. 1. A Typical VANET scenario
method these RSUs play a very important role by specifying
the direction of the vehicle. VANET is not susceptible to com-
mon ad-hoc network problems like energy constraints or lim-
ited capacity of the transmitter. The cars’ battery can provide
all the power needed by the OBUs to communicate for a long
time and an antenna can also be fitted in a car. However

IJSER © 2015 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 4, April-2015 30

ISSN 2229-5518

VANETs have their own set of problems. The key issues in VANET are high velocity of participating nodes, random to- pology changes, route establishment and maintenance, Securi- ty issues etc. In this paper we propose a routing process that causes less overhead in route establishment and easier route maintenance.
Mobile Ad Hoc networks are infrastructureless networks. VANET is mobile Ad hoc network with high velocity nodes. The main goals of an Ad hoc routing protocol are 1.route dis- covery 2.packet forwarding 3.route maintenance. There are different types of Ad hoc routing.

2 TYPES OF AD HOC NETWORK

2.1 Table-driven (proactive) routing

In This type of protocols each router maintains a routing table which has the lists of destinations and their routes by periodi- cally distributing routing tables throughout the network. Ex- amples of proactive algorithms are Optimized Link State Routing Protocol (OLSR) and Destination Sequence Distance Vector (DSDV).

2.2 On-demand (reactive) routing

This type of protocol finds a route only when a source needs to send packets to a destination. Examples of on-demand algo- rithms are Ad hoc On-demand Distance Vector (AODV) and Dynamic Source Routing (DSR).

2.3 Hybrid (both proactive and reactive) routing

This type of protocol combines the advantages of proactive and reactive routing. The routing is initiated with some proac- tive routes and then serves the demands from additional nodes through reactive routing. The choice of the method is predetermined for various cases. Example of hybrid algo- rithms is ZRP (Zone Routing Protocol).
There is another form of hybrid routing where the choice of routing depends on the hierarchical level at which a node re- sides. Usually it is proactive at higher level and reactive at lower levels. Examples of hierarchical routing algorithms are CBRP (Cluster Based Routing Protocol) and FSR (Fisheye State Routing protocol).
We can consider only reactive routing protocols for VANETs because of the high velocity of the participating nodes. Any kind of Table driven routing protocol is useless here as the routing tables will have to be updated too fre- quently causing huge overhead. So we discuss in brief the message types available in the much used on-demand routing protocols first. We use some of these messages in our routing process.
The message set of DSR consists of Route Request (RREQ), Route Reply (RREP) and Route Error (RERR) packets. The message set in AODV has HELLO messages in addition to those three message types used in DSR. RREQ packets are sent to all nearby nodes by broadcasting from the source node while initiating a routing process. These packets are broad- casted by intermediate nodes till it reaches the destination node. Destination replies with RREP packets in the reverse path of the one which is contained in the first RREQ packet received. RERR messages are used to indicate route failure
when a node breaks down or can’t forward packets for some reason. HELLO packets are used in AODV to check whether the adjacent nodes of the sender are still actively connected to the sender or not. HELLO packets are sent periodically and they can propagate the distance of only one node.

4 PROPOSED ROUTING METHOD

We consider the routing process of the most used reactive protocols and modify it to make it more suitable for VANET environments. RSU to RSU communication can be done using any wireless networking protocol since they
are stationary units. It can also be accomplished using the
backbone network. Vehicle to RSU communication is also not much complicated since the receiver is stationary. So our main concern in this paper is vehicle to vehicle communication. We consider that the roadside unit (RSU)s are installed on both sides of the road at regular distance such that a participating car can always connect with the nearest RSU on its side of the lane. Each RSU has a specific id which indicates on which direction of the road it is placed. That is, if we consider a highway with two lanes,
all the RSUs on lane 1 shall have one specific id and all the
RSUs on lane 2 have a different id. These RSUs, using this id, will make sure that a car trying to establish a route to a car on its lane never includes a car going to the opposite direction in its route. If that happens by the time the RREP is generated, the car from the opposite lane will most
likely be out of the range of the source node causing a break in the route. This may even happen every time a source node generates a RREQ if the two lanes have a very small gap separating them. If a car wants to communicate with cars going in the opposite direction it must route the packets through the RSUs and Backbone network. The information of the direction in which a car is heading
could be fetched from the GPS too. But GPS connections may not be available inside tunnels a breakdown in a stationary RSU can be addressed much more easily than a breakdown in the satellite oriented GPS service. All the RSUs are connected to a backbone network to ensure smoother and safer traffic monitoring and assistance and also for maintaining the network. This is a best effort procedure and does not guarantee delivery of packets. In our process a car (node) initiates communication with the nearest RSU sending a message requesting for the RSU id of that lane and stores the first response whenever it takes a turn or changes lane. The cars also communicate with RSUs at regular interval sending a HELLO message along with the RSU id and its own address to check if the stored RSU id has changed and to keep the network updated on its location. This may happen if the first RSU of a lane
breaks down and the RSU from the opposite side responds

IJSER © 2015 http://www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 4, April-2015 31

ISSN 2229-5518


first. This can be detected by comparing the RSU id received in response to the next periodic HELLO message and the one stored previously. In such cases the correct RSU id is obtained from the next RSUs on that side. The RSUs on the same side of the road are much closer to a car than the ones on the other lanes for obvious reasons. So all cars have the unique id of the RSUs situated at their side of the road at all time. In VANETS the need of sending or receiving continuous streams of data is highly unlikely. Mostly we need to send or receive a data packet containing certain information that we need to inform or ask something from the nearby cars. So in our procedure we do not maintain a routing table. Scenario one- Sending packets to a car heading in the same direction, that is in the same lane:
• In our method a route discovery is initiated only when a node needs to communicate to other cars or RSUs.
• When a car needs to communicate with a car heading in the same direction, whether in front of it or behind, the On Board Unit (OBU) broadcasts the RREQ packets to all adja- cent nodes.
• The RREQ packets contain the unique ID of the RSUs on that side of the road, the address of the source OBU, ad- dress of the destination OBU and a request ID.
• When a node receives a RREQ it checks if the request id already exists in its router cache. If it does then it is a dupli- cate request. So it discards the packet to avoid looping. A constraint can also be set that allows rebroadcasting of the
1RREQ packets a certain number of times depending on the usual traffic conditions of a city.
• It also checks if the RSU ID in the RREQ packet is same as the one stored in the node itself or not. If not then the re- quest is coming from a car heading in a different direction, so it discards the packet.
• Otherwise it stores the request ID in its cache and for- wards the RREQ to its neighboring nodes after appending its own address to the RREQ.
• The cache is refreshed periodically to remove old route request records.
• When a RREQ reaches the destination it replies with a RREP

reversing the route in RREQ packet. Fig. 3. Sequence flow diagram of the Routing process for scenario one
• If a destination receives the same RREQ more than once it may send a duplicate RREP in the new route assuming that the first RREP might be lost because of reasons like car break- down or nodes changing the path. There is a predetermined constraint on how many duplicate RREPs may be sent depending on traffic conditions.
• As the reply reaches the source the data packets are sent with the entire route included in its header. So this is a source based routing.

• To multicast a data packet the source initiates multiple route requests for each of the receivers.

Fig. 2. Depiction of accepting or rejecting RREQ based on contained

RSU ID

SER © 2015

/www.ijser.org

International Journal of Scientific & Engineering Research, Volume 6, Issue 4, April-2015 32

ISSN 2229-5518

TW O

5. SCENARIO TWO- COMMUNICATING WITH A CAR HEADING TOWARDS THE OPPOSITE DIRECTION

• The source node sends the data packet along with the ad- dress of the destination node to the nearest RSU.
• The RSU forwards the packet to the backbone network.
• At the backbone network the last known location of the
destination node is checked by monitoring the last HELLO
message it had sent to its nearest RSU.
• The message is forwarded to that RSU and the next few
RSUs assuming that the car might have moved ahead. The
number of RSUs that the message has to be forwarded de-
pends on the distance between the RSUs.
• The message is forwarded to the car in reply to the next
HELLO message it sends to its nearest RSU.
• The node may receive duplicate messages from each of
the RSUs that received the message from the backbone. To
prevent it the backbone may discard the messages in rest of the RSUs after the first one receives the HELLO packet and forwards the message to the destination.
• If the source wants to broadcast it to all the cars in the opposite lane then the backbone may forward the message to all the RSUs on that lane so that they can forward it to all nearby cars.

FIG. 4. SEQUENCE FLOW DIAGRAM OF THE ROUTING PROCESS FOR SCENARIO

4 CONCLUSION

The proposed method has some issues. The addresses of the nodes have to be assigned according to their registration number or some special rule so that other vehicles on the road can know its address. The backbone network also needs to be monitored properly. This routing procedure would however be more efficient than other Ad Hoc protocols in a VANET scenario.

ACKNOWLEDGMENT

The authors wish to thank all the faculty and administrative members of Institute Of Engineering and Management, Kolka- ta.

REFERENCES

[1] Wireless and mobile networks : concepts and protocols- Sunilkumar

S.Manvi

[2] Vehicular Ad hoc networks : Status, Results and challenges- Sherali

Zeadally, Ray Hunt, Yuh-Shyan Chen, Angela Irwin, Aamir Hassan. [3] Routing in vehicular networks : feasibility, security and modeling

issues-Ioannis Broustis and Michalis Faloutsos.

[4] Vehicular Ad Hoc network : A new challenge for localization based systems- Azzedine Boukerche, Horacio A.B.F Oliveira, Eduardo F Nakamura.

IJSER © 2015 http://www.ijser.org