EZCab: A Cab Booking Application Using Short-Range WirelessCommunication∗

Peng Zhou1, Tamer Nadeem2, Porlin Kang1, Cristian Borcea3, and Liviu Iftode11 Department of Computer Science, Rutgers University

2 Department of Computer Science, University of Maryland, College Park3 Department of Computer Science, New Jersey Institute of Technology

1{pzhou,kangp,iftode}@cs.rutgers.edu,2nadeem@cs.umd.edu,3borcea@cs.njit.edu

Abstract

EZCab is a proof-of-concept ubiquitous computingapplication that allows people to book nearby cabs usingtheir cell phones or PDAs equipped with short-rangewireless network interfaces. EZCab discovers and booksfree cabs using mobile ad hoc networks of vehicles. Wehave implemented an EZCab prototype on top of SmartMessages, a middleware architecture based on executionmigration, which we had developed to provide a commonexecution environment for outdoor ubiquitous computingapplications. The experimental and simulation results havedemonstrated the feasibility of EZCab.

1 Introduction

For many years, people have discussed about mobilead hoc networks (MANET) and have proposed numerousrouting algorithms [23, 31], but the technology has not beenmature enough to support the deployment of such networksin the real world. Recently, short-range wireless networkinghas started to live up to its expectations, and we see alarge deployment of products based on either IEEE 802.11standards or Bluetooth (a low-cost, low-power alternativeto IEEE 802.11 family of protocols). While short-rangewireless technology is on its way to become ubiquitousin the near future, little has been done to develop real-lifeservices or applications over mobile ad hoc networks.

This paper presents EZCab, a real-life ubiquitouscomputing application built over MANET, which allowspeople to book nearby cabs in densely populated urbanareas using their cell phones or PDAs equipped with short-range wireless network interfaces. Current cab bookingsystems rely on centralized schemes for cab dispatching

∗This work is supported in part by the NSF under the ITR grant numberANI-0121416

such as making phone calls to a taxi company or sendingshort messages (SMSs) to a certain server over cellularlinks [1, 2]. Although under the traditional centralizedsolution cab dispatching is guaranteed, this solution is notscalable due to: 1) all requests have to go through one ormultiple cab dispatchers, which introduces waiting time forthe clients, especially during periods of peak cab requests,and 2) in order to dispatch the nearest cab to the client, allcabs in the city have to be monitored to find the closest oneto the client’s location.

The EZCab dispatching system, on the other hand, issimpler, faster, and more scalable since it works in acompletely decentralized fashion, and there is no need togather the locations of all the cabs in real-time. EZCabprovides all these benefits because it defines a systemarchitecture in which the clients and vehicles communicateusing only short-range wireless network interfaces. Thisdesign decision, however, makes EZCab a “best effort”service. Clients can switch to the standard centralizedmethods to book a cab if they fail to get a cab using EZCabwithin a short period of time. Hence, the EZCab systemcan be incrementally deployed and coexist with currentcentralized systems. EZCab is useful in cities with highdensity of cabs, such as New York or Tokyo, where thecontention to get cabs during certain periods (e.g., peoplegetting out from a show) is very annoying.

EZCab is made possible by two recent technologytrends. The first is the transformation of PDAs (e.g.,HP iPAQ [5], Toshiba PocketPC [10]) and cell phones(e.g., Ericsson P900 [7], Motorola A760 [6]) into relativelypowerful mobile computers equipped with short-rangewireless capabilities. The second is the increasing presenceof powerful embedded systems, GPS receivers, and evenwireless network interfaces in modern vehicles. Forinstance, GPS has been successfully used to track vehiclesand provide accurate position information [11, 21]. A taxiservice, based on real-time GPS information collected by

Figure 1. EZCab: Booking a cab over a mobilead hoc network of cabs

a centralized dispatching center over cellular networks, hasalso been implemented in Singapore [28].

We have implemented an EZCab prototype on top ofSmart Messages (SM) [13, 24], a middleware architecturebased on execution migration, which we developed toprovide a common execution environment for outdoordistributed applications. An SM carries its own routingcode and routes itself at each node in the path toward anode of interest. To perform routing, SMs store routinginformation in a memory addressable by names at nodes.The SM self-routing mechanism [12] is especially usefulfor EZCab because it allows on-demand deployment ofnew routing algorithms and changing the routing algorithmduring execution. This feature enables EZCab to adapt tohighly dynamic network configurations. The testbed forEZCab consists of ad hoc wireless networks composed ofHP iPAQs running Linux and communicating through IEEE802.11 network interface cards. The experimental resultsshow that EZCab is a viable solution for booking cabs indensely populated urban areas. We have also evaluatedand compared through simulations multiple mechanisms fordiscovering free cabs under different traffic scenarios.

The rest of this paper is organized as follows. We presentthe design of EZCab in Section 2. Section 3 describesthe EZCab prototype, its SM-based routing algorithms, andthe experimental results. Section 4 presents the simulationresults comparing different routing algorithms. Finally, wediscuss related work in Section 5 and conclude the paper inSection 6.

2 Design

EZCab consists of a mobile ad hoc network of computersembedded in taxis and client handheld devices, whichcommunicate using short-range wireless network interfacessuch as IEEE 802.11 as illustrated in Figure 1. Insteadof booking cabs through a centralized dispatcher, EZCabclients book free nearby cabs by communicating directly

with other EZCab nodes (i.e., taxis) over a mobile adhoc network. This decentralized architecture provides asimple, cheap, and scalable solution to a real-life problem.However, EZCab presents new challenges which do notexist in traditional systems based on centralized dispatchingcenters. For instance, we need a distributed protocol toensure that at most one cab arrives at the site of the clientwho requested the cab. Furthermore, we must ensure thatany free cab accepts only one client request at any pointin time. To provide an automatic booking mechanism, wealso need accurate location information for both clients andcabs (e.g., the client’s street address has to be present inthe booking request). Finally, EZCab needs to provide amechanism for the client and driver to authenticate eachother when they meet. This section presents the EZCabsystem architecture and its protocol that satisfies theserequirements.

2.1 System Architecture

EZCab consists of two types of entities: client stationsand driver stations. A client station is a a PDA (or cellphone), while a driver station is a system embedded in thecab. We assume that all driver stations communicate witheach other using IEEE 802.11, the de facto standard for highbandwidth, short-range wireless networking. Additionally,each driver station has a GPS receiver that can report itscurrent location when needed. All driver stations that arewithin the radio range of each other form an ad hoc networkof nodes which communicate and perform the distributedcomputation necessary to book a free cab. The clientstations have to join such a network to inject their requestsfor free cabs. A client station communicates directly withcabs in its transmission range, and the cabs in the networkforward the request until a free cab is discovered.

Unlike driver stations which are homogeneous, clientstations can have different capabilities. Besides powerfulPDAs equipped with IEEE 802.11 wireless networkinterfaces and GPS receivers, cell phones equipped withlow-power Bluetooth interfaces and without GPS receiverscan also be used as client stations. In such a case,however, the client station needs to connect to a gatewaystation that forwards the request into the network of cabsand sends the answer back to the client. A gatewaystation is a computer equipped with a GPS receiver andmultiple network interfaces (i.e., Bluetooth and IEEE802.11), which can be co-located withHotspots(i.e., IEEE802.11 access points) at public places such as restaurants,stores, theaters, bus stops, telephone booths, and buildinglobbies. The role of a gateway station is to “stamp”location information on requests received from lighterclients that cannot incorporate a GPS receiver (i.e., giventhe range of Bluetooth, the location of the gateway is a good

1 2

34

65

Networkarrival time

public key of cabcar ID

public key of client public key of clientclientIDclientID

Booking

Reporting

Confirmingpublic key of cab

cab location

client destination client destinationclient locationclient location

search range

driver stationclient station

car ID

arrival timecab location

Figure 2. Cab booking protocol

approximation for the location of the client) and perform achange of protocols between client stations equipped withBluetooth and driver stations equipped with IEEE 802.11.

2.2 EZCab Protocol

The EZCab application starts when a client sends out arequest and ends with a validation at the client’s location.The EZCab protocol consists of two phases:Cab Bookingand Validation. Figure 2 shows theCab Bookingphase.During this, the client and driver stations collaborate witheach other to forward the client’s request through thenetwork until a free cab is discovered. To accommodatevarious network configurations determined by density andmobility of the cabs, EZCab assumes an extensible routinglayer which supports different routing algorithms as plug-ins (similar to Active Networks [3]). Sections 3 and 4 willpresent our experiences with developing routing algorithmsspecific to EZCab.

Cab Bookingis a three-way handshake protocol whichensures that a nearby free cab is booked and no morethan one client books a cab simultaneously. It startsby sending a request containing the client’s information(e.g., current location, destination location) into an ad hocnetwork of cabs. This request is routed to a free cab by therouting layer. Once the driver of a free cab agrees to theclient’s requirements, the cab status is changed from freeto occupied. The expected arrival time (estimated basedon the distance between the client and the cab, the time ofthe day, and previous experiences of the cab driver) and thelicense plate of the cab are sent to the client. The handshakeprotocol completes with an acknowledgment from the clientstation to the driver station. Once the driver station receivesthe acknowledgment, the cab driver is notified to pick upthe client.

Both the client and driver stations have a timeoutmechanism which allows them to cope with highly dynamicnetwork configurations. If the driver station times outbefore receiving the last part of the handshake, the cab willbe made available again. Similarly, if the client station times

out before receiving any confirmation from a cab, a newrequest is injected in the network. While multiple driverstations may be traversed during the execution of the EZCabapplication, its protocol ensures that a cab which satisfiesthe client’s requirements is finally booked and reaches theclient.

When the booked cab arrives at the vicinity of theclient, the driver initiates theValidation phase to mutuallyauthenticate with the client. TheValidation protocoluses a challenge-response scheme based on public-keycryptography. The client and the driver stations exchangetheir public keys during the three-way handshakeCabBookingprotocol. Once, the cab arrives in the proximityof the client, the driver station sends a random numberencrypted using the client station’s public key (as achallenge) to the client. Only the client holding thecorresponding private key can successfully decrypt thechallenge. The client then encrypts the result (as a response)using the driver station’s public key and sends it back tothe driver station. If the driver station could successfullydecrypt the response, both the client and driver stationshave mutually authenticated. Thus, no client can claim analready booked cab, and no driver can get somebody else’sclient.

3 Prototype Implementation

We have implemented EZCab using Smart Mes-sages [13, 24], a middleware architecture based onexecution migration, which we developed to provide acommon execution environment for outdoor ubiquitouscomputing applications. This section presents a shortoverview of Smart Messages, the EZCab prototype, therouting algorithms used by EZCab to find free cabs, andexperimental results over ad hoc networks of PDAs.

3.1 Smart Messages

Smart Messages (SM) define a middleware architecture,similar to mobile agents, for programming distributed

applications over mobile ad hoc networks of resourceconstrained devices. An SM is a distributed applicationconsisting of code, data, and a lightweight executionstate. Instead of transferring data among nodes involved incomputation, SMs migrate the execution to each of thesenodes. An SM carries routing code and routes itself ateach node in the path toward a node of interest. Eachnode cooperates to support the SM execution by providinga virtual machine (VM) for execution over heterogeneousplatforms, a shared memory addressable by names (tagspace) for inter-SM communication and synchronization,and a code cache for storing frequently executed code.

An SM calls explicitly for migration when it needs toexecute on a different node. Upon an SM arrival at a newnode, its execution is resumed from the next instructionfollowing a migration invocation. During its execution anSM can spawn or create new SMs. Additionally, an SMcan interact with the host or other SMs using tags stored inthe tag space. Essentially, the tags are(name, data)pairs.Corresponding to their functionality, there are two types oftags: application tags for “persistent” memory across SMexecutions which can store application-specific data, andI/O tags for interaction with the host’s operating systemand I/O. Tags can also be used for synchronization betweenSMs. An SM can block on a tag until another SM performsa write on that tag (i.e., update-based synchronization).

SMs name nodes by tag names (i.e., content-basednaming) and migrate to nodes of interest using a highlevel migration function that implements routing [12]. Therouting is executed at each node on the path toward anode of interest; hence, SMs are self-routing applications.The implementation of routing uses information stored bySMs in the tag space and a system-provided primitive forone-hop migration. This primitive captures the currentexecution control state and migrates it to the next hop alongwith the code and data.

The SM platform is developed by directly modifying SunMicrosystem’s Kilobyte Virtual Machine (KVM); KVMfeatures a small memory footprint (160K) suitable for mostembedded devices. The tag space and SM operations areavailable to applications as a Java API.

3.2 EZCab Prototype

We have implemented the EZCab prototype on topof the SM platform installed on HP iPAQs runningLinux. The iPAQs use Orinoco’s 802.11 cards for wirelesscommunication, and each of them is connected to a Geko201 GPS receiver. We have demonstrated in a differentproject [18] that cars can be mapped with high accuracyon the roads despite the low accuracy provided by raw GPSdata (e.g., raw GPS data provides on average an accuracy of10 meters). Figure 3 illustrates an EZCab driver station.

Figure 3. EZCab driver station consisting ofan HP iPAQ equipped with Orinoco 802.11wireless card and Geko 201 GPS receiver

The EZCab prototype has two types of graphical userinterfaces, corresponding to client station and driver station,respectively. Each user interface communicates with theSM platform via special bi-directional I/O tags, calledUI tags. These tags persist for the entire durationof the user interface process and behave similar to aproducer-consumer circular buffer. We have used the OpenPalmtop Integrated Environment (OPIE) to develop the userinterfaces of EZCab. OPIE is an open source graphical userenvironment for PDA’s and other devices running Linux.

3.3 EZCab Routing Algorithms

A very important feature of the SM middleware is itsself-routing mechanism that enables SMs to use newlydeveloped routing algorithms during their lifetime andchange between multiple algorithms dynamically. Thisfeature allows applications to plug-in different routingprotocols according to their needs without the need to installsuch algorithms on the nodes (i.e., SMs carry their routingcode). An EZCab SM can switch to different routingalgorithms as it traverses the network (based on differentnetwork properties such as mobility, network density, andGPS data). Carrying routing code with an SM does notincur additional overhead in the common case because therouting code will be cached at nodes. Thus, the cost oftransferring routing code is amortized over time.

The routing algorithms for EZCab have two specialproperties that make them different from traditionalMANET routing: limited geographical scope and multiplepossible destinations. First, EZCab routing only looks fora destination node within a limited geographical scope (i.e.,a free cab near the client). Second, every free cab nodewithin a limited range of the client serves equally well as

destination of the request.We have implemented and compared three routing

algorithms for finding free cabs:Flooding, ProbabilisticOn-Demand, and Probabilistic Proactive. All the threealgorithms rely on an underlying broadcast mechanism andassume symmetric links. The first algorithm does notcache any routes, while the second and third algorithmscache discovered routes in a routing table on each node forsubsequent re-use.

The three-way handshake protocol described in Sec-tion 2 is implemented as three different SMs: BookSM,ReportSM, and ConfirmSM. BookSM uses any of the threerouting algorithms mentioned above to find a free cab.Upon reaching a free cab, it creates a ReportSM whichgoes back to the client with the cab’s information. Uponreaching back the client, ReportSM creates a ConfirmSMwhich goes back to the cab driver waiting for clientconfirmation. Both the ReportSM and the ConfirmSM usegeographical routing which allows them to reach the nodesof interest independent of any routing information, exceptfor the geographical positions of the one-hop neighbornodes. This method is scalable and avoids possible brokenroutes. In the following, we describe the implementation ofthe Flooding, Probabilistic On-Demand, andProbabilisticProactiverouting algorithms using SMs.

3.3.1 Flooding

Flooding is the basic mechanism to propagate messages inmany MANET protocols (e.g., routing, service discovery).In this scheme, each EZCab client request (BookSM)is broadcasted to all its neighbors recursively, up to amaximum number of hops,TTL, or until it arrives at afree cab node, whichever comes first. The client node willonly consider the first free cab response (i.e., ReportSM);responses from other cabs will be dropped. The SM waitingat the client for responses will eventually timeout if no freecab is available withinTTL hops. To prevent routing loops,BookSM also marks visited nodes using a unique tag. Inmost cases, this simpleFlooding yields free cabs in theproximity of the client and works well in a less crowdedscenario. If the network is very dense,Flooding does notwork well due to the unavoidable wireless contention. Insuch a situation, we resort to the next two algorithms.

3.3.2 Probabilistic On-Demand

This routing algorithm builds routing tables on-demand fornodes lying in aTTL-hops range from the client. Therouting table at a node can be shared among differentBookSMs, and it consists of entries with the probabilityof finding a free cab through the node’s neighbors. Sincethe route to each neighbor could be invalidated due tomobility, each routing entry records its last update time; the

Figure 4. Probabilistic on-demand routediscovery

system uses this information to age routing entries. TheProbabilistic On-Demandmechanism is similar to the re-active routing protocols in MANET such as AODV [31].

BookSM triggers theProbabilistic On-Demandroutediscovery on any node where the routing table doesnot exist, the maximum probability is too small, or thecommunication failed because the node with maximumprobability is not a neighbor of the current node any more.To do so, BookSM creates a DiscoverySM, which migratesin the network to look for a free cab and blocks on a routingtag for a timeout value. We have adopted a timeout schemeinstead of waiting for a certain number of DiscoverySMs toreturn (i.e., we could have waited for one DiscoverySM foreach direct neighbor) since it is unreasonable to do so in avolatile ad hoc network. If a new BookSM request arrivesat the same node, it will block on the same tag instead ofcreating another DiscoverySM. Thus, only the first requestupdates the routing table at that node. The second andsubsequent requests will use the routing table created bythe first request when they continue after timeout.

Figure 4 shows theProbabilistic On-Demandroutediscovery in action. The DiscoverySM spawns itself at eachnode. The child SM broadcasts itself to its neighbors, andthe parent blocks with a timeout waiting for all its childrento come back with routing information (i.e., probabilityto find a free cab through this node). Each child storesthe address of its source node (which according to thealgorithm is one-hop away). Once a DiscoverySM reachesa node locatedTTL-hops away from client, it will report theprobability to its source as either 0.5 or 0.0, depending onwhether the cab is free or occupied, respectively. Note thatevery node traversed by a DiscoverySM, except for the lasthop, has a blocked DiscoverySM. When the DiscoverySMunblocks (after timeout), it will gather all the probabilitiesreported by its child SMs and report back to its source node.This process continues until the top-level DiscoverySM is

reached.

The routes created by this algorithm form aDirectedAcyclic Graph, rooted at the client station. The DAGscreated by multiple client stations could overlap each other.The probability,Pn (1 ≤ n < TTL), reported by each nodelocatedn hopes away from the client to its source is givenby:

Pn =

{12

(1 + max(Pn+1)

)if n is occupied,

12max(Pn+1) if n is available.

The timeout for the parent DiscoverySM at each node isdefined by:

2× oneHopT ime× (TTL− currentHops)× L,

whereoneHopT ime is the time for single hop migration.Thus, (2 × oneHopT ime × (TTL − currentHops))is the total migration time. To account for differentfactors affecting the migration time (such as MAC layercontention), we introducedL (L > 1) as a fudge factor.L is our attempt to ensure that the child Discovery SMscould get back before the parent SM times out. Accordingto our experimental results, the more contentions, the largerL should be. For instance, a fudge factorL = 3 works wellfor cabs with 6 or less neighbors.

When a client sends out a request, BookSM simplychecks the local routing table and migrates to the neighborwith the largest probability. At the same time, it updates therouting table based on theTTL used by the DiscoverySM.Once it chooses the next hop, BookSM divides thecorresponding probability by2(N−hopCount), whereN isthe estimated number of hops from the client to the free cab(we have chosenN = TTL

2 ) andhopCountis the number ofnodes already visited on the path from the client to the freecab. For instance, the probability is reduced by1

2N at thefirst node and 1

2(N−1) at the second node. The probability isreduced by12 for each node located farther thanTTL

2 hopsaway from the client. This process repeats until a free cab isreached or no further route is available. If a free cab is foundand the driver has agreed to pick up the client, the BookSMcreates a ReportSM. This SM uses geographical routing tosend the booking information back to the client. On theother hand, if no further route is available and no free cab isfound, BookSM performs a fresh route discovery from thecurrent node.

The overhead of this routing scheme is expected tobe lower than that ofFlooding when nodes move slowlyand many requests occur within a limited region and timeinterval (e.g., when many people book cabs outside a theaterwhen the play just finished).

3.3.3 Probabilistic Proactive

In a highly dynamic network, theProbabilistic On-Demandalgorithm could perform poorly. For example, the entrywith the largest probability can become invalid before itis utilized (i.e., the node moves out of wireless range).This situation triggers DiscoverySM, a relatively expensiveprocess since the BookSM has to wait for2 × TTLnode traversals while routing tables are reconstructed fromscratch.

To have “fresher” information in the routing table, wepropose a third routing algorithm:Probabilistic Proactive.Proactive routing algorithms are known to perform poorlyin highly mobile networks [14]. This algorithm, however,has the potential to work well for EZCab because EZCabdoes not need end-to-end transfers of bulk data, but ratherto find any free cab in a given region.

Similar to theProbabilistic On-Demandscheme, thisalgorithm builds routing tables with probabilities to findfree cabs in each entry. The routing updates, however, aretriggered proactively by the presence of free cabs, not byon-demand requests from client stations. Every free cabusing this algorithm broadcasts an UpdateSM periodically.UpdateSMs contain a smallTTL value to limit the scope offlooding and a unique identifierfreeCabIDof the free cabwhich generated it. Upon receiving this update, the directneighbors of this free cab update their routing table with(freeCabID, 0.5) and decrement theTTL of the UpdateSM.The UpdateSM is then further propagated until theTTLreaches 0. Each hop receives a pair (previousCabID, 1

2N ) inthe UpdateSM, whereN , (1 ≤ N ≤ TTL), is the numberof hops from the free cab. IfpreviousCabIDis not in therouting table, a new entry will be created. Otherwise, thecurrent probability is updated with the new value. Similarto theProbabilistic On-Demandscheme, an aging intervalis used to purge old information.

This algorithm generates overlapping DAGs rooted ateach free cab. When a client requests a free cab, BookSMwill migrate hop-by-hop through the entries with the largestprobability (up toTTL hops) until a free cab is found. If afree cab is found, EZCab will proceed with the next phaseof the three-way handshake protocol. A BookSM migratingto a free cab updates the probabilities in the routing tablesin the same way it does in theProbabilistic On-Demandalgorithm. If no free cab is found afterTTL hops, BookSMwill report the failure to the client. On the other hand, if abroken link is discovered (i.e., the target node disappeared),a DiscoverySM usingFlooding will be injected to find afree cab instead of rebuilding the whole routing table.

3.4 Experimental Results

We measured the completion time for a single EZCabrequest using three ad hoc wireless network topologies

Busy Cab

Client Busy Cab

Busy Cab

Busy Cab

Busy Cab

Busy Cab

Free Cab

Topology A

Busy Cab

Busy Cab

Client

Topology B

Client Busy Cab Busy Cab Busy Cab Busy Cab Busy Cab Busy Cab Free Cab Topology C

Busy Cab Busy Cab

Busy Cab Busy Cab

Free Cab

Figure 5. Topologies used in our experiments

Topology Response Time (ms)

A 444.18B 401.57C 356.60

Table 1. Completion time for EZCab usingthree topologies

consisting of eight HP iPAQs running our prototype.Figure 5 shows the three topologies, and Table 1 presentsthe average response time for each of them. Response timeis defined as the total time needed to complete the three-way handshake protocol which starts with the client sendinga cab request and ends with a cab receiving a bookingconfirmation. Although a request in topology C has to travelmore hops than in the other two, EZCab completes faster forthis topology because of low contention. Since the scale ofthe network is small (only 8 nodes), we did not expect tosee significant differences in the response time for differentroute discovery algorithms. Hence, we have used just asimple flooding to discover a free cab. Moreover, we didnot use geographical routing for ReportSM and ConfirmSMin these experiments. The experimental results demonstratethe feasibility of EZCab for small scale networks, showingthat the application can successfully book a cab in areasonable amount of time.

4 Performance Evaluation

To compare the performance of the three EZCab routingalgorithms under different scenarios, we have simulatedEZCab using thens-2 simulator [9], enhanced with theCMU-wireless extensions [8]. Different scenarios are usedto test sensitivities of the algorithms to various applicationand network parameters. In this section, we describe ourexperiments and present the corresponding results.

4.1 Scenario Generator

We have developed our own scenario generator toolbased onsetdest, a generator tool for random-way point

mobility model, developed at Carnegie Mellon Universityto generate traffic scenario for cities with grid roads (e.g.,Manhattan). The scenario generator accepts as parametersthe simulation time, the width and length of the city gridsin meters, number of horizontal roads, number of verticalroads, number of lanes per road, average speed of the cabsin meters/sec, average gap distance between cabs on thesame lane, and the number of clients in the city.

In our traffic model, we use an even number ofalternated single direction roads along each dimension ofthe grid. Cabs can change their lanes within the same roadindependently of each other. The probability of staying onthe same lane is 0.6, whereas the probability of changingthe lane is 0.4 either to the left or to the right. Similarly,cabs can switch their roads at intersections. With equalprobabilities, a cab chooses either to stay on the same roador change to the road it intersects with. When a cab reachesthe last intersection on a road, it is forced to change tothe road it intersects with. Clients behave similarly to thecabs at the intersections, except that they can move on bothdirections of a road. Therefore, clients at intersections canchoose uniformly between the three new directions.

The cabs select their speed as[average speed ±(0.25×average speed×rand())], whererand() returns auniformly distributed random number from the range[0, 1].The clients select their speed uniformly from range[0, 1]meters/sec. Initially, each cab moves toward a randomdestination along its road using its currently selected speed.Once a cab reaches its destination, it selects another randomdestination along its road as well as a new speed. If theselected destination is behind the next intersection on theroad, the cab sets its destination to the intersection. Clientsselect their new destinations in a similar manner.

For all the simulations, we fixed the width of the gridsto 2,000 meters, while the length is 3,000 meters. Theroads are distributed uniformly as 6 vertical roads and10 horizontal roads with 2 lanes per road. The averagegap between successive cabs on the same lane is 185 me-ters. The scenario generator places[number of lanes ×( city width

gap × number vertical roads + city lengthgap ×

number horizontal roads)] = 410 cabs and 200 clientsevenly distributed on the roads. We used IEEE 802.11b as

the wireless media, with a data transmission rate of 11Mband a transmission range of 250 meters. During our outdoorexperiments, we found out that the wireless transmissionrange is less than 250 meters. However, we have been ableto restore this transmission range using external antennas.

4.2 Simulation Results

For all the simulation runs, the first 200 secondsrepresent a warm up period (i.e., no cab request occurswithin this period). Each client sends a cab request(BookSM) once during the simulation period, at a timechosen randomly after the warm up period. BookSMis unicasted for the on-demand and proactive routingmechanisms, while it is broadcasted for the floodingmechanism. Note that in case a client uses theProbabilisticOn-demandor Probabilistic Proactiverouting mechanismsand has no routing table information, it will broadcast theBookSM or DiscoverSM (to simplify the exposition, wewill refer only to BookSM).

The maximum number of hops a request can propagate(i.e., TTL) searching for a free cab is set to 20 hops.Once a free cab receives a cab request, it sets its status toreserved for a period chosen randomly between 2 and 5seconds and sends back a ReportSM. Once a confirmation(ConfirmSM) is received from a client, the cab status is setto booked (occupied) for a random period chosen uniformlyover the range [300, 1800] seconds. Regardless of therouting mechanism, a client re-broadcasts a cab request if itdoes not receive a reply from any free cab within a randomperiod chosen uniformly over the range [2, 5] seconds. Theaverage cab speed is set to 15 meters/second with zeropause time. We set the fudge factorL for the on-demandmechanism to 3. For the proactive mechanism, we set themaximum entries in the routing table (maxE) to 20, andthe periodic update interval (UPD) for UpdateSM to 5seconds. The maximum number of hops (i.e.,TTL) forUpdateSMs generated by free cabs is set to 3. Each entryin the routing table expires after2.5×UPD seconds of thelast update.

4.2.1 Effects of Number of Free Cabs

We first look at the effect of the initial number of free cabs.An initial free cab can be booked during the simulationand then switches its status back to free after the bookingperiod. On the other hand, all the cabs initialized as bookedat the beginning of the simulation remain booked duringthe simulation period. The initially booked cabs act only asrelays. For these runs, we fix the simulation time to 1500seconds, with the 200 seconds warm up period. The clientsrequest cabs uniformly over the next 1200 seconds, leavingthe last 100 seconds for any unfinished requests.

0 50 100 150 200

355 \ Flooding

355 \ On-demand

355 \ Proactive

255 \ Flooding

255 \ On-demand

255 \ Proactive

155 \ Flooding

155 \ On-demand

155 \ Proactive

Free

cab

s \ R

outin

g m

echa

nism

Type distribution of the 200 cab requests

unicast only1 broadcast2 broadcasts3 broadcasts4 broadcasts> 4 broadcasts

Figure 6. The type distribution of the 200request messages versus the number of freecabs

Figure 6 plots the type distribution of the requests usedby the 200 clients for each routing mechanism. A clientstarts with a unicast request if possible. If the unicastcannot be used or simply fails, the client switches to one ormore broadcast requests until it books a cab. For example,the ’155\On-demand’bar indicates that only 13 clientssucceeded to get a cab using only unicast requests. The restof the clients had to switch to broadcast requests. Of which,141 clients succeeded to book cabs using a single broadcastrequest, while the rest timed out and had to re-broadcast therequest (i.e., 26 clients needed two broadcasts to book a cab,6 clients need three broadcasts, and the remaining 12 clientsneeded four or more broadcasts).

All cab requests in the flooding mechanism, where norouting tables are used, are broadcast requests. As thenumber of initial free cabs decreases, a single client requestcould be repeated several times due to the unavailability offree cabs or dropping of the reply/confirmation messagesbecause of collisions. Most of the cab requests of theproactive mechanism are unicast that exploit the storedrouting tables. However, when the number of free cabsdecreases, some of those unicasts fail, and the clients usebroadcast requests. For the on-demand mechanism, becausethe clients were distributed over the city, just a few of themcould benefit from other requests and succeed to reservecabs using unicast requests, while the rest of the clientsswitched to broadcast requests.

Figure 7 plots the cumulative number of clients againstthe response time of the booking process. A client bookingends when a cab gets a reservation confirmation fromits client. A point (t, n) on the plot means that thebooking process time forn cabs is less than or equal totseconds. The proactive mechanism has the best responsetime, and most of the clients finish their booking in lessthan 10 milliseconds. Although this time is significantlyless than the time measured in the experimental results(our implementation uses execution migration and TCP forone-hop data transfer, while the simulations work directly

on top of IEEE 802.11), we believe that the simulationresults provide a realistic comparison among the routingalgorithms used by EZCab for large scale networks.

Figure 8 shows the average number of hops between abooked cab and its corresponding client. Interestingly, wefound that the cabs booked by the proactive mechanism arethe closest ones to their clients, while the other mechanismstend to book farther away cabs. This could be explained byFigure 9, which shows the average number of reserved cabsper request. Due to the large number of reservations foreach request in the flooding and on-demand mechanisms,subsequent cab requests may find that all closer cabs arereserved, and therefore, the requests propagate deep into thenetwork. The on-demand mechanism is the worst becausea free cab keeps forwarding the requests aggressively afterit replies back to the client in order to enable other clientsto update their local routing tables, while in the floodingmechanism, the propagation of the request terminates at afree cab.

Figure 10 shows the overhead of the mechanisms interms of the average number of messages transmittedper request (including the UpdateSMs for the proactivemechanism). We found that the overhead of theproactive mechanism is higher than the flooding mechanismespecially when the number of free cabs is large. This is dueto the periodic update messages from the cabs in the system.The on-demand mechanism has the highest overheadbecause of its aggressive broadcasting mechanism.

4.2.2 Effects of Cab Request Rate

We also tested the performance of the three mechanismsunder different rates of cab requests. In doing this, we limitall the cab requests to be within a fixed period after thewarm up. The simulation terminates 100 seconds after theend of request period. Changing the period length changesthe cab request rate. All the 410 cabs were initialized tofree. Figure 11 shows that the proactive routing exploits therouting tables and manages to send many of the requestsas unicasts even with high request rates. The othermechanisms suffer from hitting large number of reservedcabs, as shown in Figure 13, that increases the possibility touse broadcast requests several times. Figure 12 shows howthe proactive method managed to serve most of the clientsin a very short period compared with the other mechanisms.Figure 14 indicates that the proactive mechanism is still ableto catch a close cab to the client even with high request rates.Additionally, with high request rates, the overhead of theupdate messages per request in the proactive mechanismis minimized. Therefore, the proactive mechanism hasthe lowest overhead with high request rates as shown inFigure 15.

0

50

100

150

200

0.0001 0.001 0.01 0.1 1 10Booking time in seconds (logarithmic scale)

Num

ber

of c

lient

s

355 \ On-demand 255 \ On-demand 155 \ On-demand355 \ Proactive 255 \ Proactive 155 \ Proactive355 \ Flooding 255 \ Flooding 155 \ Flooding

Figure 7. The cumulative number of clientsversus the booking time for different numbersof free cabs

0

1

2

3

4

5

355 305 255 205 155

Number of free cabs from the 410 cabs

Avg

erag

e num

ber o

f hop

s be

twee

n a

book

ed ca

b an

d its

co

rres

pond

ing

clie

nt

FloodingOn-demandProactive

Figure 8. The average number of hopsbetween a booked cab and its correspondingclient versus the number of free cabs

0

20

40

60

80

100

120

140

355 305 255 205 155

Number of free cabs from the 410 cabs

Num

ber o

f cab

s set

to b

e re

serv

ed

FloodingOn-demandProactive

Figure 9. The average number of reservedcabs per cab request versus the number offree cabs

0

200

400

600

800

1000

1200

1400

1600

1800

355 305 255 205 155

Number of free cabs from the 410 cabs

Num

ber o

f tra

nsm

itted

pac

ket

per c

ab re

ques

t

FloodingOn-demandProactive

Figure 10. The average number of overheadmessages per cab request versus the numberof free cabs

0 50 100 150 200

10 \ Flooding

10 \ On-demand

10 \ Proactive

20 \ Flooding

20 \ On-demand

20 \ Proactive

50 \ Flooding

50 \ On-demand

50 \ ProactiveC

ab r

eque

sts p

er se

cond

\ R

outin

g m

echa

nism

Type distribution of the 200 cab requests

unicast only1 broadcast2 broadcasts3 broadcasts4 broadcasts> 4 broadcasts

Figure 11. The type distribution of the 200request messages versus the cab requestrate

4.2.3 Effects of Proactive Parameters

To study the performance of the proactive mechanism, werun different scenarios with different values of parametersmaxE, TTL, andUPD. We found out that increasing theTTL value has negligible effect on the performance, whichindicates that most of periodic updates happen only withinvery few hops of their origin. For these simulations, wefixed UPD to 5 seconds, whilemaxE varied between 5and 100 seconds. Similarly,maxE is fixed at 20 for thescenarios with differentUPD values ranging from 5 to 45seconds. Due to space constraints, we just summarize themain results.

Changing themaxE parameter has a small effect onthe distribution of the request types, while increasingthe interval of the periodic updates (UPD) decreasessignificantly the number of successful unicast requestsbecause of the outdated information stored in the routingtables. Therefore, the number of clients that finish thebooking process in less than 10ms has been significantlydecreased from 175 clients to 108 clients whenUPD hasbeen increased from 5 to 45 seconds. IncreasingUPDreduces the overhead of the periodic update messages, but atthe same time, it increases the number of broadcast requestswhich adds overhead on the system.

From the above results, we conclude that theProba-bilistic Proactiverouting is the most efficient mechanismas it guarantees more cab bookings in shorter time. Also,it guarantees to fetch cabs closer to the clients than theother mechanisms, which impacts favorably on the qualityof the service for both cab drivers and clients. We alsofound that the overhead of the updates sent by the proactivemechanism could be minimized in certain scenarios bytuning its parameters.

0

50

100

150

200

0.0001 0.001 0.01 0.1 1 10Booking time in seconds (logarithmic scale)

Num

ber

of c

lient

s

10 \ On-demand 20 \ On-demand 50 \ On-demand10 \ Proactive 20 \ Proactive 50 \ Proactive10 \ Flooding 20 \ Flooding 50 \ Flooding

Figure 12. The cumulative number of clientsversus the booking time for different cabrequest rate

0

10

20

30

40

50

60

70

10 20 50

Number of cab requests per second

Num

ber o

f cab

s fou

nd to

be

rese

rved

FloodingOn-demandProactive

`

Figure 13. The average number of cabs foundreserved per cab request versus the cabrequest rate

0123456789

10

10 20 50Number of cab requests per second

Avg

erag

e num

ber o

f hop

s be

twee

n a

book

ed ca

b an

d its

co

rres

pond

ing

clie

nt

FloodingOn-demandProactive

Figure 14. The average number of hopsbetween a booked cab and its correspondingclient versus the cab request rate

0

200

400

600

800

1000

1200

1400

10 20 50

Number of cab requests per second

Num

ber o

f tra

nsm

itted

pac

ket

per c

ab re

ques

t

FloodingOn-demandProactive

Figure 15. The average number of overheadmessages per cab request versus the cabrequest rate

5 Related Work

Existing cab booking systems [4, 28, 1, 2] use fixedinfrastructures such as Internet or cellular phone networksto relay client requests to a centralized dispatcher andtrack the location of cabs for optimal dispatch. Incontrast, EZCab consists of a mobile ad hoc network ofcomputers embedded in taxis and client handhelds, whichcommunicate through short-range wireless networks suchas IEEE 802.11 or Bluetooth. Instead of booking cabsthrough a centralized dispatcher, EZCab clients book freecabs by communicating directly with other EZCab nodesover the mobile ad hoc network.

Many research groups have looked into applications andsystem support for inter-vehicular communication [15, 16,22, 30]. While most of this research has been validated onlythrough simulations, we have designed and implemented aprototype for a real-life ubiquitous computing applicationwhich works over mobile ad hoc networks. In doing so, wehave leveraged on lessons and insights gained from work onrouting in mobile ad hoc networks [23, 31]. To minimizethe size of routing table, we use a probabilistic measure toindicate the probability of finding a free cab through eachnext-hop neighbors. This is possible for EZCab since thereis no distinction between different free cabs.

Due to their scalability and robustness against frequenttopological changes, geographical routing algorithms [26,27, 33, 20] are suitable for highly mobile vehicular traffic inEZCab, after a free cab has been discovered. With thesealgorithms, there is no need to maintain routes from thesender to the destination because the forwarding decisionsare based only on local knowledge.

The Smart Messages (SM) platform shares the idea ofexecution migration with mobile agents [25, 19], and activenetworks [17, 29, 32]. Mobile agents name nodes by fixedaddresses and commonly know the network configuration apriori, while SMs name nodes by content and discover thenetwork configuration dynamically. In contrast to mobileagents, SMs are responsible for their own routing at eachnode in the path between two nodes of interest. This featureallows SMs to adapt quickly to changes that may occur bothin the network topology and the availability of resources atnodes.

Although the SM computing platform shares some of thedesign goals and leverages work done in active networks(AN), it differs from AN in several key features. ANtarget improved performance for end-to-end data transferin relatively stable networks, while the SM platform helpsthe development of outdoor ubiquitous applications. UnlikeAN, the SM platform define a computing model wherebyseveral SMs can cooperate, exchange data, and synchronizewith each other through the tag space. In terms ofmigration, AN do not transfer the execution state from node

to node whereas the SM model does. The migration of theexecution state for SMs trades off overhead for flexibility toreact “on-the-spot” to adverse network conditions.

6 Conclusions and Future Work

In this paper, we have presented EZCab, a real-lifeubiquitous computing application for booking cabs in cities.EZCab discovers and books free cabs using only vehicle-to-vehicle short-range wireless communication. EZCab iseasy to deploy, cost effective, and scalable since it worksin a completely decentralized fashion. EZCab is just oneof the outdoor distributed computing applications that weare developing on top of mobile ad hoc networks usingSmart Messages as a common middleware architecture. Theexperimental results over ad hoc networks of nodes runningour prototype have demonstrated the feasibility of EZCab.The simulation results using different scenarios show thatEZCab with aProbabilistic Proactiverouting yields the bestresponse time and finds the closest cab to the client.

We are considering several extensions to EZCab asfuture work. In this paper, we assumed the cabsare cooperative and willing to propagate data betweeneach other. We plan to investigate the performance ofEZCab when it uses different classes of cabs in whichcommunication happens only between cabs belonging tothe same class. Cab classes model the situation of differentcabs companies, where each company is not willing to routemessages for a competing company. Another extension willallow occupied cabs to act as free candidate cabs based ontheir scheduled drop-off location and time. For example,it would be useful to consider a cab that is scheduled todrop-off a client a mere 10 feet from the new client withina minute, which is far better than booking a 15 minutesaway free cab. We also plan to study the use of prioritiesfor the free cabs based on, for example, their distances tothe client, how long they have been idle, or the number ofclients served in the last hour. The goal of such prioritysystem is to guarantee fairness and optimality.

References

[1] http://www.citycab.com.sg/services/nts/smsbooking.html.

[2] http://www.comfort-transportation.com.sg/bookingsvcs.html.

[3] Active Networks. http://nms.lcs.mit.edu/activeware/.[4] Auriga Systems. http://www.auriga.co.uk/.[5] HP iPAQ. http://h71016.www7.hp.com.[6] Motorola A760. http://www.motorola.com.[7] Sony Ericsson P900,

http://www.sonyericsson.com/p900/.[8] The Monarch Group at Rice University.

http://www.monarch.cs.rice.edu/.

[9] The Network Simulator ns-2,http://www.isi.edu/nsnam/ns/.

[10] Toshiba PocketPC. http://www.csd.toshiba.com.[11] D. Ashbrook and T. Starner. Using GPS to learn

significant locations and predict movement across multipleusers.Personal and Ubiquitous Computing, 7(5):275–286,October 2003.

[12] C. Borcea, C. Intanagonwiwat, A. Saxena, and L. Iftode.Self-Routing in Pervasive Computing Environments usingSmart Messages. InProceedings of the 1st IEEEInternational Conference on Pervasive Computing andCommunications (PerCom 2003), pages 87–96, Dallas-FortWorth, TX, March 2003.

[13] C. Borcea, D. Iyer, P. Kang, A. Saxena, and L. Iftode.Cooperative Computing for Distributed Embedded Systems.In Proceedings of the 22nd International Conference onDistributed Computing Systems (ICDCS 2002), pages 227–236, Vienna, Austria, July 2002.

[14] J. Broch, D. A. Maltz, D. B. Johnson, Y.-C. Hu, andJ. Jetcheva. A performance comparison of multi-hopwireless ad hoc network routing protocols. InProceedingsof the 4th annual ACM/IEEE international conference onMobile computing and networking, pages 85–97, ACMPress New York, NY, USA, 1998.

[15] Z. Chen, H. Kung, and D. Vlah. Ad Hoc RelayWireless Networks over Moving Vehicles on Highways. InProceedings of the 2nd ACM International Symposium onMobile Ad-hoc Networking and Computing, pages 247–250,Long Beach, CA, Oct 2001.

[16] I. Chisalita and N. Shahmehri. A Peer-to-Peer Approachto Vehicular Communication for the Support of TrafficSafety Applications. InProceedings of the 5th IEEEInternational Conference on Intelligent TransportationSystems, Singapore, Sept 2002.

[17] D. Wetherall. Active Network Vision Reality: Lessons froma Capsule-based System. InProceedings of the 17th ACMSymposium on Operating Systems Principles (SOSP 1999),pages 64–79, Charleston, SC, December 1999. ACM Press,New York, NY.

[18] S. Dashtinezhad, T. Nadeem, B. Dorohonceanu, C. Borcea,P. Kang, and L. Iftode. TrafficView: A DriverAssistant Device for Traffic Monitoring based on Car-to-Car Communication. InProceedings of the 59th IEEESemiannual Vehicular Technology Conference, May 2004.

[19] R. Gray, G. Cybenko, D. Kotz, and D. Rus. Mobile Agents:Motivations and State of the Art. In J. Bradshaw, editor,Handbook of Agent Technology. AAAI/MIT Press, 2002.

[20] H. Hartenstein, B. Bochow, A. Ebner, M. Lott,M. Radimirsch, and D. Vollmer. Position-aware adhoc wireless networks for inter-vehicle communications:theFleetnet project. InProceedings of the 2nd ACMinternational symposium on Mobile ad hoc networking &computing, pages 259–262, Long Beach, CA, 2001.

[21] Jennewein and J. Lexus. Volvo launch GPS-based telematicsin the US, 2000. Global Positioning & Navigation News 10,19.

[22] J. G. Jetcheva, Y.-C. Hu, S. PalChaudhuri, A. K. Saha, andD. B. Johnson. Design and Evaluation of a MetropolitanArea Multitier Wireless Ad Hoc Network Architecture. In

Fifth IEEE Workshop on Mobile Computing Systems &Applications, Monterey, California, October 2003.

[23] D. Johnson and D. Maltz.Dynamic Source Routing in AdHoc Wireless Networks. T. Imielinski and H. Korth, (Eds.).Kluwer Academic Publishers, 1996.

[24] P. Kang, C. Borcea, G. Xu, A. Saxena, U. Kremer, andL. Iftode. Smart Messages: A Distributed ComputingPlatform for Networks of Emb edded Systems.TheComputer Journal, Special Focus-Mobile and PervasiveComputing, pages 475–494, 2004. The British ComputerSociety. Oxford University Press.

[25] N. Karnik and A. Tripathi. Agent Server Architecture forthe Ajanta Mobile-Agent System. InProceedings of the1998 International Conference on Parallel and DistributedProcessing Techniques and Applications (PDPTA’98), LasVegas, NV, July 1998.

[26] B. Karp and H. Kung. Greedy Perimeter Stateless Routingfor Wireless Networks. InProceedings of the Sixth annualACM/IEEE International Conference on Mobile Computingand Networking (MobiCom 2000), Boston, MA, August2000. ACM Press, New York, NY.

[27] Y.-B. Ko and N. H. Vaidya. Location-Aided Routing(LAR)in Mobile Ad Hoc Networks. InProceedings of theFourth annual ACM/IEEE International Conference onMobile Computing and Networking (MobiCom), pages 66–75, October 1998.

[28] Z. Liao. Real-time taxi dispatching using Global PositioningSystems.Communications of the ACM, 46(5):81–83, 2003.

[29] J. Moore, M. Hicks, and S. Nettles. Practical ProgrammablePackets. InProceedings of the 20th Annual Joint Conferenceof the IEEE Computer and Communications Societies(INFOCOM 2001), pages 41–50, Anchorage, AK, April2001.

[30] T. Nadeem, S. Dashtinezhad, C. Liao, and L. Iftode.TrafficView: A Scalable Traffic Monitoring System. InProceedings of the 2004 IEEE International Conferenceon Mobile Data Management (MDM 2004), Berkeley, GA,January 2004.

[31] C. Perkins and E. Royer. Ad Hoc On Demand DistanceVector Routing. InProceedings of the 2nd IEEE Workshopon Mobile Computing Systems and Applications (WMCSA1999), pages 90–100, New Orleans, LA, February 1999.

[32] B. Schwartz, A. Jackson, W. Strayer, W. Zhou, R. Rockwell,and C. Partridge. Smart packets: Applying active networksto network management.ACM Transactions on ComputerSystems, 18(1):67–88, 2000.

[33] J. Tian, L. Han, K. Rothermel, and C. Cseh. SpatiallyAware Packet Routing for Mobile Ad Hoc Inter-VehicleRadio Networks. InIEEE 6th International Conference onIntelligent Transportation Systems (ITSC), Shanghai, China,October 2003.