# Low-Cost and Energy-Saving Wireless Sensor Network for Real-Time Urban Mobility Monitoring System

Authors: Joyoung Lee; Zijia Zhong; Bo Du; Slobodan Gutesa; Kitae Kim
Journal: Journal of Sensors
 (2015)

---

## Abstract

This paper presents a low-cost and energy-saving urban mobility monitoring system based on wireless sensor networks (WSNs). The primary components of the proposed sensor unit are a Bluetooth sensor and a Zigbee transceiver. Within the WSN, the Bluetooth sensor captures the MAC addresses of Bluetooth units equipped in mobile devices and car navigation systems. The Zigbee transceiver transmits the collected MAC addresses to a data center without any major communications infrastructures (e.g., fiber optics and 3G/4G network). A total of seven prototype sensor units have been deployed on roadway segments in Newark, New Jersey, for a proof of concept (POC) test. The results of the POC test show that the performance of the proposed sensor unit appears promising, resulting in 2% of data drop rates and an improved Bluetooth capturing rate.


---

## Body

## 1. Introduction

Wireless sensor network (WSN) technologies not only offer enhancements on the existing sensor network (e.g., home automation and environmental monitoring), but they also have been innovatively applied to health care delivery and transportation [1–3]. Being one of their applications in transportation, probe-based traffic detection has gained a great deal of attention for real-time traffic monitoring, work zone and incident management, and transportation planning. By tracking instantaneous vehicle position information captured by an in-vehicle GPS navigation unit and/or smart mobile device, several commercial vendors have provided real-time travel time information to not only roadway users but also traffic management agencies. Knowing the market penetration rates of vehicular navigation system and smart mobile devices in the US, the number of probe samples would be sufficient to cover major US highways. However, the accuracy of the GPS unit embedded in the navigation system and mobile devices is often mediocre; it is known that the range of the position error of such popular GPS units reaches up to 9 meters (30 ft), particularly in a highly urbanized area forming urban valleys by skyscrapers, such as New York City, Boston, Seattle, and Los Angeles where the accuracy of GPS is often unacceptable for real-time traffic management.Recently, Bluetooth-based traffic detection technology has emerged [4, 5]. By sensing Bluetooth signal from any Bluetooth-embedded devices, such as smartphone, laptop, tablet PC, wireless headset, and car audio system, Bluetooth sensor captures the 48-bit Medium Access Control (MAC) address of the detected devices. MAC address is a unique identifier assigned to each communication device. Thus, for a certain roadway segment, it is likely to estimate the travel time of a Bluetooth device by matching its MAC address captured at both ends of the segment without a GPS unit. Several traffic management agencies (e.g., NJDOT, VDOT, and MDOT) have employed Bluetooth-based traffic sensing devices developed by multiple vendors in the US.Unlike GPS-based probe detection, the Bluetooth-based sensing system requires existing communications infrastructure to stream out collected data for real-time traffic monitoring. Current practices utilize either existing fiber-optic network deployed for traffic surveillance devices (e.g., traffic video camera and loop detector) or commercial wireless communications service (e.g., 3G or 4G/LTE) provided by telecommunication companies. Fiber-optic network provides seamless communications quality but is only available along a few major highway corridors (e.g., interstate highways). Commercial wireless services are also available across the country, but one needs to pay service fees to fully utilize them. Thus, using such communications infrastructure would be cost-ineffective for urban traffic monitoring system.This paper proposes a low-cost and energy-efficient traffic monitoring system particularly suitable for highly urbanized area where it is challenging to fully utilize existing fiber-optic network and high cost commercial communications services. By incorporating low-energy Bluetooth modules and Zigbee transceiver to form wireless mesh sensor network, the proposed sensor unit is expected to capture high quality GPS-free traffic data while ensuring seamless data delivery without existing communications infrastructure.The remainder of this paper is organized as follows. Literature review on urban mobility monitoring efforts previously conducted is summarized in the next section. The section of system architecture presents the details of the proposed sensor unit and the overall framework of urban monitoring system based on a wireless sensor network. Results from a proof of concept (POC) test will be discussed in the next section followed by conclusions and recommendations in the section of concluding remarks.


## 2. Literature Review

Monitoring urban roadway mobility has been a crucial element for the advanced urban traffic management system. Numerous relevant applications to conduct urban mobility monitoring have been proposed. In this section, some of those research highlights are summarized.Traditionally, urban mobility monitoring was implemented within the framework of an integrated intersection management system which incorporates data collection devices (e.g., loop detectors or video cameras) and communications infrastructure (e.g., fiber optics). Bretherton et al. [6] and Bielefeldt et al. [7] tested an urban congestion management system, namely, COSMOS, on top of the SCOOT traffic control system in London, UK. COSMOS is a central control system integrating intersection controls, incident management, and congestion monitoring implemented in SCOOT. The congestion monitoring of COSMOS was handled by MONACO (Monitoring and Analysis of Congestion), a subsystem installed on SCOOT in London. By using online traffic information obtained through SCOOT’s traffic sensing system, MONACO continuously monitored prevailing traffic conditions by capturing intersection volume information. Given an integrated intersection management system, such a monitoring subsystem like MONACO would be beneficial enough as it would require no additional costs to build traffic sensing system and communications infrastructure. However, compared to either travel time or speed data as a primary performance measure for urban monitoring, the traffic counts data collected by the intersection management system would be insufficient to precisely reflect prevailing traffic conditions on urban roadway.Numerous efforts to collect travel time data as a major urban mobility performance measure have been conducted to achieve more accurate urban traffic monitoring system. Cathey and Dailey [8] estimated corridor travel time by using transit vehicles equipped with an Automatic Vehicle Location (AVL) unit based on Global Positioning System (GPS). While the AVL-based transit probe system was successfully deployed in King County, Washington, the authors also pointed out that the quality of travel time heavily relies on the sample size of probes and likely produced biased travel time results in case of insufficient samples. Chakroborty and Kikuchi [9] examined the differences between automobile- and bus-based probe travel times and addressed the fact that bus-based probe travel time would cause accuracy and distance issues. To deal with those issues, the authors proposed a framework to predict automobile-based travel time from the bus-based travel time. The authors developed several regression models by using field data collected in multiple corridors in New Castle County, Delaware. Despite acceptable performance of their models, issues must be handled prior to field implementation, which includes update interval, time of day effect, and accuracy level. Pu et al. [10] proposed a bus-based probe system to collect real-time roadway travel time in Seattle, Washington. Equipped with a GPS unit and a radio transmission device, each bus reported its position information along with its time stamp in real-time to a traffic management center (TMC). With the collected position information from each equipped bus, the TMC estimated the travel time of roadway as an urban mobility performance indicator. In light of the operations of buses at bus stops, the travel time from the equipped bus might be often improper to reflect actual traffic conditions. To handle this issue, the authors had to propose an adjustment algorithm for bus travel time.With the continuous growth of mobile devices, such as smart phones, tablet PCs, and in-vehicle navigation systems, mobile device-based probe systems [11] have been prosperous since early 2000. Equipped with a built-in GPS module and wireless communications using 3G or 4G/LTE service, high-accuracy travel time information is easily collected from the individuals who have committed to provide their location information to service providers such as INRIX [12], NavTeq [13], and WAZE [14]. Recently, numerous transportation agencies like state DOTs and MPOs have employed mobile-based probe travel time from INRIX to monitor the traffic congestions of major corridors in real-time [15]. While GPS-based probes provided by such service providers would ensure highly accurate travel time information, it would be often unsuitable for small scale transportation agencies (e.g., city DOTs) due to high cost for data subscription. In addition, the quality of GPS-based location information would be less desirable in the downtown areas of modern mega cities due to an urban valley effect causing multipath inferences of GPS signal [16].Wireless sensor network- (WSN-) based traffic monitoring approaches have been examined by several researchers in their respective domains covering computer sciences, wireless communications, and electrical engineering. Meng et al. [17] proposed a conceptual framework of WSN-based urban traffic monitoring system. Without going into details of a specific sensing technology, the authors focused on an algorithmic approach to efficiently deal with tremendous amount of traffic sensing data obtained from sensor networks. Khanafer et al. [18] explored several WSN architectures suitable for Intelligent Transportation Systems (ITS) applications. The authors also defined crucial elements required for designing WSNs for ITS: robustness, scalability, cost, security, and power efficiency. Based on such design requirements, the authors evaluated layered, clustered, and planar architectures for WSN and identified the clustered architecture which would be suitable for traffic monitoring. Yulian et al. [19] proposed a real-time traffic information collecting and monitoring system based on Internet of Things (IoT). IoT refers to a group of devices or systems via wireless and/or wired network forming a cloud of data and information. With Radio Frequency Identification (RFID) devices presumably equipped in individual vehicles to form an IoT cloud, the authors created a virtual test bed in a laboratory and evaluated the performance of WSN-based traffic monitoring system.In summary, numerous efforts have been proposed to achieve accurate real-time urban mobility monitoring and some of the systems have been successfully implemented with promising performances. It is discovered that the key elements of the successful deployments were high-accuracy data collection devices and seamless communications network which require tremendous capital investments for installation and maintenance. WSN-based urban mobility monitoring architecture would be able to replace such a high cost infrastructure by employing low-cost sensor units.


## 3. System Architecture

### 3.1. Components

#### 3.1.1. Bluetooth Reader

Bluetooth is a mid- to short-range wireless communications protocol enabling two-way communications between devices such as smartphones, mobile computers, and/or car radios. Bluetooth uses a low-cost transceiver chip to exchange information between the devices. Bluetooth transceivers under the “discoverable” mode continuously transmit their MAC addresses, a unique identification code assigned to each Bluetooth device, for the purpose of identifying a device to communicate, and establish a link with the “responding devices” [20]. Inquiries are transmitted continuously as long as the devices are located within the communications range. By matching the MAC addresses of the Bluetooth-enabled devices passing through each Bluetooth reader, the travel time of a roadway section can be measured [21].In this paper, a customized multisensor Bluetooth reader is proposed to improve the detection rate by using two Class II Bluetooth modules together, the detection range of which is up to 9 meters (30 ft). Unlike rural corridors, intersections on urban roadways are often densely located, making two or three intersections within 90 meters (300 ft). In terms of capturing interintersection travel times in urban area, Class I Bluetooth readers with a coverage of 90 meters (300 ft) would be unsuitable and likely resulting in inaccurate travel time measurements. In comparison, Class II Bluetooth readers would be suitable for urban roadways but shorter coverage would suffer from insufficient detection rate. To handle this issue, a multisensor configuration for Bluetooth reader was employed.Based on Bluetooth standard [22], a Bluetooth reader keeps sending scanning signal (inquires) which elapses 11 milliseconds at every 1.28-second scanning interval as shown in Figure 1(a). In case of a Class II Bluetooth reader, it creates an 18-meter (60 ft) diameter of scanning circle for 11 milliseconds every 1.28 seconds. Thus, if a vehicle equipped with a Bluetooth device passes by a Class II Bluetooth reader with a driving speed of 51 km/h (31.9 mph) (i.e., 18 meter (60 ft)/1.28 sec = 14 meter/sec (46.9 ft/sec)) or higher, it is very unlikely for the reader to capture the vehicle. Alternatively, Figure 1(b) shows the formation of a scanning coverage when two Class II sensors are alternately scanning at every 1.28-second interval, resulting in 0.64 seconds of scanning interval. The dual-sensor configuration in Figure 1(b) is able to capture vehicles equipped with Bluetooth devices travelling at up to 102 km/h (63.8 mph), which is high enough on urban roadways.Figure 1
Bluetooth scanning coverage and sensor configuration.
(a)
Single-reader configuration
(b)
Dual-reader configuration


#### 3.1.2. Zigbee Transceiver

Zigbee is a wireless mesh network standard for low-cost and low-power wireless mobile sensing system. Based on IEEE 802.15.4 protocol [23], Zigbee is designed to transmit data up to 250 kBps in the 2.4 GHz frequency band within 90-meter (300-ft) indoor and 3.2-kilometer (2-mile) line-of-sight outdoor communications ranges. Since Zigbee is not intended to support high-power networking (e.g., Wi-Fi and WiMax), it has been usually used for low-energy mesh sensor networks such as environment monitoring and wide-range temperature and precipitation detections. It is necessary to clearly note that Zigbee transceivers are not used for collecting MAC addresses in the proposed architecture. The primary purpose of using Zigbee transceivers is to transmit the MAC address data obtained through Bluetooth readers to a certain access point which gathers all the MAC address data within the communications range in the mesh network.When it comes to designing a wireless network, weak node calculation capability and energy limited node should not be overlooked. Based on the configuration, a Zigbee transceiver has three different roles: a coordinator, a router, or an end node. A coordinator Zigbee acts as an access point, which receives all the incoming data packets from router and end node Zigbee. On the other hand, an end node Zigbee only transmits data packets to either a coordinator or a router sensor. A router Zigbee performs both transmitter and receiver roles handling the data packets from/to adjacent routers and end nodes. Depending on the combination of those sensor roles, a WSN could be categorized into three different topologies: pair, star, and mesh as shown in Figure2. For urban mobility monitoring, a mesh network is known to be suitable.Figure 2
Wireless sensor network topology.
(a)
Pair
(b)
Star
(c)
Mesh


#### 3.1.3. Sensor Unit Integration

Major components of the proposed sensor unit are depicted in Figure3(a). A mini PC handles the operation of a Bluetooth reader and a Zigbee transceiver and provides an interface to exchange data from the Bluetooth reader to Zigbee sensor by using a computer program developed by the research team. The mini PC also archives data obtained from the Bluetooth reader to its storage space. Unlike the Bluetooth readers which are directly connected to the mini PC through a USB hub, the Zigbee transceiver must utilize a dedicated breakout board, called a shield which is connected to a microcontroller. The microcontroller is connected to the mini PC through the USB hub to provide a serial communications link between the mini PC and Zigbee transceiver. The communications between the Bluetooth reader and mini PC are also maintained by a serial link. Communications speed between minc PC and both sensors is 9,600 bit per second (bps). The electrical power required for each part is provided by a rechargable battery pack through the mini PC. To keep the sensor unit operated for 24 hours and 7 days, a 30-Watt solar panel is connected to the battery pack to recharge it during the day time. Figure 3(b) shows the prototype of the sensor unit used for the proof of concept test in this paper.Figure 3
Sensor unit integration.
(a)
Sensor unit components
(b)
Prototype of the sensor unit


### 3.2. Monitoring System Architecture

At least one sensor unit is required to deploy at an intersection to capture the travel speed of a roadway segment between two intersections. It would be ideal to install a sensor unit in the middle of an intersection to capture Bluetooth-equipped vehicles from every approach. Provided a sensor unit captures incoming and outgoing traffic at an intersection, it transmits the collected Bluetooth MAC address information along with its time stamp and the serial number of the sensor unit to either a router or a coordinator Zigbee transceiver at every update interval (e.g., 2 minutes). If a receiver sensor unit is with a router Zigbee transceiver, it resends the received data packets to a coordinator sensor unit. Equipped with a communications device (e.g., WiFi or 4G/LTE Modem), the sensor unit of the coordinator Zigbee transceiver transmits the data packets received from multiple sensor units to a database server through the Internet. The database server not only archives the data collected from sensor units in a database but also estimates the travel times of roadway segments by analyzing MAC addresses and time stamps captured by every sensor unit in the network. The travel time data in the database server is retrieved by a web-based application server to produce mobility performance measures (e.g., travel speed, travel time index, and buffer index) for end users. Figure4 depicts a high-level system architecture for the WSN-based urban monitoring system.Figure 4
WSN-based monitoring system architecture.


## 3.1. Components

### 3.1.1. Bluetooth Reader

Bluetooth is a mid- to short-range wireless communications protocol enabling two-way communications between devices such as smartphones, mobile computers, and/or car radios. Bluetooth uses a low-cost transceiver chip to exchange information between the devices. Bluetooth transceivers under the “discoverable” mode continuously transmit their MAC addresses, a unique identification code assigned to each Bluetooth device, for the purpose of identifying a device to communicate, and establish a link with the “responding devices” [20]. Inquiries are transmitted continuously as long as the devices are located within the communications range. By matching the MAC addresses of the Bluetooth-enabled devices passing through each Bluetooth reader, the travel time of a roadway section can be measured [21].In this paper, a customized multisensor Bluetooth reader is proposed to improve the detection rate by using two Class II Bluetooth modules together, the detection range of which is up to 9 meters (30 ft). Unlike rural corridors, intersections on urban roadways are often densely located, making two or three intersections within 90 meters (300 ft). In terms of capturing interintersection travel times in urban area, Class I Bluetooth readers with a coverage of 90 meters (300 ft) would be unsuitable and likely resulting in inaccurate travel time measurements. In comparison, Class II Bluetooth readers would be suitable for urban roadways but shorter coverage would suffer from insufficient detection rate. To handle this issue, a multisensor configuration for Bluetooth reader was employed.Based on Bluetooth standard [22], a Bluetooth reader keeps sending scanning signal (inquires) which elapses 11 milliseconds at every 1.28-second scanning interval as shown in Figure 1(a). In case of a Class II Bluetooth reader, it creates an 18-meter (60 ft) diameter of scanning circle for 11 milliseconds every 1.28 seconds. Thus, if a vehicle equipped with a Bluetooth device passes by a Class II Bluetooth reader with a driving speed of 51 km/h (31.9 mph) (i.e., 18 meter (60 ft)/1.28 sec = 14 meter/sec (46.9 ft/sec)) or higher, it is very unlikely for the reader to capture the vehicle. Alternatively, Figure 1(b) shows the formation of a scanning coverage when two Class II sensors are alternately scanning at every 1.28-second interval, resulting in 0.64 seconds of scanning interval. The dual-sensor configuration in Figure 1(b) is able to capture vehicles equipped with Bluetooth devices travelling at up to 102 km/h (63.8 mph), which is high enough on urban roadways.Figure 1
Bluetooth scanning coverage and sensor configuration.
(a)
Single-reader configuration
(b)
Dual-reader configuration


### 3.1.2. Zigbee Transceiver

Zigbee is a wireless mesh network standard for low-cost and low-power wireless mobile sensing system. Based on IEEE 802.15.4 protocol [23], Zigbee is designed to transmit data up to 250 kBps in the 2.4 GHz frequency band within 90-meter (300-ft) indoor and 3.2-kilometer (2-mile) line-of-sight outdoor communications ranges. Since Zigbee is not intended to support high-power networking (e.g., Wi-Fi and WiMax), it has been usually used for low-energy mesh sensor networks such as environment monitoring and wide-range temperature and precipitation detections. It is necessary to clearly note that Zigbee transceivers are not used for collecting MAC addresses in the proposed architecture. The primary purpose of using Zigbee transceivers is to transmit the MAC address data obtained through Bluetooth readers to a certain access point which gathers all the MAC address data within the communications range in the mesh network.When it comes to designing a wireless network, weak node calculation capability and energy limited node should not be overlooked. Based on the configuration, a Zigbee transceiver has three different roles: a coordinator, a router, or an end node. A coordinator Zigbee acts as an access point, which receives all the incoming data packets from router and end node Zigbee. On the other hand, an end node Zigbee only transmits data packets to either a coordinator or a router sensor. A router Zigbee performs both transmitter and receiver roles handling the data packets from/to adjacent routers and end nodes. Depending on the combination of those sensor roles, a WSN could be categorized into three different topologies: pair, star, and mesh as shown in Figure2. For urban mobility monitoring, a mesh network is known to be suitable.Figure 2
Wireless sensor network topology.
(a)
Pair
(b)
Star
(c)
Mesh


### 3.1.3. Sensor Unit Integration

Major components of the proposed sensor unit are depicted in Figure3(a). A mini PC handles the operation of a Bluetooth reader and a Zigbee transceiver and provides an interface to exchange data from the Bluetooth reader to Zigbee sensor by using a computer program developed by the research team. The mini PC also archives data obtained from the Bluetooth reader to its storage space. Unlike the Bluetooth readers which are directly connected to the mini PC through a USB hub, the Zigbee transceiver must utilize a dedicated breakout board, called a shield which is connected to a microcontroller. The microcontroller is connected to the mini PC through the USB hub to provide a serial communications link between the mini PC and Zigbee transceiver. The communications between the Bluetooth reader and mini PC are also maintained by a serial link. Communications speed between minc PC and both sensors is 9,600 bit per second (bps). The electrical power required for each part is provided by a rechargable battery pack through the mini PC. To keep the sensor unit operated for 24 hours and 7 days, a 30-Watt solar panel is connected to the battery pack to recharge it during the day time. Figure 3(b) shows the prototype of the sensor unit used for the proof of concept test in this paper.Figure 3
Sensor unit integration.
(a)
Sensor unit components
(b)
Prototype of the sensor unit


## 3.1.1. Bluetooth Reader

Bluetooth is a mid- to short-range wireless communications protocol enabling two-way communications between devices such as smartphones, mobile computers, and/or car radios. Bluetooth uses a low-cost transceiver chip to exchange information between the devices. Bluetooth transceivers under the “discoverable” mode continuously transmit their MAC addresses, a unique identification code assigned to each Bluetooth device, for the purpose of identifying a device to communicate, and establish a link with the “responding devices” [20]. Inquiries are transmitted continuously as long as the devices are located within the communications range. By matching the MAC addresses of the Bluetooth-enabled devices passing through each Bluetooth reader, the travel time of a roadway section can be measured [21].In this paper, a customized multisensor Bluetooth reader is proposed to improve the detection rate by using two Class II Bluetooth modules together, the detection range of which is up to 9 meters (30 ft). Unlike rural corridors, intersections on urban roadways are often densely located, making two or three intersections within 90 meters (300 ft). In terms of capturing interintersection travel times in urban area, Class I Bluetooth readers with a coverage of 90 meters (300 ft) would be unsuitable and likely resulting in inaccurate travel time measurements. In comparison, Class II Bluetooth readers would be suitable for urban roadways but shorter coverage would suffer from insufficient detection rate. To handle this issue, a multisensor configuration for Bluetooth reader was employed.Based on Bluetooth standard [22], a Bluetooth reader keeps sending scanning signal (inquires) which elapses 11 milliseconds at every 1.28-second scanning interval as shown in Figure 1(a). In case of a Class II Bluetooth reader, it creates an 18-meter (60 ft) diameter of scanning circle for 11 milliseconds every 1.28 seconds. Thus, if a vehicle equipped with a Bluetooth device passes by a Class II Bluetooth reader with a driving speed of 51 km/h (31.9 mph) (i.e., 18 meter (60 ft)/1.28 sec = 14 meter/sec (46.9 ft/sec)) or higher, it is very unlikely for the reader to capture the vehicle. Alternatively, Figure 1(b) shows the formation of a scanning coverage when two Class II sensors are alternately scanning at every 1.28-second interval, resulting in 0.64 seconds of scanning interval. The dual-sensor configuration in Figure 1(b) is able to capture vehicles equipped with Bluetooth devices travelling at up to 102 km/h (63.8 mph), which is high enough on urban roadways.Figure 1
Bluetooth scanning coverage and sensor configuration.
(a)
Single-reader configuration
(b)
Dual-reader configuration


## 3.1.2. Zigbee Transceiver

Zigbee is a wireless mesh network standard for low-cost and low-power wireless mobile sensing system. Based on IEEE 802.15.4 protocol [23], Zigbee is designed to transmit data up to 250 kBps in the 2.4 GHz frequency band within 90-meter (300-ft) indoor and 3.2-kilometer (2-mile) line-of-sight outdoor communications ranges. Since Zigbee is not intended to support high-power networking (e.g., Wi-Fi and WiMax), it has been usually used for low-energy mesh sensor networks such as environment monitoring and wide-range temperature and precipitation detections. It is necessary to clearly note that Zigbee transceivers are not used for collecting MAC addresses in the proposed architecture. The primary purpose of using Zigbee transceivers is to transmit the MAC address data obtained through Bluetooth readers to a certain access point which gathers all the MAC address data within the communications range in the mesh network.When it comes to designing a wireless network, weak node calculation capability and energy limited node should not be overlooked. Based on the configuration, a Zigbee transceiver has three different roles: a coordinator, a router, or an end node. A coordinator Zigbee acts as an access point, which receives all the incoming data packets from router and end node Zigbee. On the other hand, an end node Zigbee only transmits data packets to either a coordinator or a router sensor. A router Zigbee performs both transmitter and receiver roles handling the data packets from/to adjacent routers and end nodes. Depending on the combination of those sensor roles, a WSN could be categorized into three different topologies: pair, star, and mesh as shown in Figure2. For urban mobility monitoring, a mesh network is known to be suitable.Figure 2
Wireless sensor network topology.
(a)
Pair
(b)
Star
(c)
Mesh


## 3.1.3. Sensor Unit Integration

Major components of the proposed sensor unit are depicted in Figure3(a). A mini PC handles the operation of a Bluetooth reader and a Zigbee transceiver and provides an interface to exchange data from the Bluetooth reader to Zigbee sensor by using a computer program developed by the research team. The mini PC also archives data obtained from the Bluetooth reader to its storage space. Unlike the Bluetooth readers which are directly connected to the mini PC through a USB hub, the Zigbee transceiver must utilize a dedicated breakout board, called a shield which is connected to a microcontroller. The microcontroller is connected to the mini PC through the USB hub to provide a serial communications link between the mini PC and Zigbee transceiver. The communications between the Bluetooth reader and mini PC are also maintained by a serial link. Communications speed between minc PC and both sensors is 9,600 bit per second (bps). The electrical power required for each part is provided by a rechargable battery pack through the mini PC. To keep the sensor unit operated for 24 hours and 7 days, a 30-Watt solar panel is connected to the battery pack to recharge it during the day time. Figure 3(b) shows the prototype of the sensor unit used for the proof of concept test in this paper.Figure 3
Sensor unit integration.
(a)
Sensor unit components
(b)
Prototype of the sensor unit


## 3.2. Monitoring System Architecture

At least one sensor unit is required to deploy at an intersection to capture the travel speed of a roadway segment between two intersections. It would be ideal to install a sensor unit in the middle of an intersection to capture Bluetooth-equipped vehicles from every approach. Provided a sensor unit captures incoming and outgoing traffic at an intersection, it transmits the collected Bluetooth MAC address information along with its time stamp and the serial number of the sensor unit to either a router or a coordinator Zigbee transceiver at every update interval (e.g., 2 minutes). If a receiver sensor unit is with a router Zigbee transceiver, it resends the received data packets to a coordinator sensor unit. Equipped with a communications device (e.g., WiFi or 4G/LTE Modem), the sensor unit of the coordinator Zigbee transceiver transmits the data packets received from multiple sensor units to a database server through the Internet. The database server not only archives the data collected from sensor units in a database but also estimates the travel times of roadway segments by analyzing MAC addresses and time stamps captured by every sensor unit in the network. The travel time data in the database server is retrieved by a web-based application server to produce mobility performance measures (e.g., travel speed, travel time index, and buffer index) for end users. Figure4 depicts a high-level system architecture for the WSN-based urban monitoring system.Figure 4
WSN-based monitoring system architecture.


## 4. Proof of Concept Test

A proof of concept (POC) test to examine the performance of the WSN-based urban monitoring system has been conducted around New Jersey Institute of Technology campus in Newark, New Jersey. The test was conducted from 4:00 PM to 6:00 PM on July 28, 2014. It must be clearly noted that the primary purpose of the POC test is to (1) build a mesh-based WSN topology for monitoring architecture and (2) examine the data collection and transmission performances of the proposed sensor units in the field. In that sense, analyzing collected data to look into the mobility performance of the roadway segments in the POC test site would be of lesser importance. For the same reason, the web-based applications that appeared in the system architecture (see Figure4) have not been included in the case study.


### 4.1. Sensor Deployment

Four sensor units were deployed to capture Bluetooth MAC addresses passing through Central Avenue, Warren Street, and Martin Luther King Jr. Boulevard in Newark, New Jersey, as denoted by 1 through 4 in Figure5. A router Zigbee transceiver (i.e., denoted by 5 in Figure 5) was deployed in between two sensor units on Central Avenue to transmit Bluetooth MAC addresses captured by the two sensor units (i.e., sensor units 1 and 2). Two coordinator Zigbee transceivers, denoted by 6 and 7 in Figure 5, were located in the NJIT campus where a campus WiFi network is available. The data collected at the coordinator units is transmitted to a database server located in the Intelligent Transportation Systems Laboratory (ITSL) in NJIT through WiFi. Each sensor unit was located around the corner of intersection sidewalk by maintaining the line of sight with adjacent sensor unit. A red small dot arrow in Figure 5 indicates a data flow from a Zigbee sender to a Zigbee receiver; for instance, the sensor unit number 2 transmits the data to the sensor unit number 5. The sensor unit number 4 also act as a router to relay the data packet from the sensor unit number 3 to the unit number 7. Each sensor unit was configured to transmit the collected data every 2 minutes to either a router or a coordinator Zigbee transceiver before the test. However, the transmission schedule of each sensor unit was all different to prevent any potential data rush to router and coordinator Zigbee transceivers.Figure 5
Sensor deployment for the POC test.
(a)
POC test site
(b)
Sensor deployment on Central Avenue, Newark, NJ


### 4.2. Results

Table1 summarizes the total number of detected MAC addresses by the sensor units 1 through 4. It also shows the total number of MAC addresses received at the router and coordinator Zigbee transceivers 5 through 7. While all the devices detected at the sensor units 1 and 2 are received at sensors 5 and 6, 2 detected devices were not transmitted to the coordinator sensor 7, resulting in 98% of reception rates. It was discovered that the missing data was sent from the sensor unit 3 to the sensor unit 4 which did not receive the data. It is noted that the heights of the positions of the sensor units in the case study site were approximately 1 to 1.2 meters (3 to 4 feet) as they were not able to be mounted on an existing intersection infrastructure like a traffic light pole. Instead, the sensor units were held by data collection assistants standing on the sidewalk around the intersections. However, the roadway segment between the sensor units 3 and 4 has numerous roadside activities such as street parking and street stall, which would prevent the line of sight between the two sensor units. It must be noted that it is certainly possible to resolve this issue by mounting the sensor units to keep the line of sight.Table 1
Number of detected Bluetooth devices and reception rate.
Unit
1
2
3
4
5
6
7
Number of detected Bluetooth devices  by end node units
44
64
62
65
—
—
—
Number of Bluetooth device received at  coordinator and router units
—
108
108
125
Receptionrate
—
100%
100%
98%The performance of the dual-reader Bluetooth configuration was examined. Table2 summarizes the number of Bluetooth devices detected by Bluetooth readers (i.e., Readers 1 and 2) in the sensor unit. It was discovered that a single Bluetooth reader detected approximately 60% to 75% of Bluetooth devices compared to the total number of detected Bluetooth devices obtained from the dual-reader configuration. Both Bluetooth readers can sense the same Bluetooth devices at the same moment, resulting in double detections. Approximately 13% to 25% of double detections were observed in this POC test. Despite such double detection cases, the dual-reader configuration appeared to improve the detection rates of Bluetooth reader.Table 2
Number of detected Bluetooth MAC addresses.
Sensor unit
1
2
3
4
Bluetooth Reader 1
27
32
41
49
Bluetooth Reader 2
30
44
31
29
Total detection (Readers 1 + 2)
57
76
72
78
Double detection
13
12
10
13
Dual-reader configuration
44
64
62
65Figure6 demonstrates the directional travel speeds of both Central Avenue and Warren Street obtained by analyzing Bluetooth MAC addresses and time stamps collected for the POC test period at the sensor units 1 through 4. Knowing that the speed limits of both roadways are 40 km/h (25 mph), the estimated travel speeds would be accurate enough to correctly reflect the actual traffic conditions. Interestingly, very low speeds less than 6.5 km/h (4 mph) were observed on both roadways in the POC test site as shown in Figure 6. Taking into consideration that both roadways are around the NJIT campus, such low speed cases, particularly on Warren Street, would be obtained by pedestrians carrying a mobile device in which a Bluetooth module is embedded. As expected, two of those low speed cases turned out to be mobile phones by examining the first 6 digits of the Bluetooth MAC address, which indicates the vendor of the Bluetooth device.Figure 6
Estimated travel speeds.


## 4.1. Sensor Deployment

Four sensor units were deployed to capture Bluetooth MAC addresses passing through Central Avenue, Warren Street, and Martin Luther King Jr. Boulevard in Newark, New Jersey, as denoted by 1 through 4 in Figure5. A router Zigbee transceiver (i.e., denoted by 5 in Figure 5) was deployed in between two sensor units on Central Avenue to transmit Bluetooth MAC addresses captured by the two sensor units (i.e., sensor units 1 and 2). Two coordinator Zigbee transceivers, denoted by 6 and 7 in Figure 5, were located in the NJIT campus where a campus WiFi network is available. The data collected at the coordinator units is transmitted to a database server located in the Intelligent Transportation Systems Laboratory (ITSL) in NJIT through WiFi. Each sensor unit was located around the corner of intersection sidewalk by maintaining the line of sight with adjacent sensor unit. A red small dot arrow in Figure 5 indicates a data flow from a Zigbee sender to a Zigbee receiver; for instance, the sensor unit number 2 transmits the data to the sensor unit number 5. The sensor unit number 4 also act as a router to relay the data packet from the sensor unit number 3 to the unit number 7. Each sensor unit was configured to transmit the collected data every 2 minutes to either a router or a coordinator Zigbee transceiver before the test. However, the transmission schedule of each sensor unit was all different to prevent any potential data rush to router and coordinator Zigbee transceivers.Figure 5
Sensor deployment for the POC test.
(a)
POC test site
(b)
Sensor deployment on Central Avenue, Newark, NJ


## 4.2. Results

Table1 summarizes the total number of detected MAC addresses by the sensor units 1 through 4. It also shows the total number of MAC addresses received at the router and coordinator Zigbee transceivers 5 through 7. While all the devices detected at the sensor units 1 and 2 are received at sensors 5 and 6, 2 detected devices were not transmitted to the coordinator sensor 7, resulting in 98% of reception rates. It was discovered that the missing data was sent from the sensor unit 3 to the sensor unit 4 which did not receive the data. It is noted that the heights of the positions of the sensor units in the case study site were approximately 1 to 1.2 meters (3 to 4 feet) as they were not able to be mounted on an existing intersection infrastructure like a traffic light pole. Instead, the sensor units were held by data collection assistants standing on the sidewalk around the intersections. However, the roadway segment between the sensor units 3 and 4 has numerous roadside activities such as street parking and street stall, which would prevent the line of sight between the two sensor units. It must be noted that it is certainly possible to resolve this issue by mounting the sensor units to keep the line of sight.Table 1
Number of detected Bluetooth devices and reception rate.
Unit
1
2
3
4
5
6
7
Number of detected Bluetooth devices  by end node units
44
64
62
65
—
—
—
Number of Bluetooth device received at  coordinator and router units
—
108
108
125
Receptionrate
—
100%
100%
98%The performance of the dual-reader Bluetooth configuration was examined. Table2 summarizes the number of Bluetooth devices detected by Bluetooth readers (i.e., Readers 1 and 2) in the sensor unit. It was discovered that a single Bluetooth reader detected approximately 60% to 75% of Bluetooth devices compared to the total number of detected Bluetooth devices obtained from the dual-reader configuration. Both Bluetooth readers can sense the same Bluetooth devices at the same moment, resulting in double detections. Approximately 13% to 25% of double detections were observed in this POC test. Despite such double detection cases, the dual-reader configuration appeared to improve the detection rates of Bluetooth reader.Table 2
Number of detected Bluetooth MAC addresses.
Sensor unit
1
2
3
4
Bluetooth Reader 1
27
32
41
49
Bluetooth Reader 2
30
44
31
29
Total detection (Readers 1 + 2)
57
76
72
78
Double detection
13
12
10
13
Dual-reader configuration
44
64
62
65Figure6 demonstrates the directional travel speeds of both Central Avenue and Warren Street obtained by analyzing Bluetooth MAC addresses and time stamps collected for the POC test period at the sensor units 1 through 4. Knowing that the speed limits of both roadways are 40 km/h (25 mph), the estimated travel speeds would be accurate enough to correctly reflect the actual traffic conditions. Interestingly, very low speeds less than 6.5 km/h (4 mph) were observed on both roadways in the POC test site as shown in Figure 6. Taking into consideration that both roadways are around the NJIT campus, such low speed cases, particularly on Warren Street, would be obtained by pedestrians carrying a mobile device in which a Bluetooth module is embedded. As expected, two of those low speed cases turned out to be mobile phones by examining the first 6 digits of the Bluetooth MAC address, which indicates the vendor of the Bluetooth device.Figure 6
Estimated travel speeds.


## 5. Concluding Remark

An innovative sensor unit to capture prevailing traffic conditions was proposed, aiming to build a wireless sensor network for a low-cost urban mobility monitoring system. It adopts two Class II Bluetooth readers and a 2.4 GHz Zigbee transceiver, which enables low-cost and energy-saving sensing operations in the field. Additionally, the proposed sensor unit employs a dual-reader Bluetooth configuration to improve the detection rates of Class II Bluetooth reader within the 9-meter (30-foot) detection range. With the proposed sensor units, it is certainly possible to build a wireless sensor network (WSN) for a low-cost real-time urban mobility monitoring system. As one of the key features of the WSN-based monitoring system, it does not heavily rely on data collection and communications infrastructures usually involving tremendous cost and efforts for construction, operations, and maintenance. A proof of concept (POC) test of the prototype sensor units was conducted around the NJIT campus in Newark, New Jersey. With a mini WSN formed by a total of seven sensor units, a temporary real-time urban mobility monitoring system was implemented during the POC test. The POC test results showed that the proposed sensor unit produced 98% of reception rates, which is certainly acceptable for real-time monitoring system. It was also discovered that the dual-reader Bluetooth configuration improved the detection rates of Bluetooth reader compared to single-reader configuration with the detection rate of approximately 60% to 75%.As demonstrated in the POC test, the proposed sensor unit proved its promising performance for low-cost real-time urban mobility monitoring. Knowing that building necessary infrastructures to deal with data collection and management for real-time monitoring involves huge amounts of cost and tremendous efforts, the WSN-based architecture proposed in this paper would be a viable solution to achieve a low-cost real-time urban mobility monitoring system.The POC test performed for this paper primarily focused on examining the operability of the proposed sensor unit and real-time mobility monitoring architecture in the field. In the future, a new pilot test could be conducted to cover a larger urban area by permanent deployment of the proposed sensor units to achieve long-term urban mobility monitoring. In addition, under the long-term monitoring environment, the monitoring architecture will be fully functional to provide proper web services to end users in the future. With respect to estimating travel speed, as shown in the POC test result, the proposed sensor unit on urban roadways would likely sense lower speed cases caused by pedestrians, bicyclists, or drivers under heavy traffic congestion. To tackle this issue, a filtering algorithm will be developed in the future. Finally, advanced intersection management system including adaptive control system would harness the estimated speed produced by the proposed architecture through future research efforts.



---

*Source: 685786-2015-09-06.xml*