LOTIR : A Routing Protocol for Multi-hop V-toI Communication Using Local Traffic Information

Vehicular Ad Hoc Network (VANET) is an emerging technology that can be applied to safety, transport efficiency, or infotainment applications for roads and highways. However, due to its unique features, such as dynamic mobility patterns and uneven distributions of vehicles, VANET faces many challenging research issues for robust data dissemination in the network. Many routing protocols have been proposed for VANET in the past few years, and the idea of utilizing a navigation system to assist the routing protocol for selecting the next best forwarder has become increasingly popular. However, it might not be realistic to assume that every vehicle is equipped with a navigation system. In addition, due to privacy concerns, drivers might not want to reveal their planned routes to other cars. In this work, we propose a new routing protocol, called LOTIR (LOcal Traffic Information Routing), that relies on only local traffic information and does not require the assistance of a navigation system. LOTIR is a DTN-based routing protocol that utilizes the car-following theory and traffic light information to decide the next carrier to forward the data to. We implement LOTIR in NS-2, and our results show that it can achieve similar performance as prior work which depends on the availability of global network topology information.


Introduction*
Vehicular Ad Hoc Network (VANET) is a technology that is becoming increasingly popular for improving road traffic safety and efficiency.However, VANET faces many research challenges due to rapid topology changes, short contact duration, and unstable wireless connections.Many routing protocols have been proposed for disseminating data in a VANET.Among these, some recent protocols, such as GeOpps [1] and GeoDTN+Nav [2], propose using the *Corresponding author.Email: jensen0915@gmail.cominformation from a travel guidance system (that provides a suggested route from the current position of the vehicle to the destination) to assist selecting the next best forwarder by acquiring the planned routes of a vehicle to predict its future position.While these studies have shown promising results, one obvious limitation of such a system is that not all vehicles are equipped with a navigation system.In addition, from the perspective of privacy, drivers might not want to reveal their planned routes to other cars.
In VANET, vehicles communicate with road-side units (V2I) as well as among themselves (V2V).V2I communication provides traffic conditions and safety information, such as traffic jam and accident warning, to avoid road congestion.In a V2I system, vehicles can send information to road-side units (RSU) through multi-hop routing to rapidly distribute information to a specific area [3].If the RSU has access to the Internet, it can further disseminate information from a remote entity (e.g., traffic control center) to support safety and infotainment applications.Many research projects, like CarTALK2000 [4], COOPERS [5], FleetNet [6], and SAFESPOT [7], use multi-hop V2I communication to investigate safety related problems and design cooperative systems, such as sending emergency messages, like accident information, to nearby RSUs, which further relay the messages to hospitals, police, and so on.When some vehicles are equipped with sensors, such a V2I system can also collect real-time sensor data from the environment.These data can then be used for air quality analysis or traffic congestion estimation [8].
Vehicle mobility patterns have a strong impact on the performance of VANET.Many factors could affect the movement patterns of vehicles, such as road speed limits, traffic lights, and driving behavior [9], [10], [11].For example, the existence of traffic lights can potentially cluster cars at intersections.Furthermore, car-following models have been extensively studied in the transportation research community [12], [13], and these describe how vehicles follow one another on a roadway.Normally, a vehicle will keep a minimum distance from the car in front to avoid collisions.In other words, if the leading car reduces its speed, the following vehicle will also need to slow down.Intuitively, if we assume that drivers typically want to arrive at their destinations in the shortest time possible and most follow the traffic regulations (such as road speed limits), when we observe that a car is traveling at a significantly lower speed than the speed limit, it is likely there is another vehicle in front of it.Note that here we do not consider car overtaking behavior in a multi-lane scenario.
In addition, cars generally do not reduce their speed on a roadway unless they are approaching some traffic incident (e.g., a traffic light, accident spot, lane merging, and so on).Considering a group of vehicles, when the leading car is approaching a traffic light, it might lower its speed to prepare to stop if the light is turning red, which might cause the following cars to also reduce their speed.In other words, if we observe a car is driving at a speed significantly lower than the road speed limit, it is possible that there are other cars in front it that are also driving at a lower speed.With circular inference, the above observation suggests that there might exist some cars distributed within the road segment between the observed car and the closest intersection with a traffic light.
If we assume that every intersection has a traffic light, two insights can be taken away from the clustering effect of traffic lights and the car-following behavior.First, the probability of finding a car near the intersection could be higher than that at other parts of a road segment.Second, a car driving at a lower speed might be a better candidate to forward the packet than a car driving at a higher speed, because the former is more likely to have other cars in front of it to help forward the packet further toward the destination.In this paper, we propose a routing protocol called LOTIR (using LOcal Traffic Information for Routing) by utilizing the above insight to select a more stable forwarding path to the destination.Previous protocols, such as GeOpps and GeoDTN+Nav, that use the suggested routes from a travel guidance system to determine the next hop by calculating the Minimum Estimated Time of Delivery (METD), which is the shortest distance between the vehicles' routes and the destination of the packet.In contrast, LOTIR utilizes only local traffic information, such as car location, speed, and direction to determine the next best forwarder.The contributions of this paper are threefold:  We propose a new routing protocol, LOTIR, which explores the insights of considering the effects of traffic lights and car-following theory.Our protocol relies on only local traffic information to find a stable forwarding path to the destination. We discuss the effects of different mobility patterns on the performance of our protocol. We show that LOTIR can achieve similar or better performance compared to prior work which requires knowledge of the global network topology.The remainder of this paper is structured as follows.In Section 2, we describe the related work.We then discuss the detailed implementation of LOTIR in Section 3 and evaluate its performance in Section 4. Finally, we conclude this paper in Section 5, and briefly describe the directions of our future work.

Related Work
Our work builds on prior work on the VANET routing protocol, Delay Tolerant Network (DTN) and car-following models.VANET is a special case of Mobile Ad Hoc Networks (MANET).Similar to MANET, nodes in VANET can self-organize into a network.However, VANET possess some special characteristics that are note present in MANET.For example, nodes in VANET do not move in any random direction and are constrained by the road topology.Moreover, in general, energy is not an issue in VANET (although this might change in the near future, when electric cars become more common).In addition, node speed is bounded by the road speed limit and the capacity of a vehicle.Intermittent connectivity is a norm and node contact time is limited in VANET.Because of these characteristics, it is inappropriate to directly apply protocols designed for MANET to VANET.
Many routing protocols for VANET have been proposed in the past few years.Generally, as shown in Fig. 1, they can be classified into two categories: topology-based and position-based routing.In the topology-based routing protocols, nodes maintain global topology information in order to determine the next forwarder.Such protocols can be further divided into proactive (table-driven), such as FSR [14], and reactive (on-demand) approaches, such as TORA [15], DSR [16], AODV+PGB [17].However, obtaining global topology information is difficult to achieve in practice, due to the dynamic nature of vehicle movements.On the other hand, in the geographic routing protocols, nodes share their geographic positions with each other.Upon receiving a packet, the node will choose the neighbor which is closer to the destination as the next forwarder.Position-based routing protocols can be further divided into three categories, non-DTN, DTN, and hybrid.

Non-DTN
These kind of geographic routing protocols do not consider cars' intermittent connectivity and are more suited to a densely populated VANET.They can be further classified into three types: with-beacon, no-beacon (e.g., CBF [19]), and hybrid (e.g., TO-GO [20]).In the with-beacon type, a node periodically sends its position information to all its one-hop neighbors and maintains a one-hop neighbor table.In contrast, in the no-beacon type, a node directly broadcasts data packets to all its one-hop neighbors.The with-beacon type can be separated into two cases: non-overlay based routing (e.g., GPSR [21], GPSR+AGF [17], and GRANT [22]) and overlay based routing (e.g., GPCR [23], GpsrJ+ [24], CAR [25], GSR [26], A-STAR [27], STBR [28], GyTAR [29], and LOUVRE [30]).In the first category, the packet forwarding might face an issue when no neighbor is closer to the destination or the forwarding path comes to a dead end.Therefore, these protocols typically need to provide a recovery strategy to deal with such a situation.On the other hand, such problems do not exist for the overlaybased protocols, since they can exploit nodes at intersections to help forward the packet.
Finally, some protocols, such as GyTAR, LOUVRE, and TOPO [31], choose the route with a higher traffic density (i.e., more congested roads) as the forwarding path.
While the above protocols show promising results, they all require knowledge of the global network topology.Similar to prior work, like GyTAR, our protocol also chooses road segments with a higher vehicle density (for better network connectivity and lower delay) when forwarding a packet.Similar to LOTIR, VPGR [32] and LD-CROP [33] were proposed for multi-hop V2I communication, in which a pre-loaded digital map [34] is required to provide the positions of RSUs.In VPGR, a source predicts a sequence of valid intersections from the source to the RSU using two-hop neighbors' information.VPGR defines 'valid intersections' as follows: the source first estimates the time duration during which a vehicle i remains within the radio range of intersection j.If this estimated duration is longer than the minimum duration required for forwarding a packet from vehicle i to intersection j, intersection j is then considered as a 'valid' intersection.On the other hand, in LD-CROP, the sender finds a route to RSU based on the minimum delay.Unlike the above non-DTN protocols, LOTIR is a DTN-based one that utilizes only local traffic information, such as car location, speed, and direction, to determine the next best forwarder.

DTN
These kind of geographic routing protocols (e.g., VADD [35] and GeOpps [1]) take node disconnectivity into consideration.In a DTN, a node can store packets and carry them for some distance until it encounters another node that can forward them.Lo et al. [36] proposed using nodes' motion vectors to select potential candidates for the next forwarder.Specifically, their protocols first check if the angle of two motion vectors is less than 90 degrees to select the candidate nodes.Among all candidate nodes, the one with the shortest distance from the destination will be chosen as the next forwarder.
FFRDV [37] divides a road into blocks so that one-hop communication can be realized in each block.This protocol selects the node which is the closest to the destination.On the other hand, LOTIR considers the node that has the shortest hop number to the next intersection as the potential next forwarder in order to find a stable forwarding path.GeOpps uses the suggested routes from vehicles' navigation systems to determine the next hop by calculating the Nearest Point (NP), which is the shortest distance between the vehicles' routes and the destination of the packet.For example, in Fig. 2, node S encounters two other cars, N1 and N2, at the intersection.N1 and N2's suggested routes are marked using blue and green lines, respectively.When node S wants to sends a packet to the destination, it first broadcasts a query to its neighboring nodes.After receiving the query, N1 and N2 compute their corresponding NPs which are NP1 and NP2, respectively, as shown in Fig. 2. N1 and N2 then estimate the Minimum Estimated Time of Delivery (METD) for the packet which is the travel time from S to NP, plus the time from NP to the destination.S will then pick the neighbor that has the smallest METD as the next forwarder.However, in reality, considering the issue of personal privacy, many drivers might not want to reveal their planned routes to other cars.VADD is a location-based routing protocol that is designed for a sparse network.The next forwarder is selected from cars that are driving toward the destination, and is the vehicle that has the lowest estimated delay to the destination.However, in order to estimate the delay of the forwarding path to the destination, VADD needs information such as the traffic density on different roads, average vehicle speeds on different roads at different times of the day, and the length of the red light cycle at intersections.Unlike GeOpps and VADD, in which global network topology information is required, LOTIR utilizes only local traffic information such as neighboring cars' location, speed, and direction, to determine the next best forwarder.GeoDTN+Nav considers metrics, such as the number of hops a packet has traveled so far, neighbor's delivery quality, and neighbor's direction with respect to the destination, to detect if a partition has occurred.GeoDTN+Nav uses the Virtual Navigation Interface (VNI) to estimate the route of a vehicle and the probability that the vehicle is following the route suggested by the navigation system.Car following models determine how vehicles follow one another on a roadway, in which a driver attempts to adjust his/her car speed to minimize trip duration and maximize safety.Burnham et al. [38] presented an optimal controller model and a look-ahead model for single-lane car following.Burnham and Bekey [39] proposed a driver behavior model based on a finite-state decision tree with which the driver calculates the acceleration required to accelerate or decelerate at each instant of time.Car following models are also used to classify different types of drivers [40].In this paper, we exploit the car-following behavior to infer vehicle density on a road segment.We assume that if a car is traveling at a significantly lower speed than the road speed limit, it is likely there is another vehicle in front of it.A road segment with a higher vehicle density might be a better path to forward the packet along.

Local Traffic Information Routing (LOTIR)
In this work, we assume that every vehicle is equipped with a Global Positioning System (GPS) device and pre-loaded digital map [34] which provides the coordinates of intersections and road-side units (RSU) for every road segment.Generally, people tend to drive at the maximum allowable speed in order to arrive at their destination sooner.Therefore, we assume that a vehicle will move at the maximum allowable speed when it is not blocked by other vehicles or traffic lights.Our protocol is based on the storecarry-forward concept to manage the intermittent connectivity between nodes.In this work, we consider a simple queue management scheme.The packet received by the node will be put in a queue in a First-In-First-Out order.Our protocol is designed as a routing protocol for multi-hop V-to-I communication for applications such as disseminating a current snapshot of traffic status [3,40,41,42,43].Every node periodically broadcasts a "hello" message to discover its neighbors and maintain a neighbor information table that records the position, speed and direction of neighboring nodes, as shown in Table 1.
LOTRI consists of two modes: straightway and intersection.When an intermediate node receives a data packet, it first stores the packet in its local storage, then it checks its current position.If its position happens to be at an intersection, the protocol enters the intersection mode.Otherwise, the protocol chooses the straightway mode.This process is repeated until the packet finally arrives at the destination, as shown in Fig. 3.

Straightway Mode
The straightway mode is similar to the concept of GPSR [21], in that the goal is to select a forwarder that can take the packet closer to the destination in order to reduce packet delivery delay.Specifically, the current packet carrier will first choose nodes that are driving toward the destination as potential candidates.Next, among the selected nodes, the node with the shortest distance from the destination will be chosen as the next forwarder.An overview of the straightway mode is shown in Fig. 4, while Fig. 5 shows an example, in which node 1 will be chosen as the next forwarder (here S and D are the source and the destination, respectively).

Intersection Mode
Similar to the straightway mode, in the intersection mode, we also first select neighboring nodes which are driving toward the destination.Given that these selected cars might be driving in different directions, we further group these cars based on this.For example, as shown in Fig. 6, we put nodes 1, 2, and 5 in one group and nodes 3 and 4 in another.
Next, as in the straightway mode, in each group we choose the node which has the shortest distance from the destination as the candidate node.For example, nodes 1 and 3 will be chosen as the candidate nodes in Fig. 6.The final task is to pick the next forwarder from the selected candidate nodes.This can be divided into three cases, as detailed below.Here we assume that, according to the car-following theory, if the candidate node drives at a significantly lower speed than the maximum road speed, it is possible that there are some cars in front of it.Note that, in our current work, we do not consider the car overtaking behavior.Therefore, from our routing protocol's point of view, the case for a multi-lane street with different speed limitations is same as the case of multiple single-lane streets with different speed limits, since the candidate node will be selected from the one with the highest speed that has the shortest time to arrive at the nearest intersection.Fig. 7 shows an overview of the intersection mode.In this case, we will select the candidate node that is driving slower than the maximum road speed as the next forwarder.For example, in Fig. 6, by comparing the car speed and the road speed limit, we predict that there is at least one car in front of node 1, but no car in front of node 3. Therefore, selecting node 1 provides a more stable path toward the destination, since it might be able to immediately forward the packet to the cars in front, while it is not known when node 3 will encounter another car.In other words, the probability of finding a next forwarder is higher for node 1 than it for node 3.

CASE 2-No candidate node driving slower than the maximum road speed
In this case, we will select the candidate node that arrives at the next intersection at the earliest time as the next forwarder.The idea is that, due to the clustering effect of traffic lights, as described in Section 1, we assume that it is likely that the selected candidate node can find the next forwarder at the intersection.Based on the neighbor information table, the current packet carrier can estimate the amount of time required for each candidate node to arrive at the intersection.The candidate node with the shortest time will be chosen as the next forwarder.

CASE 3-More than one candidate node driving slower than the maximum road speed
In this case, we will select the candidate node that takes the least number of hops to forward the packet to some other node at the intersection as the next forwarder.To estimate how many hops (H) are required to forward the packet to the intersection, we first need to know how many cars (C) are between the candidate node and the intersection.Based on the formula developed in prior research [45], [46], we compute the safety distance and average length of a vehicle.Specifically, Given a radio range, we can compute how many vehicles can be covered in one hop (U) and how many cars (C) are between the candidate node and the intersection.That is, . .
Here D is the distance between the current packet carrier and the next intersection.The candidate node that has the smallest number of hops H to reach the next intersection will be chosen as the next forwarder.

Performance Evaluation
To evaluate the performance of our protocol, we compare LOTIR with GeOpps, which uses the information (i.e., suggested route) provided by a travel guidance system to select the next forwarder.We implement a bundle layer in NS-2 [47] to simulate a DTN architecture.We use MOVE [48] to generate various vehicle mobility patterns.To simplify our analysis, we simulate a 4 x 4 grid topology that represents a 1600m x 1600m square area.The roads have two lanes and are bi-directional.We set up a traffic light at every intersection, so there are a total of 25 traffic lights in this road network.In our simulations, every vehicle is equipped with a 802.11 radio and a GPS receiver.The maximum possible radio transmission range for 802.11 is set at 250m.All packets are transmitted at the same frequency.We randomly select the source and the destination.Each simulation scenario is repeated ten times.The source and the destination are randomly selected following a uniform distribution.The simulation parameters are shown in Table 2.As shown in Fig. 8, LOTIR and GeOpps achieve similar packet delivery ratios when there are no traffic lights.However, as the cycle time of the traffic lights increases gradually, LOTIR starts to perform better than GeOpps (here the cycle time is defined as the duration of a red light).This is because as the cycle time increases, the clustering effect of traffic lights becomes more significant.While our approach considers such an effect in the protocol design, GeOpps does not consider the effect of traffic lights.On the other hand, the packet delivery ratio of both protocols becomes better as the number of nodes increases.However, this is not surprising, given that we model vehicle movement using a uniform distribution for node distribution, and thus the probability of finding an ideal next carrier becomes higher as the node density increases.In particular, as we increase the number of nodes to 500 (to simulate the traffic jam scenario), the packet delivery ratio reaches 100% for both protocols.
We next look at how many hops are necessary for LOTIR and GeOpps to transmit a packet from the source to the destination in our scenario.As shown in Fig. 9, both protocols exhibit similar performance.In addition, we observe that the hop number does not change significantly, even in the case of a traffic jam, as the node density increases.This is probably because both protocols adopt a greedy forwarding approach [21] by choosing the node which is closer to the destination as the potential next forwarder.Furthermore, we observe that the overall hop number slightly decreases as the cycle time become longer.In a DTN network, the number of hops a packet needs to travel can generally be viewed as an indicator of network partitioning.As shown in Section 1, the existence of traffic lights can help reduce the number of network partitions.Moreover, as the cycle time of a traffic light becomes longer, the effect of traffic lights become more apparent.
Finally, in terms of the latency of delivering a packet from the source to the destination, LOTIR and GeOpps have similar performances, as shown in Fig. 10.The latency decreases as the number of nodes increases.This is because the delivery latency is mainly contributed by the network partition (i.e., the time to find the next forwarder), and the time to wait for the traffic light to turn green.Therefore, as the network density increases, it is easier to find the next forwarder.In addition, the latency becomes larger as we increase the traffic light cycle time, as shown in Fig. 10.We observe that GeOpps generally has a higher latency than LOTIR.This is because in some cases in GeOpps the current packet carrier might not be able find a neighboring node which has a closer NP than itself (i.e., the current packet carrier has a lower METD than its neighbors).In such situations, even though some of its neighbors might be closer to the destination, the current packet carrier will not be able to use them as the next forwarder and have to carry the packet by itself until it encounters other cars which have a closer NP.Given that car speed is much slower than the speed of wireless transmission, this will significantly increase the latency of GeOpps.
Note that we randomly select the source and destination of packets for each simulation.In addition, the effect of traffic lights introduces more randomness into the simulations.Fig. 8 and Fig. 10 basically show the general trend that the throughput increases and latency decreases as the node density rises (while the number of hops is not strongly affected by the number of nodes, as shown in Fig. 9), although these relationships are not strictly monotonic.The reason why the results are not strictly monotonic is mainly because of the randomness in our simulations, as noted above.For example, a traffic light can improve or degrade the node connectivity depending on the time when a node arrives at the intersection, and this depends on the selected path.In other words, the inclusion of traffic lights introduces significant unpredictability into the simulations.When the effect of traffic lights is considered, it is not always the case that a larger number of nodes will lead to better network connectivity with the destination.As an example, we show snapshots of the network topology when the number of nodes is 40 and 50 in Fig. 11 and Fig. 12, respectively.Comparing these two figures, we can observe that the network is more disconnected and has more isolated clusters when the number of nodes is higher.In a vehicular network, drivers tend to exhibit a bias for their destination selection [11].In other words, some locations could potentially be visited more often than others.Different destination selection patterns will result in different network topologies and levels of connectivity.We next consider the case when the selection of the destination follows a Pareto distribution, which implies that some locations are visited much more often than others.
As shown in Fig. 13, the packet delivery ratio of LOTIR is significantly better than that of GeOpps, even when there are no traffic lights (which introduces vehicle clusters).Intuitively, GeOpps tends to select a path which has the shortest distance to the destination, while LOTIR tends to select a path which has a higher node density.Therefore, it is likely that GeOpps would select the node whose route is the shortest distance from the destination, such as node S in Fig. 14, as the next forwarder.However, when the node distribution is uneven, S might not be able to find a next forwarder to forward the packet toward the destination, even though its route has a shorter distance from the destination than the routes of other nodes.On the other hand, given that LOTIR tends to choose the path which has a higher node density, the packet has a better chance of reaching the destination.

Conclusion
In this paper, we present LOTIR, which is a DTN-based routing protocol that utilizes local information and traffic characteristics to select the next forwarder.This is in contrast to prior work in this area that requires global network topology information, which might not be available in practice due to privacy concerns.Our protocol explores insights obtained from considering the effects of traffic lights and car-following theory.Our simulation results show that LOTIR can achieve similar or better performance compared to GeOpps, which utilizes a travel guidance system to obtain global topology information.
Driving behavior is an important factor that can affect the performance of a vehicular network.For example, overtaking or patterns of braking and acceleration/deceleration could potentially change the intercar distance at the street level.Moreover, driver preferences in path and destination selection can also affect the overall

Figure 2 .
Figure 2. Example of calculation of the Nearest Point from destination of the packet

Figure 4 .Figure 5 .
Figure 4.An overview of the straightway mode

Figure 6 .
Figure 6.An example of the intersection mode

Figure 8 .Figure 9 .
Figure 8. Packet delivery ratio for different cycle times and protocols

Figure 11 .Figure 10 .Figure 12 .
Figure 11.The snapshot of network topology when the number of nodes is 40

Figure 14 .Figure 13 .
Figure 14.Example of selecting paths to destination between GeOpps and LOTIR

Table 1 .
Neighbor information table EAIEuropean Alliance for Innovation LOTIR: A Routing Protocol for Multi-hop V-to-I Communication Using Local Traffic Information