ABSTRACT child gets lost while watching a parade in the middle of a Mobile crowdsensing is becoming a vital technique for envi- large city. The distraught parents, upon noticing their child ronment monitoring, infrastructure management, and social is missing, immediately use their smartphone to initiate a computing. However, deploying mobile crowdsensing appli- search, providing sample images with their child’s face. A cations in large-scale environments is not a trivial task. It crowdsensing search application tries to match these with creates a tremendous burden on application developers as the videos and images being captured by the many smart- well as mobile users. In this paper we try to reveal the phone cameras in the crowd. Any potential matches are barriers hampering the scale-up of mobile crowdsensing ap- forwarded to the parents’ phone, along with GPS location plications, and to offer our initial thoughts on the potential information. With thousands of electronic eyes applied to solutions to lowering the barriers. this problem, the child is quickly found, before she herself is even aware of being lost. For this use case, the large number of smartphone cameras in use makes it likely the 1. INTRODUCTION child appears in one or more captured images; however, the In recent years, there has been phenomenal growth in the crowdsensing search application itself can succeed only if a richness and diversity of sensors on smartphones. It is now sufficiently large number of smartphone users participate. common to find two cameras, a GPS module, an accelerom- More generally, there is a growing realization that scale is eter, a digital compass, a gyroscope and a light sensor in a the key to the success of crowdsensing applications. Since in- single smartphone. And there is more to come! The rich dividual users may go offline and individual sensor readings information about the smartphone user’s activity and envi- may be inaccurate or corrupted, the reliability and trustwor- ronment provided by these sensors inspired the first wave of thiness of crowdsensing applications scales more than pro- sensing applications that personalized user experience based portionally with the number of users. Access to a vast user on the sensed context. Now, a second wave of mobile sensing base is thus crucial. However, our survey of the literature applications is gaining momentum. The focus has shifted shows that today’s mobile crowdsensing applications using from individual sensing towards crowdsensing, defined as physical sensors like GPS have rarely been scaled up to more “individuals with sensing and computing devices collectively than 1,000 participants. sharing information to measure and map phenoma of com- Table 1 shows a representative sample of crowdsensing mon interest” [10]. Initially, crowdsensed inputs were ana- studies. Much to our surprise, the number of participants is lyzed offline, for example in the analysis of transportation often omitted in the papers reporting these studies. When activities in urban spaces [34], for the measurement of inter- concrete numbers are provided, the crowd sizes are usually person similarity [14], or for mental and physical health as- small. It is only with data sources that are easy to collect sessment of elder people [23]. In more recent crowdsensing (e.g. from social networking applications such as Twitter) applications, the collected inputs are processed in real time. that larger crowds have been studied. The one notable ex- Examples include traffic monitoring [35, 36], public safety ception is the work of Balan et al [2], discussed in Section 2. management [27], and collaborative searching [31]. What limits the scaling of crowdsensing applications? In A hypothetical use case serves to illustrate the potential this paper, we explore this issue and and propose an archi- benefits of crowdsensing using information-rich multimedia tectural solution. We then explore the merits of this archi- sensors and some potential pitfalls [25]. Imagine that a small tecture, and discuss potential implementation challenges.
2. OBSTACLES TO CROWD SCALING Permission to make digital or hard copies of all or part of this work for Crowdsensing applications, including the ones that exist personal or classroom use is granted without fee provided that copies are today and the emerging class of applications making use not made or distributed for profit or commercial advantage and that copies of richer multimedia sensors, face three major barriers to bear this notice and the full citation on the first page. To copy otherwise, to achieving the large crowd sizes critical to their success. republish, to post on servers or to redistribute to lists, requires prior specific The first obstacle is the heterogeneity of sensing hard- permission and/or a fee. HotMobile’13, February 26–27, 2013, Jekyll Island, Georgia, USA. ware and mobile platforms. In today’s mobile device market, Copyright 2013 ACM 978-1-4503-1421-3/13/02 ...$15.00. there are at least three popular software platforms, includ- Reference Mobile Platform Application Category Crowd Size Input Zhou et al. [35] (Mobisys 2012) Android Transportation unknown cell tower ID, audio signal accelerometer Tiramisu [36] (CHI 2011) iOS Transportation 28 GPS SignalGuru [12] (MobiSys 2011) iOS Transportation 13 video frames Balan et al. [2](Mobisys 2011) Car GPS Transportation 15000 GPS Mathur et al. [16] (Mobisys 2010) Car GPS Transportation 500 GPS Niu et al. [20] (Com.geo 2011) Blackberry Transportation unknown GPS Bao et al. [3] (Mobisys 2010) Symbian, iPod Social Application unknown video Wirz et al. [30] (SCI 2011) Android Social Application unknown GPS CrowdSearch [31] (Mobisys 2010) iOS Search unknown image GeoLife [34] (WWW 2009) GPS phones User Behavior Study 107 GPS SoundSense [15] (Mobisys 2009) iOS User Behavior Study unknown audio stream #EpicPlay [28] (CHI 2012) Twitter Social Application unknown tweets Wakamiya et al. [29] (ICUIMC 2012) Twitter User Behavior Study 39898 tweets Fujisaka et al. [9](ICUIMC 2012) Twitter User Behavior Study 8139 tweets CrowdSearcher [5] (WWW 2012) Facebook Search 137 text
Table 1: Representative Sample of Crowd-sensing Applications ing Android, iOS and Windows 8. Applications written for for it to be useful. Rapid, large-scale deployment, as in the any of these can not be run on the others. Even different lost child usage scenario above, is impossible with an install- versions of a particular platform are sometimes incompati- based deployment model. Users also have to be tolerant ble, due to changes in hardware or evolution of the software of the processing, memory, and battery life these applica- APIs. Furthermore, the Apps model in vogue today, along tions consume. Because today’s mobile operating systems with the relatively low processing power of mobile devices, are designed to shield applications from each other, each has encouraged smaller, stand-alone applications, and dis- application is meant to be self-contained and does not share couraged the development of external libraries, middleware, information with others. In addition, some sensors, such as and virtualization techniques to bridge the differences be- cameras, need to be exclusively locked before use. Partici- tween platforms. There is no sign that a single platform will pating in more than one crowdsensing application at a time dominate this fragmented market in near future. For true is therefore not easy, even if a user is positively inclined. ubiquity, application developers need to write, test, support, The third obstacle, which primarily affects future appli- and maintain versions of their applications for all of these cations, is the increasing network bandwidth demands of platforms. In a sense, the complexity of the crowdsensing emerging crowdsensing applications. Table 1 shows that application space grows with cross product of the number of the GPS data has been the most widely used sensing in- platforms and the number of applications. formation in the existing crowdsensing applications. How- This issue of heterogeneity is underscored by the experi- ever, looking ahead, we envision growing use of data-rich, ence of Balan et al. [2], who conducted one of the largest multimedia sensing information like video [1] in emerging crowdsensing studies to date. It took them six months to applications such as augmented reality, or the video-based deploy one version of their GPS-based crowdsensing applica- lost child locator discussed above. These applications not tion on 15,000 taxis in Singapore, mainly due to the hetero- only demand far more computing power, but also far more geneity of the on-car GPS devices provided by different ven- network bandwidth to send data to the cloud infrastructure. dors. Web-based applications implemented in HTML5 are Based on data rate analysis of 80 videos on YouTube cap- sometimes put forward as a “write once, run everywhere” al- tured from a first-person viewpoint, each participant in a ternative. Unfortunately, the HTML5 sensor APIs available video-based crowdsensing application will upload between on mobile browsers are still quite limited and the support 0.6 Mbps (360p resolution) and 5.6 Mbps (1080p resolu- for different sensors varies from browser to browser and from tion). With many users, such an application can easily over- platform to platform. While geolocation tracking using GPS whelm link capacity in regional networks and into datacen- is widely supported in the up-to-date mobile browsers, ac- ters. For example, Verizon recently introduced state-of-the- cessing the microphone and video cameras is not possible in art 100 Gbps links in their metro networks [21], yet these are most cases [17]. In practice, due to the potential incompat- only capable of supporting 1080p streams from just 18000 ibility between browsers (e.g. the inconsistent support for users. A broadly-deployed application with 1 million users audio and video codecs), developers still have to customize will require 1–2 Tbps, 200x the total upload bandwidth of their code for different browsers in some cases. all YouTube contributors [33] today. An application model The second obstacle is the burden today’s crowdsensing where each device sends data to centralized servers (as is applications place on users. Today, each user must install a typical today) cannot scale to support data-rich sensors. En- separate proprietary application for every crowdsensed ex- suring the scalability of crowdsensing with data-rich sensors periment in which s/he wishes to participate. As a result, requires rethinking application and cloud architectures to the deployment of a single crowdsensing application is lim- acquire, process, and aggregate such data efficiently. ited by the rate at which users adopt and install it on their Ultimately, all three of these obstacles are ramifications of devices. It can take weeks or months for a newly introduced the deployment model in vogue today, where participation application to reach the critcial mass of participants needed in each crowdsensing activity requires a separate application a single application is responsible for collecting sensor data P Proxy VM (one per mobile user) and communicating it to the proxy VM. This application can Clone of Application VM (one A B be either implemented as a native application, or -if a good per application per user) Cloud mobile browser is available on the device- as a HTML5 web Master Application VM (optional; M Application one per cloudlet) Server application. The proxy VM is essentially an extension of Private virtual network the mobile device into the cloudlet, and can perform custom Sensing data stream data preprocessing, e.g., to enforce privacy settings or handle quirks of the mobile platform, and enforce user preferences on data sharing and crowd participation. From here, data A is forwarded to one or more application VMs also running M B A on the cloudlet infrastructure. P P Application VMs perform data processing steps specific A to each crowdsensing application. Each application VM A hosts a single crowdsensing application, which is not cus- Sensing data P P tomized to any particular mobile platform. Generally, for
Mobile device each crowdsensing activity, one application VM is assigned to each participant, making it easy to migrate a user’s proxy VM together with the associated application VMs, preserv- Figure 1: System Architecture. ing any hard state they may contain. If an application does not need to maintain hard state for each user, then a single application VM can be shared by all users on a particular that must be installed and run on user devices, and directly cloudlet. communicates to central servers. To overcome these obsta- The application VMs for each sensing service are deployed cles, we must rethink the structure and deployment model by a coordinating entity on the highest layer in our archi- used in crowdsensing applications. tecture, typically by the application server running on the centralized cloud infrastructure. In practice, when many 3. PROPOSED SOLUTION application VMs are run on each cloudlet, the application We propose a crowdsensing deployment model built around server can initiate a master application VM (MAVM) on 3 core design principles: each cloudlet and delegate management and data aggrega- tion tasks. The MAVM will coordinate, clone, and config- • separation of data collection and sharing from application- ure the application VMs on the cloudlet, and aggregate data specific logic. within the cloudlet before forwarding results. Depending on • removal of application installation on smartphones from the application, the MAVMs on multiple cloudlets may form the critical path of application deployment. a peer-to-peer overlay network / tree to scalably aggregate data to the central application server. • decentralization of processing, and data aggregation Our deployment model is predicated on two assumptions. near the source of data. First, this architecture depends on distributed cloud infras- tructure near the user. The vision of executing customized These design principles address the obstacles discussed above. VMs on nearby infrastructure has been articulated many By construction, our proposed solution overcomes the key times, e.g. in [8] and [11]. It has also be argued that of- barriers to scaling up crowdsensing applications. floading to nearby computing infrastructure (cyber foraging) 3.1 System Architecture is needed for compute-intensive and latency-sensitive mobile applications [4] for the purpose of energy savings and latency The 3-tier system architecture of our deployment model reduction. Our concept of distributed cloud infrastructure is illustrated in Fig. 1. The first layer is composed of mobile to host proxy and application VMs fits perfectly in this vi- devices, whose roles are essentially reduced to that of (multi- sion. input) sensors forwarding captured data to proxy VMs in Second, our approach assumes a standard API exists for the second layer. The second layer comprises of distributed the data transfer between the proxy VM and the associated cloud infrastructure deployed close to the mobile devices, application VMs. However, we argue this is a much eas- typically in the access or aggregation network of Wi-Fi or ier task to accomplish than having to write an individual cellular network providers. The concept of distributed cloud application for each mobile platform (and possibly for each infrastructure here is akin to the concept of cloudlet pre- individual version of the mobile platform). Indeed, the out- sented in [26]. In practice, this can be a private cloud owned put of scalar sensors can be represented as a few integers by a business or community, or a small data center such as (e.g. GPS coordinates, temperature value, ...), and stan- Myoonet’s Micro data center [18] that is deployed by a cloud dards for multimedia data (e.g., video formats) already ex- operator. For the sake of simplicity, we will refer to this dis- ist. Combining such data with standardized XML format tributed cloud infrastructure as cloudlets in the remainder descriptions, one can establish a standard for communica- of this paper. tion between proxy VMs and application VMs. In fact, sev- Each proxy VM is associated with a single mobile device, eral programming frameworks for crowdsensing applications and is kept physically close to the mobile device through VM have proposed solutions to abstract sensing information [32, migration to other cloudlets or public clouds. This ensures 24] and task description [22]. These programming frame- network resources to transfer data from the mobile device is works can be leveraged in our model as well. minimized. The proxy VM handles all the requests for sensor data on behalf of the mobile device. On the mobile device, ④ get a list of proxy VMs practice, these can simply be clones of the MAVM, that can provide images ② get a list of cloudlets located in the target area ⑥ request for application operating in a different mode. App VM creation Registry Server ⑦ configure the new application VM 7. The MAVM configures the networking setup of the ap- ① send task description plication VMs, while the the proxy VM will add the ③ create a master new application VM to the subscriber list. application VM Task Generator When the above steps are finished, the proxy VMs will ④ ⑥ Cloudlet Local M Example Task Description: start forwarding images and videos to the application VMs, Registry ⑦ Daemon Fifth Avenue , New York which will apply face detection and forward potential matches ⑤ P A VM Monitor face detection smartphone. We believe our architecture has the potential ⑤ get permission to bootstrap large crowds in just a matter of minutes, mak- from user through photo_1.img ing this on-demand crowdsensing use case possible. the proxy VM photo_2.img worker 3.3 Benefits of Our Design Our deployment model is architected to support scalable, efficient data sharing between multiple applications and users, Figure 2: Workflow of crowd bootstrap. while reducing the burden on application developers and end users. It scales up crowdsensing tasks by making it easier to 3.2 Crowd Bootstrap access data from a larger pool of diverse smartphones, allow users to simultaneously particpate in multiple applications, Let’s revisit the lost child scenario from Section 1 to see and support rich, high-data-rate sensors at global scale. how a crowdsensing task can be rapidly bootstrapped using Separating the process of data collection and sharing from our deployment model. As shown in Fig. 2, the process of application-specific processing, our system lets developers crowd bootstrap can be summarized in the following seven focus on the latter, rather than porting their application to steps. a myriad of mobile platforms and understanding the idiosyn- 1. The task generator (here, it is the parents’ smart- chrasies of each. In fact, our deployment model increases the phone) constructs and sends a task description to the choices in programming languages, as the application is self- application server, typically located in the public cloud. contained in its application VM and does not have to meet The actual format of this can be application-specific, specific compatibility constraints for mobile platforms. Sim- but is shown as an XML snippet here. The critical ilarly, the developer is free to use a variety of programming information includes type of search (face detection), models to distribute computation and aggregate results, and the sample images, and a location area to scope the not forced to use a one-size-fits-all paradigm. Deploying search. How this description is constructed and com- VMs to users boils down to rapid cloning of the application municated is also left to the application, e.g., with a VMs on cloudlets, regardless of the mobile devices. front-end app on the phone, or through a web-form on In our architecture the personal data of the users is stored the application server. and processed on their own proxy VMs. According to [7] this approach provides a higher degree of privacy if compared to 2. The application server parses the task description, and the traditional approach of storing and processing the data consults a global registry for a list of cloudlets that are using centralized third party services. Our framework also located in the target area. allows flexibility in partitioning work between the proxy VM 3. The application server contacts the cloudlet daemon and mobile device. For example, supporting multiple appli- on each target-area cloudlet, and requests a MAVM in- cations with differing fidelity or resolution requirements si- stance be created. It forwards the VM disk image and multaneously will entail some amount of preprocessing; this memory snapshot to launch the MAVM. In practice, can be done in the proxy VM, mobile device, or a combina- techniques employing demand paging or VM synthesis tion of both depending on hardware capabilities, processing can minimize overheads of launching the MAVM. overheads, and energy availability. Our approach reduces the burden on users and their mo- 4. The MAVM on each target cloudlet uses a cloudlet- bile devices for participating crowdsensing. First, instead of local registry to discover proxy VMs connected to de- installing individual apps on their devices for each crowd- vices that can provide the desired sensor data (here, sensing application, users only need to install one app that videos and images). allows users to participate in different crowdsensing applica- 5. The MAVM requests participation from the mobile tions. Users can join a crowd by simply granting permission, users through the proxy VMs. Depending on user- and if willing, can direct their proxies to automatically par- defined policies, the proxy may require explicit permis- ticipate in some forms of crowdsensing. When a user leaves a sion from the user, or the proxy VM can automatically crowd, the application VM is simply destroyed, and does not join crowds on behalf of the user when particular cri- require additional attention from the user. Second, demands teria are met (e.g., share video when in a public space, on the mobile device can also be reduced, as processing is but not audio). offloaded to the cloud, and only a single copy of the sensor data is uploaded even when participating in multiple appli- 6. Once permission is granted, the MAVM will request cations. The potential reduction in data transmission helps the cloudlet daemon to create application VMs. In save energy for users’ mobile devices. Lastly, our design performs processing and data aggrega- lutions may not provide adequate performance in our en- tion close to the data sources. This brings two benefits: 1) it visaged scenarios. Non IP-based solutions such as the Host reduces traffic on wide-area networks; 2) it reduces network Identify Protocol [19] have been designed from scratch with latency by avoiding long-distance data transmission through these limitations in mind, but these protocols still need to the backbone networks. This makes it possible to scale up be evaluated in real networks. The deployment of these is crowdsensing with high-data-rate sensors. VM migration unlikely to be easy, given the fact that today’s Internet is can ensure that processing remains close to data source even built almost exclusively on the TCP/IP stack. as users move around. 4.3 Standardization of Sensing Interfaces 4. CHALLENGES Sensor data is distributed from the proxy VMs to the There are several technical hurdles in the path of a real- application VMs through a publish-subscribe mechanism. world deployment of our proposed architecture. We discuss Standard sensor data descriptions are needed to realize com- these below. munication between proxy VMs and application VMs of var- ious developers. As discussed in Section 3.1, some efforts [32, 4.1 Virtualization Overhead 24] have been invested on developing such interfaces, how- Leveraging virtualization allows us to create a flexible ever, unfortunately so far no consensus has been made yet. platform in a multi-party setting where user privacy, scal- Another challenge lies in the fact that different crowd- ability and isolation between crowdsensing applications are sensing applications might be built on the same sensor data, key requirements. These advantages come at the price of but require a different format or sample rate. However, the both VM creation overhead and the need for more advanced sensor data collected from the devices provided by different inter-VM communication management. In our design, a new vendors may not be able to always provide the data in the clone of the application VM is instantiated for each user join- right format or at the right sample rate. ing the crowd. Ideally, this new VM should start as fast as There is a trade-off to be studied on whether the conver- possible with minimal cost on resources. In practice, when sion from the original sensor data to the requested output a VM Monitor starts a new VM, it must first reserve all of format(s) must be done on the mobile device, the proxy VM the memory resources needed for the VM. This constraint or inside the application VM itself. At first sight, running prevents rapid creation of multiple VMs concurrently. inside the application VM is the most logical choice, as it One way to solve this problem is to reduce the num- removes as much logic as possible from the mobile device ber of running VMs by replacing the per-user application and the proxy VM. However, this results in a lack of syn- VMs with one multiplexing application VM on each cloudlet. chronization and a potential waste of resources. For exam- However, this will introduce the complexity of process mi- ple, what if all currently running application VMs only need gration in mobile scenario when any hard state contained in camera frames at 10 fps, while the mobile device emits at a the application VMs must be preserved. An alternative way standard 30 fps? In this case, it would make sense to put is to reduce the overhead of VM creation through advanced downsampling application logic on the mobile device, and to cloning mechanisms. There are several efforts that try to put logic in the proxy VM that can configure the sensor cap- reduce the memory copy overhead by cloning the memory turing on the mobile device. When a new application VM from running VMs. SnowFlock [13] proposes to fetch mem- is deployed needing 15 fps, the proxy VM may instruct the ory on demand while cloning VMs. It manages to clone 32 mobile device to increase its frame rate accordingly. Sup- clones in 32 different hosts within one second by combin- port for device-level configuration may vary significantly by ing on-demand fetching with TCP multicasting for network platform and specific sensor hardware, so proxy VMs need scalability. Kaleidoscope [6] takes this one step further by to be designed to abstract away such differences. discriminating VM memory state into semantically related regions to achieve prefetching and efficient transmitting. 5. CONCLUSIONS An additional challenge is configuration and performance This paper has argued that the existing deployment model of inter-VM communication. The performance of inter-VM for crowdsensing applications does not support either effi- communication is relatively low compared to inter-process cient crowd scaling over heterogeneous mobile platforms or communication. When the system workload on the cloudlet the data sharing between crowdsensing applications. While increases, this may result in delayed transmission of sensor VM-based cloudlets have been widely studied and utilized data between proxy and application VMs. Note that this for computation offloading, we explore the potential uses of low performance is due to inefficient CPU scheduling of the VM-based cloudlets for lowering the barriers to scaling up host, as the physical network interface is not touched by crowdsensing applications. Our solution leverages the exist- inter-VM traffic. ing programming frameworks for crowdsensing applications. There are still several challenges that must be addressed be- 4.2 Migration-induced Reconfiguration fore this kind of deployment model can be adopted, we are Physical mobility of a device may trigger the migration of implementing the deployment platform with specific focus the proxy VM and the associated application VMs that are on the research challenges discussed in this paper. not stateless. Consequently, the IP address of the mobile de- vice as well as those of the VMs may change. To maintain es- 6. ACKNOWLEDGMENTS tablished connections between mobile device and proxy VM, as well as between proxy VMs and application VMs, auto- We are grateful to the anonymous reviewers and our shep- herd Nina Bhatti for their valuable comments and feedback, mated advanced network reconfiguration is needed. This which helped to improve the final version. This research potentially includes network addressing, NAT settings and was supported by the National Science Foundation (NSF) firewall setup in VMs. Due to this overhead, IP-based so- under grant numbers CNS-0833882 and IIS-1065336, by an Intel Science and Technology Center grant, by the Depart- road-side parking statistics. In Proc. of MobiSys ment of Defense (DoD) under Contract No. FA8721-05-C- (2010). 0003 for the operation of the Software Engineering Institute [17] Mobile HTML5. http://mobilehtml5.org, 2013. (SEI), a federally funded research and development center, [18] MYOONET. Unique scalable data centers. and by the Academy of Finland under grant number 253860. http://www.myoonet.com/unique.html, 2011. Any opinions, findings, conclusions or recommendations ex- [19] Nikander, P., Gurtov, A., and Henderson, T. pressed in this material are those of the authors and do not Host identity protocol (hip): Connectivity, mobility, necessarily represent the views of the NSF, Intel, DoD, SEI, multi-homing, security, and privacy over ipv4 and ipv6 Carnegie Mellon University or Academy of Finland. This networks. Communications Surveys Tutorials, IEEE material has been approved for public release and unlimited 12, 2 (2010), 186 –204. distribution except as restricted by copyright. [20] Niu, Z., Li, S., and Pousaeid, N. Road extraction using smart phones gps. In Proc. of COM.geo (2011). [21] PC World. http://www.pcworld.com/article/ 7. REFERENCES 255519/verizon_to_offer_100g_links_resilient_ [1] Bahl, P., Philipose, M., and Zhong, L. Vision: mesh_on_optical_networks.html, 2012. cloud-powered sight for all: showing the cloud what you see. In Proc. of MCS (2012). [22] Ra, M.-R., Liu, B., La Porta, T. F., and Govindan, R. Medusa: a programming framework for [2] Balan, R. K., Nguyen, K. X., and Jiang, L. crowd-sensing applications. In Proc. of MobiSys Real-time trip information service for a large taxi (2012). fleet. In Proc. of MobiSys (2011). [23] [3] Movi: mobile Rabbi, M., Ali, S., Choudhury, T., and Berke, Bao, X., and Roy Choudhury, R. E. Passive and in-situ assessment of mental and phone based video highlights via collaborative sensing. physical well-being using mobile sensors. In Proc. of In Proc. of MobiSys (2010). UbiComp (2011). [4] Bonomi, F., Milito, R., Zhu, J., and Addepalli, [24] Fog computing and its role in the internet of things. Ravindranath, L., Thiagarajan, A., S. Balakrishnan, H., and Madden, S. Code in the In Proc of MCC (2012), pp. 13–16. air: simplifying sensing and coordination tasks on [5] Bozzon, A., Brambilla, M., and Ceri, S. smartphones. In Proc. of HotMobile (2012). Answering search queries with crowdsearcher. In Proc. [25] Satyanarayanan, M. Mobile computing: the next of WWW (2012). decade. In Proc of MCS (July 2010). [6] Bryant, R., Tumanov, A., Irzak, O., Scannell, [26] Satyanarayanan, M., Bahl, P., Caceres, R., and A., Joshi, K., Hiltunen, M., Lagar-Cavilla, A., Davies, N. The case for vm-based cloudlets in mobile and de Lara, E. Kaleidoscope: cloud micro-elasticity computing. IEEE Pervasive Computing 8, 4 (Oct. via vm state coloring. In Proc. of EuroSys (2011). 2009). [7] Caceres,´ R., Cox, L., Lim, H., Shakimov, A., and [27] Shah, S., Bao, F., Lu, C.-T., and Chen, I.-R. Varshavsky, A. Virtual individual servers as Crowdsafe: crowd sourcing of crime incidents and safe privacy-preserving proxies for mobile devices. In Proc routing on mobile devices. In Proc. of ACM of MobiHeld (2009), pp. 37–42. SIGSPATIAL GIS (2011). [8] Cuervo, E., Balasubramanian, A., Cho, D.-k., [28] Tang, A., and Boring, S. #epicplay: Wolman, A., Saroiu, S., Chandra, R., and Bahl, crowd-sourcing sports video highlights. In Proc. of P. Maui: making smartphones last longer with code CHI (2012). offload. In Proc. of MobiSys (2010). [29] Wakamiya, S., Lee, R., and Sumiya, K. [9] Fujisaka, T., Lee, R., and Sumiya, K. Discovery of Crowd-sourced urban life monitoring: urban area user behavior patterns from geo-tagged micro-blogs. characterization based crowd behavioral patterns from In Proc. of ICUIMC (2010). twitter. In Proc. of ICUIMC (2012). [10] Ganti, R. K., Ye, F., and Lei, H. Mobile [30] Wirz, M., Strohrmann, C., Patscheider, R., crowdsensing: current state and future challenges. Hilti, F., Gahr, B., Hess, F., Roggen, D., and IEEE Communications Magazine 49, 11 (2011). Troster,¨ G. Real-time detection and [11] Kosta, S., Aucinas, A., Hui, P., Mortier, R., and recommendation of thermal spots by sensing collective Zhang, X. Thinkair: Dynamic resource allocation and behaviors in paragliding. In Proc. of SCI (2011). parallel execution in the cloud for mobile code [31] Yan, T., Kumar, V., and Ganesan, D. offloading. In Proc of INFOCOM (2012). Crowdsearch: exploiting crowds for accurate real-time [12] Koukoumidis, E., Peh, L.-S., and Martonosi, image search on mobile phones. In Proc. of MobiSys M. R. Signalguru: leveraging mobile phones for (2010). collaborative traffic signal schedule advisory. In Proc. [32] Ye, F., Ganti, R., Dimaghani, R., Grueneberg, of MobiSys (2011). K., and Calo, S. Meca: mobile edge capture and [13] Lagar-Cavilla, H. A., Whitney, J. A., Scannell, analysis middleware for social sensing applications. In A. M., Patchin, P., Rumble, S. M., de Lara, E., Proc. of WWW Companion (2012). Brudno, M., and Satyanarayanan, M. Snowflock: [33] YouTube. rapid virtual machine cloning for cloud computing. In http://www.youtube.com/t/press_statistics, 2012. Proc. of EuroSys (2009). [34] Zheng, Y., Zhang, L., Xie, X., and Ma, W.-Y. [14] Lane, N. D., Xu, Y., Lu, H., Hu, S., Choudhury, Mining interesting locations and travel sequences from T., Campbell, A. T., and Zhao, F. Enabling gps trajectories. In Proc. of WWW (2009). large-scale human activity inference on smartphones [35] Zhou, P., Zheng, Y., and Li, M. How long to wait?: using community similarity networks (csn). In Proc. of predicting bus arrival time with mobile phone based UbiComp (2011). participatory sensing. In Proc. of MobiSys (2012). [15] Lu, H., Pan, W., Lane, N. D., Choudhury, T., [36] Zimmerman, J., Tomasic, A., Garrod, C., Yoo, and Campbell, A. T. Soundsense: scalable sound sensing for people-centric applications on mobile D., Hiruncharoenvate, C., Aziz, R., phones. In Proc. of MobiSys (2009). Thiruvengadam, N. R., Huang, Y., and Steinfeld, A. Field trial of tiramisu: crowd-sourcing [16] Mathur, S., Jin, T., Kasturirangan, N., bus arrival times to spur co-design. In Proc. of CHI Chandrasekaran, J., Xue, W., Gruteser, M., (2011). and Trappe, W. Parknet: drive-by sensing of
