Reliable Intersection-Based

Traffic Aware Routing

Protocol for Urban Areas
Vehicular Ad Hoc Networks
Tasneem S. J. Darwish and Kamalrulnizam Abu Bakar
Are with the Pervasive Computing Research Group, Faculty of Computing,
Universiti Teknologi Malaysia (UTM), 81310 Skudai, Johor D. T, Malaysia
Email: tasneem83darwish@gmail.com (tasneem).
Khalid Haseeb
Is with the Computer Science Department,
Islamia college (Chartered University), Peshawar, Pakistan
Email: khalid.haseeb@icp.edu.pk

Abstract­—Nowadays, providing reliable vehicle to vehicle communications in

vehicular ad hoc networks is essential to serve the emerging intelligent trans-
portation systems. Traffic aware routing is considered a promising approach for
delivering data packets between geographically separated vehicles. However,
most of the existing traffic aware routing protocols greedily select the next-hop
based on distance. Consequently, high packet loss ratio occurs especially with
the vehicles high speed mobility. Some existing forwarding schemes attempted to
improve the next-hop selection by considering inter-vehicle communication qual-
ity or neighbours predicted positions. Nevertheless, such schemes depend on the
neighbours mobility information received through beacons regardless of its fresh-
ness. In addition, the differentiation between road and intersection areas while for-
warding packets was neglected. Therefore, a reliable traffic aware routing protocol is
proposed, which selects the next-hop based on roads structure, neighbours predicted po-
sitions and their received signal strength, and the recentness of the mobility information
received from neighbours. The simulation results show significant improvements in terms
of packet delivery ratio and end-to-end delays.

image licensed by ingram publihing

Digital Object Identifier 10.1109/MITS.2017.2776161
Date of publication: 19 January 2018

IEEE Intelligent transportation systems magazine • 60 • spring 2018 1939-1390/18©2018IEEE

I. Introduction

V
ehicular ad hoc networks (VANETs) are a core component of the future intelligent transportation
systems. VANETs consist of vehicles with on-board wireless communication facilities that are able
to establish ad hoc communications with their peers, as well as with infrastructure networks [1].
Moreover, the evolution of the standard communication protocols such as IEEE 802.11p and IEEE
1609 contributed towards realizing the concepts of VANETs. In addition, the huge investment of automo-
bile manufacturers is pushing towards the real-world deployment of vehicular networks. For instance,
due to the applied regulations, all new cars in USA are expected to be communication-enabled by 2017 [2].
Although most of VANETs early applications were to enhance traffic safety, the number of third-party
providers offering non-safety applications is growing recently [3]. For example, VANETs can be utilized
for real-time data collection in traffic control and roads maintenance systems [4], automated toll pay-
ment, enhanced navigation, location-based services [5], infotainment applications and Internet access
[6]. Thus, in the near future the demand for reliable and efficient communication, among vehicles (V2V)
and between vehicles and infrastructure (V2I), will rise dramatically. To enable geographi-
cally separated vehicles to communicate, VANETs employ multi-hop communica-
tions by relying on intermediate vehicles to forward packets. However, the
high speed mobility of vehicles causes intermittent inter-vehicle com-
munication [7]. Therefore, delivering data packets through multi-
hop communications in VANETs environment requires reliable
and efficient routing protocol.
As geographical routing forwards packets based on
vehicles positions, it is considered a promising routing
approach in dynamic environments for its scalability
and robustness against frequent topology changes
[8]. Greedy Perimeter Stateless Routing (GPSR)
is the basic geographical routing protocol pro-
posed for ad hoc networks [9]. However, GPSR
forwards packets greedily based on vehicles
positions only, and it has no consideration for
network and traffic status. Therefore, pack-
ets might be forwarded through roads with
low vehicular density or high level of net-
work disconnections. In addition, choosing
the furthest neighbour as a next forwarder
might result in forwarding data packets to
unreachable neighbours.
To eliminate conventional geographi-
cal routing protocols limitations geographic
routing was integrated with traffic aware-
ness resulting in traffic aware routing (TAR)
protocols, which adapt to variable traffic con­­
ditions. Although there is a variety of TAR
protocols, intersection-based TAR protocols are
considered the most adaptable to urban VANETs
dynamic environment [10]. Intersection-based TAR
protocols make routing decisions at each inter-
section after giving each adjacent road a weighted
score, where the road with the highest score is cho-
sen for packet forwarding.
Unfortunately, many of the existing TAR protocols em-
ploy the greedy forwarding method to select a next forwarder
within roads and at intersections, which highly affect the routing
performance. Although exploiting greedy-based forwarding reduces
the number of hops, it results in higher packet loss ratio, especially with

IEEE Intelligent transportation systems magazine • 61 • spring 2018


In the near future the demand for reliable and efficient
communication, among vehicles (V2V) and between vehicles
and infrastructure (V2I), will rise dramatically.
high speed mobility. Therefore, some forwarding approach-
es restricted the next forwarder selection area or predicted
neighbours positions before selecting the next forwarder.
However, such approaches have no consideration for roads
structure and the possibility of changing vehicles direc-
tion due to approaching intersection areas. In addition, as a be chosen as a next-hop even after it turns into a different
subcategory of position-based routing protocols, TAR pro-
tocols depend on the beacon messages exchanged between
vehicles to get neighbours mobility information. Neverthe-
less, the vehicle might change its direction and speed after
sending a beacon message, which results in using outdated
neighbour mobility information that causes deceptive next
hop selection. Therefore, this research contributes towards
eliminating the previously mentioned problems by pro-
posing a Reliable Traffic Aware Routing (RTAR) protocol,
which selects the next forwarder based on multiple crite-
ria. Basically, RTAR differentiates between the next for-
warder selection in roads and intersection areas. Moreover,
RTAR considers neighbours predicted positions, Received
Signal Strength Indicator (RSSI) values, and the received
neighbours mobility information recentness while select-
ing next forwarders.
This paper is structured as follows: Section II discusses next-hop is the closest to the destination and has the low-
several TAR approaches proposed in the context of VANETs
and details the motivations of this paper. Section III, intro- this approach neglects the recentness of the neighbours
duces RTAR functionality, design and algorithms. Section
IV presents and discusses the performance evaluation of
RTAR. Finally, Section V concludes this article.
II. Motivations and Related Work
Traffic aware routing is a recent approach for delivering
data in VANETs environment, which endeavours to solve
the limitations of geographical routing protocols by in-
volving the traffic awareness routing metrics in the rout-
ing decisions. However, TAR protocols performance is
seriously influenced by the utilized next-forwarder se-
lection scheme.
Several TAR protocols adopted the greedy forward-
ing mechanism, where the selected next-hop is the one
closest to the destination or to next intersection (i.e., fur- tion is selected as a next-hop. In [21], [22] the authors en-
thest neighbour from the current forwarder) [11]–[13].
As the wireless signal strength decreases by increasing
transmission distance, the furthest neighbour might not
receive a good quality signal from the current forward-
IEEE Intelligent transportation systems magazine •
er [14]. In [15], the full path to-
wards destination is dis­covered,
then data packets are forwarded
greedily between anchor points.
In such protocols, vehicles ob-
tain their neighbours positions
via beacon messages. Neverthe-
less, as vehicles tend to change
their directions rapidly near to
or at intersection areas, the used
neighbours positions might be inaccurate. Thus, greedy
forwarding causes high packet loss in VANETs environ-
ment since it has no consideration for the roads structure,
recentness of neighbours mobility information, and com-
munication links quality. In particular, a vehicle might
road or is no longer located in the coverage area of the cur-
rent forwarder.
To tackle the limitations of classical greedy forward-
ing, the authors in [16] proposed to forward packets on
paths constructed based on distance and communication
link lifetime between vehicles. Although considering link
lifetime reduces the impact of greedy forwarding as stable
links are chosen, the proposed mechanism does not con-
sider roads structure and the quality of received signals. In
addition, link lifetime estimation was based on the neigh-
bours mobility information received in beacon messages,
which may result in inaccurate estimation especially when
outdated information is used. A different approach was in-
troduced in [17], where in low vehicular density the next-
hop is chosen as the closest to the destination and moving
towards it. On the other hand, in high density situations the
est load compared to other neighbour vehicles. However,
mobility information and the signal strength, which might
result in choosing an unreachable next-hop. A restricted
forwarding algorithm was applied in [18], which chooses
a neighbour within a specific distance range to reduce
packet loss caused by distant next-hop selection. However,
the restricted forwarding range is a fixed range which does
not adapt to roads structure or transmission links quality.
Moreover, the next-hop is selected based on neighbours
mobility information without considering its validity
or recentness.
To alleviate the impact of vehicles mobility, the authors
in [19], [20] proposed the improved greedy forwarding,
where the current positions of neighbour vehicles are
predicted, then the closest neighbour to next intersec-
hanced the mechanism of improved greedy forwarding
by selecting the neighbour with a high RSSI value (i.e.,
RSSI value above 60% of the maximum recorded RSSI
value). However, neglecting roads’ structure may lead to
62 • spring 2018
­ eceptive next-hop selection, es-
d
pecially near to intersection areas
where vehicles tend to cha nge
t hei r directions rapidly. Moreover, Delivering data packets through multi-hop communications
the neighbours positions prediction in VANETs environment requires reliable and efficient
is done based on the instantaneous
mobility i nfor mat ion rec eived routing protocol.
via beacons, which does not de-
scribe vehicles movement over a
period of time. Thus, there is a
high probability of carrying out inaccurate neighbours po- the required quality of service while routing packets. Un-
sition prediction that leads to unreliable next-forwarder se- fortunately, depending on neighbours mobility informa-
lection. Therefore, high packet loss might occur, especially tion for calculating link duration without considering the
near intersection areas, as the aforementioned forward- recentness of such information may result in a deceptive
ing schemes have low reliability and may select unreach- next-hop selection. In [27], a contention-based forwarding
able neighbours. is employed, where the closest neighbour to destination
In a different approach, the virtual distance for all further forwards the data packet. Nevertheless, conten-
neighbours which are closer to the destination than cur- tion-based forwarding might generate redundant packet
rent forwarder is calculated [23], [24]. Here, the virtual replications and transmissions, which may cause broad-
distance refers to the largest two-hop distance, which cast storms and network congestions.
equals to the distance between the current forwarder and In TAR protocols, next-hop selection has a significant
its neighbour vehicle plus the distance between the neigh- impact on the reliability of the routing process. As can
bour vehicle and its closest neighbour to the destination. be deduced from the previously discussed related work,
Eventually, the neighbour with the largest virtual distance many of the existing TAR forwarding schemes suffer the
is chosen as the next hop. Although this mechanism de- limitations of greedy forwarding. Some TAR schemes at-
pends on two-hop distance for selecting a next-hop, com- tempted to address the problem by exploiting neighbours
munication links quality and stability were not considered. positions prediction, restricted forwarding area or RSSI
Moreover, the freshness of neighbours mobility informa- values as an indication of communication link quality.
tion was not considered in this approach, which makes dis- However, the aforementioned solutions depend on the
tance estimation more error-prone as it is calculated over neighbours mobility information received through bea-
two hops. con messages without considering the validity and fresh-
In [25], the authors improved the greedy forward- ness of such information, which may result in selecting
ing performance by increasing neighbour tables ac- a deceptive next-hop. In addition, the existing schemes
curacy. Actually, two problems caused by conventional have no consideration for roads structure, even though
hello messages scheme with fixed broadcasting intervals vehicles tend to change their direction rapidly within or
were identified. First, when old neighbours are no longer near intersection areas. To overcome the aforementioned
within transmission range, their entries are not deleted problems, RTAR introduces a reliable next-hop selection
on time. Second, some new neighbours are not added to scheme, which considers neighbours current position,
the neighbour table as soon as they enter the transmission communication links quality, roads structure and the re-
range since they need to wait for the next hello message. centness of neighbours mobility information. Moreover,
To address such problems, for each neighbour recorded in RTAR gives priority for the neighbours that their mobil-
the neighbour’s table, the lifetime is estimated. More- ity information is received recently to be next-forwarders
over, when two vehicles are approaching each other the at junctions, which contributes towards avoiding choos-
time after which they can directly communicate is esti- ing neighbours that turned to different roads. In addition,
mated by an intermediate vehicle. Next, without waiting RTAR utilizes the traffic and network status measurement
for the next hello message both vehicles are informed for adjacent roads to forward packets through the best
with the estimated time. Nevertheless, communication road, thereby improving the routing performance of traf-
links lifetime estimation is error-prone, due to the ef- fic aware routing.
fect of variable vehicles speed and the mobility patterns
at intersections. In addition, the introduced enhancement III. Reliable Traffic Aware Routing (RTAR) Protocol
generates extra network overhead that rises with high This section explains in details the proposed RTAR proto-
driving speeds. col for V2V communication in VANETs environment. RTAR
On the other hand, the authors in [26] selects the next- makes its routing decision when the data packet reaches an
hop by favouring either distance or link stability to satisfy intersection area to choose the best next road for ­forwarding

IEEE Intelligent transportation systems magazine • 63 • spring 2018

 siders traffic and network status on adjacent roads, while
Algorithm 1 Road Area Reliable Routing (RARR)
making routing decisions at intersections to select the best
road for packet forwarding. Basically, for each adjacent road
Require: CF neighbour table, CF position, destination position
Ensure: Forward data packet through a road a score is calculated using its status evaluation results, then
 1: Set NF = Null the score is used while making routing decisions. Thus, pro-
 2: Set N = The CF neighbours table viding accurate road status evaluation results leads to better
 3: if CF and destination vehicle are in the same road then routing decisions that dynamically adapt to variable roads
  4:   TP = destination position
conditions. However, the network overhead generated by
 5: else
  6:   TP = TI.center the road evaluation process may degrade the routing proto-
 7: Endif cols performance. Therefore, to employ accurate and light-
 8: PFG = {n: n ! N / n.RSSI # RSSI threshold / n.predictedPosition in CF.coverage / weight road status evaluations, RTAR exploits the Real-time
 9: n.predictedPosition closer to TP than CF } Traffic and Network Status Measurement (RTNSM) process
10: PFG sameRoad = {n ! PFG: n is in same road as CF }
introduced in [29].
11: NF = CF
12: if PFG sameRoad .size! = 0 then //Beginning of Case 1 The main idea of RTNSM is based on creating and for-
13:    for i = 1; i 1= PFG sameRoad .size; i ++ do warding control packets between each two consecutive
14:       if PFG sameRoad [i ] closer to TP than NF then intersections to evaluate the road status in terms of both di-
15:           NF = PFG sameRoad [i ] rection vehicular density, inter-vehicle communication
16:       Endif
link lifetime among neighbours and the road’s network load,
17:    Endfor
18: Endif //End of Case 1 which provides a comprehensive road status description.
19: if NF == CF then Afterwards, the roads evaluations results are announced
20:    if PFG.size! = 0 then //Beginning of Case 2 at intersections areas to be available for routing purposes.
21:       Set NF1 = Null The RTNSM process evaluates roads when changes in roads
22:       Set NF2 = Null
status are expected to occur, resulting in detecting and re-
23:       Set Z = CF
24:       for i = 1; i 1= PFG.size; i ++ do flecting the roads real-time status more accurately with
25:          if PFG[i] closer to TP than then minimized network overhead. This is achieved by control-
26:             if CF received PFG[i] beacon in the last beacon interval then ling and adapting the generation frequency of control pack-
27:                 NF1 = PFG [i ] ets based on changes in road status.
28:                 Z = NF1
To improve the packet forwarding process, RTAR se-
29:             else if CF received PFG[i] beacon in the last two beacon
30: intervals then lects the next forwarder (NF) vehicle in a reliable way,
31:                 NF2 = PFG [i ] whereas multiple criteria related to current forwarder
32:                 Z = NF2 (CF) position (i.e., located at a road or an intersection) and
33:             Endif the conditions of its available neighbours are considered.
34:             Endif
To achieve this goal, RTAR introduces two algorithms for
35:          Endif
36:       Endfor selecting the NF. The first algorithm is the Road Area Re-
37:       if NF1! = Null then liable Routing (RARR), which is applied when the CF is
38:          NF = NF1 within a road area. However, if the CF vehicle is currently
39:       else if NF2! = Null then within an intersection area, the Intersection Area Reliable
40:          NF = NF2
Routing (IARR) algorithm is applied. The following subsec-
41:       Endif
42:    Endif tions explain the reliable packet forwarding procedure of
43: Endif //End of Case 2 RTAR in more details.
44: if NF == CF then
45:    for i = 1; i 1= PFG.size; i ++ do //Beginning of Case 3 A. The Road Area Reliable Routing (RARR)
46:       if PFG[i] closer to TP than NF then
When the CF is located within a road area and the destina-
47:           NF = PFG [i ]
48:       Endif tion vehicle is not the CF’s direct neighbour, RTAR selects
49:    Endfor the NF vehicle based on Algorithm 1 (RARR). To explain
50: Endif the workflow of Algorithm 1, references to its line numbers
51: if NF == CF then are used in this section.
52:    CF carries the data packet
First, if the destination vehicle is located on the same
53: Endif //End of Case 3
road as the CF, then the destination vehicle position is
considered the Target Point (TP). In case the destination
based on roads status. As vehicles are the main network en- vehicle and the CF are not on the same road, then the TP
tities in VANETs, routing protocols performance is highly is the center of the Target Intersection (TI). The TI is the
affected by the availability of vehicles and their inter-vehicle first closest intersection to the destination, where the data
communication quality [28]. Therefore, RTAR protocol con- packet should reach in order to carry out Algorithm 2 and

IEEE Intelligent transportation systems magazine • 64 • spring 2018

make the intersection-based routing decision. To forward
Algorithm 2 Intersection Area Reliable Routing (IARR)
the data packets towards TP, a NF vehicle needs to be cho-
sen. To select a NF vehicle in a reliable way, the CF forms
Require: CF neighbour table and road information table
the Potential Forwarders Group (PFG) which includes the Ensure: Forward data packet towards the best road
neighbours that fulfil the following conditions:  1: Set NF = Null
■■ The average RSSI value obtained by calculating the RSSI  2: Set N = The CF neighbours Table
mean of the received beacon messages/data packets  3: Set AR = Adjacent roads to CI
from the neighbour must be greater than the predefined  4: if CF does not have LREresult f or all AR then
 5:    Send CPs to get LREresult
threshold as formulated in Equation 1. The RSSI max val-  6:    wait to receive LREresult
ue is the maximum value among all the recorded RSSI  7: Endif
values of the received beacons and data packets from  8: for i = 1; i 1= AR.size; i ++ do //calculate adjacent roads scores
all neighbours.  9:    Roads [i ] .score = b 1 ·AR [i ] .LRE result + b 2 ·AR [i ] .PD
■■ Neighbour’s predicted position is in the CF transmis-
10: Endfor
11: RankedRoads = sortRoads(Roads) //Rank adjacent roads
sion coverage area. Predicted positions are calculated 12: for j = 1; j 1= RankedRoads.size; j ++ do
based on neighbours mobility information (i.e. speed, 13:    TP = RankedRoad[j]:CTI:center
direction and latest position), which is obtained through 14:    PFG [j ] sameRoad = {n: n ! N / n.RSSI # RSSI threshold /
beacons. 15: n.predictedPosition in CF.coverage / n.predictedPosition closer to TP than CF /
■■ Neighbour’s predicted position is closer to TP than CF.
16: n is in the road RankedRoads [j ]}
17:    if PFG [j ] sameRoad .size! = 0 then
18:       Set NF1 = Null
Neighbour_RSSI $ RSSI threshold 19:       Set NF2 = Null

where RSSI threshold = 0.6 ) RSSI max (1) 20:       Set Z = CF
21:       for x = 1; x 1= PFG [j ] sameRoad .size; x ++ do
Afterwards, the CF vehicle forms a sub set of the PFG 22:          candidateNeighbour = PFG [j ] sameRoad [x]
23:          if candidateNeighbour closer to TP than Z then
which includes the neighbours that belong to the same 24: //Giving priority to the neighbour with the most updated mobility information
road as CF; i.e., PFG sameRoad (line 10, Algorithm 1). Next, if 25:             if CF received candidateNeighbour’s beacon in the last beacon
the PFG sameRoad set is not an empty set, then the CF apply interval then
Case 1 to select the NF; otherwise, Case 2 is applied. How- 26:                NF1 = candidateNeighbour
ever, in case of failing to find a neighbour in Case 2, then 27:                Z = NF1
28:             else if CF received atleast one candidateNeighbour’s beacon
the NF is selected based on Case 3. in the last two beacon intervals then
Case 1 (lines 12–18, Algorithm 1): In this case, the CF 29:                NF2 = candidateNeighbour
still has some neighbours on the same road and located be- 30:                Z = NF2
tween itself and TP. Figure 1 demonstrates this case where 31:             Endif
TI (1) is the TP. Therefore, the CF inspects the neighbours 32:          Endif
33:       Endfor
included in the PFG sameRoad group, and then the closest 34:       if NF1! = Null then
neighbour to the TP is selected as NF. 35:          NF = NF1
Case 2 (lines 20–41, Algorithm 1): In this case, the CF 36:          break
does not have a neighbour located on the same road and 37:       else if NF2! = Null then
closer to TP than itself. This may occur when the CF is 38:          NF = NF2
39:          break
approaching the TI area, as shown in Figure 2. Therefore, 40:       Endif
the CF inspects the PFG group and chooses the closest 41:    Endif
neighbour to TP, which at least one beacon message was 42: Endfor
received from it in the last beacon interval (lines 26–28 43: if NF == Null then //Select a neighbour in the CI area
and 35–36, Algorithm 1). However, if such a neighbour 44:    PFG CI = {n: n ! N / n.RSSI # RSSI threshold /
45: n.predictedPosition in CF.coverage / n.predictedPosition closer to CI.
is not available, then the CF selects from PFG the closest center than CF }
neighbour to TP which at least one beacon message was 46:    NF = x: x ! PFG CI / x is the closest to CI.center
received from it in the last two beacon intervals (lines 29– 47: Endif
31 and 37–38, Algorithm 1). This is to give priority for the 48: if NF == Null then
neighbours to be chosen as next forwarders, whose their 49:    CF carries the data packet
50: Endif
mobility information was received recently. Thereby, the
probability of forwarding data packets to unreachable
neigbours is reduced. to TP to be the NF (lines 42–48, Algorithm 1). However,
Case 3 (lines 42–51, Algorithm 1): When neighbours if such a neighbour is not available, then the CF keeps
with recent mobility information are not available in PFG, ca r rying the packet until it finds a suitable NF (lines
the CF inspects PFG and chooses the closest neighbour 49–51, Algorithm 1).

IEEE Intelligent transportation systems magazine • 65 • spring 2018

 In fact, beacon messages carry instantaneous mobility
information of neighbours, which might cause prediction
errors, especially in VANETs dynamic environment. In ad-
dition, neighbours positions prediction is more error-prone
when vehicles are nearby or in intersection area, as vehicles
might change their directions by turning into different roads
suddenly. Accordingly, as the CF in Case 2 is approaching an
intersection, and the selected NF neighbour is not located on
the same road, thus, the selected neighbour might turn into
a different road soon and become unreachable. Therefore,
selecting the neighbour with the recently updated mobil-
ity information to be the NF, reduces the probability of for-
warding data packets to unreachable neighbours, thereby
improving the reliability of data packet routing.
B. The Intersection Area Reliable Routing (IARR)
Once a data packet reaches an intersection area (TI (1) in
Figure 2), the CF forwards the data packet directly if the
destination vehicle is its direct neighbour. However, if the
destination vehicle is unreachable (i.e., not a direct neigh-
bour), RTAR selects the best road to forward the packet
through, by executing Algorithm 2 (IARR). References to
Algorithm 2 line numbers are used in this section to ex-
plain the algorithm workflow.

Destination
C Vehicle
G

D H

T1(1) B F
T1(2)

Next E
A Forwarder

Source
Vehicle

Fig 1 Data packet forwarding within a road based on RARR algorithm (case1).

Destination
C Vehicle
G

D H

T1(1) B F
T1(2)

Next
Forwarder A E

Source
Vehicle

Fig 2 Data packet forwarding towards intersection based on RARR algorithm (case2).

IEEE Intelligent transportation systems magazine • 66 • spring 2018

 The main concept of IARR is to forward data packets
through the best adjacent road and reliably choose a NF
from the selected road. To choose a neighbour in a reliable
way, the neighbour’s predicted position and average RSSI
value are considered as well as the recentness of the re-
ceived neighbour’s mobility information (i.e., the reception
time of the recently received beacon message). This is to
give priority to the neighbours that sent their mobility in-
formation recently, thereby reducing the probability of for-
warding packets to unreachable neighbours. For adjacent
roads evaluation, the RTNSM process, introduced in [29], is
employed to provide the lightweight road evaluation (LRE)
results for each of the adjacent roads. As mentioned previ-
ously, the LRE result represents the road status in terms
of vehicular traffic density, inter-vehicle connectivity and
network load.
Initially, to select the best road, the CF evaluates each
adjacent road, which it does not have its valid LRE results,
except the road where the packet came from (lines 4–7, Al-
gorithm 2). After receiving the roads’ LRE results, the CF
calculates the roads scores based on Equation 2 (line 8-ten,
Algorithm 2), whereas b 1 and b 2 are the weighting factors
for the two routing metrics, namely the road’s LRE result and
the progressive distance ^PDh towards destination. The
weighting factors represent each of the two routing met-
rics significance in calculating the roads scores, whereas
b 1 + b 2 = 1 . The sensitivity analysis of the weighting fac-
tors values is discussed in Section III-C. The calculated
road score value is in the range [0.0, 1.0] as both PD and
LRE result have values in the same range.
RoadScore = b 1 ·LRE result + b 2 ·PD (2)
The PD metric measures the distance progress that the
selected road contributes in the process of delivering data
packets to the destination. Thus, roads which make data
packet closer to the destination are given higher scores. The
PD is calculated using Equation 3, where Distance fromCTI
and Distance fromCI are the distance from Candidate Target
Intersection (CTI) to destination and distance from Cur-
rent Intersection (CI) to destination, respectively. CTI is
where the data packet should reach in case it is forwarded
through the associated road.
Distance fromCTI
PD = 1.0 - (3)
Distance fromCI
Afterwards, the CF sort adjacent roads based on their
calculated scores (line 11, Algorithm 2). Then, the road
with the highest score is considered first. Subsequently,
the PFG sameRoad of the considered road is formed by ap-
plying the same conditions introduced in Section III-A,
whereas the CTI of the considered road is the target point
(i.e., TP) (lines 12–16, Algorithm 2). Through inspecting
the PFG sameRoad of the considered road, the NF is selected
IEEE Intelligent transportation systems magazine •
as the closest neighbour to CTI that its beacon message
was received in the last beacon interval (lines 23–27, Al-
gorithm 2). In case such a neighbour is not available, the
NF is selected as the closest neighbour to CTI, which at
least one of its beacon messages was received in the last
two beacon intervals (lines 28–31, Algorithm 2). However,
if the considered PFG sameRoad does not include a neighbour
which fulfils any of the two conditions mentioned previ-
ously, the PFG sameRoad of the road with the second highest
score is formed and inspected. This process is repeated
until the CF selects a NF from one of the adjacent roads,
otherwise, the closest neighbour to the CI in the PFG CI set
is selected as NF (lines 43–47, Algorithm 2). The PFGCI set
includes the neighbours that satisfy the conditions men-
tioned in Section III-A, whereas CI is the target point (i.e.,
TP). In the case of not finding any neighbour that fulfils
any of the aforementioned selection criteria, the CF keeps
carrying the data packet until it finds a suitable NF (lines
48–50, Algorithm 2).
Accordingly, IARR forwards packets through the best
road in terms of road’s progressive distance towards the
destination and its traffic and network status. As RTNSM
provides accurate real-time road evaluation results, IARR
routing decision is highly adapted to changes in traffic
and network conditions. In addition, packet forward-
ing reliability is improved by considering the neighbours
predicted position, received RSSI values, and mobility in-
formation recentness. Moreover, since RTNSM produces
low network overhead, network congestion and transmis-
sion collisions are reduced, which leads to more reliable
packet forwarding.
C. Sensitivity analysis of weighting factors
This section presents the analysis of the weighting factors
values incorporated in the road score calculation process.
Equation 2 formulates the road score calculation, which
combines the values of LRE results and PD of the evalu-
ated road based on the weights of b 1 and b 2 . Basically, the
weighting factors are used to determine the percentage of
contribution for each component in calculating the road
score. Accordingly, the summation of the percentages of
contributions that b 1 and b 2 represent must equal to 100%
^i.e., b 1 + b 2 = 1 h . For instance, considering the values of
b 1 = 0.5 and b 2 = 0.5 means that each of LRE results and
PD contributed by 50% in the calculation of the road score.
In general, there are no optimal ratios to be assigned to
b 1 and b 2 which give the best routing performance in all
scenarios. Therefore, the sensitivity analysis for b 1 and b 2
ratios is conducted to determine the most suitable values
for making routing decisions.
Three different weighting factors configurations are
evaluated to analyse the effect of b 1 and b 2 values on rout-
ing performance, where RTAR (0.2,0.8) corresponds to
the configuration of b 1 = 0.2 and b 2 = 0.8, RTAR (0.5,0.5)
67 • spring 2018
refers to the configuration of b 1 = 0.5 and b 2 = 0.5, and
RTAR (0.8,0.2) represents the configuration of b 1 = 0.8 and
b 2 = 0.2. These configuration are adopted from a previous
sensitivity analysis introduced in [19]. In particular, RTAR
(0.2,0.8) favors progressive distance and RTAR (0.8,0.2)
favors LRE results value while calculating the road score
value. The three considered configuration RTAR (0.2,0.8),
RTAR (0.8,0.2) and RTAR (0.5,0.5) are evaluated in terms of
packet delivery ratio and end-to-end delay in high and low
vehicular density scenarios.
Figure 3 shows the packet delivery ratio of the three
considered configuration in high and low vehicular den-
sity scenarios. In addition, Figure 4 depicts the end-to-end
delay of packet delivery for each of the evaluated configu-
rations. Accordingly, configuration RTAR (0.2,0.8) results
in better performance in terms of packet delivery ratio

100 100

98 98

96 96
Packet Delivery Ratio (%)

Packet Delivery Ratio (%)

94 94

92 92

90 90

88 88

86 86
RTAR (0.5,0.5)
84 84 RTAR (0.2,0.8)
82 82 RTAR (0.8,0.2)
80 80
2 4 6 8 10 12 14 16 2 4 6 8 10 12 14 16
Number of CBR Connections Number of CBR Connections
High Vehicular Density High Vehicular Density

Fig 3 Packet delivery ratio with various number of CBR connections under different RTAR configurations.

0.14 0.12
RTAR (0.5,0.5)
0.12 RTAR (0.2,0.8)
0.1
RTAR (0.8,0.2)
0.1
0.08
End-to-End Delay (s)

End-to-End Delay (s)

0.08
0.06
0.06

0.04
0.04

0.02 0.02

0 0
2 4 6 8 10 12 14 16 2 4 6 8 10 12 14 16
Number of CBR Connections Number of CBR Connections
High Vehicular Density High Vehicular Density

Fig 4 End-to-end delay for different number of CBR connections under different RTAR configurations.

IEEE Intelligent transportation systems magazine • 68 • spring 2018

and end-to-end delay in high ve-
hicular density scenario. This is
because in high vehicular den-
sity scenario the majority of roads Basically, to make routing decisions at intersections and
have high evaluations and provide forward data packets through the most reliable roads,
good connectivity, which reduces
the significance of selecting the RTAR exploits lightweight and accurate roads’ traffic and
road with highest road evaluation network status measurements.
result. In such a case, favouring
distance reduces the delivery delay
resulting in higher packet delivery
level. On the other hand, in low ve-
hicular density scenario, RTAR (0.8,0.2) produced the best performance is studied using 16 Constant Bit Rate (CBR)
performance in both packet delivery ratio and end-to-end connections, while varying data sending rate from 1.0 to
delay. This is due to giving higher preference to roads with 0.1 seconds. A CBR connection is established when a source
better traffic and network conditions even though such vehicle starts sending data packets (in constant bit rate) to a
roads may increase the routing distance, which is more destination vehicle through multi-hop communication. In
suitable for the highly dynamic VANETs environment es- some protocols the location services are merged with rout-
pecially in low vehicular density situation. ing process [32]–[34]. However, in this work it is assumed
Based on the results of Figure 3 and 4, it is obvious that that the destination vehicles’ position can be obtained by
each weighting factor has a positive and negative impact utilizing a location service system such as HLS or GLS [35].
on the performance of RTAR in different vehicular density Variety of scenarios are considered to evaluate the perfor-
scenarios. However, giving equal values to both weighting mance of RTAR in high, average and low vehicular den-
factors results in a more balanced influence of LRE results sities. In fact, high vehicular density reduces the vehicles
and PD, which contributes towards optimizing routing mobility speed, which results in more accurate predictions
decisions at intersections under different vehicular den- for vehicles positions and longer inter-vehicle link lifetime.
sity conditions. Therefore, b 1 and b 2 are assigned equal In addition, high vehicular density provides more alterna-
weights ^ b 1 = b 2 = 0.5 h, which gives equal importance tives while choosing the next hop. On the other hand, low
for both roads evaluations and progressive distance while vehicular density allows vehicles to move faster, which
making routing decisions in any vehicular density scenar-
io. In all subsequent simulations b 1 and b 2 are assigned
Table I. Simulation parameters.
uniform values which are equal to 0.5.

Parameters Values
IV. RTAR Performance Evaluation
In this section, RTAR routing performance is evaluated Simulation time 400 seconds
against the Traffic Flow-Oriented Routing (TFOR) proto- Mobility model Car following model
col [24] and Intersection-based Connectivity Aware Rout-
Vehicular Density High density (40-50 vehicle/km/lane)
ing (ICAR) protocol [22], in terms of packet delivery ratio Average density (13-16 vehicle/km/lane)
(PDR) and end-to-end delay. The implementation and eval- Low density (6-8 vehicle/km/lane)
uation phases of this research involved the usage of OM-
Maximum vehicle speed 60 km/h
NET++ 4.6 [30] as a network simulation environment along
with SUMO [31] for urban traffic mobility simulation. The Beacon interval 1 seconds
protocols evaluation is carried out based on the simulation N con 12 vehicles
parameters in Table I. As RTAR, TFOR, and ICAR are all
Payload size 512 bytes
intersection-based routing protocols, part of Manhattan
map (latitude: 39.1912 to 39.1839 and longitude: –96.5737 MAC layer protocol IEEE 802.11p
to –96.5629) is used to emulate vehicles movement in ur- Transport layer protocol UDP
ban areas. The map data and structure is obtained from Network layer protocol IPv6
OpenStreetMap contributions. The area of simulation map
Propagation model Two Ray Ground reflection
is approximately 2000 m # 2000 m with 112 bidirection-
al roads and 64 intersections. In addition, the real traffic Transmission range 300 m
regulations (e.g., traffic lights, speed limits and traffic pri- Channel capacity 18 Mbps
orities), which are applied in that part of Manhattan city,
Transmission Power 20mW
are also considered in the vehicular traffic simulation. The

IEEE Intelligent transportation systems magazine • 69 • spring 2018

results in short inter-vehicle links lifetime and unreliable
packet forwarding. Each value in the results graphs is the
average of 10 values recorded through 10 simulation repe-
titions. In addition, the confidence intervals are calculated
and included in all graphs, whereas 95% confidence level
is considered.
A. Packet Delivery Ratio
For the high vehicular density scenario, Figure 5 illus-
trates the behaviour of the three simulated protocols in
high ­vehicular density, while varying the sending rate from
0.1 to 1.0 seconds. It is obvious that RTAR has the highest
PDR, as an average of 29% improvement is achieved in de-
livering data packets; while considering the fastest send-
ing rate. Moreover, Figure 5 shows that faster data sending
rates (e.g., sending data packet every 0.1 or 0.2) has less
95
90
Packet Delivery Ratio (%)
effect on RTAR performance in comparison with existing
schemes. This is due to using the lightweight RTNSM pro-
cess for evaluating roads, which reduces the roads evalu-
ation overhead.
Considering the average vehicular density scenario,
RTAR, ICAR and TFOR packet delivery ratio is presented as
a function of packet sending rate in Figure 6. By analysing
the graphs of Figure 6, it can be deduced that in compari-
son to the existing schemes RTAR has achieved the highest
packet delivery ratio, which scored an average improve-
ment of 11%. In particular, the performance of ICAR and
TFOR degrades with faster data packet sending rates (i.e.,
from 0.4 to 0.1 seconds), while the performance of RTAR
remains in a relatively stable situation. This is because of
avoiding to choose unreachable neighbours and reducing
the number of trials while sending a data packets, which
loosen network load impact.
Figure 7 depicts the behaviour of RTAR, ICAR and TFOR
in the scenario of low vehicular density; while considering
different packet sending rates. Based on the presented re-
sults, it can be inferred that RTAR has superior performance

85
in comparison to the existing schemes as it attained 15%
80
average improvement. In low vehicular density scenarios,
75 the network is less congested and there is lower contention
70 on transmission channels as fewer vehicles are exchanging
beacon messages. Accordingly, the main cause for packet
65
loss in low vehicular density is the rapid movement of vehi-
60 TFOR cles. Therefore, with the developed algorithms of IARR and
ICAR
55 RARR, RTAR maintained a PDR around 90%, while ICAR
RTAR
50
and TFOR had an average PDR of 80%. This is due to apply-
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 ing the multi criteria selection while choosing the next hop,
Data Packet Sending Rate (s) which increases the forwarding process reliability.
Based on the provided simulation results in this sec-
Fig 5 Packet delivery ratio in high vehicular density scenario. tion, it can be concluded that RTAR achieved a distinguished

100 100

95 95
Packet Delivery Ratio (%)

Packet Delivery Ratio (%)

90
90
85
85
80

80 RTAR TFOR
75 ICAR
ICAR
TFOR RTAR
75 70
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Data Packet Sending Rate (s) Data Packet Sending Rate (s)

Fig 6 Packet delivery ratio while varying data packet sending rate in Fig 7 Packet delivery ratio while varying data packet sending rate in low
average vehicular density scenario. vehicular density scenario.

IEEE Intelligent transportation systems magazine • 70 • spring 2018

­ erformance in terms of PDR as compared to existing
p gation, the performance of RTAR still needs to be tested
work, especially in the low vehicular density scenario. This
is due to employing the IARR and RARR algorithms, which
reliably choose a next-forwarder by considering multiple
criteria. As a result, more priority is given to neighbours
with high RSSI and more updated mobility information;
while considering the difference between roads and in-
tersections areas routing. In addition, IARR utilized the
LRE results as roads status evaluations, which are used
as traffic awareness metric while making routing deci-
sions at intersection areas. Accordingly, RTAR forwards
data through more reliable roads, which have the high-
est average inter-vehicle link life time, lowest network
load and highest vehicular density moving in the packet
forwarding direction. In high vehicular density scenario
the RTNSM process generates higher network load than
low or average vehicular density scenario [29]. Therefore,
the PDR value in high density scenario is lower than that
achieved in low or average density scenarios. Moreover,
as in low vehicular density scenario the network is not
congested, the only cause for packet loss is the poor received
signals or out of date neighbours mobility information.
Nevertheless, RTAR succeeded in reducing the effects of
these two factors through introducing IARR and RARR al-
gorithms and improved the PDR in low vehicular density
scenario remarkably.
As can be observed from the simulation parameters in
Table I, the used propagation model is considered simple
and less realistic. The reasons for choosing such propaga-
tion model are: 1) to avoid loosing packets due to signal
propagation issues; and 2) to focus on addressing the prob-
lems neighbours mobility information freshness and the
position of the next forwarder (in street or intersection).
Therefore, to be able to analyse the effects of signal propa-
0.6
TFOR
0.5 ICAR
RTAR
End-to-End Delay (s)
0.4
0.3
0.2
0.1
0 0
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Data Packet Sending Rate (s)
Fig 8 End-to-end delay for various data packet sending rates in high
vehicular density scenario.
IEEE Intelligent transportation systems magazine •
while considering a more realistic propagation model.
B. End-to-End Delay
For the high vehicular density scenario, RTAR, ICAR and
TFOR are compared in terms of their average consumed
end-to-end delay in Figure 8. RTAR achieved 70% aver-
age reduction of end-to-end delay at sending rate equals
to 0.1 seconds. This is due to the reliable routing decision
of RTAR that exploits the road evaluations provided by
RTNSM, which produces low routing overhead. As a result,
the number of attempts to transmit a data packet is reduced
as well.
Figure 9 shows the average end-to-end delay for RTAR,
ICAR and TFOR of the average vehicular density scenario
simulations. Based on Figure 9, it is obvious that RTAR
has a lower end-to-end delay in comparison to existing
schemes, especially when network load is increased. More
precisely, in comparison with the existing schemes, RTAR
has achieved an average of 11% reduction of end-to-end
delay with a sending rate of 0.1 seconds. Actually, in aver-
age vehicular density there are less vehicles to forward the
packets and their movement is faster than the high density
scenario. However, as RTAR employs a multi criteria selec-
tion for the next-hop it is more adaptable to such dynamic
environment than existing schemes. Moreover, consider-
ing the recentness of the neighbours mobility information
prevents using outdated mobility information, which reduces
errors in neighbours positions predictions.
Considering the low vehicular density scenario, Fig-
ure 10 describes the performance of RTAR, ICAR and TFOR
in terms of the average end-to-end delay for delivering a
packet. It is obvious that RTAR has slightly higher end-
to-end delay than ICAR and TFOR, which reached an ­average
0.1
0.09 TFOR
ICAR
0.08 RTAR
End-to-End Delay (s)
0.07
0.06
0.05
0.04
0.03
0.02
0.01
1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Data Packet Sending Rate (s)
Fig 9 End-to-end delay for various data packet sending rates in average
vehicular density scenario.
71 • spring 2018

0.1
TFOR
0.09 ICAR
RTAR
End-to-End Delay (s)
0.08
0.07
0.06
0.05
0.04
0.03
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Data Packet Sending Rate (s)
Fig 10 End-to-end delay for different for various data packet sending
rates in low vehicular density scenario.
i­ncrement of 17%. This is because RTAR attempts to for-
ward data packets through reliable roads even though
such roads might be longer in distance, which increases
the routing distance and end-to-end delay. Moreover, RTAR
aims to increase the next forwarder selection reliability
which may increase the number of hops. However, this
slight increment in end-to-end delay comes as a price for
the significant improvements that RTAR exhibited in terms
of packet delivery ratio.
By studying the end-to-end delay graphs of this section,
it can be concluded that RTAR succeeded in minimizing
the delivery delay, especially in the high vehicular density
scenario. This is achieved through the reliable routing of
RTAR, which considers neighbours predicted positions, the
received RSSI values, the recentness of the mobility infor-
mation received from neighbours, and the current position
of CF whether it is in a road or intersection area. However,
in the low vehicular density scenario, optimum roads for
reliably delivering data packets might not be the shortest.
Therefore, increasing the reliability of data packets deliv-
ery slightly increases the end-to-end delay in low vehicu-
lar density cases. The performance evaluation of RTAR was
performed over a relatively small area of Manhattan city.
However, in our future work a larger area is going to be
considered to evaluate the scalability of RTAR.
V. Conclusion
As TAR protocols utilize traffic status while selecting roads
for packet routing, they are considered a promising solu-
tion for urban VANETs environment. However, most of
the existing TAR protocols adopted the greedy forwarding
mechanism, which selects next forwarders based on dis-
tance. As a result, such protocols have low performance in
IEEE Intelligent transportation systems magazine •
the highly dynamic networks of vehicles. Therefore, this
research work addressed the issue of greedy forwarding
and improved the reliability of traffic aware routing by in-
troducing the RTAR protocol. Basically, to make routing de-
cisions at intersections and forward data packets through
the most reliable roads, RTAR exploits lightweight and ac-
curate roads’ traffic and network status measurements.
In addition, the two algorithms RARR and IARR are intro-
duced, which perform the next-hop selection at roads and
intersection areas respectively. Moreover, RTAR selects for-
warders based on multiple criteria, which considers neigh-
bours predicted positions and their RSSI values as well as
the recentness of the received mobility information from
neighbours. Consequently, forwarding data to unreachable
1 neighbours is eliminated which leads to more reliable data
packet forwarding and enhanced routing performance.
For future work, this protocol needs to be examined while
considering a more realistic evaluation environment with
a more complicated signal propagation models. In addition,
RTAR can be improved and tested to access infrastructure
networks over multi-hop communications.
Acknowledgment
This work has been done under the Post-doctoral Fellow-
ship Scheme of Universiti Teknologi Malaysia for the proj-
ect:” Big data analysis on vehicular networks for intelligent
transportation systems”
About the Authors
Tasneem S. J. Darwish is a researcher
of Universiti Teknologi Malaysia under
the Post-doctoral Fellowship Scheme for
the project:” Big data analysis on ve-
hicular networks for intelligent trans-
portation systems”. She is a member
of the Pervasive Computing research
group. She received her B.Sc. degree in computer engineer-
ing from Islamic University of Gazah in 2005 and M.Sc. de-
gree in electronics and electrical engineering from the
University of Glasgow, United Kingdom, in 2007. She re-
ceived her PhD degree in computer science in 2017 from
Universiti Teknologi Malaysia. From 2008 to 2013 she was
working as a research and lecturer assistant at the Faculty
of applied engineering, University of Palestine. Her current
research focuses on vehicular communications, wireless
ad hoc networks, and mobile computing.
Kamalrulnizam Abu Baker is a profes-
sor in Computer Science at Universiti
Teknologi Malaysia (UTM), Malaysia,
and a member of the Pervasive Com­­
puting research group. He received his
B.Sc. degree in computer science from
the Universiti Teknologi Malaysia (UTM),
72 • spring 2018
Malaysia, in 1996, M.Sc. degree in computer communica-
tions and Networks, from Leeds Metropolitan University,
United Kingdom, in 1998, and his Ph.D. degree in computer
science from Aston University, United Kingdom, in 2004.
His research interest includes mobile and wireless com-
puting, ad hoc and sensor networks, information security
and grid computing. He is a member of ACM and Interna-
tional Association of Engineering. He involves in many re-
search projects and is a referee for several scientific journals
and conferences.
Khalid Haseeb (received his M.Sc. de-
gree in information technology from In-
stitute of Management Sciences, Pakistan.
He completed his Ph.D in computer sci-
ence from Faculty of Computing at Uni-
versiti Teknologi Malaysia in June 2016.
During Ph.D, he was a member of the
Pervasive Computing research group. Since 2008, he works at
Computer Science Department, Islamia College Peshawar,
Pakistan. His research areas include sensors and ad-hoc net-
works, network security, cloud computing and mobile com-
munication. He is a reviewer for many reputed international
journals and conferences.
References
[1] F. A. Silva, A. Boukerche, T. R. M. B. Silva, L. B. Ruiz, E. Cerqueira, and
A. A. F. Loureiro, “Vehicular networks: A new challenge for content-deliv-
ery-based applications,” ACM Comput. Surv., vol. 49, no. 1, pp. 11:1–11:29,
June 2016.
[2] D. Naboulsi and M. Fiore, “Characterizing the instantaneous connec-
tivity of large-scale urban vehicular networks,” IEEE Trans. Mobile
Computing, no. 99, pp. 1–1, 2016.
[3] G. Yan and S. Olariu, “A probabilistic analysis of link duration in ve-
hicular ad hoc networks,” IEEE Trans. Intell. Transport. Syst., vol. 12,
no. 4, pp. 1227–1236, Dec. 2011.
[4] R. Du, C. Chen, B. Yang, N. Lu, X. Guan, and X. Shen, “Effective urban
traffic monitoring by vehicular sensor networks,” IEEE Trans. Veh.
Technol., vol. 64, no. 1, pp. 273–286, Jan. 2015.
[5] S. Zeadally, R. Hunt, Y.-S. Chen, A. Irwin, and A. Hassan, “Vehicular ad
hoc networks (vanets): Status, results, and challenges,” Telecommun.
Syst., vol. 50, no. 4, pp. 217–241, 2012.
[6] F. Malandrino, C. Casetti, C. F. Chiasserini, C. Sommer, and F.
Dressler, “The role of parked cars in content downloading for vehicu-
lar networks,” IEEE Trans. Veh. Technol., vol. 63, no. 9, pp. 4606–4617,
Nov. 2014.
[7] Y. A. Daraghmi, C. W. Yi, and I. Stojmenovic, “Forwarding methods
in data dissemination and routing protocols for vehicular ad hoc net-
works,” IEEE Network, vol. 27, no. 6, pp. 74–79, Nov. 2013.
[8] S. M. Bilal, C. J. Bernardos, and C. Guerrero, “Position-based routing
in vehicular networks: A survey,” J. Netw. Comput. Appl., vol. 36, no. 2,
pp. 685–697, 2013.
[9] B. Karp and H. T. Kung, “GPSR: Greedy perimeter stateless routing for
wireless networks,” in Proc. 6th Annu. ACM Int. Conf. Mobile Comput-
ing Networking, New York, 2000, pp. 243–254.
[10] T. Darwish and K. Abu Bakar, “Traffic aware routing in vehicular ad
hoc networks: Characteristics and challenges,” Telecommun. Syst.,
vol. 61, no. 3, pp. 489–513, 2016.
[11] C. Zhao, C. Li, L. Zhu, H. Lin, and J. Li, “A vehicle density and load
aware routing protocol for vanets in city scenarios,” in Proc. Wireless
Communications Signal Processing Int. Conf., Oct. 2012, pp. 1–6.
[12] G. Li, L. Boukhatem, and S. Martin, “An intersection-based QOS rout-
ing in vehicular ad hoc networks,” Mobile Netw. Appl., vol. 20, no. 2,
pp. 268–284, 2015.
IEEE Intelligent transportation systems magazine •
[13] C. C. Lo and Y. H. Kuo, “Traffic-aware data delivery strategy for ve-
hicular ad hoc networks,” in Proc. 17th Int. Conf. Advanced Communi-
cation Technology, July 2015, pp. 18–22.
[14] T. Darwish, K. A. Bakar, and A. Hashim, “Green geographical rout-
ing in vehicular ad hoc networks: Advances and challenges,” Comput.
Elect. Eng., 2016.
[15] V. Naumov and T. R. Gross, “Connectivity-aware routing (car) in ve-
hicular ad-hoc networks,” in Proc. 26th Int. IEEE Conf. Computing
Communications, May 2007, pp. 1919–1927.
[16] A. Benslimane, S. Barghi, and C. Assi, “An efficient routing protocol
for connecting vehicular networks to the internet,” Pervasive Mobile
Comput., vol. 7, no. 1, pp. 98–113, 2011.
[17] H. Hashemi and S. Khorsandi, “Load balanced vanet routing in city
environments,” in Proc. 75th IEEE Vehicular. Technology Conf., May
2012, pp. 1–6.
[18] Y. Xiang, Z. Liu, R. Liu, W. Sun, and W. Wang, “GEOSVR: A map-based
stateless {VANET} routing,” Ad Hoc Netw.(Special Issue on Theory,
­Algorithms and Applications of Wireless Networked Robotics and Re-
cent Advances in Vehicular Communications and Networking), vol. 11,
no. 7, pp. 2125–2135, 2013.
[19] M. Jerbi, S.-M. Senouci, T. Rasheed, and Y. Ghamri-Doudane, “To-
wards efficient geographic routing in urban vehicular networks,”
IEEE Trans. Veh. Technol., vol. 58, no. 9, pp. 5048–5059, 2009.
[20] S. Bilal, S. A. Madani,, “Enhanced junction selection mechanism for
routing protocol in vanets,” Int. Arab. J. Inform. Technol., vol. 8, no. 4,
pp. 422–429, 2011.
[21] N. Alsharif, S. Céspedes, and X. Shen, “ICAR: Intersection-based con-
nectivity aware routing in vehicular ad hoc networks,” in Proc. IEEE
Int. Conf. Communications, June 2013, pp. 1736–1741.
[22] N. Alsharif and X. Shen, “ICARII: Intersection-based connectivity
aware routing in vehicular networks,” in Proc. IEEE Int. Conf. Com-
munications, June 2014, pp. 2731–2735.
[23] Y. He, C. Li, X. Han, and Q. Lin, “A link state aware hierarchical road
routing protocol for 3D scenario in vanets,” in Internet Vehicles Tech-
nologies Services, Series Lecture Notes in Computer Science, vol. 8662,
R.-H. Hsu and S. Wang, Eds. New York: Springer International, 2014,
pp. 11–20.
[24] I. A. Abbasi, B. Nazir, A. Abbasi, S. M. Bilal, and S. A. Madani, “A traffic
flow-oriented routing protocol for vanets,” EURASIP J. Wireless Com-
mun. Netw., vol. 2014, no. 1, pp. 1–14, 2014.
[25] C. Li, C. Zhao, L. Zhu, H. Lin, and J. Li, “Geographic routing protocol
for vehicular ad hoc networks in city scenarios: A proposal and analy-
sis,” Int. J. Commun. Syst., vol. 27, no. 12, pp. 4126–4143, 2014.
[26] Y. Sun, S. Luo, Q. Dai, and Y. Ji, “An adaptive routing protocol based on
QOS and vehicular density in urban vanets,” Int. J. Distrib. Sens. Netw.,
vol. 2015, pp. 5:5–5:5, Jan. 2015.
[27] R. Akamatsu, K. Obara, and H. Shigeno, “Road-oriented geographic
routing protocol for urban vehicular ad hoc networks,” in Proc. 29th
Int. IEEE Conf. Advanced Information Networking Applications Work-
shops, Mar. 2015, pp. 721–726.
[28] T. Darwish and K. A. Bakar, “Traffic density estimation in vehicular ad
hoc networks: A review,” Ad Hoc Netw., vol. 24, Part A, pp. 337–351, Jan.
2015.
[29] T. Darwish and K. Abu Bakar, “Lightweight intersection-based traffic
aware routing in urban vehicular networks,” Comput. Commun., vol. 87,
pp. 60–75, 2016.
[30] A. Varga. (2009). Omnet++. [Online]. Available: http://www.omnetpp.org/
[31] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker, “Recent devel-
opment and applications of SUMO: Simulation of Urban MObility,” Int.
J. Adv. Syst. Meas., vol. 5, no. 3&4, pp. 128–138, Dec. 2012.
[32] R. Khadim, A. Ennaciri, M. Erritali, and A. Maaden, “Coupling of
geographic location-based service and routing for wireless sensor
networks,” in Proc. Int. Arab Conf. Information Technology, 2016,
pp. 1–7.
[33] M. Ayaida, M. Barhoumi, H. Fouchal, Y. Ghamri-Doudane, and L.
Afilal, “Joint routing and location-based service in vanets,” J. Parallel
Distrib. Comput., vol. 74, no. 2, pp. 2077–2087, 2014.
[34] S. M. Das, H. Pucha, and Y. C. Hu, “Performance comparison of scal-
able location services for geographic ad hoc routing,” in Proc. 24th
Annu. IEEE Joint Conf. Computer Communications Societies, 2005, vol. 2,
pp. 1228–1239.
[35] M. Ayaida, H. Fouchal, L. Afilal, and Y. Ghamri-Doudane, “A comparison
of reactive, grid and hierarchical location-based services for vanets,” in
Proc. IEEE Vehicular Technology Conf., 2012, pp. 1–5.

73 • spring 2018