2013 Eighth International Conference on P2P, Parallel, Grid, Cloud and Internet Computing
Towards the Cloud of Things
Sensing and Actuation as a Service, a key enabler for a new Cloud
paradigm
Salvatore Distefano
Dipartimento di Elettronica, Informazione e Bioingegneria
Politecnico di Milano
Piazza L. Da Vinci 32, 20133 Milano, Italy
Email: salvatore.distefano@polimi.it
AbstractCloud computing has emerged as one of the most
effective paradigms to enable cheap, elastic and user-friendly
access to computing, storage and networking resources. How-
ever, a key drawback of current Cloud solutions lies in the lack
of avenues for interaction with the physical world. This work
aims at contributing the design of an architecture for pervasive
ICT infrastructure, where new generation services leverage
the surrounding environment, collecting data and actuating
control strategies. In accordance with such vision computing,
storage, networking and sensing t as a whole in an all-round
encompassing Cloud-inspired provisioning model, paving the
way for innovative and value-added services, to be implemented
by bridging Clouds with the Internet of Things. Heterogeneous
resources should be aggregated and abstracted according to
tailored thing-like semantics, thus enabling a Things as a
Service paradigm and eventually disclosing what we call a
Cloud of Things (CoT).
Keywords-Cloud computing; volunteer contribution; re-
sources mashup; Sensors and Actuators as a Service; Things
as a Service; ontology.
I. I NTRODUCTION
Everybody is talking about Clouds nowadays, and this one
could easily be the tech mantra of the decade, and beyond,
if early success stories are any indication of things to come.
Yet, for all the hype and interest, both enabling technologies
and use cases appear to be quite well understood, if not
outright xed in stone. This paper challenges the status quo,
advocating a novel kind of Infrastructure as a Service, in
order to stimulate a discussion on whats next for Cloud
computing, especially where it meets the Internet of Things.
A rst-hand experience on any mass-market mobile gad-
get, not to mention ordinary desktops, can readily provide
clues about how ubiquitous Cloud-powered services already
are. Still cheaper hardware and economies of scale dont
play any role other than getting ever fatter clients in the
pockets of wider pools of customers.
Even just talking about customers may help to reveal the
biggest shortcoming of the current wisdom about Clouds:
the supply chain stops right before the end-user. If we try to
think about it, this isnt the mainstream view when talking
978-0-7695-5094-7/13 $31.00 2013 IEEE
DOI 10.1109/3PGCIC.2013.16
Giovanni Merlino, Antonio Puliato
Dipartimento di Ingeneria
Universita di Messina
Contrada di Dio, S. Agata, 98166 Messina, Italy
Email: {gmerlino,apuliafito}@unime.it
about content: there we have crowdsourcing at every corner,
and the impact of such avenues is never appreciated enough,
witness the undisputed success and overwhelming rise of
everything social. By the same token, we believe ordinary
users can and should be considered (potential) providers as
well, not only of content, but of infrastructure (and metadata
about it) as well. Therefore we are going to outline an
effective, abstract model for Clouds, where infrastructure
includes I/O in the form of sensors and actuators, provided
also by volunteering end-users.
On a wider scope and potentially deeper impact, this
paper also introduces things as infrastructure for Cloud-
like exploitation. In this sense we aim to provide a holistic
approach that allows to combine any kind of resource in
one pervasive infrastructure, disclosing new use cases where
value-added services mixing context-awareness, augmented
reality and social aspects can be provided through the Cloud.
A. Trends in computing
An impressive number of ever more powerful and inte-
grated devices (smartphones, household appliances, etc.) join
the Internet every year, and the global trafc volume (data,
voice, multimedia, etc.) is on the rise accordingly, foreshad-
owing a Web of smart devices, or things in the Internet
of Things (IoT) perspective, where a big role is played by
(wireless) sensor and actuator networks (SNs/WSNs).
The outlook points to an outright constellation of stan-
dalone devices and SNs alike, all going to be connected
over Internet. Such ecosystem of geographically distributed
resources cant be left untapped, and all those resources
should be made available for discovery and selection, ac-
cording to provided functionalities, eventually cooperating
autonomously towards a common goal.
Sensing and actuation resources in particular should be
part of the Cloud, not just as mere data endpoints, as
envisioned by current mobile Cloud trends, but abstracted,
virtualized and (administratively) grouped in Clouds, i.e. to
be dealt with along the same lines as computing and storage
resources in typical IaaS fashion.
60
B. IoT
There are several ideas and meanings attributed to the
emerging IoT concept. According to CERP [5], IoT can be
dened as a dynamic, scalable, global network infrastruc-
ture, endowed with self-adaptive facilities based on inter-
operable communication protocols, standards, taxonomies
(folksonomies) and ontologies, where things, either physi-
cal or virtual, have in turn physical attributes, identities, and
virtual personalities, and employ smart interfaces, seam-
lessly joining the information highway.
Things are thus poised to acquire active roles in social,
information and business processes, enabled to interact with
the external environment and among themselves by exchang-
ing sensed data, and to react autonomously to physical world
events, as well as to affect the environment they are plunged
into by means of triggers, and actuators acting upon, in the
end disclosing services, even without human intervention.
C. Keys to the Cloud
When talking about Clouds its crucial to identify, and
focus on, the mainstream categories, as well as the layers at
which implementations get developed and operations occur
in order to offer services. In particular, apart and above the
user- and developer-facing services, respectively Software as
a Service (SaaS) and Platform as as Service (PaaS), the real
engine behind Cloud enablement is in Infrastructure as a
Service (IaaS) innovations and technologies. Hybridization
(e.g. mashups) and exploitation of SaaS and PaaS brings new
services to wildly heterogeneous populations of customers,
yet IaaS is a relatively recent development in computing, and
a very powerful vector for new possibilities up the stacks.
Clouds therefore become endowed with computing, stor-
age and sensing too, thus creating a pervasive infrastructure
that is able to interact with the surrounding environment.
Novel possibilities for contextualization and geo-awareness
get unlocked by leveraging previously untapped infrastruc-
ture, i.e. sensors and actuators. Per naming conventions, as
applied to virtualized computing resources, i.e. IaaS, and
storage resources, in terms of DaaS, short for Data as a
Service, our approach could be dened with an acronym
such as SAaaS, i.e. Sensing and Actuation as a Service [11].
By nature and provenance of sensing resources, possibly
involving mobile devices in volatile settings, the scenario
is prone to be highly dynamic, well beyond the typical
(i.e. xed) infrastructure exploited for Cloud computing and
storage services. Thus, a workable plan to address such
issues suitably is to resort to the volunteer contribution
model as an underlying approach.
So-called heterogeneous resource mashup, i.e. orchestrat-
ing resources of volunteer-based sensing-powered Clouds
together with those from mainstream computing and storage
Clouds, whether for internal use or as public offerings, is
among the prominent issues to be addressed in building such
a wide-ranging Cloud (eco)system.
61
D. Linking the IoT to Clouds
Keeping in mind the foregoing description, a remarkable
intersection between SAaaS Clouds, volunteer contributions
and mashups may just lie in the IoT, more specically in
exposing underlying physical items through further abstrac-
tions according to thing-like semantics. The infrastructure
we are going to outline could indeed be the platform on top
of which such abstractions would be implemented, where
thing handlers, pointing to physical items (e.g. documents,
cars, products, parts, etc.), are available for discovery, selec-
tion and allocation, enabling the Things as a Service (TaaS)
provisioning model. Our purview is reframed accordingly,
in terms of a Cloud of Things (CoT) [10] that, compared to
IoT and WoT (Web of Things) paradigms, bears signicantly
higher expectations than what mere interconnection and
hyperlinking of things may yield.
Indeed the missing link could be a hypervisor of handles
on things to manage the lifecycle of several non-exclusive
perspectives on the same (physical) item. On one hand,
theres a need to decline a handle into a certain context
according to the task under request, thus binding a subset of
the pointed resources. On the other, a requirement is to book
just enough capabilities, leaving the underlying devices
open to concurrent exploitation, without further perspectives
overstepping on the scheduled ones, in pure IaaS fashion,
i.e. exposing elastic infrastructure from limited hardware
resources.
To implement this challenging vision, mechanisms and
tools for SAaaS, volunteer framework, resource mashup and
TaaS are needed. A tentative roadmap can be drafted iden-
tifying the following research and development milestones:
1) SAaaS enablement: WSNs, smartphones or other de-
vices, endowed with sensors/actuators, to be managed
in a Cloud environment;
2) Volunteer involvement: application of volunteer com-
puting approaches to SAaaS node enrolment;
3) Resource mashup: meeting special requirements with
the help of IaaS/DaaS Clouds;
4) Things abstraction and virtualization: disclosing the
CoT by mashups according to the TaaS paradigm.
The aforementioned phases would follow a chronologi-
cal/logical order but are not interlocked, i.e. they could par-
tially overlap. In accordance with the roadmap, a blueprint
of the architecture implementing the functionalities above
identied is shown in Fig. 1, where the stack as a whole
is depicted, outlining the modules for a TaaS-based CoT.
There is an IntraNode layer at the bottom, i.e. an execu-
tion environment at the level of a single node, where to
abstract away either embedded sensors, e.g. those available
on a smartphone, or standalone ones, usually belonging
to a network of uniformly capable devices (WSNs). At
the IntraCloud/InterNode level lies every interaction among
nodes belonging to a single (SAaaS) Cloud, to be generated
 SaaS - IoT SAaaS module

CoT Services Apps BPaaS

Abstraction & Virtualization
Unit
Node Manager
P InterCloud - PaaS
h
a
s TaaS Provider
e Adapter
4 TaaS module
Device
P
h
a
s
e
IntraCloud/ Figure 2. SAaaS module
3 SAaaS Providers
InterNode
P VolunteerCloud
h Existing IaaS Existing DaaS Management
a
s Providers Providers
e
Autonomous Autonomous
In Fig. 2 an high-level view of the internal architecture of
2
module module the SAaaS module is depicted, subdivided into three main
P
h IntraNode SAaaS
module
SAaaS
module
modules:
a
s
e Devices
Sensor Network
Gateways i. the Adapter interfaces directly with sensing/actuation
1
devices and keeps track of connectivity, translating
commands and relaying them to the underlying physical
Figure 1. Architectural schema and modules endpoints, by means of device-native communication
protocols.
ii. the Node Manager is in charge of policy enforcement,
and exported to the upper layer, InterCloud, where interop- exclusively at node level but enhanced with autonomic
erability and federation among Clouds are the core issues features, e.g. self-optimization with regards to energy
a TaaS provider needs to deal with. More specically the efciency and self-conguration to enable sensor virtu-
highest layer should mash up heterogeneous (IaaS/DaaS) alization.
Clouds with SAaaS ones, interacting with the former through iii. the Abstraction and Virtualization Unit exposes the
industry-wide interfaces and standards. There are four core functional aspects of the node as services, relays sen-
modules in this architecture, from the bottom up: SAaaS, sor events to upper layers, and virtualizes underly-
Autonomous, VolunteerCloud Management and TaaS. ing resources, e.g. repurposing or aggregating sen-
Aim of this paper is to provide an overview of the CoT, sors/actuators to shape the functionality the node ex-
and related enabling technologies. Although we have already ports.
implemented solutions for a few problems, here we focus on
The SAaaS module therefore provides sets of sen-
the big picture and on the main inspiration about the CoT,
sors/actuators in the widest possible meaning (e.g. printers,
thus only providing pointers to previous efforts and ongoing
webcams, human interaction peripherals), or even arbitrarily
work we are carrying on, starting also from, and referring
complex ones, e.g. weather sensors as virtual resources
to, existing solutions and background.
that consist of basic temperature, pressure and humidity
To this purpose, following the roadmap heretofore iden-
sensors, i.e. originating from their composition. Moreover
tied, the architecture will be detailed below.
it supports hypervisor-like features, i.e. splitting one sensor
II. SA AA S ENABLEMENT into a multitude by tuning e.g. sampling parameters, or even
repurposing it, e.g. providing motion detection services with
At the bottom of the stack, the SAaaS module is needed a camera, in order to cope with the lack of positioning
for the abstraction of sensing and actuation resources, en- sensors.
hanced with policies and data handling. It exposes function- Starting from existing languages and models providing
alities to be provided at the level of what would represent formal descriptions of sensor systems and processes as-
a single node, i.e. a management domain, comprising either sociated with sensor observation (SensorML, Observations
a WSN [12], [4], [3], hidden behind a gateway, or a set and Measurements Schema within the OGC Sensor Web
of sensors embedded in a standalone device. A node, when Enablement [20]), the lower level of the above architecture,
talking about SNs, may turn out to be less easily identiable i.e. the adapter and the abstraction modules, has been already
when compared with the one-to-one mapping that naturally implemented into the CLEVER stack [14].
springs to mind when talking about smartphones and other The Node Manager and the Abstraction & Virtualiza-
personal devices: typically an SN may be made up of tion Unit are work in progress, also based on the W3C
thousands of sensors, yet exposing a limited subset of sinks, Semantic Sensor Network Incubator Group initiative, ex-
amongst other considerations the only components where tending SensorML-enabled syntactic level interoperability
nodal modules of the stack could be deployed.

62
 Volunteer Framework
VolunteerCloud
Autonomous Management
APIs
Module
Reward QoS SLA
System Manager Manager
Module
SAaaS module
Figure 3. Volunteer Framework
to a semantic level, through the development of both an
ontology for describing sensors and their data, and an
annotation framework for adding semantic metadata to the
SWE standards.
However those standards do not yet provide a full-edged
semantic description of the sensor and the phenomena it
measures, a central theme in Section V.
III. VOLUNTEER INVOLVEMENT
The Volunteer framework is needed to consolidate
volatile, ad-hoc resources and services, such as volunteer-
borne sensors, in a Cloud setting. The core duties are
about techniques for mitigation of the effects brought about
by resource churn, where performance is largely dynamic,
lifespan is short, nodes are heterogeneous and mobile, and
information on their status is partial and often already out-
of-date when the need arises. It follows that, while operating
on largely unpredictable and unreliable resources, this layer
provides increasingly dependable services to the upper ones.
Decentralized, on-the-y selection of services requires
dynamic binding, and involves active service tracking, mon-
itoring and rich metadata, including QoS/SLA metrics.
Distributed broker agents coordinate to keep track of the
energy prole, quality, availability, location and context of
services, and pick resources according to criteria and con-
straints. Another signicant topic is about how information
and metadata about services (e.g. QoS, SLA) should be
handled and indexed, considering distribution, heterogeneity
and likelihood to quickly get outdated, due to the steady
turnaround of volunteers.
Moreover, in order to increase the reliability and avail-
ability of services, a multi-dimensional reward system is
needed, motivating contributors to provide more predictable
metadata and stay involved for longer.
The Volunteer Framework is logically structured into
two modules, as depicted in Fig. 3: the VolunteerCloud
Management and the Autonomous ones. The former stores
and executes management strategies at the Cloud level by
means of a steady interaction with every node belonging
to the newly-formed (sensing) Cloud, while the latter is
to be deployed into each node of the SAaaS Cloud in
63
order to enforce self-adaptively the policies coming from
the VolunteerCloud Management module.
Looking at the framework as a whole, it is also reason-
able to leave room for fully autonomous volunteer-SAaaS
Clouds, set with well-dened default policies (e.g. best-
effort), where the VolunteerCloud Management module is
not strictly needed, thus leaving all the duties to be self-
managed by the Autonomous module.
The Autonomous module makes up a decoupled, two-
level, hierarchical autonomic management system in com-
bination with the SAaaS Node Manager, the whole being
entirely deployed and running on the node. The former
works at node level, e.g. within a SN domain, whereas the
latter tracks and enforces higher-level Cloud targets.
The Volunteer Framework thus builds a volunteer-based
sensing Cloud upon the SAaaS module, and exports services
for mashups and TaaS, by providing the following compo-
nents, spanning the two aforementioned layers:
i. Reward System: increases reliability and availability of
volunteer-borne services based on sensors/actuators, and
keeps track of resource usage for management and
billing purposes;
ii. QoS Manager: implements the monitoring framework
for quality of service, at the level of a single Cloud;
iii. SLA Manager: enforces the SLAs ratied by the coop-
erating layers of the whole stack, e.g. TaaS, mashups or
just peer Clouds.
In summary, the Autonomous module logically translates
and tie-breaks reward, QoS and SLA autonomic policies
on the SAaaS nodes, applying directives coming from the
VolunteerCloud Management module. In order to achieve the
best node conguration while satisfying most QoS, SLA and
Reward-Credit system constraints, such policies have to be
locally coordinated.
In relation to these issues we are going to leverage the
experience acquired, and work done, in the Cloud@Home
project [7], [6], [8], aimed at implementing fully volunteer-
contributed Clouds that can interoperate with, and federate
to, commercial Clouds, mixing aspects and ideas coming
from volunteer approaches (credit systems, BOINC [1]) and
P2P mechanisms (i.e. Jingle, as per XMPP enhancement
proposals) with the Cloud provisioning model.
With regards to the CoT, a critical task, up to the Au-
tonomous module, is to provide support for identication
of things. The collaboration of node owners and adminis-
trators, providing specic input to augment knowledge on
things with metadata, through semantic Web technologies
[15], is needed in order to further the CoT agenda. This
requires a common and well-known ontology framework
as a prerequisite, shared and agreed upon by both TaaS
owners/administrators and providers.
Still, higher-level mechanisms and tools have to be em-
ployed provider-side, e.g. implementing feature extraction

TaaS module
Frontend
Things Abstraction
& Virtualization
High-Level Manager
Cloud Driver
Figure 4. TaaS module architecture
services, complementary to user-generated metadata, in or-
der to properly identify and describe things, as discussed in
Section V.
IV. R ESOURCE MASHUP
The TaaS module deals with issues related to the upper
management duties for the overall infrastructure, and builds
on top of already formed (sensing/actuation, computing
and storage) Clouds, enabling heterogeneous infrastructure
mashups, in particular geared towards the CoT.
Location awareness, and other contextual metadata, are
poised to help deeply in the optimisation of computing,
storage and sensing interCloud management, hence those
should be considered as potential key differentiators of the
proposed approach for an interCloud solution that needs to
work in a distributed fashion (e.g. policy-based), so as to
provide support for heterogeneous Clouds.
Issues to be addressed here are: interoperability, abstrac-
tion, virtualization and management of mashed up resources
for TaaS, SLA, QoS, security (e.g. trustiness, privacy, iden-
tity management), billing and accounting, many of which
are to be tackled across the whole framework.
In Fig. 4 a draft outline of the structure of the TaaS
module is depicted, composed of four main parts: the Cloud
Driver, the High-Level Manager, the Things Abstraction &
Virtualization and the Frontend.
The Cloud Driver provides interfaces to volunteer Clouds,
and non-volunteer ones as well, collects and manages infor-
mation about Clouds availability and provided services, in
terms of both functional and non-functional properties, e.g.
QoS, costs and reliability.
Its main duty is to provide interoperability among vol-
unteer and proprietary Clouds alike, and to cooperate with
the High-Level Manager to carry out heterogeneous resource
discovery.
The High-Level Manager in turn is a key building block of
TaaS: it manages incoming requests of mashed-up cross-
type resources by splitting them into simpler single-kind
requests, to be dispatched to the corresponding SAaaS, IaaS
or DaaS providers, thus can be compared to a Cloud broker.
Other issues to be considered are related to security, QoS,
64
trustworthiness, billing and reward-credit systems, and non-
functional properties as well, negotiated through tailor-made
SLAs.
A further high-level abstraction is needed in the TaaS
module, where mashed up resources are handled as things
in a CoT perspective, chiey requiring semantic efforts in
the assignment of thing-like meaning to resources. These
tasks belong to the Things Abstraction & Virtualization, as
described in detail in Section V.
At last we have the Frontend, providing tools for cus-
tomer interactions with TaaS Clouds, collecting and relaying
requests issued by users, e.g. through a Web portal, imple-
menting access facilities for the Cloud, in particular related
to identication, authentication and authorization, e.g. by
means of an infrastructure based on PKI and related tech.
A good starting point for resource mashup could be the
one by existing infrastructure providers, in terms of both
IaaS (EC2 and the like) and DaaS (S3 or similar) therefore
exploring issues in mashing up heterogeneous resources. In
particular there are some interesting third-party solutions
(Rapidscale, EMC2) implementing brokering, management
and coordination activities.
On the interoperability and federation front, our re-
search unit is developing CLEVER, an innovative IaaS
stack offering an advanced storage, messaging and presence
framework, hinged on the XMPP family of standards, for
interconnection among administrative domains.
V. L AST MILE TO THE C OT:
ABSTRACTION AND VIRTUALIZATION
The main theme of this efforts is in relation to the Internet
of Things, and lies in what we identied as the Cloud of
Things, or CoT, paradigm.
Indeed the underlying infrastructure, as heretofore de-
scribed, is geared towards building a CoT framework, since
things, per the IoT denition, RFID-tagged or otherwise
featuring smart sensors/actuators, are typically mobile, and
a stack of this kind is poised to provide all the enabling
technologies to tackle this vision.
It goes without saying that such a framework would
turn out to be very valuable even without a CoT level.
Yet the latter can be a killer application for this kind of
infrastructure, where the pay-off is an IoT scenario, enriched
by enhanced context and unlocked degrees of freedom for
discovery and allocation of resources, setting the stage for
a marketplace of things.
As outlined in Section IV, the last step along the way
to the CoT goes through the abstraction of mashed up
resources, by virtue of renements, specications and im-
plementations based on the notion of thing, semantically
tagging the underlying items.
In the TaaS module the Things Abstraction & Virtualiza-
tion block has to enable search of things satisfying user-
dened requirements, e.g. devices with certain monitoring

Things Abstraction &
Virtualization
Management
Virtualization
Mapping & Transformation
Detection & Identication
Mashed-up Resources
Figure 5. Things Abstraction & Virtualization module architecture
features, vehicles inside specic areas, people (or things)
whose positions or trajectories follow a predened pattern,
and so on, according to the application domain, per request
specication.
Moreover pre-processing and ltering of data are among
its core duties, in order to trigger custom algorithms and
provide new value added services, e.g. goods tracking,
trafc control, emergency management, remote monitoring.
Therefore ontologies, and the taxonomies they encode, are
required to label things.
An abstraction layer over the mashed up resources can be
decomposed in a Detection & Identication module below,
and a Mapping & Transformation one above, as depicted in
Figure 5.
Its useful to pinpoint use cases based on smart cities
scenarios, thus following through with examples, in order
to lay out a detailed description of these layers. Lets focus
on (urban) trafc control and major events management as
driving applications of the aforementioned scenario.
From the bottom up, theres the Detection & Identication
module rst, tasked with detection of features that can help
identifying things, i.e. collecting both inner and (contextual)
user-provided information relayed from the lower levels, as
well as autonomously generated relevant metadata by means
of deployed (or builtin) check-in mechanisms, or traps, to
signal the availability of new clues for otherwise already
tagged things.
One more avenue is top-down feature extraction, central-
ized yet scalable, i.e. hierarchical and inherently level-local,
services for pattern recognition out of historical and real-
time samples. Moreover, metadata collected through one of
these channels could be validated against info from other
sources.
All these techniques should therefore be viewed as
matched parts of the whole machinery, as setting those
mechanisms in motion at the earliest, i.e. node enrolment
stage, is a precondition for proactive collection of relevant
clues to be passed on to the Identication step, to be in
turn carried out by a semantic inference engine, for instance
65
based on a set of OWL DL [2] ontologies, to be bootstrapped
and populated [9] through semantic partitioning [21], taxon-
omy mining and instance extraction.
The ontologies should be coupled with a query metasys-
tem [17], [22], hinged on frame-based languages [16] with
Manchester syntax, in order to avoid caring about domain-
specic syntax quirks. While crucial, domain ontologies
are only part of the answer here, as even narrowing the
scope for identication to a limited selection of predened
categories, i.e. according to mainstream use-cases, cannot
entirely eschew cross domain-spanning relations. In this
context, ontology alignment [13] would come to the rescue,
possibly aided by upper (foundation) ontologies [19] as glue,
in the role of ancestors along the semantic hierarchy.
As an example at this stage, a few smartphone owners
could volunteer for being part of the Cloud, and the app UI
would ask info to the participant in an opt-out fashion. Yet
external venue-based check-in machinery (i.e. at the stadium,
concert hall, gas station) could still be triggered unaided as
soon as a proximity event res, and tag phones, or more
accurately, the embedded sensors onboard, accordingly, by
their identiers in the Cloud. In both situations, lightweight
pattern recognition methods could be applied to the envi-
ronment the mobiles are plunged into, in order to enrich
acquired metadata.
Up one level the Mapping & Transformation step takes
place, where the abstraction mechanisms come to fruition.
Here things, or individuals according to semantic termi-
nology, make up both the inputs and outputs of this block,
undergoing the following operations, to name a few:
mapping one thing to belong to more classes;
decomposing a thing into its parts;
morphing the class of an individual in another one more
apt (e.g. higher popularity) to be matched to requests
for service, albeit under well-dened constraints, for
instance a sibling relationship.
Other typical use cases would include specialization or
generalization of the classes things belong to, tantamount
to semantic super-/sub-classing, by traversal of the ontology
graph.
Furthering our scenario-based blueprint, an identity map-
ping could be established in order to relay the output of
the classication (Identication) block transparently to the
Virtualization level, in the simplest case. On the other hand,
already stretching a bit the usefulness and complexity of
the use case, an aggregation or composition of things could
be the output. Pushing the envelope, recursive relationships
may help generating full-blown ecosystems. Summing it
up, whichever the transformations or the complexity, even
at this step one or more reasoners [23] are needed, endowed
with relevant knowledgebases [18].
In line with the examples heretofore developed, we can
think of situations like:
 a commuter that becomes also a member of an audience
(mapping);
a group of people that gets tagged as a crowd, for
instance a ash mob (aggregation);
a car unbundled into its parts, a family into its members,
or a theater into its different areas (decomposition);
a trafc jam that just melts into an uneventful ow
(morphing);
an unidentied vehicle whose description gets further
rened into a SUV (specialization), and so on.
Still treading the analogy between IaaS and TaaS, whereas
the Abstraction level provides one or several representations
for a single item or for a whole environment of things, en-
coded as semantic cardinality, the Virtualization layer could
indeed be thought as exposing functionalities equivalent to
a hypervisor of handles on the abstracted things. In this
way it is able to arbitrate and manage instantiation and
lifecycle of multiple perspectives on the same physical
item, i.e. sets of handles abstracted from (e.g. sensing) nodes
belonging to the semantically dened individual. This allows
to contextualize the whole thing, i.e. the generated set of its
resources, to pending tasks, binding a subset of resources to
the request per the application domain.
As an example, a request for monitoring the speed of vehi-
cles on a certain road, along with their spatial conguration,
for instance for trafc jam forecasting and prevention, would
translate into instantiation of perspectives on the enclosed
vehicles. Each handle therefore represents a perspective
on a car (or a group of), in this case just made up of
geopositioning and motion sensors allocated from onboard
devices (e.g. in-dash) as well as volatile ones, such as those
on the mobiles of passengers.
Bringing home the point, virtualization means, by IaaS
denition, exposing more infrastructure than the available
hardware, in order to keep the pipe full at all times,
concurrently satisfying as many requests as possible, thus
squeezing maximum value from the setup expenses, while
keeping the underlying constraints unbeknownst to the cus-
tomer.
In the CoT setting, virtualizing means guaranteeing non-
exclusive access to the devices exposed in a perspective
where possible, as long as the Abstraction layer exports
resources satisfying the minimum requirements under the
constraints emanating from the request for service, hence
justifying once more the need for transformations.
Keeping with our example, on the aforementioned sensors
sampling would be tuned in order to export enough func-
tionality for the task at hand, leaving the same underlying
devices open to further exploitation through request multi-
plexing for new perspectives, made up of handles compatible
with the allocations already in place.
At the top of the whole module a Management system
would deal with discovery, allocation and business logic
mechanisms, as per best practices for plain IaaS. In order
66
to ease the scaling and timing issues, a probabilistic kind
of matching [15] for discovery needs to be achieved, by
combining approximate, or non-deterministic as a last resort,
classication with thing (class) look-up supported by e.g.
requirements substitution. At lower levels the prevalent
volunteer nature of contributors would naturally lead towards
P2P methods (e.g. distributed hash tables) for indexing and
discovery duties. Yet such an approach would be a good t
also at the TaaS layer, if we consider that, however (partly)
centralized, the indexing and labeling of the things would
happen across families of resources, administrative domains
or Clouds. Since TaaS allocation and business logic policies
have to be mainly mapped into lower level policies on
mashed up resources, in such case the Management system
implements a kind of wrapper of incoming requests into
mashed-up ones, from that point onwards managed by High
Level Manager of the TaaS module, as discussed in Section
IV.
Recapping, in a top-down fashion, the management layer
processes free-form requests probabilistically matching ap-
plication domains, while the virtualization one below instan-
tiates perspectives on things in a deterministic way, based
on matched domains as relayed from above.
VI. R EADY FOR C OT?
Theres no doubt that Cloud computing and IoT are
among the trendiest topics in ICT. Here we tried to address
unexplored ideas at their intersection, where things may
be provided dynamically according to a service oriented
paradigm, thus shifting the boundaries towards a Cloud of
Things, i.e. employing the Cloud provisioning model to meet
user needs according to guaranteed service levels.
The CoT thus can only be built atop a platform suited for
the management of:
i. sensing (and actuation) resources exposed as a ser-
vice (SAaaS) from mobiles and SNs alike, addressing
volatile availability and reliability, especially when mo-
biles are involved, by means of volunteer computing-
inspired techniques;
ii. mashed up resources, provided through heterogeneous
(IaaS, DaaS and SAaaS) Clouds, also addressing issues
related to interoperability and federation;
iii. things, by means of suitable ontologies and semantic
approaches, to be adopted en masse and standardized
upon by most users, customers and providers, in order
to label, map and transform mashups in a TaaS fashion.
In this way TaaS unlocks pervasive, innovative and value-
added applications under the guise of CoT to any customer,
at the same time a potential provider as well, thus disclosing
an open marketplace for things. These new avenues could
require input from, or be input for, innovative research on
revenue models and business methods, behavioral and social
aspects (i.e. psychology, sociology, public relations), legal
issues (service level agreements, licensing, privacy), service
engineering (human-machine interaction, visualization, de-
sign), and other elds as well.
R EFERENCES
[1] David P. Anderson and Gilles Fedak. The computational and
storage potential of volunteer computing. In CCGRID 06,
pages 7380. IEEE Computer Society, 2006.
[2] Sean Bechhofer, Frank van Harmelen, Jim Hendler, Ian Hor-
rocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and
Lynn Andrea Stein. OWL Web Ontology Language Reference.
W3C, dean, mike and schreiber, guus edition, February 2004.
[3] D. Bruneo, A. Puliato, and M. Scarpa. Dependability
analysis of wireless sensor networks with active-sleep cycles
and redundant nodes. In Proceedings of the First Workshop on
DYnamic Aspects in DEpendability Models for Fault-Tolerant
Systems, DYADEM-FTS 10, pages 2530, New York, NY,
USA, 2010. ACM.
[4] Dario Bruneo, Salvatore Distefano, Francesco Longo, Anto-
nio Puliato, and Marco Scarpa. Evaluating wireless sensor
node longevity through markovian techniques. Computer
Networks, 56(2):521532, 2012.
[5] Cluster of European Research Projects on the Internet of
Things (CERP-IoT). Internet of Things Strategic Re-
search Roadmap. Technical report, European Commis-
sion - Information Society and Media DG, http://www.grifs-
project.eu/data/File/CERP-IoTAccessed May 2013 2009.
[6] V. D. Cunsolo, S. Distefano, A. Puliato, and M. Scarpa.
Cloud@home: Bridging the gap between volunteer and cloud
computing. In 5th International Conference on Intelligent
Computing, ICIC 2009, LNCS, pages 423432. Springer,
2009.
[7] V.D. Cunsolo, S. Distefano, A. Puliato, and M. Scarpa.
Volunteer computing and desktop cloud: The cloud@home
paradigm. In Network Computing and Applications, 2009.
NCA 2009. Eighth IEEE International Symposium on, pages
134 139, july 2009.
[8] A. Cuomo, G. Di Modica, S. Distefano, A. Puliato, M. Rak,
O. Tomarchio, S. Venticinque, and U. Villano. An sla-based
broker for cloud infrastructures. J. Grid Computig, 11(1):1
25, 2013.
[9] H. Davalcu, S. Vadrevu, S. Nagarajan, and I.V. Ramakrishnan.
Ontominer: bootstrapping and populating ontologies from
domain-specic web sites. Intelligent Systems, IEEE, 18(5):24
33, sep/oct 2003.
[10] S. Distefano, G. Merlino, and A. Puliato. Enabling the
cloud of things. In Sixth IEEE International Conference
on Innovative Mobile and Internet Services in Ubiquitous
Computing, IMIS, pages 858863. IEEE, 2012.
[11] S. Distefano, G. Merlino, and A. Puliato. Sensing and
actuation as a service: A new development for clouds. In
11th IEEE International Symposium on Network Computing
and Applications, NCA, pages 272275. IEEE, 2012.
67
[12] Salvatore Distefano. Evaluating reliability of wsn with
sleep/wake-up interfering nodes. Int. J. Systems Science,
44(10):17931806, 2013.
[13] Marc Ehrig. Ontology Alignment: Bridging the Semantic Gap,
volume 4 of Semantic Web And Beyond Computing for Human
Experience. Springer, 2007.
[14] M. Fazio, M. Villari, and A. Puliato. Sensing technologies
for homeland security in cloud environments. In Sensing
Technology (ICST), 2011 Fifth International Conference on,
pages 165 170, 28 2011-dec. 1 2011.
[15] Sara Hachem, Thiago Teixeira, and Valerie Issarny. Ontolo-
gies for the internet of things. In Proceedings of the 8th
Middleware Doctoral Symposium, MDS 11, pages 3:13:6,
New York, NY, USA, 2011. ACM.
[16] Matthew Horridge, Holger Knublauch, Alan Rector, Robert
Stevens, and Chris Wroe. A Practical Guide To Building
OWL Ontologies Using The Protege-OWL Plugin and CO-
ODE Tools Edition 1.0, August 2004.
[17] Dimitrios A. Koutsomitropoulos, Ricardo Borillo Domenech,
and Georgia D. Solomou. A structured semantic query inter-
face for reasoning-based search and retrieval. In Proceedings
of the 8th extended semantic web conference on The semantic
web: research and applications - Volume Part I, ESWC11,
pages 1731. Springer-Verlag, 2011.
[18] Holger Neuhaus and Michael Compton. The Semantic Sensor
Network Ontology: A Generic Language to Describe Sensor
Assets. In AGILE Workshop Challenges in Geospatial Data
Harmonisation, 2009.
[19] Ian Niles and Adam Pease. Towards a standard upper
ontology. In Proceedings of the international conference on
Formal Ontology in Information Systems - Volume 2001, FOIS
01, pages 29, New York, NY, USA, 2001. ACM.
[20] C. Reed, M. Botts, J. Davidson, and G. Percivall. Ogc(r)
sensor web enablement: overview and high level achhitecture.
In Autotestcon, 2007 IEEE, pages 372 380, sept. 2007.
[21] Julian Seidenberg and Alan Rector. Web ontology segmen-
tation: analysis, classication and use. In Proceedings of the
15th international conference on World Wide Web, WWW
06, pages 1322, New York, NY, USA, 2006. ACM.
[22] Smith M. Sirin E., Bulka B. Terp: Syntax for owl-friendly
sparql queries. In 7th OWL Experiences and Directions
Workshop, San Francisco, 2010.
[23] Peter Yeh, Bruce Porter, and Ken Barker. Mining trans-
formation rules for semantic matching. In ECML/PKDD
2nd International Workshop on Mining Graphs, Trees, and
Sequences, pages 8394, 2004.