Teleport An Open, Accurate and Flexible.pdf

7/27/2019 Teleport An Open, Accurate and Flexible.pdf

1/13

BlahBlahBlahBlah

BlahBlahBlahBlahBlahBlahBlah

Teleport: An Open, Accurate and Flexible

System to Measure Traffic Flow.

Contact: Vikram Srinivasan

email: [email protected]

Team: Avhishek Chatterjee, Samik Datta, Supratim Deb, Sharad Jaiswal

Bell Labs Research, India


2/13

Whitepaper on the Teleport Traffic Sensing System

EXECUTIVE SUMMARY

In this paper we present a low cost sensing infrastructure for urban road traffic monitoring, especially

applicable to emerging markets. The infrastructure relies on the presence of Bluetooth radios on cell

phones and inexpensive sensors by the roadside to provide highly accurate travel time information tocommuters in real time. Our system hits the sweet spot between cost, accuracy and reliability compared

to existing approaches for road traffic monitoring. We have deployed a pilot sensing system in the city

of Mumbai, India for a duration of one month. Through our deployment, we have been able to validate

the key principles behind this approach, understand various deployment challenges and issues that will be

faced by a large scale operational system and mine the gathered data to gain valuable insights about traffic

patterns. We develop algorithms that exploit these patterns to accurately predict travel times. Specifically

our main contributions in this paper are (i) identifying Bluetooth and in general near field communications

as a mechanism to do accurate and low cost sensing of road traffic, (ii) extensive experiments to validate

and characterize the efficacy of Bluetooth as a traffic sensor, (iii) designed and implemented and deployed

a system for large scale sensing of road traffic, (iv) designed approaches to improve estimates in the

presence of insufficient data and (v) developed algorithms to accurately predict traffic up to an hour into

the future.

2


3/13


I. INTRODUCTION

In this paper we present a low-cost, highly-accurate, large-scale sensing system to infer travel times on urban

roads. This is an important and topical problem since a high quality transportation infrastructure and the ability to

move goods and services in a timely and cost-effective manner, plays a critical role in the economic prosperity ofany nation. For example, according to [4], the GDP loss due to traffic-congestion could be up to 6 % in Bangkok,

and around 2 % in Japan, while according to [6] in New York City alone, the annual economic loss due to congestion

is USD 13 billion. Clearly, traffic congestion has an even greater impact in developing countries, where the gap

between the capacity of the existing infrastructure and the needs of the economy is usually the widest.

Congestion reduction can be alleviated in a variety of ways, such as increasing road capacity, improving public

transportation, congestion taxes etc. Each of these methods has its own pros and cons and require government

commitment, significant capital investment and public support to be successful. We argue that in addition to all

these approaches, providing relevant and timely information about traffic conditions to commuters will go a long

way in alleviating congestion and commuter stress. Providing accurate information such as the least congested route

to take, the expected travel time on the route allows commuters to make informed choices about routes, thereby

easing the congestion on the road. In addition archived information on commute times, congestion patterns on

different road stretches etc., can be used by urban planners to make informed decisions such as where to improve

road capacity, on which routes to increase public transport frequency etc. Providing such fine grained informationrequires a large scale traffic sensing infrastructure. However current solutions are extremely expensive or woefully

inaccurate. Our goal in this paper is to design a low cost traffic sensing system especially applicable to emerging

markets.

We believe that a good traffic sensing system for emerging markets should satisfy the following requirements.

1) Accuracy: The system should provide accurate travel-time information, with appropriate confidence intervals

for the estimate.

2) Low-cost and scalability: The cost of the solution (installation and maintenance) is a major design constraint.

In fact, several existing solutions are prohibitively expensive for emerging markets like India, Indonesia etc.

Apart from the initial deployment costs, the costs should not increase with the volume of traffic and number

of users of the traffic information.

3) Robustness to failures: The system should provide graceful loss in performance with the failure of any of its

components.

4) Richness of information: Apart from immediate travel-time information, the system should also have the

ability to predict travel times a few hours in to the future, allow users to explore archived data and ideally

do vehicle classification.

A. Our Approach

In this work we describe a low cost traffic sensor network that meets most of these requirements. Our key idea is

based on the observation that most phones carried by commuters even in emerging markets have short-range radio

interfaces present on the phone. Of these, Bluetooth is the most pervasive (802.11 WiFi could be another option).

Given this, our approach is the following. We place low cost Bluetooth scanners along the road-side - these sensors

have two key capabilities, detecting other Bluetooth devices in the vicinity, and sending the collected data on a

wireless back-haul link to a back-end server.

As vehicles with Bluetooth devices travel by, the Bluetooth scanners placed on the road-side passively detect the

vehicles and take a note of the MAC id (of the Bluetooth interface) and the time(s) of detection of the vehicles.This information is transmitted periodically by the scanner to a back-end server, which, by correlating a MAC id

observed between any two scanners computes the travel time between the points at which the scanners are placed.

By placing such Bluetooth scanners at many points across the city, and correlating their observations, travel time

estimates between any two points in the city can be computed. One crucial advantage of our system is that it

requires no active participation from commuters. They do not need to download any application on to their phones

or incur costs in transmitting positional information.

The cost of the scanner-box will be of the order of USD 100-200 - allowing widespread deployment across

any city. The system has very little privacy related concerns as it is extremely difficult to match the MAC of

3


4/13


the Bluetooth interface of the phone with the identity of the phone user. Also, as we show using our prototype

deployment, the system is capable of providing highly accurate travel-time estimates in real-time with the aid of

data mining and statistical algorithms.

B. Existing solutions and discussion

There exist several alternate approaches to measure road traffic congestion, we now provide a detailed discussionof other efforts towards building a traffic sensing system.

In-road Sensors (e.g., inductive loop sensors, magnetometers, video cameras): In this approach, traffic sensors are

either embedded in the roads, or placed by the road-side. The sensors can accurately classify the vehicles by type,

and detect speeds. Hence these solutions provide both a rich and reliable source of traffic information. However,

there are three important drawbacks. Firstly, the solutions are prohibitively expensive. A reliable loop-detector alone

costs between USD 12,000-15,000, while a traffic video camera costs around USD 16,000 per direction on arterial

roads (including cost of mounting a camera pole). Cost of fiber backhauling from the in-road sensors to a central

location could range from USD 20,000 to USD 100,000 per mile depending on whether new conduits had to be

laid or not [5]. Thus, these solutions are impractical for large scale citywide deployment, especially in developing

countries like India, Brazil, Thailand etc. Secondly, the maintenance and troubleshooting of such sensors can be a

difficult task as it involves human intervention, and possible traffic disruption. Placing redundant sensors for fault-

tolerance may not be feasible due to their prohibitively high cost. Finally, since these sensors are sparsely placed

(due to the high deployment cost), a single faulty sensor in a road-stretch could severely impact the travel-timeestimates on that road.

Using vehicles with GPS-based devices as probes: If a GPS device is present in cars or in phones, the speed of

the vehicle can be obtained from the GPS location data at different points in time. This idea of using cars with

GPS-devices as probes is used by companies such as traffic.com and dash.com. The CarTel [8] project

explores how GPS data can be opportunistically transported to a central server by exploiting wide spread WiFi

deployment in a city. In [9], the authors use GPS based information to estimate traffic conditions on city roads. In

essence they classify traffic between congested and non-congested state. However, GPS-based systems have several

shortcoming in the emerging markets context:

1) Penetration of GPS devices in many emerging markets is extremely low, and only available on a few high-end

phones.

2) Acquiring GPS location information is both a drain on the user phones battery, and on the network resources.

Moreover users incur a cost in relaying their positional information to a central location. This is an issue

in emerging markets where users are highly cost conscious (e.g., the average revenue per user per month inIndia is USD 7, as opposed to USD 50 in developed countries). Alternatives such as opportunistic backhaul

through exposed Wi-Fi hotspots is not feasible in emerging markets where broadband penetration and WiFi

adoption is low.

3) GPS location information tied to an individuals phone has privacy issues.

4) For standard GPS, devices require line-of-sight with satellites, and the system will not work well on roads

with high rise buildings. The efficacy of such a system for good coverage in the city (especially in densely-

built urban neighborhoods) is an issue. AGPS (assisted GPS) based solutions are not yet widely available in

countries like India and require a data connection for AGPS to work. This incurs a higher cost to the end

user.

Cellular triangulation based solutions: Location estimates of mobiles can also be obtained by triangulation of the

cellular signal received at different base stations from the phone. This signal is obtained either when the phone is

actively involved in a call or when the phone provides a location area update (typically of the order of 10 minutes).

To obtain accurate velocity estimates, one needs to triangulate the same phone at two different locations. Such a

solution has been developed by several providers such as TomTom [3] (with an announced partnership with Vodafone

to provide real-time travel time information to commuters), IntelliOne [2] etc. Clearly this approach is extremely low

cost, however, such an approach too has several issues. Studies by the Florida Department of Transportation [12]

concludes that cellular triangulation technology works well only under free flow traffic condition on highways. The

reasons being:

1) The accuracy of the location estimate is 100-300 meters; in dense urban streets, this makes it difficult to

pinpoint the location of a vehicle between parallel streets or at intersections. In emerging markets this is an

especially critical, since there are few highways and commutes are typically done over city roads.

4


5/13


2) Location estimates requires the phone to be active (i.e., in a call). Few people are actively engaged in a call

while driving, especially since it is illegal in several countries. Moreover, to pinpoint the vehicle accurately

in two locations sufficiently far apart (to get a useful travel time estimate) requires the call to last for a

sufficiently long duration of time, which maybe impractical.

3) It creates additional load on the cellular network giving rise to scalability issues.

Other approaches: There are a couple of other notable efforts that use sensors on mobile devices to detectroad-traffic conditions. In the project Nericell [10], the authors have developed a system that uses accelerometer,

microphone, GSM radio, and/or GPS sensors in phones to detect potholes, bumps, braking, and honking. In [7],

the authors have demonstrated a system using accelerometer data along with machine learning techniques, to detect

potholes and road-surface anomalies. This is especially relevant in emerging market scenarios where roads conditions

rapidly deteriorate. The goal of our system is different: to build and deploy a system that is low-cost and that can

provide highly accurate travel-time estimates in real-time.

Near Field Based Approaches: Parallel to our work, very recently, we have found news reports, published in

November 2008, of a study from Intelligent Transportation Systems researchers at Purdue University using Bluetooth

as a traffic sensing mechanism [1]. While the core idea is identical to ours, we are yet to find any public research

report that rigorously evaluates the idea or discusses an end-to-end system architecture and associated research

challenges.

Comparison with other Methods: We now provide (Table I) a side-by-side comparison of our approach vs. the

efforts discussed above, along some metrics that we consider are most relevant. Our solution hits the sweet spotbetween cost, accuracy and usability in emerging markets.

TABLE I

TABLE COMPARING DIFFERENT TRAFFIC SENSING MECHANISMS

Usability GranularitySystem Accuracy Cost time-scale of

in emerging informationmarkets

GPS-based Low-Medium Low Long-term Medium

Cellulartriangulation- Low Low Short-term Medium

basedLoop detectors High High Short-term High

TelePort Medium-High Low Short-term Medium(our approach)

1) Key Contributions: Clearly, there are many challenges that need to be overcome to successfully deploy such

a system. This paper makes the following contributions:

1) To the best of our knowledge, ours is the first work to design and rigorously evaluate a near-field communica-

tions based traffic sensing mechanism using Bluetooth-based sensors. As we will argue, our system is capable

of providing highly-accurate real-time estimates of travel time, has a very low deployment and maintenance

cost, and is robust to failures.

2) We conduct extensive experiments to characterize the efficacy of Bluetooth as a traffic sensing solution.

3) We designed, implemented and deployed (for over a month) a pilot system in the city of Mumbai, India.

4) We present an extensive analysis of the traffic data and observed interesting patterns.

5) We design algorithms that exploit this structure to predict travel time. For the data we collected, our algorithm

significantly outperforms recently proposed algorithms in literature. We provide a novel improvisation of a

well known statistical estimation technique (LMSE) to improve the estimation accuracy of travel time on a

road stretch even when very few Bluetooth devices are present.

5


6/13


I I . PRELIMINARIES AND WORKING PRINCIPLE

We now describe how we use the Bluetooth protocol and Bluetooth based scanners to detect vehicles on the

road. Our system is based on the way Bluetooth functions.

A. Working principle and validation of approach

The TelePort system relies on two key observations: (i) many commuters have Bluetooth enabled cell-phones

because most cell phones (including low-end cell phones costing even less than USD 50) come with Bluetooth, (ii)a Bluetooth device simply performing device discovery in inquiry state can at least detect the presence of other

Bluetooth devices in the vicinity without having to establish a communication between the inquiring device and the

detected device. To this end, the key working principle is following: if a vehicle carrying a Bluetooth device A is

detected by two Bluetooth sensors/scanners placed at the beginning and end of a road-stretch, then the travel-time

on the road stretch can be deduced from the detection times of A.

In the following, we will demonstrate simple experiments to answer the following questions. Specifically, the

experiments are designed to answer the following:

1) If Bluetooth sensor is a Class-I device, i.e., range of 100 m, and that of the Bluetooth enabled cell-phone is

10 m, i.e., Class-II device, then what is the effective distance at which the Bluetooth sensor can detect the

Bluetooth enabled cell-phone? This is important because most Bluetooth enabled cell phones have a 10 m

range and our sensors have a 100 m range.

2) Can static road-side Bluetooth scanners/sensor, with a detection range of 100 m, detect Bluetooth carrying

vehicles traveling at large enough speed?

3) Since the estimated travel time of the vehicle between two Bluetooth sensors will contain errors, how large

can this error be?

4) Are there sufficient number of Bluetooth enabled phones carried by people?

Experiment-1: In the first experiment, we had one class-1 Bluetooth device with a range of 100 m perpetually

running in the inquiry mode 1. We placed a Bluetooth enabled cell phone (that has a Bluetooth device with a range

of 10 m) at varying distances from the class-1 Bluetooth scanner; at each distance, the Bluetooth in the cell-phone

was switched on for a duration of 15 s. We repeated this step multiple times and noted two observables: number

of times the Bluetooth enabled cell-phone was detected, and the average detection time. The first observable was

converted into probabilities. In Table II, we show the result of this simple experiment.

TABLE II

DETECTION RANGE OF A CLASS-1 BLUETOOTH DEVICE

Distance between Probability of Averagethe two devices (m) detection detection time (s)(class-1 and class-2)

50 1.0 2.15

60 0.90 2.05

80 0.65 2.96

100 0.41 3.74

There are two important take away messages from this experiments.

1) Reliable detection range of class-1 Bluetooth devices (range of 100 m) in terms of detecting another class-2

device (range of 10 m), is more than 60 m even with low cost (USD 6) Frontech dongles. While this relies

critically on the manufacturer of the Bluetooth device, we have made this observation for Bluetooth devices

of several makes2.

2) The average detection time sheds light on the speed at which a vehicle could be traveling so that it can be

detected. For example, suppose we have a car traveling at 40 km/hr (typical urban speeds in Indian cities),

1This was done using software scanner module written over the Linux BlueZ stack (on laptops with Frontech Bluetooth dongles). The scanneralso noted the system times when other Bluetooth devices were detected

2The reliable detection range was as high as 85 m with USD50 Linksys Bluetooth dongles.

6


7/13


i.e., 11 m/s. Now, the time taken for the car to travel 120 m (total detection range) is roughly 11 s. This 11 s

duration is 5.5 times the average detection time when the two devices are placed 60 m apart.

Experiment-2: This experiment was performed with a moving car on two city roads in India - one congested

and the other lightly loaded. In each city road, we had two Bluetooth sensors (class-1 Bluetooth sensors with range

of 100 m), held by two people (say, person-A and person-B), standing at least 0.6 Km apart on the side of the road

stretch. For each of the two roads, the car drove past them 5 times: the velocity was around 60-80 km/hr on thelightly loaded road, and it was around 10-25 km/hr on the congested road. The detection times were measured in

two ways:

1) Manual measurement of travel-time: When the car goes past, say person-A, he notes down the system time

at which the car went past him. Person B too does the same thing and the difference in the time noted by A

and B is the actual (manually observed) travel time.

2) TelePort travel-time: The sensors perform continuous Bluetooth device discovery and notes the system time

when another Bluetooth device is detected. Since a Bluetooth device can be detected multiple times while

it is in the vicinity of the Bluetooth sensor, for each run, we compute an average of all the detection times

for each MAC id that is detected. The difference between average detction times at the two sensors is the

estimated travel time.

After measuring the travel-times in these two manners, we then noted the difference between the manual

measurement of travel time and the average travel time produced by the system. This difference gives an estimate

of the error in travel time produced by the system; this error could result from the randomness of the location of thecar within the detection range when it is detected, and also the multiple detections as a car goes past. Furthermore,

this experiment also demonstrates the efficiency of detecting a moving vehicle by a road-side Bluetooth sensor.

TABLE III

DETECTION TIME STATISTICS OF THE CAR AT TWO SENSORS SEPARATED BY 0.6 KM

Statistics of Error on Error ondifference between congested lightly loadedmanual and system road road

measurement of travel-time (in sec) (in sec)

Maximum 9 7

Minimum 2 1

Average 5.4 3.4

In Table III, we show the difference between manually observed travel-times and the travel-times computed by

the TelePort system. There are two take away messages from this simple experiment.

1) Note that the error in travel-time is 9 s in the worst case, and this error does not increase with the distance

between the two sensors. Hence, the error, as a percentage of the actual travel time, is very small for individual

vehicles and is typically less than 5% for sensors placed 2 km apart.

2) Also, moving vehicles can be detected with a reasonably high probability by static Bluetooth sensors. In our

experiment, the class-1 Bluetooth dongle with both persosns detected the moving vehicle 10 out of 10 times.

Experiment-3: An important question to answer is whether there are a sufficient number of commuters with

Bluetooth enabled cell phones and whether Bluetooth sensors can detect vehicles in real world conditions. To verify

this, we conducted at least 6 sets of experiments across different road stretches in the city of Bangalore, India.The sensors were placed inside two cars parked on the side of the road and separated by at least one kilometer.

The road stretch in-between had few and (lightly trafficked) branch offs from the road. We report results from

an experiment from 10AM to 12:30PM on June 24 2008, a Tuesday. The sensors discovered 207 and 185 unique

MAC ids respectively. In other words, an average of 1.4 and 1.26 MAC ids respectively per minute. The number of

common MAC ids discovered between the two sensors was 103. We observed similar results from experiments in

other parts of Bangalore. As we will demonstrate later in the paper, these number of samples is sufficient to provide

accurate average travel time estimates (particularly for time scales over which traffic patterns change significantly).

Experiment-4: Dublin City Our colleagues in Bell Labs Ireland, performed two sets of experiments in the city

of Dublin. The first was on a busy city street to see if there were sufficient number of people carrying Bluetooth

7


8/13


Fig. 1. TelePort system architecture

phones in Dublin. The second was on the M50 highway to see if Teleport was effective at detecting vehicles

traveling at high speeds (80-120 Kmph).

Case-1: Dublin city - Snugborough Road: The measurements were performed on Snugborough road, near the

National Aquatic Centre Junction from 1630-1505 hours on a Monday. Two sensors were placed on either side of

the junction. A total of 659 vehicles traveled through the junction. The sensors detected a total of 322 Bluetooth

devices were detected, i.e. at least 48.8% of the vehicles had a Bluetooth device in them.

Case-2: Dublin City - M50: The next set of experiments were performed at the M50 Footbridge, Talbot Courtat 1645-1700 hrs on a Thursday evening. Traffic was free flowing and between 80-120 Kmph. A total 2300 vehicles

traversed the sensor location. A total of 981 unique MAC IDs were detected, i.e., around 48%. This shows that

Teleport is an effective traffic monitoring tool for highways also.

III. SYSTEM ARCHITECTURE

In this section, we will describe the hardware and software architecture of TelePort and our prototype deployment

in Mumbai, India.

As depicted in Fig. 1, the TelePort system has three main components: roadside sensors, a central back-end

server, and a query processing engine. We start with a step by step description of how these components function

in the TelePort system:

1) A commuter with a Bluetooth enabled cell-phone drives along a road stretch covered by TelePort sensors;

2) The sensors detect the MAC id of the Bluetooth device and note the time of detection ;

3) At periodic intervals, each sensor transmits a collection of Bluetooth MAC ids and detection times to the

central server.

4) The central server collects the data, cleanses it (details provided later), and saves it into a database.

5) A user queries (either through the web, or as a SMS query) for the travel-time between point A and point B.

The query reaches the query processing engine which passes it on the central back-end data server.

6) The back-end server correlates the MAC ids and their detection times at different sensors to compute an

estimate of the travel time between point A and point B. The resolved query is relayed back to the query

processing engine which in turn returns the estimate to the user.

8


9/13


We now discuss the architectural features of each of the above mentioned elements of our system, the specific

details of our deployed prototype system.

A. Components of the System

The major components of our system are:

Roadside Sensors: The TelePort sensors are inexpensive single-board computer (SBC) based devices, that run Linuxand have good peripheral support. Existing commercial SBCs are relatively low-cost (USD 100-300), rugged, and

support peripherals such as wireless data cards, and Bluetooth radios. In future, when such systems are customized

for our purposes the wireless peripheral cards will be integrated into the main-board. The software on the sensor-

boxes scans for Bluetooth devices in the vicinity, summarizes the collected data, and through a wireless back-haul

(2.5G, 3G or WiMax) relays it back to the sensor data aggregator. For each vehicle detected, we only store the MAC

id (6 bytes) and average detection time (4 bytes). Thus the total volume of data generated by these sensors over the

course of a day is small. For example, assuming a sensor detects 10 vehicles/min, over a typical 10 hour duration

(of interest to commuters), the total data volume produced is only 3.6MB, and over a period of one month only

108MB. This translates to a data rate requirement of less than 2kBps. Furthermore with appropriate compression,

the total volume of data transferred can be shrunk significantly.

Central Backend Server: The central backend server has four functional units:

Sensor data aggregator: This module receives data from all the sensors (over a TCP socket), and passes it to the

data-cleanser (either via shared memory or temporary data base). The raw sensor data is saved as a 3-tuple of the

form (sensor id, MAC id, detection time).

Data cleanser: This module cleanses the raw sensor data (e.g. pedestrian traffic, vehicles that take an unusually

long time due to possible halts etc.) using simple data mining mining techniques.

Segment time computer: Given the cleansed data, this module computes a first-cut travel time estimate on each

road-segment (a road segment is the length of the road between two successive sensors), and maintains a moving

average of the travel-time along different road-segments (other averaging techniques can be used as well).

Database: A mySQL database with tables that store (for each road segment) the real-time travel times per segment,

as well as a summary of the historical travel-times. The segment time computer is responsible for filling the real-

time estimates, and the route computation engine is responsible for filling in the table for summarized historical data.

Route Computation Engine: This is the most important module in the system and implements several algorithmic

innovations. This module takes queries from the query processing engine, interacts with the database and computes

the travel time between the queried source and destination points. To answer a query satisfactorily, this module has

to perform two key functions:

1) Through statistical techniques refine the travel-time estimates of any segment by capturing correlation between

different segments of the road.

2) Use statistical techniques to predict travel time in the future, i.e., answer queries like what is the travel time

between A and B 3 hours from now.

In a later section, we will outline some of the algorithms we have developed to implement the above.

Query Processing Engine: The query processing engine processes queries from users (that arrive either via SMS,

a web interface, or possibly a voice gateway) parses, and relays the query to the route computation engine in asuitable format.

B. Prototype Deployment

We have deployed a prototype TelePort system in the city of Mumbai, that comprises 4 Bluetooth sensors along

a 4 km road stretch of road (Fig 2). The system was operational from December 13 2008 to January 13 2009. There

were almost no branch-offs or turns on this stretch of road and every car was most likely to traverse the entire 4 Km

stretch. The first sensor was placed at a security booth at the gate of a large industrial complex. The security booth

is set back from the road by at least 60 meters. The middle two sensors were placed in shops adjacent to the road.

9


10/13


Fig. 2. Map showing the locations of our sensors in Mumbai

Each shop was at least 10 meters from the road, with obstacles such as parked cars, customers and pedestrians. The

location of the second sensor was a few meters from a flyover and typically had smooth flowing traffic going past

it. The third sensor was located about 50 meters before a traffic signal. The last sensor was placed at a traffic police

booth located adjacent to a road intersection with a traffic signal 3. The distance between the first and second sensor

was 2Km, and the distance between all other adjacent sensors was 1Km. This road stretch is a major thoroughfare

in Mumbai, with most vehicles being cars, buses and a few trucks. Very few motorbikes and bicycles ply on this

road.

IV. OBSERVATIONS FROM PILOT DEPLOYMENT IN MUMBAI

In this section we analyze the data obtained from the deployment in Mumbai and discuss observations towards i)

better deployment strategies to increase the reliability of the system and ii) the feasibility of modeling travel time

evolution. For the rest of the paper, we refer to the road stretch between Sensor 1 (at the industrial complex) and

Sensor 2 (at shop I ) as Link 1, between Sensor 2 and Sensor 3 (at shop II ) as Link 2 and the stretch between

Sensor 3 and Sensor 4 (at the traffic police booth) as Link 3.

Sensor 1 was located at a distance of 60 meters from the road-side and we obtained very little data from this

sensor - mostly, only the traffic going in and out of the complex (a company interested in this solution requested ademo and insisted that one sensor be placed at the security booth at the entrance to its office complex). Therefore

we limit the results reported in this paper to data from from Sensors 2, 3 and 4 (and Links 2 and 3). Also, we only

consider data collected between 11AM and 7PM everyday. This was because at other times we are not assured of

obtaining data reliably (shops may not be open, and hence the sensors will not be operational). We compute travel

times for every link over t minute measurement intervals by averaging over the travel times for the common IDs

detected on the link. In this paper we use values of t = 30 and t = 10 minutes.

3Due permissions were taken from the Commissioner of Police for Traffic in the city

10


11/13


A. Basic Observations

Measurements of number of detected Bluetooth devices:

Figure 3 plots the number of unique MAC ids detected by Sensors 2, 3 and 4, over each 30 minute interval in

a day (from 11AM to 7PM) on December 18th 2008. We observe that Sensor 4, ideally placed at a traffic signal,

detects as many as 70 MAC ids in a 30 minute interval and at least 30 devices in any 30 minute interval 4 . Sensors

2 and 3 (placed in shops) detect fewer - as many as 35 MAC ids, and there was only one interval in which noMAC ids were detected. This implies the following. First, there is a sufficient density of Bluetooth based phones in

this stretch of road (as captured by a well-placed sensor). Second, even for less than desirable deployments (with

obstructions etc.) the Bluetooth based sensor can detect several passing vehicles. Third, a good deployment strategy

would be to place sensors at traffic signals to capture as many vehicles as possible.

(a) Sensor 2 (b) Sensor 3 (c) Sensor 4

Fig. 3. Number of Bluetooth MAC ids over each 30 minute interval from 11AM to 7PM on December 18th 2008.

Next, in Figure 4, we consider the number of common MAC ids detected in each 30 minute interval between the

sensors on Link 2 and Link 3. We observe that on average about 6 common IDs are detected in every measurementinterval. Typically, our sensors detected enough Bluetooth devices to provide sufficient statistic. We also note that,

in reality, the reliability of our sensors can be substantially improved by two means, namely, by placing the sensors

intelligently at road intersections, and by employing sophisticated statistical algorithms that we developed (ths

algorithm is patent pending). The improvement obtained by using our algorithm is described in Section ??.

Patterns in measured travel times: In Figure 5 we plot the travel time evolution on Link 2 for weekdays between

16th and 25th December 2008. We are interested in observing patterns of traffic behavior. Our intuition is simple,

people are creatures of habit and based on work hours, school hours etc., there is a typical travel time observed at

any given time of the day, and across days. However, visually, the plot reveals no discernible patterns and hence, we

use statistical tools to further examine the data. However by using sophisticated statistical tools and techniques such

as weak-sense cyclostationarity and fourier series analysis, we were able to establish that the travel time data does

have several patterns in a statistical sense. Indeed we exploit these patterns to develop algorithms for predicting

travel times in the future.

V. TOWARDS LARGE SCALE DEPLOYMENT

Our trial deployment in Mumbai coupled with several experiments in Bangalore has clearly demonstrated the

feasibility of using Bluetooth as a traffic sensing mechanism. We are currently in the process of designing a system

for large scale city wide deployment. Such a system involves several thousands of sensors deployed over a large

4Note that we are reporting cleansed data, and have already eliminated pedestrian traffic etc.

11


12/13


(a) Link 2 (b) Link 3

Fig. 4. Number of common Bluetooth MAC ids detected on Link 2 and Link 3 over each 30 minute interval from 11AM to7PM on December 18th 2008.

Fig. 5. Travel Time Evolution on Link 2 over a 6 day period

area and throws up several interesting technical challenges. We now describe a few key challenges that we have

identified. We also outline possible solutions that we are currently exploring.

Deployment: Our experience with deployments in Mumbai and Bangalore suggest that clear line of sight and

proximity to the road critically impact the reliability of the sensing mechanism. As we have already mentioned

before, deploying these sensors on traffic lights or road side lamp posts would be the right strategy. Moreover,

12


13/13


we believe that performance can be further enhanced with high gain antennas and by having multiple Bluetooth

scanners on each sensor. Apart from increasing the reliability, reducing the cost of deployment is also critical. In

this direction, devising optimal strategies (exploit city wide road network, traffic load etc.) which provide maximum

information with minimal number of sensors deployed.

Powering the Sensors: Unlike many other sensor network systems commonly described in literature, TelePort

sensors can rely on a continuous supply of power (given that they will be deployed on existing infrastructure such

as lamp posts or traffic signals). However, given the unreliability of power supply in emerging markets, having a

back-up power source for the sensor boxes is essential. A TelePort sensor consumes less than 10 W and can easily

be powered via alternative energy sources like solar power. In fact it is a common sight to see solar powered traffic

signals in several cities in India.

Backhauling the Data: As mentioned in Section III-A, the volume of data generated by each sensor is quite small.

For example, we conservatively estimate that the total data rate required per sensor to backhaul the information is

less than 2 Kbps. Therefore existing cellular systems can easily accommodate a large scale deployment of TelePort

sensors. However in the future, there could be several thousands of such sensors (for different applications including

TelePort, smart metering etc.) spread across a city, with each application only generating a small amount of data and

we envisage several interesting research issues. For example, what support can the cellular infrastructure provide

to efficiently manage and schedule the connections associated with each such application?

Remote Troubleshooting and Management: Managing a large scale city wide network is a non-trivial task. A

key requirement is remote monitoring of the health of all the sensors in the system. Once a fault is identified, theability to remotely run diagnostic tests and troubleshoot a sensor to identify the bug in the system is essential.

This could be particularly challenging if we are operating over large latency 2.5G cellular networks. Finally, we

need the ability to distribute patches for bugs or completely upgrade the software on the sensor boxes over the air

with no manual intervention. Once again doing this in an efficient manner with minimal overhead to the cellular

infrastructure is a challenging problem.

While TelePorts initial goal is to sense traffic in the environment, the TelePort infrastructure can serve a much

larger purpose and can be used as a platform to sense diverse types of environmental variables including pollution,

weather etc in the urban environment. This complements distributed participatory sensing approaches and combined

information from both these approaches can significantly improve quality of life in urban areas.

REFERENCES

[1] http:news.cnet.com830117938 105101040081.html.[2] http://www.intellione.com.[3] http://www.tomtom.com.[4] CARISMA, B., AN D LOWDER, S. Economic costs of traffic congestion: A literature review for multiple locations. Available from

http:greenconsumerism.netcategory/traffic-congestion/ (Aug 2008).[5] DEPARTMENT OF TRANSPORTATION, U . http:www.itscosts.its.dot.govitsbenecost.nsf (2004).[6] ECONOMIC DECISIONS INC ., H. The economic costs of congestion in the New York City Region. A Report (Nov 2006).[7] ERIKSSON, J., GIROD, L., HUL L, B., NEWTON, R., MADDEN, S., AN D BALAKRISHNAN, H. The Pothole Patrol: Using a Mobile Sensor

Network for Road Surface Monitoring. In ACM MobiSys (Breckenridge, U.S.A., June 2008).[8] HUL L, B., BYCHKOVSKY, V., ZHANG, Y., CHE N, K., GORACZKO, M., MIU , A. K., SHI H, E., BALAKRISHNAN, H., AND MADDEN, S.

CarTel: A Distributed Mobile Sensor Computing System. In ACM SenSys (November 2006).[9] LIU , J. Y. B. N. M . Surface Street Traffic Estimation. In ACM MobiSys (June 2007).

[10] MOHAN, P., PADMANABHAN, V., AND RAMJEE, R. Nericell: Rich monitoring of road and traffic conditions using mobile smartphones.In ACM SenSys (November 2008).

[11] MULLER, K.-R., SMOLA, A. J., RATSCH, G., SCH OKOPF, B., KOHLMORGEN, J., AN D VAPNIK, V. Using support vector machines fortime series prediction. 243253.

[12] S. WUNNAVA, K. YEN , T. B. R. Z . R. R. C. A. travel time estimates using cell phones on highways and roads.[13] WU, C.-H., HO, J.-M., AN D LEE , D. T. Travel-Time Prediction With Support Vector Regression. IEEE Transaction on Intelligent

Transportation Systems (December 2004).

13

Teleport An Open, Accurate and Flexible.pdf

Documents

Transcript of Teleport An Open, Accurate and Flexible.pdf