Employing Crowdsourcing in Transportation Systems

Employing Crowdsourcing in Transportation Systems

Chandan B Skanda K Karthik R S Darshan M City Engg.College, City Engg.College, City Engg.College, City Engg.College Bangalore,India, Bangalore,India, Bangalore,India, Bangalore,India, Chandan.cec107@gmail.com skandapushkara@hotmail.com Karthiksathavalli@gmail.com 1ce09is008@gmail.com

Abstract

CrowdSourcing(CS) is the practice of obtaining needed services, ideas, or content by soliciting contributions from a large group of people, and especially from an online community. CroudSourcing is attracting a lot of people nowadays. Smartphones are nowadays equipped with a number of sensors, such as WiFi, GPS, accelerometers, etc. This feature allows smartphone users to easily engage in crowdsourced computing services, which contribute to the solution of complex problems in a distributed manner. Collecting the required data and sending it to the requested user is an important task of CS. In the existing technology, vehicles and roadside devices are equipped with sensing and communication capabilities. The main drawback is that capturing the events by the drivers using their smart phones. In this paper, we propose the use of Crowdsourcing in transportation system. In CS human inputs, along with the sensory data, are collected and communicated to a processing server using mobile phones. The basic idea is to use the Crowd with smart mobile phones to enable certain CS applications without the need of any special sensors or communication devices, both in-vehicle and on-road. Next, integration and aggregation of data from many information sources takes place and then information is sent to the driver based on his/her geo-location. O n e o f the d i f f i cu l t t a s k is to integrate human inputs, with multiple information sources, aggregate and finally it is localized according to the drivers geo-location. CS applications are developed using Android and iPhone mobile phones.

1. INTRODUCTIO N

   The projected estimate of 8.5 million driving- related deaths by the year 2020 is one of the motivations behind numerous academic, commercial and governmental engage- ments in adapting technology for transportation industry. Technology made CS way into CS in the forms of Vehicle-to-Vehicle (V2V) and Vehicle- to-Infrastructure (V2I) paradigms [1]. These paradigms rely on certain communica- tion and sensing technology, e.g., WiFi, WiMax, short-range radar, active RFID tags, etc.information from outside sources. The first scheme is the vehicular ad-hoc wireless communication and involves only vehicles, i.e., the V2V model. The second scheme is the vet- hikes to infrastructure and involves fixed infrastructure-based wireless communication, i.e., the V2I model. Application of these schemes, and CS in general,

   include real-time safety and convenience applications (forward collision warning, blind spot detection, etc.) and non-real-time (or near real-time) management and leisure applications (congestion avoidance, traffic reporting, etc.). In this paper, our research focus is on the non-real time CS applications.

   Information collection and dispersion are key to non- real- time CS application, e.g., avoiding traffic congestion. Diverse approaches have been investigated in the literature, employing these schemes for efficient data dissemination. Sophisticated routing, (e.g., location-aided routing [2], trajectory based rout- ing [3], gossiping-based routing [4] and flooding), relaying protocols [5], opportunistic and delay-tolerant approaches, (e.g., spray-and-wait [6], epidemic [7] and message ferrying methods [8]) have been studied extensively within the context of CS and CS applications.

   In this paper, we propose Crowdsourcing in transportation system. Crowdsourcing enables the utilization of the Crowd to find solutions which otherwise would be hard or impossible to resolve, for some monetary reward or personal satisfaction [9]. The basic idea is to use the drivers community with smart mobile phone (Crowd) to assist in enabling non real-time and near real-time CS applications. Motivation is to enable these applications without the need for deployment of sophisticated sensors on the roads or complex communication devices within vehicles.

   Conceptually, the major change is to collect human in- puts and aggregate it with other readily available sources, e.g., traffic reports from Ministry of Transportation Ontario (MTO). The aggregation is handled by the CS processing server(s) which pull-in the information from numerous sources, e.g., databases, micro- blogging, etc. The Crowd server pushes out the events of possible interest to the driver of each mobile phone. The push-out events are selected according to the geo-location of each member of the Crowd. Googles Cloud to Device Messaging (C2DM) service is used by Crowd for events delivery. We also have designed a key

   CS application; path re-routing to avoid traffic congestions. We report on the initial development of the application for the iPhone and Android smart mobile phones.

   The remainder of the paper is organized as follows. Sec- tion II gives an overview of Crowdsourcing. Section III presents the Crowd and explains the architectural compo- nents and interfaces. Section IV describes the development of an important CS application, vehicles re-routing, using Crowd framework using iPhone and Android platform. Section V presents future work and conclusions.

2. CROWDSOURCING: AN OVERVIEW

   Crowdsourcing, in general terms, is the act of taking a job traditionally performed by a designated employee and outsourcing it to an undefined, generally large group of people

   Smart Mobile Phones

   mySQL database

   Micro- blogging

   PUSH Localized Data

   REGISTER-AUTH

   PUSH Selective Data (for individual devices)

   PULL Data

   REST

   API

   Internet

   MTO

   Google's

   C2DM

   Crowd Server(s)

   Desktop Tablets

   Laptops

   (a Crowd) in the form of an open call [9]. Technically speaking, Crowdsourcing is a distributed problem-solving and production model. In such model, initially, the problems are formulated in a format that can be understood easily by techni- cal and non-technical people. These formulated problems are then broadcast to an unknown group of solvers, i.e., the Crowd, in the form of an open call for their solutions. The Crowd, usually knitted together via web-based technology subm their solutions. The submitted solutions can also be sorted and filtered out by the Crowd itself, in search for finding the best set of solutions. The final solution(s) is then owned by the organization which initiated the problem, i.e., Crowdsourcer. In most cases, the effort put in by the individuals, with one of the best solutions, is awarded monetarily or by some form of recognition. In other cases, the individuals are working out for their personal interests so personal satisfaction might also be sufficient. These steps are depicted in Fig. 1.

   2. Divide into small tasks

   Fig. 2: System architecture of the CrowdITS

   utilize Crowdsourcing to answer queries, in the form of micro- tasks to the AMT Crowd (workers), which would not be oth- erwise answered by a conventional database. Crowdsourcing has found various other themes such as Crowd funding [11] and Crowd wisdom [12].

3. SYSTEM ARCHITECTURE

   Crowd is a Crowdsourcing platform for near real-time and non real-time CS applications, involving data collection from large number of users. Traditionally in ITS, the tasks of identifying various traffic related statistics, events and incidents are handled by specialied sensory equipments. For instance, the loop wires and CCTV on the major highways are used to meter traffic and congestion, respectively. In CrowdITS, these tasks along with others are performed by the Crowd, i.e., the driver or passenger(s) of the vehicle, using

   Problem(s)

   1. Initiate

problem 6. Reward (if accepted)

Crowd

1. Propose solution(s)

2. Filter/Sort (if required)

   either interactive mode (e.g., voice), ubiquitous mode (e.g.,

   GPS logging) or both. Crowd, as an appreciation, receives localized and groomed information of their potential interests. Unlike Crowdsourcing, wherein the tasks are solely handled by the Crowd, the Crowd is a hybrid system as it integrate Crowd-based sensing with conventional data gathering, e.g.,

   Crowdsourcer

3. Final Solution

   Solution(s) both on-road and in-vehicle sensors.

   The Crowd architecture is composed of three major

   components. These components are Crowd sensing and inter- face, information processing, and localized device messaging.

   Fig. 1: Overview of main steps in Crowdsourcing

   Amazon provides a Crowdsourcing platform, namely Ama- zon Mechanical Turk (AMT)1 , on which Crowdsourcers broadcast their problem tasks and define a price/reward (min- imum is $0.01) for each satisfactorily completed task. The Crowd accepts, works on these tasks and might get rewarded. CrowdDB; a relational query processing system, has been proposed [10]. The CrowdDB Interface is of great importance in smart-phone enabled CS applications. The interface can be interactive, pervasive or both. In interactive mode, the Crowd can enter events in

   two ways. First, an interactive screen, shown in Fig. 3-b, wherein the two places a

   mySQL DB

   Archiving

   Prediction

   Verification

   Add-on Services and apps

   Information Sources

   Work in progress

   Init Init pull pull push push
   query	query
   update update close close
   Data retriev	al, geo-hash
   authentication and sorting Aggregation & filtering
   registration, a	uthentication
   CORE

   schedular, request handler, dispatcher, config, etc.

   REST API & WebServer

   mySQL DB

   mySQL DB

   C2DM

   Local DB

   Remote DB

   Data Service

   1. Main interface (b) Event posting interface

Fig. 3: Crowd interface for posting an event, navigating and GPS follow-up on an Android phone

Second, using voice commands wherein pre-configured sets of commands are available. Using the voice commands the Crowd can specify the event, CS severity, CS expected timeout and other metadata (e.g., personal message). An event, as a consequence of using either input method, is auto-stamped with current time and geo-location. The logged time is used to filter out and to set an expiry time for irrelevant entries. The geo-location, converted into geohash, is use to group the events and sent notifications to the Crowds mobile devices. The driver can freely roam around and be notified of any potential problems ahead or can navigate to a preset destination. The main interface is shown in Fig. 3-a. In pervasive mode, the mobile phone periodically enters CS sensory data (e.g. GPS) which can then be used to determine vehicles speed and direction hence,traffic congestion. Currently, the traffic layers in Google maps are obtained using the pervasive approach. This approach however, has limited reporting facilities, i.e., reporting of only a certain type of events can be made possible. Currently, we are further evaluating the technical and non- technical aspects of different reporting approaches.

Geohashing is used to map and link multiple events to- gether, from different sources. Geohash is a

latitude/longitude geocode system based on a hierarchical spatial data structure which subdivides space into buckets of grid shape2 . The obtained hash, a string, is used as a unique identifier to represent a point anywhere in the world. Geohash has arbitrary precision, due

to CS encoding mechanisms which allow having variable- size strings, and hence, flexible precision. Due to this property, any nearby places will often (but not necessarily always) present similar prefixes to the geohash string. In other words, the longer a shared prefix is, the closer

Fig. 4: Framework for the Crowd processing servers

1. Information Processing

   The Crowd processing server provides three main ser- vices. These include information retrieval and storage,

   registra- tion and authentication, and localized messaging to mobile de- vices. Furthermore, additional services can also be developed, e.g., archiving and traffic prediction, information verification, web service, etc.

   Numerous information sources are available in ITS. The number of sources and data volumes demand scalable and expandable architecture. We propose a plugin-based frame- work for the centralized Crowd processing server that will provide a scalable and expandable utilization of the numerous information sources and data volumes available for ITS. The overall framework of such an architecture is shown in Fig. 4. Each stream of information is handled by CS own plug-in which processes incoming data packets, archives them into individual repositories and provides APIs for the core unit to pull or push, query, and update data. To balance the

   heavy workload of Crowd, different plug-ins can be configured to handle sub-sets of geo-location, i.e., only a range of geohash. The information archived into various databases is retrieved, filtered, and is aggregated into meaningful information by the core component of Crowd server. Information related to events is geo-hashed which will then be pushed to the subscribed devices using Googles Cloud to device messaging service. Using REST API, the updated information, integrated

   with Google maps and traffic layers, is also viewable using standard web browser. Our system is implemented using PHP. For repositories and maps, we make use of MySQL in PHP and PHP-Google-map-api version 3.0 in Google maps. Currently, we are investigating algorithms for data aggregation and traffic predictions.

2. Localized Device Messaging

Crowd generates large volume of information, then aggregated with other sources to generate events for any geohash grid. The Crowd subscribe respective interested grid(s) for potential notifications. These notifications can be pulled by the mobile phone or pushed by the processing server to the mobile phones. In CrowdITS, we adopt the push mechanism since it is energy-efficient and has lesser communication overhead for mobile phones. To enable this we integrated the Crowd with the Cloud based messaging service provided by Google, namely Cloud to Device Messaging (C2DM), shown in Fig. 5.

The mobile phone registers with C2DM, using an email address, and receives a registration ID (Step-1). The Registration ID (R-ID) is unique for each device and applica- tion pair therefore allowing multiple applications to utilize C2DM services. The R-ID is sent to CrowdCS server (Step-2) where it is logged into central database. The Crowd server authenticates to C2DM server (step-3) and receives an AUTH token. In case of notification for any mobile phones, measured by any updates on the subscribed geohash by CS associated R-ID, the Crowd server pushes the event data onto C2DM using CS own AUTH token and mobile phone R- ID (step-4). The C2DM internally authenticates the tokens, routes the message to appropriate server and subsequently queues it (steps 6-8). The message is eventually pushed out to the mobile phone using a persistent CP/IP session (step-9). Currently, the C2DM service is available only for the Android devices.

In this section, we describe the development of an important and fundamental CS application, i.e., traffic re-routing to avoid congestions.

It is estimated that the annual cost of congestion for each driver is approximately $1000 and $200 for large and small cities, respectively. Traffic reporting, beside other solutions, is in-use to assist commuters to anticipate and avoid traffic problems. Conventionally, video cameras and radio/TV for messages collection and their broadcast respectively have been Shown are

GPS traces using, red star is a collision reported seconds before the vehicle reaches used. However, such messages are usually macro-level infor- mation, outdated, and do not provide drivers with an alternate congestion free path. Certain mobile phone-based navigational applications, e.g., Google maps, provide traffic layers that may not be up-to-date or complete. These shortcomings are due to their pervasive mode of operation as only the certain kinds of events are reportable. Fig. 6 shows snapshot of GPS traces, using GPS with Google maps and Crowd congestion-free path re-routing application. An event, e.g., collision, shown as red star, is logged by the Crowd minutes before reaching it. GPS-based navigational applications fail to recognize any such conditions (Fig 6-a) whereas Crowd finds an alternate congestion free path and guided the driver promptly (Fig 6-b).

We have developed the congestion free path re-routing application for both Android and iPhone platform. The main interface snapshots are shown in Fig. 3 and Fig. 6-b for Android and iPhone, respectively. To provide congestion free path re-routing, the application makes use of Google Maps, CrowdITS, CloudMade and C2DM APIs. Using the main screen, shown in Fig. 3-a, user enters (with auto-complete) the destination address. The entered address is communicated to Google maps server, as HTTP request, and in return receives JSON formatted responses containing all possible matching addresses. The user current GPS position and the final picked address, from the matches, is used as the path source and destination, respectively.

Using REST, the source and destination pair along with other necessary options is sent to the CloudMade server. The CloudMade server returns JSON response that includes navigational information in the form of latitude longitude pairs for the desired destination. These pairs are converted to their respective geohashes which, along with the R-ID (obtained from C2DM; explained in Section III- C), is used to subscribe. for event notifications with CrowdITS. The driver navigates using the obtained path information, as the application speak out the directions at appropriate geo-locations. The parsed JSON responses are also used to plot the route using Google maps. Driver, in case if it see an event of interest, can report using either command or touch interface, as explained in Section III-A.

Google C2DM

2

mobile phone

C2DM

9 Message

Server

1

6

CrowdITS

SERVER

4 C2DM

Frontend

3

8 C2DM

Message

Queue

7

5 Client Login Service

Fig. 5: Integration of the GooglesC2DM with croud ITS

Upon receiving any notification in the form of latitude longi- tude pair(s), from the Google C2DM, the CloudMade request is re-initiated. The notifications are uploaded into C2DM by the CrowdITS, as it collect and aggregates from Crowd and other sources. The newly formed CloudMade request contains the initial destination, current GPS location and the notified latitude and longitude pairs. In case of any path change, a freshly calculated geohash zones are used to re-subscribe to the Crowd server and the driver are re-navigated accordingly. This process is repeated till the destination. The overall process is shown in Fig. 7. As an alternate to mobile phone notification, the Crowd server provide web interface to the aggregated traffic information. Fig. 8 is a snapshot of the Crowd webpage showing aggregated view of Crowd posted events (red), MTO logged events (orange) and traffic layers using Google maps.

V. CONCLUSION S

Intelligent Transportation Systems (ITS) is an active area of research and development in government, academic and indus- trial sectors. In this paper, we advocate the use of Crowdsourc- ing for non-real-time applications. Motivation is to enable these applications without the needs of deploying sophisticated sensors on the roads or complex communication devices within the vehicles. We describe the design of Crowdsourcing in ITS; namely, CrowdITS, explains various architectural components

and report on the application development of congestion free path re-routing, for the Android and iPhone mobile phones. Numerous technical and non-technical challenges still need to be overcome in order to adopt Crowdsourcing at a wider scale within CS applications. Main research challenges are to device efficient data aggregation and verification algorithms, traffic prediction and efficient interface design for Crowd reporting. As future work, we plan to evaluate and report on the wide-scale deployment and performance of the Crowd system while developing other exciting CS applications.

Fig. 6: Comparison of the Google maps and Crowd path.

REFERENCE S

1. R. Bishop, Intelligent Vechicle Technology and Trends. Artech House Publishers, 2005.

2. Y.-B. Ko and N. H. Vaidya, Location-aided routing (lar) in mobile ad hoc networks, Wireless Networks, vol. 6, no. 4, pp. 307321, 2000.

3. D. Niculescu and B. Nath, Trajectory based forwarding and CS apple- captions, in Proceedings of the 9th annual international conference on Mobile computing and networking, 2003, pp. 260272.

4. P. Costa, D. Gavidia, B. Koldehofe, H. Miranda, M. Musolesi, and O. Riva, When cars start gossiping, in Proceedings of the 6th workshop on Middleware for network eccentric and mobile applications, 2008, pp.

   14.

5. J. Zhao and G. Cao, Vadd: Vehicle-assisted data delivery in vehicular ad hoc networks, in Proceedings of the 25th IEEE International Conference on Computer Communications, 2006, pp. 112.

6. T. Spyropoulos, K. Psounis, and C. S. Raghavendra, Spray and wait: an efficient routing scheme for intermittently connected mobile networks, in Proceedings of the ACM SIGCOMM workshop on Delay-tolerant networking, 2005, pp. 252259.

7. Z. J. Haas, J. Y. Halpern, and L. Li, Gossip-based ad hoc routing,

   IEEE/ACM Transaction on Networking, vol. 14, no. 3, pp. 479491, 2006.

8. W. Zhao, M. Ammar, and E. Zegura, A message ferrying approach for data delivery in sparse mobile ad hoc networks, in Proceedings of the 5th ACM international symposium on Mobile ad hoc networking

   and computing, 2004, pp. 187198.

9. J. Howe, Crowdsourcing: Why the Power of the Crowd Is Driving the

   Future of Business. Crown Business, 2009.

10. M. J. Franklin, D. Kossmann, T. Kraska, S. Ramesh, and R. Xin, Crowddb: answering queries with crowdsourcing, in Proceedings of the international conference on Management of data, 2011, pp. 61 72.

11. A. Ordanini, L. Miceli, M. Pizzetti, and A. Parasuraman, Crowd- funding: Transforming customers into investors through innovative ser- vice platforms, Journal of Service Management, vol. 22, no. 4, pp. 443470, 2011.

12. J. Surowiecki, The Wisdom of Crowds.

Fig. 8: Webpage snapshot, using Google map view , of integrated Crowd events, MTO logged events, and Googles traffic layers