Opportunistic Trajectory-based Routing for V2V

Communications

Huy Ngoc Dau and Houda Labiod

Institut TELECOM, TELECOM ParisTech & LTCI-UMR 5141 CNRS

46 rue Barrault, 75634 Paris Cedex 13, France

Email: {huy.dau, houda.labiod}@telecom-paristech.fr

Abstract—In this paper, we propose enhanced Simple Forwarding

over Trajectory (eSIFT), a novel opportunistic trajectory-based

routing protocol for Vehicular Ad hoc Networks (VANETs),

based on Simple Forwarding over Trajectory (SIFT). eSIFT is

designed to operate in highly dynamic vehicular networks for

data dissemination. eSIFT presents advantages such as no

discovery step and low overhead. We also present performance

evaluation results of eSIFT, in comparison to SIFT. Simulations

show that eSIFT improves SIFT, in particular in term of delay,

and slightly in term of hop count and packet delivery ratio.

Keywords-Vehicular ad hoc network; routing;

opportunistic;timer trajectory-based, local forwarding node

selection.

I. INTRODUCTION

Vehicular communications are becoming more and more important. Vehicles are now mostly equipped with GPS devices which guide drivers to their destinations easily by using GPS signals and preloaded maps. Intelligent Transportation Systems (ITS) are developed in the context where drivers’ needs involve more services such as: emergency, collaboration mobility, e-payment, internet access, etc. However, constraints in vehicular environment such as high mobility level, dynamic network topology may cause some issues to routing, e.g. bad delivery ratio, high latency, etc. To cope with these issues, we introduce eSIFT, a novel routing protocol which deals with both V2V and V2I communications. eSIFT is a new approach which is a combination of opportunistic and trajectory-based approaches. We have adopted the opportunistic approach as it may adapt to dynamic nature of vehicular networks, in which nodes have high level of mobility, whereas trajectory-based approach assures that a packet gets to its destination without a discovery step.

In section II we describe some background works on opportunistic and trajectory-based routing protocols. Section III is dedicated to eSIFT along with its enhancements compared to SIFT [1]. Performance evaluation results are presented in section IV. Finally, in section V we give some concluding remarks.

II. BACKGROUND

As enhanced Simple Forwarding over Trajectory (eSIFT) is based on opportunistic routing and trajectory-based routing approaches, in this section, we give some brief introductions about these two routing approaches.

A. Opportunistic routing

In opportunistic routing, the next forwarder along the path is not pre-defined, but is chosen dynamically for each packet and each hop from the actual circumstances. Therefore an opportunistic routing protocol is said to be a real-time routing protocol. The best qualified neighbor according to a certain criterion becomes the next forwarder. Due to its characteristics, opportunistic routing may have advantages over classical routing in dynamic environment like VANETs, such as: lower end-to-end delay, lower hop count hence lower resources required. The use of opportunistic routing is actually quite novel in vehicular networks, yet it has proved to be promising as shown by the experimental results. TO-GO, MOVE are two opportunistic routing protocols.

Topology-assist Geo-Opportunistic routing in Urban Vehicular Grids (TO-GO) [2] is an opportunistic routing protocol based on actual 2-hop topology information to select the next forwarder. The protocol proposes an enhanced beacon format that a node has to broadcast periodically in order to keep other nodes informed about its neighbors, furthest neighbors, and also each neighbor’s neighbors. Using this information, a forwarding node decides whether to forward to a junction node, or to bypass it and forward to the furthest neighbor node. Different from Greedy Perimeter Coordinator Routing (GPCR) [3] which always forwards to junction nodes where all routing decisions are made, TO-GO bypasses junctions and forwards directly to the furthest node if this furthest node is in the same direction as the best direction.

Figure 1. Forwarding hops: TO-GO (dashed arrows) vs GPCR (solid arrows)

2011 IEEE 22nd International Symposium on Personal, Indoor and Mobile Radio Communications

978-1-4577-1348-4/11/$26.00 ©2011 IEEE 783

TO-GO seems to outperform the typical GPCR in term of hop count and thus has a better delay.

Motion Vector (MOVE) [4] makes use of actual trajectory vector piggy-backed on the HELLO-RESPONSE messages. If a node tends to move closer to the destination than the transmitter, which means it has smaller distance from its current trajectory to the destination, then the node will become the next forwarder.

Figure 2. MOVE: node N is the next hop of current node C, as both nodes

are moving towards destination D, but dN - N’s closest distance to D is smaller than dc - C’s closest distance to D

MOVE is a simple routing scheme, it does not take into account the road topology to make decision, which may cause a groping situation where a node never gets close to the destination as expected.

B. Trajectory-based routing

Routing paths, defined by sequence of forwarding nodes, are unstable due to topology changes, while geographical routes, defined by road segments, are quite stable due to the physical characteristics of the service area. Trajectory-based routing mechanisms exploits this basic observation proposing a position-based routing scheme that requires the source node to encode a geographical trajectory, into the packet header. To our knowledge, not many vehicular routing protocols exploit this trajectory-based approach.

Mobility-centric Data Dissemination algorithm for Vehicular Networks (MDDV) [5] is a trajectory-based routing protocol where messages are forwarded by certain nodes along a pre-defined trajectory. These nodes are called “message heads”. MDDV proposes the use of a “message head pair”: message head’s location and the correspondent time. This is in fact extra information piggy-backed in the message. MDDV assumes that all the nodes moving along the trajectory and having received a message form a cluster. “Message head pair” can be received by all other nodes in the cluster due to some link layer mechanism. As the message is broadcasted periodically by “message heads”, a node can determine the message heads’ actual location. This allows a group of vehicles closed to the real “message head” to consider themselves as “message heads” and therefore reinforce delivery reliability.

When a message head leaves the trajectory or receives the same message from another node, it becomes a non-message head. MDDV also adopts a store and drop mechanism to

determine whether MDDV should drop a message which is usually stored upon its overhearing in every vehicle.

Although MDDV may suffer from a problem of high overhead due to a group of message heads broadcasting periodically, the protocol has an interesting trajectory-based approach which utilizes the static road network topology information to generate metrics as input for the Dijkstra path selection algorithm.

Having studied these routing protocols which may suffer from bad progression (MOVE), unreachable destination (MOVE, TO-GO), or high overhead (MDDV), we propose eSIFT which aims to cope with these problems.

III. ESIFT

In [1], we have proposed SiFT, a broadcast routing approach in which packets get forwarded only by nodes located along a trajectory determined by the source node. The protocol is dedicated to vehicular emergency applications and can support different communication types: unicast, multicast, broadcast. SiFT has the advantage of low overhead, however throughout its performance evaluation results, SiFT suffers from latency issue in some cases. We aim to overcome these issues by proposing a new eSIFT, which combines opportunistic and trajectory-based routing approaches.

Similarly to a trajectory-based routing protocol, eSIFT pre-defines the forwarding trajectory in packet header, similarly to source routing. As an opportunistic routing protocol, eSIFT does not pre-define nodes responsible for packet forwarding, but eliminates the control overhead as there is no signaling between nodes in order to select the next hop. The forwarding decision is in fact a distributed contention process between the last forwarder’s neighbors thanks to the broadcast nature of radio transmission: each node that receives a broadcasted packet computes a timer based on its own position, the last forwarder’s position and the trajectory. The node with first expired timer forwards the packet. Upon reception of the forwarded packet, other nodes stop the timer and identify the packet as forwarded. By this way, eSIFT has the advantages of no control overhead and no neighborhood information maintenance, due to a local selection procedure. To our knowledge, the combination of opportunistic, trajectory based approaches and local selection procedure in VANETs is quite new. In addition, a simple recovery from failure procedure is also proposed.

eSIFT provides three main procedures: trajectory encoding, packet forwarding, and recovery from failure.

A. Trajectory Encoding

Along with the packet ID and the coordinates of the last forwarder, the trajectory is encoded in the packet header as a sequence of points corresponding to segments’ ends. Thus, an eSIFT data packet header is constituted by the following fields:

PKTID: packet ID, which is unique within the entire network, usually obtained from MAC address of the source and a sequence number

LFN-X, LFN-Y: position coordinates of the last forwarder, updated each time the packet is forwarded.

784

Any intermediate node can know the position of the last forwarder without exchanging any control message.

SN: number of segments in the trajectory

AR: array of segment ends, in which each element is position coordinates of a segment end, encoded by 2 parameters: X, Y. The number of elements is equal to SN + 1.

B. Packet Forwarding

We analyzed nodes’ progression with SiFT and find out some incorrect routing behavior using (1), described in [1]. In fact, in cases where a node’s distance to the trajectory is very small, or even zero, even though little progression towards the destination is made and there are other potential forwarder nodes making much better progression, it may still be chosen as next forwarder as its timer is really close to (or is equal to) zero:

(1)

C’s better candidate

zone

DL

DT

C

A

Trajectory

B’

B

D

Figure 3. SiFT forwarding with timer formula (1)

Figure 3 shows an example of such case: although C is pretty close to the trajectory and makes good progression towards the destination D, B and B’ are really close to the sending node A, but are situated in C’s better candidate zone.

We modify the formula (1) so that nodes making good progression can be chosen over close-to-trajectory-but-little-progression-making nodes.

First, we make a little change on the DL parameter: a node receiving a packet will calculate the timer with respect to the straight segment in which the node is located as follows:

(2)

Where:

DT: distance from node to trajectory

DLp: projection of the distance from node to the transmitter on the trajectory, whereas in (1) DL is the distance between the actual node and the last forwarder.

α: environment adaptation constant

According to (2), the next forwarder should be the best candidate who is at the time close to the trajectory and makes

long forwarding progress along the trajectory. The traversed road segments are not included in the packet to be forwarded in order to save network throughput. The best candidate forwards the packet when its timer expires. Upon reception of a packet corresponding to one pending in the buffer, a node stops its corresponding timer as it knows that the packet was forwarded by another node. Every potential forwarding node stores the packet ID to avoid unnecessary further processing upon reception of the same packet ID, either to prevent duplications or routing loops.

Thereafter, by introducing a parameter β into the formula, we eliminate the nodes making bad progression from the better candidate zone of node making good progression.

C’s better candidate

zone

C

-β

Trajectory

(0,0)

x

y

B

D

A

DLp

DT

Figure 4. eSIFT forwarding with timer formula (3)

With this optimization, we assure that a packet can go further at each hop, thus reduces the hop count, which also means lower resources and better delay.

As formula (3) adds an extra delay to the timer due to parameter β, we implement a threshold Th to determine whether to use (2) or (3) in each situation. If the node makes a smaller progression than the threshold, then it will use (3) to overvalue its timer. On the other hand, nodes making larger progression than the threshold will use (2) so that their timers are not added an extra delay, which elevate their priority over nodes close to the last forwarder. The threshold parameter is thus smaller than nodes’ communication range.

C. Recovery from failure procedure

When a packet is forwarded, unchosen forwarder candidates extract the new forwarder’s location information from the forwarded packet, thanks to the broadcasting nature of wireless network. If a node finds out that it makes more progression towards the destination than the last forwarder, it will arm a recovery timer which is short enough for the node to capture any forwarded packet. Apparently, these unchosen “next-hop candidates” cannot forward. However, in case where there is no “next-hop candidates” for the latest forwarder, nodes making better progression towards the destination should join the recovery phase as they can reach further than the last forwarder. In this recovery phase, we use only the progression as criterion for choosing the node to perform the retransmission, for the following reason: nodes further than the last forwarder along the trajectory should not be far from the trajectory, as the last forwarder is expected to make good progression, assumed to be larger than half the transmission

785

range’s radius. Thus if we consider the transmission range a circle where the transmitter is the center, then the potential recovery nodes should be in the smaller circular segment whose chord is perpendicular to the trajectory and passes through the last forwarder.

The furthest node among these nodes will be “chosen”, after its recovery time expires, similarly to the selection process of the next forwarder.

y

x

S1

2 3

Trajectory

4

Figure 5. Recovery procedure example

An example is illustrated on figure 5. Node (1) is the next forwarder of S, as it makes good progession and is close to the trajectory, but it does not have any other nodes to forward the packet. Meanwhile, (2) was not chosen to forward, but it makes better progession than (1). (2) is thus chosen to perform the recovery procedure. Then the packet can continue to be forwarded by (3) situated in (2)’s communication range.

With the proposed recovery mechanism, we guarantee not only no extra overhead between the last forwarder and the recovery node, but also the packet can reach further along the trajectory in case there is no “next-hop” candidates in transmission range of the latest forwarder.

IV. PERFORMANCE EVALUATION

We used traffic simulator VanetMobiSim and network simulator ns-2 to analyze the performance of eSIFT, in comparison with SIFT in term of latency, packet delivery ratio (PDR) and hop count.

TABLE I. SIMULATION PARAMETERS SETTINGS

Parameters Values

Simulator NS-2

Traffic Simulator VanetMobiSim

Simulation time 1000s

Simulation runs 10

Simulation area 3000 x 1000 m²

Transmission range 50-500m

Vehicle speed 2-20 m/s

Packet rate 1 packet/s

Vehicle density 20-50 vehicles/km

Mobility model IDM-LC

Packet size (Application Layer) 50 bytes

α 0,001

β 5

Th 150 m

MAC protocol IEEE 802.11

Table I shows the simulation parameters settings. Vehicles

travel in a 3 km² city section over a set of urban roads. The destination node was placed 2 kilometers away from the source node, and both are static nodes.

For the first simulations, the average speed is set to 10 m/s. Transmission range is set to 250 meters. We vary the vehicle density from 20 vehicles / kilometer to 50 vehicles / kilometer.

Figure 6. Latency vs Density

Figure 7. PDR vs Density

Figure 8. Hop count vs Density

As the density increases, both protocols’ latency slightly increases in order where eSIFT’s latency is around 8 percent lower. There is almost no difference in term of PDR, where both curves get close to 100 percent rapidly but then converge from 40 vehicles / kilometer. eSIFT has slight better hop count than SIFT.

786

Next, we vary the transmission range from 50 meters to 500 meters. Average speed is set to 10 m/s. Vehicle density is set to 30 vehicles / kilometer.

Figure 9. Latency vs Range

Figure 10. PDR vs Range

Figure 11. Hopcount vs Range

As the communication range increases, both protocols’ latency decreases in order where eSIFT’s latency is around 8 percent lower. There is almost no difference in term of PDR and hop count. Both PDR curves get close to 100 percent rapidly but then converge from 300 meters. Hop counts decrease as the communication range increases.

We also vary the average speed from 2 m/s to 20 m/s. Vehicle density is set to 30 vehicles / kilometer. Transmission range is set to 250 meters.

Figure 12. Latency vs Speed

We can see that speed does not have much impact on the performance parameters, except for PDR, where the maximum is 95 percent at 5 m/s, but gets down to 74 percent at 20 m/s.

Figure 13. PDR vs Speed

Figure 14. Hopcount vs Speed

Throughout all these scenarios, simulations show that eSIFT outperforms SIFT in term of latency: the latency is reduced by around 9 percent. In term of PDR and hop count, eSIFT performs slightly better.

V. CONCLUSION

In this article, we have presented eSIFT, a novel trajectory-based and opportunistic routing protocol which has many advantages over classical VANET routing protocols such as no control overhead, no routing table needed for vehicles that are equipped with localization device and preloaded maps. Also, eSIFT presents improvements comparing to SIFT, which aims at achieving a better delay performance, and lower used resources.

In term of perspective, we plan to continue the evaluation where we will experiment more parameter effects on the protocol and vary environments characteristics. Comparison with other vehicular routing protocols trajectory-based and opportunistic will also be considered.

REFERENCES

[1] H. Labiod, N. Ababneh, and M.G.D.L. Fuente, "An Efficient Scalable Trajectory Based Forwarding Scheme for VANETs", in Proc. AINA, 2010, pp.600-606.

[2] Kevin C. Lee, Uichin Lee, Mario Gerla, "TO-GO: TOpology-assist Geo-Oppertunistic Routing in Urban Vehicular Grids", WONS 2009, Snowbird, Utah, February, 2009.

[3] C. Lochert, M. Mauve, H. Füßler, and H. Hartenstein, "Geographic routing in city scenarios", presented at Mobile Computing and Communications Review, 2005, pp.69-72.

[4] Jason LeBrun, Chen-Nee Chuah, Dipak Ghosal, Michael Zhang,. “Knowledge Based Opportunistic Forwarding in Vehicular Wireless. Ad Hoc Networks,” IEEE VTC 2005 Spring, Stockholm, Sweden.

[5] H. Wu, R. M. Fujimoto, R. Guensler, M. Hunter, “MDDV: Mobility-Centric Data Dissemination Algorithm for Vehicular Networks,” ACM Workshop on Vehicular Ad Hoc Networks (VANET), October 2004.

787