robustgeo: a disruption-tolerant geo-routing...

11RobustGeo: A Disruption-Tolerant

Geo-Routing Protocol

Ruolin Fan1, Yu-Ting Yu2 and Mario Gerla1

1Department of Computer Science, University of California,Los Angeles, CA, USA2Qualcomm Research, Bridgewater, NJ, USA

Abstract

While geo-routing is a promising routing algorithm in urban vehicular ad-hocnetworks (VANETs), there is still much work to be done for it to becometruly usable for such environments. One of the biggest obstacles to thisgoal is the intermittent nature of VANETs due to mobility. Traditional geo-routing algorithms do not perform well in these conditions because they droppackets whenever they cannot find an immediate forwarder for the packet.In this chapter, we propose RobustGeo, a routing protocol that combines thesimplicity and efficiency of the greedy forwarding technique in geo-routingalgorithms, with the robustness of delay-tolerant networks in the face ofdisruptions in network connectivity. When there exists a good connectionbetween the source and destination, RobustGeo can route the packet like thetraditional geo-routing algorithms, and when the network faces disruptions,RobustGeo relies upon vehicle mobility and packet replication to exploremultiple geo-route paths and quickly recover the packet back to greedyforwarding. We show that for a highly intermittent scenario, RobustGeo has adelivery ratio of over 20% (compared to a pure geo-routing protocol’s deliveryratio of 0), and it reduces the delay by over 40% as compared to a more puredelay-tolerant routing solution.

Keywords:Delay-tolerant networks, geo-routing, VANET, ad-hoc networks,mobility.

315

316 RobustGeo: A Disruption-Tolerant Geo-Routing Protocol

11.1 Introduction

Location-based routing algorithms are a class of routing algorithms that uselocations of forwarding nodes to route packets. Unlike the more traditionallink-state (LS) or distance-vector (DV) algorithms that rely on each nodehaving some overarching information on the network topology [1], location-based routing generally only requires each node to have information on itsimmediate neighbors. This is a desirable property to have because it obviatesthe need for nodes to periodically flood the network with routing-relatedmessages. Because of their scalability in this respect, these algorithms offera very promising solution to the difficult problem of routing in vehicular ad-hoc networks (VANETs), where the network topology changes rapidly andbandwidth is limited [2].

One of the first and the most well known of these routing protocols isthe Greedy Perimeter Stateless Routing (GPSR) protocol [3], which sets thefoundation for almost all subsequent location-based routing algorithms. InGPSR, each node in the network keeps a list of its immediate neighbors andtheir locations. Packets are thus routed based on greedy forwarding undernormal circumstances, where the forwarding node transmits packets to theneighbor who is the closest geographically to the packets’ destination. Whenno node closer to the destination than the current one can be found, the packetis said to have encountered a local maximum and must be routed around theperimeter via perimeter forwarding, which requires a careful mapping of thenodes to form planar graphs so that routing loops can be avoided.

While the greedy forwarding method proposed by GPSR offers a greatsolution to routing in VANETs, the perimeter routing approach as a solutionto the local maximum problem is inadequate [4], as the highly mercurialnetwork topology common to VANETs quickly outdates any planar graphsthat may have been built from the nodes, much like routing tables in theDV and LS algorithms. GPCR (Greedy Perimeter Coordinator Routing) [5],another location-based routing protocol that focuses more on urban VANETs,takes advantage of the urban layout that naturally forms a planar graph forits recovery strategy from a local maximum and proposes the restrictedgreedy forwarding method, which prioritizes forwarding packets to urbancross-streets for better routing decision making.

To the end of avoiding local maximums and getting out of them in urbanVANETs, many proposals are made [6–9]. However, all of them make theassumption that despite mobility and the urban landscape, the network isalways connected. Unfortunately, this is not the case for VANETs in reality,

11.2 Background 317

where the network is often partitioned or disrupted due to mobility, givingno instant end-to-end routes. According to [10], network connections inVANETs are highly dependent upon inter-vehicle spacing, which is neverconstant, and that on freeways network disconnectivity generally heals on theorder of seconds. In such situations, conventional geo-routing algorithms willcause large numbers of packets to be dropped. To address this problem, wepropose RobustGeo, a location-based routing algorithm that takes the storeand forward and replication approaches of delay-tolerant networks to explorethe possibility of multiple paths to overcome such disruptions in VANETconnectivity.

Although delay-tolerant networks (DTNs) were originally proposed fornetworks that experience very frequent and long periods of disconnectivity[11], the DTN methods, with modification, can be used to deal with the shorterintermittencies in geo-routing with great benefits. One such method is the DataMULE (Mobile Ubiquitous LAN Extension) [12] that exploits node mobilityto deliver packets. While this used by itself translates to unacceptable delaylengths in more conventional networks, we can, in the same spirit, rely onnode mobility to recover from a disconnected scenario by saving the packetand actively looking for greedy forwarding routes at the same time. Anotherimportant aspect of DTNs is packet replication, as seen in Epidemic Routing[13] and Spray and Wait [14]. The drawback to these methods is mainlyin bandwidth overhead when too many packet replications occur. However,by using similar methods while limiting the number of replications, we canincrease the packet delivery ratio and minimize delay.

With the combination of traditional geo-routing schemes and DTNapproaches, RobustGeo indeed offers a more robust solution for geo-routing inurban VANETs. When the network connectivity is good, RobustGeo simplyacts like any other state-of-the-art location-based routing algorithm. Whenthe connectivity is intermittent, RobustGeo is not only able to withstand thesedisruptions and continue forwarding packets when the network heals, but alsomake use of the mobility of nearby neighboring nodes to even increase thehealing rate (in the perspective of the packet stored by the node).

The rest of this chapter is organized as follows. Section 11.3 describesthe general design of RobustGeo, while Section 11.4 analyzes the potentialeffects and consequences of packet replication. In Section 11.5, we evaluateRobustGeo by comparing it with three other geo-routing and DTN approachesand conclude with Section 11.7.


11.2 Background

11.2.1 Location-based Routing Algorithms

Location-based routing algorithms are a class of routing algorithms thatuses locations of forwarding nodes to route packets, rather than using themore traditional link-state or distance-vector algorithms. One of the firstand the most well known of these routing protocols is Greedy PerimeterStateless Routing (GPSR) protocol [3]. GPSR improves upon the link-stateand distance-vector algorithms because it employs a much more scalableapproach that obviates the need for each node to have information about thenetwork over more than a single hop. This means that it is not bogged downas much by the trade-off between having stale routes leading to routing loops,or overwhelming the network with update or status exchange messages.

In GPSR, each node in the network is able to route packets simplyby keeping a list of its immediate neighbors and their locations. Undernormal circumstances, GPSR routes packets based on what it calls “greedyforwarding”. With greedy forwarding, a node greedily routes the packet to itsneighbor who is the closest geographically to the packet destination. With thisapproach, the packet is routed hop by hop and any beaconing is done purelyin a single hop basis, preventing the network from becoming congested withrouting messages.

However, greedy forwarding does not work completely on its own, sincesituations sometimes arise where a packet arrives at what is called a “localmaximum” node, where another closer node cannot be found. Rather, thepacket would temporarily need to be routed further away from the destinationbefore greedy forwarding can be resumed. GPSR’s solution to this problemis perimeter routing, which routes the packet around the perimeter of the voidarea. To avoid crosslinks that can cause routing loops, a planar graph must firstbe constructed. The packet can then be routed along the planar graph usingright hand rule to the destination. Two ways to construct such a planar graphare the “Relative Neighborhood Graph” (RNG) or “Gabrel Graph” (GG). Ifthe destination is unreachable, the packet would be routed back to the localmaximum node and dropped.

While the greedy forwarding method proposed by GPSR offers a greatsolution to routing in VANETS, the perimeter routing approach to solvethe local maximum problem is not much help. This is because in an urbansetting with VANETs, mobility causes rapid changes in the network topologythat quickly outdates any planar graphs that may have been built from thenodes. Moreover, physical buildings and radio interference common in theseenvironments cause the local maximum phenomenon to occur frequently,

11.2 Background 319

especially if pure greedy forwarding was used. As highlighted in [5], a packetmay be greedily forwarded to a location exactly at the opposite side of abuilding from the destination, prompting perimeter routing to be used forfurther forwarding of the packet. Lochert et al.’s solution to this problemis Greedy Perimeter Coordinator Routing (GPCR), which proposes the ideaof restricted greedy forwarding, where the packet is greedily forwarded tojunction nodes rather than as close to the destination as possible. In GPCR,junction nodes are nodes located at the block intersections in the city, whichmakes better decisions on where the packet should be forwarded next becauseit can help the packet to take a turning path. GPCR also presents a form ofperimeter routing of its own, of which it terms a “recovery strategy”. In itsperimeter routing, GPCR does not construct a planar graph from scratch assuggested by GPSR, but takes advantage of the urban layout with the junctionnodes, which naturally forms a planar graph on which the packet can traverse.

The problem of how to most effectively route packets using positional-based routing techniques in an urban setting is an interesting one, becausethe urban grid has a more stable topology, and it is very easy for packets toget stuck in a local maxima because of buildings. To this end, many furtherenhancements were made. References [6, 7] propose to propagate the beaconsby an extra hop for nodes to get a better view of the geographic topologyand find the junction nodes more efficiently. References [6, 9] both suggestan anchoring system where packets are routed along anchored streets, withinformation from static maps or GPS with live traffic information. When apacket reaches the local maximum, a new anchor is computed from the mapand the packet is forwarded along the new street.

All of these contributions are either suggesting ways to avoid the localmaximum situation by some new greedy forwarding scheme, or proposingsome new way of recovering from a local maximum situation. RobustGeo iscompatible with most of the suggested ways of avoiding the local maximumsituation, but in terms of recovery, it utilizes a solution in the spirit of thedelay-tolerant networks.

11.2.2 Delay-Tolerant Networks

As suggested by its name, delay-tolerant networks are a class of networks thatexperience very frequent and long periods of disconnectivity [11]. In thesenetworks, delivery rate and power consumption take on a higher priority thanthe speed of delivery, though higher speeds of dissemination are still preferredif possible. Almost all DTN routing algorithms use some variations of storeand forward, where mobile nodes store the packet and physically deliver it to


the destination, to other nodes that eventually forwards it to the destination,or to a more connected network that will guarantee delivery.

Data Mobile Ubiquitous LAN Extensions (MULEs) [12] and messageferries [15] are two examples of such algorithms. While they both exploit thehigher chances of delivery in mobile nodes, the two approaches differ in thatMULEs are reactive, whereas ferries are proactive. This means that MULEspasses data along to any mobile nodes that comes into the range of the lessmobile nodes and hope that it travels to somewhere with connectivity fordelivery. Ferries, on the other hand, employ mobile nodes that move in a non-random fashion with the purpose of picking up packets and delivering them totheir destinations. Another more extreme approach is epidemic routing [13],where any node that meets any other nodes would pass along the messageso that it can eventually reach its destination. While this approach results ina high chance of delivery rate given enough time (eventually 100%), it alsointroduces a lot of overhead and higher congestion into the system, especiallywhere node storage capacity is an issue. The spray and wait routing algorithm[14] seeks to alleviate such transmission overhead concerns by limiting theoverall number of copies of the packet that can be in the network. Spray andwait operates in two phases: in the spray phase, L copies of the message aredisseminated into the network, and in the wait phase, each node with a copyof the message move around until it can be delivered to the destination.

As seen from above, almost all DTN routing approaches are replication-based, that is, multiple copies of the message are disseminated in the networkto increase the chances of data delivery. They are much more preferred oversingle copy approaches because of the high frequency and long periods ofnetwork disconnectivity, which poses a great obstacle in finding a route thatis needed in a single copy routing approach. However, it must be noted atthis junction that the scenarios for which these protocols are designed arequite different from the urban VANET scenario. While urban VANETs doexperience high frequencies of network partitioning due to environment andmobility, the period for which the network is disconnected is usually short. Atthe same time, though the message delivery speeds in the proposed VANETscenarios are more tolerant of delays than the Internet, delivery times onthe order of hours [11] are unacceptable. In addition, transmission overheadscaused by overzealous replication of packets can cause more harm than goodin an environment where radio interference itself is a cause for networkintermittency. For these reasons, directly using a DTN approach to route in aVANET would generally not work well simply due to tighter delay constraintsand network bandwidth availability. However, a hybrid approach that usesideas from DTN, such as data MULEs in [12] and limited replication of

11.3 Design 321

messages in [14], stabilizes a VANET scenario that is otherwise bogged downby frequent interruptions to connectivity.

11.3 Design

RobustGeo combines the quick speed of geo-routing with the robustness ofdelay-tolerant networking. Under normal circumstances, greedy forwardingis used to quickly route packets to its destination. When, unavoidably, alocal maximum situation arises, it can use a good recovery algorithm likethe one suggested in [8] to route around the perimeter while at the same timesafeguard against complete disconnectivity by employing the delay-tolerantnetworking routing approach. In this approach, the nodes keep the packets intheir disruption tolerant queue (DTQ), where the packets are opportunisticallyrouted as available greedy forwarding neighbors are found. Periodically, nodesbroadcast the packets inside their DTQ to their one-hop neighbors to exploreother possible paths and increase the chances of finding a geo-routed pathtoward the destination.

11.3.1 Geo-Routing

The geo-routing component of RobustGeo is compatible with all types ofgreedy-forwarding mechanism based on the one proposed in [3]. Generally,each node keeps a list of its immediate neighbors and looks for the neighborgeographically closest to the packet destination. Following these neighbors,the packets are forwarded greedily step by step until it reaches its destination.To combat the challenges posed by urban grid layouts and high urbanerror rates, restrictive forwarding approaches as described in GPCR [5],GpsrJ + [7], and TO-GO [8] can be employed.

Likewise, RobustGeo can utilize any of the previously existing solutionsfor perimeter forwarding to attempt local maxima recovery.

11.3.2 Disruption Tolerance

The DTN component of RobustGeo exploits the mobile nature of VANETS.In such a highly mobile environment, it is beneficial to not give up on a localmaximum node so quickly since topology can evolve quite rapidly. In manycases, a local maximum at one moment in time may very well no longer bea local maximum in the next simply because of mobility. Therefore, unlikeconventional geo-routing algorithms, when the perimeter forwarding phase isentered, RobustGeo routes a replica of the packet around the perimeter rather


than the original packet itself. It then pushes the original packet into the node’sDTQ, essentially turning the node into an “intelligent” data MULE [12] thatlooks for greedy forwarding neighbors and at the same time further packetreplication by periodically broadcasting to its one-hop neighbors. In this way,RobustGeo recovers from a local maximum situation by entering DTN modein addition to perimeter forwarding.

11.3.2.1 Perimeter forwarding with packet replicationWhen a node encounters a local maximum, it sends out a packet replica forperimeter forwarding, stores the original in its DTQ, and continues to activelytry and look for nodes that are closer to the destination than the local maximum.If found, the node has successfully recovered greedy forwarding via DTNmeans.

Meanwhile, as the replicated packet is routed around the perimeter itrecords each node it visits as breadcrumbs. If a greedy path is recovered,a receipt can be sent back to the originator using the breadcrumb path so thatthe originator can remove the packet from its DTQ and abort the broadcastingcountdown time. Otherwise, the perimeter-routed packet can continue to berouted by the right-hand rule until either a greedy route is found, or ends upback at the originator or reaches its TTL. In both of the latter cases the packetis discarded. Note that packet replication due to perimeter forwarding happensonly once at the original local maximum node. This prevents the packet fromreplicating out of control as it is forwarded around the perimeter.

If the original packet and its replicas both manage to find a greedy for-warding path, two cases should be considered. In the first case, as illustrated inFigure 11.1, multiple different paths to the destination are found. This arguablyimproves the scenario, since having multiple paths to the destination causesthe intermittent network to be more robust. In the second case (Figure 11.2),both packets are forwarded greedily onto the same path. While on the surfacethis may seem problematic, it is not a great cause for concern since in theunlikely event that this happens, the receiving node can simply drop one ofthe duplicates and continue to forward the packet onwards. However, this doesmean that the packets should be uniquely identified so that identical packetscan be easily discovered. A way to realize this is to use a large sequencenumber in combination with the sender’s identifier (like an IP address).

The decision to replicate the packet when doing perimeter forwarding isdue to the fact that in urban scenarios, the local maximum situation oftenoccurs because of complete network partitioning. When this is the case,no amount of perimeter forwarding can bring the packet to its destination.Fortunately, these situations are generally not permanent because of mobile

11.3 Design 323

Figure 11.1 Greedy forwarding and perimeter forwarding finding two different paths. Thegreedy forwarding recipient node G moves into the source node S’s range after S has perimeterforwarded the packet to node P.

nature of VANETs. An example of such an occurrence is when there aregaps in vehicular traffic caused by something as simple as a long red light.Traditional perimeter forwarding solutions in these situations will cause thepacket to be dropped when it either reaches its TTL or ends up back at itsoriginator [3, 16]. With RobustGeo, however, because the local maximumnode keeps the perimeter forwarded packets, connectivity that is reestablisheda little later can allow greedy forwarding to resume. Although this will causethe network to experience delays, the receiver is still able to receive themessage eventually rather than experiencing a complete disconnectivity.

11.3.2.2 Single-hop broadcasting to explore multiple pathsPackets that are not replicas of any previous broadcasts in the DTQ arescheduled to be one-hop broadcasted periodically to explore multiple paths,which potentially increases the delivery rate and decreases latency. Althoughthe node is still continuing to look for greedy routes for the packet, once thepacket was broadcasted, it essentially switches into “full DTN mode”, relyingmore on node mobility to recover the next greedy routing path.


Figure 11.2 Greedy forwarding and perimeter forwarding finding the same path. Once again,the greedy forwarding recipient node G moves into the source node S’s range a moment afterperimeter routing is done by S. The two identical packets both pass through node R and thelatter one is dropped.

When a node receives a broadcasted packet, it first makes sure that it doesnot already have the packet in its DTQ. Then it adds the packet into its DTQ,where the node can repeatedly attempt to greedy forward it.

The single-hop broadcasting technique is beneficial in situations wherenode density is sparser, taking advantage of the replication effects in delay-tolerant networking [17]. In RobustGeo, we choose to replicate the packetsusing single-hop broadcast because it has a high replication-to-transmissionratio in that a packet can reach all the neighboring nodes with just a singletransmission.

Since packet replication increases bandwidth usage, it is important toconsider the length of the period in between broadcasts. Set too long, thenode can lose opportunities to send to neighbors who are good data MULEcandidates; set too short, the network would be saturated with replicatedpackets. With this in mind, we configure the period to be 6 sec, which we

11.3 Design 325

believe is short enough to not miss most of the potential neighbors, yet longenough that it does not overload the network (see Section 11.4). We believe thatmost of the potential neighbors would not be missed because vehicles rarelytravel faster than 20 m/s (about 45 mph) in an urban area. Taking incomingtraffic into account, the relative speed can be up to 40 m/s. Therefore, 6 secis equivalent to 240 m, still within most broadcasting ranges. Additionally,we set this as an adjustable parameter depending on needs. For example, ifthe target scenario is a very sparse network, then it would be beneficial tomake this period shorter. In all, due to the relatively long broadcasting period,momentary interruptions in the network will not trigger one-hop broadcasts.

To further limit the number of packet replicas, a packet that was oncereceived via broadcasting can never be broadcasted again. This is easily doneby marking a single bit in the packet header and checking that bit whenever apacket is about to be put into broadcast mode. Finally, when the first copy ofthe packet, be it a replica or the original, reaches its destination, the destinationcan send out an active receipt [18] to clean up all of the packet replicas thatare still in the network.

11.3.2.3 SchedulingWhen a local maximum situation occurs, the node stores the packet into itsDTQ, and packets bound for other destinations with available next-hop nodescontinue to be forwarded normally. Every time the node receives a new beacon,be it from any of its existing neighbors or from a new neighbor, the node wouldcheck its DTQ to see if any of the packets can now be routed.

The DTQ is similar in function to a normal FIFO queue, in that packetswhich are enqueued earlier generally get dequeued earlier as well. However,the DTQ is not necessarily dequeued from the head all the time. Whenevera node receives a new beacon from its neighbor, potentially marking a newroute, RobustGeo attempts to dequeue from the DTQ by attempting to greedilyroute to the destination every packet in the queue, beginning with the packetat the head. When a route is found for a packet, that packet is dequeued tobe sent out. This speeds up average packet delivery time and keeps the queuelength short.

To prevent a large number of packets in the DTQ from suddenly floodingthe network, RobustGeo allows only one packet to be sent out for a set period oftime. For example, it may be decided that the backlogged packets should onlytake up about 1 Mbps of the overall bandwidth, so a maximum of 1 packetcan be sent out every millisecond. However, since the beaconing period is


much longer than that, a dispatch buffer is introduced to manage the send rate.Therefore, the DTQ dequeues all eligible packets into the dispatch buffer upto a maximum of send rate ∗ beaconing period packets each beaconingperiod. Then at every 1

send rate period, RobustGeo sends out a packet from thedispatch buffer.

Packets marked for one-hop broadcasting are not sent out immediatelyeither. Rather, RobustGeo adds the packet into a separate broadcasting queueand continues to look through its DTQ for other packets to be greedilyforwarded. Additionally, the packet marked for broadcasting still remainsin the DTQ for more future attempts at greedy forwarding recovery. If therecovery attempt is successful, the packet is removed from both the DTQ andthe broadcasting queue. On the other hand, if the packet was broadcasted,it is removed from the broadcast queue only but kept in the DTQ, with thebroadcasting timer reset to begin a new period of broadcasting.

Having two queues with different priorities, we employ our dispatchbuffer to enforce these priorities. The broadcasting packets are never addedto the dispatch buffer. Instead, the dequeuing method for the dispatch bufferdequeues a packet from the broadcast queue only if the dispatch buffer isempty. As a result, packets are only broadcasted when there are no more geo-routed packets to be sent out in the beaconing period. Figure 11.3 gives anoverall view of the components of RobustGeo working together inside a nodeupon a packet arrival.

11.4 Analysis

Packet replication is a tricky parameter in ad hoc networks. In a lossy andespecially delay-tolerant environment, replication can provide substantialbenefits in that it increases the delivery rate and decreases delay [17]. Unfort-unately, replication is a double-edged sword, as it also introduces bandwidthoverhead into the network. Therefore, as a protocol that stresses replication, itis important to see just how much overhead replication brings into the network.

In RobustGeo, packets are only replicated when a local maximum isreached. When the node is attempting to route the packet via perimeter routing,it introduces a single packet replica. If the recovery time is long, the packet canbe replicated many times due to periodic broadcasting. The overall number ofpackets replicated as the result of a single local maximum is therefore

rep1 = mn

!t

π

"+ 1, (11.1)

11.4 Analysis 327

Figure 11.3 RobustGeo processing a packet. Normal packets use all paths as necessary;Broadcasted packet replicas do not traverse the long-dashed grey path; perimeter forwardedpacket replicas only stay on the solid black path.

where m is the number of packets in the network that experience localmaximum recovery exactly once, t is the average local maximum recoverytime in seconds; π is the broadcasting period of each node, and n is the numberof neighbors that receive the broadcasted packet for the first time.

However, not every replicated packet ends up finding a greedy route.Packets that do not find alternate paths are ultimately dropped as they timeout, and perimeter-routed replicas that find a greedy route cancels out itsoriginal. For this reason, we assign probabilities to the replicated packets toindicate that they actually remain in the network.

Suppose that each broadcasted packet finds an alternative route withprobability Pb, and the perimeter-routed packet finds an alternative routewithout being able to inform its originator with probability Pp, then the numberof replicated packets produced from a single local maximum recovery withthese probabilities take into account is


rep1 = mn

!t

π

"Pb + Pp. (11.2)

Multiplying Pb to the first term takes into account that the only replicatedpackets that remain are those who are forwarded to neighbors that eventuallyfind a greedy geo-forwarded route. The value 1 from Equation (11.1) isreplaced with Pp to take into account that the packet replicated from perimeterrouting ends up remaining in the network at the probability Pp.

If the distance between the sender and receiver is long, a packet mayexperience multiple cases of local maximum. Each time it happens, morepackets are replicated. In RobustGeo, no packet replicas from broadcastingcan be broadcasted again, but they may still replicate via perimeter-routing.We now calculate the number of replicas produced from the second time thatm packets encounter local maximum recovery:

rep2 = mn

!t

π

"Pb + Pp

#mn

!t

π

"Pb

$+ Pp + P 2

p . (11.3)

The first term, mn[ tπ ]Pb, is the number of packet produced from broadcasting

the original packet. The second term, Pp(mn[ tπ ]Pb), is the probabilistic

number of packets produced from broadcasting the perimeter-routed packet.Pp is the replica from perimeter-routing the current original packet, and P 2

pis the replica from perimeter-routing the replicated packet produced from thefirst time that perimeter-routing was performed.

Since Pp is a probability with value between 0 and 1, as it gets higherpowers it becomes more negligible and is disregarded. Further, each timethe packet is perimeter-routed, a new broadcastable packet is replicatedfrom perimeter routing with probability Pp. The next time that the localmaximum is encountered, all of these replicated packets are eligible forbroadcasting. Therefore, the total number of replica packets in the net-work as m original packets are routed through K local maximums isapproximately

rep ≈K%

k=1

mn

!t

π

"Pb(1 + (k − 1)Pp) + Pp. (11.4)

Figure 11.4 shows the number of replicas a single packet accumulates as it isrouted in the network. It describes an urban scenario with short but frequent

11.4 Analysis 329

Figure 11.4 The average number of packet replicas in the network vs. the number ofintermittencies encountered by a packet, where the intermittency length t is modeled as aPoisson random variable with λ = 3. All cases of intermittencies are independent of oneanother.

intermittencies. In this scenario, the recovery time is assumed to take 3 sec onaverage, and the broadcasting period is 6 sec. We also assume that the nodehas on average 10 new neighbors to broadcast to each time that it broadcasts.We also set Pp to be 0.01, a very low number because we assume that for themajority of times, the local maximum occurs due to brief network partitionsand so it fails. For a similar reason, we set Pb to be 0.2 because we assumethat most of the paths found through broadcasting are not unique. Becausethe broadcast rate is a floor function, we assume that the length of recovery isroughly a Poisson distribution with λ = 31 (for the 3 sec of average recoverytime) so that the results are not just summations of Pp.

We see that the number of packet replicates increase slowly with thenumber of intermittencies it encounters. At 100 intermittencies, the averagenumber of replicas is less than 5 per packet. Thus, packet replication ismanageable.

1we can use a discrete pmf in this case since the output values we are concerned with arediscrete.


11.5 Evaluation

We evaluate RobustGeo’s performance by simulating three scenarios usingthe NS3 simulator, with the following parameters:

• PhyMode: OFDM 36 Mbps• Propagation Delay Model: Constant Speed• Propagation Loss Model: Friis• WiFi Standard: 802.11a• Wifi Mac Type: Adhoc Wifi Mac• Transport Protocol: UDP• Application: CBR Client-Server Pair (20 Kbps)• Simulation Time: 200 s

We begin with an artificially set-up scenario mainly to showcase the majorfeatures of RobustGeo, followed by two progressively more realistic scenarios,first with a realistically simulated mobility model running on an actual map ofWashington D.C and then with an actual trace of taxicabs in the San Franciscoarea. We believe that these three scenarios give a clear view of the superiorityof RobustGeo over the other three competing routing algorithms.

To highlight the effectiveness of RobustGeo in intermittent situations, wetreat all cases of local maximum in the simulation as network partitioningby not allowing perimeter routing in any of the algorithms we evaluate. Foreach scenario, we compare RobustGeo against pure geo-routing, which simplydrops the packet that it cannot immediately route, geo-routing with a DTQ thatimproves delay tolerance but without packet replication, similar in behaviorto GeoDTN+Nav [16], and geo-routing with controlled flooding, where nodescan only pass along the packet to 5 unique neighbors before dropping thepacket (Epidemic Routing [13] with restrictions).

We base our comparisons on the following metrics: packet delivery rate,average delay, and overall traffic per packet received. While packet deliveryrates and average delay are obvious metrics to measure, we believe thatthe overall traffic per packet received is equally important because packetreplication is a major feature of RobustGeo. Finally, using data gathered fromthe San Francisco cab trace, we analyze the number of intermittencies packetsgenerally encounter in the network, as well as the number of times each packetis broadcasted, to further cement our claim that RobustGeo is scalable in termsof packet replication.

We begin by testing a synthetic scenario as illustrated in Figure 11.5. This5-part system consists of groups of three static nodes and two groups of mobilenodes, with a total of 11 nodes. The two clusters of static nodes on the left form

11.5 Evaluation 331

Figure 11.5 5 groups of nodes in an intermittent situation; arrows denote node mobility, anddotted lines denote network connection.

a stable connection, while the single group of static nodes on the right relieson the two mobile groups to receive messages. As the mobile nodes movearound, there are short intervals and they form a bridge of network connectionbetween the source and the destination. Most of the time, however, the networkon the left side is completely partitioned off from the right. We believe thatthis is a scenario best fit for RobustGeo since the source is able to reach itsstably connected neighbor via periodic broadcasting and thus make use of bothroutes as each become available. Such a path cannot be realized with perimeterrouting because when the mobile node on the slant is connected to the staticrelay, it is not connected with anything else, so all of the perimeter-routedpackets would be dropped.

We repeat our simulation 10 times with different seeds for each of therouting algorithms in this scenario. In Figure 11.6, we see that as expected,the pure geo-routing method performs poorly because the sender can onlytransmit to the receiver when the two mobile clusters line up to form thetransmission bridge. For the other three schemes, while RobustGeo performsmarginally better than the rest in terms of packet delivery, it generated themost packets. We attribute this to the small number of nodes in the network.Controlled flooding only sends packets to another node if the packet is brand


Figure 11.6 Results for the 5-group artificial scenario.

new to the node. With only 11 nodes in a highly partitioned system, there isnot as much chance for sending packets in such a fashion. RobustGeo, on theother hand, broadcasts periodically regardless of who is around.

We also simulated a more realistic environment by downloading a2,000 m by 2,000 m map of the Washington, DC area made available bythe US Census Bureau’s TIGER database, and simulating mobility on themap using the Intelligent Driver Model with Intersection Management byVanetMobisim [19]. This model is complete with intersection and stop lightrules to simulate realistic vehicular traffic on the streets provided by the

11.5 Evaluation 333

Washington, DC map. The vehicles in the scenarios have maximum andminimum speeds of 10 m/s and 20 m/s, respectively. We generate 4 scenariosby varying the number of nodes between 50 and 125. With each scenario, werandomly place a static node on the map as the destination (server) and choosea random mobile node as the source (client).

As Figure 11.7 shows, in the very sparse scenario of only 50 nodes, puregeo-routing completely breaks down and has a packet delivery ratio of 0.Having the DTQ and using RobustGeo marginally increase the delivery ratio,but it is still under 10%. As the nodes become more dense, the protocolsgenerally trend upwards in their packet delivery ratios. Something quiteunexpected is that geo-routing + controlled flooding did considerably worsethan pure geo-routing when the number of nodes increased to 125. We attributethis to the fact that each time a node cannot find a greedy forwarding path fora packet, the packet is sent out at least 5 times by that single node aloneand multiplied by each recipient 5 more times. This generates a large amountof traffic, taking up available bandwidth and causing interference for nearbynodes. This suspicion is confirmed by the traffic line plot in Figure 11.7. In all,from the VanetMobisim scenarios we see that RobustGeo is indeed the mostrobust of all four routing schemes compared, having the highest delivery ratiofor every situation. In terms of delay, geo-routing + DTQ did better in the75-node case, but RobustGeo did better in all other cases. Additionally, wesee that as predicted in Section 11.4, the replication overhead of RobustGeo isa manageable one, since it has only a slightly higher traffic to packet receivedratio (about 10% or less) than the geo-routing + DTQ scheme that does nothave replication.

Finally, we used real traces of an extremely intermittent network to furthercompare the four geo-routing schemes. In this scenario, we use actual mobilitytraces of taxicabs in San Francisco downloaded from Crawdad [20]. We runthe simulation in a 5,700 m by 6,600 m area with 116 nodes moving for 200 secand again place a static node on the map to be the receiver. In this scenario,the nodes are extremely sparse because only cab movements are recorded inthe tracefile. This means that the network’s period of disconnection is likelylonger than its connectivity.

As Figure 11.8 shows, the pure geo-routing approach completely breaksdown, with a receiving ratio of 0. Geo-routing + DTQ and RobustGeo domuch better, with RobustGeo almost achieving a 30% packet delivery ratio.Once again, the geo-routing + controlled flooding approach fails, with a lessthan 1% delivery rate. We again attribute this to its high delay time. Thismeans that had the simulation time been longer, the geo-routing + controlled


Figure 11.7 Results of the simulation using realistically simulated mobility patterns generatedwith VanetMobisim.

flooding approach can likely a more acceptable packet delivery rate at the costof even higher delay times. We choose to show the traffic per packet deliveredmetric for only pure geo-routing + DTQ and RobustGeo because the other

11.5 Evaluation 335

Figure 11.8 Results of the simulation using real life San Francisco taxicab traces.

two approaches yield incredibly high numbers (infinity and about 2500). Asexpected, RobustGeo generated 58% more traffic per packet delivered thangeo-routing + DTQ. At the same time, it also has a 36% higher delivery ratiowith a very slightly lower average delay. We believe that this is a good trade-offas packet delivery ratios should be prioritized over bandwidth conservation.

Since the San Francisco cab scenario is very realistic and at the same timegives an extremely intermittent network, we use it to analyze disconnectivity


Table 11.1 The number of packets that encounter each frequency of intermittencies in the SFtaxicab scenario

# Intermittencies # Packets1 14342 10633 9814 2145 36 5

and broadcast frequencies. Table 11.1 shows that in the given environ-ment, the majority of packets experience disconnectivity 3 or fewer times,with only 8 packets encountering more than 4 intermittencies. Meanwhile,Figure 11.9 shows that about 80% of packets get broadcasted 6 times orfewer. This confirms the fact that packet replication will not spiral outof control.

We also postulate that the majority of packets experiencing higher fre-quencies of broadcast do not end up at the destination. If true, this can be usedas a good metric to decide how long the packet should remain in a node’s DTQbefore being dropped.

Figure 11.9 The CDF of packet broadcast rate in the SF taxicab scenario.

11.6 Related Work 337

11.6 Related Work

Several other works have also explored the possibility of using delay-tolerantnetworks that exploits location knowledge in VANETs. GeOpps [21] is onesuch DTN protocol. GeOpps uses the vehicle’s navigation systems to findthe Nearest Point (NP) to the message’s destination that the vehicle willtravel to, assuming that the vehicle has a predetermined destination of itsown. While on the way, the vehicle will periodically broadcast the message’sdestination to its one-hop neighbors. The neighbors that receive the destinationlocation calculates their Minimum Estimated Time of Delivery (METD) forthe message based on their own calculated NP and replies to the messagecarrier. The message carrier makes the decision to pass along to its neighborthat has the shortest METD, and the process is repeated. While GeOpps relyingon a “smarter” way of choosing what are essentially Data MULEs can increasethe data dissemination speed, its high dependence on vehicular movementsto carry the message to its destination causes it to experience much higherdelays than greedy forwarding, since network propagation is much faster thanphysical node movements.

GeoSpray [22] is another VANET routing solution that combines geo-graphical knowledge with DTN ideas. Inspired by GeOpps, GeoSpray worksin a similar fashion in that it takes into account the neighbors’ METD andforwards the message to the ones with small METDs. However, they differin that GeoSpray utilizes the concept of the spray phase in the binary Sprayand Wait [14] method where it utilizes controlled packet replication to exploremultiple paths and decrease delay. This is similar to RobustGeo’s singe hopbroadcast phase, which also makes use of replication. However, just likeGeOpps, GeoSpray suffers in a similar fashion in that it cannot take advantageof nodes who can otherwise be valid relay nodes in greedy forwarding, simplybecause they have a low METD value.

The work that is the most similar to RobustGeo is GeoDTN + Nav [16].GeoDTN + Nav fully incorporates the DTN paradigm into existing workson location-based routing protocols by operating with three modes: restrictedgreedy forwarding, perimeter forwarding, and DTN. The added DTN modeof GeoDTN + Nav allows packets to still be routed to the destination with aDTN approach in the event that the network is segmented due to sparse nodetopologies. The default greedy forward strategy for GeoDTN + Nav is thesame as the one used in GPCR, and the default recovery mode is the same asthat of VCLCR [23], a location-based routing protocol that can detect routingloops in perimeter forwarding otherwise missed by GPCR. Finally, it uses the


simple store-and-forward approach in DTN mode until greedy forwarding canbe recovered.

GeoDTN + Nav switches from perimeter forwarding mode into DTNmode by having each node on the perimeter path calculate the switching scoresof its neighbors to see if they are good candidates for carry-forward MULEs.These scores are based on three metrics: the probability of network discon-nectivity, the neighbor’s delivery quality in DTN mode, and the neighbors’travel direction. If the score is high enough, the packet is passed to the node’sneighbor and DTN mode commences. In the DTN mode, the receiving nodestores the packet and relies upon its own mobility to carry the packet untilrestricted greedy forwarding can once again be used to forward the packet toits destination.

GeoDTN + Nav differs from RobustGeo mainly in that the DTN methodemployed in GeoDTN + Nav uses a single-forwarding based algorithm, whichgenerally has low reliability in packet delivery [17]. For example, GeoDTNuses the neighbor’s current travelling direction to determine its switchingscore. Unfortunately, vehicles’ travelling directions are not constant. A changein direction by the vehicle after receiving the packet means that the packetwould be actually brought away from the destination and thus increasingdelays. Moreover, if no “good” neighbors are found within the packet’s TTL,it is dropped. RobustGeo performs better in these situations because it exploresthe possibility of limited message replication by having the local maximumnode keep a copy of the packet in the recovery phase, allowing multiple nodesto look for greedy paths toward the destination. Additionally, GeoDTN + Navis very much focused upon the method with which to switch into the DTNmode from perimeter mode, whereas RobustGeo is designed so that unlessthe packet is immediately forwarded, it is, in some ways, always both ingeo-routing mode and in DTN mode. RobustGeo is able to do this becauseit includes a simple scheduling system to dispatch packets opportunistically.Having such a feature allows RobustGeo to have much greater flexibility andthus be more robust.

11.7 Conclusion and Future Work

In this chapter we presented another location-based routing algorithm, Robust-Geo, that is designed to withstand network intermittencies common to urbanVANETs. RobustGeo achieves this result by taking advantage of both the storeand forward and packet replication strategies found in delay-tolerant networks.With RobustGeo, we were willing to make the trade-off of introducing extra

References 339

bandwidth overhead into the network with packet replications in favor of morereliable delivery. We showed in both Sections 11.4 and 11.5 that the trade-off isa viable one.As future work, we would like to analyze the relationship betweena packet’s frequency of broadcasts and its journey completion likelihood toget a better idea of how long the packet should remain in the DTQ beforetiming out and being dropped. This can be very helpful in RobustGeo as ithelps reduce node storage overhead in addition to bandwidth overhead. Inall, RobustGeo is a hybrid solution that allows for connections in both reliableand intermittent networks, which are attributes of VANETs.

References

[1] Huhtonen. A. (2004). Comparing AODV and OLSR routing protocols.Telecommun. Software Multimedia, 1–9.

[2] Yousefi, S., Mousavi, M. S., and Fathy, M. (2006). Vehicular ad hocnetworks (vanets): challenges and perspectives. In 2006 6th InternationalConference on ITS Telecommunications Proceedings, pp. 761–766.IEEE.

[3] Karp, B., and Kung, H.-T. (2000). GPSR: Greedy perimeter statelessrouting for wireless networks. In Proceedings of the 6th Annual Interna-tional Conference on Mobile Computing and Networking, pp. 243–254.ACM.

[4] Lee. K. C. (2010). Geographic routing in vehicular ad hoc networks.University of California, Los Angeles.

[5] Lochert, C., Mauve, M., Füßler, H., and Hartenstein, H. (2005). Geo-graphic routing in city scenarios. ACM SIGMOBILE Mobile Comput.Commun. Rev., 9(1), 69–72.

[6] Jerbi, M., Senouci, S.-M., Meraihi, R., and Ghamri-Doudane, Y. (2007).An improved vehicular ad hoc routing protocol for city environments.In IEEE International Conference on Communications, 2007. ICC’07,IEEE. pp. 3972–3979.

[7] Lee, K. C., Haerri, J., Lee, U., and Gerla. M. (2007). Enhanced perimeterrouting for geographic forwarding protocols in urban vehicular scenarios.In Globecom Workshops, 2007 IEEE, pp. 1–10. IEEE.

[8] Lee, K. C., Lee, U., and Gerla, M. (2009). To-go: topology-assist geo-opportunistic routing in urban vehicular grids. In Sixth InternationalConference on Wireless On-Demand Network Systems and Services,2009. WONS 2009, IEEE. pp, 11–18.


[9] Seet, B.-C., Liu, G., Lee, B.-S., Foh, C.-H., Wong, K.-J., and Lee,K.-K. (2004). A-star: A mobile ad hoc routing strategy for metropolisvehicular communications. In Performance of Computer and Communi-cation Networks; Mobile and Wireless Communications, NETWORKING2004. Networking Technologies, Services, and Protocols. Pp. 989–999.Springer, Berlin.

[10] Wisitpongphan, N., Bai, F., Mudalige, P., and Tonguz, O. (2007). Onthe routing problem in disconnected vehicular ad-hoc networks. InInternational Conference on Computer Communications, INFOCOM2007. 26th IEEE. Pp. 2291–2295, May.

[11] Jain, S., Fall, K., and Patra, R. (2004). Routing in a delay tolerantnetwork. In Proceedings of the 2004 Conference on Applications, Tech-nologies, Architectures, and Protocols for Computer Communications,SIGCOMM ’04, pp. 145–158, New York, NY, USA. ACM.

[12] Shah, R. C., Roy, S., Jain, S., and Brunette, W. (2003). Data mules:modeling and analysis of a three-tier architecture for sparse sensornetworks. Ad Hoc Networks, 1 (2), 215–233.

[13] Vahdat, A., and Becker, D. et al. (2000). Epidemic routing for par-tially connected ad hoc networks. Technical report, Technical ReportCS-200006, Duke University.

[14] Spyropoulos, T., Psounis, K., and Raghavendra, C. S. (2005). Spray andwait: an efficient routing scheme for intermittently connected mobilenetworks. In Proceedings of the 2005 ACM SIGCOMM Workshop onDelay-tolerant Networking, pp. 252–259. ACM.

[15] Zhao, W., Ammar, M., and Zegura, E. (2004). A message ferryingapproach for data delivery in sparse mobile ad hoc networks. In Pro-ceedings of the 5th ACM International Symposium on Mobile Ad HocNetworking and Computing, MobiHoc’04, pp. 187–198, New York, NY,USA. ACM.

[16] Cheng, P.-C., Lee, K. C., Gerla, M., and Härri, J. (2010).GeoDTN + NAV: Geographic dtn routing with navigator prediction forurban vehicular environments. Mob. Netw. Appl., 15 (1), 61–82, Feb.

[17] Zhang, Z. (2006). Routing in intermittently connected mobile ad hoc net-works and delay tolerant networks: overview and challenges. Commun.Surveys Tutorials, IEEE, 8 (1), 24–37.

[18] Harras, K. A., and Almeroth, K. C. (2006). Transport layer issues indelay tolerant mobile networks. In NETWORKING 2006. Network-ing Technologies, Services, and Protocols; Performance of Computer

References 341

and Communication Networks; Mobile and Wireless CommunicationsSystems, pp. 463–475. Springer, Berlin.

[19] Härri, J., Filali, F., Bonnet, C., and Fiore, M. (2006). Vanetmobisim:Generating realistic mobility patterns for vanets. In Proceedings of the3rd International Workshop on Vehicular Ad Hoc Networks, VANET ’06,pp. 96–97, New York, NY, USA. ACM.

[20] Piorkowski, M., Sarafijanovic-Djukic, N., and Grossglauser, M. (2009).CRAWDAD data set epfl/mobility (v. 2009-02-24). Downloaded fromhttp:// crawdad.org/epfl/mobility/, Feb.

[21] Leontiadis, I., and Mascolo, C. (2007). Geopps: Geographical oppor-tunistic routing for vehicular networks. In IEEE International Symposiumon a World of Wireless, Mobile and Multimedia Networks, 2007.WoWMoM 2007, pp. 1–6. IEEE.

[22] Soares, V. N., Rodrigues, J. J., and Farahmand, F. (2014). Geospray:A geographic routing protocol for vehicular delay-tolerant networks.Information Fusion, 15:102–113.

[23] Lee, K. C., Cheng, P.-C., Weng, J.-T., Tung, L.-C., and Gerla, M. (2008).VCLCR: a practical geographic routing protocol in urban scenarios.UCLA Computer Science Department, Tech. Rep. TR080009.

robustgeo: a disruption-tolerant geo-routing...

Documents