Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Teleport: An Open, Accurate and

Flexible System to Measure Trafc Flow.

Contact: Vikram Srinivasan email: vikramsr@alcatel-lucent.com Team: Avhishek Chatterjee, Samik Datta, Supratim Deb, Sharad Jaiswal

Bell Labs Research, India

Whitepaper on the Teleport Trafc Sensing System

E XECUTIVE S UMMARY In this paper we present a low cost sensing infrastructure for urban road trafc 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 to commuters in real time. Our system hits the sweet spot between cost, accuracy and reliability compared to existing approaches for road trafc 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 trafc patterns. We develop algorithms that exploit these patterns to accurately predict travel times. Specically our main contributions in this paper are (i) identifying Bluetooth and in general near eld communications as a mechanism to do accurate and low cost sensing of road trafc, (ii) extensive experiments to validate and characterize the efcacy of Bluetooth as a trafc sensor, (iii) designed and implemented and deployed a system for large scale sensing of road trafc, (iv) designed approaches to improve estimates in the presence of insufcient data and (v) developed algorithms to accurately predict trafc up to an hour into the future.

Whitepaper on the Teleport Trafc Sensing System

I. I NTRODUCTION 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 of any nation. For example, according to [4], the GDP loss due to trafc-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, trafc 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, signicant capital investment and public support to be successful. We argue that in addition to all these approaches, providing relevant and timely information about trafc 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 ne grained information requires a large scale trafc sensing infrastructure. However current solutions are extremely expensive or woefully inaccurate. Our goal in this paper is to design a low cost trafc sensing system especially applicable to emerging markets. We believe that a good trafc sensing system for emerging markets should satisfy the following requirements. 1) Accuracy: The system should provide accurate travel-time information, with appropriate condence 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 trafc and number of users of the trafc 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 classication. A. Our Approach In this work we describe a low cost trafc 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 difcult to match the MAC of

Whitepaper on the Teleport Trafc Sensing System

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 trafc congestion, we now provide a detailed discussion of other efforts towards building a trafc sensing system. In-road Sensors (e.g., inductive loop sensors, magnetometers, video cameras): In this approach, trafc 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 trafc 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 trafc video camera costs around USD 16,000 per direction on arterial roads (including cost of mounting a camera pole). Cost of ber 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 difcult task as it involves human intervention, and possible trafc disruption. Placing redundant sensors for faulttolerance 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-time estimates 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 trafc conditions on city roads. In essence they classify trafc 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 in India 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 efcacy of such a system for good coverage in the city (especially in denselybuilt 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 ow trafc condition on highways. The reasons being: 1) The accuracy of the location estimate is 100-300 meters; in dense urban streets, this makes it difcult 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

Whitepaper on the Teleport Trafc Sensing System

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 sufciently far apart (to get a useful travel time estimate) requires the call to last for a sufciently 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 detect road-trafc 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 trafc sensing mechanism [1]. While the core idea is identical to ours, we are yet to nd 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 spot between cost, accuracy and usability in emerging markets.
TABLE I TABLE COMPARING DIFFERENT TRAFFIC SENSING MECHANISMS

System

Accuracy

Cost

GPS-based Cellular triangulationbased Loop detectors TelePort (our approach)

Low-Medium Low High Medium-High

Low Low High Low

Usability time-scale in emerging markets Long-term Short-term Short-term Short-term

Granularity of information Medium Medium High Medium

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 rst work to design and rigorously evaluate a near-eld communications based trafc 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 efcacy of Bluetooth as a trafc 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 trafc data and observed interesting patterns. 5) We design algorithms that exploit this structure to predict travel time. For the data we collected, our algorithm signicantly 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.

Whitepaper on the Teleport Trafc Sensing System

II. P RELIMINARIES AND W ORKING P RINCIPLE 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. Specically, 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 sufcient number of Bluetooth enabled phones carried by people? Experiment-1: In the rst 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 rst observable was converted into probabilities. In Table II, we show the result of this simple experiment.
TABLE II D ETECTION RANGE OF A CLASS -1 B LUETOOTH DEVICE

Distance between the two devices (m) (class-1 and class-2) 50 60 80 100

Probability of detection 1.0 0.90 0.65 0.41

Average detection time (s) 2.15 2.05 2.96 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),
1 This was done using software scanner module written over the Linux BlueZ stack (on laptops with Frontech Bluetooth dongles). The scanner also noted the system times when other Bluetooth devices were detected 2 The

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

Whitepaper on the Teleport Trafc Sensing System

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 the lightly 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 the car within the detection range when it is detected, and also the multiple detections as a car goes past. Furthermore, this experiment also demonstrates the efciency of detecting a moving vehicle by a road-side Bluetooth sensor.
TABLE III D ETECTION TIME STATISTICS OF THE CAR AT TWO SENSORS SEPARATED BY 0.6 KM

Statistics of difference between manual and system measurement of travel-time Maximum Minimum Average

Error on congested road (in sec) 9 2 5.4

Error on lightly loaded road (in sec) 7 1 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 sufcient 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 trafcked) 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 sufcient to provide accurate average travel time estimates (particularly for time scales over which trafc patterns change signicantly). Experiment-4: Dublin City Our colleagues in Bell Labs Ireland, performed two sets of experiments in the city of Dublin. The rst was on a busy city street to see if there were sufcient number of people carrying Bluetooth 7

Whitepaper on the Teleport Trafc Sensing System

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 Court at 1645-1700 hrs on a Thursday evening. Trafc was free owing 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 trafc monitoring tool for highways also.

III. S YSTEM A RCHITECTURE 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

Whitepaper on the Teleport Trafc Sensing System

We now discuss the architectural features of each of the above mentioned elements of our system, the specic 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 Linux and 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 sensorboxes 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 signicantly. 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 trafc, 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 rst-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 lling the realtime estimates, and the route computation engine is responsible for lling 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 rene 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 a suitable 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 rst 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

Whitepaper on the Teleport Trafc Sensing System

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 yover and typically had smooth owing trafc going past it. The third sensor was located about 50 meters before a trafc signal. The last sensor was placed at a trafc police booth located adjacent to a road intersection with a trafc signal3 . The distance between the rst 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. O BSERVATIONS F ROM P ILOT D EPLOYMENT IN M UMBAI 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 trafc 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 trafc going in and out of the complex (a company interested in this solution requested a demo and insisted that one sensor be placed at the security booth at the entrance to its ofce 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.
3 Due

permissions were taken from the Commissioner of Police for Trafc in the city

10

Whitepaper on the Teleport Trafc Sensing System

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 trafc signal, detects as many as 70 MAC ids in a 30 minute interval and at least 30 devices in any 30 minute interval4 . Sensors 2 and 3 (placed in shops) detect fewer - as many as 35 MAC ids, and there was only one interval in which no MAC ids were detected. This implies the following. First, there is a sufcient 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 trafc signals to capture as many vehicles as possible.

(a) Sensor 2 Fig. 3.

(b) Sensor 3

(c) Sensor 4

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 measurement interval. Typically, our sensors detected enough Bluetooth devices to provide sufcient 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 trafc 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. T OWARDS L ARGE S CALE D EPLOYMENT Our trial deployment in Mumbai coupled with several experiments in Bangalore has clearly demonstrated the feasibility of using Bluetooth as a trafc 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
4 Note

that we are reporting cleansed data, and have already eliminated pedestrian trafc etc.

11

Whitepaper on the Teleport Trafc Sensing System

(a) Link 2 Fig. 4.

(b) Link 3

Number of common Bluetooth MAC ids detected on Link 2 and Link 3 over each 30 minute interval from 11AM to 7PM 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 identied. 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 trafc lights or road side lamp posts would be the right strategy. Moreover, 12

Whitepaper on the Teleport Trafc Sensing System

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, trafc 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 trafc 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 trafc 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 efciently 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 identied, the ability 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 efcient manner with minimal overhead to the cellular infrastructure is a challenging problem. While TelePorts initial goal is to sense trafc 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 signicantly improve quality of life in urban areas. R EFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] http:news.cnet.com830117938 105101040081.html. http://www.intellione.com. http://www.tomtom.com. C ARISMA , B., AND L OWDER , S. Economic costs of trafc congestion: A literature review for multiple locations. Available from http:greenconsumerism.netcategory/trafc-congestion/ (Aug 2008). D EPARTMENT OF T RANSPORTATION , U. http:www.itscosts.its.dot.govitsbenecost.nsf (2004). E CONOMIC D ECISIONS I NC ., H. The economic costs of congestion in the New York City Region. A Report (Nov 2006). E RIKSSON , J., G IROD , L., H ULL , B., N EWTON , R., M ADDEN , S., AND BALAKRISHNAN , H. The Pothole Patrol: Using a Mobile Sensor Network for Road Surface Monitoring. In ACM MobiSys (Breckenridge, U.S.A., June 2008). H ULL , B., B YCHKOVSKY, V., Z HANG , Y., C HEN , K., G ORACZKO , M., M IU , A. K., S HIH , E., BALAKRISHNAN , H., AND M ADDEN , S. CarTel: A Distributed Mobile Sensor Computing System. In ACM SenSys (November 2006). L IU , J. Y. B. N. M. Surface Street Trafc Estimation. In ACM MobiSys (June 2007). M OHAN , P., PADMANABHAN , V., AND R AMJEE , R. Nericell: Rich monitoring of road and trafc conditions using mobile smartphones. In ACM SenSys (November 2008). M ULLER , K.-R., S MOLA , A. J., R ATSCH , G., S CH OKOPF , B., KOHLMORGEN , J., AND VAPNIK , V. Using support vector machines for time series prediction. 243253. S. W UNNAVA , K. Y EN , T. B. R. Z. R. R. C. A. travel time estimates using cell phones on highways and roads. W U , C.-H., H O , J.-M., AND L EE , D. T. Travel-Time Prediction With Support Vector Regression. IEEE Transaction on Intelligent Transportation Systems (December 2004).

13