End-to-End Routing Through a Hybrid Ad Hoc Architecture for V2V and V2I communications

N.Brahmi (1), L.Boukhatem (2), N. Boukhatem (3), M. Boussedjra (1)

N. Dau Nuy (3), H. Labiod (3), J.Mouzna(1)

(1) IRSEEM-ESIGELEC, St Etienne du Rouvray, France, {n.brahmi, boussedjra}@esigelec.fr 2) Centre de Recherche en Informatique, Université Paris-Sud XI - CNRS, France, lila.boukhatem@lri.fr

(3) Telecom ParisTech, Telecom Institute, France, {labiod, boukhatem}@telecom-paristech.fr

Abstract— The routing problem in Intelligent Transportation Systems is one of the main objectives of TRAFIC project. TRAFIC is a research and industrial initiative which aims to contribute to the global academic and industry effort in this area. In this paper, we focus on TRAFIC Efficient Routing approach proposed as a solution for end-to-end routing problem to support V2V and V2I communications.

Keywords-component; ITS, VANETs, routing, dynamic environment, hybrid, V2V, V2, trajectory-based routing, decision-based routing, ITS services, non-ITS services.

I. INTRODUCTION

Designing an Intelligent Transportation System (ITS) has drawn a significant interest from the research and industrial communities over the last few years. Indeed, the increase in traffic accidents and driving fatalities has urged the authorities on finding a way to improve the road safety and anticipate hazardous situations. As a consequence, many research projects like “CarTALK2000” [1], “COOPERS” [2], “SAFESPOT” [3] and “TRAFIC” rose from this need to investigate safety related issues and design cooperative systems for an optimized road traffic. They took advantage of the rapid advances in wireless technologies that enable inter-vehicular communications (IVC) and vehicle-to-infrastructure communications (V2I). Hence, the data exchange between nearby vehicles is made possible using short-distance connections spontaneously created as the need arises. The moving vehicles can form networks on the fly without any preinstalled infrastructure. These self-organizing networks known as Vehicular Ad hoc NETworks or VANETs have emerged as a specialization of MANETs. Their flexible and low cost deployment makes them attractive.

Furthermore, VANETs offer the opportunity for a variety of innovative applications that will ensure the road safety and improve the conditions of drivers and passengers [4]. Typically, potential vehicular applications defined in the literature can be classified as safety (ITS) and non safety (non-ITS) applications [5]. First, safety applications include traffic monitoring and control, cooperative driving and prevention of collisions. They mainly intend to increase the overall safety

and efficiency of the transportation system. On the other hand, new infotainment services can be offered for the comfort of both drivers and passengers by means of a variety of broadband services and commercial applications. For instance, through vehicular communications people can query for remote services provided in nearby regions (e.g., parking availability) or request for useful information to make a better travel plan. Moreover, applications such as instant messaging and file sharing between moving vehicles can be easily supported in such context.

Based on their requirements, vehicular applications can also be categorized into two groups: infrastructure-assisted applications and purely ad-hoc applications [6]. The first group relies on deployed infrastructure in order to connect vehicles to roadside Internet gateways or centralized servers. Purely ad-hoc applications such as accident warning are designed to perform even in the absence of infrastructure. They require reliable and decentralized communication schemes to guarantee the delivery of messages addressed to specific target receivers.

Common to all the aforementioned applications is the need for efficient routing schemes that ensure data delivery from sources to destinations. That is, when two vehicles are not within their respective transmission range, routing is required to establish communication between them. However, compared to other mobile ad hoc networks, the particular characteristics of vehicular environments make the design of routing protocols a very challenging task. For this reason, a great number of routing protocols are being developed to deal with routing issue in VANET networks. Geographic-based routing protocols have been proposed to support efficient and scalable routing for Ad hoc and sensor networks. Karp and Kung [7] proposed the GPSR (Greedy Perimeter Stateless Routing) that uses greedy perimeter forwarding method to select the next relaying node. The geographic distance routing (GEDIR) [8] uses a greedy approach to achieve efficient and loop-free data delivery (in a collision free-environment). These protocols perform very well in static ad hoc configurations but they were not initially planned for topology constrained and high mobility environments.

978-1-4244-8435-5/10/$26.00 ©2010 IEEE

Recently, routing in VANET has been extensively studied. In GSR [9] a geographic source routing approach is proposed. GSR extends the position based routing in a vehicular environment by considering topology information. The route chosen by GSR is based on the shortest distance in terms of intersection hops between source and destination. A basic greedy forwarding is used by vehicles to relay packets between intersections. CLA-S [10] is a connection-less routing protocol proposed for city environments which can adapt to network topology changes mainly caused by fast moving vehicles and the presence of large obstacles (buildings). A link quality estimation approach was developed in MURU [11] and GVGRID [12] which are two source routing protocols. They define a new metric for the quality of a network path and more specially the probability of disconnection. More recent protocols are cited in surveys papers including opportunistic, trajectory-based and epidemic routing protocols.

In this paper, we propose TRAFIC Efficient Routing Protocol (TERP) to ensure V2V and V2I communications. It is a hybrid protocol which uses, according to the situation of the network, a combination of unicast and broadcast/multicast communications. For example, for safety messages propagation TERP uses a broadcast mechanism to send the data. On the other hand, for infotainment applications unicast method could be used. The paper is organized as follows: Section II describes the TRAFIC hybrid architecture. Section III presents TERP and gives a brief description of three routing protocols studied in the context of TERP design. Section IV highlights some performance results. Finally, Section V concludes the paper.

II. TRAFIC COMMUNICATION INFRASTRUCTURE

TRAFIC project is a research and industrial initiative which aims to contribute to the global academic and industry effort to develop ITS systems. More specifically, TRAFIC defines a hybrid communication infrastructure that exploits the offered opportunities of inter-vehicle cooperation, as well as the advanced capabilities of communicating devices deployed along the roads.

TRAFIC hybrid infrastructure gathers several communication components: a network infrastructure and a vehicular network. The network infrastructure consists of a wired/wireless access network (such as Wi-Fi/DSRC access points, WiMAX access, 2G/3G access, etc.), a backbone, and a sensor network. The access network ensures connectivity between the vehicular network and the backbone. The sensor network helps in detecting fine granularity traffic and security statistics related to roads and vehicles conditions while the backbone ensures the IP connectivity and houses the value-added services offered to vehicle users. Note that the access network and the backbone can be operated by the same organization (telecommunication operator for example) or managed by different entities (road operator, telecom operator, ISP) through global agreements.

All collected information are returned to a control center (CC) for processing purposes and for taking the appropriate decisions to rapidly react to critical situations. The fine granularity of the collected data helps the CC in taking

proactive decisions which may be highly decisive in safety situations. The Figure 1 shows the global TRAFIC architecture.

Major particularities of TRAFIC project reside mainly in the original developed solutions to cope with the complexity of the dynamic VANET communication environment; namely the virtual link concept and the dynamic routing TERP.

The virtual link model was designed to deal with management issues related to the collective mobility of several communicating entities. Many ITS and non-ITS application scenarios rely on such grouped mobility, such as for example the coordination of emergency teams to converge to an accident site. Hence, we proposed that TRAFIC infrastructure, through the virtual link, would be the supporting framework to handle mobility management and data delivery issues for an efficient information exchange and coordination between the communicating entities.

The second proposal of TRAFIC is the dynamic routing protocol TERP. The main objective of TERP is to dynamically adapt to the communication environment changes and communication features (unicast, broadcast, and multicast) to launch the most appropriate routing routine. In this paper, we will first and foremost focus on TERP routing protocol, the description of the virtual link solution is beyond the scope of the paper.

Figure 1. TRAFIC communication architecture

III. TRAFIC EFFICIENT ROUTING PROTOCOL

TRAFIC Efficient Routing Protocol (TERP) uses the hybrid communication infrastructure proposed in TRAFIC. It defines an end-to-end efficient routing policy based on using two routing approaches: trajectory-based using SIFTv2 (SImple Forwarding over trajectory Version 2) protocol and dynamic decision based routing using LoP (LTT over Progress) and MAGF (Movement Aware Greedy Forwarding) mechanisms. The aim of TERP is to ensure the transport of information through the hybrid TRAFIC architecture and to allow continuity between V2V and V2I/I2V routing mechanisms. Depending on the role of the packet forwarder (source or intermediate nodes) and applications requirements, TERP selects the appropriate routing approach.

We have analyzed ITS and non-ITS applications and listed the key parameters which impact the choice of the type or

1111

1111

1111

routing approach to apply. Despite the fact and MAGF can be used in both safapplications, they still remain based on the sccan be done in order to optimize the ucommunication architecture. Through this noticed that the first key parameter to transmission type: point-to-point, broadcSIFTv2 is more powerful in the case of bapplications. Unicast transmission can besupported by LTT and MAGF. A secondistinguishes LTT and MAGF, it concerenvironment: LTT is adapted to urban scenardecision made at crossroads. MAGF can be or rural scenarios without necessarily using th

TERP at source side is represented in fthe different steps followed by the sourcepackets. The source node starts by analyzinrequirements and determines the more approach. Then, it specifies the routing typrouting type into the field Type_of_routing oFigure 2 illustrates a broadcast scenario exselected and its procedures are executedcalculated and inserted into the data packet This routing approach allows minimtransmission delay. During packet forwardinlet intermediate vehicles to identify the routithen each forwarder based on its selection mthe steps related to its routing protocol.

Figure 2. TERP – routing selection at Sou

In the following sections, we shortly routing protocols investigated in this paper.

A. SIFTv2

To take benefit of the hybrid TRAFICextended SIFT [13] protocol and we mechanism called SIFTv2. It comprises tw(V2V mode) for V2V communications a

that SIFTv2, LTT fety and comfort cenario choice that

use of our hybrid study, we have consider is the

ast or multicast. broadcast/multicast more efficiently

nd key parameter rns the vehicular rios with a routing used in highways

he infrastructure.

figure 2 describing e to transmit data ng the application

adapted routing pe by inserting theof the sent packet. xample. SIFTv2 is d, a trajectory is

before sending it. mizing end-to-end

g, the routing type ing protocol to use

metrics will execute

urce node

address the three

C architecture, we specified a new

wo modes: SIFTv2 and SIFTv2 (V2I

mode) for V2I/I2V communicaSIFT and highlights the process

The first version of SIFcommunications without using faced when the maintenance successfully deliver a data pathis drawback, we extended SIF

Shifting from one mode variations that can occur inillustrates some of such situpriority messages that requiresorder to meet delay constraifailure due to loss of connectivi

Figure 3. TERP with V2V Rou

Different from previously forwarding schemes, SIFT usepoint transmissions. Wireless nature and allow reaching possame time. Moreover, the forwthe transmitter to the receiverpacket takes the decision wheonly on its own position, thtrajectory. This greatly reducesthe protocol and energy consumSIFT includes two phases:

• The trajectory computimplemented by the Cand it is only executsending a new packet fcannot be invoked by isource-based and thus by the source node. Thto compute the trajectofor the first time triggprocess.

ations. In this section, we resume s of SIFTv2.

T is dedicated to pure V2V the infrastructure. A problem is procedure ‘Recovery’ fails to

acket to neighbors. To alleviate FT into SIFTv2.

to another mode is tied to n the environment. Figure 3 uations like dealing with high s going through infrastructure in ints or maintenance procedure ity.

uting and V2I/I2V Routing modes

proposed trajectory based es broadcast instead of point-to-

transmissions are broadcast in sibly all active neighbors at the

warding decision is shifted from r. Each node that receives the

ether to forward it or not based he transmitter position and the s control overhead introduced by mption. To support its functions,

tation phase: The first phase is Compute_Trajectory procedure, ted by the source node before for the first time. This procedure intermediate nodes since SIFT is trajectories are established only

he intention behind this phase is ories and to send the messages gering the multihop forwarding

• The packet forwarding phase: The second phase is implemented by the Forward procedure, which is invoked by each intermediate node when receiving a data packet that passes through the networks on its way towards its destination. The intention behind this phase is to decide, at each intermediate node, on whether to forward the packet or not.

Once received a packet, each node sets a timer according to its position with respect to the trajectory and the transmitter. If a copy of the packet, forwarded by another node, is received before the timer expires, the timer is stopped and the packet is deleted from the forwarding queue. Otherwise, the packet is passed to the Medium Access Control (MAC) layer for transmission when the timer expires. Therefore, the node with the minimum timeout value will forward the packet. It is the node in the best position since it is far from the last node and close to the trajectory. If the node is located within the admissibility strip margins (i.e., distance to trajectory admissibility strip threshold), then the distances from node N to the trajectory (DT) and from node N to LF (last forwarder) are calculated as follows:

Forwarding contention may occur when all one-hop neighbors of node LF try to forward the packet P. SIFT resolves this contention by enforcing each node to delay its broadcast of packet P for a timeout value TMR. Each node chooses a delay value based on its location with respect to the trajectory and to the LF. A node closer to the trajectory with longer distance to LF generates a smaller TMR value. At the end of the delay, the node broadcasts the packet to its one-hop neighbors. The TMR value is set as follows:

Where, is an environment adaption constant, and PD is the packet propagation delay.

Packets include into the header the trajectory and the coordinates of the last node that forwarded the packet. The original source identifier, a sequence number, and a hop count are included as well. Each node maintains a list of recently received packets (i.e., source ID and sequence number) to avoid cycles.

In SIFTv2 (mode V2V) we define a new packet structure which includes two new fields: ‘Type_of_routing’ and ‘type’ to indicate if the message is urgent or not.

Here, we propose an extension to SIFT, which enables Vehicle-to-Infrastructure (V2I) communications to detect and overcome forwarding failures. SIFTv2 (mode V2I) mechanism comprises two procedures: a forwarding procedure and a discovery procedure.

When a node n forwards a message M, it starts a backup timer T. If message M is not received again by node n before timer T expires, it means that node n has no neighbors or

message M was not received by any other node. In this case, node n changes the routing mode to V2I and forwards message M to the nearest access point to the infrastructure (for example access points (APs) in Wi-Fi hybrid based architecture). When the message is received at the designated AP it forwards it to the next available AP in the way towards the destination node through the control centre (a supervision key entity, which manages the whole network including the backbone infrastructure and the ad hoc part). After, the AP broadcasts the message M (i.e., return on road) and message M is delivered by intermediate vehicles to the destination in Vehicle to Vehicle (V2V) fashion. Each AP node periodically broadcasts HELLO messages to inform the nearby vehicles about it. Such a message is a packet containing the following: AP ID, AP status, AP location and list of APs in region. Upon reception of HELLO messages, a node (i.e., vehicle) can gather information about APs in the neighborhood. Such information must be refreshed periodically to detect the changes in the topology. Each node updates its local knowledge about its neighbors APs with each received HELLO message. Such information is considered valid for a limited period of time, and must be refreshed periodically to remain valid. Expired information is purged from the AP table. Each AP sets a timeout value Td to determine how long it should wait before it broadcasts its neighbor’s information. To ensure every moving vehicle can communicate with the nearby APs within the HELLO message exchange period, we define the timer Td as follows:

After Td expires, the AP broadcasts a HELLO message. Upon reception of HELLO message from an AP, nearby vehicles synchronize their information about neighbor APs in region with the current AP.

B. LTT OVER PROGRESS (LoP) ROUTING LoP1 module is executed when the key routing decision is

in favor of a point-to-point communication in an urban environment. LoP relies on TRAFIC communication infrastructure and more specifically the road side Access Points (APs) deployed at road intersections. The APs can communicate with the vehicles within their coverage range and have knowledge of their local road topology (each AP knows its neighboring APs). The key role of TRAFIC infrastructure here is to support the vehicle network in making the best routing decisions using a delay metric called LTT (Link Transport Time).

LoP is an intersection-based routing which dynamically adapts routing by taking decision at each intersection based on more accurate and up-to-date local information on road segments connectivity and their traffic load state. The key idea of LoP is to provide an estimation of the real-time latency (LTT) between two adjacent intersections when using V2V communications which in other terms reflects the packet delivery delay. Using this latency metric, the routing protocol

1 LoP routing protocol has been designed with the collaboration of Prof. Ivan Stojmenovic, SITE, University of Ottawa

can choose at each intersection the road segment which ensures the minimum latency toward the next intersection.

LoP routing main objectives are: i) avoid intersection based source routing since the route optimality can be rapidly lost due to high vehicles mobility, ii) take advantage of TRAFIC infrastructure which provides static nodes on which vehicles can rely to estimate the packet delivery delay on each road, and iii) use more accurate estimations of the road delivery time than classical statistical information such as average vehicle density and speed limitation.

Before describing LoP protocol, recall that the same basic assumptions as previously mentioned in other TERP modules are made, namely a location service is available and all APs and vehicles are assumed to be equipped with GPS devices and digital road maps. Let S be a source vehicle which aim at sending packets to a destination vehicle D.

1) LTT estimation Link Transport Time of road segments is derived to help in

routing decisions at intersection. This delay is estimated by recent historical data of vehicles that just traversed the road segment by carrying the time of last encounter with AP at previous intersection.

LTT time implicitly reflects several parameters: vehicles density, vehicles distribution on the road, and data channel load. Vehicles density and distribution represent the vehicular network connectivity and the data channel load is related to the load of the multi-hop communication on the concerned road segment.

To estimate the LTT value of each road segment, every AP of the network needs to broadcast periodically a LTT-Beacon information to vehicles in its transmission range. The LTT-Beacon packet contains three main information: the identifier of the AP source APi, the current transmission time Tt (which for a receiving vehicle will constitute the time of encounter with APi), and the current LTT values toward each neighboring AP. The vehicle can then either carry Tt time or transmit it greedily to the vehicles ahead that are progressively closer to the next APj on the road. Note that Tt information can be either sent in a specific LTT message or piggybacked in Hello packets. The next vehicle receiving the Hello/LTT message first checks that the carried Tt value is more recent than its buffered one, in which case a new Hello/LTT packet is immediately generated and the new Tt is stored. Otherwise, the old Tt value is sent in periodic Hello/LTT packets. Tt information is propagated from vehicle to vehicle until it reaches the destination APj. APj can then simply derive the packet delay time LTTi,j between APi and APj as follows (assuming AP synchronization using GPS facilities):

trji TTLTT −=, (1)

where Tr is the reception time of the Hello/LTT packet announcing a new Tt value at the destination APj. Note that LTT asymmetry can be resolved using wired/wireless direct TRAFIC connections between APs or by piggybacking LTTi,j value in data packets transmitted in opposite direction (from APj to APi).

The LTT estimation procedure is performed periodically by each APi to derive the LTT delays toward each neighboring AP. The different LTTs are then broadcasted by APi in the LTT-Beacon message to help vehicles within range in their intersection routing decision.

2) LoP routing phases The LoP routing includes two basic phases: 1) dynamically

selecting a route by choosing at each intersection the best road segment in terms of packet delivery delay, 2) efficiently forwarding packets using V2V communications through each selected road segment.

a) Forwarding between two intersections Forwarding through road segments is achieved using a

simple greedy forwarding approach. Each vehicle node makes a decision for choosing the best packet relaying vehicle based only on the location of itself, its neighboring nodes, and the next AP destination. Forwarding in this scheme follows successively closer geographic vehicles until the next AP is reached. Since network partitioning can occur (no possible forwarding vehicle), a carry-and-forward approach is used.

b) Routing decision at intersections When a forwarding vehicle A reaches an intersection, it

receives the current APi LTT-Beacon. This means that A should execute the intersection routing process to select the best road segment (and thus the next AP) toward the destination D. We assume that APi is connected to n neighboring APs through n road segments.

Vehicle A uses a Cost-over-Progress (CoP) function based on LTT metric and the achieved progress toward the final destination D. The CoP function is taken by vehicle A of a road segment between APi and a neighboring APj is defined as follows:

0,,

, >−<

−=

i

ji

i

jiji dd

thresholdLTTLTTdd

LTTCoP (2)

where LTTi,j is the link transport time between APi and APj, d (respectively di) is the distance separating APi (respectively the neighbouring APj) from the destination node D, and LTT threshold represents the maximum sustainable value before declaring a lack of connectivity between the two APs.

Equation (2) estimates the cost of all road segments leading closer to D and having acceptable LTT metric. Finally, the selected next AP is the one which minimizes the cost function. Formally, the CoPi function is defined as:

jinji CoPCoP ,,1min == (3)

CoPi function gives to vehicle A, at intersection i, the identity of APj that should be used as next AP destination. Then, vehicle A executes the greedy forwarding previously detailed using APj as next AP destination. The two routing phases are repeated until final destination D is reached.

The CoPi function may fail in deriving a result if either no progress is possible or LTT is greater than LTT threshold for all the links outgoing from APi. In this case, a simple repair mechanism can be adopted by keeping the packets at the APiside until a new refreshed LTT value allows the cost function

to derive a solution. To avoid a long packets buffering at AP, we define a Maximum Buffering Time (MBT) parameter which increases the LTT threshold value to accept higher LTTs.

Note that this version of LoP has been extended to take into account an estimation of the packet delivery delay over two or three AP hops. Obviously the optimal solution is that all APs exchange their LTTs toward all network APs just as performed in link state routing protocols. However, this solution will suffer from the large overhead (LTT updates) due to high vehicles mobility which strongly impacts the packet delivery delays.

C. MOVEMENT AWARE GREEDY FORWARDING (MAGF) This section describes Movement Aware extension of the

Greedy Forwarding strategy (MAGF) used by TERP. MAGF includes the speed and the direction of the vehicle’s movement in order to optimize the routing decisions. It also exploits the concept of the lifetime representing the link duration between moving nodes to address the inaccuracy of the traditional position-based routing.

1) Assumptions MAGF assumes that every vehicle can easily obtain its

accurate position as well as its velocity and its direction through the navigation system. Typically, in a self-organizing ad hoc network like VANET, each vehicle learns about the existence of its neighboring nodes through the exchange of periodic beaconing messages known as HELLO messages. In MAGF, we assume that a Hello message, in addition to the vehicle’s position, includes the speed and the direction of the vehicle.

We also suppose the availability of a location service through which a source node can retrieve the destination’s information. The design of a location service is out of concern in this work; we consider that many location approaches had already been proposed in the literature [14], although this issue remains under hot discussions.

2) MAGF overview Our routing approach MAGF is based on the Greedy

Forwarding strategy with consideration of nodes movements. It is designed to match the high mobility requirements and to perform even in cases of pure Greedy Forwarding failure. The core idea of this approach is to define a function to assign priority between neighbours while selecting a next hop forwarder. The function is a weighted score which depends on three factors: the position, the speed and the direction of the mobile node. This score, called Wi,, is computed by the current packet’s forwarder for a neighbour i as follows:

mmmi SDPW γβα ++= (4) Here, we consider α , β and γ the weights of the three used

metrics Pm, Dm, Sm representing, respectively, the position, the direction and the speed factors with α +β +γ = 1.

First, the position factor is designed to favor the selection of the nodes making the highest progress towards the

destination. As shown in the figure 2, according to the position metric selection node j should be preferred to node i.

Figure 4. Graphical representation of the position factor influence

In order to ensure the selection procedure described below, a position function measuring the progress of a node i toward the destination is defined. The progress Pr is the distance between the source and the projection of the node i on segment [SD] connecting source to destination and it is given by:

c

cm D

ddDP

2

2'22 ++= (5)

where Dc is the closest distance from the source to the destination, d and d’ are the distances separating intermediate node i from the source and the destination, respectively (see Figure 2).

Hence, the target position metric is defined while comparing the progress value to the distance between the source and the destination.

cm DP Pr/= (6) Such a definition of the position metric assures that priority

is given for the nodes which are closer to the destination.

The direction factor is defined to select the optimal direction of forwarding by choosing the nodes moving towards the destination:

≤=elsewhere

ifCosD m0

2)(2 πθθ (7)

where θ is the angle between the movement direction of the intermediate node and the straight line connecting it to the destination.

The speed factor is chosen to favor among all neighbors, the node moving with the highest speed. For a node moving with a speed iV it can be computed as:

MinMaxMinvdiff

VdiffNormS iim −

−==

)())(( (8)

where Max and Min represent, respectively, the maximal and minimal values among all the speed factors computed for all the neighbours of node i. diff represents the difference of speeds between the node i and the source S:

diff ( vi ) = vi − vs (9)

The obtained values of diff are normalized to ensure getting a speed metric value included into the interval [0, 1] same as the position and the direction metrics.

Afterwards, a sorted list of next hop candidates can be defined based on the computed score Wi: the node with the highest weighted score among all the neighbors of the current forwarder will be selected as the best candidate to relay the packet.

However, before forwarding a packet, the packet’s carrier has to check the validity of the selected neighbour. To address this issue related to the high mobility of nodes, we exploit the concept of the link lifetime. The lifetime defines the duration for which a node remains in the radio range of the forwarder. We applied the mobility prediction method defined in [15] to MAGF in order to avoid the selection of an out of range neighbour. In fact, using the movement parameters of two neighbour nodes, we estimate the duration of time these nodes remain connected. Thus, while selecting the next hop, based on lifetime metric, a node checks whether a neighbour is still on the communication range or not. If we consider, two nodes i and j, with a transmission range R, speeds vi and vj, coordinates (xi, yi) and (xj, yj), and movement direction angles i and j, respectively, the lifetime LT can be computed by:

22

2222 )()()(ca

bcadrcacdabLT

+

−−+++−= (10)

where

ji

jjii

ji

jjii

yyd

vvc

xxb

vv

−=

−=

−=

−=

θθ

θθ

sinsin

coscosa

By predicting the lifetime duration of the links connection only neighbours that are still within the transmission range will be considered as valid candidates for the next hop selection.

The following algorithm shows the detail of next hop selection in MAGF.

Notations: Cv: the current forwarding vehicle Nlist: the neighbor list of the current of the Cv Clist: the list of candidates for forwarding next hop Nexthop: the selected next hop to forward the packet Ni: a neighbor i

Algorithm A vehicle Cv receives a data packet Clist: empty list Nexthop = Null For each Ni in Nlist of do

Compute the weighted score Wi of Ni

Add Ni to the Clist End for Sort the Clist according to Wi (highest value first)

While (still candidate in Clist and Nexthop = Null) do Ci : head of Clist Get the lifetime LT of Ci

If LT > 0 then Nexthop = Ci

Break; Else

Remove node Ci from Clist

End While If (Nexthop Null) then

Forward the packet to Nexthop Else store the packet until its validity time expires End if

Figure 5. The procedure of the next hop selection in MAGF

IV. SIMULATION AND RESULTS To evaluate TERP performance, an implementation was

achieved and tested using ns-2 simulator. We have chosen several scenarios which are equally adapted to one of the three modules of TERP (SIFTv2, LoP, MAGF). Their performances are then compared to those of several reference protocols (GPSR, GSR, GOSR, DREAM) in a vehicular environment. For that purpose, several performance metrics were used such as the rate of successfully delivered packets, end-to-end delay from source to destination.

• SIFTv2 performance

In this section, we present our main findings. An extensive simulation runs has been carried out to analyze the two modes of SIFTv2, mode V2V and mode V2I in different urban scenarios and with various mobility models. Varying network size, distance between the source and destination nodes, communication range, traffic load and nodes’ speed we investigated packet delivery ratio, end-to-end delay, route length and control overhead. Firstly, the performance of SIFTv2 mode V2V is evaluated through simulation. It is benchmarked against a well-known and comparable position-based routing protocol, namely DREAM. Encouraging results are obtained. Indeed, the proposed scheme reduces the control overhead to zero and achieves a better delivery ratio and shorter route length in a grid-shaped urban scenario.

A comparison with GPSR and opportunistic routing protocol GOSR [16] revealed that SIFTv2 thanks to its two modes can reach better performance in urban environment. We also compared SIFTv2 (mode V2V) to flooding mechanisms (pure flooding and randomized-backoff flooding). We have seen that a broadcast technique as simple as flooding outperforms SIFTv2 scheme in case of high vehicle densities, while generating a significant large amount of network traffic overhead. SIFTv2 reduces this overhead while showing an acceptable end-to-end delivery delay. SIFTv2 performs better than pure flooding in high traffic load scenarios. It is able to deliver more emergency packets through shorter paths comparing to the other two flooding techniques.

• LoP performance

To highlight the efficiency of LoP intersection based routing, we compared LoP performance to GSR [9] routing scheme in a dense urban scenario with a high number of intersections. Recall that GSR uses a basic greedy forwarding scheme between vehicles on a route chosen based on the shortest distance in terms of intersection hops between source and destination. Both protocols implement the store-and-forward mechanism when no possible forwarding nodes exist. We

showed that LoP outperforms GSR in terms of packet delivery since LoP when using the LTT metric selects at intersections the less traffic loaded routes while avoiding routing holes. The GSR protocol performs poorly because the geographic shortest path suffers from either high traffic loads or frequent network disconnections. Note that even though we integrated the store-and-forward mechanism to GSR, it shows a lower performance than LoP. We finally showed that the performance of LoP is enhanced when considering two and three hops for LTT estimations. In terms of end-to-end delay, we can observe that LoP shows a lower end-to-end delay than GSR. The main reason for that is that the adaptive path selection in LoP reduces the inaccurate route density selection and forwards packets on the optimal local path. For GSR, since channel load and route connectivity are not considered, more network partitioning and packet buffering occur on the shortest path when forwarding the packets; leading to an increased delay.

• MAGF performance

MAGF is tested in urban scenario by considering a two-lane road where vehicles are moving in both the right and the left lane with opposite directions. Two scenarios are considered; one with a transmission range of 100m and the second with a transmission range of 250m, in order to verify if the setting of the weights (α ,β ,γ) depends on some parameters like the speed of vehicles and the radio range. Simulations showed that MAGF, with an optimized choice of weights values, outperforms GPSR protocol. This is due to the decrease of the local maximum cases which are avoided thanks to the movement awareness. However, the comparison of the performance of MAGF between the two scenarios demonstrates that the values setting depends on many parameters (the speed of vehicle, radio range…) and therefore, they should be adjusted to be adapted to the type of the application. Comparing the delay values to those obtained with GPSR, about 64 ms for scenario1 and 41 ms for scenario2, we observed that MAGF, with an adapted selection of the weights for different factors, outperforms GPSR. This is due to the avoidance of the perimeter mode that increases the delay in case of GPSR. Note that with the selected optimal values of weights, the delivery ratio of MAGF is still better than GPSR.

V. CONCLUSION

In this paper, we present a hybrid architecture defined in the context of French ANR project called TRAFIC. We focus on giving details about TERP end-to-end routing approach. We defined three protocols SIFTv2, MAGF and LoP. These mechanisms can meet different ITS and non-ITS application requirements: SIFTv2 is based on the broadcast paradigm and therefore can be used in safety applications like alarm message delivery. MAGF and LoP are mechanisms that offer unicast forwarding schemes and then are suitable to applications like conversational services or emails. The type of transmission constitutes a first element of the strategy used in TERP. A second element is the expected environment for service delivery. A last element is the urgency level of the delivery of

messages which has been taken into account in each proposed routing protocol. A common strategy is adopted by passing through the fixed infrastructure for the urgent message delivery. A combination between V2V and V2I/I2V communications is supported to deal with V2V routing failures.

References

[1] D. Reichardt, M. Miglietta, L. Moretti, P. Morsink and W.Schulz, "CarTalk 2000: Safe and comfortable driving based upon inter-vehicle communication", in Proc. of IEEE Intelligent Vehicle Symposium, 2002.

[2] COOPERS, Cooperative Systems for Intelligent Road Safety, available at http://www.coopers-ip.eu.

[3] SAFESPOT, available at http://www.safespot-eu.org. [4] H. Hartenstein, B. Bochow, A. Ebner, M. Lott, M. Radimirsch, and D.

Vollmer, “Position-aware ad hoc wireless networks for inter-vehicle communications: the fleetnet project,” in MobiHoc ’01: Proceedings of the 2nd ACM international symposium on Mobile ad hoc networking &computing. New York, NY, USA: ACM, 2001, pp. 259–262.

[5] Y. Khaled, M. Tsukada, J. Santa Lozano, and T. Ernst, “On the design of efficient Vehicular Applications,” in IEEE Vehicular Technology Conference, Barcelona Espagne, 2009.

[6] H. Moustafa, G. Bourdon, “Vehicular Networks Deployment View: Applications, Deployment Architectures and Security Means,” Ubiquitous Computing and Communication Journal, Special Issue on Ubiquitous Roads, March 2008.

[7] B. Karp and H. T. Kung, “Greedy perimeter stateless routing for wireless networks,” in MobiCom ’00: Proceedings of the 6th annual International Conference on Mobile Computing and Networking (Mobicom2000), Boston, USA, 2000, pp. 243–254.

[8] I. Stojmenovic, X. Lin, “GEDIR: Loop-free location based routing in wireless networks”, in IASTED Conference on Parallel and Distributed Computing and Systems, Nov. 1997, pp. 1025–1028.

[9] Mauve, M., Widmer, J. and Hartenstein, H., A survey of position-based routing in mobile ad-hoc networks. IEEE Network Magazine. v15 i6. 30-39.

[10] C. Lochert, M. Mauve, H. Fussler, and H. Hartenstein, “Geographic routing in city scenarios,” in ACM SIGMOBILE Mobile Computer Communications Review, vol. 9, no. 1, pp. 69–72, 2005.

[11] Z. Mo, H. Zhu, K. Makki, and N. Pissinou, “Muru: A multihop routing protocol for urban vehicular ad hoc networks,” IEEE Mobiquitous, pp. 1–8, 2006.

[12] W. Sun, H. Yamaguchi, K. Yukimasa, and S. Kusumoto, “Gvgrid: A qos routing protocol for vehicular ad hoc networks,” in Quality of Service, 2006. IWQoS 2006. 14th IEEE International Workshop on, June 2006, pp. 130–139.

[13] Labiod, H., Ababneh, N., and de la Fuente, M.G. "An Efficient Scalable Trajectory Based Forwarding Scheme for VANETs," In Proceedings of 24th IEEE International Conference on Advanced Information Networking and Applications (AINA'10), 2010.

[14] A. Ho, Y. Ho, and K. Hua, “A connectionless approach to mobile ad hoc networks in street environments,” in Proceedings of the IEEE Intelligent Vehicles Symposium, 2005, Las Vegas, USA, 2005, pp. 575–582.

[15] W. Su, S. J. Lee, and M. Gerla, “Mobility prediction and routing in ad hoc wireless networks,” Int. J. Netw. Manage, vol. 11, no. 1, pp. 3–30, 2001.

[16] Zhongyi, L., Tong, Z., Wei, Y., and Xiaoming, L., "GOSR: geographical opportunistic source routing for VANETs." SIGMOBILE Mobile Computing and Communications Review,13(1): p. 48-51, 2009.