AutoWaze: Towards Automatic Event Inference in Intelligent ...instance, Waze builds a live map where...

2
AutoWaze: Towards Automatic Event Inference in Intelligent Transportation Systems Ning Wang * and Yunsheng Wang * Department of Computer Science, Rowan University, Glassboro, USA Department of Computer Science, Kettering University, Flint, USA Email: [email protected] and [email protected] Abstract—Traffic monitoring is one of the key challenges in In- telligent Transportation Systems (ITS). In this paper, we propose to build a crowdsourcing application for traffic monitoring. The novelty of the proposed approach is that visual data is collected to enable automatic event inference with the recent advance in Computer Vision. The challenge is that mobile devices are not capable of handling visual task processing in high accuracy. We propose to build a networked system so that mobile devices can offload data via available wireless access interfaces (e.g., 4G LTE, WiFi, DSRC) to edge servers, e.g., GENI Rack. We plan to use the testbed at Kettering University to validate the proposed approach. Index Terms—Spatial crowdsourcing, Intelligent Transporta- tion Systems, Edge Computing I. I NTRODUCTION Traffic monitoring is a key task in Intelligent Transporta- tion Systems (ITS). Most existing monitoring systems are infrastructure-based systems, deploying dedicated traffic sen- sors, e.g., cameras, radars, etc., at fixed locations. However, infrastructure-based systems are very expensive, and thus sensors are only deployed in highways, major urban streets, and large intersections. For example, a radar speed sign will cost around $3000 [1]. As a result, these systems cannot collect sufficient traffic information, particularly for large urban areas consisting primarily of smaller streets. Nowadays, crowdsourcing-based navigation applications, e.g., Google Map [2] and Waze [3], are widely used by drivers. Drivers usually mount smartphones on the windshield before driving and get real-time updates during their trip. One of the significant advantages is that navigation apps utilize millions of users (i.e., crowds) to collect traffic information. Compared with the infrastructure-based systems, navigation apps collect traffic-related data from all running users and thus have roads’ traffic information on major streets and smaller streets. For instance, Waze builds a live map where a Waze user can report real-time traffic information, e.g., accidents, road hazards, traffic jams, so that other Waze users can further calculate the fastest route based on the real-time traffic updating [3]. In this abstract, we propose a traffic monitoring crowd- sourcing system, i.e., AutoWaze, which utilizes the mounted smartphone in the windshield to collect visual data. The collected visual data can be analyzed automatically with Com- puter Vision technique to support real-time traffic monitoring and safety-related alerts in intelligent transportation systems. (a) SSD MobileNet (b) SSD Inception (c) Faster R-CNN ResNet101 (d) Faster R-CNN NAS Fig. 1. Detection results of four object detection models As a result, it addresses several drawbacks of navigation applications with the human operation (e.g., Waze). First, reporting traffic-related events by drivers manually can be distracting, and thus, it is not safe. According to [4], as a user reporting an event currently needs some screen time, even two seconds on the phone can cost a driver loss of attention for 30 meters (assuming 60 km/hour speed). Second, it will be tough for a driver to report events in complicated road condition. Third, there are only several categories and thus, the information provided by the crowds is limited. II. RESEARCH PLAN A. Challenges The major challenge of using visual data is due to weak computation power of smartphones. The reason is that the actual road situation might be extremely complicated. To fully understand the current case, we need to hand-code millions of variables in real-time. Notably, the weak computation power of the smartphone cannot handle traffic detection in a real-time manner and thus limits us from developing more sophisticated applications. We ran some tests by using four state-of-the- art object detection models on a Traffic CCTV camera in Bangkok Thailand [5] and the results are shown in Fig. 1. The SSD MobileNet simply detect nothing in a complex scenario. However, according to [6], mobile devices can only handle lightweight object detection models, e.g., SSD MobileNet and SSD Inception rather than more sophisticated models, e.g., Faster R-CNN Inception and Faster R-CNN NAS. 978-1-7281-2700-2/19/$31.00 2019 c IEEE

Transcript of AutoWaze: Towards Automatic Event Inference in Intelligent ...instance, Waze builds a live map where...

Page 1: AutoWaze: Towards Automatic Event Inference in Intelligent ...instance, Waze builds a live map where a Waze user can report real-time traffic information, e.g., accidents, road hazards,

AutoWaze: Towards Automatic Event Inference inIntelligent Transportation Systems

Ning Wang∗ and Yunsheng Wang†∗Department of Computer Science, Rowan University, Glassboro, USA†Department of Computer Science, Kettering University, Flint, USA

Email: [email protected] and [email protected]

Abstract—Traffic monitoring is one of the key challenges in In-telligent Transportation Systems (ITS). In this paper, we proposeto build a crowdsourcing application for traffic monitoring. Thenovelty of the proposed approach is that visual data is collectedto enable automatic event inference with the recent advance inComputer Vision. The challenge is that mobile devices are notcapable of handling visual task processing in high accuracy. Wepropose to build a networked system so that mobile devices canoffload data via available wireless access interfaces (e.g., 4G LTE,WiFi, DSRC) to edge servers, e.g., GENI Rack. We plan to use thetestbed at Kettering University to validate the proposed approach.

Index Terms—Spatial crowdsourcing, Intelligent Transporta-tion Systems, Edge Computing

I. INTRODUCTION

Traffic monitoring is a key task in Intelligent Transporta-tion Systems (ITS). Most existing monitoring systems areinfrastructure-based systems, deploying dedicated traffic sen-sors, e.g., cameras, radars, etc., at fixed locations. However,infrastructure-based systems are very expensive, and thussensors are only deployed in highways, major urban streets,and large intersections. For example, a radar speed sign willcost around $3000 [1]. As a result, these systems cannot collectsufficient traffic information, particularly for large urban areasconsisting primarily of smaller streets.

Nowadays, crowdsourcing-based navigation applications,e.g., Google Map [2] and Waze [3], are widely used by drivers.Drivers usually mount smartphones on the windshield beforedriving and get real-time updates during their trip. One of thesignificant advantages is that navigation apps utilize millionsof users (i.e., crowds) to collect traffic information. Comparedwith the infrastructure-based systems, navigation apps collecttraffic-related data from all running users and thus have roads’traffic information on major streets and smaller streets. Forinstance, Waze builds a live map where a Waze user can reportreal-time traffic information, e.g., accidents, road hazards,traffic jams, so that other Waze users can further calculatethe fastest route based on the real-time traffic updating [3].

In this abstract, we propose a traffic monitoring crowd-sourcing system, i.e., AutoWaze, which utilizes the mountedsmartphone in the windshield to collect visual data. Thecollected visual data can be analyzed automatically with Com-puter Vision technique to support real-time traffic monitoringand safety-related alerts in intelligent transportation systems.

(a) SSD MobileNet (b) SSD Inception

(c) Faster R-CNN ResNet101 (d) Faster R-CNN NAS

Fig. 1. Detection results of four object detection models

As a result, it addresses several drawbacks of navigationapplications with the human operation (e.g., Waze). First,reporting traffic-related events by drivers manually can bedistracting, and thus, it is not safe. According to [4], as auser reporting an event currently needs some screen time, eventwo seconds on the phone can cost a driver loss of attentionfor ∼30 meters (assuming 60 km/hour speed). Second, it willbe tough for a driver to report events in complicated roadcondition. Third, there are only several categories and thus,the information provided by the crowds is limited.

II. RESEARCH PLAN

A. Challenges

The major challenge of using visual data is due to weakcomputation power of smartphones. The reason is that theactual road situation might be extremely complicated. To fullyunderstand the current case, we need to hand-code millions ofvariables in real-time. Notably, the weak computation powerof the smartphone cannot handle traffic detection in a real-timemanner and thus limits us from developing more sophisticatedapplications. We ran some tests by using four state-of-the-art object detection models on a Traffic CCTV camera inBangkok Thailand [5] and the results are shown in Fig. 1. TheSSD MobileNet simply detect nothing in a complex scenario.However, according to [6], mobile devices can only handlelightweight object detection models, e.g., SSD MobileNet andSSD Inception rather than more sophisticated models, e.g.,Faster R-CNN Inception and Faster R-CNN NAS.978-1-7281-2700-2/19/$31.00 2019 c© IEEE

Page 2: AutoWaze: Towards Automatic Event Inference in Intelligent ...instance, Waze builds a live map where a Waze user can report real-time traffic information, e.g., accidents, road hazards,

TABLE IA COMPARISON BETWEEN THE PROPOSED APPROACH WITH THE EXISTING APPROACH

Collected data Comm. Interface Advantage Challenges Human interactionGoogle Map GPS, cellular data Cellular small data size high estimation error NoWaze GPS, cellular data,

human event reportCellular small data size driver distraction,

limited event categoryYes

AutoWaze Visual Data, GPS, ve-hicle sensor readings

Cellular, WiFi,DSRC, etc.

fine-grained descrip-tion, automatic eventrecognition

Big data size, weakphone computationpower

No

3932 IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 63, NO. 8, OCTOBER 2014

Fig. 5. Experimental setups of (left) a roadside AP and (right) a vehicularrogue AP.

V. EVALUATION

Here, we present our experimental setup, the methodology,and the experimental results, which attempt to answer the fol-lowing questions: 1) What is the performance of both basic al-gorithm and advanced algorithm working in practice? 2) Whatis the time cost of determining whether an AP is a rogue AP?3) How does the speed of a vehicle affect the performance?

A. Experimental Setup and Methodology

The devices used in our experiments are comprised of aroadside AP, a vehicular rogue AP, and a vehicular client.

Roadside AP: A commercial outdoor AP (Deliberant CPE2-12) was configured as a roadside AP. The specification of thismodel can be found in [26]. The AP was mounted on top of atripod that is 2 m high (see Fig. 5, left side). When deploying theAP alongside the road, we used a GPS receiver (GlobalSat BU-353) to measure its physical location. To enable broadcastingthe GPS information via beacons, we loaded the AP withOpenWrt [27] firmware and a modified Wi-Fi driver. The extracontent in each beacon has 18 B including 1-B element ID, 1-Blength, 8-B latitude, and 8-B longitude.

Vehicular Rogue AP: A laptop connected with an exter-nal omniantenna and a GPS receiver (see Fig. 5, right side)mounted on the roof of a car was configured as a vehicularrogue AP. The laptop was running a 2.6.27-generic Linuxkernel with madwifi driver (svn r4128). Similar to the roadsideAP, we modified the madwifi driver to support GPS broadcast.We did not set up the Internet access for all APs since itdoes not affect the performance of our algorithms. In ba-sic attacks, we fixed the TX power by executing commandiwconfigtxpower[value] with the maximum power value.In advanced attacks, we tried to automatically adjust TX powerto mimic the real trend of RSS values, but eventually, wefound that it was really difficult to make it work in practice.Most of the time, the rogue AP could be detected by our basicalgorithm. To ease evaluation, we optimistically assume that therogue AP can bypass our basic algorithm, and we investigatethe advanced algorithm without changing the TX power of theAP. This is correct since our algorithm does not rely on anyconfiguration of APs.

TABLE IIEQUIPMENT DESCRIPTION

Vehicular Client: The vehicular client used the same hard-ware as the vehicular rogue AP. The Wi-Fi interface of the clientwas set to monitor mode, which could capture all the packets inair. Injecting and receiving packets were achieved by libpcap.The control of per-packet TX power and TX rate was done by aradiotap header. In Linux, the IEEE 802.11 MAC layer allowsarbitrary injected packet composed in the following format:

[radiotap header] + [ieee80211 header] + [payload].

IEEE80211_RADIOTAP_RATE and IEEE80211_RADIOTAP_DMB_TX_POWER in the radiotap header are used to control thedata rate and the TX power of injected packets. Given differentvalues, a packet can be transmitted with the desired power anddata rate. Note that to control per-packet TX power hal_tpcmust be enabled while loading the madwifi module. Table IIsummarizes all the equipment used in our experiments.

The experiments were conducted in a suburb an area, wherewe could freely drive along the road and stop to collect mea-surements. In the experiments, the roadside AP was placedin a parking lot around 60 m away from the road. Two carsconfigured to be a vehicular rogue APs and a vehicular clientwere driven along the road passing through the roadside AP.The roadside AP broadcast its actual GPS location, and therogue AP broadcast a location close to the roadside AP. Wetook two sets of experiments to evaluate our vehicular rogueAP detection schemes. The first set of experiments was usedto evaluate the performance of our basic algorithm, where theclient passively listened to the beacons. The second set was toevaluate the advanced algorithm, where the client actively sentprobe requests to the AP.

B. Experimental Results

Basic Attack Evaluation: First, we tested whether legitimateroadside APs could pass our basic algorithm. As an example,the top of Fig. 6 shows the measured RSS values against thelogarithmic distance in an experiment. The client started thealgorithm when observing the first beacon from a roadsideAP and terminated the algorithm when γ was stable. In total,the client collected 110 beacons within 11 s. The estimated γwas 3.31 eventually, which falls into the valid range from 2 to6. Therefore, the AP is correctly labeled as a legitimate AP.Although the finish time seems a little long, it should be noticedthat this cost only occurs once when the client initially turns onthe Wi-Fi and tries to find an AP to connect. After that, theclient will wait for a certain period until the signal strength ofcurrent APs becomes weak. Only at that time the client needsto find another AP for handoff. During the waiting period, theclient should have collected enough RSS values from nearbyAPs to determine which APs are rogue APs. To investigate therobustness of our algorithm, we also conducted experiments

Kettering University GM Mobility Research Center

GENI Rack

Academic Building

MottEngineering

InnovationCenter

0.6 Miles

GENI rack

Base Station 1

Base Station 2

Base Station 3

Kettering University GM Mobility Research Center (GMMRC).

RSU DSRC 4G LTE

1 2 3 4 5

Wifi roadside unit Cohda WirelessMK5-OBD

Cohda WirelessMK5-RSU

Airespan Air4G AirespanAireSynergy

1 2 3

4 5

Testbed

Fig. 2. Experimental testbed at Kettering University.

B. Proposed Approach

We plan to build a networked system, which can per-ceive the traffic event with the minimum human operationand communicate with servers to get timely result. It takesadvantage of the wide availability of multiple sensors (e.g.cameras, ultrasonics, radar, GPS, etc. [7, 8]), computation(e.g., multi-core CPU architecture and powerful GPUs) andcommunication resources (e.g., DSRC [9], WiFi, 4G/LTE [10],and other licensed/unlicensed spectrum [11]) of smartphonesor modern vehicles. A comparison between the proposedmethod and existing approaches is shown in Table I.

To leverage the limited computation power of smartphones,we proposed to build a networked system. We assume a typicalVehicle-to-Everything (V2X) communication environment inthe intelligent transportation system [12], where there aretwo types of interfaces (i.e., proximity-based communicationinterfaces (e.g., WiFi, DSRC) and the cellular communicationinterface) [13, 14]. The mounted smartphone in the vehicle orthe vehicle, if there is no confusion, can communicate withremote servers through nearby vehicles, roadside infrastruc-tures, e.g., the Roadside Unit (RSU), through proximity-basedcommunication in an ad hoc manner if they are available. Onthe other hand, the smartphone can communicate with serversthrough the cellular network at any time. We plan to addressthe cellular monetary cost, inference latency and inferenceaccuracy trade-off in the proposed system.

C. Experimental Platform

We have a 4G-LTE testbed facility and two Chevrolet BoltEVs at Kettering University. We have a master agreement toaccess Sprint’s 4G LTE 38 and 41 bands (2, 510 MHz, 2, 520

MHz, and 2, 530 MHz frequencies). As shown in Fig. 2, thereare 5 base stations installed in 3 different locations acrossKettering University campus area. There are 3 Air4G antennason the roof of Academic Building with the coverage rangeabout 1.5-2 miles. Other 2 AirSynergy antennas are locatedon the roof of Mott Engineering Building and InnovationCenter, respectively. The AirSynergy antenna’s coverage rangeis about 1-1.5 miles. This 4G-LTE system fully covers Ket-tering University GM Mobility Research Center, which is a21 acre outdoor vehicle test track. In addition, the DSRC(Cohda Wireless MK5) and WiFi Ad Hoc RSUs can be usedto conduct proximity-based communication experiments. Thistest system is also connected with a backend GENI rack, wherewe can run Deep Neural Networks (DNNs) to get inferenceresult at high accuracy.

REFERENCES

[1] [Online]. Available: http://www.treetopproducts.com/[2] [Online]. Available: https://www.google.com/maps[3] [Online]. Available: https://www.waze.com/[4] [Online]. Available: https://rctom.hbs.org/submission/waze-t

he-application-which-supports-or-even-incentivizes-its-users-to-break-the-rules/

[5] Traffic in bangkok thailand - waiting for the light to change.[Online]. Available: https://www.youtube.com/watch?v=4ou0joJiEro

[6] J. Wang, Z. Feng, Z. Chen, S. George, M. Bala, P. Pillai, S.-W.Yang, and M. Satyanarayanan, “Bandwidth-efficient live videoanalytics for drones via edge computing,” in Proceedings of theIEEE/ACM SEC, 2018.

[7] All tesla cars being produced now have full self-drivinghardware. [Online]. Available: https://www.tesla.com/blog/all-tesla-cars-being-produced-now-have-full-self-driving-hardware

[8] R. Ono, W. Ike, and Y. Fukaya, “Pre-collision system for toyotasafety sense,” SAE Technical Paper, Tech. Rep., 2016.

[9] J. B. Kenney, “Dedicated short-range communications (dsrc)standards in the united states,” Proceedings of the IEEE, vol. 99,no. 7, pp. 1162–1182, 2011.

[10] E. Dahlman, S. Parkvall, and J. Skold, 4G, LTE-advanced Proand the Road to 5G. Academic Press, 2016.

[11] Garmin digital traffic. [Online]. Available: https://www8.garmin.com/traffic/index.html

[12] L. Greer, J. L. Fraser, D. Hicks, M. Mercer, K. Thompsonet al., “Intelligent transportation systems benefits, costs, andlessons learned: 2018 update report,” United States. Dept. ofTransportation, Tech. Rep., 2018.

[13] N. Wang and J. Wu, “Opportunistic wifi offloading in a vehicu-lar environment: Waiting or downloading now?” in Proceedingsof the IEEE INFOCOM, 2016.

[14] N. Wang and J. Wu, “Optimal cellular traffic offloading throughopportunistic mobile networks by data partitioning,” in Proceed-ings of the IEEE ICC, 2018.