UCLA CSD Technical Report: TR080009, March 26, 2008

VCLCR: A Practical Geographic Routing Protocol in Urban Scenarios

Kevin C. Lee, Pei-Chun Cheng, Jui-Ting Weng, Lung-Chih Tung, Mario GerlaUniversity of California, Los Angeles

4732 Boelter HallLos Angeles, CA 90095

{kclee,pcheng,jtweng, lctung,gerla}@cs.ucla.edu

AbstractIn this paper, we propose VANET Cross Link Corrected Rout-

ing (VCLCR), a simple yet novel, event-driven geographic routingprotocol that removes cross links dynamically to avoid routingloops in urban Vehicular Ad Hoc Networks (VANETs). VCLCRuses the natural planar feature of urban maps without the prob-lematic planarization strategy. The salient features of dynamicloop detection and statelessness make VCLCR suitable for highlymobile VANET. We have shown that in both static and mo-bile cases, VCLCR’s packet delivery ratio (PDR) is consistentlyhigher than GPSR’s and GPCR’s. We have also shown thatcaching (VCLCR+Cache) provides the same high PDR but fewerhops. As the problem of cross links greatly manifests itself in ur-ban environments filled with traffic lights and intersection roads,VCLCR proves promising in making geographic routing possible.

1. IntroductionThe ever growing spread of vehicles and roadside traffic mon-

itors with the advancement of navigation systems [4] and the lowcost of wireless network devices provides incentives for car man-ufacturers to equip vehicles with real-time traffic reports, promis-ing peer-to-peer applications such as CarTorrent [35, 33, 27],and externally-driven services to vehicles. However, for theseapplications and services to materialize, there is a need forstandards of ubiquitous high-speed communications and homo-geneous communication interfaces among different automotivemanufacturers. For this purpose, the Intelligent TransportationSystems (ITS) have proposed the Wireless Access in Vehicu-lar Environments (WAVE) standards that define an architecturethat collectively enables vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless communications [5]. Specifi-cally, IEEE 802.11p, the groundwork for Dedicated Short RangeCommunications (DSRC) protocols within ITS, has recently beendrafted to add wireless access to the vehicular environments [1].While the major objective has clearly been to improve the over-all safety of vehicular traffic, promising traffic management solu-tions or on-board entertainment applications are also expected bythe different bodies involved in this field (C2CCC [2], VII [6],CALM [3]). When equipped with WAVE communication de-vices, cars and roadside units form a highly dynamic networkcalled Vehicular Ad Hoc Network (VANET). Similar to mobilead hoc networks (MANETs), nodes have limited radio range andcommunicate with one another by multi-hop routing protocols.

Since VANET is characterized by dynamic, highly mobilenodes, designing an efficient multi-hop routing protocol that gov-erns the data communication between vehicles to support thewide range of applications can be a challenging problem. On-demand approaches such as AODV [38] or DSR [18] suffer from

flooding overhead. Consequently, these approaches often do notscale well when traffic density increases. Proactive approachessuch as OLSR [10] does not cope well with high node mobil-ity. Hierarchical routing approaches such as HSR [37] or LAN-MAR [36] may not be efficient since clusterheads need to be up-dated frequently and communication between two nodes needs togo through their clusterhead even though the two nodes are withinradio range of each other. Position-based routing has proven tobe well suited for highly dynamic environment such as VehicularAd Hoc Networks (VANET) due to its simplicity and efficiency.Data is routed to nodes based on their geographic location. Dueto the low cost and prevalence of global positioning system (GPS)and recent research on Geo-Location Services [11, 30, 40], geo-graphic routing protocol such as GPSR [22], its variants [32, 28],and CBF [13, 12] becomes a practical and suitable routing solu-tion [31, 34, 17] for VANET. In GPSR, nodes forward packetsgreedily by choosing their neighbor which has the shortest dis-tance to the destination. A node receiving packets chooses thenext hop in the same way until packets reach the destination.However, there are some cases where packets will reach a localmaximum where no neighbor is closer to the destination than thecurrent forwarding node itself. In such case, the node switchesfrom greedy mode to perimeter mode and forwards packets alonga planar representation of the underlying topology by the right-hand rule. A packet is delivered in greedy mode again when itarrives at a node which has a shorter distance to the destinationthan the distance from the node it entered the perimeter mode tothe destination. During perimeter mode, if the packet goes backto the original point, the node will drop the packet since the des-tination is unreachable.

Regardless whether the network is connected, in perimetermode, GPSR requires a planar graph in order to make sure thatthe packets do not get dropped prematurely because of routingloops. Distributed algorithms [22, 8] have been proposed to pro-duce Relative Neighborhood Graph (RNG) and Gabriel Graph(GG) that are known to be planar. However, due to obstacles andirregular communication range as a result of transceiver differ-ences, the unit graph assumption that guarantees the successfulcreation of a planar graph from the underlying topology is oftenviolated. [23, 24] have observed anomalies of these planarizationalgorithms. More specifically, these anomalies are network parti-tions, asymmetric links, cross links, and collinear links. Mutualwitness protocol [21, 20, 19], CLDP [23], and LCR [15] havetried to remove these anomalies.

[22, 28] have recognized that urban roads naturally form a pla-nar graph where intersections are nodes and edges are formedby two intersections. The natural formation of a planar graphfrom the underlying roads eliminates the need for node planariza-tion. Furthermore, the natural planarity of the roads eliminates

1

UCLA CSD Technical Report: TR080009, March 26, 2008pathologies that arise because of non-unit graph assumption andlocalization errors [24, 19]. Since the unit of a perimeter is fromone intersection to the next in perimeter mode, each node neednot make “baby” steps towards the destination. Rather, nodescan forward as far as they can from one intersection to the next.Decision about which road to forward to will then be made by anode at a junction. However, problems, in particular, cross links,still occur when nodes do not exist at a junction. Figure 2(a)demonstrates that the presence of cross links, introducing routingloops, would not have happened had a node existed at junction B.Typical cross links that happen in VANET is a result of nodes’ in-ability to hear one another on different roads because of obstaclesand the absence of nodes at junctions. Unlike highways, the prob-lem of cross links greatly manifests itself in urban scenarios thatare filled with traffic lights and intersection roads. Without a dy-namic cross-link removal algorithm, geographic routing is nearlyimpossible in urban environments.

In this paper, we propose VANET Cross-Link Corrected Rout-ing (VCLCR) protocol, a simple yet novel, event-driven protocolthat exploits the natural planar graph of urban roads and helpsnodes route packets in the presence of cross links due to emptyjunctions. Unlike CLDP and LCR, no addition of probe packetis needed as VCLCR data packets remove cross links as they go.We coin this feature as “dynamic loop detection.” Since most ofthe cross links do not affect the delivery of packets, VCLCR onlyconsiders loop-inducing cross links in the current packet’s routingpath for removal. Because VCLCR does not require the need ofprobing packets, its resource overhead is also significantly lower.Another major difference from CLDP and LCR is that VCLCRis completely stateless. Each node need not remember which oftheir links are unroutable. The salient features of dynamic loopdetection and statelessness make VCLCR suitable for highly mo-bile VANET. We have also proposed a variant of VCLCR thatrequires minimal state information at some nodes to exploit reg-ular traffic patterns (for example, peak traffic hours are between5:00pm and 7:00pm) to further improve the end-to-end latencyand hop count. We have also proposed to limit the informationrecorded on a packet so that VCLCR’s overhead can be kept ata minimum (see Section 3.6). The rest of the paper is organizedas follows: Section 2 provides a short discussion of the currentefforts in dealing with cross links. In Section 3, we formally in-troduce VCLCR by showing its properties, examples, and opti-mizations. Section 4 presents the realistic evaluation of VCLCRin static and mobile city scenarios. Section 5 presents the futurework and concludes the paper.

2. Geographic Routing in VANETIn this section, we briefly describe the Greedy Perimeter State-

less Routing (GPSR), Greedy Perimeter Coordinator Routing(GPCR) algorithm, Cross-Link Detection Protocol (CLDP), LazyCross-Link Removal (LCR), and comparison with VCLCR.2.1. Greedy Perimeter Stateless Routing

The Greedy Perimeter Stateless Routing (GPSR) algorithm be-longs to the category of position-based routing, where a node for-wards a packet to an immediate neighbor which is geographicallycloser to the destination node. Due to the non-uniform distribu-tions of nodes or to the existence of radio obstacles, it is possiblethat a packet reaches a local maximum where its distance to thedestination is closer than its neighbors’ distance to the destina-tion. To make further advance from the local maximum, a recov-ery mode is used to forward a packet to a node that is closer to thedestination than the node where the packet encountered the localmaximum. The packet resumes forwarding in greedy mode when

D

x

y

1

2

x-axis

virtual edge

Figure 1. Perimeter forwarding by right-hand rule.it reaches a node whose distance to the destination is closer thanthe node at the local maximum to the destination.

Many recovery algorithms have been developed includ-ing GPSR [22], Compass [25], Face-1 and Face-2 [9], orGOAFR+ [26]. GPSR recovers from a local maximum using thePerimeter Mode based on the right-hand rule shown in Figure 1.The rule states that when a node x first enters into the recov-ery mode, its next forwarding hop is the node that is sequentiallycounterclockwise to the virtual edge formed by x and destinationD. Afterwards, the next hop is sequentially counterclockwise tothe edge formed by y and its previous node x. To avoid routingloops, the right-hand rule requires that all edges are non-crossing.GPSR proposes either Relative Neighborhood Graph(RNG) [39]or Gabriel Graph(GG) [14] to obtain a planar network graph withno crossing edges, while another approach suggests the use ofspanning trees or convex hulls [29]. The maintenance of planargraphs at each node introduces a significant overhead.2.2. Greedy Perimeter Coordinator Routing

While GPSR provides an efficient and reliable routing proto-col, the main drawback of GPSR is that it requires a planar graphto guarantee its correctness in the perimeter mode. Two meth-ods are proposed in GPSR to construct planar graph: RelativeNeighborhood Graph (RNG) and Gabriel Graph (GG). However,in reality, constructing a planar graph is nearly impossible due toobstacles and irregular communication devices. Greedy Perime-ter Coordinator Routing algorithm (GPCR) [32] solves the pla-narization problem by exploiting the urban street map that nat-urally forms a planar graph. Consequently, it does not requireany planarization algorithm. Like GPSR, GPCR has two modesto deliver packets: restricted greedy forwarding mode and a re-covery mode. In GPCR’s restricted greedy mode, a node wouldforward greedily unless it finds a node at a junction in its greedypath. A junction node would be selected since the node can hearneighbors from all roads and thus can make better forwarding de-cision. Determining whether a node is at a junction can eithercome from its neighbors’ beacons of their locations or the map it-self. In the perimeter mode, junction nodes forward packets to thenext hop by applying the right-hand rule. Non-junction nodes for-ward packets greedily to the next junction, as we have describedabove in the greedy mode.

A major drawback of GRCR is that when there is no nodeat a junction, packets will be forwarded “cross” junctions. For-warding across “empty” junctions is likely to lead to a non-planargraph, that causes routing loops. For example in Figure 2(a), Sroutes packets in perimeter mode to R. If there are vehicles atall the junctions, the packet can be delivered to destination R fol-lowing the path shown in Figure 2(a). However, suppose junctionnode B is missing; in other words, junction B is empty. We cansee in Figure 2(b) that this graph is no longer planar. We can ei-ther remove the cross link which might disconnect the graph orwe can forward over the cross link which violates the principleof face routing and might induce routing loops. This is exactly

2

UCLA CSD Technical Report: TR080009, March 26, 2008

R9

R

S

R4

DR8 R3

R0

CG

F E

A

R1

R2

R5R6

H

B

(a) Simplified street map (no crosslinks).

R7

R9

R

S

R4

DR8 R3

R0

CG

F E

A

BR1

R2

R5R6

HUR: [R5R6]

(b) VCLCR routes over cross link.

Figure 2. VCLCR routing example.

what we want to address in this paper. We propose VCLCR todetect and remove cross links. By carefully removing cross linkswithout disconnecting the graph, VCLCR yields a better packetdelivery than GPCR.2.3. Cross-Link Detection Protocol

So far we have discussed the pitfalls of GPSR in its planariza-tion algorithm and pitfalls of GPCR in missing junctions, we haveshown GPSR’s pitfalls in an environment with obstacles. To ad-dress this problem, Kim et al. [23] proposed Cross-Link Detec-tion Protocol (CLDP) that produces a connected subgraph1 onwhich one can reliably use geographic routing. In CLDP, eachnode recursively2 and repeatedly3 probes its adjacent links to seeif it is crossed by other links. As the probe follows the right-hand rule going through the network, it records the links thatcross the currently probed link. When the probe returns to theoriginal node, the node carefully decides which of its cross linksis to be removed to avoid partitioning the network. The currentprobing node then notifies nodes that form such a link that it isunroutable. Consequently, future packet forwarding at either oneof the unroutable link will not consider the link for forwarding.

In Figure 3(a), a CLDP probe on link BC originates from C.The probe eventually returns back to C and records link AD thatcrosses BC. Because the packet traverses BC once in each direc-tion, CLDP-enabled node C infers that removing link BC woulddisconnect the network. Instead, it removes link AD. Node Aand D are then notified about the unroutable link between them.While CLDP is promising, its message complexity, scalability,and convergence time are not. The message complexity stemsfrom the fact that probing is done in a concurrent fashion tospeed up convergence. Concurrency introduces race conditionand brings complex locking mechanism. As the number of crosslinks grows, the global number of probes also increases. The re-peated probing of one link to remove all cross links and recursiveprobing of all the other links hurt CLDP’s scalability. Further-more, according to [23], for a 200-node wireless network, mostlinks in concurrent CLDP converge within 15-20 probes, whereeach probe’s frequency is 15 sec. This corresponds to a conver-gence time of 4 minutes. This long convergence time might be

1Note that the subgraph need not be planar. CLDP removes all cross links thatare removable so as not to create network partitions.

2All links have to be probed.3For each link, CLDP may probe repeatedly to remove all cross links as in the

case of multiple cross links in [23].

A

D

B

C

(a) CLDP example.

L

K

M

J

S

N

D

(b) LCR example.

Figure 3. CLDP and LCR examples.

acceptable in ad hoc networks with moderate mobility, for ex-ample, sensor networks. However, it is not suitable for VANETwhen high mobility constantly changes the underlying topology.

By piggybacking probes on data packet, VCLCR does nothave the additional message overhead like CLDP. Furthermore,VCLCR only removes loop-inducing cross links on the currentrouting path by the right-hand rule (dynamic loop detection).Not only does it remove probing altogether and speed up con-vergence time, but it also eliminates the complex locking mech-anism. There is no locking mechanism involved at all becauseeach source-destination pair dictates which cross links to removeindependent from the other pairs by their own packets (stateless).In other words, the link that is considered unroutable for a par-ticular source-destination pair might be considered routable foranother source-destination pair. The state information is not be-ing kept at each node and there is no absolute determination of alink’s routability by VCLCR.2.4. Lazy Cross-Link Removal Protocol

Realizing CLDP’s message complexity, Kim et al. devel-oped Lazy Cross-Link Removal (LCR) protocol that reduces themessage complexity by only removing loop-inducing cross linkswhen necessary. Instead of making the protocol responsible forremoving all cross links possible, the task is shifted to mutual wit-ness algorithm [19, 20, 21] that generates an approximate planargraph of the underlying topology. The rest of the cross links willthen be taken care of by LCR as need basis. In Figure 3(b), forexample, packets sent from S to D will eventually loop back to Sin perimeter mode and report back KL and JM as loop-inducingcross links. By removing either KL or JM , LCR can forwardpackets successfully from S to D.

Although LCR does not suffer the high message complexityas CLDP, it does not completely eliminate it, either. Since ituses CLDP to remove cross links, there is still the need of prob-ing messages. Scalability still suffers as LCR tries to removeall loop-inducing cross links going out of source node. Further-more, “when LCR detects that a looped walk does not contain across link, LCR initiates a recursive search on the adjacent facesfor cross link. [15]” Although the approach improves the packetdelivery ratio, the cost of probing messages for such improve-ment grows with increasing level of recursion and the number ofnodes in the network. The “recursive search procedure can, in theworst-case, incur overhead comparable to CLDP. [15]” The over-head worsens in VANET when nodes are highly mobile. The costof getting the expensive none-cross-link path between the sourceand destination is incurred every time nodes move. It is con-ceivable that LCR’s control packets overwhelm the network thatapplication-layer communication becomes nearly impossible.

In contrast to LCR, VCLCR does not have the high messageoverhead as LCR. Moreover, due to its dynamic loop detection,

3

UCLA CSD Technical Report: TR080009, March 26, 2008loop-inducing cross link can immediately be removed at repeatednodes. For example, in Figure 3(b), as soon as the packet loopsback to the repeated node K, VCLCR removes JM and forwardspackets from K, L, M , N , to D. The immediate action taken byrepeated node as opposed by source node only improves the over-all end-to-end latency and hop count. Table 1 shows the compar-ison between CLDP, LCR, and VCLCR.

3. VCLCR AlgorithmVCLCR is a geographic routing protocol that consists of

greedy forwarding and perimeter forwarding modes. In VCLCR,we utilize street maps as natural planar graphs. As obstacles blockradio signals for cross roads, the major decision of directions ismade only by junction nodes. The greedy forwarding mode al-ways forwards packets greedily to a junction node when there isone; otherwise, it will forward to current node’s furthest neigh-bor. In the perimeter mode, a junction node performs the right-hand rule to select which road should be traversed next, whilenon-junction nodes forward packets greedily to the next junctionnode.

During the perimeter mode, the forwarding node would recordthe road that it is on in the packet before forwarding to the nextnode. If the next node is a non-junction node and is on a differentroad, the next node would record the two roads that result in sucha missing junction and the node’s road. If the next node is a junc-tion node, it would simply record the junction ID in the packet.We will explain the necessity of these recordings later. For now,suppose that the packet comes back first to a node where its roador junction ID is in the packet, the node will realize that there is aloop as a result of either disconnectivity or cross links. The nodewill inspect the packet to determine whether there are cross linksand whether the node itself is on any of the cross links.

If there is no cross link, the node can continue forwarding thepacket based on the right-hand rule. If there is a cross link, thenode forwards the packet according to the loop indicated by thepacket so that the offending cross link can eventually be removed.If the repeated node is on the cross link, it is responsible for re-moving the cross link or its crossing link depending on the re-moval result that does not produce a network partition. Specifi-cally, the node removes the cross link that has been traversed onlyonce. For cross links that have been traversed twice, once in eachdirection, removing them will result in network partition [23].After determining which cross link to remove, the node, in ad-dition to forwarding, adds the removed cross link to unroutable(UR) field. Future forwarding nodes will look at the UR field andforward to nodes that are not on unroutable links in the UR fieldof the packet. The node only drops the packet when it reaches thevery same road or junction that the perimeter mode started ini-tially and has visited all faces. In conclusion, as long as a packetforms a loop by coming back to any node on the previously vis-ited road, and there is a cross link in this loop, the node, whileremoving the adjacent cross link, will forward the packet to thesame loop indicated in the packet given that the next link in theloop is not in the UR field (otherwise, forward by the right-handrule).

For the rest of this section, we describe our basic assumptions,VCLCR algorithm, VCLCR examples, VCLCR properties, andVCLCR optimizations.3.1. Basic Assumptions and Terminology

In VCLCR, we have made the following definition and as-sumptions.

1. We define a road segment which is formed by exactly two

GR8 R3

R4

R5R6

R7

R1

R0

R2

R9

FE

D C H

B A

I

Street Map

Node 1: (X1, Y1)

Node 2: (X2, Y2)

Node 3: (X3, Y3)GPS Service Examples:

GPS_RID(X1, Y1) = R1

GPS_RID(X2, Y2) = R7

GPS_RID(X3, Y3) = (R4, R5)

Figure 4. VCLCR basics.Term DefinitionEmpty Junction A junction in which no node resides.(Missing-junction) link A link such that packets travel directly from

one road segment to another because they areconnected by an empty junction. It is charac-terized by [RfromRto].

Symmetric link A link [RtoRfrom] such that[RfromRto] also exists.

Cross link A link that has been crossed by another link.Removable cross link A cross link that can be removed so as not to

cause network partition.Adjacent cross link A cross link that is adjacent to the current

junction.

Table 2. Terminology.unique junctions. Furthermore, every road segment andjunction are uniquely numbered, denoted as Road SegmentID and Junction ID. For example, in Figure 4, ten road seg-ments (R0, R1, . . . , R9) are connected by seven junctions(A,B, . . .). In reality, the same road can be separated bymore than two unique junctions. Each of these segments canbe given a unique identifier to conform to our definition.

2. We assume that a GPS service is given. This service pro-vides three primitive functions: map coordinates to roadsegment ids (GPS RID), map coordinates to junction ids(GPS JID), and check whether two pairs of a tuple of roadsegments are intersecting (GPS CX).

For example, in Figure 4, GPS RID(X1, Y1) returns R1,GPS JID(X3, Y3) returns E, and GPS CX([R1R2], [R5R6])returns true.

We believe this assumption is reasonable because moreand more cars are equipped with on-board navigation sys-tems, and navigation systems themselves should alreadyhave some internal road numbering and coordinate mappingmechanisms.

3. We assume that nodes on different cross road segments can-not detect one another because of radio obstacles such astrees and buildings. However, if one road segment is an ex-tension of another road segment, either horizontally or verti-cally, nodes may detect each other. For example, in Figure 4,Node 1 on R1 can hear Node 2 on R2 because R1 is an ex-tension of R2 in the vertical direction.

We define terms used throughout the paper in Table 3.1.3.2. Restricted Greedy Forwarding

In VCLCR, the default greedy forwarding strategy is the sameas the restrictive greedy forwarding in GPCR. Recall that inthe restricted greedy forwarding, because junctions are the onlyplaces where a node can forward to nodes on other roads, pack-ets must always be forwarded to a junction node even though thecurrent forwarding node can greedily forward nodes beyond the

4

UCLA CSD Technical Report: TR080009, March 26, 2008Protocol No control

msgsNo concur-rency/locks

Stateless Remove onlyLICLs4

No GG/MW DynamicLoop Detec-tion

Complete

CLDP X XLCR X X

VCLCR X X X X X XTable 1. Comparisons of the three routing protocols.

R1, R5, [R3R4], R2

[R6R5]

Probe

UR

Data

R2VF

Figure 5. Packet format.junction. At junctions, a greedy decision is made to determinewhich neighbor that brings the maximum progress towards thedestination. If a local maximum is reached, the recovery mode,that is, the perimeter forwarding is used.3.3. Perimeter Forwarding

We have shown that in GPCR, empty junction nodes mightcause cross links that induce routing loops. Here, we describeVCLCR implementation in perimeter forwarding to detect andremove cross links to improve packet delivery. Unlike CLDP,VCLCR is on demand and stateless and hence suits vehicular net-works. In VCLCR, we piggyback three fields Probe, UR, and VFin data packets:

1. Probe: Probe records the roads and junctions that a packethas traveled. For example, if a packet has traversed Junc-tion A, Road 1, Junction B, and Road 2, the Probe fieldwould record the path as “A,R1, B,R2.” It is important tomake it clear that we only store distinct road/junction IDsbut not individual node ID. If there is more than one vehicleat the same junction, they have the same junction ID as faras VCLCR is concerned.

2. UR (Unroutable roads): UR records road segments that areunroutable. The format is the same as the format of missing-junction links as [RfromRto]. When nodes make a routingdecision, they would ignore all unroutable road segments.This effect is, to some extent, similar to negative source rout-ing.

3. VF (Visited Faces): VF records the first road that has beenvisited in the current face by the source node. This fieldmakes sure that the source node visits all faces so as to try tofind a complete solution. Figure 5 illustrates a packet format.

The basic idea behind VCLCR is that when a node receives pack-ets forwarded in perimeter mode, it first checks if there is a loop(i.e., the packet comes back to itself) by looking at the Probe field.If there is a loop, then the node further checks the probe to deter-mine if there is any cross link. If the loop has an adjacent crosslink, the node determines which cross link is going to be removedand record the removed cross link in UR field. At the same time,the original recorded loop in the Probe field is also truncated. Ifthere are multiple cross links in the loop, the cross links will beremoved one by one as the packet keeps looping back to the samenode.

Before we describe our algorithm in detail, we explain why weput road ID, junction ID, and missing-junction link in the probe.The design choice is one of necessity. However, we discuss ways

to optimize the probe size further in Section 3.6. The reason forrecording the road ID (i.e., R1, R2, etc.) is that non-junctionnodes can detect a loop-inducing cross link and take an earlieraction. For example, as soon as the packet comes back to nodein Figure 2(b), node H can make an immediate action to forwardalong the same loop with cross link [R5R6] removed; this deci-sion to forward along the same loop need not be made at junctionA. The similar reason applies to recording junction ID so thatnodes at a junction can detect a loop-inducing cross link and takean earlier action. Since there can be more than one node at ajunction and since a junction ID best characterizes such a node,we therefore put junction ID in the probe. The missing-junctionlink in the probe allows us to determine what candidate links toconsider for cross links and for removal. Therefore, it is neces-sary to record it in the probe as well.

The procedure for VCLCR when a node receives a packet islisted as follows. We only outline our algorithm for perimeterforwarding:

Algorithm PerimeterForwardInput: currentHop, the destination, Probe, UR, the node x that first enters into the perimeter

modeOutput: nextHop1. if DIST(currentHop, destination) < DIST(x, destination)2. then switch to Greedy Forwarding Mode3. return currentHop4. if currentHop not at junction5. then nmax ←the furthest potential forwarder along the current road in the same

packet forwarding direction6. if nmax exits7. then return nmax8. else mmax ←the furthest potential forwarder along the current road in the

opposite direction to the current packet forwarding direction9. return mmax10. else PF ←ordered list of potential forwarders by the right-hand rule11. forced nextHop←call CheckProcessLoop(Probe, UR)12. if forced nextHop exists13. then PF ←{forced nextHop, PF}14. for nextHop ∈ PF15. do roadLink←road of the currentHop to road of the next hop16. nextroad←the road nextHop is on17. if (roadLink /∈ UR) and (nextRoad /∈ VF)18. then return nextHop19. if currentHop is source node20. then VF←{VF, nextRoad}21. return NULL

Algorithm CheckProcessLoopInput: Probe, UROutput: nextHop1. loop←a routing loop enclosed by two junction IDs or roads in Probe2. rclink←set of cross links in Probe3. aclink←set of adjacent cross links in Probe4. if loop exists5. then if rclink exists6. then if aclink exists7. then dlink←pick one adjacent cross link8. UR←{UR, dlink}9. Probe←{Probe− loop}10. forced nextHop ←furthest neighbor on the next road or the next

junction node indicated in the loop11. return forced nextHop12. else return NULL13. else return NULL

From line 1 to 3, the current node first checks if it is closer tothe destination than the first node x that enters into the perimetermode. If it is, the node switches to the greedy mode and returnsitself. If it is not closer, the node first determines whether it isa junction node by the GPS function, GPS JID. If it is not ajunction node, according to line 4 to 9, it looks for nmax in the

5

UCLA CSD Technical Report: TR080009, March 26, 2008current forwarding direction. If it is not found, mmax is the fur-thest node in the opposite forwarding direction. Note that nmaxis only up to the next road junction.

If the current node is a junction node, it first creates an orderedlist PF of forwarders based on the right-hand rule in line 10. Inother words, the node that makes the first counterclockwise turnfrom the edge formed by the current node and the previous node(or the virtual edge between the current node x and destination ifx is the node that first enters in the perimeter mode) will be thefirst node in this set. The second node will be the node that makesthe second counterclockwise turn, so on and so forth. SubroutineCheckProcessLoop is called to add forced nexthop in PF .

In CheckProcessLoop, the node first looks for a probe en-closed by its junction IDs or roads in the probe in line 1. Itthen determines whether there are any cross links in the probein line 2. Next, a node can determine whether it is adjacent tothe cross link. If there is a cross link and the node is adjacent toit, it would decide whether its adjacent link or its crossing linkto be placed in UR in line 8. We follow CLDP in determiningwhether a cross link is removable to avoid partitioning the net-work. In particular, we only remove the link [RfromRto] tupleonly if [RtoRfrom], its symmetric link, does not exist within theloop. The presence of a symmetric link indicates that the linkis traveled in both directions; thus, removing it can partition thenetwork. When two separate cross links do not have symmet-ric links, we remove either one of them arbitrarily. The probeis truncated by deleting the loop that is enclosed by the junctionID. forced nexthop will be assigned the furthest neighbor onthe road that follows the junction ID in the loop or a node at thenext junction ID. forced nexthop will force the packet to travelthe original route so that loops as a result of cross links can beresolved right away. This affords the packet the opportunity toget to the destination faster. Note that it does not matter whetherthe cross link is adjacent to the current node, as long as there is across link, forced nexthop will be assigned in line 11.

Back to PerimeterForward, lines 12-13 addforced nexthop to PF if forced nexthop exists. Fromlines 14-21, a candidate nextHop is chosen based on what isin the PF , which is an ordered list of nodes by the right-handrule. If the road link formed by the current hop and the candidatenexthop is not in UR and the edge formed by currentHop andnextHop is not in VF, we can return nextHop. Lines 19-20 addnextRoad to VF if currentHop is the source node. This ensuresthat if we ever come back to the source node, we can try to visitother faces to try to obtain a complete solution. Note that if allthe faces are visited by the source node, PerimeterForwardwould return NULL. This is consistent with the condition ofdropping the packets.3.4 VCLCR Routing Examples

Now we demonstrate how VCLCR works in the following ex-amples. Note that the main purpose of perimeter forwarding isto recover the packet from a local maximum. For simplicity, weassume all packets in our examples are forwarded in perimetermode and the destination in our examples is along the route thatdoes not loop back to the source.3.4.1 Routing Loop Scenario IIn the first example, we investigate the same cross-link problemdiscussed in Section II. In Figure 2(a), nodes A, B, C, D, E, F ,G, R and S represent junctions. Edges R0 to R8 represent roadsegments. Now suppose that there are no cars at junction B, thus[R1R2] becomes a cross link to [R5R6], and vice versa.

Now a packet is sent from junction S to A through road R0.By the right-hand rule, the packet will be forwarded past junction

C

B

D

E

A

R1

R2

R3

R4R5

R9

R6

R7 R8

RR11

Figure 6. The data packet traverses a loop.B through road R1 and R2, and to junction C, D, E, F , G, andthen back to C again. The path recorded in the Probe is “S, R0,A, H , R1, [R1R2], R2, C, R3, D, R4, E, R5, [R5R6], R6, F ,R7, G, R8, C.” Here C will detect there is a loop because itsown ID appears twice in the Probe. So it checks its “local loop,”which is “C, R3, D, R4, E, R5, [R5R6], R6, F , R7, G, R8, C,”and finds that there is no cross-link pair in the local loop. Thus,it simply forwards packets to the next hop by the right-hand-rule.The next hop is H in this case.

Now H will also detect a routing loop and a cross-link pair[R1R2], [R5R6] in its local loop, “. . ., R1, [R1R2], R2, C, R3, D,R4, E, R5, [R5R6], R6, F , R7, G, R8, C, [R2, R1], R1.” Since[R1R2] is an adjacent link for H , it is responsible for removingeither [R1R2] or [R5R6] and adding the offending link to UR.Since [R1R2] and its symmetric link [R2R1] appear inside theloop, removing [R1R2] will cause a network partition. However,[R5R6] does not have a symmetric link. Hence, it is a removablecross link. H then places [R5R6] in the UR, removes its localloop from the Probe, and forwards the packet to the node that ison the next road or the next junction in its loop. The next hophappens to be C. Note that we do not follow the right-hand rulebecause we have removed a cross link and changed the networktopology. Therefore, we forward the packet to this path againwithout the offending cross link.

The packet then goes to junction E through path “C, R3, D,R4, E.” E finds that [R5R6] is marked as un-routable path in theUR field, so it forwards the packet back to D (Figure 2(b)). NowD will forward the packet to R which may offer a potential pathto destination. This shows why we want to forward packets to thesame path after we delete a cross link to make packets progressfurther.

3.4.2 Routing Loop Scenario IIWe investigate a more complex scenario in Figure 6. In this ex-ample, the destination is at node R. Starting from A, the packetwould traverse a loop with two pairs of cross links, one pair of[R1, R2] and [R4, R5] and another pair of [R5, R6] and [R8, R9].Node B would first detect the loop and remove a cross link andthen forward the packet again following the same path. However,since now the packet could not be forwarded over the removedcross link, the loop is broken and the probe can be delivered todestination R.

Table 3 shows the detailed packet delivery trace when thepacket traverses a loop and comes back to node B. By check-ing the Probe field inside the packet, B can detect that there isa loop. In the loop, there are also two cross links, [R5R6] and[R8R9]. Since both are not symmetric links, both are removablecross links.

B breaks the tie by removing [R5R6] arbitrarily and forwardsthe packet along the loop again. The reason for routing throughthe loop again is to re-try the route produced by the loop without

6

UCLA CSD Technical Report: TR080009, March 26, 2008Junction /Road

Probe UR VF Node Action

A A R1 Record AR1 A, R1 R1 Record R1R2 A, R1, [R1, R2], R2 R1 Record

[R1, R2],R2B A, R1, [R1, R2], R2, B R1 Record BFollow the path: B → R3 → C → R4 → [R4R5] → R5 → [R5R6] →R6 → E → R7 → D → R8 → [R8, R9] → R9 → BB Before R1

A, R1, [R1R2], R2, B,R3, C, R4, [R4R5], R5,[R5R6], R6, E, R7, D, R8,[R8R9], R9, B

Record B, up-date UR, up-date Probe

AfterA, R1, [R1R2], R2, B [R5R6]

Follow the path: B → R3 → C → [R4, R5]R5 A, R1, [R1R2], R2, B, R3,

C, R4, [R4R5], R5

[R5R6] R1 Record R5,cannot forwardto R6

Follow the path: [R5, R4] → C → R. Packet delivered!

Table 3. Packet Routing Trace.

R4 R2C S

B A

D

R1

R3

R5

Figure 7. Non-loop-inducing cross-link example.the cross link. This saves us unnecessary hops incurred by go-ing back to the source, in this case, A. Now, because the packetcannot go through [R5R6], it would use right-hand rule to findanother next hop that eventually reaches the destination R shownin the dotted arrows in Figure 6.

3.4.3 Non-loop-inducing cross linksWe demonstrate that VCLCR can still deliver even though thecurrent loop does not have any cross links. In Figure 7, node Stries to send packets to node D. The packet travels S → A →B → C face and records R1 as the first edge of the current facein VF. When the packet loops back to S, it detects no cross link inthe current face traversal and tries to route to another face whosefirst edge is not in VF. Based on the right-hand rule, S will try toroute the packet to the face whose first edge is R2 while addingR2 to VF. Since the packet is delivered to D successfully on thenew face, VCLCR is never triggered.

3.4.4 Remote Cross LinksFor example, in Figure 8, a node at junction S sends a packetto junction A. The packet will go back to S following the path“B, C, D, S.” S then finds out there is a loop and a cross link pair[R1R2], [R3R4], but no adjacent cross links. So it just forwardspacket to A again. Now A will find there are a loop and an ad-jacent cross link in its local loop. It will delete the cross link by

R1

R2

R3

R4

Figure 8. Remote cross links.

D

S

CB

A

E

I

Figure 9. S would forward to D along the dottedarrows, but it would forward to C and back to Aalong the solid arrows if it changes face becauseID < SD

marking it as un-routable and forward the packet according to itsoriginal path. In this case A marks [R3R4] as un-routable andtries to forwards packet to B but finds no path. It then forwardspacket back to S. The intuition behind forwarding according toits loop rather than the right-hand rule at junction S is that whenthere is a loop and cross link pair but no adjacent cross links thata node can deal with, the node will just forward packets in theloop and let the other downstream nodes in this loop to resolvethe cross link problems.3.5 VCLCR PropertiesProperty 1. When there is no missing junction, VCLCR results inthe same forwarding path as GPCR in both the restricted greedyand perimeter mode.Proof. When there is no missing junction, packets will be for-warded to the next junction node as greedily as possible in therestricted greedy mode. When the packet falls into a local max-imum at a node, the node switches to the perimeter mode andforwards the packet along the perimeter of roads. Since the un-derlying urban topology is already planar and forwarding to junc-tion nodes ensure that there is no cross link, VCLCR will resultin the same forwarding path as GPCR in the perimeter mode.Property 2. VCLCR’s face routing never changes to another faceuntil it finishes the traversal of the current face.

Unlike GPSR and GPCR, this property says that we do not pre-empt the traversal of the current face when there is an intersectionpoint closer to the destination than the current one (denoted as Lf

in [22]). Our design choice is of two reasons. First, we have ob-served from our experiments that by following the current facetraversal without preemption, packets tend to switch to greedymode faster (See Figure 9). As far as how far the greedy modecan get the packet, it all depends on the topology and density. Wedo not concern ourselves about this unpredictability. Our mainconcern is to fulfill the objective of the perimeter mode - to getto a node as fast as we can so that greedy mode can be resumed.Second, as a result of missing junction in urban environments,traversing an exterior (unenclosed) face is far too common. Byswitching to another “face,” we might still be traveling on thesame exterior face except that now the order of the traversal ofthe current face is disrupted. As shown in Figure 9, S tries to for-ward to D in perimeter mode. When it gets to C, A will “switchface” because it has found an intersection point I closer than S toD. However, by switching the traversal, not only does the packetnot get to E which would forward to D in greedy mode, but theorder of the traversal of this exterior face is disrupted. In sum-mary, we only switch to another face only when we have comeback from an enclosed face (i.e., we have come back from anedge other than e0, the first edge of the current face) and that onany boundary of such a face, there is an intersection point that iscloser to the destination than the current Lf .Definition A one-time-traversal link is a link that is traversedonly once by a probe.

7

UCLA CSD Technical Report: TR080009, March 26, 2008

c B

D

AS

R1

R3

R4

R2

Figure 10. S forwards to D without VCLCR beingtriggered.

Example Consider a probe for link CB in Figure 2.3, the probetraverses the link twice in each direction. Therefore, CB is not aone-time-traversal link. Note that CLDP will never remove linksthat are not one-time-traversal cross links because it will result innetwork partition. Conversely, CLDP will attempt to remove allone-time-traversal cross links.Lemma 1. It is not necessary to remove all one-time-traversalcross links for a packet to make progress in the perimeter mode.Proof. Consider Figure 10 where S tries to forward to D. Eventhough there is a pair of cross links, S can still forward to Dsuccessfully. Under CLDP, however, either [R1R2] or [R3R4]will have to be removed. Moreover, the choice of which linkto remove greatly affects the hop count. By removing [R3R4]instead of [R1R2], the packet will travel more hops to reach D.This lemma forms the foundation of the next VCLCR property.

Property 3. If a link is removed by VCLCR, either the link itselfor its crossing link will be removed by CLDP. However, if a link isremoved by CLDP, it may not be necessarily removed by VCLCR.

Proof. By VCLCR, a link AB is considered for removal if andonly if the packet has formed a loop, a cross link CD has beendetected, and link AB is adjacent to the current node. Supposethe probe on link AB has entered the “commit” phase (i.e., CDcannot be locked nor probed), CLDP will choose to remove eitherAB or CD. In this case, VCLCR and CLDP will remove thesame link. Now suppose the probe on link CD has entered the“commit” phase (i.e., AB cannot be locked nor probed), eitherCD or AB will be removed by CLDP. Regardless of the choiceof removal by VCLCR, such a link is guaranteed to be either ABor CD.

Now the second part of the proof follows directly fromLemma 1 that CLDP always removes all one-time-traversal crosslinks.

This property indicates two things. First, CLDP is costly. Thecost stems from the unnecessary removal of cross links to guar-antee a global approximate5 planar graph. However, a global pla-nar graph may not be necessary, depending on where the sourceand destination are. Furthermore, removing a cross link is ex-pensive in CLDP. Multiple probes for the link need to be sent toestablish two-phase commit and avoid race conditions. Second, itdemonstrates the on-demand, dynamic, and non-intrusive natureof VCLCR. In Figure 10, before the packet can come back to S toform a loop as a result of cross links, it has already been deliveryto D. Thus, VCLCR is never triggered.Definition A single loop-inducing cross link is one that crossesby exactly one other link. A multiple cross link is one that crossesby more than one other link.

5Some cross links cannot be removed because they are not one-time-traversallinks.

����� ���������

����� ����� � �����

����� ����� ������

����� �����

������� !�" �#�� �����

�����

� ��������#

!��$!���� �����

�����

������Removal of only these

links is important to us!

Figure 11. Cross-link taxonomy.Lemma 2. Based on the definition of what a road segment is inSection 3.1, there can only be single cross links in our scenarios.

Proof. We prove this by contradiction. Suppose a link AB is amultiple cross link, that is, it is crossed by more than one otherlink. Without loss of generality, assume AB is crossed by CDand EF . AB says that there is a junction 2 between road A androad B besides two other junctions 1, 3 that form road A (from 1to 2) and road B (from 2 to 3). If CD and EF cross AB, therewill be at least one more junction in between junction 1 and 3.Based on our definition, four junctions will have to form threeroads. This contradicts to AB that can only be formed by threeunique junctions. Therefore, AB can never be crossed by morethan one link.Property 4. VCLCR only removes single loop-inducing crosslinks.Proof. When the packet comes back to either the same junctionor road, VCLCR-enabled node first checks if there is a cross linkin the local loop. If there is a cross link, it will either remove it orlet the “downstream” link in the loop remove it. These cross links,by definition, are loop-inducing. By VCLCR, they are subject toremoval. Furthermore, based on the above lemma, the cross linkcannot be multiple cross link. Therefore, VCLCR only removessingle loop-inducing cross links. We categorize the types of crosslinks in Figure 11.

Property 5. A loop induced by cross links never repeats itself inVCLCR.Proof. By Lemma 2, there can never be any multiple loop-inducing cross links; that is, a loop can never be created as a resultof a link’s being crossed more than once. Therefore, an offendinglink never becomes loop-inducing again when it itself or its cor-responding crossing link is removed. Moreover, when a link isremoved, VCLCR follows the right-hand rule to explore the newroute which is certainly not on its way back to the original node.Therefore, recreating the same loop is not possible.

Property 5 indicates that VCLCR does not have the same prob-lem as CLDP and LCR in that they need to repeatedly probe toremove multiple cross links. Repeated probing only increases thenumber of packets flooding in the network. Consequently, it pro-longs the convergence time. Property 5 also justifies our designchoice to truncate the probe by the loop since a loop can never berecurring. Keeping it in the probe is of no use.Property 6. Dynamic loop detection finds a route no slower thanLCR.Proof. We denote the first link of this loop L0. A loop can comeback to the source either through L0 or through a link other thanL0. If the loop that comes back to the source is through L0, therewill be a loop formed by all nodes before the source. These nodeswill trigger VCLCR to traverse the loop with cross links removed.

8

UCLA CSD Technical Report: TR080009, March 26, 2008In this case, VCLCR finds a route faster than LCR because loopdetection takes place at “downstream” nodes before the packetloops back to the source. In Figure 6, that is exactly what hap-pens. Before the packet loops back to S, A detects that there is aloop and reroute the packet with the cross link removed.

If the loop that comes back to the source is not through L0,VCLCR and LCR will take care of loop-inducing cross links thesame way. Therefore, the packet will be routed to the destinationat the same time.Property 7. Given a n×n grid, where n is the number of junctionper side, VCLCR’s storage overhead is O(n2).Proof. We will consider the Probe field in the data packet sinceits cost dominates UR and VF fields. Recall that in the Probefield, we store the junction IDs, road IDs, and links. In a n × ngrid, there are n junctions per row. Since there are n rows, thereare n2 junction IDs. In a n × n grid, there are (n − 1) numbersof roads per row and (n−1) numbers of roads per column. Sincethere are n rows and n columns, the total number of roads isn(n− 1) + n(n− 1) roads or 2n(n− 1) roads. Lastly, in a n×ngrid, cross links cannot appear along the edges of the grid becauselinks do not cross on the perimeter. Therefore, it is enough tocount the number of junctions within the grid. For each of thisjunction, the absence of a node produces two cross links. Sincethere are (n−2)(n−2) junctions within the grid, there are 2(n−2)(n − 2) cross links. We can sum up all these quantities andsubtract the number of missing junction IDs that cause cross links(there are (n−1)(n−2) of them). Hence, the worst-case storageoverhead would then be n2 + 2n(n− 1) + 2(n− 2)2 − (n− 2)2

or O(n2).Property 8. VCLCR is neither optimal nor complete.Proof. The non-optimality comes from that fact that perimeterrouting using the right-hand rule is inherently not optimal. Right-hand rule might eventually yield a node that is no closer than anode yielded by the left-hand rule to the destination. The non-optimality solution plagues any face routing algorithm. VCLCRis not an exception.

Completeness says that if there is a solution, the algorithmmust find it. VCLCR is not complete because each face walkoriginated from the source is determined by the right-hand ruleand the right-hand rule does not explore other branching linksalong the walk. However, VCLCR attempts to reach a completesolution by visiting neighboring faces originated from the source(See example in Section 3.4.3). In Figure 10, by trying out thefaces other than S → A → B → C → S, VCLCR eventuallyfinds a solution.

VCLCR can be made complete by doing a recursive traversalsimilar to LCR. The idea would be to visit the neighboring facesof the current non-cross-link looping face recursively. If any oneof the neighboring faces is also a non-cross-link looping face,all the neighboring links on the non-cross-link looping face willalso be visited. This recursion stops until at least one face traver-sal reaches the destination. The destination then initiates somekind of signaling to stop all recursive packets trying to reach itto avoid flooding. The destination also notifies the source so thatfuture packets would be sent through this route to avoid repeatedrecursions experienced by future packets. In the worst case whenthe destination is disconnected, the packet is duplicated at everynode and the network becomes flooded.

Because of the observation that “on random graphs, we havenever found the need to recurse more than one level to makeprogress towards the destination” [15] and because of the dy-namic nature of the VANET, the cost of a complete solutionoutweighs its benefit. We therefore choose to keep VCLCRlightweight and simple without pursuing a complete solution.

3.6 VCLCR Optimizations3.6.1 Time Optimization - By CacheIn Figure, it is not too hard to see that every packet originatedfrom S will loop back to H , get stamped with the same unroutablelink in their UR, and get forwarded to the destination again with-out link [R5R6]. This redundancy can be eliminated by cachingthe unroutable link at a node (in our example, it is node H) wherethe link is first stamped into the UR. Future packets can then bestamped with this information in their UR from the cache a-priorito avoid looping back unnecessarily. Cache is uniquely identifiedwith each source-destination pair because the virtual edge formedby the source and destination can affect the outcome of the loopand the node at which cache is stored. In addition, to considermobility, cache expires after a certain timeout. We implementVCLCR+CACHE and show the results in Section 4.

3.6.2 Space Optimization - By Recording Cross Link OnlyThe cost for storing roads, links, and junction IDs can be tremen-dously high for a VCLCR packet. The cost grows quadraticallywith the number of roads the packet travels in the network (shownin Property 7). One way to reduce this cost is to record onlythe missing junction ID and a direction. When a node forwardspassed a missing junction, it would record the missing junctionID and a direction in the form of a tuple (North, South) matchedmost closely from a predefined permutation of cardinal orienta-tions (North, South, East, and West) and their derived orienta-tions (NE, NW, SE, and SW). If the missing junction is passedmore than once, the new direction will be appended to the ex-isting direction. A cross link can be recognized as one wherethere is more than one direction associated with the junction ID.A removable cross link can be identified as one where there is noopposite direction; that is, the cross link is not traveled in bothdirections.

When the packet loops back to the source, it can then deter-mine the removable cross link and place the offending cross linkin the form of junction ID and direction in the UR field of thepacket. When the packet arrives at a node that is about to crossthe same junction in the same direction as noted in the UR field,the node would switch to a node on a different link to avoid loop-ing back to the source. The storage cost, in the new scheme, doesnot depend on the number of roads traveled but on the numberof cross links seen. However, the drawback of the new schemeis that loops can only be detected by the source, not by nodesalong the way back to the source. Because nodes along the wayare not able to make dynamic decision in forwarding packets withcross links removed, the new scheme can potentially incur longerend-to-end delay. In the new scheme, we trade time for space.We plan to verify the new scheme’s correctness and compare itslatency with the original VCLCR in the future.3.7 Summary of VCLCR Features

We summarize VCLCR features below:

1. On-demand: VCLCR only removes cross links that causerouting loops. Based on Lemma 1 there is no reason to spendnetwork resources to remove cross links unless they causerouting loops. Links are of concern if packets are routed onthem.

2. Lightweight: VCLCR does not recursively look for a solu-tion by taxing all nodes to do a face traversal. Not only doesa full traversal of all possible links from each node put greatstrain on the network, but it also makes the routing algorithmcomplex. VCLCR simply drops the packet if the source hascompleted all possible face traversals with its neighbors.

9

UCLA CSD Technical Report: TR080009, March 26, 20083. Simple: In VCLCR, cross-link removal is done sequentially

according to the face routing by the right-hand rule. VCLCRdoes not require global synchronization and locking of nodesto perform simultaneous cross-link removals like CLDP.

4. Efficient: VCLCR’s removal of cross links is a destination-oriented procedure. The goal of a node in perimeter modeis to find another node which is geographically closer to thedestination than the perimeter-mode starting node. VCLCRstops whenever the packet can switch back to greedy mode.Therefore, a lot of unnecessary work is avoided.

5. Cheap: VCLCR works well in high mobility VANET be-cause it does not incur signaling overhead. Unlike VCLCR,CLDP and LCR need to rebuild unroutable links at ev-ery node every time the network topology changes. Fur-thermore, nodes’ probes will saturate the network to makepacket delivery impossible.

6. Fast: In VCLCR, the cross-link removal procedure is per-formed as long as the packet routes back to the same node(not necessary the source). Then, the packet is forwarded outon the same road again. This means VCLCR repeatedly re-moves cross links for a route until the feasible path is foundwhile the packet is making advances toward the destination.For CLDP and LCR, because some link may be crossedmore than once, removing its crossing links have to be doneone link at a time to avoid network disconnection. The con-verging time of CLDP, however, is bounded by the probingupdate period.

7. Stateless: VCLCR-enabled nodes do not keep any states.However, we also propose a “soft-state” VCLCR that keepscache at certain nodes to improve end-to-end latency andhop count.

4 PERFORMANCE EVALUATIONIn this section, we evaluate VCLCR and VCLCR+Cache by

comparing them with GPSR and GPCR. Our objective is to showthat VCLCR improves performance significantly compared toGPSR and GPCR. We plan to port LCR in TinyOS to Qualnetto establish empirical evidence of LCR’s relative performance toVCLCR. First we describe our experimental setup and then pro-vide simulation results.4.1 Experimental Setup

We based our experiments on Qualnet simulator 3.95. Weuse IEEE 802.11b DCF as the MAC with a transmission rate of2Mbps and transmission range of 250m. We assume that nodeson different roads cannot talk to each other because of obstacles(trees, buildings, etc.) unless two roads share the same extensionin either the horizontal or vertical direction.

The mobility traces were generated by VanetMobiSim [16], anopen source and freely available realistic vehicular traffic gener-ator for network simulators. VanetMobiSim’s functionalities aredecomposed into macro- and micro- mobility features of a vehic-ular environment to produce realistic urban mobility traces. Themacro-mobility part is composed of motion constraints and a traf-fic generator, while the micro-mobility part controls cars’ accel-eration and deceleration in order to keep a safe inter-distance andavoid accidents and overlapping.

The urban topology shown in Figure 12 is a realistic 1000m by1000m Washington, D.C. from U.S. Census Bureau’s Topologi-cally Integrated Geographic Encoding and Referencing (TIGER)database [7]. All intersections are controlled by stop signs and allroad segments contain speed limitations. Unless specified differ-ently, all roads have a single lane and a speed limit of 15m/s (54

Figure 12. TIGER Map of Washington, D.C.km/h). Finally, the micro-mobility is controlled by the IDM-IM4,an extension to the Intelligent Driver Model (IDM) consideringintersections.

With the aforementioned setup, we run two experiments. Thefirst experiment is a static scenario of 100 nodes. The placementof nodes is such that we expose routing protocols to high prob-ability of cross links. We then obtain the packet delivery ratio(PDR), hop count, and failed hop (the average number of hopsthat an unsuccessful packet experiences before being dropped).We repeat the experiment for 100 runs. Each run consists of 10random src-dest pairs using constant bit rate (CBR), an UDP-based packet generation application. In the second experiment,we introduce mobility by inserting nodes into a strip of roadswhere empty junctions are likely to happen. The insertion ofnodes “simulates” the behavior of cars moving into these roads.Nodes are inserted in 20-node increment until the total number ofinserted nodes reaches 100. The coordinates of inserted nodes aregenerated by VanetMobisim to ensure mobility fidelity. We repeatthis experiment 20 runs for each 20-node increment insertion fora total of 100 runs. Each run consists of 30 random src-dest pairsusing CBR packet generation application.4.2 Experiment Results4.2.1 Static ScenarioFigure 13(a) shows the packet delivery ratio of GPSR, GPCR,VCLCR, and VCLCR+Cache for each run up to 100 runs. Anaverage delivery ratio (PDR) is obtained for the 10 random src-dest pairs per each run. A quick glance shows that VCLCR andVCLCR+Cache display a higher PDR than GPCR and GPSRsince VCLCR and VCLCR+Cache remove cross links that re-sult in routing loops for most src-dest pairs. The oscillation ex-plains the random selection of src-dest pairs. Some src-dest pairsare unreachable; therefore, it explains the low PDR for all rout-ing protocols (for example in run 24). Some src-dest pairs areonly reachable with cross links removed; therefore, it explainsthe VCLCR’s and GPCR’s opposing heights in PDR (for exam-ple in run 10). The figure also shows that without VCLCR orVCLCR+Cache, the highest PDR that GPCR can deliver is about52

Figure 13(b) shows the results of 100 runs of the experi-ment sorted by the delivery ratio of VCLCR in ascending or-der. One obvious observation is that VCLCR+Cache further im-proves VCLCR. The caching reduces the number of hops thateach packet has to travel (evident also in Figure 14c)); therefore,it results in slightly higher PDR. The other observation is that

10

UCLA CSD Technical Report: TR080009, March 26, 2008

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

CDF of PDR

Packet Delivery Ratio

GPSRGPCR

VCLCRVCLCR+Cache

(a) PDR

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50

CDF of avg. hops

Avg. number of hops (delivered packets)

GPSRGPCR

VCLCRVCLCR+Cache

(b) Hop count

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50

CDF of hops

Avg. number of hops (dropped packets)

GPSRGPCR

VCLCRVCLCR+Cache

(c) Failed hop

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5

CDF of latency

Avg. latency (secs)

GPSRGPCR

VCLCRVCLCR+Cache

(d) Latency

Figure 14. Measurements for dynamic scenario.

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50 60 70 80 90 100

Packet Delivery Ratio

Experiment id

GPSRGPCR

VCLCRVCLCR+Cache

(a)

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50 60 70 80 90 100

Packet Delivery Ratio

Experiment id (sorted based on VCLCR)

GPSRGPCRVCLCR

VCLCR+Cache

(b)

Figure 13. PDR for static scenario.

there is a subtle downward trend (minus the outliers) of PDR forGPCR for an upward trend of PDR for VLCLR(+Cache). Theopposing, diverging trends indicate that cross link is the culpritfor low packet delivery. The trends also confirm that removal ofcross links is beneficial in improving packet delivery.

Figure 14(a)-14(d) show the cumulative distribution function(CDF) of PDR, hop count, latency, and failed hop. Figure 14(a)indicates that about 90% of the random src-dest pairs deliver suc-cessfully 50%+ of the time in VCLCR and VCLCR+Cache whileclose to 0% of the random src-dest pairs deliver successfully50%+ of the time in GPCR and GPSR. Figure 14b) shows theCDF of hop counts of successful packets for each protocol. At 20hops, there are 81% of src-dest pairs for GPCR, 78% for GPSR,90% for VCLCR+Cache, and 20% for VCLCR. GPCR’s hopcounts are less than GPSR’s because GPCR is “greedy” in bothgreedy and perimeter mode. GPCR’s and GPSR’s hop counts areless than VCLCR+Cache’s and VCLCR’s because the destina-tions that cannot be successfully delivered by GPCR and GPSRcontribute zero to the average hop count. In other words, sincemost src-dest pairs are not reachable because of cross links, theircontribution (0 hop count) to the average hop count only lowersit. The same src-dest pairs that are unreachable are reachable inVCLCR and VCLCR+Cache with nonzero hop count. Thus, theycontribute to higher average hop count. We also see that cachingdramatically improves the average hop count as 90% of src-destpairs take 20 or less hops in VCLCR+Cache and only 20% of src-dest pairs take 20 or less hops in VCLCR. Figure 14c) shows theCDF of latency, which is consistent with the CDF of hop count inFigure 14(b).

Figure 14(c) shows the failed hops of the four routing pro-tocols. It reveals two things. First, the number of failed hopsexperienced by an undeliverable packet for GPSR is higher thanthe other three routing protocols. Before the packet makes a loopback to the source, it has made too many hops due to node pla-narization. Second, the figure also suggests that VCLCR and

11

UCLA CSD Technical Report: TR080009, March 26, 2008VCLCR+Cache have higher failed hops than GPCR. A closer in-spection of the way the average failed hop is calculated explainswhy this is the case. In the scenario where there is no cross link inthe perimeter traversal in the unreachable src-dest pair, the num-ber of failed hops for GPCR, VCLCR, and VCLCR+Cache is thesame. However, in the scenario where there is a cross link, thenumber of failed hops for VCLCR and VCLCR+Cache is higherthan GPCR’s because VCLCR and VCLCR+Cache do not dropthe packets at the loop but continue forwarding the packets. Giventhat the average failed hop is the number of hops divided by thenumber of dropped packets and that the denominator is held con-stant (the number of dropped packets), this quantity is higher forVCLCR and VCLCR+Cache than GPCR.

4.2.2 Mobile ScenarioFigure 15(a)-15(d) show the PDR, hop count, latency, and failedhop of the four routing protocols in experiment two in whichincrement of 20 nodes is introduced to a strip of roads wherecross links are likely to occur until the number of additionalnodes reaches 100. In Figure 15(a), the PDR of VCLCR andVCLCR+Cache remains steady and the PDR of GPSR and GPCRincreases as the number of nodes increases. This outcome is ex-pected since the denser the roads, the more likely junctions arenonempty. While VCLCR and VCLCR+Cache delivers packetswith or without junction nodes, the presence of junction nodesgreatly helps GPCR and GPSR. Figure 15(b) shows the hop countof all four routing protocols. Once again, the lower hop countat 0 additional node for GPCR and GPSR than for VCLCR andVCLCR+Cache is because most src-dest pairs fail to communi-cate with each other in the presence of cross links and result inzero hop count contribution. Consequently, they lower the aver-age number of hops for GPCR and GPSR. But at the number ofnodes increases, the gap becomes smaller. Starting from 80 nodesonwards, GPCR, VCLCR, and VCLCR+Cache result in the samehop count. As the number of nodes increases, however, GPSR be-comes increasingly inefficient. Node planarization prevents pack-ets from making large “strides” to the destinations. Once again,we see the slight advantage of caching unroutable links to reducethe average hop count. Figure 15(d) shows the corresponding la-tency of the four routing protocols, consistent with the hop countin Figure 15(b). Figure 15(c) shows the failed hops, the num-ber of hops experienced by an unsuccessfully delivered packet,of the four routing protocols. Once again, GPSR’s failed hop in-creased as the number of nodes increases due to planarization.As explained in the static case, GPCR’s failed hop is lower thanVCLCR’s and VCLCR+Cache’s because GPCR does not re-routelooping packets under the presence of cross links. As the numberof nodes increases, the number of cross links starts to disappearand the failed hop count for GPCR, VCLCR, VCLCR+Cacheconverges.

5 ConclusionIn this paper, we propose VCLCR, a simple, lightweight,

yet novel, event-driven geographic routing protocol that removescross links dynamically to avoid routing loops in urban Vehic-ular Ad Hoc Networks (VANETs). The salient features of dy-namic loop detection and statelessness make VCLCR suitable forhighly mobile VANET. Simulations using realistic city map andtraces from realistic mobility generator have shown that in bothstatic and mobile cases, VCLCR’s packet delivery ratio (PDR) isconsistently higher than GPSR’s and GPCR’s. We also demon-strate that it is possible to reduce hop count and improves the

PDR further by caching an unroutable link in nodes where itis first determined. Finally, we propose a scheme to compressVCLCR packet efficiently by recording only a vector that con-tains the cross link with its direction. Future works include com-paring space-optimized VCLCR and ported LCR with the origi-nal VCLCR. In conclusion, we have shown VCLCR to be a fea-sible and suitable geographic routing protocol in urban scenarios.

References

[1] 802.11p. http://grouper.ieee.org/groups/802/11/Reports/tgp_update.htm.

[2] Car to Car Communication Consortium (C2CCC). http://www.car-to-car.org.

[3] Continous Air Interface for Long and Medium Interface (CALM).http://www.calm.hu.

[4] dash. http://www.dash.net/.[5] ITS Standards. http://www.standards.its.dot.gov/

about.asp.[6] The Vehicle Infrastructure Integration (VII) Initiative. http://

www.vehicle-infrastructure.org.[7] Tiger, tiger/line and tiger-related products. U.S. Census Bureau.

[Online]. http://www.census.gov/geo/www/tiger/.[8] P. Bose, P. Morin, I. Stojmenovic, and J. Urrutia. Routing with

guaranteed delivery in ad hoc wireless networks. Wireless Networks,7(6):609–616, 2001.

[9] P. Bose, P. Morin, I. Stojmenovic, and J. Urrutia. Routing with guar-anteed delivery in ad hoc wireless networks. Wirel. Netw., 7(6):609–616, 2001.

[10] T. Clausen and P. Jacquet. Optimized link state routing protocol(olsr), 2003.

[11] R. Flury and R. Wattenhofer. MLS: an efficient location service formobile ad hoc networks. In MobiHoc ’06: Proceedings of the 7thACM international symposium on Mobile ad hoc networking andcomputing, pages 226–237, New York, NY, USA, 2006. ACM.

[12] H. Fußler, H. Hartenstein, J. Widmer, M. Mauve, and W. Effels-berg. Contention-based forwarding for mobile ad-hoc networks.

[13] H. Fußler, H. Hartenstein, J. Widmer, M. Mauve, and W. Effels-berg. Contention-based forwarding for street scenarios.

[14] K. R. Gabriel and R. Sokal. A new statistical approach to geo-graphic variation analysis. 18 Systematic Zoology, pages 231–268,1969.

[15] Y.-J. K. R. Govindan, B. Karp, and S. Shenker. Lazy cross-linkremoval for geographic routing. In SenSys ’06: Proceedings of the4th international conference on Embedded networked sensor sys-tems, pages 112–124, New York, NY, USA, 2006. ACM.

[16] J. Harri, F. Filali, C. Bonnet, and M. Fiore. Vanetmobisim: gen-erating realistic mobility patterns for vanets. In VANET ’06: Pro-ceedings of the 3rd international workshop on Vehicular ad hoc net-works, pages 96–97, New York, NY, USA, 2006. ACM.

[17] 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: Pro-ceedings of the 2nd ACM international symposium on Mobile adhoc networking & computing, pages 259–262, New York, NY, USA,2001. ACM.

[18] D. B. Johnson and D. A. Maltz. Dynamic source routing in adhoc wireless networks. In Imielinski and Korth, editors, MobileComputing, volume 353. Kluwer Academic Publishers, 1996.

[19] R. G. K. Seada, A. Helmy. On the effect of localization errors ongeographic face routing on sensor networks. In Proceedings of theThird IEEE International Workshop on Information Processing inSensor Networks, 2004.

[20] B. Karp. Challenges in geographic routing: Sparse networks, ob-stacles, and traffic provisioning. Presentation at DIMACS Workshopon Pervasive Networking, Piscataway, NJ, May, 2001.

12

UCLA CSD Technical Report: TR080009, March 26, 2008

0

0.2

0.4

0.6

0.8

1

0 20 40 60 80 100

Packet Delivery Ratio

Number of Nodes

GPSRGPCR

VCLCRVCLCR+Cache

(a) PDR

0

5

10

15

20

25

30

35

40

45

0 20 40 60 80 100

Number of Hops (Delivered Packets)

Number of Nodes

GPSRGPCR

VCLCRVCLCR+Cache

(b) Hop count

0

10

20

30

40

50

60

0 20 40 60 80 100Number of Hops (Dropped Packets)

Number of Nodes

GPSRGPCR

VCLCRVCLCR+Cache

(c) Failed hop

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0 20 40 60 80 100

Latency

Number of Nodes

GPSRGPCR

VCLCRVCLCR+Cache

(d) Latency

Figure 15. Measurements for dynamic scenario.

[21] B. Karp. Geographic Routing for Wireless Networks. PhD thesis,2000.

[22] B. Karp and H. T. Kung. GPSR: greedy perimeter stateless routingfor wireless networks. In Mobile Computing and Networking, pages243–254, 2000.

[23] Y.-J. Kim, R. Govindan, B. Karp, and S. Shenker. Geographic rout-ing made practical. In NSDI’05: Proceedings of the 2nd conferenceon Symposium on Networked Systems Design & Implementation,pages 217–230, Berkeley, CA, USA, 2005. USENIX Association.

[24] Y.-J. Kim, R. Govindan, B. Karp, and S. Shenker. On the pitfallsof geographic face routing. In DIALM-POMC ’05: Proceedings ofthe 2005 joint workshop on Foundations of mobile computing, pages34–43, New York, NY, USA, 2005. ACM.

[25] E. Kranakis, H. Singh, and J. Urrutia. Compass routing on geomet-ric networks. In Proc. 11 th Canadian Conference on ComputationalGeometry, pages 51–54, Vancouver, August 1999.

[26] F. Kuhn, R. Wattenhofer, Y. Zhang, and A. Zollinger. Geometricad-hoc routing: of theory and practice. In PODC ’03: Proceedingsof the twenty-second annual symposium on Principles of distributedcomputing, pages 63–72, New York, NY, USA, 2003. ACM.

[27] K. Lee, S. Lee, R. Cheung, U. Lee, and M. Gerla. First experiencewith cartorrent in a real vehicular ad hoc network testbed. IEEEMobile Networking for Mobile Environments(INFOCOM/MOVE),May 2007.

[28] K. C. Lee, J. Haerri, U. Lee, and M. Gerla. Enhanced perimeterrouting for geographic forwarding protocols in urban vehicular sce-narios. Globecom Workshops, 2007 IEEE, pages 1–10, 26-30 Nov.2007.

[29] B. Leong, B. Liskov, and R. Morris. Geographic routing withoutplanarization. In NSDI’06: Proceedings of the 3rd conference on3rd Symposium on Networked Systems Design & Implementation,pages 25–25, Berkeley, CA, USA, 2006. USENIX Association.

[30] J. Li, J. Jannotti, D. S. J. D. Couto, D. R. Karger, and R. Morris.A scalable location service for geographic ad hoc routing. In Mo-biCom ’00: Proceedings of the 6th annual international conferenceon Mobile computing and networking, pages 120–130, New York,NY, USA, 2000. ACM.

[31] C. Lochert, H. Hartenstein, J. Tian, H. Fussler, D. Hermann, andM. Mauve. A routing strategy for vehicular ad hoc networks in cityenvironments. Intelligent Vehicles Symposium, 2003. Proceedings.IEEE, pages 156–161, 9-11 June 2003.

[32] C. Lochert, M. Mauve, H. Fussler, and H. Hartenstein. Geographicrouting in city scenarios. SIGMOBILE Mob. Comput. Commun.Rev., 9(1):69–72, 2005.

[33] A. Nandan, S. Das, G. Pau, M. Gerla, and M. Y. Sanadidi. Co-operative downloading in vehicular ad-hoc wireless networks. Sec-ond Annual Conference on Wireless On-demand Network Systemsand Services (WONS), pages 32–41, July 2005.

[34] V. Naumov, R. Baumann, and T. Gross. An evaluation of inter-vehicle ad hoc networks based on realistic vehicular traces. In Mo-biHoc ’06: Proceedings of the 7th ACM international symposiumon Mobile ad hoc networking and computing, pages 108–119, NewYork, NY, USA, 2006. ACM.

[35] L. Parker. Peer-to-peer network invites drivers to get connected.http://www.guardian.co.uk/technology/2008/jan/17/researcanddevelopment.technology, 2008.

[36] G. Pei, M. Gerla, and X. Hong. Lanmar: Landmark routing forlarge scale wireless ad hoc networks with group mobility, 2000.

[37] G. Pei, M. Gerla, X. Hong, and C.-C. Chiang. Wireless hierarchicalrouting protocol with group mobility (WHIRL). Technical Report990006, 25, 1999.

[38] C. E. Perkins and E. M. Royer. Ad hoc on-demand distance vectorrouting. Proceedings of the 2nd IEEE Workshop on Mobile Com-puting Systems and Applications, pages 90–100, February 2005.

[39] G. Toussaint. The relative neighborhood graph of a finite planarset. Pattern Recognition, 12:231–268, 1980.

[40] Y. Yu, G.-H. Lu, and Z.-L. Zhang. Enhancing location servicescalability with high-grade. Mobile Ad-hoc and Sensor Systems,2004 IEEE International Conference on, pages 164–173, 25-27 Oct.2004.

13