1 Introduction

Intelligent traffic systems (ITS) hold the promise to improve roadway congestion and transportation infrastructure management by capitalizing on information derived from traffic monitoring. The increasing requirement and public expectation for accurate vehicular traffic information to manage traffic flows has precipitated the deployment of large scale traffic monitoring infrastructures. Typically, this has included the use of inductive loop detectors, microwave sensors and relatively expensive video cameras.

On-board vehicular electronic devices as well as consumer electronic devices are emerging as an alternative traffic sensing modality to complement the existing traffic monitoring and management infrastructure. This evolving infrastructure provides has the benefit of providing cost-effective, real time traffic data by leveraging existing telecommunication infrastructure such as the cellular phone network.

This paper reviews the application of Bluetooth sensing in relation to ITS. It is a field that has seen very rapid evolution in the past 10 years, and will undoubtedly continue to evolve rapidly. A survey of the current state of the art can serve as a point of reference for both future and past works. In this paper, wireless sensor networks based on Bluetooth sensing are presented as a practical means of collecting a statistical representation of traffic density and flow. A basic system configuration consists of a Bluetooth probe device (s) that scans for other Bluetooth-enabled device (s) within its radio proximity, and then stores or forwards the data for future analysis and use. The scanned devices are typically on-board vehicular electronics and consumer devices carried by the driver and/or passengers which use Bluetooth communications, which reasonably proxy for the vehicle itself. Thus, the data provide the information needed to extract a reasonable approximation of traffic presence, density, and flows.

The work reported here is contextualized within many of the uses initially suggested under the IntelliDrive initiative [1] that are oriented towards improving mobility within surface transportation systems. However, advanced applications are not practical to deploy on scale without leveraging implementations based on networked and web services and evolving internet technologies. Currently, web service realization for ITS applications is promising, since a uniform middleware can be achieved while utilizing the underlying network infrastructure [2]. The applications reviewed in this paper demonstrate this integration.

Early vehicular telematic applications were user-centric, whereas innovative applications that are now within reach often combine crowdsourced information with the objective of data collection and analysis for statistical reliability and generalizability [3]. These newer class applications are cohort-centric rather than individual- or user-centric. An early reference to the use of crowdsourcing for ITS [4] pursued the idea via a Smartphone app than from a wireless sensor network. These applications often rely on inferencing from GPS-equipped probes or floating cars, with the intent to capture the behaviours of a statistically significant portion of vehicles, such that meaningful inferences can be made and potentially generalized to the entire population of vehicles [5], [6]. Being statistical in nature, in some cases, only a very small amount of floating car or probe data are required to infer significant events such as congestion build-up or dissolution [7]. In addition to the work relative to estimating traffic from GPS-enabled probe devices and map services, an alternative includes the possibility of using drivers’ cellphone trajectories as directly as proxies for vehicles, without an intermediary Smartphone app, as could be provided from a mobile cellular service provider [8–10]. Cellphone trajectories are typically coarser-grained in both space and time but can be overlaid on a traffic grid and allow for some degree of traffic flow inferencing [11].

This survey is directly related to the use of Bluetooth transceivers to crowdsource data from a statistically significant sample of vehicles, where the data can be analyzed for traffic reliable inferencing. Bluetooth is a short-range, wireless telecommunications standard that defines how mobile phones, computers, personal digital assistants, car radios, GPS units, and other digital devices can be easily interconnected. A prototypical example of the technology configuration is the interconnection of a driver’s or passengers’ mobile phone to a wireless earpiece of vehicle audio system for hands-free operation while driving.

The remainder of this paper is organized as follows. Section 2 provides a background of Bluetooth in Intelligent Transportation Systems (ITS) from some of the earliest academic references in the research area to the present. Section 3 discusses Bluetooth relative to the methods and data that can be readily obtained in a non-intrusive manner in an ITS context. Section 4 overviews the design considerations within a Bluetooth configuration for ITS applications, and Section 5 provides a provides a an illustrative reference design which encompasses many of the phenotypes of a typical Bluetooth sensor network for ITS and illustrates the ease with which data can be collected, stored and presented.

2 A Survey of Bluetooth in ITS

The earliest references to using Bluetooth for tracking purposes were typically unrelated to vehicular traffic and ITS. Within overall objectives of safety and flow monitoring, early examples included Bluetooth tracking systems to track of children at a zoo [12] and students at a University [13]. The realization that wireless sensor networks generally may play a significant role in traffic monitoring emerged in the literature in the mid-2000s [14] without explicitly mentioning Bluetooth.

Bluetooth may now appear to be an obvious methodology for non-intrusive traffic detection and estimation; however, industry reports and tests as late as 2010 evaluated various traffic sensors without considering Bluetooth as an option [15]. In a 2010 study, the authors almost apologetically implied that limiting their system to Bluetooth networks was a potential limitation, and indicated that their work could be applied to Wi-Fi devices as well [16]. The field since then has borne out that the Bluetooth devices serve as better proxies for vehicles than Wi-Fi devices would have been.

Another concurrent stream of research has been associated with the role of GPS in traffic monitoring relative to estimating travel times, vehicle density, and vehicle flows. In a more ambitious program where data was collected from GPS-enabled cellular devices, the work indicated that a 2-3 % penetration of GPS enabled cell phones in the driver population was sufficient to provide accurate measurement of the velocity of traffic flow [6]. Although the percentage of GPS enabled cell phones is clearly above the 2-3 % of the population, it is also a requirement that the GPS unit be physically on and driver data voluntarily be provided (either implicitly or explicitly). In comparison to Bluetooth, the only requirement is that the probed device has its Bluetooth enabled or discoverable, which is more often the case than having GPS enabled as well.

The potential of Bluetooth in traffic monitoring began to appear in the academic literature near 2010 [16, 17] although a small number of early field trials by local government transportation departments and agencies date to as early as 2008 [18] and 2010 [19]. Another early reference to Bluetooth sensing in a 2009 academic thesis emphasized optimal sensor location as opposed to data collection [20]. These were some of the first publications to consider Bluetooth as a means of collecting data for traffic monitoring and ITS management. A potential exception may be a 2004 reference to Bluetooth for ITS where Bluetooth is considered as a means of inter-vehicle communication as opposed the use of Bluetooth as a traffic monitoring sensor [21].

The reliability of Bluetooth sensor systems for ITS depends on widespread Bluetooth-enabled device penetration. In a study of traffic through the Limfjord Tunnel, Bluetooth penetration was estimated at between 27 and 29 % [22]. This appears to be considerably higher than many other reports at or about the same time frame. In a longitudinal study, Bluetooth penetration was seen to increase dramatically with the number of unique MAC addresses seen increasing over a year by 26 % [22]. Rationale for the increased penetration was assumed to be the popularity of GPS units combined with an increasing number of vehicles with built-in Bluetooth. This reported level of Bluetooth penetration augers well for the continued investigation into these technologies and increased levels of statistical confidence as an increasing number of Bluetooth devices become discoverable.

Most often, one thinks of the Bluetooth-enabled cellular phone as a foundational component in a Bluetooth sensor system for ITS. This premise is supported by cellular penetration rates in Canada and the U.S as well as elsewhere. In the first quarter of 2012, Canada had 28 million cellular subscribers in total, which is a penetration rate of up to 80 % if no duplicate devices to a single subscriber are considered. While not all cellular phones are Bluetooth-capable, Nielson reports Smartphone penetration of up to 64 % of mobile phone owners in the U.S. by August 2013 [23].

In one of the earliest references, researchers in 2008 envisioned the basic system components of a Bluetooth sensor system for ITS that have since evolved, stating that “one could easily imagine a battery-powered, Bluetooth enabled, smart cell phone in a plastic case chained to the side of the road to collect much more substantive travel time estimates over 24 h or 7 d to much more precisely characterize operational characteristics of either a signalized corridor or a construction work zone. Those data might be logged for later download” [18].

In general, these early studies typically focused on applications to vehicle travel times estimates (including travel time delays due to roadway obstructions) and origin–destination estimates on urban arterials and freeways. Potential applications to network analysis (shortest path), congestion reporting, bicycle and pedestrian travel times, and before-after studies were also speculated [19]. Other research interests included the quality of data produced by the Bluetooth detection of mobile devices for applications to travel time forecasting and estimates of time-dependent origin–destination matrices within an Advanced Traffic Information System (ATIS) that supplies information to drivers [24]. More recent studies likewise investigate the role of Bluetooth sensors to estimate travel times [25, 26] and vehicle velocities [27].

Privacy considerations were also foreseen early on, with the recommendation that organizations that implement Bluetooth-based tracking for ITS applications develop practices that encrypt and preclude storing MAC addresses for more than a few hours [18].

Early studies also observed asymmetry of traffic data collected in opposite directions (e.g. westbound vs. eastbound) and attributed this to antenna position. Others extended this line of investigation, characterizing antenna patterns and observing that an omnidirectional radiation pattern is most suitable for Bluetooth data collection [28]. This is not unexpected, as it reduces the complexity of antenna placement and analysis when implementing a larger system of Bluetooth sensors.

In one such study of antenna characterization relative to travel time data collection using Bluetooth, the proportion of unique Bluetooth MAC addresses read relative to the known total traffic flow was reported to be 10 % [28]. Although published in 2013, these data appear to have been collected in 2011 and as such, they represent a significant increase in the Bluetooth MAC address reads reported just three years earlier at 1 % [18]. This improvement is likely due to both higher gain antennas developed combined with the precipitous increase in the number of Bluetooth devices in vehicles over that same time period. Currently, the collecting of CoD information is largely absent in the available literature.

Furthermore, the role that Received Signal Strength Indicator (RSSI) may play in the Bluetooth data collection process in ITS arose as an explicit research question around 2011 [29], with little other apparent work on investigating RSSI as a Bluetooth data source specifically for vehicular traffic. One of the few studies available explores using RSSI as means of estimating distance from the scanning point and using Class of Device information as a potential means of differentiating pedestrians from vehicles [30].

System calibration and validation studies are becoming more rigorous as more Bluetooth sensor systems for ITS are deployed. Opportunities exist to calibrate the data with existing traffic measurement devices, including loop-detectors, mechanical counters, travel survey data of various forms, and increasingly, data inferred from cellphone trajectories. In one novel study, Bluetooth sensor data has been compared with automatic license plate recognition (ALPR) systems [17]. If available, ALPR provides as nice alternative for validation as both ALPR and Bluetooth sensors also label the data, in contrast to loop-detectors, counters, and survey data. Systems have been developed that employ a variety of sensors and their fusion in scaling up systems [31], such as the fusion of loop based detection with Bluetooth-enabled devices [32]. While Bluetooth devices appear to have been limited to defined probe vehicles resulting in a low quantity of Bluetooth data, the work demonstrated opportunities in multi-sensor data fusion using Bluetooth data in conjunction with auxiliary measurements. Another instructive example of multi-system calibration potential is with the Anonymous Wireless Address Matching (AWAM) proof of concept demonstration with the City of Houston on an urban arterial [33]. Travel times and speeds collected on identical roadway segments using a probe-based toll tag (AVI) system and the AWAM system were compared with excellent correlation.

While large-scale deployment of commercial Bluetooth traffic monitoring is still in its infancy, a number of pilot programs of various scales are being deployed. In Clark County, a pilot program costing $540,000 has approximately 20 Bluetooth probes installed collecting data along the Andresen corridor which experiences relatively high traffic, in an effort to determine whether the system can provide the information that traffic engineers need [34]. The study reports the system reading 3-5 % percent of vehicular traffic via Bluetooth MAC addresses, and they have recognized this to be sufficient to provide information on traffic flow. According to the authors, sufficient data and analysis is anticipated by early 2014 for agencies to use the outcomes to adjust traffic signal timing. Similar pilot programs are ongoing in many other countries [35–37]. While many pilot programs have focused on traffic flow on corridors and arterials, there are other Bluetooth scanning applications that are associated with work zone diversions [19, 38, 39]. At present, the majority of pilot programs are related to travel time informatics and Bluetooth data assessment towards building evidence-based cases for traffic signal retiming [40].

One of the earliest commercial system that used Bluetooth for vehicle identification for travel time estimation appears to be BLIDS [41] (http://www.blids.cc/). BLIDS was introduced early 2008 with over 50 systems deployed primarily along corridors. Traffax Inc. (http://www.traffaxinc.com/) is also one of the early commercial vendors of Bluetooth traffic monitoring systems, with the system known by the trade name BluFax and introduced in 2009. Traffax has a patent application pending (CA2711278 A1) which claims a priority date of January 2008, (provisional filing) but may come under some challenges as the system of [18] was already deployed at that time. Blipsystems (http://www.blipsystems.com/home/) supplies a commercial solution to Bluetooth tracking and traffic monitoring, with their product is denoted BlipTrack. Another commercial system is TrafficCast (http://trafficcast.com/) with a product denoted BlueTOAD. Iteris (http://www.iteris.com/) also has similar product denoted Vantage Velocity for capturing Bluetooth MAC data but does not appear to have integrated cellular connectivity. In these commercial systems, most if not all of the components discussed in this survey are included as product offerings. Somewhere in-between commercial systems and academic prototypes, various transportation institutes and agencies are leveraging intellectual property developed at or in conjunction with universities. An excellent example is the Texas A&M Transportation Institute [37, 42].

With the observed data gathering potential of Bluetooth for ITS applications combined with the emergence of a ‘big data’ culture, numerous references to systems and implementations have appeared from industry, governments, and academia. This diversity of approaches, motivations, and originators of the research lends credibility to the expanding role that Bluetooth sensing can play in ITS. In spite of this, there continues to be a need to explore system integration and validation for the various combinations of system configurations that can be envisioned.

3 Bluetooth Technology

Bluetooth is one of several available wireless technologies that may be employed to assist in resolving location extracted from a consumer electronic device (Table I). This survey focuses on classical Bluetooth 2.0 with a range that is well-tailored for monitoring or detecting devices residing in or integrated into vehicles, such as Smartphones, Bluetooth earpieces and car audio. NFC and BLE 4.0 are more recent market entries with emphasis on low power and more personal communication or very body-centric networking. WiFi and cellular are intended for wider area networking.

Table I Various wireless proximities
Full size table

In addition to Table I, there is a variety of wireless networking technologies developed over the IEEE 802.15.4 protocol such as ZigBee or XBee. These and similar are not considered here as they have not established a dominant presence in consumer devices such as smartphones. However, they are technologies to stay aware of as automobile manufacturers incorporate greater degrees of low cost wireless technologies into product lines. Relative to the basic functionality of inferencing vehicle presence by scavenging radio signals, ZigBee could provide an alternative to Bluetooth, although at this time is difficult to foresee ZigBee to be as pervasive as Bluetooth.

In general, Bluetooth scanning requires a device to probe the local wireless environment and detect the proximity of Bluetooth radios. In the ITS context, the proximate Bluetooth radios (typically, drivers’ or passengers’ Smartphones, earpieces, or on-board car audio) detected by the probe device serve as proxies for vehicles. The objective of the probe devices (aka probes) is to collect information on vehicle presence (detection by one probe) and vehicle trajectory information (detection by multiple probes in sequence) via Bluetooth device discovery, and then transmit this information via either an intermediate wireless tier or directly over a cellular network to a web service or backend server. The communication protocols between probes and backend servers are typically based on the TCP/IP protocol stack, leveraging not only the physical communication infrastructure but also the highly developed Internet IP infrastructure.

The data collected from a Bluetooth scan can be fairly detailed, including a detected Medium Access Control (MAC) address, Class of Device (CoD) information, as well as metadata from the manufacturer or as specified by the device owner (Fig. 1). While getting all of this information from a device and storing it could lead to security and privacy concerns, the MAC address, the primary method of identifying a Bluetooth device, can easily be anonymized in a fashion such that the device can be uniquely identifiable from other devices while preserving a user’s identity to a certain degree.

Fig. 1
figure 1

Simple Bluetooth Probe Scan Data

Full size image

The Bluetooth address itself is a unique 48bit device identifier, where the first 3 bytes of the address are assigned to a specific device manufacturer by the IEEE (www.ieee.org/), and the last 3 bytes are freely allocated by the manufacturer. Even if the manufacturer of a device is known, the number of possible Bluetooth addresses is immediately limited to 16,777,216. As well, since only devices that are in discoverable mode can be detected by the scan, a user can simply turn their device off (non-discoverable) to avoid being detected. There are software tools available which allow brute-force discovery of non-discoverable devices, an early example of which is RedFang, but this is usually too complex for a minimal hardware configuration and not necessary for data collection purposes associated with ITS. It is also possible to burrow deeper into Bluetooth connections to provide connection-based tracking for fine granular or building-wide device tracking [43].

It is desirable, but not necessary, to employ probes in such a way that the system is scalable. This is one of the most unique features of a Bluetooth data collection system. An organization can start with a very limited and even a portable system and easily scale it to meet increased sensing demands. In this regard, the backend data collection, storage and analysis hardware are conservative. Modern web servers and connectivity are more than sufficient to collect the volume of data that could be collected even from a large number of Bluetooth probes. The scalability issue has essentially been further resolved by existing cellular and internet infrastructure, web servers, and data services collectively being developed as a Service-Oriented Architecture (SOA) [44, 45].

The primary equipment used as the Bluetooth probe device must have the ability to be set for device discovery. Several of the existing Bluetooth modules libraries are designed to detect eight devices per inquiry, which is insufficient for most vehicular traffic applications. The limitation of eight appears to be a consequence of the anticipated use cases of Bluetooth enabled consumer devices, where supporting eight connections is likely more than sufficient. In effect, many existing Bluetooth modules are designed for connecting with the Bluetooth devices it discovers, whereas for ITS Bluetooth data collection, the primary requirement is only for devices to be detected. During traffic congestion periods, it is desirable to discover as many surrounding devices as possible, but a connection to the surrounding devices is not required. The important aspect is to ensure that the selected Bluetooth probe modules can discover as many devices as possible. In the reference design (Section 5), up to 250 unique devices per inquiry were detectable and hence recordable. This detection capability is not a restriction of the standard but rather particular implementations. For example, a detailed description of the Bluetooth discovery protocol that simulates the detection of 15 devices within a few seconds is available in the literature [46].

4 Bluetooth Sensor System: Attributes & Design Decisions

When designing a Bluetooth sensor system for ITS applications, there are choices in system attributes that become design decisions unique to the context and objectives of the system in deployment (Fig. 2). The basic configuration requires the designer to decide what type of probe device (s) will be used, how many probe device (s) are required, and where and how they will be located and fixed in the environment.

Fig. 2
figure 2

Bluetooth traffic monitoring design decisions

Full size image

  • Commercial/Prototype: In academia, a prototype system can often be easily assembled for several thousand dollars and provide entry-level data for exploring Bluetooth device detection. A commercial-grade installation of similar scope would likely be an order of magnitude greater in cost. Intermediate-grade systems are also available, for example [30].

  • Fixed/Portable: A fixed system implies a permanent or semi-permanent installation, whereas a portable system implies a system set-up or tear-down time of several hours maximum, and a deployment period measured in days, weeks, or months. In the case of a portable system, consideration has to be application domain, and a portable system offers the convenience of being more easily redeployed. A portable system typically implies a storage battery and possibly a battery charging system, such as solar. A fixed system is typically more robust but greater attention in sensor placement is required as the initial placement decisions may not be easily changeable. Fixed system may also rely on battery power, although a permanent power supply may be cost-effective as well. In both fixed and portable systems, GPS positioning is required. Both fixed and portable systems may be online or offline

  • Online/Offline: An on-line system has the potential for real-time data collection (and potentially, analysis), by data being stored in the probe for only very short periods of time and backhauled at regular intervals over a wireless connection to a dedicated server. In an offline system, a requirement exists for much more significant data storage and relatively simple retrieval. A minimum requirement would be for the probes to write data to an onboard SD card or similar, and the manual data retrieval protocol to be planned. On-board data storage is typically Flash-based and very robust.

  • Wireline power/battery/solar: The choice of power to the probe devices depends largely on the intended application. A portable application will most probably be battery powered, and depending on it intended duration and the environment, it may also be equipped with a solar charging system. Wireline power may be an economical alternative in a fixed system, although a fixed system may also run on battery power.

  • Networking: Networking considerations are typically limited to online systems, where the designer must consider means of data transport. Two of the more likely networking technologies are cellular (e.g. GSM), or WiFi. The consideration in selecting WiFi would be to ensure adequate coverage over a wide area.

  • Tiered wireless configuration: A tiered wireless sensor network is a very common architecture for sensor networks (e.g. [30] and the reference design in Section 5). In a system with multiple probe devices, a design decision must be made whether each probe will be equipped with its own WiFi or GSM/GPRS module, allowing direct communication from each probe to the back-end server. The alternate would be to implement a middle wireless tier, adding some complexity to the system. An example, of a multi- tiered wireless implementation is presented in Section 5. It is these authors opinion however, that a tired wireless system should be avoided and direct communication to the probes be supported.

  • RSSI capable: Only a very limited number of published works incorporated RSSI for traffic monitoring in an ITS context [29, 30, 47]. At time of writing, RSSI data does not play a significant role in Bluetooth systems for ITS applications, although the rapid evolution of this area in general may illuminate the potential and utility of RSSI data within a few years.

  • Bidirectional: A bidirectional system may be able to proactively communicate over Bluetooth to ‘subscribers’ or discovered devices, for example by providing traffic alerts. For example, a potential business model would allow users to purchase low-cost devices solely for the purpose of being tracked [18], with a subsequent feature of being able to backcast from the ITS to the device. This device may be as redundant as a Smartphone running a suitable app. The opportunity to also log a subscriber’s OBD-II data automatically would also require bidirectional communication via an established connection with a simple Bluetooth OBD-II dongle.

  • Remote monitoring and/or control: The Bluetooth probes should be chosen to be remotely monitored and preferably also configurable. The physical environment of installation sites (heavy traffic areas, exposure to all weather conditions) may make on-site monitoring and configuration both uncomfortable and potential dangerous. Remote monitoring allows for early detection of malfunctioning probes and other inconsistencies. Remote configuration can range from configuring the sampling rate and/or sleeping sensors when not required, which becomes critical for battery powered units. The implication of remote monitoring and configuration is that wireless access via WiFi or cellular is available to the probes. .

  • Cross validation/calibrating: As a Bluetooth sensor is sampling a proportion of the by-proxy vehicle population, by definition considerable emphasis has to be placed of validating and calibrating. A Bluetooth sensor network is relatively easy to install and provides considerable opportunity for sensor fusion. At minimum, designers must consider Bluetooth radio ranges of the probe (s) relative to the sampling area and clock synchronization between multiple probes. In data analysis, considerations include but are not limited to the ability to handle multiple MAC address reads from a given probe sensor that represent different vehicles as well as multiple reads of the same vehicle (e.g. a vehicle stopped at a traffic signal for several sampling periods), simultaneous MAC address reads from two or more probe sensors, one or more MAC address reads of a single MAC address by multiple sensors either simultaneously or in sequence, and MAC address reads of devices that are not necessarily sourced from a vehicle. The fact that the data is labeled can be used to provide some level of differentiation. There will always be some degree of uncertainty; for example, the data analysis is unlikely to be able to definitely differentiate a single vehicle from public transportation (e.g. a bus with 40 passengers and multiple Bluetooth reads). Managing uncertainty is one of the more academic aspects associated with Bluetooth traffic monitoring and promises to be a rich area of research [48].

  • Security: By virtue of the fact that all wireless communication devices need to signal to some degree in plain sight, security will always be an issue. It is not possible to alter this fact, as communicating devices need a standard means of identifying one another.

Bluetooth scanning for ITS applications such as simple traffic flow will become contextualized within big data concepts, in which the opportunities for exploring and exploiting the rich suite of data such systems are capable of generating is a significant research area in its own right. Examples include generating trajectories from uncertainties in measurement and detection [49] using techniques like Hidden Markov Models. Similar efforts will produce forecasting models that use massive amounts of real-time Bluetooth device data.

5 A Reference Design

This section presents a reference design as an example of one combination of many of the system attributes and design choices overviewed above. The system used multiple Bluetooth transceivers consisting of one master node or access point and multiple sensor probes around a major intersection in a Winnipeg, Canada, during winter 2013 (Fig. 3) [50]. The multiple probes collected vehicle presence information (detection by one probe) and vehicle trajectory information (detection by multiple probes in sequence) via Bluetooth device discovery, and then transmitted this information to the master node via the 802.15.4 protocol.

Fig. 3
figure 3

High level system overview

Full size image

Architecture

The basic system architecture is that of a Bluetooth sensor network, interconnected with an XBee/802.15.4 middle tier to the master node, and then a GSM wireless backhaul tether to a web data collection and processing web portal. XBee Pro was selected as the middle tier wireless networking technology as it offers a low power solution with sufficient range for the interconnection between the master node and sensor probes. GSM was selected as the cellular tier as a means of aggregating and forwarding data collected to a web server for processing and display. The data sent to the central server displayed the current traffic density and average velocity of vehicles at the intersection on a web front end (including mobile website) at five-minute intervals.

Probe design

The probe design uses an Arduino Uno development board, which utilizes the ATMega328 microcontroller, an XBee module and a Bluetooth Pro module, both of which connect to the Arduino module (Fig. 4).

Fig. 4
figure 4

Probe node

Full size image

During the data collection process at each probe, the information was organized in a consistent manner. Each device frame is 8 bytes and included a marker byte, a 4 byte timestamp, and 3 bytes for the truncated MAC address. To increase privacy, only half of the MAC address is recorded which still provides 16 million unique combinations for one probe network. The first 3 bytes of the packet are reserved bytes; a control byte, a length byte, and a probe id byte. The maximum packet size that can be produced is 100 bytes, as this is the size of the receive buffer of the XBee module.

The XBee module on the master node was set as the network coordinator, and the XBee module on each probe was set to associate with the network coordinator. To save power, the XBee module on the probes were configured to hibernate when not in use. Due to changes in temperature and other internal and external factors on the probes and master node, the calculated time offset at various nodes slowly drifted over time, requiring scheduled clock resynchronization.

The function of the probe is illustrated in the main flow diagram of Fig. 5, and the scan flow sub diagram is illustrated in Fig. 6.

Fig. 5
figure 5

Probe flow diagram

Full size image
Fig. 6
figure 6

Bluetooth scan diagram

Full size image

Master node

The master node consisted of Arduino-based GBoard from iteadstudio.com. For the GSM module, a preexisting library was used, with modifications and additional functionality to meet system requirements.

Power

The desired minimum run time of each probe was 24 h. A combination of battery-only and battery-plus-solar were used, demonstration the viability of a solar rechargeable source for the wireless sensor network. The rechargeable power sources were two 4,400 mA, 3.7 V lithium ion batteries hooked up in parallel to a step-up converter (to 7 V). Both batteries are connected to lithium-ion chargers powered by a 3.7 W, 6 V solar panel. A custom step-up converter was also designed to have lower current draw compared to the off the shelf step-up converter; thereby increasing the life expectancy of the supply.

Database and front-end

A MySQL database was used in order to store data, refreshed at five minute intervals, and display data to a user through a website or a smartphone app. Initial scripts were written where device MACs are compared to a table of existing MACs to find matching devices with a different probe location. When found, a probe-pair was created using the start probe, end probe and detection time difference; this was used to estimate the velocity of the device. Another PHP script was created that automatically runs every five minutes, refreshing the traffic data that is displayed on the websites. The data is stored as the total travel time for all vehicles and the total vehicle count through each probe-pair.

Implementation

A Bluetooth discovery test was conducted to ensure devices traveling in excess of 80 km/h could be detected. The XBee distance test consisted of testing the connectivity while increasing the separation between master and slave devices. Line of sight difficulties were encountered for distances exceeding 200 m. As a complete test of the system, four probes were placed along a major thoroughfare to capture the traffic over several 24 h timeframes for multiple iterations representative of different traffic and weather conditions. Probes and master nodes were mounted to light standards along the thoroughfare using steel strapping at an elevation of approximately 2.5 m. Several single-probe and multi-probe trials were carried out over winter, 2013. Data were cross-referenced to data obtained by mechanical traffic counters and to cellular service provider data that can serve as proxies for users’ movements between cell towers. Qualitatively similar trends in traffic density and flow were observed from the data sources. The reference design was found to capture an average of 4.5 % of real vehicle traffic (when compared to mechanical counters), which is above the 2-3 % conjectured as being required for statistically accurate traffic flower inferencing [6]. Initial findings lent credibility to the reference design as having the characteristics of a viable full-scale system. The cost of the reference design described above was approximately $1,500 in 2012 and 2013.

The reference system described above provides insights into the type of data that can be easily and cost effectively collected at a relatively inexpensive capital cost. The reference design, which was an academic prototype, is validated conceptually by others who report similar systems and investigations. In a study on traffic monitoring with Bluetooth sensors over ZigBee, an intervening multitier network is discussed [30]. Although a different protocol is deployed, the basic ideas and rationales are similar. Others similarly discuss the use of Bluetooth data to infer vehicle proximity as a means of estimating traffic characteristics, including the use of solar power to meet system energy requirements [51, 52].

6 Additional Considerations

As of time of writing, the emerging wireless technology for inferring traffic is that based on Bluetooth 2.x. Bluetooth 2.x is the most widely deployed mid-range communication protocol has a range commensurate with distances typical of traffic and traffic control systems. The ubiquity of Bluetooth 2.x and its ready application to traffic-related contexts currently makes it a natural choice for ITS applications. In the future, communication alternatives and superior wireless versions - ostensibly developed for different user applications - will undoubtedly contribute to the data collected for ITS. For example, Bluetooth 4.0 is currently available for ‘coin-cell-powered’ devices and is currently not obviously applicable to common ITS applications; however, this applicability is likely to develop as new opportunities emerge. The same is true for other technologies, in the spirit that the most effective uses of a technology often emerge after its development rather than as a bounded or fixed a priori specification.

From our experience, one significant recommendation in this field of Bluetooth sensor systems for ITS would be to avoid ad hoc intermediate networks. The difficulties with installation and reliability make data collection networks that rely on lines of sight for communication too constraining. In addition, the XBee communications used in the reference design were power-intensive and not tuned for power conservation. As an alternative, each sensor should ideally be equipped with GSM/GPRS and have the backend service parse data from each probe directly. The additional costs of this approach are likely to be outweighed by the benefits accrued through much simpler deployment and lower maintenance. The intervening XBee, communication network also added complexity through the use of a less efficient protocol for data transmission than GSM directly. This follows the principle of “Lex Parsimonia” where the simplest system is most likely the best.

Future work should investigate the integration of mobile Bluetooth probes as well as stationary probes. This increases processing and analysis of the data collected, but would augment data collected by the stationary Bluetooth probes. An example of a vehicle trajectory while scanning, is in [53], while a patent application for a mobile probe can be found in [54]. Utilizing mobile probes would also allow for augmenting of the data with information such as acceleration at intersections, and would be a direct means of inferring environmental conditions such as ice and snow.

Finally, a decided advantage of a Bluetooth traffic monitoring system through a Services Oriented Architecture is that it can easily and inexpensively augment any existing traffic measurement system.

The real academic, engineering, and organizational challenges will lie in full-scale deployment of a Bluetooth sensor system at many intersections across a large urban centre. The probe sensor network may be augmented by a large number of probe vehicles that could also be configured to upload data from proximate devices detected while in transit. The only requirement for this additional data from probe vehicles is to augment the discovered Bluetooth MAC address and timestamp with GPS information. Once scaled to city-wide deployment, the data mining challenges will be considerable and will require a whole new big data approach, but will also become an invaluable input to an ITS.