A survey of geographic routing protocols for Vehicular Ad Hoc Networks (VANETs)

Jesus Gabriel Balderas Lopez

New Mexico State University.

Fall 2010

CS 479/579

Problem definition:

Routing has been a challenge in Vehicular Ad Hoc Networks (VANETs) because of the features of this kind of networks. We know that in VANETs exist a frequent change in the topology of the network and this is due to the fast mobility of the nodes/vehicles. There also exist the problem of connectivity between the nodes for the same reason.

VANETs have many applications; we can use them to improve road traffic safety and efficiency with real time information about the status of the road, if there is an accident we can know it and look for a new route to go to your destination; we can also use VANETs for media sharing between two vehicles (like the example given in class where the driver of one of the vehicles is able to know the song that is playing is the neighbor vehicle and sends a request to download the song and play it on his vehicle). There are many applications of VANETs and in order to accomplish these things we need some new routing protocols that consider the challenges mentioned above. In this survey we are going to analyze only routing strategies that use geographical location information obtained from street maps, traffic models or even more prevalent navigational systems on-board the vehicles. The reason of this is that geographic routing has been identified as a more promising routing paradigm for VANETs; therefore, most of the routing protocols available for VANETs use some kind of

geographic information.

In the following sections, I classify the geographic routing protocols for VANETs according to the routing type; I describe each protocol and describe how the protocol uses the location information for routing. After this classification I present my insights of the problem, and finally I present some complexities that I ran into while trying to solve this problem.

Classification:

The easiest way to classify the geographic routing protocols is by type of routing (Unicast, Broadcast or Geocast). Other way to classify them is by the use that the protocol gives to the position information (Packet forwarding, Route Selection, Cluster formation, Formation of cells, Classify Forwarding Group, or Route Request Forwarding). For this survey I will use the type of routing classification and in each protocol I’ll talk about how the protocol uses the geographic information.

Unicast: GPSR (Greedy Perimeter Stateless Routing) [2] is probably

the best known geographic routing protocol for VANETs. GPSR uses the positions of routers and a packet’s destination to make packet forwarding decisions. The position of a packet’s destination and positions of the candidate next hops are sufficient to make correct forwarding decisions, without any other topological information. In this protocol the authors assume that all wireless routers know their own position, either from a GPS device, if outdoors, or through other means. They also assume bidirectional radio reachability. Finally, they assume that packet sources can determine the locations of packet destinations, to mark packets they originate with their destination’s location.

GPSR consists of two methods for forwarding packets: greedy

forwarding, which is used wherever possible, and perimeter forwarding, which is used in the regions greedy forwarding cannot be.

● Greedy forwarding A forwarding node can make a locally optimal, greedy choice in choosing a packet’s next hop. The locally optimal choice of next hop is the neighbor graphically closest to the packet’s destination. This scheme is followed successively

until the destination is reached.

The figure above represents an example of greedy next hop choice. Here, the x receives a packet destined for D. x’s radio range is denoted by the dotted circle about x, and the arc with radius is equal to the distance between y and D is shown as the dashed arc about D. x forwards the packet to y, as the distance between y and D is less than that between D and any of x’s other neighbors. This greedy forwarding process repeats until the packet reaches D.Periodically, each node transmits a beacon to the broadcast MAC address, containing only its own identifier and position. This process provides all nodes with their neighbors’ positions.There are topologies in which the only route to a destination requires a packet move temporarily farther in geometric distance from the destination. An example of such topology is shown in the next figure.

In this figure, x is closer to D than its neighbors w and y. Although two paths, (x -> y -> z -> D) and (x -> w -> v -> D), exists to D, x will not choose to forward to w or y using greedy forwarding because x is the local maximum in its proximity to D. Some other mechanism must be used to forward the packets in these situations.

● The Right-Hand Rule: Perimeters: This rule states that when

arriving at node x from node y, the next edge traversed is the next one sequentially counterclockwise about x from edge (x, y). The figure to the right illustrates this rule. It is known that the right-hand rule traverses the interior of a closed polygonal region (a face) in clockwise edge order- In this case, the triangle bounded by the edges between nodes x, y, z, in the order (y -> x -> z -> y). They call the sequence of edges traversed by the right-hand rule a perimeter.

It is important to recall that all nodes maintain a neighbor

table, which stores the addresses and locations of their single-hop radio neighbors.

All packet data packets are marked initially at their originators as greedy mode. Packet sources also include the geographic location of the destination in packets.

When a forwarding node receives a packet in greedy mode, it searches its neighbor table for the neighbor geographically closest to the packet destination. If this neighbor is closer to the destination, the node forwards the packet to that neighbor. When no neighbor is closer, the node marks the packet into perimeter mode.

GPSR forwards perimeter mode packets using a simple planar graph traversal.

GPSR works best in a free open space scenario with evenly distributed nodes. It also suffers from several problems. First, in city scenarios, greedy forwarding is often restricted because direct communications between nodes may not exist due to obstacles such as buildings and trees. Second, if apply first planarized graph to build the routing topology and then run greedy forwarding or face routing on it, the routing performance will degrade. Third, mobility can also induce routing loops for face routing, and last, sometimes packets may get forwarded to the wrong direction leading higher delays or even

network partitions.

Geographic Source Routing (GSR) [3] is other position-based routing protocol for VANETs. GSR assumes the aid of a street map in city environments. This street map is used to know the city topology. GSR uses something called Reactive Location Service (RLS) to get the destination position. GSR combines geographic routing and topological knowledge from street maps; the sender determines the junctions that have to be traversed by the packet using the Dijkstra’s shortest path algorithm and then forward the packet in a position-based fashion between the junctions. This protocol was designed for city environments.

GPCR (Greedy Perimeter Coordinator Routing) [4] is other unicast geographic routing protocol for VANETs. The main idea of GPCR is to take advantage of the fact that streets and junctions form a natural planar graph, without using any global or external information such as a static street map. It consists of two parts: A restricted greedy forwarding procedure and a repair strategy which is based on the topology of real-world streets and junctions and hence does not require a graph planarization algorithm.

● Restricted Greedy Routing: A special form of greedy forwarding is used to forward a data packet towards the destination. Since obstacles block radio signal, data packets should be routed along streets. Junctions are the only places where actual routing decisions are taken. Therefore packets should always be forwarded to a node on a junction rather than being forwarded across a junction. This is illustrated in the figure below where node u would forward the packet beyond the junction to node 1a if regular greedy forwarding is used. By forwarding the packet to node 2a an alternative path to the destination node can be found without getting stuck in a local optimum. They call a node located in the area of a junction a coordinator.

● Repair Strategy: The repair strategy of GPCR avoids using graph

planarization by making routing decision on the basis of street and junctions instead of individual nodes and their connectivity. As a consequence the repair strategy of GPCR consist of two parts:

○ On each junction it has to be decided which street the packet should follow next.

○ In between junctions greedy routing to the next junction can be used.

If the forwarding node for a packet in repair mode is a coordinator then the node needs to determine which street the packet should follow next. To this end the topology of the city is regarded as a planar graph and the well known right-hand rule is applied. The next image is taken from [1] This image compares Greedy

forwarding (used in GPSR) vs Restricted greedy routing in the area of junctions (used in GPCR) in (a), and (b) illustrates the right hand rule used in the repair strategy of GPCR.

Anchor-based Street and Traffic Aware Routing (A-STAR) [5] was

proposed for city environments. A-STAR is similar to GSR; it uses the street map to compute the sequence of junctions (anchors) through which a packet must pass to reach its destination. Bur unlike GSR, A-STAR computes the anchor paths with traffic awareness.

A-STAR is also different from other protocols because it employs a new local recovery strategy for packets routed to a local minimum that is more suitable for a city environment than the greedy approach of GSR and the perimeter-mode of GPSR. In the local recovery state, the packet is salvaged by traversing the new anchor path. To prevent other packets from traversing through the same void area, the street at which local minimum occurred is marked as “out of service” temporarily and these streets are not used for anchor computation or re-computation during the “out of service” duration and they resume “operational” after the time out duration.

Clustering for Open Inter-vehicular communication (IVC) Networks (COIN) [6] is a cluster-based protocol. In cluster-based routing, a virtual network infrastructure must be created through the clustering nodes in order to provide scalability. Each cluster can have a cluster head, which is responsible for intra-and inter-cluster coordination in the network management functions. Nodes inside a cluster communicate via direct links. Inter-cluster communication is performed via the cluster-heads. The image below illustrates clustering in VANETs. COIN uses the location information for cluster formation. Cluster head election is based on vehicular dynamics and driver intentions, instead of ID or relative mobility as in classical clustering methods. COIN produces much more stable structures in VANETs while introducing little additional overhead.

LORA_CBF [7] is other location based routing algorithm that uses

cluster-based flooding for VANETs. Each node can me the cluster-head, gateway or cluster member. If a node is connected to more than one cluster, it is called gateway. The cluster-head maintains information about its members and gateways. Packets are forwarded from a source to the destination by protocol similar to greedy routing. If the location of the destination is not available, the source will send out the location request (LREQ) packets. This phase is similar to the route discovery phase of AODV, but only the cluster-heads and gateways will disseminate the LREQ and LREP (Location Reply) messages.

Broadcast:

The simplest way to implement a broadcast service is flooding in which each node re-broadcast messages to all of its neighbors except the one it got this message from. Flooding guarantees the message will eventually reach all nodes in the network. Flooding performs relatively well for a limited small number of nodes and is easy to be implemented. But when the number of nodes in the network increases, the performance drops quickly. Flooding may have a very significant overhead and selective forwarding can be used to avoid network congestion.

BROADCOMM [8] is an emergency broadcast protocol based on a hierarchical structure for a highway network. In BROADCOMM, the highway is divided into virtual cells, which moves as the vehicle moves. The nodes in the highway are organized into two level of hierarchy: the first level includes all the nodes in a cell; the second level is represented by the cell reflectors, which are a few nodes usually located closed to the geographical center of the cell. Cell reflectors behaves for a certain time interval as a base station or cluster head that will handle the emergency messages coming from members of the same cell, or close members from neighbors cells.

BROADCOMM outperforms similar flooding based routing protocols in the message broadcasting delay and routing overhead. However, it is very simple and only works with simple highways networks.

UMB (Urban Multi-Hop Broadcast) [9] is designed to address the broadcast storm, hidden node, and reliability problems of multi-hop broadcast in urban areas. This protocol assigns the duty of forwarding and acknowledging broadcast packet to only one vehicle by dividing the road portion inside the transmission range into segments and choosing the vehicle in the furthest non-empty segment without apriori topology information. When there is an intersection in the path of the message dissemination, new directional broadcast are initiated by repeaters located at the intersections.

The most important goals of UMB, according to the authors, are as follows:

1. Avoiding collisions due to hidden nodes: In order to decrease the effect of hidden nodes, a mechanism similar to RTS/CTS handshake in point-to-point communication is employed by their UMB protocol. They refer to RTS and CTS as Request To Broadcast (RTB) and Crear To Broadcast (CTB), respectively.

2. Using the channel efficiently: Forwarding duty is assigned to only the furthest vehicle in the transmission range without using the network topology information.

3.Making the broadcast communication as reliable as possible: To achieve the reliability goal, an ACK packet is sent by the vehicle which was selected to forward the packet.

4.Disseminating messages in all directions at an intersection: New directional broadcast are initiated by the simple repeaters installed at the Intersection Broadcast mechanism.

The next image illustrates the sequence of packets in UMB to

avoid collisions due to hidden nodes.

The image below illustrates the intersection broadcast in UMB

for disseminating messages in all directions at an intersection.

Vector-based TRAcking DEtection (V-TRADE) and History-enhanced V-

TRADE (HV-TRADE) [10] are GPS based message broadcasting protocols. The basic idea is similar to the unicast routing protocol Zone Routing Protocol (ZRP). Based on position and movement information, their methods classify the neighbors into different forwarding groups. For each group only a small subset of vehicles (called border vehicles) is selected to rebroadcast the message. They show significant improvement of bandwidth utilization with slightly loss of reachability, because the new protocols pick fewer vehicles to rebroadcast the messages. But they still have routing overhead as long as the forwarding nodes are selected in every hop.

Geocast:

Geocast routing is basically a location-based multicast routing. The objective of a geocast routing is to deliver the packer from a

source node to all the other nodes with a specified geographical region (Zone of Relevance, ZOR). Vehicles outside the ZOR are not alerted to avoid unnecessary and hasty reactions. The source node is usually inside the ZOR

Most geocast routing methods are based on directed flooding, which tries to limit the message overhead and network congestion of simple flooding by defining a forwarding zone and restricting the flooding inside it. Non-flooding approaches (based on unicast routing) are also proposed, but inside the destination region, regional flooding may still be used even for protocols characterized as non-flooding.

Inter-Vehicles Geocast protocol (IVG) [11] consists in informing all the vehicles of a highway about any danger such as an accident or any other obstacle. In this case, risk areas are determined according to the driving direction and the position of the vehicles. The node which receives an alarm message should not rebroadcast it immediately but has to wait some time, called defer time, to take a decision about rebroadcast. When this defer time expires and if it does not receive the same alarm message from another node behind it, it deducts that there is no relay node behind it. Thus it has to designate itself as a relay and starts broadcasting alarm messages to inform the vehicles which might be behind it. The defer time of node (x) receiving a message from another node (s) is inversely proportional to the distance separating them that is to favorite the farthest node to wait less time and to rebroadcast faster

Cached Geocast [12] is other geocast protocol. The main idea of

their cached greedy geocast inside the ZOR is to add a small cache to the routing layer that holds those packets that a node cannot forward instantly due to a local minimum. When a new neighbor comes into a reach or known neighbors change their positions, the cached message can be possibly forwarded to the newly discovered node. Their distance aware neighborhood strategy takes frequent neighborhood changes into account. It chooses the closest node to destination which is inside

the range r (smaller than the transmission range) instead of the node transmission range in the general greedy routing mode. The improved neighborhood selection taking frequent neighborhood changes into account significantly decreases network load and decreases end-to-end delivery delay.

Beside of the classical geocast routing, there is a special geocast, called Abiding Geocast [13], where the packets need to delivered to all nodes that are sometime during the geocast lifetime (a certain period of time) inside the geocast destination region. Services like position-based advertising, position-based publish-and-subscribe, and many other location-based services profit from abiding geocast. For VANETs, abiding geocast allows realization of information and safety applications like virtual warning signs. Similar to real traffic of warning signs, they are attached to a certain geographical position or area. When a vehicle enters such an area, the virtual warning sign is displayed for the driver. The authors provided three solutions:

1. A server is used to store the geocast messages.2. An elected node inside the geocast region stores the messages.3. Each node stores all geocast packets destined for its location

and keeps the neighbor information.

My insights

In this work I only present a few position-based routing protocols for Vehicular Ad hoc Networks, there are so many and more to come because this is a field of wireless networks that is increasing so fast. We can see in this paper that have different protocols depending the environment, if this is for a city of highway, and the routing type.

When I started to work on this project I wanted to be able to mention the best protocol for VANETs but this is a hard job. If we want to implement one of these protocols we need to think about the requirements. If it is a city scenario maybe I would choose a unicast protocol like A-STAR because it is also consider traffic load in the streets. Another option is a broadcast protocol like UMB, I think this is a good option because this protocol tries to avoid collisions due to hidden nodes, makes broadcast a reliable way of communication because implements ACK packets in the process of communications between nodes; it also adds the idea of repeater in the intersections to rebroadcast the packets and this is useful because you don’t necessarily need other vehicles in the streets to forward the packet

to the destination.

I think there is so much work to do in the area of routing in VANETs because in our day to day life we are not always in the city nor in the highways; it’s necessary to create a new protocol able to work in both city environments and highways but this is a big challenge.

I never thought to find a protocol like Abiding Geocast that is designed for advertising and publishing depending on the region the vehicle is located and this is an amazing application for VANETs, not only for real time traffic information or emergency information.

I am impressed of all these protocols and applications and I think there is more to come.

Complexities

I think that the complexities of solving this problem of routing in VANETs are related in the implementation and experimentation. This is because in order to have better results we need no implement the protocol in a real-life scenario and not just simulate it with some kind of traffic simulator; also we could need to implement the protocol not just in one city or highway, maybe 2 or more is better to obtain results not just in a particular place. I think this part is the hardest one.

References

1. F. Li and Y. Wang, “Routing in vehicular ad hoc networks: A Survey,” Vehicular Technology Magazine, IEEE, vol. 2, no. 2, pp. 12-22, jun 2007

2.B. Karp and H. T. Kung, “GPSR: Greedy perimeter stateless routing for wireless networks,” in Proceedings of the ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom), 2000.

3. C. Lochert, H. Hartenstein, J. Tian, D. Herrmann, H. Füßler, and M. Mauve, “A routing strategy for vehicular ad hoc networks in city environments,” in Proceedeings of IEEE Intelligent Vehicles Symposium (IV2003), pp. 156-161, June 2003.

4. C. Lochert, M. Mauve, H. Füßler, and H. Hartenstein, “Geographic routing in city scenarios,” ACM SIGMOBILE Mobile Computing and Communications Review (MC2R), vol. 9, no. 1, pp. 69-72, Jan.

2005.

5.G. Liu, B.-S. Lee, B.-C. Seet, C. H. Foh, K. J. Wong, and L.-K. Lee, “A routing strategy for metropolis vehicular communications,” in International Conference on Information Networking (ICOIN), pp. 134-143, 2004.

6. J. Blum, A. Eskandarian, and L. Hoffman, “Mobility management in IVC networks,” in IEEE Intelligent Vehicles Symposium, 2003.

7. R. A. Santos, A. Edwards, R. Edwards, and L. seed, “Performance evaluation of routing protocols in vehicular adhoc networks,” The International Journal od Ad Hoc and Ubiquitous Computing, vol. 1, no. ½, pp. 80-91, 2005.

8.M. Durresi, A. Durresi, and L. Barolli, “Emergency broadcast protocol for inter-vehicle communications,” in ICPADS `05: Proceedings of the 11th International Conference on Parallel and Distributed Systems--Workshops (ICPADS`05), 2005.

9. G. Korkmaz, E. Ekici, F. Özgüner, and Ü. Özgüner, “Urban multi-hop broadcast protocol for inter-vehicle communication systems,” in ACM International Workshop on Vehicular Ad Hoc Networks, pp. 76-85, 2004.

10. M. Sun, W. Feng, T.-H. Lai, K. Yamada, H. Okada, and K. Fujimura, “GPS-based message broadcasting for inter-vehicle communication,” in ICPP `00: Proceedings of the 2000 International Conference on Parallel Processinf, 2000.

11. A. Bachir and A. Benslimane, “A multicast protocol in ad hoc networks inter-vehicle geocast,” in Proceedings of the 57th IEEE Semiannual Vehicular Technology Conference, vol. 4, pp. 2456–2460, 2003.

12. C. Maihöfer and R. Eberhardt, “Geocast in vehicular environments: Caching and transmission range control for improved efficiency,” in Proceedings of IEEE Intelligent Vehicles Symposium (IV), pp. 951–956, 2004.

13. C. Maihöfer, T. Leinmüller, and E. Schoch, “Abiding geocast: time-stable geocast for ad hoc networks,” in Proceedings of the 2nd ACM international workshop on Vehicular ad hoc networks (VANET ’05), pp. 20–29, 2005.

14. J. Luo and J.-P. Hubaux. A survey of inter-vehicle communication. Technical Report IC/2004/24, EPFL, Lausanne, Switzerland, 2004.