Efficient Opportunistic Sensing using Mobile
Collaborative Platform MOSDEN
Prem Prakash Jayaraman
∗
, Charith Perera, Dimitrios Georgakopoulos and Arkady Zaslavsky
CSIRO Computational Informatics
Canberra, Australia 2601
Email: {prem.jayaraman, charith.perera, dimitrios.georgakopoulos,
arkady.zaslavsky}@csiro.au
∗
Corresponding Author
Abstract—Mobile devices are rapidly becoming the primary
computing device in people’s lives. Application delivery platforms
like Google Play, Apple App Store have transformed mobile
phones into intelligent computing devices by the means of
applications that can be downloaded and installed instantly. Many
of these applications take advantage of the plethora of sensors
installed on the mobile device to deliver enhanced user experience.
The sensors on the smartphone provide the opportunity to
develop innovative mobile opportunistic sensing applications in
many sectors including healthcare, environmental monitoring
and transportation. In this paper, we present a collaborative
mobile sensing framework namely Mobile Sensor Data EngiNe
(MOSDEN) that can operate on smartphones capturing and
sharing sensed data between multiple distributed applications and
users. MOSDEN follows a component-based design philosophy
promoting reuse for easy and quick opportunistic sensing appli-
cation deployments. MOSDEN separates the application-specific
processing from the sensing, storing and sharing. MOSDEN
is scalable and requires minimal development effort from the
application developer. We have implemented our framework on
Android-based mobile platforms and evaluate its performance
to validate the feasibility and efficiency of MOSDEN to oper-
ate collaboratively in mobile opportunistic sensing applications.
Experimental outcomes and lessons learnt conclude the paper.
I. INTRODUCTION
Today mobile phones have become a ubiquitous central
computing and communication device in people’s lives [1].
The mobile device market is growing at a frantic pace and
it wont be long before it outnumbers the human population.
It is predicted that mobile phones combined with tablets will
exceed the human population by 2017 [2]. Mobile phones more
specifically smartphones are equipped with a rich set of on-
board sensors, such as ambient light sensor, accelerometer,
gyroscope, digital compass, GPS, microphone and camera.
Moreover, current generation smartphones are equipped with
technologies such as NFC, Bluetooth, WiFi that enable them
to communicate and interact with external sensors available in
the environment.
Smartphones have the potential to generate an unprece-
dented amount of data [3] that can revolutionise many sectors
of economy, including business, healthcare, social networks,
environmental monitoring and transportation. According to
Gartner
1
, at present, smartphones dominate mobile phone
sales with estimates indicating rapidly increasing smartphone
1
http://www.gartner.com/newsroom/id/2525515
shipments in the future. The data generated by an individual
smartphone can be used to infer information about its user and
to certain extent the environment around the user. By fusing
data from a multitude of smartphones from a population of
users, high level context information can be inferred. E.g.,
using an individual’s smartphone, we can detect the current
activity of the individual [4], [5]. On the other hand, using
data obtained from a population of individual’s, we can detect
the environmental context i.e. ambient light, noise in the
environment [6]. In either form, the data generated by the
smartphones are valuable and offers unique opportunities to
develop novel and innovative applications.
Most mobile sensing applications can be classified into
personal and community sensing [1], [7]. Personal sensing
applications focus on the individual. On the contrary, com-
munity sensing also termed opportunistic/crowdsensing
2
takes
advantage of a population of individuals to measure large-scale
phenomenon that cannot be measured using single individual.
In most cases, the population of individuals participating in
crowdsensing applications share a common goal. To date most
efforts to develop crowdsensing applications have focused
on building monolithic mobile applications that are built for
specific requirements [8]. Further, the sensed data generated
by the application are often available only within the closed
population [9]. However, to realise the greater vision of a
collaborative mobile crowdsensing application, we would need
a common platform that facilitates easy development and
deployment of collaborative crowd-sensed applications.
The key challenge here is to develop a platform that
is autonomous, scalable, interoperable and supports efficient
sensor data collection, processing, storage and sharing. The
autonomous ability of the system enables it to work indepen-
dently when the device is off-line. Further, indiscriminately
collecting all sensor data and transmitting it to a central server
is expensive due to bandwidth and power consumption. We
strongly believe that providing an easy to use, scalable plat-
form to deploy collaborative mobile crowdsensing applications
will be significant for many new applications. To this end, we
propose a collaborative mobile sensing framework namely Mo-
bile Sensor Data Engine (MOSDEN). MOSDEN is capable of
functioning on multitude of resource-constrained devices (e.g.
Raspberry Pi
3
) including smartphones. MOSDEN is a scalable
2
In this paper, we use the terms opportunistic sensing , crowdsensing and
participatory sensing synonymously.
3
http://www.raspberrypi.org/
arXiv:1310.4052v1 [cs.NI] 15 Oct 2013
platform that enables collaborative processing of sensor data.
The platform follows a component-based system paradigm
allowing users to implement custom algorithms and models
depending on application requirements. The key contributions
of this paper are summarised as follows:
• We present the design and implementation of MOS-
DEN, a scalable, easy to use, interoperable platform
that facilitates the development of collaborative mobile
crowdsensing applications
• We demonstrate the ease of development and deploy-
ment using MOSDEN platform by demonstrating a
collaborative mobile crowdsensing application
• We present experimental evaluation of MOSDEN’s
ability to respond to user queries under varying work-
loads to validate the scalability and performance of
MOSDEN.
The rest of the paper is organised as follows. Section
II discusses related work. Section III considers a motivation
scenario. Section IV presents the proposed MOSDEN platform
architecture. Section V discusses MOSDEN implementation
and Section VI presents MOSDEN platform evaluations and
results. Section VI concludes the paper with indicators to
future work.
II. RECENT WORK
Mobile crowdsensing popularly called community sensing
[9], [10] is an autonomous collaborative sensing approach that
requires minimal user involvement (e.g. continuous processing
of noise level around users location). Numerous real and
successful mobile crowd-sensing applications have emerged
in recent times such as WAYZ
4
for real-time traffic/navigation
information and Wazer2
5
for real-time, location-based citizen
journalism, context-aware open-mobile miner (CAROMM) [6]
among others. Mobile crowdsensing applications [11], [12]
thrive on the data obtained from diverse sets of smart phones
owned and operated by humans. Until recently mobile sensing
application such as activity recognition (personal sensing),
where people’s activity (e.g. walking, talking, sitting) is clas-
sified and monitored, required specialised mobile devices [4],
[5]. This has significantly changed with advent of smartphones
equipped with powerful computing, storage and on-board sens-
ing capabilities. More recently, research efforts have focused
on development of activity recognition, context-aware [13]
and data mining models on smartphones [14]–[16] that take
advantage of smartphone’s on-board sensing capabilities.
The efforts to build crowdsensing application have focused
on building monolithic mobile application frameworks that
are built for specific purpose and requirements. Extending
these frameworks to develop new applications is difficult, time-
consuming and in some cases impossible. Crowd-sourcing data
analytics system (CDAS) [17] is an example of a crowd-
sensing framework. In CDAS, the participants are part of a
distributed crowd-sensed system. The CDAS system enables
deployment of various crowd-sensing applications that require
human involvement for simple verification tasks delivering
4
http://www.wayz.com/
5
https://www.wazer2.co.il/
high accuracy. The system follows a two-stage approach. In the
first stage, the given job is performed by a high-performance
computer. The result of the job is then broken into subparts
and sent to human workers for verification using Amazon
Mechanical Turk (AMT). The results from human workers
are combined to compute the final result. The CDAS system
incorporates complex analytics that enables it to disseminate
jobs, obtain results and compare results obtained from different
workers to determine the correct one. Mobile edge capture and
analysis middleware for social sensing applications (MECA)
[18] is another middleware for efficient data collection from
mobile devices in a efficient, flexible and scalable manner.
MECA provides a platform by which different applications can
use data generated from diverse mobile data sources (sensors).
The proposed MECA architecture has three layers comprising
data layer (mobile data sources mobile phones), edge layer
(base stations that select and instruct a device or group of de-
vices to collect data and process data), phenomena/application
layer (the backend that determines the edge nodes to process
application request). The mobile analytics performed on the
data in CDAS and MECA are at the cloud/remote-server layer.
The MetroSense [19] project at Dartmouth is an example
of another crowdsensing system. The project aims in develop-
ing classification techniques, privacy approaches and sensing
paradigms for mobile phones. The CenceMe [?] project under
the MetroSense umbrella is a personal sensing system that
enable members of social networks to share their presence.
The CenceMe application incorporates mobile 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, high ozone) to determine presence. The CenceMe
system comprises two parts, the phone software and back-
end software. The phone software is implemented on a Nokia
N95 running Symbian operating system. The phone software is
developed in Java Micro Edition (JME) which interfaces with
Symbian C++ modules controlling the hardware. MineFleet
[15] is a distributed vehicle performance data mining system
designed for commercial fleets. In MineFleet [15], dedicated
patented custom built hardware devices are used on fleet trucks
to continuously process data generated by the truck. MineFleet
system comprises an onboard data stream mining module that
performs extensive processing of data using various statistical
and data stream mining algorithms. This data stored locally
is transmitted to an external MineFleet Server for further
processing when network connectivity is available.
Mobile crowdsensing is becoming a vital technique and has
the potential to realise many applications that require large
amounts of data from distributed communities in a collabo-
rative fashion. The aforementioned crowdsensing frameworks
and applications are mostly hard wired allowing very little flex-
ibility to develop new applications. Further, frameworks like
MECA [18] use the smartphone as a dumb data generator while
all processing is offloaded to the server layer (Edge). This is
good for certain types of applications but may not be suitable
in scenarios where the smart phone may go off-line [20].
Moreover, crowdsensing applications like Waze, MetroSense
[19] and MineFleet [15] are built around specific data handling
models (e.g. GPS for Waze, Microphone for MetroSense and
Data mining algorithms for object monitoring). On contrast,
the proposed MOSDEN platform has been developed with the
2
2
1
1
1
MOSDEN
MOSDEN
MOSDEN
MOSDEN
User communities
User communities
Cloud platform for
Resource Intensive processing
Applications Using
Crowd sensed data
3
1
2
Fig. 1: Environmental Monitoring - Mobile Crowdsensing Scenario
design goal of ease of use, ease of development/deployment,
scalability, easy access to both on-board and external sensors,
support for on-board data analytics and collaboration and
data sharing. The MOSDEN platform provides the applica-
tion developer with implementation options i.e. choice of
using processing on the smartphone and/or processing at the
server. The MOSDEN platform promotes a distributed sensing
infrastructure where each MOSDEN instance running on a
smartphone is self-managed.
III. MOTIVATING SCENARIO - ENVIRONMENTAL
MONITORING
In this section we present a motivating futuristic scenario
that explains the need for a scalable, collaborative, mobile
sensing platform like MOSDEN. The scenario under consid-
eration is an environmental monitoring scenario (e.g. noise
pollution) in smart cities as depicted in Figure 1. In step (1),
a remote-server (cloud-based) registers the interest for data
within user communities. In the example depicted in Figure
1, the user communities are grouped based on location. In
step (2), the processed data from the smartphones are sent to
the remote-server (push/pull). In step (3), the crowd-sensing
application obtains data from the remote-server for further
processing and visualisation. The above scenario is a typical
case for many crowdsensing applications that require data
from diverse user communities. The same approach can be
used to deploy a crowdsensing application that computes air
pollution within the environment. To this, the smartphone
will also have to rely on external sensors that are part of a
smart city infrastructure to obtain air pollution data. Using a
monolithic approach may results in developing a niche class of
applications that may not be scalable for other scenarios which
is a major obstacle. To achieve this goal, the crowdsensing
platform needs to support real-time data collection, processing
and storage, support to implement specific algorithms/models,
energy-efficient operation, autonomous functions i.e. ability
to work with minimal user interaction and support offline
modes. The proposed MOSDEN platform supports the above
mentioned features natively.
IV. MOSDEN - MOBILE SENSOR DATA ENGINE
We propose MOSDEN, a crowdsensing platform built
around the following design principles:
• Separation of data collection, processing and storage
to application specific logic
• A distributed collaborative crowdsensing application
deployment with relative ease
• Support for autonomous functioning i.e. ability to self-
manage as a part of the distributed architecture
• A component-based system that supports access to
internal and external sensor and implementation of
domain specific models and algorithms
These design principles address the obstacles mentioned in
Section III. The proposed MOSDEN platform overcomes the
key barriers of developing and deploying scalable collaborative
mobile crowdsensing applications.
A. Platform Architecture
MOSDEN platform follows similar design principle of
Global Sensor Network (GSN) architecture [21]. GSN is
a sensor network middleware developed to run on high-
powered computing devices (e.g. servers and cloud resources).
GSN presents a unified middleware approach that facilitates
acquisition, processing and storage of sensor data. It uses
the concept of virtual sensors that abstracts the underly-
ing data source (e.g. wireless sensor network). Since, GSN
was not developed for resource constrained environment, we
made significant enhancement to GSN when designing and
implementing MOSDEN. MOSDEN follows a component-
based architecture allowing extensibility without modifying the
existing codebase. The architecture of the proposed MOSDEN
platform is presented in Figure 3 followed by description of
each component.
Plugin: In MOSDEN, we introduce the concept of Plugins.
In GSN, a developer had to implement wrappers to
accommodate new sensor data sources into the system.
This required the system to be recompiled and redeployed.
This approach is not very practical. The use of plugin
overcomes this challenge. The Plugins are independent
applications that communicates with MOSDEN. Plugin
define how a sensor communicates with MOSDEN. We
have developed a plugin descriptor that crowdsensing
application developer can use to implement plugins for
the new sensor types. MOSDEN can dynamically discover
new plugins at run-time. A conceptual description of the
plugin is shown in XML format in Figure 2.
<DataFields>
<DataField>
<name> accelerationX_axis_incl_gravity </name>
<type> double </type>
<description> Acceleration force along the X axis
(including gravity)measures in m/s2.
</description>
</DataField>
<DataField>
<name> accelerationY_axis_incl_gravity </name>
<type> double </type>
<description> Acceleration force along the Y axis
(including gravity)measures in m/s2.
</description>
</DataField>
<DataField>
<name> accelerationZ_axis_incl_gravity </name>
<type> double </type>
<description> Acceleration force along the Z axis
(including gravity)measures in m/s2.
</description>
</DataField>
</DataFields>
Fig. 2: A Conceptual Description of MOSDEN Plugin
Virtual Sensor: The virtual sensor is an abstraction of the
underlying data source from which data is obtained. This
concept has been carried forward from GSN design. The
virtual sensor lifecycle manager is responsible to manage
the instantiation, updation and removal of virtual sensor
resources.
Processors: The processor classes are used to implement
custom models and algorithms that processes the incom-
ing data. For example, a Fast Fourier Transform (FFT)
algorithm to compute the decibel level from microphone
recordings.
Storage Manager: The raw data acquired from the sensor
is processed by the processing classes and stored locally.
This is a key feature of MOSDEN as local storage
supports off-line modes.
Query Manager: The query manager is responsible to
resolve and answer queries from external source. An
external source can be another MOSDEN instance, a
user or an application querying for data collected by the
smartphone.
Service Manager: The service manager is responsible to
manage subscriptions to data from external sources. The
service manager registers subscription request and de-
pending on the mode of data delivery (push/pull) will de-
liver available data to the requested external source when
possible. The service manager is specifically designed to
manage the working on MOSDEN in resource constrained
environments where frequent disconnection occurs.
API Manager: The application programmable interfaces
(APIs) provides a standard way to subscribe and access
data to/from MOSDEN instances. The API’s requests are
received and processed over HTTP.
Each MOSDEN instance running on the mobile smart-
S S S S
Sensors
Plugin Plugin Plugin Plugin
Smartphone
MOSDEN
Virtual Sensor Virtual Sensor Virtual Sensor
Virtual Sensor Lifecycle Manager
Storage Manager
Query Manager
Service Manager
API (HTTP)
External Sensors
Processor Processor Processor
Processor Lifecycle Manager
...
...
S S SS
Fig. 3: MOSDEN Platform Architecture
phones can run with minimal user interaction. It can register
a data request from a remote-server (e.g. cloud-based). MOS-
DEN then works in the background processing the request by
collecting, processing and storing the requested data locally.
When the processed data is required by the application running
at the remote-server, it can query the MOSDEN instance
for the data (push/pull). MOSDEN realises a true distributed
system architecture as it has the ability to function independent
of the remote-server (support for off-line modes).
As depicted in the architecture, each individual MOS-
DEN instance is self contained and managed and is capable
of working in mobile environments that encounter frequent
disconnections. The use of APIs to communicate between
instances encourages collaborative workload sharing and pro-
cessing. The plugin based approach increases usability and
promotes interoperability allowing MOSDEN to communicate
with any sensors both internal and external. This remove the
burden on crowdsensing application developer. Further, the use
of a component-based architecture enables system developers
to implement domain specific algorithms with ease. Moreover,
the MOSDEN platform enables the development of mobile
crowdsensing applications that can scale from an individual
to a community. For example, the platform can be used to
develop a personal fitness monitor application that works on
an individual smartphone taking advantage of on-board sensing
capabilities to noise pollution application that compute noise
pollution by obtaining inputs from a community of users.
V. IMPLEMENTING A CROWDSENSING APPLICATION
USING MOSDEN
In Section III we presented an environmental monitoring
scenario to determine the noise pollution level from data
obtained from a community of user. Using the information
obtained from the user communities, a crowdsensing appli-
cation running on a remote-server can further analyse and
visualise the noise pollution level at a given location. Each
user community in this scenario is grouped by location.
In this section we present a detailed description of the
noise pollution crowdsensing proof-of-concept application im-
plementation using MOSDEN platform. Figure 4 presents
the overview of the noise pollution crowdsensing application
implemented on MOSDEN platform. In the scenario depicted
MOSDEN
MOSDEN
MOSDEN
Global Sensor
Network
Message Broker
1
1
1
1
2
2
2
Fig. 4: Implementation of Crowdsensing Application using
MOSDEN
in 4, in step (1) MOSDEN instances running on the smartphone
registers with the cloud GSN instance. Once registration is
complete in step (2) the cloud GSN instance registers its
interest to receive noise data from MOSDEN. When data is
available, MOSDEN streams the data to the cloud GSN. The
streaming processes can be push or pull based depending on
application requirement. In this specific example we imple-
mented a pull-based approach.
The MOSDEN reference architecture has been imple-
mented on the Android
6
platform. We deployed the noise
pollution application developed on MOSDEN platform on a set
of smartphones that represent user communities. To compute
the noise decibel level, we implemented a modified version
of the processing class from Audalyzer open source project
7
.
The microphone sensor on the smartphones was used to obtain
raw sound recordings. Code to interface with the sensor was
already available as a part of the MOSDEN platform via
plugins (we have developed plugins for on-board sensors). As
MOSDEN is similar to GSN design, it is compatible with GSN.
For our proof-of-concept implementation, we implemented
GSN in the cloud that queries data from individual MOSDEN
instances. A MOSDEN instance registers itself with the GSN
in the cloud. As we stated earlier, the design of MOSDEN
makes it easily extensible to suit any crowdsensing application
requirements. To validate this, we implemented the registration
process via a message broker as depicted in Figure 4. Along
with the registration, each MOSDEN instances also updates
the cloud GSN instance with a list of available sensors. We
note, MOSDEN API supports any form of registration. It is
the responsibility of the crowdsensing application developer
to choose the most appropriate registration process. It is to
be noted that the cloud GSN instance can be replaced by
another smartphone running MOSDEN. In such a scenario,
the MOSDEN requesting crowdsensed data performs further
processing and visualisation. Screenshots of the MOSDEN
implementation on Android smartphone (Figure 5a) and GSN
in the cloud (Figure 5b, 5c) are illustrated in Figure 5. We note,
the default version of GSN with no enhancements was used to
demonstrated the proof-of-concept implementation. Figure 5c
depicts the noise graph computed from 3 MOSDEN users. In
this example, we have plotted the noise data individually.
6
http://www.android.com/
7
https://code.google.com/p/moonblink/
(a) MOSDEN User Interface
(b) GSN Sensor Registration Screenshot
(c) GSN Noise Plot Screenshot
Fig. 5: Crowdsensing Application - Noise Pollution - Screen-
shots
