Sahyog: A Middleware for Mobile Collaborative Applications

Transcription

1 Sahyog: A Middleware for Mobile Collaborative Applications Garvita Bajaj Indraprastha Institute of Information Technology New Delhi, India garvitab@iiitd.ac.in Pushpendra Singh Indraprastha Institute of Information Technology New Delhi, India psingh@iiitd.ac.in Abstract The ubiquitous nature of mobile devices offering high computing capabilities has attracted a large number of users. The sensors available on these devices provide valuable data about user contexts, which when combined with sensor data from other mobile devices can reveal interesting environmental contexts, which can then be used for applications like real-time traffic monitoring, noise mapping, crowdmapping, etc. Developing applications for inferring environmental context requires participation from multiple users satisfying certain requirements (e.g., location of users etc.); hence, building such applications requires developers to carefully identify potential collaborators satisfying these conditions. This makes the development of such applications cumbersome and time-consuming. In this work, we present Sahyog 1 a publish-subscribe framework that allows developers to specify these requirements and identify users that can actively participate in such applications. Sahyog helps application developers request data from a large number of users without worrying about reaching out to users, communicating data requests and responses, and storing information. We discuss the design and implementation of our system with the underlying research challenges, and evaluate it using several parameters. Keywords Context-aware applications, crowdsensing, smartphones I. INTRODUCTION Mobile devices like smartphones and tablets have experienced a drastic increase in the number of users over the past few years. Such devices, apart from providing communication and computing capabilities, are equipped with a plethora of sensors that can provide valuable contextual information about users. Further, mobile sensor data of a set of users can be fused together to infer their environmental contexts. Researchers are now focussing on applications that provide environmental contexts of users, e.g. real-time traffic monitoring [1], [2], [3], noise-mapping [4] etc., to make them aware of their surroundings. These applications take advantage of multiple devices present in vicinity to infer contextual information that is otherwise beyond the capability of a single device. For example, SignalGuru [3] uses the data collected by a number of mobile devices present on a road segment to predict schedules of traffic signals ahead. It relies on an infrastructure-less solution to allow collaboration with other devices for predicting the traffic signal schedules, which may be difficult for a single device itself. Such context-aware applications can provide vast 1 The word Sahyog means collaboration in Hindi. information about users and their environment, and require large user participation to accurately predict broader contexts. However, most of the existing context-aware applications are standalone in nature, and developing a similar new application requires developers to start from scratch. They must take into consideration issues like detecting and communicating with unknown devices in requested contexts willing to share their sensor data. This calls for an efficient and secure mechanism for identifying and communicating with unknown devices using a central mechanism, and identifying their contexts. We believe these two segments can be combined at a middleware level to assist developers with the development of such applications. In this work, we identify the requirements for building context-aware collaborative applications and develop a middleware that satisfies these needs. We have implemented our middleware on Android phones with support for location and activity contexts for collecting sensor data. This relieves developers of the hassles of identifying potential collaborators for their context-aware application, allowing them to concentrate better on application logic. We evaluate the performance of Sahyog in terms of power consumption and time requirements for publishing queries. The rest of this paper is organized as follows: We present our system (related literature in Section II) with the basic requirements in Section III-A and implementation details in Section III-B and evaluate it in Section IV. We finally conclude our work in Section V. II. RELATED WORK Several applications take advantage of multiple mobile devices present in surroundings to infer contextual information. For example, EarPhone [4] and NoiseTube [5] utilize the audio data (collected by microphone sensor) to infer noise levels at user locations and construct noise maps. Nericell [1]; VTrack [6]; and Zhou et al. [2] use motion data (collected by accelerometer and GPS sensors) to predict different aspects of road monitoring. Nericell [1] predicts road patterns (bumps and potholes), VTrack [6] predicts most probable road segments taken by users, and Zhou et al. [2] predicts waiting times for buses. Participating users in these applications are unknown to each other in advance for example, a user querying for estimated wait time for a bus may not know passengers onboard that bus. Thus, identifying unknown potential collabora /15/$ IEEE

2 Fig. 1. A scenario describing the flow of information in context-aware applications for inferring environmental contexts from a set of users. tors for collecting sensor data is important for inferring broader contextual information. Several frameworks have been proposed in the literature to allow researchers and application developers to reach out to several users for sensor data collection. BubbleSensing [7] is one such attempt which allocates sensing tasks to devices within bubbles using anchor nodes. MOSDEN [8] platform allows registration of interests at a cloud server to gather sensor data from MOSDEN instances running on smartphones. Application interests refer to a common goal and do not serve user requests individually. Pogo [9] is a middleware that allows researchers to remotely deploy scripts for sensor data collection on multiple mobile devices. Another middleware AnonySense [10], focusses on expressing queries and collecting data reports in a privacy-aware manner using a domain specific language AnonyTL. However, the use of AnonyTL requires a dedicated interpreter which increases the implementation overhead. This problem is resolved by PRISM [11] that uses two-level predicates for specifying queries to execute binary files at mobile ends. In this work, we propose the use of JSON queries for quick and light-weight communication between requesters and providers of data. Our goal is to provide a middleware for application developers to support development of context-aware applications for inferring larger contexts based on user queries using resources present on multiple ubiquitous mobile devices. III. SYSTEM DETAILS In this section, we present a middleware for scenarios similar to those highlighted in Figure 1. A client (requester), in need for some sensor data (to infer some context), issues a query containing certain parameters to the central server using our middleware. The server communicates with relevant providers (i.e. clients willing to share their sensor data) to receive the required response, and forwards the received data to the requester over an agreed protocol. A. Requirements A middleware for implementing the scenario identified above must meet the following requirements: 1) Seamless discovery of relevant devices: While building context-aware applications, it is important to dynamically detect and interact with relevant devices, i.e., capable devices willing to participate in the collaborative task. Therefore, a middleware for developing such applications must provide a mechanism for devices to express their interest in sharing sensor data. 2) Ability to dispatch tasks and collect results: Collaboration requires participating devices to know details of the task to be performed. This requires a simple, lightweight query format indicating different task parameters to reduce storage and interpretation overhead on the devices. 3) Privacy Control: Collaboration may require participating users sensor data such as GPS or audio data. Previous work proves that sensor data is sensitive in nature and can reveal user information [12]. Sharing such sensitive data may raise privacy concerns among users resulting in low participation. To encourage participation, the middleware must provide users with complete control over the information they wish to share and also, ensure user anonymity. Ensuring anonymous communication between users assures them of privacy. 4) Support for real-time collaboration: Collaboration may involve tasks requiring real-time support. For example, request for GPS speeds for users within an area to infer traffic conditions must be addressed in real time as traffic conditions change dynamically. Providing data that is not real-time will no longer serve the purpose of such applications. Also, some applications building on collaboration may work offline. Existing middlewares like Pogo [9] only provide sensor data to the users in an offline manner. We believe that a generic middleware must provide support for applications involving both real-time and offline collaborations among participating devices. B. Implementation Details Sahyog is implemented as a publish-subscribe middleware using Redis [13] for publishing queries and receiving sensor data in light-weight JSON format. The advantages of choosing a pub-sub implementation over other mechanisms are threefold. Firstly, it eliminates the dependency between sender and receiver of messages with the use of an event-manager 2. Since the senders and receivers are decoupled in space domain, i.e., they are unknown to each other; received sensor data cannot be used to identify providers. Secondly, pub-sub implementations are scalable and adhere to dynamic network topology which is essential for developing mobile-based context-aware applications requiring large-scale participation. Thirdly, the concept of subscription topics or channels allows providers to express their interest in sharing sensor data with requesters. Collecting context-aware sensor data from unknown devices is accomplished by the use of following two components in Sahyog: 1) Mobile Devices (Clients): These are the publishers and subscribers of queries or sensor data in the middleware. A client may operate in two modes: Requester: publishing a query for a new data request. Provider: responding to queries of other users by providing them with the required data. 2 Event manager is the message broker or server in a pubsub framework.

3 Fig. 2. Basic system architecture of Sahyog We have implemented the client on Android platform (4.4.2) using Jedis library (a Redis Java client library). 2) PubSub framework (Server): We are using Redis (REmote DIctionary Server) for implementing pubsub functionalities using an Ubuntu virtualbox. Sahyog uses two types of channels to distinguish query requests from sensor data, and requesters from providers: i) Query channels: Requesters publish queries over these channels which are received by providers subscribed to them. Currently, we are using sensor based subscription, so every query channel essentially represents a sensor. For example, requesters requesting for accelerometer data from providers will publish a query to accelerometer query channel to which potential providers are subscribed; ii) Data channels: Providers publish collected sensor data over these channels to which requesters are subscribed. Every requester, after issuing a query, is subscribed to a unique data channel corresponding to that query. The basic system architecture is shown in Figure 2. To initiate sensor data collection, a requester publishes a query to the respective query channel on the Redis server. This query contains various parameters required for identifying suitable devices for collaboration. A query can be expressed either by the use of general purpose language or domain specific language. We prefer to use domain specific language because it is concise and portable. We have developed our query format using JSON which is a light-weight data-interchange format. Figure 3 shows a sample query. The query object consists of two different field types: mandatory and optional. The mandatory fields are used to define the basic fields required for collaboration and their description is as follows: a) userid refers to the unique device ID (IMEI number) of the requester initiating the collaboration, b) queryno refers to a globally unique ID identifying the query request (a combination of the userid and the timestamp at which the query was generated), c) datareqd refers to the sensor name for which the data must be collected, d) fromtime and totime define the beginning and ending time (in UTC format) of the task execution (currently refers to the beginning and ending time of sensor data collection on the participating devices), e) expirytime refers to the time (in UTC format) before which the result must be sent to the requester (this refers to the TTL of the query thread on the server), and f) count field specifies the number of providers which must provide the data to complete the task. count has two subfields: min and max which can be used to specify a range of providers (in cases where the requester can suffice with min number of providers, but would be happy to obtain data from up to max providers). The optional fields Fig. 3. A sample query given with different fields. The query states that user requested for accelerometer data, of 5 minutes duration, from any one user who is driving within 500 meter of the location < , > (IIIT-Delhi, India) between 6:00 PM and 6:30 PM on 31st July, 2013 add extra levels of granularity to the data request. Higher the number of optional fields, better is the context of the provider available. The optional fields in our query format with a brief description of each is as follows: a) frequency refers to the frequency of sensor data collection (the rate at which the sensor must collect the data), b) activity field indicates the context for which the providers must collect data (one of these: driving, walking, running, cycling or still), and c) latitude and longitude refer to the geographical location at which the task must be executed. An Android application can ask users to provide a place, and generate its geographical coordinates using the Geocoder service. The query format can be easily extended to accommodate more fields and support wider range of applications. Instead of following a centralized approach, where providers continuously update their contexts to the server, we follow a model where all intelligence lies at the client end of the framework. Every provider subscribed to a query channel receives query request published on that channel, and extracts location and activity contexts from the query. It compares the requested context with its own context (i.e., location and/or activity). If the contexts match, then the provider collects the requested sensor data, saves it to a file and publishes the file to the respective data channel. Else, the request is discarded by the provider. Currently, the middleware allows queries to request for future sensor data from providers. However, if a request for past-time is received (maybe because of different time zones etc.), the provider discards the request (as it not possible to collect sensor data for a passed time frame). The concept of subscription channels addresses all the requirements highlighted in the previous section. It allows providers to easily express their interest in sharing some sensor data, and requesters to address the right set of providers concerning a query, allowing easy dispatch of queries and data collection. Since all communication between requesters and providers happens over these subscription channels (either query channel or data channel), users are ensured of anony-

4 Fig. 4. Time taken to service query requesting for 10 seconds of accelerometer data from one provider Fig. 5. runs Time taken to publish 100 queries over WiFi network in different mous communication relieving them of underlying privacy concerns. Further, Redis pubsub implementation ensures near real-time delivery of messages and synchronization decoupling ensuring that requesters and providers are not blocked waiting for responses from each other. IV. EVALUATION Our objective is to provide developers with a middleware for easy development of context-aware applications requiring real-time sensor data from ubiquitous mobile devices. Hence, it is essential for Sahyog to perform well in real-time situations. To assess the performance of Sahyog, we conducted several controlled experiments to highlight its strength. Time plays a crucial role in decision making in realtime applications. For example, a traffic monitoring application aimed at providing users with real-time traffic updates will no longer be useful if it provides stale data. We designed our first experiment to assess the applicability of Sahyog to such applications. The goal was to measure the average time taken by the middleware to service a query, i.e., starting from JSON query generation to receiving the first input file on requester. We performed several runs with one subscriber to accelerometer query channel and published queries containing all parameters over college WiFi network (802.11n) with a link speed of 72Mbps. Both requester and provider were NTP clock synchronized. Publisher requested for accelerometer data from one provider starting at 20 seconds from the time of publishing for a duration of 10 seconds. For 40 different runs at same network speed, the first file (average size 31.6 kb) was received within an average of seconds. At times, file was received earlier than 30 seconds because of difference in time clocks on requester and provider. Figure 4 shows the time taken and file sizes of the data samples collected by providers. We were further intrigued to find out if the query service time depends on the file size, for which we measured the correlation between file sizes and query service times. The correlation value was which represents negligible association between them. To further keep track of delay encountered in publishing a query, we performed a controlled experiment with one requester and no provider to measure the exact publishing time for a query. For every run of the experiment, requester issued 100 queries to the server over the same WiFi network. The time Fig. 6. Time taken to publish same query under different network conditions taken by 10 such runs is shown in Figure 5. The top whisker of box plot represents the time taken to issue the first query of the run, and is higher than the remaining values because it requires establishing a WiFi connection with the server. For the remaining 99 queries, since there is already an established data connection, it takes less time. This experiment shows that the average time taken to publish a query is under 0.03s. To monitor the dependency of Sahyog on network conditions, we performed a controlled experiment to measure the time it takes to publish a query over networks with varying data rates. Since publishing a query (including time taken to generate a JSON query) also requires subscribing to a unique channel (over which data is published), we performed the experiments when no subscribers were available. This was done to get a fair idea of the time taken to construct a query packet, transmit it over the network and receive the reply. We performed the experiment under different network conditions and the results are summarized in Figure 6. As shown, the time taken to publish a query depends on the network conditions. With network speeds of 72Mbps over the college WiFi, the average time (over 100 runs) to publish a query was secs, which increased to secs over 3G network (Vodafone 3G network in indoor conditions) a drastic increase of 1422% with change in network conditions. Since Sahyog based applications will run on smartphones (battery constrained devices), it is important to monitor the power consumed by Sahyog. We monitor the power consumed by both requesters and providers involved in query servicing

5 using PowerTutor app [14]. Screenshots obtained are shown in Figure 7. For a requester, power is consumed in two steps: 1) forming the JSON query (using a UI here), and 2) sending the query to the server using WiFi (or 3G) connection. For a provider, power is consumed in three steps: 1) receiving the query from the server, 2) sending acknowledgement to the server, and 3) collecting and sending the required sensor data to the server. Major power is consumed during network activity (WiFi or 3G), but it lasts for a very small duration. Hence, devices running Sahyog-based applications can last longer without hampering battery-level, and allow users to avail other services offered by smartphones. This proves that our middleware is light-weight (does not require much computation resources) and is energy-efficient for developing context-aware mobile sensing applications. V. CONCLUSION AND FUTURE WORK Smartphones are improving day by day in terms of their computation power and resources. These increasing capabilities open up a platform for new applications that can use collaborative sensor data collected by multiple such devices to infer environmental contexts. However, communicating with unknown devices within a context for collecting sensitive sensor data is tedious. We realise the need for a middleware that facilitates the development of such applications. Towards this end, we present Sahyog a publish-subscribe middleware to facilitate development of context-aware applications requiring large user participation. The middleware allows for easy communication between unknown devices through the concept of subscription topics while ensuring privacy of users and near real-time delivery of data. The performance evaluation of devices using the middleware ensure low power consumption and fast delivery of messages which makes the middleware suitable to run real-time applications. VI. ACKNOWLEDGEMENT Authors will like to acknowledge the support provided by ITRA project, funded by DEiTY, Government of India, under grant with Ref. No. ITRA/15(57)/Mobile/HumanSense/01. We also thank Kshitiz Bakshi, Nishant Jain, Arjun Ahuja, and Nikita Juneja for their contributions. REFERENCES [1] Prashanth Mohan, Venkata N Padmanabhan, and Ramachandran Ramjee. Nericell: rich monitoring of road and traffic conditions using mobile smartphones. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages ACM, [2] Pengfei Zhou, Yuanqing Zheng, and Mo Li. How long to wait?: predicting bus arrival time with mobile phone based participatory sensing. In Proceedings of the 10th international conference on Mobile systems, applications, and services, pages ACM, [3] Emmanouil Koukoumidis, Li-Shiuan Peh, and Margaret Rose Martonosi. Signalguru: Leveraging mobile phones for collaborative traffic signal schedule advisory. In Proceedings of the 9th International Conference on Mobile Systems, Applications, and Services, MobiSys 11, pages , New York, NY, USA, ACM. [4] Rajib Kumar Rana, Chun Tung Chou, Salil S Kanhere, Nirupama Bulusu, and Wen Hu. Ear-phone: an end-to-end participatory urban noise mapping system. In Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks, pages ACM, Fig. 7. Power consumed by different clients (Requester (left) and Provider (right)) to service a query [5] Nicolas Maisonneuve, Matthias Stevens, Maria E Niessen, and Luc Steels. Noisetube: Measuring and mapping noise pollution with mobile phones. In Information Technologies in Environmental Engineering, pages Springer, [6] Arvind Thiagarajan, Lenin Ravindranath, Katrina LaCurts, Samuel Madden, Hari Balakrishnan, Sivan Toledo, and Jakob Eriksson. Vtrack: Accurate, energy-aware road traffic delay estimation using mobile phones. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems, SenSys 09, pages 85 98, New York, NY, USA, ACM. [7] Hong Lu, Nicholas D Lane, Shane B Eisenman, and Andrew T Campbell. Bubble-sensing: Binding sensing tasks to the physical world. Pervasive and Mobile Computing, 6(1):58 71, [8] Prem Prakash Jayaraman, Charith Perera, Dimitrios Georgakopoulos, and Arkady Zaslavsky. Mosden: A scalable mobile collaborative platform for opportunistic sensing applications. arxiv preprint arxiv: , [9] Niels Brouwers and Koen Langendoen. Pogo, a middleware for mobile phone sensing. In Proceedings of the 13th International Middleware Conference, pages Springer-Verlag New York, Inc., [10] Cory Cornelius, Apu Kapadia, David Kotz, Dan Peebles, Minho Shin, and Nikos Triandopoulos. Anonysense: Privacy-aware people-centric sensing. In Proceedings of the 6th International Conference on Mobile Systems, Applications, and Services, MobiSys 08, pages , New York, NY, USA, ACM. [11] Tathagata Das, Prashanth Mohan, Venkata N Padmanabhan, Ramachandran Ramjee, and Asankhaya Sharma. Prism: platform for remote sensing using smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages ACM, [12] Emiliano Miluzzo, Alexander Varshavsky, Suhrid Balakrishnan, and Romit Roy Choudhury. Tapprints: your finger taps have fingerprints. In Proceedings of the 10th international conference on Mobile systems, applications, and services, pages ACM, [13] Salvatore Sanfilippo and Pieter Noordhuis. Redis, [14] Mark Gordon, Lide Zhang, Birjodh Tiwana, R Dick, ZM Mao, and L Yang. Powertutor: A power monitor for android-based mobile platforms, 2013.