ICST Transactions Preprint MOSDEN: A Scalable Mobile … · ICST Transactions Preprint MOSDEN: A Scalable Mobile Collaborative Platform for Opportunistic Sensing Applications Prem

ICST Transactions PreprintMOSDEN: A Scalable Mobile Collaborative Platformfor Opportunistic Sensing ApplicationsPrem Prakash Jayaraman∗1, Charith Perera1, Dimitrios Georgakopoulos2 and ArkadyZaslavsky,†1

1CSIRO Computational Informatics, Canberra, Australia 26012School of Computer Science and Information Technology, RMIT University, GPO Box 2476, Melbourne VIC 3001

Abstract

Mobile smartphones along with embedded sensors have become an efficient enabler for various mobileapplications including opportunistic sensing. The hi-tech advances in smartphones are opening up a world ofpossibilities. This paper proposes a mobile collaborative platform called MOSDEN that enables and supportsopportunistic sensing at run time. MOSDEN captures and shares sensor data across multiple apps, smartphonesand users. MOSDEN supports the emerging trend of separating sensors from application-specific processing,storing and sharing. MOSDEN promotes reuse and re-purposing of sensor data hence reducing the effortsin developing novel opportunistic sensing applications. MOSDEN has been implemented on Android-basedsmartphones and tablets. Experimental evaluations validate the scalability and energy efficiency of MOSDENand its suitability towards real world applications. The results of evaluation and lessons learned are presentedand discussed in this paper.

Keywords: opportunistic sensing, crowdsensing, mobile middleware, mobile data analytics

1. Introduction

Today mobile phones have become a ubiquitous com-puting and communication device in people’s lives [1].The mobile device market is growing at a frantic paceand it won’t be long before it outnumbers the humanpopulation. It is predicted that mobile phones com-bined with tablets will exceed the human population by2017 [2]. Current generation smartphones are equippedwith plethora of features such as rich set of sensors (e.g.ambient light sensor, accelerometer, gyroscope, digi-tal compass, GPS, microphone and camera) to enableon-the-move sensing and technologies such as NFC,Bluetooth, WiFi that enable them to communicate andinteract with external sensors available in the envi-ronment. Smartphones have the potential to generatean unprecedented amount of data [3] that can revolu-tionise many sectors of economy, including business,healthcare, social networks, environmental monitoringand transportation.

∗Corresponding authorEmail: {prem.jayaraman, charith.perera, arkady.zaslavsky}@[email protected]†Prof. Zaslavsky is an International Adjunct Professor at StPetersburgNational Research University of IT, Mechanics and Optics, Russia

Mobile opportunistic sensing is one such new waveof innovative application popularly called collabora-tive community sensing or crowdsensing [4, 5]. MobileOpportunistic sensing is an autonomous collaborativesensing approach that takes advantage of a populationof users to measure large-scale phenomenon whichcannot be measured using a user. Mobile opportunisticsensing applications require minimal user involvement(e.g. continuous computation of user activity passivelyi.e. in the background). Opportunistic sensing appli-cations [6] thrive on the widespread availability ofsmartphones and the diverse sets of data generatedby these devices. Date captured from an individualsmartphone user can be used to infer the user’s currentcontext and activity. On the other hand, by fusingdata from a multitude of smartphone user population,high level context information such as crowd activitywithin a given environment [6] can be inferred. In eitherform, the data generated by the smartphones is valuableand offers unique opportunities to develop novel andinnovative applications.

To date most efforts to develop opportunisticsensing/crowdsensing1 applications have focused onbuilding monolithic mobile applications that are built

1In this paper, we use the terms opportunistic sensing andcrowdsensing synonymously.

1ICST Transactions Preprint

mailto:mailto:CharithMiniText BoxPrem Prakash Jayaraman, Charith Perera Dimitrios Georgakopoulos, and Arkady Zaslavsky, MOSDEN: A Scalable Mobile Collaborative Platform for Opportunistic Sensing Applications, Transactions on Collaborative Computing, Volume 14, Issue 1, 2015, Pages 1-16 (16) More: www.charithperera.net

P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky

for specific requirements [7]. These application siloshave very little capability for extensions and sharing ofsensed data with a community of users often makingthe data available only within the application’s context[4]. However, to realise the greater vision of mobilecollaborative opportunistic sensing we need a commonextensible platform that facilitates easy developmentand deployment of collaborative opportunistic sensingapplications on-demand.

The key challenge here is to develop a platform thatis autonomous, scalable, interoperable and supportsefficient sensor data capturing, processing, storageand sharing. The autonomous ability of the systemenables self-management and independent operationsduring device disconnections and off-line modes.We strongly believe that providing an easy-to-use,scalable platform to develop and deploy collaborativemobile opportunistic sensing applications will besignificant. To this end, we propose a collaborativemobile sensing platform namely Mobile Sensor DataEngine (MOSDEN). MOSDEN is capable of functioningon multitude of resource-constrained devices (e.g.Raspberry Pi2) including smartphones. MOSDENis a scalable platform that enables collaborativeprocessing of sensor data. The MOSDEN platformfollows component-based design philosophy allowingusers/developers to implement custom data analyticalgorithms (e.g. data mining algorithms [8]) and modelsto suit application requirements. Further, MOSDENincorporates local processing, storage and sharing asa means to accomplish data reduction for Big Dataapplications. By limiting the continuous transmissionof data to a centralised server which is typical of mostmobile opportunistic sensing application, MOSDENreduces bandwidth and power consumption. The keycontributions of this paper are summarised as follows:

• We propose MOSDEN, a scalable, easy-to-use,interoperable platform that facilitates the devel-opment of collaborative mobile opportunisticsensing applications

• We demonstrate the ease of development anddeployment of a opportunistic sensing applica-tion using the MOSDEN platform

• We experimentally evaluate and validate thescalability, performance and energy-efficiency ofMOSDEN under varying collaborative oppor-tunistic sensing workloads

The rest of the paper is organised as follows. SectionII discusses related work. Section III considers amotivation scenario. Section IV presents the proposedMOSDEN platform architecture. Section V discusses

2http://www.raspberrypi.org/

MOSDEN implementation and Section VI presentsMOSDEN platform evaluations and results. Section VIconcludes the paper with indicators to future work.

2. Related WorkNumerous real and successful mobile opportunisticsensing applications have emerged in recent timessuch as WAYZ3 for real-time traffic/navigation infor-mation and Wazer24 for real-time, location-basedcitizen journalism, context-aware open-mobile miner(CAROMM)[6] among others. Mobile opportunisticsensing applications [9, 10] thrive on the data obtainedfrom heterogeneous sets of smart phones owned andoperated by humans. Until recently mobile sensingapplication such as activity recognition (personal sens-ing), where people’s activity (e.g. walking, talking, sit-ting) is classified and monitored, required specialisedmobile devices [11, 12]. This has significantly changedwith advent of smartphones equipped with on-boardsensing capabilities. More recently, research effortshave focused on development of activity recognition,context-aware [13] and data mining models for smart-phones [8, 14, 15] that leverage on smartphone’s pro-cessing and on-board sensing capabilities.

Recent efforts to build opportunistic sensing appli-cation have focused on building monolithic mobileapplications that are built with specific purpose andrequirements. The MetroSense [16] project at Dart-mouth is an example of one such opportunistic sensingsystem. The project aims in developing classificationtechniques, privacy approaches and sensing paradigmsfor mobile phones. The CenceMe [17] project underthe MetroSense umbrella is a personal sensing sys-tem that enable members of social networks to sharetheir presence. The CenceMe application incorporatesmobile analytics by capturing user activity (e.g., sitting,walking, meeting friends), disposition (e.g., happy, sad,doing OK), habits (e.g., at the gym, coffee shop today,at work) and surroundings (e.g., noisy, hot, bright, highozone) to determine presence. The CenceMe systemcomprises two parts, the phone software and back-end software. The phone software is implemented ona Nokia N95 running Symbian operating system. Thephone software is developed in Java Micro Edition(JME) which interfaces with Symbian C++ modulescontrolling the hardware.

MineFleet [8] is a distributed vehicle performancedata mining system designed for commercial fleets. InMineFleet, dedicated patented custom built hardwaredevices are used on fleet trucks to continuouslyprocess data generated by the truck. MineFleet systemcomprises an on-board data stream mining module

3http://www.wayz.com/4https://www.wazer2.co.il/


MOSDEN: A Scalable Mobile Collaborative Platform for Opportunistic Sensing Applications

that performs extensive processing of data usingvarious statistical and data stream mining algorithms.This data stored locally is transmitted to an externalMineFleet Server for further processing when networkconnectivity is available.

Crowdsourcing data analytics system (CDAS) [18] isa crowd sourcing framework in which, the participantsare part of a distributed crowdsourced system. TheCDAS system enables deployment of crowdsourcingapplications that require human involvement forsimple verification tasks using Amazon MechanicalTurk (AMT). E.g. users in the system would besent a picture for identification by a centralisedtask distributor. Humans users participating in thecrowdsourcing application respond with appropriateanswers. The results from human workers are combinedto compute the final result. The CDAS systemincorporates complex analytics that enables it todisseminate jobs, obtain results and compare resultsobtained from different workers to determine thecorrect one. GeoCrowd [19] is another crowdsourcingsystem that employs spatial characteristics to estimatetask assignments among user populations. Mobile edgecapture and analysis middleware for social sensingapplications (MECA) [20] is another middleware forefficient data collection from mobile devices in aefficient, flexible and scalable manner. MECA providesa platform by which different applications can use datagenerated from diverse mobile data sources (sensors).The proposed MECA architecture has three layerscomprising data layer (mobile data sources âĂŞ mobilephones), edge layer (base stations that select andinstruct a device or group of devices to collect dataand process data), phenomena/application layer (theback-end that determines the edge nodes to processapplication request).

Applications like Waze5, MetroSense [16] and Mine-Fleet [8] are built around specific data handling models(e.g. GPS for Waze, Microphone for MetroSense andData mining algorithms for object monitoring) andapplication requirements reducing its re-usability. Onthe other hand, frameworks like CDAS[18], GeoCrowd[19] and MECA [20] offload processing to centralisedservers increasing bandwidth usage and making themless suitable for working in off-line modes. Moreover,in these frameworks, the smartphones are viewed asmere data collection or user response collection deviceslacking capabilities to implement localised data ana-lytics. On contrast, the proposed MOSDEN platformis developed with the design goal of 1) re-usability,2) ease of use, 3) ease of development/deployment, 4)scalability, 5) easy interface to access both on-boardand external sensors, 6) support for on-board complex

5http://www.wayz.com/

data analytics and 7) distributed mobile data sharing.The MOSDEN platform provides the application devel-oper with implementation options i.e. choice of usingprocessing on the smartphone and/or processing atthe server. It also provides extensions to implementmobile distributed load-balancing that can determineon-demand the best location to process data. We note,discussions on load-balancing and task allocation todifferent collaborative MOSDEN smartphone devicesare outside the scope of this paper. The MOSDENplatform promotes a distributed collaborative sensinginfrastructure where each MOSDEN instance runningon a smartphone is self-managed. In our previous work[21] we proposed the architecture of MOSDEN sup-ported by evaluations focusing on system performance.In this paper, we further analyse and present eval-uation results of MOSDEN’s scalability performanceand energy-efficiency under varying workloads typi-cal of collaborative opportunistic sensing applications.Specifically, we have critically evaluated the energyefficiency of MOSDEN platform when performing oper-ations like continuous sensing and sensing/sending. Wealso evaluate MOSDEN’s query processing efficiencywhen answering to distributed queries from multipleMOSDEN instances in a collaborative experimentalsetup.

3. Opportunistic Sensing ScenarioIn this section we present a motivating scenariothat explains the need for a scalable, collaborative,mobile sensing platform like MOSDEN. The scenariounder consideration is an environmental monitoringapplication (e.g. noise pollution) in smart cities asdepicted in Fig. 1.

In step (1), a remote-server (cloud-based) registersthe interest for data within user communities. In theexample depicted in Fig. 1, the user communitiesare grouped based on location. In step (2), thedata captured and processed on the smartphones aremade available to the remote-server. In step (3), theopportunistic sensing application obtains data from theremote-server for further processing and visualisation.The above scenario is a typical case for manyopportunistic sensing applications that require datafrom diverse user communities. The same approach isapplied to another opportunistic sensing applicationthat computes air pollution within the environment. Toaccomplish this requirement, the smartphone will alsohave to rely on external sensors that are part of a smartcity infrastructure to obtain air pollution data.

Using a monolithic approach may results in devel-oping a niche class of applications built for a sin-gle purpose. Such an application may not be scal-able/adaptable to work in other scenarios which is amajor obstacle. E.g. the algorithm required to process



MOSDENMOSDEN

MOSDEN

MOSDEN

User communities

User communities

Cloud platform forResource Intensive processing

Applications using Crowd sensed data

1

1

1

1

3

2

2

2

Figure 1. Environmental Monitoring - Mobile Opportunistic Sensing Scenario

noise data is different to air pollution computation.Moreover, such an opportunistic sensing applicationis hard-wired making it extremely difficult to makechanges to different parts of the code. E.g. addingnew interface to communicate with external sensors tocollect air pollution data.

To achieve the level of extensibility and scalabilityto support a range of different opportunistic sens-ing application requirements, the opportunistic sensingplatform needs to follow the design principle of separat-ing the sensor capturing operation and application spe-cific processing. This will in turn promote on-demandapplication composition. Further, the platform needsto support real-time data collection, processing andstorage, ability to incorporate application specific dataanalytic algorithms/models, energy-efficient operationand autonomous functions i.e. ability to work withminimal user interaction and with support for off-linemodes. The proposed MOSDEN platform supports theabove mentioned features natively.

4. MObile Sensor Data ENgine (MOSDEN): Acollaborative mobile opportunistic sensing platformWe propose MOSDEN, a crowdsensing platform builtaround the following design principles:

• Separation of data collection, processing andstorage to application specific logic

• A distributed collaborative crowdsensing applica-tion deployment with relative ease

• Support for autonomous functioning i.e. abilityto self-manage as a part of the distributedarchitecture

• A component-based system that supports accessto internal and external sensor and implementa-tion of domain specific models and algorithms

These design principles address the obstacles men-tioned in Section 3. The proposed MOSDEN platform

overcomes the key barriers of developing and deploy-ing scalable collaborative mobile opportunistic sensingapplications.

Architecture. MOSDEN platform follows the designprinciple of Global Sensor Network (GSN) [22]. GSNis a sensor network middleware developed to runon high-powered computing devices (e.g. servers andcloud resources). GSN presents a unified middlewareapproach that facilitates acquisition, processing andstorage of sensor data. We reuse the concept of vir-tual sensors proposed by GSN. A virtual sensor is aabstraction of the underlying data source (e.g. wirelesssensor network). Since, GSN was not developed forresource constrained environment, we made significantenhancement to GSN when designing and implement-ing MOSDEN described in the following section. MOS-DEN follows a component-based architecture allowingextensibility without modifying the existing codebase.The architecture of the proposed MOSDEN platformis presented in Fig. 2 followed by description of eachcomponent.

Plugin: In MOSDEN, we introduce the concept ofPlugins. In GSN, a developer had to implementwrappers to accommodate new sensor datasources into the system. To accommodate a newwrapper, the system had to be recompiled andredeployed. This approach is not very practicalespecially for real-time applications. Hence, weintroduced a plugin-based approach to overcomesthis challenge. The Plugins are independentapplications that communicates with MOSDEN.MOSDEN uses a discovery mechanism specific tothe implementation platform to discover the listof plugins installed in the system. E.g. in caseof android operating system, a plugin discoveryservices provides a list of registered pluginsand their description. The key function of theplugin is to describe how to interface with asensor that needs to be connected with MOSDEN.



SS

InternalSensors Plugin

PluginPlugin

Plugin

SmartphoneM

OS D

EN

Virtua l Senso r

Virtua l Sen sor L ifecy cle Manag er

Storag e Ma nager

Query M

ana ger

Servic e Ma nager

API (H

TTP)

Proce ssor L ifecy cle Manage r

SS

External Sensors

Plugin Layer

Processor

Processor

Processor

Processor

Processor

Processor….

Virtua l Senso r

Virtua l Senso r

Virtua l Senso r

Virtua l Senso r

Virtua l Senso r

Figure 2. MOSDEN Platform Architecture

We have developed a plugin descriptor thatopportunistic sensing application developer canuse to implement plugins to interface with newsensors. A conceptual description of the plugin isshown in XML format in Fig. 3.

Virtual Sensor: The virtual sensor is an abstraction ofthe underlying data source from which data isobtained. The virtual sensor can perform streamlevel operation e.g. fuse data from multiplesensor sources (on-board, external sensors con-nected to the mobile device and remote MOS-DEN instances). The virtual sensor can be used tospecify configurations to capture data from dis-tributed MOSDEN instances. In such situations,the query and service manager at the remoteMOSDEN instance is responsible for processingthe query. The virtual sensor file dynamicallylinks the sensor plugins with MOSDEN platformvia an XML configuration file. The virtual sensorlifecycle manager is responsible to manage theinstantiation, updation and removal of virtualsensor resources.

Processors: The processor classes are used to imple-ment application specific data analytics modelsand algorithms. For example, a Fast Fourier Trans-form (FFT) algorithm to compute the decibel levelfrom microphone recordings or a data miningalgorithm to perform high speed data stream clus-tering and classification [8].

Storage Manager: The function of the storage manageis to store the data acquired from the virtualsensor and processor workflow. The storagemanager uses a data collection window to deleteold data. This function of the data collectionwindows is very similar to sliding windowprotocol. The virtual sensor configuration file is

used to configure the data collection window sizeduring application deployment. The window sizecan be modified during runtime.

Query Manager: The query manager is responsible toresolve and answer queries from external entities.An external entity can be another MOSDENinstance, a user or an application querying fordata collected by the smartphone. The querymanager employs a queuing mechanism to resolveincoming queries. The local storage and queryprocessing functionality of MOSDEN is a keyenabler of off-line mode operations.

Service Manager: The service manager is responsible tomanage subscriptions to data from external enti-ties. The service manager registers subscriptionrequest and depending on the mode of data deliv-ery (e.g. persistent/non-persistent) will deliveravailable data to the requested external sourcewhen possible. The service manager is respon-sible to handle data connections with externaldata sources. The service manager is specificallydesigned to manage the working of MOSDENin resource constrained environments where fre-quent disconnection occurs.

API Manager: The application programmable inter-faces (APIs) provides a standard way to subscribeand access data to/from MOSDEN instances. TheAPI requests are received and processed overHTTP. Request received via the API are passedto the service manager for further processing andmanagement.

Each MOSDEN instance running on the mobilesmartphones can run with minimal user interac-tion. It can received and register a data capture



accelerationX_axis_incl_gravity double Acceleration force along the X axis (including gravity)measures in m/s2.

accelerationY_axis_incl_gravity double Acceleration force along the Y axis (including gravity)measures in m/s2.

accelerationZ_axis_incl_gravity double Acceleration force along the Z axis (including gravity)measures in m/s2.

Figure 3. A Conceptual Description of MOSDEN Plugin

request/processing from a remote-server (e.g. cloud-based). MOSDEN then works in the background pro-cessing the request by collecting, processing and storingthe requested data locally. When the processed datais required by the application running at the remote-server, it can query the specific MOSDEN instance run-ning on user smartphone for the data. MOSDEN realisesa true distributed collaborative system architecture as ithas the ability to function independent of the remote-server.

As depicted in the architecture, each individualMOSDEN instance is self contained and managed andis capable of working in mobile environments thatencounter frequent disconnections. The use of APIs tocommunicate between instances encourages collabora-tive workload sharing and processing. The plugin basedapproach increases re-usability and promotes interop-erability allowing MOSDEN to communicate with anysensors both internal and external. This remove theburden on opportunistic sensing developer. Further, theuse of a component-based architecture and a workflowstyle processing allows system developers to implementand integrate domain specific data analytics algorithmswith relative ease. Moreover, the MOSDEN platformenables the development of mobile opportunistic sens-ing applications that can scale from an individual userto a community. E.g. an individual personal fitnessmonitoring application to a group activity recognitionapplication involving a community of users can bedeveloped and deployed using the MOSDEN platform.

5. Implementing a Collaborative opportunisticsensing Application using MOSDENIn Section 3 we presented an environmental monitoringscenario to determine the noise pollution level usingthe data obtained from a community of user. Using

the information obtained from the user communities,a opportunistic sensing application running on aremote-server (e.g. cloud) can further analyse andvisualise the noise pollution level of a smart city. Eachuser community in this scenario is grouped by theirlocations.

In this section we present a detailed descriptionof the noise pollution opportunistic sensing proof-of-concept application implemented using MOSDENplatform. Fig. 4 presents the overview of the applicationimplemented on MOSDEN platform. In the scenariodepicted in 4, in step (1) MOSDEN instances runningon the smartphone registers with the cloud GSNinstance (clients are aware of server’s IP address duringconfiguration process). Once registration is complete instep (2) the cloud GSN instance registers its interestto receive noise data from MOSDEN running onthe smartphones. When data is available, MOSDENon the smartphones stream the data to the cloudGSN. The data transfer process could employ pushor pull techniques over a persistent or non-persistentconnection depending on application requirement. Inthis specific example we implemented a pull-basedapproach where GSN running on the remote-server willspecifically query each MOSDEN instance running onthe smartphones.

The MOSDEN reference architecture presented inFig. 2 has been implemented using the Android6

SDK platform. We deployed the noise pollution appli-cation developed on the MOSDEN platform on aset of smartphone and tablet devices that simulatea user community. To compute the noise decibel

6http://www.android.com/

MOSDEN MOSDEN

Global Sensor Network

Message Broker

11 1

1

22

2

MOSDEN

Figure 4. Implementation of Opportunistic Sensing Applicationusing MOSDEN



(a) (b) (c) (d)

Figure 5. MOSDEN screenshots: (a) List of sensors connected the MOSDEN; (b) List of virtual sensors currently running on theMOSDEN and their details; (c) Map that shows sensor locations; and (d) Interface for data fusing and filtering

level, we implemented a modified version of the pro-cessing class from Audalyzer open source project7.The microphone sensor on the smartphones wasused to obtain raw sound recordings. Code to inter-face with the microphone sensor was already avail-able as a part of the MOSDEN platform via plu-gins (we have developed plugins for on-board sen-sors and few selected external sensors e.g. waspmotes- http://www.libelium.com/products/waspmote/). Forour proof-of-concept implementation, we implementedGSN in the cloud that queries data from individualMOSDEN instances running on user mobile devices.A MOSDEN instance once deployed on the smart-phone/tablet registers itself with the GSN in the cloud.As we stated earlier, the design of MOSDEN makesit easily extensible to suit any opportunistic sensingapplication requirements. To validate this, we imple-mented the registration process via a message brokeras depicted in Fig. 4. Along with the registration,each MOSDEN instances also updates the cloud GSNinstance with a list of available sensors. We note, MOS-DEN API extends support to any form of registration.It is the responsibility of the opportunistic sensingapplication developer to choose the most appropriateregistration process best suited to the application.

MOSDEN’s API enables it to query data from anyother MOSDEN instances. Hence, it is to be notedthat the GSN running in the cloud instance could bereplaced by another smartphone running MOSDEN.In such a scenario, the MOSDEN instance is alsoresponsible to query data from other smartphones,performs further data analytics on collected dataand perform visualisation. The analytics and visual

7https://code.google.com/p/moonblink/

Table 1. LOC to develop a Noise Pollution MonitoringApplication

Component Lines of CodeVirtual Sensor (MOSDEN) 30 LinesPlugin Wrapper (MOSDEN) 190 LinesPlugin Application: Capture Micro-phone data (External)

75 lines

Data Analytics: Decibel Computa-tion FFT (External)

194 Lines

components required to accomplish the previouslystates functions can be easily integrated with MOSDENas individual components. Screenshots of the MOSDENimplementation on Android smartphone and GSN inthe cloud are illustrated in Fig. 5 and 6. We note, thedefault version of GSN with no enhancements was usedto demonstrated the proof-of-concept implementation.Fig. 6b depicts the noise graph computed from 3MOSDEN users. In this example, we have plotted thenoise data individually. To demonstrate the ease ofdeploying complex opportunistic sensing applicationsusing MOSDEN, Table 1 presents the total lines ofcode that was required to develop the previouslymentioned noise pollution monitoring application. Wenote, the configuration files required by MOSDENto implement a new application are Virtual Sensorand Plugin Wrapper. The plugin application tocapture microphone data and data analytics componentare application specific implementations external toMOSDEN code and would change depending onapplication complexity. In the current implementation,the plugin application is a standard android sensorservice implementation.



(a). GSN Sensor Registration Screenshot

(b). GSN Noise Plot Screenshot

Figure 6. Opportunistic Sensing Noise Pollution ApplicationScreenshots

Benefits of MOSDEN Design. The proposed MOSDENmodel is architected to support scalable, efficient datasharing and collaboration between multiple applicationand users while reducing the burden on applicationdevelopers and end users. The scalable architecturecan easily be orchestrated for opportunistic sensingapplications that range from an individual to acommunity of users. It facilitates easy sharing of dataamong large community of users which is a vitalrequirement for opportunistic sensing applications.

By separating the data collection, storage and sharingfrom domain-specific application logic, our platformallows developers to focus on application developmentrather than understanding the complexities of theunderlying mobile platform. In fact, our model hidesthe complexities involved in accessing, processing,storing and sharing the sensor data on mobiledevices by providing standardised interfaces thatmakes the platform reusable and easy to develop newapplication. This we believe will is critical and willsignificantly reduce the time to develop new innovativeopportunistic sensing applications. Since, MOSDENis designed as a component-based architecture, itprovides easy interfaces to implement applicationspecific data analytic models and algorithms.

Further, our model works in the background withminimal user interaction reducing the burden on smart-phone users. By providing support for processing andstorage on the device, we also reduce frequent trans-mission to a centralised server as compared to currentopportunistic sensing frameworks. The potential reduc-tion in data transmission has the following benefits:1) saves energy on users’ mobile device; 2) reducesnetwork load by avoiding long-running data transmis-sions and 3) reduces data transmission costs by limitingcontinuous data transmissions.

The benefits of MOSDEN Design can also bearticulated from a Big Data perspective. Evidencefrom Big Data applications like Phenonet[23] indicate,only 0.1% of the data collected for scientific plantexperiments (from 1 million data points) representgolden data points. A typical Big Data approachintroduces the challenges of capturing, storing filteringand analysing such volumes of data streams in remotecloud servers. Such an approach is both time andresourcing consuming. An alternative approach that wepropose is to leverage on MOSDEN-like architectureleveraging on distributed local data analytics, storage,retrieval on-demand and off-line functioning capabilityfor the following benefits: 1) Data reduction: datafiltering near the data capturing location using localdata analytics e.g. using statistical approaches tofilter unwanted and erroneous data; 2) RelevantData stream Selection: ability to selectively chooserelevant data sources and query these sources for datadepending on application needs. This will again reducetransfer and processing of large amounts of data to aremote-location; 3) Better real-time access to data on-demand and 4) Reduction in resource and bandwidthconsumption due to collaborative distributed dataanalytics, storage and querying.

To validate the performance of the proposedMOSDEN platform to support scalable,energy andresource efficient data sharing and collaboration, in thenext section we present MOSDEN platform evaluations.To this end, we evaluate MOSDEN under extremeloads typical of collaboratively opportunistic sensingapplication scenarios.

6. Evaluation of MOSDEN PlatformIn this section, we present the details of ourexperimental test-beds and evaluation methodology.Further, we discuss the results and present the lessonslearnt from experimental evaluations. The overallobjective of the experimental evaluations is to examinethe scalability, resource consumption, performanceand energy consumption of MOSDEN platform incollaborative environments. Scalability of MOSDENunder collaborative application scenarios is tested byexperimenting MOSDEN’s ability to handle growing



amount of sensing and querying tasks in a capablemanner.

6.1. Experimentation Testbed and SetupFor the evaluation of the proof of concept implementa-tions, we used four mobile devices and a laptop. Fromhere onwards we refer them as D1, D2, D3, D4, and D5respectively. The technical specifications of the devicesare as follows.

• Devices (D1 & D4): Google Nexus 4 mobilephone, Qualcomm Snapdragon S4 Pro CPU, 2 GBRAM, 16GB storage, Android 4.2.2 (Jelly Bean)

• Devices (D2 & D3): Google Nexus 7 tablet,NVIDIA Tegra 3 quad-core processor, 1 GB RAM,16GB storage, Android 4.2.2 (Jelly Bean)

• Device (D5): ASUS Ultrabook Intel(R) Core i5-2557M 1.70GHz CPU and 4GB RAM (Windows 7operating system)

For experimentation, we devised two setups asillustrated in Fig. 7 and evaluated the proposedframework in each setup independently. For ease ofillustration, in each setup, the parent node performsthe operations of the remote-server including issuingqueries to fetch data and process and store obtaineddata while child nodes perform client operationsincluding data capturing, local analytics, storage andquery processing. The proposed MOSDEN platformcan be deployed in either roles i.e. remote-serveror client depending on application requirements.In our setup depicted in Fig. 7a, the MOSDENplatform on the mobile device (D1, D2, D3) assumesthe role client while in Fig. 7b, the MOSDENplatform on the mobile device (D1, D2, D3, D4)assumes the role of both remote-server and client.The laptop computer (D5) in Fig. 7b is configuredto run GSN engine [22]. The MOSDEN architecturepromotes a distributed collaborative system withconnection between MOSDEN instances (client andserver) maintained and managed independently aspeers. The term "client" and "server" is used to specifythe temporary role of the mobile devices duringexperiments i.e. server is responsible to answer to userqueries while clients only collect data. For example, insetup 2, the mobile device (D1) running MOSDEN canalso perform local sensing and respond to requests fromother MOSDEN instances transforming this setup intoa hierarchical peer-to-peer architecture. At any timeusing minimal configurations, MOSDEN on mobiledevices can perform the role of both client and servermaking the collection of MOSDEN’s devices peers. Weaim to extend out experiments in future for peer-to-peer scenarios. It is to be noted, the use of client serverterminology does not limit MOSDEN platform to only

(a) (b)Computer

D1 D2 D2D3 D4D3

D5

D1

Figure 7. Experimental Testbed has been configured in twodifferent ways: (a) Setup 1: Three mobile devices are connectedto a laptop and (b) Setup 2: three mobile devices are connected

to another mobile device.

client server setup, rather is used for ease of illustration.Further, for evaluations purposes, we chose a setupwith 4 devices in different configurations. Experimentalevaluations show that MOSDEN can scale to n numberof devices when working in either client or servermodes.

The maximum number of sensors was set to 13and kept fixed throughout the experiments8. In allthe evaluations, CPU usage (consumption) is measuredin units of jiffies9. Sampling rate for all the sensorsconnected to MOSDEN is one second.

In Fig. 7(a) and (b), a query in the form of a requestis sent from the server to MOSDEN client instances.Depending on the number of sensors queried onMOSDEN instances, the number of requests increase.We use the term ’MOSDEN client’ to refer to mobiledevices where MOSDEN act as a client such as D1, D2and D3 in setup 1 in Fig. 7(a) and D2, D3 and D4 insetup 2 in Fig. 7(b)). We use the term ’MOSDEN server’to refer to a mobile device where MOSDEN performsthe role of a server such as D1 in setup 2 in Fig. 7(b)).

6.2. Experimental Results and DiscussionIn this section, we will present discussions of eachexperiment we conducted in detail.

CPU and Memory Consumption Experiment. In thisexperiment, we evaluate the CPU and memory usageof MOSDEN platform functioning as client andserver in setups (a) and (b) illustrated in Fig. 7.To experimentally evaluate MOSDEN client’s resourceconsumption, we conducted two experiments. In thefirst experiments, we computed the total CPU and

8All the sensors available on the given device has been used(e.g. In D1: accelerometer, microphone, light, orientation, proximity,gyroscope, magnetic, pressure).9In computing, a jiffy is the duration of one tick of the system timerinterrupt. It is not an absolute time interval unit, since its durationdepends on the clock interrupt frequency of the particular hardwareplatform



memory consumption when performing sensing (on-board sensors), processing and local storage (henceforthwe use the term sensing to represent the 3 operations).In the second experiment, we also include resourceconsumption incurred due to data transmission overWi-Fi For MOSDEN server (D1 in Fig. 7)(b)), theexperiment only considered the resources consumedto process queries from distributed MOSDEN clientinstances (D1, D2 and D3 in Fig. 7)(a)).

For the query processing experiment, we used twodata transmission methods between the MOSDENclient and server namely restful streaming and push-based streaming. Restful streaming is designed to have apersistent connection between the client and the server.On the other hand, the push-based approach makes anew connection every time to transmit data. Both thesetechniques can be used to perform communicationbetween two (or more) distributed GSN or MOSDENinstances (i.e. GSN ↔ GSN, MOSDEN ↔ MOSDEN,GSN↔MOSDEN). The two approaches have their ownstrengths and weakness. The former is good for clientsrunning MOSDEN that have a reliable data connection.The latter is useful for clients that need to work in off-line modes. The MOSDEN platform supports both theoperations and the application developer has the choiceto choose the best approach that satisfies the applicationrequirements. The resource consumption experimentoutcome of MOSDEN client is presented in Fig. 8,9, 10 and 11. The resource consumption experimentoutcomes of MOSDEN server is presented in Fig. 12 and13.

Fig. 8 and 9 presents the CPU and memoryconsumption of MOSDEN client when performingsensing operation. We computed the memory andCPU consumption of the two devices independentlydue to the difference in their memory and processingcapabilities. The memory allocation to MOSDEN isentirely managed by the Android operating systemdepending on available memory. As its can noted,MOSDEN has very little memory and CPU footprintfor continuous operation even when the number

1 2 3 4 5 6 7 8 9 10 11 12 130

5

10

15

20

25

30

35

Device 2 (D2)

Device 1 (D1)

Number of Sensors

CPU

Use

age

(Ave

rage

uni

ts o

f jiff

ies)

Figure 8. Comparison of CPU Usage by MOSDEN Client -Sensing

1 2 3 4 5 6 7 8 9 10 11 12 130

5

10

15

20

25

30

35

40

45

Device 2 (D2)

Device 1 (D1)

Number of Sensors

Mem

ory

Usag

e (M

B)

Figure 9. Comparison of Memory Usage by MOSDEN Client -Sensing

1 5 10 20 300

10

20

30

40

50

60Restful StreamingPush-based Streaming

Number of Requests Processed by MOSDEN ClientCPU

Usa

ge (A

vera

ge u

nits

of j

iffie

s)

Figure 10. Comparison of CPU Usage by MOSDEN Client -Sensing + Sending

1 5 10 20 300

50

100

150

200

250

300

350

400


Number of Requests Processed by MOSDEN Client

Mem

ory

Usag

e (M

B)

Figure 11. Comparison of Memory Usage by MOSDEN Client- Sensing + Sending

of sensors connected increase to 13. This clearlyvalidates the scalability of MOSDEN client to workunder collaborative sensing application consumingsignificantly less resources. Fig. 10 and 11 illustratesthe difference in CPU and memory usage of MOSDENclient during sensing and sending operations. Theexperiments observes the variation in CPU and memoryconsumption when the number of requests increases.According to Fig. 10, it is evident that restful streamingis marginally better than push-based streaming fromCPU consumption perceptive. On contrast, restfulstreaming consumes more memory than push-basedstreaming as depicted in Fig. 11. One reason for such a



3 6 9 15 30 60 900

10

20

30

40

50

60

70


Number of Requests Handle by MOSDEN ServerCPU

Usa

ge (A

vera

ge u

nits

of j

iffie

s)

Figure 12. Comparison of CPU Usage by MOSDEN Server

3 6 9 15 30 60 900

20

40

60

80

100

120

140


Number of Requests Handled by MOSDEN Server

Mem

ory

Usag

e (M

B)

Figure 13. Comparison of Memory Usage by MOSDEN Server

outcome could be attributed to the overheads involvedin maintaining a persistent network connections. Inboth the cases, the MOSDEN client performed well tohandle data capture, processing, storage and queryingoperations. Further, as it can be noted from the result inFig. 10, the memory consumption increases to 400MBwhen MOSDEN is processing data concurrently from30 sensors. The device used for this experiment wasthe Nexus 7 tablet (D2) with an available memory of1 GB (average among most current day smartphonesand tablets). As android manages memory allocationand the tablet was only running the device monitoringapplication, MOSDEN was allocated more memoryas needed. When there is contention from otherapplications, the memory allocation to MOSDEN mightdecrease. Under such circumstances, MOSDEN will stillperform significantly well which is further justified bythe query response latency experiments presented later.Moreover, newer devices such as Google Nexus 5 andSamsung Galaxy S5 have over 3GB of on-board memorywhich will significantly increase the performance ofMOSDEN.

In Fig. 12 and 13, we compare the performance ofrestful streaming and push-based streaming techniquesin terms of CPU and memory usage by the mobiledevice (D1) functioning as MOSDEN Server (Fig.7(b)). The experiments compute the difference in CPUand memory usage by MOSDEN server when thenumber of requests increases. According to Fig. 12

restful streaming is better than push-based in terms ofCPU usage while as indicated in Fig. 13 push basedstreaming is slightly better that restful streaming interms of memory consumption. This is due to thefact, push-based makes connection on-demand hencerequiring more CPU and less memory while restfulmaintains a constant connection consuming less CPUand more memory (connection maintenance overhead).Further, it is important to note that both techniquesmaintain the same amount of CPU consumption overtime despite the increase in requests it handles.Additionally, MOSDEN server consumes significantlyless amount of memory in comparison to MOSDENclient. One reason is that MOSDEN client performssensing, processing and local storage activities inaddition to sending data to the server. In contrast,MOSDEN server performs query processing task only(from clients). As we mentioned earlier, when thenumber of requests handled by MOSDEN increases(give that no other tasks are performed), restfulstreaming technique performs better in term of bothCPU consumption and memory consumption.

Storage Requirements Experiment. In this experimentwe examine how storage requirements vary whennumber of sensors handled by the MOSDEN clientincreases. For this experiment, we used Setup 1 in7. All the sensors on-board the client mobile device(i.e. accelerometer, microphone, light, orientation,proximity, gyroscope, magnetic, pressure) are used assensor sources. Sampling rate for sensors are configuredas one second. The D1 (Setup 1) has been configuredto receive data request from the server in an onesecond interval. The experiment was conducted forthree hours. The exact storage requirements dependon multiple factors such as number of active sensorssending data, number of data items generated by thesensor10, sampling rate, and history size [24]. We usedexternal sensor to increase the number of sensorsconnected to MOSDEN during the experiment in orderto examine the behaviour of MOSDEN from a storagerequirement perceptive. The results of the experimentis presented in Fig. 14.

According to the outcome shown in Fig. 14, storagerequirements are linear i.e. the increase in storagechanges at a constant rate depending on the history-size. History-size defines how much data record needsto be stored at a given time. Large history sizes can beused for summarising purposes or archival purposes.However, the amount of storage in easily predictabledue to history size, because MOSDEN always deletesold items in order to accommodate new data items. InMOSDEN, storage can be easily controlled by changing

10E.g. accelerometer generates 3 data items i.e. x, y, and z whiletemperature sensor generate one data item



the history-size. Specially, for real time reasoninghistory can be set to one. Considering all the abovefactor, it is fair to conclude that modern mobile deviceshave the storage capacity to store sensor data collectedover long period of time.

Query Processing Experiment. In this section, we presentresults of MOSDEN servers’ query processing efficiencyevaluation. To measure query performance, we evaluatehow the round trip time11 is impacted when thenumber of requests handled MOSDEN server (D1 inFig. 7(b)) increases. Both restful streaming and push-based streaming techniques are evaluated separately.As a comparison, we compute the round-trip time inprocessing a request by GSN server (D5 in Fig. 7(a)).Further, we also evaluate and compare the amount oftime (average) it takes to process a single request12. Thisis different from round trip time and is calculated asdenoted in Equation 1. The results of the experimentsare presented in Fig. 15 and 16.

Average time to process single request

=Duration of the Experiment

Total number of Round Trips Completed(1)

According to Fig. 15, it is clearly evident thatresource constrained device such as mobile phonestake more time to perform computations. As a resultdelay time is comparatively high when the servernode is a mobile device in contrast to a computer-based processing node. Further it has been observedthat (also we predicted in earlier section), push-based technique has much larger delay time due toadditional overheads involved in connection setup and

11The round-trip time is the time taken for the server MOSDENinstance to request a data item from a given virtual sensor on a clientMOSDEN instance. The total time is computed as the interval elapsedbetween server request and client response.12Time taken to process a single request is the time interval elapsedbetween two subsequent requests made by the server to any clientirrespective of the virtual sensor

1 min 5 min 10 min 30 min 1h 2h 3h0

0.5

1

1.5

2

2.5

3

3.5

One Virtual Sensor 7 Virtual Sensors

15 Virtual Sensors 30 Virtual Sensors

Time in Minutes

Stor

age

Req

uire

men

t (M

egab

ytes

)

Figure 14. Storage Requirement of MOSDEN client

tear down For laptop-based server instances, the reasonfor having much less round trip time when handling90 requests (3 clients * 30 queries each) is due to theavailability of more computational resources. However,when resource constrained devices play the role of aserver node, the CPU and memory resources are limitedhence resulting in greater round trip times. Fig. 16 alsoshows the impact of increased overheads when usinga push-based streaming technique. It is important tonote that, even though, the average round trip time ishigher as observed in Fig. 15 (e.g. 20 seconds whenhandling 90 requests) when restful steaming techniquesis used, the amount of time taken to make subsequentrequests by the server is mush less (e.g. less than asecond when handling 90 requests) as observed in Fig.16. This outcomes is further validated by results of thefollowing experiment.

In Fig. 17 and 18, we presents results of theexperiments (Fig. 7-Setup 2) that examine how eachrequest was processed. We compared the performanceusing both restful streaming and push-based streaming.In this experiment, we configured MOSDEN server tomake 30 requests to each of the three distributed clientMOSDEN instances. We conducted the experiment fora fixed interval of time. Later, we calculated usingEquation 2, the number of round-trips completedby each request and plotted them as a percentage.We denote the total number of round-trip requests

15 30 60 900

10

20

30

40

50

60

70

80Restful Streaming (GSN Server)Push-based Streaming (GSN Server)Restful Streaming (MOSDEN Server)Push-based Streaming (MOSDEN Server)

Number of Request handled by GSN / MOSDEN Server

Rou

nd-T

rip T

ime

(Ave

rage

) in

Sec

onds

Figure 15. Comparison of Round-trip Times

15 30 60 900

0.5

1

1.5

2

2.5

3Restful Streaming (GSN Server)Push-based Streaming (GSN Server)Restful Streaming (MOSDEN Server)Push-based Streaming (MOSDEN Server)

Number of Requests Handle by GSN / MOSDEN Server

Tim

e to

Pro

cess

a S

ingl

e R

eque

st

(Ave

rage

) (in

sec

onds

)

Figure 16. Comparison of Data Retrieval and Processing Ability



0

1

2

3

4

5

6Restful Streaming Push-based Streaming

Different Requests Handled by MOSDEN Server

Num

ber o

f Req

uest

Pro

cess

edin

Per

cent

age

(%)

Figure 17. Comparison of Requests Processing Variation

0

2000

4000

6000

8000

10000

12000

14000

Time

Del

ay in

Milis

econ

ds

Figure 18. Variation of round-trip time (delay / latency) over a period of time where seven requests are being processed

completed for a virtual sensors S as Si where i is thevirtual sensor identifier. The x-axis in Fig. 17 representsi.

Number of round-trips completed by each request

=(

Number of Round trips Completed by SiTotal number of Round Trips Completed

∑ni=1 Si

)× 100

(2)

According to Fig. 17, restful streaming techniqueallows each request to have fair amount of computa-tional resources but push-based streaming does not.The main reason is attributed to the fact that restfulstreaming maintains a persistent connection betweenthe client and server. When devices use push-basedstreaming, more computational resources are requiredto handle the connection setup and tear down Specially,when the number of requests that needs to be han-dled increases significantly, it places significant over-heads on round-trip times for the push-based stream-ing approach as shown in Fig. 17. Due to restrictedresources, under extremely high loads, in push-basedstreaming, there is a fair possibility that some requestsmade MOSDEN server to MOSDEN clients may not getexecuted at all. In Fig. 18, we visually illustrate howdelay occurs in processing 90 requests (in Fig. 17, weonly show 7 requests due to space limitation). Eachrequest is shown in a different colour. Different requests(a combination of both restful and push based stream-ing queries were employed to compute the round-trip

time) have different round-trip times depending on howprocessing capabilities and priorities of both server andclient devices. This clearly shows the significance of thevariation observed in previous experimental outcomes.Some requests (at some point of time) take only 6 mil-liseconds whereas some other requests take 12 secondsto complete a round trip.

Energy Consumption Experiment. This experiment eval-uates the energy consumption of MOSDEN platformwhile functioning as both client and server. Energy con-sumption is vital consideration for any mobile deviceapplication. For this experiment, the MOSDEN clientwas tested with a 13 sensors including a combina-tion of on-board sensors (accelerometer, gravity, gyro-scope, linear acceleration, ambient temperature, light,pressure, relative humidity, magnetic field, orientation,proximity) and additional data source generators. Weused the experimental setup depicted in Fig. 7(b). Forthe MOSDEN client, energy consumption for sensingonly and sensing + sending operations were measured.The MOSDEN server was responsible to request datafrom 3 distributed clients and process the responseinstantaneously. Each MOSDEN client was issued 30queries by the MOSDEN server. This resulted in MOS-DEN server processing 90 queries in total (30 x 3).For this experiment, we chose the restful data stream-ing approach as a persistent data connection involves



longer usage of Wi-Fi connection. During the experi-ment continuous requests with sampling rate of 1 sec-ond were made by MOSDEN server. The experimentaloutcomes are presented in Fig. 19, 20 and 21.

According to the results in Fig. 19, 20 and 21 itcan be concluded that MOSDEN functions energy-efficiently under extreme loads (MOSDEN clientsensing and processing 30 requests while MOSDENserver processing 90 requests). The experimentaloutcome clearly validates and supports this inference.We note, the average energy consumption by MOSDENclient over a 30 minute time window for 13 virtualsensors and MOSDEN server processing 90 requestswas ≈ 40J. It is to be noted, in our energy consumptionexperiment we did not consider LCD consumptionas this is entirely dependent on user’s usage pattern.Further, we controlled the amount of data transmittedduring experimentation by increasing and decreasingthe number of queries sent to MOSDEN instance.Changes to the size of sensed data did not impact theenergy consumption significantly.

Discussion. Overall MOSDEN performs extremely wellin both server and client roles in collaborativeenvironments. MOSDEN (as a server) was able tohandle 90 requests (i.e. 180 sub requests including90 requests/90 responses) where each request hasa sampling rate of one second. This resulted in

1 2 3 4 5 6 7 8 9 10 11 12 130

5

10

15

20

25

30

Energy Consumption (J)

Number of Sensors

Ener

gy C

onsu

mpt

ion

(J)

Figure 19. Energy Consumption - MOSDEN Client (Sensing)

1 5 10 20 300

5

10

15

20

25

30

35

40

45

50

Energy Consumption (J)

Number of Queries

Ener

gy C

onsu

mpt

ion

(J)

Figure 20. Energy Consumption - MOSDEN Client (Sensing +Sending)

1 5 10 20 30 60 900

5

10

15

20

25

30

35

40

45

Power Consumption

Number of Queries Processed by MOSDEN (as a Server)

Ener

gy C

onsu

mpt

ion

(J)

Figure 21. Energy Consumption - MOSDEN Server

a MOSDEN server (running on a mobile device)processing 5400 data points (90 requests * 60 seconds)every minute from distributed clients. Similarly, aMOSDEN client was stress tested with up to 13virtual sensors which included a combination of on-board sensors and additional data source generators.Hence, the MOSDEN clients was processing 1800data points (30 queries on 13 sensors * 60 seconds)every minute. It is to be noted, that for evaluationpurposes and to test the energy efficiency, resourceconsumption, performance and scalability of MOSDEN,we conducted experiments on MOSDEN server andclient under extreme loads. Such processing is intensiveand rare in real-world applications. However, ourexperiments showed that MOSDEN can withstand suchintensive loads proving to be a scalable, performanceoriented and energy efficient platform for deployinglarge-scale opportunistic sensing applications. Undersuch extensive loads, considering the battery ratingof Google Nexus 7 (16Wh), the MOSDEN server andMOSDEN client (sensing + sending) in continuousprocessing mode with 1 second sampling rate can last≈ 20 hours while the MOSDEN client in sensing onlymode can last ≈ 35 hours. If MOSDEN is configuredto collect data from 10 different sensors and handle30 requests (typical of real-world situations), it canperform real-time sensing with delay of 0.4 - 1.5seconds.

7. Conclusion and Future WorkA mobile opportunistic sensing application develop-ment framework must scale from an individual userto user communities (tens of thousands of users). Inthis paper, we proposed MOSDEN, a collaborativemobile platform to develop and deploy opportunisticsensing applications. MOSDEN differs from existingopportunistic sensing platforms by separating the sens-ing, collection and storage from application specificprocessing. This unique feature of MOSDEN rendersit an easy-to-use, reusable framework for developingnovel opportunistic sensing applications. We proposed



the architecture of the MOSDEN framework. We thendemonstrated its ease of use and minimal developmenteffort requirement by developing a proof-of-conceptnoise pollution application. We validated MOSDEN’sperformance, energy efficiency, resources consumptionand scalability when working in distributed collab-orative environments by extensive evaluations underextreme loads resolving and answering queries fromexternal sources (MOSDEN instances and GSN in thecloud). Overall MOSDEN is extremely energy andresource efficient and performs exceedingly well underhigh degrees of load in collaborative environments val-idating its suitability to develop large-scale opportunis-tic sensing applications.

Our next step is to explore protocols for dynamicdiscovery, load balancing and task allocation amongMOSDEN sensing and processing resources in a typicalmobile ad-hoc network scenario. The aim of theextension is to dynamically distribute a collective taskto a set of MOSDEN clients and servers autonomouslyto achieve a common goal.

Acknowledgements. Part of this work has been carried outin the scope of the ICT OpenIoT Project which is co-fundedby the European Commission under seventh frameworkprogram, contract number FP7-ICT-2011-7-287305-OpenIoT.The authors acknowledge help and support from CSIROSensors and Sensor Networks Transformational CapabilityPlatform (SSN TCP).

References[1] Lane, N., Miluzzo, E., Lu, H., Peebles, D., Choudhury,

T. and Campbell, A. (2010) A survey of mobile phonesensing. Communications Magazine, IEEE 48(9): 140–150.

[2] Lilly, P., Mobile devices to outnumber globalpopulation by 2017. URL http://tinyurl.com/pbodtus[Accessedon:2013-08-06].

[3] Eagle, N. (2011) Mobile Phones as Social Sensors (OxfordUniversity Press). URL http://realitymining.com/pdfs/handbook.05.pdf.

[4] Ganti, R., Ye, F. and Lei, H. (2011) Mobile crowdsensing:current state and future challenges. CommunicationsMagazine, IEEE 49(11): 32–39.

[5] Le, V.D., Scholten, H. and Havinga, P. (2012) Towardsopportunistic data dissemination in mobile phonesensor networks. In Eleventh International Conferenceon Networks, ICN 2012 (France: International Academy,Research and Industry Association (IARIA)): 139–146.

[6] Sherchan, W., Jayaraman, P., Krishnaswamy, S.,Zaslavsky, A., Loke, S. and Sinha, A. (2012) Usingon-the-move mining for mobile crowdsensing. In MobileData Management (MDM), 2012 IEEE 13th InternationalConference on: 115–124.

[7] Brouwers, N. and Langendoen, K. (2012) Pogo, a mid-dleware for mobile phone sensing. In Proceedings of the13th International Middleware Conference, Middleware’12 (New York, NY, USA: Springer-Verlag New York, Inc.):21–40.

[8] Kargupta, H., Sarkar, K. and Gilligan, M. (2010)Minefleet: an overview of a widely adopted distributedvehicle performance data mining system. In Proceedingsof the 16th ACM SIGKDD international conference onKnowledge discovery and data mining, KDD ’10 (NewYork, NY, USA: ACM): 37–46.

[9] Zaslavsky, A., Perera, C. and Georgakopoulos, D.(2012) Sensing as a service and big data. In InternationalConference on Advances in Cloud Computing (ACC-2012)(Bangalore, India): 21–29.

[10] Perera, C., Zaslavsky, A., Christen, P. and Geor-gakopoulos, D. (2014) Sensing as a service model forsmart cities supported by internet of things. Transac-tions on Emerging Telecommunications Technologies (ETT): n/a–n/a.

[11] Choudhury, T., Consolvo, S., Harrison, B., Hightower,J., LaMarca, A., Legrand, L., Rahimi, A. et al. (2008)The mobile sensing platform: An embedded activityrecognition system. Pervasive Computing, IEEE 7(2): 32–41.

[12] Starner, T. (1999) Wearable computing and contextualawarenes. Ph.D. thesis, Massachusetts Institute ofTechnology. Dept. of Architecture. Program in MediaArts and Sciences. URL http://hdl.handle.net/1721.1/9543.

[13] Perera, C., Zaslavsky, A., Christen, P. and Geor-gakopoulos, D. (2013) Context aware computing forthe internet of things: A survey. Communications SurveysTutorials, IEEE xx: x–x.

[14] Gomes, J., Krishnaswamy, S., Gaber, M., Sousa, P.and Menasalvas, E. (2012) Mobile activity recognitionusing ubiquitous data stream mining. In Cuzzocrea, A.and Dayal, U. [eds.] Data Warehousing and KnowledgeDiscovery (Springer Berlin Heidelberg), Lecture Notes inComputer Science 7448, 130–141.

[15] Raento, M., Oulasvirta, A., Petit, R. and Toivonen,H. (2005) Contextphone: a prototyping platform forcontext-aware mobile applications. Pervasive Computing,IEEE 4(2): 51–59.

[16] Metrosense. URL http://metrosense.cs.dartmouth.edu/[Accessedon:2013-08-06].

[17] Miluzzo, E., Lane, N.D., Eisenman, S.B. and Campbell,A.T. (2007) Cenceme: injecting sensing presence intosocial networking applications. In Proceedings of the2nd European conference on Smart sensing and context,EuroSSC’07 (Berlin, Heidelberg: Springer-Verlag): 1–28.

[18] Liu, X., Lu, M., Ooi, B.C., Shen, Y., Wu, S. and Zhang,M. (2012) Cdas: a crowdsourcing data analytics system.Proc. VLDB Endow. 5(10): 1040–1051.

[19] Kazemi, L. and Shahabi, C. (2012) Geocrowd: Enablingquery answering with spatial crowdsourcing. InProceedings of the 20th International Conferenceon Advances in Geographic Information Systems,SIGSPATIAL ’12 (New York, NY, USA: ACM):189–198. doi:10.1145/2424321.2424346, URLhttp://doi.acm.org/10.1145/2424321.2424346.

[20] Ye, F., Ganti, R., Dimaghani, R., Grueneberg, K.and Calo, S. (2012) Meca: mobile edge capture andanalysis middleware for social sensing applications. InProceedings of the 21st international conference companionon World Wide Web: 699Ű702.


http://tinyurl.com/pbodtus [Accessed on: 2013-08-06]http://tinyurl.com/pbodtus [Accessed on: 2013-08-06]http://realitymining.com/pdfs/handbook.05.pdfhttp://realitymining.com/pdfs/handbook.05.pdfhttp://hdl.handle.net/1721.1/9543http://hdl.handle.net/1721.1/9543http://metrosense.cs.dartmouth.edu/ [Accessed on: 2013-08-06]http://metrosense.cs.dartmouth.edu/ [Accessed on: 2013-08-06]http://dx.doi.org/10.1145/2424321.2424346http://doi.acm.org/10.1145/2424321.2424346


[21] Jayaraman, P.P., Perera, C., Georgakopoulos, D. andZaslavsky, A. (October, 2013) Efficient opportunisticsensing using mobile collaborative platform mosden.In 9th IEEE International Conference on CollaborativeComputing: Networking, Applications and Worksharing(COLLABORATECOM) (Austin, Texas, United States).

[22] GSN Team (2011), Global sensor networks project.URL http://sourceforge.net/apps/trac/gsn/[Accessedon:2011-12-16].

[23] Phenonet: wireless sensors in agriculture.URL http://www.csiro.au/Outcomes/ICT-and-Services/National-Challenges/Wireless-sensors-in-agriculture.aspx.

[24] Aberer, K., Hauswirth, M. and Salehi, A. (2007) Infras-tructure for data processing in large-scale intercon-nected sensor networks. In International Conference onMobile Data Management: 198–205.


http://sourceforge.net/apps/trac/gsn/ [Accessed on: 2011-12-16]http://sourceforge.net/apps/trac/gsn/ [Accessed on: 2011-12-16]http://www.csiro.au/Outcomes/ICT-and-Services/National-Challenges/Wireless-sensors-in-agriculture.aspxhttp://www.csiro.au/Outcomes/ICT-and-Services/National-Challenges/Wireless-sensors-in-agriculture.aspxhttp://www.csiro.au/Outcomes/ICT-and-Services/National-Challenges/Wireless-sensors-in-agriculture.aspx

1 Introduction2 Related Work3 Opportunistic Sensing Scenario4 MObile Sensor Data ENgine (MOSDEN): A collaborative mobile opportunistic sensing platformArchitecture

5 Implementing a Collaborative opportunistic sensing Application using MOSDENBenefits of MOSDEN Design

6 Evaluation of MOSDEN Platform6.1 Experimentation Testbed and Setup6.2 Experimental Results and DiscussionCPU and Memory Consumption ExperimentStorage Requirements ExperimentQuery Processing ExperimentEnergy Consumption ExperimentDiscussion

7 Conclusion and Future Work

Documents

ICST Transactions Preprint MOSDEN: A Scalable Mobile … · ICST Transactions Preprint MOSDEN: A Scalable Mobile Collaborative Platform for Opportunistic Sensing Applications Prem