A routing protocol for Urban Vehicular Ad Hoc ... - CyberLeninka

2 downloads 0 Views 6MB Size Report
Berhampur-761003, India. bParallel and Distributed Computing Lab, ...... a research paper in Natural Computing, Springer. Email: rashmiranjan.cse@pmec.ac.in ...
Accepted Manuscript A routing protocol for Urban Vehicular Ad Hoc Networks to support non-safety applications S.K. Bhoi, P.M. Khilar, M. Singh, R.R. Sahoo, R.R. Swain PII:

S2352-8648(17)30122-0

DOI:

10.1016/j.dcan.2017.08.003

Reference:

DCAN 97

To appear in:

Digital Communications and Networks

Received Date: 10 April 2017 Revised Date:

12 July 2017

Accepted Date: 9 August 2017

Please cite this article as: S.K. Bhoi, P.M. Khilar, M. Singh, R.R. Sahoo, R.R. Swain, A routing protocol for Urban Vehicular Ad Hoc Networks to support non-safety applications, Digital Communications and Networks (2017), doi: 10.1016/j.dcan.2017.08.003. This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

Digital Communications and Networks(DCN)

journal homepage: www.elsevier.com/locate/dcan

RI PT

A Routing Protocol for Urban Vehicular Ad Hoc Networks to Support Non-Safety Applications

SC

S. K. Bhoi∗a , P. M. Khilarb , M. Singhc , R. R. Sahooa , R. R. Swainb a Department

of Computer Science and Engineering, Parala Maharaja Engineering College (Govt.), Berhampur-761003, India Parallel and Distributed Computing Lab, Department of Computer Science and Engineering, National Institute of Technology, Rourkela-769008, India c Department of Computer Science and Engineering, VIT University, Bhopal-466114, India

M AN U

b

Abstract

c 2015 Published by Elsevier Ltd.

TE

D

Urban Vehicular Ad Hoc Network (UVANET) provides non-safety applications like media sharing, Internet service, file transfer, gaming, and so on. To provide better services to the users in UVANET, routing plays an important role. In this paper, a novel routing protocol is proposed for UVANET to support the non-safety applications. We have considered a non-safety application where the drivers and passengers of different parking lots can play multi-player games with each other. To play the games smoothly, the game data should reach the destination in a minimum time. Simulation results show that, when the density of the vehicles in the city area is high, then the proposed protocol fulfills the end-to-end delay tolerance of 100 ms. At last, an experimental work is performed to validate the proposed routing protocol by running a simple puzzle game in a UVANET prototype designed in an indoor laboratory environment and outdoor environment.

1. Introduction

EP

KEYWORDS: UVANET, Non-Safety Applications, Routing, Gaming, Slow-Paced Games

AC C

UVANET is an advanced wireless communication network to provide safety and non-safety applications to the passengers and drivers [1, 2, 3, 4, 5, 6, 7]. Safety applications mainly provide safety systems, traffic management, and maintenance. Non-safety or comfort applications provide media downloading and uploading, file transfer, mailing, gaming for back seat passengers, Internet access, location information, Region of Interest (ROI) information, and simple message transfer (reserving a seat in a coffee shop) [8]. In UVANET, a vehicle itself becomes a sender, receiver, and router. Vehicles transfer valuable information using vehicle to vehicle (V2V) and vehicle to infrastructure (V2I) communication. UVANET uses ∗ Corresponding

author (email: [email protected]).

Dedicated Short Range Communication (DSRC) standard for data communication, which is based on IEEE 802.11 technology. It is now advancing to Wireless Access in Vehicular Environment (WAVE) standard, which is based on IEEE 802.11p [9]. Routing in UVANET is a challenging task due to high speed of vehicles on the roads [10]. This leads to link disruption problem, where a vehicle is out of the communication range, and the link gets disconnected. Due to lower density of vehicles, routing also suffers from communication gap problem, where a vehicle is unable to forward the data to the next vehicle. If the density is high, that does not mean the vehicles are connected to each other. Therefore, the data should be transmitted in such a path where there is high density of vehicles and less link disruption problem between the vehicles. Recent advancement in multimedia over UVANET

ACCEPTED MANUSCRIPT

[11]. This is a new application where the players of different parking lots can play multi-player games using UVANET. The main contributions in this paper are stated as follows:

RI PT

1. A novel routing protocol is proposed for UVANET to support the non safety-applications. In this paper, we have considered a scenario where the drivers and passengers of different parking lots can play multi-player games with each other, where the game data is transfered using the proposed routing protocol. 2. The proposed routing protocol approximates the number of communication gaps generated between the junctions, before forwarding the data on a path. It fulfills the end-to-end delay tolerance of 100 ms for successful execution of the slow-paced games. 3. Simulation works are performed to evaluate the performance of the proposed routing protocol in terms of end-to-end delay, packet delivery ratio, number of hops, and number of gaps encountered. 4. At last, an experimental work is performed to validate the proposed routing protocol by running a simple puzzle game in a UVANET prototype designed in an indoor laboratory environment and outdoor environment.

EP

TE

D

M AN U

allow the drivers and passengers to transfer the data (ex. live video, audio, and text messages) to the destination in a minimum time. Many routing protocols are proposed for UVANET to support the non-safety applications. However, these protocols are unable to estimate the number of communication gaps between the vehicles. Hence, the end-to-end delay to send the data from the source vehicle to the destination increases. If the density of vehicles is high on the roads, then all the routing protocols perform similar. But, there is no guarantee that if there is high density then the vehicles are connected. The existing routing protocols lack knowledge about the link breakages between the vehicles, and forward the data through the high density path. Hence, it increases the end-to-end delay. In UVANET, to the best of our knowledge no such non-safety application is proposed where the vehicles of different parking lots can play multi-player games with each other. This is possible, if an efficient routing protocol is proposed which can satisfy the end-to-end delay tolerance of 100 ms [11]. In UVANET, it is difficult to play high bandwidth fastpaced games (ex. NFS, Counter Strike, FIFA, etc.) because it requires full connectivity between the vehicles [11]. However, due to high speed of vehicles in the network, frequent disconnections occur in the network, which stops the successful execution of the game. The game stops due to unavailability of data (player actions, game state, high resolution images, sounds, text and voice messages, coordinate information, etc.) at the current time. However, low bandwidth slow-paced games (ex. Chess, Cards, Puzzles, etc.) are possible to play in UVANET environment because players take some time (seconds) to take the action, and the game data size is low. So, a player can wait for some seconds (carrying time) if a communication gap occurs between the vehicles. In this paper, to evaluate the performance of the proposed routing protocol, we have run a slow-paced simple puzzle game in a prototype, and send the game data using the proposed routing protocol.

Name of the first author, et al.

SC

2

AC C

In this paper, a novel routing protocol is proposed to support the non-safety applications (gaming). For this, we have considered a non-safety application where the vehicles spend hours in the parking lots, where the drivers and the passengers available in the vehicles get bored. They use AM/FM radio, CD/DVD players, TVs, media players, mobile phones, laptops, etc. to get entertainment [11, 12, 13, 14]. In-vehicle gaming facility is nonexistent in UVANET [11]. Drivers and passengers play multi-player games on laptops and mobile phones using Internet, which is costly. Therefore, the games can be played free of cost using UVANET. Players of different parking lots can join with a game server in some other parking lot to play multi-player games. To make the non-safety application possible, the game data should reach the destination with an end-to-end delay tolerance of 100 ms

The rest of the paper is organized as follows. Section 2 presents the related works. Section 3 describes about the proposed routing protocol. Section 4 presents the simulation and results. Section 5 presents the experimental tests and results. Section 6 presents the conclusion of the proposed work. 2. Related Works Many routing protocols are proposed for UVANET to provide efficient data delivery to the destination [15, 16, 17, 18, 19, 20, 21, 22]. Topology based routing protocols are difficult to implement in UVANET because of frequent topology change. Therefore, UVANET prefers position based routing protocols, where path maintenance is not required, only destination position and neighbor position information is required to send the data. Geographic Source Routing (GSR) protocol is proposed to send the data effectively to the destination in a shortest path [23]. Greedy Perimeter Stateless Routing (GPSR) protocol sends the data in a shortest path by forwarding the data to the vehicles nearer to the destination [24]. It uses perimeter mode to recover from the local optimum problem. Greedy Perimeter Coordinator Routing (GPCR) protocol sends the data in a shortest path using Dijkstra algorithm. It uses the coordinator node to select the next path for data forwarding [25]. Anchor-Based Street and Traffic Aware

ACCEPTED MANUSCRIPT

Paper Title (The title should be descriptive, not full sentence)

SC

RI PT

The faulty vehicles should be detected in a network as they affects the end-to-end delay and packet delivery ratio. A RVCloud routing protocol is proposed for UVANET to send the data to the destination in a minimum time using cloud computing technology [39]. However, this method is costly as the Internet service is used. Lee et al. [40] proposed an efficient relay method for UVANET to send the data to the destination in a minimum time. However, this method lacks knowledge about the communication gaps generated between the junctions, and hence end-to-end delay increases. Lee et al. [41] designed an in-vehicle sensor database management system to store the sensed data received from the vehicles. It sends the data to the destination using position based routing protocol. These are some of the routing protocols proposed by the researchers to send the data to the destination in a minimum time. Bhoi et al. [36] proposed a path selection based routing protocol for UVANET where many types of communications are shown such as ground vehicle to ground vehicle (GV2GV), ground vehicle to flyover vehicle (GV2FV/FV2GV), and flyover vehicle to flyover vehicle (FV2FV). This paper presents a novel routing protocol for UVANET to support the non-safety applications. In this paper, a non-safety application is considered where the players of the different parking lots can join a game server and play the multi-player games. To support this application, a routing protocol is proposed which transfers the game data to the destination in minimum time. It satisfy the end-to-end delay tolerance of 100 ms to run the multi-player games smoothly.

AC C

EP

TE

D

M AN U

Routing (A-STAR) protocol sends the data through the major streets [26]. Major streets have high density of vehicles. Greedy Traffic-Aware Routing (GyTAR) protocol intelligently forward the data to the destination using the traffic conditions ahead [27]. A Cell Data Packet (CDP) is used to transfer the density information from one junction to other through the vehicles. When a vehicle with the data reached a junction, it calculates a weight for each neighboring junction. Then it forward the data in that direction which has a maximum weight. Intersection Based Routing (IBR) protocol sends the data in a path which takes minimum packet forwarding delay [28]. Diagonal Intersection Based Routing (DIR) protocol sends the data to the destination by forwarding the data through the diagonal junctions [29]. The data is forwarded to the diagonal junction in that path which takes minimum packet forwarding delay. Peripheral node-based GEographic DIstance Routing (P-GEDIR) protocol sends the data to the destination by using the vehicles which lies on the periphery of the communication range [30]. Intersection-Based Geographical Routing Protocol (IGRP) sends the data to the Internet gateway through the junctions. The path is selected on the basis of packet forwarding delay, Quality of Service (QoS), bandwidth, link connectivity and error rate [31]. Toutouh et al. [32] proposed an optimized link state routing technique for UVANET to provide efficient data delivery to the destination. Sahu et al. [33] proposed a backbone assisted hop greedy routing technique to forward the data to the destination with minimum intersection nodes. Static intersection nodes are set at the intersection to forward the data in the next path. Al-Rabayah et al. [34] proposed a hybrid routing protocol for UVANET to reduce the routing overhead and increase the scalability. It uses reactive routing and location based routing to forward the data effectively to the desination. Taleb et al. [35] proposed a stable routing protocol by grouping the vehicles according to their velocity vectors. This reduces the link failure between the vehicles. These are some of the routing protocols used in UVANET to transfer the data to the destination in a minimum time. A path selection based routing protocol is proposed for UVANET to transfer the data through the flyovers [36]. This work mainly focuses on ground vehicle to ground vehicle communication, ground vehicle to flyover vehicle communication, and flyover vehicle to flyover vehicle communication. This protocol sends the data to the destination in a minimum time. A road selection based routing protocols are proposed where the guarding nodes at the junctions control the communication [37]. If there are n number of roads connected to the junction then there are n number of guarding nodes. The guarding nodes mainly transfer the data in an optimal path. A self soft-fault detection based routing protocol is proposed to send the data to the destination in a minimum time through the fault free vehicles [38].

3

3. Proposed Routing Protocol 3.1. System Model The city is considered as a graph G(V, E), where vertex V and edge E signifies a junction and a road respectively. City consists of roads, junctions, Road Side Units (RSUs), vehicles, and parking lots. Vehicle transmits beacon messages at a particular interval of time. This message contains information such as identity, location, speed, and direction. Vehicle On Board Unit (OBU) consists of GPS module to find its own location. RSUs are set at the junction to find the next data forwarding path. In this model, RSU stores the beacon information of the vehicles which pass through the junction. RSU stores the information of a vehicle for a particular time and then updates the information when a new vehicle arrives. RSU contains the maps and the information of other RSUs (locations). The passengers and drivers available in the vehicles at the parking lot take part in the gaming process (if they want to play). The Players (P1 , P2 , ..., Pk ) of different parking lots can join a game server G server at some other parking lot, where k signifies the number of players. The Game server has a maximum player limit.

ACCEPTED MANUSCRIPT

4

Name of the first author, et al. Communication Range

The next section describes about the proposed routing protocol.

Veh_2

3.2. Functionality

Veh_3

RSU2

Fig. 2: Next hop selection.

SC

Fig. 2 shows the selection of the next hop Hnext based on the Euclidean distance Ed. From Fig. 2, it is observed that Veh1 selects Veh3 as the next best hop. The next hop is selected by projecting a point Veh′3 on the line Veh1 RS U2 . The line Veh3 Veh′3 is perpendicular to line Veh1 RS U2 . The vehicle which has a minimum Ed is selected as the next best hop in the range. According to Fig. 2, the next best hop Hnext is selected as follows:

D

M AN U

The game server G server at parking location PLoc2 starts a multi-player game and broadcast a message containing the server information, game information, and parking location information. The message is broadcast to the nearest parking lots. When a driver or passenger (player Pk ) at other parking location PLoc1 receives the broadcast message, it starts the same multi-player game and exchange information with the G server to smoothly play the game. The information includes player actions, game state, images, sounds, text and voice messages, coordinate information, etc. The player Pk updates the server by sending the action information. G server stores the global information and determines the state of the game. It then sends the results to the players connected to it. To perform effective data delivery, a routing protocol is proposed, which sends the data to the destination through the vehicles. This proposed method reduces the traffic because the messages are not flooded and the information is exchanged only between the players Pk and G server through the vehicles using unicast routing. Fig. 1 shows the information exchange between Pk at PLoc1 and G server at PLoc2 .

RI PT

RSU

J3

TE

J4

RSU3

PLoc2

Game Server

RSU2

EP

Vehicle RSU1

J1

(1)

Vehnearer = Hnext

(2)

2

3

This process continues until data reaches junction J1 . When a vehicle with the data reaches a junction, it handovers the data to the RSU (RS U1 ). RS U1 contains all information about the vehicles moving between the junctions. RS U1 then calculates a weight for each path connected to the junction J1 . The Ptweight is calculated using the following parameters discussed below. Firstly, RS U1 finds the positions of the vehicles between the junctions using the formula:

J2

PLoc1

AC C

RS U2 RS U2 Hnext = min(EdVeh ′ , EdVeh′ )

Dcover = (tcurrent − tbeacon ) × v,

(3)

Player

Fig. 1: Gaming in parking lots using UVANET.

After receiving the message from G server , Pk starts sending information to G server . The data is transmitted in a path (road joining two junctions) which has a minimum path weight Ptweight . Ptweight signifies a weight calculated for a path to find the next path that takes minimum packet forwarding delay. The path with the minimum Ptweight has high connectivity between the vehicles. According to Fig. 1, Pk sends the data to the next vehicle Vehnearer in the communication range. Vehnearer is the vehicle in the communication range which is nearer to the junction J1 .

where Dcover is the distance covered by a vehicle after the last beacon, tcurrent is the current time, tbeacon is the time when the last beacon is received by the RSU (RS U1 ), and v is the speed of the vehicle. RS U1 finds the positions for those vehicles which moves between tcurrent and (tcurrent − tcover ), where tcover is the maximum time a vehicle takes to cover the distance between the junctions, if it moves with the average lowest speed (vlower ). After finding the positions, RS U1 consider those vehicles whose positions lie between the two junctions. RS U1 then finds a logical path of data transmission Pttr using the positions and range of the vehicles. RS U1 finds Vehnearest vehicle by using the positions of the vehicles. Then, this process continues until RS U2 is reached. After generating the Pttr from RS U1 to RS U2 , RS U1 calculates the expected

ACCEPTED MANUSCRIPT

Paper Title (The title should be descriptive, not full sentence)

Algorithm 1 Path weight calculation 1: for J start to Jend do ⊲ J start denotes the first junction to receive response message if J , Jend then for each path connected to the current junction Jcurrent do RSU finds the positions of the vehicles moving between tcurrent and (tcurrent − tcover ) 5: Dcover is calculated by: (tcurrent − tbeacon ) × v 6: Position is generated using Dcover 7: if Dcover > D(Jcurrent ,Jnext ) then 8: invalid position 9: else 10: valid position 11: end if 12: RSU generates a logical path Pttr 13: RSU finds D f p and Dci 14: RSU finds texp(Pttr ) 15: RSU finds g, S Ptnext , and S Ptcurrent next 16: RSU finds Ptweighti by: w1 × texp(Pttr ) + w2 × S SPtPtcurrent + w3 × g 17: end for 18: Pt selected = min(Ptweight1 , Ptweight2 , ..., Ptweighti ) 19: Forward the data on the selected path 20: for Jcurrent to Jnext do 21: if Jnext is reached then 22: Handover the data to the RSU 23: else 24: Find the Vehnearest vehicle 25: if Vehnext vehicle is available then 26: Send data 27: else 28: Carry data 29: Send data ⊲ when a forward positioning vehicle is encountered or junction is reached 30: end if 31: end if 32: end for 33: end if 34: end for

2: 3: 4:

AC C

EP

TE

D

M AN U

p=1

RI PT

Pn−1−g

g n−1 X D f p + gR X + trest j + tci , c j=1 i=1 (4) M where (n−1)l denotes the transmission delay, r Pn−1−g P p=1 D f p +gR denotes the propagation delay, n−1 j=1 trest j c Pg denotes the processing and queuing delay, and i=1 tci denotes the data carrying delay which signifies the delay a vehicle takes to carry the data until a new vehicle arrives. Communication gap between the two vehicles VehA and VehB is defined as the distance after the radio range of VehA to the position of VehB . If gap occurs and the forward vehicle is moving at high speed than the carrying delay is estimated by the time it carries the data until a new vehicle arrives in the forward position or it reaches near the junction. If the forward vehicle is moving in slow speed than the carrying delay is estimated by the time it carries the data until a new vehicle arrives in the forward position or it reaches near the junction. n is the number of vehicles or RSUs in Pttr , l M is the message length, and r is the data rate. D f p is the forwarding distance between the vehicles to forward the data in Pttr , c is propagation speed, p is the number of forwarding distances, and g × R is the number of communication gaps g multiplied with the communication range R, which signifies the forwarding distance established after carrying the data. i denotes the number of times the data is carried when a gap is encountered. j denotes the number of rest delays. Then RS U1 next calculates the ratio SSPtPtcurrent , where S Ptnext denotes the shortest path from the next junction to the parking location PLoc2 and S Ptcurrent denotes the shortest path from the current junction to the parking location PLoc2 . The shortest paths are calculated using next Dijkstra algorithm. SSPtPtcurrent signifies the closeness of next is the PLoc2 from RS U1 . So, if the value of SSPtPtcurrent less, then the destination is nearer to the RS U. After collecting the required information such as texp(Pttr ) , S Ptnext S Ptcurrent , and g, RS U 1 calculates Ptweight for a path as follows:

texp(Pttr )

(n − 1)l M = + r

vehicles. To play the games smoothly, player Pk continuously transmits data to G server using the proposed routing protocol. G server also uses the same method to send the data to the players connected to it. The pseudocode for path weight calculation is shown in Algorithm 1.

SC

delay texp(Pttr ) on Pttr using the formula:

5

Ptweight = w1 × texp(Pttr ) + w2 ×

S Ptnext + w3 × g, (5) S Ptcurrent

Pt selected = min(Ptweight1 , Ptweight2 , ..., Ptweighti )

(6)

where summation of the weights w1 , w2 , and w3 is

3.3. Analysis of proposed Routing Protocol The proposed routing protocol is evaluated using the lemmas presented as follows: Lemma 1. If the number of path segment increases then the data forwarding delay increases. Proof. Let the path Pt1 has u number of path segments and the path Pt2 has v number of path segments, where u > v. Path segment is a path connecting the two junctions. Let texp1 and texp2 are the total delays in path Pt1 and Pt2 respectively to send the data from VehS to VehD . From Eq. (4), the delays texp1 and texp2 are represented as follows:

1. All the parameters used to calculate the path weight should be minimum to send the data quickly to the next junction. RS U1 calculates two path weights and transmits the data to junction J2 , which has a minimum path weight according to Fig. 1. This process continues until the data reaches the last junction (J2 ). After data reaches at J2 , the data is sent to G server using multihop communication by finding the Vehnearest

texp1

(n − 1)l M = + r

Pn−1−g p=1

D fp + g × R c

+

n−1 X

trest j +

j=1

g X

tci

k=1

(7)

texp2

(n′ − 1)l M = + r

Pn′ −1−g′ p=1

D f p + g′ × R c

+

′ nX −1



trest j +

g X k=1

j=1

(8)

tci

ACCEPTED MANUSCRIPT

Lemma 2. If the number of communication gaps increases then the data forwarding delay in the path segment increases. Proof. Let there are g number of communication gaps in a path segment Ptseg1 and g′ number of communication gaps in a path segment Ptseg2 , where g > g′ . According to the protocol, the data is sent on a path with less number of communication gaps. Let the path segments Ptseg1 and Ptseg2 are represented as follows: communication gap

(9)

communication gap

−−−−−−−−−−−−−−→ Veh3 → RS U2

communication gap

Ptseg2 = RS U3 → Veh4 → Veh5 −−−−−−−−−−−−−−→ Veh6 → RS U4 (10)

D

According to the protocol, if the communication gaps are approximated earlier then the delay can be reduced. Therefore, the packet forwarding delay for Ptseg1 and Ptseg2 are represented as: carry and f orward

z }| { = texp(RS U1 ,Veh1 ) + tc1 + texp(Veh1 ,Veh2 ) carry and f orward

TE

texpPtseg1

S Ptnext +w3 ×g S Ptcurrent (13) S Ptnext +w3 ×g′ Ptweight2 = w1 ×texp(RS U1 ,RS U2 ) +w2 × S Ptcurrent (14) If the number of gaps is more, then there is a high packet forwarding delay. Hence, from Eq. (13) and Eq. (14), Ptweight1 > Ptweight2 , and path Pt2 is selected as the next path for data forwarding. Ptweight1 = w1 ×texp(RS U1 ,RS U2 ) +w2 ×

Lemma 4. The time complexity for the proposed routing protocol is O(n), where n is the number of vehicles and RSUs used to send the data to the destination.

M AN U

Ptseg1 = RS U1 → Veh1 −−−−−−−−−−−−−−→ Veh2

approximated parameters such as delay from one junction to other, number of gaps, and closeness to the destination should be minimum. Therefore, according to the model, Ptweight is calculated as w1 ×texp(RS U1 ,RS U2 ) + next +w3 ×g. If a path Ptweight1 has g number of w2 × SSPtPtcurrent gaps and path Ptweight2 has g′ number of gaps, where g > g′ then Ptweight1 and Ptweight1 are represented as follows:

RI PT

As u > v, path Pt1 contains u + 1 number of junctions and path Pt2 contains v + 1 number of junctions. This signifies that if the number of junctions increases, then the distance increases. If the path distance increases, number of vehicles and RSUs used in the path also increases. Hence, the packet forwarding delay increases and texp1 > texp2 .

Name of the first author, et al.

SC

6

(11)

EP

z }| { +tc2 + texp(Veh2 ,Veh3 ) + texp(Veh3 ,RS U2 )

4. Simulation and Results

texpPtseg2 = texp(RS U3 ,Veh1 ) + texp(Veh1 ,Veh2 ) + carry and f orward

Proof. The proposed routing protocol selects the Vehnearest vehicle from the neighbors and sends the data. When a vehicle with the data reaches a junction, it handovers the data to the RSU. Then RSU selects a Vehnearest vehicle in that path which has a minimum Ptweight . Hence, in each iteration, a vehicle or RSU receives data from the preceding node and transfers the data, except the source and the destination. Source sends the data through the intermediate nodes and destination receives the data. This process continues until the destination is reached. Therefore, n number of vehicles and RSUs are used to send the data to the destination, and hence the time complexity is O(n).

(12)

AC C

z }| { tc3 + texp(Veh2 ,Veh3 ) + texp(Veh3 ,RS U4 ) , where tc1 and tc2 denote the carrying time by the sufferer vehicles Veh1 and Veh2 respectively, in Eq. (11). Ptseg1 has higher number of communication gaps than Ptseg2 , which signifies that Ptseg1 uses more number of carry and forward mechanisms to forward the data. Hence, from Eq. (11) and Eq. (12), texpPtseg1 > texpPtseg2 . Therefore, existence of communication gaps increases the packet forwarding delay. Lemma 3. Let a junction is connected with two paths Pt1 and Pt2 . If a path is selected by calculating the path weights Ptweight1 and Ptweight2 for the the paths Pt1 and Pt2 respectively, then the packet forwarding delay reduces. Proof. Path weight shows the ability of a path to send the data to the next junction in a minimum time. The

The performance of the proposed routing protocol is evaluated using MATLAB R2015a. MATLAB provides a numerical computing environment to solve problems by implementing the algorithms in an easy way. The simulation is performed on an Intel Core i73770 CPU with 4 GB RAM and Microsoft Windows 7 platform. The proposed routing protocol is compared with GyTAR, A-STAR, P-GEDIR, and GSR routing protocols. GyTAR protocol is mainly proposed for UVANET scenario to send the data to the destination in a minimum time. It calculates a score for each path connected to the junction and forward the data in that path which has a maximum score. A-STAR is mainly proposed for city scenarios where it mainly consider the dense roads (major streets) for data forwarding, and set least weights for the roads according to the density. P-GEDIR is proposed for city as well as highway scenarios, where the data forwarding is performed by sending the data to the border nodes. GSR

ACCEPTED MANUSCRIPT

Paper Title (The title should be descriptive, not full sentence) routing protocol uses the shortest path in the city scenario to send the data to the destination in a minimum time. The performance metrics for the simulation are:

180 w1=0.2, w2=0.2, w3=0.6 w1=0.2, w2=0.6, w3=0.2 w1=0.6, w2=0.2, w3=0.2 w1=0.333, w2=0.333, w3=0.334

160

140 0.05

w1=0.333, w2=0.333, w3=0.334

120

w1=0.2, w2=0.6, w3=0.2

0.045

w1=0.2, w2=0.2, w3=0.6 w1=0.6, w2=0.2, w3=0.2

End-to-End Delay (seconds)

100

80

60

0.04

0.035

0.03

RI PT

End-to-End Delay (seconds)

1. End-to-End Delay: It shows the time taken to send the data from the source to the destination. 2. Number of Gaps: It shows the number of communication gaps encountered during the data transfer from the source to the destination. 3. Number of Hops: It shows the total number of hops (vehicles and RSUs) used to forward the data to the destination. 4. Packet Delivery Ratio: It is the ratio of the number of packets received at the destination to the number of packets sent from the source.

7

0.025

0.02

0.015

40

0.01 30

35

40

45

50

55

60

65

70

0 0

10

20

30

40

50

60

70

The simulation environment is set as a square grid of area 3000 × 3000 m2 with a road distance of 1000 m between the junctions. Tab. 1 shows the simulation parameters and values. Fig. 3 shows the snapshot of the simulation environment.

SC

Density of Vehicles

4.1. Simulation Setup

Fig. 4: End-to-End delay in seconds at different weights.

EP

TE

D

M AN U

The environment has 16 junctions with 24 roads, and 1 RSU is assumed to be set at each junction. The average density of the vehicles between the juncTable 1: Simulation environment tions in both directions are set between 10 to 80 (vehicles/km). The number of vehicles on the roads are disParameter Parameter Value tributed using Poisson distribution. The positions of Simulation area 3000×3000 m2 the vehicles on the roads (2-D environment) are disDistance between the junctions 1000 m tributed using uniform random distribution. The positions generated are assumed to be the current posiNumber of junctions 16 tions. According to the simulation setup, to transmit Average density of vehicles 10-80 vehicles/km the data from one junction to other the protocol uses Communication range 200 m an average of 5 links (distance/range). If the density Data rate 3 Mbps is high, the positions of the vehicles have a negligible Packet size 512 bytes impact on the data transmission delay. The indepenVehicle speed 30-50 km/hr dent speed of a vehicle between the junctions is ranNumber of simulation runs 100 domly set between 30 to 50 km/hr. The speed of a veMobility model Manhattan Grid hicle is assumed to be constant between the junctions. The communication range for the vehicle and the RSU is set to 200 m. The data rate is set to 3 Mbps. The packet size is set to 512 bytes. The delay is calculated Communication Range Intervehicular using transmission delay, propagation delay, and carof Source and Destination Communication rying delay, according to Eq. (4). If a vehicle is in 3000 the communication range then the packet is assumed to be received at the receiver end. If communication 2500 gap arises between the two vehicles, then the carrySource ing delay in the simulation is calculated by generating 2000 positions of the vehicles after every 3 seconds. This process continues until a vehicle gets a new vehicle in 1500 the forward position in the range or its communication range reaches the RSU/destination. If a vehicle 1000 Destination is out of the junction, then the new position is generated in the straight path with a probability of 0.50 or 500 left path with a probability of 0.25 or right path with a probability of 0.25. It is also assumed that the vehicles 0 −500 0 500 1000 1500 2000 2500 3000 3500 forward the data in the same direction and destination can receive the data from the vehicles moving in any direction. In the simulation, the source and destination Fig. 3: Snapshot of the simulation environment. are randomly chosen. Here, the source is the first vehi-

AC C

75

80

Density of Vehicles

20

80

ACCEPTED MANUSCRIPT

cle on the road to receive the data from the player and destination is the last vehicle nearer to the destination. To select the weights, we have only measured the end-to-end delay parameter with different values of w1 , w2 , and w3 . For performance evaluation, end-toend delay is the most important parameter in our simulation. The results are obtained by averaging 100 simulation runs. From Fig. 4, it is observed that when the weights w1 , w2 , and w3 are set to 0.333, 0.333, and 0.334 respectively, proposed protocol shows less endto-end delay. Hence, to evaluate the performance of the protocol, we have chosen the weights to be 0.333, 0.333, and 0.334 respectively.

Name of the first author, et al.

180 Proposed GyTAR A-STAR P-GEDIR GSR

160

0.05

120

Proposed GyTAR A-STAR P-GEDIR GSR

0.045

100 80 60 40

0.04

0.035

0.03

RI PT

End-to-End Delay (seconds)

140

End-to-End Delay (seconds)

8

0.025

0.02

0.015

0.01 40

20

50

60

70

80

Density of Vehicles

0 30

40

50

60

70

80

Density of Vehicles

SC

4.2. Simulation Results

Fig. 6: End-to-End delay in seconds at different densities (30-80).

4.2.1. End-to-End Delay From Fig. 5 and Fig. 6, it is observed that the proposed routing protocol shows less end-to-end delay than GyTAR, A-STAR, P-GEDIR, and GSR routing protocols. When the density is low (10 and 20), the protocols encounter communication gaps in the path which increases the end-to-end delay due to increase in the carrying delay. The proposed protocol shows less end-to-end delay by sending the data through that path which has a high link connectivity. When the density is set to 30, proposed protocol does not encounter a gap in the path, and the delay is less than 0.035 seconds (35 ms). But, other routing protocols except GyTAR encounter gaps when the density is 30. When the density is increased to 40, 50, 60, 70, and 80, it is observed that no gaps are encountered by the protocols due to high availability of vehicles in the radio range. Therefore, all the protocols perform similar in the high density scenarios by showing less end-toend delay.

EP

TE

Number of Gaps Encountered

D

M AN U

4.2.2. Number of Communication Gaps Encountered From Fig. 7, it is observed that the proposed routing protocol encounters less number of communication gaps in the path than GyTAR, A-STAR, P-GEDIR, and GSR routing protocols. When the density is low (10 and 20), all the routing protocols encounter communication gaps in the path due to less availability of vehicles in the radio range.

3 2 1 0

20 30 40

Proposed GyTAR A−STAR P−GEDIR GSR

160 140 End−to−End Delay (seconds)

4

10

AC C

180

Proposed GyTAR A-STAR P-GEDIR GSR

5

50 60 70 80

Density of Vehicles

120

Fig. 7: Number of gaps encountered at different densities.

100

80 60 40 20 0 10

20

30

40 50 Density of Vehicles

60

70

Fig. 5: End-to-End delay in seconds at different densities.

80

When the density is set to 30, proposed protocol does not encounter a gap in the path because the data is sent through that path which has a high density and high link connectivity. However, other routing protocols except GyTAR encounter communication gaps when the density is set to 30. When the density is increased to 40, 50, 60, 70, and 80, it is observed that no gaps are encountered in the paths due to high density of vehicles. Therefore, all the protocols perform similar in the high density scenarios by encountering less

ACCEPTED MANUSCRIPT

Paper Title (The title should be descriptive, not full sentence)

4.2.3. Number of Hops From Fig. 8, it is observed that when the density increases, all the protocols use higher number of hops due to high availability of vehicles in the communication range.

30

20

Parameter Value MRF24J40MD 2.405-2.48 2.405 20 IEEE 802.15.4 -104 -85 1 packet/sec 100 11 bytes 250 Kbps 20-200

Table 3: Experimental results for PDR 15

Proposed GyTAR A−STAR P−GEDIR GSR

10

5

0

10

20

30

40 50 Density of Vehicles

60

70

80

D

Fig. 8: Number of hops at different densities.

Distance (m) 20 40 60 80 100 120 140 160 180 200

M AN U

Number of Hops

Parameter Transceiver module (dBm) Operating frequency (GHz) Selected channel frequency (GHz) Transmit power (dBm) Standard Receiver sensitivity (dBm) Packet receiving threshold (dBm) Packet Sending Rate Number of packets sent Packet size Data Rate Distance (m)

SC

25

Table 2: Experimental environment for PDR testing

RI PT

number of communication gaps. From the results, it is observed that the average number of gaps encountered by proposed, GyTAR, A-STAR, P-GEDIR, and GSR in the densities (10-80) are 0.375, 0.625, 0.875, 1.125, and 1.125 respectively.

9

AC C

EP

TE

But, when the density is low (10, 20, and 30), protocols use less number of vehicles due to less availability of vehicles in the communication range. At low density, vehicles carry the data and this leads to high end-to-end delay. The proposed protocol uses higher number hops than the other routing protocols because the data is forwarded through the highly connected path. When the density is increased to 40, 50, 60, 70, and 80, it is observed that all the routing protocols use similar number of hops. It becomes stable due to high availability of vehicles in the radio range. A-STAR uses higher number of hops because it sends the data through that path where the density is high (major streets), but it may be a long route. From the results, it is observed that the average number of hops used by proposed, GyTAR, A-STAR, P-GEDIR, and GSR in the densities (10-80) are 23.25, 23.125, 24.75, 22.65, and 22.25 respectively. 5. Experiments and Results 5.1. Packet Delivery Ratio To estimate the packet delivery ratio (PDR), an experiment has been conducted in outdoor Rourkela city environment. Tab. 2 shows the experimental parameters and values.

PDR 100 100 100 100 100 99 99 99 98 97

The main objective of this experiment is to find the PDR at a distance (Euclidean distance between two vehicles position), and apply the data to estimate the PDR for the protocols. In the simulation setup discussed above, we have generated the positions of the vehicles between the junctions. The PDR test results calculated are then applied to estimate the PDR between any two vehicles (Veh1 (x1 , y1 ) − Veh2 (x2 , y2 )). After receiving the data, Veh2 (x2 , y2 ) forward the number of received packets to the next vehicle Veh3 (x3 , y3 ). This process continues until the destination is reached, and the final PDR value is estimated. In this experiment, a transmitter is fixed at a city road point, and it sends 100 packets to the receiver with a packet sending rate of 1 packet per second. The receiver is set at the opposite end by varying the distance from 20 m to 200 m. For this experiment, we use the Arduino uno embedded with Atmega 8-bit microcontroller and Microchip MRF24J40MD transceivers. Tab. 3 shows the PDR testing results at a distance. The MRF24J40MD transceiver operates at 20 dBm power level with a maximum range of 170 m in indoor and 825 m in outdoor environment [42]. However, due to radio propagation irregularity, the tested range may not be uniform in every direction. Therefore, we have

ACCEPTED MANUSCRIPT

set the receiver in four directions east, west, north, and south to estimate the PDR. The path loss may not be uniform in all directions. Therefore, we set the packet receiving threshold to -85 dBm.

P-GEDIR, and GSR in the densities (10-80) are 78, 76.875, 73.25, 75.125, and 75.25 respectively. The proposed protocol shows an improvement of 1.44 %, 6.08 %, 3.68 %, and 3.52 % than GyTAR, A-STAR, P-GEDIR, and GSR routing protocols respectively. From the results, it is concluded that the proposed routing protocol performs well in the city scenarios, and supports the non-safety applications by sending the data in a minimum time. If the road complexity increases, number of hops to transfer the data also increases (destination is far away from the source). This reduces the packet delivery ratio. From the results shown in Figures 3, 8, and 9, it is observed that if the number of hops increases the protocol shows less PDR value. At an average of 23.25 hops the average PDR is 78 %, and the total distance of data forwarding is 4 Km.

100

RI PT

Proposed GyTAR A−STAR P−GEDIR GSR

95

Packet Delivery Ratio (%)

90

85

80

75

70

65

20

30

40 50 Density of Vehicles

60

Fig. 9: PDR at different densities.

70

EP

TE

D

In the experimental test, we observed that, when the distance increases the PDR decreases due to obstacles in the road environment. At distance of 20 m to 100 m, the PDR is 100%, however when the distance is varied from 120 m to 160 m the PDR is 99%. When the distance is further increased to 180 m and 200 m, the PDR is 98% and 97% respectively. The results obtained are the average of the PDR values in each direction. From the results obtained, we assume that, if a receiver vehicle position is at a distance of 150 m then the PDR is 99%. We have chosen 99% because 150 m is between 140 m and 160 m and we assume that the same number of packets can be received below 160 m. From Fig. 9, it is observed that the proposed routing protocol shows more PDR than the other routing protocols. At low density (10, 20, and 30), the number of hops to send the data to the destination is less, therefore the PDR is high for GyTAR and proposed. GSR, P-GEDIR, and A-STAR shows less PDR at low density because of encountering gaps in the path. Due to this situation, there may be a case when the forward positioning vehicle is reached at the boundary of the communication range (180-200 m). However, when the density of vehicles increase, the number of hops used also increases and becomes stable. PDR becomes stable after density=40 for all the routing protocols. From the results, it is observed that if the route length increases, number of hops also increases and this reduces the PDR value. A-STAR sends the data in a longer route because it uses the major streets. However, this increases the number of hops, and PDR value reduces. From the results, it is observed that the average PDR (%) for proposed, GyTAR, A-STAR,

AC C

80

5.2. Validation of Proposed Routing Protocol Using Prototype To validate the proposed routing protocol, an experiment has been conducted in an indoor laboratory environment and outdoor environment. Firstly, we have conducted the indoor laboratory test. In this experiment, a small UVANET platform is made in an area of size 6×3 m2 . Fig. 10 shows the experimental setup to test the proposed routing protocol. The experimental environment parameters and values are shown in Tab. 4.

M AN U

60 10

Name of the first author, et al.

SC

10

Table 4: Experimental environment for UVANET platform

Parameter Transceiver module (dBm) Operating frequency (GHz) Selected channel frequency (GHz) Transmit power (dBm) Standard Receiver sensitivity (dBm) Network size (m2 ) Number of junctions Distance between the junctions (m) Maximum communication range (m) Number of vehicles Number of RSUs Number of destination Speed of vehicle (m/sec) Packet receiving threshold (dBm) Packet Sending Rate Number of packets sent Packet size Data Rate Number of times tested

Parameter Value MRF24J40MA 2.405-2.48 2.405 -20.5 IEEE 802.15.4 -90 6*3 6 3 2 4 6 1 0.2199 -85 1 packet/0.1 sec 20 9 bytes 250 Kbps 20

The platform consists of 6 junctions and the distance between the junctions is set to 3 m. It also consists of 4 line following robots (vehicles) and 6

ACCEPTED MANUSCRIPT

Paper Title (The title should be descriptive, not full sentence)

11

In this experiment, the player sends 20 packets to the destination with a packet sending rate of 1 packet per 0.1 second. According to the protocol, each vehicle beacons its position at a particular interval. In this experiment, we manually set the (x,y) position coordinate in each vehicle and assumes it as the current location coordinate. Tab. 5 shows the initial positions and addresses of the vehicles and RSUs. The positions of the other vehicles and their addresses are also set in a vehicle. It also stores the Parking Location 2 positions and addresses of the RSUs. RSU stores the positions and addresses of the vehicles. The player stores the destination address. The experiment RSU_1 Server Veh_2 Veh_1 starts by running the 4 vehicles and transmitting Veh_3 the data from the source, and receiving the data in Player RSU_2 the destination module that is connected to a laptop to display the result in the Arduino serial monitor. Parking Location 1 The results obtained are the average of 20 tests. For simplicity, we have mainly focused on the decision making capability of RS U1 . From the results, it is observed that the packets are forwarded in the path: Player(0x4201)→ Veh1 (0x4212)→ RS U1 (0x4202)→ Veh3 (0x4204)→RS U2(0x4205)→S erver(0x4207). The results obtained are shown in Tab. 6. A text message M = ”T wo S eats” is sent from the player to the server. In this experiment, speed of the vehicle has a negFig. 10: Experimental setup for UVANET in indoor laboraligible impact on the parameters because the motors tory environment. used in this experiment are of 60 rpm with a wheel diameter of 7 cm. It is also observed that the destination receives all the 20 packets because the vehicles can Table 5: Initial positions and addresses of the vehicles and maximum move 0.4 m ahead in 2 sec (1 packet/0.1 RSUs. sec). From the obtained results, it is concluded that Initial Coordinate Set Hardware Address proposed routing protocol is feasible to implement in a real UVANET environment. Player (1.3,2.7) 0x4201 Veh1 (2,3) 0x4212 Table 6: Experimental Results for proposed routing protocol Veh2 (3,2.1) 0x4203 Veh3 (3,1.3) 0x4204 Parameter Tested result Veh4 (3.5,3) 0x4207 Packet Delivery Ratio 100% Server (5,0.2) 0x4206 End-to-End Delay 0.00144 sec RS U1 (3,3) 0x4202 Number of Gaps 0 RS U2 (3,0) 0x4205 Number of Hops 6

AC C

EP

TE

D

M AN U

SC

RI PT

static wireless modules (RSUs). The destination wireless module is a static vehicle/device lying on the road side. The vehicle is made with Arduino uno embedded with Atmega 8-bit microcontroller, Microchip MRF24J40MA transceiver, and IR sensors to track the black trajectory. The RSU is made with the Arduino uno embedded with Atmega 8-bit microcontoller and Microchip MRF24J40MA transceiver.

The MRF24J40MA transceiver operates at 0 dBm power level with a maximum range of 40 m in indoor and 120 m in outdoor environment [43]. However, due to radio propagation irregularity, the tested range may not be uniform in every direction. To set the communication range approximately to 2 m, we set the transmit power to -20.5 dBm and set the receiver at a distance of 2 m and tested the RSSI in east, west, north, and south directions. The path loss may not be uniform in all directions, therefore we set the packet receiving threshold to -85 dBm. From the results, it is observed that the RSSI values in all the directions are greater than -85 dBm, and we approximate the communication range to be 2 m.

We have tested the performance of the proposed routing protocol by running a simple puzzle game in the prototype designed above. In this game, a player P1 (PLoc1 ) plays a game with player P2 (PLoc2 ). The game data is send through the vehicles, as shown in the above experiment. From the diagram shown in Fig. 11, we have exchanged 12 messages between P1 and P2 for successful execution of the game. P1 (PLoc1 ) sends a message M to P2 (PLoc2 ), which contains the game information. After receiving M, P2 sends an ACK1 message to P1 to inform P1 that he/she is available to play the game. Then P1 sends a query Q M to P2 to think a number between 10 to 99. After receiving Q M , P2 sends an ACK2 message to P2 to inform

ACCEPTED MANUSCRIPT

P1

P2

7

AC C

9-1=8 Send 8 (R)

11

RI PT V 

RSU_1

2+4=6

6

Fig. 12: Experimental setup for outdoor test (Google map data 2016, NIT Rourkela). 24-6=18

8

W o   MJ )

IM

L/R (P2)

m

24

SM

ACK4

9

Veh_S

4

EP

ACK3

120

V 

TE

AM

RSU_2

D

QM ACK2

5

2

Parameter Value MRF24J40MA 2.405-2.48 2.405 -22.8 IEEE 802.15.4 -90 240*50 6 40 3 2 1 1 -85 4 bytes 250 Kbps 10

Veh_2

V 

240 * 50 m2

ACK1

3

Parameter Transceiver module (dBm) Operating frequency (GHz) Selected channel frequency (GHz) Transmit power (dBm) Standard Receiver sensitivity (dBm) Network size (m2 ) Number of junctions Maximum communication range (m) Number of static vehicles Number of RSUs Number of destination Number of source Packet receiving threshold (dBm) Packet size Data Rate Number of times tested

m

M

Table 7: Experimental environment for outdoor UVANET platform

50

1

ment.

M AN U

P1 that he/she thought the number (24). Then P1 sends A M message to P1 to add the two digits (2+4=6). After the addition, P2 informs P1 by sending a ACK3 message. Then P1 sends a message S M to subtract the numbers (24-6=18). After the subtraction, P2 informs P1 by sending an ACK4 message. Then P1 sends a I M message to P2 to send the right side digit information (8) or left side digit information (1). P2 sends 1 to P1 . Then P1 calculates the other digit to be 8 (right digit). The main trick to get a left or right digit is to subtract the number given by the other player with 9. Then P1 sends 8 to P2 . After receiving 8, P2 checks it with the number it calculated (18==18). If it is same, then P2 sends an ACK5 message to P1 to inform that the value matches. After receiving the message P1 knows whether he/she win or lose. The game messages are send using the proposed routing protocol. The results obtained are the average of 10 tests. From the experiment conducted, we observed that the the whole game process takes 0.00768 sec. The average end-to-end delay to send a message is 0.00064 sec. The average number of hops used is 6. The average number of communication gaps encountered on the path is 0. The packet delivery observed is 100 %.

Name of the first author, et al.

SC

12

Send 1 (L) 10

L/R (P1) ACK5

L/R (P2)== L/R (P1) 12

WIN/LOSE

Fig. 11: A simple puzzle game played in indoor UVANET prototype.

Finally, we have tested the proposed routing protocol in an outdoor environment by exchanging the puzzle game information between the source and the destination. Tab. 7 shows the experimental environment for UVANET prototype designed in outdoor environ-

Sourc

Destination

Fig. 13: Source and destination set in the outdoor environment to play the puzzle game.

ACCEPTED MANUSCRIPT

Paper Title (The title should be descriptive, not full sentence)

SC

RI PT

Telecommunication Systems 50 (4) (2012) 217–241. [2] M. L. Sichitiu, M. Kihl, Inter-vehicle communication systems: a survey, Communications Surveys & Tutorials, IEEE 10 (2) (2008) 88–105. [3] S. Bhoi, P. Khilar, Vehicular communication: a survey, Networks, IET 3 (3) (2014) 204–217. [4] J. He, L. Cai, J. Pan, P. Cheng, Delay analysis and routing for two-dimensional vanets using carry-and-forward mechanism, IEEE Transactions on Mobile Computing 16 (7) (2017) 1830– 1841. [5] C. Sobin, V. Raychoudhury, G. Marfia, A. Singla, A survey of routing and data dissemination in delay tolerant networks, Journal of Network and Computer Applications 67 (2016) 128–146. [6] C. Song, J. Wu, M. Liu, H. Zheng, Efficient routing through discretization of overlapped road segments in vanets, Journal of Parallel and Distributed Computing 102 (2017) 57–70. [7] G. M. N. Ali, P. H. J. Chong, S. K. Samantha, E. Chan, Efficient data dissemination in cooperative multi-rsu vehicular ad hoc networks (vanets), Journal of Systems and Software 117 (2016) 508–527. [8] S. K. Bhoi, Path selection based routing protocols for urban vehicular ad hoc networks, Ph.D. thesis (2017). [9] K. A. Hafeez, L. Zhao, B. Ma, J. W. Mark, Performance analysis and enhancement of the dsrc for vanet’s safety applications, Vehicular Technology, IEEE Transactions on 62 (7) (2013) 3069–3083. [10] J. H¨arri, F. Filali, C. Bonnet, Mobility models for vehicular ad hoc networks: a survey and taxonomy, Communications Surveys & Tutorials, IEEE 11 (4) (2009) 19–41. [11] O. K. Tonguz, M. Boban, Multiplayer games over vehicular ad hoc networks: A new application, Ad Hoc Networks 8 (5) (2010) 531–543. [12] J. Saldana, G. Marfia, M. Roccetti, First person shooters on the road: Leveraging on aps and vanets for a quality gaming experience, in: Wireless Days (WD), 2012 IFIP, IEEE, 2012, pp. 1–6. [13] C. E. Palazzi, M. Roccetti, S. Ferretti, G. Pau, M. Gerla, Online games on wheels: Fast game event delivery in vehicular ad-hoc networks, Proc. of Vehicle-to-Vehicle Communications. [14] H. T. Cheng, H. Shan, W. Zhuang, Infotainment and road safety service support in vehicular networking: From a communication perspective, Mechanical Systems and Signal Processing 25 (6) (2011) 2020–2038. [15] F. Li, Y. Wang, Routing in vehicular ad hoc networks: A survey, Vehicular Technology Magazine, IEEE 2 (2) (2007) 12– 22. [16] J. Liu, J. Wan, Q. Wang, P. Deng, K. Zhou, Y. Qiao, A survey on position-based routing for vehicular ad hoc networks, Telecommunication Systems (2015) 1–16. [17] Y.-W. Lin, Y.-S. Chen, S.-L. Lee, Routing protocols in vehicular ad hoc networks: A survey and future perspectives., J. Inf. Sci. Eng. 26 (3) (2010) 913–932. [18] S. K. Bhoi, P. M. Khilar, Ijs: An intelligent junction selection based routing protocol for vanet to support its services, International Scholarly Research Notices 2014. [19] O. S. Oubbati, A. Lakas, F. Zhou, M. G¨unes¸, N. Lagraa, M. B. Yagoubi, Intelligent uav-assisted routing protocol for urban vanets, Computer Communications. [20] A. H. A. Hanan, M. Y. Idris, O. Kaiwartya, M. Prasad, R. R. Shah, Real traffic-data based evaluation of vehicular traffic environment and state-of-the-art with future issues in locationcentric data dissemination for vanets, Digital Communications and Networks. [21] D. Lin, J. Kang, A. Squicciarini, Y. Wu, S. Gurung, O. Tonguz, Mozo: A moving zone based routing protocol using pure v2v communication in vanets, IEEE Transactions on Mobile Computing 16 (5) (2017) 1357–1370. [22] N. Alsharif, X. Shen, i car-ii: Infrastructure-based connectivity aware routing in vehicular networks, IEEE Transactions on Vehicular Technology 66 (5) (2017) 4231–4244. [23] C. Lochert, H. Hartenstein, J. Tian, H. Fussler, D. Hermann,

M AN U

For simplicity, in this experiment we have set 5 static vehicles (wireless nodes) in our college campus (NIT, Rourkela). We have also set 2 RSUs at the junctions. Figure 12 shows the setup to test the simple puzzle game. The vehicles are assigned with the addresses and 2D coordinate values. The communication range for the vehicle and RSU is approximately set to 40 m by setting the transmit power (dBm) to -22.8. Figure 13 shows the source and the destination. The experiment is carried out in a same way as it is conducted for the indoor environment. The source and the destination exchange 12 messages to play the game. The game messages are send using the proposed routing protocol. The results obtained are the average of 10 tests. From the experiment conducted, we observed that the whole game process takes 0.007681 sec. The average end-to-end delay to send a message is 0.000641 sec. The number of hops used to send the data is 6 (VehS → RS U1 → Veh1 → RS U2 → Veh2 → VehD ). The average number of communication gaps encountered on the path is 0. The packet delivery observed is 100 %. The messages are not transmitted through Veh3 because the path weight is more due to high carrying delay.

13

6. Conclusion

AC C

EP

TE

D

A routing protocol is proposed for UVANET environment to support the non-safety applications. This protocol performs well in the city scenarios by sending the data to the destination in a minimum time. In this paper, we have used this routing protocol to transfer the game data from one parking lot to other parking lot. From the simulation results, it is observed that when there is high density and high connectivity between the vehicles then the proposed routing protocol fulfills the average end-to-end delay tolerance of 100 ms (for successful execution of the game) by showing an average end-to-end delay of 35 ms. This protocol performs better than GyTAR, A-STAR, P-GEDIR, and GSR routing protocols in terms of end-to-end delay, packet delivery ratio, number of hops, and number of communication gaps encountered. At last, a simple puzzle game is run on a UVANET prototype designed in an indoor laboratory environment and outdoor environment. The game data is transfered using the proposed routing protocol. From the results, it is observed that the game is successfully played with the exchange of 12 messages. This protocol promises a better routing solution for the non-safety applications. In future, we will implement the proposed routing protocol in a real UVANET environment by fixing MRF24J40MA wireless modules in the cars (mobile) and connecting the parking lots. References [1] S. Zeadally, R. Hunt, Y.-S. Chen, A. Irwin, A. Hassan, Vehicular ad hoc networks (vanets): status, results, and challenges,

ACCEPTED MANUSCRIPT

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42] [43]

RI PT

M AN U

[28]

D

[27]

TE

[26]

EP

[25]

AC C

[24]

M. Mauve, A routing strategy for vehicular ad hoc networks in city environments, in: Intelligent Vehicles Symposium, 2003. Proceedings. IEEE, IEEE, 2003, pp. 156–161. B. Karp, H.-T. Kung, Gpsr: Greedy perimeter stateless routing for wireless networks, in: Proceedings of the 6th annual international conference on Mobile computing and networking, ACM, 2000, pp. 243–254. C. Lochert, M. Mauve, H. F¨ußler, H. Hartenstein, Geographic routing in city scenarios, ACM SIGMOBILE mobile computing and communications review 9 (1) (2005) 69–72. B.-C. Seet, G. Liu, B.-S. Lee, C.-H. Foh, K.-J. Wong, K.-K. Lee, A-star: A mobile ad hoc routing strategy for metropolis vehicular communications, in: Networking 2004, Springer, 2004, pp. 989–999. M. Jerbi, S.-M. Senouci, T. Rasheed, Y. Ghamri-Doudane, Towards efficient geographic routing in urban vehicular networks, Vehicular Technology, IEEE Transactions on 58 (9) (2009) 5048–5059. L.-D. Chou, J.-Y. Yang, Y.-C. Hsieh, D.-C. Chang, C.-F. Tung, Intersection-based routing protocol for vanets, Wireless personal communications 60 (1) (2011) 105–124. Y.-S. Chen, Y.-W. Lin, C.-Y. Pan, Dir: diagonal-intersectionbased routing protocol for vehicular ad hoc networks, Telecommunication systems 46 (4) (2011) 299–316. R. S. Raw, S. Das, Performance analysis of p-gedir protocol for vehicular ad hoc network in urban traffic environments, Wireless personal communications 68 (1) (2013) 65–78. H. Saleet, R. Langar, K. Naik, R. Boutaba, A. Nayak, N. Goel, Intersection-based geographical routing protocol for vanets: a proposal and analysis, Vehicular Technology, IEEE Transactions on 60 (9) (2011) 4560–4574. J. Toutouh, J. Garc´ıa-Nieto, E. Alba, Intelligent olsr routing protocol optimization for vanets, Vehicular Technology, IEEE Transactions on 61 (4) (2012) 1884–1894. P. K. Sahu, E. H.-K. Wu, J. Sahoo, M. Gerla, Bahg: backbone-assisted hop greedy routing for vanet’s city environments, Intelligent Transportation Systems, IEEE Transactions on 14 (1) (2013) 199–213. M. Al-Rabayah, R. Malaney, A new scalable hybrid routing protocol for vanets, Vehicular Technology, IEEE Transactions on 61 (6) (2012) 2625–2635. T. Taleb, E. Sakhaee, A. Jamalipour, K. Hashimoto, N. Kato, Y. Nemoto, A stable routing protocol to support its services in vanet networks, Vehicular Technology, IEEE Transactions on 56 (6) (2007) 3337–3347. S. K. Bhoi, P. M. Khilar, M. Singh, A path selection based routing protocol for urban vehicular ad hoc network (uvan) environment, Wireless Networks (2015) 1–12. S. K. Bhoi, P. M. Khilar, A road selection based routing protocol for vehicular ad hoc network, Wireless Personal Communications 83 (4) (2015) 2463–2483. S. K. Bhoi, P. M. Khilar, Self soft fault detection based routing protocol for vehicular ad hoc network in city environment, Wireless Networks 22 (1) (2015) 1–12. S. K. Bhoi, P. M. Khilar, Rvcloud: a routing protocol for vehicular ad hoc network in city environment using cloud computing, Wireless Networks 22 (4) (2015) 1–12. D. Lee, S.-w. Chang, S.-s. Lee, Analysis and design on efficient message relay methods in vanet, Multimedia Tools and Applications 74 (16) (2015) 6331–6340. J.-H. Lee, W.-S. Han, K. H. An, K. B. Sung, Towards intelligent in-vehicle sensor database management systems, Multimedia Tools and Applications 74 (10) (2015) 3599–3615. http://ww1.microchip.com/downloads/en/devicedoc/70005173a.pdf. http://ww1.microchip.com/downloads/en/appnotes/00001629a.pdf.

Name of the first author, et al.

SC

14

ACCEPTED MANUSCRIPT

Title: A Routing Protocol for Urban Vehicular Ad Hoc Networks to Support Non-Safety Applications Manuscript ID: DCAN_2017_99

M AN U

SC

RI PT

Author Details

AC C

EP

TE D

Sourav Kumar Bhoi has completed his Ph.D. in 2017 from the Department of Computer Science and Engineering, National Institute of Technology (NIT), Rourkela, India. He received his M.Tech degree in 2013 from the same institute. He has received his B.Tech degree in 2011 from Department of Computer Science and Engineering, VSSUT University, Burla, India. He is currently working as an Assistant Professor in the Department of Computer Science and Engineering, Parala Maharaja Engineering College (Govt.), Berhampur, India. His research interests include Vehicular Communication System, Sensors, IoTs, Network Security, and Cloud Computing. He has published papers in journals like Wireless Networks, Wireless Personal Communications, National Academy Science Letters, IET Networks, Hindawi, IEEE Sensors (Accepted) and MDPI. He has authored 29 research articles in reputed journals and international conferences. He received the IET Premium Award-2016 from IET Networks for the best journal paper in the last two years. He is a member in IAENG. Email: [email protected]

SC

RI PT

ACCEPTED MANUSCRIPT

TE D

M AN U

Pabitra Mohan Khilar received his Ph.D. in Computer Engineering in 2009 from Indian Institute of Technology (IIT), Kharagpur, India. He received his M.Tech degree in 1999 from the Department of Computer Science and Engineering, National Institute of Technology (NIT), Rourkela, India. He received his B.Tech degree in 1990 from Department of Computer Science and Engineering, University of Mysore, India. He is an Assistant Professor in the Department of Computer Science and Engineering, National Institute of Technology (NIT), Rourkela, India. His research interests include Parallel and Distributed Computing, Fault Tolerant Systems, Wireless Networks, Sensors, and VLSI Design. He has a teaching experience of more than 20 years. He has awarded 7 doctoral degrees. He has authored more than 150 journals and conference papers. He has published papers in journals like Wireless Networks, Wireless Personal Communications, IJCS Wiley, Ad Hoc Networks, Computer and Electrical Engineering, Swarm and Evolutionary Computation, IET Networks, IET Wireless Sensor Systems, and IEEE Surveys and Tutorials. He received the IET Premium Award-2016 from IET Networks for the best journal paper in the last two years. He is a Life Member in MIEEE, MIE, MCSI, MISTE, MOEC, MOITS, MIETE, and MISCA.

AC C

EP

Email: [email protected]

Munesh Singh has completed his Ph.D. in 2017 from the Department of Computer Science and Engineering, National Institute of Technology (NIT), Rourkela, India. He received his M.Tech

ACCEPTED MANUSCRIPT

TE D

M AN U

SC

RI PT

degree in 2012 from the Department of Computer Science and Engineering, Pondicherry University, India. He has received his B.Tech degree in 2010 from Department of Computer Science and Engineering, RGTU University, India. He is currently working as an Assistant Professor in Department of CSE, VIT University, Bhopal, India. He has an industrial experience of 1 year in Honeywell Technology Solution Lab, Bangalore, India. His research interests include Wireless Sensor Networks, Radar Surveillance, Ad hoc Networks, Sensors, and Robotics. He has authored 3 research articles in Wireless Networks, Springer, 1 research article in Wireless Personal Communications, Springer, 1 article in IEEE Sensors (Accepted) and 1 letter in National Academy Science Letters. He is a member in IAENG. Email: [email protected]

EP

Rashmi Ranjan Sahoo is pursuing his Ph.D. degree in the Department of Electronics and Telecommunication Engineering, Jadavpur University, India. He received his M.Tech degree in 2012 from the same institute. He is currently working as an Assistant Professor in the Department of Computer Science and Engineering, Parala Maharaja Engineering College (Govt.), Berhampur, India. He has a teaching experience of more than 6 years. His research interests include Wireless Sensor Networks, Ad hoc Networks, Sensors, and Security. He has authored 12 research articles. He has published a research paper in Natural Computing, Springer.

AC C

Email: [email protected]

SC

RI PT

ACCEPTED MANUSCRIPT

AC C

EP

TE D

Email: [email protected]

M AN U

Rakesh Ranjan Swain is pursuing his Ph.D. degree in the Department of Computer Science and Engineering, National Institute of Technology (NIT), Rourkela, India. He received his M.Tech degree in 2014 from the Department of Computer Science and Engineering, VSSUT University, Burla, India. His research interests include Wireless Sensor Networks, Fault Tolerance, and Soft Computing. He has authored 2 research articles in Wireless Personal Communications, Springer and IJCS, Wiley.