-
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/
2ICST Transactions Preprint
-
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
3ICST Transactions Preprint
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
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.
4ICST Transactions Preprint
-
MOSDEN: A Scalable Mobile Collaborative Platform for
Opportunistic Sensing Applications
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
5ICST Transactions Preprint
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
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
6ICST Transactions Preprint
-
MOSDEN: A Scalable Mobile Collaborative Platform for
Opportunistic Sensing Applications
(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.
7ICST Transactions Preprint
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
(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
8ICST Transactions Preprint
-
MOSDEN: A Scalable Mobile Collaborative Platform for
Opportunistic Sensing Applications
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
9ICST Transactions Preprint
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
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
450Restful StreamingPush-based Streaming
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
10ICST Transactions Preprint
-
MOSDEN: A Scalable Mobile Collaborative Platform for
Opportunistic Sensing Applications
3 6 9 15 30 60 900
10
20
30
40
50
60
70
80Restful StreamingPush-based Streaming
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
160Restful StreamingPush-based Streaming
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
11ICST Transactions Preprint
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
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
12ICST Transactions Preprint
-
MOSDEN: A Scalable Mobile Collaborative Platform for
Opportunistic Sensing Applications
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
13ICST Transactions Preprint
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
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
14ICST Transactions Preprint
-
MOSDEN: A Scalable Mobile Collaborative Platform for
Opportunistic Sensing Applications
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.
15ICST Transactions Preprint
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
-
P.P Jayaraman, C. Perera, D. Georgakopoulos and A. Zaslavsky
[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.
16ICST Transactions Preprint
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