TrafficView: A Scalable Traffic Monitoring System ∗

Tamer Nadeem, Sasan Dashtinezhad, Chunyuan LiaoDepartment of Computer Science

University of Maryland{nadeem,sasan,liaomay}@cs.umd.edu

Liviu IftodeDepartment of Computer Science

Rutgers Universityiftode@cs.rutgers.edu

Abstract

Vehicles are part of people’s life in modern society, intowhich more and more high-tech devices are integrated, anda common platform for inter-vehicle communication is nec-essary to realize an intelligent transportation system sup-porting safe driving, dynamic route scheduling, emergencymessage dissemination, and traffic condition monitoring.TrafficView, which is a part of the e-Road project, definesa framework to disseminate and gather information aboutthe vehicles on the road. Using such a system will providea vehicle driver with road traffic information, which helpsdriving in situations as foggy weather, or finding an optimalroute in a trip several miles long. This paper describes thebasic design of TrafficView and different algorithms used inthe system.

1 Introduction

Vehicles are part of people’s life in modern society,into which more and more high-tech devices are integrated.Most of the current research focuses on the functionalitiesof individual vehicles, and less attention has been paid tothe cooperation among vehicles and road facilities, whichforms the whole transportation system. Moreover, a com-mon platform for inter-vehicle communication is necessaryto realize an intelligent transportation system supportingsafe driving, dynamic route schedule, emergency messagedissemination, traffic condition monitoring, etc.

The e-Roadproject is an attempt to achieve the afore-mentioned goals by providing a scalable infrastructurefor inter-vehicle communication. Specifically, the e-Roadproject is aimed at building a system with the followingcharacteristics:

• Real-time message dissemination platform:The mes-sages can be efficiently delivered from moving vehi-

∗This work is supported in part by National Science Foundation underNSF ANI-0121416

cles or fixed stations to other vehicles, with small de-lay and low bandwidth cost. The dissemination sys-tem could be used in sending messages about trafficcondition monitoring, road condition, accident report,road-side e-advertisements, etc.

• Information query platform:Besides “passively” re-ceiving messages, a vehicle is enabled to query infor-mation about specific targets. For example, a vehiclecan query about the average vehicle speed in a region,road condition at Exit 11, or hotels 10 miles away.

• Reliable information exchange protocol:This is nec-essary Algorithms and Metricsfor connection-orientedapplications. For example, it can be used for musicdownloading, back-seat passenger games, or connec-tion to the Internet.

In this paper, we presentTrafficView, which is a part ofthe e-Road project. TrafficView defines a framework to dis-seminate and gather information about the vehicles on theroad. Using such a system, a vehicle driver will be aware ofthe road traffic, which helps driving in situations like foggyweather or finding an optimal route in a trip several mileslong.

A GPS receiver shows a static view of the map, whereasTrafficView provides the driver with a dynamic view of theroad traffic, and therefore complements the GPS receiver.When integrated with the traditional digital map system,TrafficView would be able to provide the functionality ofreal-time automatic route scheduling. Moreover, in such aplatform, other applications such as accident alert, and road-side e-advertisement can be easily implemented.

This paper describes our experience in developing theTrafficView system. Throughout our experimentation, weperform a detailed study of different information dissem-ination techniques under various road density and vehiclemobility conditions.

The rest of the paper is organized as follows: The nextsection presents the background, and the description of theproblem is given in Section3. In Section4 and Section5 we

1

describe the design of TrafficView and the mechanisms usedin the system. The System performance is studied in Sec-tion 6. In Section7 we summerize the related work. Finallywe present our conclusions and future work in Section8.

2 Background

2.1 Mobile Ad-hoc Networks

Pervasive computing, a hot topic in recent systems re-search, gives researchers a new broad horizon to explore.At the heart of the pervasive computing, distributed sys-tem and mobile computing have received a lot of attention[15]. With the development of the pervasive computing,the use of computers will become invisible and natural, andbe tightly combined with physical objects to form adataspace, where the data is inherently dispersed and connectedas a part of physical objects.

Wireless Mobile Ad Hoc Networks (MANETs) are oneof the contributions toward the aforementioned goal; quiteattractive because of higher flexibility and ad hoc infras-tructure. However, they also give rise to challenges toresearchers, because of the inherent high dynamic net-work topology and limited transmission range in these net-works. A lot of work has been done, involving routing, datacaching, data querying, and so forth related to MANETs.

2.2 Inter-Vehicle Communication

The research in Inter-Vehicle-Communication hasemerged in the past couple of years; mainly because it isa good experiment platform for Wireless Mobile Ad HocNetworks, and has a great market potential [8]. Several ma-jor automobile manufactures and universities have begun toinvestigate in this field; GM research center in CMU [7],BMW Research Labs [16] and Ford Research Labs [11],Rice University [17][13], and Harvard University [4] are afew to name.

In addition to the similarities to MANTET such as shortradio transmission range, low bandwidth, omnidirectionalbroadcast (at most times) and low storage capacity, inter-vehicle communication has its unique characteristics andchallenges as well:

• Rapid changes in link topology.Because of the relativemovement of the vehicles, the connectivity betweenvehicles is always changing. For example, if vehicles’speed is around 60 mph, i.e., 25m/s, and the trans-mission range of wireless networks is 250m, the con-nectivity between two vehicles could last for at most500/25 = 20 seconds.

• Frequently disconnected network.In the case of lowvehicle density, the gap between two vehicles might

be several miles, far beyond the transmission rangeof wireless networks. In turn, the disconnection timecould be minutes. Due to the fast movement of vehi-cles, and high dynamic traffic conditions, this situationis not uncommon.

• Data compression/aggregation.Wireless networkshave a limited available bandwidth. In order to build ascalable system, data compression/aggregation mech-anisms are required to save the bandwidth.

• Prediction of vehicle’s positions.Vehicles normallyrun along pre-built roads, which remain unchangedover years. Therefore, given the average speed, cur-rent position, and road trajectory of a specific vehicle,the future position of that vehicle can be predicted.

• Energy is not a big issue.In sensors networks, thenodes are battery-powered, and it is not easy to replacethe battery after deployment. This limits the runningtime of a node is such a network. Therefore, a lot ofeffort has been made to conserve energy in sensor net-works. On the other hand, in a vehicle network, thevehicle itself can be used as a source of electric power,and therefore, energy is not a big issue in such a net-work.

2.3 Data Delivery modes

In multihop wireless networks, such as vehicle network,data could be delivered using two different modes:pushmode andpull mode.

In push mode, which is the focus of this paper, data isbroadcast and propagated to all possible recipients that pas-sively listen to the channel. There is no notion of routeestablishment or interaction between the senders and thereceivers. Data is transported in unreliable and out oforder fashion. Typical application scenarios are vehicleaccident alert, peering vehicles monitoring, road-side e-advertisements, and so forth.

In contrast, in pull mode the data is transmitted betweenaquery sender(QS) and aquery responder(QR), and thereis some interaction between the two. The QS needs to ac-tively send out a request to a specific target—a vehicle ora group of vehicles in a region—which in return reply withthe available answer. To establish this session, the QS andQR should identify each other with their geographic posi-tion, unique identification number or other means.

3 Problem Description

Given a set of moving vehicles on the road, the goal isto exchange information about the position and speed of

2

1

2

3

4

1

2

3

4

1

2

3

4

1

2,1

3,2,1

4,3

1

2

3

4

1

2,1

3,2,1

4,3,2,1

(a) (b) (c)

Figure 1. The problem this paper addresses (a) and the diffusion mechanism (b and c)

those vehicles among them to enable each individual ve-hicle to view and assess traffic and road conditions in frontof it. As the vehicles move along the road, they might en-ter the transmission range of some vehicles, and exit thatof others. Figure1 (a) shows an example of a road withfour lanes, on which four vehicles are moving. Two mainmechanisms could be used to achieve this goal: floodingand diffusion. In the flooding mechanism, each individualvehicle periodically broadcasts (pushes) information aboutitself. Whenever a vehicle receives a broadcast message,it stores it andimmediatelyforwards it by rebroadcastingthe message. Obviously, this method is not scalable, due tomessages flooding over the road, especially in high densityroads.

In the other mechanism—the diffusion mechanism—each vehicle broadcasts information about itself and theother vehicles it knows about. Whenever a vehicle receivesbroadcast information, it updates its stored information anddefers forwarding the information to the next broadcast pe-riod, at which time it broadcasts its updated information.The diffusion mechanism is scalable, since the number ofbroadcast messages is limited and they do not flood the net-work. We use the diffusion mechanism in TrafficView.

As an illustration of the diffusion mechanism, assumethat in Figure1 (a), vehicles 2 and 3 are in the transmissionrange of vehicle 1. Likewise, vehicles 3 and 4 are in theradio range of vehicles 2 and 3, respectively. At the begin-ning, each vehicle knows only its own position and speed.After the first broadcast period (part (b) of the figure,) ve-hicles 2 and 3 hear vehicle 1’s broadcast about itself, andstore that information. The same happens for vehicle 4 hear-ing vehicle 3’s broadcast message. After the next broadcastperiod (part (c) of Figure1), vehicle 4 hears the messagebroadcast by vehicle 3 which includes information about allof 1, 2, and 3, and updates its local information. Note that

the relative position of the vehicles have changed over time,and some have changed their lanes.

TrafficView does not suffer from memory limitation dueto the small size of the stored records. As will be shown inSection4, the average size for data records is on the orderof 50 bytes. Assuming a very high density, five-lane roadin which the distance between consecutive vehicles is 5 me-ters, about 5K bytes will be needed to store the informationabout all the vehicles in 100 meters, and about 1M bytesto store information of all the vehicles in 20Km. Most ofthe current portable devices come with more memory thanthese values.

On the other hand, assuming a transmission range of250m for the wireless network card, there will be 50 ve-hicles competing for the same wireless medium in a sin-gle lane and about 250 vehicles in a five-lane road giventhe lanes are close to each other. Then, the total amountof data that needs to to be broadcast by these vehicles ev-ery broadcast period is 250MB, which is beyond the capa-bilities of the current wireless technology. To cope withthe bandwidth limitation, each vehicle is allowed to broad-cast a small packet in order of few kilo bytes every broad-cast period to allow other surrounding vehicles to share themedium. Therefore, compression/aggregation mechanismsare needed to reduce the size of information to fit into thebroadcast packet.

For simplicity, we assume throughout this paper that theroad is straight. In the general case, the direction of themovement of a vehicle can be included in the record sentout about that vehicle, and then used to estimate its positionon the road trajectory. Moreover, without loss of generality,we assume that the road is along they axis, and all the ve-hicles are moving in the positive direction of the road. In areal situation, a road might be bidirectional, where vehiclesmove in two opposite directions. In this case, a vehicle will

3

Figure 2. Hardware components used in theTrafficView prototype

need to examine the movement vector in a record receivedabout another vehicle, and ignore it if that vehicle is mov-ing in the opposite direction. This can also be applied inthe case of an intersection where a vehicle might hear aboutdifferent vehicles moving in different directions.

4 System Design

In this section we present the design of the implementedprototype of TrafficView system. Hereafter we use theterms “vehicle” and “node” interchangeably.

4.1 Hardware

We implemented a prototype of TrafficView system asshown in Figure2. The prototype consists of a portable de-vice (e.g. Compaq iPAQ with Linux Familiar distribution)augmented with two slots PCMCIA sleeve, Global Position-ing System (GPS), 802.11b wireless card, DSP-100 2 portRS-232 serial PCMCIA card [1], and OBDI-II interface [2].The GPS receiver provides the latitude and longitude of thevehicle in addition to the global time. Using the wirelesscard, network connectivity is established, and the vehiclewill be able to transmit and receive information about othervehicles. TrafficView periodically queries the vehicle’s sta-tus (e.g. speed) using the OBDI-II interface. DSP-100 cardis used to connect the iPAQ with the GPS and OBD-II.

The iPAQ device runs the TrafficView software that dis-plays road traffic information and is responsible for the in-teraction with other vehicles. We assume that each vehiclehas a unique identification number (ID). The vehicle iden-tification number (VIN) or driver’s driving license number

NIC/recv

Non-validated

Validation Aggregation

Display/UI

GPS/OBDII

NIC/send

Validated

Figure 3. The structure of a node in Traf-ficView

are good candidates for the ID.

4.2 Software

In TrafficView, each vehicle stores records about itselfand other vehicles it knows about. In this section, wedescribe the record format and the system modules.

4.2.1 Data Representation

Each record stored about another vehicle consists of the fol-lowing fields:

• Identification (ID): Used to uniquely identify therecords belonging to different vehicles.

• Position (POS):The current estimated position of thevehicle.

• Speed (SPD):Used to estimate the vehicle’s position ifno messages containing information about that vehicleare received.

• Broadcast Time (BT):The global time at which thevehicle broadcast that information about itself.

4.2.2 System Components

Figure 3 shows the software components (modules) of anode in the system. Each vehicle stores records aboutother vehicles in its local datasets. When the record isfirst received in a broadcast message, it is stored in thenon-validateddataset, since it might contain outdated orconflicting information. After these records are examinedfor validity, they are moved and merged with thevalidateddataset.

A TrafficView node, as in shown Figure3 contains sixmodules that operate on its datasets:

4

• GPS/OBD module:Periodically updates the vehicle’sown record fields in the validated dataset.

• Receive module:Listens to broadcast messages fromneighboring vehicles, and stores the records receivedin the non-validated dataset. It ignores the messagesbroadcast by its own vehicle.

• Validation module:Validates and resolves conflicts ofthe records in non-validated dataset. It then mergesthe validated versions with the records in the validateddataset. For example, this module removes all therecords that are about vehicles behind its own vehicle1.Another example of a validity check is when thereare multiple records containing information about thesame vehicle. In this case, this module keeps the mostrecent record, and removes the older versions. In ad-dition, this module periodically updates the estimatedposition of the vehicles in the validated dataset us-ing the stored speeds. The validation module is alsoresponsible ofinformation aging, which will be dis-cussed in detail in Section5.4

• Aggregation module:Performs aggregation algorithmson the records in the validated dataset in order to beable to place more information in the outgoing broad-cast messages. This module might as well update thedataset by replacing the original records with the newaggregated version.

• Send module:Writes the contents of the records in thevalidated dataset in a broadcast message and broad-casts it on the wireless channel using the wireless card.

• Display/UI module:Responsible of displaying the val-idated records periodically on the display. It is alsoresponsible for the user interaction (e.g., graphicallyand/or audibly).

5 Data Aggregation Algorithm

A MAC layer protocol (e.g. IEEE 802.11b protocol) lim-its the size of the payload that is sent on the network chan-nel to a maximum size (which is 2312 bytes for 802.11b.)This limit applies to the broadcast message a node intendsto send in the TrafficView system as well. On the otherhand, the number of records in a node’s validated datasetcan be large, making it impossible to fit all of them inone broadcast message. In order to deliver as many in-formation about other vehicles as possible, data compres-sion/aggregation techniques should be applied on the vali-dated records. Data compression and aggregation are two

1TrafficView only stores information about the vehicles in front of thecurrent vehicle, and ignores the ones behind it.

different concepts. Data compression is actually ”binarycompression” in the sense that it does not base the decisionsmade on the semantics of the data. Moreover, data com-pression techniques require a lot of computation resourceswhich is not suitable for most portable devices. In this paperwe focus on data aggregation mechanisms only.

Data aggregation is based on the semantics of the data.For example, the records from two vehicles can be replacedby a single record with little error, if the vehicles are veryclose to each other, and they are moving with relatively thesame speed. In other words, the distance between them isalways in a small range. The way data aggregation con-tributes to the TrafficView system is by delivering as manyrecords as possible in one broadcast message. This way,more new records can be delivered in a certain period oftime and the overall system performance is improved.

5.1 Data Aggregation Basics

A single aggregated record will represent informa-tion about a set of vehicles. In this paper we adoptone simple format for the aggregated records2: In anaggregated record, the ID field is extended to a list ofvehicles’ IDs while the other fields—position, speed,and broadcast time—remain as single values for all thevehicles stored in the record. Formally, if the records(ID1,POS1,SPD1,BT 1) . . . (IDn,POSn,SPDn,BTn)are being aggregated, anddi is the estimated distancebetween the current vehicle and the vehicle withIDi, theaggregated record will be

({ID1, . . . , IDn},POSa,SPDa,BT a)

where

BT a = min{BT 1, . . . ,BTn},

POSa =n∑

i=1

POS i/di, and

SPDa =n∑

i=1

SPD i/di.

We realize that storing the minimum broadcast time—asopposed to storing the maximum or average—is advanta-geous, in that it allows the information about the vehiclewhich corresponds to the minimum broadcast time value tobe updated as soon as a fresher record is heard about thatvehicle.

According to the way the aggregated fields are calcu-lated, the aggregated records should have close values for

2We are developing other aggregation formats for the TrafficView sys-tem.

5

0

5

10

15

20

25

30

35

40

45

1000 2000 3000 4000

Ave

rage

Rec

ord

Late

ncy

(m)

Distance Between Sender and Receiver (m)

Figure 4. Average record delay based on thedistance between the sender and receiver

their POS, SPD, and BT fields to reduce the error result-ing from the aggregation. Our preliminary experiment re-sults showed (as expected) that if two vehicles are close toeach other, their broadcast records will arrive at a specificreceiver at nearly the same time. Figure4 shows the averagedifference between the record broadcast time and its receipttime, and the distance between the sender and the receiver,for a simulation of 550 total nodes, moving with an averagespeed of 30m/s, using the simple diffusion mechanism forinformation exchange. As a result, if two records have closePOS values, they are expected to have close BT values.

At the same time, if the difference between the speed oftwo vehicles that are close to each other is big, their distancewill grow in a short time as well. Keeping in mind that thebroadcast period is in the order of seconds, we can ignorethe speed difference among the aggregated records, becausethe record will be updated with the new up-to-date positioninformation as soon as new broadcast messages are heard.As a conclusion, the records are selected for aggregationbased of their relative distances only. To achieve this in anefficient manner, records are kept sorted on the estimatedrelative distance of the current vehicle to the correspond-ing vehicles. This way, we limit the search for records tocombine only to consecutive records in the sorted list.

Whenever a node receives a record containing informa-tion about some vehicles, it first checks the information inthat record against the validated records it has. If the recordcontains information about some vehicles about which thenode already knows, it performs the following:

1. If the broadcast time of the records is greater than thebroadcast time of the stored record, it means the newrecord is fresher, and therefore the node removes thecorresponding vehicle ID from its stored record,

2. Otherwise, the new record contains older information,and hence the node removes the corresponding vehicleID from the received record.

ID relative distance speed broadcast time1 40 30 9.802 65 25 9.753 120 35 9.004 140 20 8.805 250 30 6.906 280 15 6.757 600 30 4.25

Table 1. Sample records used to illustrate dif-ferent aggregation algorithms

In TrafficView, vehicles apply the aggregation procedureon the records in the validated dataset each broadcast pe-riod to prepare the broadcast packet. Our preliminary exper-minets showed that the effect of each vehicle either replac-ing its current validated records with the aggregated version,or maintainting the original records in its validated dataset,on the quality of the information gained by other vehicles onthe road, is almost identical; the only difference being theimposed overhead in the next broadcast period. We there-fore decided to replace the validated dataset records withthe new aggregated version during each broadcast period inorder to reduce the overall aggregation overhead.

In the following subsections we describe different algo-rithms to select the aggregated records. Table1 lists a setof records that will be used for the illustration of the algo-rithms.

5.2 Ratio-based Algorithm

The algorithm divides the road in front of the vehicle toa number of regions (ri). For each region, an aggregationratio (ai) is assigned. The aggregation ratio is defined asthe inverse of the number of individual records that wouldbe aggregated in a single record. Each region is assigneda portion (pi where0 < pi ≤ 1) of the remaining freespace in the broadcast message. The aggregation ratios andregion portion values are assigned according to the impor-tance of the regions and how accurate the broadcast infor-mation about the vehicles in that region is needed to be. Forexample, assigning decreasing values to the aggregation ra-tios and equal values to portion parameters will result inbroadcasting less accurate information about regions thatare farther away from the current vehicle, since for thoseregions, each individual record will represent large numberof aggregated vehicles (records).

Given the aggregation ratios, portion values, and num-ber of regions, the algorithm calculate the region boundaries([bi, bi+1[) as shown in Algorithm1.By knowing the num-ber of current records in the validated dataset that lie within

6

Algorithm 1: RATIO-BASED ALGORITHM()

I NPUT :Sorted list of validated recordsn : number of regions(r1 . . . rn)a1 . . . an : aggregation ratiosp1 . . . pn : message portion values

OUTPUT :th1 . . . thn : merging thresholdsb1 . . . bn : region boundaries

VARIABLES :R : size of the remaining space in the broadcast

messageL : number of records left in the list of recordsoptimum: optimum aggregation ratiodmax : distance of the farthest vehicle the current

vehicle knows aboutli : number of records in regioni

ALGORITHM :mainInitialize biandthi to 0 for all ib0 ← dmax

R ← size of broadcast messageL ← number of records in the input listfor each regionri

do

optimum← R

(average record size)×L

if optimum≥ 1then return

if optimum≥ ai

then

bi ← dmax

thi ← bi−bi−1

L×optimumreturn

li ← number of records that fit inR×pi

aibytes

L ← L− liif li = 0

then{

bi−1 ← dmax

returnbi ← relative distance of the last record fitthi ← bi−bi−1

li×ai

R ← R−R× pi

ID(s) relative distance speed broadcast time1, 2, 3 61.58 29.30 9.004, 5, 6 203.88 21.73 6.75

7 600 30 4.25

Table 2. Records sent out by the Ration-basedalgorithm

the boundaries of each region and the corresponding freespace in the broadcast packet, the algorithm calculates themerging threshold (thi) corresponding to each region. Anyset of consecutive records in regionri will be aggregated ina single record if the the relative distance (iny direction)between the first and the last record is less than the corre-sponding merge thresholdthi.

As shown in Algorithm1, the algorithm will not over-aggregate the records. This is guaranteed by calculating theoptimum aggregation ratio at the beginning of the loop foreach region. This aggregation ratio is the value needed tofit the rest of the records in the message free space. If thisratio is greater than or equal to one, the algorithm termi-nates since no aggregation is needed. Otherwise, the opti-mum value and the aggregation ratio of the current regionare compared and the maximum among these two is used.

After the algorithm aggregates the records, it starts writ-ing the record contents to the broadcast message until nofree space is left. There is no guarantee to write all therecord contents in the message. The tradeoff between thenumber of records written and the accuracy of the recordsis governed by the parameter values used in the algorithm.

As an example, assume a vehicle withID = 0, using thisalgorithm, divides the road into two regions, and the corre-sponding parameter values area1 = 0.5 with p1 = 0.5and a2 = 0.25 with p2 = 0.5. If the algorithm is ap-plied to the records listed in Table1, if will calculate thefollowing parameters:b1 = 120, th1 = 80, b2 = 600, andth2 = 261.82. Note thatth2 is calculated using the optimalaggregation ratio0.46 instead of the input value,0.25.

After calculating the parameters, in the first region, thealgorithm first combines records 1 and 2, and then combinesthe result with record 3. Likewise, the records 4, 5, and 6are combined in the second region. The records sent outby the algorithm are shown in Table2. Record 7 is sentunaggregated. Note that the speeds are calculated as theweighted average in a single value while the broadcast timesare calculated as the minimum value.

5.3 Cost-based Aggregation

In the Ratio-based algorithm, records that satisfy themerging threshold (thi) are “blindly” combined without

7

Algorithm 2: COST-BASED AGGREGATION()

I NPUT :Sorted list of validated recordscost-thresholdn : number of regions(r1 . . . rn)a1 . . . an : aggregation ratiosp1 . . . pn : message portion values

VARIABLES :R : size of the remaining space in the broadcast messageL : number of records left in the list of recordsoptimum: optimum aggregation ratioli : number of records in regioni

ALGORITHM :mainR ← size of broadcast messageL ← number of records in the input listfor each regionri

do

optimum← R

(average record size)×L

if optimum≥ 1then return

ai ← max(optimum, ai)goal← ai × Lwhile L > goal

do

c ← minimum cost of merging twoconsecutive records in the remainingrecords set

if c > cost-thresholdthen return

Merge the two records corresponding to theminimum cost

L ← L− 1li ← number of records that fit inR× pibytesR ← R− size of theli records

considering the cost of the aggregation. In contrast, theCost-based algorithm assigns a cost for aggregating eachpair of records, and whenever it needs to aggregate tworecords, the two that correspond to the minimum cost arechosen. Assume two records storing aggregated informa-tion abouts1 and s2 vehicles, with a relative distance ofd1 andd2, respectively. The cost of aggregating the tworecords is calculated as follow:

cost =|d1 − da| × s1 + |d2 − da| × s2

da,

whereda is the relative distance of the aggregated group ofvehicles. This formula is calculated such that it:

1. assigns a high cost for the vehicles that are relativelyclose to the current vehicle (1/da),

2. tries to minimize the error introduced during the merg-ing (|di − da|), and

3. minimizes the number of vehicles affected by the ag-gregation (si).

The details of the algorithm are shown in Algorithm2.The aggregation ratios and message portion values are theinputs to the algorithm. For each aggregation ratio and thecorresponding portion value, the algorithm starts by contin-uously selecting the two records that result in the minimumcost, and aggregating them until the number of records isreduced to the value needed by the factor of the aggregationratio. Afterwards, it writes the contents of the first recordsin the sorted list to the beginning of the message until theyfill the space allocated according to the corresponding por-tion value. In the next iteration, the same procedure of ag-gregation and writing is applied on the rest of the recordsthat are not written yet. The aggregation ratios in each it-eration is compared with the optimum aggregation ratio toavoid over-aggregation.

A problem that might happen is that as the algorithm pro-ceeds, the number of records left decreases, and the distancebetween any two consecutive records increases. Hencethere is a risk of combining two records that correspond tovehicles that are very far from each other. To avoid this, af-ter the cost is calculate, the algorithm terminates whenevercost is greater than a threshold (cost-threshold.)

As an example, assume vehicle withID = 0 intends touse this algorithm havinga1 = a2 = 0.5, p1 = p2 = 0.5,andcost-threshold= 0.9. During the first iteration (a1) itfirst aggregates records 5 and 6 (cost = 0.11,) then 3 and 4(cost = 0.15,) and finally 1 and 2 (cost = 0.50.) In the sec-ond phase (a2,) the minimum cost is 1.22, which is greaterthan the cost threshold, therefore the algorithm terminates.Table3 lists the records that are sent out by vehicle0 andthe corresponding fields. In this case, vehicle0 cannot fitrecord 7 in its message.

8

ID(s) relative distance speed broadcast time1, 2 49.52 27.84 9.753, 4 129.23 27.80 8.805, 6 264.15 22.72 6.75

Table 3. Records sent out by the Cost-basedalgorithm

5.4 Information Aging

The records stored in both the validated and non-validated datasets, must be examined to verify that they re-flect the current status of the road and eliminate the out-dated (old) information. For example, vehicles included inthe validated dataset might have exited the road. Moreover,new received records (non-validated) might contain inaccu-rate information due to the frequent changes in speed of thecorresponding vehicles and/or aggregation mechanisms ap-plied on the data in relaying nodes.

The problems here are how is the value of the informa-tion in a broadcast message is calculated, and how can a bal-ance between knowing inaccurate information about a vehi-cle and knowing nothing about it be achieved. In general, ifthe cost of knowing inaccurate information about vehiclejthat is at a relative distance ofd is a functionc1(j, d), andthe cost of having no information aboutj is another func-tion c2(j, d), the information should be accepted and storedif c1(j, d) < c2(j, d), otherwise it should be dropped. Un-fortunately, it is not clear how to assign values to these twofunctions.

To solve this problem, TrafficView exploits two agingmechanisms: The first mechanism associates a timer witheach record added to the validated dataset. This timer is re-set each time the record is updated due to a broadcast mes-sage. If the timer is expired, the record is dropped. The sec-ond mechanism, which we call Receive-aging, deals withnewly received records via broadcast messages. Whenevera new record is received, the expected latency in receivingthe record is calculated and compared to the actual latency(the difference between the receive time and the BT field.)If the difference between these two is lower than a thresh-old, it is stored, otherwise, it is considered out-of-date, andis ignored.

Formally, assume node2 receives a record about vehicle1 at timet. Looking at the record contents, node2 extractsthe timeBT 1 at which the record was first broadcast, andvehicle1’s positionPOS1 at that time. Knowning its ownpositionPOS , node2 estimates its positionPOS 2 at timeBT 1 as

POS 2 = POS − v2 × (t− BT 1),

0

1000

2000

3000

4000

5000

6000

7000

8000

0 1000 2000 3000 4000 5000 6000 7000 8000

Ave

rage

est

imat

ion

erro

r (m

)

Distance between sender and receiver (m)

Usigng receive-agingWithout receive-aging

Figure 5. Effect of Receive-aging: average po-sition estimation error in to simulations, onewith Receive-aging enabled, and the otherwithout that mechanism

wherev2 denotes node2’s speed which we assume, withno loss of generality, to be fixed during the time period[BT1, t]. Node2 then calculates the expected delay in re-ceiving the record as:

delay =|POS1 − POS 2||r/p + v2| .

where r is the wireless transmission range, andp is thebroadcast period.r/p is the approximate propagation speedof the information between the vehicles. This record is ac-cepted by node2 only if

|t− BT 1| ≤ δ1 + (1 + δ2)× delay ,

whereδ1 andδ2 are acceptance thresholds.To validate the effectiveness of the Receive-aging mech-

anism, we ran two simulations with 870 total nodes movingwith an average speed of 30m/s. In the first run, the nodeswere using this mechanism withδ1 = 6.0 andδ2 = 0.3,whereas in the second, it was disabled. Figure5 presentsaverage estimation error of the position of the vehicles inthe two runs. As the figure shows, when Receive-aging isnot used, the estimation error for vehicles that are at far dis-tance is huge. In contrast, using this mechanism has reducedthe average error to a small value.

6 Performance Evaluation

We have implemented the algorithms and have run ns-2simulations to compare the performance of different algo-rithms. In this section, we present the experiments, and thecorresponding results.

6.1 Scenario Generator

Modeling road traffic is a research topic about which alot of work has been done. For example CORSIM [6] is

9

a microscopic traffic simulator developed by The FederalHighway Administration. Unfortunately, none of the trafficmodeler tools are freely available to public. We have there-fore developed our own scenario generator tool based on“setdest”—a generator tool for random-way point mobilitymodel, developed at Carnegie Mellon.

The scenario generator accepts as parameters simulationtime, length of the road, average speed of the nodes, numberof lanes on the road, and the average gap length betweenvehicles. It uses a simplified traffic model as follows:

• Entries and Exits:The entries and exits are evenly dis-tributed along the road each 1000 meters. Vehiclesmay enter the road at each entry except the last oneand leave at any consecutive exit. Vehicles enter theroad at the front-end entry with a probability of 0.7,and at side entries with a probability of 0.3.

• Speed Changes:To model the changes to the speed ofa node, the road between the entry point and exit pointof a node is divided into regions of 50 meters, and aconstant speed of max speed× (0.75 + rand(−2, 2)×0.125) is used for each region, where rand(a, b) returnsa uniformly distributed random integer betweena andb.

• Changing Lanes:Vehicles can change their lanes withno dependence on other vehicles. The probability ofstaying on the same lane is 0.6 whereas the probabilityof changing to the right or left lane is 0.2. If a nodeis on the leftmost (rightmost) lane, the probability ofchanging to the left (right) lane is 0.0.

• Vehicle Density:The density of vehicles is an impor-tant factor because it determines the number of neigh-boring nodes in the transmission range of a vehicle,which has a great impact on the transmission delay andavailable bandwidth of the network. The scenario gen-erator initially puts

road-length× number of lanesaverage gap

activenodes, evenly distributed, on the road. Once avehicle leaves the road at one of the exits, it is deacti-vated, and a new node is added (activated) to the roadrandomly. As soon as a node is deactivated, it will nolonger affect our metric calculations introduced in thesection.

Figure6 shows the histogram of the average speed andnumber of lane changes per minute for a scenario generatewith average speed = 30m, and average gap = 100. Thegraphs show the percentage of vehicles that have that aver-age speed and average number of lane changes per minute,

respectively. A segment of a road in an example scenariogenerated by the tool is shown in Figure7. The road, alongwhich 11 nodes are moving, has three exits at each side.

For all the simulations in this paper, we fixed the lengthof the road to be 15,000 meters with 4 lanes. We used802.11b (with a data transmission rate of 11Mb) as thewireless media with a transmission range of 250m. Dur-ing a simulation, nodes broadcast messages periodically.The broadcast period is selected uniformly from[1.75, 2.25]seconds, and each node recalculates the next broadcast pe-riod after the current broadcast. For all the simulation runs,we use broadcast messages of size 2312 (the maximum pay-load size of 802.11b standards) and we fix the simulationtime to 300 seconds.

6.2 Algorithms and Metrics

We implemented two simple algorithms in addition tothe ones introduced in Section5 for comparison purposes:non-aggregation and brute-force cost-based. In the non-aggregation method, no aggregation is performed and eachnode broadcasts only the first records in its validated datasetthat fit in one broadcast message. In the brute-force cost-based algorithm, the node keeps aggregating its records us-ing the same technique introduced in the Cost-based algo-rithm, until it can fit all the current record contentss in onebroadcast message.

During the simulation, each node periodically broadcaststhe information it has about other vehicles. Upon receiptof a broadcast message, a node updates its datasets accord-ingly.

We will use the following metrics and graphs to assessthe performance of the different algorithms:

• Accuracy: The road in front of each vehicle is dividedinto regions of 500 meters long, and the average errorin estimating the position of vehicles in each region iscalculated. In the accuracy graphs, the average estima-tion error for each region is shown, averaged over allthe nodes during the corresponding simulation.

• Visibility: We define the visibility of a specific vehicleas theaveragerelative distance to the vehicles it knowsabout. A point(d, p) on a visibility graph means thatp% of the vehicles have had a visibility ofd meters ormore.

• Knowledge Percentage: The road in front of each ve-hicle is divided into regions of 200 meters long. Foreach region, the percentage of the vehicles in that re-gion about which the current node knows, is defined asthe knowledge percentage of that node for that region.The knowledge percentage graph presents the knowl-edge percentage for each region, averaged over all thenodes during a simulation run.

10

14

16

18

20

22

24

26

28

15 20 25 30 35 40 45

Per

cent

age

of c

ars

Average speed

05

1015202530354045

-1 0 1 2 3 4 5 6

Per

cent

age

of c

ars

Avg # of lane change/minute

Figure 6. Sample histograms of average speed(left) and average number of lane changes perminute (right) in a scenario generated by the sce-nario generator tool

exits

exits

Figure 7. A segment of a road in an example sce-nario generated by the scenario generator

Name a1 a2 a3 p1 p2 p3

param1 0.5 0.25 0.17 0.5 0.5 0.5param2 0.75 0.5 0.25 0.5 0.5 0.5param3 0.5 0.25 0.17 0.4 0.6 0.8param4 0.5 0.25 0.17 0.3 0.43 0.75

Table 4. Parameter settings for different runsof the Ratio-based and Cost-based aggrega-tion algorithms

6.3 Aggregation Parameters

We ran different simulations to select the suitable val-ues for the parameters of the Ratio-based and Cost-basedalgorithms. Total number of nodes in all of these simula-tions was 960. The suitable set of values are used in thesimulations run to compare the performance of different al-gorithms.

For these two algorithms, the maximum number of re-gions in front of each node is four. The first three regionsare defined by parametersa1, a2, a3, p1, p2 andp3. Thefourth region is defined dynamically by the remaining avail-able space in the outgoing message and the remaining set ofrecords that each node has.

Table4 lists the parameters used in different runs of thealgorithms. The way these parameters are selected is to firstrun the algorithm with param1, and param2 to select thebetterai values and then fixais and run with param3 andparam4 to choosepi values. The incentive is to selectaisas small as possible to achieve as large visibility as possiblewhile maintaining a good accuracy for the closer vehicles.

In param3, we allocate0.4, (1 − 0.4) × 0.6 = 0.36 and0.192 of the broadcast message to the first three regions, re-spectively, hence leaving only0.048 (×2312 = 111 bytes)of the message to the rest of the records. In contrast, param4allocates approximately0.3 of the message to each of the

0

10

20

30

40

50

60

70

80

90

100

0 2000 4000 6000 8000 10000 12000

Per

cent

age

(%)

Distance (m)

param1param2param3param4

Figure 8. Visibility graphs for different runs ofthe Ratio-based algorithm

first three regions and leaves0.1 of the space to the remain-ing records. The reason we started with theai values is thatthey have a larger effect on the performance of the aggrega-tion algorithms than the effect ofpi parameters.

Figure8 shows the visibility graph for different runs ofthe Ratio-based algorithm. We found out that param1 set-tings give a higher accuracy while maintaining a good vis-ibility. We therefore use param1 values to set the Ratio-based parameters in the rest of the simulation runs.

On the other hand, we noticed that using param4 gives ahigher accuracy among the other settings for the Cost-basedaggregation algorithm while maintaining a good visibilityas shown in Figure9. We therefore use the values of param4for in the rest of the simulation runs for the Cost-based al-gorithm.

For the Receive-aging mechanism, we setδ1 to 6.0 andδ2 to 0.3. These values were selected by running the non-aggregation method with different values for these paame-ters, and choosing the ones that resulted in the best visibilitywhile maintaining an acceptable accuracy.

11

0

10

20

30

40

50

60

70

80

90

100

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000

Per

cent

age

(%)

Distance (m)

param1param2param3param4

Figure 9. Visibility graphs for differentruns of the Cost-based algorithm

0

10

20

30

40

50

60

70

80

90

100

0 200 400 600 800 1000 1200 1400

Per

cent

age

(%)

Distance (m)

scen1scen2scen3scen4

Figure 10. Visibility graphs for differentruns of the non-aggregation algorithm

6.4 Results

To compare the performance of different algorithms, weran each algorithm on different scenarios. Table5 lists theparameters of each simulation.

We first look at the effect of the road parameters ondifferent algorithms. Figure10 shows the visibility graphfor runs on different scenarios of the non-aggregation al-gorithm. From the figure, average speed does not have asignificant effect on the performance of the algorithm. Onthe other hand, the average gap, directly effects the perfor-mance: As the gap between vehicles increases, the numberof vehicles scattered over the road decreases. Therefore,

Name Total # of nodes Average speed Average gapscen1 690 10 100scen2 780 20 100scen3 870 30 100scen4 548 40 175

Table 5. Parameters of different simulationsused to compare different algorithms

0

10

20

30

40

50

60

70

80

90

100

0 1000 2000 3000 4000 5000 6000 7000

Per

cent

age

(%)

Distance (m)

scen1scen2scen3scen4

Figure 11. Visibility graphs for different runsof the brute-force algorithm

the broadcast message will contain records about vehiclesin farther distances and that results in increasing the visibil-ity metric.

Figure11 shows the same graph for the brute-force al-gorithm. For this algorithm, as the average speed increases,the rate the vehicles get closer to or depart from each otherincreases. Due to this increase, more number of records getaggregated. With the increase in cars speed, the values ofbroadcast fields (BT ) fields decrease faster and that result ininvalidating records more quickly due to aging mechanisms,and hence the average visibility decreases. Again, increas-ing the gap value increases the vehicles visibility. The otheraggregation mechanisms show a similar behaviour.

We will use the results of running the aggregation algo-rithms using scenario scen3 to compare their performance,becasue it reveals the behavior of the algorithms moreclearly.

Figure12 shows the visibility graph of the different al-gorithms. The Ratio-based algorithm achieved the high-est visibility value. The Cost-based algorithm outperformsthe brute-force algorithm. As mentioned earlier, this is dueto the fact that records are invalidated more quickly in thebrute-force algorithm. The reason the Ratio-based achievesthe highest visibility is that it performs aggregation on allthe vehicles in all the regions while the Cost-based andbrute-force methods have less or no control on selecting theregion where the aggregation is performed. The result isthat the boundaries of the regions generated by Ratio-basedalgorithm cover larger road areas than the other algorithms,and hence it has the highest visibility.

Figures13 and14 present average estimation error andaverage knowledge percentage for different algorithms us-ing scen3. As a result of the Ratio-based mechanism per-forming aggregation on all the regions, its knowledge per-centage about the close and medium-distanced vehicles isless than the other algorithms; its accuracy is also lowerthan the other algorithms.

12

0

10

20

30

40

50

60

70

80

90

100

0 1000 2000 3000 4000 5000 6000

Per

cent

age

(%)

Distance (m)

Non-aggregationRatio-basedCost-basedBrute-force

Figure 12. Visibility graphs for runs of differ-ent algorithms using scenario scen3

0

500

1000

1500

2000

2500

3000

3500

0 2000 4000 6000 8000 10000 12000 14000

Ave

rage

err

or (

m)

Distance (m)

Non-aggregationRatio-basedCost-basedBrute Force

Figure 13. Average position estimation er-ror for runs of different algorithms using thescen3 scenario

0

10

20

30

40

50

60

70

80

90

100

0 2000 4000 6000 8000 10000 12000 14000

Per

cent

age

(%)

Distance (m)

Non-aggregationRatio-basedCost-basedBrute Force

Figure 14. Average knowledge for runs of dif-ferent algorithms using the scen3 scenario

From the above results we conclude that the Ratio-basedalgorithm is more flexible than the other algorithms in thatit provides more control over the tradeoff between the accu-racy and visibility governed by the parameter setting. Forthe other methods, although tuning the parameters is easier,the cost function does not provide the flexibility present inthe Ratio-based algorithm.

7 Related Work

A lot of effort has been put into Inter-Vehicle Communi-cation research in the recent few years. CarNet [12] projectfocuses on how the radio nodes in the vehicles get IP con-nectivity with the help of Grid [9]. A Grid-to-Internet gate-way is setup to route packets between the wireless networkand the Internet. In [14], a wireless traffic light system ispresented. At the intersection, a static control unit peri-odically broadcasts the current light status, location of in-tersection, and a reference point, using which the vehiclesapproaching the intersection can check their relative posi-tion and make a decision accordingly. They also designedcollision warning system [11] in which peer-to-peer beaconmessage exchange is used. An architecture of the vehicu-lar communication is described in [5]. It integrates inter-vehicle communication (IVC) with Vehicle-Roadside Com-munication (VRC), where both moving vehicles and basestations can be peers in the system. The peers are organizedinto Peer Spaces for message exchange, in which floodingis the main method of delivery.

The authors of [13] examine the feasibility of short rangecommunication between fast moving vehicles using Blue-tooth, and a mobile test-bed RUSH has been establishedin [17], composed of the fixed base station and mobile nodeson shuttle buses.

Two delivery modes known as pessimistic and optimisticforwarding are compared in disconnected vehicle networksin [4]. The experiment shows that the average delay inoptimistic delivery is better. The authors of [3] propose a”wait-and-resend” scheme where a mobile node can cachethe message for a while before new neighbors enter its trans-mission range, and [10] proposes an algorithm to dynam-ically modify the trajectories of the intermediate nodes toapproach next available nodes, for relaying the message tothe destination.

8 Conclusions and Future Work

In this paper we introduced the TrafficView system,which is a part of broader project—e-Road—that is stillunder development. The goal of TrafficView is to providethe driver of a vehicle with information about traffic androad conditions. The essence of the system is to gather and

13

disseminate traffic information between the vehicles on theroad. We presented the basic design of the system, and thealgorithms used for data aggregation and information dis-semination using the 802.11b wireless standards.

For future work, we are continuing to work in a numberof different directions. We are experimenting with a linearprogramming model to estimate the aggregation parametersdynamically based on the road condition.

Privacy is an important issue in such a system. Differentprivacy levels should be available from which the driverscan select. One level of privacy could be to completelyhide any information about the vehicle while it continues toparticipate in relaying other vehicles’ information. Anotherlevel is to allow others to gain information about the vehi-cle without being able to identify it. For example, vehicleson the road may know about a group of vehicles, includingthe target one which is located in an area on the road with-out being able to identify the exact location of any vehicleincluding the target.

Security and trust are two other important issues in sucha system. A fraudulent vehicle could disseminate infor-mation about nonexistent vehicles, or broadcast bogus in-formation about existing vehicles. Different mechanismsshould be proposed to prevent this and to identify thosefraudulent vehicles and avoid accepting their packets.

We believe that TrafficView and the e-Road project willgreatly enhance and ease the driving experience. At thesame time, they will encourage and trigger several appli-cations to be built over these systems.

References

[1] http://www.quatech.com

[2] http://www.obddiagnostics.com

[3] L. Briesemeister, G. Hommel, “Role-based multicastin highly mobile but sparsely connected ad hoc net-works,” in First Annual Workshop on Mobile Ad HocNetworking ans Computing, pp. 45–50, Aug. 2000.

[4] Z. D. Chen, HT Kung, D. Vlah, “Ad Hoc Relay Wire-less Networks over Moving Vehicles on Highways,”in Proceeding of the 2001 ACM ACM InternationalSymposium on Mobile Ad-hoc Networking and Com-puting, pp. 247–250, Oct. 2001.

[5] I. Chisalita, N. Shahmehri, “A peer-to-peer approachto vehicular communication for the support of trafficsafety applications,”5th IEEE Conference on Intelli-gent Transportation Systems, pp. 336–341, Singapore,Sept. 2002.

[6] CORSIM User Manual, Version 1.01, The FederalHighway Administration, US Department of Trans-portation, 1996.

[7] General Motors Collaborative Laboratory websiteavailable online athttp://gm.web.cmu.edu/ .

[8] W. Kellerer, “(Auto)Mobile Communication in a Het-erogeneous and Converged World,”IEEE PersonalCommunications, Vol. 8(6), pp. 41–47, Dec. 2001.

[9] J. Li, J. Jannotti, D. S. J. De Couto, D. R. Karger, R.Morris, “A Scalable Location Service for GeographicAd Hoc Routing”,ACM Mobicom 2000, pp. 120-130,Boston, MA.

[10] Q. Li, D. Rus, “Sending Messages to Mobile Usersin Disconnected Ad-hoc Wireless Networks,” inPro-ceedings of the Sixth Annual International Conferenceon Mobile Computing and Networking, Boston, MA,Aug. 2000.

[11] R. Miller, Q. Huang, “An Adaptive Peer-to-Peer Col-lision Warning System,”IEEE Vehicular TechnologyConference (VTC), Birmingham, AL, May 2002.

[12] R. Morris, J. Jannotti, F. Kaashoek, J. Li, D. Decouto,“CarNet: A Scalable Ad Hoc Wireless Network Sys-tem,” 9th ACM SIGOPS European Workshop, Kold-ing, Denmark, Sept. 2000

[13] P. Murphy, E. Welsh, P. Frantz, “Using Bluetoothfor Short-Term Ad-Hoc Connections Between Mov-ing Vehicles: A Feasibility Study,”IEEE VehicularTechnology Conference (VTC), pp. 414–418, Birming-ham, AL, May 2002.

[14] Q. Huang, R. Miller, “The Design of Reliable Proto-cols for Wireless Traffic Signal Systems”. TechnicalReport WUCS-02-45, Washington University, Depart-ment of Computer Science and Engineering, St. Louis,MO.

[15] M. Satyanarayanan, “Pervasive Computing: Visionand Challenges,”IEEE Personal Communications,Vol. 8(4), pp. 10–17, Aug. 2001.

[16] C. Schwingenschloegl, T. Kosch, “Geocast Enhance-ments for AODV in Vehicular Networks,”ACM Mo-bile Computing and Communications Review, Vol.6(3), pp. 96–97, Jul. 2002.

[17] E. Welsh, P. Murphy, P. Frantz, “A Mobile Testbedfor GPS-Based ITS/IVC and Ad Hoc Routing Experi-mentation,”International Symposium on Wireless Per-sonal Multimedia Communications (WPMC), Hon-olulu, HI, Oct. 2002.

14