MOSDEN: An Internet of Things Middleware forResource Constrained Mobile Devices

Charith Perera, Prem Prakash Jayaraman,Arkady Zaslavsky, Dimitrios Georgakopoulos

CSIRO ICT Center, Canberra, ACT 2601, Australia{charith.perera, prem.jayaraman, arkady.zaslavsky,

dimitrios.georgakopoulos}@csiro.au

Peter ChristenResearch School of Computer Science,

The Australian National University,Canberra, ACT 0200, Australia

peter.christen@anu.edu.au

Abstract—The Internet of Things (IoT) is part of FutureInternet and will comprise many billions of Internet ConnectedObjects (ICO) or ‘things’ where things can sense, communicate,compute and potentially actuate as well as have intelligence,multi-modal interfaces, physical/ virtual identities and attributes.Collecting data from these objects is an important task as itallows software systems to understand the environment better.Many different hardware devices may involve in the process ofcollecting and uploading sensor data to the cloud where complexprocessing can occur. Further, we cannot expect all these objectsto be connected to the computers due to technical and economicalreasons. Therefore, we should be able to utilize resource con-strained devices to collect data from these ICOs. On the otherhand, it is critical to process the collected sensor data beforesending them to the cloud to make sure the sustainability of theinfrastructure due to energy constraints. This requires to movethe sensor data processing tasks towards the resource constrainedcomputational devices (e.g. mobile phones). In this paper, wepropose Mobile Sensor Data Processing Engine (MOSDEN), anplug-in-based IoT middleware for mobile devices, that allows tocollect and process sensor data without programming efforts. Ourarchitecture also supports sensing as a service model. We presentthe results of the evaluations that demonstrate its suitabilitytowards real world deployments. Our proposed middleware isbuilt on Android platform.

I. INTRODUCTION

Internet of Things (IoT) [4] is a part of future Internetand ubiquitous computing. It envisions interactions betweenthings1 that consists of sensors and actuators. As the priceof sensors diminishes rapidly, we can soon expect to seevery large numbers of things. The vision of IoT is to allow‘things’ to be connected anytime, anyplace, with anythingand anyone, ideally using any path, any network and anyservice [20]. In order to realise this vision, we need a commonoperating platform namely middleware that is scalable andsupports high level of interoperability. This platform enablessensor data collection, processing, and analysis. Efficient andfeature rich IoT middeware platforms are key enablers of IoTparadigm. We are currently observing an emerging trend inmiddelware solutions that enable IoT [8]. However, most ofthe solutions are designed and developed to be used in thecloud environments where abundant resources are available.We believe that middleware solutions designed specifically

1We use terms objects, things, smart objects, devices, nodes to give thesame meaning as they are frequently used in IoT related documentationinterchangeably.

for low powered resource constrained computation devices arecritical in order realise the vision on IoT.

In this paper, we propose an IoT middleware solution thatcan work on resource constrained mobile devices allowingthem to collect and process data from sensors easily. To achievethis, we extend existing middleware solution namely GlobalSensor Network (GSN) [1] as well as propose new strategiesthat make our solution more scalable and user friendly. Thecontribution of this paper can be summarised as follows:

• We present the design and implementation detailsof our proposed middleware solution namely MobileSensor Data Processing Engine (MOSDEN). MOS-DEN is designed to support sensing as a servicemodel [15] natively. Further, MOSDEN is a true zeroprogramming middleware where users do not need towrite program code or any other specifications usingdeclarative languages. Our solution also supports bothpush and pull data streaming mechanism as well ascentralised and decentralised (e.g. peer-to-peer) datacommunication.

• We employ a plugin architecture, so developers candevelop plugins allowing MOSDEN to communicatewith for their sensor hardware. We also utilize theapplication markets that are built around android plat-form to efficiently share and distribute plugins.

• We designed and developed MOSDEN in such away that it is interoperable with other cloud-basedmiddleware solutions such as GSN. Our pluggablearchitecture is scalable and promotes ease-of-use.

• We present results of evaluating the performance ofMOSDEN using devices with different capabilitiesand resource constraints in order to validate MOS-DEN’s scalability and suitability towards IoT domain.

The rest of this paper is structured as follows. SectionII presents the background and the motivation. We set thebackground in two different perspectives: Internet of Thingsarchitecture and sensing as a service model. In Section III,we defines the research challenges that we have addressed inthis paper. Subsequently, Section IV discusses the architecturaldesign in details. Implementation details are presented inSection V. Section VI presents the evaluation of our IoTmiddleware using three mobile devices with different resourcelimitations. We also discuss the results in detail followed by

arX

iv:1

310.

4038

v1 [

cs.N

I] 1

5 O

ct 2

013

Cloud (Internet)Sensor Nodes/Networks (SN)

High-end Computational Devices

Low-end Computational

Devices Sink Nodes

(e.g. Raspberry Pi)

Category 5 Category 4 Category 3 Category 2Category 6 Category 1

Low-end(e.g. Waspmote)

High-end(e.g. Meshlium)

Hig

her

Cat

ego

ries

Low

er C

ateg

orie

s

Fig. 1: Categorization of IoT devices based on their computational capabilities. The devices belong to each category has differentcapabilities depending in term of processing, memory, and communication. They are also different in price where devices becomesmore expensive when move to left. The computational capabilities are also get increased when move to left.

an analysis of lessons learnt. Related literature is reviewed inSection VII under three broad themes. Section VIII concludesthe paper by highlighting future work.

II. BACKGROUND AND MOTIVATION

In this section, we briefly discuss the background andour motivation behind this work. The discussion is mainlystructured under two main areas. First, we explain the hardwareinfrastructure that IoT is intended to use. Second, we explainthe sensing as a service model and how it can fuels theadaptation of IoT. Our work is also stimulated and motivatedby the statistics and prediction related to Internet of Things.Some of the details are discussed in [22].

A. Internet of Things Architecture

Even though IoT envisions billions of ‘things’ to be con-nected to the Internet, it is not possible and practical to connectall of them to the Internet directly. This is mainly due toresource constraints (e.g. network communication capabilitiesand energy limitations). Connecting directly to the internet isexpensive in term of computation, bandwidth usage, and hard-ware cost point of view. Enabling persistent Internet access ischallenging and also negatively impacts on miniaturization andenergy consumption of the sensors. Due to such difficulties,IoT solutions need to utilize different types of devices withdifferent resource limitations and capabilities. In Figure 1, webroadly categorise these devices into 6 categories (also calledlevel or layer).

The computational and connectivity capabilities increaseas we move from right to left. Similarly, devices are alsogetting expensive and larger in form-factor when moving to theleft. We believe that an ideal IoT middleware solution shouldbe able to take advantage and adapt to these different typesof devices in order to make the solution more efficient andeffective. One of the most critical decision that needs to betaken in the domain of IoT is ‘where and ‘when’ to processthe collected data. It is clear that no single solution wouldfit every situation. Though there are many factors need tobe considered, energy consumption for data processing andnetwork communication are among the most important factors.If we denote the energy requirement for data processing as Eα

and energy requirement for data communication over networkas Eβ , the following rule can be used to determine whetherto process data in the current layer or send them to a higherlayer.

• IF (Eα < Eβ ) THEN process locally ELSE send to a nodewith higher capability

Processing data in any device locally before sending themto the higher layers is important in terms of saving energy.However, the type of processing that needs to be performed atthe each device is a difficult choice. Expensive processing candrain the battery quickly. In contrast, sending data frequentlycan also drain the battery quickly due to usage of communi-cation radio [16]. One of our motivations in this work is toaddress this problem. MOSDEN performs data processing andanalytic before transmitting them over a network. More im-portantly, our proposed middleware platform can be installedon devices that belongs to lower level categories which haveresource limitations similar to mobile phones or RaspberryPi2. For prototype implementation and evaluation, we usemobile phones. However, we believe, more cheaper deviceswith similar resource limitations will be available in the marketovertime. MOSDEN can process sensor data based on SQL-like queries such as average which reduces the network com-munication due to sensor data fusion. The processing capabili-ties are discussed further in upcoming sections. Fifty differentsensor application domains are explained in [3]. MOSDENcan be used in all these applications to improve the long-term sustainability of the IoT infrastructures by using availableenergy optimally and reduce unnecessary data communication.Specially, in outdoor sensing applications, it is troublesomeand labour intensive to recharge the batteries of the sensingdevices frequently.

B. Sensing as a service Model

This model provides sensors data to the users / consumer(i.e. anyone need access to sensor data) on-demand [22].Sensing as a service model does not collect sensor datafrom all the available sensors at all times. IoT middlewareplatforms that supports sensing as a service do keep track of theindividual sensors, their availability, and capabilities. However,they do not collect sensor data unless a consumer makes arequest. Our solution, MOSDEN, supports sensing as a servicemodel. Specifically, MOSDEN provides easy way to retrievedata from sensors. MOSDEN also collect information abouteach sensor sends them to the cloud-based IoT middelware(e.g. GSN [1]). Cloud IoT middleware maintains a registry

2The Raspberry Pi is a credit-card-sized single-board computer devel-oped in the UK by the Raspberry Pi Foundation with the intention ofpromoting the teaching of basic computer science in schools. It has max-imum of 512MB memory, up to 1 GHz CPU. One unit cost around $25.http://www.raspberrypi.org/

Internet of Things Middleware (In the Cloud)

Different sensor data consumers use the

sensor data for different purposes

IoT middleware solutions

installed on low level

computation devices collect

data from different types of sensors on

demand (Worker Nodes)

Se

nsor

s

Fig. 2: MOSDEN supports sensing as a service Model. Sensorsthat do not have long-range network communication capabili-ties connect to MOSDEN instances. Then, MOSDEN processthe data and transmit them to the cloud selectively,

of sensors which includes their availabilities and capabilities.Cloud IoT middleware retrieves this information though mul-tiple MOSDEN instances. Once the Cloud IoT middlewarereceives a request from a consumer, it searches the requiredsensors and composes a request query. It then registers therequest with the MOSDEN instance connected to the sensor.

Then, MOSDEN sends data to Cloud IoT middleware untilthe request expires. Figure 2 illustrates the typical architectureof a sensing as a service model and the role of MOSDENintends to play. More importantly, MOSDEN performs dataprocessing before send the data to the server. For example,instead of sending data every 2 seconds, MOSDEN maylocally process, store the data and send the data to the cloudonce a minute by averaging values3. As another example,MOSDEN may collect all sensor data for a minute and sendthem to GSN at once. Such approach can save significantamount of energy due to reduction of network operations(e.g. opening and closing communication radios are energyexpensive operations).

Additionally, MOSDEN locally keeps track of the avail-abilities and capabilities of the sensors attached to each in-stance which makes it is easy and efficient for the cloud IoTmiddleware to stay up to date. Further, different MOSDENinstances connected to cloud IoT middleware are managedusing a publish / subscribe model [2].

III. RESEARCH PROBLEM

We address several research problems in this work. Our fo-cus areas are energy efficient and effective data processing andnetwork communication, cost efficient infrastructure supportfor large scale IoT deployment, and usability in connecting/ configuring sensors. In the earlier section, we highlightedthe importance of addressing the above mentioned researchchallenges: (1) the importance of processing data locally beforetransmitting to the cloud, (2) the importance of utilizingdevices with different computational capabilities and pricetags, and (3) the importance of providing efficient and easyway to connect sensors to low level computational devices(devices belongs to category 3 and 4 in Figure 1).

3The sampling rate and the data processing operation that may exactly usein each situation depends on the user requirement

There are several commercial solutions4 that have beenproposed in order to address some of the above mentionedchallenges. However, these solution have several weakness.The following brief analysis helps to identify those weaknessesas well as to identify the ideal design requirements of an IoTmiddleware that needs to be installed on resource constraineddevices. Though some of the hardware components are opensourced, software systems remain closed source which makesit hard to extend and interoperate. Further, these solutionshave their own hardware devices that performs tasks similarto MOSDEN. However, these devices are custom built. Webelieve, utilizing commonly available devices such as mobilephones, makes it easy to adopt due to the fact the most ofthe people are familiar with mobile phones and know howto operate them in comparison to custom build proprietarydevices. Another major drawback is inability for devices tointeroperate with solutions provided by different vendors. Forexample, a sensor designed to be used by one solution cannotbe connected to the software system of another solution..Hence, our proposed middleware aims to be vendor agnostic.

IV. MOSDEN: ARCHITECTURAL DESIGN

In this section, we explain the design decisions in details.First, we present the reasons behind introducing a pluginarchitecture. Secondly, we explain the complete MOSDENarchitecture. Thirdly, we explain how MOSDEN interacts withits peers as well as cloud companions. Finally, we explainhow distributed processing performed collectively by cloudcompanions (i.e. GSN instances) and MOSDEN instances.

A. Plugin Architecture

In MOSDEN, we employed a plugin architecture [9] inorder to support three main requirements: scalability, usability,and community based development. A plugin is a independentsoftware component that adds a specific feature to an existingsoftware application. In MOSDEN, each plugin translatesgeneric communication messages to sensor specific commandsin order to enable communication between MOSDEN anda specific sensor. When an application supports plugins, itenables customization. Further, MOSDEN plugins can beinstalled and configured at run time.

Scalability: Due to plugin approach, MOSDEN can vir-tually support any sensor in the world. Anyone can developplugins that allow MOSDEN to communicate with given sen-sors. Further, plugins consumes very small amount of storagespace (e.g. 25KB). Therefore, large number of plugins can bestored even in a resource limited mobile device. Furthermore,MOSDEN automatically removes unused plugins when thememory is running low. New plugins can be downloadedthrough application stores such as Google Play or directlyas .apk files. Separation of plugins from the main MOSDENapplication, helps to reduce the size of the application andalso promotes plug-n-play. Practically, at a given point of time,only small number of plugins need to be installed in order tofacilitate sensor communication though thousands of pluginswould be available on applications stores. Finally, the pluginarchitecture allows us to improve MOSDEN in the future,

4TWINE (supermechanical.com), Ninja Blocks (ninjablocks.com), andSmart Things (smartthings.com)

S

S

S

S

S

W

W

W

W

W Virtu

al Se

nsor Ma

nager

Input S

tream

M

anage

r

Stre

am

Qu

ality Man

ager

Life cycle

Mana

ger

Sto

rage

Query Manager

Query R

epositor y

Qu

ery Pro

cesso

r

Notification M

an ager

VS

VS

VSA

pplicatio

ns and S

ervices

P

P

P

P

PPlugin

Manager1

2

3

4

5

1

2

3

4

5

Fig. 3: The architectural design of the MOSDEN. Legend: Sensor (S), Plugin (P), Wrapper (W), Virtual Sensor (VS). Pluginscommunicates with the sensors and retrieve data. Each plugin should be compatible with the sensor it wants to communicateswith. Plugins compatible with different sensors can be downloaded from Google Play

specially in the directions of automated sensor discovery andplugin installation based on context information.

Usability: MOSDEN is convenient to use as it allowsto collect data from sensors without programming efforts.Users are only required to download the matching pluginfrom an application store. Due to standardise plugin structure,MOSDEN knows how to communicate with each plugin. Forthe user, all the technical complexities and details are hiddenand happen autonomously behind the scene.

Community-based Development: Plugin architecture al-lows us to engage with developer communities and supportvariety of different sensors through community-based devel-opment. Our software are expected to release as free andopen source software in the future. We provide the mainMOSDEN application as well as the standard interfaces wheredevelopers can use to start develop their own plugins to supportdifferent sensors. We provide a sample plugin source codewhere developers only need to add their code according tothe guidelines provided. Plugin model support to increasinglyenable the number of sensors supported by MOSDEN. Pluginsfor MOSDEN can be downloaded via applications stores suchas Google play.

B. General Architecture

The architecture of MOSDEN is presented in Figure 3.MOSDEN architecture is based on the GSN architecture [1].Additionally, we made several changes to the architecture inorder to improve the efficiency as well as scalability. The majorchange is that we added a plugin manager and a plugin layerto support and manipulate plugins. GSN requires differentwrappers to connect to different sensors. We eliminate thisrequirement and instead developed a single generic wrapperto handle the communication. In MOSDEN, wrappers do notdirectly communicate with sensors. Instead, the generic wrap-per communicates with plugins and plugin communicates withthe sensors (i.e. wrapper→ plugins (Pi)→ Sensor (Si)). Due tothe introduction of a generic wrapper, manual re-compilationof MOSDEN is not required when new sensors are added.Our newly added plugin manager component communicateswith the cloud based GSN instances as well as MOSDENpeer instances and share the information about the sensors

connected to them. All the other architectural componentsbehave as same as in the GSN middleware [1].

C. Interaction with the Cloud and Peers

MOSDEN is design to be used as part of the sensing as aservice model. On the other hand, due to that fact that our codeis based on GSN middleware, MOSDEN is 100% compatiblewith GSN. This means communication between GSN instancesand MOSDEN instance can be performed natively withoutany additional effort. Further, MOSDEN is a part of ouroverall vision of providing middleware support across differentcategories of devices as depicted in Figure 1. The typical inter-actions between GSN cloud instance and MOSDEN instancesare illustrated in Figure 4. There are three main interaction thatare frequently performed between MOSDEN instances and aGSN cloud instance. During our work, we also extended thecloud GSN architecture in order to support these interactions.When MOSDEN instance detect a new sensor connected toit through a plugin, it retrieves additional context informationabout the sensor (e.g. type of the sensor, unit measurements,manufacturer) from the sensor itself. Then, MOSDEN registersthe newly detected sensor in the cloud GSN instance. DifferentMOSDEN instances register their own sensors independentlyni the cloud GSN instance. Cloud GSN combines all theinformation and model the data using the Semantic Sensornetwork ontology (www.w3.org/2005/Incubator/ssn/ssnx/ssn).

S1

S4

S6

Sensor Plugin 1

Sensor Plugin 2

Wra

pp

er

La

yer

Mobile Phone

Da

ta

Str

ea

me

rC

on

figu

ratio

n H

an

dle

r

Sensor Plugin 3

MO

SD

EN

In

stan

ce 1

Sensor Registry (based on Semantic

Sensor Network Ontology)

S1

S4

S7

S12

S15

Sensor Plugin 4

Sensor Plugin 5

Wra

pp

er

La

yer

Da

ta

Str

ea

me

rC

on

figu

ratio

n H

an

dle

r

Sensor Plugin 6

S6

S7

S12

S15

MO

SD

EN

In

stan

ce 2

MOSDEN 1

MOSDEN 1

MOSDEN 1

MOSDEN 2

MOSDEN 2

MOSDEN 2

32

1

12

3

Cloud GSN instance

1 Registration of sensor information

2 Cloud GSN makes the request for sensor data

3 MOSDEN instance streams data to the Cloud GSN based on its requirement specification

Fig. 4: Interactions between MOSDEN and Cloud GSN

When the cloud GSN instance receives a request from auser, it queries the sensor description registry in order to findout the relevant sensors that matches the user requirements.Then, it finds the MOSDEN instances that are capable offulfilling the user request (i.e. whether the given MOSDENis capable of collecting data from a sensor which is requiredby the user). Subsequently, GSN instance sends the requeststo MOSDEN instances. Then, each MOSDEN registers therequest. Finally, MOSDEN starts streaming the requested datato the cloud GSN instance. The cloud GSN instance can makethe requests in both pull and push mechanisms. In the pullmethod, GSN makes the request every time it wants data fromMOSDEN. In push method, cloud GSN sends the request andMOSDEN sends the data back until the request expires.

D. Distributed Processing

Our proposed IoT middleware platform capable of runningon different resource constrained mobile devices supportsdistribute processing. Even though in this paper, we do notdiscuss distributed processing in detail, it is important tonote that, processing data locally saves substantial amountof network communication cost. Additionally, peer to peerdata communication and processing is also important. Forexample, multiple MOSDEN instance can interact in peer topeer communication mode without having central controllersuch as cloud MOSDEN. All the processes discussed earlieris also valid in such scenarios.

V. IMPLEMENTATION

In this section, we describe the implementation details ofMOSDEN. First, we present an overview of the developmentplatforms, tools and technologies we used to develop theproposed solution. Further, we illustrate some of user interfacesprovided in MOSDEN. We also discuss how we implementedthe plugin architecture and the steps and guidelines that needto be followed in order to develop new plugins that arecompatible with MOSDEN.

Our middleware is written in Java and runs on Androidbased devices. We used Java to develop our middleware inorder to make sure the compatibility with its cloud basedcompanion, GSN middleware [1]. Further, we selected An-droid platform due to its availability and the popularity5.Another important factor is the portability of the Androidplatform. Android is not intended to be a platform only formobile phones. The leading developer of the Andorid platform,Google Inc., intends to use if for many other smart devicessuch as automobiles, refrigerators, televisions, and so on. Thisvision supports our objectives we discussed earlier in SectionII. Therefore, the objective of developing MOSDEN is not onlyto support mobile phone platforms but also to support devicessuch as Raspberry Pi (raspberrypi.org). Currently, androidfor Raspberry Pi is under development. MOSDEN runs onAndroid 2.3 (and up), and it has 9935 (+ 768 logging linesin debugging version) lines of Java code. It consists of 115class distributed across 14 packages. MOSDEN is based onpopular middleware called Global Sensor Networks (GSN) [1].MOSDEN source code will be available to downloaded freelyin the future. As we mentioned earlier, our goal is not only to

5http://www.gartner.com/newsroom/id/2335616

(a) (b)

Fig. 5: MOSDEN screenshots: (a) List of sensors connectedthe MOSDEN; (b) List of virtual sensors currently running onthe MOSDEN and their details

support mobile phones but also to support devices with similarresources limitations. These devices may or may not havescreens. We decided to develop two different versions of ourmiddleware based on the same underline code-base where oneversion provides fully-fledged user interface to support directuser interaction with the MOSDEN as illustrated in Figure 5.The other version provides a simple user interface that onlyallows to start the middleware6. Figure 6 illustrates the userinterface of the cloud GSN.

6It is important to note that graphical user interface version requires Android4.0 or higher as we have utilized latest user interface components in order toprovide rich experience to the users. Limited user interface version is suitablefor devices such as Raspberry Pi which reduces the additional overhead causedby the user interfaces.

Fig. 6: Screenshot of a cloud GSN instance showing threedifferent MOSDEN instances registration

All the features available in GSN are also available inMOSDEN including data processing and REST-base peer-to-peer communication over HTTP. In comparison to GSN,we changed the wrapper structure and developed a genericwrapper. Further, we introduced the notion of plugins andadded a plugin layer as well as a plugin manager. We alsoreplaced the web-based user interface with an native Androidapplication.

A. Plugin Development

This section explains how third party developers can de-velop plugins in such a way that their plugins are compatiblewith MOSDEN so MOSDEN can use them to communicatewith external sensors. In plugin development, there are threemain components that needs to be considered: (1) Plugininterface written in Android Interface Definition Language(AIDL)7, (2) Plugin class written in Java, and (3) Plugindefinition in AndroidManifest file. Figure 7 shows the plugininterface written in AIDL. IPlugin is an interface defined inAIDL. Plugin developers should not make any changes inthis file. Instead they can use this file to understand howMOSDEN plugin architecture works. IPlugin is similar to theJava interfaces. It defines all the methods that need to beimplemented by all the plugins despite their functionalities.Related to MOSDEN, we defined three methods to supportthe communication between main application and third partyplugins8. Figure 8 present the basic structure of a MOS-DEN plugin. Each plugin is defined as an Android service.MOSDEN plugin developers need to implement these twomethods: getdataStructure() and getReadings(). There is a thirdmethod, void setConfiguration(in Map config), that developerscan use to retrieve data from MOSDEN at runtime, speciallyinformation unknown to them at the development time (e.g.ip address, port number and other information related toconfiguration). This method accepts a Map9 data structure asinput and does not return any output.

In high-level, getdataStructure() returns a data type calledDataField4Plugins[]. This returning data structure describeswhat kind of data items that MOSDEN should expect fromthe plugin. So MOSDEN can prepare its internal data struc-tures as necessary. At the initialization phase, MOSDEN callsthe getdataStructure() method so MOSDEN knows to expect

7http://developer.android.com/guide/components/aidl.html8We expect to add more methods in order to support sophisticate function-

alities and features in the future.9A Java Data structure

package au.csiro.mosden;

import au.csiro.mosden.beans.DataField4Plugins;import au.csiro.mosden.beans.StreamElement4Plugins;

interface IPlugin { DataField4Plugins[] getDataStructure(); StreamElement4Plugins[] getReadings(); void setConfigurationInfo(in Map info);}

Fig. 7: IPlugin written in AIDL (Android Interface DefinitionLanguage) that governs the structure of the Plugins. It definesthe essential items in the plugin.

public class [Class] extends Service implements [Any Interface]{ public int onStartCommand(Intent intent, int flags, int startId) {...} public void onDestroy() {...} public IBinder onBind(Intent intent) {...}

private final IFunction.Stub mulBinder = new IPlugin.Stub(){public DataField4Plugins[] getDataStructure() throws RemoteException {...}

public StreamElement4Plugins[] getReadings() throws RemoteException {…}

public void setConfiguration(Map config) throws RemoteException {} }}

Fig. 8: MOSDEN plugin is an Android service

before real data comes in. Once the initialization is done,MOSDEN calls getReadings() repeatedly depending on thefrequency specified by the cloud GSN. The method getRead-ings() returns a data raw (that comprise data items) that isorganized as specified in the DataField4Plugins[]. The returndata type is StreamElement4Plugins[]. Plugin developers areallowed to perform any operation within this method as longas it produces and returns the data types as specified bythe guidelines10. Figure 9 shows how the plugins need tobe defined in the AndroidManifest so MOSDEN applicationcan automatically queried and identified them. The Androidplugin must have an intent filter and the action name mustbe ‘au.csiro.mosden.intent.action.PICK PLUGIN’. Developerscan provide any category name based on their preferences.

<service android:name=[Plugin name] android:exported="true" > <intent-filter> <action android:name="au.csiro.mosden.intent.action.PICK_PLUGIN"/> <category android:name="au.csiro.mosden.intent.category.[PLUGIN_NAME]"/> </intent-filter></service>

Fig. 9: Code snippet of the plugins AndroidManifest file

In order to support much user friendly and scalable pluginarchitecture, we extended the typical GSN Virtual Sensor Defi-nition (VSD). The essential details that are required to connecta specific sensor to MOSDEN (e.g. IP address, port number)can be passed into the plugin via the VSD as illustrated inFigure 10. These details are important special, in scenarioswhere multiple sensors need to use the same plugin (e.g.connecting 2 sensors that are similar)

<stream name="input1"> <source alias="source1" sampling-rate="1" storage-size="1"> <address wrapper="pluginwrapper"> <predicate key="plugin"> au.csiro.sensmalite.mainapp.intent.category. LIBELIUM_SMART_CITY_SENSOR </predicate> <predicate key="ip-address">130.56.73.110</predicate> <predicate key="port">20143</predicate> </address> <query>SELECT * FROM wrapper</query> </source> <query>SELECT * FROM source1</query></stream>

Fig. 10: Code snippet of a virtual sensors definition10We expect to release a developer guide that explains how third party

plugins can be developed in the future

VI. EVALUATION

In this section, we present the details of the test-beds andevaluation methodology. We also discuss the lessons learntfrom experimental evaluations.

A. Test-beds

We evaluated the proposed middleware solution, MOSDENusing several different parameters such as CPU consumption,scalability, memory requirements, latency and so on. Forthe evaluation, we used three devices with different resourcelimitations. From here onwards we refer them as D1, D2, andD3. The technical specifications of the devices are as follows.

• Device 1 (D1): Google Nexus 4 mobile phone, Qual-comm Snapdragon S4 Pro CPU, 2 GB RAM, 16GBstorage, Android 4.2.2 (Jelly Bean)

• Device 2 (D2): Google Nexus 7 tablet, NVIDIA Tegra3 quad-core processor, 1 GB RAM, 16GB storage,Android 4.2.2 (Jelly Bean)

• Device 3 (D3): Samsung I9000 Galaxy S, 1 GHzCortex-A8 CPU, 512 MB RAM, 16GB storage, An-droid 2.3.6 (Gingerbread)

We used a computer with Intel(R) Core i5-2557M 1.70GHzCPU and 4GB RAM to host the cloud GSN during the eval-uations. For our evaluations, we employed sensors built intothe above devices (e.g. Motion sensors: accelerometer, gravity,gyroscope, liner acceleration, rotation vector; Environmentalsensors: ambient temperature, light, pressure, relative humid-ity; Position sensors: magnetic fields, orientation, proximity.).Further, we used sensors manufactured by Libelium [11] as ex-ternal sensors with different combination of hardware sensorsplugged into them such as temperature sensor, humidity sensor,LDR sensor, air pressure sensor, leaf wetness sensor, noisesensor, dust sensor, force and pressure sensor, flex-bend sensor,flexible stretch sensor, hall-effect sensor, differnt gas sensors(e.g. O2, CO2) and so on. Resource constrained computationaldevices we used in this work as well as some of the sensorsused in this experiments are shown in Figure 11.

B. Methodology

This section explains the evaluation methodology, exper-imental conditions and objectives of the Figures 12a to 13.All the evaluations are done using three different resourceconstrained mobile devices as explained in the section above.In all the evaluations, CPU usage (consumption) is measuredin units of jiffies11. At this point, MOSDEN supports only Wi-Fi communications12. We keep the sampling rate as 1 secondduring the course of evaluations.

In Figure 12a, we examine how CPU usage changes whenthe number of sensors involved increases. Figure 12b showshow memory consumption changes when number of sensorsinvolved increases. Figure 12c measures how energy consump-tion changes when number of sensors involved increases. In

11In computing, a jiffy is the duration of one tick of the system timerinterrupt. It is not an absolute time interval unit, since its duration dependson the clock interrupt frequency of the particular hardware platform.

12We expect to support Zigbee and Bluetooth in the future. However, suchimprovements will not change the overall architecture.

(a)

(b)(c)

(d)

(e)(f)(g)(h)

(j)

(i)

(k)(l)

(m)

(o)(p)

(q)

(r)

(s)

(t)

Fig. 11: Some of the hardware devices used in the experimen-tation: (a) Google Nexus 7 tablet, (b) Google Nexus 4 mobilephone, (c) Samsung I9000 Galaxy S, (d) Smart cities board(with batteries), (e) Smart cities board (without batteries), (f)Smart metering board, (g) Agriculture board, (h) Gas board, (i)Flex bend sensor, (j) Events board, (k) Ultra sound sensor ,(l)Air pressure sensor,(m) Air contaminant sensors, (o) Presencesensor,(p) Humidity sensor,(q) Temperature sensors, (r) Leafwetness sensor, (s) Wi-Fi broad / Antenna, (t) Vibration sensors

Figures 12a, 12b and 12c, MOSDEN only uses inbuilt sensorsto collect data and store them in the local storage space.No network communication is performed. In Figure 12d, weevaluate how CPU usage changes when the number of queriesprocessed by the MOSDEN changes (step 2 and 3 in Figure4). Figure 12e shows how memory consumption changes whenthe number of queries changes. Additionally, Figure 12f showshow energy consumption changes when the number of querieschanges. In Figures 12d, 12e, and 12f, MOSDEN uses inbuiltsensors to collect data and send them to the cloud GSN overa WiFi network.

In Figure 13, we examine the time MOSDEN takes (i.e.latency) to process and transmit the data. We measure the timetaken for the following two operations. (1) We start measuringthe time taken by the plugin to retrieve data from a sensor, passit to a wrapper and subsequently store it in a local database.(2) Time taken for MOSDEN to respond to incoming queryrequest from the cloud GSN.

C. Results

According to Figure 12a, it is evident that CPU usageincreases when the number of sensors increase. It is importantto highlight that, D3 consumes more CPU time comparedto other devices when it needs to handle 10+ sensors. Onereason for this is the lack of main memory (RAM) which

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

5

10

15

20

25

30

35

40

Device 1 (D1)

Device 2 (D2)

Device 3 (D3)

Number of Sensors

CP

U U

seag

e(A

vera

ge u

nits

of

jiffie

s)

(a)

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

5

10

15

20

25

30

35

40

45

Device 1 (D1)

Device 2 (D2)

Device 3 (D3)

Number of Sensors

Mem

ory

Usa

ge (

MB

)

(b)

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

5

10

15

20

25

30

35

40

Device 1 (D1)

Device 2 (D2)

Device 3 (D3)

Number of Sensors

Ene

rgy

Con

sum

ptio

n (J

)

(c)

1 3 5 7 9 11 13 15 17 19 21 23 25 27 290

10

20

30

40

50

60

70

80

90Device 1 (D1)

Device 2 (D2)

Device 3 (D3)

Number of Queries

CP

U U

seag

e(A

vera

ge u

nits

of

jiffie

s)

(d)

1 3 5 7 9 11 13 15 17 19 21 23 25 27 290

100

200

300

400

500

600

700

Device 1 (D1)

Device 2 (D2)

Device 3 (D3)

Number of Queries

Mem

ory

Usa

ge (

MB

)

(e)

1 3 5 7 9 11 13 15 17 19 21 23 25 27 290

10

20

30

40

50

60Device 1 (D1)

Device 2 (D2)

Device 3 (D3)

Number of Queries

Ene

rgy

Con

sum

ptio

n (J

)

(f)

Fig. 12: Experimentation and Evaluation Results. (Note: MOSDEN application and plugins use CPU, memory, and energyindependently where plugins are treated as individual service by Android platform. All the calculations are accumulated valuesof MOSDEN application and plugin services)

puts additional overheads on the CPU. Similar pattern isrevealed in Figure 12b as well as in term of memory usage.Devices that have larger memory capacity can afford to allo-cate more memory to MOSDEN which increases the overallperformance of MODSEN. Further, comparatively resourcerich devices consumes more energy due to usage of powerfulCPUs and sensing hardware. This is observed in the 12cwhere difference in energy consumption for D1 and D3 ismuch higher compared to difference in memory usage. Whennot performing any network communication tasks, MOSDENtakes only 38MB (D1) / 30MB (D3) to collect, process andstore data from 13 different sensors13. MOSDEN consumesaround 35J (D1) / 10J (D3) to process, and store data from13 sensors. It is important to note that, Android manages thememory allocated to application. Depending on the memoryavailability at a given point of time, Android could restrictan application from consuming large amount of memory tofacilitate smooth running of other essential applications andservices. We also note, during this evaluation, only systemprocesses and services, MOSDEN and our power monitorapplication were running on the phone.

Most important fact is that D3 could not handle more than20 parallel queries from the cloud GSN14. This is mainly dueto lack of available memory as compared to other devices.Additionally, D3 is based on Android 2.3.6 (Gingerbread) OSand does not support multi core operations. Further, Android2.3.6 does not provide efficient multi tasking support15. Aswe mentioned earlier related to Figure 12a, Figure 12d alsoreveals that D3 uses significantly more CPU compared toother devices due to the overhead created by lack of memory.

13All the devices do not have all 13 sensors though the Android platformsupports them

14When running more than 20 queries in D3, MOSDEN becomes unstable.Sometimes, D3 was able to handle 20+ queries for a very short period of timebefore it crashed

15http://socialcompare.com/en/comparison/android-versions-comparison

Comparatively, D1 and D2 use less CPU and as observedfrom the results, the CPU consumption is gradually increasingbut not significant when MOSDEN processes more than 10queries. One reason for this is that, Android OS restrictsMOSDEN from consuming too much CPU resource after acertain level as it needs to facilitate other essential Androidapplications and services.

Figure 12e clearly shows that D3 suffers from lack ofmemory as it is not allocated more than 150MB of memory.In contrast, both D1 and D2 have abundant memory availableto be utilized so memory usage increase up to 620MB (D1)/ 580MB (D2). Energy consumption graph with and withoutnetwork communication looks similar in pattern. However,energy consumption has significantly increased across all threedevices (50J (D1) / 40J (D2) when processing 30 queries).When there is no network communication, MOSDEN takes22 seconds to collect data from a sensor plugin, processand store it locally. However, when the cloud GSN startssending queries Android allocates more CPU and memory toMOSDEN. Hence, the data collection/processing and queryprocessing operations are performed much faster which helpsto reduce the overall latency from 22 seconds to 0.2 seconds.

0 1 5 10 20 301

10

100

1000

10000

100000Collect/Process/Send to CloudCollect/Process/Store Locally

Number of Server Requests

Late

ncy

(mili

seco

nds)

[in

Log

arith

mic

]

0.2K 0.32K

22K 8.7K 10K

0.45K

Fig. 13: Data Processing Latency

As the number of query request increases, from the results, weobserve that, latency16 also increases. When MOSDEN pro-cesses 30 queries, latency increases to 10 seconds. However,significant potion of the total processing time is taken to fusethe data and send them to the cloud17.

D. Lessons Learnt and Potential Applications

Lessons Learnt: Our experimental evaluations validatethe energy and performance efficient of our the proposedplugin-based MOSDEN platform. The middleware functionedwithout any issues during our experiments. Additionally, theplugin-based architecture increases the usability of MOSDENby allowing users to download and install plugins fromGoogle market place with zero effort programming and nomodifications to MOSDEN. Further, modern mobile devicescan process significant amount of requests with the limitedresources they have. It is evident that the memory is moreimportant than CPU in situation where data needs to beprocessed under small sampling rates. In our previous work[16], we learnt that reduced sampling rate can save energy andresource consumption significantly. In such scenarios, MOS-DEN will be able to process much more queries efficientlythan it did in the evaluations. We look forward to performmore experiments to examine the impact of sampling rate onMOSDEN’s performance.

Potential Applications: The MOSDEN platform cangreatly fosters the development of new and innovative mobiledata services that depend on IoT devices as the source ofdata. One such example is a crowd-sourcing application wheresensor data (e.g. noise level in outdoor environment) can becollected from users’ mobile device running MOSDEN. Thecollected data can be used by applications in the cloud in theirdecision making process (e.g. determine the noise pollutionlevel at an intersection in the city by fusing data from multipleMOSDEN instances). Another example is to determine real-time traffic conditions using data acquired from MOSDENrunning on user mobile devices.

VII. RELATED WORK

In this section, we review the literature under three cat-egories of research where our proposed solution lies at theintersection: IoT middleware, mobile Sensor middleware, anddata processing in resource constrained devices.

IoT Middleware: Bandyopadhyay et al. [5] have done asurvey on IoT middleware solutions. We discussed the GSNmiddleware in detail before as we selected it to build our so-lution on top of it. Microsoft SensorMap [12] (sensormap.org)is a data sharing and visualization framework. It is also a peerproduced sensor network that consists of sensors deployed bycontributors around the world. SensorMap mashes up sensordata on a map interface. Then, it allows to selectively querysensors and visualize data. SensorMap is designed to runon server computers. Linked Sensor Middleware (LSM) [17](lsm.deri.ie) is a platform that provides wrappers for real timedata collection and publishing. It also provides a web interfacefor sensor search, linked stream data query, data annotation andvisualisation. LSM mainly focuses on linked data publishing.

16Time takes to fulfil all the requests made by the cloud GSN17Time that the data takes to travel over the network is not counted

This platform is also focused on server-based deployment.Cosm (formerly Pachube) (cosm.com) is a platform for Internetof Things devices. Cosm allows different data sources to beconnected to it. Then, it provides functionalities such as eventtriggering and data filtering. Cosm is also a server level middle-ware that is not suitable for resource constraint devices. Thereare several other commercial solutions available: TWINE(supermechanical.com), Ninja Blocks (ninjablocks.com), andSmart Things (smartthings.com). All these solutions focus onevent detection using IF-THEN rules in smart environments.They use their own proprietary software systems installed onsmall resource constrained computational devices. Their ownsensors can communicate with these devices. MoSHub [13] isan mobile application that collects data from both internal andexternal sensors and push them to the cloud IoT middleware.However, it does not provide data processing capabilities. Thismeans all the sensor data collected are uploaded to the cloudthen and there which makes this approach inefficient in termof energy consumption.

Mobile Sensor Middleware: These category of solutionsaim to turn smart phones into mobile sensors so data on userbehaviour and the surrounding environment can be capturedand analysed. Mobile phone based sensing algorithms, ap-proaches, and applications are discussed in [10]. Pogo [6]is a middleware for mobile phone sensing that focuses onbuilding large scale mobile phone sensing test beds. They havedeveloped a server-based counterpart as well as the middelwarefor Android. The objective of pogo is to sense the behaviour ofthe applications. In contrast, MOSDEN focuses on collectingand processing sensor data from both internal and externalsensors. DAM4GSN [16] is also an approach based on GSN.It provides an application that is capable of collecting datafrom internal sensors of a mobile phone and send to the GSNmiddleware. No processing capabilities are provided at themobile phone end. Therefore, all the information sensed aresent to the server. This approach is inefficient due to continuoususage of communication radio of the mobile phone speciallywhen the sampling rate is small (< 1 min) [16].

Data Processing in Resource Constrained Devices: Dy-namix [7] is a plug-and-play context framework for Android.Dynamix automatically discovers, downloads and installs theplug-ins needed for a given context sensing task. Dynamix isa stand alone application and it tries to understand new envi-ronments by using pluggable context discovery and reasoningmechanisms. It does not provide server-level solution. Contextdiscovery is the main functionality in Dynamix. In contrast, oursolution is focused on allowing easy way to connect sensors toapplications in order to support sensing as a service model inIoT domain. We employee a pluggable architecture which issimilar to the approach used in Dynamix, in order to increasethe scalability and rapid extension development by 3rd partydevelopers. One of the most popular type of processing inmobile is activity recognition. Yan et al. [21] have presentedan energy-efficient continuous activity recognition on mobilephones. One of the most important data processing task thatneed to be performed at the lower level devices (e.g. categories2,3,4 in Figure 1) in IoT is validation, fusing, filtering, contextdiscovery, and annotation [14]. Data collected by lower leveldevices needs to be validated in order to reduce the wastageof network communication [19]. Further, data fusing and fil-tering operations prevent redundant network communications.

Some of the context information such as location need to bediscovered at the lowest layers [18] which makes it impossibleto perform such operation at higher levels.

VIII. CONCLUSION AND FUTURE WORK

The number of mobile devices connected to the Internet isgrowing at a rapid space. Significant portion of these devicesare mobile phones today. However, it is expected that billionsof different types of resource constrained computational devicewill be connected to the Internet over the coming decade. Onthe other hand, number of sensors deployed around us aregetting increased. It is an increasingly important task to collectdata from these sensors in order to analyse and act upon them.

In this paper, we presented an Internet of Things middle-ware for resource constrained computational mobile devicescalled MOSDEN. Our proposed middleware also supportssensing as a service model. MOSDEN provides an easy andconvenient way to connect sensors to the mobile device withzero programming effort. We introduced a scalable pluginarchitecture where plugins are distributed through leadingmobile application stores such as Google Play. MOSDEN iscapable of collecting data from multiple different sensors andprocess them together. MOSDEN is 100% compatible withGlobal Sensor Network Middleware that runs on the cloud.Further, MOSDEN can act as a peer to peer data processingengine as well. We evaluated MOSDEN in different aspectssuch as resource consumption, scalability, and usability. Wehave demonstrated the feasibility and scalability towards usingMOSDEN on resource constrained devices to collect andprocess sensors data. We also demonstrated that significantamount of resources can be saved by processing the datalocally instead of transmitting all data to the remote server.It is evident that such processing allows to run the IoTinfrastructure for longer time period.

We will release the source code of MOSDEN platformto the public in future. In the future, we would like to addautomated sensor discovery and configuration functionalitiesto the MOSDEN where it will be able to search and discoverany kind of sensors around a given location and automaticallyinstall the required plugins. This will allows MOSDEN tocommunicate and configure the sensors autonomously. Further,we will develop a configuration model that can be used toconfigure different devices (belongs to different categories)in the IoT architecture presented in Figure 1. Configurationdetails and sensing strategies such as scheduling, samplingrate, data acquisition method, and protocols will be designedfor each individual sensor by the higher-level devices and willbe pushed towards the lower layers. Further, we will investigatethe impact of employing different data processing techniquesand sampling rates in order to find-out their the suitabilitytowards resource constraint devices considering the factorssuch as energy consumption and network communication.

Acknowledgements: Authors acknowledge support fromOpenIoT Project, which is co-funded by the European Com-mission under seventh framework program FP7-ICT-2011-7-287305-OpenIoT.

REFERENCES

[1] K. Aberer, M. Hauswirth, and A. Salehi. Infrastructure for data pro-cessing in large-scale interconnected sensor networks. In InternationalConference on Mobile Data Management, pages 198–205, May 2007.

[2] S. K. Arkady Zaslavsky, Prem Prakash Jayaraman. Sharelikescrowd:Mobile analytics for participatory sensing and crowd-sourcing applica-tions. In IEEE International Conference on Data Engineering, 2013.

[3] A. Asin and D. Gascon. 50 sensor applications for a smarter world.Technical report, Libelium Comunicaciones Distribuidas, 2012. http://www.libelium.com/top 50 iot sensor applications ranking/pdf [Ac-cessed on: 2012-05-02].

[4] L. Atzori, A. Iera, and G. Morabito. The internet of things: A survey.Comput. Netw., 54(15):2787–2805, Oct. 2010.

[5] S. Bandyopadhyay, M. Sengupta, S. Maiti, and S. Dutta. Role ofmiddleware for internet of things: A study. International Journal ofComputer Science and Engineering Survey, 2:94–105, 2011.

[6] N. Brouwers and K. Langendoen. Pogo, a middleware for mobilephone sensing. In Proceedings of the 13th International MiddlewareConference, Middleware ’12, pages 21–40, New York, NY, USA, 2012.Springer-Verlag New York, Inc.

[7] D. Carlson and A. Schrader. Dynamix: An open plug-and-play contextframework for android. In Internet of Things (IOT), 2012 3rd Interna-tional Conference on the, pages 151–158, 2012.

[8] Cosm. Cosm platform, 2007. https://cosm.com/ [Accessed on: 2012-08-05].

[9] D. Kharrat and S. Quadri. Self-registering plug-ins: an architecture forextensible software. In Electrical and Computer Engineering, 2005.Canadian Conference on, pages 1324–1327, 2005.

[10] N. Lane, E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, and A. Camp-bell. A survey of mobile phone sensing. Communications Magazine,IEEE, 48(9):140 –150, sept. 2010.

[11] Libelium Comunicaciones Distribuidas. libelium, 2006. http://www.libelium.com/ [Accessed on: 2012-011-28].

[12] S. Nath, J. Liu, and F. Zhao. Sensormap for wide-area sensor webs.Computer, 40(7):90–93, July 2007.

[13] C. Perera, P. Jayaraman, A. Zaslavsky, P. Christen, and D. Georgakopou-los. Dynamic configuration of sensors using mobile sensor hub ininternet of things paradigm. In IEEE 8th International Conferenceon Intelligent Sensors, Sensor Networks, and Information Processing(ISSNIP), pages 473–478, Melbourne, Australia, April 2013.

[14] C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos. Contextaware computing for the internet of things: A survey. CommunicationsSurveys Tutorials, IEEE, xx:x–x, 2013.

[15] C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos. Sensingas a service model for smart cities supported by internet of things.Transactions on Emerging Telecommunications Technologies (ETT),pages n/a–n/a, 2014.

[16] C. Perera, A. Zaslavsky, P. Christen, A. Salehi, and D. Georgakopoulos.Capturing sensor data from mobile phones using global sensor networkmiddleware. In IEEE 23rd International Symposium on Personal Indoorand Mobile Radio Communications (PIMRC), pages 24–29, Sydney,Australia, September 2012.

[17] D. L. Phuoc, H. N. M. Quoc, J. X. Parreira, and M. Hauswirth. Thelinked sensor middleware - connecting the real world and the semanticweb. In International Semantic Web Conference (ISWC), October 2011.

[18] K. Schreiner. Where we at? mobile phones bring gps to the masses.Computer Graphics and Applications, IEEE, 27(3):6–11, 2007.

[19] Z. Shen and Q. Wang. Data validation and confidence of self-validatingmultifunctional sensor. In Sensors, 2012 IEEE, pages 1–4, 2012.

[20] H. Sundmaeker, P. Guillemin, P. Friess, and S. Woelffle. Visionand challenges for realising the internet of things. Technical re-port, European Commission Information Society and Media, March2010. http://www.internet-of-things-research.eu/pdf/IoT ClusterbookMarch 2010.pdf [Accessed on: 2011-10-10].

[21] Z. Yan, V. Subbaraju, D. Chakraborty, A. Misra, and K. Aberer.Energy-efficient continuous activity recognition on mobile phones: Anactivity-adaptive approach. In Wearable Computers (ISWC), 2012 16thInternational Symposium on, pages 17–24, 2012.

[22] A. Zaslavsky, C. Perera, and D. Georgakopoulos. Sensing as a serviceand big data. In International Conference on Advances in CloudComputing (ACC-2012), pages 21–29, Bangalore, India, July 2012.