ON MEASURING TRAFFIC WITH Wi-Fi AND BLUETOOTH

Andreas Luber Marek Junghans Sascha Bauer Jan Schulz Institute of Transportation Systems German Aerospace Center Rutherfordstae 2, 12489 Berlin, Germany {Andreas.Luber;Sascha.Bauer;Marek.Junghans;Jan.Schulz}@dlr.de

ABSTRACT
In this paper a method for measuring travel times and mean travel speeds in a road network on the basis of Wi-Fi and Bluetooth data is presented. Until now, only Bluetooth-based equipment has been used for wireless detection. This papers aims at an additional evaluation of a Wi-Fi based approach for vehicle identification and re-identification. Furthermore, some promising results and problems encountered are shown.

INTRODUCTION
During the past recent years, an increasing number of cheap sensors replaced the physically invasive infrastructure to measure traffic parameters, particularly travel times on highways, in city centres and in sensitive areas. Bluetooth is a promising technology in this respect because wireless communication technologies are an ever increasing companion while travelling. Apart from smart phones equipped with WLAN and Bluetooth technology present in vehicles, Head-sets and hands-free kits also rely on wireless communication. Furthermore, an increasing number of upper class cars are equipped with Wi-Fi access points. By processing identified and re-identified unique MAC addresses distributed by these wireless devices at different locations, travel times can be derived. An advantage of (re-)identifying vehicles using wireless technologies is the usage of empirical data which can be derived with no additional expenses on the vehicle side. Furthermore, these approaches are less costly than current sensors since the underlying technology is cheap and meant for mass production. Additionally, this wireless approach avoids legal issues through anonymity of the collected data compared to ALPR (automated license plate recognition). 1

The first practical results of the method applied on DLRs road test track on the Ernst-Ruska-Ufer, Berlin, which is equipped with two gantries to offer best conditions for such experiments, show the feasibility of the Wi-Fi approach for measuring traffic data. The results underline the high potential for a low cost traffic management based on Wi-Fi technology in addition to the Bluetooth approach. Assuming a certain level of deployment, this approach is able to derive meaningful and reliable traffic data.

WIRELESS TRAFFIC DATA ACQUISITION

Today many vehicles are directly or indirectly equipped with different wireless technologies which are detectable from the roads side. Particularly Bluetooth and Wi-Fi based devices are easy to detect at feasible distances and therefore give reference to passing devices for a cross section of a street (lane-by-lane data is not available). Using MAC-addresses matches from at least two successive detector stations travelling direction and sample travel times for the corresponding street segment can be derived (1,2,3,4). The quality of data is high enough to use as reference data for other travel time estimations like Floating-Car-Data (5) or evaluate traffic-light coordination (6). Another valued side-product of nets consisting Bluetooth detection devices are origin-destination-matrices (7,8). In order reduce the location error, it was shown that RSSI-values representing the signal strength can be used (9).

URBAN TRAFFIC RESEARCH LABORATORY THE TEST TRACK

For the development and the validation of novel sensors and methods for traffic data acquisition and traffic control the DLR uses the Urban Traffic Research Laboratory (UTRaLab), which is a 1.2 km long test track on the street Ernst-Ruska-Ufer (see Fig. 1). Everyday approximately 30,000 vehicles provide traffic data on their way between the districts Kpenick and Adlershof to the motorway A113 connecting the center of Berlin. The data is then gathered, processed and evaluated in a virtual traffic management center. The UTRaLab is mainly equipped with classical loop, radar, video detectors and weather detectors. The two gantries (see Fig. 1), which are separated by a distance of 810m, were equipped with omnidirectional antennas catching Bluetooth and Wi-Fi packets. The inductive loops serve as a reference. The vehicles mean speed is about 60 km/h (50 km/h allowed). During the afternoon peak hour the traffic is usually jammed in near the easterly gantry (here: from left to right).

Fig. 1 UTRaLAb: the test track with one of the two gantries; the direction is

BLUETOOTH
Bluetooth is the industry standard IEEE 802.15.1, developed by the Bluetooth Special Interest Group (SIG) in the 1990s. It was originally made for the wireless communication between devices over short distances to avoid cables. Today, Bluetooth represents an interface, enabling the communication between computers, PDA, mobile phones, head sets and many more devices. Currently, the development of Bluetooth standards has reached version 4.0 to enable a connection between two devices in less than 5 ms and to obtain high data rates, since the time to connect may last up to 2.56 s (11). Bluetooth devices communicate in the license free ISM band around 2.4 GHz using 79 frequencies of 1 MHz bandwidth each. Since other technologies (e.g., WLAN, microwaves and many others), use the same ISM band, the frequencies are changed up to 1,600 times per second to achieve robustness. This is known as frequency hopping. The available Bluetooth devices are classified in three classes for short range communication up to 10 m (class 3), middle range communication up to 30 m (class 2) and long range communication up to 100 m (class 1). Tests with theses normal class 1 and 2 sticks showed an increasing coverage of up to 250 m and more than 70 m respectively, without a significant increase of the error bit rate (10). Using directional antennas can increase the range. A part of the implementation of the Bluetooth standard is the worldwide unique identification code of every Bluetooth device the 12 digit hexadecimal coded MAC address which is particularly sent out by any Bluetooth device periodically, when the device is looking for a slave (partner) to connect with. This procedure is called inquiry process and can be described as follows: A Bluetooth device A is ready to connect with other Bluetooth devices to form a pico net and thus, switches to the inquiry scan sub state, which is repeated periodically for 1.28 s (default). During this time a second sub time interval of 11.25 ms is chosen at random (inquiry scan window), in which A is able to receive an inquiry by a second Bluetooth device B at one specific inquiry frequency. In the rest of the time A remains idle and is not able to 3

receive inquiry packets from B. When A has received an inquiry packet, an inquiry response packet including MAC and clock information is sent back to B and the connection process can proceed. To ensure that the inquiry device B hits the specific random inquiry scan frequency of device A in the first scan round, the inquiry package has to be send on all 32 possible inquiry frequencies within the inquiry scan window of 11.25 ms. According to the Bluetooth specification (11) this is not possible. A transmitting and receiving cycle lasts 625 s for each frequency which leads to 20 ms for 32 frequencies. So we need at least two Bluetooth devices working on two disjoint subsets of 16 inquiry frequencies at the same time. But even if two parallel devices are used for the inquiry process 1.919 s are needed for the complete inquiry in the worst case, which is 1.27 s (inquiry scan idle time) + 0.64 s (maximum back off time). Using this time as an upper boundary for the detection, the following maximum object velocities depending on the detection range are given: radio class 3 2 1 detection range(m) 10 30 100 maximum object speed (km/h) 37.5 112.6 375,2

Tab. 1 Maximum object speed for Bluetooth detection under worst condition depending on detection range. There exist many software based packet analyzers which are able to catch MAC addresses and RSSI values from passing Bluetooth devices. These were utilized in our approach to detect discoverable Bluetooth devices. The main challenge is the long and stochastic time to detect a device. Combined with the short range of detection radius of about 25 m result in undiscovered vehicles passing the detector remain.

WIRELESS LAN
Wireless LAN is a local network, which is based on the IEEE 802.11 standard and was originally designed for the operation of wireless devices in 1997. Up to now, several standards (802.11a/b, 802.11g, 802.11n) exist for different technologies and purposes. The 802.11p standard was made particularly for traffic purposes, i.e. for vehicle-vehicle-communication and vehicle-infrastructure-communication. As in the case of Bluetooth, any Wi-Fi device provides a 12 digit worldwide unique MAC address, which uniquely identifies the device. In contrast to Bluetooth Wi-Fi potentially offers a much higher detection rate and range. Wi-Fi enabled devices can be passively detected by catching probe requests of passing devices. These types of packets are broadcasted by the devices to retrieve connectable access points in their proximity. In the same way as Bluetooth, 4

the sniffing of these packages yield MAC addresses and additional signal statistics which can be used to derive traffic data.

EVALUATION OF DATA
Data from the test track was collected in the week between the 1. and 7. February of 2011. We choose standard antennas for the Wi-Fi measurements in the February setup. This Setup was able to capture a sufficient number of Wi-Fi devices at the cost of positioning accuracy. But by reducing the antenna gain it is possible to get a better accuracy of vehicle position at the expense of detection rate. As described before the accumulated data of both gantries yielded time stamps, mac addresses, signal statistics and type of technology (Wi-Fi or Bluetooth). Furthermore single vehicle data from inductive loops on two cross sections of the street serve as reference. In the following section, different evaluations of the acquired data are presented. First of all the deployment rate of Bluetooth and Wi-Fi is analyzed, since a minimum rate is mandatory for deriving meaningful traffic data. Next, detections at two adjacent stations lead to the travelling time of the section. The average speed and travel time is derived using the distance between the stations. A detected vehicle is defined as a MAC address measurement made at one gantry with a corresponding measurement at the other gantry with a difference in acquisition time less than a predefined T_MAX.

RESULTS
Fig. 2Error! Reference source not found. displays the counts of probe data resulting from Wi-Fi and Bluetooth measurements during the week in February. The bars represent the absolute number of vehicles passing the gantries (1 hour histogram). Taking the inductive loop data as reference the mean absolute detection rate of Bluetooth devices is in average 6.5% (max. 30%) whereas the mean of Wi-Fi is about 1% (max. 20%) of total passing vehicles. Comparing the acquisition times of Wi-Fi and Bluetooth, the data indicates that vehicles are mostly not equipped with both technologies at the same time. This is an incentive to combine Bluetooth and Wi-Fi measurements to yield an overall higher detection rate.

Fig. 2 Detection rate of Wi-Fi and Bluetooth: This figure displays a week of measurement starting at
1st of February 2011. Red columns indicate the counts of Wi-Fi whereas blue columns Bluetooth counts indicate. Gray columns display the reference counts of inductive loop data. The accordingly colored solid lines represent the resulting absolute detection rate.

Fig. 3Error! Reference source not found. depicts the mean speed on the test track derived from measured travel times. Blue dots indicate the computed average speed values of each detected vehicle. The solid blue line represents the mean of speeds accumulated over an hour with standard deviation represented by the light blue area around the mean. Reference speed is represented by the black solid line. The mean difference between Bluetooth and reference speeds is about 1 km/h with 2 km/h standard deviation and a maximum deviation of 21 km/h. High maximum deviation occurred in times of low traffic resulting in few measured Bluetooth data-sets.

Fig. 3 Derived Mean Speed on Road Segment from Bluetooth Measurement: The speeds
derived from Bluetooth measurements are displayed as blue dots. The mean speed of these measurements is the blue solid line and the blue colored region is the corresponding standard deviation. The gray solid line is the loop

derived reference speed. Gray columns represent the Bluetooth counts per 15 minutes.

Fig. 4Error! Reference source not found. displays the speeds derived from Wi-Fi data for a 15 minute window of aggregation time. Again, red dots mark probed speeds, red solid line is the 15 minute mean and the light red filled area represents the standard deviation of speed data points. Reference speed is represented by the solid black line. As expected from far less detection rate the error in terms of mean difference to reference speed dropped to 2 km/h with 3 km/h standard deviation. Because of sparse measurements the Wi-Fi data had to be aggregated over 1h. That is why the Wi-Fi data follows nicely the reference speed during day time over the whole week. During the night Wi-Fi data is almost not present and therefore cannot be used to derive meaningful speed and travel time data.

Fig. 4 Derived Mean Speed on Road Segment from Wi-Fi Measurement: The speeds derived
from Wi-Fi measurements are displayed as red dots. The mean speed of these measurements is the red solid line and the red colored region is the corresponding standard deviation. The black solid line is the loop derived reference speed. Gray columns represent the Bluetooth counts per 15 minutes.

Fig. 5Error! Reference source not found. and Fig. 6Error! Reference source not found. show an entire day of data with an aggregation time of 5 minutes. Especially the traffic jam in the afternoon at 4 pm is detectable by both of the technologies. During night time, due to lack of data, traffic measurement with Bluetooth or Wi-Fi fail to reproduce the reference data.

Fig. 5 Single Day Evaluation of Bluetooth Data with Traffic Jam at Afternoon

Fig. 6 Single Day Evaluation of Wi-Fi Data with Traffic Jam at Afternoon Following this experiment, we altered our setup in order to achieve a gain in detection rate. In terms of Bluetooth we used a different Bluetooth stack that was capable of inquiring more data. In terms of Wi-Fi we also changed the software-basis and reduced the antenna gain. Unfortunately due to hardware failure no reference data is currently available for this measurement.

SUMMARY & OUTLOOK

In this paper the well-known approach for measuring travel times of vehicles with Bluetooth was applied on Wi-Fi. We could show, that even at a very low deployment level travel times and mean travel speeds between the two gantries of our test track could be estimated. Even traffic breakdowns could be detected on the basis of only a few measurements. In contrast to Bluetooth the quantities of Wi-Fi detections are not very high, but the results are promising. Since car OEM will continue to introduce more and more Wi-Fi technologies in the middle 8

and upper class the Wi-Fi detection level will increase within the next years. In addition to the Bluetooth based measurement of traffic parameters, a Wi-Fi based technique may complement the results and the spatial and temporal surveillance horizon is extended. Our future research will deal with different aspects: First, we want to improve the data by integrating physical models concerning the propagation properties of Wi-Fi for traffic parameter measurement in urban areas and narrow corridors. Second, from a traffic-based viewpoint, the detection of particular patterns in the resulting data of wireless communication systems may be very important, e.g. commuter traffic can be investigated to calibrate macroscopic traffic models. Third, further investigations will have to be done in the experimental setup, e.g. the experiments must be repeated with different antenna types.

REFERENCES
(1) Tarnoff, P. J.; Wasson, J. S.; Young, S.; Ganig, N.; Bullock, D. M.; Sturdevant, J. R. (2008): The Continuing Evolution of Travel Time Data Information Collection and Processing, TRB 2009 Annual Meeting (2) Wasson, J. S.; Hasemann, R. J.; Bullock, D. M. (2009): Real Time Measurement of Work Zone Travel Time Delay and (3) Brennan Jr., T. M. (2009): Influence of Vertical Sensor Placement on Data Collection Efficiency from Bluetooth MAC Address Collection Devices, Journal of Transportation Engineering (4) Malinovskiy, Y.; Lee, U.; Wu, Y.; Wang, Y. (2011): Investigation of Bluetooth-Based Travel Time Estimation Error on a Short Corridor, TRB 90th Annual Meeting (5) Haghani, A.; Hamedi, M.; Farokhi Sadabadi, K.; Young, S.; Tarnoff, P. (2010): Freeway Travel Time Ground Truth Data Collection Using Bluetooth Sensors, TRB 2010 Annual Meeting Evaluation Metrics Using Bluetooth Probe Tracking, TRB 2010 Annual Meeting (6) Day C.M.; Haseman, R.; Premachandra, H.; Brennan, Jr., T.M; Wasson, J.S.; Sturdevant, J.S.; Bullock, D.M (2009): Visualization and Assessment of Arterial Progression Quality Using High Resolution Signal Event Data and Measured Travel Time, 89th Annual Meeting of the Transportation Research Board (7) Barcel, J.; Montero, L.; Marqus, L.; Carmona, C. (2009): Travel Time Forecasting and Dynamic OD Estimation in Freeways based on Bluetooth Traffic Monitoring. 89th Annual Meeting of the Transportation Research Board (8) Quayle, S.M.; Koonce, P.; DePencier, D.; Bullock, D.M (2010): Arterial Performance Measures Using MAC Readers: Portland Pilot Study, 89th Annual Meeting of the Transportation Research Board (9) Ahmed, H.; El-Darieby, M.; Abdulhai, B.; Morgan, Y. (2011): A Bluetooth- and WI-FI-Based Mesh Networks Platform for Traffic Monitoring, TRB 2008 Annual Meeting (10) Holzmann, C.; Oppl, S. (2003): Bluetooth in a Nutshell [Context Framework for Mobile User Applications Strategic Alliance Siemens AG], Linz University (11) SIG (2009), Bluetooth Specification Version 4.0, Master Table of Contents & Compliance Requirements, Vol. 0