Future Generation Computer Systems 56 (2016) 623–639

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

Mobile crowdsensing as a service: A platform for applications on top

of sensing Clouds
Giovanni Merlino a,b , Stamatis Arkoulis c , Salvatore Distefano d,e,∗ , Chrysa Papagianni c ,
Antonio Puliafito a , Symeon Papavassiliou c
a
Dip. di Ingegneria (DICIEAMA), Università di Messina, Italy
b
Dip. di Ingegneria (DIEEI), Università di Catania, Italy
c
School of Electrical and Computer Engineering, National Technical University of Athens, Greece
d
Social and Urban Computing Group, Higher Institute of Information Technology and Information Systems (ITIS), Kazan Federal University, Russia
e
Dip. di Elettronica, Informazione e Bioingegneria (DEIB), Politecnico di Milano, Italy

highlights
• Emulation of deployment comparing (i) prototype of MCSaaS and (ii) current practices.
• Modeling of MCSaaS paradigm by Petri nets and evaluation against conventional MCS.
• Description of architectural elements of the platform and their interactions.
• MCSaaS platform for mass deployment of MCS apps, and their elastic user base adaptation.
• Mobile crowdsensing as a service paradigm for MCS apps design and deployment.

article info abstract

Article history: Consumer-centric mobile devices, such as smartphones, are an emerging category of devices at the edge
Received 22 November 2014 of the Internet. Leveraging volunteers and their mobiles as a (sensing) data collection outlet is known as
Received in revised form Mobile Crowd Sensing (MCS) and poses interesting challenges, with particular regard to the management
11 September 2015
of sensing resource contributors, dealing with their subscription, random and unpredictable join and
Accepted 12 September 2015
Available online 9 October 2015
leave, and node churn.
To facilitate and expedite the (commercial) exploitation of this trend, in this paper we propose to adopt
Keywords:
a service-oriented approach to cope with MCS application deployment into a sensing Cloud infrastructure,
Cloud decoupling the MCS application domain from the infrastructure one. To this purpose we provide the
IoT building blocks for implementing such a novel take on MCS, which from a Cloud layering perspective can
Infrastructure as a Service be identified as a platform service, i.e., an MCS as a service (MCSaaS). A prototype implementation that
Volunteer contribution serves as a blueprint and a proof-of-concept of the proposed framework is presented, while an evaluation
Sensors and actuators of the effectiveness of the MCSaaS paradigm has been provided using suitable mobility-related use cases
Runtime customization for a validation of the concept, as well as a modeling approach through the adoption of generalized
stochastic Petri nets.
© 2015 Elsevier B.V. All rights reserved.

and participatory sensing paradigms, such as Mobile Crowd Sens-

1. Introduction and motivations ing (MCS). MCS leverages the pervasiveness of smartphones and
other portable devices, enabling users and community groups to
Current trends, with specific regard to cyber physical systems collectively share data from onboard sensing resources so as to
and Internet of Things (IoT), suggest that one of the most interest- measure phenomena of common interest, exploiting social dynam-
ing thrusts towards pervasive services comes from opportunistic
ics. The contributor has also the possibility to augment raw data
with context as metadata. This community-driven sensing trend
is brought about by machine interactions at different levels, in-
∗ Corresponding author at: Dip. di Elettronica, Informazione e Bioingegneria cluding data communications, collection, processing and mining.
(DEIB), Politecnico di Milano, Italy. Commencing crowd-sourcing and sensing duties from mobiles,
E-mail addresses: gmerlino@unime.it, giovanni.merlino@dieei.unict.it
(G. Merlino), stark@cn.ntua.gr (S. Arkoulis), s_distefano@it.kfu.ru,
involving device owners as volunteering participants, potentially
salvatore.distefano@polimi.it (S. Distefano), chrisap@noc.ntua.gr (C. Papagianni), renders end users both contributors and consumers of large vol-
apuliafito@unime.it (A. Puliafito), papavass@mail.ntua.gr (S. Papavassiliou). umes of (curated) data.
http://dx.doi.org/10.1016/j.future.2015.09.017
0167-739X/© 2015 Elsevier B.V. All rights reserved.
624 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

However, there are several key issues that need to be addressed For delivering this novel MCS approach, the Sensing and Actu-
for the MCS paradigm to experience widespread adoption [1,2]. ation as a Service (SAaaS) framework, proposed in [6], is adopted
Firstly, a unified architecture for supporting MCS applications is as the lower-level (infrastructure domain) enabler. SAaaS is based
required to enable reusability of software components, facilitating on the service-oriented (and Cloud-inspired) approach of elasti-
shorter time to market cycles. Existing MCS applications are built cally providing (virtual) sensing and actuation resources on de-
as stand-alone ones, while common challenges, e.g., related to mand, gathered from underlying (contributed) physical nodes. The
resource engagement, get independently revisited each time, or study at hand extends and adapts the SAaaS paradigm for enabling
are not addressed at all. The heterogeneity of mobile Operating rapid MCS app deployment and streamlining their operation, actu-
Systems (OS) and sensor hardware further amplifies the problem. ally providing an MCS as a Service (MCSaaS) platform.
As a result sensing and processing activities usually result in There are a number of advantages in dealing with MCS from
carrying out similar tasks (i) within a single device (contributing the (SA)aaS angle. Virtualizing and customizing sensing resources,
node) for different MCS applications, resulting in energy starvation starting from the capabilities provided by the SAaaS model,
and (ii) across multiple, neighboring devices, leading to spikes in allows for concurrent exploitation of pools of devices by several
bandwidth usage and processing requirements at the back end. platform/application providers. Delivering MCSaaS may further
Both cases highlight a non-scalable deployment model. simplify the provisioning of sensing and processing activities
Furthermore, MCS applications rely on every single contributor within a device or across a pool of devices. Moreover, decoupling
for local deployment duties. While most MCS apps require a the MCS application from the infrastructure promotes the roles
critical mass of contributors to be deemed useful, app adoption is of a sensing infrastructure provider that enrolls and manages
bounded by the rate at which users keep track of, and install, newly contributing node(s), below, and of a platform provider on top of
introduced ones. A substantially low rate as, according to recent that, acting as a broker between (i) the former and (ii) the MCS
reports, e.g., in 2014 nearly 80% of the 1.2 million apps available at application provider, enabling the latter to focus on the application
the Apple App Store had hardly any downloads at all.1 Providing and leave concerns and enforcement about requirements (type of
resources on a volunteer basis is one of the foremost limitations resources, availability, etc.) to the platform.
to the large scale exploitation of the MCS paradigm, as it naturally In this paper we provide a high level overview of the
bears constraints related to contribution churn. In terms of MCS proposed MCSaaS approach complemented by a description of the
applications this sets the need for ‘‘marketing’’ strategies aimed at distinct architectural elements and their interactions. Moreover
increasing the number of subscriptions, stimulating, retaining and we highlight the benefits of the proposed framework as opposed
rewarding potential contributors through incentives. However, to the conventional MCS approach, by means of (i) a prototype
even if the enrollment activities (or even mechanisms, such as implementation of the MCSaaS framework under the guise of the
credit-reward systems) may be highly effective, the subscription MobiCSOS stack and the emulation of a real-world application
process is usually characterized by long and smooth dynamics. deployment; and by (ii) modeling with generalized stochastic Petri
Therefore a significant time delay may be experienced before nets (GSPN) [7].
getting a significant stream of sensing data. This issue may strongly The main contributions of this work can be therefore identified
confine the scope of the MCS paradigm to a shortlist of applications in:
featuring broad, long-established supporting communities of
• a novel (Cloud-based) service-oriented paradigm for MCS, i.e.,
potential contributors.
MCSaaS;
From a different perspective, another significant trend moves
IoT towards service-oriented and Cloud computing paradigms
• a reference architecture for the MCSaaS stack;
[3–5]. In this view, the Cloud is not just a technology to support the
• a prototype MCSaaS implementation, i.e., MobiCSOS, develop-
ing basic mechanisms, such as churn management, that serves
archiving of sensed data coming from pervasive IoT infrastructure,
as a proof of concept for the proposed approach;
but also a model and a paradigm to adopt in the management of
the underlying resources and things.
• a preliminary evaluation of the MCSaaS potential on Android
mobiles, based on simple real-world scenario and a larger-scale
Following this IoT-Cloud research trajectory, in this paper, a
analytical model.
novel platform for opportunistic (mass) exploitation of contributed
resources for MCS apps is presented to get more insights as to The remainder of the paper is organized as follows. Section 2
whether the MCS paradigm may indeed be applied at large-scale provides an overview of related work. Section 3 focuses on the
in the IoT context. The proposed approach overcomes several of overall MCS scenario, characterizing and motivating the MCSaaS
the aforementioned hurdles, by facilitating what is essentially the approach we propose, while Section 4 presents the infrastructure
most difficult endeavor for prospective MCS entrepreneurs, i.e., of- elements. Section 5 deals with the main features of the MCSaaS
fering a level playground, with homogeneous access to wildly dif- platform, Section 6 addresses the problem of application setup and
ferent underlying ecosystems. To this end, we identify two classes deployment, while Section 7 focuses on the implementation details
of concerns with regard to (unassisted) dissemination of MCS apps; of MobiCSOS. The MCSaaS-assisted deployment of MCS apps, with
(i) infrastructure-related, mostly focused on mechanisms to enroll regards to urban mobility use cases, are discussed in Section 8, with
and manage voluntarily contributing nodes, as well as to abstract some numerical evaluation based both on an emulated scenario
sensing resources and enable uniform access, and (ii) application- and on a GSPN model, while conclusions are drawn in Section 9.
related, mainly devoted to mechanisms for interfacing with en-
abled infrastructure, asking for the required sensing resources and, 2. Preliminary concepts and related work
once obtained, deploying the MCS app onto the resource-hosting
nodes. This way we are able to decouple infrastructure resources
2.1. Mobile crowd-sensing
(supply) from application requirements (demand) as in Cloud con-
texts, making development, deployment and operation fully inde-
pendent. MCS [1] is an emerging trend, lying at the intersection of vol-
unteer and crowd-based computing, IoT, and sensing paradigms. It
refers to a broad range of community-powered sensing approaches
belonging to either participatory [8] and/or opportunistic [9] cate-
1 https://www.adjust.com/assets/downloads/AppleAppStore_Report2014.pdf. gories, aiming at involving large population of contributors [2,10].
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 625

on the other, are investigating potential exploitations of the MCS

approach both in scientific applications and in commercial ones.
Therefore, the current state of affairs highlights the need for
suitable methodologies and techniques able to bring order in the
MCS field, adopting engineering practices and tools to explore the
untapped potential of the paradigm.
With specific regard to the issues raised in the previous section,
several frameworks have been proposed to support expedite MCS
application development and deployment. AnonySense [23] is
a privacy-aware framework for opportunistic and participatory
sensing. Applications specify the sensing task behavior using a
Domain Specific Language (AnonyTL) and then submit it to the
AnonySense components and mobile nodes. A polling model is
used for task distribution. Downloaded tasks are matched to the
nodes based on their context.
Medusa [24] is a programming framework that specifies the
workflow of sensing tasks to be executed in smartphones and onto
the Cloud. It defines the Med-Script programming language that
provides high-level abstractions for the various stages in crowd-
sensing tasks as well as for flow control. Moreover it provides a
distributed runtime between the Cloud and smartphones.
Pogo [25] proposes a middleware for building large scale sens-
ing testbeds using mobile phones. Both researchers and device
owners, each category running the middleware differently, de-
pending on their role. Pogo relies on the XMPP protocol for com-
Fig. 1. MCS application scenario. munication between nodes. Experiments are written in JavaScript.
Vita [26] supports the development, deployment and manage-
Participatory sensing is characterized by individuals that are ac- ment of multiple MCS applications/tasks. It consists of both a mo-
tively involved in contributing to a given application by mean of bile and a Cloud platform. The former provides the appropriate
devices or (meta-)data (e.g., taking a picture), while opportunis- services (e.g., map and location) that enable the execution of sens-
tic sensing is more autonomous and user involvement is minimal ing tasks. It optimizes the allocation of a task to a group of users or
(e.g., continuous sampling of geo-localized data). Cloud servers by using Genetic Algorithms and K-means clustering.
A broad range of applications, from mining of urban dynam- The Cloud platform streamlines the development and deployment
ics [11], to public safety [12], traffic and environment monitor- of MCS applications, integrates and stores uploaded sensing data,
ing [13,14], smart lighting [15] and smart cities [16], just to name as well as metrics related to system operation.
a few, may be implemented adopting the MCS paradigm. Existing PRISM [27] is also a platform for community-sensing ap-
MCS applications are comprised of two main components [1]: plications that allows the deployment of binaries ready for
execution onto mobiles. Method call interposition is used to
(i) device-specific ones, for data collection, execution of local sandbox-untrusted applications to ensure security and privacy.
analytics if needed, and data dissemination, PRISM follows a push-based model for the automatic deployment
(ii) the backend, for extensive data analysis, storage and visualiza- of applications to an appropriate set of phones. Efficient tracking
tion duties. of mobiles is implemented mitigating privacy risks and reducing
A simple and generic MCS application scenario is shown in communication overhead.
Fig. 1, where the main elements and stakeholders involved in Most of the aforementioned frameworks propose custom
the MCS system are identified based on [1]. These include the languages for hardware and OS abstraction of the contributing
contributing nodes, e.g., smartphones, tablets and, PDAs, shared by devices or specify ad-hoc sandboxed environments for secure
execution of applications. Although convenient, the fact that only
their Owners or Contributors to build up the sensing infrastructure
pre-programmed functions and software modules are provided to
environment, as well as the Application Service Provider (MCS ASP),
developers results in a less flexible and not as powerful application
that manages and supervises the whole process, gathering and
development environment. In fact, only PRISM [27] allows for
processing sensed data through the application server, which also
native MCS applications deployment (although sensors can only be
interfaces with the End User of the MCS application.
accessed through a sandbox), while also providing a mechanism
for selection of contributing devices. By not spinning a service-
2.2. Related work oriented model for (sensing) infrastructure out from the platform
that is meant to exploit it, sandboxing and access to hardware
Although MCS is a quite new and emerging topic, several resources need to be crafted explicitly for the platform itself,
works deal with related issues. Earliest works on the topic present instead of delegating such duties to an IaaS-level framework.
and characterize the approach in terms of opportunistic [9], With regard to the deployment of sensing applications and
participatory [8], social and crowd sensing [17] paradigms. All such tasks, the above frameworks allow for rapid installation and ex-
concepts have been then grouped under the MCS umbrella [1]. ecution on all contributing devices indiscriminately. Additionally,
So far, several MCS applications [18,19,13,20] have been Medusa provides specific rewards and incentives to stimulate user
developed in different contexts, demonstrating the MCS paradigm participation while it allows smartphone owners to specify limits
is useful in applications directly and indirectly involving different on usage of system components. However, most of these frame-
stakeholders and huge populations of users. This has drawn the works do not provide any advanced mechanisms for targeted se-
attention of both the academic and business communities, which, lection of contributing devices, despite that such a process could
on one hand, started developing new middlewares implementing significantly increase efficiency in the exploitation of available re-
mechanisms and tools for MCS system management [21,22] while, sources, as well as minimize impact on existing MCS-dependent
626 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

Fig. 2. MCSaaS scenario.

services running on the same devices. This is a consequence of the This strongly impacts on the MCS paradigm, significantly
lack of infrastructure ready to be exploited in a controlled way for changing the scenario by introducing new stakeholders, and
MCS, as resources are still to be enrolled with ad-hoc mechanisms enabling further avenues for exploitation, not only in terms
as provided by the aforementioned platforms. of research but also from a business perspective, such as an
In closing, it is notable that none of the above frameworks open market of MCS(aaS) sensing resources and services. More
tackles support to contribution churn as a platform-provided specifically, as can be seen in Fig. 2, different application service
feature, as a way to enable on-demand expansion or shrinkage of providers (MCS ASPs) may leverage the facilities an MCSaaS plat-
the user base of MCS apps, according to the needs of application form provider has on offer, including traditional enterprise-level
developers and providers. infrastructure providers such as the incumbent players for both
processing and storage resources, i.e., Infrastructure as a Service
(IaaS) and Data as a Service (DaaS), respectively. Under the sensing
3. The MCSaaS paradigm
Cloud a few kinds of infrastructure contributors are depicted: as
we are talking about SAaaS here, the owners/admins are contrib-
3.1. The MCSaaS vision utors sharing resources under their control, such as mobiles, PDAs
or even Wireless Sensor Networks (WSNs).
The MCSaaS framework attempts to address the basic limi- The differences between the ‘‘traditional’’ MCS scenario and
tations of existing MCS applications, such as explicit and time- the proposed MCSaaS one are clear by comparing Figs. 1 and 2,
consuming developer efforts in the engagement of resources, while and have been summarized in Table 1, where the main MCSaaS
instead supporting contributor recruitment by MCS ASPs. Specif- actors with their duties, as well as the pros and cons of their roles,
ically, in MCSaaS these issues are addressed by making infras- are described. More specifically, within the ‘‘plain’’ MCS domain
tructure available on demand. This way, MCS application/service (Fig. 1), a potential contributor directly interacts with an MCS
providers can immediately deploy and run their applications and ASP to be engaged in an MCS activity. According to the MCSaaS
services on promptly available resources, ready to use once con- scenario in Fig. 2, contributors are node owners/administrators
figured or customized for deploying the MCS application. Another that are sharing resources under their control via registration to a
important benefit of this approach lies in having real-time require- sensing Infrastructure Provider (SaaS), possibly retained by means
ments fulfilled mostly for free, by design due to the paradigm shift, of suitable incentives. The contribution is therefore managed at a
since QoS requirements can be satisfied by providing a certain lower level, thus lending a degree of freedom to resource sharing
guaranteed number of devices in face of loss. (multiple MCS app contributions, contribution profiles, credits,
From a high level point of view, this approach can be imple- money, etc.) but this requires to delegate resource control to
mented by functionally and administratively splitting the MCS the infrastructure provider. The MCSaaS scenario is thus enriched
application/service deployment into two domains: (i) the infras- by new stakeholders, such as the Infrastructure Providers (InP)
tructure domain, which includes (embedded) sensing devices, and the MCSaaS Provider (MCSaaS-P) in between the MCS ASP
providing services for resource management (brokering, inter- and the Contributors. This brings about several benefits and is
operability, etc.) and facilities for customizing and deploying advantageous in particular for MCS ASPs, who can rapidly develop
the MCS application; and (ii) the application domain, hosting and deploy their apps onto MCSaaS-enabled infrastructure.
the frontend and backend (analytics) services for the (filtered A service-oriented provisioning model is the best way for the
and pre-processed) data provided by the infrastructure modules, MCSaaS-P to provide the required resources to MCS ASP, enabling
exploiting infrastructure/low level application deployment and customization facilities while ensuring the required service levels
data/node management facilities to implement the MCS application for provisioning. The MCSaaS-P can provide support to single or
or service. multiple MCS applications/services to be delivered transparently
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 627

Table 1
Actors involved in the MCSaaS scenario.
Actor Description
Pros Cons

Volunteering contributor of sensing resources, stimulated by appropriate incentives.

– Possibility to earn credits, rewards. – The node contribution is initially managed by a
third party broker (delegation cons).
Contributor
– Free or remunerated.
– Multiple MCS application contributions through a single subscription (delegation pros).
– Possibility to be both user and contributor.
– Privacy and security due to two layers of isolation.

A sensing infrastructure provider enrolls and manages contributors according to specific service level agreement.
InP
- Enlarge the business customer portfolio (due to mashups). - Third party brokering and monitoring.

The MCSaaS-P provides resources mashup and brokerage services to MCS ASPs, along with customization service for the engaged resources and MCS
application deployment service.
– New business opportunities. – Resource management.
MCSaaS-P – Increased resource utilization and throughput. – Duties on security, privacy and SLA to both sides.
– To reach a wide audience.
– Big data-analytics.
– Involving sensor networks.
– Actuation.

Application provider that delivers a single or multiple MCS applications/services to MCS End Users. The MCSaaS ASP deploys the MCS application(s)
utilizing the MCSaaS framework.
– Wider application domains involving mobile and/or static (SN) sensors and actuators. – May be charged.
– No problems of enrollment and management of sensing resources.
– QoS-guaranteed resource provisioning.
– Real-time applications suitability.
MCS ASP – Increased application reliability, availability and performance.
– Capillarity, worldwide coverage, # of contributors.
– Heterogeneous resources (computing, storage, sensing) provided.
– Facilities for the application deployment (configuration, customization, setup, analytics
tools).
– Customizability of resources (pre-processing, filtering, client-side functionalities, reduced
overhead, bandwidth-local processing trade-off).
– Abstracted/homogeneous access (APIs) where resources are what is customized to meet
the needed abstraction (SAaaS-unique).
– Resources handling capabilities due to the device/resource-centric approach vs the
data-centric one, enabling enhanced features and new applications.
– New applications involving actuation resources.

The consumer of the MCS services provided by the MCS ASP.

MCS EU – High performance, low delays. - May be charged.
– The role of an MCS EU may naturally coincide with the role of Contributor.

to MCS End Users (EU), as in the traditional MCS scenario. In order we adopt a multi-tiered approach as depicted in Fig. 3, where
for the MCSaaS-P to provide the requested sensing resources to a layered scheme comprising the node and the infrastructure
the MCS ASP, the two parties have to negotiate the set of required Clouds below the platform (PaaS) and the application-Software as
resources and then, upon agreement, the ASP deploys the MCS app a Service (SaaS) on top, is proposed.
to the corresponding set of registered contributing nodes provided At a lower level of the MCSaaS stack we have contributors
by the InP through the MCSaaS platform. Details on this process are sharing their nodes with infrastructure providers that enroll
reported in Section 6. them to provide (virtual) sensing and actuation resources as a
service (SAaaS). Optionally also computing (IaaS) and storage
3.2. The MCSaaS stack (DaaS) providers could be included at this level. On top of the
basic infrastructure mechanisms, services mainly related to the
The main idea we propose in this work is therefore to specific configuration, customization, and management of virtual
adopt a Cloud and service-oriented approach for the on-demand resources for MCS applications are provided by the MCSaaS Cloud
provisioning of MCS resources and services. This way, the SAaaS platform. Facilities to expose resources provided by different
sensing Cloud becomes a pillar of the MCSaaS infrastructure. categories (i.e., IaaS, DaaS, SAaaS) of infrastructure providers may
Furthermore, a higher platform-like layer to provide services for be implemented by the MCSaaS platform. At a higher level, an MCS
the resource management (mashup, brokering, interoperation, application employs such infrastructure and platform facilities to
etc.) as well as for deploying and customizing the app on top of eventually enable and provide SaaS services. However, an MCS
such infrastructure is mandatory. Sensing and actuation resources ASP may just deploy an application, collecting and/or displaying
are involved in the Cloud not as simple endpoints, as in current data, without necessarily building up a Web service out of it,
mobile Cloud trends, but rather in the same way as computing, or otherwise becoming an (MCS-powered) Software as a Service
storage, and network resources usually are in more traditional provider.
Cloud stacks: abstracted, virtualized and grouped in Clouds, to
unlock new value-added services by mixing the potential of the 4. The Infrastructure
Cloud with that of the IoT.
Our goal is therefore to provide a conceptual framework, and As seen in the previous section, the MCSaaS scenario may
correspondingly a software stack, able to deal with such issues, involve third parties to provide IaaS/DaaS resources where needed
while aiming at the MCSaaS vision as the whole. To this purpose, for developers of MCS applications, but here we focus on the
628 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

Fig. 3. MCSaaS stack.

main building block of any kind of MCS-centered facility: (mobile)

sensing infrastructure, under the guise of service-oriented Cloud-
enabled resources, a so-called Sensing and Actuation as a Service
(SAaaS).
SAaaS is a paradigm aimed at developing a sensing infrastruc-
ture based on sensors and actuators from both mobile devices and
SNs, providing virtual sensing and actuation resources in a Cloud-
like fashion. More specifically, it delivers the basic mechanisms and
tools for enabling a Cloud of sensors and actuators, which have to
be suitably extended and customized by providers to implement
enhanced services and provisioning models. To this end, the main
issues to be addressed include: abstraction of sensing and actua-
tion resources, virtualization, customization, monitoring, SLA and
QoS management, subscription, churn and policy management, en-
rollment, indexing and discovery, security and fault tolerance.
This fosters the design of a software stack that implements
the following main functionalities: (i) involvement of SNs, smart-
phones or other devices endowed with sensors and/or actuators, Fig. 4. SAaaS reference architecture: modules.
and their enablement for interoperation in a Cloud environment;
(ii) distributed mechanisms and tools for self-management, config- if multiplexed and/or virtualized, it allows for customization and
uration and adaptation of nodes; (iii) functions and interfaces for configuration capabilities typically unexposed higher up to MCS
enabling and managing contributing resources. ASPs, that may in turn explore previously neglected application
To implement such ambitious idea, i.e., a Cloud of sensors based domains.
on the SAaaS paradigm, in [6] we introduced the whole stack and The lowest block, the Hypervisor, operates at the level of a sin-
a high-level blueprint of the architectural modules, the three main gle node, where it abstracts the available sensors. The node can be a
components of which are shown in Fig. 4, bottom-up: Hypervisor, standalone resource-rich device, such as a smartphone, or it can be
Autonomic Enforcer and VolunteerCloud Manager. an embedded system which belongs to a network (such as a WSN).
The SAaaS stack and modules span to the two lower layers of The main duties of the Hypervisor are: communications and net-
Fig. 3: from the Cloud Infrastructure one, providing support to the working virtualization primitives, abstract description of devices
MCSaaS PaaS and MCS SaaS software applications and services, to and capabilities according to the relevant information model, vir-
the node layer, covering edge devices. Through the SAaaS stack, any tualization of sensing resources, customization, isolation, semantic
device, either mobile or static, may be engaged in crowdsensing labeling.
activities, as well as any sensor network, regardless of the software The Cloud modules, under the guise of an Autonomic Enforcer
environment and operating system. This way, the term SAaaS and a VolunteerCloud Manager, deal with issues related to the
node is used in the following to indicate a smart device equipped interaction among nodes. The former is responsible of the node-
with sensors, such as a smartphone, or a frontend to a possibly internal enforcement of Cloud policies, local vs. global policy
large number of smaller sensing devices (i.e., motes), such as the tie-breaking, cooperation on overlay instantiation, enrollment
gateway of an SN. initiation and subscription(s) bookkeeping. Whenever suitable it
Furthermore, since the SAaaS implements a device-centric operates according to autonomic principles. The latter is instead
approach, providing actual sensing and actuation resources, even in charge of the following functionalities: exposing the Cloud of
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 629

sensors via Web Service interfaces, indexing of subscribers and

contributed resources, monitoring of Service Level Agreements
(SLAs) and Quality of Service (QoS) metrics. These layers thus form
a coupled, two-level Cloud stack, where many mechanisms are
split in both modules, dealing with node-wise actions and self-
organizing properties in the lower one, and centrally managed
Cloud-wise methods in the upper one.
Indeed, taking as an example device enrollment, the lower
Cloud module is in charge of node-side initiation of the enrollment
process, including one-time interaction with the contributor, Fig. 5. MCSaaS module.
e.g., for excluding or limiting access to certain device-hosted
resources, by pushing the description of enumerated resources to objects. This is initially managed by the Orchestrator, which
the Cloud, as well as of bookkeeping of any Cloud instance the node identifies the resources required by the MCS application extracting
has successfully subscribed to. The centralized module is instead requirements and dependencies from the request encoding the
in charge of Cloud-side acceptance or rejection of the enrollment high level workflow of the application. This kind of service may
request as well as indexing of resources (and the corresponding conform to available standards, e.g., TOSCA [30], in terms of
nodes) to provide querying capabilities to the end user of the Cloud. exposed functionalities and relevant APIs. It therefore iteratively
At this level, having communication among the Cloud modules interacts with the Cloud Broker to reserve resources according to
layered on top of ubiquitously available protocols and services for the aforementioned requirements provided by the MCS ASP, the
IoT and M2M such as WebSockets [28] means getting access to lots Broker in turn planning in advance the engagement of sensing
of available gadgets and personal devices that would otherwise devices as needed through SAaaS InPs. Following a successful
go untapped, unless major revisions in terms of their firmware, negotiation and the allocation of required resources to the MCS
and communication stacks in particular, get planned. This choice application the application setup phase is launched by both
directly reverberates on the widening possibilities a MCS app the Customization Service and the Deployment Manager. The
developer may experience as a result of the potential expansion Customization Service mainly focuses on customizing the resources
of the pool of resources. and (virtual) devices, setting specific low-level parameters such
as duty cycle, sampling frequency and scale range for sensing
5. The platform: MCSaaS module resources, as well as high level configurations of the software
environment hosting the injected code of the MCS application.
For the design of the MCSaaS stack, the need comes up to define This is achieved by translating high-level directives in terms of
what an MCSaaS platform should offer. PaaS is an intermediate uniform low-level primitives, still expressed in a generic form, as
service model for Cloud computing, between IaaS and SaaS, where those are ultimately relayed to the SAaaS for further processing.
the consumer creates software using tools, libraries, etc., available The Deployment Manager instead is aimed at deploying the
from the provider, also controlling software deployment and required modules on the available resources, adapting them to
configuration settings. The PaaS provider usually hosts lots of the hosting environment. Pre-configured packages or bundles may
ancillary facilities to the main infrastructure under consideration be provided, where the payload may contain a whole application
(in our case SAaaS mainly), e.g., networks, servers, storage, sensors. environment or parts of it, or even extra tools that implement
A platform like MCSaaS must cater for domain-specific APIs advanced features such as analytics, interfaces, domain-related
for MCS, such as pre-filtering and pre-processing mechanisms to plugins and add-ons. As the latter modules are here the main focus
be leveraged both at the node endpoint (e.g., the mobile) and at for the initial implementation, in Section 6 the workflows involved
the Cloud, while considering the trade-off between communica- are described and in Section 7 more details are given in terms of the
tion overhead and local computation. Other APIs would include corresponding software design.
general-purpose analytics frameworks, in this case to be lever-
aged only at IaaS/DaaS level. Issues related to federation, inter- or 6. Setup and deployment of MCS applications
multi-Cloud setups, privacy, security and trust, which would ide-
ally fall under the scope of MCSaaS, have not been investigated Within the proposed paradigm, the actions and interactions of
for this specific effort. Thus application hosting and a deployment the main stakeholders (depicted in Fig. 2) through the blocks and
environment are the main focus in this context. Moreover a PaaS the modules identified above, are of high practical importance.
typically also includes facilities for application design, application Thus, the main activities related to MCS application setup,
development and testing as well as typical services for developers deployment and management into the MCSaaS framework, are
and integrators, such as team collaboration, Web service integra- described through the following Activity Diagrams (AD). More
tion, database-driven persistence, state management, application specifically, two main perspectives associated with the MCSaaS-P
versioning, application instrumentation / profiling and facilities for and the MCS ASP are taken into account in the description of these
community nurturing. main activities, which include (i) setting up an MCSaaS platform
All aforementioned functionalities are synthesized in the (Section 6.1), followed by (ii) the configuration and deployment of
MCSaaS module implementing a PaaS service at the platform a specific MCS application on it (Section 6.2), respectively.
layer (see Fig. 5). The Infrastructure Interface provides the
means to interact with the underlying sensing Clouds. Standard 6.1. MCSaaS platform setup
interfaces such as OCCI [29] and/or specific techniques following
the multi-Cloud approach can be adopted. On top of the With regard to enablement of PaaS over potentially exploitable
Infrastructure Interface, four MCSaaS core sub-modules are infrastructure (SAaaS), we first need to describe a bootstrap
defined, namely Cloud Broker, Orchestrator, Customization Service scenario, where mandatory MCSaaS components are pushed to the
and Deployment Manager. mobiles in a PaaS-agnostic way. In more detail, the following kind
An incoming MCSaaS request is forwarded by the Platform of interaction is envisioned: the MCSaaS provider needs to choose
Interface to these sub-modules. Such interface should be RESTful the appropriate infrastructure, given a set of available InPs, to offer
and expose as entities useful abstractions, e.g., application bundle MCS as a service.
630 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

Fig. 6. Initial platform setup.

Afterwards a phase of bootstrap ensues, where the MCSaaS-

P must enable every mobile, booked through the SAaaS InP, for
easy MCSaaS-assisted deployment of MCS applications. For this
purpose SAaaS-provided services, powered by the Hypervisor, are Fig. 7. App negotiation and platform bootstrap.
employed to deploy the node-side MCSaaS module.
The MCSaaS module enables contributors to choose their level 6.2.1. Negotiation and bootstrap
of involvement and resource sharing for MCS apps, i.e., not Fig. 7 describes the (PaaS-mediated) app negotiation and
only sensing resources as in pure SAaaS scenarios, but also platform bootstrap stages. The former entails identifying the
CPU time, memory and/or on-board storage. Moreover, this required building blocks for the app, in terms of IaaS/DaaS/SAaaS
module is in charge of duties related to MCS app deployment, resources, with a phase where the developer (or MCS ASP)
i.e., activating endpoints for, and then cooperating with, the pushes the corresponding plan to the platform frontend (resource
Deployment Manager in Fig. 5, also enforcing the aforementioned planning). It is followed by a negotiation of the requirements to be
choices in terms of local computing and storage resources when matched, coordinated by the Cloud Broker, possibly with iterations
receiving and deploying the next MCS app. involving the MCS-ASP still into the planning stages (requirement-
The aforementioned approach, apart from avoiding layering
constraint matching). Upon agreement and following the MCS ASP
(IaaS/PaaS) violations, also enables us to implement the mobile-
confirmation (confirm reservation), the platform modules have to
side SAaaS components to cope just with sensing infrastructure
be deployed into the provided sensing resources, through the
concerns and SAaaS scenarios. This focus then carries over also
interaction between the MCSaaS-P (platform bootstrap) and the
in terms of sandboxing and other security-related mechanisms,
InP (bootstrap module deployment). Thus, the end-point references
e.g. dealing with user-mandated restrictions, only with regard to
(EPR) of the reserved sensing resources are fed back to the MCSaaS-
SAaaS-relevant sensing resource usage and interactions.
P and stored (register resource EPR) and the reservation data
In the same fashion, any node-side operations dictated by the
forwarded to the MCS ASP (store rsv info).
Customization Service, would just be dealt with by the boot-
strapped environment, thus leading to the development of certain
security-related mechanisms, such as checking permissions of MCS 6.2.2. Deployment
apps in terms of, e.g., access to any kind of user data, to be imple- Field deployment of an MCS app, as detailed in Fig. 8, starts
mented only at this level, i.e., in the MCSaaS bootstrapped compo- with the MCS ASP choosing among available APIs (choice of API), for
nent itself. basic as well as advanced operations (e.g. pre-filtering, analytics).
Fig. 6 depicts MCSaaS-P activities related to the platform setup, This is followed by the platform’s artifact contextualization of
starting with a macro-step including all actions involved inPaaS- the MCS application and the configuration of the infrastructure
enablement for infrastructure, such as identifying and selecting sensing resources on the specific application domain (app domain
potential InPs, exposing relevant APIs and service endpoints. configuration), translating at the same time customer-driven
Afterwards a phase of platform frontend configuration follows: constraints on resources and APIs by wiring up infrastructure
this entails the setup of a Software as a Service instance, i.e., a endpoints accordingly (service endpoint wiring).
Rapid Application Development (RAD) environment available to Then, an initial set of requirements is submitted by the
application developers. As soon as the frontend is ready, the application (requirement push), which is the ‘‘recipe’’ (including
MCSaaS-P can ‘‘go live’’ and start servicing customers, e.g. MCS high-level code) obtained during the bootstrap phases as discussed
ASPs. in Section 6.2.1. This step kickstarts the artifact deployment
(binaries, configurations, system images, etc.) to VMs, storage
6.2. MCS application configuration and deployment objects and, in the case of SAaaS, contributor-owned mobiles.
Behind the scenes the deployment would be preceded by
The MCS application configuration/deployment is performed translation of recipes in artifacts, e.g. compilation/packaging, still
by the MCS ASP using the services provided by an MCSaaS-P and up to the Deployment Manager. Activation of the endpoints, and
is broken down into the (i) application negotiation and platform subsequent mapping of the wiring (as shown in the corresponding
bootstrap stages and (ii) the actual app deployment, detailed in AD of Fig. 8) over allocated resources (orchestration), are up to
Sections 6.2.1 and 6.2.2 respectively. the Orchestrator. For the operations of the Orchestrator to be
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 631

mechanisms, as well as for on-demand activation of a WebSocket-

based subsystem. This preference towards a (partially) custom
communication bus lies in the inherent limitations (and costs)
borne by the use of GCM, which is simply not meant for big
payloads (e.g., file transfers), but is specifically designed and
marketed for push notifications and in our case employed also for
signaling.
In terms of the main modules, the Broker keeps track of the
reservations and transfers resource requests to the Orchestrator.
The latter in the current implementation mainly deals with churn,
which at MCSaaS level means reacting to fluctuations in the
number of active contributors for any of the MCS apps hosted
by the system. In particular, as soon as in a certain area such
population falls below a threshold, according to parameters set
by the MCS developer, the churn management routines running
in the Orchestrator look up other platform-enabled nodes in
the same area to push notifications through GCM, meant for
triggering the nodes to retrieve the package, install and launch
the corresponding payload, the MCS app. The whole MCSaaS
Fig. 8. MCS app deployment. population is continuously under tracking so any query is expected
to be serviced in the order of fractions of a second. The client-
effective, or even just feasible under most circumstances, platform- side component of the Deployment Manager listens for incoming
initiated activations and (re)wirings are required, thus leading to a payloads, tagged as such by the server-side logic, to automate the
need for an always-on (anytime) push-to-client messaging channel installation of the app as soon as it is downloaded onto the device.
for each registered device, powered by environment-agnostic bi- This is to let the app be installed without any user intervention,
directional asynchronous exchange primitives. albeit the process gets inevitably visible at times, as some windows
Afterwards, a phase of resource contextualization, by means would pop up anyway during installation stages, albeit for very
of the Customization Service, is called for, either in terms of short time intervals (e.g., less than a second for any window
configuring or even customizing the underlying resources, e.g., by instance).
iteratively involving the SAaaS services, where relevant. Mapping Fig. 9 depicts the layout of the infrastructure and platform-
and, especially, customization could possibly lead to a mismatch level framework subsystems, the MobileCrowdSensing Open Stack
between initial requirements and actual setup, thus requiring (MobiCSOS), focusing on communication between end users,
eventual iterations with MCS ASP to reach a convergence or at least e.g., MCS ASPs and other interested developers, and sensor-
a satisfactory trade-off before stopping the matchmaking process. /actuator-hosting nodes. On the node side, the MobiCSOS Edge,
Furthermore, the MCS ASP can start exposing a portal or useful acting either as SAaaS Client or MCSaaS Client according to
Web services to share and visualize full datasets, or any compact the corresponding instance of execution, interacts with the OS
representation thereof in the dataset sharing service deployment. resources and services, and in the case of SAaaS, with (virtualized)
These datasets may therefore be provided to third parties (also as sensing and actuation resources through (mediated) access to the
Sensing APIs. It is the point of contact with the Cloud infrastructure,
OpenData) to let them develop applications centered around such
allowing end users to manage node-hosted resources even if they
datastores.
are behind a NAT or a strict firewall. This is ensured by a GCM and
WebSocket-based communication between the MobiCSOS Edge
7. The MCSaaS design
and its Cloud counterpart, namely the MobiCSOS MPlatform service.
The MobiCSOS MPlatform service, acting both as VolunteerCloud
In the following we provide a description and some details Manager (SAaaS) and Broker (MCSaaS), is implemented as an
regarding the MCSaaS stack implementation. OpenStack service, providing Cloud users with the ability to
With regard to the node-side runtime, there are the Sensing book and manage SAaaS or MCS-contributed resources remotely,
APIs and the environment-provided notification subsystem which respectively. This can happen both via a command-line based
are of particular relevance to our design. Whilst the former is client, namely MobiCSOS command line client, and a Web browser
opaque in terms of the MCSaaS, as its Customization Service has though a set of servlet-wrapped RESTful APIs provided by the
to relay sensor reconfiguration and tuning requests to the SAaaS MobiCSOS MPlatform service.
device-side subsystem, the latter is useful at both Cloud layers,
to minimally involve platform-provided Cloud-based mechanisms 7.1. Node-side components
for push-based communication to devices, avoiding to tackle
corner cases in terms of reachability, and tracking of networking With respect to network connectivity and presence/reachability,
conditions in general. WebSockets [28] are our technology of choice, a standard HTTP-
The server-side logic, available in the Orchestrator and the based protocol providing full-duplex TCP communication over a
Cloud Broker, has been developed in Java and Python, resorting single HTTP-based persistent connection. One of the main advan-
to servlets [31] in terms of the user-facing interaction model and tages of WebSocket is that it is network agnostic, and clients only
RESTful endpoints as Cloud-private interfaces to the mechanisms need outgoing traffic (over standard ports for the Web) to be al-
implemented in Python. lowed. This is of benefit for those environments which block any
Apache Tomcat [32] is used as the Java servlet container. For Internet connections unrelated to Web traffic using a firewall.
example, Google notification service, Google Cloud Messaging Fig. 10 shows the MobiCSOS architecture with more focus
(GCM) [33], is used for exchanging (MCSaaS-bootstrapping) on the node side SAaaS components, whereas Fig. 11 shows the
asynchronous messages in Android-powered mobiles, as needed architecture with regard to the MCSaaS instance of node-side
to support Cloud-initiated primitives and runtime customizable MobiCSOS components.
632 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

Fig. 9. MobiCSOS subsystems, for mobile-based nodes.

Fig. 10. MobiCSOS node-side SAaaS architecture.

Building upon the Sensing APIs abstraction at the lowest level, libraries) and to the interactions with OS resources and system-
there is the need for the SAaaS node-side subsystem to mediate level tools (e.g., filesystem, background services and activities,
access by means of a set of virtualization-inspired libraries, package manager). Communication with the Cloud is ensured by
denoted as MobiCSOS virt libraries. These provide the interface to SDK-provided primitives for push-based messaging, in our case
read/write sensor/actuators as well as to set device parameters, GCM under Android.
thus are an actual implementation of the SAaaS Hypervisor. Moreover, a set of WebSocket libraries (MobiCSOS wstunnel
Such operations are thus placed at the right level of semantic libraries) enables the engine to act as a WebSocket-based (reverse)
abstraction, i.e., locking and releasing resources according to tunneling server, connecting to a specific WebSocket server
bookings and in a way that is dependent upon constraints deriving
running in the Cloud. This allows internal services to be directly
from the granularity of the APIs and that are specific to the sensing
accessed by external users through the tunnel, whose incoming
and actuating resources.
traffic is automatically forwarded to the internal background
The MobiCSOS Edge hub represents the core of the board-side
service under consideration. Outgoing traffic is redirected to the
software architecture, thus can be considered as the centerpiece of
the SAaaS Autonomic Enforcer, whereas a specialized instance of tunnel and eventually reaches the end user that connects to the
the same component is hosted in the MCSaaS client. This engine WebSocket server running in the Cloud to interact with the node-
in both instances interacts with the Cloud through a WebSocket hosted service.
full-duplex channel and GCM-based messaging (see also Fig. 12), The MCSaaS gets (selective) access to the (virtual) sensing
sending and receiving data to/from the Cloud and executing resources by means of the MobiCSOS sensing proxy, as well as to
commands provided by the users via the Cloud, respectively. mobile-hosted services and in particular the package manager,
Such commands can be related to the communication with the through the corresponding proxies as depicted in the diagram. All
node sensing and actuation resources (through the MobiCSOS virt such proxies interact with the SAaaS instance of the Edge hub.
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 633

Fig. 11. MobiCSOS node-side MCSaaS architecture.

Fig. 12. MobiCSOS Cloud-side architecture.

The Edge subsystem also provides a plugin loader which, many research projects are founding their Cloud strategies. Hence
in the MCSaaS instance, implements the node-side mechanisms our goal is to extend OpenStack for the management of sensing and
enabling the Customization Service. Custom plugins can be actuation resources and to support a platform for MCS.
injected from the Cloud and run on top of the plugin loader to The MobiCSOS Cloud-side architecture (see Fig. 12) consists
implement specific user-defined primitives, including (sandboxed) of an OpenStack service we called MPlatform. MPlatform is char-
system-level interactions, such as, e.g., with a package manager acterized by the standard architecture of an OpenStack service.
and/or services automatically started at boot-time. Indeed, one The MobiCSOS MPlatform conductor represents the core of the ser-
of such plugins, the one interacting with the package manager, vice, managing the MobiCSOS MPlatform database that stores all
implements the node-side counterpart to the MCSaaS Deployment the required information, e.g., node-unique identifiers, association
Manager. with either SAaaS and/or MCSaaS users and tenants, board prop-
erties and hardware/software characteristics as well as dispatch-
ing remote procedure calls among other components. Indeed, it is
7.2. Cloud-side architecture the component where the Broker and Orchestrator logic is imple-
mented, otherwise interacting with external ad-hoc services im-
As already mentioned, with respect to virtual infrastructure plementing mechanisms for customization and deployment, here
management, OpenStack [34] is the technology of reference. comprising an instance of a continuous integration subsystem,
OpenStack is a centerpiece of infrastructure Cloud solutions for i.e., Jenkins [35].
most commercial, in-house, and hybrid deployments, as well as a The MobiCSOS MPlatform APIs exposes a two-fold RESTful
fully Open Source ecosystem of tools and frameworks upon which interface for the end users, one for SAaaS and the other for
634 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

Fig. 13. MCSaaS-driven app deployment scenario.

MCSaaS, that may interact with the services both via a custom scenario, involving two different MCS applications: (i) a multi-
client (MobiCSOS MPlatform command line client) and via a Web purpose community-focused app for pothole mapping and (ii)
browser. In fact, the OpenStack Horizon dashboard has been a traffic monitoring app serving the Messina, Milan and Athens
enhanced under the guise of a MobiCSOS dashboard, exposing all urban areas (Fig. 13).
the functionalities provided by the MobiCSOS MPlatform service The UMe (University of Messina), PMi (Politecnico di Milano)
and other software components. In particular, the dashboard also and NTUA (National Technical University of Athens) SAaaS (InPs)
deals with access to node-internal services, redirecting the user to are used in the deployment scenario, leveraging their private
the MobiCSOS MPlatform WS tunnel agent. This piece of software is IaaS and DaaS providers if needed (such as the OpenStack-
a wrapper and a controller for the WebSocket server to which the powered UMe and PMi PoliCloud [37]). However, any private or
nodes connect through the use of MobiCSOS wstunnel libraries. public company/institution (e.g., mobile telcos) could take up the
Similarly, the MobiCSOS MPlatform GCM agent acts as a role of the InP. Our SAaaS Clouds feature smartphone sensors
GCM bridge between other components and the nodes. Indeed from volunteering Contributors (roaming users). Smartphones are
the command stream, such as the one originating from the bound to be extremely useful in such scenarios, as they are
Customization Service, gets relayed by the GCM agent. It translates equipped with several relevant sensors e.g., for positioning (GPS,
AMQP messages into GCM messages and vice versa. Following the GSM, WiFi) and motion detection (gyroscope), while supporting
standard OpenStack philosophy all the communication among the (always-on) Internet access. Roaming users become Contributors
MPlatform components is performed over the network via AMQP by discovering and (non-exclusively) subscribing to SAaaS Clouds.
queues. This allows the whole architecture to be as scalable as The UMePMiNTUA MCSaaS-P is established according to the
possible given that all the components can be deployed on different workflow depicted in Fig. 6. After the selection of the appropriate
machines without affecting the service functionalities, as well as
InPs (subscribed to services, signed SLAs, etc.), UMePMiNTUA dis-
the fact that more than one tunnel agent together with more than
covers, collects and exposes generic (templatized) WS endpoints
one GCM agent may be instantiated, each of them dealing in that
(URIs), typically for RESTful consumption, and corresponding APIs
case with a subset of the enrolled mobiles. This way, redundancy
documentation within an HTML5-powered RAD IDE.
and high availability may also be guaranteed.
On top of this platform, the pothole mapping and traffic
With regard to discovery mechanisms, which are core to the
monitoring apps are provided by two different MCS ASPs.
enrollment stages for the MPlatform conductor to register the
Contributors may be engaged for both pothole mapping and traffic
available resources, the design is based upon the AllJoyn [36]
monitoring MCS apps concurrently, a desired outcome and one of
framework for IoT, a family of standards and reference imple-
the main drivers behind this effort. The MCS End User (EU) (e.g., a
mentations which comprises at its core a DBus-derived applica-
tion protocol useful for messaging, advertisement and discovery of taxi driver), uses the corresponding mobile (or Web-based) apps
services, working via selected mechanisms on available transports, for retrieving the information of interest. Often an MCS EU also acts
in our case over MPlatform-enabled WS tunnels. as a Contributor.
In the following, we initially discuss how to set up and deploy
8. MCS app case study these two MCS apps (Sections 8.1 and 8.2) using the proposed
MSCaaS platform. Then, in Section 8.3, we (i) report on the
In this section we discuss examples of MCS applications preliminary results of the MobiCSOS prototype in the context of
deployed using the MCSaaS platform, highlighting the benefits of the traffic monitoring use case and (ii) highlight the benefits of the
MCSaaS. To compare the proposed approach against the traditional MCSaaS approach against the conventional MCS one through an
MCS one, we consider two possible use cases in an IoT/Smart City analytic model.
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 635

8.1. Pothole mapping meant for automatic deployment of multiple MCS apps if needed,
ready to be executed side by side, so a scenario where both
A pothole mapping MCS application automatically collects the pothole mapping application and the traffic monitoring ones
road condition information once it is started, without human are concurrently working in background is absolutely feasible
intervention. It requires just an accelerometer and a positioning and contemplated, while still addressing the specifics of the
system at the core, to be sampled for detection of abrupt vertical requirements of each application, e.g., real-time constraints on the
displacements and geo-localization. Data validation including the availability of actively contributing resources in the case of traffic
removal of outliers and elimination of false positives is facilitated monitoring only.
by the crowdsensing approach collecting, analyzing and clustering The latter is really a use case for the orchestration capabilities
input coming from a diverse range of users. of the platform, as exemplified by the management of node churn,
In the current MCS app deployment scenario, the pothole which needs to be addressed on a continuous basis, to provide
app requires just a database and a server for the Web UI. the expected quality of service, or at least degrading gracefully
Therefore planning the requirements in terms of IaaS/DaaS is quite by informing the developer about the number of currently (or
straightforward. On the other hand, the high-level constraints for recently) involved contributors per area, in other words, under
the sensing infrastructure to be transmitted/negotiated include a simplified scheme, the confidence interval with respect to
(i) sensing potential (accelerometers and positioning at least), (ii) displayed metrics.
geographical area and (iii) device mobility (vehicular, e.g., bikes This way, resorting to the MCSaaS provider UMePMiNTUA is
and cars). The app design stage requires to leverage a set of libraries maybe the only effective solution to ensure a predefined level of
and ready-made routines, a typical process for a RAD environment, accuracy in sampling for the traffic monitoring service. Also in this
for, e.g., mobile-side outliers detection, as well as IaaS APIs to case a hybrid MCS-MCSaaS solution may be effective, exploiting
choose from (OGC- or M2M-compliant REST calls), etc., following the (vehicular) sensing resources provided by the UMePMiNTUA
the PaaS approach. MCSaaS-P to complement and enrich the information gathered
Once the app is released, the pothole ASP has two main from the contributing ones engaged by the traffic monitoring ASP
alternatives: directly enrolling contributors supporting the pothole through a traditional MCS enrollment process. On the other hand,
mapping service in a given area of interest (traditional MCS) or the enrollment of sensing resources from UMePMiNTUA follows
asking an MCSaaS-P, e.g., UMePMiNTUA, to provide the required the negotiation and deployment/configuration phases described in
(vehicular) sensing resources. As discussed above, in the former Figs. 7 and 8.
case, user enrollment could be slow or even not successful, while
in the other case the MCS ASP has immediate access to the 8.3. Testing and evaluation
sensing infrastructure at the cost of the provided service (MCSaaS).
Combining the two approaches in a kind of ‘‘cloudbursting’’
To demonstrate the effectiveness of the MCSaaS model
fashion, the pothole ASP may resort on-demand to third party
against the traditional MCS one, we evaluate (i) a preliminary
sensing resources provided by the UMePMiNTUA MCSaaS-P along
implementation of the MobiCSOS stack for the deployment of the
the ‘‘owned’’ ones directly engaged by the MCS, when required,
traffic monitoring app and (ii) the corresponding GSPN models.
e.g. in the case accuracy in the mapping is required within a given
time constraint.
The pothole ASP has to negotiate with the UMePMiNTUA 8.3.1. MCS application deployment: A proof of concept
MCSaaS-P for the resources, required by the pothole mapping app The traffic monitoring application, denoted hereafter as MCS-
that needs to be deployed in the MCSaaS platform/infrastructure. Traffic app, falls under the category of infrastructure MCS apps
In the case of successful negotiation, the sensing resources [1]. The implementation of the MCS-Traffic application follows
provided by the UMePMiNTUA MCSaaS-P have to be set up and the same principles as similar community-based GPS-enabled
configured to receive the pothole app code as shown in Fig. 7. applications for navigation (e.g., Waze [38]), using contributor’s
The pothole app deployment begins as soon as the developer location and travel times via GPS to provide real-time traffic
lets the output (recipe) of the design stage be consumed by updates, as exemplified in Section 8.2. To show the benefits of using
the Deployment Manager, in this case just dealing with a the proposed paradigm for the MCS ASP, as opposed to current MCS
limited subset of binaries (e.g., compatible with Android-powered application deployment practices, an illustrative example related
mobiles), with regard to sensing resources (Fig. 8). Finally, at to the MCS-Traffic app is presented, specifically focusing on issues
instantiation time endpoints that are provided/consumed by the such as volunteer-based contribution and node churn.
application get enabled and the (abstract) wiring in the recipe gets Testing scenario. The MCS-Traffic app requires real-time informa-
mapped to the infrastructure by the Orchestrator. tion (via GPS tracking) to provide updates on (expected) travel
times for an arterial road (service area). Specifically, the minimum
8.2. Traffic monitoring number of actively probing vehicles (contributors) is crucial for es-
tablishing the reliability of estimations in terms of link speed [39].
Another application of the MCS paradigm may be traffic A link is a section of road spanning a continuous segment with no
monitoring, which is a useful instance of service based on mobile intersections, while the link speed refers to the distance traveled
contributors, still related to drivers also as a potential pool of by a vehicle in a unit of time.
consumers and/or producers, and in general in the same domain. We consider the following testing scenario: vehicles enter the
In terms of MCS, while the sensing activities are similar to pothole service area according to a Poisson process and travel times are
mapping, e.g., still mainly enabled by positioning subsystems and normally distributed [40]. We assume that data from at least 10
accelerometers, the requirements diverge remarkably. probes are required with a sampling period of 700s to establish the
As overall traffic and specific metrics, such as current cruising reliability of the estimate on link speed [39]. This way, the traffic
speed and the rate of slowdowns, to name a few, need to be fed monitoring app is able to correctly estimate and predict actual
and updated in real-time for the service to be genuinely useful, traffic in the area of interest.
it follows that there are constraints such as, e.g., the minimum In our experiments we assume to have an average population
number of contributors per area on average, to ensure accuracy of 150 vehicles in the service area. Furthermore, we assume that
on traffic monitoring sampling. Most importantly the platform is just a part of them are also SAaaS contributors (about 8%), and
636 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

similarly that just about 5% of vehicles are MCS contributors,

directly engaged by the ASP. These values are arbitrary, however,
since a conventional MCS application needs to recruit, engage and
retain participants, we consider such assumptions reasonable, and
maybe a bit conservative in the MCSaaS case.
Testing environment. The prototype implementation of MobiCSOS
at MCSaaS and SaaS levels, described in Section 7, has been used
to test the deployment and operation of the MCS-Traffic app. MCS
EUs/contributors were emulated (running Android 4.2/API level
8 [41]), due to the lack of a substantial number of physical devices,
as required by the testing scenario. We adopted Android, not only
for its widespread availability and popularity, but also for some of
the facilities the SDK and the runtime environment provide, e.g. the
emulation subsystem (using Genymotion [42]) and the Debug
Bridge (ADB) [43] for the management of emulated instances.
Helper functions, using shell scripting, were employed for setting
up the testing scenario (e.g., vehicle mobility, engagement, etc.)
along with ADB for provisioning and control of the emulated Fig. 14. Basic MCS and MCSaaS emulation scenario contribution sampling.
instances.
Experimentation metrics. The two different scenarios discussed in (1) the time needed for the SAaaS server to identify the arrival of
Section 3 are examined in experiments based upon the MCS-Traffic a new contributor and initiate the MCSaaS client installation
app: (i) the one envisioned under the conventional MCS paradigm process;
and (ii) the one enabled by the proposed MCSaaS paradigm. (2) the MCSaaS client installation time;
We compare these two scenarios based on the average number (3) the time needed for the MCSaaS server to identify the arrival of
of vehicles within the service area as a function of time, serving a new contributor and initiate the MCS-Traffic app installation;
as active probes (Number of Contributors). For this purpose, (4) the application installation time.
we enumerate the (i) MCS contributors (MCS-C), involved in This delay is also captured in the MCSaaS curve of Fig. 14,
the conventional MCS scenario; and (iii) MCSaaS contributors highlighted in the [0, 10] time unit interval.
(MCSaaS-C), contributing to the traffic monitoring app through In this evaluation we neglected the overhead introduced by the
the whole MobiCSOS stack. MCSaaS contributors are a subset of abstraction of sensor resources and registration of infrastructure
users engaged by the SaaS provider (InP) that are denoted as SAaaS services, since in [44] we measured metrics pertaining to the
contributors (SAaaS-C). abstraction overhead of sensing resources, at the SAaaS level, and
In addition, we quantify the effect of Resource Churn, by mea- we found it could be considered negligible for all purposes. With
suring on average the time required by the MobiCSOS framework regard to registration, it can be prospected as a typically one-time
to replace MCSaaS contributors that left the service area, restoring (SAaaS-level) operation, so it is not so critical in the long term.
the MCSaaS pool to the number required by the MCS-Traffic app. A quantitative, in-depth evaluation on the impact of the churn
Results and comparison. In the MCSaaS scenario, it is up to the SAaaS management in terms of performance cannot be performed due to
provider (InP) to ensure a consistent high number of contributors the limits of the testbed and the preliminary implementation of
engaged to a MCSaaS-P. Then it is up to the MCSaaS-P in its the MobiCSOS framework. Nonetheless, some general, qualitative
turn to reserve at least the minimum required amount of MCS observations, based on the experiments conducted, are reported
contributors, according to the application requirements (in this in the following. The impact of resource churn (and subsequent
case the MCS-Traffic app). updates of resources) on the performance of the service to be
Number of Contributors: For the set of sampling periods, we offered (i.e., the MCS application) is rather limited by design, as
estimated on average 5.8 contributors for the conventional MCS long as any replacement is application-transparent (as is the case in
scenario and 9.2 contributors for the MCSaaS one, excluding a general for MCSaaS). The overall application behavior may depend
warm-up period of 500 s. Comparing the results obtained in the on the smoothness of the curve depicting the ratio of available
case of the MCSaaS scenario to the conventional one, we can argue resources to the requested ones over time, as in the case of the
that the MCSaaS solution succeeds in engaging contributors within traffic monitoring app. Reactivity is thus key mostly when dealing
the service area, as it approximately meets the constraint posed by with loss of huge numbers of contributed devices. App deployment
the MCS-Traffic app in terms of the number of active probes (10 time, depending on bandwidth and concurrent (non-blocking) fan-
probes are required). out, is mostly constant, not proportional to the number of devices
The effectiveness of the proposed approach in addressing the to be replaced.
requirements of the application, is also visible in Fig. 14 that is a
snapshot of the emulation within a sampling period, just reporting 8.3.2. Modeling and evaluation
on a single testing trace. Following the 20th time unit there To further highlight the benefits of the MCSaaS approach
are two, almost simultaneous, SAaaS contributor departures that against the basic MCS one, two simple models representing the
affect the MCSaaS provisioning service. However the MobiCSOS paradigms under comparison have been devised and evaluated
framework is able to promptly react, restoring the MCSaaS pool to through Petri nets (Fig. 15). The MCS model of Fig. 15(a) is more
10 contributors/probes as requested by the MCS-Traffic app. complex than the MCSaaS one of Fig. 15(b), since it has to consider
Resource Churn: Through the experiments we evaluated a lag the contributor enrollment and churn management, while in
of 6 time units (30 s) on average, due to the resource churn func- the MCSaaS approach this is managed by the SAaaS provider,
tionality, for the MCSaaS system to actually replace contributors assuming there are always enough SAaaS contributors available
(MCSaaS-C) that left the system. This lag is broken down into four satisfying the app requirements. This assumption is quite realistic
intervals: considering that, if motivated with specific incentives, the SAaaS
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 637

(a) MCS. (b) MCSaaS.

Fig. 15. PN models of the two approaches.

contributor population should be very large, orders of magnitude Table 2

larger than the one supporting a single app. Furthermore, this Parameters of the PN models (h−1 ).
availability, paired to the MCSaaS facilities for churn management, λSubscribe λJoin λLeave λEnter λExit λReplacement λJoin−Enter λLeave−Exit
should easily allow to always have enough contributors actively 1/24 1/3 1 1/4 1 120 7/12 2
engaged by, and contributing to, the app.
We represented a generic MCS application as the pothole map-
ping or the traffic monitoring ones above described, elaborat- the above experiments. This way TJoin−In and TLeav e−Out represent
ing data coming from a given area of interest. This way, in the the dynamics of active contributors (Av/In) only for the MCSaaS
PN of Fig. 15(a), four possible states can be identified for a con- system.
tributing node, obtained as combinations of contributor availabil- With regard to MCSaaS, at the time the R requested sensing
ity (Av/NAv) and position on the area of interest (In/Out ). A node resources are provided (PAv/In−Act ), the system has N further
is thus actively contributing to the MCS app if it is available and in resources available in the area of interest that could be used as
the area of interest (PAv/In ), while it is not contributing otherwise, spares in the case of node churn (PAv/In−NAct ). Other S contributors
i.e., if outside the area or not available (PAv/Out , PNAv/In , PNAv/Out ). (P¬AvIn ) may join the system or enter the area of interest later on.
New contributors may subscribe to the MCS system (through tran- In the models we used exponential distributions to stochasti-
sition TSubscribe ), and will enter the system in one of the above iden- cally characterize these behaviors, assuming all the related events
tified conditions (PAv/In , PAv/Out , PNAv/In , PNAv/Out ), able to actively are effects of random causes and thus randomly distributed. This
support the MCS service only when in the area of interest and avail- way two GSPN models are obtained. The distribution parameters
able (PAv/In ). The entry condition is therefore probabilistically spec- have been chosen also based on existing literature [45]. The rates
ified by assigning corresponding weights to the immediate transi- of all the transitions are reported in Table 2. Notice that λReplacement
tions after the input place: we assigned high (equal) weights (4) is obtained by the experiments described in the previous section
to the transitions to PAv/In , PAv/Out , assuming that 80% of new sub- (30 s per replacement). It is important to remark that such rates
scribers are immediately available to contribute, while low weights and the corresponding distributions are marking dependent since
each of them represents a single activity or contributor. This is rep-
(1) have been associated with PNAv/In and PNAv/Out , meaning that
resented in Fig. 15 by a # symbol close to the marking dependent
just 20% of new subscribers are not immediately available to con-
transition.
tribute. Then, once in the MCS system, subscribers can change their
The evaluation results shown in Fig. 16 demonstrate the
states becoming available/not available or going in/out the area of
effectiveness of the MCSaaS approach. Indeed, considering R =
interest. In the first case, transitions TJoin∗ and TLeav e∗ regulate avail- 10, N = 5 and S = 20, the MCSaaS system is able to ensure on
ability changing, while transitions TEnter ∗ and TExit ∗ characterize the the average 9.99 continuously operating nodes, with a probability
in/out mobility, respectively. of 0.989 to provide 10 users, as requested by the MCS. Higher
On the other hand, the MCSaaS system is supported by the probability can be reached by over-provisioning. The results also
SAaaS infrastructure that, as discussed above, we assume is always highlight the slow dynamics of the MCS system, which requires
able to expose the right subset of sensing resources (R), for the about 100 days to reach 10 actively contributing nodes on the
scenarios at hand, to the MCS application to be deployed due average, on the basis of about 100 subscribers.
to a large population of motivated and incentivized contributors. Another interesting metric that allows us to compare the MCS
In fact, given large-scale field use of SAaaS-enabled devices, and MCSaaS approaches is the amount of data collected and
the assumption about availability of a sensor-rich and diverse managed by the system. Assuming a simple model where every
range of measurable quantities and technologies for sampling node contributes with a constant data rate, e.g., 100 MB/day for
may hold, while delegating to the SAaaS components mostly a system contributing steadily over 24 h, according to the results
duties related to capability abstraction and discovery. The model of Fig. 16, the total amount of data gathered by the MCS system
thus mainly represents the node churn management, where the against the MCSaaS one over the first 10 days is about 50 MB vs 10
replacement of a leaving contributor with one who is available GB (a 1:200 ratio in favor of the MCSaaS), 20 GB vs 200 GB (1:10)
and in the area of interest (PAv/In ) is stochastically characterized over 20 days, 125 GB vs 500 GB (1:4) over 50 days, 500GB against
and quantified (TReplacement ) according to the values obtained by 1 TB (1:2) over 100 days, respectively.
638 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639

[9] N. Lane, E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, A. Campbell, A survey of

mobile phone sensing, IEEE Commun. Mag. 48 (9) (2010) 140–150.
[10] B. Guo, Z. Yu, X. Zhou, D. Zhang, From participatory sensing to mobile crowd
sensing, in: 2014 IEEE International Conference on Pervasive Computing
and Communications Workshops, PERCOM Workshops, 2014, pp. 593–598.
http://dx.doi.org/10.1109/PerComW.2014.6815273.
[11] X. Yu, W. Zhang, L. Zhang, V.O. Li, J. Yuan, I. You, Understanding ur-
ban dynamics based on pervasive sensing: An experimental study on traf-
fic density and air pollution, Math. Comput. Modelling 58 (56) (2013)
1328–1339. http://dx.doi.org/10.1016/j.mcm.2013.01.002. the Measure-
ment of Undesirable Outputs: Models Development and Empirical Anal-
yses and Advances in mobile, ubiquitous and cognitive computing. URL
http://www.sciencedirect.com/science/article/pii/S089571771300006X.
[12] E. Aubry, T. Silverston, A. Lahmadi, O. Festor, Crowdout: A mobile crowd-
sourcing service for road safety in digital cities, in: 2014 IEEE International
Conference on Pervasive Computing and Communications Workshops, PER-
COM Workshops, 2014, pp. 86–91. http://dx.doi.org/10.1109/PerComW.2014.
6815170.
[13] P. Mohan, V.N. Padmanabhan, R. Ramjee, Nericell: rich monitoring of road and
traffic conditions using mobile smartphones, in: Proceedings of the 6th ACM
Conference on Embedded Network Sensor Systems, SenSys ’08, ACM, New
York, NY, USA, 2008, pp. 323–336.
[14] S. Hu, L. Su, H. Liu, H. Wang, T. Abdelzaher, Smartroad: A crowd-
sourced traffic regulator detection and identification system, in: Pro-
Fig. 16. Comparison between the approaches through PN model evaluation.
ceedings of the 12th International Conference on Information Pro-
cessing in Sensor Networks, IPSN ’13, ACM, New York, NY, USA,
2013, pp. 331–332. http://dx.doi.org/10.1145/2461381.2461433. URL
9. Conclusions http://doi.acm.org/10.1145/2461381.2461433.
[15] G. Merlino, D. Bruneo, S. Distefano, F. Longo, A. Puliafito, A. Al-Anbuky,
A smart city lighting case study on an openstack-powered infrastructure,
In this paper, a novel MCS as-a-Service paradigm is proposed Sensors 15 (7) (2015) 16314. http://dx.doi.org/10.3390/s150716314. URL
which addresses key design and business challenges of current http://www.mdpi.com/1424-8220/15/7/16314.
MCS deployment practices. Specifically, a platform for MCS mass [16] G. Cardone, L. Foschini, P. Bellavista, A. Corradi, C. Borcea, M. Ta-
lasila, R. Curtmola, Fostering participaction in smart cities: a geo-social
deployment is presented that essentially splits the MCS service crowdsensing platform, IEEE Commun. Mag. 51 (6) (2013) 112–119.
application and infrastructure into two different levels supporting http://dx.doi.org/10.1109/MCOM.2013.6525603.
[17] M. Demirbas, M. Bayir, C. Akcora, Y. Yilmaz, H. Ferhatosmanoglu, Crowd-
distinct functions and several business exploitation avenues. sourced sensing and collaboration using twitter, in: 2010 IEEE International
The corresponding actors involved, their respective roles and Symposium on a World of Wireless Mobile and Multimedia Networks,
WoWMoM, 2010, pp. 1–9.
interactions, as well as potential benefits and drawbacks, are [18] Y. Chon, N.D. Lane, F. Li, H. Cha, F. Zhao, Automatically characterizing places
identified and discussed. Moreover, a prototype implementation with opportunistic crowdsensing using smartphones, in: Proceedings of the
2012 ACM Conference on Ubiquitous Computing, UbiComp ’12, ACM, New
that serves as a proof-of-concept for the conceptual framework is York, NY, USA, 2012, pp. 481–490.
presented, while an evaluation of the soundness of the proposed [19] S.B. Eisenman, E. Miluzzo, N.D. Lane, R.A. Peterson, G.-S. Ahn, A.T. Campbell,
paradigm is presented using (i) suitable scenarios for proof- Bikenet: A mobile sensing system for cyclist experience mapping, ACM Trans.
Sens. Netw. 6 (1) (2010) 6:1–6:39.
of-concept validation and (ii) a modeling approach through [20] X. Chen, E. Santos-Neto, M. Ripeanu, Crowdsourcing for on-street smart
Generalized Stochastic Petri Nets. The results demonstrate a parking, in: Proceedings of the Second ACM International Symposium on
Design and Analysis of Intelligent Vehicular Networks and Applications,
greater flexibility of the MCSaaS approach compared to plain DIVANet ’12, ACM, New York, NY, USA, 2012, pp. 1–8.
MCS, making room for speculation about its possible adoption [21] M.-R. Ra, B. Liu, T.F. La Porta, R. Govindan, Medusa: a programming framework
in commercial contexts, opening up new application domains for crowd-sensing applications, in: Proceedings of the 10th International
Conference on Mobile Systems, Applications, and Services, MobiSys ’12, ACM,
and unlocking business opportunities. Amid ongoing development New York, NY, USA, 2012, pp. 337–350.
efforts we believe we will have the chance to delve further into [22] Y. Xiao, P. Simoens, P. Pillai, K. Ha, M. Satyanarayanan, Lowering the barriers
to large-scale mobile crowdsensing, in: Proceedings of the 14th Workshop on
other interesting use cases and application scenarios, including Mobile Computing Systems and Applications, HotMobile ’13, ACM, New York,
experimentation on actual devices and heterogeneous platforms. NY, USA, 2013, pp. 9:1–9:6.
[23] C. Cornelius, A. Kapadia, D. Kotz, D. Peebles, M. Shin, N. Triandopou-
References los, Anonysense: Privacy-aware people-centric sensing, in: Proceed-
ings of the 6th International Conference on Mobile Systems, Ap-
plications, and Services, MobiSys ’08, ACM, New York, NY, USA,
[1] R. Ganti, F. Ye, H. Lei, Mobile crowdsensing: current state and 2008, pp. 211–224. http://dx.doi.org/10.1145/1378600.1378624. URL
future challenges, IEEE Commun. Mag. 49 (11) (2011) 32–39. http://doi.acm.org/10.1145/1378600.1378624.
http://dx.doi.org/10.1109/MCOM.2011.6069707. [24] M.-R. Ra, B. Liu, T.F. La Porta, R. Govindan, Medusa: A programming framework
[2] Y. Xiao, P. Simoens, P. Pillai, K. Ha, M. Satyanarayanan, Lowering the barriers for crowd-sensing applications, in: Proceedings of the 10th International
to large-scale mobile crowdsensing, in: Proceedings of the 14th Workshop on Conference on Mobile Systems, Applications, and Services, ACM, 2012,
Mobile Computing Systems and Applications, HotMobile ’13, ACM, New York, pp. 337–350.
NY, USA, 2013, pp. 9:1–9:6. http://dx.doi.org/10.1145/2444776.2444789. URL [25] N. Brouwers, K. Langendoen, Pogo, a middleware for mobile phone sensing,
http://doi.acm.org/10.1145/2444776.2444789. in: Proceedings of the 13th International Middleware Conference, Springer-
[3] European Commission Definition of a research and innovation policy Verlag New York, Inc., 2012, pp. 21–40.
leveraging cloud computing and iot combination. tender specifications, smart
[26] X. Hu, T. Chu, H. Chan, V. Leung, Vita: A crowdsensing-oriented mobile cyber-
2013/0037, Tech. rep., European Commission, 2013.
physical system, IEEE Trans. Emerg. Top. Comput. 1 (1) (2013) 148–165.
[4] J. Zhou, T. Leppanen, E. Harjula, M. Ylianttila, T. Ojala, C. Yu, H. Jin, L. http://dx.doi.org/10.1109/TETC.2013.2273359.
Yang, Cloudthings: A common architecture for integrating the internet of
[27] T. Das, P. Mohan, V.N. Padmanabhan, R. Ramjee, A. Sharma, Prism: platform for
things with cloud computing, in: 2013 IEEE 17th International Conference on
remote sensing using smartphones, in: Proceedings of the 8th International
Computer Supported Cooperative Work in Design, CSCWD, 2013, pp. 651–657.
Conference on Mobile Systems, Applications, and Services, ACM, 2010,
http://dx.doi.org/10.1109/CSCWD.2013.6581037.
pp. 63–76.
[5] A. Botta, W. de Donato, V. Persico, A. Pescape, On the integration of
cloud computing and internet of things, in: 2014 International Confer- [28] I. Fette, A. Melnikov, The WebSocket Protocol, RFC 6455, RFC Editor, December
ence on Future Internet of Things and Cloud, FiCloud, 2014, pp. 23–30. 2011. URLhttp://www.rfc-editor.org/rfc/rfc6455.txt.
http://dx.doi.org/10.1109/FiCloud.2014.14. [29] T. Metsch, A. Edmonds, R. Nyrén, A. Papaspyrou, Open cloud computing
[6] S. Distefano, G. Merlino, A. Puliafito, Sensing and actuation as a ser- interface–core, in: Open Grid Forum, OCCI-WG, Specification Document, 2010.
vice: A new development for clouds, in: Proceedings of the 2012 Available at: http://forge.gridforum.org/sf/go/doc16161.
IEEE 11th International Symposium on Network Computing and Ap- [30] O.T.T. Committee, Topology and Orchestration Specification for Cloud
plications, NCA ’12, IEEE Computer Society, Washington, DC, USA, Applications, Tech. Rep., OASIS, URL http://docs.oasis-open.org/tosca/TOSCA/
2012, pp. 272–275. http://dx.doi.org/10.1109/NCA.2012.38. URL v1.0/os/TOSCA-v1.0-os.html.
http://dx.doi.org/10.1109/NCA.2012.38. [31] R. Mordani, S.W. Chan, Java Servlet Specification, Sun Microsystems Inc.,
[7] D. Kartson, G. Balbo, S. Donatelli, G. Franceschinis, G. Conte, Modelling with version 3.
Generalized Stochastic Petri Nets, John Wiley & Sons, Inc., 1994. [32] Apache Tomcat. URL http://tomcat.apache.org/tomcat-8.0-doc/index.html.
[8] J. Burke, D. Estrin, M. Hansen, A. Parker, N. Ramanathan, S. Reddy, M.B. [33] A. Developers, Google cloud messaging for android.
Srivastava, Participatory sensing, in: In: Workshop on World-Sensor-Web [34] Openstack documentation. URL http://docs.openstack.org.
(WSW’06): Mobile Device Centric Sensor Networks and Applications, 2006, [35] Jenkins: An extensible open source continuous integration server [cited June
pp. 117–134. 2015]. URL https://jenkins-ci.org/.
 G. Merlino et al. / Future Generation Computer Systems 56 (2016) 623–639 639

author of more than 100 scientific papers. He is member of international conference

[36] AllJoyn. URL http://allseenalliance.org.
[37] PoliMi POLICLOUD [cited Dec 2014]. URL http://policloud.polimi.it/. committees and he is in the editorial boards of the International Journal of
[38] Waze: Free gps navigation with turn by turn [cited Dec. 2014]. URL Performability Engineering, Journal of Cloud Computing, International Journal of
https://www.waze.com/. Engineering and Industries, International Journal of Big Data, International Journal
[39] R. Long Cheu, C. Xie, D.-H. Lee, Probe vehicle population and sample size for of Computer Science & Information Technology Applications. He also acted as
arterial speed estimation, Compu.-Aided Civil Infrastruct. Eng. 17 (1) (2002) guest editors for special issues of the Journal of Risk and Reliability, Journal
53–60. of Performability Engineering, ACM Performance Evaluation Review and IEEE
[40] W.F. Adams, Road traffic considered as a random series (includes plates), J. ICE Transactions on Dependable and Secure Computing.
4 (1) (1936) 121–130.
[41] Android open source project [cited Dec. 2014]. URL http://source.android.
com/. Chrysa Papagianni is a Senior R&D Associate at the
[42] Genymotion. URL https://cloud.genymotion.com/page/doc/.
Network Management and Optimal Design Laboratory
[43] Android Debug Bridge. URL http://developer.android.com/tools/help/adb.html.
[44] S. Distefano, G. Merlino, A. Puliafito, A utility paradigm for iot: The sensing (NETMODE), National Technical University of Athens
cloud, Pervasive Mobile Comput. 20 (0) (2015) 127–144. http://dx.doi.org/10. (NTUA), Athens, Greece, since October 2010. She obtained
1016/j.pmcj.2014.09.006. URL http://www.sciencedirect.com/science/article/ her Diploma and the Ph.D. degree in Electrical and
pii/S157411921400159X. Computer Engineering, both from NTUA in 2003 and 2009
[45] S. Choi, M. Baik, C. Hwang, J. Gil, H. Yu, Volunteer availability based fault respectively. Her research interests lie in the area of
tolerant scheduling mechanism in desktop grid computing environment, computer networks with emphasis on cloud computing,
in: Third IEEE International Symposium on Network Computing and virtualization, network optimization and management,
Applications, 2004. Proceedings, NCA 2004, IEEE, 2004, pp. 366–371.
and service provisioning.

Giovanni Merlino is an Electronics Engineer (Univer-

Antonio Puliafito is a full professor of computer engi-
sity of Messina, Italy). He has participated in Italian Grid
neering at the University of Messina, Italy. His interests
Initiative-led activities, and since 2012 is a Research Fel-
include parallel and distributed systems, wireless tech-
low at University of Messina, meanwhile also participat-
nologies, GRID and Cloud computing. He is also interested
ing in an international Ph.D. programme at University of
in the performance evaluation of such systems. He partic-
Catania. His research interests include distributed systems
ipated and currently participate to several Italian an Eu-
with particular emphasis on virtualization, Grid and Cloud
ropean research projects on distributed computing, cyber
paradigms, ad-hoc and sensor networks, mobile platforms.
physical systems and smart cities.
He has been involved in national and international re-
search projects.

Stamatis Arkoulis received the BSc. degree in Computer

Science and the M.Sc. in Information Systems both from
Symeon Papavassiliou is a Professor with the Faculty
the Athens University of Economics and Business, Greece,
of Electrical and Computer Engineering Department,
in 2007 and 2009 respectively. He received his Ph.D.
National Technical University of Athens. He received the
degree in Electrical and Computer Engineering National
Diploma in Electrical and Computer Engineering from
Technical University of Athens (NTUA), Greece in 2014.
the National Technical University of Athens, Greece,
His research interests span the area of modeling and
in 1990, and the MSc and Ph.D. degrees in Electrical
performance evaluation of computer and communication
Engineering from Polytechnic University, Brooklyn, NY,
networks, resource reconfiguration in Cognitive Radio
USA, in 1992 and 1996 respectively. From 1995 to 1999, Dr.
networks and optimization modeling and design.
Papavassiliou was a senior technical staff member at AT&T
Laboratories in Middletown, New Jersey, and in August
Salvatore Distefano is an assistant professor at Po- 1999 he joined the Electrical and Computer Engineering
litecnico di Milano. His main research interests include Department at the New Jersey Institute of Technology (NJIT), where he was an
non-Markovian modeling; performance and reliability Associate Professor until 2004. Dr. Papavassiliou was awarded the Best Paper
evaluation; dependability; Quality of Service/Experience; Award in IEEE INFOCOM ’94, the AT&T Division Recognition and Achievement
Service Level Agreement; Parallel and Distributed Com- Award in 1997, the National Science Foundation (NSF) Career Award in 2003, and
puting, Grid, Cloud, Autonomic, Volunteer, Crowd Com- the Best Paper Award in IEEE WCNC 2012. Dr. Papavassiliou has an established
puting; Big Data; Software and Service Engineering. record of publications in his field of expertise, with more than two hundred
During his research activity, he has contributed in the de- technical journal and conference published papers. His main research interests lie
velopment of several tools such as WebSPN, ArgoPerfor- in the area of computer and communication networks with emphasis on wireless
mance and GS3. He has been involved in several national communications, resource allocation and optimization, network virtualization and
and international research projects. He is author and co- performance analysis and evaluation of stochastic systems.