adaptive route for traffic

Many emerging information appliancesassist motorists as they travel on today’s

congested roads:

� Route planners give detailed instructions on thesequence of roads to follow to reach a particular des-tination. The information may be presented via a dis-play mounted on the dashboard or as audio using thespeakers attached to the vehicle’s entertainmentsystem.

� Roadside monitors identify congested roads andtransmit reports to wireless receivers in vehicles. Carsequipped with computers can report their own speedto improve the quality of this information. The cen-tral system can broadcast all the information to pro-vide users with a global perspective.

� The Global Positioning System (GPS) can be used tomake vehicles aware of their current location.

� Mobile phones enable communication while traveling.

However, these services do not link toeach other, and using them while dri-ving can be dangerously distracting.

This article reports on an inte-grated system that uses congestioninformation to guide routing, bothin advance and while in transit. Itoffers two novel features:

� Historic information about con-gestion is collected and retainedfor use when planning routes.

� GPS tracks vehicles while theyundertake journeys, and theGlobal System for Mobile Com-munications (GSM) Short Mes-sage Service (SMS) maintainscommunications between a mov-ing vehicle and a central planningservice to suggest revised routesavoiding congestion.

What is congestion?We need a useful definition of congestion. What

offends drivers?There are many possible answers, such as the num-

ber of vehicles per mile on a road divided by the numberthe road was designed to bear, or the speed of trafficcompared to the speed limit for that class of road. Fur-ther options include the length of queues of traffic trav-eling at similar speeds and measurements of trafficdensity compared to a predetermined set of values. Inpractice, most drivers want to know how much longer ajourney is likely to take under the prevailing conditions,compared with traveling on an empty road.

We based the provision of routes discussed in this arti-cle on minimizing the time taken to complete a journey.Consequently, the definition of congestion used here isthe ratio of the current speed of traffic to the limit for thatclass of road. We can use this ratio, combined with thelengths of the relevant road sections, to calculate delays.

Available technologiesSeveral new technologies that have recently become

generally available can help solve the problem.Computer programs to calculate routes for motorists

have been available for several years. MicrosoftAutoRoute (http://www.microsoft.com/AutoRoute/)comes in versions with route data for both Great Britainand Europe, and Vicinity Corporation’s MapBlast(http://www.mapblast.com/) offers a similar onlineservice in the United States.

However, both programs assume the capacity of roadsremains static. The algorithms calculate a vehicle’sspeed solely on the basis of the class of road on which itis traveling (one speed for motorways or freeways,another for A-roads or main roads, and so on). No atten-tion is paid to variations in the traffic density with time.

A possible solution relies on the data offered by theTrafficmaster system. According to the HighwaysAgency, Department of the Environment, Transport, andthe Regions (http://www.highways.gov.uk/), there are10,458 km of trunk roads in the UK. Trafficmaster

0272-1716/00/$10.00 © 2000 IEEE

Information Appliances

2 May/June 2000

An integrated system uses

road congestion information

to guide routing. GPS tracks

vehicles, and the GSM short

message service maintains

communications with a

central planning service.

John Fawcett and Peter RobinsonUniversity of Cambridge

Adaptive Routingfor Road Traffic

(http://www.trafficmaster.co.uk/)has installed sensors every few kilo-meters that measure the speed ofvehicles moving on each stretch ofroad (see Figure 1). Trafficmasteruses two techniques:

� On major roads with separate car-riageways, sensors mounted onbridges and using infrared trans-ceivers capture the speed of indi-vidual cars.

� On smaller roads, camerasmounted on roadside poles iden-tify the central four characters invehicles’ registration numbersand timestamp the sightings. Theresults from adjacent sensorswhen correlated give the vehicle’saverage speed while travelingbetween them.

The information returns over a veryhigh frequency (VHF) packet radiosystem to a control center forrebroadcast to users.

Trafficmaster offers two maintypes of display. Subscribers can seemaps of any part of the road net-work with annotations indicatingareas of congestion. An alternativefree service gives warnings of con-gestion within about 20 km of thereceiver, together with an indicationof the affected directions of travel.The first service indicates the speed of traffic on roadsexperiencing congestion; the second simply reports theduration of the anticipated delay.

The information is also available to anyone equippedwith a cellular telephone. When the cell phone user callsthe appropriate number, information from the cellularnetwork determines the caller’s position. Then the Traf-ficmaster system reports the current state of traffic onnearby roads using synthesized speech, including boththe speed and anticipated delay. The latter is surpris-ingly accurate.

Two further technologies also prove relevant.The GPS1 uses a constellation of satellites in low earth

orbit (LEO) to provide a positioning system with accu-racy of a few tens of meters using relatively inexpensiveground receivers. Auxiliary services such as differentialcorrection and dead reckoning improve the accuracy toa few centimeters.

GSM-SMS provides reliable delivery of text messagesup to 160 characters in length between mobile phones.This has been packaged to provide a convenient wayfor mobile workers to interact with computers at theirbases.2

Associated workThe idea of using traffic monitoring and computer

support to alleviate the problems of congestion is not

new. Several significant results have been achieved.The Royal Automobile Club (RAC, http://www.rac.

co.uk/) offers a route-planning service that takesaccount of the currently congested roads as reported bythe Trafficmaster system. The service uses the currentcongestion information at the time of planning theroute. It does not account for the fact that conditionsmay differ when the journey actually starts or, indeed,may change during the course of a journey.

Similar monitoring systems are appearing elsewherein Europe and in the United States. The Calendar+ sys-tem developed by Schaffer and Alway at the Universityof Washington (http://www.cs.washington.edu/) com-bines routes from MapBlast with congestion informa-tion from the Washington State Department ofTransportation (Puget Sound Traffic Conditions,http://www.wsdot.wa.gov/PugetSoundTraffic/) onlinereports to advise travelers of likely delays. However, thisneither uses historical data to predict delays nor sug-gests alternative routes to avoid them.

Cameron et al.3 described a simulator that modelstraffic flows through urban areas. This uses a massivelyparallel computer to simulate the behavior of a largenumber of vehicles in real time. It is intended for use indesigning road networks rather than optimizing theiruse after construction.

Bar-Noy and Schieber4 discussed the problem of

IEEE Computer Graphics and Applications 3

1 Trafficmastersensor coveragein the UK.

planning a route through a road network susceptible toblockages. Their mobile agent only becomes aware ofblockages slightly before encountering them, so routeshave to be sufficiently intelligently planned to incor-porate flexibility for bypassing blockages as they arise.The approach presented in this article takes a broaderview of the network and so can plan more radical alter-native routes.

Awerbuch et al.5 discussed possible trade-offsbetween the size of the data held at each node in a graphand the time taken to perform a routing calculation. Thissubtlety isn’t really necessary when traversing graphswith the complexity of a road network.

Mitchell and Papadimitriou6 described the problemof finding a shortest path through a plane divided intosectors where different speeds can be achieved. Theiralgorithm would support the calculation of routes foroff-road driving, but that’s a different problem.

AimsThe project described in this article investigated pos-

sible ways to integrate congestion information from theTrafficmaster system with a route planner in such a waythat the recommended route would reflect the conges-tion anticipated at the (future) time when the journeywould be undertaken. Moreover, the traveler should benotified if congestion at the time of travel makes an alter-native route preferable.

System structureThe overall system consists of several modules, as

shown in Figure 2:

� The system collects congestion information from avariety of different network services. Converters forany electronic data source can be written indepen-dently and the software can be asked to dynamicallyadd (or remove) data sources from the system with-out restarting.

� These data are collated into a single queue and copiesdistributed to registered data recipients, including,in particular, a map manager that accumulates his-toric information and a live data service that informsclients of unanticipated congestion.

� The map manager annotates a detailed road map withcongestion information for different times of the dayand days of the week. The optimum time granularity—determined to be 15 minutes—adequately capturestrends in traffic congestion. Quadratic interpolationused between 15-minute aggregated samples estimatesthe instantaneous congestion at intermediate times.

� The routing service uses the connectivity and capac-ity information in the map manager to find an opti-mal route between a pair of points for a given time ofdeparture, in terms of minimizing the time taken tomake a journey. The optimization criterion could eas-ily be changed to minimizing fuel consumption, emis-sions, or a trade-off among several.

� The live data service monitors the current positionsof clients and current congestion along their antici-pated routes, and advises them of revised journeytimes and revised routes to avoid congestion.

� An administration console allows an operator to mon-itor and control the system, for example, to introducenew data sources dynamically.

Data collectionTrafficmaster made the raw sen-

sor data from its entire networkavailable to the AT&T Research Lab-oratory in Cambridge using a specialVHF radio receiver. This informa-tion is then distributed to nominat-ed users over standard transportcontrol protocol/Internet protocol(TCP/IP) socket connections.Reports are delivered as lines of textgiving a time stamp, the Ordnance


4 May/June 2000

Client Client Client

Livedata service

Client Client

Routingservice

1

Mapmanager

Administrationconsole

Roadmap15 4 3 2

Congestion packetinput queue

1

Network

Datasources

Congestion packets

2 Overall struc-ture of thesystem.

One-way road Two-way road Limited access junction

3 Representingdifferent typesof road andjunction.

Survey grid coordinates (OSGB) ofthe sensor, the name of the sensor’slocation, the direction of traffic flow,and the traffic speed, together withsome other housekeeping details.These are interspersed with textmessages reporting road restrictionsfor repairs or because of accidents.This collection of information wasmassaged into a standard form by aTrafficmaster data source filter andthe resulting packets inserted intothe processing queue.

Adaptors for other data sourcescould be written similarly. Forexample, the British BroadcastingCorporation (BBC) broadcasts traf-fic information in data subcarriersof its radio and television servicesand through its Web pages, andthese data could be fed into the sys-tem as well.

Map managerWe represented the road network

using a directed graph with eachedge depicting a one-way road andeach node corresponding to a junction. Two-way roadswere represented as a pair of edges, one in each direc-tion. This model permits easy modeling of one-wayroads and limited access junctions (see Figure 3). Wedidn’t model the exact routes of roads between junc-tions, assuming them to be straight lines. Given the fre-quency of junctions, assuming that roads run straightbetween them doesn’t introduce significant error intothe calculations.

Obviously the level of congestion on roads changeswith the time of day. This leads to a specific requirementregarding the algorithm used to calculate routes.Weights (or costs) attached to the edges in the directedgraph represent the speed of traffic on the correspond-ing roads (in the direction of the edge) and have to varywith the time of day.

This raises an important question: What temporalgranularity should we use to record congestion infor-mation? If the timing is too precise, the size of the storeddata will be too large, and if the timing is too coarse, thepredicted route times will be inaccurate. After collect-ing congestion reports for a couple of months, we decid-ed to record road capacities for 15-minute intervals for24 hours each day and 7 days each week. Weekends dif-fer sufficiently from weekdays to make this necessary,but seasonal variations through the year are generallynot worth recording. Consequently, every edge in theroad map carries 572 bytes of speed information.

The system revises the speed information for an edgeat the current time-of-week every time it receives a newcongestion report by calculating a running average:

revised = α × old + (1 − α) × new

This effectively calculates a geometrically weighted

average of all the past values. Empirical evidence sug-gested a value of 0.5 for α to give a good balancebetween rapid response to new reports and long-termstability. (Note that duplicate reports are suppressed,since they would bias the accumulated statistics. Also,reports are generated even in the absence of conges-tion; otherwise, the expected speed on roads woulddecrease monotonically.)

The entire map database including revised conges-tion averages is check-pointed to disk at regular inter-vals and archives are kept.

Routing serviceThe routing service takes any two points in the map

and an intended start time, and calculates the quickestroute between the two points given the anticipated con-gestion from historic information. The resulting itiner-ary lists roads, junctions, distances, and estimatedtimes, and is optimal with respect to minimizing thetime taken.

Live data serviceThe live data service serves two functions. First, it pro-

vides the data needed by graphical user interfaces todisplay a map of the road system overlaid with currentcongestion information (see Figure 4).

The red circles indicate the location of traffic reports,and the white numbers are the traffic speeds in milesper hour at these sites. The text area at the bottom logshuman-readable reports delivered by data sources suchas the Trafficmaster system.

Secondly, information from the live data service isused to advise clients already on the road of alterationsto their itineraries recommended in light of recentlyreceived congestion information.


4 Live congestion information.

Routing algorithmsRouting is well studied in computer science,7 but

some of the standard algorithms turn out to be lackingor inappropriate for this application in one or morerespects.

Breadth-first and priority-first searchesBreadth-first search and priority-first search would

work and might be expected to find an optimal route,but they require substantial computational effortbecause they explore inappropriate parts of the graphin addition to the relevant parts. It’s not clear whatheuristics should be used with priority-first search tofind good routes in a reasonable time. Some of the earlycommercial route planners were notoriously ineffectivein this respect and would, for example, lead the driverthrough miles of twisting country lanes rather thanheading a few miles directly away from the destinationto reach a motorway junction.

Dijkstra’s algorithmDijkstra’s algorithm guarantees to find the best route

(with respect to minimizing the total cost of edges in theroute) between two nodes, if a route actually exists. Thealgorithm considers edges with the smallest cost first,but this means it cannot know how much time will haveelapsed since the start of the journey when any partic-ular link is traversed. This application cannot determinethe weight of an edge until it knows the time of travel.It can evaluate the weights only at an estimated time,and the start time of the journey provides as good anapproximation as any.

A better estimation of the time when an edge will betraversed can be derived by interpolation from thestraight-line distance between the edge and the startand an estimate of the total journey time. However, thisimproves matters only slightly. The algorithm guaran-tees to terminate in all circumstances. The asymptoticcost is O(v2) for a graph with v vertices.

Lee’s algorithmOriginally used for track routing on printed circuits and

integrated circuits, Lee’s algorithm8 suits changing roadcapacity more naturally than Dijkstra’s. This algorithmalso finds the best route with respect to optimizing some

metric, as long as such a route exists. The method simu-lates an inkblot spreading out over a piece of paper, cen-tered on the start point. The area covered representsvertices already explored. The real time is known upontraversal of each edge, so the algorithm can calculate thecorrect value of the delay (because the delays depend ontime and day). When the destination vertex is reached,the algorithm traces the route back to the start.

When used for track routing in very large scale inte-grated (VLSI) circuit design applications, a Lee routerexplores the surfaces of a circuit board by making equal-sized steps in all permissible directions, beginning withthe start node. The search takes a breadth-first approachand is initialized by putting the start node in a queue ofnodes to explore. Items in the queue are tagged with thedistance (number of steps) already spent in reachingthat point.

At each computation step the router examines thequeue. An empty queue means no route exists. Other-wise, the algorithm extracts and examines the head ofthe queue. If the head of the queue is the required des-tination node, then a route has been found. Using a sim-ple induction can prove that the path taken by the routeris the quickest route from the start. If the head of thequeue is not the destination node, then the router con-siders equal-sized steps in all (valid) directions to reachfurther nodes. These nodes move to the end of thequeue, with their distance-so-far indicators increment-ed by one. However, a node already in the queue oralready explored is not added again, since a shorterroute to that location has already been found. If thequickest path to the destination does indeed go throughthat location, there can be no need to go via the newintermediate point, as that route would take at least aslong as the previously discovered one.

In the road-traffic routing application, the step sizesare unequal because roads have differing lengths andlevels of congestion, which change the time taken to tra-verse them. The distance-so-far attached to items in thequeue equals the total time spent in reaching that loca-tion from the start. As the router explores nodes andfinds them not to be the destination node, it considersnew locations. It marks these new locations as reach-able in a time equal to the time taken to reach theexplored node plus the time taken to drive along thejoining road at the relevant time-of-day (computed fromthe user-supplied start date and time of the journey andthe time-so-far into the route). The newly reached nodesmust be inserted into the queue in increasing order ofarrival time. For this reason, the router uses a time-ordered list to store the list of vertices to explore, ratherthan a simple queue. Duplication in the time-orderedlist needs careful attention: If a node being added isalready in the queue, then only the entry with the lowertime is kept. This may involve removing an existingqueue item. Otherwise, the algorithm proceeds asdescribed above. It also guarantees to find the shortestroute (in terms of time), as long as one exists.

Adaptive traffic routing needs a further modificationbecause the cost of an edge may change between theexploration and trace-back phases, which can cause thetracer to find no routes with the expected cost. Merging


6 May/June 2000

The final route produced by Lee’s

algorithm is optimal in the sense that

starting at a time specified by the user and

taking into account the time when each

section of road would be driven, the

output route offered the quickest

path to the destination.

the trace-back and exploration phases fixes this—theexplorer builds a tree as it runs, and when it finishes, theoptimum route is the unique path through the tree fromthe destination leaf to the root (the start vertex). A treeis built rather than a general graph because the algo-rithm does not explore cycles.

This algorithm’s cost is difficult to express. It is bestdescribed as polynomial in the number of edges. Theworst case only occurs when there is no route betweenthe start and destination vertices, and so is unlikely tooccur in practical road maps, especially if ferry crossingsare included in the map. The average cost is less than thatof Dijkstra’s algorithm because it stops considering routeswhen they are longer than the best route so far from thesource to the destination. Lee’s algorithm can be seen astaking a local view, whereas Dijkstra’s takes a global view,considering all edges at once, which wastes time.

Soukup’s algorithmBased on Lee’s algorithm, Soukup’s routing algorithm

uses heuristics to limit the search and prioritize theorder of vertex exploration. These modifications meanthat the algorithm cannot guarantee to find the opti-mum route or even to find a route if one exists. Weexpected that the running time of a Lee router on agraph of the sparseness of a road map would be only afraction of a second, so optimizations motivated by lim-iting the search space to improve performance don’tapply.

Bellman-Ford routing algorithmBellman-Ford7 is a distance-vector routing scheme

used by the early Arpanet routers and implementationsof Routing Information Protocol (RIP, for DECnet andNovell IPX packet routing). Each node maintains a tablethat lists the quickest route to every other node. At reg-ular intervals, the nodes broadcast their tables to theirneighbors, which update their tables accordingly andpropagate the information to their neighbors, and so on.Care has to be taken with cycles. Calculating a routebetween two nodes is an O(log n) operation for a graphwith n nodes—it only involves a look-up in the table held

by the start node. Using an appropriate data structure(for example, a heap, red-black tree, B-tree, or a hashtable), this can be very efficient.

The disadvantage for adaptive traffic routing is thatthe amount of storage required for all the tables is vastand increases as the square of the number of nodes inthe graph. While routes can be provided with very littlecomputation, maintaining the tables carries a largeexpense. This arduous housekeeping must be done evenwhen no users are requesting routes.

Fast Lee routingOn balance, we used Lee’s algorithm because it gives

satisfactory results in a reasonable time without addingundue complexity. The final route produced is optimalin the sense that starting at a time specified by the userand taking into account the time when each section ofroad would be driven, the output route offered thequickest path to the destination.

Performance improves by representing the edges inLee’s inkblot as events in a time-ordered list, in a sim-ilar way to how an event-based simulator models sig-nal changes propagating through a piece of hardware.This allows the algorithm to develop the perimeter ofthe inkblot extremely quickly, avoiding parts of thegraph already passed or still some distance away. Find-ing a route from one end of the United Kingdom to theother takes an imperceptible fraction of a second on amodest PC.

The images in Figure 5 show the routes offered by thesystem to cross London at similar times on Sunday andMonday mornings. On Sunday, the program recom-mends using the M25 orbital motorway, but given theknown congestion of the M25 on a Monday with com-muters, it suggests a direct route through the center ofLondon instead. Actually, this scenario is unrealistic,reflecting the absence of congestion sensors in centralLondon, but it nevertheless demonstrates the principle.

The sitting-still problemA problem still arises from the quantization of the

changing speeds on individual edges in the graph. This


5 Recommend-ed routes forthe same jour-ney at similartimes on differ-ent days.

will affect any algorithm that attempts to find an opti-mal route.

Suppose a route being explored has reached junctionj at time τ, from which there are two routes to some ver-tex k (possibly via one or more intermediates), as shownin Figure 6. If both routes are heavily congested at timeτ, but r1 slightly less so than r2, then r1 will be selected.However, in a few minutes the congestion may havecleared considerably on r2, and it may be that waitingthose few minutes and then taking r2 results in a quick-er route overall. Of course, it is never sensible to “sit still”at junction j—the driver should take the r2 branch imme-diately, as this will always give the same or better timeto reach k.

The solution adopted is to reduce the granularity ofspeed data samples in the edges by interpolatingbetween the values for consecutive time slots. When esti-mating the time it would take to drive from one roadjunction to a neighboring junction at a specific time ofthe week, the distance between the junctions is dividedby the traffic speed at that time. Quadratic interpola-tion used within each time slot improves the estimatesof speed.

Real-time routingThe second goal of this project was to calculate

revised routes in the light of actual congestion infor-mation received at the time of travel. This uses two fur-ther pieces of technology.

The Navstar GPS and the GSM-SMS extend the func-tionality of the routing software. We envisage that sooncars, vans, and trucks will be fitted with GPS receiversand GSM telephones (or some similar wireless commu-nications technology). With a Car-PC (Kontron Embed-ded Computers, http://www.kontron.com) or similardevice installed, lightweight code can be executed onthe move, and the full potential of the GPS and GSM-SMS hardware can be realized.

At regular intervals (in either time or distance cov-ered) the equipment in the car determines its locationusing the GPS receiver and sends the coordinates, alongwith an identifier, by GSM-SMS to an SMS server backat base. The identifier is looked up in a table of previ-ously recommended routes to determine where this dri-ver is heading. The routing service is then called tocalculate a revised route from the current location of the

vehicle to its known destination. This route is comparedwith that given to the driver before the journey started.

If, in light of accidents for example, the best route haschanged, the server returns the revised route to the dri-ver by GSM-SMS. Alternatively, the best route may notchange, but the road speeds might, making the esti-mated time of arrival significantly different. In this case,the server advises the driver to follow current directionsbut that the estimated time of arrival has increased (ordecreased) by the appropriate amount. The server alsodescribes any likely congestion ahead.

The additional service is implemented through theSMS server at the AT&T Research Laboratory in Cam-bridge.2 This effectively presents a standard command-line interface on the computer running the routingservices through GSM-SMS. Commands are sent asshort messages and responses returned similarly.

In this case, the command carries arguments speci-fying the driver’s current position and the identity ofthe route:

GSMRelay 544606 262498

robinson_route_42

The response indicates anticipated congestion:

20MpH on M25 J27-J28

20MpH on M1 J9-J8

25MpH on M1 J12-J11

15MpH on M6 J7-J6

20MpH on M6 J10-J9

20MpH on M6 J10a-J10

The advisory function checks each active route for newcongestion and generates text when appropriate, relay-ing it to the driver as soon as possible. To simplify thepresentation of information to the user, and to improvethe user interface, a combined functionality informa-tion appliance could be created by passing the conges-tion advice as speech, either generated on the serverand relayed as a voice message to the mobile phone, orforwarded as a command directly to a speech synthe-sizer in the car.

The routing algorithm is sufficiently fast that a singleserver can support several hundred clients whose posi-tions are monitored every couple of minutes. A moreelaborate scheme would use congestion reports asindices back into currently active journeys and onlyreconsider directly affected users, but this isn’t necessaryin practice. As the computing power available in a stan-dard car increases, the whole system could be distrib-uted and recalculations performed locally in the vehicle.

ConclusionsWhilst not a commercial product, the software has

demonstrated that adaptive computerized route gener-ation could help drivers cope with the growing conges-tion on UK roads. Although it doesn’t tackle the causesof congestion, the software could prove useful in mini-mizing the delays resulting from queues of traffic.

As the network of sensors expands, the routing advicewill improve with little extra cost. The extra data should


8 May/June 2000

k

m

r1

r2j

6 The sitting-still problem.

enhance accuracy through better modeling of the realworld. At the same time the cost of running Lee’s algo-rithm shouldn’t increase significantly, so the softwareshould continue to calculate routes quickly.

Commercial organizations conceivably might usesoftware similar to that described here. Many compa-nies already have database facilities available to helptheir drivers find delivery addresses and to help themanagement team assess performance of their employ-ees. Adding route planning facilities to the databasecould increase productivity and profits for the compa-ny by reducing wasted time and money when drivers sitin traffic. This would also help to cut vehicle pollution,which plagues many inner-city areas.

The software is implemented in Java. This gives it theability to run on Web browsers in homes and offices, andalso in hotel rooms and boardrooms via WebTVs. Thesystem shows how computing, communications, andlocation information combined in an information appli-ance can provide valuable facilities in a genuinely ubiq-uitous computing environment. �

AcknowledgmentsWe are very grateful to Trafficmaster UK and AT&T

Research Laboratories, Cambridge, UK for making thecongestion information available.

References1. I. Getting, “The Global Positioning System,” IEEE Spectrum,

Vol. 30, No. 12, Dec. 1993, pp. 36-38, 43-47.2. F.M. Stajano and A.H. Jones, “The Thinnest of Clients: Con-

trolling it all via Cellphone,” ACM Mobile Computing andCommunications Review, Vol. 2, No. 4, Oct. 1998, pp. 46-53.

3. G. Cameron, B.J.N. Wylie, and D. McArthur, “Paramics—Moving Vehicles on the Connection Machine,” Conf. onHigh Performance Networking and Computing, Washing-ton, Nov. 1994, pp. 14-18.

4. A. Bar-Noy and B. Schieber, “The Canadian Traveler Prob-lem,” Symp. on Discrete Algorithms, ACM Press, New York,Jan. 1991, p. 261.

5. B. Awerbuch et al., “Compact Distributed Data Structuresfor Adaptive Routing,” ACM Symp. on the Theory of Com-puting, ACM Press, New York, May 1989, pp. 479-489.

6. J.S.B. Mitchell and C.H. Papadimitriou, “The WeightedRegion Problem,” J. ACM, Vol. 38, No. 1, 1991, pp. 18-73.

7. R. Sedgewick, Algorithms, 2nd edition, Addison-Wesley,Reading, Mass., 1988.

8. C.Y. Lee, “An Algorithm for Path Connectivity and its Appli-cations,” IRE Trans. on Electronic Computers, Vol. 10, No. 3,Sept. 1961, pp. 346-365.

John Fawcett is a PhD student atthe Laboratory for CommunicationsEngineering at the University ofCambridge in England and a mem-ber of Churchill College. He is part ofthe Sentient Computing group. Hepreviously studied for a degree in the

Computer Laboratory at the University of Cambridge inEngland. His current research focuses on applications formobile users, includes services that may be delivered tovehicles over wireless communications media, and extendsto additional facilities that can be brought about by hav-ing large numbers of equipped vehicles.

Peter Robinson is a lecturer in theComputer Laboratory at the Univer-sity of Cambridge in England, wherehe is part of the Rainbow Groupworking on computer graphics andinteraction. He is also a Fellow, Pra-elector, and Director of Studies in

Computer Science at Gonville & Caius College, where hepreviously studied for a first degree in mathematics and aPhD in computer science. His research interests are in thegeneral area of applied computer science. The main focusfor this is human-computer interaction. He also works onelectronic design automation and, in particular, on sup-port for self-timed circuits. He is a Chartered Engineer anda Fellow of the British Computer Society.

Readers may contact Robinson at the University of Cam-bridge, Computer Laboratory, New Museums Site, Pem-broke St., Cambridge, England CB2 3QG, [email protected].


adaptive route for traffic

Documents